隨著B站近幾年的快速發展，業務規模越來越大，迭代速度越來越快，系統運行復雜度也越來越高。線上每天都會發生各種各樣的故障，且發生的場景越來越刁鉆。為了應對這種情況，保障業務在任何時刻都能將穩定性維持在一個高基線之上，B站專門成立了SRE體系團隊，在提升業務穩定性領域進行了全方位、體系化的積極探索，從理論性支撐和能力化建設進行著手，從故障應急響應、事件運營、容災演練、意識形態等多方面進行穩定性運營體系的構筑。

本次分享主題是B站SRE在穩定性方面的運營實踐，分享內容分為以下幾個部分：

• 案例剖析
• 從應急響應看穩定性運營
• 核心運營要素有哪些
• 兩個運營載體：OnCall與事件運營中心
• 挑戰與收益

一、案例剖析

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

我們先來看兩個案例，案例以真實事件為依托，相關敏感內容進行了改寫。

案例一

1）背景

一個手機廠商的發布會在某天晚上12點舉辦，B站承接了該品牌的線上發布會直播。公司的運營同學提前就配置好了12點的直播活動頁面以及準點的應用內Push消息。在12點到來之后，直播活動頁推送生效，大量用戶收到應用內推送消息，點擊進入直播活動頁面。

2）故障始末

12點01分，直播活動頁內嵌的播放器無法支持部分用戶正常加載播放。

12點03分，研發同學李四收到了異常的報警，開始介入處理。

12點04分，客服同學收到了大量有關發布會無法正常播放的用戶反饋，常規處理方法無法解決用戶問題。

影響持續到12點15分，研發同學李四還在排查問題的具體原因，沒有執行相對應的止損預案（該種問題有對應預案），問題持續在線上造成影響。

直到12點16分，老板朋友找到了老板反饋今晚B站的某品牌手機直播發布會頁面視頻無法正常播放，此時老板開始從上往下詢問，研發leader知道了這件事，開始聯系SRE同學介入問題處理，并及時執行了相關的切換預案，直播活動頁面播放恢復正常。

3）問題

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

• 故障的相關告警雖然及時，但是并沒有通知到足夠多對的人。
• 該故障的告警，在短時間沒有處理響應后，并未進行有效的結構性升級（管理升級，及時讓更高level的人參與進來，知曉故障影響，協調處理資源）和職能性升級（技術升級，讓更專業和更對口的人來參與響應處理，如team leader、SRE等）。
• 一線同學往往容易沉迷于查找問題根因，不能及時有效地對故障部位進行預案執行。

案例二

1）背景

一個平淡無奇的周末晚上，23點30分，監控系統觸發大量告警，幾乎全業務線、各架構層都在觸發告警。

2）故障始末

23點40分，企業微信拉了有十幾個群，原有的業務溝通群、基礎服務OnCall群，都在不停地轉發告警，詢問情況。整個技術線一片恐慌，起初以為是監控系統炸了。此時相關故障的SRE同學已經被拉到某一個語音會議中。

注意，此時公司的多個BU業務線同學都炸鍋了，到處咨詢發生了什么，業務怎么突然就不炸了。又過了幾分鐘，資深的SRE同學又拉了一個大群，把相關業務對接人都拉進群里，開始整體說明故障情況。此時，該同學也比較糾結如何通報和說明這個問題，因為此時沒有一個明確故障定位，語言很難拿捏，各個高level的老板也都在問（已上熱搜）。并且，負責恢復入口服務的一線同學把故障預案執行了個遍，發現無濟于事。后續在GSLB調度層，執行了整個跨機房的流量有損切換才讓服務逐漸恢復正常。

凌晨之后，原有機房的問題定位出來了，補丁迅速打上，異常的問題徹底修復了。后續，在對此事件進行復盤時，發現困難重重。因為故障處理過程中，涉及到大量的服務、組件和業務方，并且大家當時拉了一堆群，同樣的消息被發送到了很多群。參與處理故障的同學在語音、電話和企微群都有進行過溝通和處理進展發布，整個事件的細節整理起來非常耗費人力和精力，準確性也很難保障。

3）問題

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

案例剖析

通過對上述兩個案例的分析我們能夠發現，在故障發生前、處理中和結束后，各個階段都會有很多因素導致我們的故障不能被快速解決，業務不能快速恢復。

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

1）事前

• 告警信息量大，信息太過雜亂；
• 平臺系統繁多，變更信息無處收斂；
• 客服反饋的信息，需要靠人工去關聯，并反饋到技術線；
• 和公司輿情相關的信息，技術線很難感知到。

2）事中

• 一線同學過于關注技術，沉迷問題解決；
• 當一個故障影響面擴大之后，涉及多個團隊的協同非常困難，最新的進展消息無法及時有效地傳遞到相關人員手中；
• 當參與一個故障處理的人員多了之后，多個人員之間缺乏協調，導致職責不清晰，產生事情漏做、重復做的問題；
• 故障處理過程中，會有一些不請自來，湊熱鬧的同學。

3）事后

• 當我們開展復盤時，發現故障處理時又是群、又是電話、又是口頭聊，又是操作各種平臺和工具，做了很多事情，產生了很多信息，梳理時間線很繁瑣，還會遺漏，寫好一份完整的復盤報告非常麻煩；
• 拉一大堆人進行復盤的時候，因為缺少結構化的復盤流程，經常是想到什么問什么。當某場復盤會，大家狀態好的時候，能挖掘的點很多。如果狀態不好或者大家意識上輕視時，復盤的效果就較差；
• 復盤后產出的改進事項，未及時統一地記錄跟進，到底有沒有完成，什么時間應該完成，完成的情況是否符合預期都不得而知；
• 對于已經修復的問題，是否需要演練驗收確保真正修復。

以上三個階段中可能發生的各種各樣的問題，最終只會導致一個結果：服務故障時間增長，服務的SLA降低。

二、從應急響應看穩定性運營

針對上述問題，如何進行有效改善？這是本部分要重點分享的內容，從應急響應看穩定性運營。

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

三、核心運營要素有哪些

做好應急響應工作的核心目標是提升業務的穩定性。在這個過程中，我們核心關注4大要素。核心點是事件，圍繞事件有三塊抓手，分別是人、流程和工具/平臺。

人作為應急響應過程中參與和執行的主體，對其應急的意識和心態有很高要求。特別是在一些重大的故障處理過程中，不能因為壓力大或緊張導致錯誤判斷。

流程將應急響應的流程標準化，期望響應人能夠按照既定階段的既定章程進行有效的推進和處理。

工具/平臺支撐人和流程的高效合規運行，并將應急響應的過程、階段進行度量，進而分析和運營，推進人和流程的改進。

事件

1）生命周期劃分

要對故障進行有效運營，就需要先明確故障的生命周期。通過劃分故障的生命周期，我們可以針對不同的周期階段進行精準聚焦，更有目的性地開展穩定性提升工作。

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

按故障的流程順序劃分，可以分為故障防御、故障發生、故障響應、故障定位和故障恢復、復盤改進等階段。

這里我圍繞故障的時間階段，從故障不同階段的形態變化做拆分，將故障拆分為四個階段。

• 告警/變更/客訴

當故障還未被確認時，它可能是一個告警、變更或客訴。

• 事件

當這個告警、變更、客訴被上報后，會產生一個事件，我們需要有人去響應這個事件，此時一個真正的事件就形成了。

• 故障

當事件的影響范圍逐漸擴散，這時往往有大量的用戶、業務受到影響，我們需要將事件升級成故障，觸發故障的應急協同，進行一系列的定位、止損等工作。

• 改進

故障最終會被恢復，接下來我們要對故障進行復盤，產生相關改進項，在改進項被完成之后，還需要進行相關的驗收工作。

2）階段度量

從更科學的角度看，我們知道在運營工作中，度量是很關鍵的一點。管理學大師彼得·德魯克曾經說過：“你如果無法度量它，就無法管理它”。有效的度量指標定義，可以幫助我們更好更快地開展運營工作、評估價值成果。上文中我們提到的3個階段是比較籠統的階段，接下來我將介紹更加具體和可執行的量化拆分方法。

如上圖所示，從故障預防依次到故障發現，故障定位，故障恢復，最后到故障改進，整體有兩個大的階段：MTBF（平均無故障時間）和MTTR（平均故障恢復時間）。我們進行業務穩定性運營的核心目標就是降低MTTR，增加MTBF。根據Google的定義，我們將MTTR進一步拆分為以下4個階段：

• MTTI：平均故障發現時間，指的是故障發生到我們發現的時間。
• MTTK：平均故障定位時間，指的是我們發現故障到定位出原因的時間。
• MTTF：平均故障修復時間，指的是我們采取恢復措施到故障徹底恢復的時間。
• MTTV：平均故障修復驗證時間，指的是故障恢復之后通過監控、用戶驗證真實恢復的時間。

3）關鍵節點

基于階段度量的指標，我們能夠得到一系列的關鍵時間節點。在不同的階段形態，事件和故障會存在一些差異。故障因為形態更豐富，所存在的時間節點更多。上圖中定下來的時間，均是圍繞MTTR進行計算的。主要是為了通過度量事件、故障的處理過程，發現過程中存在的問題點，并對問題點進行精準優化，避免不知道如何切入去提升MTTR的問題，也方便我們對SRE的工作進行側面考核。

人

人作為事件的一個主體，負責參與事件的響應、升級、處置和消息傳播。

人通過上文中我們講到的OnCall參與到應急響應中。我們在內部通過一套OnCall排班系統進行這方面的管理。這套系統明確了內部的業務、職能和人員團隊，確保人員知道什么時間去值什么業務的班。下面的工具/平臺部分會展開介紹。對參與人的要求，主要有以下幾點：

• 具備良好的響應意識和處理心態。
• 具備熟練地響應執行的經驗。

滿足以上特征，才能做到故障來臨時響應不慌亂，有條不紊地開展響應工作。

流程

那么針對人的要求如何實現？人員如何參與到應急響應的環節中去？人員的意識如何培養呢？

首先，我們內部制定了應急響應白皮書，明確了以下內容：

• 響應流程；
• 基于事件大小，所要參與的角色和角色對應的職責；
• 周邊各個子系統SOP制定的標準規范；
• 針對應急過程中的對外通告內容模板；
• 故障過程的升級策略。

之后，我們會周期性地在部門內部、各BU進行應急響應宣講，確保公司參與OnCall的同學能夠學習和掌握。另外，我們也會將其作為一門必修課加入新同學的入職培訓中。最后就是故障演練，通過實操，讓沒有參與過故障處理的新同學能夠實際性地參與應急響應的過程，避免手生。

平臺

平臺作為支撐人與流程進行高效、穩定執行的載體，我將在下一部分進行具體描述。

四、兩個運營載體：OnCall與事件運營中心

這部分我將向大家分享B站在應急響應方面落地的兩個運營性平臺。

OnCall系統

OnCall系統，即值班系統。值班系統在日常運轉過程中的作用往往被低估，SRE、工程效率做這部分建設時，很容易基于二維的方式對人和事進行基于日歷的值班管理，并通過網頁、OpenAPI等方式對外提供數據服務。

下面我們通過幾個例子來說明OnCall的必要性。

在日常工作中，當我們使用公司某個平臺功能時，可能會習慣性找熟悉的同學，不管他這一天是不是oncall。這可能給那位同學帶來困擾，他可能上周才值完班，這周要專心于研發或者項目的推進，你隨時找他可能打斷他的工作節奏。還有一種情況是新同學不知道該去找誰，我們內部之前經常有這種情況，一個新來的同學接手一套系統之后，有問題不知道該找誰，經常要轉好幾手，才能找到對的人，這一過程很痛苦。

以上內容總結起來就是總找一個人，總找不到人，除此之外，還會出現平臺找不到人的情況。這些問題的根源是什么呢？無非就是who、when、what和how的問題，不能在正確的時間為正確的事找到正確的人。

那么OnCall系統的重要性和必要性都體現在哪些方面呢？

• 有問題找不到人

隨著公司業務規模的擴大和領域的細分，一些新的同學和新業務方往往會出現一個問題。不知道是哪些人負責，需要咨詢很多人才能找到具體解決問題的人。這一問題不僅限于故障，更存在于日?，嵤轮?。特別是SRE同學的日常，經常會被研發同學咨詢找人拉群，戲稱拉群工程師。

• 下班不下崗

當人們遇到問題時，經常會下意識找熟悉的人。這就導致一些能力強、服務意識好的同學，總是在被人找。不論他今天值不值班，他將無時無刻都要面臨被人打擾的問題。除了被人找之外，內部的監控系統、流程系統，也會給不值班的同學發送監控告警和流程審批信息。這也將SRE同學有50%的時間用于工程這一愿景變成泡影。

1）設計

① 明確關聯邏輯

針對上述兩種情況，我們對公司的業務、服務、職能和組織架構進行了分析建模，明確了人、團隊、職能和業務之間的關聯關系。

② 建立三維合一模型

我們構建起了一套三維合一的模型。由組織-業務、職能-人員、組織-職能的關聯關系，產生交匯點。值班人員會通過值班小隊的方式，落在這些交匯點上，并且基于業務和基礎架構的異同點，通過業務視角和職能視角分別對外提供服務。

以我們公司內部主站業務為例，我們會有專門的SRE小隊進行日常的值班響應，這個小隊只負責主站業務的值班響應。通過這樣的對應關系，當人或平臺有需求的時候，都可以通過業務和職能關聯到對應實踐的值班小隊，最終定位到具體的人，這樣也幫助我們將人藏了起來，更有利于后續SRE輪崗機制的推進落地。

③ 雙視角提供服務

通過雙視角的設計，區分了職能型和業務型的不同值班方式和關注點。原因在于B站的業務層級組織模式是按照“組織->業務->應用”這三級進行組織的，所有的應用歸屬到業務，業務歸屬到具體的組織架構。

• 職能視角

前端采用樹型展示，組成結構為組織->職能->覆蓋范圍（組織->業務->服務），值班表具體掛載在覆蓋范圍下，覆蓋范圍可以只有一級組織也可以精確到組織下面的業務或業務下面的服務。

• 業務視角

前端采用樹型展示，組織結構為組織->業務->職能，值班表具體掛載在職能下面。

在日常工作中，基礎架構相關的服務，比如SRE、DBA、微服務、監控、計算平臺等強職能型服務會通過職能視角對外提供值班信息。當業務人員有具體問題時，可以通過職能樹快速定位到具體的值班人員。而對于業務服務來講，日常的工作模式是圍繞業務開展的，因此會通過業務進行展開，提供該業務下相關職能的對應值班信息。

這兩個視角的底層數據是相通的，強職能相關服務提供方只需要維護好職能視角的值班信息，業務視角下的關聯會自動生成。

2）功能展示

基于以上設計，我們內部做了一套OnCall排班的系統。

這套系統是管理業務、職能和人的系統。我們基于上文中提到的幾個核心概念，在這些概念間建立了關系，分別是兩條線，一條是職能-團隊和人，另外一條是職能-業務和服務。

系統提供了排班班組的管理，支持基于日歷的排班，同時支持班組設置主備oncall角色。在排班的細節上，我們支持基于時段進行自動排班計劃生成，也支持在一個職能里多個班組混合排班。另外，也支持對已經排好班的班組，進行覆蓋排班和換班，這個主要應對oncall同學突然有事請假的情況。在oncall通知方面，我們支持了企業微信、電話等通知方式，并且支持虛擬號碼的方式，保護員工號碼不對外泄露。同時也避免了因為熟悉導致的頻繁被打擾的情況。

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

事件運營中心

事件運營中心這套系統是我們基于ITIL、SRE、信息安全應急計劃的事件管理體系，為了滿足公司對重大事件/故障的數字化管理，實現信息在線、數據在線和協同在線，使組織能夠具備體系化提升業務連續性能力所做的產品平臺。這個平臺的定位是一站式的SRE事件運營中心，數字化運營業務連續性的目標是提升MTBF，降低MTTR，提高SLA。

1）架構設計

上圖是我們平臺的模塊架構圖，整體上還是圍繞上文提到的事件的事前、事中和事后三個階段拆分，覆蓋了一個事件產生、響應、復盤、改進的全生命周期。

• 事前

我們對事件進行了4大類型的拆分，分別是告警、變更、客訴和輿情，然后通過設計標準的事件上報協議，以集成的方式將我們內部的各個系統打通，將事件信息統一收集到一起。在收集的過程中，進行二次處理，實現事件的結構化轉儲。

• 事中

我們會對接入的4大類型信息進行事件轉化，然后通過預定義的規則對事件進行降噪，抑制、報警、召回、分派和升級等相關操作。在這個過程中，如果一個事件被判定影響到業務，我們會將它升級成一個故障，然后觸發故障的應急響應流程。這里就進入到對故障響應處理過程中的一個階段，在這個階段我們會產生各種角色，例如故障指揮官、故障通訊人員、故障恢復人員等，相關人員明確認領角色，參與故障的止損。止損過程中，通過平臺一鍵拉群創建應急響應指揮部，通過平臺的進展同步進行相關群和業務人員的通告，通過記錄簿實現故障信息的信息傳遞和記錄。

• 事后

在故障結束之后，就進入到我們整體的改進環節。平臺可以基于故障一鍵創建復盤報告，自動關聯故障處理過程中的專家數據。平臺提供預制的故障復盤問答模板，以確認各階段是否按照預期的目標進行。復盤產生的待辦列表，平臺會進行定期的狀態提醒和處理進度跟進。最終的這些都會以知識的形式，沉淀在我們的知識庫。幫助日常On-Call問答和公司內部員工的培訓學習。整體這樣一套平臺流程下來，就實現了將一些日常高頻的非結構性事務驅動，通過統一接入、精準觸達、事件閉環和持續改進等環節，轉化為低頻的結構化數據驅動方式。

2）場景覆蓋

下面我們介紹平臺在各個場景的覆蓋。

① 集約化

對事件產生的上游來源進行集約化管理，通過隊列訂閱、API和SDK的方式，將內部的監控，Prometheus、監控寶等各個云平臺的監控都通過前面的4大類型定義收歸到一起，然后統一進行通知觸達。

② 標準事件類型

為了實現各個渠道消息的結構化規約，我們設計了標準的事件模型，通過這個事件模型，我們將周邊各個系統/工具/平臺進行收集，并且實現了事件的關聯操作。模型主要分為4部分：

• base是一些事件的基礎信息字段；
• who是指這一事件來自哪里，有哪些相關方；
• when是指事件發生或產生影響的時間；
• where是指事件來源于哪個業務、影響了哪些業務；
• what是指這個事件的具體內容，它的操作對象是什么等等。

③ 降噪聚類

由于我們對事件的上報結構進行了標準化，并且預埋了關聯字段，通過這些關聯字段，我們就建立起了事件的關聯關系，從而可以做事件的降噪聚類。

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

• 橫向抑制

我們支持對單個來源的事件、告警，通過定義的規則進行收斂，比如Prometheus報警出一個服務在某個持續時間內持續報了N條一樣的告警信息，平臺會收斂到一個事件中去。

• 縱向抑制

這對上文中提到的底層系統故障十分有效，可以將底層故障導致的上層業務告警都統一收到一個事件中，避免大量告警使大家造成混淆。

④ 協同在線

在協同在線的場景下，我們通過一個面板將人、業務、組件和系統信息進行了匯總，通過一個事件詳情頁，將整個事件當下的處理人、關聯業務和服務組件、當下的一些信息統一展示在一起。在協同能力上，我們提供了一鍵創建應急響應群的功能，建群時會自動關聯該故障相關oncall同學，對故障感興趣的同學也可以通過面板加入響應群。在故障頁面，清晰看到故障當前的指揮官是誰，當下的處理人是哪些同學。徹底解決了之前靠人工拉語音、打電話、面對面交流的原始協作方式。

平臺的各方面能力實現了事件全生命周期的閉環管理。監控告警、故障發現、應急響應、故障定位、故障恢復、故障復盤和故障改進，全階段都通過平臺能力去承載。

• 故障響應時，支持了故障的全局應急通告，提供了多種通告渠道，信息實時同步不延誤，避免人工同步，漏同步、同步內容缺漏等問題；
• 故障跟蹤階段，平臺可以實時展示最新的故障進展；故障影響面、當下處置情況，各階段時間等等；
• 故障結束的復盤階段，通過定義好的結構化、階段化的復盤過程，確保復盤過程中，該問的問題不遺漏，該確認的點都確認到；
• 故障改進階段，通過對改進項的平臺化錄入，關聯相關責任方、驗收方，確保改進的有效執行和落實。

上圖中是協同相關的一些示例，當一個故障被創建出來時，會自動關聯該故障涉及到的業務、組件、基礎設施的oncall同學，這些同學可能是SRE、研發等，平臺會記錄他們是否有響應這些問題，并且當下所負責的角色是什么。因為角色決定了在該事件中所擔負的事項和責任；下方一鍵拉群，可以將相關人員，自動拉入到一個群內，方便大家進行溝通協同，并且事件、故障的相關最新進展也會定期在群內同步；涉及到事件的參與人員，事件運營中心的服務號也會定期推送最新進展，確保不會丟失消息。

上圖是我們內部的故障協同的詳情頁面，提供了記錄簿、故障階段更新、最近變更信息和相似事件，確保每次的響應處理，都能形成一個專家經驗的沉淀，幫助后續新來的同學進行故障響應過程的學習。

復盤方面，我們定義了結構化的故障復盤模板，像相關人員、組織、影響情況、處置過程、根因分析(在根因分析里面，我們設置了6問，確保對問題能夠有深度地挖掘)，改進措施等。在復盤效率方面，我們關聯了相關的變更信息、故障處理時的一些變更操作，以及處理時間線，幫助復盤同學快速生成故障的相關信息，減少人工錄入負擔。

五、挑戰與收益

挑戰

在業務穩定性運營體系的建設過程中，團隊也踩了很多坑，面臨著諸多技術之外的挑戰。鑒于業界對于技術相關的分享比較豐富，這里就針對體系邏輯和人員方面的挑戰進行分享。

• 元信息統一

穩定性是個大話題，我們在落地整體體系時會發現，設計的上下游系統太多了。每個系統里面都會有人、業務、職能的使用需求。在初期，我們內部在服務、業務和人的關聯這塊沒有形成統一的數據基準，導致我們在應急協同的諸多特性上難以落地，諸如故障的有效通知、群內的有效傳遞、故障畫像的拓撲關聯計算缺少映射關系等等。

在這種情況下，我們重新梳理了服務樹和OnCall系統，通過服務樹將組織、業務和服務的映射關系維護好，通過OnCall系統將組織、職能、業務和人的映射關系維護好，來確保找人的時候能找到人，找服務的時候能找到服務。

• 工作模式改變

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

收益

以上就是B站在業務穩定性運營方面所做的相關工作。通過體系化建設，已經在組織、流程和平臺層面實現強效聯動，具備了數字化運營業務穩定性的能力，建立了科學有效的穩定性評估提升量化標準，讓穩定性提升有數據可依托。將故障應急響應流程從由人工驅動升級到由平臺系統驅動，應急響應人員可以更專心處理故障，大幅提升故障恢復時間。后續我們將會持續探索更科學有效的管理運營方法，期望通過引入AI的能力，提升故障輔助定位能力、提早發現故障隱患，聯動預案平臺實現更多場景的故障自愈。