摘要：當(dāng)云平臺(tái)出現(xiàn)網(wǎng)絡(luò)故障系統(tǒng)故障等問題，這對云租戶用戶有時(shí)甚至是致命的，所以不少是由高級別開發(fā)人員轉(zhuǎn)型而來。目前國內(nèi)各大云廠商也基本都提供了應(yīng)用運(yùn)維平臺(tái)，包括騰訊藍(lán)鯨阿里華為等。

下圖是我們熟知的軟件研發(fā)環(huán)節(jié)，在迭代頻率高的研發(fā)組織里，一天可能要經(jīng)歷多次如下循環(huán)。對于用戶群體龐大或者正在經(jīng)歷大幅業(yè)務(wù)擴(kuò)張的企業(yè)研發(fā)組織，除了重點(diǎn)關(guān)注應(yīng)用的快速上線之外，如何保障應(yīng)用的高可靠、高可用也成為焦點(diǎn)，即服務(wù)上線要快，運(yùn)行要好。

如何讓開發(fā)更簡單，運(yùn)行更高效，接下來我們從兩個(gè)角度來探討這個(gè)問題：

組織方式

研發(fā)工具

一種方式是組建專門的運(yùn)維團(tuán)隊(duì)，一個(gè)運(yùn)維團(tuán)隊(duì)往往會(huì)承接多個(gè)開發(fā)團(tuán)隊(duì)的協(xié)作。除了 DBA 這類針對某個(gè)中間件的運(yùn)維之外，這種模式的弊端在于不少運(yùn)維工程師深陷于環(huán)境配置、日志收集、業(yè)務(wù)恢復(fù)、現(xiàn)象記錄等瑣碎事情當(dāng)中，沒有時(shí)間閱讀項(xiàng)目源碼以及提升能力，對較為深入的業(yè)務(wù)問題分析困難，開發(fā)團(tuán)隊(duì)又往往無暇分身，運(yùn)維容易陷入被動(dòng)的境地。

另一種方式，開發(fā)人同時(shí)負(fù)責(zé)各自模塊的開發(fā)與運(yùn)維。好處自然是由于開發(fā)人員熟悉本模塊源碼，定位問題的效率要高出不少。同時(shí)開發(fā)者可以直接得到下游用戶使用反饋，將其融入到研發(fā)當(dāng)中去。壞處在于，讓開發(fā)人員陷入到頻繁的用戶問題定位之后，難以保證代碼開發(fā)的時(shí)間。

近年來，國內(nèi)也興起了 SRE 這種高級運(yùn)維職業(yè)，特別是在云計(jì)算行業(yè)，SRE 的職業(yè)要求非常高，需要精通諸如網(wǎng)絡(luò)、編程、算法、數(shù)據(jù)結(jié)構(gòu)、操作系統(tǒng)、安全等知識與技能。當(dāng)云平臺(tái)出現(xiàn)網(wǎng)絡(luò)故障、系統(tǒng)故障等問題，這對云租戶/用戶有時(shí)甚至是致命的，所以不少 SRE 是由高級別開發(fā)人員轉(zhuǎn)型而來。

在 Google SRE 的服務(wù)可靠性層級當(dāng)中，SRE 通過產(chǎn)品、開發(fā)、容量規(guī)劃、測試、根因分析、事件響應(yīng)、監(jiān)控七個(gè)層次的實(shí)踐來確保應(yīng)用服務(wù)的健康狀態(tài)。從這個(gè)層級當(dāng)中我們可以看出 Google 提倡運(yùn)維要積極控制服務(wù)發(fā)展的方向，而不僅僅在事故發(fā)生后反應(yīng)性地滅火。目前來看，SRE 這種精英式的運(yùn)維在國內(nèi)還有待探索與實(shí)踐。

粗暴地將開發(fā)運(yùn)維拆開，或者將開發(fā)運(yùn)維簡單合并，都不是特別合適的一種方式。從筆者的研發(fā)經(jīng)驗(yàn)看，一種方式可供大家思考與討論——根據(jù)業(yè)務(wù)實(shí)際情況做分工：比如由團(tuán)隊(duì)內(nèi)的開發(fā)者輪流負(fù)責(zé)整個(gè)項(xiàng)目運(yùn)維。由于各個(gè)開發(fā)者對項(xiàng)目公共代碼都需要熟悉，在理解其它模塊代碼也相對快速，這種方式基本能消滅大部分的問題，剩下的一小部分可以和指定模塊的負(fù)責(zé)人結(jié)對定位。除此之外，為“每個(gè)服務(wù)團(tuán)隊(duì)分派運(yùn)維聯(lián)絡(luò)人”，“邀請運(yùn)維工程師參加開發(fā)團(tuán)隊(duì)的會(huì)議”都是能夠加強(qiáng)運(yùn)維與開發(fā)之間協(xié)作的措施。

除了恰當(dāng)?shù)娜藛T組織方式之外，合適的工具也能給研發(fā)團(tuán)隊(duì)注入能力。

在配置研發(fā)環(huán)境時(shí)，研發(fā)組織可以選擇通過開源工具自建代碼管理和持續(xù)構(gòu)建環(huán)境。這種方式的缺點(diǎn)在于需要有專門的 CI 團(tuán)隊(duì)來維護(hù)持續(xù)構(gòu)建環(huán)境，一旦環(huán)境被破壞，開發(fā)的腳步就會(huì)停滯。并且由于各個(gè)開源工具數(shù)據(jù)未打通，開發(fā)人員要在多個(gè)工具之間切換使用。另外一種方式就可以通過現(xiàn)有的軟件研發(fā)管理系統(tǒng)，例如 CODING 研發(fā)管理系統(tǒng)，來實(shí)現(xiàn)一站式的研發(fā)流程管理，無需自建、維護(hù)眾多的研發(fā)工具與研發(fā)環(huán)境，支持在瀏覽器中完成全套軟件開發(fā)流程，真正做到了 Coding Anytime Anywhere。

當(dāng)開發(fā)人員通過 CODING 研發(fā)管理系統(tǒng)快速開發(fā)并部署好應(yīng)用后，下一步就要讓應(yīng)用在運(yùn)維工具的輔助監(jiān)控下可靠運(yùn)行（并不是所有應(yīng)用都需要運(yùn)維工具，需對癥下藥）。研發(fā)組織可以選擇自己開發(fā)運(yùn)維工具，也可以選擇現(xiàn)有的運(yùn)維工具。

目前的運(yùn)維工具逐漸地朝以應(yīng)用為中心發(fā)展，因?yàn)閼?yīng)用是直接向用戶提供業(yè)務(wù)能力的，無論是開發(fā)還是運(yùn)維，都是被業(yè)務(wù)價(jià)值驅(qū)動(dòng)的。主流的運(yùn)維工具主要涵蓋基礎(chǔ)設(shè)施層監(jiān)控、應(yīng)用層面監(jiān)控、業(yè)務(wù)層面的分析與監(jiān)控。

接下來我們看看現(xiàn)有的運(yùn)維工具一般會(huì)提供哪些具體能力：

基礎(chǔ)設(shè)施環(huán)境的監(jiān)控：對服務(wù)器整體的 CPU、內(nèi)存、磁盤、文件系統(tǒng)、網(wǎng)絡(luò)等資源占用情況進(jìn)行上報(bào)。

應(yīng)用性能監(jiān)控：針對應(yīng)用使用的中間件，例如持久化數(shù)據(jù)庫、緩存數(shù)據(jù)庫、消息中間件等訪問效率進(jìn)行監(jiān)控；以及對應(yīng)用本身請求響應(yīng)速度進(jìn)行監(jiān)控，包括延遲、吞吐量等等。

應(yīng)用調(diào)用鏈路追蹤：在分布式系統(tǒng)下，一個(gè)請求往往需要經(jīng)過多個(gè)進(jìn)程處理完畢。當(dāng)出現(xiàn)用戶請求調(diào)用失敗或者出錯(cuò)時(shí)，運(yùn)維平臺(tái)支持整個(gè)調(diào)用鏈路的分析與故障環(huán)節(jié)定位。

日志數(shù)據(jù)采集與分析：日志的采集主要是為了輔助應(yīng)用調(diào)用鏈路分析以及性能監(jiān)控，運(yùn)維人員無需進(jìn)入后臺(tái)去大量翻找日志。

故障自動(dòng)恢復(fù)

靈活的告警

可視化面板展示監(jiān)控與告警信息

國外熱度較高的運(yùn)維工具包括 ZIPKIN（分布式追蹤），pinpoint（分布式追蹤），logstash（數(shù)據(jù)收集）等等。目前國內(nèi)各大云廠商也基本都提供了應(yīng)用運(yùn)維平臺(tái)，包括騰訊藍(lán)鯨、阿里 ARMS、華為 APM 等。以下是這幾個(gè)運(yùn)維平臺(tái)能力的簡要對比：

目前大部分的運(yùn)維平臺(tái)主要通過 Agent 和探針的方式去采集應(yīng)用的指標(biāo)信息，匯總處理后反應(yīng)在可視化界面上。除上述的工具和平臺(tái)之外，AIOps 也逐漸成為未來的一個(gè)趨勢，AIOps 通過 AI 技術(shù)的運(yùn)用來進(jìn)行智能業(yè)務(wù)故障診斷，同時(shí)自動(dòng)恢復(fù)應(yīng)用故障，企圖讓研發(fā)組織徹底告別人肉運(yùn)維時(shí)代，筆者也萬分期待這天的到來。運(yùn)維人員不用擔(dān)心因 AIOps 失業(yè)，工具和平臺(tái)只是提升運(yùn)維效率，不會(huì)取代運(yùn)維。

在運(yùn)維階段發(fā)現(xiàn)缺陷后，開發(fā)人員可在 CODING 中處理對應(yīng)的缺陷，記錄下每個(gè)缺陷的類型、優(yōu)先級、模塊、描述、處理人等信息。軟件缺陷是不可避免的，但只有通過對缺陷進(jìn)行管理和復(fù)盤才能知道缺陷產(chǎn)生的原因（人為因素 / 環(huán)境因素 / 工具問題等），從而改進(jìn)，避免類似缺陷的重復(fù)。對缺陷的管理也有助于管理人員對軟件質(zhì)量的正確評估。缺陷處理人通過 CODING 實(shí)現(xiàn)缺陷的快速修復(fù)和部署，可大大縮短故障恢復(fù)時(shí)間，減少因缺陷產(chǎn)生的業(yè)務(wù)損失。

在 DevOps 理念的指導(dǎo)下，筆者建議開發(fā)人員在開發(fā)業(yè)務(wù)代碼時(shí)，除了功能之外，也應(yīng)當(dāng)思考如何開發(fā)可運(yùn)維的代碼，通過適當(dāng)?shù)娜罩?、錯(cuò)誤碼、異常等措施來提升運(yùn)維效率；運(yùn)維人員也需逐步提升能力，從傳統(tǒng)的繁雜運(yùn)維當(dāng)中轉(zhuǎn)型，走上敏捷自動(dòng)化的運(yùn)維之路。

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

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