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

嘉賓介紹

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

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

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

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

比如搭建一套完善的監(jiān)控系統(tǒng)：

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

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

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

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

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

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

在企業(yè)大范圍上云的當下大環(huán)境里，您覺得運維人員應該做出哪些調(diào)整才能更適合當下的人才需求？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

工具選型這塊，到底是自研，還是使用開源，還是使用商業(yè)產(chǎn)品，是如何抉擇的？

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

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

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

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

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

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

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

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

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

這都2023年了，聊這個話題就跟互聯(lián)網(wǎng)運維弄個NOC監(jiān)控值班一樣，開倒車。

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

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