2021年7月13日，bilibili 出現了一次服務不可用的宕機事故。一年以后，bilibili 技術團隊以一篇事故復盤的文章刷爆了技術人的朋友圈，這一次典型的技術事故，卻成了一個非典型的技術故事。

　　類似的黑天鵝事件時有發生，有的或出于單體應用的代碼規范問題，有的或出于瞬時流量的峰值涌入，有的或因為云廠商的服務抖動受到牽連。可以說，后端研發人員的成長之旅，往往伴隨著對黑天鵝事件的防范、處理、教訓，互聯網服務這么多年發展至今，高可用能力到了什么程度，是否能幫助企業規避黑天鵝事件的發生?上云是否是這個時代保證服務穩定性的有效途徑?企業技術管理者又該如何居安思危，調整技術架構?

　　9月25日，騰訊云 TVP 走進 B 站，暢聊「高可用 VS 黑天鵝」的那些事兒，相信能給你一些不一樣的啟發。本文為本次活動精華總結。

　　bilibili云原生架構演進

　　bilibili 技術委員會主席、騰訊云 TVP 毛劍帶來了題為《bilibili 云原生架構演進》的主題分享。

　　毛劍老師介紹道，bilibili 的云原生演進大體上始于2015年，主要歷程涵蓋了微服務、容器化和中間件三個關鍵環節：

　　微服務：伴隨著業務的發展、DAU 的爆發，2015年開始從單體轉向微服務，面對單體架構無法擴展、可靠性低的問題，應對的思路概括為“化繁為簡，分而治之。

　　容器化：15年最初部署在裸金屬上;16年開始使用 Mesos+Marathon 進行容器編排，17年遷移到 Kubernetes，之后很快在線應用彈性公有云上線。20年離線 Yarn 和 在線 K8S 做了在離線混部(錯峰使用)，基于混部 Agent，協調分配資源。22年離線 Flink、Spark Native on K8S，開始逐漸嘗試覆蓋，統一調度架構，完成統一調度。

　　中間件：容器+微服務的組合帶來的應用爆發式增長給架構帶來了巨大挑戰，為此引入了開源社區的組件，在性能、穩定性能達到要求的情況下，盡可能使用開源方案，少量組件需要二次開發和迭代。

　　從架構設計的層面上看，從CDN到接入層再到服務/中間件/存儲、可觀測、效率體系、穩定體系，每個環節都有穩定性、可用性的保障，每一層都有不同技術人員去做維護和迭代。毛劍老師表示，設計很美好，但黑天鵝該來還得來。

　　毛劍老師表示，從技術人員的視角看，可用性保障的核心就是流量能否得到有效管控。無論是網絡故障、機房故障、組件故障還是服務故障，每一層都應該設計備有相應的容錯機制，以避免事故發生或在事故發生時能快速定位、及時修補。

　　在 bilibili 2021年發生的7.13事故中，引發的原因就是接入層SLB不可用了。毛劍老師詳細分享了本次事故所暴露出的基礎技術建設方面的問題，諸如：

　　用戶鏈路和辦公網鏈路未徹底隔離

　　多活未按預期立即生效，不支持寫

　　人力不足，故障止損和排查無法并行

　　組件故障預案不完善，處理耗時久

　　復雜事故影響面極大，定位成本高

　　……

　　毛劍老師表示，多活是機房級故障時容災止損最快的方案。在這樣的背景下，bilibili 做了多活基架能力建設、多活管控能力提升的針對性改進。在 bilibili 技術委員會成立后，選擇了擁抱云原生，以強調工程一致性的方式做云原生的落地建設。

　　另一方面，針對容災、快速切換的高可用能力方面，設計了同城雙活的架構，具體如下圖所示。

　　隨著業務的快速演進，bilibili 開始從 Global Zone(單點全局業務)演進到同城雙活、異地 AZ 的建設，逐漸也過度到異地多活。毛劍老師表示，實現單元化用戶流量的混合云架構是 bilibili 一直在追求做的事情，包括在急需擴容的情況下，可依托于云廠商的云原生技術基礎能力，在云上新建一個 RZone/CZone Shard，遷移部分用戶 bucket 流量，發揮云的彈性優勢，實現共贏。

　　分享最后，毛劍老師也基于 bilibili 的業務場景，解釋了 bilibili 為何要在私有云架構之上再上公有云的實際思考。

　　大變革時代研發團隊的重塑

　　有贊技術副總裁、顧問，騰訊云 TVP 沈淦帶來了題為《大變革時代研發團隊的重塑》的主題分享。

　　分享伊始，沈淦老師為大家介紹了大變革的時代背景下，舊經濟模式與新經濟模式的變化。當前的企業從以前的“活得好”到現在開始思考如何“活下去”，這背后折射的是經濟底層范式的重置：從絕對經濟優先轉變為可持續、社會公平、數據安全、自主可控的新經濟模式。在內卷的舊經濟時代，技術管理的核心價值，是打造技術團隊超(無限)高的交付效率。

　　從舊經濟到新經濟的轉變過程中，技術團隊的使命和價值也發生了相應的變化。從行為到職責，需要改變的地方有很多。如下圖所示，當前大部分的技術團隊仍舊處于圖中的第二階段，效率和成本仍是核心價值，但新經濟要求的的速度和適應性的價值已經更為突出。

　　沈淦老師以 SaaS 行業為例，介紹了價值驅動業務模式的三條主線：其一是高技術密度的產品力;其二是商業化能力;其三是從客戶之聲到 CSGB 的客戶成功。這三條線大多數業務團隊都有在做，但大部分彼此之間都比較孤立，沒有形成有機結合，效果不佳。

　　另一方面，對于考核體系的理解也有待革新。過去的考核體系主要關注點落在“做了什么”的動作上，聚焦功能、非功能需求的實現。當前階段開始由做了什么到做成了什么轉變，關注GMV增長、PV/UV、穩定性等等。而對技術人員而言，終極的目標應該是價值的實現——達成了什么?是爆款?是增購?還是客戶的推薦?

　　沈淦老師將以上所體現的理念總結為了“找價值、設指標、拆流程、建團隊”的端到端流程四步法。這四個步驟拆開來看，單個環節可能每個技術團隊都有涉及到，但只有按照一定的順序、有機結合地去做，才能產生更大的業務價值。

　　“流程四步法中最難的也許是建團隊”，從組織結構上去撬動杠桿往往是最難的地方，因為這背后涉及到人與人之間的連接。沈淦老師舉例指出，建團隊有三個基本理論需要關注，其一是康威定律，其二是認知負荷，其三是隧道視野。技術團隊的管理者應該從大處著眼，小處著手，由點及面地完成高效能團隊的構建工作。

　　騰訊自研業務上云背后的高可用實踐

　　騰訊云云原生產品中心技術總監王濤帶來了題為《騰訊自研業務上云背后的高可用實踐》的主題分享。

　　王濤老師首先簡要分享了騰訊自研業務容器化上云的歷程。技術路線上，從胖容器到富容器再到微容器，演化到 Serverless、FaaS 的形態，同時持續著在離線混部、在線混部的實踐，包括 Service Mesh 也都有持續的應用。

　　王濤老師介紹到，經過3-4年的大規模自研業務云原生實踐，騰訊在各個技術方向和業務場景都沉淀了大量的解決方案。與此同時持續反哺給公有云產品，提升各種業務場景下的核心技術競爭力。

　　在這樣的背景下，騰訊的云原生成熟度模型演進到 V2.0 版本，從平臺和業務兩個維度，考察云原生的能力。在這樣的模型考量下，騰訊自研業務上云的規模及成熟度也保持了一個持續上揚的趨勢，業務和平臺的云原生成熟度都得到了持續提升，價值得以量化。

　　王濤老師分析到，容器平臺穩定性主要涵蓋平臺層穩定、集群層穩定、節點層穩定、業務層穩定幾個方面。他重點分享了節點穩定性和業務穩定性的case，持續深耕云原生OS，提供更好的容器隔離性能力和可觀測性，與此同時騰訊也在逐步大規模使用 Serverless K8s(EKS)的產品能力，徹底解決容器隔離性問題，并實現了統一大資源池的調度能力。

　　在業務容災的成本方面，過去面向集群業務管理效率低、容災部署成本高，改造的目標是快速實現業務的多地域多活部署、一鍵發起應用的全球灰度變更，業務灰度期間只需偶爾關注應用大盤視圖即可掌控整體灰度情況，極大的提升了應用管理效率，這對大規模的應用管理極其重要。

　　王濤老師表示，這背后涉及到的關鍵技術有很多，比如騰訊開源的多集群管理項目Clusternet、多集群的應用聲明、面向應用的多集群協同彈性伸縮能力和動態拆分調度能力等，最終以面向應用的”屏蔽集群、模糊可用區“等產品能力，幫助業務快速實現同城多活、兩地三中心等容災部署能力。全球多地域一次性高可用部署以及豐富的多集群業務灰度變更策略等，幫助業務提升容災部署/變更的效率以及可用性。

　　在服務路由的高可用方面，通過騰訊內部自研的服務東西向流量管理“北極星Polaris”，提供解決包括遠程過程調用(RPC)的服務注冊與發現、動態路由、負載均衡、服務熔斷等一系列的超大規模和高性能的服務路由管理能力。輔以Kubernetes Controller的方式對接北極星，進一步提升了Pod狀態和服務實例可用性的聯動實時性，加快了實例故障自動剔除等關鍵動作。

　　在混沌工程方面，騰訊云所有云產品都必須參與日常混沌演練，提前發現產品隱患，提升云產品的可用性。由此也孵化出了公有云混沌演練平臺，日常通過高可用攻擊演練的方式，鍛煉運營質量與架構的高可用改造，在故障真實發生時從容應對。

　　云上高可用能力建設

　　騰訊云高可用專家服務負責人廖行星帶來了題為《云上高可用能力建設》的主題演講。

　　分享伊始，廖行星老師從黑天鵝和高可用的關系上做了一個論斷——黑天鵝是一個現象，是一個結果，但高可用/異構系統，以及技術側的能力，是對應的治理手段和方法，我們是期望通過這樣的方法來降低，或者說控制黑天鵝事件對業務的影響時長和范圍。

　　對于高可用能力的度量指標，廖行星老師總結了以下幾個關鍵：RTO 恢復時間目標;RPO 恢復點目標;WRT 工作恢復時間;MTD 最大可容忍停機時間。高可用能力的價值體現，如下圖所示：

　　廖行星老師表示，異地多活的能力是服務高可用的關鍵，在技術目標上主要可以分為以下幾個維度。

　　DNS 調度。常見影響 DNS 調度的因素有 locallands 多出口、locallands 不支持 ECS、NS 不支持 ECS、NS 的 IP 庫不準確等，由此帶來的技術目標是需要能夠保證大部分流量調度的準確性。

　　路由層流量糾偏。利用openresty流量糾編實現，確保流量精確流入某一region。

　　邏輯層單元化建設。徹底單元化，確保region間無數據流動。

　　數據層數據同步。數據回環，一致性，數據沖突。

　　在災難切換方面，重點步驟可以總結為以下幾點：

　　1.多活規則中心下發禁寫通知和禁寫時間基線

　　2.數據庫SDK收到禁寫數據庫寫入和更新

　　3.雙向復制器收到超過禁寫時間基線不再復制

　　4.雙向復制器上報復制完成狀態

　　5.多活規則中心下發流量切換通知

　　6.Nginx&網關層收到將流量切換到機房B并上報切換完成狀態

　　7.多活規則中心下發取消禁寫通知

　　廖行星老師介紹道，騰訊云在高可用能力建設方面做了很多技術上的實現工作，在路由層面上，API網關+SCF可以實現復雜的流量染色場景;在接入層方面，CLB 具備就近接入、VIP 漂移的高可用能力;在邏輯層方面，騰訊云微服務平臺 Tencent Service Framework(TSF)提供微服務全生命周期管理、服務可觀測、配置管理、服務治理及業務容災架構能力;在數據層方面，CDB&DTS 能夠有效實現數據的一致性、數據回環等。

　　觀點眾議

　　精彩的分享結束后，TVP 們還在線下展開了一場別開生面的小組討論會，在場嘉賓分為三組針對三個高可用話題展開了討論，并派出了三位小組代表(劉意、毛劍、大漠窮秋)做要點總結。

　　對于體量較小的企業而言，是否有必要提前搭建高可用的容災體系？

　　劉意：我們這桌正好有創業者，他們公司跟 bilibili 有點類似，都是重 IT 的客戶。對于類似的小體量企業，不具備 bilibili 的業務體量時，是不需要重度發展高可用容災體系的，更多可以用多云多活的架構來部署自己的業務系統。這樣做的好處是可以確保自己的業務在 A 云中發生故障時可以平滑地遷移到 B 云，平時也可以通過演練確保切換動作的絲滑流暢。還有一個好處就是可以利用兩方云平臺的成本體系去平衡成本，實現降本增效。

　　毛劍：對于小體量企業而言，PaaS 平臺的搭建的確很花精力。很多人以為用了云就具備了高可用能力，其實不然，小企業仍舊需要懂 SRE 去主動培養高可用的意識。服務穩定性的影響因素有很多，僅僅是研發人員寫的一個 bug，同樣會對其造成不可估量的影響。這背后需要一系列的手段去做避免，本質上是一個系統工程。小企業可以不建平臺，可以只用云的能力，但一定要具備 SRE 的意識。

　　大漠窮秋：我職業生涯里經歷過兩次自己搞出來的故障，影響都比較大，一次是在某電力系統公司搞掛了監控系統的庫，另一次是在接手舊系統的維護升級工作時優化了代碼格式刪除了多余空行導致系統故障，這兩次都是在相對互聯網而言較小的企業里。對于小企業而言，體量只是其中的一個因素，另外還需要去考量企業是否會在某個階段突然獲得爆發式的增長，比如最近很火爆的一些現象級的小游戲，判斷增長的空間才有足夠合理的提前搭建高可用容災體系的必要。

　　目前眾多的冷備、熱備、雙活、多活、同城、異地、多云等災備方案中，如何更好的選擇貼合自身要求的高可用和容災架構方案？

　　劉意：多云多活的方案中，bilibili 和喜馬拉雅都選擇了混合云的模式。大部分企業并不常遇到數據庫爆炸一樣的極端情況，也不像銀行業一定要異地多活高規格的容災體系，一般而言雙活就能起到高可用的作用足夠滿足需求了。相比其他而言，提高 IT 團隊的管控能力可能更為重要。此外，要讓業務在自建 IDC 和上云之間做好選擇，哪些核心系統上云，哪些不用，充分利用自建 IDC 數據的可靠性，確保業務跑得更快、更好。

　　毛劍：很多人對系統的多活容災有誤解，多活在技術上對時間、精力的消耗很大，但幾乎沒有產生附加價值，所以技術團隊在做多活方案之前一定要考慮到業務的 ROI。類似交易型電商、金融行業，對異地多活的需求會比較高，但大部分業務做到同城雙活就足夠了。建設多活的核心其實就是兩點，第一是思考出現停機問題時，業務損失和投入建設的資源之間比例是否劃算;第二，因為一個機房放不下，花錢買資源的同時實現多活能力。

　　大漠窮秋：并不是所有的事故都需要做容災，技術人員還是要去提前評估好業務和事故之間可能存在的聯系。有些東西掛了就掛了，重啟就能解決，未必一定要用容災的方式去做建設。這背后一個是技術體系與人員操作規范的問題，兩者都是重要的影響因素。另一個問題就是性價比的問題，對很多中小團隊來說，建容災冗余的投入遠大于事故發生時的損失，成本對于中小企業而言就是最敏感的影響因素。

　　在「黑天鵝」事件發生，導致業務癱瘓時，作為企業領導者，如何進行應急處理？

　　劉意：類似刪庫的黑天鵝事件發生時，作為云廠商而言應該在力所能及的范圍內去幫助客戶恢復業務系統和關鍵數據，這是云廠商應盡的義務。從企業領導者的角度看，首先應該在構建系統的時候就充分做好業務的保障，然后充分利用內部的技術資源、外部云廠商的資源能力，去盡可能地挽救業務損失。

　　毛劍：作為企業領導者不要局限在技術側的處理，更要從全局上看問題。其中從事件本身的公關角度來說，可以這樣分：第一，統一口徑回復給來自 C 端客戶的客訴;第二，同步 PR 部門的同事，在媒體層面上去做危機公關;第三，通過 GR 等政府關系部門去向上報備同步。

　　技術側處理時，首先不要慌，把相關人員組織好，統一事故協調和回復的對接人;第二，盡快通知其他部門事故的發生，在日常工作中也要多做事故演練;第三，做好事故的復盤，對事不對人，規范化流程和人的問題。基于這些想法理念可以建設一個平臺，我們目前建的平臺叫事件中心，保留事件發生前做了什么，事中做了什么，事后的復盤等等。

　　結語

　　線上服務的穩定性對企業而言至關重要，穩定性差的服務在帶給用戶不佳體驗的同時，甚至可能給企業造成直接的經濟損失。而影響線上服務穩定性的因素又有很多，無論是業務研發人員還是云平臺的技術人員，都在不斷地持續求索那提升高可用能力的可能，不斷地逼近『4個9』、『5個』的可用性極限。

　　TVP 從成立之初，所追求的用科技影響世界，讓技術普惠大家，也跟這樣追求極致的技術精神所一脈相承、互相輝映。TVP 們走進的是 B 站，走出來的卻是更多高可用技術背后的思考與實踐。