2个月演练200+次：B站如何实现演练平台的快速接入与易用性提升？

见贤思齐

# 一分钟精华速览 #为应对业务增长引发的频繁故障，B站进行了一系列的技术改造，然而如何验证这些改造能力、且能让常态化改造有效，以及怎么让研发人员能自助验证成为问题。基于此，B站通过接入不同演练工具、统一演练流程、降低演练门槛、标准化常态演练等核心技术能力建设，打造了一个高效、易用、安全的混沌平台。平台上线两个月，已完善20+场景，执行200+演练，覆盖30+应用，发现50+问题。详细的解决策略和方法，请参阅文章正文。作者介绍?哔哩哔哩资深开发工程师——谷林涛?TakinTalks稳定性社区专家团成员，哔哩哔哩资深开发工程师。2021年9月加入bilibili公司，就任于基础架构部—SRE平台工程组。在职业生涯中，专注于稳定性平台的体系化、产品化工作，并结合业务以及环境现状，实现技术落地和业务产出。曾负责应急故障平台、变更管控、工单平台研发工作。现在目前的主要工作是负责从0-1建设混沌平台，专注公司混沌技术平台落地，提升公司业务稳定性。温馨提醒：本文约8000字，预计花费13分钟阅读。后台回复?“交流”?进入读者交流群；回复“Q117”获取课件；背景由于业务的快速增长，B站也遇到了频繁的故障，为了应对这些挑战，我们提出了建立多可用区的方案，在两个不同的可用区之间进行业务流量的切换，这样即使一个区域出现故障，另一个区域仍然可以保持业务的运行，从而大大降低了单点故障的风险。然而，在实施过程中我们遇到了一些意料之外的问题。比如，当一个机房出现异常时，另一个机房有时并不能独立工作。这暴露了我们设计中的一些弱点，包括对中间件如Redis的依赖问题，以及核心应用与非核心应用之间的强弱依赖问题。我们积极进行了一系列的技术改造，包括增强了多活能力，实现了在多可用区的双读或双写，同时对强弱依赖进行了梳理和改造，去除了一些不合理的依赖等等。但是，随着产品的迭代和技术的发展，如何保证这些改造能够长期有效呢？同时，如何驱动研发团队能够在开发周期中自主地发现和解决问题？所以基于这个背景，我们就提出了B站需要建立一个统一的混沌平台，通过这个混沌平台模拟各种故障情况，提前发现并解决潜在的问题，从而确保我们的多活架构能够适应长期的业务和技术发展，保持其长期有效性。一、B站的演练流程是怎么设计的？1.1 ?标准化演练流程通过与业务团队、基架团队的紧密沟通，以及在开源社区和技术上进行的深入交流，我们结合了公司的具体情况，抽象出了一套标准的演练流程。这个流程大致可以分为三个阶段：演练前、演练中和演练后。1、业务梳理首先是业务的梳理和方案的确认。我们需要明确，对于B站来说，哪些业务需要进行演练，这些业务的验证方案是什么，以及这些演练可能带来的影响面有多大。2、方案确认在方案确认阶段，我们要决定在演练前是否需要进行流量切换，是否需要制定预案。预案分为两类：一类是可预期的预案，比如我们已经知道演练中Redis可能会受到影响，那么我们需要制定什么样的预案来降级处理，验证这个预案的可行性。另一类是不可预期的预案，即在演练过程中出现了不符合预期的结果，或者影响范围扩大了，我们如何终止演练，以及在演练后可能出现的数据异常、数据丢失、数据不一致等问题，我们如何去解决。此外，我们还需要确认兜底方案，即在最糟糕的情况下，我们是选择限流，还是采取其他更综合的措施。3、制定演练范围这个阶段我们需要确定演练的范围。这包括我们选择在什么环境下进行演练，我们是基于某个应用进行演练，还是针对某台机器，或者是某台物理机进行演练。明确了演练范围后，我们就可以预估受影响的范围，从而实现对演练影响面的可控。4、配置演练流程配置演练流程至关重要，因为它确保了我们在面对各种潜在故障时的应对能力。演练流程主要包含三个关键点：? a.演练场景的设定。我们需要明确哪些场景需要进行演练。例如，我们可能认为系统B依赖于系统A，但A并不是一个核心业务场景。在A不可用的情况下，B是否能够按照预期继续运行并进行降级处理，这就是我们需要定义和验证的一个演练场景。在一次演练中，我们可以同时验证多个场景，以确保整个演练的完整性。? b.指标的可观测性。在演练过程中，我们需要确保变更是可观测、可归因、可回滚的。我们需要观测演练是否成功执行，业务指标是否符合预期，或者是否完全不受影响。这要求我们在演练前进行充分的业务梳理，明确预期的影响。? c.防护范围的确定。我们需要确保有兜底措施，比如核心业务告警，当出现严重告警时，我们需要立即终止演练。5、关联验证场景我们还需要关联验证场景，这包括预期场景中业务是否会受损，以及设置断言配置来验证业务接口、响应和返回是否符合预期。6、执行演练我们不仅要执行演练操作，还要进行巡检，检查业务指标是否异常，确保演练工具的稳定性，并持续注入故障。同时，我们会记录演练的验证和待办事项，包括业务反馈、监控表现等，以便实时记录并快速记录不符合预期的问题。7、恢复演练演练结束后，我们需要进行恢复演练，验证是否能够正常恢复，并执行必要的预案和回滚操作，恢复到演练前的状态。8、常态化演练如果一次完整的演练符合业务预期，并且系统设计符合预期，我们就可以将其纳入常态化演练，定期自动触发，以验证整个模块是否能够持续符合预期。另外一件事是突袭演练，它的特点是在非预期的时间、地点，甚至是非预期的范围内发起攻击。这样做的目的是为了验证我们的演练场景是否能够承受我们之前设计的各种情况。9、待办跟进对于演练中发现的不符合预期的问题，以及需要进行二次验证的问题，我们会列入待办事项中进行跟踪。这样做可以确保我们在演练过程中一旦发现问题，就能够迅速地解决。我们制定的这一整套标准化演练流程，主要是为了帮助SRE、研发、测试以及稳定性负责人这四个关键角色，通过我们的平台推进和执行整个演练工程。1.2 ?业务演练推进过程由于业务的标准演练是在线上进行的，而我们不可能直接在生产环境中开展。因此，我们提出了一个整体的演练流程。构建一个演练场景，在非生产环境中先行演练，通过非生产环境的演练后才能进入生产环境的演练。当生产环境的演练完成并且没有发现预期之外的问题时，我们才会推进实施常态化演练。二、混沌平台的架构是怎么设计的？2.1 设计目标对于单次演练的生命周期和整个流程的标准SOP，我们已经提出了整个混沌平台的架构设计，其设计目标主要分为4个方面：2.2 ?整体架构B站整个混沌能力可以大概分三期——第一期，我们构建了基础的混沌工程能力。第二期，我们通过特化场景配置，提供了高级的混沌工程能力。第三期，我们提供了一站式能力，覆盖从演练前的风险梳理，到演练中的风险验证，再到演练后的风险复盘的整个流程。这在我们的架构中得到了完整体现。2.2 ?图1 - 混沌平台整体架构原子故障库：我们提供一个原子故障库，包含CPU异常、内存异常、网络异常等各类异常。这些异常有多种工具可以实现，底层也需要较多工具支持，后面我将分享如何做对应的接入。演练场景：为了让用户使用更流畅，我们在原子故障库之上提供了演练场景，分为通用场景和特化场景。通用场景如CPU高负载、容器异常、网络丢包等，直接对应原子库中的具体行为。然而，我们发现用户在使用这些原生场景时存在难度，因为参数复杂，且缺乏业务属性，导致研发难以理解和使用。因此，我们提供了特化场景，针对特定的业务背景和遇到的问题，如跨可用区调用不符合预期，中间件或依赖问题等，通过特化场景的方式，提供更贴近业务的演练场景。混沌实验：在演练场景的基础上，我们构建了混沌实验，包括混沌演练的创建、分发、注入中断、查看、回复、日志、编排等等，这些操作是标准化的，它们贯穿了整个演练过程。实验观测：再往上就分为两块——实验观测和经验沉淀。我们提供了一系列能力，帮助用户进行实验观测，这包括对基础过程的监控、注入效果、恢复效果，以及资源指标、业务稳定性和异常。我们的目标是实现全面可观测性，其中包括两个关键点：业务本身是否符合预期。演练本身是否符合预期。经验沉淀：对于研发人员来说，他们可能并不清楚在实际工作中可能会遇到哪些类型的故障，比如中间件的不可用、依赖服务的故障、断网容灾等情况。我们的平台通过历史故障和问题中，总结了大量经验，并将其沉淀为标准化流程，以便用户能够快速验证自己的业务在混沌场景下的表现是否符合预期。演练管理：在业务层面，我们还提供了演练管理功能，包括演练计划、任务、编排，以及实验关联和执行。演练报告：演练结束后，我们会生成一份详尽的演练报告，其中不仅包含性能数据，还有代办事项、业务监控数据和告警信息等，这些都将在报告中得到体现。2.2 图2 - 一个页面完成演练的全诉求三、混沌平台具备哪些核心技术能力？3.1 ?核心能力目标我们的目标是为用户提供一个集高效性、易用性和安全性于一体的演练平台。这个平台不仅仅是一个工具，更是一个推动业务发展和创新的强大引擎。我们致力于实现以下几个关键能力目标：3.2 ?如何实现不同演练工具的接入？接下来探讨我们是如何实现不同演练工具的接入，并制定一个标准化的混沌协议。问题：不同演练工具之间的差异性给研发团队带来了挑战，通过深入调研开源社区，我们抽象出不同演练工具的共同需求，并基于此制定了一个标准化的混沌协议。该协议旨在快速且专业地接入各种演练工具，简化了公司内部测试团队在执行故障注入测试时的接入流程。尽管标准化协议的制定是一个进步，但在实施过程中我们遇到了一些问题，比如，攻击参数的复杂性对研发团队来说理解成本高，他们可能需要查阅大量文档或咨询其他团队才能获取正确的参数。另外还有演练工具黑屏操作，这对研发来说也是不可控的。方案：为了应对这些挑战，我们平台需要适配一套技术化的标准协议。这套协议主要用于平台的对接，以兼容并支持大量的混沌工具。在向用户透传时，我们需要自定义演练场景，即特化场景。这样，用户就可以快速地使用平台实现自己的演练协议。3.2 图1- 标准的混沌协议3.3 ?如何降低演练门槛？我将向各位介绍我们是如何实现混沌平台接口标准协议和混沌平台事件标准协议的隔离，并通过场景转化器解决我们面临的问题。对于用户而言，他们只需确定选择哪个混沌验证场景，并定义攻击范围。例如，用户可以针对Kubernetes的特定几台机器或者某几个染色环境，或者基于整个应用ID进行攻击。在确定了攻击范围和攻击内容之后，比如阻断跨可用区的链路，或者阻断数据库的访问，甚至模拟数据库的延迟，如MySQL在平台上的性能表现，用户就可以通过混沌平台的事件标准协议接入。这里，我们引入了一个称为“转化器”的概念，它是我们设计中的一个关键点。转化器充当了用户态协议和混沌平台技术协议之间的桥梁，负责将用户想要构造的混沌配置转化为平台能够理解和执行的格式。转化器的核心工作主要分为两个部分：通过调研开源社区和对开源工具的完整测试，将用户的需求转化为对应的参数。在转化过程中，帮助用户对接内部数据源信息，以解决参数配置问题。通过这样的场景转化，我们能够接入混沌平台的接口标准协议，选择具体的工具实现混沌场景的注入。这是我们在整个平台设计中的重中之重，它能极大地降低用户的使用门槛和成本。3.4 如何实现标准化的监控和护栏？这一部分相对来说比较简单，主要涉及到指标的接入。在整体设计时，我们考虑到不同业务或不同告警系统可能需要不同的接入方式。例如，在公司内部，我们有SLO的指标、平台告警，还有一些日志平台告警。针对这些不同的告警系统和指标平台，我们需要实现快速接入，以便进行可视化管理。3.4 图 - 标准的演练监控和护栏在BCM的设计中，我们提供了一个标准的引擎监控和后台设计。这里的核心是一个标准的监控模型，即对于任何一个监控对象，我们都有对应的指标和告警项。这些告警项会生成告警事件，通过标准化的接入接口，我们可以迅速接入公司的日志平台和相应的告警平台。通过这样一套措施，我们能够快速接入内外部的监控平台，并在整个演练过程中实现核心指标的可视化展示。四、有哪些业务最佳实践？我会在这部分回顾之前讨论的问题，包括如何降本增效，如何快速帮助用户解决问题，以及如何设计专业的演练场景。4.1 ?混沌底层能力--基于ChaosBlade实践背景：当时我们想要演练一个网络故障导致跨区域不可用的场景。在对开源社区进行调研后，我们选择基于ChaosBlade实践。然而，在实际操作过程中，我们发现了两大业务痛点。观测性问题——ChaosBlade和 ChaosBlade-operator 及其他几个 Module 的日志没有统一接入，在业务排查问题的时候，由于缺乏日志导致无法解决。注入逻辑问题——比如在实战过程中，DNS干扰的演练无法正常恢复；网络不可用命令超长不符合预期；CPU Load 注入不符合预期等。解决方案：针对这些场景，我们决定基于公司的具体情况和ChaosBlade生态系统，进行自主研发。4.1 图 - 自建BCM-Engine，由BCM-Agent和BCM-Blade组成我们简化了一些不需要的功能，并提供了一个进程管理的能力，以解决观测性和注入问题。通过BCM服务的重构，实现了标准化的演练流程，解决我们此前遇到的问题，并能够设计更多的场景来满足业务需求。4.2 ?混沌底层能力——基于ChaosBlade部署背景：我们有4个环境。首先是本地验证，主要用于开发过程中的验证。然后是FAT环境验证，用于验证CI/CD完成的核心场景用例和自动化验证能力。这两个环境都不会影响用户使用。4.2 图 - B站的4个部署环境UAT环境虽然作为开发环境使用，但在公司内部进行验证时，我们发现UAT环境的演练频次远高于线上发布环境。因为在UAT环境中，业务团队会进行更多的日常业务演练。如果在UAT环境中发布演练，一旦引发bug，将严重影响用户体验。在历史的踩坑过程中，我们几次遇到了演练失效的情况，但用户并不知情，这可能导致用户误以为演练符合预期，而实际上并不符合。解决方案：为了杜绝部署策略导致的问题，我们采取了与线上部署策略一致的方法来部署UAT环境。尽管UAT环境用于开发测试，但它实际上也是一个线上环境，其优势在于，即使混沌演练中的部署注入失败，也不会对线上用户产生影响。我们最担心的是恢复失败，而不是部署失败，这是UAT环境的最大好处。我们的部署策略是基于Kubernetes资源池的灰度部署，通过资源池的灰度隔离来保障用户使用不受影响。在部署前，我们加入了变更管控，将混沌演练视为一种变更行为，来保障用户按规定执行变更（即执行故障注入）。对于线上演练，我们与SRE团队以及稳定性团队进行了大量沟通，最终确定只在特定可用区的特定资源上持续部署，以避免不可预期的影响。其止损方式的特点是，一旦发生问题，我们会终止全量的演练并执行回滚。以此来保障整个落地过程中平台的稳定性。4.3 ?最佳实践之——跨可用区断网验证背景：公司内部多活改造业务持续推进，但缺乏验证手段，需要BCM承载验证能力。解决方案：在业务推进时，我们向用户提供了三个参数：IP隔离白名单、中间件白名单、可用区白名单。这些能力允许用户在演练过程中排除已知的异常问题，避免这些问题发生。在场景转化方面，我们对接了公司的Redis资源信息、Akso资源信息以及网络资源信息，进行了相应的转化，以获取对应的IP和端口。我们还打通了容器信息和演练目标信息，包括确定攻击哪台机器、哪个染色或者哪台具体的容器，并根据用户选择执行相应的注入。最后是参数合成，包括目标IP、排除端口、网卡接口、超时时间以及容器等复杂参数，这些都会通过数据转化和容器信息获取，最终直接使用。最前面设定的执行参数对用户是可见的，而整个合成和平台转换是我们系统内部完成的工作。工作结果：实现公司内部平台的跨可用区断网演练20+，发现10+不符合预期的业务问题，并持续推进业务的演练验证。4.4 混沌底层能力——基于网络不可用的实践我们刚才讨论的跨机房网络不可用的阻断，只是网络不可用众多模块中的一个。还有数据库不可用、依赖服务不可用、中间件不可用、缓存不可用以及域名不可用等一系列情况。面对这些泛化出的特殊场景，我们的工作主要分为两个部分：整合公司的机柜网络信息、数据库元信息、缓存元信息以及Discovery元信息。利用这些信息，我们可以构造出对应的IP数据段、端口以及网卡信息等参数模块。针对演练目标，整合CMDB的数据，获取了容器资源和主机资源信息。为什么要打通这些信息？因为这部分数据不适合开放给用户使用，错误的使用可能会导致故障扩散，产生不可预期的影响。将这两部分信息合并后，我们生成了必要的参数，并在后台执行了如网络DNS破坏、丢包或延迟等操作。4.4 图 - 基于网络不可用情况的标准处理流程针对不同的业务场景和用户定义的参数，我们帮助用户合成了所需的配置，简化了用户的操作流程。我们的目标非常明确：用户对ChaosBlade原生场景不熟，我们把ChaosBlade验证完，用户无需使用原生场景；通过提供业务化的演练场景，帮助用户快速上手解决使用难题；收口主机资源和容器资源，并平台化的提供注入范围，屏蔽注入信息，避免用户误操作引发灾难性的演练；集中元信息管理，透明各类数据元信息；通过这些分类的演练场景，我们帮助用户验证了在遇到异常时，系统是否能够进行有效的应对，比如在数据库出现异常时，系统是否能够自动执行切换到备用数据库的操作，以及其他相关的业务场景。4.5 ?最佳实践之——演练快照接下来，我将向各位展示我们的技术设计页面，它主要分为三个部分：演练配置、演练控制台、演练报告。4.5.1 演练配置演练配置部分我们提供了一个模块，用于模拟数据库的延迟异常。在这里，可以配置延迟波动、延迟时长，以及注入范围。用户可以选择是仅注入主库、仅注入从库，还是主从库同时注入。通过这样的配置，用户可以模拟出数据库延迟的异常情况。4.5.1 图1 - 演练配置详情页其次是可观测性接入，我们支持包括请求可用率-GRPC、请求可用率-HTTP的监控指标，以监控业务是否符合预期。此外，还有防护配置，包括设定故障多久后自动恢复，以及在特定告警发生时是否能够自动恢复。4.5.1 图2 - 演练配置-观测配置和防护配置再来看演练流程配置。在页面的中心部分，我们向用户清晰展示了确定的应用环境、资源类型、集群和机器配置，明确了我们的演练范围。通过流程化的方式，我们展示了演练的具体内容。4.5.1 图3 - 演练流程配置4.5.2 演练控制台在演练控制台，我们以简洁的方式向用户展示了演练进度、注入情况，以及当前执行节点的状态，如待攻击、待恢复或攻击中。同时，我们也会显示注入失败或提前恢复的状态。此外，整个页面还会展示一整套的巡检措施和指标信息。4.5.2 图1 - 演练控制台页面展示4.5.3 演练报告在演练报告部分，我们提供了一个note功能，并引入了演练指标。这是因为演练的核心在于可观测性，无论是通过控制台还是演练报告，都需要实时关注业务指标，以保障业务的稳定。4.5.3 图 - 演练报告详情展示页面演练报告除了展示上述信息外，更多地体现在用户的演练反馈和待办事项上。通过演练反馈，我们可以验证演练前的业务场景配置是否符合预期。而演练待办事项则是在演练过程中发现的需要后续跟进和处理的事件。五、实践效果如何？通过这样的产品化能力建设，我们得以帮助研发团队自主化地完成整个演练工程。最后简单回顾混沌平台上线两个月以来的业务数据——我们成功完善了20+场景在线上和日常环境中执行了200+演练演练覆盖了超过30+应用帮助我们发现了50+问题以及对各团队的赋能价值方面——业务团队中，能应对最常见的问题，包括缓存不可用、缓存延迟、数据库延迟以及域名不可用等情况。基架平台方面，推进了跨可用区断网验证工作。这些场景不仅符合业务场景，而且已经得到了有效的验证。在这个过程中，已经能够实现无需额外成本的演练。研发团队，只需负责日常的运维和答疑，而无需对每一次演练过程进行跟进。未来，我们计划接入公司内部的其他演练工具，以标准化整个公司的演练体系，培养用户的统一操作习惯，完成一整套的演练能力。通过演练前、演练中和演练后的流程，我们帮助用户驱动用户去管理混沌可能产生的业务风险，并跟进混沌本身产生的业务问题，以及解决这些问题的能力。（全文完）Q&A:1、混沌工程是如何控制生产环境的爆炸半径？2、实验撤销机制是怎么样的，怎么保证实验的影响能够被完全撤销？以上问题答案，欢迎点击“阅读全文”，观看完整版解答！！！征稿活动开始啦！！征稿主题：年中技术盘点——异常处理和案例分析（8月15日结束）投稿内容汇总：https://news.shulie.io/?page_id=9541！！重要通知！！如果你在某个稳定性领域有深入研究和实践，或者是技术团队的管理人员。欢迎加入TakinTalks稳定性社区专家团，以演讲、文章、视频等形式传播你的最佳实践和经验。有意可联系社区工作人员?18958048075（乔伊，微信同号），可免费获取社区赠书。2023下半年合集：15万字稳定性提升经验：《2023下半年最佳实践合集》限量申领！2023上半年合集：10万字干货：《数字业务连续性提升最佳实践》免费领取｜TakinTalks社区社区讲师课件合集：凭朋友圈转发截图免费课件资料并免费加入「TakinTalks读者交流群」添加助理小姐姐声明：本文由公众号「TakinTalks稳定性社区」联合社区专家共同原创撰写，如需转载，请后台回复“转载”获得授权。更多故障治理内容「好文推荐」??美图是如何搭建压测监控一体化平台的？??故障复盘后的告警如何加出效果？??去哪儿是如何做到大规模故障演练的？??美图SRE:一次线上大事故，我悟出了故障治理的3步9招??破坏系统是为了更稳定？混沌工程在去哪儿的4个阶段实践??监控告警怎么搭建比较合理？??点击【阅读原文】直达TakinTalks稳定性社区，获取更多实战资料！