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

[[211862]]

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

項目管理及云計算架構

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

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

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

[[211863]]

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

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

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

這個項目重大，我們將通過這些重大項目促進公司全面升級轉型技術架構，由傳統信息化建設轉型深化移動互聯網式發展，向資源集約型、平臺支撐型轉變。

并提供持續集成與優化服務，趨向敏捷快速交付，由單一的運維資源交付轉型全面云化生態運營交付。

我們的云計算架構體系如下：

圍繞上述架構原型，我們要在特定時間、預算、資源限定內依據規范完成云計算項目建設，時間緊任務重，整個項目組壓力大，動力也大。

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

高效會議管理

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

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

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

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

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

• 云計算核心網絡跑內部 BGP 及 OSPF 問題。
• 通過 VRF 解決多 VPN 路由轉發問題。

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

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

但有些遺憾的是王宜同學總是喜歡上來就干，不喜歡寫規劃，不喜歡寫文檔總結，無法協調好團隊。

自打讓他負責帶團隊之后，結果依然是他一個人在全線戰斗，沒有發揮整個團隊的價值。

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

網絡安全管理

項目會剛開不久，這時網絡安全負責人劉森，神色凝重，讓我出來一下。

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

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

現在網絡安全是運維常態化重點工作，我們通常定期做安全漏洞掃描、滲透測試。

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

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

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

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

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

運維自動化架構設計

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

本運維自動化是一體化解決方案，從我們的實際業務需求出發，基于 DevOps 理念，引入輕量級 IT 服務管理體系，以 CMDB 資源管理為核心驅動，圍繞運維監控及自動化管理為建設主體，構建起敏捷運維服務管理體系。

通過運維自動化管理解決方案融合、統一管理運維人員、資源、事件流程，統一監控管理 IT 資源，有效關聯整合數據信息，從而促進運維管理工作的標準化、流程化、可視化、自動化、智能化、產品化。

最終目標是要提供更好地運維服務交付能力，更好地支撐我們當前及未來業務快速穩健發展。

如下是本運維自動化系統邏輯架構規劃圖：

對于運維自動化系統的設計與實現思路，我們老大（后文即將出場）曾提出了他的一些建議：

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

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

項目團隊管理

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

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

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

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

兩地三中心架構概述

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

由于歷史原因，我們的這組核心數據庫系統存在一些隱患：

• 有些模塊的數據庫 rac 集群心跳線還是百兆，無法保障集群的性能及穩定性。
• 存儲陣列已經過保，而且容量及性能都有限，難以支撐系統業務發展。
• 當前缺乏有效地數據備份及災備保護。

因此我建議重新升級優化架構，從整體設計上解決這些問題，主要思路如下：

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

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

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

老大問：“你是否與業務部門，研發部門，商務部門一塊討論過這個方案？”

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

老大又問：“互聯網運維和傳統信息化運維有區別么？”

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

老大繼續再問：“你這方案的優化創新思路在哪里？”

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

“是好多年了，你還在照搬多年前的技術架構，方案毫無創新。”，老大若有所思：

• 首先你應該了解業務，技術與業務不能兩張皮，技術要與其他部門業務協同，技術要支撐業務發展。
• 其次咱們不能再走傳統信息化那種封閉豎井式道路，要走平臺化、集群分布式、敏捷可持續、開放互聯、合作共贏的生態道路。
• 最后再次提醒你們，從業務到技術到運營，你們需要互相協同與支持。

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

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

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

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

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

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

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

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

傳統運維 VS 互聯網運維異同對比

我走回自己的辦公位，冥思苦想互聯網運維與傳統運維有什么區別呢？不知廣大讀者朋友有何見解？我先說說拙見吧。

傳統運維與互聯網運維的差異，可以歸結為如下 6 大差異：

• 架構差異。
• 工作內容差異。
• 知識體系差異。
• 面向對象差異。
• 運維人員差異。
• 體制理念差異。

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

網絡大流量事件處置

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

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

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

網站架構通常如下圖所示：

基于網站架構及網民訪問的數據流向，我們逐個排查 CDN、源站、負載均衡……

很快，我們發現一個老舊負載均衡設備上并發連接數激增，如下圖所示：

根據我們以往經驗，這種突發激增往往由某種網站活動引起的。

經過網安部梳理 CDN 監測信息、負載情況、域名網站、流控監測信息，網站業務運行信息，我們很快確定了部分網站緩慢原因。

由于惡意刷票導致突發大并發連接，過度消耗設備性能，由于這臺負載老設備處理并發性能有限，因此該負載下網站都出現了訪問緩慢問題。

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

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

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

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

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

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

老大又說道：“還有，你們要考慮如何升級轉型架構體系，遵循公司戰略目標，通過技術創新升級并引領業務發展”。

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

列舉如下：

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

人員離職現象與原因概括

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

但我查看網站性能監控并未告警，從監控來看有些波動，但貌似沒有太明顯異常。

這是為什么？這可能是前端或系統相關問題，我想找王宜核查一下，但劉森說他已經下班走了。

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

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

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

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

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

李智說：“頭，這個問題現象有些籠統，咱們今天都做過什么變更么？”

我猶豫了一下，“今天的變更有很多，不過你先查查前端系統吧，我再找人查其他環節”。

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

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

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

“啊？”我沒繼續說。

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

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

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

變更經驗總結

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

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

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

雖然問題解決，但我總結教訓如下：

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

運維架構體系規劃

這時我突然想起老大的提醒，我應該從架構體系的層面梳理解決當前一鍋粥似的一系列問題。運維架構體系是運維的基礎及核心競爭力。

通過運維體系的構建及完善，使我們的運維做到穩定可靠，準確完備，規范科學。

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

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

這里我將從一個架構高度看待和規劃運維，如下圖所示：

下面列舉了這四個方面各自的含義及相關內容：

• 人：例如完善崗位職責與職業發展、提高團隊技術水平、完善技能分享與培訓、完善團隊績效考核、規范工作行為規范等。

目的是要建成一支工作高效、技術水平高、團結穩定、有職業素養的運維團隊。

• 事：例如做好日常基礎運維工作，保障好生產業務運行。不斷探索新的運維理念與技術，探索優化系統架構。

具體可以分為幾大塊，例如運維流程管理，資源架構規劃，應急與故障處理，監控與優化，安全與防護，項目及日常工作等等。

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

• 物：主要是如何管理好系統運維所涉及的各種資源。例如機房環境、辦公設備、服務器、網絡設備、操作系統、應用軟件、工具等各種軟硬件資源。

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

• 流程標準：運用流程標準將上述要素（人、事、物）有機地結合，有序科學地流轉、高效穩定地運行。

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

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

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

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

運維同理心

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

工作繁瑣：采購設備軟硬件，上架貼標簽，系統環境軟硬件部署，統計核實設備信息、復核系統變更情況，搬遷設備，調優系統……如此工作，日復一日，年復一年，會讓人感覺無始無終。

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

設備系統故障：設備系統，尤其是過保的硬件設備，很容易出故障。機房環境、溫濕度，業務的讀寫頻繁度，業務人員野蠻地使用，各種因素都會導致設備系統意外故障。意外就是意外，往往出現在不恰當的時間、地點。經常會讓運維人員莫名郁悶。

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

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

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

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

[[211868]]

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