文章目錄

• • 前言
  • 35 | 版本發布：軟件上線只是新的開始
  • 36 | DevOps工程師到底要做什么事情？
  • 37 | 遇到線上故障，你和高手的差距在哪里？
  • 38 | 日志管理：如何借助工具快速發現和定位產品問題 ？
  • 39 | 項目總結：做好項目復盤，把經驗變成能力
  • 最后

前言

本周正式回歸正常的辦公場所，關于遠程辦公和公司辦公我只能說各有各的好壞，說實話我會更偏向在公司辦公，后面有機會寫篇文章分享下。本周繼續專欄學習計劃，目前已經進展到專欄的尾聲了，正篇內容基本可以在這周可以搞定，這周的主題是運行維護篇，以下內容是我的總結：

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 | 項目總結：做好項目復盤，把經驗變成能力

復盤的常見問題

• 總結不出來有效的結論（過流水賬）
• 沒做好是客觀原因導致的（沒有想清楚）
• 知道什么原因，但不知道該怎么辦（沒有解決思路）

復盤的四個基本步驟

回顧項目目標

• 清晰描述當初定的項目目標
• 里程碑是什么，能否做到準確客觀（可量化）

評估項目結果

列出好的差異和壞的差異，就是做得好的部分和不好的部分

分析原因

分析導致項目結果好跟壞的原因，好的比如改進了研發流程，工具的使用，規范了項目流程；壞的比如老板過多干預產品需求，周期過長，頻繁變更導致延期等

總結規律，落實行動

基于原因總結規律，保持好的實踐，停止不好的實踐或尋求改變

這節課能給我們的啟發是很多的，當時也發了個朋友圈：

定期回顧項目進展和目標，讓團隊小伙伴知道勁往哪里使，避免無意義的抱怨，解決問題為主，讓寫代碼變得更加美好。

最后

運行維護篇作為軟件工程當中最后的環節，讓我們知道軟件上線僅僅只是第一步，后續的運行維護才是我們讓產品生命力繼續發光的手段，只有產品成功，我們研發的價值才能體現。在軟件研發過程中，自然會有做的好的和不好的，階段性復盤是我們能夠將經驗轉化成能力的好實踐，經過這段時間的學習，我也很想將這里面學習到的內容推廣到我們的團隊當中，借助好的方法論一定能夠讓我們團隊研發實力更上一層樓。

總結

以上是生活随笔為你收集整理的《软件工程之美》打卡第七周的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。