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

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

一件小事以及引發的思考

事情呢是醬紫的，看到工作群有一個小伙A說需要重啟服務器重做 raid，原話大概是：

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：……（慚愧）

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

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

一件小事以及引發的思考

事情呢是醬紫的，看到工作群有一個小伙A說需要重啟服務器重做 raid，原話大概是：

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

一句真理

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

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

一句真理

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

總結

以上是生活随笔為你收集整理的【必看】谈谈变更过程中的运维意识的全部內容，希望文章能夠幫你解決所遇到的問題。

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