一、傳統(tǒng)告警渠道的困局

1.傳統(tǒng)告警——事前

1）業(yè)務(wù)痛點(diǎn)

溝通群里有各種各樣的告警，如基礎(chǔ)設(shè)施的告警、業(yè)務(wù)接口的告警、中間件的告警，客情輿情的用戶反饋。這些信息通過不同的形式方式以及依賴每個告警工具的建設(shè)，推送在群中，導(dǎo)致整個群信息雜亂，處理告警無從下手。

日常告警：海量的數(shù)據(jù)內(nèi)容復(fù)雜瑣碎，包括業(yè)務(wù)和中間件的數(shù)據(jù)。由于效率不足，很多時候大家會直接靜默，錯過一些重要告警，最終導(dǎo)致問題沒有被及時跟進(jìn)，變成故障，甚至社會輿情。

網(wǎng)絡(luò)輿情：不只是個人告警，網(wǎng)絡(luò)輿情的數(shù)量也很龐大。在微博、知乎等一系列的公開場合每天都有大量網(wǎng)絡(luò)輿情。這些客體的數(shù)據(jù)分布在每個平臺的社交網(wǎng)絡(luò)上，網(wǎng)絡(luò)感知更快，但難以迅速觸達(dá)研發(fā)和產(chǎn)品側(cè)，錯過最快的抑制時間。

業(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)告警中，每個人都相當(dāng)于孤軍奮戰(zhàn)，因?yàn)榫W(wǎng)絡(luò)只是輿情的輸入端，而非告警。客訴在群中流轉(zhuǎn)，日常告警則不斷推送各種各樣的渠道告警，但我們最終只是收到告警，不清楚這條告警通知了誰，有無得到處理，一切都是未知數(shù)；
• 存在信息偏差：由于組織架構(gòu)調(diào)整，相關(guān)研發(fā)和運(yùn)維人員的信息維護(hù)未必非常準(zhǔn)確。收到告警的人可能無需收到類似告警，而本應(yīng)收到告警的新成員，卻未能收到；
• 數(shù)據(jù)離散：用戶不清楚接收的告警數(shù)量，也無法分辨有效告警和無效告警，更無法判斷告警的重要性，導(dǎo)致整個數(shù)據(jù)無法度量，各個視角（研發(fā)、測試、運(yùn)維、老板）都無法感知自身業(yè)務(wù)的穩(wěn)定和應(yīng)急協(xié)同的成效。

3）痛點(diǎn)引發(fā)的新問題

• 溝通復(fù)雜：如果成員們認(rèn)為收到的告警表明情況嚴(yán)重，則會在群里說一聲，但是群消息非常多，因此在收到重要告警時大家可能察覺不到。
• 問題升級：溝通復(fù)雜可能導(dǎo)致告警疲勞，造成問題升級。若小問題得不到及時解決，積累后越來越嚴(yán)重，就會導(dǎo)致故障發(fā)生。
• 無法度量：由于渠道、產(chǎn)品不統(tǒng)一，無法跟進(jìn)度量應(yīng)急時效、有效及后續(xù)情況，所以無法評估并提升業(yè)務(wù)穩(wěn)定性。 

研發(fā)、老板、SRE三大角色需要處理這些風(fēng)險，各自的困難如下圖：

2.傳統(tǒng)告警——事中

對于傳統(tǒng)預(yù)警告警的處理，本質(zhì)上是處理并解答四個問題：有哪些人？采取什么機(jī)制？有哪些信息？用了哪些平臺工具？然而在實(shí)踐過程中，可能會遇到各種各樣的挑戰(zhàn)。

• 缺乏標(biāo)準(zhǔn)SOP，研發(fā)處理過于依賴個人能力

缺乏標(biāo)準(zhǔn)的SOP應(yīng)急流程，導(dǎo)致SRE、研發(fā)、老板三個角色在問題發(fā)生出現(xiàn)時，對預(yù)警、故障的處理完全依賴個人的經(jīng)驗(yàn)?zāi)芰Ατ谝粋€具有豐富工作經(jīng)驗(yàn)的同學(xué)來說，不會在處理故障時遇到很大障礙。但對于一些工作時間不長、沒有遇到過線上問題的同學(xué)來說，處理故障完全依賴個人理解和能力，這可能導(dǎo)致一些“非標(biāo)”的動作，或遺漏重要的應(yīng)急步驟。最終，輕則影響恢復(fù)市場，重則擴(kuò)大故障影響面。

• 實(shí)時進(jìn)展無同步，信息不對稱可能放大故障影響面

在整個操作過程中，由于事態(tài)比較緊急，可能會存在操作過程不規(guī)范或信息未能及時同步的情況，使得大家雙向操作。其本質(zhì)問題是實(shí)時進(jìn)展無法同步、信息不對稱，最終放大故障的影響面。

• 人員職責(zé)不清晰

一個標(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)維操作的平臺眾多，來回橫跳影響應(yīng)急效率。

處理方案：

• 觀測定位：在實(shí)戰(zhàn)過程中，一個事件告警產(chǎn)生后，首先不斷地跳轉(zhuǎn)大量平臺，進(jìn)行觀測和定位；
• 預(yù)案快恢：類似重啟、線上應(yīng)用配置修改、數(shù)據(jù)庫執(zhí)行DDL、等常規(guī)手段，涉及平臺極多。平臺執(zhí)行時難以及時通知整個內(nèi)部團(tuán)隊(duì)，例如有人進(jìn)行業(yè)務(wù)降級時，其他人可能并不知道；
• 應(yīng)急協(xié)同：一旦出現(xiàn)嚴(yán)重的問題，大家會拉群溝通，如果跨團(tuán)隊(duì)，或者涉及多人的跨云協(xié)作則可能雙方人員都會拉群。但實(shí)際工作中已有SRE群、研發(fā)群和處理臨時問題的各種群，群的數(shù)量劇增，信息同步效率卻不高。以上情況直接導(dǎo)致整個告警處理過程中出現(xiàn)一個極大的業(yè)務(wù)痛點(diǎn)——即大家無法做到信息對齊，問題會在處理過程中進(jìn)一步被放大。

3.傳統(tǒng)告警——事后

傳統(tǒng)告警基本沒有事后處理，缺乏對有效占比、原因分類、響應(yīng)時長、完結(jié)時長等一系列標(biāo)準(zhǔn)操作的信息數(shù)據(jù)度量。數(shù)據(jù)度量的缺失就意味著難以進(jìn)行對應(yīng)數(shù)據(jù)治理，導(dǎo)致問題處理后，缺乏數(shù)據(jù)沉淀，也難以避免類似問題再發(fā)生。此外，如何判斷告警的有效性，如何治理等問題都缺乏對應(yīng)抓手和處理依據(jù)，這是傳統(tǒng)告警存在的困局。

二、風(fēng)險預(yù)警——閉環(huán)風(fēng)險的全生命周期 

基于上文的困局，我們提出了“風(fēng)險”的概念。什么是風(fēng)險？它與故障有什么區(qū)別？以下將詳細(xì)介紹。

整個風(fēng)險的生命周期基本實(shí)現(xiàn)了全閉環(huán)，先風(fēng)險發(fā)現(xiàn)，然后跟蹤和定位風(fēng)險，最后風(fēng)險打標(biāo)。

• 風(fēng)險發(fā)現(xiàn)

風(fēng)險挖掘需要定義風(fēng)險。風(fēng)險覆蓋人工、客情、輿情、工單系統(tǒng)等方面，也可定義為通過業(yè)務(wù)監(jiān)控、中間件監(jiān)控或基礎(chǔ)設(shè)施監(jiān)控發(fā)現(xiàn)的風(fēng)險。風(fēng)險不等同于故障，故障嚴(yán)重影響業(yè)務(wù)的可用性，而風(fēng)險意味著可能對業(yè)務(wù)產(chǎn)生小部分影響，但還未擴(kuò)大至較高等級的影響，無需通過標(biāo)準(zhǔn)的故障流程來處理。我們通過告警系統(tǒng)或人工上報打通流程，發(fā)現(xiàn)對應(yīng)風(fēng)險。

• 風(fēng)險跟蹤

定義和發(fā)現(xiàn)風(fēng)險后，就需要跟蹤和相應(yīng)風(fēng)險。基于風(fēng)險響應(yīng)，我們制定了一套標(biāo)準(zhǔn)的SOP流程。

• 風(fēng)險定位

這個風(fēng)險如何產(chǎn)生？根因是什么？這些都是大家需要關(guān)注的重點(diǎn)。

根因定位一旦完成，就需要采取快速恢復(fù)的手段。抖動則無需處理，但它可能是一個action，需要后續(xù)優(yōu)化代碼，執(zhí)行預(yù)案，或執(zhí)行一定的運(yùn)維操作，比如重啟等行為。快恢操作后，若能確定業(yè)務(wù)完成了閉環(huán)的風(fēng)險處理，就意味著風(fēng)險完結(jié)。如果風(fēng)險還未完結(jié)，基本上可以確定已升級為故障。

• 風(fēng)險打標(biāo)

風(fēng)險處理完畢后，最后進(jìn)行風(fēng)險打標(biāo)。有了打標(biāo)才能更好地實(shí)現(xiàn)閉環(huán)，回溯到第一步的風(fēng)險挖掘。

基于風(fēng)險的定義，我們提出了一個“風(fēng)險場景”的新概念，它是風(fēng)險預(yù)警環(huán)節(jié)的核心因素。

1.風(fēng)險告警——事前

針對上圖右方的三種異常，不同人員的關(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)險場景的實(shí)體關(guān)聯(lián)了三個要素，分別是規(guī)則表達(dá)式、監(jiān)控指標(biāo)和告警、預(yù)案和快恢。

• 規(guī)則表達(dá)式：作用是向穩(wěn)定性負(fù)責(zé)人和老板提出異常定義，類似于物理公式，在計(jì)算某個值的時候會先給出一個公式。對于穩(wěn)定性負(fù)責(zé)人和老板來說，他們并不關(guān)心公式的值，但這個公式能明確表達(dá)當(dāng)成功率低于某個值的時候，就可以進(jìn)行風(fēng)險認(rèn)定。
• 監(jiān)控指標(biāo)和告警：基于規(guī)則表達(dá)式，研發(fā)需要補(bǔ)全相關(guān)信息。因?yàn)橐?guī)則表達(dá)式本身只是一個定義和公式，在具體計(jì)算時需要關(guān)聯(lián)對應(yīng)的指標(biāo)。監(jiān)控指標(biāo)告警與三個概念相關(guān)聯(lián)，一是指標(biāo)，二是告警，三是監(jiān)控實(shí)體。這個實(shí)體涉及變更和定位，能夠表達(dá)規(guī)則表達(dá)式當(dāng)中的異常關(guān)聯(lián)在哪個實(shí)體上，也可以確定哪個監(jiān)控實(shí)體或哪個應(yīng)用實(shí)體發(fā)生了異常。基于風(fēng)險場景，規(guī)則表達(dá)式能表達(dá)異常的定義，監(jiān)控指標(biāo)告警則關(guān)聯(lián)表達(dá)式，實(shí)現(xiàn)基礎(chǔ)的計(jì)算能力。
• 預(yù)案和快恢：通過人工預(yù)案的快恢綁定，也可以通過自動化預(yù)案綁定。當(dāng)它觸發(fā)某個場景時，通過整個信息流轉(zhuǎn)，集成到整個快恢平臺的能力內(nèi)，置于風(fēng)險場景上，就能解決事前的配置化工作，類似于獲得一本操作手冊，避免運(yùn)行時標(biāo)準(zhǔn)化層面的不一致。

綜上所述，我們提出了一個對應(yīng)的配置頁面，除了場景外，還會引入值班組和預(yù)警節(jié)點(diǎn)。預(yù)警節(jié)點(diǎn)即CMDB，用于定義整個業(yè)務(wù)、部門或應(yīng)用預(yù)警的節(jié)點(diǎn)。

• 場景和值班組的關(guān)系：值班組包括對應(yīng)的管理者，處理對應(yīng)問題的企業(yè)微信協(xié)同群及對應(yīng)的升級側(cè)。響應(yīng)機(jī)制是5分鐘未接手就升級至負(fù)責(zé)人，10分鐘未接手則升級至leader。一個風(fēng)險的預(yù)警節(jié)點(diǎn)可關(guān)聯(lián)多個值班組和多個場景。
• 值班組的職能：處理預(yù)警節(jié)點(diǎn)所對應(yīng)的場景信息，比如一個大團(tuán)隊(duì)設(shè)置了3個值班組，則每個值班組需要處理其中的4個異常場景。通過這些關(guān)聯(lián)的指標(biāo)配置，可清晰定義這個節(jié)點(diǎn)下需要負(fù)責(zé)的具體值班組和具體的異常場景，關(guān)注點(diǎn)有可能重疊，比如老板的視角會關(guān)注所有的場景異常。

通過場景的定義、值班組和預(yù)警節(jié)點(diǎn)的概念，我們整合出了風(fēng)險預(yù)警的三個核心概念，即哪些值班組在哪個預(yù)警節(jié)點(diǎn)要處理哪些場景的異常。有了該定義，在事前就能較好梳理風(fēng)險點(diǎn)的具體位置以及人員職責(zé)，避免上文所述的告警混亂和渠道不一致問題。

2.風(fēng)險告警——事中

• 報警推送

場景觸發(fā)異常時，第一個消息就是報警推送。收到告警后，我們會在群里推送一套標(biāo)準(zhǔn)化流程的卡片，標(biāo)準(zhǔn)化的格式是標(biāo)題內(nèi)容、告警時間渠道以及最近變更成員，然后進(jìn)行一定的標(biāo)準(zhǔn)行為操作，比如遇到風(fēng)險需要接手并響應(yīng)，加入一個應(yīng)急的協(xié)同群。通過對接不同的監(jiān)控系統(tǒng)，我們可以清晰定義監(jiān)控和告警的實(shí)體以及用戶關(guān)心的內(nèi)容。針對來自MySQL、SLO、Alarm、公司內(nèi)部前端的告警和普通的告警，會適配不同的模板，由渠道統(tǒng)一推送。

主要貢獻(xiàn)：統(tǒng)一流程、整合能力、提供協(xié)同、適配渠道、精準(zhǔn)觸達(dá)、

• 行為同步

由于我們已經(jīng)明確“標(biāo)準(zhǔn)SOP體系下的風(fēng)險處理”定義，所以告警出現(xiàn)后，自然有人接手。之后再進(jìn)行轉(zhuǎn)交，并在排查過程中機(jī)型信息的錄入與同步，也可以告知他人自己遇到的問題，這些信息都會在群中同步，如此便實(shí)現(xiàn)了事件的閉環(huán)。我們還提供了催辦升級能力，同步廣播進(jìn)展，進(jìn)行統(tǒng)一的度量。若整個群做到了以上幾點(diǎn)，那么在老板視角就可以及時獲知問題，是否有人處理和響應(yīng)等。研發(fā)也能互相協(xié)同，因?yàn)橐粋€平臺由多個研發(fā)負(fù)責(zé)，在這個平臺中我們可以了解問題的跟進(jìn)詳情，問題根因來自誰等，可便于在群中做進(jìn)一步的溝通。

主要貢獻(xiàn)：閉環(huán)事件、催辦升級、廣播進(jìn)展、統(tǒng)一度量、信息透明

• 預(yù)警詳情

除了簡短的卡片信息外，還會提供一些對應(yīng)的技術(shù)指標(biāo)，比如針對SLO的告警，我們提供了一個相關(guān)接口錯誤碼的指標(biāo)時序圖，以方便研發(fā)在預(yù)警詳情中通過一個頁面查看過往大量平臺的信息。表面上是平臺整合，但實(shí)際上是通過標(biāo)準(zhǔn)的SOP流程明確定義需要關(guān)注的平臺，并且借助算法和工程能力查出具體的指標(biāo)錯誤，同時提供一定的根因分析和預(yù)案快恢能力。根因分析和預(yù)案快恢的完整行動路線都會通過信息同步的方式在群中進(jìn)行協(xié)同處理，以避免由于信息不一致而導(dǎo)致操作失誤。

• 預(yù)警列表

方便用戶在群中快速得知哪些預(yù)警仍未完結(jié)，通過一個較為標(biāo)準(zhǔn)的處理流程，就能妥當(dāng)?shù)靥幚盹L(fēng)險。即使一個研發(fā)缺乏一定的風(fēng)險處理能力，但借助這套產(chǎn)品也能極快地處理風(fēng)險，降低整個業(yè)務(wù)的風(fēng)險。

對于整個風(fēng)險預(yù)警產(chǎn)品，我們不僅做了標(biāo)準(zhǔn)的SOP流程，還從變更層面挖掘了信息的拓?fù)淠芰Α?/p>

• 快恢覆蓋

快恢即在整個恢復(fù)過程中所執(zhí)行的手段，回滾最為常見，因?yàn)槌^73%的故障和風(fēng)險基本上都由變更引起。此外還有中間件和基礎(chǔ)設(shè)施的運(yùn)維操作，以及標(biāo)準(zhǔn)化預(yù)案平臺的接入。

通過這些覆蓋，我們在整個事中可以做到賦予研發(fā)更多處理問題的手段和能力，借助變更覆蓋和監(jiān)控覆蓋，結(jié)合拓?fù)涓采w，我們就能嘗試幫助用戶定位風(fēng)險的誘因。

圖右側(cè)展示了風(fēng)險預(yù)警的定位能力以及對應(yīng)的覆蓋能力。通過定位，能將內(nèi)容快速推送到群中；通過接口的監(jiān)控，告知指標(biāo)在同環(huán)比增加的比率，最后幫助用戶發(fā)現(xiàn)問題。

如果上下游出現(xiàn)異常，拓?fù)涓采w也能定位。若你的應(yīng)用發(fā)現(xiàn)異常，我們會幫你檢測有無做過對應(yīng)的變更，若無變更，則通過拓?fù)湫畔蓽y周圍鏈路上發(fā)生的變更，給出一定的推薦，幫助用戶找到對應(yīng)的人員，從而快速解決問題。

而在快恢層面，我們也會同步所有信息，在整個群中做協(xié)同，以避免研發(fā)在重復(fù)操作或者信息不同步不對稱的情況下，導(dǎo)致故障或風(fēng)險的二次發(fā)生。

3.風(fēng)險告警——事后

有了恰當(dāng)?shù)呐渲煤褪轮械奶幚恚ㄟ^相對簡單的方式便能度量事后的數(shù)據(jù)。

接手時長、接手率、完結(jié)時長以及完結(jié)率是四個非常核心的技術(shù)指標(biāo)，透過這些指標(biāo)即能感知每個部門的情況。我們會根據(jù)這些情況去溝通，加深對產(chǎn)品的了解，思考產(chǎn)品能夠持續(xù)優(yōu)化的各個方向和層面。

事前涉及基礎(chǔ)設(shè)施的風(fēng)險覆蓋、中間件的風(fēng)險覆蓋、應(yīng)用的風(fēng)險覆蓋以及SLO的風(fēng)險覆蓋，事中的核心度量就是接手率、完結(jié)率和轉(zhuǎn)故障數(shù)。事后則會度量有效率和場景治理。

場景治理包括兩方面，一是正召回，二是負(fù)向召回。正召回即召回誤告的告警，負(fù)向召回即需要填充未被發(fā)覺的告警。事后的度量完成后，整個風(fēng)險就能產(chǎn)生一個新的閉環(huán)，從而解決風(fēng)險的遺漏風(fēng)險、告警的失效，以及人員的治理問題，最終就能解決整個風(fēng)險。

三、風(fēng)險預(yù)警的產(chǎn)品架構(gòu)&技術(shù)架構(gòu)

1.風(fēng)險預(yù)警總體架構(gòu)

2.風(fēng)險預(yù)警技術(shù)架構(gòu)

最底層是人員組織的管理，用于表明公司的人員信息；CMDB即預(yù)警節(jié)點(diǎn)的節(jié)點(diǎn)能力，也會搭建基礎(chǔ)服務(wù)，以便為上層服務(wù)提供權(quán)限。場景管理再往上，則會通過一些微服務(wù)（如核心的場景管理）實(shí)現(xiàn)整個場景的數(shù)據(jù)配置化能力。

• 監(jiān)控管理：提供一個標(biāo)準(zhǔn)的監(jiān)控模型，把不同的監(jiān)控系統(tǒng)接入到整個平臺中；
• 值班管理：Oncall值班組的能力；
• 變更管理：不但承載封網(wǎng)管控能力，還負(fù)責(zé)變更信息的錄入。在最底層的業(yè)務(wù)設(shè)計(jì)基礎(chǔ)上，分為四部分，分別是配置管理、處理風(fēng)險、定位恢復(fù)和數(shù)據(jù)度量；
• 配置管理：管理場景、CMDB、人員組織和值班表的相關(guān)關(guān)系，提供風(fēng)險挖掘和故障防控的能力；
• 處理風(fēng)險：除消息推送、應(yīng)急協(xié)同和催辦升級外，也能聚焦于快恢能力。我們的產(chǎn)品主要是解耦式的設(shè)計(jì)，可以支持外部系統(tǒng)做對應(yīng)的推送。以MySQL為例，這種場景下如果要做定位，有了解耦式的設(shè)計(jì)，就能通過DBA自行診斷整合到我們風(fēng)險預(yù)警的應(yīng)急流程處理中去，更好地服務(wù)于研發(fā)和SRE，幫助他們解決這個問題。

通過整套技術(shù)架構(gòu)以及領(lǐng)域劃分的設(shè)計(jì)，它的橫向拓展性相對會更好。針對后續(xù)的一些用戶訴求，不管是SRE老板、運(yùn)維穩(wěn)定性負(fù)責(zé)人還是一線研發(fā)，都會在這個產(chǎn)品中承擔(dān)不同的角色，并滿足不同的訴求。

Q&A

Q1: 影響范圍、上下文和診斷信息等告警信息是否都會給出？

A1：我們有一定的拓?fù)淠芰Γ瑫衙恳粋€節(jié)點(diǎn)封裝成一個對應(yīng)的實(shí)體，這個實(shí)體會關(guān)聯(lián)對應(yīng)的中間件依賴以及上下游的依賴。當(dāng)我們接入一個告警信息時，它的上下游信息會根據(jù)HTTP和RPC的標(biāo)準(zhǔn)指標(biāo)將紅色的異常節(jié)點(diǎn)進(jìn)行定義，在告警信息中給出對應(yīng)的診斷。

由于它依賴指標(biāo)的計(jì)算所以在技術(shù)上使用了異步模式，當(dāng)它推送告警信息后，如果它在1~2分鐘內(nèi)判斷出大概的影響范圍和上下文，就會補(bǔ)充診斷信息，將可能導(dǎo)致告警的原因告知用戶——自身應(yīng)用導(dǎo)致還是上游檢測出的依賴方的調(diào)用出現(xiàn)了環(huán)比的突增？最終都會給出診斷。

Q2：如何確認(rèn)預(yù)警告警本身的準(zhǔn)確性和有效性？

A2：首先我們會通過風(fēng)險的挖掘，告知用戶具體的風(fēng)險。在出現(xiàn)風(fēng)險告警時，研發(fā)確實(shí)會接收到大量的無效告警，但在我們的處理過程中，會有一個閉環(huán)，在風(fēng)險度量時就能看出哪些是誤告率極高的告警，所以這時透過周報就能看到相關(guān)信息，從而篩選出準(zhǔn)確有效的告警，并通過數(shù)據(jù)的閉環(huán)幫助用戶做對應(yīng)的治理。

你也可以一鍵優(yōu)化規(guī)則，或者通過屏蔽無效告警、比如代碼屏蔽errorCode的方式來確認(rèn)，比如用戶未登錄而執(zhí)行某些結(jié)果導(dǎo)致鑒權(quán)報錯，針對這種情況就可以用上述的方法。

因此，數(shù)據(jù)閉環(huán)的作用是驅(qū)使研發(fā)自閉環(huán)地判斷告警本身的準(zhǔn)確性和有效性，并據(jù)此做對應(yīng)的治理，這是整個風(fēng)險預(yù)警的重要貢獻(xiàn)之一。

Q3：預(yù)警對故障的容忍度如何，怎樣設(shè)置閾值？

A3：首先，中間件異常和基礎(chǔ)設(shè)施異常也有可能不影響業(yè)務(wù)故障，比如四臺機(jī)器掛兩臺，如果流量不高，則業(yè)務(wù)上可能無感知，我們會把這方面劃分在預(yù)警的領(lǐng)域內(nèi)。至于容忍度，則需要SRE制定一個標(biāo)準(zhǔn)的SLI，因?yàn)樗赡芡ㄟ^pv/uv、或者一些資損得到一個對應(yīng)的結(jié)果，因此若SLI認(rèn)為某個指標(biāo)的成功率低于90%則為故障，那么對預(yù)警而言，可能就會將值設(shè)置為95%或96%，具體基于研發(fā)對自己系統(tǒng)業(yè)務(wù)上的規(guī)則定義。

注意以下兩點(diǎn)：容忍度必須比故障更高一些，比如故障的指標(biāo)是90%，你就可以設(shè)置95%時發(fā)出一條預(yù)警，思考低于95%時是否需要開始介入，以避免發(fā)生更進(jìn)一步的故障；比如宿主機(jī)發(fā)生異常，或者整個中間的鏈路上分支環(huán)節(jié)上出現(xiàn)異常的時候，可能還未對故障的指標(biāo)產(chǎn)生影響，通過預(yù)警就能迅速容忍故障的發(fā)生。這就是它能防控故障的原因，因?yàn)樗龅搅藢鼍皹I(yè)務(wù)更為精細(xì)化的管理。

Q4：發(fā)生雪崩效應(yīng)大面積告警故障時，能否快速定位故障源，具體如何實(shí)現(xiàn)？

A4：無論從內(nèi)部復(fù)盤還是整個行業(yè)的經(jīng)驗(yàn)上看，絕大部分的大面積故障都源于兩方面，一方面是變更，另一方面則是運(yùn)維的操作，運(yùn)維操作也可以定義為變更，一個是發(fā)代碼，一個是發(fā)配置。

基于這兩點(diǎn)，我們接入了變更的整個拓?fù)鋽?shù)據(jù)，還接入了CMDB。CMDB是配置時的拓?fù)湫畔ⅲ\(yùn)行時則是通過分析 Discovery數(shù)據(jù)拓?fù)洹粋€鏈路的實(shí)時動態(tài)和調(diào)用關(guān)系，將它們結(jié)合分析，基本上就能基于告警的爆炸中心找到對應(yīng)上下游的變更情況，以及對應(yīng)的核心指標(biāo)。以應(yīng)用為例，我們定義了HTTP和RPC，就能快速定位可能存在的故障源，不過這只是一種可能。整個底層模型是一個拓?fù)涞臉湫谓Y(jié)構(gòu)，當(dāng)它發(fā)現(xiàn)最頂層的異常時，通過分析依賴關(guān)系可以通過快速找到對應(yīng)的故障點(diǎn)，因?yàn)槲覀冋J(rèn)為往下都是果，最頂層才是因。

Q5：為什么要有風(fēng)險的概念？用這套流程來做故障處理不是同樣可以嗎？

A5：風(fēng)險和故障之間有比較明確的界定，不影響業(yè)務(wù)的異常（如中間件的異常）更需要研發(fā)關(guān)注。比如我有六個下游做同一件事情，每個下游是六分之一的分流，且有兩個下游異常，這時業(yè)務(wù)并不感知，但是它可以通過風(fēng)險來處理，因?yàn)榱鶄€業(yè)務(wù)中有兩個供應(yīng)商可能異常，這需要我們定義。

風(fēng)險有可能影響業(yè)務(wù)，但不足以啟動整個故障的流程處理。所以我們提出風(fēng)險自閉環(huán)能力，它并不是一個管控手段，而故障更多的是一種行政管控手段，可以將它理解為一個獎懲機(jī)制。你觸發(fā)了故障，就要按照標(biāo)準(zhǔn)的流程處理，必須第一時間解決問題，必須要復(fù)盤，最后計(jì)入穩(wěn)定性分析，可能還會有各種各樣的掛鉤，但風(fēng)險始終是自閉環(huán)。

故障確實(shí)有部分協(xié)同與風(fēng)險一致，但在數(shù)據(jù)度量以及對應(yīng)的手段上，故障本身不需要接入一些中間件、基礎(chǔ)設(shè)施或者指標(biāo)自定義的告警，它接入更多的是強(qiáng)勢的業(yè)務(wù)管理，比如交易成功率低于多少，下單成功率或者彈幕的發(fā)送成功率低于多少等，這是與風(fēng)險的最大區(qū)別。

Q6：事件變更如何要求所有業(yè)務(wù)的變更都去變更平臺錄入變更信息？若不錄入，他們就無法進(jìn)行變更嗎？

A6：我們不會找所有的業(yè)務(wù)，而是對接整個公司，比如應(yīng)用的發(fā)布平臺、編譯平臺以及配置的發(fā)布平臺，以及數(shù)據(jù)庫的DDL變更，把整個變更平臺的信息視作標(biāo)準(zhǔn)化的結(jié)構(gòu)錄入。

Q7：故障的影響范圍如何快速評估？

A7：故障影響范圍的快速評估主要通過四種方式，第一是監(jiān)控指標(biāo)，整個業(yè)務(wù)會不斷地在應(yīng)急協(xié)同群中反饋哪些業(yè)務(wù)受影響。第二種，比如我做了網(wǎng)絡(luò)變更，導(dǎo)致網(wǎng)絡(luò)異常，但我知道網(wǎng)絡(luò)有可能會影響哪些業(yè)務(wù)，所以故障的影響方本身也可以做到影響范圍的快速評估。第三即拓?fù)淠芰Γ梢钥焖倮稣麄€鏈路的影響范圍。但在實(shí)戰(zhàn)過程中，如果遇到了大故障，我們的定位系統(tǒng)壓力極大，基本算不過來，這種情況就無需再定位，因?yàn)橛绊懨嫣珡V，大家基本已全部得知。第四種即客情，一旦出現(xiàn)大故障，在微博上必定會出現(xiàn)客情，產(chǎn)生一定的社會影響面，所以可以借助整個社會的反饋來做評估。

Q8：風(fēng)險預(yù)警的定義門檻比故障更低，如何讓技術(shù)人員對風(fēng)險預(yù)警足夠重視，又不至于被過多的預(yù)警轟炸到麻木？

A8：首先，我們產(chǎn)品的核心與故障有本質(zhì)區(qū)別，故障更多的是一種管控手段，風(fēng)險預(yù)警則是我們給研發(fā)提供自閉環(huán)風(fēng)險的概念，也就是說，理論上研發(fā)對風(fēng)險預(yù)警擁有接收自由，我們并沒有強(qiáng)制研發(fā)一定要接收風(fēng)險預(yù)警。

針對整個風(fēng)險預(yù)警的定義，它是一個產(chǎn)品，用于幫助技術(shù)人員或者研發(fā)等不同的角色提高風(fēng)險對應(yīng)的管理能力。故障相對而言強(qiáng)制性更強(qiáng)，對公司來說可以稱為一種政治手段。風(fēng)險預(yù)警是一個產(chǎn)品化的能力，它幫助技術(shù)人員去做這個事情。技術(shù)人員可能是最底層的一線技術(shù)人員，也可能是技術(shù)人員的老板，希望通過風(fēng)險預(yù)警提供一個抓手，提高整個團(tuán)隊(duì)對風(fēng)險的管控能力。他也有可能是穩(wěn)定性負(fù)責(zé)人，希望更快獲知風(fēng)險。

這個產(chǎn)品提供了一定的技術(shù)能力，并且將在后續(xù)的迭代中不斷豐富，比如更精準(zhǔn)的定位能力、更精準(zhǔn)的快恢、接入更多的快恢平臺，制定恢復(fù)預(yù)案等，將這些技術(shù)能力整合在一起，幫助技術(shù)人員更好地解決風(fēng)險。借助該產(chǎn)品，他們可以迅速獲得業(yè)務(wù)結(jié)果，以最小的成本實(shí)現(xiàn)穩(wěn)定性的建設(shè)。如果他們意識到以上的好處，他們也會認(rèn)同并相信風(fēng)險預(yù)警能解決對應(yīng)的業(yè)務(wù)痛點(diǎn)。

至于如何避免被過多的預(yù)警轟炸到麻木，第一配置成本會調(diào)高；第二，我們會進(jìn)行數(shù)據(jù)復(fù)盤，在整個大盤中告知哪些預(yù)警的規(guī)則可能存在問題。我們不會讓用戶簡單地打標(biāo)告警有效或無效，會闡述清楚是抖動還是監(jiān)控異常，或是規(guī)則不合理，還是偶發(fā)事件無需處理等等一系列原因，幫助研發(fā)通過整個大盤的數(shù)據(jù)得知自己上周的應(yīng)急協(xié)同數(shù)據(jù)，即獲知每天處理的風(fēng)險數(shù)量以及有效率，哪些風(fēng)險需要重視等，通過一個閉環(huán)清除無效的告警，幫助研發(fā)挖掘更多可能需要覆蓋的風(fēng)險點(diǎn)。綜上所述，當(dāng)技術(shù)人員認(rèn)為這個產(chǎn)品對他有幫助，他就會自發(fā)使用。

谷林濤

嗶哩嗶哩 

基礎(chǔ)架構(gòu)部 資深開發(fā)工程師

B站事件運(yùn)營中心研發(fā)負(fù)責(zé)人，負(fù)責(zé)建設(shè)Bilibili內(nèi)部穩(wěn)定性平臺產(chǎn)品，提升線上問題的應(yīng)急協(xié)同效能。同時負(fù)責(zé)工單、封網(wǎng)管控、拓?fù)涠ㄎ划a(chǎn)品，總體保障業(yè)務(wù)系統(tǒng)的安全生產(chǎn)。