運維，或許是一個在 IT 技術崗中很尷尬的職位。其一，許多應屆生都未曾接觸過，對工作的職能界定非常模糊;其二，很多其他技術崗的往屆生會覺得，『臥槽，這么 low 逼，只會重啟推配置做發布』;其三，正在從事運維崗的往屆生會覺得自己在公司的 KPI 很難體現。我在從事運維工作的前 2 年，也總是問自己：WTF，到底我的存在有啥意義?

[[273624]]

WTF

運維并不是一個可以從校園里可以培養出來的職業，它完全需要從實踐中去體會。當然，今天寫這篇不是為了想告訴大家這兩年我體會到的所謂運維存在的意義，而是就一件最近工作上的一件小事和大家談談生產線應該具備的運維意識。

一件小事以及引發的思考

事情呢是醬紫的，看到工作群有一個小伙A說需要重啟服務器重做 raid，原話大概是：『127.0.0.1 重做raid，告警忽略@同事B @同事C』

本來這個事情貌似沒啥問題，鑒于近期公司出現了多次因生產故障產生的資損事件，我就單獨找他聊了下，看似風平浪靜的事情其實是波濤洶涌啊!

運維需要清楚【變更的需求背景】

這一點上，A同學是可以回答的上來的，但是對于接到任務之后，就不假思索的去做，是很可怕的，因為你并不知道做這件事情的意義。每一次變更就和開車并道一樣，并一次就多一分產生車禍的風險，需要清楚衡量變更的意義和價值，權衡風險和價值的輕重，才可以對此次變更進行有效的精力投入評估。BTW，我們必須要問自己一句：這個變更一定要做嗎，是否值得對需求方提出挑戰?

[[273625]]

車禍猛如虎變更也一樣

運維需要清楚【變更的合適時間】

假設每次變更都有產生故障的可能性，那么就必須要確認清楚最佳變更時間。有幾個原則：a. 避開本產品線業務高峰期、關鍵期;b. 和同產品線的其他變更互斥;c. 和相關產品線的其他變更互斥。這一點上，同學A由于信息渠道窄，并沒有接到業務部門對產品演示的通告，違反了原則a。怎么規避掉這個風險呢?就是把變更看成一個項目進行推進，每個環節的進展需要同步告知干系人，干系人負責進行風險評估。

運維需要成為【變更的項目經理】

打個比方，消防員在沖進火場的時候，需要確認是否仍有可能的爆炸源，否則被炸因公殉職也是自己的責任。運維在職能上和消防員類似，出現故障(火災)的時候去殲滅故障源(火源)，在執行變更的時候也需要多留一個心眼，反復確認上下游干系業務，才能進行變更規劃(其實故障處理也是一次緊急變更)。任何一次變更都要當做一個項目進行運作，清楚干系人，把控風險，制定合理的步驟和時間節點，我們要把他看成一個持續若干天的項目推進，也就是說變更其實在接到需求的那一刻就開始了。

[[273626]]

運維就如消防員

運維需要【遵循變更流程】

變更的大致流程是：需求確認 -> 干系業務/人確定 -> 方案探討 -> 方案確立&時間確立 -> 變更單撰寫 -> 變更單 review -> 審批報備 -> 變更通告 -> 方案實施 -> 方案效果反饋 (-> 回滾方案)，可酌情進行步驟刪減。遵循變更流程的主要好處是，首先，你可以在整理變更步驟的時候仔細思考每一處風險點，多次變更之后可以固化下來風險相對較小的標準化文檔，后續可以把重復操作自動化。其次，風險均攤及最小化，方案是大家探討后確定的，時間是大家商量后認可的，流程是經過審批報備的。真的，如果把類似的流程貫徹下去，因為變更產生故障的概率會大大降低。現在成熟的公司運維團隊，都已經把類似的流程固化到運維平臺里了，但是又有多少團隊的負責人真正在遵循，而不是隨便審批了事呢?不要和我談業務壓力有多大，不要和我談缺人手，原則是不能卻步的，否則撿了芝麻丟了西瓜。

一句真理

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