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

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

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

SRE核心理念

SRE是谷歌十?dāng)?shù)年運(yùn)維過(guò)程中演練出來(lái)的模式，在實(shí)踐過(guò)程中積累了很多經(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é)類(lèi)似，但在工作方式上有很大區(qū)別： 1）應(yīng)急響應(yīng)主要落實(shí)在對(duì)監(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)維是長(zhǎng)期目標(biāo)，也是熱點(diǎn)內(nèi)容。

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

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

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

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

金融行業(yè)ITSM特性

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

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

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

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

SRE平臺(tái)架構(gòu)模型如上圖，資源供給層是基于數(shù)人云的PaaS平臺(tái)，以Docker容器化管理做資源調(diào)動(dòng)，應(yīng)用調(diào)度分別基于Mesos和Marathon，目前數(shù)人云也開(kāi)源了名為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)層，對(duì)應(yīng)公司里的架構(gòu)部門(mén)，包括采用RPC框架、緩存、消息中心選型等等。

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

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

發(fā)布協(xié)調(diào)在日常的工作中應(yīng)用很多，如應(yīng)用上線、變更管理。在SRE指導(dǎo)下，某項(xiàng)目現(xiàn)場(chǎng)成立了類(lèi)似于發(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ù)雜。開(kāi)發(fā)測(cè)試環(huán)境如物理環(huán)境完全隔離，和互聯(lián)網(wǎng)行業(yè)不同?；ヂ?lián)網(wǎng)行業(yè)，都是在線發(fā)布，測(cè)試環(huán)境也許就是生產(chǎn)環(huán)境，采用灰度發(fā)布或者藍(lán)綠發(fā)布模式去做。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 第二，人工檢查

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

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

整體過(guò)程都體現(xiàn)了SRE思想，發(fā)布平臺(tái)的每個(gè)步驟均可通過(guò)界面配置完成，中間關(guān)鍵點(diǎn)由人工參與，目的是保障產(chǎn)品上線的成功率，避免在上線過(guò)程中手動(dòng)配置產(chǎn)生問(wè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)控的重要性深有體會(huì)，我們?cè)谀辰鹑诠維RE團(tuán)隊(duì)中有1—2名監(jiān)控專(zhuān)員，專(zhuān)員主要職責(zé)是維護(hù)監(jiān)控系統(tǒng)。一個(gè)是甲方內(nèi)部人員，另一個(gè)是數(shù)人云的同事。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

目標(biāo)定位

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

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

文章題目：大數(shù)據(jù)中如何解決發(fā)布協(xié)調(diào)及監(jiān)控告警兩大難題
文章源于：http://sd-ha.com/article46/pchpeg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站排名、移動(dòng)網(wǎng)站建設(shè)、App設(shè)計(jì)、營(yíng)銷(xiāo)型網(wǎng)站建設(shè)、、品牌網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話(huà)：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)