隨著B站近幾年的快速發(fā)展，業(yè)務(wù)規(guī)模越來(lái)越大，迭代速度越來(lái)越快，系統(tǒng)運(yùn)行復(fù)雜度也越來(lái)越高。線上每天都會(huì)發(fā)生各種各樣的故障，且發(fā)生的場(chǎng)景越來(lái)越刁鉆。為了應(yīng)對(duì)這種情況，保障業(yè)務(wù)在任何時(shí)刻都能將穩(wěn)定性維持在一個(gè)高基線之上，B站專門成立了SRE體系團(tuán)隊(duì)，在提升業(yè)務(wù)穩(wěn)定性領(lǐng)域進(jìn)行了全方位、體系化的積極探索，從理論性支撐和能力化建設(shè)進(jìn)行著手，從故障應(yīng)急響應(yīng)、事件運(yùn)營(yíng)、容災(zāi)演練、意識(shí)形態(tài)等多方面進(jìn)行穩(wěn)定性運(yùn)營(yíng)體系的構(gòu)筑。

本次分享主題是B站SRE在穩(wěn)定性方面的運(yùn)營(yíng)實(shí)踐，分享內(nèi)容分為以下幾個(gè)部分：

• 案例剖析
• 從應(yīng)急響應(yīng)看穩(wěn)定性運(yùn)營(yíng)
• 核心運(yùn)營(yíng)要素有哪些
• 兩個(gè)運(yùn)營(yíng)載體：OnCall與事件運(yùn)營(yíng)中心
• 挑戰(zhàn)與收益

一、案例剖析

多年來(lái)業(yè)界同仁針對(duì)穩(wěn)定性這一話題進(jìn)行了大量的探索和實(shí)踐，業(yè)界不乏針對(duì)穩(wěn)定性保障相關(guān)的討論和研究。在圍繞穩(wěn)定性的實(shí)踐上，大家也經(jīng)常聽到諸如混沌工程、全鏈路壓測(cè)、大促活動(dòng)保障和智能監(jiān)控等話題的分享。B站在這些方面也做了很多建設(shè)工作，今天我將從應(yīng)急響應(yīng)的角度切入，和大家分享B站在穩(wěn)定性運(yùn)營(yíng)方面所做的工作。

我們先來(lái)看兩個(gè)案例，案例以真實(shí)事件為依托，相關(guān)敏感內(nèi)容進(jìn)行了改寫。

案例一

1）背景

一個(gè)手機(jī)廠商的發(fā)布會(huì)在某天晚上12點(diǎn)舉辦，B站承接了該品牌的線上發(fā)布會(huì)直播。公司的運(yùn)營(yíng)同學(xué)提前就配置好了12點(diǎn)的直播活動(dòng)頁(yè)面以及準(zhǔn)點(diǎn)的應(yīng)用內(nèi)Push消息。在12點(diǎn)到來(lái)之后，直播活動(dòng)頁(yè)推送生效，大量用戶收到應(yīng)用內(nèi)推送消息，點(diǎn)擊進(jìn)入直播活動(dòng)頁(yè)面。

2）故障始末

12點(diǎn)01分，直播活動(dòng)頁(yè)內(nèi)嵌的播放器無(wú)法支持部分用戶正常加載播放。

12點(diǎn)03分，研發(fā)同學(xué)李四收到了異常的報(bào)警，開始介入處理。

12點(diǎn)04分，客服同學(xué)收到了大量有關(guān)發(fā)布會(huì)無(wú)法正常播放的用戶反饋，常規(guī)處理方法無(wú)法解決用戶問題。

影響持續(xù)到12點(diǎn)15分，研發(fā)同學(xué)李四還在排查問題的具體原因，沒有執(zhí)行相對(duì)應(yīng)的止損預(yù)案（該種問題有對(duì)應(yīng)預(yù)案），問題持續(xù)在線上造成影響。

直到12點(diǎn)16分，老板朋友找到了老板反饋今晚B站的某品牌手機(jī)直播發(fā)布會(huì)頁(yè)面視頻無(wú)法正常播放，此時(shí)老板開始從上往下詢問，研發(fā)leader知道了這件事，開始聯(lián)系SRE同學(xué)介入問題處理，并及時(shí)執(zhí)行了相關(guān)的切換預(yù)案，直播活動(dòng)頁(yè)面播放恢復(fù)正常。

3）問題

在這個(gè)案例中，暴露了以下一些問題：

• 故障的相關(guān)告警雖然及時(shí)，但是并沒有通知到足夠多對(duì)的人。
• 該故障的告警，在短時(shí)間沒有處理響應(yīng)后，并未進(jìn)行有效的結(jié)構(gòu)性升級(jí)（管理升級(jí)，及時(shí)讓更高level的人參與進(jìn)來(lái)，知曉故障影響，協(xié)調(diào)處理資源）和職能性升級(jí)（技術(shù)升級(jí)，讓更專業(yè)和更對(duì)口的人來(lái)參與響應(yīng)處理，如team leader、SRE等）。
• 一線同學(xué)往往容易沉迷于查找問題根因，不能及時(shí)有效地對(duì)故障部位進(jìn)行預(yù)案執(zhí)行。

案例二

1）背景

一個(gè)平淡無(wú)奇的周末晚上，23點(diǎn)30分，監(jiān)控系統(tǒng)觸發(fā)大量告警，幾乎全業(yè)務(wù)線、各架構(gòu)層都在觸發(fā)告警。

2）故障始末

23點(diǎn)40分，企業(yè)微信拉了有十幾個(gè)群，原有的業(yè)務(wù)溝通群、基礎(chǔ)服務(wù)OnCall群，都在不停地轉(zhuǎn)發(fā)告警，詢問情況。整個(gè)技術(shù)線一片恐慌，起初以為是監(jiān)控系統(tǒng)炸了。此時(shí)相關(guān)故障的SRE同學(xué)已經(jīng)被拉到某一個(gè)語(yǔ)音會(huì)議中。

注意，此時(shí)公司的多個(gè)BU業(yè)務(wù)線同學(xué)都炸鍋了，到處咨詢發(fā)生了什么，業(yè)務(wù)怎么突然就不炸了。又過(guò)了幾分鐘，資深的SRE同學(xué)又拉了一個(gè)大群，把相關(guān)業(yè)務(wù)對(duì)接人都拉進(jìn)群里，開始整體說(shuō)明故障情況。此時(shí)，該同學(xué)也比較糾結(jié)如何通報(bào)和說(shuō)明這個(gè)問題，因?yàn)榇藭r(shí)沒有一個(gè)明確故障定位，語(yǔ)言很難拿捏，各個(gè)高level的老板也都在問（已上熱搜）。并且，負(fù)責(zé)恢復(fù)入口服務(wù)的一線同學(xué)把故障預(yù)案執(zhí)行了個(gè)遍，發(fā)現(xiàn)無(wú)濟(jì)于事。后續(xù)在GSLB調(diào)度層，執(zhí)行了整個(gè)跨機(jī)房的流量有損切換才讓服務(wù)逐漸恢復(fù)正常。

凌晨之后，原有機(jī)房的問題定位出來(lái)了，補(bǔ)丁迅速打上，異常的問題徹底修復(fù)了。后續(xù)，在對(duì)此事件進(jìn)行復(fù)盤時(shí)，發(fā)現(xiàn)困難重重。因?yàn)楣收咸幚磉^(guò)程中，涉及到大量的服務(wù)、組件和業(yè)務(wù)方，并且大家當(dāng)時(shí)拉了一堆群，同樣的消息被發(fā)送到了很多群。參與處理故障的同學(xué)在語(yǔ)音、電話和企微群都有進(jìn)行過(guò)溝通和處理進(jìn)展發(fā)布，整個(gè)事件的細(xì)節(jié)整理起來(lái)非常耗費(fèi)人力和精力，準(zhǔn)確性也很難保障。

3）問題

• 在上面這個(gè)案例中，我們可以看到整個(gè)故障從發(fā)生、處置到結(jié)束后復(fù)盤，都存在以下問題：
• 當(dāng)一個(gè)影響面比較大的故障產(chǎn)生時(shí)，大家沒有統(tǒng)一的故障進(jìn)展同步方式，依托原始的人工拉群，人工找相關(guān)人員電話聯(lián)系，導(dǎo)致了故障最新的進(jìn)展情況只能夠在小范圍傳播擴(kuò)散，無(wú)法統(tǒng)一對(duì)外公布，并且在傳播過(guò)程中，很容易消息失真；
• 在故障處理過(guò)程中，缺少主要協(xié)調(diào)人（故障指揮官）。像這種大型故障，需要有一個(gè)人能夠去協(xié)調(diào)各層人員分工、消息收斂、服務(wù)業(yè)務(wù)情況等，這個(gè)人需要能夠掌控整個(gè)故障的所有消息和全貌進(jìn)展；
• 在故障處理過(guò)程中，缺乏故障上下文的信息關(guān)聯(lián)，大家難以知曉故障發(fā)生的具體位置，只是感知到自己的業(yè)務(wù)受損了，自己的服務(wù)可能有異常，這導(dǎo)致整個(gè)故障的定位時(shí)間被拉長(zhǎng)；
• 在故障恢復(fù)之后，我們對(duì)這個(gè)故障進(jìn)行復(fù)盤時(shí)，發(fā)現(xiàn)故障處理過(guò)程中的信息太過(guò)零散，復(fù)盤成本很高。

案例剖析

通過(guò)對(duì)上述兩個(gè)案例的分析我們能夠發(fā)現(xiàn)，在故障發(fā)生前、處理中和結(jié)束后，各個(gè)階段都會(huì)有很多因素導(dǎo)致我們的故障不能被快速解決，業(yè)務(wù)不能快速恢復(fù)。

這里我們從故障的前、中、后三個(gè)階段總結(jié)可能存在的一些問題。

1）事前

• 告警信息量大，信息太過(guò)雜亂；
• 平臺(tái)系統(tǒng)繁多，變更信息無(wú)處收斂；
• 客服反饋的信息，需要靠人工去關(guān)聯(lián)，并反饋到技術(shù)線；
• 和公司輿情相關(guān)的信息，技術(shù)線很難感知到。

2）事中

• 一線同學(xué)過(guò)于關(guān)注技術(shù)，沉迷問題解決；
• 當(dāng)一個(gè)故障影響面擴(kuò)大之后，涉及多個(gè)團(tuán)隊(duì)的協(xié)同非常困難，最新的進(jìn)展消息無(wú)法及時(shí)有效地傳遞到相關(guān)人員手中；
• 當(dāng)參與一個(gè)故障處理的人員多了之后，多個(gè)人員之間缺乏協(xié)調(diào)，導(dǎo)致職責(zé)不清晰，產(chǎn)生事情漏做、重復(fù)做的問題；
• 故障處理過(guò)程中，會(huì)有一些不請(qǐng)自來(lái)，湊熱鬧的同學(xué)。

3）事后

• 當(dāng)我們開展復(fù)盤時(shí)，發(fā)現(xiàn)故障處理時(shí)又是群、又是電話、又是口頭聊，又是操作各種平臺(tái)和工具，做了很多事情，產(chǎn)生了很多信息，梳理時(shí)間線很繁瑣，還會(huì)遺漏，寫好一份完整的復(fù)盤報(bào)告非常麻煩；
• 拉一大堆人進(jìn)行復(fù)盤的時(shí)候，因?yàn)槿鄙俳Y(jié)構(gòu)化的復(fù)盤流程，經(jīng)常是想到什么問什么。當(dāng)某場(chǎng)復(fù)盤會(huì)，大家狀態(tài)好的時(shí)候，能挖掘的點(diǎn)很多。如果狀態(tài)不好或者大家意識(shí)上輕視時(shí)，復(fù)盤的效果就較差；
• 復(fù)盤后產(chǎn)出的改進(jìn)事項(xiàng)，未及時(shí)統(tǒng)一地記錄跟進(jìn)，到底有沒有完成，什么時(shí)間應(yīng)該完成，完成的情況是否符合預(yù)期都不得而知；
• 對(duì)于已經(jīng)修復(fù)的問題，是否需要演練驗(yàn)收確保真正修復(fù)。

以上三個(gè)階段中可能發(fā)生的各種各樣的問題，最終只會(huì)導(dǎo)致一個(gè)結(jié)果：服務(wù)故障時(shí)間增長(zhǎng)，服務(wù)的SLA降低。

二、從應(yīng)急響應(yīng)看穩(wěn)定性運(yùn)營(yíng)

針對(duì)上述問題，如何進(jìn)行有效改善？這是本部分要重點(diǎn)分享的內(nèi)容，從應(yīng)急響應(yīng)看穩(wěn)定性運(yùn)營(yíng)。

應(yīng)急響應(yīng)的概念較早來(lái)源于《信息安全應(yīng)急相應(yīng)計(jì)劃規(guī)范GB/T24363-2009》中提到的安全相關(guān)的應(yīng)急響應(yīng)，整體定義是“組織為了應(yīng)對(duì)突發(fā)/重大信息安全事件的發(fā)生所作的準(zhǔn)備，以及在事件發(fā)生后所采取的措施”。從這個(gè)概念我們延伸到穩(wěn)定性上就產(chǎn)生了新的定義，“一個(gè)組織為了應(yīng)對(duì)各種意外事件的發(fā)生所作的準(zhǔn)備以及在事件發(fā)生后所采取的措施和行為”。這些措施和行為，通常用來(lái)減小和阻止事件帶來(lái)的負(fù)面影響及不良后果。

三、核心運(yùn)營(yíng)要素有哪些

做好應(yīng)急響應(yīng)工作的核心目標(biāo)是提升業(yè)務(wù)的穩(wěn)定性。在這個(gè)過(guò)程中，我們核心關(guān)注4大要素。核心點(diǎn)是事件，圍繞事件有三塊抓手，分別是人、流程和工具/平臺(tái)。

人作為應(yīng)急響應(yīng)過(guò)程中參與和執(zhí)行的主體，對(duì)其應(yīng)急的意識(shí)和心態(tài)有很高要求。特別是在一些重大的故障處理過(guò)程中，不能因?yàn)閴毫Υ蠡蚓o張導(dǎo)致錯(cuò)誤判斷。

流程將應(yīng)急響應(yīng)的流程標(biāo)準(zhǔn)化，期望響應(yīng)人能夠按照既定階段的既定章程進(jìn)行有效的推進(jìn)和處理。

工具/平臺(tái)支撐人和流程的高效合規(guī)運(yùn)行，并將應(yīng)急響應(yīng)的過(guò)程、階段進(jìn)行度量，進(jìn)而分析和運(yùn)營(yíng)，推進(jìn)人和流程的改進(jìn)。

事件

1）生命周期劃分

要對(duì)故障進(jìn)行有效運(yùn)營(yíng)，就需要先明確故障的生命周期。通過(guò)劃分故障的生命周期，我們可以針對(duì)不同的周期階段進(jìn)行精準(zhǔn)聚焦，更有目的性地開展穩(wěn)定性提升工作。

針對(duì)故障生命周期的劃分有很多種方式，按故障的狀態(tài)階段劃分，可以分為事前、事中和事后。

按故障的流程順序劃分，可以分為故障防御、故障發(fā)生、故障響應(yīng)、故障定位和故障恢復(fù)、復(fù)盤改進(jìn)等階段。

這里我圍繞故障的時(shí)間階段，從故障不同階段的形態(tài)變化做拆分，將故障拆分為四個(gè)階段。

• 告警/變更/客訴

當(dāng)故障還未被確認(rèn)時(shí)，它可能是一個(gè)告警、變更或客訴。

• 事件

當(dāng)這個(gè)告警、變更、客訴被上報(bào)后，會(huì)產(chǎn)生一個(gè)事件，我們需要有人去響應(yīng)這個(gè)事件，此時(shí)一個(gè)真正的事件就形成了。

• 故障

當(dāng)事件的影響范圍逐漸擴(kuò)散，這時(shí)往往有大量的用戶、業(yè)務(wù)受到影響，我們需要將事件升級(jí)成故障，觸發(fā)故障的應(yīng)急協(xié)同，進(jìn)行一系列的定位、止損等工作。

• 改進(jìn)

故障最終會(huì)被恢復(fù)，接下來(lái)我們要對(duì)故障進(jìn)行復(fù)盤，產(chǎn)生相關(guān)改進(jìn)項(xiàng)，在改進(jìn)項(xiàng)被完成之后，還需要進(jìn)行相關(guān)的驗(yàn)收工作。

2）階段度量

從更科學(xué)的角度看，我們知道在運(yùn)營(yíng)工作中，度量是很關(guān)鍵的一點(diǎn)。管理學(xué)大師彼得·德魯克曾經(jīng)說(shuō)過(guò)：“你如果無(wú)法度量它，就無(wú)法管理它”。有效的度量指標(biāo)定義，可以幫助我們更好更快地開展運(yùn)營(yíng)工作、評(píng)估價(jià)值成果。上文中我們提到的3個(gè)階段是比較籠統(tǒng)的階段，接下來(lái)我將介紹更加具體和可執(zhí)行的量化拆分方法。

如上圖所示，從故障預(yù)防依次到故障發(fā)現(xiàn)，故障定位，故障恢復(fù)，最后到故障改進(jìn)，整體有兩個(gè)大的階段：MTBF（平均無(wú)故障時(shí)間）和MTTR（平均故障恢復(fù)時(shí)間）。我們進(jìn)行業(yè)務(wù)穩(wěn)定性運(yùn)營(yíng)的核心目標(biāo)就是降低MTTR，增加MTBF。根據(jù)Google的定義，我們將MTTR進(jìn)一步拆分為以下4個(gè)階段：

• MTTI：平均故障發(fā)現(xiàn)時(shí)間，指的是故障發(fā)生到我們發(fā)現(xiàn)的時(shí)間。
• MTTK：平均故障定位時(shí)間，指的是我們發(fā)現(xiàn)故障到定位出原因的時(shí)間。
• MTTF：平均故障修復(fù)時(shí)間，指的是我們采取恢復(fù)措施到故障徹底恢復(fù)的時(shí)間。
• MTTV：平均故障修復(fù)驗(yàn)證時(shí)間，指的是故障恢復(fù)之后通過(guò)監(jiān)控、用戶驗(yàn)證真實(shí)恢復(fù)的時(shí)間。

3）關(guān)鍵節(jié)點(diǎn)

基于階段度量的指標(biāo)，我們能夠得到一系列的關(guān)鍵時(shí)間節(jié)點(diǎn)。在不同的階段形態(tài)，事件和故障會(huì)存在一些差異。故障因?yàn)樾螒B(tài)更豐富，所存在的時(shí)間節(jié)點(diǎn)更多。上圖中定下來(lái)的時(shí)間，均是圍繞MTTR進(jìn)行計(jì)算的。主要是為了通過(guò)度量事件、故障的處理過(guò)程，發(fā)現(xiàn)過(guò)程中存在的問題點(diǎn)，并對(duì)問題點(diǎn)進(jìn)行精準(zhǔn)優(yōu)化，避免不知道如何切入去提升MTTR的問題，也方便我們對(duì)SRE的工作進(jìn)行側(cè)面考核。

人

人作為事件的一個(gè)主體，負(fù)責(zé)參與事件的響應(yīng)、升級(jí)、處置和消息傳播。

人通過(guò)上文中我們講到的OnCall參與到應(yīng)急響應(yīng)中。我們?cè)趦?nèi)部通過(guò)一套OnCall排班系統(tǒng)進(jìn)行這方面的管理。這套系統(tǒng)明確了內(nèi)部的業(yè)務(wù)、職能和人員團(tuán)隊(duì)，確保人員知道什么時(shí)間去值什么業(yè)務(wù)的班。下面的工具/平臺(tái)部分會(huì)展開介紹。對(duì)參與人的要求，主要有以下幾點(diǎn)：

• 具備良好的響應(yīng)意識(shí)和處理心態(tài)。
• 具備熟練地響應(yīng)執(zhí)行的經(jīng)驗(yàn)。

滿足以上特征，才能做到故障來(lái)臨時(shí)響應(yīng)不慌亂，有條不紊地開展響應(yīng)工作。

流程

那么針對(duì)人的要求如何實(shí)現(xiàn)？人員如何參與到應(yīng)急響應(yīng)的環(huán)節(jié)中去？人員的意識(shí)如何培養(yǎng)呢？

首先，我們內(nèi)部制定了應(yīng)急響應(yīng)白皮書，明確了以下內(nèi)容：

• 響應(yīng)流程；
• 基于事件大小，所要參與的角色和角色對(duì)應(yīng)的職責(zé)；
• 周邊各個(gè)子系統(tǒng)SOP制定的標(biāo)準(zhǔn)規(guī)范；
• 針對(duì)應(yīng)急過(guò)程中的對(duì)外通告內(nèi)容模板；
• 故障過(guò)程的升級(jí)策略。

之后，我們會(huì)周期性地在部門內(nèi)部、各BU進(jìn)行應(yīng)急響應(yīng)宣講，確保公司參與OnCall的同學(xué)能夠?qū)W習(xí)和掌握。另外，我們也會(huì)將其作為一門必修課加入新同學(xué)的入職培訓(xùn)中。最后就是故障演練，通過(guò)實(shí)操，讓沒有參與過(guò)故障處理的新同學(xué)能夠?qū)嶋H性地參與應(yīng)急響應(yīng)的過(guò)程，避免手生。

平臺(tái)

平臺(tái)作為支撐人與流程進(jìn)行高效、穩(wěn)定執(zhí)行的載體，我將在下一部分進(jìn)行具體描述。

四、兩個(gè)運(yùn)營(yíng)載體：OnCall與事件運(yùn)營(yíng)中心

這部分我將向大家分享B站在應(yīng)急響應(yīng)方面落地的兩個(gè)運(yùn)營(yíng)性平臺(tái)。

OnCall系統(tǒng)

OnCall系統(tǒng)，即值班系統(tǒng)。值班系統(tǒng)在日常運(yùn)轉(zhuǎn)過(guò)程中的作用往往被低估，SRE、工程效率做這部分建設(shè)時(shí)，很容易基于二維的方式對(duì)人和事進(jìn)行基于日歷的值班管理，并通過(guò)網(wǎng)頁(yè)、OpenAPI等方式對(duì)外提供數(shù)據(jù)服務(wù)。

下面我們通過(guò)幾個(gè)例子來(lái)說(shuō)明OnCall的必要性。

在日常工作中，當(dāng)我們使用公司某個(gè)平臺(tái)功能時(shí)，可能會(huì)習(xí)慣性找熟悉的同學(xué)，不管他這一天是不是oncall。這可能給那位同學(xué)帶來(lái)困擾，他可能上周才值完班，這周要專心于研發(fā)或者項(xiàng)目的推進(jìn)，你隨時(shí)找他可能打斷他的工作節(jié)奏。還有一種情況是新同學(xué)不知道該去找誰(shuí)，我們內(nèi)部之前經(jīng)常有這種情況，一個(gè)新來(lái)的同學(xué)接手一套系統(tǒng)之后，有問題不知道該找誰(shuí)，經(jīng)常要轉(zhuǎn)好幾手，才能找到對(duì)的人，這一過(guò)程很痛苦。

以上內(nèi)容總結(jié)起來(lái)就是總找一個(gè)人，總找不到人，除此之外，還會(huì)出現(xiàn)平臺(tái)找不到人的情況。這些問題的根源是什么呢？無(wú)非就是who、when、what和how的問題，不能在正確的時(shí)間為正確的事找到正確的人。

那么OnCall系統(tǒng)的重要性和必要性都體現(xiàn)在哪些方面呢？

• 有問題找不到人

隨著公司業(yè)務(wù)規(guī)模的擴(kuò)大和領(lǐng)域的細(xì)分，一些新的同學(xué)和新業(yè)務(wù)方往往會(huì)出現(xiàn)一個(gè)問題。不知道是哪些人負(fù)責(zé)，需要咨詢很多人才能找到具體解決問題的人。這一問題不僅限于故障，更存在于日常瑣事中。特別是SRE同學(xué)的日常，經(jīng)常會(huì)被研發(fā)同學(xué)咨詢找人拉群，戲稱拉群工程師。

• 下班不下崗

當(dāng)人們遇到問題時(shí)，經(jīng)常會(huì)下意識(shí)找熟悉的人。這就導(dǎo)致一些能力強(qiáng)、服務(wù)意識(shí)好的同學(xué)，總是在被人找。不論他今天值不值班，他將無(wú)時(shí)無(wú)刻都要面臨被人打擾的問題。除了被人找之外，內(nèi)部的監(jiān)控系統(tǒng)、流程系統(tǒng)，也會(huì)給不值班的同學(xué)發(fā)送監(jiān)控告警和流程審批信息。這也將SRE同學(xué)有50%的時(shí)間用于工程這一愿景變成泡影。

1）設(shè)計(jì)

① 明確關(guān)聯(lián)邏輯

針對(duì)上述兩種情況，我們對(duì)公司的業(yè)務(wù)、服務(wù)、職能和組織架構(gòu)進(jìn)行了分析建模，明確了人、團(tuán)隊(duì)、職能和業(yè)務(wù)之間的關(guān)聯(lián)關(guān)系。

② 建立三維合一模型

我們構(gòu)建起了一套三維合一的模型。由組織-業(yè)務(wù)、職能-人員、組織-職能的關(guān)聯(lián)關(guān)系，產(chǎn)生交匯點(diǎn)。值班人員會(huì)通過(guò)值班小隊(duì)的方式，落在這些交匯點(diǎn)上，并且基于業(yè)務(wù)和基礎(chǔ)架構(gòu)的異同點(diǎn)，通過(guò)業(yè)務(wù)視角和職能視角分別對(duì)外提供服務(wù)。

以我們公司內(nèi)部主站業(yè)務(wù)為例，我們會(huì)有專門的SRE小隊(duì)進(jìn)行日常的值班響應(yīng)，這個(gè)小隊(duì)只負(fù)責(zé)主站業(yè)務(wù)的值班響應(yīng)。通過(guò)這樣的對(duì)應(yīng)關(guān)系，當(dāng)人或平臺(tái)有需求的時(shí)候，都可以通過(guò)業(yè)務(wù)和職能關(guān)聯(lián)到對(duì)應(yīng)實(shí)踐的值班小隊(duì)，最終定位到具體的人，這樣也幫助我們將人藏了起來(lái)，更有利于后續(xù)SRE輪崗機(jī)制的推進(jìn)落地。

③ 雙視角提供服務(wù)

通過(guò)雙視角的設(shè)計(jì)，區(qū)分了職能型和業(yè)務(wù)型的不同值班方式和關(guān)注點(diǎn)。原因在于B站的業(yè)務(wù)層級(jí)組織模式是按照“組織->業(yè)務(wù)->應(yīng)用”這三級(jí)進(jìn)行組織的，所有的應(yīng)用歸屬到業(yè)務(wù)，業(yè)務(wù)歸屬到具體的組織架構(gòu)。

• 職能視角

前端采用樹型展示，組成結(jié)構(gòu)為組織->職能->覆蓋范圍（組織->業(yè)務(wù)->服務(wù)），值班表具體掛載在覆蓋范圍下，覆蓋范圍可以只有一級(jí)組織也可以精確到組織下面的業(yè)務(wù)或業(yè)務(wù)下面的服務(wù)。

• 業(yè)務(wù)視角

前端采用樹型展示，組織結(jié)構(gòu)為組織->業(yè)務(wù)->職能，值班表具體掛載在職能下面。

在日常工作中，基礎(chǔ)架構(gòu)相關(guān)的服務(wù)，比如SRE、DBA、微服務(wù)、監(jiān)控、計(jì)算平臺(tái)等強(qiáng)職能型服務(wù)會(huì)通過(guò)職能視角對(duì)外提供值班信息。當(dāng)業(yè)務(wù)人員有具體問題時(shí)，可以通過(guò)職能樹快速定位到具體的值班人員。而對(duì)于業(yè)務(wù)服務(wù)來(lái)講，日常的工作模式是圍繞業(yè)務(wù)開展的，因此會(huì)通過(guò)業(yè)務(wù)進(jìn)行展開，提供該業(yè)務(wù)下相關(guān)職能的對(duì)應(yīng)值班信息。

這兩個(gè)視角的底層數(shù)據(jù)是相通的，強(qiáng)職能相關(guān)服務(wù)提供方只需要維護(hù)好職能視角的值班信息，業(yè)務(wù)視角下的關(guān)聯(lián)會(huì)自動(dòng)生成。

2）功能展示

基于以上設(shè)計(jì)，我們內(nèi)部做了一套OnCall排班的系統(tǒng)。

這套系統(tǒng)是管理業(yè)務(wù)、職能和人的系統(tǒng)。我們基于上文中提到的幾個(gè)核心概念，在這些概念間建立了關(guān)系，分別是兩條線，一條是職能-團(tuán)隊(duì)和人，另外一條是職能-業(yè)務(wù)和服務(wù)。

系統(tǒng)提供了排班班組的管理，支持基于日歷的排班，同時(shí)支持班組設(shè)置主備oncall角色。在排班的細(xì)節(jié)上，我們支持基于時(shí)段進(jìn)行自動(dòng)排班計(jì)劃生成，也支持在一個(gè)職能里多個(gè)班組混合排班。另外，也支持對(duì)已經(jīng)排好班的班組，進(jìn)行覆蓋排班和換班，這個(gè)主要應(yīng)對(duì)oncall同學(xué)突然有事請(qǐng)假的情況。在oncall通知方面，我們支持了企業(yè)微信、電話等通知方式，并且支持虛擬號(hào)碼的方式，保護(hù)員工號(hào)碼不對(duì)外泄露。同時(shí)也避免了因?yàn)槭煜?dǎo)致的頻繁被打擾的情況。

在周邊生態(tài)方面，這套OnCall系統(tǒng)完全依賴周邊系統(tǒng)的接入。我們目前對(duì)接了內(nèi)部的告警系統(tǒng)、流程系統(tǒng)，確保告警和流程能夠只通知oncall人，而不形成騷擾。在企業(yè)微信的服務(wù)號(hào)中，也進(jìn)行了H5的頁(yè)面嵌入，在用戶通過(guò)企業(yè)微信反饋問題、找人時(shí)，知道當(dāng)下該找誰(shuí)。在各個(gè)接入的平臺(tái)，也內(nèi)嵌了OnCall的卡片頁(yè)面，明確告訴用戶本平臺(tái)當(dāng)前是誰(shuí)值班。通過(guò)這套OnCall系統(tǒng)的落地，我們明確了人、團(tuán)隊(duì)、職能和業(yè)務(wù)的概念，并將這些概念進(jìn)行了關(guān)系建立和對(duì)應(yīng)。人員通過(guò)排班班組統(tǒng)一對(duì)外為某個(gè)業(yè)務(wù)提供某項(xiàng)職能的值班響應(yīng)。通過(guò)前端的可視化，提供了日歷的值班展示效果，可以直觀看到某個(gè)業(yè)務(wù)所需要的某塊職能在某個(gè)時(shí)間點(diǎn)是由哪個(gè)班組在服務(wù)，周邊的各個(gè)系統(tǒng)也都對(duì)接OnCall系統(tǒng)，實(shí)現(xiàn)了人員響應(yīng)的統(tǒng)一管理，解決了某些人員認(rèn)人不認(rèn)事，不通過(guò)正規(guī)流程處理的問題。

事件運(yùn)營(yíng)中心

事件運(yùn)營(yíng)中心這套系統(tǒng)是我們基于ITIL、SRE、信息安全應(yīng)急計(jì)劃的事件管理體系，為了滿足公司對(duì)重大事件/故障的數(shù)字化管理，實(shí)現(xiàn)信息在線、數(shù)據(jù)在線和協(xié)同在線，使組織能夠具備體系化提升業(yè)務(wù)連續(xù)性能力所做的產(chǎn)品平臺(tái)。這個(gè)平臺(tái)的定位是一站式的SRE事件運(yùn)營(yíng)中心，數(shù)字化運(yùn)營(yíng)業(yè)務(wù)連續(xù)性的目標(biāo)是提升MTBF，降低MTTR，提高SLA。

1）架構(gòu)設(shè)計(jì)

上圖是我們平臺(tái)的模塊架構(gòu)圖，整體上還是圍繞上文提到的事件的事前、事中和事后三個(gè)階段拆分，覆蓋了一個(gè)事件產(chǎn)生、響應(yīng)、復(fù)盤、改進(jìn)的全生命周期。

• 事前

我們對(duì)事件進(jìn)行了4大類型的拆分，分別是告警、變更、客訴和輿情，然后通過(guò)設(shè)計(jì)標(biāo)準(zhǔn)的事件上報(bào)協(xié)議，以集成的方式將我們內(nèi)部的各個(gè)系統(tǒng)打通，將事件信息統(tǒng)一收集到一起。在收集的過(guò)程中，進(jìn)行二次處理，實(shí)現(xiàn)事件的結(jié)構(gòu)化轉(zhuǎn)儲(chǔ)。

• 事中

我們會(huì)對(duì)接入的4大類型信息進(jìn)行事件轉(zhuǎn)化，然后通過(guò)預(yù)定義的規(guī)則對(duì)事件進(jìn)行降噪，抑制、報(bào)警、召回、分派和升級(jí)等相關(guān)操作。在這個(gè)過(guò)程中，如果一個(gè)事件被判定影響到業(yè)務(wù)，我們會(huì)將它升級(jí)成一個(gè)故障，然后觸發(fā)故障的應(yīng)急響應(yīng)流程。這里就進(jìn)入到對(duì)故障響應(yīng)處理過(guò)程中的一個(gè)階段，在這個(gè)階段我們會(huì)產(chǎn)生各種角色，例如故障指揮官、故障通訊人員、故障恢復(fù)人員等，相關(guān)人員明確認(rèn)領(lǐng)角色，參與故障的止損。止損過(guò)程中，通過(guò)平臺(tái)一鍵拉群創(chuàng)建應(yīng)急響應(yīng)指揮部，通過(guò)平臺(tái)的進(jìn)展同步進(jìn)行相關(guān)群和業(yè)務(wù)人員的通告，通過(guò)記錄簿實(shí)現(xiàn)故障信息的信息傳遞和記錄。

• 事后

在故障結(jié)束之后，就進(jìn)入到我們整體的改進(jìn)環(huán)節(jié)。平臺(tái)可以基于故障一鍵創(chuàng)建復(fù)盤報(bào)告，自動(dòng)關(guān)聯(lián)故障處理過(guò)程中的專家數(shù)據(jù)。平臺(tái)提供預(yù)制的故障復(fù)盤問答模板，以確認(rèn)各階段是否按照預(yù)期的目標(biāo)進(jìn)行。復(fù)盤產(chǎn)生的待辦列表，平臺(tái)會(huì)進(jìn)行定期的狀態(tài)提醒和處理進(jìn)度跟進(jìn)。最終的這些都會(huì)以知識(shí)的形式，沉淀在我們的知識(shí)庫(kù)。幫助日常On-Call問答和公司內(nèi)部員工的培訓(xùn)學(xué)習(xí)。整體這樣一套平臺(tái)流程下來(lái)，就實(shí)現(xiàn)了將一些日常高頻的非結(jié)構(gòu)性事務(wù)驅(qū)動(dòng)，通過(guò)統(tǒng)一接入、精準(zhǔn)觸達(dá)、事件閉環(huán)和持續(xù)改進(jìn)等環(huán)節(jié)，轉(zhuǎn)化為低頻的結(jié)構(gòu)化數(shù)據(jù)驅(qū)動(dòng)方式。

2）場(chǎng)景覆蓋

下面我們介紹平臺(tái)在各個(gè)場(chǎng)景的覆蓋。

① 集約化

對(duì)事件產(chǎn)生的上游來(lái)源進(jìn)行集約化管理，通過(guò)隊(duì)列訂閱、API和SDK的方式，將內(nèi)部的監(jiān)控，Prometheus、監(jiān)控寶等各個(gè)云平臺(tái)的監(jiān)控都通過(guò)前面的4大類型定義收歸到一起，然后統(tǒng)一進(jìn)行通知觸達(dá)。

② 標(biāo)準(zhǔn)事件類型

為了實(shí)現(xiàn)各個(gè)渠道消息的結(jié)構(gòu)化規(guī)約，我們?cè)O(shè)計(jì)了標(biāo)準(zhǔn)的事件模型，通過(guò)這個(gè)事件模型，我們將周邊各個(gè)系統(tǒng)/工具/平臺(tái)進(jìn)行收集，并且實(shí)現(xiàn)了事件的關(guān)聯(lián)操作。模型主要分為4部分：

• base是一些事件的基礎(chǔ)信息字段；
• who是指這一事件來(lái)自哪里，有哪些相關(guān)方；
• when是指事件發(fā)生或產(chǎn)生影響的時(shí)間；
• where是指事件來(lái)源于哪個(gè)業(yè)務(wù)、影響了哪些業(yè)務(wù)；
• what是指這個(gè)事件的具體內(nèi)容，它的操作對(duì)象是什么等等。

③ 降噪聚類

由于我們對(duì)事件的上報(bào)結(jié)構(gòu)進(jìn)行了標(biāo)準(zhǔn)化，并且預(yù)埋了關(guān)聯(lián)字段，通過(guò)這些關(guān)聯(lián)字段，我們就建立起了事件的關(guān)聯(lián)關(guān)系，從而可以做事件的降噪聚類。

降噪聚類在執(zhí)行上，主要分為兩部分。

• 橫向抑制

我們支持對(duì)單個(gè)來(lái)源的事件、告警，通過(guò)定義的規(guī)則進(jìn)行收斂，比如Prometheus報(bào)警出一個(gè)服務(wù)在某個(gè)持續(xù)時(shí)間內(nèi)持續(xù)報(bào)了N條一樣的告警信息，平臺(tái)會(huì)收斂到一個(gè)事件中去。

• 縱向抑制

這對(duì)上文中提到的底層系統(tǒng)故障十分有效，可以將底層故障導(dǎo)致的上層業(yè)務(wù)告警都統(tǒng)一收到一個(gè)事件中，避免大量告警使大家造成混淆。

④ 協(xié)同在線

在協(xié)同在線的場(chǎng)景下，我們通過(guò)一個(gè)面板將人、業(yè)務(wù)、組件和系統(tǒng)信息進(jìn)行了匯總，通過(guò)一個(gè)事件詳情頁(yè)，將整個(gè)事件當(dāng)下的處理人、關(guān)聯(lián)業(yè)務(wù)和服務(wù)組件、當(dāng)下的一些信息統(tǒng)一展示在一起。在協(xié)同能力上，我們提供了一鍵創(chuàng)建應(yīng)急響應(yīng)群的功能，建群時(shí)會(huì)自動(dòng)關(guān)聯(lián)該故障相關(guān)oncall同學(xué)，對(duì)故障感興趣的同學(xué)也可以通過(guò)面板加入響應(yīng)群。在故障頁(yè)面，清晰看到故障當(dāng)前的指揮官是誰(shuí)，當(dāng)下的處理人是哪些同學(xué)。徹底解決了之前靠人工拉語(yǔ)音、打電話、面對(duì)面交流的原始協(xié)作方式。

平臺(tái)的各方面能力實(shí)現(xiàn)了事件全生命周期的閉環(huán)管理。監(jiān)控告警、故障發(fā)現(xiàn)、應(yīng)急響應(yīng)、故障定位、故障恢復(fù)、故障復(fù)盤和故障改進(jìn)，全階段都通過(guò)平臺(tái)能力去承載。

• 故障響應(yīng)時(shí)，支持了故障的全局應(yīng)急通告，提供了多種通告渠道，信息實(shí)時(shí)同步不延誤，避免人工同步，漏同步、同步內(nèi)容缺漏等問題；
• 故障跟蹤階段，平臺(tái)可以實(shí)時(shí)展示最新的故障進(jìn)展；故障影響面、當(dāng)下處置情況，各階段時(shí)間等等；
• 故障結(jié)束的復(fù)盤階段，通過(guò)定義好的結(jié)構(gòu)化、階段化的復(fù)盤過(guò)程，確保復(fù)盤過(guò)程中，該問的問題不遺漏，該確認(rèn)的點(diǎn)都確認(rèn)到；
• 故障改進(jìn)階段，通過(guò)對(duì)改進(jìn)項(xiàng)的平臺(tái)化錄入，關(guān)聯(lián)相關(guān)責(zé)任方、驗(yàn)收方，確保改進(jìn)的有效執(zhí)行和落實(shí)。

上圖中是協(xié)同相關(guān)的一些示例，當(dāng)一個(gè)故障被創(chuàng)建出來(lái)時(shí)，會(huì)自動(dòng)關(guān)聯(lián)該故障涉及到的業(yè)務(wù)、組件、基礎(chǔ)設(shè)施的oncall同學(xué)，這些同學(xué)可能是SRE、研發(fā)等，平臺(tái)會(huì)記錄他們是否有響應(yīng)這些問題，并且當(dāng)下所負(fù)責(zé)的角色是什么。因?yàn)榻巧珱Q定了在該事件中所擔(dān)負(fù)的事項(xiàng)和責(zé)任；下方一鍵拉群，可以將相關(guān)人員，自動(dòng)拉入到一個(gè)群內(nèi)，方便大家進(jìn)行溝通協(xié)同，并且事件、故障的相關(guān)最新進(jìn)展也會(huì)定期在群內(nèi)同步；涉及到事件的參與人員，事件運(yùn)營(yíng)中心的服務(wù)號(hào)也會(huì)定期推送最新進(jìn)展，確保不會(huì)丟失消息。

上圖是我們內(nèi)部的故障協(xié)同的詳情頁(yè)面，提供了記錄簿、故障階段更新、最近變更信息和相似事件，確保每次的響應(yīng)處理，都能形成一個(gè)專家經(jīng)驗(yàn)的沉淀，幫助后續(xù)新來(lái)的同學(xué)進(jìn)行故障響應(yīng)過(guò)程的學(xué)習(xí)。

復(fù)盤方面，我們定義了結(jié)構(gòu)化的故障復(fù)盤模板，像相關(guān)人員、組織、影響情況、處置過(guò)程、根因分析(在根因分析里面，我們?cè)O(shè)置了6問，確保對(duì)問題能夠有深度地挖掘)，改進(jìn)措施等。在復(fù)盤效率方面，我們關(guān)聯(lián)了相關(guān)的變更信息、故障處理時(shí)的一些變更操作，以及處理時(shí)間線，幫助復(fù)盤同學(xué)快速生成故障的相關(guān)信息，減少人工錄入負(fù)擔(dān)。

五、挑戰(zhàn)與收益

挑戰(zhàn)

在業(yè)務(wù)穩(wěn)定性運(yùn)營(yíng)體系的建設(shè)過(guò)程中，團(tuán)隊(duì)也踩了很多坑，面臨著諸多技術(shù)之外的挑戰(zhàn)。鑒于業(yè)界對(duì)于技術(shù)相關(guān)的分享比較豐富，這里就針對(duì)體系邏輯和人員方面的挑戰(zhàn)進(jìn)行分享。

• 元信息統(tǒng)一

穩(wěn)定性是個(gè)大話題，我們?cè)诼涞卣w體系時(shí)會(huì)發(fā)現(xiàn)，設(shè)計(jì)的上下游系統(tǒng)太多了。每個(gè)系統(tǒng)里面都會(huì)有人、業(yè)務(wù)、職能的使用需求。在初期，我們內(nèi)部在服務(wù)、業(yè)務(wù)和人的關(guān)聯(lián)這塊沒有形成統(tǒng)一的數(shù)據(jù)基準(zhǔn)，導(dǎo)致我們?cè)趹?yīng)急協(xié)同的諸多特性上難以落地，諸如故障的有效通知、群內(nèi)的有效傳遞、故障畫像的拓?fù)潢P(guān)聯(lián)計(jì)算缺少映射關(guān)系等等。

在這種情況下，我們重新梳理了服務(wù)樹和OnCall系統(tǒng)，通過(guò)服務(wù)樹將組織、業(yè)務(wù)和服務(wù)的映射關(guān)系維護(hù)好，通過(guò)OnCall系統(tǒng)將組織、職能、業(yè)務(wù)和人的映射關(guān)系維護(hù)好，來(lái)確保找人的時(shí)候能找到人，找服務(wù)的時(shí)候能找到服務(wù)。

• 工作模式改變

新的應(yīng)急響應(yīng)流程，將故障過(guò)往對(duì)人的依賴轉(zhuǎn)移到靠系統(tǒng)來(lái)自行驅(qū)動(dòng)，這導(dǎo)致現(xiàn)有人員的工作模式產(chǎn)生了很大變化。傳統(tǒng)故障處理時(shí)，響應(yīng)人員手動(dòng)拉群、語(yǔ)音或現(xiàn)場(chǎng)找人，現(xiàn)在變成了優(yōu)先在系統(tǒng)內(nèi)升級(jí)已有事件或錄入故障信息，然后通過(guò)系統(tǒng)自動(dòng)進(jìn)行人員關(guān)聯(lián)和邀請(qǐng)。群內(nèi)的隨意溝通，變成了在平臺(tái)進(jìn)行階段性進(jìn)展同步。原有的故障升級(jí)邏輯變成了平臺(tái)定時(shí)通知，這給故障處理人員帶了一定的壓迫感。整體形式上更加嚴(yán)肅和標(biāo)準(zhǔn)，在落地初期給大家?guī)?lái)了一定的不適應(yīng)感。針對(duì)這種情況，我們一方面通過(guò)在系統(tǒng)的文案描述上進(jìn)行改善，交互邏輯上進(jìn)行優(yōu)化，盡可能在推行新標(biāo)準(zhǔn)的同時(shí)，適應(yīng)舊的使用習(xí)慣。例如，常規(guī)應(yīng)急協(xié)同群會(huì)先于平臺(tái)的故障通告建立，這就會(huì)與平臺(tái)創(chuàng)建的故障協(xié)同群發(fā)生沖突。此時(shí)，我們通過(guò)增加現(xiàn)有群關(guān)聯(lián)來(lái)實(shí)現(xiàn)已有故障協(xié)同群和故障的關(guān)聯(lián)。另外一方面，我們通過(guò)定期持續(xù)的宣講，給大家介紹新的應(yīng)急響應(yīng)流程和平臺(tái)使用方法，幫助大家適應(yīng)新的應(yīng)急響應(yīng)模式。

收益

以上就是B站在業(yè)務(wù)穩(wěn)定性運(yùn)營(yíng)方面所做的相關(guān)工作。通過(guò)體系化建設(shè)，已經(jīng)在組織、流程和平臺(tái)層面實(shí)現(xiàn)強(qiáng)效聯(lián)動(dòng)，具備了數(shù)字化運(yùn)營(yíng)業(yè)務(wù)穩(wěn)定性的能力，建立了科學(xué)有效的穩(wěn)定性評(píng)估提升量化標(biāo)準(zhǔn)，讓穩(wěn)定性提升有數(shù)據(jù)可依托。將故障應(yīng)急響應(yīng)流程從由人工驅(qū)動(dòng)升級(jí)到由平臺(tái)系統(tǒng)驅(qū)動(dòng)，應(yīng)急響應(yīng)人員可以更專心處理故障，大幅提升故障恢復(fù)時(shí)間。后續(xù)我們將會(huì)持續(xù)探索更科學(xué)有效的管理運(yùn)營(yíng)方法，期望通過(guò)引入AI的能力，提升故障輔助定位能力、提早發(fā)現(xiàn)故障隱患，聯(lián)動(dòng)預(yù)案平臺(tái)實(shí)現(xiàn)更多場(chǎng)景的故障自愈。