作者簡介
郭曉敏 百度高級研發工程師
負責百度智能運維產品（Noah）故障自愈平臺的設計和研發工作，在智能監控、智能故障自愈方向有廣泛實踐。
乾貨概覽
時隔一年，單機房故障自愈又和各位新老朋友見面了，在《單機房故障自愈—黎明之戰》中，我們介紹了單機房故障自愈的基礎設施建設，包括容災能力、智能監控平臺以及流量調度平臺。對於容災能力的容量建設，需保證服務常態容量滿足N+1冗餘，即在任何一個機房故障情況下，該機房流量能夠被其他機房剩餘容量所承載。那麼當業務流量增長，但資源成本有限，容量無法滿足N+1冗餘時，如何儘可能止損呢？這就是今天要和大家聊的話題，藉助服務降級平衡可用性、資源成本和業務效果，實現最大化收益。
重溫單機房故障自愈
在大型互聯網公司，單機房故障因爲其故障時間長，影響範圍大，一直是互聯網公司及運維人員心頭之痛。構成單機房故障的原因，除了常見的物理機房、運營商、鏈路等基礎設施層面故障，也包括突增的用戶請求、業務服務的容量不足、程序Bug、異常的運維變更操作等，都會觸發單機房級業務故障的發生。在傳統的運維方式中，由於故障感知判斷與容量&流量調度決策的複雜性，通常是人爲進行有效止損，但人工介入的時效性會影響服務的恢復速度，而人工決策的不可靠性則可能導致問題的擴大。
爲解決這類問題，針對百度內外部網絡環境建設了基於智能流量調度的單機房故障自愈能力。結合外網運營商鏈路監測、內網鏈路質量監測與業務指標監控構建了全方位故障發現能力，基於百度統一前端（BFE）與內網資源定位服務（BNS）實現了智能流量調度與自動止損能力。同時，基於實時容量預測與實時水位流量來調度自動止損策略與管控風險，從而實現任意單機房故障時業務均可快速自愈的效果。
單機房故障自愈流量調度過程
發生單機房故障時，根據請求流量、服務容量執行流量調度。當服務滿足N+1冗餘時，任何故障機房的流量可全部調度到健康機房，調度完成後沒有流量損失。
圖1 滿足N+1冗餘的流量調度
但由於業務使用量的增長，或活動等帶來的業務流量突增，機房容量的建設速度並不能完全滿足流量的上漲速度。發生單機房故障後，當服務不滿足N+1冗餘時，爲了避免過載誘發次生災害，故障機房的流量不能全部調度到健康機房，調度完成後故障機房仍有部分流量，造成了業務的損失。
圖2 不滿足N+1冗餘的流量調度
如何滿足N+1冗餘
爲保證在單機房故障情況下，服務仍然能夠滿足N+1冗餘，我們就需要在單機房故障情況下，快速增加健康機房的服務容量，儘量達到N+1冗餘，減少損失。
擴容是最直觀的增加服務容量方式，但在大部分情況下，我們的後備資源有限，缺少足夠資源來保證快速擴容。這時我們可以考慮另一種思路，即通過服務降級來裁剪服務部分功能騰出容量空間，實現在服務實例數沒有增長的情況下，單個服務實例處理能力的增長，實現容量的增加。
例如推薦類服務，可以將部分個性化內容推薦的步驟裁剪掉，直接返回熱門內容，使單次請求帶來的系統消耗減少，服務吞吐能力增加。雖然給用戶的內容質量有一定損失，但可以保證所有的用戶都能正常訪問。
圖3 通過服務裁剪進行降級
服務裁剪後健康機房騰出的容量可以承載故障機房的容量，滿足了容量的N+1冗餘。
降級多少合適
降級是通過裁剪服務來實現的，騰出容量的同時對業務效果也有影響，降級對業務的影響可近似用下面的曲線來表示，其中橫軸表示降級可騰出的容量，縱軸表示執行該降級後單位流量價值損失，橫軸和縱軸所圍成的區域表示降級後造成的損失。如某推薦類服務執行降級預案A後騰出了500QPS的容量，但由於服務裁剪，將造成損失係數爲3的單位流量價值損失；當執行裁剪更多服務的降級預案B後，可進一步將騰出的容量增加到1500，但損失係數也相應的增加到6。
圖5 降級造成的單位流量價值損失
從上圖可以看出隨着降級騰出容量的增加，造成的單位流量價值損失也會增加，所以我們需要權衡降級方案，選擇最佳的降級策略，獲取最佳收益。
在實際建設中，我們對同一個業務設計多種不同級別的降級方案。降級級別較低的方案，裁剪的步驟少，對業務效果影響較少，但能夠騰出的容量也較小，反之降級級別高的方案，裁剪的步驟多，對業務效果影響較大，但能夠處理更多的請求。
假設有N種可選降級預案，執行第i種降級預案歸一化到流量的總損失爲
故障機房未切走的損失和降級後健康機房的損失之和最小的降級預案就是我們要選取的最佳預案。
如何保證降級操作的安全性
所有的線上操作都存在一定的風險，用於止損的降級預案也不例外，我們歷史上也遇到過多次業務線執行預案操作導致整個服務故障的情況，止損操作反而加重了損失。
爲保證降級操作的安全性，降級必須分級執行，即嚴格按照單機房單服務器->單機房全部服務器->剩餘機房單服務器 ->剩餘機房全部服務器的順序進行分級操作，各分級之間通過檢查指標確認降級操作的安全，當檢測到降級異常時能迅速停止正在執行的降級動作。
整個降級預案的分級操作流程如下圖所示：
圖6 包含分級的降級過程
降級觸發：發生單機房故障時，配置的對應降級動作被自動觸發。
執行控制：執行控制部分包含降級過程的主要動作:降級執行、降級檢測。
降級執行：完成指定降級動作。爲保證安全性，降級預案實現爲分級操作，且備份修改前的配置文件以便快速回滾使用。出於時效性考慮，降級動作需要在較短時間內完成，例如10s內完成；
降級檢測：每執行一級降級操作後，都要有對應的檢測確保此次降級後健康機房不出現異常且降級已生效。
熔斷控制：爲保證降級的安全性，當某一降級失敗時，設置當前降級操作爲失敗，立刻停止當前正在執行的降級動作並通知人工介入。
如何更快的止損
降級提高了容量空間，那麼單機房故障發生時如何對降級操作和流量調度進行合理編排，實現更快速的止損呢？
簡單的編排方式是串行執行，即先降級、後切流。降級操作後，調度故障機房流量到健康機房，實現止損。
圖7 降級和流量調度串行執行
但如前文所屬，降級操作是一個複雜且耗時的操作流程，既包含降級操作本身的耗時、也包含分級操作帶來的等待耗時。一次完整的降級，很可能會持續到分鐘級甚至十分鐘級別，在降級操作完成前，故障機房帶來的損失沒有任何緩解。
我們可以以更快的方式來做這件事，即流量調度和降級並行執行。在降級執行完成前，儘量將故障機房的流量調度到健康機房，先保證一部分請求訪問正常，在降級結束健康機房容量增加後，繼續將故障機房的剩餘流量調度到健康機房，實現完整的止損。
併發執行時，降級和流量調度如何進行協同呢？我們設計了容量DB，該DB存儲當前服務各機房容量數據，通過容量DB協同服務降級和流量調度。降級和流量調度的協同可認爲是基於事件的協同，降級操作完成後，將服務降級後的容量更新到容量DB中；流量調度服務在並行執行過程中會週期性從容量DB中獲取最新的容量數據，根據最新的容量和當前的流量進行調度。
圖8 降級和流量調度併發執行
總 結本文介紹了我們在單機房故障自愈中服務降級的實踐，上述方案和措施爲容量不滿足N+1冗餘的場景提供了故障自愈能力，同時讓我們獲得了最佳收益，並保證了降級的安全性和時效性。作爲《單機房故障自愈》系列的重要一篇內容，服務降級爲我們在單機房故障自愈領域的繼續探索提供了參考。如果您對故障自愈有好的建議，也請不吝賜教。
關注公衆號回覆“單機房”瞭解更多~
閱讀推薦
運維實踐
智能運維架構 | 架構集成 | 網絡判障 | 監控數據採集 | 監控報警 | 網絡異常 | 分佈式監控系統 | 數據可視化 | 單機房故障自愈 | TSDB數據存儲 | 異常檢測 | 流量異常檢測 | 複雜異常檢測 | 報警風暴 | 實時計算 | 故障診斷 | 日誌監控 | 網絡監控可視化 | HBase實踐 | 多維度數據
運維產品
百度雲BCM | 企業級運維平臺 | 基礎設施管理引擎 | 運維知識庫 | 通告平臺 | 百度名字服務 | 業務部署 | 數據配送 | 集羣控制系統 | 外網監控 | 內網監控 | 部署變更 | 配置管理 | 站點監控
精品推薦
AIOps全解析 | AIOps中的四大金剛 | 智能運維 | AIOps時代 | 運維演進
↓↓ 點擊"閱讀原文" 【瞭解更多精彩內容】