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

關于工具平臺

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

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

這個組織的劃分，不同公司可能不同，關系倒不是很大，關鍵是PE團隊應該怎么開展工作？PE團隊核心要做好以下事項：

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

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

關于外部供應商

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

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

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

延展一下擇業問題，雖然某個細分領域可能現在還沒有很好的供應商，但是3年以后呢？5年以后呢？國外是不是已經率先有了？國內是不是有潛力不錯的供應商了？如果已經有了，兄弟，你還敢繼續投身在這個細分領域么？是否應該早做一些打算？

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

關于應急故障處理

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

業務研發如此，數據庫變更、基礎網絡變更、接入層的變更，都是同樣的道理，做變更的那個人來響應自己的服務的故障告警，看起來是比較合理的。

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

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

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

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

關于變更發布

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

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

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

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

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

關于成本優化

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

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

小結

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