運維的一天：架構設計、故障處理、人員離職…
高效運維社群致力於陪伴您的職業生涯，與您一起愉快的成長。
作者簡介：
韓曉光
DevOps Master、資訊系統專案管理師、ITIL Foundation、RHCE。GOPS金牌講師、金牌作者。著有《系統運維全面解析:技術、管理與實踐》一書。
本文導讀：
本文以敘事形式濃縮了很多運維場景、技術與總結。目錄結構如下：
文中也提到一些問題困惑，作者希望以文互動，隔空問答，請讀者探討交流，同時點名了幾位業內大咖祈求答疑解惑。
本文故事場景純屬虛構，人物皆為化名，除此之外都是實在乾貨。
1、專案管理及雲端計算架構
今天週五，多雲霧霾，我到了單位，接杯水瞅了瞅窗外，雲遮霧罩，有種做夢的感覺，不知為啥眼睛跳的厲害，這不是好兆頭。
我習慣先開啟郵箱，再開啟即時通訊軟體，再開啟雲筆記，看看24小時值班情況、工作郵件、專案郵件、即時訊息和技術文章，通過這些內容資訊基本上能概覽昨天工作和今天要乾的事情，同時瞭解一些最新技術動態。
面對朦朧的窗外，我在想：工作人生就是在層層迷霧中探索，不斷撥雲見日，開拓眼界和道路，實現虛擬夢境到現實世界的轉變。
看完郵件和一些OA內容，我把今天要做的事情劃分四個層次：
1）重要而且緊迫；
2）緊迫但不重要；
3）重要但不緊迫；
4）既不重要又不緊迫。
10:00，我要召開每週專案例會,討論雲端計算專案進展情況和後期安排，做好四控兩管一協調工作（我好像幹了監理的工作）。
這個專案重大，我們將通過這些重大專案促進公司全面升級轉型技術架構，由傳統資訊化建設轉型深化移動網際網路式發展，向資源集約型，平臺支撐型轉變，提供持續整合與優化服務，趨向敏捷快速交付，由單一的運維資源交付轉型全面雲化生態運營交付。
圍繞上述架構原型，我們要在特定時間、預算、資源限定內依據規範完成雲端計算專案建設，時間緊任務重，整個專案組壓力大，動力也大。
說到專案管理，它是一門大學問，做運維管理、系統整合，資訊化建設，專案經理等工作都需要了解，這裡梳理了一個專案管理5大流程10大知識領域知識圖，有興趣大家可以看看PMBOk等相關資料，這裡不再贅述。
2、高效會議管理
說到開會，其實也是一個技術活。為了提高會議效率和效能，我通常會這麼做：
- 借鑑《羅伯特議事規則》。例如會議要有主持人、記錄人以維持好會議執行效力；會議要有具體、明確、可操作的行動建議。會議要有大小主題，不要跑題，發言有序、有時限。就事論事，不人身攻擊，不質疑私人偏好，習慣，文化觀等。
- 提前發會議議題，資料。避免會上臨時看資料，臨時討論，所有都是臨時拍腦袋，導致會議冗長、效能差。
- 做好會議紀要，遵循SMART原則。明確會議的結論，任務、執行人和期限，做好工作任務追蹤、追溯。
關於我們雲端計算專案進展，我看了下上週會議紀要，當前還有兩個重要問題待解決：
（1）雲端計算核心網路跑內部BGP及OSPF問題，
（2）通過VRF解決多VPN路由轉發問題。
這些問題都很棘手且重要，因此問題交由王宜牽頭解決。王宜是我們的一個全棧型SRE人才，從前端CDN、負載、代理到後端資料庫、儲存樣樣通，熟悉網路架構，我們的新建IDC網路架構就是他主導設計的，他還能寫的一手好程式碼，我們的運維自動化平臺的核心模組也是他主要完成的。
但有些遺憾的是王宜同學總是喜歡上來就幹，不喜歡寫規劃，不喜歡寫文件總結，無法協調好團隊。自打讓他負責帶團隊之後，結果依然是他一個人在全線戰鬥，沒有發揮整個團隊的價值。
為此我跟王宜談了多次，期望他能發揮更大能力，每當我們討論過技術和管理的平衡關係時，最終往往陷入到底技術重要還是管理重要的漩渦中。不知廣大讀者朋友有何見解？
@陳桂新，桂總您是如何辯證地看待運維技術與運維管理關係的？
3、網路安全管理
專案會剛開不久，這時網路安全負責人劉森，神色凝重，讓我出來一下，我跟著他到了隔壁會議室，劉森拿出一分檔案讓說，這是內部安全審計結果，我們還有安全漏洞，需要立刻整改，否則下週一外部審計過來就不合適了。我看了看看報告，其中提到安全問題概要如下：
現在網路安全是運維常態化重點工作，我們通常定期做安全漏洞掃描、滲透測試。針對安全漏洞，我們常用的漏洞修復策略如下：
- 嚴格各區域之間訪問限制與隔離，阻止伺服器之間的互相訪問，防止內網移動滲透；
- 下線有問題的系統，保留證據，重新安裝部署備機後再上線；
- 嚴格堡壘機訪問許可權，什麼角色的人使用什麼許可權；
- 加強系統iptables訪問策略，嚴格應用訪問策略；
- 修改相關係統的賬號密碼；
- 升級打補丁，修復系統、應用漏洞；
- 清理有木馬等異常的系統伺服器。；
由於是限期安全整改，截止到下週一必須完成。我們得立刻找人手開始修復漏洞。考慮到這次安全限期整改的重要緊急性，我安排王宜加入劉森安全整改專案組。
王宜是一個全棧型技術人才，希望他能幫助劉森儘快解決這些安全問題。
4、運維自動化架構設計
對於批量增刪改查、密碼查詢修改，批量打補丁，系統部署，監控管理等工作，我們有自己研發的一套運維自動化綜合管理平臺，總體功能框架設計如下圖。
本運維自動化是一體化解決方案，從我們的實際業務需求出發，基於DevOps理念，引入輕量級IT服務管理體系，以CMDB資源管理為核心驅動，圍繞運維監控及自動化管理為建設主體，構建起敏捷運維服務管理體系。
通過運維自動化管理解決方案融合、統一管理運維人員、資源、事件流程，統一監控管理IT資源，有效關聯整合資料資訊，從而促進運維管理工作的標準化、流程化、視覺化、自動化、智慧化、產品化。最終目標是要提供更好地運維服務交付能力，更好地支撐我們當前及未來業務快速穩健發展。
如下是本運維自動化系統邏輯架構規劃圖。詳細內容介紹請參考作者文章《運維自動化與標準規範化：解析、設計及實現 | 操作指南式的實戰》。
對於運維自動化系統的設計與實現思路，我們老大（後文即將出場）曾提出了他的一些建議：
- 功能要精專，模組要解耦，不要過度設計。
- 產品要實用，能夠很好支撐業務，而不是僅僅做成純技術理論產品。
- 運維自動化是把雙刃劍，要特別注意安全防護和許可權控制。
對此我有些不解，我總想把該系統做成大一統緊耦合，自動化到極致，寄希望於運維自動化解放運維人員，但實際情況我逐漸領悟到二八原則和中庸之道，凡是要適度恰到好處，凡是要柔韌不可用盡。
@王津銀，王總您是如何設計運維自動化解決方案的？
5、專案團隊管理
上午的專案會、安全事情和一些運維瑣事交織在一切，讓人感覺時間飛快。
眼看就要12:00了，我看見劉森和王宜好像還在因為安全修復專案組怎麼組建、怎麼分工，怎麼開工的事情爭論不斷。我忍不住過去也加入了他們的爭論之中。
我把我總結的布魯斯·塔克曼的團隊發展階段模型及應對措施給他們講了講，希望他們能從中獲得一些價值和幫助。
說完我先走了，我得趕緊吃點午飯，準備一些材料。下週需要召開立項研討會。我打算升級優化核心資料庫系統的技術架構，為此我已初擬了個立項報告。
考慮到專案重大，我需要今天下午提前向老大彙報徵求一下意見。
6、兩地三中心架構概述
下午14:00，我準時來到老大的辦公室，我直奔主題說明我的想法。由於歷史原因，我們的這組核心資料庫系統存在一些隱患：
- 有些模組的資料庫rac叢集心跳線還是百兆，無法保障叢集的效能及穩定性。
- 儲存陣列已經過保，而且容量及效能都有限，難以支撐系統業務發展。
- 當前缺乏有效地資料備份及災備保護。
因此我建議重新升級優化架構，從整體設計上解決這些問題，主要思路如下：基於兩地三中心大量成熟方案，構建同城雙活實時同步，異地災備非同步同步體系，實施雙機RAC+Dataguard雙層冗餘，基於應用、資料庫及儲存陣列級多層次資料同步，通過儲存連續性保護應對應用邏輯故障，外加磁帶歸檔儲存。兩地三中心是什麼樣的架構，下面我給一個示意圖例。
我認為我考慮地很周全，我稀里嘩啦說了一通，但發現老大沒有欣賞之意。
老大問：你是否與業務部門，研發部門，商務部門一塊討論過這個方案？
“這個……沒有…….”我支支吾吾說“我覺得這是純技術方案…..”
老大又問：“網際網路運維和傳統資訊化運維有區別麼？”
“這個，那個…..” 我一時間腦袋空白了。
老大繼續再問：“你這方案的優化創新思路在哪裡？”
這時我感覺一股冷氣植入後脊樑，頭腦飛速但凌亂“我這個方案有很多成熟案例，這種技術架構已有好多年了……”
“是好多年了，你還在照搬多年前的技術架構，方案毫無創新”，老大若有所思：
首先你應該瞭解業務，技術與業務不能兩張皮，技術要與其他部門業務協同，技術要支撐業務發展；
其次咱們不能再走傳統資訊化那種封閉豎井式道路，要走平臺化、叢集分散式、敏捷可持續、開放互聯、合作共贏的生態道路；
最後再次提醒你們，從業務到技術到運營，你們需要互相協同與支援”。
我有種頓悟的感覺，但同時我也想趕緊離開這裡。
突然我的手機簡訊響了，是一條告警顯示“嚴重故障，mysql主從不同步”，我有種得救的感覺。趕緊說“有個監控告警，小故障，我得去了解下情況”，說完趕緊從辦公室出來了。
我走到王宜那裡問： “誰在處理 MySQL 主從不同步的故障？”
王宜很自信地說：“我在處理，這個小問題我能解決”
“安全漏洞防護進展咋樣了？”我問。
“劉森讓我幫助他做系統安全加固和打補丁”，王宜有些無奈地表情說“他根本不瞭解我這邊工作情況，我今天一直在忙，根本沒時間做系統安全加固的事情，等我把mysql的問題解決了，再做系統iptables控制策略…..”
我沒有再說什麼，只是在想，其實我更希望王宜他們團隊的組員去處理（而不是王宜直接處理），希望發揮其團隊每個人的價值。但我又想，王宜本身也需要鍛鍊團隊管理協調能力，所以還是由王宜自己判斷如何協調團隊工作吧。
7、傳統運維 VS 網際網路運維異同對比
我走回自己的辦公位，冥思苦想網際網路運維與傳統運維有什麼區別呢？不知廣大讀者朋友有何見解？
我先說說的拙見吧，傳統運維與網際網路運維的差異，可以歸結為6大差異，如下：架構差異、工作內容差異、知識體系差異、面向物件差異、運維人員差異、體制理念差異。
這裡只擺放一個架構差異的圖解，如下圖所示。（具體闡述請參見作者文章《傳統運維 VS 網際網路運維 從哪來到哪去》）。
說到運維知識體系，@趙舜東（趙班長）總結的非常到位，那麼我有一個問題請教趙總：您構建起的運維知識體系是如何輸出價值，以支撐服務好業務（客戶）？
8、網路大流量事件處置
這時張馳快步向我走來，看著有些著急：有故障，我們的多個域名開啟異常緩慢，網站效能監測頻發告警。雖然我幹IT工作10餘年了，但當我聽到“故障”這倆字，仍然感覺刺耳敏感。
作為運維人，經常要救火，頭腦需要冷靜，做到膽大心細，行事可以忙但不能亂。對於這種訪問故障，我們通常會基於網路架構層次逐個捋順排查和定位。網站架構通常如下圖所示。
基於網站架構及網民訪問的資料流向，我們逐個排查CDN、源站、負載均衡……很快，我們發現一個老舊負載均衡裝置上併發連線數激增，如下圖所示。
根據我們以往經驗，這種突發激增往往由某種網站活動引起的。
經過網安部梳理CDN監測資訊、負載情況、域名網站、流控監測資訊，網站業務執行資訊，我們很快確定了部分網站緩慢原因：
由於惡意刷票導致突發大併發連線，過度消耗裝置效能，由於這臺負載老裝置處理併發效能有限，因此該負載下網站都出現了訪問緩慢問題。
我看了下時間17:45，網安部門劉森向我走來，他懷著一種慶幸（找到了問題原因）和一些委屈（又是投票，這是業務層面事情，不是運維導致的故障）向我反饋詳細故障由來。
等他說完原因，我問道：“業務影響範圍有多大？後續如何處置？什麼時間徹底解決？”
對於這些問題，劉森貌似還沒準備好如何回答。
我接著說道：做運維需要熟悉業務才能更好地支撐業務，基於業務場景的運維是運維價值觀的重要體現。
@許穎維：請問許總，你是如何運維好你們大資料業務系統的？
這個時候，我們老大也走了過來。“問題解決怎麼樣了？要抓緊解決，不要保留問題過夜”，老大說，“發生了這麼多問題，你們要從架構體系層面高屋建瓴式地解決問題，而不是天天忙於被動救火”
我回答道“好的，我趕緊落實處理惡意刷票問題……”。
老大又說道“還有，你們要考慮如何升級轉型架構體系，遵循公司戰略目標，通過技術創新升級並引領業務發展”。
對於老大的建議，我若有所思…..不過我還是先解決當下棘手的刷票問題吧。對於這種惡意刷票現象，很多行業已屢見不鮮了，考慮到投票業務多樣性，我們運維解決思路也有很多方式，列舉如下：
- 調整負載均衡流量，將大流量的業務切換到小流量的負載上，或者單獨配置（軟、硬）負載。
- 使用IP地址過濾，通過CDN、前端防火牆、負載、代理、lua等軟硬體對惡意IP進行過濾。
- 通過session會話、cookies驗證來防止惡意刷票。
- 通過實名制登記、登陸驗證碼等來防止惡意刷票
- 把業務搬到公有云上，藉助公有云資源來防護惡意刷票，也是一種手段。
9、人員離職現象與原因概括
不知不覺時間已經18:50了，這時我們值班服務檯ServiceDesk同事打回電話說（需要二線支援），業務部門反映釋出系統非常緩慢，甚至打不開，圖片、js、css載入緩慢。
但我檢視網站效能監控並未告警，從監控來看有些波動，但貌似沒有太明顯異常。
這是為什麼？這可能是前端或系統相關問題，我想找王宜核查一下，但劉森說他已經下班走了。
“他不是在幫助你解決安全防護的問題麼，怎麼沒有個里程碑式結論就走人了？”我有些詫異。
“這個安全事情。。。。。咱們待會再商議吧”，劉森無奈地說“我現在給王宜打電話，優先處理業務使用者反饋問題”
稍後劉森說“王宜電話沒人接，您看下步怎麼辦？”
這時我腦子裡首先一閃念，想起了一個運維前輩曾經給我說過“做運維工作，要有高度責任心，不甩鍋不背鍋”。
我拿起電話，直接撥通了王宜團隊的組員李智的號碼。我把問題現象給他描述了一下。
李智說“頭，這個問現象有些籠統，咱們今天都做過什麼變更麼？”
我猶豫了一下，“今天的變更有很多，不過你先查查前端系統吧，我再找人查其他環節”。
李智也猶豫了一下“……我可能最近也要變動一下…..”
“你說什麼？” 我好想沒聽懂。
“我正想找您說這事……”李智說“我打算離職了……”
“啊？”我沒繼續說。
“這個回頭再說吧……”李智轉移了話題“我先處理問題吧”。
我掛下電話，有種焦頭爛額的感覺。我想了想：鐵打的營盤，流水的兵，離職倒也是正常現象。
可能離職原因多種多樣，但歸納起來，（借鑑馬斯洛需求層次理論）無外乎以下幾種訴求得不到滿足：生理需求（工資待遇）、安全需求（公司內外環境）、社會需求（文化、社交）、尊重的需求（人文關懷、團隊建設）、自我實現的需求（職業發展）、自我超越的需求（人生髮展）
@樑定安：把這麼一個敏感話題交給大梁總,請問您是如何看待與處置人員離職問題的？
10、變更經驗總結
我還在猜想李智的離職原因，這時王宜電話打回電話說剛才沒聽見電話響。我把問題給他又複述了一遍，他好像知道了什麼。
“可能由於批量化操作，導致前端有組特殊的ngnix系統的iptables配置錯了”，王宜說“估計李智不清楚這套系統環境，所以這事還是由我來處理吧”
沒過一會，王宜反饋說問題解決了。主要原因是：這組特殊的ngnix在負載後面，但由於錯誤的iptables策略，收到負載請求則不處理丟棄，因此造成超時tcp重傳，負載只能再向ngnix分配請求，如此造成訪問請求緩慢不穩定。
雖然問題解決，但我總結教訓如下：
- 儘量避免變更，應保持不可變基礎設施。
- 一次變更只做一件事，同時做好變更的記錄。
- 條件允許的話，在做變更之前先做好測試、應急回退措施。
- 做變更最好有實施者，有複核（配合）人員，有工作互備人員。最好能做到相關人員周知。
- 變更最好週五之前做，夜晚做。
- 運維自動化的確是把雙刃劍，沒有標準化、流程化的批量自動化可能是災難。
11、運維架構體系規劃
這時我突然想起老大的提醒，我應該從架構體系的層面梳理解決當前一鍋粥似的一系列問題。運維架構體系是運維的基礎及核心競爭力。通過運維體系的構建及完善，使我們的運維做到穩定可靠，準確完備，規範科學。
以面向服務、持續交付為核心，從人、事、物、流程這四個方面把運維體系進行解構，它們彼此互相作用，共同構建了一個完整實用的運維體系。
前文已闡述了傳統運維與網際網路運維的不同層面維度的差異，但從另一方面來看，作為運維，還是有很多共同之處。這裡我將從一個架構高度看待和規劃運維，如下圖所示。
下面列舉了這四個方面各自的含義及相關內容。
人：例如完善崗位職責與職業發展、提高團隊技術水平、完善技能分享與培訓、完善團隊績效考核、規範工作行為規範等。目的是要建成一支工作高效、技術水平高、團結穩定、有職業素養的運維團隊。
事：例如做好日常基礎運維工作，保障好生產業務執行。不斷探索新的運維理念與技術，探索優化系統架構。具體可以分為幾大塊，例如運維流程管理，資源架構規劃，應急與故障處理，監控與優化，安全與防護，專案及日常工作，等等。目的是要明白運維做什麼正確的事，怎麼正確地做事，做事有章法，穩定高效能。
物：主要是如何管理好系統運維所涉及的各種資源。例如機房環境、辦公裝置、伺服器、網路裝置、作業系統、應用軟體、工具等各種軟硬體資源。目的要使各類資源配置管理妥當，清楚資源屬性，知道從哪來，現在哪，要去哪。使得物盡其用，物有所值，安置妥當。
流程標準：運用流程標準將上述要素（人、事、物）有機地結合，有序科學地流轉、高效穩定地執行。例如資源規劃與採購，各種標準規範、專案規範、軟硬體配置部署規範、安全制度、工作交接，等等。
如下列舉一個安全崗位運維規劃圖。關於運維架構體系的規劃，請詳見作者書籍《系統運維全面解析:技術、管理與實踐》，文章《韓曉光：系統運維體系架構規劃》。
想著想著，不覺得已進入深夜，我看下時間，晚上22:17了。忙碌了一天，感覺整個身體被掏空，終於回到家可以，洗把臉睡吧。晚上做起了夢，夢境不可描述，我把這個奇葩的夢境畫面貼出來，請讀者幫我解夢，說說你們的理解。
12、運維同理心
這雖然是一個夢，但夢卻是真實的表達。作為運維工作者，其中的酸甜苦辣，誰解其中味？也許誰幹誰知道。
工作繁瑣：採購裝置軟硬體，上架貼標籤，系統環境軟硬體部署，統計核實裝置資訊、複核系統變更情況，搬遷裝置，調優系統……如此工作，日復一日，年復一年，會讓人感覺無始無終。
鴨梨山大: 有句話說的好“操著賣白粉的心,賺著賣白菜的錢。”，運維各種繁瑣工作交織一塊，在有限時間、精力和繁重工作情況下，我們倍感鴨梨山大。系統故障、上線、調優、升級、恢復等特殊環境下，我們的身心都面臨著不可描述的感受……
裝置系統故障: 裝置系統，尤其是過保的硬體裝置，很熱容易出故障。機房環境、溫溼度，業務的讀寫頻繁度，業務人員野蠻地使用，各種因素都會導致裝置系統意外故障。意外就是意外，往往出現在不恰當的時間、地點。經常會讓運維人員莫名鬱悶。
熬夜加班: 有沒有別人節假日團圓happy，你在苦逼的加班熬夜。有沒有別人吃喝暢聊，你在角落裡苦逼的遠端vpn，有沒有三更半夜向特務一樣起床敲程式碼，低聲細語的頻繁打電話？有沒有。。。。。。？反正我都有。。。。。
IT消防員：我們就是IT消防員，我們的最高境界就是無我境界，大家都很舒服時都想不起來我。一旦想起來我，可能IT環境出問題了。。。。。。我們只有硬著頭皮去結尾，犧牲我一個，幸福一大家。
背黑鍋：運維人員有天生背黑鍋的宿命。當你找不出別人的問題時，那就只能背黑鍋，或許找出問題，也可能一起背黑鍋。任何行業工作都有其委屈尷尬的一面，背黑鍋是運維人員成熟歷練的必經之路。
我感覺夢裡有種刺耳有熟悉的鈴聲響起，不……我突然醒了，原來是手機響了……
文章來自微信公眾號：高效運維