概述
每年的雙十一對阿裡的網絡都是一次嚴峻的考驗。在雙十一當天，阿裡的網絡必須承載來自于世界各地數以億計的使用者所帶來的巨大流量，任何故障的影響力都會被成倍放大。盡管大家做了很多努力盡量去避免故障的發生，但是故障仍然還是會發生，尤如阿裡現今的大體量。這個時候，快速可靠的的故障恢複機制就尤為關鍵了。随着網絡體量的急劇擴大，以及架構的多樣化發展，通過人工手段去恢複故障已經不能滿足業務對網絡高可用性、高可靠性的要求了。在這個過程中，自動化的故障恢複應運而生。
我們處理故障的主要流程是：監控采集->故障發現->根因定位->故障恢複
圖1 自動恢複整體流程
豐富的采集
目前每天的資料采集量接近萬億級的水準，采集的類型包括日志、SNMP采集（路由器交換機性能名額采集）、AliPing采集（内網品質采集）、AliInternet采集（網際網路品質采集）、Netflow采集（流資料采集）等。
SNMP采集
網絡裝置跟伺服器不一樣，需要通過拉取的方式将裝置的metrics抓取出來。我們采取的政策是劃分采集域進行資料的拉取，然後集中計算。
各個采集域之間做好備份：
圖2 SNMP&Syslog采集
AliPing采集
除了對網絡裝置metric的監控，同時要基于網絡丢包和延時，更快速和準确地判斷網絡故障。我們模拟業務網絡特征，建構ICMP/TCP Ping探測的封包，對全網所有實體伺服器進行探測。
圖3 Aliping(内網網絡品質)整體架構
AliInternet采集
網際網路是阿裡網絡的延伸，網際網路的品質不是由誰統一控制的，任一節點都有故障風險，完善的監控以及快速響應就顯得尤為關鍵了。從全球IP位址庫為每個國家，每個營運商動态挑選存活IP進行探測，每分鐘千萬級IP進行探測。
圖4 AliInternet(網際網路網網絡品質)整體架構
其他
除了上面所述的資料以外，我們還采集了全網路由器的Netflow資料，LVS VIP流量資料，Anat session日志等。
靈活的告警（故障發現）
- 基礎事件*
我們通過實時流計算，将采集到的資料轉換為一個個異常的事件，比如一次端口中斷、協定中斷、闆卡離線、延遲超過基線等。在基礎事件的生成過程中我們主要采用了Spark Streaming的技術。
為什麼要采用Spark呢？
- 線上和離線的混合計算
- 非常友善整合外部資料源
- 高性能和易用性
- 機器學習和圖計算
- 可以和目前的HBase、MR等複用Yarn叢集資源
在兩年多以前我們開始使用Spark的時候，集團沒有完善的Spark任務管理平台。我們開發了RCS平台，RCS平台主要幫我們解決了如下幾個問題：
- 代碼或程式Jar管理
- 運作期參數管理
- 排程Spark的Yarn叢集管理
- 送出Spark任務的支援
- Spark任務監控和報警管理
我們通過內建Apache Zeppelin實作了Spark任務的管理：
圖5 基于Zeppelin的單叢集管理
考慮到在出現惡性故障時，叢集可能不穩定。但是故障發現系統要確定高可用性，我們設計了多叢集容災遷移的功能，以確定故障時任務能夠在叢集間遷移。
圖6 基于Zeppelin的多叢集管理
CEP複雜事件引擎
在産生一個個基礎異常事件以後，就是如何配置合适的規則，生成正确的告警。在這裡我們采用了CEP引擎Siddhi，這樣就大大加強了配置的靈活性。
比如我們可以配置如下的告警：
閥值比例(流量大于70%)
發生頻率（端口Down一分鐘十次）
聚合閥值（鍊路組25%鍊路中斷，同一叢集20%NC Ping失敗）
條件組合（流量超過70%并且出現丢包）
圖7 整體的告警流程
告警收斂
在生成告警以後，我們又基于拓撲對告警事件進行了收斂，以確定在故障場景下能夠精準地定位主要的告警。我們收斂的過程是通過在一個連通子圖内基于PageRank對告警的裝置和事件進行打分，打分最高的裝置和事件被認定為故障主要告警。
圖8 告警收斂
故障定位&自動恢複
在确定主要告警以後，我們就需要針對不同的告警定制不同的分析政策和故障恢複政策。我們提供一個平台，讓營運的同學送出腳本，更全面、靈活的覆寫到所有的告警場景。
這是我們故障恢複的整體運作流程：
圖9 故障恢複的流程
舉一個例子，這是外圍出現營運商的重大故障時：
圖10 營運商故障自動恢複
總結
在過去的兩年多中，我們從監控的全面性做起，逐漸對阿裡網絡形成了一個立體的監控，并且通過告警的自定義和收斂，讓故障告警更加精煉、準确。目前網絡告警已經有47%通過系統自動化完成，後續這一比例會逐漸提高。我們很高興能夠看到業務的營運模式從救火隊員逐漸邁向智能化的領域。後續我們希望能夠逐漸把這個比例提高到90%以上，并且進一步地減少故障的發生和縮短故障的恢複時間。