故障自愈機器人，保你安心好睡眠

本文做者：AIOps智能運維

乾貨概覽

 

在大型互聯網公司中，單機房故障由於其故障時間長、影響範圍大，一直是互聯網公司運維人員的心頭之痛。在傳統的運維方式中，因爲故障感知判斷、流量調度決策的複雜性，一般須要人工止損，但人工處理的時效性會影響服務的恢復速度，同時人的不可靠性也可能致使問題擴大。

 

爲了解決這類問題，咱們針對百度內外部網絡環境建設了基於智能流量調度的單機房故障自愈能力。結合外網運營商鏈路監測、內網鏈路質量監測與業務指標監控構建了全方位故障發現能力，基於百度統一前端(BFE)與百度名字服務(BNS)實現了智能流量調度與自動止損能力。同時，基於實時容量與實時流量調度自動止損策略與管控風險，實現了任意單機房故障時業務都可快速自愈的效果。當前此解決方案已覆蓋搜索、廣告、信息流、貼吧、地圖等衆多核心產品的單機房故障自愈場景。

 

單機房故障頻發影響業務可用性

 

回顧近2年來各大互聯網公司被披露的故障事件，單機房故障層出不窮。例如：

 

2015年6月某公司雲服務香港IDC節點電力故障崩潰12小時

 

2016年5月某公司杭州電信接入故障，服務中斷小時級別

 

2017年1月某業務天津機房故障，數小時沒法提供服務

 

2017年6月北京某處機房掉電，多家互聯網公司受影響

 

單機房故障頻繁影響業務的可用性而且會給公司帶來直接或間接的損失。直接損失包括訪問流量丟失、商業收入降低、用戶體驗受損、打破服務等級協議（SLA）形成的商業賠付等，間接損失包括用戶信任度降低、給競品佔領市場機會等。

 

單機房故障誘因衆多不可避免

 

單機房故障誘因衆多，詳細覆盤若干單機房故障發現故障誘因大體能夠分爲四類：

 

基礎設施故障：物理機房故障、網絡鏈路擁塞、流量轉發基礎設施故障等

 

程序缺陷：程序隱藏bug、程序性能嚴重退化等

 

變動故障：測試不充分的程序、配置、數據變動，人工臨時介入的誤操做等

 

依賴服務故障：第三方服務故障例如通用的認證服務、支付服務、存儲服務、計算服務故障等

 

單機房故障止損可靠性與效率急需提高

 

人工處理場景下，運維人員一般選擇7*24小時值班，接收大量的報警，隨時準備在緊急狀況下進行響應、決策、操做一系列故障止損動做，儘可能挽回服務損失，下降故障影響。

 

但上述解決方案會面臨以下問題：

 

響應可能不夠迅速：例如夜間報警

 

決策可能不夠精確：例如新手OP經驗欠缺，誤決策

 

操做可能出現失誤：例如止損命令錯誤輸入

 

「機器人」處理場景下，單機房故障自愈程序可獨立完成故障感知、決策、執行的完整故障處理過程，並及時向運維人員同步故障處理狀態。運維人員的職責由處理轉向管理，最終運維人員在低壓力值班中保證服務穩定運行。

 

單機房故障自愈解決方案概述

 

百度AIOps框架中，單機房故障自愈解決方案構建在運維知識庫、運維開發框架、運維策略框架三個核心能力之上。具體過程爲自愈程序蒐集分散的運維對象狀態數據，自動感知異常後進行決策，得出基於動態編排規劃的止損操做，並經過標準化運維操做接口執行。該解決方案策略和架構解耦，而且託管到高可用的自動化運維平臺之上，實現了業務在任意單個機房故障狀況下皆可自愈的效果。

 

截至目前該方案已覆蓋百度大多數核心產品，止損效率較人工處理提高60%以上。典型案例：

 

在8月28日某產品在單機房故障發生後1min55s完成止損。

 

在後續文章中咱們會繼續介紹單機房故障自愈的更多詳細內容，敬請期待！

單機房故障容災能力的建設

 

在容災能力建設中有哪些常見問題？

 

如何證實服務已經具有單機房容災能力？

單機房故障人工止損方法

 

人工止損時如何感知服務故障？

 

人工止損時如何收集故障信息？

 

人工止損時如何進行流量調度？

單機房故障機器人止損方法

 

如何設計單機房故障自愈總體方案？

 

如何下降流量調度風險？

 

如何應對不一樣業務流量調度策略和平臺的差別？

 

原文連接地址：https://developer.baidu.com/topic/show/290067