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间无数据流动。
- 数据层数据同步。数据回环，一致性，数据冲突。
在灾难切换方面，重点步骤可以总结为以下几点：
- 多活规则中心下发禁写通知和禁写时间基线
- 数据库SDK收到禁写数据库写入和更新
- 双向复制器收到超过禁写时间基线不再复制
- 双向复制器上报复制完成状态
- 多活规则中心下发流量切换通知
- Nginx&网关层收到将流量切换到机房B并上报切换完成状态
- 多活规则中心下发取消禁写通知
廖行星老师介绍道，腾讯云在高可用能力建设方面做了很多技术上的实现工作，在路由层面上，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 站，走出来的却是更多高可用技术背后的思考与实践。
