👉腾小云导读
本文主要是搜索在稳定性 MTTD（平均故障检测时间）、MTTR（平均响应时间）优化一个量级，尤其在重大事故层次形成一个较强控制力。内容全面且实践性较强，团队的每项能力定 位也比较清晰，除了核心的容灾、发现、应急建设，还在前置拦截、自动防御，风险扫盲等维度进行全方位治理。欢迎阅读~
👉 目 录
1 可用性架构体系
2 容灾-高可用的磐石
3 发现-化繁为简的艺术
突然被告知发生了一个事故，对稳定性同学而言这是无比尴尬的事情。腾讯搜索在治理之前就是这样的状态，看不到问题，事故在悄悄酝酿；问题不能上浮，被低效应对；影响面在扩大，却无招可用。从而，我们开始整理稳定性技术债，思考建设一个怎样的稳定性体系，并付诸实践，在短期内达成高可用目标。
搜索的稳定性建设是比较全面的，覆盖了几乎所有环节，并从这些环节抓主放次，围绕业务事故控制去建设、强化、完善各类能力。
每个业务欲要达成高可用目标，必须具备一些保命手段，能够在紧急情况下将风险拉回可控范围内，这就是容灾能力的核心定位：止损。尤其是黑盒式 （不需要知道什么原因引入） 的容灾手段，便于我们掌握主动，控制住进一步的恶化和损失。这些手段，可能无损，可能有损，作为一种速效手段，能够为我们争取更大半径的应对空间。搜索针对涉及事故定级的十多个业务都有这种能力布控，根据业务的差异容灾能力也会有差异，我们抽离出一些核心的，主要如下： 2 .1 冗余架构 多地、多活、多实例，作为分布式理念，无论是服务、数据还是专线都应有这样的冗余设计。下面两点是搜索稳定性在实操时对执行短板的优化。 2 .1.1 异地多活
在索引的离线制作上，我们梳理所有的单机房环节和跨专线问题，对阻塞点和高风险环节输出治理方案和容灾方案，避免单机房异常或者单专线异常引发全业务异常。如离线时效性通路治理，增加抓取后的处理服务多活和 kafka 容灾能力，彻底解决因专线、服务或者 kafka 异常引发的全断流问题，并建立起切流和兜底策略的容灾能力。 2 .1.2 同地多实例 对于一些资源消耗比较小的服务，如 proxy、中转服务等，有的时候为了成本控制更容易忽略节点可用率问题，异常服务的流量会打到还存活的服务节点上，从而将还存活的服务打垮产生雪崩效应。并且这种服务大多属于阻塞节点，一旦异常可能导致整条链路断掉。如服务 A 在 gz 机房仅有两个节点 A1、A2，其在服务变更过程中会存在两个风险：
· 123的分批发布过程中，这两台可能都在一个批次里，会造成 gz 在这个时间段断流；· A1 在发布的时候，其流量会打到唯一能够服务的 A2 上，如果 A2 的冗余buff不足，会将 A2 打垮。
针对这种情况，搜索对这种低消耗服务做一次梳理，将服务的资源配额调低 （如 cpu8 核调为4核） ，同时扩容到一定可用率保障数量。 2 .2 三板斧 三板斧 （切流、降级、容灾缓存） 是大搜重点建设的核心预案，覆盖绝大多数的故障止损，都是分钟级的生效速度。其中，切流是一种黑盒且无损的容灾能力，确定业务受损后的首选且可以第一时间操作的能力；降级是一种自我屏蔽和去负重手段，以此来切断问题源或者释放更多资源来提升系统压力；容灾缓存是一种系统兜底手段，在系统完全不可用的时候仍可以保证一定比例的用户体验。 2 .2.1 切流 搜索链路复杂，业务也复杂，无法从一处建立切流能力来覆盖所有场景，我们从链路走向和业务分布，建立四类切流能力。
域名粒度的切流能力，可以全切也可以按省份将一个域名某机房的流量切至其他机房。这种切流更灵活，更易操作，但是因为域名会有缓存，其全部生效时间会有5分钟。
服务粒度的切流能力，将大搜某一个机房的流量按照 nginx 粒度切至其他机房，会覆盖所有域名进入得流量。相比于 DNS 切流，其生效更快 （1分钟生效） ，操作粒度更大 （所有这个机房的流量都会被切走） 。
大搜融合了搜狗的检索系统和 kd 的搜索中台。因为历史原因，搜狗侧服务大多部署在物理机上，并且具备一定的冗余，而 kd 侧部署在123，因成本控制冗余不足。所以，如果大搜从上游切流，kd 侧的流量也会随之变动 （非绝对，仅部分域名的流量会下发到kd侧） ，但 kd 冗余不足，就需要在 kd 侧把这部分流量切回去，这是在这个支路建立切流的原因之一。另一个原因，kd 侧是独立的支路和系统，其本身也需要一个切流能力。 搜索除了大搜，还有增长、推荐类等服务，并且很多都是独立的系统和入口，这些大多是没有 nginx 的，走的是 trpc +北极星+123，我们使用北极星的规则路由插件建立基于主被调的切流能力 （基于比例的切流） ，来满足这些业务场景的需求。 2 .2.2 降级 大搜应该建设成什么样的降级能力，是建设成 L4 级的自动感知决策及动态化指令，还是建设成 L2 级的人工感知决策及平台化能力，前者需要超高的成本和精准决策力，后者具备超强的灵活性和干预力。搜索对降级的核心定位是：超强的干预止损能力，且零风险额外引入。基于 ROI 和较高可用性定位，我们选择 L2 级的方案能力。
上图为降级执行流程示意图，人工在降级平台操作降级指令，大搜会把这些指令一路下传，各个降级点会解析这些指令信息从判断是否要执行某一降级项。在决策辅助上，我们单独建设一个稳定性 server 服务来采集和输出降级告警信息，其中图中红标1处是降级决策指标，是否要操作降级；红标2处是中台侧辅助指标，是否要操作中台支路的降级能力；红标3处是搜狗侧辅助指标，是否要操作检索架构的降级能力。 // 指令协议 1 key = value 形式的string ，其中key为xxDegrade；value 为各指令的组合字符串；2 一个指令最多有三级参数3 各指令之间用英文|分割4 指令的二级参数用英文:指定 5 若指令的二级参数有多个，之间用&分隔6 若指令有三级参数，之间用#连接 // 指令名称 // 实例1（一级指令和二级指令组合） 1 &2 &3 |kdXX:15 // 实例2（三级指令） #1000&XX#300
· 摘服务：摘除异常数据源节点或者支路等，保障核心能力不影响；
· 缩召回：摘库、截断、降低透传批次、丢掉异常 Source 等，提升系统整体抗压性；
· 降算力：熔断重计算服务、启用重计算服务兜底策略等，降低单请求的消耗，提升系统容灾力；
· 调超时：各个数据源超时控制，防止某一节点异常拉长整个链路的耗时。
降级能力完善后，我们启动平台建设，输出一个统一入口和权限管控，其核心收益为：
安全操作 ：人员管控、指令选择，避免人为操作引入新问题； 效能提升 ：一键化的能力、默认指令组合，在问题时能够迅速完成止损动作； 增强赋能 ：除了降级，我们还在平台上打通了实验应急，可一键暂停全部或者最近 n 时间内的实验，来迅速关停未知实验引入的风险。除此之外，我们还在计算增加低质流量和灵犀卡的应急能力。
2 .2.3 容灾缓存 按照腾讯 PCG 的事故定级规范，较短时间的系统不可用就会成为一个事故，而这个时间留给止损的 buffer （N 分钟） 是很具挑战的，为了给稳定性治理提升更大的应对半径，我们设计了一种更大粒度的容灾方案：容灾缓存。大搜的容灾缓存采用的是一种冷备方案，作为最后的容灾手段启动，来应对极端情况下的系统不可用。 新建容灾模块 SearchGuard，负责缓存的读写。写入口在前端模块 node，在系统正常下会一直写，系统开启容灾缓存是关闭写入；读逻辑在业务 nginx 侧控制，在开关开启的情况下访问容灾缓存服务，如果拿到结果就返回，读取结果空就继续访问大搜下游。 我们单从事故影响这个维度来看，容灾缓存在事故定级层面带来的影响有下面两个：
· 容灾缓存启用下，用户非100%受影响，业务的定级维度就从“服务不可用指数”降为“服务水平下降指数”统计，后者的指数范围比前者更大。换句话说，就是相同指数值下，后者的服务影响时间要求更宽松：五级的影响时间范围延长2倍，四级和三级的延长1倍。· 服务水平下降指数的统计方式为：用户影响面*时长=指数，在相同指数情况下，假如容灾下用户影响面为 n，相比于原100%的用户影响面，为我们增加了1 / n -1的时间应急（如果影响面有50%，那就是在上面的时间增加基础上又增加了一倍的应急时间） 。
2 .3 流控方案 2 .3.1 限流
· 大搜的 anti 服务框架及北极星路由支持对个别 ip 进行封禁，也可对每个 ip 进行流量控制。
2 .3.2 关实验 实验中 interleaving 和 rankab 都会对后端增加实验组100%的流量，在实验集中时这部分流量是相当大的，在流量超负载情况下可以考虑将实验暂停来缓解系统压力。 2 .3.3 热词打散 搜索的 SR 和 SH 服务都是本地缓存，分环时根据 query 来分，也就是每个节点是有状态的，SH 自身拥有降级措施，可以利用快速返回有效解决热词 Query 的问题，但当 QPS 很高 （如10倍涨幅） 的情况下，SH 会出现 GC 卡顿崩溃的现象。如出现全网关注的新闻事件，同一关键词的流量打垮单台。长线方案是优化 SR 和 SH 架构，短线方案我们输出一种容灾能力，以干预的方式将超高关键词打散。 2 .4 柔性策略 当拿不到原始想要的结果和算力时，可以换种替代方式来达到稍次的效果。如本地的 kv 数据或缓存结果来替换远程的结果，本地简化的排序能力来替换复杂或者远程大模型算力等等。 2 .5 定期演习 容灾预案要想达到预期的效果，首先效果是需要验证的，符合预期并且不会引入新风险；其次用的时候要保证能力是存活的，不被常规的迭代磨灭掉；最后要熟练操作，越快操作越好。所以定期演习是必须的，搜索是月度演习 （每月一次） ：
· 不断储备人力，每次都是不同的同学操作，熟练能力、储备操作人员。
发现要能及时且精准地捕捉到问题，并以有效的告警途径通报给正确的接收人。一个简单的有效监控项，要做到及时、精准、通报途径有效、接收人正确，却并不简单。更残酷的现实是搜索的监控项不止一条，有些同学仅每天接收到的告警量就能达到万级。如此大的监控工程，却不能达到预期效果，反而给开发增加更多困惑和负担：监控太多了，不知道监控的啥；告警太多了，不知道跟哪个；误报太多了，对监控失去信任；故障回顾时，发现监控没覆盖或者告警没接收到。 搜索从三个维度去优化：注重用户感知、注重业务输出、注重告警投放，并以层化的方式建立黑盒指标、业务指标、功能指标、统计指标、工程指标、基础设施指标六大类核心监控，成功将 MTTD 降低一个量级之多。 3.1 黑盒指标
KPI 黑盒告警是大搜最重要的一个监控项，它以探针机的方式对搜索系统持续打词 （穿透缓存） ，对状态码为 5XX 的打词结果就会形成 KPI 电话告警，并自动封禁 CD 平台的所有变更动作，直到系统恢复。这个指标直观体现了大搜是否有恙，是切流决策的一个重要依据。 3.2 业务指标 站在业务的角度，监控首先要关注的是业务的核心输出是什么，比如 sug 是否出词、热搜榜的结果数、灵犀的展卡率、大搜的有结果率等。这类指标不需要太多，一个业务一两个就足够，它能精准反馈业务是否还在正常提供服务，所以这个指标的优先级是阻塞性的，一旦告警都要第一时间介入，所以也是事故防范的一个核心指标。 3.3 功能指标 功能指标是以仿真用户的角度来 check 端的操作效果及返回的结果是否符合预期。相比业务指标，功能指标更加细化、更加直接、更加贴近用户体验。搜索对所有涉及事故定级业务都有功能指标覆盖 goodcase，核心分为两类：
交互类 case ：仿真用户实际操作，来 check 每一个 step 的界面效果是否 OK，如是否可点击、是否成功跳转、是否出结果展示等。真正意义上做到了从用户入口来监控。非交互类 case ：以后端的方式获取结果并解析结果，来发现一些更细微的问题，如是否死链、是否出摘要、是否飘红、是否展卡等。
· 搜索是以卡的方式来展示各类结果的，功能 case 能够做到卡粒度的监控，其灵活性和覆盖力都很强大；· 对于没有后端的业务一样可以覆盖，如起始页历史（仅用户终端存储和读取） ；
3.4 统计指标 统计指标是基于用户行为的监控，如 pv、uv、点击、曝光、收入等，这些会直观体现系统的变化；也如用户反馈 case 量的变化，这也是事故定级规范中的一个定级维度，单位时间用户反馈量突增一定代表系统某方面的表现存在重大异常并让用户不满意；也如终端可达性监控，对各类终端在各个省份、各个运营渠道成功率、pv 的变化实时监控，也做到了终端层面的监控等。统计指标应关注时延，时延较差的指标其告警意义就较弱。 3.5 工程指标 上面的指标都是以用户的维度，在系统外去监视服务，工程指标是深入系统内，在服务的关键调用链上去建立核心监控，是一种服务粒度的监控。搜索在工程指标建立和监控上注重如下几个事项：
· 梳理核心节点和阻塞点，每一处关键位置都应该有监控覆盖，如离线输出节点、kd 支路输出节点、灵犀结果汇总节点处等；· 注重质量指标，如成功率、有结果率等，这类指标都建立对应的 oncall；· 非质量指标监控应放大范围告警范围、设立双重降噪，更加关注系统大的波动；如 SR 耗时告警不仅容忍更大波动范围、延迟3分钟报警，还通过前后时间及同比时间波动来消除预期内的波动，来减少告警量，聚焦真正的服务异常。
3.6 基础设施指标 除了关注系统本身引入的异常外，还需要关注基础设施异常带来的影响，这在平时 case 的贡献占比也不小，也是容易忽略的一个监控点。核心关注事项有各个域名流量、延迟、丢包率，带宽，防火墙，CDN，DNS 等。 3.7 总述
· · 涉及影响用户直接体验和服务可用性的指标都尽量建设电话报警能力，并且投放企微大群，和应急机制联动起来；· 所有涉及事故规范定级的维度和业务都要有监控覆盖，只有这样才能保证每一个故障都能及时发现，杜绝监控盲点。
在发现和容灾之间应该有一个纽带，能够迅速决策操作哪类容灾能力并迅速执行起来，这就是应急框架的核心意义。如果所有的容灾能力都是自动触发的，那么应急的重要性就不会这么高，如果不是，这个能力是必须要建设的。MTTR 可以拆分为三部分：从发现到介入的时间、从介入到开始执行止损动作的时间、止损操作后到系统恢复的时间。其中第三部分可以理解是容灾生效时间，因为容灾能力基本都是速效手段，这类时间基本可控。那么，核心需要优化的时间就是前面两部分，也就是上图中方框内的时间。 搜索的应急框架尽量简化流程、理解和决策成本，稳定性会定义一些基本管理要素和建设一些快速动作来辅助应急框架的自发执行，目前搜索遇到紧急故障都是大群一键快速会议，少量的一些同学就能迅速介入并执行容灾预案。 4.1 管理要素 角色分类 负责内容 响应组 （大本营） 企微大群，通报接收和值周群 作战室 （阵地） 在线会议，任何人都可以拉起 指挥者 （老板） 故障总控负责人，掌控应急节奏 （值周人、业务 leader 或接口人、第一发现人、稳定性同学顺位） 操作者 容灾能力操作人、故障定位人 决策者 默认在场最高级别人员
4.2 原则和要求 · 第一时间止损和恢复 （切流、实验应急、摘服务是首批考虑能力）；
4.3 应急流程 在这个环节里，搜索稳定性重点打造五个提速动作：通报快、介入快、止损快、决策快、恢复快。 提速动作 具体流程 通报快 目前搜索建设的一些核心发现能力都是自动的投放到企微大群里，省去了通报这个动作 介入快 顺位的指挥者共识、一键阵地拉起、核心人员电话表，保障了快速启动和快速进入 止 损快 各类速效手段的容灾能力建设，并形成平台化输出，交棒 SRE 决策和执行，保障了操作无障碍 决策快 最高级别人员决策或 SRE 自发决策，以及积累的止损黄金法则（第一时间切流），保障了决策无障碍 恢复快 建设各类定位能力、快速回滚能力、优化服务启动速度、实验应急等，来提效服务恢复到故障前状态
在回顾历史 case 时，统计发现90%的 case 可以在发布初期乃至测试阶段被拦截住。搜索在稳定性建设初期就考虑往拦截这块使劲，核心动作如下： 5.1 分级 分级是拦截的核心，其提供一个缓步空间让从 offline 溢进变更阶段的 case 尽早暴露，并能够将其影响控制在可控范围内。 5.1.1 预发布 无真实用户流量的线上环境，真正意义上发布前的最后一道验证和拦截渠道。
5.1.2 CD 分级 预发布–>单台–>各机房单台–>单机房–>剩余全机房 在dfly变更平台，建立严格的分级机制，所有接入的代码、数据、配置都执行分级流程。在腾讯123变更平台，因微服务模式，服务较多，我们梳理搜索在123的关键路径节点，统一推动接入 XAC （一种 pipeline 模式的变更机制） ，替换123的分批发布模式。 5.1.3 沙盒环境 沙盒环境部署–>数据沙盒环境 dfly 流水线校验 （冒烟用例） –> dfly 上线正式环境 5.2 校验 分级缩小了暴露 case 的影响范围，校验可以及时地发现暴露的问题。校验不仅能提升分级的效果，如果自动化做的好，还可以一定程度解决分级带来的上线效率问题。搜索的核心校验点有这几处：
· 每个分级 level 的 checklist，需要上线者去一一确认； · 单机房分级完成后接入 goodcase 校验，提前发现功能性问题；· 天象平台在实验生效之前接入 goodcase 校验，确认实验逻辑是否有风险；· 热载数据正式发布前接入沙盒冒烟测试，提早发现数据引入的问题。
5.3 质量红线和卡点 offline 是拦截问题的先锋和大头，规范而强大的测试力是有力保障。在测试左移的趋势下，保持住原有测试力水平，提高自动化程度，提升执行度和执行效果，是搜索线下拦截的重大挑战。
· 梳理各个模块的流水线和核心测试力，输出全自动化的流水线； · 对各个测试项划立红线，推动各模块去建设；如强制 CR|MR、强制增量单测 n%、强制 diff-verify 验证等； · 建设卡点，任何变更必须运行流水线，并且必须跑通才能发布。
5.4 流程和规范 搜索很早就发布了上线变更流程与运维规范，并将很多事项落地到自动化实现，如 dfly 和 xac 分级、自动校验、上线单推进、发布时间约束、case 采集和复盘等等。 一个好的系统和架构设计，本身也需要具备一定的健壮性和容灾力，常规的一些代码习惯、鲁棒性和异常处理这里不细讲，重点讲架构设计层次的优化和一些自动防御能力建设。 6.1 架构优化 6.1.1 计算和缓存分离 在2.3流控方案里，给出了热词问题的短线方案，这里是长线方案。 SR 是有状态服务，其必须与 memdb 服务按照1:1的实例数部署，计算与存储紧密耦合，如果热词流量打散到其他实例，会丢失该实例的缓存数据。优化方案是改造 SR 为无状态服务，将计算和存储解耦合，存储改造为旁路模式，实例间共享。
6.1.2 上线/回滚耗时优化 在 SH 服务启动上，分析启动耗时点，优化数据加载依赖关系和并行化、优化预热效果和条目量、优化无用的大数据问题等，整体启动时间优化点40+%，大幅度提升启动效率。同时调整分级过程中每个批次的机器量，并建立快速回滚通道，在保障安全的基础上，加速回滚速度。 6.1.3 请求队列 在中台支路的上游建立请求 hash 和请求队列，短时间内相同请求的结果复用，彻底解决 qu 因为历史原因引入的 diff 问题 （结果不一致） 。qu 会输出请求解析内容，并一路带下去，如果 qu 有 diff，整条链路都会产生 diff。请求队列的形式很好地将 qu 的 diff 从外层闭合掉，保证相同请求下游下发的 qu 内容一致。 6.1.4 分布式缓存 对于一些高请求量服务、阻塞点服务，在其上游建立分布式缓存是一种不错的方式，既能缓解下游压力，同时也能在下游异常时继续提供一定的服务能力。 6.2 自动防御 6.2.1 自动降级 除了大降级容灾能力，搜索系统本身也建立了很多具备自动决策力的降级能力，这些一般是 query 粒度，具备更强的反应力。 · 排序服务 建立针对 qps 的自动限流能力，针对 tm 的兜底能力（超指标不再请求gpu，启用本地算力） ；· 控制服务建立压力控制器，控制下游的分片成功率，丢弃的分片会发 cancel 请求释放被丢弃请求； · 召回服务支持排队等待过长请求会丢弃或者降低检索域；
6.2.2 自动熔断 在链路上游模块 SH 增加单机熔断限流器设计，对于网络不可用情况、连续 N 个请求错误情况、时间窗口 T 内错误率较高情况启动熔断策略。为了保护未熔断的正常实例不被流量打垮，增加限流保护，超过一定熔断比例后，启动限流，限流比例为 ，限流在无故障时单台压力水位附近。 这一章重点讲述 where 的问题，痛点在哪、风险在哪、问题在哪。通过这些多视角地分析，既能找到可用性建设的方向，也能让我们对系统可用性程度有一个全面且清晰的认知，有效提升我们对重大事件或者故障处理时的应对力。 7.1 自省视角 case 复盘是一个重要的被动治理手段。每一个线上问题发生，一定会暴露出整个流程中某些问题。就单个 case 而言，问题共性抽离，可能解决多个潜在问题；多个 case 问题汇总、统计、分析，就可以看到系统各个环节薄弱程度，从而有针对性去治理。 7.1.1 case 采集机制 建立自动化或半自动化登记入口，尽可能将多地线上问题收集起来，汇总到一个case 池子里。 · 问题上浮，复杂系统深链路的业务尤其重要，面对不熟悉的业务部分，只要有足够的 case，就可以分析其薄弱处；· case 分析，设计、测试、发布、流程、规范、架构、运维、应急、定位、容灾等等，任何一个能杜绝这个 case 发生或者减小影响的环节都是一个优化选择。case 量足够丰富的时候，这些优化选择的优先级就可以排位了；· 统计分析，采集时丰富采集内容，可以阶段性地check治理效果，调整治理方向。
// 采集字段信息 case 材料 责任人（必填） 责任人归属组（必填） 责任人归属总监（必填） 是否部署拦截方案 是否自动化漏测 是否纳入MTTD&MTTR考核（必填） MTTD MTTR 介入延迟 止损延时 恢复延迟 违反流程规范 填写时间（自动） 7.1.2 CS （casestudy） 机制 搜索采取定期复盘机制，每周都有一个固定时间的复盘会，需要 cs 的 case 就近加入。稳定性提供 case 材料模板及材料要求、复盘重要原则及参与人要求、 case 规避措施及责任人要求等。 cs 机制一定要坚持执行，不仅可以持续完善系统，还可以成员强化稳定性意识。 7.1.3 FL （follow） 机制 cs 的规避措施可以划分优先级，不同的优先级不同的时间限制，每条措施建立对应的 tapd 跟踪，并将进度定期通报到责任人及大群，同时每周的回顾里也会贴上措施闭合率。 7.1.4 统计分析 根据 case 池子，除了可以分析一些暴露的系统薄弱环节问题，还可以基于一些统计信息定期分析如 MTTD、MTTR、拦截率、漏测率等核心指标变化，跟踪稳定性治理效果。 7.2 蓝军视角 除了常规的混沌工程、容灾演练，搜索提出“危机六问”模型，作为事故和危机管理的核心，从繁琐的监控和治理体系中抽离出来，聚焦核心业务，关注核心输出，从事故规范定义中倒推出“事故控制应该把核心焦点放在什么位置？”。其本质是一个效率问题，便于我们高效地解决“看到”、“控制”、“恢复”三个层次的问题。搜索以此模型来评估各个业务在事故防范中的治理水平，挖掘治理漏洞，并推动优化治理。 能看到问题这是治理的基础。业务应该在业务指标、功能指标、统计指标、工程指标各个维度都有核心覆盖（参考第三章） ，这是主动发现要求，覆盖每个核心输出。其次，发现时延必须在5分钟内，每个核心发现能力告警都要通报到大群里，和应急联动起来。 故障发生时，需要一个或者多个角度去衡量和评估故障的影响具体是什么，这些角度应该能直接反映到用户体验，是用户体验下降的一种量化。这种量化在事中可以提供应急决策帮助、在事后可以提供故障定级支持。在量化具备一定准确度后可以指导我们的治理工作提升到自动决策和容灾层次，导向一个更加效率的方向。 核心是各类容灾能力建设，面对基础设施异常、服务挂机、流量激增、功能异常等等各个情况覆盖。 找到源头，是解决问题的第一步。问题会层层蔓延到业务顶层输出，最初出现问题的节点是关键，要尽快找到这个节点。通过看板、通过监控、通过可观测渠道等，尽快找到源头，有效降级 mttr。 问题不会无缘无故发生，总会存在一个“变量”致使问题触发，找到了这个“变量”，就回答了“是什么问题？”。这个变量就是诱因，如变更（数据、配置、程序等） 、实验、流量、干预、特征、网络、dns、带宽等。 找到问题诱因后，就可以针对性去解决这个问题。凡是操作引入的，大多是逆操作，如变更引入的就回滚变更操作；外因引入的，较难处理，可能需要一些预案能力来辅助。还有一点需要特别注意，无论哪样地解决手段，都要快，因为这个时间的系统，要么是有损的，要么是不稳定的（如已切流情况下，难以承担二次类似问题发生） 。
7.3 链路视角 系统异常大多出在系统的某一节点上，多梳理、思考如何在主要链路上做文章，如果有效规避主要链路节点异常带来的风险是重中之重。 7.4 重保视角 每次重要节假日或者重大事件时，稳定性应该有专门的应对预案。如果预案及容灾能力不能够有效覆盖各类情况，这肯定是个大风险，需要提前治理。 稳定性无论从广度还是深度都是很泛的，涉及的人员、角色、大组、部门都很多。如何有效协作，如何共力建设，是搜索在可用性治理中不断摸索的一个方向。 8.1 顶层式治理 搜索在治理初期采取的是稳定性的同学提出治理方案，各个部门出人力的方式。取得了不错的成效，迅速将基础体系建立起来，形成了初步的防治力。但是顶层式治理有明显弊端： · 治理盲点多，如果不能对全系统每一处环节都有足够了解，很难看全所有风险。
8.2 下沉式治理 让距离问题最近的人去治理问题，并提高其治理积极性。搜索在二期治理过程中开始下沉，提出下沉式治理模式，输出三道防护圈机制。各个组出稳定性接口人，并独立制定治理方案，一起承担稳定性目标。 · 稳定性大线条出治理指导、大风险梳理、okr 指标拆解到各个方向和接口人。做事故和危机管理、做整体统筹和监督；· 业务组小线条以接口人和组领导为牵头，做组内的治理；· 模块防护圈以节点为粒度，以老板为牵头，承担各个节点的治理工作。
稳定性建设的每一个环节，都应该积极往自动化方向转化。多做机制、工具、平台，以自动的方式去串联一些环节、流程，减少人为因素参与。如搜索建设大量监控 oncall、告警自动投放、监控看板、上线墙、搜狗白盒监控投放伽利略、容灾平台、全自动化流水线、goodcase 按模板自动生成机制等。 以上是腾讯搜索在稳定性治理中核心实践方向，在聚焦可用性及事故控制上，也在不断地去偿还一些稳定性技术债，来健全整体的防御力，所以上面的内容会覆盖到各个环节。在基本技术债理清之后，稳定性应聚焦在容灾力、工具、架构优化建设，不同的业务场景和可用性定位就会有不同的治理方案，无论是哪种，选择合适的，才是最有效的 。 整篇文章分享到这里就结束啦！各位开发者在做项目的同时，也不要忘了定期地去检查、清理技术债务。让项目流畅稳定地运行，这样工作下来也能事半功倍。 你对技术债有什么看法？在工作中如何避免技术债的堆积？欢迎在评论区讨论。我们将选取1则最有创意的评论，送出 腾讯云开发者-鼠标垫 1个（见下图）。6月15日中午12点开奖。
本篇文章来源于微信公众号：腾讯云开发者
本文来自投稿，不代表TakinTalks稳定性技术交流平台立场，如若转载，请联系原作者。
微信扫一扫