作者：huashionxu，騰訊 TEG 業務運維專家

運維同學作為站在研發團隊背后的男人們，一直在擔任著舉重若輕的角色，而這兩年盛行的 Devops、研效變革也直接影響到運維同學崗位職責的變化， 騰訊云架平技術運維副總監 huashion 近十年運維領域的自我修養體會，清晰運維人的工作職責定位，文化準則，與大家共同探討的職業發展，Devops 引發的職位變更等當下樂問熱點，本文旨在為所有可能看到的技術運維鵝們帶來一些成長的啟示。

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

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

在今天來看，當時 Margaret 做的工作其實就是在做預案，這跟我們現在運維做的工作是如出一轍的，所以從這個意義上講，她可以被認為是世界上第一個業務運維。

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

一、運維到底是干什么的？

很多人認為運維應該是在機房搬服務器，插拔網線，調試網絡，或者修電腦的。但我們自己覺得運維應該是個比較“高雅”的職業，每天狀態是在辦公室，泡杯茶或咖啡，面對電腦處理著工作....但實際上呢，其實還是挺苦的，很多運維同事都是救火的狀態，覺得特像消防員，每天都是在面對各種線上問題，半夜還要值告警，特別辛苦同時壓力也會很大。

1、運維的工作分類

運維這個職業有很多工種，比如說我自己是做業務運維，主要是面向業務的；還有系統運維，比如負責網絡，操作系統的、底層 IaaS 的等等；還有一類是數據庫 DBA，是專門負責數據庫；還有專門負責安全的安全運維；還有運維開發，Devops（AIOps）負責開發運維工具和平臺；還有像我們 8000 的小伙伴，做IT運維。

因為現在大部分的基礎設施都云化了，如果按照云的維度來看，又可以分為 SaaS、PaaS 和 IaaS 運維。

2、運維的工作職責

運維的工作職責和定位通常是：第一個定位 質量守門人，運維最核心的 OKR 或 KPI 就是圍繞質量，負責所有線上的問題；

第二個定位是效率提升者，運維需要對日常的一些重復工作去開發各種各樣的工具，提升整體運維效率，這樣才能更好的去驅動質量的提升；

第三個定位是口碑維護者，很多運維同學都是要接觸業務，不管是負責內部自研業務還是外部云客戶，都需要深入業務做好服務，在 TEG 很多同事都承擔了這樣的職責，這就是左邊的圈。

同時我們日常開展工作鎖圍繞的三個生命周期(右邊的圓圈)：

第一個故障生命周期，故障生命周期就是從一個故障最開始的發生，到發現，到定位，到分析，到最后恢復；

第二個應用生命周期，所有線上跑的應用 APP，從最開始的發布評審，到發布上線，到監控，包括做資源，后面預案，都是圍繞應用生命周期；

第三個資源生命周期，資源生命周期和應用生命周期還是有些區別。因為運維還管了很多設備，包括硬件設備，IT，實例資源，那就要去做資源生命周期的相關工作，包括資源的申請、報備......所以運維的職責大致就可以用這兩個圈來概括。

3、運維的工作內容

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

4、運維文化

運維跟研發，或者研究等其他崗位是有些差別，我大致總結了幾點。

4.1 故障文化

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

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

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

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

第二個故障是我入職時導師講的，有個同學半夜接到電話說某一批機器的分區要滿了，那個同學動作很快馬上寫了一個腳本開始批量刪除，結果不小心把歷史網頁庫的 1/3 全部刪除了。因為很多歷史網頁實際上現在已經沒了（原站已經關停了），所以他這次操作基本上把中國互聯網過去十年前 1/3 網頁干掉了，但當時 leader 跟我說這個同學還在公司，而且發展還不錯已經是經理了。這個例子讓我震撼的是，雖然運維做錯刪庫了（任何一個人都有可能犯錯誤），但只要不是故意不管是主觀還是客觀原因，至少大家對于運維都不會去針對人，還是聚焦事情本身。

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

所以總結來說，故障文化就是運維需要認真地去針對每一次故障、事情和問題本身、以及針對性的解決方案和故障預防或規避流程。

4.2 線上文化

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

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

不輕易去改變線上當前穩定的運行狀態；如果要去改變，一定要多次驗證，并且是可逆的；

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

5、運維準則

5.1 墨菲定律

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

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

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

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

● 第四，如果你擔心某件事情發生，它就一定會發生。

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

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

5.2 恩法則

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

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

5.3 灰犀牛理論

第三個是灰犀牛理論，這個理論實際上最早用于金融界，但是你會發現，不管是造飛機，心理學，金融界，跟我們工作都很有關系。灰犀牛理論跟海恩法則有些類似。黑天鵝事件大家應該都知道，黑天鵝其實是一種偶發性、不可預見的，之所以叫黑天鵝，就是因為它突然出現，無法預防。但是灰犀牛實際上是一個你能夠看見、顯而易見、很大的一個危機。

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

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

6、運維人的特質

運維人跟其他人除了在工作職責上有區別之外，在特質或者素質上有什么不一樣？我總結出 2 個特質，也許可以幫助大家更好的去工作。

6.1 第一個特質，大心臟

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

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

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

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

6.2 第二個特質，強迫癥

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

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

二、技術成長和個人成長

接下來，我分享下運維人的技術和個人成長部分，因為運維人員本身工作很瑣碎，所以大家就更關心里面有沒有成長，每天都在發變更，日復一日，年復一年，會非常焦慮。

1、核心競爭力

運維人的核心競爭力是什么，所謂核心競爭力是不可替代性，應該怎樣去做？我認為：

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

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

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

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

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

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

總結下，運維的核心，就是這三個（方法論、業務和架構、操作系統）。

2、運維人的技術棧

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

右邊這個圖很好，可以用來做 Linux 性能監測或者調優，Linux的體系架構是什么樣，每一層應該去用什么工具去看，對應什么樣的指標（這個圖在網上找就能找到）。

前面我在講基礎的核心競爭力的時，已說道對 linux 的操作的掌握是基礎。技術棧也是一樣，操作系統一定是技術基礎中的基礎，然后涉及四大方向：計算、網絡、存儲、數據庫。

如果你做業務運維偏向計算業務，那計算已經做得很厲害后，你還可以去拓展去做網絡往深處去擴展，技術是不可能一成不變的，所以除了把基礎打好了之外，可以往其他的方向去做擴展和補充。

3、技術成長

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

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

從一個處理現網問題的運維工程師在不同級別的要求是不同的，可以看到對應 8 級或者 10 級的要求是完全不一樣的技能

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

接下來是運維技術的發展和運維體系。運維技術的發展，大致經歷了標準化、自動化、數據化、智能化這幾個階段，不同公司不同產品所處的階段不盡相同。大家也可以對比下自己當前負責的產品處在哪個階段。這里我總結了行業內不同公司的運維體系，從中可以看出不同公司的運維體系還是不太一樣，但其實很難去說哪個運維體系先進。因為不同公司業務、所處的階段不同，那么他所需要的運維體系可能就不一樣。對于行業的趨勢和最新的技術，大家還是需要保持學習和敏感度。

4、轉型

這個也是我想重點提的，最近很多同學很焦慮這個問題。首先說 SRE，PCG 有很多組織都已經改了，包括職責也有對應的轉變。

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

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

第二個是 DevOps。 DevOps 我們團隊涉及不多，現在的團隊主要是做存儲，基本上沒有轉型 DevOps，但實際上現在整個公司包括 TEG，大家都在往這條路上去走，所以這里我淺談下自己的理解和看法。

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

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

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

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

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

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

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

三、運維最終的出路是什么？

最后，也是現場一位同學問我說，運維最終出路是什么？

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

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

第二個例子，跟我專業相關的，我是做云盤 CBS，CBS 有不同的規格，有低性能、中性能、高性能。那我們做了很多遷移和調度的事情，比如說用戶反饋性能有瓶頸，我可以把他從低性能遷移到高性能上面去，用戶就沒有問題了。如果我作為一個用戶，本身業務是有峰谷的，如果買的高性能云盤，那就一直要按照高性能云盤付費。但晚上如果低峰期，那能不能在晚上把它降成低性能。第二天早上業務高峰期之前，再通過無縫遷移，繼續遷移到高性能上去。在運維來看它其實就是一個遷移的工具，但是實際上如果能把它變成一個產品，可能就要一個自身的預判能力；對于用戶是非常喜聞樂見，因為原來的成本是一條這樣的曲線，通過我們的產品之后，可以變成另一條曲線，能夠為用戶節約成本。

所以，大家不要把自己想得局限，我們應該想怎么樣把我們的運維能力、工具平臺，往整個產品的主路徑上去輸出，產生更多的價值。站在更高的角度去想，能不能給產品增加的更多價值。

最后一句話，不會開發的運維不是好的產品經理。現在對運維的要求越來越高，你除了會運維之外，還要會開發，像 DevOps，結合業務，還是需要有很多的產品思維和產品能力，這樣才能夠不斷拓寬你的職業道路！

總結

以上是生活随笔為你收集整理的一个运维老将的自我修养的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。