上周五馬馳和來(lái)煒在線交流，話題是運(yùn)維崗位真的不能干了么？我作為主持人，既是點(diǎn)火的又是拉架的 :) 聽(tīng)兩位老兵分享了一些他們各自的觀點(diǎn)，受益匪淺。今天抓緊記錄一下，以免忘記，算是對(duì)直播的一個(gè)復(fù)盤(pán)。

關(guān)于工具平臺(tái)

工具平臺(tái)會(huì)取代一部分人工，這個(gè)其實(shí)是顯而易見(jiàn)的，無(wú)需多言。

但是工具平臺(tái)誰(shuí)來(lái)構(gòu)建呢？這個(gè)值得捋一下。監(jiān)控系統(tǒng)、CI/CD的平臺(tái)、混沌工程的平臺(tái)、中間件服務(wù)等，都是Platform，由Platform Engineer來(lái)構(gòu)建，簡(jiǎn)稱PE。PE顯然是拆成很多小組的，每個(gè)PE小組負(fù)責(zé)有限的幾個(gè)平臺(tái)。這些零散的PE小組整體可以組成一個(gè)大的團(tuán)隊(duì)，比如叫基礎(chǔ)架構(gòu)團(tuán)隊(duì)，也可以拆到多個(gè)團(tuán)隊(duì)，比如跟工程效能相關(guān)的PE小組放到一個(gè)部門(mén)（比如效能工程部門(mén)），數(shù)據(jù)庫(kù)、大數(shù)據(jù)相關(guān)的PE小組放到一個(gè)部門(mén)（比如數(shù)據(jù)部門(mén)），穩(wěn)定性保障相關(guān)的PE小組放到一個(gè)部門(mén)（比如運(yùn)維部）。

這個(gè)組織的劃分，不同公司可能不同，關(guān)系倒不是很大，關(guān)鍵是PE團(tuán)隊(duì)?wèi)?yīng)該怎么開(kāi)展工作？PE團(tuán)隊(duì)核心要做好以下事項(xiàng)：

• 構(gòu)建好用的平臺(tái)，讓業(yè)務(wù)研發(fā)團(tuán)隊(duì)來(lái)自助服務(wù)
• 平臺(tái)要沉淀最佳實(shí)踐。平臺(tái)需要滿足業(yè)務(wù)，但也要有業(yè)界最佳實(shí)踐，理論上，如果業(yè)務(wù)需求和業(yè)界最佳實(shí)踐相沖突的時(shí)候，盡量應(yīng)以業(yè)界最佳實(shí)踐為準(zhǔn)，如果短期實(shí)在無(wú)法做到，也應(yīng)該制定分步落地的計(jì)劃，爭(zhēng)取未來(lái)要做到，否則個(gè)性的東西、反模式的東西越來(lái)越多，Platform側(cè)就會(huì)越來(lái)越難受，最后不堪重負(fù)，推倒重來(lái)，一地雞毛
• 要想方設(shè)法使用平臺(tái)來(lái)落地規(guī)范，而不是用規(guī)章制度來(lái)落地規(guī)范，馬馳舉了一個(gè)例子挺好的，他們有個(gè)規(guī)范，是要求業(yè)務(wù)程序不能利用本地磁盤(pán)存儲(chǔ)狀態(tài)數(shù)據(jù)，他們沒(méi)有把這個(gè)作為紅線法令頒布，而是明確告訴業(yè)務(wù)方會(huì)定期重啟容器，讓容器漂移！其實(shí)用過(guò)aws的人應(yīng)該知道，aws的虛機(jī)有的時(shí)候也會(huì)莫名重啟，面向不可靠的基礎(chǔ)設(shè)施提供高可用的應(yīng)用程序，本就是應(yīng)用研發(fā)人員的職責(zé)
• 需要COE（領(lǐng)域?qū)＜遥﹣?lái)指導(dǎo)Platform的演進(jìn)，因?yàn)樯瞄L(zhǎng)數(shù)據(jù)庫(kù)的架構(gòu)師未必擅長(zhǎng)Hadoop，擅長(zhǎng)Hadoop的架構(gòu)師未必擅長(zhǎng)可觀測(cè)性系統(tǒng)，擅長(zhǎng)可觀測(cè)性系統(tǒng)的架構(gòu)師未必擅長(zhǎng)混沌工程。

但所有的Platform都不是一蹴而就的，如果還沒(méi)有這些Platform，怎么辦？公司應(yīng)該先去招聘COE，讓COE來(lái)一邊做業(yè)務(wù)顧問(wèn)，一邊建設(shè)Platform的能力，業(yè)務(wù)發(fā)展很快，Platform自研太慢，也可以尋求外部供應(yīng)商的解決方案。甚至COE本身，都是可以尋求外部解決方案的，視情況而定。

關(guān)于外部供應(yīng)商

大家直觀上會(huì)覺(jué)得：歐美的公司更樂(lè)于采購(gòu)SaaS服務(wù)，國(guó)內(nèi)的公司更樂(lè)于基于開(kāi)源自建。是不是因?yàn)閲?guó)內(nèi)的公司理念不行？不盡然。國(guó)內(nèi)很多領(lǐng)域缺少靠譜的ToB企業(yè)和產(chǎn)品才是最核心的問(wèn)題。試想，如果某個(gè)ToB公司可以為甲方提供：

• 優(yōu)秀的、先進(jìn)的方法論
• 穩(wěn)定的、易用的產(chǎn)品
• 優(yōu)秀的、穩(wěn)定的客戶成功團(tuán)隊(duì)，幫助客戶更好的落地最佳實(shí)踐
• 價(jià)格上，比甲方自己招聘人員自研更便宜

只要CXO腦子沒(méi)壞，肯定會(huì)選擇引入這樣的外部供應(yīng)商。但是這樣的ToB公司有么？這是個(gè)大大的問(wèn)號(hào)。我們創(chuàng)建快貓星云公司，為客戶提供可觀測(cè)性產(chǎn)品，力爭(zhēng)成為這樣的供應(yīng)商。希望業(yè)界ToB同仁一起努力！

延展一下?lián)駱I(yè)問(wèn)題，雖然某個(gè)細(xì)分領(lǐng)域可能現(xiàn)在還沒(méi)有很好的供應(yīng)商，但是3年以后呢？5年以后呢？國(guó)外是不是已經(jīng)率先有了？國(guó)內(nèi)是不是有潛力不錯(cuò)的供應(yīng)商了？如果已經(jīng)有了，兄弟，你還敢繼續(xù)投身在這個(gè)細(xì)分領(lǐng)域么？是否應(yīng)該早做一些打算？

當(dāng)然了，對(duì)于未來(lái)的預(yù)估，我們通常過(guò)于樂(lè)觀，也過(guò)于悲觀，對(duì)時(shí)間的預(yù)估，通常預(yù)估的超前，也預(yù)估的滯后。道理如此，兄弟，就看你怎么判斷了。

關(guān)于應(yīng)急故障處理

應(yīng)該由研發(fā)來(lái)OnCall故障響應(yīng)？還是運(yùn)維？這個(gè)問(wèn)題很有意思。馬馳認(rèn)為，線上80%的故障跟變更相關(guān)，變更是研發(fā)做的，研發(fā)顯然更熟悉，讓研發(fā)來(lái)OnCall故障響應(yīng)，就意味著，80%的問(wèn)題研發(fā)可以更快的響應(yīng)。

業(yè)務(wù)研發(fā)如此，數(shù)據(jù)庫(kù)變更、基礎(chǔ)網(wǎng)絡(luò)變更、接入層的變更，都是同樣的道理，做變更的那個(gè)人來(lái)響應(yīng)自己的服務(wù)的故障告警，看起來(lái)是比較合理的。

實(shí)際上，這取決于兩個(gè)前提：

1. 監(jiān)控、可觀測(cè)性做的足夠好，變更導(dǎo)致的問(wèn)題能夠通過(guò)這套平臺(tái)及時(shí)發(fā)現(xiàn)，大家加油，希望每個(gè)公司都有一套完備的可觀測(cè)性體系
2. 變更引入的問(wèn)題是即時(shí)體現(xiàn)的，有些變更引入的問(wèn)題如果一周之后才出現(xiàn)，做變更的人也很難懷疑到自己頭上

其實(shí)我們可以分兩種情況對(duì)待，變更之后的服務(wù)穩(wěn)定性監(jiān)測(cè)，本就是這個(gè)做變更的人的分內(nèi)之事，日常OnCall是另一個(gè)場(chǎng)景，單獨(dú)對(duì)待。那日常OnCall應(yīng)該由誰(shuí)來(lái)做呢？應(yīng)該是那些可以直接參與故障定位、止損的人，道理很明顯，如果OnCall的人收到告警還需要去聯(lián)系別人，那這個(gè)故障止損的時(shí)效性就太差了。

所以首先，應(yīng)該對(duì)告警分門(mén)別類的處理，不同的人OnCall不同的告警。所有的告警都交給研發(fā)或者都交給運(yùn)維，這種絕對(duì)的做法是不合理的。

關(guān)于變更發(fā)布

最終目標(biāo)是有共識(shí)的，就是讓業(yè)務(wù)研發(fā)可以自由發(fā)布版本，但是我們又希望受控，希望安全的發(fā)布，希望在發(fā)布的同時(shí)保障業(yè)務(wù)連續(xù)性。這就對(duì)CI/CD的系統(tǒng)提出了極高的要求。

如果不管不顧，變更系統(tǒng)的底層就是去一批機(jī)器上批量跑個(gè)腳本的事情。但是附加了上述這些要求之后，就困難了很多，變成了一個(gè)系統(tǒng)性工程。

業(yè)務(wù)研發(fā)側(cè)，需要做好埋點(diǎn)可觀測(cè)，需要監(jiān)控類的系統(tǒng)能夠及時(shí)發(fā)現(xiàn)問(wèn)題，甚至告警之后自動(dòng)阻斷發(fā)布流程。需要有一些藍(lán)綠發(fā)布、金絲雀發(fā)布的手段落地，需要有些自動(dòng)代碼掃描、安全掃描的能力，工具體系不完備，一味地要求研發(fā)確保變更可回滾，確保變更安全也是不合適的。CI/CD的能力水平如何，基本可以看出這個(gè)公司的技術(shù)實(shí)力。

如果你所在的公司，還是研發(fā)給運(yùn)維提單，運(yùn)維去線上操作，要掂量一下這么做是否合理了哈。當(dāng)然，上面的做法更多的是偏互聯(lián)網(wǎng)的做法，未必適合所有的公司，這個(gè)直播也只是提供一個(gè)思路，你要自行斟酌。

當(dāng)然了，這個(gè)理想的情況怎么達(dá)到？在這個(gè)理想的情況達(dá)成之前應(yīng)該怎么一步一步走過(guò)去？時(shí)間問(wèn)題，直播里并未探討。如果公司的業(yè)務(wù)適合跑在Kubernetes上，用Kubernetes來(lái)構(gòu)建這么一套體系是相對(duì)容易的，可以盡快行動(dòng)起來(lái)。如果公司的業(yè)務(wù)必須跑在物理機(jī)、虛擬機(jī)環(huán)境，那就先搞一個(gè)統(tǒng)一的變更發(fā)布平臺(tái)，然后哪里缺失補(bǔ)哪里，逐漸完善了。

關(guān)于成本優(yōu)化

兩位嘉賓談的不多，不過(guò)大家對(duì)這個(gè)事情都非常慎重。提醒大家：

1. 人比硬件貴，千萬(wàn)不要做花費(fèi)了5000萬(wàn)的人力，節(jié)省了4000萬(wàn)硬件成本的事情
2. 要給業(yè)務(wù)留出足夠的冗余算力，如果資源用的太過(guò)緊張，該批的預(yù)算不批，因?yàn)槿萘繉?dǎo)致故障的話，客戶體驗(yàn)受損、輿論不利，得不償失
3. 可笑的例子是，用3000萬(wàn)買量，為了節(jié)省300萬(wàn)的硬件成本，沒(méi)抗住量，真的就呵呵了

小結(jié)

現(xiàn)在這個(gè)階段，平臺(tái)體系還沒(méi)有那么完備，使用自助Platform+COE+BP（Business Partner）的架構(gòu)來(lái)搭建運(yùn)維體系看起來(lái)是靠譜可落地的。未來(lái)Platform足夠好的的時(shí)候，可以縮減BP人力（BP也慢慢具備了COE的能力），Platform繼續(xù)完備，可以繼續(xù)縮減COE，再之后，嗯，運(yùn)維和研發(fā)可能就都不需要了吧。