文章目錄
前言
本週正式迴歸正常的辦公場所，關於遠程辦公和公司辦公我只能說各有各的好壞，說實話我會更偏向在公司辦公，後面有機會寫篇文章分享下。本週繼續專欄學習計劃，目前已經進展到專欄的尾聲了，正篇內容基本可以在這周可以搞定，這周的主題是運行維護篇，以下內容是我的總結：
35 | 版本發佈：軟件上線只是新的開始
業界通用版本編號
主版本號 . 子版本號.[. 修正版本號.[構建版本號]]
比如：1.2.1.1
主版本和子版本分別在大功能和小功能編號時累加，修正版本標識Bug修復，而構建版本號基於每一次構建，自動累加。
版本的發佈規劃
- 首先要規劃要發佈的功能
- 定義好發佈的質量標準
- 設計好發佈的策略（比如：Beta策略，讓小部分用戶先體驗新功能）
- 最後有一個綜合性的版本發佈計劃
業界好的發佈規範流程
- 在發佈之前要做代碼凍結（封版，不允許新的功能增加）
- 對代碼凍結後發現的Bug要分級（是否在發佈前修改，還是發佈後修改）
- 每次修復Bug後，發佈新的候選版本
- 每次部署新的候選發佈版本，要做迴歸測試（確認Bug已經修復並且無引入新的Bug）
- 申請上線發佈（正規的審批流程）
- 部署發佈（確保線上運行正常）
- 上線後的測試（發現問題採取回滾策略）
上線後要做的事情
- 提供用戶反饋的渠道
- 針對版本進行監控，收集必要的信息；比如：App Crash的Log、服務器資源佔用情況、API出錯比例、網頁響應速度等
- 回顧項目過程，總結覆盤，將經驗變成能力
這一節講的內容講的是軟件項目上線之後要關注的事情，上線僅僅只是開始，一個產品的好壞除了更新迭代，也得靠日常運營，營造好的品牌口碑，提高曝光度。作爲一個軟件工程師，能夠負責一款受人喜愛的產品研發，自己也能從中收穫到成就感。
36 | DevOps工程師到底要做什麼事情？
什麼是DevOps?
先來回答DevOps解決什麼問題，現代運維模式存在兩個挑戰：
- 服務器的規模快速增長和虛擬化技術的快速發展
- 高頻的部署發佈
DevOps的出現是爲了解決開發和運維之間的協作問題，提升運維開發和自動化能力。
DevOps是開發（Development）和運維（Operations）一切緊密協作的工作方式，從而可以更快更可靠的構建、測試和發佈軟件。
DevOps帶來的好處
- 軟件的構建、測試和發佈過程高度自動化
- 信息更加透明和易於策略
- 培養跨職能協作的文化
DevOps工程師要做什麼？
- 幫助團隊建立基於持續集成和持續交付工作流程
- 建立一套基於日誌的監控報警的系統，以及故障響應的流程
- 構建基於雲計算和虛擬化技術的基礎設施
- 幫助團隊構建協作文化
關於這一節的內容，我最大的感受就是不僅僅只是運維工程師需要學習DevOps，而是所有開發都應該學習DevOps，開發和運維本身就分不開，構建協作的文化，提升研發效能，不管對產品還是團隊都是非常好的實踐。
擴展閱讀：
DevOps 前世今生 | mPaaS 線上直播 CodeHub #1 回顧
孫宇聰：來自Google的DevOps理念及實踐
關於 DevOps ，咱們聊的可能不是一回事
37 | 遇到線上故障，你和高手的差距在哪裏？
新手處理線上故障
- 遇到複雜的線上故障，不知道怎麼下手
- 遇到線上故障，會想着馬上修復Bug，匆忙打補丁，可能會引入新的Bug，造成更嚴重的損失
- 不知道如何快速定位Bug
- 解決完線上故障，可能還會重犯
高手處理線上故障
- 會有一套解決問題的步驟
- 第一步，評估影響範圍
- 第二步，試圖重現問題
- 第三步，臨時方案和終極方案
- 第四步，風險評估及持續優化
- 遇到故障，會先評級、評估影響範圍，優先保證業務可用，恢復生產，再考慮修復Bug
- 通過有效手段重現Bug，逐步縮小問題範圍，定位具體的錯誤位置
- 會仔細分析Bug產生的原因，從根本上解決，避免類似的故障再次發生
大廠處理線上故障值得借鑑的地方
大廠其實是把高手解決故障的方式，變成故障處理的流程和操作手冊，並且通過反覆地故障演習。不斷練習和強化對故障處理的流程，讓系統更健壯，讓新手也可以快速上手，做到高效處理線上故障。
- 故障報警和輪值機制
- 找對故障服務最熟悉的人
- 輪值on call，報警響應
- 實戰演習（混沌工程）
- 日誌記錄和分析工具（搭建ELK或Splunk這樣的日誌分析系統）
- 其他好的實踐
- 灰度發佈策略
- 開關控制灰度
這節課讓我更深刻的瞭解處理線上故障的實踐，前後端解決具體問題的方法可能會有所不同，但總體解決策略和思路是類似的。關於工程師解決問題的和分析問題的能力其實也是我們的核心競爭力，如何更好的解決問題，提升業務價值，是我們在整個成長過程中需要不停去思考並踐行的。
38 | 日誌管理：如何藉助工具快速發現和定位產品問題 ？
這節課寶玉老師主要分享了怎麼通過搭建日誌管理系統來幫助我們快速發現和定位產品問題。更多是偏後端的內容，這裏我就基於文章內容進行以下總結：
什麼是日誌管理？
日誌就是操作系統和應用軟件自動生成的事件說明或者消息記錄，包含了時間、日誌信息。
日誌管理就是指對系統和應用程序產生的日誌進行處理的方法，包括對日誌進行統一收集，對日誌數據進行篩選和解析，統一存儲，還要讓它們可以方便被檢索。
日誌管理系統解決的肉眼檢索困難，服務架構複雜，無法統一記錄和檢索的問題
如何快速發現和定位問題？
- 集中式管理，統一檢索
- 統一收集和實時統計，生成可視化圖表
- 根據日誌數值設置規則自動報警
業內大廠的最佳實踐
- 日誌採集和解析
- 解析成結構化數據，方便檢索
- 存儲和搜索
- 索引和分析，快速檢索出結果
- 結果可視化
- 觀察數據走勢曲線
- 監控和報警
- 設定觸發報警規則，通知值班人員處理
39 | 項目總結：做好項目覆盤，把經驗變成能力
覆盤的常見問題
- 總結不出來有效的結論（過流水賬）
- 沒做好是客觀原因導致的（沒有想清楚）
- 知道什麼原因，但不知道該怎麼辦（沒有解決思路）
覆盤的四個基本步驟
- 回顧項目目標
- 清晰描述當初定的項目目標
- 里程碑是什麼，能否做到準確客觀（可量化）
- 評估項目結果
列出好的差異和壞的差異，就是做得好的部分和不好的部分
- 分析原因
分析導致項目結果好跟壞的原因，好的比如改進了研發流程，工具的使用，規範了項目流程；壞的比如老闆過多幹預產品需求，週期過長，頻繁變更導致延期等
- 總結規律，落實行動
基於原因總結規律，保持好的實踐，停止不好的實踐或尋求改變
這節課能給我們的啓發是很多的，當時也發了個朋友圈：
定期回顧項目進展和目標，讓團隊小夥伴知道勁往哪裏使，避免無意義的抱怨，解決問題爲主，讓寫代碼變得更加美好。
最後
運行維護篇作爲軟件工程當中最後的環節，讓我們知道軟件上線僅僅只是第一步，後續的運行維護纔是我們讓產品生命力繼續發光的手段，只有產品成功，我們研發的價值才能體現。在軟件研發過程中，自然會有做的好的和不好的，階段性覆盤是我們能夠將經驗轉化成能力的好實踐，經過這段時間的學習，我也很想將這裏面學習到的內容推廣到我們的團隊當中，藉助好的方法論一定能夠讓我們團隊研發實力更上一層樓。