建站
咨詢
售后
建站咨詢
新聞中心
本次分享主題是B站SRE在穩(wěn)定性方面的運營實踐，分享內(nèi)容分為以下幾個部分：
- 案例剖析
- 從應(yīng)急響應(yīng)看穩(wěn)定性運營
- 核心運營要素有哪些
- 兩個運營載體：OnCall與事件運營中心
- 挑戰(zhàn)與收益
一、案例剖析
多年來業(yè)界同仁針對穩(wěn)定性這一話題進行了大量的探索和實踐，業(yè)界不乏針對穩(wěn)定性保障相關(guān)的討論和研究。在圍繞穩(wěn)定性的實踐上，大家也經(jīng)常聽到諸如混沌工程、全鏈路壓測、大促活動保障和智能監(jiān)控等話題的分享。B站在這些方面也做了很多建設(shè)工作，今天我將從應(yīng)急響應(yīng)的角度切入，和大家分享B站在穩(wěn)定性運營方面所做的工作。
我們先來看兩個案例，案例以真實事件為依托，相關(guān)敏感內(nèi)容進行了改寫。
案例一
1）背景
一個手機廠商的發(fā)布會在某天晚上12點舉辦，B站承接了該品牌的線上發(fā)布會直播。公司的運營同學(xué)提前就配置好了12點的直播活動頁面以及準(zhǔn)點的應(yīng)用內(nèi)Push消息。在12點到來之后，直播活動頁推送生效，大量用戶收到應(yīng)用內(nèi)推送消息，點擊進入直播活動頁面。
2）故障始末
12點01分，直播活動頁內(nèi)嵌的播放器無法支持部分用戶正常加載播放。
12點03分，研發(fā)同學(xué)李四收到了異常的報警，開始介入處理。
12點04分，客服同學(xué)收到了大量有關(guān)發(fā)布會無法正常播放的用戶反饋，常規(guī)處理方法無法解決用戶問題。
影響持續(xù)到12點15分，研發(fā)同學(xué)李四還在排查問題的具體原因，沒有執(zhí)行相對應(yīng)的止損預(yù)案（該種問題有對應(yīng)預(yù)案），問題持續(xù)在線上造成影響。
直到12點16分，老板朋友找到了老板反饋今晚B站的某品牌手機直播發(fā)布會頁面視頻無法正常播放，此時老板開始從上往下詢問，研發(fā)leader知道了這件事，開始聯(lián)系SRE同學(xué)介入問題處理，并及時執(zhí)行了相關(guān)的切換預(yù)案，直播活動頁面播放恢復(fù)正常。
3）問題
在這個案例中，暴露了以下一些問題：
- 故障的相關(guān)告警雖然及時，但是并沒有通知到足夠多對的人。
- 該故障的告警，在短時間沒有處理響應(yīng)后，并未進行有效的結(jié)構(gòu)性升級（管理升級，及時讓更高level的人參與進來，知曉故障影響，協(xié)調(diào)處理資源）和職能性升級（技術(shù)升級，讓更專業(yè)和更對口的人來參與響應(yīng)處理，如team leader、SRE等）。
- 一線同學(xué)往往容易沉迷于查找問題根因，不能及時有效地對故障部位進行預(yù)案執(zhí)行。
案例二
1）背景
一個平淡無奇的周末晚上，23點30分，監(jiān)控系統(tǒng)觸發(fā)大量告警，幾乎全業(yè)務(wù)線、各架構(gòu)層都在觸發(fā)告警。
2）故障始末
23點40分，企業(yè)微信拉了有十幾個群，原有的業(yè)務(wù)溝通群、基礎(chǔ)服務(wù)OnCall群，都在不停地轉(zhuǎn)發(fā)告警，詢問情況。整個技術(shù)線一片恐慌，起初以為是監(jiān)控系統(tǒng)炸了。此時相關(guān)故障的SRE同學(xué)已經(jīng)被拉到某一個語音會議中。
注意，此時公司的多個BU業(yè)務(wù)線同學(xué)都炸鍋了，到處咨詢發(fā)生了什么，業(yè)務(wù)怎么突然就不炸了。又過了幾分鐘，資深的SRE同學(xué)又拉了一個大群，把相關(guān)業(yè)務(wù)對接人都拉進群里，開始整體說明故障情況。此時，該同學(xué)也比較糾結(jié)如何通報和說明這個問題，因為此時沒有一個明確故障定位，語言很難拿捏，各個高level的老板也都在問（已上熱搜）。并且，負(fù)責(zé)恢復(fù)入口服務(wù)的一線同學(xué)把故障預(yù)案執(zhí)行了個遍，發(fā)現(xiàn)無濟于事。后續(xù)在GSLB調(diào)度層，執(zhí)行了整個跨機房的流量有損切換才讓服務(wù)逐漸恢復(fù)正常。
凌晨之后，原有機房的問題定位出來了，補丁迅速打上，異常的問題徹底修復(fù)了。后續(xù)，在對此事件進行復(fù)盤時，發(fā)現(xiàn)困難重重。因為故障處理過程中，涉及到大量的服務(wù)、組件和業(yè)務(wù)方，并且大家當(dāng)時拉了一堆群，同樣的消息被發(fā)送到了很多群。參與處理故障的同學(xué)在語音、電話和企微群都有進行過溝通和處理進展發(fā)布，整個事件的細(xì)節(jié)整理起來非常耗費人力和精力，準(zhǔn)確性也很難保障。
3）問題
- 在上面這個案例中，我們可以看到整個故障從發(fā)生、處置到結(jié)束后復(fù)盤，都存在以下問題：
- 當(dāng)一個影響面比較大的故障產(chǎn)生時，大家沒有統(tǒng)一的故障進展同步方式，依托原始的人工拉群，人工找相關(guān)人員電話聯(lián)系，導(dǎo)致了故障最新的進展情況只能夠在小范圍傳播擴散，無法統(tǒng)一對外公布，并且在傳播過程中，很容易消息失真；
- 在故障處理過程中，缺少主要協(xié)調(diào)人（故障指揮官）。像這種大型故障，需要有一個人能夠去協(xié)調(diào)各層人員分工、消息收斂、服務(wù)業(yè)務(wù)情況等，這個人需要能夠掌控整個故障的所有消息和全貌進展；
- 在故障處理過程中，缺乏故障上下文的信息關(guān)聯(lián)，大家難以知曉故障發(fā)生的具體位置，只是感知到自己的業(yè)務(wù)受損了，自己的服務(wù)可能有異常，這導(dǎo)致整個故障的定位時間被拉長；
- 在故障恢復(fù)之后，我們對這個故障進行復(fù)盤時，發(fā)現(xiàn)故障處理過程中的信息太過零散，復(fù)盤成本很高。
案例剖析
通過對上述兩個案例的分析我們能夠發(fā)現(xiàn)，在故障發(fā)生前、處理中和結(jié)束后，各個階段都會有很多因素導(dǎo)致我們的故障不能被快速解決，業(yè)務(wù)不能快速恢復(fù)。
這里我們從故障的前、中、后三個階段總結(jié)可能存在的一些問題。
1）事前
- 告警信息量大，信息太過雜亂；
- 平臺系統(tǒng)繁多，變更信息無處收斂；
- 客服反饋的信息，需要靠人工去關(guān)聯(lián)，并反饋到技術(shù)線；
- 和公司輿情相關(guān)的信息，技術(shù)線很難感知到。
2）事中
- 一線同學(xué)過于關(guān)注技術(shù)，沉迷問題解決；
- 當(dāng)一個故障影響面擴大之后，涉及多個團隊的協(xié)同非常困難，最新的進展消息無法及時有效地傳遞到相關(guān)人員手中；
- 當(dāng)參與一個故障處理的人員多了之后，多個人員之間缺乏協(xié)調(diào)，導(dǎo)致職責(zé)不清晰，產(chǎn)生事情漏做、重復(fù)做的問題；
- 故障處理過程中，會有一些不請自來，湊熱鬧的同學(xué)。
3）事后
- 當(dāng)我們開展復(fù)盤時，發(fā)現(xiàn)故障處理時又是群、又是電話、又是口頭聊，又是操作各種平臺和工具，做了很多事情，產(chǎn)生了很多信息，梳理時間線很繁瑣，還會遺漏，寫好一份完整的復(fù)盤報告非常麻煩；
- 拉一大堆人進行復(fù)盤的時候，因為缺少結(jié)構(gòu)化的復(fù)盤流程，經(jīng)常是想到什么問什么。當(dāng)某場復(fù)盤會，大家狀態(tài)好的時候，能挖掘的點很多。如果狀態(tài)不好或者大家意識上輕視時，復(fù)盤的效果就較差；
- 復(fù)盤后產(chǎn)出的改進事項，未及時統(tǒng)一地記錄跟進，到底有沒有完成，什么時間應(yīng)該完成，完成的情況是否符合預(yù)期都不得而知；
- 對于已經(jīng)修復(fù)的問題，是否需要演練驗收確保真正修復(fù)。
以上三個階段中可能發(fā)生的各種各樣的問題，最終只會導(dǎo)致一個結(jié)果：服務(wù)故障時間增長，服務(wù)的SLA降低。
二、從應(yīng)急響應(yīng)看穩(wěn)定性運營
針對上述問題，如何進行有效改善？這是本部分要重點分享的內(nèi)容，從應(yīng)急響應(yīng)看穩(wěn)定性運營。
應(yīng)急響應(yīng)的概念較早來源于《信息安全應(yīng)急相應(yīng)計劃規(guī)范GB/T24363-2009》中提到的安全相關(guān)的應(yīng)急響應(yīng)，整體定義是“組織為了應(yīng)對突發(fā)/重大信息安全事件的發(fā)生所作的準(zhǔn)備，以及在事件發(fā)生后所采取的措施”。從這個概念我們延伸到穩(wěn)定性上就產(chǎn)生了新的定義，“一個組織為了應(yīng)對各種意外事件的發(fā)生所作的準(zhǔn)備以及在事件發(fā)生后所采取的措施和行為”。這些措施和行為，通常用來減小和阻止事件帶來的負(fù)面影響及不良后果。
三、核心運營要素有哪些
做好應(yīng)急響應(yīng)工作的核心目標(biāo)是提升業(yè)務(wù)的穩(wěn)定性。在這個過程中，我們核心關(guān)注4大要素。核心點是事件，圍繞事件有三塊抓手，分別是人、流程和工具/平臺。
人作為應(yīng)急響應(yīng)過程中參與和執(zhí)行的主體，對其應(yīng)急的意識和心態(tài)有很高要求。特別是在一些重大的故障處理過程中，不能因為壓力大或緊張導(dǎo)致錯誤判斷。
流程將應(yīng)急響應(yīng)的流程標(biāo)準(zhǔn)化，期望響應(yīng)人能夠按照既定階段的既定章程進行有效的推進和處理。
工具/平臺支撐人和流程的高效合規(guī)運行，并將應(yīng)急響應(yīng)的過程、階段進行度量，進而分析和運營，推進人和流程的改進。
事件
1）生命周期劃分
要對故障進行有效運營，就需要先明確故障的生命周期。通過劃分故障的生命周期，我們可以針對不同的周期階段進行精準(zhǔn)聚焦，更有目的性地開展穩(wěn)定性提升工作。
針對故障生命周期的劃分有很多種方式，按故障的狀態(tài)階段劃分，可以分為事前、事中和事后。
按故障的流程順序劃分，可以分為故障防御、故障發(fā)生、故障響應(yīng)、故障定位和故障恢復(fù)、復(fù)盤改進等階段。
這里我圍繞故障的時間階段，從故障不同階段的形態(tài)變化做拆分，將故障拆分為四個階段。
- 告警/變更/客訴
當(dāng)故障還未被確認(rèn)時，它可能是一個告警、變更或客訴。
- 事件
當(dāng)這個告警、變更、客訴被上報后，會產(chǎn)生一個事件，我們需要有人去響應(yīng)這個事件，此時一個真正的事件就形成了。
- 故障
當(dāng)事件的影響范圍逐漸擴散，這時往往有大量的用戶、業(yè)務(wù)受到影響，我們需要將事件升級成故障，觸發(fā)故障的應(yīng)急協(xié)同，進行一系列的定位、止損等工作。
- 改進
故障最終會被恢復(fù)，接下來我們要對故障進行復(fù)盤，產(chǎn)生相關(guān)改進項，在改進項被完成之后，還需要進行相關(guān)的驗收工作。
2）階段度量
從更科學(xué)的角度看，我們知道在運營工作中，度量是很關(guān)鍵的一點。管理學(xué)大師彼得·德魯克曾經(jīng)說過：“你如果無法度量它，就無法管理它”。有效的度量指標(biāo)定義，可以幫助我們更好更快地開展運營工作、評估價值成果。上文中我們提到的3個階段是比較籠統(tǒng)的階段，接下來我將介紹更加具體和可執(zhí)行的量化拆分方法。
如上圖所示，從故障預(yù)防依次到故障發(fā)現(xiàn)，故障定位，故障恢復(fù)，最后到故障改進，整體有兩個大的階段：MTBF（平均無故障時間）和MTTR（平均故障恢復(fù)時間）。我們進行業(yè)務(wù)穩(wěn)定性運營的核心目標(biāo)就是降低MTTR，增加MTBF。根據(jù)Google的定義，我們將MTTR進一步拆分為以下4個階段：
- MTTI：平均故障發(fā)現(xiàn)時間，指的是故障發(fā)生到我們發(fā)現(xiàn)的時間。
- MTTK：平均故障定位時間，指的是我們發(fā)現(xiàn)故障到定位出原因的時間。
- MTTF：平均故障修復(fù)時間，指的是我們采取恢復(fù)措施到故障徹底恢復(fù)的時間。
- MTTV：平均故障修復(fù)驗證時間，指的是故障恢復(fù)之后通過監(jiān)控、用戶驗證真實恢復(fù)的時間。
3）關(guān)鍵節(jié)點
基于階段度量的指標(biāo)，我們能夠得到一系列的關(guān)鍵時間節(jié)點。在不同的階段形態(tài)，事件和故障會存在一些差異。故障因為形態(tài)更豐富，所存在的時間節(jié)點更多。上圖中定下來的時間，均是圍繞MTTR進行計算的。主要是為了通過度量事件、故障的處理過程，發(fā)現(xiàn)過程中存在的問題點，并對問題點進行精準(zhǔn)優(yōu)化，避免不知道如何切入去提升MTTR的問題，也方便我們對SRE的工作進行側(cè)面考核。
人
人作為事件的一個主體，負(fù)責(zé)參與事件的響應(yīng)、升級、處置和消息傳播。
人通過上文中我們講到的OnCall參與到應(yīng)急響應(yīng)中。我們在內(nèi)部通過一套OnCall排班系統(tǒng)進行這方面的管理。這套系統(tǒng)明確了內(nèi)部的業(yè)務(wù)、職能和人員團隊，確保人員知道什么時間去值什么業(yè)務(wù)的班。下面的工具/平臺部分會展開介紹。對參與人的要求，主要有以下幾點：
- 具備良好的響應(yīng)意識和處理心態(tài)。
- 具備熟練地響應(yīng)執(zhí)行的經(jīng)驗。
滿足以上特征，才能做到故障來臨時響應(yīng)不慌亂，有條不紊地開展響應(yīng)工作。
流程
那么針對人的要求如何實現(xiàn)？人員如何參與到應(yīng)急響應(yīng)的環(huán)節(jié)中去？人員的意識如何培養(yǎng)呢？
首先，我們內(nèi)部制定了應(yīng)急響應(yīng)白皮書，明確了以下內(nèi)容：
- 響應(yīng)流程；
- 基于事件大小，所要參與的角色和角色對應(yīng)的職責(zé)；
- 周邊各個子系統(tǒng)SOP制定的標(biāo)準(zhǔn)規(guī)范；
- 針對應(yīng)急過程中的對外通告內(nèi)容模板；
- 故障過程的升級策略。
之后，我們會周期性地在部門內(nèi)部、各BU進行應(yīng)急響應(yīng)宣講，確保公司參與OnCall的同學(xué)能夠?qū)W習(xí)和掌握。另外，我們也會將其作為一門必修課加入新同學(xué)的入職培訓(xùn)中。最后就是故障演練，通過實操，讓沒有參與過故障處理的新同學(xué)能夠?qū)嶋H性地參與應(yīng)急響應(yīng)的過程，避免手生。
平臺
平臺作為支撐人與流程進行高效、穩(wěn)定執(zhí)行的載體，我將在下一部分進行具體描述。
四、兩個運營載體：OnCall與事件運營中心
這部分我將向大家分享B站在應(yīng)急響應(yīng)方面落地的兩個運營性平臺。
OnCall系統(tǒng)
OnCall系統(tǒng)，即值班系統(tǒng)。值班系統(tǒng)在日常運轉(zhuǎn)過程中的作用往往被低估，SRE、工程效率做這部分建設(shè)時，很容易基于二維的方式對人和事進行基于日歷的值班管理，并通過網(wǎng)頁、OpenAPI等方式對外提供數(shù)據(jù)服務(wù)。
下面我們通過幾個例子來說明OnCall的必要性。
在日常工作中，當(dāng)我們使用公司某個平臺功能時，可能會習(xí)慣性找熟悉的同學(xué)，不管他這一天是不是oncall。這可能給那位同學(xué)帶來困擾，他可能上周才值完班，這周要專心于研發(fā)或者項目的推進，你隨時找他可能打斷他的工作節(jié)奏。還有一種情況是新同學(xué)不知道該去找誰，我們內(nèi)部之前經(jīng)常有這種情況，一個新來的同學(xué)接手一套系統(tǒng)之后，有問題不知道該找誰，經(jīng)常要轉(zhuǎn)好幾手，才能找到對的人，這一過程很痛苦。
以上內(nèi)容總結(jié)起來就是總找一個人，總找不到人，除此之外，還會出現(xiàn)平臺找不到人的情況。這些問題的根源是什么呢？無非就是who、when、what和how的問題，不能在正確的時間為正確的事找到正確的人。
那么OnCall系統(tǒng)的重要性和必要性都體現(xiàn)在哪些方面呢？
- 有問題找不到人
隨著公司業(yè)務(wù)規(guī)模的擴大和領(lǐng)域的細(xì)分，一些新的同學(xué)和新業(yè)務(wù)方往往會出現(xiàn)一個問題。不知道是哪些人負(fù)責(zé)，需要咨詢很多人才能找到具體解決問題的人。這一問題不僅限于故障，更存在于日?，嵤轮?。特別是SRE同學(xué)的日常，經(jīng)常會被研發(fā)同學(xué)咨詢找人拉群，戲稱拉群工程師。
- 下班不下崗
當(dāng)人們遇到問題時，經(jīng)常會下意識找熟悉的人。這就導(dǎo)致一些能力強、服務(wù)意識好的同學(xué)，總是在被人找。不論他今天值不值班，他將無時無刻都要面臨被人打擾的問題。除了被人找之外，內(nèi)部的監(jiān)控系統(tǒng)、流程系統(tǒng)，也會給不值班的同學(xué)發(fā)送監(jiān)控告警和流程審批信息。這也將SRE同學(xué)有50%的時間用于工程這一愿景變成泡影。
1）設(shè)計
① 明確關(guān)聯(lián)邏輯
針對上述兩種情況，我們對公司的業(yè)務(wù)、服務(wù)、職能和組織架構(gòu)進行了分析建模，明確了人、團隊、職能和業(yè)務(wù)之間的關(guān)聯(lián)關(guān)系。
② 建立三維合一模型
我們構(gòu)建起了一套三維合一的模型。由組織-業(yè)務(wù)、職能-人員、組織-職能的關(guān)聯(lián)關(guān)系，產(chǎn)生交匯點。值班人員會通過值班小隊的方式，落在這些交匯點上，并且基于業(yè)務(wù)和基礎(chǔ)架構(gòu)的異同點，通過業(yè)務(wù)視角和職能視角分別對外提供服務(wù)。
以我們公司內(nèi)部主站業(yè)務(wù)為例，我們會有專門的SRE小隊進行日常的值班響應(yīng)，這個小隊只負(fù)責(zé)主站業(yè)務(wù)的值班響應(yīng)。通過這樣的對應(yīng)關(guān)系，當(dāng)人或平臺有需求的時候，都可以通過業(yè)務(wù)和職能關(guān)聯(lián)到對應(yīng)實踐的值班小隊，最終定位到具體的人，這樣也幫助我們將人藏了起來，更有利于后續(xù)SRE輪崗機制的推進落地。
③ 雙視角提供服務(wù)
通過雙視角的設(shè)計，區(qū)分了職能型和業(yè)務(wù)型的不同值班方式和關(guān)注點。原因在于B站的業(yè)務(wù)層級組織模式是按照“組織->業(yè)務(wù)->應(yīng)用”這三級進行組織的，所有的應(yīng)用歸屬到業(yè)務(wù)，業(yè)務(wù)歸屬到具體的組織架構(gòu)。
- 職能視角
前端采用樹型展示，組成結(jié)構(gòu)為組織->職能->覆蓋范圍（組織->業(yè)務(wù)->服務(wù)），值班表具體掛載在覆蓋范圍下，覆蓋范圍可以只有一級組織也可以精確到組織下面的業(yè)務(wù)或業(yè)務(wù)下面的服務(wù)。
- 業(yè)務(wù)視角
前端采用樹型展示，組織結(jié)構(gòu)為組織->業(yè)務(wù)->職能，值班表具體掛載在職能下面。
在日常工作中，基礎(chǔ)架構(gòu)相關(guān)的服務(wù)，比如SRE、DBA、微服務(wù)、監(jiān)控、計算平臺等強職能型服務(wù)會通過職能視角對外提供值班信息。當(dāng)業(yè)務(wù)人員有具體問題時，可以通過職能樹快速定位到具體的值班人員。而對于業(yè)務(wù)服務(wù)來講，日常的工作模式是圍繞業(yè)務(wù)開展的，因此會通過業(yè)務(wù)進行展開，提供該業(yè)務(wù)下相關(guān)職能的對應(yīng)值班信息。
這兩個視角的底層數(shù)據(jù)是相通的，強職能相關(guān)服務(wù)提供方只需要維護好職能視角的值班信息，業(yè)務(wù)視角下的關(guān)聯(lián)會自動生成。
2）功能展示
基于以上設(shè)計，我們內(nèi)部做了一套OnCall排班的系統(tǒng)。
這套系統(tǒng)是管理業(yè)務(wù)、職能和人的系統(tǒng)。我們基于上文中提到的幾個核心概念，在這些概念間建立了關(guān)系，分別是兩條線，一條是職能-團隊和人，另外一條是職能-業(yè)務(wù)和服務(wù)。
系統(tǒng)提供了排班班組的管理，支持基于日歷的排班，同時支持班組設(shè)置主備oncall角色。在排班的細(xì)節(jié)上，我們支持基于時段進行自動排班計劃生成，也支持在一個職能里多個班組混合排班。另外，也支持對已經(jīng)排好班的班組，進行覆蓋排班和換班，這個主要應(yīng)對oncall同學(xué)突然有事請假的情況。在oncall通知方面，我們支持了企業(yè)微信、電話等通知方式，并且支持虛擬號碼的方式，保護員工號碼不對外泄露。同時也避免了因為熟悉導(dǎo)致的頻繁被打擾的情況。
在周邊生態(tài)方面，這套OnCall系統(tǒng)完全依賴周邊系統(tǒng)的接入。我們目前對接了內(nèi)部的告警系統(tǒng)、流程系統(tǒng)，確保告警和流程能夠只通知oncall人，而不形成騷擾。在企業(yè)微信的服務(wù)號中，也進行了H5的頁面嵌入，在用戶通過企業(yè)微信反饋問題、找人時，知道當(dāng)下該找誰。在各個接入的平臺，也內(nèi)嵌了OnCall的卡片頁面，明確告訴用戶本平臺當(dāng)前是誰值班。通過這套OnCall系統(tǒng)的落地，我們明確了人、團隊、職能和業(yè)務(wù)的概念，并將這些概念進行了關(guān)系建立和對應(yīng)。人員通過排班班組統(tǒng)一對外為某個業(yè)務(wù)提供某項職能的值班響應(yīng)。通過前端的可視化，提供了日歷的值班展示效果，可以直觀看到某個業(yè)務(wù)所需要的某塊職能在某個時間點是由哪個班組在服務(wù)，周邊的各個系統(tǒng)也都對接OnCall系統(tǒng)，實現(xiàn)了人員響應(yīng)的統(tǒng)一管理，解決了某些人員認(rèn)人不認(rèn)事，不通過正規(guī)流程處理的問題。
事件運營中心
事件運營中心這套系統(tǒng)是我們基于ITIL、SRE、信息安全應(yīng)急計劃的事件管理體系，為了滿足公司對重大事件/故障的數(shù)字化管理，實現(xiàn)信息在線、數(shù)據(jù)在線和協(xié)同在線，使組織能夠具備體系化提升業(yè)務(wù)連續(xù)性能力所做的產(chǎn)品平臺。這個平臺的定位是一站式的SRE事件運營中心，數(shù)字化運營業(yè)務(wù)連續(xù)性的目標(biāo)是提升MTBF，降低MTTR，提高SLA。
1）架構(gòu)設(shè)計
上圖是我們平臺的模塊架構(gòu)圖，整體上還是圍繞上文提到的事件的事前、事中和事后三個階段拆分，覆蓋了一個事件產(chǎn)生、響應(yīng)、復(fù)盤、改進的全生命周期。
- 事前
我們對事件進行了4大類型的拆分，分別是告警、變更、客訴和輿情，然后通過設(shè)計標(biāo)準(zhǔn)的事件上報協(xié)議，以集成的方式將我們內(nèi)部的各個系統(tǒng)打通，將事件信息統(tǒng)一收集到一起。在收集的過程中，進行二次處理，實現(xiàn)事件的結(jié)構(gòu)化轉(zhuǎn)儲。
- 事中
我們會對接入的4大類型信息進行事件轉(zhuǎn)化，然后通過預(yù)定義的規(guī)則對事件進行降噪，抑制、報警、召回、分派和升級等相關(guān)操作。在這個過程中，如果一個事件被判定影響到業(yè)務(wù)，我們會將它升級成一個故障，然后觸發(fā)故障的應(yīng)急響應(yīng)流程。這里就進入到對故障響應(yīng)處理過程中的一個階段，在這個階段我們會產(chǎn)生各種角色，例如故障指揮官、故障通訊人員、故障恢復(fù)人員等，相關(guān)人員明確認(rèn)領(lǐng)角色，參與故障的止損。止損過程中，通過平臺一鍵拉群創(chuàng)建應(yīng)急響應(yīng)指揮部，通過平臺的進展同步進行相關(guān)群和業(yè)務(wù)人員的通告，通過記錄簿實現(xiàn)故障信息的信息傳遞和記錄。
- 事后
在故障結(jié)束之后，就進入到我們整體的改進環(huán)節(jié)。平臺可以基于故障一鍵創(chuàng)建復(fù)盤報告，自動關(guān)聯(lián)故障處理過程中的專家數(shù)據(jù)。平臺提供預(yù)制的故障復(fù)盤問答模板，以確認(rèn)各階段是否按照預(yù)期的目標(biāo)進行。復(fù)盤產(chǎn)生的待辦列表，平臺會進行定期的狀態(tài)提醒和處理進度跟進。最終的這些都會以知識的形式，沉淀在我們的知識庫。幫助日常On-Call問答和公司內(nèi)部員工的培訓(xùn)學(xué)習(xí)。整體這樣一套平臺流程下來，就實現(xiàn)了將一些日常高頻的非結(jié)構(gòu)性事務(wù)驅(qū)動，通過統(tǒng)一接入、精準(zhǔn)觸達(dá)、事件閉環(huán)和持續(xù)改進等環(huán)節(jié)，轉(zhuǎn)化為低頻的結(jié)構(gòu)化數(shù)據(jù)驅(qū)動方式。
2）場景覆蓋
下面我們介紹平臺在各個場景的覆蓋。
① 集約化
對事件產(chǎn)生的上游來源進行集約化管理，通過隊列訂閱、API和SDK的方式，將內(nèi)部的監(jiān)控，Prometheus、監(jiān)控寶等各個云平臺的監(jiān)控都通過前面的4大類型定義收歸到一起，然后統(tǒng)一進行通知觸達(dá)。
② 標(biāo)準(zhǔn)事件類型
為了實現(xiàn)各個渠道消息的結(jié)構(gòu)化規(guī)約，我們設(shè)計了標(biāo)準(zhǔn)的事件模型，通過這個事件模型，我們將周邊各個系統(tǒng)/工具/平臺進行收集，并且實現(xiàn)了事件的關(guān)聯(lián)操作。模型主要分為4部分：
- base是一些事件的基礎(chǔ)信息字段；
- who是指這一事件來自哪里，有哪些相關(guān)方；
- when是指事件發(fā)生或產(chǎn)生影響的時間；
- where是指事件來源于哪個業(yè)務(wù)、影響了哪些業(yè)務(wù)；
- what是指這個事件的具體內(nèi)容，它的操作對象是什么等等。
③ 降噪聚類
由于我們對事件的上報結(jié)構(gòu)進行了標(biāo)準(zhǔn)化，并且預(yù)埋了關(guān)聯(lián)字段，通過這些關(guān)聯(lián)字段，我們就建立起了事件的關(guān)聯(lián)關(guān)系，從而可以做事件的降噪聚類。
降噪聚類在執(zhí)行上，主要分為兩部分。
- 橫向抑制
我們支持對單個來源的事件、告警，通過定義的規(guī)則進行收斂，比如Prometheus報警出一個服務(wù)在某個持續(xù)時間內(nèi)持續(xù)報了N條一樣的告警信息，平臺會收斂到一個事件中去。
- 縱向抑制
這對上文中提到的底層系統(tǒng)故障十分有效，可以將底層故障導(dǎo)致的上層業(yè)務(wù)告警都統(tǒng)一收到一個事件中，避免大量告警使大家造成混淆。
④ 協(xié)同在線
在協(xié)同在線的場景下，我們通過一個面板將人、業(yè)務(wù)、組件和系統(tǒng)信息進行了匯總，通過一個事件詳情頁，將整個事件當(dāng)下的處理人、關(guān)聯(lián)業(yè)務(wù)和服務(wù)組件、當(dāng)下的一些信息統(tǒng)一展示在一起。在協(xié)同能力上，我們提供了一鍵創(chuàng)建應(yīng)急響應(yīng)群的功能，建群時會自動關(guān)聯(lián)該故障相關(guān)oncall同學(xué)，對故障感興趣的同學(xué)也可以通過面板加入響應(yīng)群。在故障頁面，清晰看到故障當(dāng)前的指揮官是誰，當(dāng)下的處理人是哪些同學(xué)。徹底解決了之前靠人工拉語音、打電話、面對面交流的原始協(xié)作方式。
平臺的各方面能力實現(xiàn)了事件全生命周期的閉環(huán)管理。監(jiān)控告警、故障發(fā)現(xiàn)、應(yīng)急響應(yīng)、故障定位、故障恢復(fù)、故障復(fù)盤和故障改進，全階段都通過平臺能力去承載。
- 故障響應(yīng)時，支持了故障的全局應(yīng)急通告，提供了多種通告渠道，信息實時同步不延誤，避免人工同步，漏同步、同步內(nèi)容缺漏等問題；
- 故障跟蹤階段，平臺可以實時展示最新的故障進展；故障影響面、當(dāng)下處置情況，各階段時間等等；
- 故障結(jié)束的復(fù)盤階段，通過定義好的結(jié)構(gòu)化、階段化的復(fù)盤過程，確保復(fù)盤過程中，該問的問題不遺漏，該確認(rèn)的點都確認(rèn)到；
- 故障改進階段，通過對改進項的平臺化錄入，關(guān)聯(lián)相關(guān)責(zé)任方、驗收方，確保改進的有效執(zhí)行和落實。
上圖中是協(xié)同相關(guān)的一些示例，當(dāng)一個故障被創(chuàng)建出來時，會自動關(guān)聯(lián)該故障涉及到的業(yè)務(wù)、組件、基礎(chǔ)設(shè)施的oncall同學(xué)，這些同學(xué)可能是SRE、研發(fā)等，平臺會記錄他們是否有響應(yīng)這些問題，并且當(dāng)下所負(fù)責(zé)的角色是什么。因為角色決定了在該事件中所擔(dān)負(fù)的事項和責(zé)任；下方一鍵拉群，可以將相關(guān)人員，自動拉入到一個群內(nèi)，方便大家進行溝通協(xié)同，并且事件、故障的相關(guān)最新進展也會定期在群內(nèi)同步；涉及到事件的參與人員，事件運營中心的服務(wù)號也會定期推送最新進展，確保不會丟失消息。
上圖是我們內(nèi)部的故障協(xié)同的詳情頁面，提供了記錄簿、故障階段更新、最近變更信息和相似事件，確保每次的響應(yīng)處理，都能形成一個專家經(jīng)驗的沉淀，幫助后續(xù)新來的同學(xué)進行故障響應(yīng)過程的學(xué)習(xí)。
復(fù)盤方面，我們定義了結(jié)構(gòu)化的故障復(fù)盤模板，像相關(guān)人員、組織、影響情況、處置過程、根因分析(在根因分析里面，我們設(shè)置了6問，確保對問題能夠有深度地挖掘)，改進措施等。在復(fù)盤效率方面，我們關(guān)聯(lián)了相關(guān)的變更信息、故障處理時的一些變更操作，以及處理時間線，幫助復(fù)盤同學(xué)快速生成故障的相關(guān)信息，減少人工錄入負(fù)擔(dān)。
五、挑戰(zhàn)與收益
挑戰(zhàn)
在業(yè)務(wù)穩(wěn)定性運營體系的建設(shè)過程中，團隊也踩了很多坑，面臨著諸多技術(shù)之外的挑戰(zhàn)。鑒于業(yè)界對于技術(shù)相關(guān)的分享比較豐富，這里就針對體系邏輯和人員方面的挑戰(zhàn)進行分享。
- 元信息統(tǒng)一
穩(wěn)定性是個大話題，我們在落地整體體系時會發(fā)現(xiàn)，設(shè)計的上下游系統(tǒng)太多了。每個系統(tǒng)里面都會有人、業(yè)務(wù)、職能的使用需求。在初期，我們內(nèi)部在服務(wù)、業(yè)務(wù)和人的關(guān)聯(lián)這塊沒有形成統(tǒng)一的數(shù)據(jù)基準(zhǔn)，導(dǎo)致我們在應(yīng)急協(xié)同的諸多特性上難以落地，諸如故障的有效通知、群內(nèi)的有效傳遞、故障畫像的拓?fù)潢P(guān)聯(lián)計算缺少映射關(guān)系等等。
在這種情況下，我們重新梳理了服務(wù)樹和OnCall系統(tǒng)，通過服務(wù)樹將組織、業(yè)務(wù)和服務(wù)的映射關(guān)系維護好，通過OnCall系統(tǒng)將組織、職能、業(yè)務(wù)和人的映射關(guān)系維護好，來確保找人的時候能找到人，找服務(wù)的時候能找到服務(wù)。
- 工作模式改變
新的應(yīng)急響應(yīng)流程，將故障過往對人的依賴轉(zhuǎn)移到靠系統(tǒng)來自行驅(qū)動，這導(dǎo)致現(xiàn)有人員的工作模式產(chǎn)生了很大變化。傳統(tǒng)故障處理時，響應(yīng)人員手動拉群、語音或現(xiàn)場找人，現(xiàn)在變成了優(yōu)先在系統(tǒng)內(nèi)升級已有事件或錄入故障信息，然后通過系統(tǒng)自動進行人員關(guān)聯(lián)和邀請。群內(nèi)的隨意溝通，變成了在平臺進行階段性進展同步。原有的故障升級邏輯變成了平臺定時通知，這給故障處理人員帶了一定的壓迫感。整體形式上更加嚴(yán)肅和標(biāo)準(zhǔn)，在落地初期給大家?guī)砹艘欢ǖ牟贿m應(yīng)感。針對這種情況，我們一方面通過在系統(tǒng)的文案描述上進行改善，交互邏輯上進行優(yōu)化，盡可能在推行新標(biāo)準(zhǔn)的同時，適應(yīng)舊的使用習(xí)慣。例如，常規(guī)應(yīng)急協(xié)同群會先于平臺的故障通告建立，這就會與平臺創(chuàng)建的故障協(xié)同群發(fā)生沖突。此時，我們通過增加現(xiàn)有群關(guān)聯(lián)來實現(xiàn)已有故障協(xié)同群和故障的關(guān)聯(lián)。另外一方面，我們通過定期持續(xù)的宣講，給大家介紹新的應(yīng)急響應(yīng)流程和平臺使用方法，幫助大家適應(yīng)新的應(yīng)急響應(yīng)模式。
收益
以上就是B站在業(yè)務(wù)穩(wěn)定性運營方面所做的相關(guān)工作。通過體系化建設(shè)，已經(jīng)在組織、流程和平臺層面實現(xiàn)強效聯(lián)動，具備了數(shù)字化運營業(yè)務(wù)穩(wěn)定性的能力，建立了科學(xué)有效的穩(wěn)定性評估提升量化標(biāo)準(zhǔn)，讓穩(wěn)定性提升有數(shù)據(jù)可依托。將故障應(yīng)急響應(yīng)流程從由人工驅(qū)動升級到由平臺系統(tǒng)驅(qū)動，應(yīng)急響應(yīng)人員可以更專心處理故障，大幅提升故障恢復(fù)時間。后續(xù)我們將會持續(xù)探索更科學(xué)有效的管理運營方法，期望通過引入AI的能力，提升故障輔助定位能力、提早發(fā)現(xiàn)故障隱患，聯(lián)動預(yù)案平臺實現(xiàn)更多場景的故障自愈。
網(wǎng)站欄目：B站崩的那晚，連夜謀劃了這場穩(wěn)定性保障SRE升級之戰(zhàn)……
標(biāo)題路徑：http://m.fisionsoft.com.cn/article/cdoosgp.html
