他山之石——運維平台哪家強？

• 2019 年 10 月 4 日
• 筆記

DevOps 全鏈路

下圖是我們熟知的軟體研發環節，在迭代頻率高的研發組織里，一天可能要經歷多次如下循環。對於用戶群體龐大或者正在經歷大幅業務擴張的企業研發組織，除了重點關注應用的快速上線之外，如何保障應用的高可靠、高可用也成為焦點，即服務上線要快，運行要好。

如何讓開發更簡單，運行更高效，接下來我們從兩個角度來探討這個問題：

• 組織方式
• 研發工具

關於運維人員的組織方式

• 一種方式是組建專門的運維團隊，一個運維團隊往往會承接多個開發團隊的協作。除了 DBA 這類針對某個中間件的運維之外，這種模式的弊端在於不少運維工程師深陷於環境配置、日誌收集、業務恢復、現象記錄等瑣碎事情當中，沒有時間閱讀項目源碼以及提升能力，對較為深入的業務問題分析困難，開發團隊又往往無暇分身，運維容易陷入被動的境地。
• 另一種方式，開發人同時負責各自模組的開發與運維。好處自然是由於開發人員熟悉本模組源碼，定位問題的效率要高出不少。同時開發者可以直接得到下游用戶使用回饋，將其融入到研發當中去。壞處在於，讓開發人員陷入到頻繁的用戶問題定位之後，難以保證程式碼開發的時間。

近年來，中國也興起了 SRE 這種高級運維職業，特別是在雲計算行業，SRE 的職業要求非常高，需要精通諸如網路、編程、演算法、數據結構、作業系統、安全等知識與技能。當雲平台出現網路故障、系統故障等問題，這對雲租戶/用戶有時甚至是致命的，所以不少 SRE 是由高級別開發人員轉型而來。

在 Google SRE 的服務可靠性層級當中，SRE 通過產品、開發、容量規劃、測試、根因分析、事件響應、監控七個層次的實踐來確保應用服務的健康狀態。從這個層級當中我們可以看出 Google 提倡運維要積極控制服務發展的方向，而不僅僅在事故發生後反應性地滅火。目前來看，SRE 這種精英式的運維在中國還有待探索與實踐。

粗暴地將開發運維拆開，或者將開發運維簡單合併，都不是特別合適的一種方式。從筆者的研發經驗看，一種方式可供大家思考與討論——根據業務實際情況做分工：比如由團隊內的開發者輪流負責整個項目運維。由於各個開發者對項目公共程式碼都需要熟悉，在理解其它模組程式碼也相對快速，這種方式基本能消滅大部分的問題，剩下的一小部分可以和指定模組的負責人結對定位。除此之外，為「每個服務團隊分派運維聯絡人」，「邀請運維工程師參加開發團隊的會議」都是能夠加強運維與開發之間協作的措施。

關於工具的使用

除了恰當的人員組織方式之外，合適的工具也能給研發團隊注入能力。

在配置研發環境時，研發組織可以選擇通過開源工具自建程式碼管理和持續構建環境。這種方式的缺點在於需要有專門的 CI 團隊來維護持續構建環境，一旦環境被破壞，開發的腳步就會停滯。並且由於各個開源工具數據未打通，開發人員要在多個工具之間切換使用。另外一種方式就可以通過現有的軟體研發管理系統，例如 CODING 研發管理系統，來實現一站式的研發流程管理，無需自建、維護眾多的研發工具與研發環境，支援在瀏覽器中完成全套軟體開發流程，真正做到了 Coding Anytime Anywhere。

當開發人員通過 CODING 研發管理系統快速開發並部署好應用後，下一步就要讓應用在運維工具的輔助監控下可靠運行（並不是所有應用都需要運維工具，需對症下藥）。研發組織可以選擇自己開發運維工具，也可以選擇現有的運維工具。

目前的運維工具逐漸地朝以應用為中心發展，因為應用是直接提供業務能力的，無論是開發還是運維，都是被業務價值驅動的。主流的運維工具主要涵蓋基礎設施層監控、應用層面監控、業務層面的分析與監控。

接下來我們看看現有的運維工具一般會提供哪些具體能力：

• 基礎設施環境的監控：對伺服器整體的 CPU、記憶體、磁碟、文件系統、網路等資源佔用情況進行上報。
• 應用性能監控：針對應用使用的中間件，例如持久化資料庫、快取資料庫、消息中間件等訪問效率進行監控；以及對應用本身請求響應速度進行監控，包括延遲、吞吐量等等。
• 應用調用鏈路追蹤：在分散式系統下，一個請求往往需要經過多個進程處理完畢。當出現用戶請求調用失敗或者出錯時，運維平台支援整個調用鏈路的分析與故障環節定位。
• 日誌數據採集與分析：日誌的採集主要是為了輔助應用調用鏈路分析以及性能監控，運維人員無需進入後台去大量翻找日誌。
• 故障自動恢復
• 靈活的告警
• 可視化面板展示監控與告警資訊

國外熱度較高的運維工具包括 ZIPKIN（分散式追蹤），pinpoint（分散式追蹤），logstash（數據收集）等等。目前中國各大雲廠商也基本都提供了應用運維平台，包括騰訊藍鯨、阿里 ARMS、華為 APM 等。以下是這幾個運維平台能力的簡要對比：

目前大部分的運維平台主要通過 Agent 和探針的方式去採集應用的指標資訊，匯總處理後反應在可視化介面上。除上述的工具和平台之外，AIOps 也逐漸成為未來的一個趨勢，AIOps 通過 AI 技術的運用來進行智慧業務故障診斷，同時自動恢復應用故障，企圖讓研發組織徹底告別人肉運維時代，筆者也萬分期待這天的到來。運維人員不用擔心因 AIOps 失業，工具和平台只是提升運維效率，不會取代運維。

在運維階段發現缺陷後，開發人員可在 CODING 中處理對應的缺陷，記錄下每個缺陷的類型、優先順序、模組、描述、處理人等資訊。軟體缺陷是不可避免的，但只有通過對缺陷進行管理和復盤才能知道缺陷產生的原因（人為因素 / 環境因素 / 工具問題等），從而改進，避免類似缺陷的重複。對缺陷的管理也有助於管理人員對軟體品質的正確評估。缺陷處理人通過 CODING 實現缺陷的快速修復和部署，可大大縮短故障恢復時間，減少因缺陷產生的業務損失。

在 DevOps 理念的指導下，筆者建議開發人員在開發業務程式碼時，除了功能之外，也應當思考如何開發可運維的程式碼，通過適當的日誌、錯誤碼、異常等措施來提升運維效率；運維人員也需逐步提升能力，從傳統的繁雜運維當中轉型，走上敏捷自動化的運維之路。

寫在最後

我們可以看到隨著 DevOps 工具鏈自動化顯著提升，DevOps 的門檻變得更加地低。擁抱自動化的結果是研發過程會變得越來越安靜，頂尖的開源項目里的 committers 在日常僅僅是通過郵件和 issue 將事情說清楚，沒有熱火朝天、冗長拖沓的會議；也沒有花花綠綠，色彩斑斕的工作表格。但這些都是建立在 DevOps 良好實踐的基礎之上。我們相信在踐行 DevOps 的道路上，未來軟體的開發會更簡單，運行也會更加高效。

點擊閱讀原文，體驗 CODING 研發管理系統，助力企業實現 DevOps。

參考： https://www.collab.net https://landing.google.com/sre/sre-book/chapters/part3/ 吉恩·金（Gene Kim）；耶斯·亨布爾（Jez Humble）；帕特里克·德布瓦（Patrick Debois）；約翰·威爾斯（John Willis）.《DevOps 實踐指南》