建站
咨詢
售后
建站咨詢
新聞中心
一、傳統(tǒng)告警渠道的困局
1.傳統(tǒng)告警——事前
1）業(yè)務(wù)痛點(diǎn)
溝通群里有各種各樣的告警，如基礎(chǔ)設(shè)施的告警、業(yè)務(wù)接口的告警、中間件的告警，客情輿情的用戶反饋。這些信息通過不同的形式方式以及依賴每個(gè)告警工具的建設(shè)，推送在群中，導(dǎo)致整個(gè)群信息雜亂，處理告警無從下手。
日常告警：海量的數(shù)據(jù)內(nèi)容復(fù)雜瑣碎，包括業(yè)務(wù)和中間件的數(shù)據(jù)。由于效率不足，很多時(shí)候大家會(huì)直接靜默，錯(cuò)過一些重要告警，最終導(dǎo)致問題沒有被及時(shí)跟進(jìn)，變成故障，甚至社會(huì)輿情。
網(wǎng)絡(luò)輿情：不只是個(gè)人告警，網(wǎng)絡(luò)輿情的數(shù)量也很龐大。在微博、知乎等一系列的公開場合每天都有大量網(wǎng)絡(luò)輿情。這些客體的數(shù)據(jù)分布在每個(gè)平臺(tái)的社交網(wǎng)絡(luò)上，網(wǎng)絡(luò)感知更快，但難以迅速觸達(dá)研發(fā)和產(chǎn)品側(cè)，錯(cuò)過最快的抑制時(shí)間。
業(yè)務(wù)客訴：即基于內(nèi)部的業(yè)務(wù)客訴?？蛻敉ǔＭㄟ^熱線、在線提工單的方式反饋問題，在線小二、客服將客戶信息轉(zhuǎn)發(fā)到相關(guān)群，通知大家處理。但實(shí)際上用戶難以真正闡述問題，如果不做相關(guān)定性定量，可能在問題反饋初期無法定位問題根因，導(dǎo)致大面積的業(yè)務(wù)客訴，然后轉(zhuǎn)化為重大輿情事件。
2）問題所導(dǎo)致的痛點(diǎn)
- 由于告警過多，過于復(fù)雜，導(dǎo)致告警疲勞；
- 孤軍奮戰(zhàn)：在傳統(tǒng)告警中，每個(gè)人都相當(dāng)于孤軍奮戰(zhàn)，因?yàn)榫W(wǎng)絡(luò)只是輿情的輸入端，而非告警?？驮V在群中流轉(zhuǎn)，日常告警則不斷推送各種各樣的渠道告警，但我們最終只是收到告警，不清楚這條告警通知了誰，有無得到處理，一切都是未知數(shù)；
- 存在信息偏差：由于組織架構(gòu)調(diào)整，相關(guān)研發(fā)和運(yùn)維人員的信息維護(hù)未必非常準(zhǔn)確。收到告警的人可能無需收到類似告警，而本應(yīng)收到告警的新成員，卻未能收到；
- 數(shù)據(jù)離散：用戶不清楚接收的告警數(shù)量，也無法分辨有效告警和無效告警，更無法判斷告警的重要性，導(dǎo)致整個(gè)數(shù)據(jù)無法度量，各個(gè)視角（研發(fā)、測試、運(yùn)維、老板）都無法感知自身業(yè)務(wù)的穩(wěn)定和應(yīng)急協(xié)同的成效。
3）痛點(diǎn)引發(fā)的新問題
- 溝通復(fù)雜：如果成員們認(rèn)為收到的告警表明情況嚴(yán)重，則會(huì)在群里說一聲，但是群消息非常多，因此在收到重要告警時(shí)大家可能察覺不到。
- 問題升級(jí)：溝通復(fù)雜可能導(dǎo)致告警疲勞，造成問題升級(jí)。若小問題得不到及時(shí)解決，積累后越來越嚴(yán)重，就會(huì)導(dǎo)致故障發(fā)生。
- 無法度量：由于渠道、產(chǎn)品不統(tǒng)一，無法跟進(jìn)度量應(yīng)急時(shí)效、有效及后續(xù)情況，所以無法評(píng)估并提升業(yè)務(wù)穩(wěn)定性。
研發(fā)、老板、SRE三大角色需要處理這些風(fēng)險(xiǎn)，各自的困難如下圖：
2.傳統(tǒng)告警——事中
對(duì)于傳統(tǒng)預(yù)警告警的處理，本質(zhì)上是處理并解答四個(gè)問題：有哪些人？采取什么機(jī)制？有哪些信息？用了哪些平臺(tái)工具？然而在實(shí)踐過程中，可能會(huì)遇到各種各樣的挑戰(zhàn)。
- 缺乏標(biāo)準(zhǔn)SOP，研發(fā)處理過于依賴個(gè)人能力
缺乏標(biāo)準(zhǔn)的SOP應(yīng)急流程，導(dǎo)致SRE、研發(fā)、老板三個(gè)角色在問題發(fā)生出現(xiàn)時(shí)，對(duì)預(yù)警、故障的處理完全依賴個(gè)人的經(jīng)驗(yàn)?zāi)芰Α?duì)于一個(gè)具有豐富工作經(jīng)驗(yàn)的同學(xué)來說，不會(huì)在處理故障時(shí)遇到很大障礙。但對(duì)于一些工作時(shí)間不長、沒有遇到過線上問題的同學(xué)來說，處理故障完全依賴個(gè)人理解和能力，這可能導(dǎo)致一些“非標(biāo)”的動(dòng)作，或遺漏重要的應(yīng)急步驟。最終，輕則影響恢復(fù)市場，重則擴(kuò)大故障影響面。
- 實(shí)時(shí)進(jìn)展無同步，信息不對(duì)稱可能放大故障影響面
在整個(gè)操作過程中，由于事態(tài)比較緊急，可能會(huì)存在操作過程不規(guī)范或信息未能及時(shí)同步的情況，使得大家雙向操作。其本質(zhì)問題是實(shí)時(shí)進(jìn)展無法同步、信息不對(duì)稱，最終放大故障的影響面。
- 人員職責(zé)不清晰
一個(gè)標(biāo)準(zhǔn)預(yù)警的發(fā)生，SRE團(tuán)隊(duì)、中間件團(tuán)隊(duì)、業(yè)務(wù)團(tuán)隊(duì)和基礎(chǔ)設(shè)施團(tuán)隊(duì)都可能參與其中，傳統(tǒng)告警無法協(xié)同不同角色在各自領(lǐng)域內(nèi)解決問題。
- 多團(tuán)隊(duì)跨團(tuán)隊(duì)合作，缺乏協(xié)同能力
- 標(biāo)準(zhǔn)恢復(fù)操作涉及拉群、定位、觀測、執(zhí)行運(yùn)維操作的平臺(tái)眾多，來回橫跳影響應(yīng)急效率。
處理方案：
- 觀測定位：在實(shí)戰(zhàn)過程中，一個(gè)事件告警產(chǎn)生后，首先不斷地跳轉(zhuǎn)大量平臺(tái)，進(jìn)行觀測和定位；
- 預(yù)案快恢：類似重啟、線上應(yīng)用配置修改、數(shù)據(jù)庫執(zhí)行DDL、等常規(guī)手段，涉及平臺(tái)極多。平臺(tái)執(zhí)行時(shí)難以及時(shí)通知整個(gè)內(nèi)部團(tuán)隊(duì)，例如有人進(jìn)行業(yè)務(wù)降級(jí)時(shí)，其他人可能并不知道；
- 應(yīng)急協(xié)同：一旦出現(xiàn)嚴(yán)重的問題，大家會(huì)拉群溝通，如果跨團(tuán)隊(duì)，或者涉及多人的跨云協(xié)作則可能雙方人員都會(huì)拉群。但實(shí)際工作中已有SRE群、研發(fā)群和處理臨時(shí)問題的各種群，群的數(shù)量劇增，信息同步效率卻不高。以上情況直接導(dǎo)致整個(gè)告警處理過程中出現(xiàn)一個(gè)極大的業(yè)務(wù)痛點(diǎn)——即大家無法做到信息對(duì)齊，問題會(huì)在處理過程中進(jìn)一步被放大。
3.傳統(tǒng)告警——事后
傳統(tǒng)告警基本沒有事后處理，缺乏對(duì)有效占比、原因分類、響應(yīng)時(shí)長、完結(jié)時(shí)長等一系列標(biāo)準(zhǔn)操作的信息數(shù)據(jù)度量。數(shù)據(jù)度量的缺失就意味著難以進(jìn)行對(duì)應(yīng)數(shù)據(jù)治理，導(dǎo)致問題處理后，缺乏數(shù)據(jù)沉淀，也難以避免類似問題再發(fā)生。此外，如何判斷告警的有效性，如何治理等問題都缺乏對(duì)應(yīng)抓手和處理依據(jù)，這是傳統(tǒng)告警存在的困局。
二、風(fēng)險(xiǎn)預(yù)警——閉環(huán)風(fēng)險(xiǎn)的全生命周期
基于上文的困局，我們提出了“風(fēng)險(xiǎn)”的概念。什么是風(fēng)險(xiǎn)？它與故障有什么區(qū)別？以下將詳細(xì)介紹。
整個(gè)風(fēng)險(xiǎn)的生命周期基本實(shí)現(xiàn)了全閉環(huán)，先風(fēng)險(xiǎn)發(fā)現(xiàn)，然后跟蹤和定位風(fēng)險(xiǎn)，最后風(fēng)險(xiǎn)打標(biāo)。
- 風(fēng)險(xiǎn)發(fā)現(xiàn)
風(fēng)險(xiǎn)挖掘需要定義風(fēng)險(xiǎn)。風(fēng)險(xiǎn)覆蓋人工、客情、輿情、工單系統(tǒng)等方面，也可定義為通過業(yè)務(wù)監(jiān)控、中間件監(jiān)控或基礎(chǔ)設(shè)施監(jiān)控發(fā)現(xiàn)的風(fēng)險(xiǎn)。風(fēng)險(xiǎn)不等同于故障，故障嚴(yán)重影響業(yè)務(wù)的可用性，而風(fēng)險(xiǎn)意味著可能對(duì)業(yè)務(wù)產(chǎn)生小部分影響，但還未擴(kuò)大至較高等級(jí)的影響，無需通過標(biāo)準(zhǔn)的故障流程來處理。我們通過告警系統(tǒng)或人工上報(bào)打通流程，發(fā)現(xiàn)對(duì)應(yīng)風(fēng)險(xiǎn)。
- 風(fēng)險(xiǎn)跟蹤
定義和發(fā)現(xiàn)風(fēng)險(xiǎn)后，就需要跟蹤和相應(yīng)風(fēng)險(xiǎn)?；陲L(fēng)險(xiǎn)響應(yīng)，我們制定了一套標(biāo)準(zhǔn)的SOP流程。
- 風(fēng)險(xiǎn)定位
這個(gè)風(fēng)險(xiǎn)如何產(chǎn)生？根因是什么？這些都是大家需要關(guān)注的重點(diǎn)。
根因定位一旦完成，就需要采取快速恢復(fù)的手段。抖動(dòng)則無需處理，但它可能是一個(gè)action，需要后續(xù)優(yōu)化代碼，執(zhí)行預(yù)案，或執(zhí)行一定的運(yùn)維操作，比如重啟等行為。快恢操作后，若能確定業(yè)務(wù)完成了閉環(huán)的風(fēng)險(xiǎn)處理，就意味著風(fēng)險(xiǎn)完結(jié)。如果風(fēng)險(xiǎn)還未完結(jié)，基本上可以確定已升級(jí)為故障。
- 風(fēng)險(xiǎn)打標(biāo)
風(fēng)險(xiǎn)處理完畢后，最后進(jìn)行風(fēng)險(xiǎn)打標(biāo)。有了打標(biāo)才能更好地實(shí)現(xiàn)閉環(huán)，回溯到第一步的風(fēng)險(xiǎn)挖掘。
基于風(fēng)險(xiǎn)的定義，我們提出了一個(gè)“風(fēng)險(xiǎn)場景”的新概念，它是風(fēng)險(xiǎn)預(yù)警環(huán)節(jié)的核心因素。
1.風(fēng)險(xiǎn)告警——事前
針對(duì)上圖右方的三種異常，不同人員的關(guān)注視角不同，研發(fā)和SRE一般關(guān)注中間件異常和基礎(chǔ)設(shè)施異常，因?yàn)樗锌赡苡绊憳I(yè)務(wù)，也有可能不影響業(yè)務(wù)。如果不進(jìn)行妥善處理，后期有可能導(dǎo)致業(yè)務(wù)異常。至于業(yè)務(wù)異常，所映射的是穩(wěn)定性可能出現(xiàn)問題，業(yè)務(wù)也可能受損。因此不僅研發(fā)和SRE需要關(guān)注業(yè)務(wù)異常，老板和穩(wěn)定性負(fù)責(zé)人也需要關(guān)注。
風(fēng)險(xiǎn)場景的實(shí)體關(guān)聯(lián)了三個(gè)要素，分別是規(guī)則表達(dá)式、監(jiān)控指標(biāo)和告警、預(yù)案和快恢。
- 規(guī)則表達(dá)式：作用是向穩(wěn)定性負(fù)責(zé)人和老板提出異常定義，類似于物理公式，在計(jì)算某個(gè)值的時(shí)候會(huì)先給出一個(gè)公式。對(duì)于穩(wěn)定性負(fù)責(zé)人和老板來說，他們并不關(guān)心公式的值，但這個(gè)公式能明確表達(dá)當(dāng)成功率低于某個(gè)值的時(shí)候，就可以進(jìn)行風(fēng)險(xiǎn)認(rèn)定。
- 監(jiān)控指標(biāo)和告警：基于規(guī)則表達(dá)式，研發(fā)需要補(bǔ)全相關(guān)信息。因?yàn)橐?guī)則表達(dá)式本身只是一個(gè)定義和公式，在具體計(jì)算時(shí)需要關(guān)聯(lián)對(duì)應(yīng)的指標(biāo)。監(jiān)控指標(biāo)告警與三個(gè)概念相關(guān)聯(lián)，一是指標(biāo)，二是告警，三是監(jiān)控實(shí)體。這個(gè)實(shí)體涉及變更和定位，能夠表達(dá)規(guī)則表達(dá)式當(dāng)中的異常關(guān)聯(lián)在哪個(gè)實(shí)體上，也可以確定哪個(gè)監(jiān)控實(shí)體或哪個(gè)應(yīng)用實(shí)體發(fā)生了異常。基于風(fēng)險(xiǎn)場景，規(guī)則表達(dá)式能表達(dá)異常的定義，監(jiān)控指標(biāo)告警則關(guān)聯(lián)表達(dá)式，實(shí)現(xiàn)基礎(chǔ)的計(jì)算能力。
- 預(yù)案和快恢：通過人工預(yù)案的快恢綁定，也可以通過自動(dòng)化預(yù)案綁定。當(dāng)它觸發(fā)某個(gè)場景時(shí)，通過整個(gè)信息流轉(zhuǎn)，集成到整個(gè)快恢平臺(tái)的能力內(nèi)，置于風(fēng)險(xiǎn)場景上，就能解決事前的配置化工作，類似于獲得一本操作手冊(cè)，避免運(yùn)行時(shí)標(biāo)準(zhǔn)化層面的不一致。
綜上所述，我們提出了一個(gè)對(duì)應(yīng)的配置頁面，除了場景外，還會(huì)引入值班組和預(yù)警節(jié)點(diǎn)。預(yù)警節(jié)點(diǎn)即CMDB，用于定義整個(gè)業(yè)務(wù)、部門或應(yīng)用預(yù)警的節(jié)點(diǎn)。
- 場景和值班組的關(guān)系：值班組包括對(duì)應(yīng)的管理者，處理對(duì)應(yīng)問題的企業(yè)微信協(xié)同群及對(duì)應(yīng)的升級(jí)側(cè)。響應(yīng)機(jī)制是5分鐘未接手就升級(jí)至負(fù)責(zé)人，10分鐘未接手則升級(jí)至leader。一個(gè)風(fēng)險(xiǎn)的預(yù)警節(jié)點(diǎn)可關(guān)聯(lián)多個(gè)值班組和多個(gè)場景。
- 值班組的職能：處理預(yù)警節(jié)點(diǎn)所對(duì)應(yīng)的場景信息，比如一個(gè)大團(tuán)隊(duì)設(shè)置了3個(gè)值班組，則每個(gè)值班組需要處理其中的4個(gè)異常場景。通過這些關(guān)聯(lián)的指標(biāo)配置，可清晰定義這個(gè)節(jié)點(diǎn)下需要負(fù)責(zé)的具體值班組和具體的異常場景，關(guān)注點(diǎn)有可能重疊，比如老板的視角會(huì)關(guān)注所有的場景異常。
通過場景的定義、值班組和預(yù)警節(jié)點(diǎn)的概念，我們整合出了風(fēng)險(xiǎn)預(yù)警的三個(gè)核心概念，即哪些值班組在哪個(gè)預(yù)警節(jié)點(diǎn)要處理哪些場景的異常。有了該定義，在事前就能較好梳理風(fēng)險(xiǎn)點(diǎn)的具體位置以及人員職責(zé)，避免上文所述的告警混亂和渠道不一致問題。
2.風(fēng)險(xiǎn)告警——事中
- 報(bào)警推送
場景觸發(fā)異常時(shí)，第一個(gè)消息就是報(bào)警推送。收到告警后，我們會(huì)在群里推送一套標(biāo)準(zhǔn)化流程的卡片，標(biāo)準(zhǔn)化的格式是標(biāo)題內(nèi)容、告警時(shí)間渠道以及最近變更成員，然后進(jìn)行一定的標(biāo)準(zhǔn)行為操作，比如遇到風(fēng)險(xiǎn)需要接手并響應(yīng)，加入一個(gè)應(yīng)急的協(xié)同群。通過對(duì)接不同的監(jiān)控系統(tǒng)，我們可以清晰定義監(jiān)控和告警的實(shí)體以及用戶關(guān)心的內(nèi)容。針對(duì)來自MySQL、SLO、Alarm、公司內(nèi)部前端的告警和普通的告警，會(huì)適配不同的模板，由渠道統(tǒng)一推送。
主要貢獻(xiàn)：統(tǒng)一流程、整合能力、提供協(xié)同、適配渠道、精準(zhǔn)觸達(dá)、
- 行為同步
由于我們已經(jīng)明確“標(biāo)準(zhǔn)SOP體系下的風(fēng)險(xiǎn)處理”定義，所以告警出現(xiàn)后，自然有人接手。之后再進(jìn)行轉(zhuǎn)交，并在排查過程中機(jī)型信息的錄入與同步，也可以告知他人自己遇到的問題，這些信息都會(huì)在群中同步，如此便實(shí)現(xiàn)了事件的閉環(huán)。我們還提供了催辦升級(jí)能力，同步廣播進(jìn)展，進(jìn)行統(tǒng)一的度量。若整個(gè)群做到了以上幾點(diǎn)，那么在老板視角就可以及時(shí)獲知問題，是否有人處理和響應(yīng)等。研發(fā)也能互相協(xié)同，因?yàn)橐粋€(gè)平臺(tái)由多個(gè)研發(fā)負(fù)責(zé)，在這個(gè)平臺(tái)中我們可以了解問題的跟進(jìn)詳情，問題根因來自誰等，可便于在群中做進(jìn)一步的溝通。
主要貢獻(xiàn)：閉環(huán)事件、催辦升級(jí)、廣播進(jìn)展、統(tǒng)一度量、信息透明
- 預(yù)警詳情
除了簡短的卡片信息外，還會(huì)提供一些對(duì)應(yīng)的技術(shù)指標(biāo)，比如針對(duì)SLO的告警，我們提供了一個(gè)相關(guān)接口錯(cuò)誤碼的指標(biāo)時(shí)序圖，以方便研發(fā)在預(yù)警詳情中通過一個(gè)頁面查看過往大量平臺(tái)的信息。表面上是平臺(tái)整合，但實(shí)際上是通過標(biāo)準(zhǔn)的SOP流程明確定義需要關(guān)注的平臺(tái)，并且借助算法和工程能力查出具體的指標(biāo)錯(cuò)誤，同時(shí)提供一定的根因分析和預(yù)案快恢能力。根因分析和預(yù)案快恢的完整行動(dòng)路線都會(huì)通過信息同步的方式在群中進(jìn)行協(xié)同處理，以避免由于信息不一致而導(dǎo)致操作失誤。
- 預(yù)警列表
方便用戶在群中快速得知哪些預(yù)警仍未完結(jié)，通過一個(gè)較為標(biāo)準(zhǔn)的處理流程，就能妥當(dāng)?shù)靥幚盹L(fēng)險(xiǎn)。即使一個(gè)研發(fā)缺乏一定的風(fēng)險(xiǎn)處理能力，但借助這套產(chǎn)品也能極快地處理風(fēng)險(xiǎn)，降低整個(gè)業(yè)務(wù)的風(fēng)險(xiǎn)。
對(duì)于整個(gè)風(fēng)險(xiǎn)預(yù)警產(chǎn)品，我們不僅做了標(biāo)準(zhǔn)的SOP流程，還從變更層面挖掘了信息的拓?fù)淠芰Α?/p>
- 快恢覆蓋
快恢即在整個(gè)恢復(fù)過程中所執(zhí)行的手段，回滾最為常見，因?yàn)槌^73%的故障和風(fēng)險(xiǎn)基本上都由變更引起。此外還有中間件和基礎(chǔ)設(shè)施的運(yùn)維操作，以及標(biāo)準(zhǔn)化預(yù)案平臺(tái)的接入。
通過這些覆蓋，我們?cè)谡麄€(gè)事中可以做到賦予研發(fā)更多處理問題的手段和能力，借助變更覆蓋和監(jiān)控覆蓋，結(jié)合拓?fù)涓采w，我們就能嘗試幫助用戶定位風(fēng)險(xiǎn)的誘因。
圖右側(cè)展示了風(fēng)險(xiǎn)預(yù)警的定位能力以及對(duì)應(yīng)的覆蓋能力。通過定位，能將內(nèi)容快速推送到群中；通過接口的監(jiān)控，告知指標(biāo)在同環(huán)比增加的比率，最后幫助用戶發(fā)現(xiàn)問題。
如果上下游出現(xiàn)異常，拓?fù)涓采w也能定位。若你的應(yīng)用發(fā)現(xiàn)異常，我們會(huì)幫你檢測有無做過對(duì)應(yīng)的變更，若無變更，則通過拓?fù)湫畔蓽y周圍鏈路上發(fā)生的變更，給出一定的推薦，幫助用戶找到對(duì)應(yīng)的人員，從而快速解決問題。
而在快恢層面，我們也會(huì)同步所有信息，在整個(gè)群中做協(xié)同，以避免研發(fā)在重復(fù)操作或者信息不同步不對(duì)稱的情況下，導(dǎo)致故障或風(fēng)險(xiǎn)的二次發(fā)生。
3.風(fēng)險(xiǎn)告警——事后
有了恰當(dāng)?shù)呐渲煤褪轮械奶幚?，通過相對(duì)簡單的方式便能度量事后的數(shù)據(jù)。
接手時(shí)長、接手率、完結(jié)時(shí)長以及完結(jié)率是四個(gè)非常核心的技術(shù)指標(biāo)，透過這些指標(biāo)即能感知每個(gè)部門的情況。我們會(huì)根據(jù)這些情況去溝通，加深對(duì)產(chǎn)品的了解，思考產(chǎn)品能夠持續(xù)優(yōu)化的各個(gè)方向和層面。
事前涉及基礎(chǔ)設(shè)施的風(fēng)險(xiǎn)覆蓋、中間件的風(fēng)險(xiǎn)覆蓋、應(yīng)用的風(fēng)險(xiǎn)覆蓋以及SLO的風(fēng)險(xiǎn)覆蓋，事中的核心度量就是接手率、完結(jié)率和轉(zhuǎn)故障數(shù)。事后則會(huì)度量有效率和場景治理。
場景治理包括兩方面，一是正召回，二是負(fù)向召回。正召回即召回誤告的告警，負(fù)向召回即需要填充未被發(fā)覺的告警。事后的度量完成后，整個(gè)風(fēng)險(xiǎn)就能產(chǎn)生一個(gè)新的閉環(huán)，從而解決風(fēng)險(xiǎn)的遺漏風(fēng)險(xiǎn)、告警的失效，以及人員的治理問題，最終就能解決整個(gè)風(fēng)險(xiǎn)。
三、風(fēng)險(xiǎn)預(yù)警的產(chǎn)品架構(gòu)&技術(shù)架構(gòu)
1.風(fēng)險(xiǎn)預(yù)警總體架構(gòu)
2.風(fēng)險(xiǎn)預(yù)警技術(shù)架構(gòu)
最底層是人員組織的管理，用于表明公司的人員信息；CMDB即預(yù)警節(jié)點(diǎn)的節(jié)點(diǎn)能力，也會(huì)搭建基礎(chǔ)服務(wù)，以便為上層服務(wù)提供權(quán)限。場景管理再往上，則會(huì)通過一些微服務(wù)（如核心的場景管理）實(shí)現(xiàn)整個(gè)場景的數(shù)據(jù)配置化能力。
- 監(jiān)控管理：提供一個(gè)標(biāo)準(zhǔn)的監(jiān)控模型，把不同的監(jiān)控系統(tǒng)接入到整個(gè)平臺(tái)中；
- 值班管理：Oncall值班組的能力；
- 變更管理：不但承載封網(wǎng)管控能力，還負(fù)責(zé)變更信息的錄入。在最底層的業(yè)務(wù)設(shè)計(jì)基礎(chǔ)上，分為四部分，分別是配置管理、處理風(fēng)險(xiǎn)、定位恢復(fù)和數(shù)據(jù)度量；
- 配置管理：管理場景、CMDB、人員組織和值班表的相關(guān)關(guān)系，提供風(fēng)險(xiǎn)挖掘和故障防控的能力；
- 處理風(fēng)險(xiǎn)：除消息推送、應(yīng)急協(xié)同和催辦升級(jí)外，也能聚焦于快恢能力。我們的產(chǎn)品主要是解耦式的設(shè)計(jì)，可以支持外部系統(tǒng)做對(duì)應(yīng)的推送。以MySQL為例，這種場景下如果要做定位，有了解耦式的設(shè)計(jì)，就能通過DBA自行診斷整合到我們風(fēng)險(xiǎn)預(yù)警的應(yīng)急流程處理中去，更好地服務(wù)于研發(fā)和SRE，幫助他們解決這個(gè)問題。
通過整套技術(shù)架構(gòu)以及領(lǐng)域劃分的設(shè)計(jì)，它的橫向拓展性相對(duì)會(huì)更好。針對(duì)后續(xù)的一些用戶訴求，不管是SRE老板、運(yùn)維穩(wěn)定性負(fù)責(zé)人還是一線研發(fā)，都會(huì)在這個(gè)產(chǎn)品中承擔(dān)不同的角色，并滿足不同的訴求。
Q&A
Q1: 影響范圍、上下文和診斷信息等告警信息是否都會(huì)給出？
A1：我們有一定的拓?fù)淠芰Γ瑫?huì)把每一個(gè)節(jié)點(diǎn)封裝成一個(gè)對(duì)應(yīng)的實(shí)體，這個(gè)實(shí)體會(huì)關(guān)聯(lián)對(duì)應(yīng)的中間件依賴以及上下游的依賴。當(dāng)我們接入一個(gè)告警信息時(shí)，它的上下游信息會(huì)根據(jù)HTTP和RPC的標(biāo)準(zhǔn)指標(biāo)將紅色的異常節(jié)點(diǎn)進(jìn)行定義，在告警信息中給出對(duì)應(yīng)的診斷。
由于它依賴指標(biāo)的計(jì)算所以在技術(shù)上使用了異步模式，當(dāng)它推送告警信息后，如果它在1~2分鐘內(nèi)判斷出大概的影響范圍和上下文，就會(huì)補(bǔ)充診斷信息，將可能導(dǎo)致告警的原因告知用戶——自身應(yīng)用導(dǎo)致還是上游檢測出的依賴方的調(diào)用出現(xiàn)了環(huán)比的突增？最終都會(huì)給出診斷。
Q2：如何確認(rèn)預(yù)警告警本身的準(zhǔn)確性和有效性？
A2：首先我們會(huì)通過風(fēng)險(xiǎn)的挖掘，告知用戶具體的風(fēng)險(xiǎn)。在出現(xiàn)風(fēng)險(xiǎn)告警時(shí)，研發(fā)確實(shí)會(huì)接收到大量的無效告警，但在我們的處理過程中，會(huì)有一個(gè)閉環(huán)，在風(fēng)險(xiǎn)度量時(shí)就能看出哪些是誤告率極高的告警，所以這時(shí)透過周報(bào)就能看到相關(guān)信息，從而篩選出準(zhǔn)確有效的告警，并通過數(shù)據(jù)的閉環(huán)幫助用戶做對(duì)應(yīng)的治理。
你也可以一鍵優(yōu)化規(guī)則，或者通過屏蔽無效告警、比如代碼屏蔽errorCode的方式來確認(rèn)，比如用戶未登錄而執(zhí)行某些結(jié)果導(dǎo)致鑒權(quán)報(bào)錯(cuò)，針對(duì)這種情況就可以用上述的方法。
因此，數(shù)據(jù)閉環(huán)的作用是驅(qū)使研發(fā)自閉環(huán)地判斷告警本身的準(zhǔn)確性和有效性，并據(jù)此做對(duì)應(yīng)的治理，這是整個(gè)風(fēng)險(xiǎn)預(yù)警的重要貢獻(xiàn)之一。
Q3：預(yù)警對(duì)故障的容忍度如何，怎樣設(shè)置閾值？
A3：首先，中間件異常和基礎(chǔ)設(shè)施異常也有可能不影響業(yè)務(wù)故障，比如四臺(tái)機(jī)器掛兩臺(tái)，如果流量不高，則業(yè)務(wù)上可能無感知，我們會(huì)把這方面劃分在預(yù)警的領(lǐng)域內(nèi)。至于容忍度，則需要SRE制定一個(gè)標(biāo)準(zhǔn)的SLI，因?yàn)樗赡芡ㄟ^pv/uv、或者一些資損得到一個(gè)對(duì)應(yīng)的結(jié)果，因此若SLI認(rèn)為某個(gè)指標(biāo)的成功率低于90%則為故障，那么對(duì)預(yù)警而言，可能就會(huì)將值設(shè)置為95%或96%，具體基于研發(fā)對(duì)自己系統(tǒng)業(yè)務(wù)上的規(guī)則定義。
注意以下兩點(diǎn)：容忍度必須比故障更高一些，比如故障的指標(biāo)是90%，你就可以設(shè)置95%時(shí)發(fā)出一條預(yù)警，思考低于95%時(shí)是否需要開始介入，以避免發(fā)生更進(jìn)一步的故障；比如宿主機(jī)發(fā)生異常，或者整個(gè)中間的鏈路上分支環(huán)節(jié)上出現(xiàn)異常的時(shí)候，可能還未對(duì)故障的指標(biāo)產(chǎn)生影響，通過預(yù)警就能迅速容忍故障的發(fā)生。這就是它能防控故障的原因，因?yàn)樗龅搅藢?duì)場景業(yè)務(wù)更為精細(xì)化的管理。
Q4：發(fā)生雪崩效應(yīng)大面積告警故障時(shí)，能否快速定位故障源，具體如何實(shí)現(xiàn)？
A4：無論從內(nèi)部復(fù)盤還是整個(gè)行業(yè)的經(jīng)驗(yàn)上看，絕大部分的大面積故障都源于兩方面，一方面是變更，另一方面則是運(yùn)維的操作，運(yùn)維操作也可以定義為變更，一個(gè)是發(fā)代碼，一個(gè)是發(fā)配置。
基于這兩點(diǎn)，我們接入了變更的整個(gè)拓?fù)鋽?shù)據(jù)，還接入了CMDB。CMDB是配置時(shí)的拓?fù)湫畔ⅲ\(yùn)行時(shí)則是通過分析 Discovery數(shù)據(jù)拓?fù)洹粋€(gè)鏈路的實(shí)時(shí)動(dòng)態(tài)和調(diào)用關(guān)系，將它們結(jié)合分析，基本上就能基于告警的爆炸中心找到對(duì)應(yīng)上下游的變更情況，以及對(duì)應(yīng)的核心指標(biāo)。以應(yīng)用為例，我們定義了HTTP和RPC，就能快速定位可能存在的故障源，不過這只是一種可能。整個(gè)底層模型是一個(gè)拓?fù)涞臉湫谓Y(jié)構(gòu)，當(dāng)它發(fā)現(xiàn)最頂層的異常時(shí)，通過分析依賴關(guān)系可以通過快速找到對(duì)應(yīng)的故障點(diǎn)，因?yàn)槲覀冋J(rèn)為往下都是果，最頂層才是因。
Q5：為什么要有風(fēng)險(xiǎn)的概念？用這套流程來做故障處理不是同樣可以嗎？
A5：風(fēng)險(xiǎn)和故障之間有比較明確的界定，不影響業(yè)務(wù)的異常（如中間件的異常）更需要研發(fā)關(guān)注。比如我有六個(gè)下游做同一件事情，每個(gè)下游是六分之一的分流，且有兩個(gè)下游異常，這時(shí)業(yè)務(wù)并不感知，但是它可以通過風(fēng)險(xiǎn)來處理，因?yàn)榱鶄€(gè)業(yè)務(wù)中有兩個(gè)供應(yīng)商可能異常，這需要我們定義。
風(fēng)險(xiǎn)有可能影響業(yè)務(wù)，但不足以啟動(dòng)整個(gè)故障的流程處理。所以我們提出風(fēng)險(xiǎn)自閉環(huán)能力，它并不是一個(gè)管控手段，而故障更多的是一種行政管控手段，可以將它理解為一個(gè)獎(jiǎng)懲機(jī)制。你觸發(fā)了故障，就要按照標(biāo)準(zhǔn)的流程處理，必須第一時(shí)間解決問題，必須要復(fù)盤，最后計(jì)入穩(wěn)定性分析，可能還會(huì)有各種各樣的掛鉤，但風(fēng)險(xiǎn)始終是自閉環(huán)。
故障確實(shí)有部分協(xié)同與風(fēng)險(xiǎn)一致，但在數(shù)據(jù)度量以及對(duì)應(yīng)的手段上，故障本身不需要接入一些中間件、基礎(chǔ)設(shè)施或者指標(biāo)自定義的告警，它接入更多的是強(qiáng)勢的業(yè)務(wù)管理，比如交易成功率低于多少，下單成功率或者彈幕的發(fā)送成功率低于多少等，這是與風(fēng)險(xiǎn)的最大區(qū)別。
Q6：事件變更如何要求所有業(yè)務(wù)的變更都去變更平臺(tái)錄入變更信息？若不錄入，他們就無法進(jìn)行變更嗎？
A6：我們不會(huì)找所有的業(yè)務(wù)，而是對(duì)接整個(gè)公司，比如應(yīng)用的發(fā)布平臺(tái)、編譯平臺(tái)以及配置的發(fā)布平臺(tái)，以及數(shù)據(jù)庫的DDL變更，把整個(gè)變更平臺(tái)的信息視作標(biāo)準(zhǔn)化的結(jié)構(gòu)錄入。
Q7：故障的影響范圍如何快速評(píng)估？
A7：故障影響范圍的快速評(píng)估主要通過四種方式，第一是監(jiān)控指標(biāo)，整個(gè)業(yè)務(wù)會(huì)不斷地在應(yīng)急協(xié)同群中反饋哪些業(yè)務(wù)受影響。第二種，比如我做了網(wǎng)絡(luò)變更，導(dǎo)致網(wǎng)絡(luò)異常，但我知道網(wǎng)絡(luò)有可能會(huì)影響哪些業(yè)務(wù)，所以故障的影響方本身也可以做到影響范圍的快速評(píng)估。第三即拓?fù)淠芰Γ梢钥焖倮稣麄€(gè)鏈路的影響范圍。但在實(shí)戰(zhàn)過程中，如果遇到了大故障，我們的定位系統(tǒng)壓力極大，基本算不過來，這種情況就無需再定位，因?yàn)橛绊懨嫣珡V，大家基本已全部得知。第四種即客情，一旦出現(xiàn)大故障，在微博上必定會(huì)出現(xiàn)客情，產(chǎn)生一定的社會(huì)影響面，所以可以借助整個(gè)社會(huì)的反饋來做評(píng)估。
Q8：風(fēng)險(xiǎn)預(yù)警的定義門檻比故障更低，如何讓技術(shù)人員對(duì)風(fēng)險(xiǎn)預(yù)警足夠重視，又不至于被過多的預(yù)警轟炸到麻木？
A8：首先，我們產(chǎn)品的核心與故障有本質(zhì)區(qū)別，故障更多的是一種管控手段，風(fēng)險(xiǎn)預(yù)警則是我們給研發(fā)提供自閉環(huán)風(fēng)險(xiǎn)的概念，也就是說，理論上研發(fā)對(duì)風(fēng)險(xiǎn)預(yù)警擁有接收自由，我們并沒有強(qiáng)制研發(fā)一定要接收風(fēng)險(xiǎn)預(yù)警。
針對(duì)整個(gè)風(fēng)險(xiǎn)預(yù)警的定義，它是一個(gè)產(chǎn)品，用于幫助技術(shù)人員或者研發(fā)等不同的角色提高風(fēng)險(xiǎn)對(duì)應(yīng)的管理能力。故障相對(duì)而言強(qiáng)制性更強(qiáng)，對(duì)公司來說可以稱為一種政治手段。風(fēng)險(xiǎn)預(yù)警是一個(gè)產(chǎn)品化的能力，它幫助技術(shù)人員去做這個(gè)事情。技術(shù)人員可能是最底層的一線技術(shù)人員，也可能是技術(shù)人員的老板，希望通過風(fēng)險(xiǎn)預(yù)警提供一個(gè)抓手，提高整個(gè)團(tuán)隊(duì)對(duì)風(fēng)險(xiǎn)的管控能力。他也有可能是穩(wěn)定性負(fù)責(zé)人，希望更快獲知風(fēng)險(xiǎn)。
這個(gè)產(chǎn)品提供了一定的技術(shù)能力，并且將在后續(xù)的迭代中不斷豐富，比如更精準(zhǔn)的定位能力、更精準(zhǔn)的快恢、接入更多的快恢平臺(tái)，制定恢復(fù)預(yù)案等，將這些技術(shù)能力整合在一起，幫助技術(shù)人員更好地解決風(fēng)險(xiǎn)。借助該產(chǎn)品，他們可以迅速獲得業(yè)務(wù)結(jié)果，以最小的成本實(shí)現(xiàn)穩(wěn)定性的建設(shè)。如果他們意識(shí)到以上的好處，他們也會(huì)認(rèn)同并相信風(fēng)險(xiǎn)預(yù)警能解決對(duì)應(yīng)的業(yè)務(wù)痛點(diǎn)。
至于如何避免被過多的預(yù)警轟炸到麻木，第一配置成本會(huì)調(diào)高；第二，我們會(huì)進(jìn)行數(shù)據(jù)復(fù)盤，在整個(gè)大盤中告知哪些預(yù)警的規(guī)則可能存在問題。我們不會(huì)讓用戶簡單地打標(biāo)告警有效或無效，會(huì)闡述清楚是抖動(dòng)還是監(jiān)控異常，或是規(guī)則不合理，還是偶發(fā)事件無需處理等等一系列原因，幫助研發(fā)通過整個(gè)大盤的數(shù)據(jù)得知自己上周的應(yīng)急協(xié)同數(shù)據(jù)，即獲知每天處理的風(fēng)險(xiǎn)數(shù)量以及有效率，哪些風(fēng)險(xiǎn)需要重視等，通過一個(gè)閉環(huán)清除無效的告警，幫助研發(fā)挖掘更多可能需要覆蓋的風(fēng)險(xiǎn)點(diǎn)。綜上所述，當(dāng)技術(shù)人員認(rèn)為這個(gè)產(chǎn)品對(duì)他有幫助，他就會(huì)自發(fā)使用。
谷林濤
嗶哩嗶哩
基礎(chǔ)架構(gòu)部 資深開發(fā)工程師
B站事件運(yùn)營中心研發(fā)負(fù)責(zé)人，負(fù)責(zé)建設(shè)Bilibili內(nèi)部穩(wěn)定性平臺(tái)產(chǎn)品，提升線上問題的應(yīng)急協(xié)同效能。同時(shí)負(fù)責(zé)工單、封網(wǎng)管控、拓?fù)涠ㄎ划a(chǎn)品，總體保障業(yè)務(wù)系統(tǒng)的安全生產(chǎn)。
本文名稱：風(fēng)險(xiǎn)預(yù)警的架構(gòu)這樣做，讓故障扼殺在搖籃之中……
網(wǎng)頁鏈接：http://www.dlmjj.cn/article/cccghcs.html
