上週五馬馳和來煒線上交流，話題是運維崗位真的不能乾了麼？我作為主持人，既是點火的又是拉架的 :) 聽兩位老兵分享了一些他們各自的觀點，受益匪淺。今天抓緊記錄一下，以免忘記，算是對直播的一個複盤。
關於工具平台
工具平台會取代一部分人工，這個其實是顯而易見的，無需多言。
但是工具平台誰來建置呢？這個值得捋一下。監控系統、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%的問題研發可以更快的反應。
業務研發如此，資料庫變更、基礎網路變更、存取層的變更，都是同樣的道理，做變更的那個人來回應自己的服務的故障告警，看起來是比較合理的。
其實，這取決於兩個前提：
- 監控、可觀測性做的夠好，變更導致的問題能夠透過這套平台及時發現，大家加油，希望每家公司都有一套完整的可觀測性體系
- 變更引入的問題是即時體現的，有些變更引入的問題如果一週之後才出現，做變更的人也很難懷疑到自己頭上
其實我們可以分兩種情況對待，變更之後的服務穩定性監測，本就是這個做變更的人的分內之事，日常OnCall是另一個場景，單獨對待。那麼日常OnCall該由誰來做呢？應該是那些可以直接參與故障定位、停損的人，道理很明顯，如果OnCall的人收到告警還需要去聯絡別人，那這個故障停損的時效性就太差了。
所以首先，應該對告警分門別類的處理，不同的人OnCall不同的告警。所有的告警都交給研發或交給維運，這種絕對的做法是不合理的。
關於變更發布
最終目標是有共識的，就是讓業務研發可以自由發布版本，但是我們又希望受控，希望安全的發布，希望在發布的同時保障業務連續性。這對CI/CD的系統提出了極高的要求。
如果不管不顧，變更系統的底層就是去一批機器上批次跑個腳本的事情。但是附加了上述這些要求之後，就困難了很多，變成了一個系統性工程。
業務研發側，需要做好埋點可觀測，需要監控類別的系統能夠及時發現問題，甚至警告之後自動阻斷發布流程。需要有一些藍綠發布、金絲雀發布的手段落地，需要有些自動代碼掃描、安全掃描的能力，工具體係不完備，一味地要求研發確保變更可回滾，確保變更安全也是不合適的。 CI/CD的能力水準如何，基本上可以看出這個公司的技術實力。
如果你所在的公司，還是研發給運維提單，維運去線上操作，要掂量一下這麼做是否合理了哈。當然，上面的做法更多的是偏互聯網的做法，未必適合所有的公司，這個直播也只是提供一個思路，你要自行斟酌。
當然了，這個理想的情況怎麼達到？在這個理想的情況達成之前應該怎麼一步一步走過去？時間問題，直播裡並未探討。如果公司的業務適合跑在Kubernetes上，用Kubernetes來建立這麼一套體係是相對容易的，可以盡快行動起來。如果公司的業務必須跑在實體機、虛擬機器環境，那就先搞一個統一的變更發布平台，然後哪裡缺少補哪裡，逐漸完善了。
關於成本優化
兩位嘉賓談的不多，不過大家對這個事情都非常慎重。提醒大家：
- 人比硬體貴，千萬不要做花費了5000萬的人力，節省了4000萬硬體成本的事情
- #要給業務留出足夠的冗餘餘算力，如果資源用的太過緊張，該批的預算不批，因為容量導致故障的話，客戶體驗受損、輿論不利，得不償失
- 可笑的例子是，用3000萬買量，為了節省300萬的硬體成本，沒抗住量，真的就呵呵了
小結
現在這個階段，平台系統還沒那麼完備，使用自助Platform COE BP（Business Partner）的架構來建構維運體系看起來是可靠的落地。未來Platform夠好的時候，可以縮減BP人力（BP也慢慢具備了COE的能力），Platform繼續完備，可以繼續縮減COE，再之後，嗯，運維和研發可能就都不需要了吧。
以上是終結這個話題：運維崗位真的不能做了麼？的詳細內容。更多資訊請關注PHP中文網其他相關文章！
