編者著：井老板是我11年入行加入百度時的團隊大老板，骨灰級老炮，逮著這個機會不容易，把業內常見問題都問了個遍，以饗讀者。井老板生性灑脫，嬉笑怒罵皆成文章，道理自在其中。這里是接地氣、有高度的《運維百家講壇》第 1 期，開講！

嘉賓介紹

井源，左一，前百度運維架構師，前小米運維負責人，前美菜CIO

有些運維人員反映公司對運維的價值所知甚少，您當年是怎么給公司講清楚運維的價值的呢？

首先需要和公司講清楚運維的崗位職責（運維是干什么、產出什么）和關鍵指標（度量產出成果），比如工作圍繞穩定、安全、高效等方向展開，開展了哪些運維項目，如何主動推進關鍵指標的達成。

關鍵指標，不僅僅包含服務可用性，還有比如服務器資源達標率、服務故障數據（故障分類、故障響應時間、平均故障恢復時間、故障告警覆蓋率）、服務安全指標、服務資源到位時長等等。

比如搭建一套完善的監控系統：

監控服務器資源使用率，找出使用率不達標的服務器進行回收或資源重新分配，通過虛擬化、容器化等手段提升資源使用率 梳理告警閾值，規范P0、P1、P2、P3告警級別；監控系統提供告警合并、智能定位建議，提供活躍告警聚合，提供時間緯度的告警分析。方便更快的告警響應和故障定位，提升故障響應時間、故障恢復時間等 服務的告警和預案梳理，縮短平均故障恢復時間，提升故障告警覆蓋率

業內有觀點認為云和Kubernetes這樣的基礎設施的崛起會讓運維崗位逐漸消亡，您是怎么看待這樣的觀點呢？

很多年前我們運維團隊的口號是NO Ops，博客是noops.me。

很早就說過，運維崗位會逐漸消亡，或者部分工作職責會消亡。拿系統運維來舉例，以前管理的團隊需要服務器工程師、內核工程師、網絡工程師、CDN工程師、機房運維工程師等小20人的團隊。后來通過引入公有云，團隊只有4個人，云資源管理員1人、CDN調度工程師1人、網絡工程師1人、內核工程師1人，他們只需要管理和調度好第三方公司提供的資源和服務即可。

隨著K8s和云的普及，以及研發代碼工程化的不斷成熟，運維在這個過程中的參與度會越來越少。在部署框架成熟的情況下，為了節省運維人力，提升部署效率，二、三級服務的部署已經交給研發自助完成。

隨著科技的發展，時代的變化，一個崗位的消亡是很正常的事情，及時做好調整和規劃才是思考的重心。

在企業大范圍上云的當下大環境里，您覺得運維人員應該做出哪些調整才能更適合當下的人才需求？

在上云的大環境下，運維工程師更應該面向業務、面向架構，拓展自己的業務范圍，成為保障業務穩定的關鍵人才。如果還是和以前一樣，僅僅只關注監控報警，只負責服務部署變更，那么勢必會被淘汰。

另一方面，可以往專精的方向走，成為某個領域的專家（監控、大數據、K8s、數據庫等等），走運維研發專家的方向。

人生的建議，多尋找一些副業，運維工作只是生活的一小部分。

AIOps熱炒了幾年，但是最近明顯聲量變小了，您覺得企業現階段應該落地AIOps么？應該注意哪些問題？

就拿智能監控為例，看到了很多文案說要通過AI預測故障、智能定位。到現在沒有看到任何靠譜的案例。在一個服務變更快、依賴關系復雜、故障影響因素多的互聯網業務系統中，如果真能通過歷史數據，實現故障預測。那還不如去做地震預測，有幾千年的地震數據積累，能夠產生很大的社會價值。

做AIOps的前提，是真的懂AI，清楚機器學習和神經網絡的原理。有多少人工才有多少智能，AIOps才能不是一個口號。

chatGPT這樣的AI能力您覺得未來是否有可能解決運維行業的問題？

比如在故障管理中，根據故障的設備、數據、描述，通過知識庫、歷史故障庫等等，給出故障可能的輔助建議(suggestbot)

BTW，如果你已經可以玩轉chatGPT了，把這個技術投入到其他更能產生價值的領域吧，別老在運維這個領域耗著……

業務程序的部署，到底應該交給研發來做還是應該交給運維來做，在很多公司爭論不休，您是怎么看待這個問題呢？

之前提到過，我們二、三級的服務是完全由研發去做，一級服務是運維和研發輪流去做，主要目的主要是讓運維清楚當前服務的變化情況而已。運維人員在公司一開始做部署，更多是規范線上環境，規范服務部署方式，從而更好的研發部署系統，掌控所負責的服務架構。

安全問題、流程問題，完全可以通過部署系統去解決。運維就不要守著這個沒任何價值，沒任何沉淀的工作不放了。

您最想對（運維）行業說的一句話是？為什么？

“物理學沒有不存在，只是我們認為的物理學，可能不存在。” 運維行業可能也不存在了，多少運維人的夢想是AIOps、NOOps，要么自己去干掉這個行業，要么在這個行業被干掉。

工具選型這塊，到底是自研，還是使用開源，還是使用商業產品，是如何抉擇的？

有能力有時間就使用開源，能力一般時間有限就使用商業產品。有錢有閑還很自負的話，可以嘗試下自研。

您所在的公司是否也是多云架構？您覺得多云場景下哪些能力應該依托云廠商哪些能力應該自建？

我們是多云架構。專線或者數據傳輸的能力，這個需要自建。基于多云之上的公共能力也可以自建，比如監控系統、數據備份系統、部署系統、微服務核心組件等，其他的交給云廠商就好了。

您印象最深的一次故障是什么？對您有何啟示？

運維這么多年，遇到的詭異故障太多了，root cause讓你根本想象不到。只能說，故障很難避免，只能設法減少故障的頻率、影響面和影響時間。

所以你的績效不是故障次數和故障級別，而是故障影響面、故障響應、恢復時間等。

面對當下快速發展的基礎技術，您對給剛入行和入行已久的運維人員，分別有什么職業規劃的建議嗎？

比較偏激哈~剛入行的，建議盡快轉行！入行已久的，轉行技術相對困難，已經打上了深深的運維烙印。我見過太多運維人員轉行其他技術，多數都是運維研發、運維產品經理的崗位，還是找一下副業吧。

您覺得傳統運維和SRE的區別是什么？您的團隊做出這樣的轉型，其背后的思考是？

這都2023年了，聊這個話題就跟互聯網運維弄個NOC監控值班一樣，開倒車。

如果現在還在考慮要不要轉型SRE、怎么轉型SRE、SRE的變化這些問題，就跟5g時代，還在考慮用2g，還是3g……都會被時代所淘汰。

是否有種戛然而止的感覺？哈哈，這是《運維百家講壇》第1期，我們會持續邀請業內大佬前來分享，越是有不同的觀點才越有意思，越是能夠引發思考，咱們一起，抱著開放的心態，聆聽百家之言。下一期，再見！