大數(shù)據(jù)中如何解決發(fā)布協(xié)調(diào)及監(jiān)控告警兩大難題

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

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

SRE核心理念

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

SRE崗位工作職責(zé)有：

• 應(yīng)急相應(yīng)

• 日常運(yùn)維

• 工程研發(fā)

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

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

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

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

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

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

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

金融行業(yè)ITSM特性

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

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

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

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

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

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

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

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

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

• 上線協(xié)調(diào)需要同時(shí)面對多個(gè)外包團(tuán)隊(duì)，外包團(tuán)隊(duì)人員相對不可控，導(dǎo)致溝通成本較高。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 第二，人工檢查

• 第三，上傳程序包，配置項(xiàng)管理

• 最后，重啟容器再進(jìn)行人工檢查

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

目標(biāo)定位

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

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