作者介紹：

樑定安
騰訊織雲產品負責人，運營技術總監。十餘年網際網路運維從業經驗，高效運維社群金牌講師、復旦大學客座講師、騰訊雲佈道師、DevOps專家。親歷企業的伺服器規模從數十臺到數萬臺的運維工作，對於構建自動化運維體系和監控質量體系有著豐富的理論與實踐經驗。目前專注於騰訊織雲運維和DevOps解決方案的產品化輸出。

綜述
儘管每家企業的運維團隊面臨的挑戰與困難都有所不同，但每個運維團隊日常的工作內容是相似的。我們都要24小時待命，保障業務的質量穩定可靠；都要為每個業務運營活動，準備資源和釋出變更；都要衝在業務前線，撲滅故障的火苗。

運維團隊的使命就是為企業提供質量、效率、成本、安全的技術支援，為業務的健康發展保駕護航。

經常在一些新聞報道中，看到別人家的運維又因人為失誤而踩坑背鍋。如，某程式碼託管網站因為運維人員的失誤，錯刪生產環境的資料庫；某旅行網站的運維釋出系統出錯，導致業務中止營收受損。

這些案例都是對運維行業和運維專業度的傷害，我們在僥倖故障沒有發生在自己身上的同時，更多的應該反思為何在運維技術快速發展的當下，不同的運維團隊仍然在重複觸犯著同樣的失誤，而這些失誤仍然在反覆的折磨著各色各樣的企業。

日常運維三十六計是《DevOps三十六計》中的第一個計謀，編寫該計策的初衷很簡單，就是希望能為運維同行樹立一些正確和恰當的日常運維操作守則，讓廣大運維同仁能夠在工作中創造更大的價值，而不是把時間都浪費在不停的踩坑和填坑的工作上。

我們把日常運維工作分成計劃內任務與計劃外任務，該計策源自我個人十餘年的運維工作總結。主要目的是要沉澱出合適的實踐經驗和工作心得，指導各個運維團隊建設工具或設計流程，有效的識別和規避風險。

相信計策中有大家耳熟能詳的點子，但我懇請大家能耐心的讀完，因為不斷重複上演的運維事故一直在告誡我們，對重複、簡單運維操作的輕視和疏忽是日常運維的大忌。

幹一行，愛一行，既然選擇了運維行業，我們就要發揮聰明才智來優化與提高它，熟讀日常運維三十六計，對誤操作說“NO”，讓我們更好的應對計劃內的運維任務，有更多時間和精力去應對計劃外的任務，讓運維的工作步入良性的迴圈。

DevOps 三十六計之日常運維：

第七計：災難的緊急預案一定要有演練的機制，養兵千日用兵一時

2009年，騰訊大廈入夥，鵝廠在深圳終於擁有了屬於自己的辦公大樓，當大家都在慶祝喬遷之喜時，負責社交網路業務的小夥伴們，卻在為一個幸福的煩惱而焦慮。

那時正值WEB2.0大潮，Qzone農牧場業務引爆了全民“偷菜”社交活動，網民的熱情在服務的請求量上展露無遺，整個社交網路BU都在為這款火爆的產品忙得熱火朝天。

產品團隊在緊鑼密鼓的推出新功能新特性吸引更多的使用者，開發團隊和運維團隊都在夜以繼日為業務提供技術支援。然而，當機房建設速度趕不上業務發展速度時，深圳IDC的規模已經容納不下當時快速增值的社交和遊戲業務。

就是在這樣的大背景下，為了滿足業務長遠的規劃與發展，騰訊社交網路業務正式啟動走出深圳的專案，平臺級業務（QQ、Qzone）開始架構的優化升級，從過去無明確規劃的野蠻分佈的生長模式，轉為朝條帶化、SET化的多地域多中心的異地多活架構模式的演進。

SET化是運維團隊提出的一個很重要的概念，它代表著一個更為抽象的上層運維管理思想。

SET是提供特定功能場景的業務模組（業務模組是CMDB的管理概念，指提供單一功能服務的叢集，對應著一批IP。）的合集，如Qzone的接入SET，我們將使用者訪問Qzone的首屏所有涉及的業務模組，包括接入層、邏輯層和儲存層，都歸類到Qzone的接入SET規劃中。在同一個SET內業務模組需要保持分佈的集中，模組之間的訪問不產生IDC樓層之間的穿越流量。

同類SET之間保持服務的獨立性，業務架構採取一寫多讀的架構，以此保證當容災容錯排程時，SET能作為最小的排程單元供運維操作。

每個SET的規模一般在不超過50個業務模組，且規模被控制在500臺裝置以內。關於SET概念，在規劃和容災場景下，為運維團隊減少了運維物件，提升了決策的速度與排程的質量，是騰訊SNG運維團隊應對突發故障屢試不爽的管理利器。

但在剛嘗試引入SET概念時，SET的管理模式和運維團隊、運維繫統的磨合卻是花了很長一段時間去磨合，騰訊SNG的SET管理方案也經歷了幾次迭代，最終才能成為很好服務於業務的法寶。這一切是依靠我們踐行的運維方法“災難的緊急預案一定要有演練的機制，養兵千日用兵一時”。

運維提出SET的管理概念的目的很清晰，就是為了分佈與容災。結合織雲運維平臺的SET管理，實現了“一天部署一個SET“和“一鍵上雲”的運維效率，斬獲兩次公司級卓越運營獎。但是，當時在基於SET的容災排程管理上，我們卻未能這麼順利，因為擺在運維面前有幾個問題還有待解決：

• 調不調？

決策排程的核心指標太多，以哪個指標為準，在緊急故障發生時，這是個決策難題。必須事先準備好，最好是有且只有唯一一個決策的指標。

• 調哪個？

業務峰值遇到專線容量不足，排程解決時，調走哪個SET的流量，釋放多少專線容量，在緊急故障發生時，這是個決策難題。

• 怎麼調？

SET之間有依賴關係，從源頭SET排程走還是從中間的故障SET排程走，在緊急故障發生時，這又是一個決策難題。最好有統一的決策方式，無論故障形式，統一從源頭SET排程走。

• 調多少？

排程操作時，要切走一定百分比的使用者量，還是整個SET的使用者量全部切走，目標SET的冗餘容量是否充足，在緊急故障發生時，這是個決策難題，而且一旦決策失誤容量引起SET雪崩。

• 誰來調？

這是個背黑鍋的話題，排程的成功率由諸多因素與工具環環相扣組成，如有疏漏很容易造成執行排程時出現異常或故障，倘若沒有健全的策略保障，排程操作員的壓力將是巨大的，以至於影響排程的決策和執行速度。

再長遠的規劃總是有時效性和侷限性的，騰訊社交業務的SET規劃也一樣，我們通過堅持在業務高峰期反覆的排程演練，克服了SET容災排程規劃中的弱點。

每次在業務高峰期演練結束後，我們都有對規劃、系統、人員等因素的優化點，持續改進與打磨後，我們得出了最符合業務對質量與效率要求的SET架構與排程策略。

事後總結，這一切都是源於這條策略：“災難的緊急預案一定要有演練的機制，養兵千日用兵一時”。我誠懇的建議各位運維同仁，紙上得來終覺淺，絕知此事要躬行。任何方案都要輔以不斷的模擬演練，才能在千鈞一髮的瞬間發揮最大的效能。

第二十三計：每個偶然的故障背後都深藏著必然的聯絡，找到問題根源並優化掉

運維的日常工作時而雜亂時而繁瑣，但如果我們能抽絲剝繭的看清運維工作的本質，在看似雜亂無章的工作中，會有很多共同之處，加以規劃和處理，必定能對運維工作效率和質量有著事半功倍的成效。

在DevOps持續交付八大原則中，有一條原則是“提前並頻繁地做讓你感到痛苦的事情”，我們可以把運維的工作分成計劃內任務和計劃外任務兩大類。計劃內任務是指可預見的能否被提前防範，或者能夠輔以工作高效處理好的工作；而計劃外的任務則是指無法預見到，每次出現則要求運維人員緊急響應的救火工作。

七年前，負責系統運維的我接到一個專項優化任務，任務的目標是降低每位值班運維人員的電話量。這個任務對於團隊和個人都是非常有意義的，如果目標達成，則意味著我們的電話告警量減少，運維人員的幸福指數增加，為此我義不容辭的接下了該任務。

當時，騰訊SNG的值班運維主要負責響應處理基礎告警，包括裝置ping不可達、agent上報超時、程序/埠不存在、硬碟容量滿、硬碟只讀、大範圍網路故障，這幾類告警。

與業務邏輯異常無關的告警由值班人員統一負責處理，為的是收斂入口可以集中優化，減少基礎問題對更多人的騷擾。

對值班告警的優化過程，主要經歷了三個階段，我給大家還原下全過程：

• 第一階段，配置標準化與自愈

對於騰訊幾萬臺伺服器的運營規模而言，宕機的情況經常發生，那值班告警中，很大的告警佔比都是由此問題引起的。而應對這類問題的共性做法，便是安全的重啟裝置或替換新裝置，只要能保證自動化的操作不影響業務，就能做到故障自愈。

我們理清問題的脈絡後，便著手推進運維標準化、配置化的落實，在CMDB中儲存關鍵的業務配置資訊，如架構層、響應級別、資料是否有狀態等資訊。通過工具流程來保障配置資訊隨著模組和裝置的狀態流轉的及時更新。

配置標準化帶來的直接的效果是，ping不可達、agent上報超時、硬碟只讀，這三類直接可以通過重啟解決的基礎告警可以通過自動化的工具流程實現自愈。

• 第二階段，共性規則提煉

對於程序/埠不存在和硬碟空間滿的基礎告警，我們從運營資料觀察得出，這類問題基本上會隨著叢集多次發生。如某個模組對應的叢集有100臺裝置，其中有一臺裝置發生日誌寫滿硬碟，則其他99臺裝置有很大的可能性也會發生日誌寫滿硬碟的故障。

應對此有共性的基礎告警，我們採用了以模組為管理節點，將硬碟清理策略的規則應用於模組對應叢集的所有裝置上，以此保證只要模組下有任何一臺裝置發生過硬碟容量滿的告警，運維人員將清理策略配置在該模組的硬碟清理工具中，則可以免除該模組下其他裝置的硬碟容量滿的告警發生。

同理，這種共性規則提煉的方法也適用於程序/埠不存在的基礎告警。

• 第三階段，關聯分析與溯源

大範圍網路故障多指一些核心交換機故障，或者某些機房掉電的網路故障場景。在面對這類故障時，因為網路層面的故障影響的下聯裝置眾多，告警的表象多是告警不斷，運維人員可謂苦不堪言。

通過CMDB對裝置關聯的網路裝置與上聯交換機資訊的記錄，我們在設計告警架構時，專門增加二級告警收斂模組，其主要的邏輯是對告警內容進行機房與網路裝置的聚類收斂，如果有共性則收斂升級告警。以此實現減少告警傳送量和告警量收斂的目的。

值班電話告警優化專案已經結束了很多年，目前我們已經實現基礎告警90%以上的自愈處理，回想起當時專案的優化思路與執行過程，“每個偶然的故障背後都深藏著必然的聯絡，找到問題根源並優化掉”這條計策對於專案的順利進行給予了很好的指導。

在日常的運維工作中，建議大家切勿因事小而不為之，充分結合運維場景積累的知識和技術，利用脈絡思考的方法，順藤摸瓜，找到故障背後的共同點或相似點，再把解決問題的方法上升提煉到更高的維度，說不定能收穫事半功倍的成效。

第十一計：對不可逆的刪除或修改操作，儘量延遲或慢速執行

“運維三板斧：重啟、重灌、回滾”，這是運維圈內流傳的一個運維自嘲的段子，儘管是個段子，但是卻道出了不少運維行業為了快速修復問題所採取的緊急措施。其中，回滾操作往往是應對變更操作後出現異常的有效恢復手段。

國內國外的網際網路公司都出現過因為相關技術人員操作不當而引發的運營事故，而這些事故無法被快速修復的原因是因為變更無法被回滾。這些慘痛的案例一直在重演，如2017年3月gitlab的運維人員在多終端操作切換時，誤把生產環境當成測試環境，人為失誤的把生產環境的資料庫刪除。

雖然gitlab在遭遇重大事故時的公關處理得很從容優雅，公開致歉並且線上直播資料修復的全過程，贏得了大部分人的原諒，但是事故最終還是造成了700多個gitlab使用者的資料丟失。

在鵝廠工作的近十年運維工作經歷中，類似的低階人為失誤並不少見，我們反思著這些故障的根源是因為我們技術太差嗎？顯然不是的，對於運維而言，我們最優先的職責是要保障業務的質量，然後在謀求更高的效率、更低的成本等。

運維是技術團隊，但是光靠技術是無法解決所有難題，我們還需要有嚴格的記錄與規則，正如《日常運維三十六計》中的計策：“對不可逆的刪除或修改操作，儘量延遲或慢速執行”，這正是一條強調記錄的計策。

因為不光是gitlab，在騰訊海量的運維工作中，我們為此也是付出過很多沉痛的故障代價才“悟出”這個道理。

在應用程式的生命週期中，伴隨著業務的上線與下線，裝置（物理機與虛擬機器）會根據它所處於不同的生命週期階段，被安裝或解除安裝相關的應用程式和資料，以此達到資源有效流轉的目的。

在這個裝置上線與下線的過程，埋藏著很多引發故障的“坑”，稍不留意就容易觸雷，操作人員又要背上黑鍋。以騰訊的經驗為例，在操作裝置隔離下線時，容易產生的人為失誤操作有：

刪錯程式、刪錯資料。工具跑得太過自信，執行太過迅速，但是執行的物件因為一時失誤搞錯，釀成操作事故。

複製錯IP，搞錯下線裝置。複製貼上可以提高效率，但是每次複製貼上的內容是否足夠準確，貼上板中的內容真的是要操作下線IP嗎？這又是一個故障頻發的源頭。

流量未切乾淨就下線服務。心存僥倖的操作，切換流量沒有觀察足夠長的時間，便草草的下線服務或刪除資料，這絕對是人為過失。

為了徹底的降低和優化這些刪除或下線等不可逆操作潛在造成的風險，我們在運維工具中將運維的紀律與規則貫徹落地。以服務下線的工具流程為例（如下圖），運維標準化的工作執行流程分成七個步驟：

• 核實模組與IP。杜絕複製貼上的失誤，每次執行操作時必須校對模組與IP的對應關係，對裝置IP的下線操作遵循模組許可權的管理，基本上遮蔽了誤操作的風險。
• 名字服務下線。騰訊內部服務大量接入名字服務來實現負載均衡與高可用，下線操作流程會通過統一的介面層，在刪除服務或裝置前，集中批量的在名字服務下線，將流量切走。
• 服務停止。停止程序和埠，以此檢驗服務流量是否完全切乾淨，如果仍有訪問請求，則業務監控告警可以將其發現，下線流程將被中止。
• iptables隔離。基於iptables的防火牆策略，隔離非運維管理埠以外的全部訪問請求，保障該裝置不對外提供任何服務，如有異常，則業務監控告警可以將其發現，下線流程將被中止。
• 自動抓包觀察。啟動tcpdump自動抓包，找出非運維管理源IP以外的訪問源，並加以分析，如果屬於正常的業務訪問請求，則下線流程將被暫停或中止。
• 隔離週期。基於CMDB配置管理，對於不同模組、不同架構層、不同服務等級的裝置下線，隔離週期區別對待：快速下線隔離2天、普通下線隔離7天、資料庫下線隔離1個月等。
• 重灌/銷燬。下線的最後步驟，由工具自動化重灌作業系統或虛擬化銷燬。

上述騰訊運維的案例，是希望傳遞一個道理，運維工作中有很多高危的、不可逆的操作，這些操作需要技術與紀律同時保障，我們的工作才能進入良性迴圈，越來越好。

原文來自微信公眾號：高效運維