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

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

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

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

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

運維就如消防員

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

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

一句真理

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

本文標題：談談變更過程中的運維意識
網頁路徑：http://m.2m8n56k.cn/news22/102622.html

成都網站建設公司_創新互聯，為您提供電子商務、外貿網站建設、定制網站、關鍵詞優化、網站改版、搜索引擎優化

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：[email protected]。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯