數人云實踐|SRE趕上金融老幹部，解決發佈協調&監控告警兩大難題

7月15日上海的《DevOps&SRE超越傳統運維之道》主題沙龍上，數人云工程師保珠從核心理念、金融行業ITSM特性、發佈協調、監控告警、總結定位等方面詳細地闡述了數人云在金融場景下的落地實踐。

今天主要跟你們分享數人云SRE的落地實踐，由於目標客戶主要是金融行業，因此基於ITSM特性，介紹實際場景中的發佈協調和監控告警。

SRE核心理念

SRE是谷歌十數年運維過程當中演練出來的模式，在實踐過程當中積累了不少經驗，跟傳統運維有一些區別。是創建在DevOps的思想上的運維方面具體實踐。

SRE崗位工做職責有：

• 應急相應

• 平常運維

• 工程研發

SRE跟傳統運維的工做職責相似，但在工做方式上有很大區別：
1）應急響應主要落實在對監控、應急事件的處理以及過後總結。

2）平常運維包括容量規劃、性能監控、並更管理。

3）工程研發方面跟傳統運維的區別在於參與研發事件、SLO制定和保障以及自動化，自動化運維是長期目標，也是熱點內容。

SRE的工做原則：
擁抱變化：不擔憂付出風險而拒絕改變，經過不斷的推演和演練發現並解決問題。

服務等級目標：將服務劃分等級分配給不一樣的運維。

減小雜事：節省更多的時間用於開發。

自動化&簡單化：開發的主要目的。

金融行業ITSM特性

金融行業在ITSM的特性主要是分級管理，工做模式上，運維和開發徹底隔離，但這是DevOps思想還沒有達成的表現。運維團隊規模是線性增加的，如上線一個系統時都會分配1—2個運維人員進行跟進。無論從網絡仍是資源分配上，他們的職責更多在應急事件處理和常規變動上。

證監會和銀監會有合規運維的要求，好比兩地三個數據中心，這是金融行業比較明顯的特性。

傳統模式和SRE的區別——
傳統模式：易招聘，傳統行業招聘的運維首先是會Shell，Python等腳本編寫，在自動化運維工具上會有新要求，過往經驗積累如曾解決的事故，應對的問題。

SRE：難招聘，相對新興的崗位，很難找到徹底匹配的人才；會有開發上的要求，強調自動化，包括在自動化工具裏作編程性的內容，團隊協做等等。

接下來分享SRE在兩個客戶實際場景的落地：某交易所、某商業銀行信用卡中心。

SRE平臺架構模型如上圖，資源供給層是基於數人云的PaaS平臺，以Docker容器化管理作資源調動，應用調度分別基於Mesos和Marathon，目前數人云也開源了名爲Swan（Mesos調度器，Github地址：https://github.com/Dataman-Cl... 歡迎Star&Fork）的應用調度系統，目標是把Marathon替換掉。然後是軟件技術架構層，對應公司裏的架構部門，包括採用RPC框架、緩存、消息中心選型等等。

主要分享的內容在DC SRE這一層。再往上包括產品線有TISRE，也有接近於用戶數使用的APP SRE，因此我的理解這是長期的建設過程。

實踐—發佈協調

發佈協調在平常的工做中應用不少，如應用上線、變動管理。在SRE指導下，某項目現場成立了相似於發佈協調的團隊。成立SRE團隊與金融行業系統上線特色有關：

• 金融行業裏系統較多，包括信貸、信審等等諸多應用，系統邏輯也比較複雜。開發測試環境如物理環境徹底隔離，和互聯網行業不一樣。互聯網行業，都是在線發佈，測試環境也許就是生產環境，採用灰度發佈或者藍綠髮布模式去作。

• 上線協調須要同時面對多個外包團隊，外包團隊人員相對不可控，致使溝通成本較高。

• 規模大的系統發佈上線週期長。

如何解決以上問題，達到發佈進入可控，下降發佈失敗率，縮短髮布時間週期？

上述問題，在SRE的思想中，首先要創建發佈協調團隊。目前SRE工程師只能自行培養。團隊推薦構成：項目經理、架構師、運維工程師、開發工程師。溝通方式以發佈上線會議爲主，不斷Check系統或者產品開展工做。

團隊的職責包括：審覈新產品和內部服務，確保預期的性能指標和非性能指標。根據發佈的任務進度，負責發佈過程當中技術相關問題，以及協調外包公司的開發進度等等。

最重要的是要作到發佈過程當中的守門員，系統是否上線要由發佈協調團隊決定。

團隊在整個服務生命週期過程當中，不一樣階段，都要進行會議審覈才能繼續開展工做。會議根據發佈的檢查列表包括三個方面：架構與依賴、容量規劃、發佈計劃。

在架構與依賴方面的邏輯架構，部署架構，包括請求數據流的順序，檢查負載均衡，日誌規範着重配合監控方面的要求。同時檢查第三方監控調用時是否進行測試管理等等。

容量規劃主要是根據壓縮報告作容量預估，以及峯值，好比微信活動比較多，因此會根據預估峯值的公司預算出來須要的資源，再落實到容器上，制定詳細計劃保障發佈的成功率。

制定發佈計劃，確保成功。

在SRE的指導中，每件事都要落實到工具當中，由工具去檢查每一個事項是否落實到位。當時作了發佈平臺，包括PipeLine、Jenkins，經過其調用負載均衡上的配置F5和配置中心，以及服務註冊中心的機制。全部的發佈事項基於容器雲平臺，功能模塊包括變動管理、發佈管理、流程模板及發佈過程監控。

上圖是發佈平臺項目大盤圖，能夠看到項目在發佈流程中執行狀況——成功率和失敗率。沒有發佈平臺前，整個上線過程管理人員不能實時看到發佈具體狀況，是卡在網絡仍是某一個服務上，所以進度不可控。

有了這樣的運維大盤後，整個發佈過程能進行可視化跟蹤，關鍵節點須要人工審覈。

具體的發佈步驟：

• 第一，檢查F5裏面的配置

• 第二，人工檢查

• 第三，上傳程序包，配置項管理

• 最後，重啓容器再進行人工檢查

總體過程都體現了SRE思想，發佈平臺的每一個步驟都可經過界面配置完成，中間關鍵點由人工參與，目的是保障產品上線的成功率，避免在上線過程當中手動配置產生問題，致使回滾事件發生。

有了發佈協調團隊後，上線的成功率、自動化程度和發佈效率明顯提升，減小了人肉操做落實在Jenkins、PipeLine的配置項上，下降錯誤發生概率。

實踐—監控告警

監控做爲一個垂直系統，在數人云的產品體系中舉足輕重。監控的重要性深有體會，咱們在某金融公司SRE團隊中有1—2名監控專員，專員主要職責是維護監控系統。一個是甲方內部人員，另外一個是數人云的同事。

監控主要解決的問題：
首先要及時發現，時效性很重要，所以需創建監控系統。

爲何會出現故障，要多作事故總結以及後續的故障跟蹤。

上圖爲監控系統架構圖，基於Prometheus的時序數據庫，紅線爲監控的數據流向，因是Mesos框架，因此左邊會看到Mesos運算節點上的監控項。經過容器化的Cadvisor組件收集主機和該主機全部容器的CPU和內存以及磁盤信息。告警部分使用Prometheus的Altermanager組件，支持Webhook方式，經過短信、郵件形式告警。爲了過後總結，需將一些告警事件存在數據庫中。

綠線主要體如今日誌收集和關鍵字告警，日誌收集經過容器化的Logstash組件，首先收集容器內部的中間件，如Tomcat等Web中間件的日誌，也能收集應用日誌，根據須要會把一些信息丟到Kafka裏面，經過大數據平臺作在線日誌分析。

日誌關鍵字告警是經過自研組件在日誌傳輸過程當中過濾關鍵字進行事件告警。

容器服務的健康情況經過Marathon的事件Pushgateway推到Prometheus，最後在前臺以本身開發的UI查看監控信息和告警上的配置。爲方便使用Prometheus的查詢作統一封裝，減小API使用複雜度。

在SRE體系裏很明確提到了監控的4大黃金指標：延遲、流量、錯誤、飽和度：

• 延遲：監控服務的API以及URL的訪問時間，直接配置某一個服務的URL，後臺不斷去訪問，包括訪問時間的預值，超過期間發出告警。

• 流量：負載均衡請求的鏈接數。

• 錯誤：監控HTTP請求返回碼和日誌中異常關鍵字。

• 飽和度：根據不一樣的系統，如內存資源性系統監控內存使用率，IO讀寫使用比較高，監控資源IO狀況。

以上指標要在運維的過程當中不斷優化，如一些告警多是網絡緣由進而產生其餘問題，如網絡交換機出現問題，直接掛掉平臺的Marathon組件，應用上很明顯是第三方服務調用，接連會產生不少問題，要把共性問題聚合，減小誤告警次數。但減小誤告警也可能會把有效告警卡掉，也值得思考。

故障跟蹤和過後總結相似，人工操做會延長恢復時間，告警發生時通常由一我的處理，隨着時間延長而升級策略，如超過半個小時會逐級上報調用更多的資源處理故障。在故障跟蹤上解決線上問題爲主，處女座強迫症爲輔，作好總結Root Cause更好的反饋到自動化工具上。

事故總結很是重要，解決不意味着結束，要追溯緣由，如交換機重啓，致使Marathon的一些問題，總結後發現，最好的解決辦法是交換機重啓時通知運維，停掉相關組件，交換機恢復後，再啓動，如此不影響業務的實際運行。

要從失敗中學習，把告警的事件作記錄創建知識庫，發生問題時方便檢索，快速找到解決方案，要總結解決某個事故時如何更快發現問題所在，創建反饋機制，在SRE監控過程當中，不斷跟產品作實時反饋，包括鏈接池的使用狀況等，鼓勵主動測試，平時運維不會發生的事，儘量想辦法去看結果。

目標定位

SRE目標定位內容不少，在各個行業落地時不盡相同，因此要基於現實，擁抱變化，爲了更好應對事故，堅持作推演和演練，在事故總結方面對產品作建言，故此在工具的研發上也會有決策權。