B站故障应急与业务1-5-10摸排：如何实现超95%故障自发现率？

肥成

# 一分钟精华速览 #B站稳定性建设虽持续进行，但SRE对稳定性的量化数据知之甚少，又不断面临故障处理时间长、应急响应机制不健全、重复故障频发等问题，迫切需要建立一个面向故障的，对故障全生命周期进行更加精细化的管理。在应急响应4.0阶段，通过建设直面故障的应急响应中心，B站核心业务摸排率已达80%+，增加监控100+，并完成了30+业务的改造工作。目前，2023下半年B站已实现了推搜业务故障自发现率95%+，社区相关故障自发现率80%+。详细的解决策略和方法，请参阅文章正文。作者介绍?哔哩哔哩业务SRE负责人——张鹤?TakinTalks稳定性社区专家团成员，bilibili业务SRE负责人。2020年加入B站，负责哔哩哔哩业务稳定性保障相关工作，深度参与多活，活动保障，混沌工程，容量治理相关的建设，负责B站S赛、跨年晚会、拜年纪等相关活动的基础架构保障工作。温馨提醒：本文约8500字，预计花费13分钟阅读。后台回复?“交流”?进入读者交流群；回复“Q116”获取课件；背景无论是行业里还是在B站，都正经历大大小小的故障。对B站来说，去年也遇到了一些严重的故障，我们发现一些故障的处理时间很长，应急响应过程相对混乱，多次遇到了热搜类故障，更加不能容忍的是，同一类故障会重复发生。例如，某个运营配置在预发环境中进行部署，不小心影响到了生产环境，这种情况已发生多次。虽然我们一直在进行稳定性建设，但对稳定性的量化数据却知之甚少。比如，大家常说的故障1-5-10数据，实际表现怎么样，如何提高？故障召回率如何？客服和技术团队之间也存在一定的脱节。图 - B站稳定性保障面临的挑战面对这样的情况，我们决定建立一个全面的稳定性体系，对整个故障全生命周期进行更加精细化的管理。一、B站应急响应体系发展有哪几个阶段？1.1? 2021-2024的四个阶段1.0时代（2021年）：响应方式被动，SLB错误告警或服务可用率下降时匆忙应对。客服接到投诉后，群内讨论，效率低下。2.0时代（2022年）：引入SLO理念，基于SLO进行告警协同，但响应仍属被动，SLO告警意味着故障已发生。3.0时代（2023年）：主动识别业务风险，建立应急响应中心，整合客服、SLO、内部反馈和业务指标，集成可观测能力，快速定位问题和原因，并联动变更管理。4.0时代（2024年）：目前，专注于故障全生命周期管理，包括复盘、跟进和数据运营。1.2 ?B站应急响应体系B站的故障应急体系主要分为5个部分，即从故障预防、发现、定位、恢复或止损，到复盘和改进的整个过程。1.2 图 - B站应急响应体系的组成故障预防：采用混沌演练、断网演练等措施，重点进行业务摸排，识别核心业务场景，完善监控和预案体系。故障发现：依赖SLO、业务指标、客户投诉、内部反馈和舆情等多种数据源。故障定位：构建全面的可观测体系，上报所有变更至变更平台，提供链路变更影响分析，实现更新分析和联动预案。快速恢复：通过多活架构实现流量切换，必要时采取降级措施，利用限流能力保障系统稳定。复盘：基于时间线、故障原因、损失、定级、待办和反思总结等要素进行复盘。我将在本文分享如何进行一次有价值的复盘。二、业务1-5-10摸排如何落地？2.1 ?1-5-10摸排流程2.1 图 - 1-5-10摸排流程的4个部分确定目标：根据业务场景设定目标，如营收类项目减少资损，“热搜体质”服务确保稳定性，通用服务避免Px级故障等等。核心链路梳理：识别核心场景和关键链路，深入分析请求、数据和业务逻辑链路。技改优化：评估告警系统和预案体系有效性和完整性，识别潜在问题点，实施改进和优化措施。结果验收：定期检查优化措施是否有效，是否达到1-3-5-10目标。2.2 确定目标整体来说，安全生产的整体目标是防止能预见的问题、快恢不能预见的问题、不再发生已发生的故障。更具体来说，我们目标实现无Px级故障、无热搜、1-5-10以及无资损。2.3 ?核心场景梳理B站业务场景众多，这里我简单列举了一些主要的部分，主要分为搜索服务、推荐服务、社区互动、播放服务、基础服务、营收类等6大类。基于这些大的场景，我们会进一步细分并梳理每一个小场景的业务。在进行业务摸排时，我们会特别关注两个关键的链路：访问链路：这涉及到用户如何与服务进行交互，以及服务如何响应用户的请求。数据链路：这包括数据如何在系统内部流动，以及数据是如何被处理和存储的。2.3.1 ?关键路径-访问链路下面详细介绍访问链路摸排的一些关键点。以B站为例，访问链路从最上层的DCDN开始，然后到达不同的AZ，接着到达SLB。服务之间会有内部调用，可能会调用到KV和DB，甚至有些服务存在弱依赖，需要跨可用区调用另一个可用区的服务。2.3.1 图 - B站访问链路及对应故障分析在这样一个复杂的访问链路中，不同的点都可能出现故障。例如，如果DCDN出现故障，由于数据中心是由多家厂商提供服务的，我们可以迅速切换到其他CDN厂商，从而绕过出现问题的CDN厂商，实现快速恢复。对于SLB或GW的故障，如果是单点故障，可以通过多活架构进行流量切换和止损。此外，也可以迅速搭建一套新的SLB集群来应对故障。单个服务也可能出现各种问题，比如服务代码中存在bug、容量预估出现问题、某台物理机宕机导致服务出现抖动，或者如果弱依赖的服务出现故障，可能会影响到强依赖它的服务，引发各种问题。这就要求每个服务都必须有相应的预案来应对这些问题。再往下是中间件层，包括数据库、缓存或消息队列等，这些都可能出现各种问题。例如，数据库出现故障时，有些业务场景可能支持主从自动切换，而有些业务则无法接受自动切换，因为这可能导致数据不一致或脏数据问题。数据库连接池可能会被压垮，也可能存在容量问题。至于基础设施层面，由于我们的服务是多活架构，可能会出现专线故障或某个机房入口层的故障。比如在前两年，我们曾经遇到的一次故障，就是由于入口层的故障引发了一连串的问题。2.3.2 ?关键路径-数据链路2.3.2 图 - B站数据链路及对应故障分析通常，数据链路始于服务对DB的操作。操作后，生成的日志通过数据传输服务（例如DTS）传输和消费，然后投递到消息队列中。这些操作可能是由第三方服务，或者是其他job来完成的。在这个过程中，可能会出现多种情况。例如，数据库之间的主从复制可能出现延迟或者异常，主从复制也可能存在自动切换。DTS在拉取数据时可能会失败，或者在投递消息到队列时可能会产生延迟，甚至可能出现数据解析的异常。此外，消息服务在消费过程中也可能遇到问题。例如，作为消费者，可能因为消费速度慢而导致消息堆积，或者在生产消息或消费消息的过程中出现断流。业务服务本身也可能出现相应的异常情况。在判定这些问题时，无论是访问链路还是数据链路，都应该对每个可能出现故障的点制定相应的预案，并建设相应的处理能力。2.4 ? ?技改优化那如何实现1-3-5-10的目标呢？2.4.1 ? 快速发现（1分钟）监控系统的完善是快速发现问题的关键，因为需要依赖监控系统来及时发现问题。我们对从基础设施到服务层面的各个部分监控覆盖做了全面摸排，以确保系统的全面可观测性。2.4.1 图1-B站监控覆盖摸排2.4.2 ?定界定位（5分钟）那如何实现快速的故障定位和进阶分析？主要依赖两个方面：错误下钻、定界定位分析。1）错误下钻：基于故障的指标分析错误的分布情况，第一时间知道错误范围、边界。确定哪个可用区错误。如果错误仅集中在一个可用区，可利用多活架构通过流量切换进行初步止损。判断哪个主机、POD错误。例如，某台物理机如果宕机，可能会导致一系列的服务抖动考虑使用自恢复机制或流量切换快速止损。识别哪个Pash，什么错误码、错误量。2.4.2 图1 - 告警信息中的错误下钻2）定界定位分析：基于SLO（可用率、QPS、延时）、饱和度、变更、依赖服务、依赖组件、拓扑关系来确定故障边界和诱因。变更：上下游变更、基础设施变更、平台变更、组件变更；饱和度：CPU/MEM/IO、连接数、连接池、quota限流等常见饱和度；下游依赖：下游应用、外部依赖、下游数据库、缓存、KV、Databus、DTS等；下钻分析：进一步分析下游问题。2.4.2 图2 - 定界定位包含多个维度的分析2.4.2 图3 - 异常对象分析结果最终，可以通过分析推断出，大概率是哪个地方的问题导致了整个故障。2.4.3 ? 定界定位（全局）1）全网可用性大盘针对一些具体的故障点，比如网络交换机的问题或专线的故障，我们需要快速了解这些故障对整个系统的影响。例如，需要知道这些故障是否影响了播放服务、推荐服务、搜索服务，或者社区相关的操作。通过一个全网的可用性监控大盘，能够了解故障的影响范围，从而确定最高优先级的止损和修复工作。2.4.3 图1 -全网可用性大盘查看故障影响范围及修复优先级2.4.3 图2 - 全网可用性大盘查看核心场景SLO2.4.3 图3 - 全网可用性大盘下钻分析此外，我们还构建了基于延迟的监控大盘。当数据链路的某个环节出现问题，或者系统中的某一部分出现故障时，我们需要了解这些延迟问题具体影响了哪些业务场景。例如，判断延迟是否影响了投稿流程，或者是否对其他特定场景产生了影响。通过这些延迟大盘，能够快速进行全网的定位分析。2.4.3 图4?- 全网延迟大盘2.4.4 ?快速恢复（10分钟）2.4.4 ?图1 - 快恢能力的几个组成部分业务快恢：在故障发生时，业务能够通过降级处理数据、隐藏服务玩法或入口层等通用降级能力来快速恢复。微服务快速恢复：通过框架层面的兜底降级和恢复能力，如限流机制和自我保护措施，确保服务流量突增不影响其他服务。组件快速恢复：建立预案，包括快速扩容和恢复能力，以及内部基础组件的分布式架构和容灾能力。实施SLB和数据库限流，以及黑名单机制和网关层联动端上流控，防止过载。多活快速恢复：采用多活架构，通过东西向和南北向的流量切换实现快速止损，并能在资源不足时快速弹性扩展，支持备用资源或公有云，以快速响应流量请求。2.5 ??以搜索场景为例：1-5-10摸排实践2.5.1 ? 场景梳理B站的用户都清楚，搜索功能主要包括以下几个方面：默认词：用户在搜索框输入时，系统提供的默认词推荐。不同搜索垂搜类：例如，我们有针对直播的搜索，还有搜索历史，热搜词等场景。联想词：例如，当用户想搜索“LOL比赛”，输入“lol”之后，系统会提供一系列相关的联想词。从这些功能中，我们可以看出大场景主要包括两个部分：综搜和垂搜。功能则包括了主搜（内容搜索）、默认词、搜索历史、热搜词以及联想词。在了解了这些大场景功能之后，我们需要思考的是，对于我们来说，哪些功能是最重要的？显然，内容搜索是最基本的需求。我们必须保证用户能够通过搜索关键词得到他们想要的结果。那么回过头来看，哪些场景可能会引起一些突发的问题？热搜词是一个例子。比如，如果我们刚结束了一场比赛，大家都非常兴奋，此时通过热搜词，大家能够迅速找到相关的搜索内容。这可能会导致流量的突增。还有一些默认词，如果把某一个词作为默认词，那么这个词的流量也会有突增。搜索场景对B站来说极为重要，它直接关系到用户的体验，所以它的整个故障处理机制也必须达到1-3-510的效果。我们目标也很明确：首先，避免任何可能上热搜的故障；其次，确保不出现P3以上的故障。2.5.2 ?关键路径对于搜索场景来说，关键路径包括请求链路和数据链路。例如，热搜词会通过Router集群，然后到interface，再到热搜服务。我们最核心的服务是主搜，它通过Router集群到Interface-rerank进行一些重排操作。同时，会调用QS进行分词处理，并且基于UGC和不同的垂直分类，如直播、OGV，调用相关的Rank服务。此外，我们会调用预估服务进行打分，并调用BS服务进行数据召回。这构成了整个请求的访问链路。对于数据链路，以投稿为例，稿件在审核通过后，如何能够被搜索到？这需要通过近线和离线数据链路。内部DB消费了UGC和垂直分类的数据变更，然后直接写入到KV存储中。之后，KV存储会触发一些消息，比如实时索引会通过消费这些消息来构建。通过KV我们会定期构建全量索引，并利用索引分发服务进行索引更新。这样，我们就形成了完整的访问链路和数据链路。2.5.3 ?发现、定界、定位在我们对搜索功能进行摸排时，首先注意到整个搜索链路几乎都是由C++服务构成的，这些服务大多使用BRPC。在摸排过程中，我们发现BRPC的SLO指标并没有统一化。这意味着，例如BS和Rank这两个C++服务，它们上报的稳定性指标实际上是不同的。这种不一致性使得我们很难通过平台建设整个稳定性体系。1）如何实现快速发现？告警覆盖Brpc标准化：第一步是将BRPC的指标标准化，定义通用的Metric，并根据不同的Level进行区分。业务关键指标：点击率、展现等。我们接着梳理了整个链路中涉及的关键业务指标。对于搜索来说，我们可能更关注用户的点击率、某些卡片的展现情况，以及商业卡片或处理卡片的占比。如果这些卡片的占比很小，可能也会暗示存在问题。Coredump标准化：core_pattern统一、Core文件生命周期管理、基于角色的告警策略。C++服务非常依赖告警，但我们发现当时的告警标准化并不一致，业务依赖的目录也不一样，告警的生命周期管理也没有做好。告警通知只有工程师能收到，算法团队成员收不到。因此，我们基于CMDB的角色，做了一个统一的告警治理专项。平台支撑：我们也梳理了平台需要提供的支持，例如SLO平台支持brpc相关告警、电话升级、ERC故障协同能力、变更平台支持brpc、业务指标变更阻断告警治理实例纬度告警改造成应用纬度告警，提供max、平均、分位值等纬度告警。原来基于实例维度的告警，如一个服务有500个实例，其中300个实例CPU使用率很高，这会导致300条告警，形成告警风暴，改造后大大减少了告警量。基于服务等级告警策略。例如，对于已经实现多活的关键服务，我们要求CPU使用率不能超过35%，以确保在切换流量时能够承受全部流量。对于不那么核心的服务，如一些管理后台的服务，要求可能会放宽到70%或80%。…2）如何定界定位？可观测体系建设场景可观测大盘：把BRPC建设成一个统一标准化的体系，这样我们就可以基于通用的BRPC SLO做整个场景的可观测大盘，确保出现问题时能够及时定位并快速发现。核心链路可观测：我们构建了搜索的核心链路，通过核心链路的监控，能够一眼看到链路的SLO、饱和度，以及中间件的可用性，还有链路上是否有时间点的变更。日志：统一接入日志平台、日志告警。平台支撑：包含实验平台接入变更、SLO平台支持基于BRPC场景定义、场景大盘。我们发现实验平台的变更特别频繁，这要求实验平台的变更必须接入变更管控，必须有灰度发布的策略，基于实例进行灰度发布，控制变更的批次。同时，在变更时，必须接入BRPC的SLO能力。如果在变更过程中发现SLO指标较低，应能触发阻断机制。变更统一上报到了变更平台，这样就能够支持我们后面的故障分析能力建设。根因分析能力基于核心链路，根因下钻能力。基于核心链路做了变更分析和指标分析，确保在出现问题后能够快速帮助我们进行定界定位。这里我要提一点，快速定位故障的根因并不容易。对我们来说，能够快速界定哪个点或哪个面出现问题，就已经足够。例如，如果出现故障，我们能够快速知道是否只有某个可用区的服务出现故障，这时我们可以直接执行预案，先止损。然后再来看这个可用区的故障服务，是由于什么变更引起的，还是由于SQL操作或其他操作引起的。2.5.4 ?快速恢复就上述的搜索核心链路而言，无论是Router集群、调用interface、分词服务，还是精排或打分相关的服务，每个环节都可能出现问题。2.5.4 ?图 - 核心链路的每个环节都可能出现问题针对入口服务，如Router集群或某个可用区出现问题，多活架构允许我们直接进行流量切换。对于容量瓶颈问题，我们提供了通用的限流能力，并联动端上进行流量控制。在降级方面，我们有多种策略：如果饱和度出现问题，可以在召回时减少召回数，从而降低粗排量，提高系统吞吐量以应对流量高峰。对于某些品类的降级，例如在进行搜索时，如果OGV（官方视频内容）出现问题，我们可以自动摘除OGV，不再展示OGV卡片，这一决策基于业务指标和共同指标，如OGV的可控率变低。在底层出现问题时，容灾能力通过缓存实现。例如，当Rank服务出现问题时，我们可以通过缓存快速获取先前的搜索结果并返回给用户，确保用户始终能够看到搜索结果。此外，Router服务也可以通过T+1的QV存储进行降级。推广搜的服务通常较重，无论是词表还是模型。为了保护这些服务，我们将其纳入云原生体系，目前正在建设中，包括如何实现快速扩展和快速启动。我们实现了原理升级能力，确保服务在变更或故障修复时加载的模型和词表保持稳定，不会漂移，从而大幅提升启动效率。对于较大的服务，我们进行了服务拆分，如将直播、漫画、OGV等单独拆分为不同的服务，这样每个服务的数据和特性更轻，能够快速启动。由于服务拆分后更倾向于微服务，我们可以使用Kubernetes等云原生工具的弹性能力，以确保服务能够快速扩展和启动。2.6 ? 1-5-10 达成通过摸排工作，目前我们已经取得了一些不错的成效。三、如何建设直面故障的应急响应中心？3.1 ?面向故障建设平台能力故障召回主要包括几块：客服投诉、SLO低阈值、内部报障，以及一些舆情等，这些会触发ERC进行自动召回。策略中心对应的可以去做策略的预定义，例如，客服投诉故障后应该要拉哪些干系人处理、升级策略是什么，或者2分钟后无人响应应该怎么处理。由于ERC是面向整个故障生命周期管理的，所以也会提供故障复盘和待办跟进事项。3.1 图 - 故障召回的流程3.2 ?故障召回-故障预定义以客服团队为例，他们关注的可能是直播服务下的送礼功能，或者观看功能的故障。而对基础技术侧来说，关注点在于如何确定应该联系技术侧的哪些人员。那如何将故障场景与技术场景关联起来？1）客服召回：客诉业务域、客诉量我们提供了一个客服业务域与技术组织域关联关系的管理工具。这意味着，我们可以设定一些通用的配置，比如当客服量超过某个阈值时，系统会自动将其视为一个故障进行处理。这里值得一提的是，首次客诉时间的反馈非常重要，它能帮助判断问题的聚集性，这种聚集性的信息能够迅速帮助我们定位技术侧的问题点。3.2 图1 - 稿件发布超时故障2）SLO低阈值、业务指标我们对SLO低阈值和业务指标进行了细致管理，包括应用及特定场景（如发弹幕）的SLO指标，以及故障阈值、持续时间管理。例如，物理机宕机或主动切换若能自恢复，我们仅视其为告警。通过设定持续时间，我们减少了误报并确保故障触发的准确性。3.2 图2?- 设定持续时间减少误报我们实现了在故障发生时自动通知相关责任人并创建应急群组的功能，支持复用现有业务方故障处理群组，还制定了故障未响应时的自动升级策略。3.2 图3?- 若故障未响应则启用自动升级策略3）通用故障能力最后，我们将整个故障应急体系抽象成了通用能力，支持告警升级，并且开放了API，允许其他业务方复用协同机制。3.3 ?应急协同-客服我们与客服团队合作，确立了故障业务域与组织架构之间的关联关系。当某个地方出现问题时，如果客服接收到的投诉数量超过了我们设定的阈值（比如10个），那么这个事件就会被标记为高优先级客户投诉，自动与应急响应中心动态联动，将所有相关的干系人拉入一个群组中，以便立即开始故障的应急处理。3.3 图-基于客诉的应急协同流程同时，当确认这个故障确实存在时，我们会直接通知管理层和相关同事。通过这种方式，我们得以将高优先级的客诉以及那些确实需要关注、反馈量较多的客诉单独提取出来，进行专门的处理。这样我们线上客诉反馈的故障，处理效率提升了10+倍。3.4 ?应急协同-SLO&业务指标3.4图- 基于SLO&业务指标的应急协同流程以前的方式：过去的做法是在收到SLO告警后，研发和SRE团队会先接到通知，随后讨论告警原因。若影响范围广，会立即组建群组，召集各方集中处理。若群组内确认影响严重，将进一步通报管理层。存在的问题：面向告警的匆忙应急，可能对用户压根没影响核心场景缺乏电话告警故障干系人拉不全，协同效率低消息触达老板慢改善后：引入应急响应中心后，我们对故障处理流程进行了优化。我们为关键场景设定了明确的故障协同策略和应急响应触发条件。一旦触发，系统自动组建群组并启动应急程序，相关人员可以迅速加入并发布通告。对于关键场景，我们确保电话告警的全面覆盖，并在无人响应时自动触发电话告警。3.5 ?应急协同-可观测通过这些努力，我们实现了整个故障处理过程中的可观测性以及根因分析能力。1）过程可观测首先，我们确保整个故障处理过程是可观测的，这包括从故障的发生、发现、响应、进展更新到最终恢复的每一个环节。目标是让所有人都能够清晰地看到故障处理的进度，避免出现大家经常询问的问题，比如"故障现在处理得怎么样了？”通过将整个故障处理过程以卡片的形式展现出来，我们让每个人都能了解到当前处理的具体情况。2）基础分析下钻此外，在我们使用ERC系统处理故障时，我们还会进行一些基础的下钻分析。这包括对可用区的聚集性错误码的分布、链路变更等情况进行可观测分析。这样，在故障响应群组建立的第一时间，团队成员就能够看到当前的SLO状态，判断是否存在集中性问题，从而帮助我们做出快速决策。3）根因推荐同时，我们还联动了根因分析的能力，这基于告警的分析、基于变更的分析以及基于一些指标的下钻分析，能够让我们快速定位故障的最可能原因，并迅速采取止损措施。3.6 故障复盘当故障处理和恢复工作完成后，接下来的重点就是进行故障复盘。复盘是每家公司都在进行的工作，其关键在于如何执行一次有价值的复盘。故障预防我们从以下三个方面来进行：故障摸排回顾：首先要确认这个故障是否在之前的业务摸排中被识别到。如果已经被识别，我们需要追问为什么没有采取措施阻止故障的发生，为什么它最终演变成了实际的故障。历史重复故障：如果这是一个历史上重复发生的故障，这是我们难以容忍的。我们必须反思，为什么之前没有彻底解决这个问题，以防止它再次发生。故障阻断机制评估：要分析故障是否被故障阻断机制成功阻断。如果没有，则需要深入分析原因，并探索如何优化故障阻断能力，以避免类似问题再次发生。在故障发生时，我们需要关注的是：故障召回率：无论是通过客服渠道还是技术侧的SLO和业务指标，我们需要确保能够快速召回相关人员。如果故障是通过非正式渠道发现的，这表明我们需要提高召回率，尤其是基于技术指标的召回能力。故障召回准确率：我们要确保故障召回的准确率，避免频繁的错误拉响警报，导致团队对故障响应的敏感度降低。故障1-3-5-10达成分析：我们需要评估从发现、定位到止损的整个流程的效率，以及1-3-5-10目标的达成率。如果处理速度慢，我们需要找出瓶颈所在，并优化处理流程。最后，在复盘过程中，我们需要找出可以改进的地方，以避免同样的故障再次发生，并构建相应的预防和提醒机制。四、总结展望?关于未来的规划有三个方面：第一，持续运营。我们将持续运营和优化故障阻断率、业务达成率、故障召回率以及逃逸率。这包括对SLO的覆盖范围和故障准确率的持续关注和改进。第二，故障召回体系。我们将把端上的故障召回和舆情相关的召回纳入到故障召回体系中，以提高召回的全面性和及时性。第三，预案联动与止损能力。我们计划与预案平台进行联动，构建更加完善的预案联动和止损能力，以提升我们对潜在故障的预防和响应能力。（全文完）Q&A:1、故障摸排这里有使用故障注入或模拟技术?具体是怎么设计的的、还有怎么验证故障定位有效性?2、告警通知和升级流程是如何设计的?还有、告警升级和故障定位流程是怎么关联的?3、怎么识别和分类不同的故障模式?4、slo平台主要的功能是什么?以上问题答案，欢迎点击“阅读全文”，观看完整版解答！！！重要通知！！如果你在某个稳定性领域有深入研究和实践，或者是技术团队的管理人员。欢迎加入TakinTalks稳定性社区专家团，以演讲、文章、视频等形式传播你的最佳实践和经验。有意可联系社区工作人员?18958048075（乔伊，微信同号），可免费获取社区赠书。2023下半年合集：15万字稳定性提升经验：《2023下半年最佳实践合集》限量申领！2023上半年合集：10万字干货：《数字业务连续性提升最佳实践》免费领取｜TakinTalks社区社区讲师课件合集：凭朋友圈转发截图免费课件资料并免费加入「TakinTalks读者交流群」添加助理小姐姐声明：本文由公众号「TakinTalks稳定性社区」联合社区专家共同原创撰写，如需转载，请后台回复“转载”获得授权。更多故障治理内容「好文推荐」??美图是如何搭建压测监控一体化平台的？??故障复盘后的告警如何加出效果？??去哪儿是如何做到大规模故障演练的？??美图SRE:一次线上大事故，我悟出了故障治理的3步9招??破坏系统是为了更稳定？混沌工程在去哪儿的4个阶段实践??监控告警怎么搭建比较合理？??点击【阅读原文】直达TakinTalks稳定性社区，获取更多实战资料！