攜程旅行網是國內領先的在線旅游服務公司，也是國內規模較大的互聯網公司之一。隨著近年來業務的迅猛增長，支撐網站的技術和系統的復雜性和規模也隨之呈跳躍性的攀升。要迎接網站規模和復雜性提升帶來的各種挑戰，運維部門首當其沖。運用新技術，新思維來應對各種出現的新問題是運維技術人員天天都要面對的工作。本文中將介紹我們如何應對新場景下的排障工作。
問題描述
當運維自動化程度提高后，對于自動化服務的請求數量不斷增長，業務規則和流程的復雜性日益加大。用戶對自動化服務越來越依賴，因此對服務標準的要求也在提高，尤其表現在對服務可靠性的高要求。而另一方面，開發周期短，外部依賴多，不可控因素多等原因又使得工具和系統的缺陷在所難免。因此，在出現故障后能夠快速定位問題，快速解決問題，把對用戶的影響降到最低，就成了一個直接關系到產品成敗的非功能性需求。
以攜程運維工作流平臺（攜程運維工作流平臺是一個運行攜程核心運維流程，如服務器，網絡，應用等上線/下線/變更等工作流的系統平臺）為例，一臺服務器的上線流程從提交請求到服務器交付需要控制在半小時之內，而流程由近十個環節，和近十個工具或系統交互，任何一個環節出現微小故障或者不穩定都可能造成流程中斷。因此，需要我們能盡早發現每個環節的問題，修復問題。
傳統策略和它的問題
傳統方式下，我們使用黑盒策略，只監控流程的外在表現。監控流程中的每個步驟，給流程的每個步驟設置SLA，一旦SLA超時，就發郵件提醒相關人員及流程組。告警郵件發出后，運維人員需要接收到告警，登錄系統，分析告警，定位診斷，修復故障。
上述策略存在明顯的問題：
1) ? ?時間延誤：運維人員不能及時響應告警，造成響應及處理時間不可控
2) ? ?人力成本：人工調查故障需要消耗大量的人力成本，而且經驗積累過程緩慢（因為同一個處理人員處理同一個問題的間隔時間可能比較長，不能快速利用上次的排障經驗）
3) ? ?有價值的歷史數據沒有保存，無法統計告警現狀及解決方案。如果有保存和分類的歷史數據，我們可以了解系統的主要故障區域有哪些，以便進行針對性的改良設計。
4) ? ?引入人為錯誤：人工處理過程還有可能引入人為錯誤
解決思路
為了全面掌握當前系統中故障的分布情況，我們先進行了第一步工作：建立一個排障系統對故障進行自動記錄和分類。我們在流程平臺中的關鍵環節進行埋點，將最能反映故障和異常的特征參數隨著故障警告一起輸送出來，在系統中根據這些特征參數對故障和人工分析的結果進行分類。
經過一段時間的人工處理，統計出如下報表：
從報表中，我們可以看到幾個結果：
有很大一部分是無需干預的。
告警數量雖然很多，但是類別卻不多，大量告警可以被診斷為同一問題，使用同樣的修復方式。
絕大部分的故障可以通過告警中帶有的特征參數進行自動分類或者利用簡單的邏輯進行自動分類 – 自動診斷問題是可行的。
根據告警落地后的分析報告，很清楚地可以看到自動診斷流程是可行的，并且可以節省大量人力成本，并且大幅縮短排障時間和消除人為錯誤。
故障自動診斷方案
既然所有的問題的答案最終都指向自動診斷，那么我們來看下自動診斷需要包含哪些功能才能解決我們的問題。
故障自動診斷流程需要做到如下幾點：
告警發出時立即響應
識別誤報或可自行修復的告警
自動處理誤報及無需干預的告警
對于復雜情況的告警進行預先診斷并返回結果
有了以上目標，接下來我們需要選擇合適的工具實現自動診斷流程。
StackStorm介紹
StackStorm （以下簡稱ST2）是時下非常流行的一個自動化引擎，擅長處理自動化流程，支持各種服務及工具的自動化與集成。可以輕松的實現故障診斷和自動修復。因此利用ST2來實現故障自動診斷和修復應該是非常不錯的選擇。
那么，ST2到底是什么，能做什么，為什么可以應用到故障智能診斷中。下面做簡單介紹。
ST2是什么
官方定義：
StackStorm is a platform for integration and automationacross services and tools. It ties together your existing infrastructure andapplication environment so you can more easily automate that environment. Ithas a particular focus on taking actions in response to events.
簡單來說：StackStorm是一個事件驅動的自動化引擎。
ST2優勢
攜程之前使用最多的工作流平臺是BMC的產品Remedy。Remedy同樣是一個使用范圍廣泛的自動化工作流引擎。和Remedy這種比較龐大的工作流平臺相比，ST2有以下優勢：
? 開源，StackStorm Exchange提供了各種各樣的Pack，只要進行簡單的Pack安裝后就可以使用。
? 對DevOPS友好，ST2的Action支持任何形式的編程語言，如：Python，Java等，用簡單的標記語言定義流程，如：yaml，簡單易上手。
? 活躍的用戶群，很多大公司（如：Netflix，AMAZON ）都在使用StackStorm
? 平臺，可以給我們提供非常有價值的參考。
? 更擅長自動化，故障診斷，自動修復等場景
? 相比Remedy復雜的集群部署配置，ST2的集群配置要簡單得多
ST2運行機制
ST2運行機制 (官方)
ST2運行機制（簡單理解）
Sensor接收或者監聽外部Events，觸發Triggers，映射到Rules，在Rules中判斷是否滿足Criteria，滿足則運行具體的Workflow
實施過程
對ST2有了初步了解以后，我們來看下ST2如何應用到故障自動診斷流程中。
ST2故障自動診斷流程實現
通過Sensor監聽吐到告警系統中的告警，通過不同的Rule將告警分發到不同的Workflow進行處理
告警系統中包含多個系統（如：ITSM，CMS，…）的告警，ST2的Sensor會定期拉取告警系統中的告警信息，進行初步處理后，分發到Rules，每個Rule會根據配置的Criteria，判斷是否符合觸發該Rule的條件，如果符合則執行Rule對應的Workflow，否則結束。
ST2故障自動診斷流程優勢
ST2故障自動診斷流程解決了以往排障遇到的問題，告警得到及時響應，同時自動化流程解放了人力，大部分誤報的請求被自動處理掉，對于無法自動處理的告警，也可以進行初步的分析，將分析結果以郵件等形式反饋給運維人員，節省人工檢查的時間。自動化流程也避免了人為錯誤的引入。
除此之外，利用ST2實現自動診斷流程也有它自身的優勢：
1) ? ?ST2通過統一的Sensor將告警預處理并分發到Rules，不同系統的Rule根據條件觸發自動診斷流程。不同系統的告警診斷互不干擾，Rules之間，Workflows之間相對獨立，可以很好的支持橫向擴展。
2) ? ?Pack共享，減少重復代碼
3) ? ?自動診斷流程可以靈活的定義流程中的Action，方便系統告警的擴展
4) ? ?告警處理過程被系統記錄，有利于后期查找分析
ST2故障自動診斷流程實例
ITSM告警自動診斷Workflow
ITSM告警自動診斷Workflow實例
成果和小結
正確的思路+正確的工具=預期的結果。有了ST2自動診斷流程之后，我們將告警的發出，記錄，診斷，報表各環節全部打通，形成閉環，成為一套完整的告警自動診斷解決方案。
通過ST2自動診斷流程，經過告警自動診斷，告警結果回寫到告警系統中，得出的報表前后對比數據如下：
ST2自動診斷前
ST2自動診斷后
經過對ST2實現故障自動診斷功能的初步嘗試，ST2初露鋒芒，給我們帶來的收益也顯而易見。
有了這第一階段的實踐和成果，我們有更多的信心和經驗來展望下一步：
? ?將更多告警自動診斷接入ST2
? ?緊接自動診斷，將故障自動修復流程也加入ST2
? ?針對經常發生的故障做進一步的根因分析
原文來自:攜程技術保障中心
