2021年7月13日，bilibili 出現(xiàn)了一次服務不可用的宕機事故。一年以后，bilibili 技術團隊以一篇事故復盤的文章刷爆了技術人的朋友圈，這一次典型的技術事故，卻成了一個非典型的技術故事。
類似的黑天鵝事件時有發(fā)生，有的或出于單體應用的代碼規(guī)范問題，有的或出于瞬時流量的峰值涌入，有的或因為云廠商的服務抖動受到牽連?？梢哉f，后端研發(fā)人員的成長之旅，往往伴隨著對黑天鵝事件的防范、處理、教訓，互聯(lián)網(wǎng)服務這么多年發(fā)展至今，高可用能力到了什么程度，是否能幫助企業(yè)規(guī)避黑天鵝事件的發(fā)生?上云是否是這個時代保證服務穩(wěn)定性的有效途徑?企業(yè)技術管理者又該如何居安思危，調(diào)整技術架構?
9月25日，騰訊云 TVP 走進 B 站，暢聊「高可用 VS 黑天鵝」的那些事兒，相信能給你一些不一樣的啟發(fā)。本文為本次活動精華總結(jié)。
bilibili云原生架構演進
bilibili 技術委員會主席、騰訊云 TVP 毛劍帶來了題為《bilibili 云原生架構演進》的主題分享。
毛劍老師介紹道，bilibili 的云原生演進大體上始于2015年，主要歷程涵蓋了微服務、容器化和中間件三個關鍵環(huán)節(jié)：
微服務：伴隨著業(yè)務的發(fā)展、DAU 的爆發(fā)，2015年開始從單體轉(zhuǎn)向微服務，面對單體架構無法擴展、可靠性低的問題，應對的思路概括為“化繁為簡，分而治之。
容器化：15年最初部署在裸金屬上;16年開始使用 Mesos+Marathon 進行容器編排，17年遷移到 Kubernetes，之后很快在線應用彈性公有云上線。20年離線 Yarn 和 在線 K8S 做了在離線混部(錯峰使用)，基于混部 Agent，協(xié)調(diào)分配資源。22年離線 Flink、Spark Native on K8S，開始逐漸嘗試覆蓋，統(tǒng)一調(diào)度架構，完成統(tǒng)一調(diào)度。
中間件：容器+微服務的組合帶來的應用爆發(fā)式增長給架構帶來了巨大挑戰(zhàn)，為此引入了開源社區(qū)的組件，在性能、穩(wěn)定性能達到要求的情況下，盡可能使用開源方案，少量組件需要二次開發(fā)和迭代。
從架構設計的層面上看，從CDN到接入層再到服務/中間件/存儲、可觀測、效率體系、穩(wěn)定體系，每個環(huán)節(jié)都有穩(wěn)定性、可用性的保障，每一層都有不同技術人員去做維護和迭代。毛劍老師表示，設計很美好，但黑天鵝該來還得來。
毛劍老師表示，從技術人員的視角看，可用性保障的核心就是流量能否得到有效管控。無論是網(wǎng)絡故障、機房故障、組件故障還是服務故障，每一層都應該設計備有相應的容錯機制，以避免事故發(fā)生或在事故發(fā)生時能快速定位、及時修補。
在 bilibili 2021年發(fā)生的7.13事故中，引發(fā)的原因就是接入層SLB不可用了。毛劍老師詳細分享了本次事故所暴露出的基礎技術建設方面的問題，諸如：
用戶鏈路和辦公網(wǎng)鏈路未徹底隔離
多活未按預期立即生效，不支持寫
人力不足，故障止損和排查無法并行
組件故障預案不完善，處理耗時久
復雜事故影響面極大，定位成本高
……
毛劍老師表示，多活是機房級故障時容災止損最快的方案。在這樣的背景下，bilibili 做了多活基架能力建設、多活管控能力提升的針對性改進。在 bilibili 技術委員會成立后，選擇了擁抱云原生，以強調(diào)工程一致性的方式做云原生的落地建設。
另一方面，針對容災、快速切換的高可用能力方面，設計了同城雙活的架構，具體如下圖所示。
隨著業(yè)務的快速演進，bilibili 開始從 Global Zone(單點全局業(yè)務)演進到同城雙活、異地 AZ 的建設，逐漸也過度到異地多活。毛劍老師表示，實現(xiàn)單元化用戶流量的混合云架構是 bilibili 一直在追求做的事情，包括在急需擴容的情況下，可依托于云廠商的云原生技術基礎能力，在云上新建一個 RZone/CZone Shard，遷移部分用戶 bucket 流量，發(fā)揮云的彈性優(yōu)勢，實現(xiàn)共贏。
分享最后，毛劍老師也基于 bilibili 的業(yè)務場景，解釋了 bilibili 為何要在私有云架構之上再上公有云的實際思考。
大變革時代研發(fā)團隊的重塑
有贊技術副總裁、顧問，騰訊云 TVP 沈淦帶來了題為《大變革時代研發(fā)團隊的重塑》的主題分享。
分享伊始，沈淦老師為大家介紹了大變革的時代背景下，舊經(jīng)濟模式與新經(jīng)濟模式的變化。當前的企業(yè)從以前的“活得好”到現(xiàn)在開始思考如何“活下去”，這背后折射的是經(jīng)濟底層范式的重置：從絕對經(jīng)濟優(yōu)先轉(zhuǎn)變?yōu)榭沙掷m(xù)、社會公平、數(shù)據(jù)安全、自主可控的新經(jīng)濟模式。在內(nèi)卷的舊經(jīng)濟時代，技術管理的核心價值，是打造技術團隊超(無限)高的交付效率。
從舊經(jīng)濟到新經(jīng)濟的轉(zhuǎn)變過程中，技術團隊的使命和價值也發(fā)生了相應的變化。從行為到職責，需要改變的地方有很多。如下圖所示，當前大部分的技術團隊仍舊處于圖中的第二階段，效率和成本仍是核心價值，但新經(jīng)濟要求的的速度和適應性的價值已經(jīng)更為突出。
沈淦老師以 SaaS 行業(yè)為例，介紹了價值驅(qū)動業(yè)務模式的三條主線：其一是高技術密度的產(chǎn)品力;其二是商業(yè)化能力;其三是從客戶之聲到 CSGB 的客戶成功。這三條線大多數(shù)業(yè)務團隊都有在做，但大部分彼此之間都比較孤立，沒有形成有機結(jié)合，效果不佳。
另一方面，對于考核體系的理解也有待革新。過去的考核體系主要關注點落在“做了什么”的動作上，聚焦功能、非功能需求的實現(xiàn)。當前階段開始由做了什么到做成了什么轉(zhuǎn)變，關注GMV增長、PV/UV、穩(wěn)定性等等。而對技術人員而言，終極的目標應該是價值的實現(xiàn)——達成了什么?是爆款?是增購?還是客戶的推薦?
沈淦老師將以上所體現(xiàn)的理念總結(jié)為了“找價值、設指標、拆流程、建團隊”的端到端流程四步法。這四個步驟拆開來看，單個環(huán)節(jié)可能每個技術團隊都有涉及到，但只有按照一定的順序、有機結(jié)合地去做，才能產(chǎn)生更大的業(yè)務價值。
“流程四步法中最難的也許是建團隊”，從組織結(jié)構上去撬動杠桿往往是最難的地方，因為這背后涉及到人與人之間的連接。沈淦老師舉例指出，建團隊有三個基本理論需要關注，其一是康威定律，其二是認知負荷，其三是隧道視野。技術團隊的管理者應該從大處著眼，小處著手，由點及面地完成高效能團隊的構建工作。
騰訊自研業(yè)務上云背后的高可用實踐
騰訊云云原生產(chǎn)品中心技術總監(jiān)王濤帶來了題為《騰訊自研業(yè)務上云背后的高可用實踐》的主題分享。
王濤老師首先簡要分享了騰訊自研業(yè)務容器化上云的歷程。技術路線上，從胖容器到富容器再到微容器，演化到 Serverless、FaaS 的形態(tài)，同時持續(xù)著在離線混部、在線混部的實踐，包括 Service Mesh 也都有持續(xù)的應用。
王濤老師介紹到，經(jīng)過3-4年的大規(guī)模自研業(yè)務云原生實踐，騰訊在各個技術方向和業(yè)務場景都沉淀了大量的解決方案。與此同時持續(xù)反哺給公有云產(chǎn)品，提升各種業(yè)務場景下的核心技術競爭力。
在這樣的背景下，騰訊的云原生成熟度模型演進到 V2.0 版本，從平臺和業(yè)務兩個維度，考察云原生的能力。在這樣的模型考量下，騰訊自研業(yè)務上云的規(guī)模及成熟度也保持了一個持續(xù)上揚的趨勢，業(yè)務和平臺的云原生成熟度都得到了持續(xù)提升，價值得以量化。
王濤老師分析到，容器平臺穩(wěn)定性主要涵蓋平臺層穩(wěn)定、集群層穩(wěn)定、節(jié)點層穩(wěn)定、業(yè)務層穩(wěn)定幾個方面。他重點分享了節(jié)點穩(wěn)定性和業(yè)務穩(wěn)定性的case，持續(xù)深耕云原生OS，提供更好的容器隔離性能力和可觀測性，與此同時騰訊也在逐步大規(guī)模使用 Serverless K8s(EKS)的產(chǎn)品能力，徹底解決容器隔離性問題，并實現(xiàn)了統(tǒng)一大資源池的調(diào)度能力。
在業(yè)務容災的成本方面，過去面向集群業(yè)務管理效率低、容災部署成本高，改造的目標是快速實現(xiàn)業(yè)務的多地域多活部署、一鍵發(fā)起應用的全球灰度變更，業(yè)務灰度期間只需偶爾關注應用大盤視圖即可掌控整體灰度情況，極大的提升了應用管理效率，這對大規(guī)模的應用管理極其重要。
王濤老師表示，這背后涉及到的關鍵技術有很多，比如騰訊開源的多集群管理項目Clusternet、多集群的應用聲明、面向應用的多集群協(xié)同彈性伸縮能力和動態(tài)拆分調(diào)度能力等，最終以面向應用的”屏蔽集群、模糊可用區(qū)“等產(chǎn)品能力，幫助業(yè)務快速實現(xiàn)同城多活、兩地三中心等容災部署能力。全球多地域一次性高可用部署以及豐富的多集群業(yè)務灰度變更策略等，幫助業(yè)務提升容災部署/變更的效率以及可用性。
在服務路由的高可用方面，通過騰訊內(nèi)部自研的服務東西向流量管理“北極星Polaris”，提供解決包括遠程過程調(diào)用(RPC)的服務注冊與發(fā)現(xiàn)、動態(tài)路由、負載均衡、服務熔斷等一系列的超大規(guī)模和高性能的服務路由管理能力。輔以Kubernetes Controller的方式對接北極星，進一步提升了Pod狀態(tài)和服務實例可用性的聯(lián)動實時性，加快了實例故障自動剔除等關鍵動作。
在混沌工程方面，騰訊云所有云產(chǎn)品都必須參與日?；煦缪菥殻崆鞍l(fā)現(xiàn)產(chǎn)品隱患，提升云產(chǎn)品的可用性。由此也孵化出了公有云混沌演練平臺，日常通過高可用攻擊演練的方式，鍛煉運營質(zhì)量與架構的高可用改造，在故障真實發(fā)生時從容應對。
云上高可用能力建設
騰訊云高可用專家服務負責人廖行星帶來了題為《云上高可用能力建設》的主題演講。
分享伊始，廖行星老師從黑天鵝和高可用的關系上做了一個論斷——黑天鵝是一個現(xiàn)象，是一個結(jié)果，但高可用/異構系統(tǒng)，以及技術側(cè)的能力，是對應的治理手段和方法，我們是期望通過這樣的方法來降低，或者說控制黑天鵝事件對業(yè)務的影響時長和范圍。
對于高可用能力的度量指標，廖行星老師總結(jié)了以下幾個關鍵：RTO 恢復時間目標;RPO 恢復點目標;WRT 工作恢復時間;MTD 最大可容忍停機時間。高可用能力的價值體現(xiàn)，如下圖所示：
廖行星老師表示，異地多活的能力是服務高可用的關鍵，在技術目標上主要可以分為以下幾個維度。
DNS 調(diào)度。常見影響 DNS 調(diào)度的因素有 locallands 多出口、locallands 不支持 ECS、NS 不支持 ECS、NS 的 IP 庫不準確等，由此帶來的技術目標是需要能夠保證大部分流量調(diào)度的準確性。
路由層流量糾偏。利用openresty流量糾編實現(xiàn)，確保流量精確流入某一region。
邏輯層單元化建設。徹底單元化，確保region間無數(shù)據(jù)流動。
數(shù)據(jù)層數(shù)據(jù)同步。數(shù)據(jù)回環(huán)，一致性，數(shù)據(jù)沖突。
在災難切換方面，重點步驟可以總結(jié)為以下幾點：
1.多活規(guī)則中心下發(fā)禁寫通知和禁寫時間基線
2.數(shù)據(jù)庫SDK收到禁寫數(shù)據(jù)庫寫入和更新
3.雙向復制器收到超過禁寫時間基線不再復制
4.雙向復制器上報復制完成狀態(tài)
5.多活規(guī)則中心下發(fā)流量切換通知
6.Nginx&網(wǎng)關層收到將流量切換到機房B并上報切換完成狀態(tài)
7.多活規(guī)則中心下發(fā)取消禁寫通知
廖行星老師介紹道，騰訊云在高可用能力建設方面做了很多技術上的實現(xiàn)工作，在路由層面上，API網(wǎng)關+SCF可以實現(xiàn)復雜的流量染色場景;在接入層方面，CLB 具備就近接入、VIP 漂移的高可用能力;在邏輯層方面，騰訊云微服務平臺 Tencent Service Framework(TSF)提供微服務全生命周期管理、服務可觀測、配置管理、服務治理及業(yè)務容災架構能力;在數(shù)據(jù)層方面，CDB&DTS 能夠有效實現(xiàn)數(shù)據(jù)的一致性、數(shù)據(jù)回環(huán)等。
觀點眾議
精彩的分享結(jié)束后，TVP 們還在線下展開了一場別開生面的小組討論會，在場嘉賓分為三組針對三個高可用話題展開了討論，并派出了三位小組代表(劉意、毛劍、大漠窮秋)做要點總結(jié)。
對于體量較小的企業(yè)而言，是否有必要提前搭建高可用的容災體系?
劉意：我們這桌正好有創(chuàng)業(yè)者，他們公司跟 bilibili 有點類似，都是重 IT 的客戶。對于類似的小體量企業(yè)，不具備 bilibili 的業(yè)務體量時，是不需要重度發(fā)展高可用容災體系的，更多可以用多云多活的架構來部署自己的業(yè)務系統(tǒng)。這樣做的好處是可以確保自己的業(yè)務在 A 云中發(fā)生故障時可以平滑地遷移到 B 云，平時也可以通過演練確保切換動作的絲滑流暢。還有一個好處就是可以利用兩方云平臺的成本體系去平衡成本，實現(xiàn)降本增效。
毛劍：對于小體量企業(yè)而言，PaaS 平臺的搭建的確很花精力。很多人以為用了云就具備了高可用能力，其實不然，小企業(yè)仍舊需要懂 SRE 去主動培養(yǎng)高可用的意識。服務穩(wěn)定性的影響因素有很多，僅僅是研發(fā)人員寫的一個 bug，同樣會對其造成不可估量的影響。這背后需要一系列的手段去做避免，本質(zhì)上是一個系統(tǒng)工程。小企業(yè)可以不建平臺，可以只用云的能力，但一定要具備 SRE 的意識。
大漠窮秋：我職業(yè)生涯里經(jīng)歷過兩次自己搞出來的故障，影響都比較大，一次是在某電力系統(tǒng)公司搞掛了監(jiān)控系統(tǒng)的庫，另一次是在接手舊系統(tǒng)的維護升級工作時優(yōu)化了代碼格式刪除了多余空行導致系統(tǒng)故障，這兩次都是在相對互聯(lián)網(wǎng)而言較小的企業(yè)里。對于小企業(yè)而言，體量只是其中的一個因素，另外還需要去考量企業(yè)是否會在某個階段突然獲得爆發(fā)式的增長，比如最近很火爆的一些現(xiàn)象級的小游戲，判斷增長的空間才有足夠合理的提前搭建高可用容災體系的必要。
目前眾多的冷備、熱備、雙活、多活、同城、異地、多云等災備方案中，如何更好的選擇貼合自身要求的高可用和容災架構方案?
劉意：多云多活的方案中，bilibili 和喜馬拉雅都選擇了混合云的模式。大部分企業(yè)并不常遇到數(shù)據(jù)庫爆炸一樣的極端情況，也不像銀行業(yè)一定要異地多活高規(guī)格的容災體系，一般而言雙活就能起到高可用的作用足夠滿足需求了。相比其他而言，提高 IT 團隊的管控能力可能更為重要。此外，要讓業(yè)務在自建 IDC 和上云之間做好選擇，哪些核心系統(tǒng)上云，哪些不用，充分利用自建 IDC 數(shù)據(jù)的可靠性，確保業(yè)務跑得更快、更好。
毛劍：很多人對系統(tǒng)的多活容災有誤解，多活在技術上對時間、精力的消耗很大，但幾乎沒有產(chǎn)生附加價值，所以技術團隊在做多活方案之前一定要考慮到業(yè)務的 ROI。類似交易型電商、金融行業(yè)，對異地多活的需求會比較高，但大部分業(yè)務做到同城雙活就足夠了。建設多活的核心其實就是兩點，第一是思考出現(xiàn)停機問題時，業(yè)務損失和投入建設的資源之間比例是否劃算;第二，因為一個機房放不下，花錢買資源的同時實現(xiàn)多活能力。
大漠窮秋：并不是所有的事故都需要做容災，技術人員還是要去提前評估好業(yè)務和事故之間可能存在的聯(lián)系。有些東西掛了就掛了，重啟就能解決，未必一定要用容災的方式去做建設。這背后一個是技術體系與人員操作規(guī)范的問題，兩者都是重要的影響因素。另一個問題就是性價比的問題，對很多中小團隊來說，建容災冗余的投入遠大于事故發(fā)生時的損失，成本對于中小企業(yè)而言就是最敏感的影響因素。
在「黑天鵝」事件發(fā)生，導致業(yè)務癱瘓時，作為企業(yè)領導者，如何進行應急處理?
劉意：類似刪庫的黑天鵝事件發(fā)生時，作為云廠商而言應該在力所能及的范圍內(nèi)去幫助客戶恢復業(yè)務系統(tǒng)和關鍵數(shù)據(jù)，這是云廠商應盡的義務。從企業(yè)領導者的角度看，首先應該在構建系統(tǒng)的時候就充分做好業(yè)務的保障，然后充分利用內(nèi)部的技術資源、外部云廠商的資源能力，去盡可能地挽救業(yè)務損失。
毛劍：作為企業(yè)領導者不要局限在技術側(cè)的處理，更要從全局上看問題。其中從事件本身的公關角度來說，可以這樣分：第一，統(tǒng)一口徑回復給來自 C 端客戶的客訴;第二，同步 PR 部門的同事，在媒體層面上去做危機公關;第三，通過 GR 等政府關系部門去向上報備同步。
技術側(cè)處理時，首先不要慌，把相關人員組織好，統(tǒng)一事故協(xié)調(diào)和回復的對接人;第二，盡快通知其他部門事故的發(fā)生，在日常工作中也要多做事故演練;第三，做好事故的復盤，對事不對人，規(guī)范化流程和人的問題。基于這些想法理念可以建設一個平臺，我們目前建的平臺叫事件中心，保留事件發(fā)生前做了什么，事中做了什么，事后的復盤等等。
結(jié)語
線上服務的穩(wěn)定性對企業(yè)而言至關重要，穩(wěn)定性差的服務在帶給用戶不佳體驗的同時，甚至可能給企業(yè)造成直接的經(jīng)濟損失。而影響線上服務穩(wěn)定性的因素又有很多，無論是業(yè)務研發(fā)人員還是云平臺的技術人員，都在不斷地持續(xù)求索那提升高可用能力的可能，不斷地逼近『4個9』、『5個』的可用性極限。
TVP 從成立之初，所追求的用科技影響世界，讓技術普惠大家，也跟這樣追求極致的技術精神所一脈相承、互相輝映。TVP 們走進的是 B 站，走出來的卻是更多高可用技術背后的思考與實踐。
（免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。
任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權或存在不實內(nèi)容時，應及時向本網(wǎng)站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內(nèi)容或斷開相關鏈接。 ）
