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

站在用戶的角度思考問題，與客戶深入溝通，找到雙湖網(wǎng)站設(shè)計與雙湖網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗，讓設(shè)計與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個性化、用戶體驗好的作品，建站類型包括：網(wǎng)站建設(shè)、成都做網(wǎng)站、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣、域名注冊、雅安服務(wù)器托管、企業(yè)郵箱。業(yè)務(wù)覆蓋雙湖地區(qū)。

今天主要跟大家分享數(shù)人云SRE的落地實踐，因為目標客戶主要是金融行業(yè)，所以基于ITSM特性，介紹實際場景中的發(fā)布協(xié)調(diào)和監(jiān)控告警。

SRE核心理念

SRE是谷歌十數(shù)年運維過程中演練出來的模式，在實踐過程中積累了很多經(jīng)驗，跟傳統(tǒng)運維有一些區(qū)別。是建立在DevOps的思想上的運維方面具體實踐。

SRE崗位工作職責有：

• 應急相應

• 日常運維

• 工程研發(fā)

SRE跟傳統(tǒng)運維的工作職責類似，但在工作方式上有很大區(qū)別： 1）應急響應主要落實在對監(jiān)控、應急事件的處理以及事后總結(jié)。

2）日常運維包括容量規(guī)劃、性能監(jiān)控、并更管理。

3）工程研發(fā)方面跟傳統(tǒng)運維的區(qū)別在于參與研發(fā)事件、SLO制定和保障以及自動化，自動化運維是長期目標，也是熱點內(nèi)容。

SRE的工作原則： 擁抱變化：不擔心付出風險而拒絕改變，通過不斷的推演和演練發(fā)現(xiàn)并解決問題。

服務(wù)等級目標：將服務(wù)劃分等級分配給不同的運維。

減少瑣事：節(jié)省更多的時間用于開發(fā)。

自動化&簡單化：開發(fā)的主要目的。

金融行業(yè)ITSM特性

金融行業(yè)在ITSM的特性主要是分級管理，工作模式上，運維和開發(fā)完全隔離，但這是DevOps思想尚未達成的表現(xiàn)。運維團隊規(guī)模是線性增長的，如上線一個系統(tǒng)時都會分配1—2個運維人員進行跟進。不管從網(wǎng)絡(luò)還是資源分配上，他們的職責更多在應急事件處理和常規(guī)變更上。

證監(jiān)會和銀監(jiān)會有合規(guī)運維的要求，比如兩地三個數(shù)據(jù)中心，這是金融行業(yè)比較明顯的特性。

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

SRE：難招聘，相對新興的崗位，很難找到完全匹配的人才；會有開發(fā)上的要求，強調(diào)自動化，包括在自動化工具里做編程性的內(nèi)容，團隊協(xié)作等等。接下來分享SRE在兩個客戶實際場景的落地：某交易所、某商業(yè)銀行信用卡中心。

SRE平臺架構(gòu)模型如上圖，資源供給層是基于數(shù)人云的PaaS平臺，以Docker容器化管理做資源調(diào)動，應用調(diào)度分別基于Mesos和Marathon，目前數(shù)人云也開源了名為Swan（Mesos調(diào)度器，Github地址：https://github.com/Dataman-Cloud/swan 歡迎Star&Fork）的應用調(diào)度系統(tǒng)，目標是把Marathon替換掉。而后是軟件技術(shù)架構(gòu)層，對應公司里的架構(gòu)部門，包括采用RPC框架、緩存、消息中心選型等等。

主要分享的內(nèi)容在DC SRE這一層。再往上包括產(chǎn)品線有TISRE，也有接近于用戶數(shù)使用的APP SRE，所以個人理解這是長期的建設(shè)過程。

實踐—發(fā)布協(xié)調(diào)

發(fā)布協(xié)調(diào)在日常的工作中應用很多，如應用上線、變更管理。在SRE指導下，某項目現(xiàn)場成立了類似于發(fā)布協(xié)調(diào)的團隊。成立SRE團隊與金融行業(yè)系統(tǒng)上線特點有關(guān)：

• 金融行業(yè)里系統(tǒng)較多，包括信貸、信審等等諸多應用，系統(tǒng)邏輯也比較復雜。開發(fā)測試環(huán)境如物理環(huán)境完全隔離，和互聯(lián)網(wǎng)行業(yè)不同?；ヂ?lián)網(wǎng)行業(yè)，都是在線發(fā)布，測試環(huán)境也許就是生產(chǎn)環(huán)境，采用灰度發(fā)布或者藍綠發(fā)布模式去做。

• 上線協(xié)調(diào)需要同時面對多個外包團隊，外包團隊人員相對不可控，導致溝通成本較高。

• 規(guī)模大的系統(tǒng)發(fā)布上線周期長。

如何解決以上問題，達到發(fā)布進入可控，降低發(fā)布失敗率，縮短發(fā)布時間周期？

上述問題，在SRE的思想中，首先要建立發(fā)布協(xié)調(diào)團隊。目前SRE工程師只能自行培養(yǎng)。團隊推薦構(gòu)成：項目經(jīng)理、架構(gòu)師、運維工程師、開發(fā)工程師。溝通方式以發(fā)布上線會議為主，不斷Check系統(tǒng)或者產(chǎn)品開展工作。

團隊的職責包括：審核新產(chǎn)品和內(nèi)部服務(wù)，確保預期的性能指標和非性能指標。根據(jù)發(fā)布的任務(wù)進度，負責發(fā)布過程中技術(shù)相關(guān)問題，以及協(xié)調(diào)外包公司的開發(fā)進度等等。

最重要的是要做到發(fā)布過程中的守門員，系統(tǒng)是否上線要由發(fā)布協(xié)調(diào)團隊決定。

團隊在整個服務(wù)生命周期過程中，不同階段，都要進行會議審核才能繼續(xù)開展工作。會議根據(jù)發(fā)布的檢查列表包括三個方面：架構(gòu)與依賴、容量規(guī)劃、發(fā)布計劃。

在架構(gòu)與依賴方面的邏輯架構(gòu)，部署架構(gòu)，包括請求數(shù)據(jù)流的順序，檢查負載均衡，日志規(guī)范著重配合監(jiān)控方面的要求。同時檢查第三方監(jiān)控調(diào)用時是否進行測試管理等等。

容量規(guī)劃主要是根據(jù)壓縮報告做容量預估，以及峰值，比如微信活動比較多，所以會根據(jù)預估峰值的公司預算出來需要的資源，再落實到容器上，制定詳細計劃保障發(fā)布的成功率。

制定發(fā)布計劃，確保成功。

在SRE的指導中，每件事都要落實到工具當中，由工具去檢查每個事項是否落實到位。當時做了發(fā)布平臺，包括PipeLine、Jenkins，通過其調(diào)用負載均衡上的配置F5和配置中心，以及服務(wù)注冊中心的機制。所有的發(fā)布事項基于容器云平臺，功能模塊包括變更管理、發(fā)布管理、流程模板及發(fā)布過程監(jiān)控。

上圖是發(fā)布平臺項目大盤圖，可以看到項目在發(fā)布流程中執(zhí)行情況——成功率和失敗率。沒有發(fā)布平臺前，整個上線過程管理人員不能實時看到發(fā)布具體情況，是卡在網(wǎng)絡(luò)還是某一個服務(wù)上，因此進度不可控。

有了這樣的運維大盤后，整個發(fā)布過程能進行可視化跟蹤，關(guān)鍵節(jié)點需要人工審核。

具體的發(fā)布步驟：

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

• 第二，人工檢查

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

• 最后，重啟容器再進行人工檢查

整體過程都體現(xiàn)了SRE思想，發(fā)布平臺的每個步驟均可通過界面配置完成，中間關(guān)鍵點由人工參與，目的是保障產(chǎn)品上線的成功率，避免在上線過程中手動配置產(chǎn)生問題，導致回滾事件發(fā)生。

有了發(fā)布協(xié)調(diào)團隊后，上線的成功率、自動化程度和發(fā)布效率明顯提高，減少了人肉操作落實在Jenkins、PipeLine的配置項上，降低錯誤發(fā)生幾率。

實踐—監(jiān)控告警

監(jiān)控作為一個垂直系統(tǒng)，在數(shù)人云的產(chǎn)品體系中舉足輕重。監(jiān)控的重要性深有體會，我們在某金融公司SRE團隊中有1—2名監(jiān)控專員，專員主要職責是維護監(jiān)控系統(tǒng)。一個是甲方內(nèi)部人員，另一個是數(shù)人云的同事。

監(jiān)控主要解決的問題： 首先要及時發(fā)現(xiàn)，時效性很重要，因此需建立監(jiān)控系統(tǒng)。

為什么會出現(xiàn)故障，要多做事故總結(jié)以及后續(xù)的故障跟蹤。

上圖為監(jiān)控系統(tǒng)架構(gòu)圖，基于Prometheus的時序數(shù)據(jù)庫，紅線為監(jiān)控的數(shù)據(jù)流向，因是Mesos框架，所以左邊會看到Mesos運算節(jié)點上的監(jiān)控項。通過容器化的Cadvisor組件收集主機和該主機所有容器的CPU和內(nèi)存以及磁盤信息。告警部分使用Prometheus的Altermanager組件，支持Webhook方式，通過短信、郵件形式告警。為了事后總結(jié)，需將一些告警事件存在數(shù)據(jù)庫中。

綠線主要體現(xiàn)在日志收集和關(guān)鍵字告警，日志收集通過容器化的Logstash組件，首先收集容器內(nèi)部的中間件，如Tomcat等Web中間件的日志，也能收集應用日志，根據(jù)需要會把一些信息丟到Kafka里面，通過大數(shù)據(jù)平臺做在線日志分析。

日志關(guān)鍵字告警是通過自研組件在日志傳輸過程中過濾關(guān)鍵字進行事件告警。

容器服務(wù)的健康狀況通過Marathon的事件Pushgateway推到Prometheus，最后在前臺以自己開發(fā)的UI查看監(jiān)控信息和告警上的配置。為方便使用Prometheus的查詢做統(tǒng)一封裝，減少API使用復雜度。

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

• 延遲：監(jiān)控服務(wù)的API以及URL的訪問時間，直接配置某一個服務(wù)的URL，后臺不斷去訪問，包括訪問時間的預值，超過時間發(fā)出告警。

• 流量：負載均衡請求的連接數(shù)。

• 錯誤：監(jiān)控HTTP請求返回碼和日志中異常關(guān)鍵字。

• 飽和度：根據(jù)不同的系統(tǒng)，如內(nèi)存資源性系統(tǒng)監(jiān)控內(nèi)存使用率，IO讀寫使用比較高，監(jiān)控資源IO情況。

以上指標要在運維的過程中不斷優(yōu)化，如一些告警可能是網(wǎng)絡(luò)原因進而產(chǎn)生其他問題，如網(wǎng)絡(luò)交換機出現(xiàn)問題，直接掛掉平臺的Marathon組件，應用上很明顯是第三方服務(wù)調(diào)用，接連會產(chǎn)生很多問題，要把共性問題聚合，減少誤告警次數(shù)。但減少誤告警也可能會把有效告警卡掉，也值得思考。

故障跟蹤和事后總結(jié)類似，人工操作會延長恢復時間，告警發(fā)生時一般由一個人處理，隨著時間延長而升級策略，如超過半個小時會逐級上報調(diào)用更多的資源處理故障。在故障跟蹤上解決線上問題為主，處女座強迫癥為輔，做好總結(jié)Root Cause更好的反饋到自動化工具上。

事故總結(jié)非常重要，解決不意味著結(jié)束，要追溯原因，如交換機重啟，導致Marathon的一些問題，總結(jié)后發(fā)現(xiàn)，最好的解決辦法是交換機重啟時通知運維，停掉相關(guān)組件，交換機恢復后，再啟動，如此不影響業(yè)務(wù)的實際運行。

要從失敗中學習，把告警的事件做記錄建立知識庫，發(fā)生問題時方便檢索，快速找到解決方案，要總結(jié)解決某個事故時如何更快發(fā)現(xiàn)問題所在，建立反饋機制，在SRE監(jiān)控過程中，不斷跟產(chǎn)品做實時反饋，包括連接池的使用情況等，鼓勵主動測試，平時運維不會發(fā)生的事，盡可能想辦法去看結(jié)果。

目標定位

SRE目標定位內(nèi)容很多，在各個行業(yè)落地時不盡相同，所以要基于現(xiàn)實，擁抱變化，為了更好應對事故，堅持做推演和演練，在事故總結(jié)方面對產(chǎn)品做建言，故此在工具的研發(fā)上也會有決策權(quán)。

上述內(nèi)容就是大數(shù)據(jù)中如何解決發(fā)布協(xié)調(diào)及監(jiān)控告警兩大難題，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。