本文故事場景純屬虛構(gòu)，人物皆為化名，除此之外都是實在干貨。

[[211862]]

本文以敘事形式濃縮了很多運維場景、技術(shù)與總結(jié)。作者探討了：項目管理、云計算架構(gòu)、高效會議管理、網(wǎng)絡(luò)安全管理、運維自動化架構(gòu)設(shè)計、項目團隊管理、兩地三中心架構(gòu)、人員管理、運維架構(gòu)體系規(guī)劃、運維感悟等等與運維密切相關(guān)的典型案例及場景。

項目管理及云計算架構(gòu)

今天周五，多云霧霾，我到了單位，接杯水瞅了瞅窗外，云遮霧罩，有種做夢的感覺，不知為啥眼睛跳的厲害，這不是好兆頭。

我習(xí)慣先打開郵箱，再打開即時通訊軟件，再打開云筆記，看看 24 小時值班情況、工作郵件、項目郵件、即時消息和技術(shù)文章，通過這些內(nèi)容信息基本上能概覽昨天工作和今天要干的事情，同時了解一些最新技術(shù)動態(tài)。

面對朦朧的窗外，我在想：工作人生就是在層層迷霧中探索，不斷撥云見日，開拓眼界和道路，實現(xiàn)虛擬夢境到現(xiàn)實世界的轉(zhuǎn)變。

[[211863]]

看完郵件和一些 OA 內(nèi)容，我把今天要做事情劃分四個層次：

• 重要而且緊迫。
• 緊迫但不重要。
• 重要但不緊迫。
• 既不重要又不緊迫。

上午 10:00，我要召開每周項目例會，討論云計算項目進展情況和后期安排，做好四控兩管一協(xié)調(diào)工作（我好像干了監(jiān)理的工作）。

這個項目重大，我們將通過這些重大項目促進公司全面升級轉(zhuǎn)型技術(shù)架構(gòu)，由傳統(tǒng)信息化建設(shè)轉(zhuǎn)型深化移動互聯(lián)網(wǎng)式發(fā)展，向資源集約型、平臺支撐型轉(zhuǎn)變。

并提供持續(xù)集成與優(yōu)化服務(wù)，趨向敏捷快速交付，由單一的運維資源交付轉(zhuǎn)型全面云化生態(tài)運營交付。

我們的云計算架構(gòu)體系如下：

圍繞上述架構(gòu)原型，我們要在特定時間、預(yù)算、資源限定內(nèi)依據(jù)規(guī)范完成云計算項目建設(shè)，時間緊任務(wù)重，整個項目組壓力大，動力也大。

說到項目管理，它是一門大學(xué)問，做運維管理、系統(tǒng)集成，信息化建設(shè)，項目經(jīng)理等工作都需要了解，這里梳理了一個項目管理 5 大流程 10 大知識領(lǐng)域知識圖，有興趣大家可以看看 PMBOk 等相關(guān)資料，這里不再贅述。

高效會議管理

說到開會，也是一個技術(shù)活。為了提高會議效率和效能，我通常會這么做：

• 借鑒《羅伯特議事規(guī)則》。例如會議要有主持人、記錄人以維持好會議執(zhí)行效力；會議要有具體、明確、可操作的行動建議。

會議要有大小主題，不要跑題，發(fā)言有序、有時限。就事論事，不人身攻擊，不質(zhì)疑私人偏好，習(xí)慣，文化觀等。

• 提前發(fā)會議議題，資料。避免會上臨時看資料，臨時討論，所有都是臨時拍腦袋，導(dǎo)致會議冗長、效能差。
• 做好會議紀要，遵循 SMART 原則。明確會議的結(jié)論，任務(wù)、執(zhí)行人和期限，做好工作任務(wù)追蹤、追溯。

關(guān)于我們云計算項目進展，我看了下上周會議紀要，當(dāng)前還有兩個重要問題待解決：

• 云計算核心網(wǎng)絡(luò)跑內(nèi)部 BGP 及 OSPF 問題。
• 通過 VRF 解決多 VPN 路由轉(zhuǎn)發(fā)問題。

這些問題都很棘手且重要，因此問題交由王宜牽頭解決。王宜是我們的一個全棧型 SRE 人才。

他從前端 CDN、負載、代理到后端數(shù)據(jù)庫、存儲樣樣通，熟悉網(wǎng)絡(luò)架構(gòu)，我們的新建 IDC 網(wǎng)絡(luò)架構(gòu)就是他主導(dǎo)設(shè)計的，他還能寫的一手好代碼，我們的運維自動化平臺的核心模塊也是他主要完成的。

但有些遺憾的是王宜同學(xué)總是喜歡上來就干，不喜歡寫規(guī)劃，不喜歡寫文檔總結(jié)，無法協(xié)調(diào)好團隊。

自打讓他負責(zé)帶團隊之后，結(jié)果依然是他一個人在全線戰(zhàn)斗，沒有發(fā)揮整個團隊的價值。

為此我跟王宜談了多次，期望他能發(fā)揮更大能力，每當(dāng)我們討論到技術(shù)和管理的平衡關(guān)系時，最終往往陷入到底技術(shù)重要還是管理重要的漩渦中。不知廣大讀者朋友有何見解？

網(wǎng)絡(luò)安全管理

項目會剛開不久，這時網(wǎng)絡(luò)安全負責(zé)人劉森，神色凝重，讓我出來一下。

我跟著他到了隔壁會議室，劉森拿出一份文件來說，這是內(nèi)部安全審計結(jié)果，我們還有安全漏洞，需要立刻整改，否則下周一外部審計過來就不合適了。

我看了看報告，里面提到的安全問題概要如下：

現(xiàn)在網(wǎng)絡(luò)安全是運維常態(tài)化重點工作，我們通常定期做安全漏洞掃描、滲透測試。

針對安全漏洞，我們常用的漏洞修復(fù)策略如下：

• 嚴格各區(qū)域之間訪問限制與隔離，阻止服務(wù)器之間的互相訪問，防止內(nèi)網(wǎng)移動滲透。
• 下線有問題的系統(tǒng)，保留證據(jù)，重新安裝部署備機后再上線。
• 嚴格堡壘機訪問權(quán)限，什么角色的人使用什么權(quán)限。
• 加強系統(tǒng) ip tables 訪問策略，嚴格應(yīng)用訪問策略。
• 修改相關(guān)系統(tǒng)的賬號密碼。
• 升級打補丁，修復(fù)系統(tǒng)、應(yīng)用漏洞。
• 清理有木馬等異常的系統(tǒng)服務(wù)器。

雖然有上述很多安全防護措施，但我們總還隱約擔(dān)心安全，有種一入安全深似海，回首滄桑驚心懷。也因此我們正在探索從整體網(wǎng)絡(luò)架構(gòu)、安全架構(gòu)層面徹底解決安全防控問題。

由于是限期安全整改，截止到下周一必須完成。我們得立刻找人手開始修復(fù)漏洞。

考慮到這次安全限期整改的重要緊急性，我安排王宜加入劉森安全整改項目組。王宜是一個全棧型技術(shù)人才，希望他能幫助劉森盡快解決這些安全問題。

運維自動化架構(gòu)設(shè)計

對于批量增刪改查、密碼查詢修改，批量打補丁，系統(tǒng)部署，監(jiān)控管理等工作，我們有自己研發(fā)的一套運維自動化綜合管理平臺，總體功能框架設(shè)計如下圖：

本運維自動化是一體化解決方案，從我們的實際業(yè)務(wù)需求出發(fā)，基于 DevOps 理念，引入輕量級 IT 服務(wù)管理體系，以 CMDB 資源管理為核心驅(qū)動，圍繞運維監(jiān)控及自動化管理為建設(shè)主體，構(gòu)建起敏捷運維服務(wù)管理體系。

通過運維自動化管理解決方案融合、統(tǒng)一管理運維人員、資源、事件流程，統(tǒng)一監(jiān)控管理 IT 資源，有效關(guān)聯(lián)整合數(shù)據(jù)信息，從而促進運維管理工作的標準化、流程化、可視化、自動化、智能化、產(chǎn)品化。

最終目標是要提供更好地運維服務(wù)交付能力，更好地支撐我們當(dāng)前及未來業(yè)務(wù)快速穩(wěn)健發(fā)展。

如下是本運維自動化系統(tǒng)邏輯架構(gòu)規(guī)劃圖：

對于運維自動化系統(tǒng)的設(shè)計與實現(xiàn)思路，我們老大（后文即將出場）曾提出了他的一些建議：

• 功能要精專，模塊要解耦，不要過度設(shè)計。
• 產(chǎn)品要實用，能夠很好支撐業(yè)務(wù)，而不是僅僅做成純技術(shù)理論產(chǎn)品。
• 運維自動化是把雙刃劍，要特別注意安全防護和權(quán)限控制。

對此我有些不解，我總想把該系統(tǒng)做成大一統(tǒng)緊耦合，自動化到極致，寄希望于運維自動化解放運維人員，但實際情況我逐漸領(lǐng)悟到二八原則和中庸之道，凡事要適度恰到好處，凡事要柔韌不可用盡。

項目團隊管理

上午的項目會、安全事情和一些運維瑣事交織在一切，讓人感覺時間飛快，眼看就要 12:00 了，我看見劉森和王宜好像還在因為安全修復(fù)項目組怎么組建、怎么分工，怎么開工的事情爭論不斷。

我忍不住過去也加入了他們的爭論之中，我把我總結(jié)的布魯斯·塔克曼的團隊發(fā)展階段模型及應(yīng)對措施給他們講了講，希望他們能從中獲得一些價值和幫助。

說完我先走了，我得趕緊吃點午飯，準備一些材料。下周需要召開立項研討會。

我打算升級優(yōu)化核心數(shù)據(jù)庫系統(tǒng)的技術(shù)架構(gòu)，為此我已初擬了個立項報告。考慮到項目重大，我需要今天下午提前向老大匯報征求一下意見。

兩地三中心架構(gòu)概述

下午 14:00，我準時來到老大的辦公室，直奔主題說明我的想法。

由于歷史原因，我們的這組核心數(shù)據(jù)庫系統(tǒng)存在一些隱患：

• 有些模塊的數(shù)據(jù)庫 rac 集群心跳線還是百兆，無法保障集群的性能及穩(wěn)定性。
• 存儲陣列已經(jīng)過保，而且容量及性能都有限，難以支撐系統(tǒng)業(yè)務(wù)發(fā)展。
• 當(dāng)前缺乏有效地數(shù)據(jù)備份及災(zāi)備保護。

因此我建議重新升級優(yōu)化架構(gòu)，從整體設(shè)計上解決這些問題，主要思路如下：

• 基于兩地三中心大量成熟方案，構(gòu)建同城雙活實時同步，異地災(zāi)備異步同步體系，實施雙機 RAC+Dataguard 雙層冗余。
• 基于應(yīng)用、數(shù)據(jù)庫及存儲陣列級多層次數(shù)據(jù)同步，通過存儲連續(xù)性保護應(yīng)對應(yīng)用邏輯故障，外加磁帶歸檔存儲。

兩地三中心是什么樣的架構(gòu)，下面我給一個示意圖例：

我認為我考慮地很周全，我稀里嘩啦說了一通，但發(fā)現(xiàn)老大沒有欣賞之意。

老大問：“你是否與業(yè)務(wù)部門，研發(fā)部門，商務(wù)部門一塊討論過這個方案？”

“這個……沒有…….”我支支吾吾說：“我覺得這是純技術(shù)方案…..”

老大又問：“互聯(lián)網(wǎng)運維和傳統(tǒng)信息化運維有區(qū)別么？”

“這個，那個…..”我一時間腦袋空白了。

老大繼續(xù)再問：“你這方案的優(yōu)化創(chuàng)新思路在哪里？”

這時我感覺一股冷氣直入后脊梁，頭腦飛速但凌亂：“我這個方案有很多成熟案例，這種技術(shù)架構(gòu)已有好多年了……”

“是好多年了，你還在照搬多年前的技術(shù)架構(gòu)，方案毫無創(chuàng)新。”，老大若有所思：

• 首先你應(yīng)該了解業(yè)務(wù)，技術(shù)與業(yè)務(wù)不能兩張皮，技術(shù)要與其他部門業(yè)務(wù)協(xié)同，技術(shù)要支撐業(yè)務(wù)發(fā)展。
• 其次咱們不能再走傳統(tǒng)信息化那種封閉豎井式道路，要走平臺化、集群分布式、敏捷可持續(xù)、開放互聯(lián)、合作共贏的生態(tài)道路。
• 最后再次提醒你們，從業(yè)務(wù)到技術(shù)到運營，你們需要互相協(xié)同與支持。

我有種頓悟的感覺，但同時我也想趕緊離開這里。突然我的手機短信響了，是一條告警顯示“嚴重故障，MySQL 主從不同步”，我有種得救的感覺。

趕緊跟老大說：“我有個監(jiān)控告警，小故障，得去了解下情況”，說完趕緊從辦公室出來了。

我走到王宜那里問：“誰在處理 MySQL 主從不同步的故障？”

王宜很自信地說：“我在處理，這個小問題我能解決。”

“安全漏洞防護進展咋樣了？”我問。

“劉森讓我?guī)椭鱿到y(tǒng)安全加固和打補丁”，王宜有些無奈地表情說：“他根本不了解我這邊工作情況，我今天一直在忙，根本沒時間做系統(tǒng)安全加固的事情，等我把 MySQL 的問題解決了，再做系統(tǒng) ip tables 控制策略…..”

我沒有再說什么，只是在想，其實我更希望王宜他們團隊的組員去處理（而不是王宜直接處理），希望發(fā)揮其團隊每個人的價值。

但我又想，王宜本身也需要鍛煉團隊管理協(xié)調(diào)能力，所以還是由王宜自己判斷如何協(xié)調(diào)團隊工作吧。

傳統(tǒng)運維 VS 互聯(lián)網(wǎng)運維異同對比

我走回自己的辦公位，冥思苦想互聯(lián)網(wǎng)運維與傳統(tǒng)運維有什么區(qū)別呢？不知廣大讀者朋友有何見解？我先說說拙見吧。

傳統(tǒng)運維與互聯(lián)網(wǎng)運維的差異，可以歸結(jié)為如下 6 大差異：

• 架構(gòu)差異。
• 工作內(nèi)容差異。
• 知識體系差異。
• 面向?qū)ο蟛町悺?/li>
• 運維人員差異。
• 體制理念差異。

這里只擺放一個架構(gòu)差異的圖解，如下圖所示：

網(wǎng)絡(luò)大流量事件處置

這時，張馳快步向我走來，看著有些著急：有故障，我們的多個域名打開異常緩慢，網(wǎng)站性能監(jiān)測頻發(fā)告警。

雖然我干 IT 工作 10 余年了，但當(dāng)我聽到“故障”這倆字，仍然感覺刺耳敏感。

作為運維人，經(jīng)常要救火，頭腦需要冷靜，做到膽大心細，行事可以忙但不能亂。對于這種訪問故障，我們通常會基于網(wǎng)絡(luò)架構(gòu)層次逐個捋順排查和定位。

網(wǎng)站架構(gòu)通常如下圖所示：

基于網(wǎng)站架構(gòu)及網(wǎng)民訪問的數(shù)據(jù)流向，我們逐個排查 CDN、源站、負載均衡……

很快，我們發(fā)現(xiàn)一個老舊負載均衡設(shè)備上并發(fā)連接數(shù)激增，如下圖所示：

根據(jù)我們以往經(jīng)驗，這種突發(fā)激增往往由某種網(wǎng)站活動引起的。

經(jīng)過網(wǎng)安部梳理 CDN 監(jiān)測信息、負載情況、域名網(wǎng)站、流控監(jiān)測信息，網(wǎng)站業(yè)務(wù)運行信息，我們很快確定了部分網(wǎng)站緩慢原因。

由于惡意刷票導(dǎo)致突發(fā)大并發(fā)連接，過度消耗設(shè)備性能，由于這臺負載老設(shè)備處理并發(fā)性能有限，因此該負載下網(wǎng)站都出現(xiàn)了訪問緩慢問題。

我看了下時間 17:45，網(wǎng)安部門劉森向我走來，他懷著一種慶幸（找到了問題原因）和一些委屈（又是投票，這是業(yè)務(wù)層面事情，不是運維導(dǎo)致的故障）向我反饋詳細故障由來。

等他說完原因，我問道：“業(yè)務(wù)影響范圍有多大？后續(xù)如何處置？什么時間徹底解決？”

對于這些問題，劉森貌似還沒準備好如何回答。

我接著說道：做運維需要熟悉業(yè)務(wù)才能更好地支撐業(yè)務(wù)，基于業(yè)務(wù)場景的運維是運維價值觀的重要體現(xiàn)。

這個時候，我們老大也走了過來：“問題解決怎么樣了？要抓緊解決，不要保留問題過夜”，老大又說：“發(fā)生了這么多問題，你們要從架構(gòu)體系層面高屋建瓴式地解決問題，而不是天天忙于被動救火”。

我回答道：“好的，我趕緊落實處理惡意刷票問題……”。

老大又說道：“還有，你們要考慮如何升級轉(zhuǎn)型架構(gòu)體系，遵循公司戰(zhàn)略目標，通過技術(shù)創(chuàng)新升級并引領(lǐng)業(yè)務(wù)發(fā)展”。

對于老大的建議，我若有所思…..不過我還是先解決當(dāng)下棘手的刷票問題吧。對于這種惡意刷票現(xiàn)象，很多行業(yè)已屢見不鮮了，考慮到投票業(yè)務(wù)多樣性，我們運維解決思路也有很多方式。

列舉如下：

• 調(diào)整負載均衡流量，將大流量的業(yè)務(wù)切換到小流量的負載上，或者單獨配置（軟、硬）負載。
• 使用 IP 地址過濾，通過 CDN、前端防火墻、負載、代理、Lua 等軟硬件對惡意 IP 進行過濾。
• 通過 Session 會話、Cookies 驗證來防止惡意刷票。
• 通過實名制登記、登錄驗證碼等來防止惡意刷票。
• 把業(yè)務(wù)搬到公有云上，借助公有云資源來防護惡意刷票，也是一種手段。

人員離職現(xiàn)象與原因概括

不知不覺時間已經(jīng) 18:50 了，這時我們值班服務(wù)臺 Service Desk 同事打回電話說（需要二線支持），業(yè)務(wù)部門反映發(fā)布系統(tǒng)非常緩慢，甚至打不開，圖片、JS、CSS 加載緩慢。

但我查看網(wǎng)站性能監(jiān)控并未告警，從監(jiān)控來看有些波動，但貌似沒有太明顯異常。

這是為什么？這可能是前端或系統(tǒng)相關(guān)問題，我想找王宜核查一下，但劉森說他已經(jīng)下班走了。

“他不是在幫助你解決安全防護的問題么，怎么沒有個里程碑式結(jié)論就走人了？”我有些詫異。

“這個安全事情。。。。。咱們待會再商議吧”，劉森無奈地說“我現(xiàn)在給王宜打電話，優(yōu)先處理業(yè)務(wù)用戶反饋問題”。

稍后劉森說：“王宜電話沒人接，您看下步怎么辦？”

這時我腦子里首先一閃念，想起了一個運維前輩曾經(jīng)給我說過“做運維工作，要有高度責(zé)任心，不甩鍋不背鍋”。

我拿起電話，直接撥通了王宜團隊的組員李智的號碼。我把問題現(xiàn)象給他描述了一下。

李智說：“頭，這個問題現(xiàn)象有些籠統(tǒng)，咱們今天都做過什么變更么？”

我猶豫了一下，“今天的變更有很多，不過你先查查前端系統(tǒng)吧，我再找人查其他環(huán)節(jié)”。

李智也猶豫了一下“……我可能最近也要變動一下…..”

“你說什么？”我好想沒聽懂。

“我正想找您說這事……”李智說“我打算離職了……”

“啊？”我沒繼續(xù)說。

“這個回頭再說吧……”李智轉(zhuǎn)移了話題“我先處理問題吧”。

我掛下電話，有種焦頭爛額的感覺。我想了想：鐵打的營盤，流水的兵，離職倒也是正常現(xiàn)象。

可能離職原因多種多樣，但歸納起來，（借鑒馬斯洛需求層次理論）無外乎以下幾種訴求得不到滿足：生理需求（工資待遇）、安全需求（公司內(nèi)外環(huán)境）、社會需求（文化、社交）、尊重的需求（人文關(guān)懷、團隊建設(shè)）、自我實現(xiàn)的需求（職業(yè)發(fā)展）、自我超越的需求（人生發(fā)展）。

變更經(jīng)驗總結(jié)

我還在猜想李智的離職原因，這時王宜電話打回電話說剛才沒聽見電話響。我把問題給他又復(fù)述了一遍，他好像知道了什么。

“可能由于批量化操作，導(dǎo)致前端有組特殊的 Ngnix 系統(tǒng)的 ip tables 配置錯了”，王宜說：“估計李智不清楚這套系統(tǒng)環(huán)境，所以這事還是由我來處理吧”。

沒過一會，王宜反饋說問題解決了。主要原因是：這組特殊的 Ngnix 在負載后面，但由于錯誤的 ip tables 策略，收到負載請求則不處理丟棄，因此造成超時 TCP 重傳，負載只能再向 Ngnix 分配請求，如此造成訪問請求緩慢不穩(wěn)定。

雖然問題解決，但我總結(jié)教訓(xùn)如下：

• 盡量避免變更，應(yīng)保持不可變基礎(chǔ)設(shè)施。
• 一次變更只做一件事，同時做好變更的記錄。
• 條件允許的話，在做變更之前先做好測試、應(yīng)急回退措施。
• 做變更最好有實施者，有復(fù)核（配合）人員，有工作互備人員。最好能做到相關(guān)人員周知。
• 變更最好周五之前做，夜晚做。
• 運維自動化的確是把雙刃劍，沒有標準化、流程化的批量自動化可能是災(zāi)難。

運維架構(gòu)體系規(guī)劃

這時我突然想起老大的提醒，我應(yīng)該從架構(gòu)體系的層面梳理解決當(dāng)前一鍋粥似的一系列問題。運維架構(gòu)體系是運維的基礎(chǔ)及核心競爭力。

通過運維體系的構(gòu)建及完善，使我們的運維做到穩(wěn)定可靠，準確完備，規(guī)范科學(xué)。

以面向服務(wù)、持續(xù)交付為核心，從人、事、物、流程這四個方面把運維體系進行解構(gòu)，它們彼此互相作用，共同構(gòu)建了一個完整實用的運維體系。

前文已闡述了傳統(tǒng)運維與互聯(lián)網(wǎng)運維的不同層面維度的差異，但從另一方面來看，作為運維，還是有很多共同之處。

這里我將從一個架構(gòu)高度看待和規(guī)劃運維，如下圖所示：

下面列舉了這四個方面各自的含義及相關(guān)內(nèi)容：

• 人：例如完善崗位職責(zé)與職業(yè)發(fā)展、提高團隊技術(shù)水平、完善技能分享與培訓(xùn)、完善團隊績效考核、規(guī)范工作行為規(guī)范等。

目的是要建成一支工作高效、技術(shù)水平高、團結(jié)穩(wěn)定、有職業(yè)素養(yǎng)的運維團隊。

• 事：例如做好日?；A(chǔ)運維工作，保障好生產(chǎn)業(yè)務(wù)運行。不斷探索新的運維理念與技術(shù)，探索優(yōu)化系統(tǒng)架構(gòu)。

具體可以分為幾大塊，例如運維流程管理，資源架構(gòu)規(guī)劃，應(yīng)急與故障處理，監(jiān)控與優(yōu)化，安全與防護，項目及日常工作等等。

目的是要明白運維做什么正確的事，怎么正確地做事，做事有章法，穩(wěn)定高效能。

• 物：主要是如何管理好系統(tǒng)運維所涉及的各種資源。例如機房環(huán)境、辦公設(shè)備、服務(wù)器、網(wǎng)絡(luò)設(shè)備、操作系統(tǒng)、應(yīng)用軟件、工具等各種軟硬件資源。

目的要使各類資源配置管理妥當(dāng)，清楚資源屬性，知道從哪來，現(xiàn)在哪，要去哪使得物盡其用，物有所值，安置妥當(dāng)。

• 流程標準：運用流程標準將上述要素（人、事、物）有機地結(jié)合，有序科學(xué)地流轉(zhuǎn)、高效穩(wěn)定地運行。

例如資源規(guī)劃與采購，各種標準規(guī)范、項目規(guī)范、軟硬件配置部署規(guī)范、安全制度、工作交接等等。

如下列舉一個安全崗位運維規(guī)劃圖：

想著想著，不覺得已進入深夜，我看下時間，晚上 22:17 了。忙碌了一天，感覺整個身體被掏空，終于回到家可以洗把臉睡了。

晚上做起了夢，夢境不可描述，我把這個奇葩的夢境畫面貼出來，請讀者幫我解夢，說說你們的理解。

運維同理心

這雖然是一個夢，但夢卻是真實的表達。作為運維工作者，其中的酸甜苦辣，誰解其中味？也許誰干誰知道。

工作繁瑣：采購設(shè)備軟硬件，上架貼標簽，系統(tǒng)環(huán)境軟硬件部署，統(tǒng)計核實設(shè)備信息、復(fù)核系統(tǒng)變更情況，搬遷設(shè)備，調(diào)優(yōu)系統(tǒng)……如此工作，日復(fù)一日，年復(fù)一年，會讓人感覺無始無終。

鴨梨山大：有句話說的好“操著賣白粉的心，賺著賣白菜的錢。”，運維各種繁瑣工作交織一塊，在有限時間、精力和繁重工作情況下，我們倍感鴨梨山大。系統(tǒng)故障、上線、調(diào)優(yōu)、升級、恢復(fù)等特殊環(huán)境下，我們的身心都面臨著不可描述的感受……

設(shè)備系統(tǒng)故障：設(shè)備系統(tǒng)，尤其是過保的硬件設(shè)備，很容易出故障。機房環(huán)境、溫濕度，業(yè)務(wù)的讀寫頻繁度，業(yè)務(wù)人員野蠻地使用，各種因素都會導(dǎo)致設(shè)備系統(tǒng)意外故障。意外就是意外，往往出現(xiàn)在不恰當(dāng)?shù)臅r間、地點。經(jīng)常會讓運維人員莫名郁悶。

熬夜加班：有沒有別人節(jié)假日團圓 Happy，你在苦逼的加班熬夜。有沒有別人吃喝暢聊，你在角落里苦逼的遠程 VPN，有沒有三更半夜向特務(wù)一樣起床敲代碼，低聲細語的頻繁打電話？有沒有。。。。。。？反正我都有。。。。。

IT 消防員：我們就是 IT 消防員，我們的最高境界就是無我境界，大家都很舒服時都想不起來我。一旦想起來我，可能IT環(huán)境出問題了。。。。。。我們只有硬著頭皮去結(jié)尾，犧牲我一個，幸福一大家。

背黑鍋：運維人員有天生背黑鍋的宿命。當(dāng)你找不出別人的問題時，那就只能背黑鍋，或許找出問題，也可能一起背黑鍋。任何行業(yè)工作都有其委屈尷尬的一面，背黑鍋是運維人員成熟歷練的必經(jīng)之路。

我感覺夢里有種刺耳有熟悉的鈴聲響起，不……我突然醒了，原來是手機響了……..

[[211868]]

韓曉光，Devops Master、信息系統(tǒng)項目管理師、ITIL Foundation、RHCE，著有《系統(tǒng)運維全面解析：技術(shù)、管理與實踐》一書。