本文以敘事形式濃縮了很多運維場景、技術與總結。作者探討了：項目管理、雲計算架構、高效會議管理、網絡安全管理、運維自動化架構設計、項目團隊管理、兩地三中心架構、人員管理、運維架構體系規劃、運維感悟等等與運維密切相關的典型案例及場景。
項目管理及雲計算架構
今天周五，多雲霧霾，我到了單位，接杯水瞅了瞅窗外，雲遮霧罩，有種做夢的感覺，不知為啥眼睛跳的厲害，這不是好兆頭。
我習慣先打開郵箱，再打開即時通訊軟件，再打開雲筆記，看看 24 小時值班情況、工作郵件、項目郵件、即時消息和技術文章，通過這些內容信息基本上能概覽昨天工作和今天要幹的事情，同時了解一些最新技術動態。
面對朦朧的窗外，我在想：工作人生就是在層層迷霧中探索，不斷撥雲見日，開拓眼界和道路，實現虛擬夢境到現實世界的轉變。
看完郵件和一些 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環境出問題了。。。。。。我們只有硬著頭皮去結尾，犧牲我一個，幸福一大家。
背黑鍋：運維人員有天生背黑鍋的宿命。當你找不出別人的問題時，那就只能背黑鍋，或許找出問題，也可能一起背黑鍋。任何行業工作都有其委屈尷尬的一面，背黑鍋是運維人員成熟歷練的必經之路。
我感覺夢裏有種刺耳有熟悉的鈴聲響起，不……我突然醒了，原來是手機響了……..