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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

● 第二，所有的事情基本上都會(huì)比你預(yù)估的時(shí)間要長(zhǎng)。

● 第三，你以為會(huì)出錯(cuò)的終歸會(huì)出錯(cuò)。

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

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

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

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

總結(jié)海恩法則，在日常工作中，發(fā)現(xiàn)一個(gè)故障，再去做復(fù)盤，你會(huì)發(fā)現(xiàn)是因?yàn)樗懊婷恳粚佣荚诔鰡栴}，一點(diǎn)一點(diǎn)，有很多先兆。

第三個(gè)是灰犀牛理論，這個(gè)理論實(shí)際上最早用于金融界，但是你會(huì)發(fā)現(xiàn)，不管是造飛機(jī)，心理學(xué)，金融界，跟我們工作都很有關(guān)系。灰犀牛理論跟海恩法則有些類似。黑天鵝事件大家應(yīng)該都知道，黑天鵝其實(shí)是一種偶發(fā)性、不可預(yù)見的，之所以叫黑天鵝，就是因?yàn)樗蝗怀霈F(xiàn)，無法預(yù)防。但是灰犀牛實(shí)際上是一個(gè)你能夠看見、顯而易見、很大的一個(gè)危機(jī)。

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

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

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

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

第二個(gè)，當(dāng)真的出問題了所有人都很慌亂時(shí)，在整個(gè)產(chǎn)品或團(tuán)隊(duì)中唯一不能夠慌亂的那個(gè)人就是運(yùn)維。因?yàn)楸旧砟愀宄O(jiān)控更清楚預(yù)案，清楚如何操作，如果連你的手都在抖，都在害怕，那這個(gè)問題大概率沒人能夠靠得住。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我理解DevOps更多是一種能力模型。SRE，實(shí)際上是對(duì)DevOps的一個(gè)最佳實(shí)踐。

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

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

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

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

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

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

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

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

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

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