運維，或許是一個在 IT 技術崗中很尷尬的職位。

• 其一，許多應屆生都未曾接觸過，對工作的職能界定非常模糊；

• 其二，很多其他技術崗的往屆生會覺得，“臥槽，這么 low 逼，只會重啟推配置做發布”；

• 其三，正在從事運維崗的往屆生會覺得自己在公司的 KPI 很難體現。我在從事運維工作的前 2 年，也總是問自己：WTF，到底我的存在有啥意義？

一件小事以及引發的思考

127.0.0.1 重做 raid，告警忽略@同事B@同事C

運維需要清楚“變更的需求背景”

我：A，你了解變更背景嗎？
A：因為 X 哥告訴我需要重做 raid。

我：為什么需要重做 raid？
A：因為需要給線上生產環境部署一套 FTP，做 raid5，而原來是 none-raid。

這一點上，A同學是可以回答的上來的，但是對于接到任務之后，就不假思索的去做，是很可怕的，因為你并不知道做這件事情的意義。

每一次變更就和開車并道一樣，并一次就多一分產生車禍的風險，需要清楚衡量變更的意義和價值，權衡風險和價值的輕重，才可以對此次變更進行有效的精力投入評估。BTW，我們必須要問自己一句：這個變更一定要做嗎，是否值得對需求方提出挑戰？

車禍猛如虎，變更也一樣

運維需要清楚“變更的合適時間”

我：你決定什么時候去做？
A：接到任務就直接想去做了。
我：下午 2 ~ 3 點有方案演示，萬一你產生了誤操作，導致演示失敗，客戶會如何？
A：我沒有想到這一點。

假設每次變更都有產生故障的可能性，那么就必須要確認清楚最佳變更時間。有幾個原則：

a. 避開本產品線業務高峰期、關鍵期；

b. 和同產品線的其他變更互斥；

c. 和相關產品線的其他變更互斥。

這一點上，同學A由于信息渠道窄，并沒有接到業務部門對產品演示的通告，違反了原則a。怎么規避掉這個風險呢？就是把變更看成一個項目進行推進，每個環節的進展需要同步告知干系人，干系人負責進行風險評估。

運維需要成為“變更的項目經理”

我：你有清楚了解這臺服務器之前的情況嗎？
A：沒有，我沒有想到。

我：你知道如果之前這臺服務器上有運行核心服務的進程沒有下線，會造成什么后果嗎？
A：X哥說這臺機器是新裝機之前沒有服務的。

我：運維需要做最后一道防線，要具備質疑的精神，X哥說的不一定是『真』的，你需要再確認下。

運維需要“遵循變更流程”

我：為什么要先做 raid 再告訴同事忽略報警？
A：這樣也沒什么問題嗎，不就是騷擾大家一下，我也提醒了。

我：為什么不走流程，先關報警再變更？
A：沒必要吧，SA每天這么多操作都需要這樣？

我：不關注細節，終會釀成大錯，當年我因為沒有關注流程出現過600個節點同時宕機的誤操作。假設你的報警淹沒了當時的其他重要報警，我們晚發現核心業務故障5分鐘，你知道損失是多少嗎？
A：……（慚愧）

變更的大致流程是：需求確認 -> 干系業務/人確定 -> 方案探討 -> 方案確立&時間確立 -> 變更單撰寫 -> 變更單 review -> 審批報備 -> 變更通告 -> 方案實施 -> 方案效果反饋 (-> 回滾方案)，可酌情進行步驟刪減。

遵循變更流程的主要好處是，首先，你可以在整理變更步驟的時候仔細思考每一處風險點，多次變更之后可以固化下來風險相對較小的標準化文檔，后續可以把重復操作自動化。

其次，風險均攤及最小化，方案是大家探討后確定的，時間是大家商量后認可的，流程是經過審批報備的。真的，如果把類似的流程貫徹下去，因為變更產生故障的概率會大大降低。現在成熟的公司運維團隊，都已經把類似的流程固化到運維平臺里了，但是又有多少團隊的負責人真正在遵循，而不是隨便審批了事呢？不要和我談業務壓力有多大，不要和我談缺人手，原則是不能卻步的，否則撿了芝麻丟了西瓜。

一句真理

這么小的一個變更事件，我們可從中總結出那么多的經驗，可見運維是一個全局操盤手，心不細真的不行。有一句話是之前我在阿里一直銘記在心的，雙手奉上給各位同行：對生產環境要有敬畏之心。

點個“在看”，一年不宕機