“1-3-5-10”原则：B站如何落地安全生产体系？

燕舞晨辉

“1-3-5-10”原则：B站如何落地安全生产体系？ 哔哩哔哩 武安闯 TakinTalks稳定性社区 TakinTalks稳定性社区 杭州数列网络科技有限责任公司 专注业务稳定性提升的技术交流平台。分享领先的、可参考的、可落地的实战经验。 60篇内容 2024年09月20日 11:30 浙江 # 一分钟精华速览 #在降本增效的大背景下，各公司事故频上热搜，因此急需建立起一套面向故障的安全生产体系，以期防止能预见的问题、快速恢复不能预防的问题、不再重复已发生的问题。B站通过安全变更平台实现流程与制度的安全管控，有效减少故障发生。同时，借助多活容灾、断网演练及业务摸排等措施，显著提升故障发现与应急响应效率。此外，成立安全生产委员会并加强文化宣传，提升全员安全意识。目前，B站已形成“1-3-5-10”安全生产体系，确保系统安全与业务稳定运行。详细的解决策略和方法，请参阅文章正文。作者介绍哔哩哔哩SRE团队负责人——武安闯TakinTalks稳定性社区专家团成员，B站SRE团队负责人。当前负责业务SRE、安全生产、平台工程等方向的工作，从0到1带领B站运维向SRE转型，建设SRE可靠性体系，对高可用架构、安全生产体系、稳定性运营和SRE转型有深入的实践和思考。温馨提醒：本文约8500字，预计花费13分钟阅读。后台回复“交流”进入读者交流群；回复“Q114”获取课件；背景最近一两年，行业各种事故频发，B站也不例外。这些事故频繁登上了微博热搜，引起广泛的社会关注。就我个人的观察和分析，我认为有几个关键因素导致了这一趋势。图1 - 行业事故频发引起广泛关注业务：行业增长正在放缓，这导致了许多公司开始寻求降本增效的措施。这种压力很快传递到了业务和人员层面。业务团队感受到了更大的压力，团队组织结构频繁变动，人员更迭也变得司空见惯。这种情况下，原本由资深研发人员维护的服务，可能转交给了不熟悉服务历史的新同事，这无疑增加了出现问题的风险。人员：当前各企业普遍存在信息安全意识薄弱的问题，加之为了降低成本而引发的人员流失，这进一步增加了工作压力。当大家承受较大工作压力时，在变更管理或日常运维中的操作更容易出错，从而触发事故。文化：从文化的角度来看，尽管有些公司在安全生产方面做得比较好，比如阿里系的公司，但整个行业对安全生产的重视程度仍然参差不齐。很多公司，包括B站在内，过去更注重效率和快速迭代，而对安全生产的重视不足。技术：从技术层面上讲，变更量的增加往往导致变更质量的下降，同时，由于资源的减少，系统的稳定性债务和历史问题逐渐累积，最终爆发出来。这些技术债务的存在，加上资源的紧张，使得系统更容易出现容量事故。图2 - B站系统事故登上微博热搜如Google SRE中所说，系统的稳定运行并非理所当然，而是该系统无数异常情况下的一种特例。因此，必须面向异常和故障去设计一套安全生产机制。一、我们如何理解安全生产？安全生产不应该被看作是某个独立环节的任务，而是一个全面的、系统化的工程。为了更好地理解这一点，可以借助日常生活中的安全驾驶来做一个类比。在安全驾驶中，有明确的规章制度，有专门的执法机构来确保规则的执行，还有像摄像头这样的监控设备，以及驾驶证这样的准入门槛。对于个人来说，良好的驾驶技术和定期的车辆维护也是保障安全的重要组成部分。当事故发生时，有保险和赔偿机制来减轻损失。同样的，安全生产也需要这样一套完整的体系。从技术层面来看，首先要确保架构是高可用的，这包括基础设施、中间件以及业务架构。基于高可用架构，进一步实践多活架构，通过多活的容灾验证来增强系统的稳定性。此外，还需要对潜在的风险进行识别和预防。这包括用SLO来度量和发现服务的风险，通过变更管控来拦截可能导致故障的变更，利用混沌工程来验证系统架构的稳定性等。同时，还需要建立统一的风险管理平台，对所有风险进行上报、运营和治理。如果风险未能预防，可能会导致线上故障。所以需要对系统提前做故障摸排，对核心业务进行全面的梳理，识别可能的故障场景，并建立相应的应急响应机制。这包括提升故障定位能力，前置梳理应急预案，并通过演练来检验这些预案的有效性等。最后，除了技术层面的工作，还需要文化和运营的支持。文化上，需要建立安全生产的红线和制度，通过考试、交流等方式提升安全生产的意识。运营上，需要对内部数据进行分析和运营，确保安全生产的目标得以实现。二、B站如何设计安全生产框架？2.1 安全生产整体框架我们设定了明确的目标——防止能预见的问题、快速恢复不能预防的问题、不再重复已发生的问题。我们借鉴了行业内阿里的最佳实践，阿里提出了“1-5-10”，即1分钟发现问题，5分钟定位问题，10分钟恢复服务。在此基础上我们进行了一些调整，增加了3分钟的响应时间，形成了B站的“1-3-5-10”原则。2.2 安全生产实践思路B站的安全生产实践思路分为四个阶段。这个实践思路的顺序可能与其他公司不同，这主要取决于每个公司的组织架构和实际情况。例如，如果公司有CTO统一管理团队，可以将阶段一和阶段四合并，放在最前面。但对于许多互联网公司来说，由于组织结构趋于扁平化，已经没有CTO这样的岗位，更多是横向的组织（如技术委员会），无法一开始就制定一个红线制度约束所有研发团队，所以我们采取了先技术后意识的策略。三、B站安全生产有哪些技术实践？3.1 安全变更根据谷歌的研究表明，大约70%的故障都是由变更引起的。回顾我们过去一段时间的重大故障，无一例外都与变更有关。因此，我们决定首先从安全变更着手，建立了以安全变更为核心的变更管控能力。3.1 图 - B站遇到多起由变更引起的事故3.1.1 安全变更实践将所有变更操作统一定义并上报，我们实现了变更的集中管理和实时监控，这是基本能力的实现。另一块是稳定性能力，我们对节假日、特殊日期实施了封网策略，以避免在这些时期进行未经审批的变更，还利用SLO指标，对服务变更进行实时监控，一旦检测到服务可用率下降，系统会自动阻断变更，防止故障的发生。此外，我们还基于收集到的数据进行运营分析，不断优化变更管理流程。具体来说，每天收集和分析线上变更的相关数据，包括变更的频次、检测次数以及拦截次数。此外，还会统计每周因变更所引发的事故数量。通过对这些数据的系统化运营，能够更加精准地把握变更过程中的安全状况。以上变更管控的详细落地经过，请查看往期分享：《亿级流量下的故障事前预防：B站如何从0-1构建变更防控体系？》，这里不再展开描述。3.2 从安全变更到多活容灾当变更类的事故得到有效收敛后，我们发现架构类事故成了主要问题。面对架构类的事故，比如由于CDN不可用或IDC专线故障导致的业务不可用，以及由于业务架构问题导致的服务中断，多活容灾的预案是最为有效的应对策略。我们在多活容灾方面做了大量的工作，像用户社区、播放这类核心功能已经实现了多活容灾。然而，去年我们经历了三次网络故障，这些故障既验证了我们多活的有效性，同时也暴露出了一些问题。例如，一些依赖的服务没有实现多活，或者业务在使用多活时不规范，将两个可用区当作一个大内网来使用，没有在单个可用区内形成闭环。此外，当整个机房专线级别的故障发生时，一些组件的多活容灾行为并不符合预期。我们还发现，在机房级别或专线级别的故障发生时，内部的一些管控系统可能也无法幸免。3.2.1 图 - 用户社区、播放类核心功能已实现多活所以过去一年，我们把多活的重点放在容灾建设上：一是管控系统的容灾，二是业务系统的容灾。3.2.1 管控系统的多活容灾管控系统涵盖了我们内部的多个关键平台，包括CDN平台、DNS平台、多活切量平台、VPN登录系统、缓存系统，以及各种中间件平台等。对于管控系统的容灾，我们特别关注系统对内部服务或中间件的依赖，确保这些依赖符合预期，管控系统本身能够达到高可用的标准。除了对依赖的检查，我们还实施了专线断网演练。具体来说，断网演练将某个管控系统的所有流量切换到一个可用区，然后在另一个没有流量的可用区人为注入专线不可用的故障，再验证该可用区的服务能力是否符合预期，是否可用区内闭环。断网演练符合预期后，我们会将断网演练常态化，定期对管控系统注入专线不可用的故障，比如每周进行一次，持续观察和验证系统的行为是否符合预期。3.2.2 业务系统的多活容灾在业务系统的多活容灾实践中，我们的工作更为全面和细致。首先是业务系统的多活风险巡检，我们会巡检业务的跨可用区依赖、强弱依赖、中间件多活读写配置、服务容量、多可用区流量比例等信息，梳理出多活风险后，再找研发团队进行进一步的确认和处理。整改完成后，对业务系统进行专线断网演练，验证单可用区服务闭环能力。接下来，我们关注的是整个多活链路系统的容量问题。如果不经过实际的切量演练，我们无法保证全链路的容量可以支撑住流量切换。因此，我们实施了全面的南北向和东西向的切量演练，将某个系统的流量全部切换到一个可用区，并让其运行一整天，然后再切换回来，以此来验证全链路容量是否充足。此外，我们还实施了多活故障演练，模拟一个可用区的服务出现故障时的多活容灾预案。有两种止损方式：手动切流和自动容灾。手动切流响应时间大约是五到十分钟，但也依赖人的响应时间，因此我们引入了跨机房平滑重试机制：当一个可用区的服务不可用时，通过网关层实现请求平滑重试到另一个可用区。这种重试不是简单地将所有流量切换过去，而是基于成功率进行探测。如果发现另一个可用区服务也不可用，流量则不会跨可用区重试；如果重试成功，则会逐步增加重试过去的流量。平滑重试是我们多活自动容灾非常重要的策略。3.2.3 实践效果对于核心业务的读场景，已经能够做到不依赖于专线的可用性。日常我们已经形成围绕多活风险巡和治理的工作模式，并定期对业务系统、管控系统开展全链路的切量演练和断网演练。目前我们的断网演练是基于混沌工程进行的，下半年会进行物理链路上的专线中断演练，这将模拟IDC级别的网络故障。等下半年演练完成之后再给大家详细分享我们的踩坑历程。3.3 故障摸排与应急快恢通过多活容灾我们兜底了架构类的故障，但这不代表我们的服务稳定了。进一步思考，服务还存在哪些可能的故障类型？对于非架构类的故障应该怎么应对，故障发生时如何快速定界止损？3.3.1 业务故障摸排在业务故障摸排方面，我们遵循的是“1-3-5-10”的原则，这是一个旨在快速发现、响应、定位和恢复故障的流程。3.3.2 摸排实践案例这里以某个业务风险摸排的实际案例为例，还原我们的工作流程。1）链路梳理当对某个业务系统进行摸排时，SRE和研发团队会协同工作，首先梳理出整个业务链路。2）故障场景梳理然后识别出可能的故障场景。这些场景可能包括单个机房的全面故障，下游服务的故障导致的连锁故障等，逐一列举出这些故障场景。3）故障发现梳理故障场景梳理出来后，如何发现这些故障？为此，我们会设定故障触发的指标条件，这些指标可能是基于服务等级目标（SLO）的，也可能是基于业务指标和用户反馈的。4）故障预案梳理确定了这些故障场景后，要分析需要哪些故障预案来应对。如果是单个机房故障，我们可能需要执行多活切换；如果是组件问题，我们则需要该组件有明确的SOP，或者业务系统能够进行降级处理。5）改进优化这些预案将转化为技术改进措施，并作为技术待办事项进行跟踪和管理。3.3.3 故障应急中心（ERC）:故障发现3.3.3.1 故障如何发现？当我们完成业务故障风险的摸排后，面临的第一个问题是如何发现故障。在传统的故障应急管理中，如果出现事故，一线人员通常会忙于应急处理，无法及时做故障信息同步。即便有一个故障通告系统，要求一线人员在事故发生时首先进行通告，也是反SRE的应急意识的。故障发现阶段，应该实现自动化，让一线人员可以专注于事故处理，而不需要分心去做故障通告。同时，这也确保了管理层和相关人员能够及时获得事故信息，从而快速响应。所以我们的目标是建立一个故障应急系统，它能够自动识别故障，并自动启动应急协同流程，从而来提高我们的故障响应效率和快恢能力。3.3.3.2 自动化机制怎么设计？故障的自动发现，主要从四类指标召回：业务KPI：业务指标波动代表业务的北极星指标已经受损，用于故障召回非常合适，如业务的订单量、用户在线人数、进房数量，或业务的评论量、弹幕量等，基于这些业务类的数据指标量级波动来进行故障的检测和召回。对于推荐系统来说，关注的业务指标是推荐内容的点击率、某类卡片的展现率等指标。核心场景SLO：在一些核心功能场景中，比如视频页、拉取评论列表、拉取弹幕、点赞行为、直播间等，如果这个功能的SLO从平时的高标准突然下跌，如从四个九（99.99%）下降到两个九（99%），极大概率会导致部分用户功能不可用，严重影响用户体验，也非常适合用于故障召回。客诉突发：由于SLO和业务KPI可能无法覆盖所有的业务场景，特别是一些对用户体验影响不那么核心的功能，那就会通过客诉反馈量来兜底。在一定时间内，某个功能的客诉数量超过了设定的阈值，就会触发故障的应急响应。微博舆情：我们还会关注社交媒体上的舆情，例如微博上的用户反馈。综合这四类故障指标，我们就构建一个全面的故障自动发现能力，显著提升我们对故障的响应速度和快恢能力。3.3.3.3 如何触发？对于业务KPI和核心场景SLO指标，ERC支持常见的指标告警类规则配置，如同环比，可用率下跌、持续时间等，当规则触发时，则自动拉起故障应急响应群，拉人，并做故障信息通告。对于客诉突发，我们与客服团队进行了沟通，把客诉关联的场景跟技术侧的cmdb系统做映射。当客服接收到的客诉量超过某个阈值时，ERC自动拉起故障应急响应群，拉人，并做故障信息通告。此外，我们也提供了手动升级故障、通告故障的能力。对于没有明确业务KPI/SLO指标或客诉的业务系统，或内部管控系统和基础设施，在出现故障时，可以通过手动方式来通告线上故障。3.3.4. 故障应急中心：应急快恢1）故障发生：信息协同、人员协同当一个故障在平台被预定义并触发时，会自动创建应急协同群组，并发布故障通告。这个过程中，SRE、研发团队以及相关联的团队成员会被自动拉入到群组中。如果某个业务团队已经建立了自己内部的故障应急响应体系，并且有一些自定义的文案推送，我们还会将这些SOP推送到他们的应急群组中，以便团队成员能够迅速进行故障分析。2）故障定界、根因定位在故障定位方面，当故障发生时，我们会查看相关的变更信息或者监控大盘，比如某个组件的监控情况。由于这些监控大盘可能分散在不同的系统中，或者有不同的链接入口，故障应急平台就集成了故障定位的能力。整合所有的监控大盘信息，包括变更信息，以及故障发生时的错误指标下钻。基于这些信息，来做故障的定界和根因定位。3）快速恢复预案对于变更类故障，提供快速回滚链接。如果定界分析故障集中在某个可用区，提供多活切流预案。对于业务自身的故障，无论是变更类还是架构类的问题，还可以提供业务降级预案。我们在定义故障时，会明确故障的场景，也就能针对性编排对应的故障预案。我们将这些常见的预案集成到故障平台中，实现一键执行，确保故障三板斧——回滚、切流和降级——能够被有效且快速的执行。3.3.5. 实践效果以上故障摸排与应急快恢的更详细的落地经过，可查看往期分享：《B站故障应急与业务1-5-10摸排：如何实现超95%故障自发现率？》在业务层面，我们对推荐、搜索、商业、游戏和社区等核心体验业务进行了全面的摸排。在监控层面，我们增加了100+与故障相关的监控指标，特别针对一些技术栈，比如C++，我们推动了可观测性标准框架的实现。故障发现率方面，已经定义了大约200个故障场景，通过平台定义的故障准确率达到了70%到80%，在一些核心用户体验类的故障中，通过客诉反馈、服务等级目标（SLO）和业务指标的综合分析，故障自动发现率可以达到80%以上。在应急响应方面，我们通过与客服系统的打通，将故障响应时间从原来的30分钟优化到了1分钟左右，一旦检测到服务的可用性SLO下降，从指标检测到故障触发，再到拉起应急响应群，整个过程可以在2分钟左右完成。对于预案的执行，我们统计了推荐、社区核心业务的情况，发现预案执行的有效性达到了80%以上。主要的预案包括多活切流、业务降级和回滚，这三种预案对于快速恢复业务至关重要。3.4 从故障到风险随着故障的收敛，我们开始更多地关注故障前的风险和隐患。正如大家所熟知的海恩法则，每一个故障背后都隐藏着大量未被解决的风险，这些风险如果得不到妥善处理，最终可能会演变成线上故障。3.4.1 风险分类我们对风险进行了分类，以便更有效地识别和管理。提到风险大家可能首先会想到告警，SRE每天可能会收到成千上万条告警，告警并不是一定要跟进的风险，如，服务的CPU抖动或容量不足，并不需要立即处理，甚至可以自恢复。那怎么识别和管理要关注的风险呢？我们将风险分为动态风险和静态风险两大类。动态风险，通常对应于告警，其特点是这类风险具有自恢复的可能性，它们并不总是需要人工干预就能得到解决。相对而言，静态风险则更为严重，它们是不可自恢复的，通常是系统架构或配置的长期问题，需要通过系统性的改进来解决。通过这种分类，我们能够更精确地定位和响应真正的风险，从而提高我们的风险管理效率和系统的整体稳定性。3.4.2 风险发现与治理运营3.4.2.1 动态风险动态风险只关注SLO告警，分为服务SLO和组件SLO。对于服务SLO，我们设定了可用率的目标，比如四个九（99.99%），如果服务的可用率以一定的错误预算消耗率下跌到两个九（99%），就会触发SLO告警。SLO告警一旦被触发，无论背后的原因是什么，服务可用率一定下跌，一定代表服务出现了不可用的异常，SRE需要跟研发一起关注和分析这个风险，改进优化。组件SLO的告警则更侧重于中间件本身的异常触发和分析优化。除了SLO告警，我们基本不会将其他基于原因的告警视为风险跟进。例如，CPU的抖动、单容器故障、磁盘容量等，而是通过离线报表或巡检来进行运营跟进。对于动态风险，我们的目标是追踪SLO告警的原因和技改优化。SLO告警触发时会触发事件单，并通过与研发团队的对接群推送告警信息，事件单支持风险的协同处理。这样，告警可以被接手并完结，提供原因说明，实现全透明的流转。如果SLO下降到某个程度，还会直接触发故障应急群，从而得到更高优先级的响应。目前，SLO的实践已经覆盖了我们所有的业务团队，微服务的覆盖率达到了95%。每天，我们能够通过SLO告警召回大约20个服务的SLO风险，告警有效率达到90%以上，有效预防了线上事故的发生。3.4.2.2 静态风险静态风险主要是架构改进类的风险，这种风险不可自恢复，是一个技改任务流。例如，故障待办、架构改进、组件优化等，如果不进行改进，这些风险永远存在，不会自动消失。对于静态风险，主要通过专项治理和运营来推动改进优化。在治理上，也分为多种专项，如多活风险专项，SDK升级专项，proxy升级专项等。跟进方式上也比较多样，比如群沟通，或者是每日给研发做推送，或者是通过一些管理手段升级等；运营方式上，比如有在线文档，日报，报表等等。目前，我们正在开发一个风险治理中心，目标是整合目前分散的专项治理和运营方式。该中心将统一所有风险的上报、定义、流转和运营工作，提供一个集中的平台来管理风险，统一管理故障待办、任务流转、数据统一运营、统一报表分析等。四、B站如何提升安全生产意识？在技术层面的工作接近完成之后，我们转向了提升安全生产意识的阶段。这是一个至关重要的环节，因为意识层面的问题是始终存在的。安全生产意识上我们经常会遇到一些挑战，例如，有些人员可能不愿意执行审批或灰度发布，他们认为自己服务的等级较低，不涉及风险；触发生产事故的员工并非有意为之，作为SRE团队，在跨部门定责追责时也非常困难。业务团队会觉得业务优先，稳定性是基架和SRE的事情，不做技改规划或投入度很低等等。4.1 制度&红线为了解决这些问题，我们出台了一系列制度和红线。安全变更门禁制度明确了变更管理的规范，包括何时可以进行变更，变更审批方式，变更的豁免方式等等。系统变更管理规范强调在服务变更时可观测性和灰度发布的重要性。不同的服务等级需要有不同的观测时间和分批次发布的策略和可用区覆盖顺序。4.2 组织要求与责任尽管我们制定了详尽的安全生产规章制度，但在实际执行中发现效果并不理想。我们有一个技术委员会来制定这些标准，然后由SRE团队负责执行。然而，我们发现不同部门对这些制度的遵守程度不一，有的部门甚至没有稳定性负责人，或者他们对稳定性的重视不够。这导致了安全生产的规范制度难以在内部得到有效执行和追责。为了解决这个问题，我们成立了安全生产委员会，由SRE和各业务团队的稳定性负责人组成。安全生产委员会的核心任务是制定全局的稳定性决策规则，推动应急协同文化和安全生产文化，以及进行全局的管控系统规划和管理。4.3 文化宣传在文化宣传方面，我们采取了多种措施。比如在技术团队的工作区域贴海报，电梯口放置易拉宝，个人消息推送等方式来宣传安全生产的重要性。我们还上线了安全生产考试答题，新人只有达到100分通过考试后才能开始变更。此外，我们鼓励安全生产方向的内部分享和外部技术交流。在每半年的技术总结会议上，还会评选出在技术稳定性方面表现优异的团队，给予奖励。写在最后安全生产是一个需要全员参与的庞大议题。它不仅需要SRE、业务研发、运营同学、测试同学等每个人的共同努力，还需要专门的组织来推动。安全生产不是靠一个人或一个平台就能做好的，它需要我们在组织、意识、技术、架构等各个方向上共同努力，以确保我们的服务既稳定又安全。（全文完）Q&A:1、对于多中心多活架构，B站是采用对称双活，还是非对称双活，还是其他？该架构设计对应急处置有什么优势2、对于改进型的项目如何提升IT系统故障发现能力，需要重点做哪些工作？听听老师建议3、风险多巡检专项这里，能否讲一下更多关于这块的细节？包括哪些检查、巡检的逻辑和规则设计这些 (在风险发现和治理运营这页)以上问题答案，欢迎点击“阅读全文”，观看完整版解答！！！重要通知！！如果你在某个稳定性领域有深入研究和实践，或者是技术团队的管理人员。欢迎加入TakinTalks稳定性社区专家团，以演讲、文章、视频等形式传播你的最佳实践和经验。有意可联系社区工作人员18958048075（乔伊，微信同号），可免费获取社区赠书。2023下半年合集：15万字稳定性提升经验：《2023下半年最佳实践合集》限量申领！2023上半年合集：10万字干货：《数字业务连续性提升最佳实践》免费领取｜TakinTalks社区社区讲师课件合集：凭朋友圈转发截图免费课件资料并免费加入「TakinTalks读者交流群」添加助理小姐姐声明：本文由公众号「TakinTalks稳定性社区」联合社区专家共同撰写，如需转载，请后台回复“转载”获得授权。更多故障治理内容「好文推荐」美图是如何搭建压测监控一体化平台的？故障复盘后的告警如何加出效果？去哪儿是如何做到大规模故障演练的？美图SRE:一次线上大事故，我悟出了故障治理的3步9招破坏系统是为了更稳定？混沌工程在去哪儿的4个阶段实践监控告警怎么搭建比较合理？点击【阅读原文】直达TakinTalks稳定性社区，获取更多实战资料！