世界上沒有百分之百的安全，安全事故的發生在所難免，IT領域更是如此，因此當發生安全事故時，是否有預案來解決就變得尤爲關鍵了。本文將從雲廠商宕機史講起，談談預案能力的建設。
雲廠商宕機史
限於故障信息的披露涉及到很多環節，因此本文只從網絡上摘選一些信息進行羅列，同時，各類故障的佔比，也要辛苦大家自己來慢慢挖掘了。
AWS十年宕機史
2018年十大雲宕機
預案執行優先級
當發生服務故障後，應該立即執行哪些預案，預案執行的先後順序是什麼，主要是看預案執行的效果，基於以下因素，不同業務自行決定預案的執行順序
概率優先
首先需要考慮故障概率最高的三類場景是什麼，那對應的預案，就應該優先執行，畢竟能解決大部分的故障場景
生效時間
在明確了故障概率最高的三類場景後，就需要評估這三類場景的預案的生效時間了。舉例來說，對於某業務來講，可能最常見的問題之一就是容量問題，但擴容至少需要10-15min才能生效（假設無法繼續優化），那麼擴容預案就不適合作爲最優先的預案，因爲10-15min直接就打破了季度SLA99.99%的要求，你得另想辦法
是否有損
預案執行的目的是止損，如果預案的執行會帶來用戶體驗的下降或者是導致部分用戶無法使用，那就不應該作爲優先考慮的預案，而應該優先考慮那些概率較高且不會對用戶體驗造成影響的，就算預案執行後沒效果，起碼不會對業務產生負面的影響。對於服務已經故障一段時間，常規預案手段無濟於事的場景，這時候，預案之間比的是誰帶來的損失更小，至少不能比現在更差
複雜度
不同的預案，複雜度不同，對業務的影響也不同。舉例來講，切流量是相對簡單的操作，僅需要修改下DNS解析結果即可，但如果需要重啓線上所有的服務器，那不同的服務，操作要求不同，數據類服務貿然重啓，可能就會導致數據完整性問題
操作的冪等性
操作的冪等性是需要考慮的風險點，同樣是下發十次任務，進行流量切換的後果和服務器重啓的後果截然不同，流量切換是滿足冪等性的，你要求將流量從A切往B機房，無論執行多少次，都不會有什麼區別。而如果是重啓服務器呢，那執行十次可就是重啓十次啊
通過上述的評估標準，每個團隊都要建立起適合於自己業務的預案三板斧，並建立常態的預案演練機制，確保預案的有效性，且三板斧要能夠攔截80%的常規故障
預案七連擊
切流量
流量切換完全符合我們上述提出的五大要素，因網絡和機房故障需要切流量的場景足夠頻繁，生效時間基本在5min內，大部分時候不會引起服務質量的下降，複雜度較低，滿足操作冪等性的要求，因此非常多的團隊都將切流量作爲第一預案，一旦出現故障，先切流量試試看，從概率上看，大概有40-60%的可能性，是能夠搞定問題的。
對於外網服務來講，因爲要接入多地域多運營商的線路，因此切流量基本就是標配，無需贅述。而對於公司內部的基礎架構來講，很多人則會覺得作爲內部平臺，我沒辦法切流量。這個觀點我不能完全認同，其實對於大部分基礎服務來講，通過同城雙活或者異地雙活的部署，是可以做到流量切換的。這裏，我提供Google Borgmon的一個架構圖，Global Borgmon部署了兩套，而Datacenter Borgmon則是每個機房一套，這個思路非常值得做基礎服務的同學借鑑。
最後，切流量這個動作，是較爲容易標準化的。在BATJ裏，基本都實現了自動化，在公有云廠商裏，也作爲DNS的標配功能進行提供，在這裏也建議，大家也應該儘量讓切流量動作自動化，從而達成更高的SLA目標。後面，筆者也會專門寫一篇文章介紹下切流量的具體事宜。
降級
降級和切流量相比，就複雜多了，主要是降級目前還很難做到標準化，雖然有lstio這類工具，能夠將部分業務場景的降級標準化，但lstio們本身也是剛剛起步，普及率較低，短期內指望不上。再者，在降級方面，lstio主要是解決容器化後微服務之間的問題，如果涉及到第三方服務、開源軟件以及未容器化的服務，可能也很難奏效。
既然短期內無法實現標準化，那結果可想而知，必然是”百花齊放“。大家以不同的方式來實現降級操作，因此時效性，複雜度，操作的冪等性這類要求，就需要具體問題具體分析了。
考慮到降級的複雜度，需要專門寫文章進行詳細解釋，因此在本文中，就簡要介紹下。關於降級，大牛講的非常好，先分級後降級，個人覺得，這是降級的關鍵所在。想想，一鍋粥的狀態下，怎麼降級，降什麼，根本無從談起，因此勢必要做到先分級，然後才能談降級。最後，把大牛當年寫的PPT中關於降級的一頁截圖出來，便於大家理解先分級後降級的具體思路。
限流
限流，也叫做流控，常見的是通過接入層對異常流量（包括攻擊流量，爬蟲流量，掃描流量等）進行封禁，隔離，限速等操作，從而確保服務整體的可用性。
那限流的順序是不是應該放在降級之前而不應該是降級之後呢？主要是如下考量，限流的功能常態是開啓的，因此一旦出現服務故障，那就意味着當前的限流策略被擊穿了，所以你只能快速降級嘗試緩解故障，如果在限流策略被擊穿後，立即研究限流被擊穿的原因，再重新上線新的限流策略，恐怕SLA99.99%無論如何是保不住了的。
限流大致可以分爲三個階段，分別如下
第一階段，通過單機上nginx的防攻擊模塊進行限流，因爲是單機行爲，因此閾值設定無法做到非常精確
第二階段，通過類似於nginx+lua+redis的方式，實現集羣模式的限流功能，因爲可以拿到全局數據，因此閾值設置可以較爲精細，效果上也會有明顯提升
第三階段，公司整體使用GTC/GTM類產品，實現全局的流量精細化管理，同時也會將接入層的功能進行擴展，在接入和轉發上，也會增加SSL卸載和加速，IPV6的支持已經灰度等功能，在安全和防攻擊上，則會引入WAF等功能，也會將全局流量調度納入其中，進而形成完整的產品體系，同時，因爲涵蓋了接入的方方面面，因此其數據分析也變得極爲有價值和意義
目前，GTC/GTM類產品，各大公有云廠商均有提供，並且支持私有化部署，並且可以集成對DNS的管理，大家可以多研究研究。
暫停變更
在出現較大故障後，如果預案三板斧（切流量，降級，限流）的執行沒有取得預期的效果，那麼這時候，就需要立即暫停變更了，避免問題更加複雜。
這裏的暫停變更，不是簡單意義的停止上線操作，應該是廣義的變更，如網絡，IDC，服務器，操作系統，基礎設施等等相關的變更。不同的公司有不同的方式，自動化程度高的公司，可能直接在控制檯上點擊一個全局暫停操作，那麼大部分的自動化變更操作都可以暫停，這時候，你甚至都無法未經許可在線上執行任何命令，自動化程度低一點的公司呢，靠吼也是管用的，畢竟人員數量有限，喊一嗓子，大家也都聽到了。
回滾
線上故障的主要來源之一就是變更，之所以回滾沒有放在首要位置有如下原因：
-
回滾的耗時較長，上線遵循灰度發佈，回滾雖然沒有這麼嚴苛，但是也不能直接全併發回滾，全併發回滾就意味着在回滾期間，這個服務是完全不可用的。畢竟很多時候的故障，可能沒有這麼嚴重，如果這樣操作，就違反了是否有損中不要更差的要求
-
變更操作定位難，因爲變更導致了全局故障，潛臺詞就是他已經通過了灰度發佈實現了全量發佈。這就意味着，時間已經過去了很久，那麼在此期間，必然也會有很多其他上線，因此你很難定位是哪個上線導致的，經驗之一是，大家會默認回滾一定時間內的所有上線，但對於有前後依賴的一些變更，其實也很麻煩，只是說，從是否有損的角度看，它不會比現在更差而已。
綜上述，回滾雖然是重要的止損手段，但是限於定位難度和耗時，很難作爲快速有效的手段
重啓
重啓預案更多的適合於部分實例異常的場景，對於大規模故障場景下，往往不是首選。同樣的，重啓也面臨回滾同樣的問題，生效期間服務不可用。
但也不能就此忽視了重啓的價值，我們的生活經驗告訴我們，什麼設備有問題了，重啓一下說不定就能好。因此，在沒有辦法的時候，試試重啓，也許柳暗花明呢。
擴容
在傳統運維的思路里面，擴容是不會作爲應急預案的，主要還是因爲耗時較長，而且也面臨是否有資源的問題。隨着技術的進步，虛擬化以及Docker的出現，一定程度改善了這個情況。但擴容的生效時間，也會在3-10min左右，部分服務還需要預熱一下才行，因此，還是沒有限流或者降級來的及時一些。
預案三板斧
綜上述，切流量，降級和限流就成爲了一般業務常用的三板斧，而回滾，重啓，擴容和暫停變更，則是一些輔助手段。需要大家結合自己的實際情況來制定適合自己的三板斧。
預案能力建設
完備性
衡量一個業務預案是否完備，有如下幾種方法可供參考：
-
有沒有預案三板斧
-
三板斧能不能覆蓋80%的過往故障場景
-
最近一個季度，執行過哪些有效的預案
-
故障的平均恢復時間是多久
下圖是一個電商業務的預案列表供大家參考
自動化
自動化的預案解決如下問題：
-
人員依賴，一旦將預案腳本化，自動化之後，只需要維護相關的腳本內容即可，給出明確的執行條件，那麼應急響應的工作就可以移交給專門的團隊負責
-
執行質量，手工執行的預案，依賴於人員的經驗和理解不同，可能會出現千人千面的慘劇，而無法真正的發揮預案的價值
-
知識沉澱，自動化後的預案，都是具備實操性的，因此可以在橫向進行分享和交流，從而更好的促進整體的能力提升，也更容易孵化出橫向的平臺
-
時效性，自動化後也能夠大幅提升預案執行的時效性，手工操作預案，往往需要有個人電腦開機，VPN登錄，管理系統登錄，頁面操作/命令行操作等步驟，而自動化後，或者不需要人工干預自動執行，至少，也是在移動設備直接操作的。
有效性
很多產品線說自己有上千過萬種預案，雖然從完備性角度，可能是一個很好的結果，但是從有效性角度看，大部分預案，可能從出生那一刻開始，從未被使用過，那這樣的預案，有何意義呢？也許真到了需要使用的那一刻，發現這個預案根本無法使用。
因此，保證預案的有效性就極爲重要了，如何保證呢，一是靠例行化的執行來驗證效果，再者通過定期覆盤過往的故障以及預案的效果也是極爲必要的。
預案平臺的切入點
單機房故障自愈
本文多處提到過，單機房故障是非常高頻的場景，且對業務的影響極大，而該場景極易標準化做橫向普及，因此預案平臺的建設，往往都是從單機房故障自愈來進行切入，從而才能夠在較短的時間，取得相對不錯的效果，進而才能夠獲得管理層的長期支持。
從業界看，也體現了這一特點，阿里和百度對於單機房故障場景均有相對的項目，本文在文章末尾提供了百度單機房故障自愈項目的幾篇文章供大家參考。
在《單機房故障自愈 - 黎明之戰》一文中，對單機房故障自愈可能面臨的問題有完整的羅列，主要是四點：
-
服務存在單點
-
服務跨機房混連
-
服務不滿足N+1 冗餘
-
服務關聯強耦合
對基礎設施的要求
基礎設施列表：
-
監控系統
-
SLA儀表盤
-
故障管理系統
-
容量管理系統
-
全局流量調度
-
任務調度系統
-
全鏈路壓測
-
Trace系統
-
混沌工程
-
彈性伸縮
參考文章