大數據中如何解決發布協調及監控告警兩大難題

本篇文章為大家展示了大數據中如何解決發布協調及監控告警兩大難題，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

今天主要跟大家分享數人云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-Cloud/swan 歡迎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目標定位內容很多，在各個行業落地時不盡相同，所以要基于現實，擁抱變化，為了更好應對事故，堅持做推演和演練，在事故總結方面對產品做建言，故此在工具的研發上也會有決策權。

上述內容就是大數據中如何解決發布協調及監控告警兩大難題，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。