給大家分享的主題是基於 StackStorm 的攜程運維自動化平臺。
今年5月，勒索病毒爆發，席捲全球，影響了政府部門、醫療機構、公共交通、學校、企業等等，給全世界帶來了巨大損失。
如果有投資眼光的人，遇到這個事情，考慮的可能是購買比特幣。而作為運維工程師，考慮的只是如何防止病毒影響自己公司的業務。相信很多運維同行，都參與到了應對勒索病毒的戰役中。
關於這個病毒，雖然傳播廣，看起來威力巨大，但是也有很多應對措施。比如關閉445埠防止病毒傳播，或者內網建立開關域名防止病毒執行。當然，這些只是 workaround 的方案，根本的，還是要及時更新伺服器的安全補丁。
如果只有幾臺、幾十臺伺服器，補丁更新很簡單，登陸上去點下安裝或者敲一條命令就可以搞定，當你有成千上萬臺伺服器的時候靠人工是不可能的，如果一下子發一條命令下去到所有伺服器也不合適，可能對業務造成巨大影響。
那麼該如何自動給上萬臺伺服器打補丁呢？
我們先看一下，一臺伺服器上怎麼操作打補丁。
上圖是個比較簡單的操作流程。首先，檢查伺服器是否已經安裝了補丁，如果已經安裝流程就結束。如果還沒有安裝，先將伺服器拉出叢集脫離生產，然後安裝補丁，重啟伺服器讓補丁生效。
在拉入叢集之前，可能還需要給應用點火，比如讓應用建快取，讓應用恢復到正常狀態再接入生產流量。這其中還有一些複雜問題，比如一個叢集拉出部分伺服器後，剩餘伺服器可能扛不住，要考慮叢集可用性。
這樣一個給一臺伺服器打補丁的過程，如果要實現自動化，就要完成兩方面的任務：
實現了一臺伺服器自動打補丁後，再從1擴充套件到1000、10000，給成千上萬臺伺服器打補丁，要做的一件事就是灰度、灰度、灰度，重要的事情說三遍。
不管你操作多麼熟練，技術多麼高超，對自己開發的工具多麼自信，在做生產大批量運維操作的時候，都要謹慎再謹慎，而分批灰度是做到謹慎的很好的方法，可以大大減小對生產的影響，提高網站可用性。
綜合上述對實現上萬臺伺服器自動打補丁的需求，我們搭建了一套自動化運維平臺，包括三個模組：
-
1、使用 SaltStack 實現遠端控制；
-
2、使用 StackStorm 實現操作流程；
-
3、我們自己開發的工具 JOBS 實現分批灰度。
而這樣一套系統，不只是可以完成打補丁這樣一個功能，基本可以覆蓋各種日常運維操作自動化需求，所以拿出來和大家分享。
下面將從這三方面進行具體介紹。
1. 遠端控制
SaltStack 是一個開源的遠端管理平臺，可以管理各種作業系統的伺服器，主要有 minion 和 master 兩部分。minion 安裝在要管理的伺服器上，啟動後與 master 建立長連線，master 下發任務給 minion，minion 執行完成後，將任務結果返回給 master。
類似的遠端管理工具還有 ansible、chef、puppet，大家可以根據實際應用場景選擇。我去年在 GOPS 北京站分享過攜程在使用 SaltStack 的一些經驗，大家可以參考，這裡就不再贅述。
2. 操作流程
我們從運維發展的過程來看，首先是傳統運維，主要靠手工操作。比如上線一臺伺服器，登陸伺服器按照操作文件一步一步操作，更高階一點，把配置命令寫到指令碼里，執行一個或多個指令碼完成配置。
有什麼缺點呢？首先，人每天重複這樣的工作，很累，又沒有體現價值，交付效率低，疲勞時還容易出錯，忘記某些配置。
使用指令碼呢，容易相同功能重複開發，很多指令碼不專門記錄日誌，查詢歷史操作比較困難。使用指令碼進行運維操作，發生了故障，由於沒有統一的運維操作日誌，無法及時瞭解誰做了什麼。
隨著時間的發展，運維發展到更高階的 DevOps 時代，我們也正處於這個時代。這個時代有一個明顯的特徵，就是各種各樣開源工具的使用，同時自己會開發很多工具。工具帶來了效率的提升，大大加速了運維自動化的程式。
有這麼多的工具可以使用，也會存在一些問題。比如下面這些問題：
-
做一個複雜變更要操作很多工具
-
不同指令碼或工具的程式碼裡，相同操作重複造輪子
-
對別人開發的指令碼或工具，不清楚具體操作邏輯
-
沒有統一的運維操作日誌
針對上面這些問題，我們考慮使用基於事件驅動的開源自動化運維平臺 StackStorm。
你有各種各樣的工具，會提供很多操作的 api，你把這些 api 呼叫實現成 action 放在 StackStorm 上，然後可以把這些 action 組合成複雜的 workflow 實現不同的任務。
StackStorm 可以實現操作外掛化、操作邏輯視覺化、運維日誌統一化。
StackStorm 提供了 Web 介面，也提供了 API。你把各種工具的操作放在裡面，選中一個操作，填入引數，就可以點選執行。
使用 StackStorm 具體能做一些什麼事情呢？
我們日常有很多不同的變更操作，但是經常會重複做一些相同的事情，比如安裝軟體、重啟服務、拉入拉出叢集等。如果把不同變更操作過程進行拆分，就會拆出這樣一個個小的運維原子操作。
反過來，我們可以把這些運維原子操作進行組合，像樂高積木可以拼出各種各樣的模型，我可以將原子操作組合成各種各樣的變更流程。這樣相同的操作只需要實現一次，就可以重複使用，避免了重複造輪子，大大提高了開發效率。
在故障處理方面，我們來看一個常規的 oncall case。
比如凌晨2點，出現了一個訂單下跌的告警，NOC 開啟電話會議，將相關工程師 call 進來，工程師接到電話後迷迷糊糊地爬起來，問出現了什麼問題，NOC 需要陳述一遍，然後工程師匆匆忙忙開啟電腦，VPN 登陸到內網檢視相關監控指標，利用自己的經驗進行故障排查，花了很多時間終於定位到故障，然後進行修復操作，最後故障恢復。
這樣的故障處理過程，存在什麼問題呢？
1、修復時間長
2、半夜處理故障，操作容易出錯，而且影響第二天上班
3、隨著業務增長，報警增多，無法及時處理
4、導致網站可用性下降
如果使用 StackStorm，故障處理的過程是怎麼樣的呢？StackStorm 有 webhook 可以監聽報警，當一個報警傳送給 StackStorm 後，StackStorm 可以先進行一些分析，基於專家經驗或者基於機器學習，分析完成之後，判斷這個報警是否可以自動處理，如果可以就執行故障修復操作，故障恢復。
如果自己無法處理，會收集故障異常內容，以及初步分析結果，傳送給相應的工程師，為工程師節省了一些收集資訊和排查的時間，工程師可以快速進行故障修復。對於一些常規的頻繁發生的故障，如果已經有一些固定的處理方法，完全可以交給 StackStorm 自動處理。
StackStorm 可以與 ChatOps 結合，進行日常運維操作，比如你正在參加 GOPS，StackStorm 將報警和初步分析發給你，你通過手機在 Chat Room 下發指令給 StackStorm，快速進行故障修復。
瞭解了 StackStorm 的一些功能，再來看看 StackStorm 的部署架構。圖中黃色的部分是 StackStorm 的主要模組，包括認證、api、規則引擎、worker、chatops、webui 等等，mistral 作為 workflow 引擎，以 postgresql 作為資料庫，mongodb 儲存 action 定義、日誌，rabbitmq 是所有任務的訊息佇列。這是一個高可用的架構，每一臺伺服器上都執行著 worker 和 mistral。
這是 StackStorm 的資料流圖，StackStorm 將 chat message 對應到動作是通過這裡的規則引擎，上面提到的運維原子操作組合成工作流，工作流的解析由 mistral 來完成，每一個具體 action 的執行由 worker 完成。
StackStorm 有下面三大好處：
-
提高了自動化開發效率
-
操作邏輯視覺化
-
運維任何操作都有明細的記錄
3. 分批灰度
雖然 StackStorm 有很多優點，但是當你想對上萬臺伺服器做一個操作時，你一定不會希望自己手動分批次，手動輸入到 StackStorm 裡面點選執行，執行如果出錯，還要去看 StackStorm 不便於閱讀的輸出及報錯堆疊。
你想要的，是建一個任務，指定一批伺服器，在某個時間，執行某個任務，最後給出一個執行結果統計。所以基於大批量伺服器自動操作需求，我們開發了稱作 Jobs 的工具。
主要實現三個目標：
-
第一是可以根據選擇的分批策略自動分批，比如按伺服器比例1%、5%、10%這樣分批。
-
第二是操作是外掛化的，操作執行程式碼不在 Jobs 中實現，這裡就要結合 StackStorm，Jobs 將命令下發給 StackStorm，具體的執行邏輯在 StackStorm 中實現。
-
最後是可以進行結果統計，多少成功了，多少失敗了，在任務詳情頁可以很明確地看到。
上圖就是 JOBS 系統的新建任務介面，有分批策略、篩選伺服器等等。
這個是 Jobs 任務詳情頁。左邊是任務資訊，右邊是具體的分批的情況。分批執行任務，即使任務執行造成了故障，可以及時發現及時停止，控制影響範圍。
4. 總結
如果想搭建一套運維自動化的平臺，首先部署一套遠端管理框架，可以是 saltstack 或者 ansible 等，然後在 StackStorm 上實現日常的運維原子操作，再根據具體的操作需求，將原子操作組合成工作流，最後，對於大批量伺服器運維任務，可以考慮開發一套具有分批灰度功能的系統，完成自動化操作。