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

關(guān)于工具平臺

工具平臺會取代一部分人工，這個其實是顯而易見的，無需多言。

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

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

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

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

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

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

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

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

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

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

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

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

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

實際上，這取決于兩個前提：

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

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

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

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

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

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

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

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

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

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

兩位嘉賓談的不多，不過大家對這個事情都非常慎重。提醒大家：

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

小結(jié)

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