我畢業(yè)后的第一份工作做業(yè)務(wù)運維，接觸的產(chǎn)品也比較多如游戲、內(nèi)部安全、云安全、P2SP機房、推薦與個性化等等，基本上PC和移動時代的業(yè)務(wù)都接觸過。在16年的時候，因為機緣發(fā)展，加入騰訊，做云塊存儲類的產(chǎn)品運維，目前主要負(fù)責(zé)相關(guān)產(chǎn)品的運維管理工作。

第一個問題：世界上第一個運維是誰？這里所指運維還是偏業(yè)務(wù)運維或者SRE的范疇。

世界上第一個運維人名叫Margaret Hamilton，為什么說她是世界上第一個運維呢？其中是有一段故事的。

Margaret是在NASA工作，一次她帶著她的小女兒Lauren去工作的地方玩，期間Lauren誤觸了控制臺，引發(fā)程序崩潰，Margaret思考在火箭飛行過程中也有可能發(fā)生這樣的錯誤，于是她在火箭飛行手冊中添加了一段文字，提醒宇航員不要誤觸發(fā)P01程序，并給出了恢復(fù)手段。Apollo 8執(zhí)行飛行任務(wù)時，結(jié)果真的有人誤觸發(fā)了P01程序，幸好有Margaret之前給出的恢復(fù)手冊，最終才化險為夷。

在今天來看，當(dāng)時Margaret做的工作其實就是在做預(yù)案，這跟我們現(xiàn)在運維做的工作是如出一轍的，所以從這個意義上講，她可以被認(rèn)為是世界上第一個業(yè)務(wù)運維。

當(dāng)時她還說了這樣一段話，“無論對一個軟件系統(tǒng)運行原理掌握得多么透徹，也不能阻止人犯意外錯誤?！?/strong>這其實就是運維的思想，也是我們每天在干的事情。

運維這個職業(yè)有很多工種，比如說我自己是做業(yè)務(wù)運維，主要是面向業(yè)務(wù)的；還有系統(tǒng)運維，比如負(fù)責(zé)網(wǎng)絡(luò)，操作系統(tǒng)的、底層IaaS的等等；還有一類是數(shù)據(jù)庫DBA，是專門負(fù)責(zé)數(shù)據(jù)庫；還有專門負(fù)責(zé)安全的安全運維；還有運維開發(fā)，Devops（AIOps）負(fù)責(zé)開發(fā)運維工具和平臺；還有8000的小伙伴，做IT運維。

因為現(xiàn)在大部分的基礎(chǔ)設(shè)施都云化了，如果按照云的維度來看，又可以分為SaaS、PaaS和IaaS運維。

運維的工作職責(zé)和定位通常是：第一個定位 質(zhì)量守門人，運維最核心的OKR或KPI就是圍繞質(zhì)量，負(fù)責(zé)所有線上的問題；第二個定位是效率提升者，運維需要對日常的一些重復(fù)工作去開發(fā)各種各樣的工具，提升整體運維效率，這樣才能更好的去驅(qū)動質(zhì)量的提升；第三個定位是口碑維護者，很多運維同學(xué)都是要接觸業(yè)務(wù)，不管是負(fù)責(zé)內(nèi)部自研業(yè)務(wù)還是外部云客戶，都需要深入業(yè)務(wù)做好服務(wù)，在TEG很多同事都承擔(dān)了這樣的職責(zé)，這就是左邊的圈。

同時我們?nèi)粘ｉ_展工作鎖圍繞的三個生命周期(右邊的圓圈)：第一個故障生命周期，故障生命周期就是從一個故障最開始的發(fā)生，到發(fā)現(xiàn)，到定位，到分析，到最后恢復(fù)；第二個應(yīng)用生命周期，所有線上跑的應(yīng)用APP，從最開始的發(fā)布評審，到發(fā)布上線，到監(jiān)控，包括做資源，后面預(yù)案，都是圍繞應(yīng)用生命周期；第三個資源生命周期，資源生命周期和應(yīng)用生命周期還是有些區(qū)別。因為運維還管了很多設(shè)備，包括硬件設(shè)備，IT，實例資源，那就要去做資源生命周期的相關(guān)工作，包括資源的申請、報備......所以運維的職責(zé)大致就可以用這兩個圈來概括。

具體工作基本圍繞質(zhì)量、成本、效率、安全，大家每年在寫OKR或做規(guī)劃都是圍繞這幾方面來做，質(zhì)量提升、性能優(yōu)化、成本優(yōu)化和安全優(yōu)等等。

第一種 故障文化，江湖人稱運維叫“背鍋俠”，這大概就是我們運維人的常態(tài)?！安辉趶?fù)盤，就在去復(fù)盤的路上?！?特別是做云的小伙伴，基本上每天都在復(fù)盤，只要線上出了問題，先錄單，錄完后，QA就會來說“我們復(fù)盤吧”，然而這個問題還沒有復(fù)盤完，又出現(xiàn)新問題了，復(fù)盤完了之后又繼續(xù)……所以基本就是每天“不在復(fù)盤就在復(fù)盤的路上”。

大家都說“沒有經(jīng)歷過大的故障的運維，不能稱得上是一個好運維”。相信每個運維人都會經(jīng)歷過很多的故障，但對于運維崗位，我們在做問題復(fù)盤時，是真正意義上的“對事不對人”，這里不會去計較為什么是這個人犯的錯、出的問題、寫bug，重要的是為什么會出這個問題，出問題后能否更快發(fā)現(xiàn)和恢復(fù)，或從流程機制上保證下次不再同樣犯錯，所以在運維的文化里面重要的一點。運維都夠做到真正的對事不對人，關(guān)注問題和關(guān)注事情本身。

同時重要的是，大家是在故障中成長，在復(fù)盤中變強。這里給大家講兩個讓我印象非常深刻的例子。

第一個例子是發(fā)生在我自己身上的，在上家公司大概入職2年多的時候，有一天接到一個磁盤告警要去清理磁盤，然后我馬上進(jìn)入服務(wù)器根目錄下敲了行代碼“rm -rf *”。過了三秒鐘自己反應(yīng)過來，剛剛好像是在根目錄底下運行下刪除，當(dāng)時是立馬按Ctrl C恢復(fù)，但其實已經(jīng)刪了一些內(nèi)容。但很詭異的是當(dāng)時沒有出現(xiàn)任何問題，但我依然很害怕，就趕緊給模塊的研發(fā)打電話，說把根目錄給刪了，他也慌了馬上與我一起復(fù)盤；在復(fù)盤的時我們發(fā)現(xiàn)沒出問題，因為當(dāng)時很多的程序直接加載在內(nèi)存中運行，所以沒有影響線上服務(wù)，這個也是不幸中的萬幸......記得當(dāng)時公司有個叫雞翅文化，就是如果你犯小錯誤就請所有人吃雞翅，我當(dāng)時是請研發(fā)同學(xué)們吃雞翅，這是我人生第一次也是唯一一次請研發(fā)吃雞翅。這次事情讓我記憶深刻后來我把這個案例寫到了中心的新人培訓(xùn)材料分享出去，想不到后來真的有同學(xué)去試了一遍，把倉庫刪掉了：(  這真是一個很常見、容易犯的錯誤。

第二個是2018年我遇到，印象很深刻是這個故障發(fā)生后，我去北京做行業(yè)認(rèn)證，剛好遇到國家部委工信部的同事來詳細(xì)地了解情況，后來工信部的同事把這個故障涉及的流程規(guī)范寫進(jìn)行業(yè)認(rèn)證的規(guī)范中。那時我在想，由于一個問題出現(xiàn)竟然可以影響或者改變行業(yè)的一些東西。

總結(jié)，故障文化就是運維需要認(rèn)真地去針對每一次故障、事情和問題本身、以及針對性的解決方案和故障預(yù)防或規(guī)避流程。

第二個是 線上文化。通常來說，運維對線上是最敏感的，比如最近在做春保，不知道大家有沒有去好好拜拜服務(wù)器（玩笑），這里不得不提大家常講的一個詞叫敬畏心，亦或是對線上的敬畏心。

敬畏心到底是什么？我嘗試做下總結(jié)：

不輕易去改變線上當(dāng)前穩(wěn)定的運行狀態(tài)；如果要去改變，一定要多次驗證，并且是可逆的；

因為它現(xiàn)在運行得好好的不動就不會出問題，一動就有可能會出問題，所以你去真正改變線上穩(wěn)定運行狀態(tài)的時候，要想如果我改變了之后可能會有問題，能不能再恢復(fù)到原來狀態(tài)。原來我理解敬畏心很抽象，但落到日常的具體工作中，這其實就是運維具備的基本常識（有些研發(fā)在出問題的時候可能第一反應(yīng)是debug或者fix，而運維會優(yōu)先止損），所以這里也是我認(rèn)為運維這個職業(yè)跟大家很不一樣的地方，比如在做發(fā)布變更的時候，要有灰度意識，所有不經(jīng)過灰度直接發(fā)布是不能接受的，穩(wěn)定性更不用說了，線上的穩(wěn)定是運維的底線或者是生命，所以運維的線上文化是很重要的。

下面我想跟大家分享下準(zhǔn)則，每個行業(yè)都有自己的祖師爺，逢年過節(jié)要去拜一拜。運維這行應(yīng)該拜誰（祖師爺）？我上面列了三張圖，第一個是墨菲。因為我以為做運維一定要相信墨菲定律。什么是墨菲定律？其實墨菲定律本身是一個心理效應(yīng)。大概講的是：

● 首先，任何事情都沒有你表面看上去那么簡單。

● 第二，所有的事情基本上都會比你預(yù)估的時間要長。

● 第三，你以為會出錯的終歸會出錯。

● 第四，如果你擔(dān)心某件事情發(fā)生，它就一定會發(fā)生。

經(jīng)常我們關(guān)注的可能是第三點和第四點，就是小概率事情一定會發(fā)生。所以為什么運維要信墨菲定律？其實邏輯很簡單，本身我們職業(yè)的特殊性，就決定一個應(yīng)用程序或者一個配置真正到線上生效，我們是最后一道屏障。

我記得很清楚，有時研發(fā)同學(xué)在跟我們復(fù)盤時，經(jīng)常說這個bug是一個小概率事件，它觸發(fā)的場景非常有限，但是這不能放到運維身上來，因為運維是線上的最后一道屏障，兜底的，如果從我們這邊露出小概率事件，有可能真的會導(dǎo)致故障。所以作為運維一定不能容忍所謂的小概率事件，只要這里有個隱患，我就不能偷個懶，就不要想著故障可能不會出現(xiàn)；要想著如果有隱患不解決它就一定會出問題。不要輕易的把一些所謂的小概率事件漏掉，這是墨菲定律。

第二個 是個德國工程師的海恩法則，是個關(guān)于飛機飛行安全的故事，德國人非常嚴(yán)謹(jǐn)，海恩在經(jīng)過研究發(fā)現(xiàn)每一起嚴(yán)重的飛行安全事故，背后一定有29起輕微事故，以及300起未遂先兆，以及1000起事故隱患。量化的數(shù)字可能是經(jīng)過科學(xué)分析的，但實際上他想強調(diào)兩點：首先事故發(fā)生一定是量變引起質(zhì)變的，是一個積累的過程；第二是再好的技術(shù)、再完美的規(guī)章在操作層面，也無法替操作人的素質(zhì)。

總結(jié)海恩法則，在日常工作中，發(fā)現(xiàn)一個故障，再去做復(fù)盤，你會發(fā)現(xiàn)是因為他前面每一層都在出問題，一點一點，有很多先兆。

第三個是灰犀牛理論，這個理論實際上最早用于金融界，但是你會發(fā)現(xiàn)，不管是造飛機，心理學(xué)，金融界，跟我們工作都很有關(guān)系?；蚁＠碚摳６鞣▌t有些類似。黑天鵝事件大家應(yīng)該都知道，黑天鵝其實是一種偶發(fā)性、不可預(yù)見的，之所以叫黑天鵝，就是因為它突然出現(xiàn)，無法預(yù)防。但是灰犀牛實際上是一個你能夠看見、顯而易見、很大的一個危機。

所謂的灰犀牛事件，出現(xiàn)時不是隨機突發(fā)的，前面有一系列的警示與告知，最后才慢慢變成一個黑天鵝事件。所謂黑天鵝事件，或者故障，是想告訴大家，在出現(xiàn)這些跡象和這些警示的時候，我們不應(yīng)該掉以輕心。有時你會偷懶，會得過且過，但實際上前面有很多地方不應(yīng)該去輕視它，要去解決它。跟海恩法則會有一些類似。大家以后逢年過節(jié)，或者重大保障之前，除了拜服務(wù)器也可以拜一拜這三位，千萬不要出問題。

這些所謂的原則準(zhǔn)則，希望能夠變成大家的職業(yè)習(xí)慣，變成潛意識去主動思考問題。首先不要相信小概率事件，該發(fā)生的一定會發(fā)生。第二，要去重視一些潛在的東西，出現(xiàn)隱患時要及時解決，不要讓它變成真正的一個故障。

鯨魚是地球上最大的哺乳動物。鯨魚的心臟是世界上最大的，據(jù)說有800公斤。而作為運維人來說，我認(rèn)為也需要有這樣強大心臟。

首先是線上操作，很多時候，即使你知道接下來這個操作非常重要，操作下去可能會出重大的問題，比如說把某一個服務(wù)重啟，但如果在前期做好評估，預(yù)案也已想清楚，前面所有都做了，就應(yīng)該有自信，線上操作膽大心細(xì)。

第二個，當(dāng)真的出問題了所有人都很慌亂時，在整個產(chǎn)品或團隊中唯一不能夠慌亂的那個人就是運維。因為本身你更清楚監(jiān)控更清楚預(yù)案，清楚如何操作，如果連你的手都在抖，都在害怕，那這個問題大概率沒人能夠靠得住。

第三，復(fù)盤和故障是家常便飯，每天都在出故障，有時大家會常常因為某些故障很懊惱很糾結(jié)，但是我覺得大家要習(xí)慣，我們應(yīng)該越挫越勇。出問題沒有關(guān)系，通過流程和工具把這些問題徹底解決掉，不用太糾結(jié)；對于已經(jīng)入行和即將入行的，或者未來大家想繼續(xù)發(fā)展的，我覺得這一點特質(zhì)非常重要。

第二和重要特質(zhì)，強迫癥。為什么要有強迫癥？有時看到一些隱患或者不好的操作習(xí)慣，甚至一些不好的流程等，這時我們不應(yīng)該容忍，特別是有些問題或隱患可能涉及到線上，更不可以，應(yīng)該立刻解決。第二個，運維工作本身挺繁瑣的，包括有很多重復(fù)勞動，第一遍第二遍，會做很多遍。對這些Dirty work我們也不能容忍，應(yīng)該想法做工作做平臺去提升效率。第三個，如果大家做出來的這些流程，沒有人遵守，或者因為各種各樣的特殊流程去跳過某一個的，這個流程本身就沒什么存在意義，所以在執(zhí)行的時就應(yīng)該是一步都不能少。

我希望大家在工作時該有這樣的強迫癥，對線上負(fù)責(zé)，去消滅一些問題，提升效率；做流程時也嚴(yán)格執(zhí)行，流程一步都不能少。

運維人的核心競爭力是什么，所謂核心競爭力是不可替代性，應(yīng)該怎樣去做？我認(rèn)為：

第一個 核心競爭力是對操作系統(tǒng)掌握。原來最早做運維的人就是所謂的古典派，他們對操作系統(tǒng)是非常深入的。我們現(xiàn)在很多應(yīng)用和服務(wù)還是跑在Linux或者unix操作系統(tǒng)上，所以對應(yīng)出現(xiàn)問題應(yīng)該怎么去排查，性能怎么去優(yōu)化，監(jiān)控怎么去做，而這些都是需要對操作系統(tǒng)原理和架構(gòu)清楚的，所以操作系統(tǒng)是很核心很基礎(chǔ)的。

第二個 核心競爭力是對業(yè)務(wù)和架構(gòu)的深入掌握。運維會負(fù)責(zé)不同產(chǎn)品，它們之間的區(qū)別到底是什么，我覺得就是對所負(fù)責(zé)的業(yè)務(wù)和架構(gòu)的深入理解。比如我是做存儲的，對整個存儲的架構(gòu)，整個鏈路，底層的理解，以及關(guān)聯(lián)的存儲網(wǎng)絡(luò)、存儲硬件的了解和掌握，是你不可替代的部分。這是未來你再去找工作，大家最看重的東西。因為只有你深入的去做這個業(yè)務(wù)，做了很多年，你腦子里有很多東西是別人不知道的或者是別人容易忽略的。如果說有一個新的業(yè)務(wù)，也要做這一塊的業(yè)務(wù)，就非常需要這樣的人，不管是運維體系，還是豐富的線上運維經(jīng)驗。

到底怎么深入，大致可以用這樣一個路徑。比如一個開源軟件，開始做肯定從網(wǎng)上找一些資料部署起來，稍微改一改，可以運行起來其實這才僅僅是第一層；然后你發(fā)現(xiàn)這個性能好像上不去，那就去研究哪些配置可以深入優(yōu)化下、適配業(yè)務(wù)，所以第二個層次是能夠做些配置的優(yōu)化；第三個層次，是發(fā)現(xiàn)有一些功能沒有，比如可能會基于它的源碼做一些插件，去實現(xiàn)它的更多功能；再往下深入，就是讓自己要去重新造跟這個一樣的東西（原來我們也干過這個事情，比如說重新寫一個做接入程序，有沒有這樣的能力能夠把他包起來）所以它是一層一層往后去深入的，大家可以看下到底現(xiàn)在在哪一層，就可以很清晰地知道應(yīng)該再往哪一層去深入。

第三個，方法論。用我個人的經(jīng)驗來說，我原來一直做存儲，然后19年leader讓我去負(fù)責(zé)數(shù)據(jù)庫，當(dāng)時我并沒有數(shù)據(jù)庫的背景，基本上就是知道最基礎(chǔ)的操作而已，這種水平讓我就很虛。但后來去做了我發(fā)現(xiàn)很多事情其實是差不多的。

首先 數(shù)據(jù)庫業(yè)務(wù)也要關(guān)注故障生命周期，都要做監(jiān)控、定位、預(yù)案恢復(fù)；當(dāng)然也有不一樣的地方，原來存儲我們巡檢的是硬問題、存儲節(jié)點狀態(tài)，數(shù)據(jù)庫巡檢是主從狀態(tài)（是不是斷開了，是不是延遲），這就是業(yè)務(wù)差異化的內(nèi)容；所以我就把原來做存儲的一些思路，拿來去做數(shù)據(jù)庫，除可能有一些上層的業(yè)務(wù)不太了解，其他還是能夠復(fù)用的。專業(yè)和業(yè)務(wù)層面也不用當(dāng)心，會有專門的同學(xué)來幫助我們學(xué)習(xí)。

所以，當(dāng)你做一個產(chǎn)品很久之后，有沒有去總結(jié)這個產(chǎn)品，比如應(yīng)該怎樣去運維，如果給你一個新的產(chǎn)品，你能不能把你原來的經(jīng)驗抽象出并且把它復(fù)制到一個新的產(chǎn)品，把這個產(chǎn)品做好。比如存儲做好了，可以經(jīng)驗復(fù)制到數(shù)據(jù)庫，比如再去做CDN能不能做，只有你不?？偨Y(jié)去提升，然后把它變成方法論，那你本身的能力就是在提高的，而且你的scope也變得越來越大，所以我覺得方法論其實是挺重要，特別是方法論本身的遷移的能力。

總結(jié)下，運維的核心，就是這三個（方法論、業(yè)務(wù)和架構(gòu)、操作系統(tǒng)）。

運維的技術(shù)棧比較雜比較廣，我總結(jié)了一些，可以參考左邊的這張圖。

右邊這個圖很好，可以用來做Linux性能監(jiān)測或者調(diào)優(yōu)，Linux的體系架構(gòu)是什么樣，每一層應(yīng)該去用什么工具去看，對應(yīng)什么樣的指標(biāo)（這個圖在網(wǎng)上找就能找到）。前面我在講基礎(chǔ)的核心競爭力的時，已說道對linux的操作的掌握是基礎(chǔ)。技術(shù)棧也是一樣，操作系統(tǒng)一定是技術(shù)基礎(chǔ)中的基礎(chǔ)，然后涉及四大方向：計算、網(wǎng)絡(luò)、存儲、數(shù)據(jù)庫。

如果你做業(yè)務(wù)運維偏向計算業(yè)務(wù)，那計算已經(jīng)做得很厲害后，你還可以去拓展去做網(wǎng)絡(luò)往深處去擴展，技術(shù)是不可能一成不變的，所以除了把基礎(chǔ)打好了之外，可以往其他的方向去做擴展和補充。

技術(shù)成長也是很多同事在聊的話題，比如最近狀態(tài)不好，每天都在這干一些重復(fù)的事情，也不知道有沒有前途，也不知道技術(shù)該怎么發(fā)展。但其實關(guān)于技術(shù)成長有個很好的實踐，就是公司P族的技術(shù)運營通道，通道給出了很詳細(xì)的能力模型系統(tǒng)，分了很多的子通道，每個都有一套完整的模型和能立項。

如果你不知道自己到底應(yīng)該怎樣規(guī)劃技術(shù)成長或者技術(shù)路線中，可以參考技術(shù)運營通道的描述，其實就是是兩個維度，第一個是專業(yè)知識，是橫向的維度，第二是級別深度， 是縱向的深度。

從一個處理現(xiàn)網(wǎng)問題的運維工程師在不同級別的要求是不同的，可以看到對應(yīng)8級或者10級的要求是完全不一樣的技能。

當(dāng)然還有另一個最簡單的方式，大家可以關(guān)注一下其他大公司的招聘要求，里面會很清楚的定義這個崗位和級別需要什么樣的技術(shù)。  

接下來是運維技術(shù)的發(fā)展和運維體系。運維技術(shù)的發(fā)展，大致經(jīng)歷了標(biāo)準(zhǔn)化、自動化、數(shù)據(jù)化、智能化這幾個階段，不同公司不同產(chǎn)品所處的階段不盡相同。大家也可以對比下自己當(dāng)前負(fù)責(zé)的產(chǎn)品處在哪個階段。這里我總結(jié)了行業(yè)內(nèi)不同公司的運維體系，從中可以看出不同公司的運維體系還是不太一樣，但其實很難去說哪個運維體系先進(jìn)。因為不同公司業(yè)務(wù)、所處的階段不同，那么他所需要的運維體系可能就不一樣。對于行業(yè)的趨勢和最新的技術(shù)，大家還是需要保持學(xué)習(xí)和敏感度。

到底什么是SRE？我的理解：SRE就是當(dāng)你讓一個軟件工程師來帶運維團隊的產(chǎn)物。Google的VP Benjamin在2003年加入谷歌時，當(dāng)時Boss給他的任務(wù)是讓他組建一個由7名工程師組成的生產(chǎn)團隊（Production Team）。要知道，在這之前他一直都是個寫代碼的程序猿！所以他只能按照我自己對運維的理解和想法和組建和帶領(lǐng)這個團隊，這個團隊就成了今天Google的SRE團隊，這個團隊也一直堅守著由一位終生程序猿設(shè)定的初心。

SRE團隊中的角色分為兩類，其中50%-60%的成員就是Google的軟件工程師；其余40%-50%的成員他們本身符合85%-99% Google軟件工程師的招聘標(biāo)準(zhǔn)，但他們具備一些軟件工程師沒有的技能，例如Unix系統(tǒng)、網(wǎng)絡(luò)（1層-3層）方面的專家，這些技能對SRE來說是非常有用的。所有的SREer都要求有能力和意識通過開發(fā)軟件系統(tǒng)來解決負(fù)責(zé)問題。在SRE內(nèi)部，通過跟蹤調(diào)研以上兩類成員的職業(yè)發(fā)展軌跡，我們發(fā)現(xiàn)并沒有什么不同；事實上，不同背景的SREer讓我們的團隊產(chǎn)出了智能、高質(zhì)量的運維系統(tǒng)。轉(zhuǎn)型——不會開發(fā)的運維不是好產(chǎn)品經(jīng)理。

第二個是DevOps。DevOps我們團隊涉及不多，目前也較少轉(zhuǎn)型DevOps，但從目前整個公司大家都在往這條路上去走，所以這里我淺談下自己的理解和看法。

我理解DevOps更多是一種能力模型。SRE，實際上是對DevOps的一個最佳實踐。

SRE更多針對OKR，DevOps我覺得更多像一個文化，或者是一種模型。他強調(diào)開發(fā)運維一體化，為什么要強調(diào)一體化？大家知道，在軟件工程最有效率的一種組織架構(gòu)，就是一個人從寫代碼、測試、開發(fā)、運維全部做完，因為他沒有溝通，也不需要溝通。我們現(xiàn)在很多團隊是DO分離的，DO分離有個最大的問題，就是兩個人天天吵架，我們kpi也不一樣，會有各種各樣的沖突，有很多其他成本，但是如果一個人很厲害全都搞定了那就非常有效率，所以DevOps最樸素的想法就是，圍繞效率把開發(fā)和運維一體化。我認(rèn)為DevOps這件事情更多是一種文化，衍生出來一些方法，組織形態(tài)，以及一些工具。

第三點，更高大上的一個詞叫AIOps。這個詞實際上提了好多年，但現(xiàn)在大家看你身邊真的有很多AIOps嗎？其實沒有。

首先AIOps，不管是崗位或本身，它是有專業(yè)門檻。因為大家做傳統(tǒng)運維出身，可以搞定Linux，寫腳本。但如果想往AIOps發(fā)展，或想知道AIOps到底干什么，或需要具備什么能力，我以為大致有3點：

第一點，建模能力。我們遇到的問題都是運維問題。比如快速恢復(fù)怎么監(jiān)控怎么去管資源，但是AIOps每天是做的是數(shù)學(xué)問題（可能是一個分類問題或聚類問題）所以你要有能力能夠把運維問題，抽象建模成數(shù)學(xué)問題，這是最基礎(chǔ)的。如果你都不知道怎么把運維問題變成個數(shù)學(xué)問題，光會算法也不行。有很多同學(xué)原來在本科或者是研究生是學(xué)算法相關(guān)的，但他不懂運維，我們很懂運維但我們數(shù)學(xué)不太好，所以這里還是有一些專業(yè)門檻。

第二點，數(shù)據(jù)。現(xiàn)在很多算法最基礎(chǔ)是要有數(shù)據(jù)，有些時候需要做訓(xùn)練，所以有時需要的是有標(biāo)注的數(shù)據(jù)。如果你不知道怎么建模，也不知道用什么方法，你先把這些數(shù)據(jù)全部規(guī)劃好存儲起來，并且能夠做好標(biāo)注，那未來想拿這個數(shù)據(jù)做一些事情，你是有基礎(chǔ)的。反過來如果你有算法，卻發(fā)現(xiàn)真的要去做很多事情的時候沒有數(shù)據(jù)，這是很致命的，所以我覺得數(shù)據(jù)對于AIOps來說也是很重要的。

第三點，算法。算法現(xiàn)在的平臺化和工具化做得非常好，有各種各樣的平臺，想要什么算法，只要把數(shù)據(jù)往里面一丟，自己勾一下就行，再做一下調(diào)參，這個事情大概就搞定了。如果具體去做算法，或者說研究算法，那可能會比較難，但如果僅僅想用算法，我覺得現(xiàn)在其實門檻沒有那么高，各種各樣的平臺和機器學(xué)習(xí)相關(guān)的一些插件已經(jīng)很成熟了，所以算法其實還好。所以AIOps是的專業(yè)門檻的，大概需要把建模能力，數(shù)據(jù)能力把全部給做起來。

最后，也是現(xiàn)場一位同學(xué)問我說，運維最終出路是什么？

我的理解是，首先是這個問題在于說大家把自己的角色想得太局限了，總是認(rèn)為自己是一個運維工程師，就應(yīng)該天天去看監(jiān)控、變更，故障處理等等。但實際上我覺得運維最終歸宿一定是業(yè)務(wù)。舉個很簡單的例子。

原來做運維的時候，每天都要做告警輪值，這件事情不僅在運營團隊，在研發(fā)團隊，在各種團隊都有需求，所以我們當(dāng)時就把這個事情變成了一個平臺，先給公司內(nèi)部給所有的人用，后來把這個平臺變成一個產(chǎn)品賣給其他的公司。因為每一個公司都要做輪值，然后再后來業(yè)界出現(xiàn)了個公司PageDuty，他其實就是把運維的這件事情產(chǎn)品化了，去賣錢。

最后一句話，不會開發(fā)的運維不是好的產(chǎn)品經(jīng)理?，F(xiàn)在對運維的要求越來越高，你除了會運維之外，還要會開發(fā)，像DevOps，結(jié)合業(yè)務(wù)，還是需要有很多的產(chǎn)品思維和產(chǎn)品能力，這樣才能夠不斷拓寬你的職業(yè)道路！