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

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 的道路上，將來軟件的開發會更簡單，運行也會更加高效。

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