官方黑天鹅是谁(黑天鹅这个词有版权吗)

2021年7月13日，bilibili发生服务中断，导致服务不可用。一年后，bilibili技术团队用一篇回顾事故的文章淹没了技术人圈。这起典型的技术事故，结果却是一个非典型的技术故事。

类似的黑天鹅事件时有发生，有些是由于单个应用的代码规范问题，有些是由于瞬时流量涌入峰值，还有一些是与云厂商的服务抖动有关。可以说，后端研发人员的成长历程往往伴随着黑天鹅事件的预防、处理和教训。互联网服务已经发展了多年。高可用能力实现到什么程度了？能否帮助企业避免黑天鹅事件的发生？上云是这个时代保证服务稳定的有效途径吗？企业技术管理者该如何居安思危、调整技术架构？

9月25日，腾讯云TVP走进B站，畅谈“高可用VS黑天鹅”。相信能给你一些不一样的启发。本文是对本次活动亮点的总结。

bilibili云原生架构演进

bilibili技术委员会主席、腾讯云TVP毛健带来了题为“bilibili云原生架构演进”的主题分享。

毛健老师介绍，bilibili的云原生演进大致开始于2015年，主要流程涵盖微服务、容器化和中间件三个关键环节：

微服务：随着业务的发展和DAU的爆发，我们在2015年开始从单体转向微服务。面对单体架构不可扩展、可靠性低的问题，应对思路可以概括为化繁为简、分而治之。

容器化：2015年首次部署在裸机上；2016年开始使用Mesos+Marathon进行容器编排；2017年迁移到Kubernetes；此后不久，针对在线应用程序的弹性公共云推出了。过去20年，线下Yarn和线上K8S线下共置（错峰使用），基于共置Agent来协调和分配资源。22年，离线的Flink和K8S上的SparkNative开始逐步尝试覆盖，统一调度架构，完成统一调度。

中间件：容器+微服务的结合带来的应用爆发式增长，给架构带来了巨大的挑战。为此，引入了来自开源社区的组件。在满足性能和稳定性要求的情况下，应尽可能使用开源解决方案。少量组件需要二次开发迭代。

从架构设计的角度来说，从CDN到接入层到服务/中间件/存储、可观测性、效率系统、稳定系统，每个环节都有稳定性和可用性保障，并且每一层都有不同的技术人员在做维护和维护迭代。毛健老师说，设计很美，但是黑天鹅一定要来。

毛健老师表示，从技术人员的角度来看，可用性保障的核心是能否有效控制流量。无论是网络故障、机房故障、部件故障还是业务故障，每一层都应该设计相应的容错机制，以避免事故的发生或者在事故发生时能够快速定位和修复。

2021年bilibili发生的7.13事件，起因是接入层SLB不可用。毛健老师详细分享了本次事故暴露出来的基础技术建设问题，比如：

用户链路和办公网络链路不完全隔离

多活并没有如预期立即生效，不支持写入

人力不足，无法并行止损和排查

部件故障计划不完整，处理时间长

事故复杂影响巨大，选址成本高

……

毛健老师表示，多活是机房级故障发生时最快的容灾止损方案。在此背景下，bilibili进行了针对性的改进，构建多活动基础设施能力，提升多活动管控能力。bilibili技术委员会成立后，选择拥抱云原生，以强调工程一致性的方式进行云原生实施。

另一方面，针对容灾、快速切换等高可用能力，设计了本地双活架构，如下图所示。

随着业务的快速演进，bilibili开始从GlobalZone（单点全球业务）演进到同城、异地AZ双主的建设，并逐渐过渡到异地多主。毛健老师表示，实现用户流量统一化的混合云架构是bilibili一直追求的目标，包括在急需扩容的情况下，依托云厂商云原生技术的基础能力，打造新的RZone/CZoneShard迁移部分用户桶流量，利用云的弹性，实现双赢。

分享最后，毛健老师还结合bilibili的业务场景，阐述了bilibili为什么需要在私有云架构上进行构建，然后迁移到公有云的实践思考。

巨变时代重塑研发团队

腾讯云TVP有赞科技副总裁兼顾问沉干带来题为《大变革时代重塑研发团队》的主题分享。

分享一开始，沉甘老师向大家介绍了大变革背景下旧经济模式和新经济模式的变化。现在的企业已经从过去活得好好的，到现在开始思考如何生存。这体现的是底层经济范式的重置：从经济优先转向可持续、社会公平、数据安全、自主可控的新经济模式。在内卷化的旧经济时代，技术管理的核心价值是创造技术团队的超（无限）高交付效率。

在旧经济向新经济转型的过程中，技术团队的使命和价值也发生了相应的变化。从行为到责任，有很多需要改变的地方。如下图所示，目前大多数技术团队还处于图中的第二阶段。效率和成本仍然是核心价值，但新经济所要求的速度和适应性的价值变得更加突出。

沉甘老师以SaaS行业为例，介绍了价值驱动商业模式的三大主线：一是高科技密集的产品力；二是商业化能力；三是从客户的声音到CSGB客户的成功。大多数业务团队都在这三条线上工作，但大多彼此相对孤立，没有有机融合，效果并不好。

另一方面，对考核体系的认识也需要改革。过去，评估体系主要关注执行了哪些操作，重点关注功能性和非功能性需求的实现。现阶段开始从已做的到已实现的转变，关注GMV增长、PV/UV、稳定性等。对于技术人员来说，目标应该是价值的实现。——取得了什么成就？很受欢迎吗？是额外购买的吗？还是客户推荐？

申干老师将上面体现的理念概括为发现价值、设定指标、拆解流程、打造团队的四步端到端流程。分别看这四个步骤，每个技术团队可能只涉及单个环节，但只有按照一定的顺序、有机地结合起来，才能产生更大的商业价值。

也许四步过程中最困难的部分是建立团队。利用组织结构通常是最困难的部分，因为它涉及人与人之间的联系。申干老师举例指出，团队建设需要注意三个基本理论。第一个是康威定律，第二个是认知负荷，第三个是隧道视野。技术团队管理者要大处着眼，从小处着手，点点滴滴完成高绩效团队建设工作。

腾讯自研业务上云背后的高可用实践

腾讯云原生产品中心技术总监王涛分享了题为《腾讯自研业务上云背后的高可用实践》的主题。

王涛老师首先简单分享了腾讯自研业务容器化到云端的过程。在技术路线上，从胖容器到富容器再到微容器，已经演变成Serverless和FaaS的形式。同时不断实践线下和线上共置，包括ServiceMesh，也有持续的应用。

王涛老师介绍，经过3-4年的大规模自研业务云原生实践，腾讯在各个技术方向和业务场景积累了大量的解决方案。同时，我们持续反馈公有云产品，提升各业务场景下的核心技术竞争力。

在此背景下，腾讯云原生成熟度模型进化至V2.0版本，从平台和业务两个维度审视云原生能力。在这样的模式考量下，腾讯云自研业务的规模和成熟度也保持了持续上升的趋势。业务和平台的云原生成熟度不断提升，价值得到量化。

王涛老师分析，容器平台的稳定性主要涵盖平台层的稳定性、集群层的稳定性、节点层的稳定性、业务层的稳定性。他重点分享节点稳定性和业务稳定性的案例，并持续开发云原生操作系统，提供更好的容器隔离能力和可观察性。与此同时，腾讯也在逐步大规模使用ServerlessK8s（EKS）产品。能力，彻底解决容器隔离问题，实现统一大资源池的调度能力。

在业务容灾成本方面，过去面向集群的业务管理效率低，容灾部署成本高。转型的目标是快速实现服务的多区域、多活跃部署，一键发起应用的全局灰度变更。灰度期间，您只需偶尔关注应用仪表板视图即可掌控整体灰度情况，极大提高了应用管理的效率，这对于大规模应用管理极为重要。

王涛老师表示，这背后涉及到很多关键技术，比如腾讯开源多集群管理项目Clusternet、多集群应用声明、面向应用的多集群协同弹性伸缩能力和动态拆分调度能力等。最终凭借面向应用的屏蔽集群、模糊可用区等产品能力，帮助企业快速实现同城多活、两地三中心等容灾部署能力。全球多区域一次性高可用部署和丰富的多集群业务灰度变更策略，帮助企业提升容灾部署/变更的效率和可用性。

在服务路由高可用方面，腾讯自研的服务东西流量管理Polaris为远程过程调用（RPC）服务注册与发现、动态路由、负载均衡、服务等一系列超大规模问题提供了解决方案。断路器等规模化、高性能的服务路由管理能力。辅以KubernetesController方式连接Polaris，进一步提高Pod状态与服务实例可用性的实时联动，加快自动排除实例故障等关键动作。

在混沌工程方面，腾讯云所有云产品都必须参与日常混沌演练，提前发现产品隐患，提高云产品的可用性。这也孵化了公有云混沌演练平台，每天通过高可用攻击演练，实践运营质量和架构的高可用改造，并在实际发生故障时从容应对。

云高可用能力建设

腾讯云高可用专家服务负责人廖星星做了题为《构建云上高可用能力》的主题演讲。

分享一开始，廖星星老师就从黑天鹅和高可用的关系做了一个总结：——只黑天鹅是一种现象和结果，但高可用/异构系统和技术能力才是对应的治理方式和方法，我们希望通过这种方式来减少，或者说控制黑天鹅事件对业务影响的持续时间和范围。

关于高可用能力的衡量指标，廖星星老师总结了以下几个要点：RTO恢复时间目标；RPO恢复点目标；WRT工作恢复时间；MTD可容忍的停机时间。高可用能力的价值如下图体现：

廖星星老师表示，能够多次异地工作，是服务高可用性的关键。技术目标主要可以分为以下几个维度。

DNS调度。影响DNS调度的常见因素包括本地有多个出口、本地不支持ECS、NS不支持ECS、NS的IP库不准确等。由此产生的技术目标是保证大多数流量调度的准确性。

路由层流量校正。使用openresty流量矫正，保证流量流入某个区域。

逻辑层单元构建。完全单元化，确保区域间数据无流动。

数据层数据同步。数据环回、一致性、数据冲突。

在灾难切换方面，关键步骤可以概括为：

1、多活规则中心下发禁止写通知和禁止写时间基线

2、数据库SDK收到禁止写入和更新数据库的信息。

3.双向复制器收到超过写禁止时间基线的消息后将不再进行复制。

4、双向复制器上报复制完成状态

5、多主规则中心下发流量切换通知

6、Nginx网关层收到请求，将流量切换到B机房，并上报切换完成状态。

7、多活动规则中心发出取消禁写通知。

廖星星老师介绍，腾讯云在构建高可用能力方面做了大量的技术实现工作。在路由层面，APIGateway+SCF可以实现复杂的流量染色场景；在接入层，CLB具有就近接入、VIP漂移的高可用能力；在逻辑层方面，腾讯云微服务平台腾讯服务框架（TSF）提供微服务全生命周期管理、服务可观测、配置管理、服务治理和业务容灾架构。能力；在数据层方面，CDBDTS可以有效实现数据一致性、数据环回等。

意见共识

精彩分享结束后，TVP们还在线下进行了别具一格的分组讨论。到场嘉宾分成三组讨论三个高可用话题，派出了三名小组代表（刘毅、毛健）。沙漠琼秋）对要点进行总结。

对于规模较小的企业来说，是否有必要提前搭建高可用的容灾系统？

刘毅：我们桌边正好有企业家。他们的公司和bilibili有些相似，都是以IT为主的客户。对于类似的小型企业，不具备bilibili的业务量，不需要开发高可用的容灾系统。相反，他们可以使用多云、多活架构来部署自己的业务系统。这样做的好处是，可以保证当A云出现故障时，你的业务能够顺利迁移到B云，并且还可以进行演练，保证切换动作的顺利进行。另一个好处是可以利用两个云平台的成本体系来平衡成本，实现降本增效。

毛健：对于小型企业来说，搭建PaaS平台确实需要花很多功夫。很多人认为使用云就意味着拥有高可用性能力。事实上，情况并非如此。小企业还是需要了解SRE，主动培养高可用意识。影响服务稳定性的因素有很多。只是开发者写的一个bug也会对其产生不可估量的影响。这就需要一系列的手段来避免，这本质上是一个系统工程。小企业不需要搭建平台，只需要使用云能力，但一定要有SRE意识。

达摩琼秋：我在职业生涯中经历过两次因自己原因造成的失误，影响都比较大。一次是某电力系统公司监控系统库出现故障，另一次是我接手老系统的维护和升级。优化代码格式，删除导致系统故障的多余空行。两次都是在与互联网相比相对较小的公司中进行。对于小公司来说，规模只是因素之一。另外，还要考虑公司是否会在某个阶段突然实现爆发式增长，比如最近很火的一些现象级小游戏。判断增长空间，合理需要提前搭建高可用的容灾系统。

在目前冷备、热备、双活、多主、同城、异地、多云等众多容灾方案中，如何更好地选择高可用、容灾的架构方案符合你自己的要求吗？

刘毅：在多云多活的解决方案上，bilibili和喜马拉雅都选择了混合云模式。大多数企业不会经常遇到数据库爆炸等极端情况，而且与银行业需要异地多活、高标准的容灾系统不同，一般来说双活可以起到高可用的作用，足以满足需求。提高IT团队的管理和控制能力可能比其他任何事情都更重要。此外，企业需要在自建IDC和上云之间做出选择。哪些核心系统应该上云，哪些不应该使用？充分利用自建IDC内数据的可靠性，保证业务运行得更快更好。

毛健：很多人对系统的多活容灾存在误解。多项活动在技术上消耗了大量的时间和精力，但几乎没有产生任何附加价值。因此，技术团队在制定多活动解决方案之前必须考虑业务。投资回报率。与交易型电商、金融行业类似，异地多活动的需求会比较高，但对于大多数商家来说，同城双活动就足够了。构建多活动的核心其实有两点。首先是考虑当出现停机问题时，业务损失与建设资源投入的比例是否划算；第二，因为一个机房装不下，所以需要花钱购买资源，同时实现多活动。能力。

达摩琼秋：并不是所有的事故都需要灾难恢复。技术人员仍需提前评估业务与事故之间可能存在的联系。有些事情就是挂了，重启就可以解决。它不一定必须以灾难恢复方式构建。这背后是技术体系和人员操作标准的问题，两者都是重要的影响因素。另一个问题是成本效益。对于很多中小型团队来说，构建容灾冗余的投入远远大于发生事故时的损失。成本是中小企业最敏感的因素。

当“黑天鹅”事件发生、业务瘫痪时，企业如何处理紧急情况？

刘毅：当数据库被删除这样的黑天鹅事件发生时，云厂商应该尽力帮助客户恢复业务系统和关键数据。这是云厂商的义务。从企业角度来看，首先在建设系统时要充分保障业务，然后充分利用内部技术资源和外部云厂商的资源能力，尽可能节省业务损失。

毛健：作为企业，我们不能仅仅局限于技术层面，而应该从全局的角度来看待问题。从事件本身的公关角度来看，可以分为：一是统一回应C端客户的投诉；二是同步公关部门的同事做媒体层面的危机公关；三是通过GR等政府关系部门同时向上级汇报。

在处理技术方面时，首先不要惊慌，组织相关人员，统一事故协调和响应的联络点；二是尽快将事故情况通知其他部门，并在日常工作中多做事故演练；三、做好事故审查要重事轻人，规范流程和人的问题。基于这些想法，可以构建一个平台。我们目前正在搭建的平台叫做活动中心，它保留了活动之前做了什么、活动期间做了什么、活动之后的回顾等等。

结论

在线服务的稳定性对企业至关重要。稳定性差的服务不仅会带来较差的用户体验，甚至可能给企业造成直接的经济损失。影响在线服务稳定性的因素有很多。无论是业务研发人员还是云平台技术人员都在不断探索提高高可用能力的可能性，不断向“四个九”和“五个”靠拢。个人的可用性限制。

TVP从成立之初就追求用科技影响世界，让科技造福每个人。这种对技术的追求是相互契合、相互体现的。TVP走进的是B站，但走出来的却是更多高可用技术背后的思考和实践。