SRE实战：如何低成本推进风险治理？稳定性与架构优化的3个策略

一分钟精华速览

SRE 团队每天面临着不可控的各类风险和重复发生的琐事，故障时疲于奔命忙于救火。作为技术管理者，你一直担心这些琐事会像滚雪球一样，越来越多地、无止尽地消耗你的团队，进而思考如何系统性地枚举、掌控这些风险？怎么能更低成本地推进风险治理？

本文根据多家企业 SRE 实战总结，重点分享稳定性和架构优化的核心策略。实践已经验证，多且散的风险是可以被低成本解决的。 file

作者介绍

file

数列科技联合创始人、CTO——陆学慧

TakinTalks 稳定性社区发起人。参编《信息系统稳定性保障能力建设指南 1.0》和《稳定性保障服务商能力要求》。2017 年联合创立数列科技，专注于高可用性领域，为企业提供稳定性解决方案，帮助快速稳定地应对技术挑战。

温馨提醒：本文约 5000 字，预计花费 9 分钟阅读。

「TakinTalks 稳定性社区」公众号后台回复 “交流” 进入读者交流群；回复“0926”获取课件资料；

背景

最近一两年，我和很多公司的 SRE 团队进行了交流，发现大家日常都在面临一些故障处理、应急、琐事等等之类的难题。总的来说，就是团队能力和掌控系统风险之间存在一些差距。

其实，系统和人一样会出现健康问题，这是不可避免的。很简单的比方，我们很难通过一次体检、一次手术，就把身上所有不健康的指标变成正常指标，这是不现实的。从长远来看，我们所有的稳定性和 SRE 工作，其实是在解决系统的整体健康和医疗成本之间的平衡问题。

今天我将主要分享如何系统地解决这些问题，以及稳定性保障和架构优化的核心策略。本次分享将以案例实践为主，我将快速与大家分享我对 SRE 团队所面临的问题和核心策略的理解，也将结合实际案例分析，并深入理解核心策略的具体内容。

一、SRE 团队面临哪些核心问题？

1.1 风险多且散

我个人理解的 SRE 面临的两个最核心的问题，可能和大家在业界常讨论的有些不一样。

SRE 的同学都知道航空界的海恩法则：每一起严重事故的背后，必然有 29 次轻微事故和 300 起未遂先兆以及 1000 起事故隐患。大家听起来觉得都很有道理，但是与很多 SRE 同学交流后发现，实际工作中大家眼睛都盯着故障，故障的发现、故障的应急处理、故障的快恢等等。

那背后的 29 次轻微事故和 300 起未遂先兆以及 1000 起事故隐患，为什么不管呢？因为故障背后的风险太多、太散了。

以一个普通互联网公司为例——

应用多：一般公司应用 200 以上

风险类型多：版本发布、配置变更、局部流量变化、全局流量变化、运行环境变化、架构变化、服务依赖变化、数据库容量、缓存容量等

故障原因散：短中期看故障根因很难总结并以此预防后续故障

所以可以看到故障风险是非常复杂的。比如，一个公司里识别出来的风险数量在 2 万个以上，这些风险发现、解决和管理的成本太高了。而且故障也不是天天发生，发生了应急的成本相对较小，所以目前业界的选择大多数还是以故障应急为主。

1.2 重复发生

对于 SRE 和运维岗位来说，类似的问题重复发生，会占用大量的时间和精力。

以某厂商的订单系统调研数据为例——

客户反馈稳定性问题列表中，重复出现的问题占比 51%

订单异常咨询列表中：

①数据库 SQL 执行超时导致的，1 个月有 182 条

②系统间调用异常未处理导致的，1 个月有 375 条

这其中的琐事特别多，而且会一直重复发生。然而，SRE 同学如果想让这些问题彻底解决，需要涉及多个研发团队。比如，想要彻底解决系统间调用异常处理的问题，就需要协同好几个研发团队，甚至因为一个风险，需要给全公司发邮件要求大家整改，这个执行成本也是非常高的。所以大家大多数会选择把眼下的问题解决掉，至于这个问题在其他应用会不会也存在，SRE 很难考虑，也很难推动。

上述两个痛点都指向同一个问题：公司的稳定性表现和投入在稳定性上的成本是正相关。由于目前风险管理的成本较高，所以大家被迫选择围绕故障来解决问题。但是，从中长期维度来看，比如一年、两年、三年，其实围绕故障去解决问题的成本并不低。

二、稳定性和架构优化有哪些核心策略？

目前我看到绝大多数公司还是围绕故障来开展 SRE 相关工作。那么，在中长期的周期上，如何才能降低整体的成本？这成为一个核心问题。

2.1 三个核心策略

我们实践下来应该在以下三个维度不断深化：采集更丰富的数据、积累更丰富的经验库、从劣化场景不断消化风险。 file

丰富的数据和经验库大大地降低风险的发现、解决和管理的成本，抓住劣化的场景可以尽早逐步消灭风险，降低故障的发生概率。

2.2 经验库

2.2.1 什么是经验库

先解释一下什么是经验库。经验库是用来积累并产品化经验的模块，它有一个核心的特点——察打一体。以性能容量领域的经验库为例，它需要能够做到发现链路的容量瓶颈在哪个节点，这是察；同时，也能确定瓶颈节点的问题原因是什么，这是打。比如，下单接口性能容量不达标时，经验库可以实时诊断出瓶颈点具体在哪个微服务上，而且可以给出直接原因，如：打印太多日志导致的瓶颈、微服务代码中有较大事务导致并发度上不去等等。

file （部分性能相关经验库示例）

2.2.2 经验库繁多但能穷举

经验库需要经过长时间的积累，才能逐步发挥其价值。如图的 SLA 经验库，整个系统中的 SLA 指标非常庞大，有非常丰富的管理维度，也需要从链路到节点的全面覆盖。 file

（SLA 经验库示例）

维度包括：响应时间类、容灾部署类、发布变更类、故障发现类、请求正确率类、服务耦合类、架构隔离类等。

链路和节点全面覆盖包括：链路、应用服务节点、容器节点、物理机节点、数据库节点、缓存类节点、消息类节点、搜索类节点等。

经验库的数量和种类都如此之多，那它可以穷举吗？答案是肯定的。即使没办法做到 100%，哪怕能做到七八成，就已经能够解决很大部分问题了，可以把风险控制的成本和琐事都降下来。

2.3 数据

2.3.1 采集维度需更丰富

提到运维的常用数据，大家往往想到的是 Metrics、Trace 和 Log。而其实想要做好技术风险管理，还需要更丰富、更多种类的数据，才能降低整体的执行成本。

经验库的特点是察打一体，需要具备诊断原因的能力，所以需要的数据维度会更丰富。比如——

MySQL 中一张表的数量超过 2000 万时，普通的 SQL 也会变慢。而且如果大表出现慢 SQL，则会极大影响到整个库的稳定性，所以大表是一个很危险的现象。判断这样的情况，我们就需要用到每个数据库中每张数据表的数据量这样的数据。

配置类数据，正常来说应该使用配置中心或者参数中心管理，但有很多公司的开发，会将配置类数据放在数据库中管理。而配置数据它需要大量频繁地访问，且不太需要变更，所以它放在数据库里其实不合适。它会让整个链路的 RT 响应时间变长，且变得很不稳定。为了发现这种情况，我们需要用到数据库的表结构数据、数据库的行数、数据库某张表的读写比例等等。比如，一个很简单的判断规则，如果这张数据库里的某张表，它的列数不超过 10 ，行数不超过 5000 ，读写比例大于 1000 （即 1000 次读只有 1 次写），满足这一条件的数据，我们就把它归为配置类数据。把这种数据风险扫描出来后，就能通过技术风险管理的手段将其提前消化掉。

2.3.2 重视前期数据建设的投入

我个人的经验是，数据采集的工作和总体成本是不能忽视的。因为在很多公司里，数据采集和打通的工作难度比较大，前期确实需要投入一些建设成本，比如找到一些业务方配合，才可能逐步把数据建立起来。但是后期这种比较丰富的数据带来的效率提升是特别明显的。

在经验库中我们会记录每次经验匹配对数据的要求，从而帮助我们快速识别出缺少的数据。如下图页面所示，红色的部门就是缺少数据的，我们就可以知道还要再去采集哪些类型的数据过来，以让整个经验库更加完善。 file

（经验库示例-红色部分为缺少数据）

2.4 劣化场景

2.4.1 系统劣化的 3 个阶段

我们把系统的稳定性分为三个阶段：劣化、技术债、重构。

设想一个稳定性的系统，因为版本的不断更新，响应时间自然会不断劣化。我们有一个统计数据，即一个月的时间，接口响应时间劣化 10%以上的接口数量占比 25%左右。

随着劣化不断累积，就会在系统内部逐步留下技术债。大家都知道系统哪里有明显不稳定的地方，但是改动起来已经需要一定的成本了，且不是想改就能立马改掉的。这种状态就会导致出现故障的可能性大大增加。

技术债的累积，就会导致稍不注意就发生故障，而且修复成本很高，最终演化为被迫重构系统了。

2.4.2 劣化的 4 个主要场景

劣化一般是由于应用的版本变更、数据量的增加逐步导致，一般包括：接口响应时间劣化、业务容量劣化、业务正确率劣化、部署架构劣化等等。 file

在每次应用发布后，出现劣化现象时，是一个非常好的逐步推动消化技术风险的场景。比如发布后，链路响应时间相较于发布前增加 5%，相较于 1 个月前增加 15%。此时将这样的风险发布出来，推动解决，是一个大家比较容易接受的场景。

三、以上策略落地效果怎么样？

以上是理论层面的分享，那么是否能落地？落地效果如何？接下来我将分享具体客户的应用实践，我们在案例中看看落地数据+经验库和劣化的策略。

3.1 业务背景

这家公司是一家新能源企业，前两年新能源汽车业务迎来爆发式增长，导致系统的稳定性也遇到不小的挑战——故障频发、告警不断。

新能源汽车一般都有一个可以在 APP 上控制车辆的功能，从下图中可以看到，用户每操作 3 次，就会因为各种原因失败 1 次。可以看到系统已经处于高负荷的状态运行，随时可能出现问题——今年春节出行高峰发生了系统崩溃。 file

今年五一高峰是疫情后的第一个小长假，预计出行人数会爆发式增长。然而系统的稳定性面临了很多挑战。比如，MQTT（一个物联网消息系统）连接数不足、数据库容量不足且无法扩容、内部的消息系统经常堆积、网关经常超时等等。从上图的描述中，可以看到技术债已经很多了。

3.2 实施契机

这家企业早些时候已经安装了数据采集的客户端，并且在系统逐渐劣化的过程中已经识别出了很多风险，比如微服务自消耗超时、缓存响应时间超标、网关耗时过长、消息容量不足以及应用机器内存使用率不足等等。

虽然已经意识到了有这么多风险，但之前一直没有下定决心逐步消除它们，也没有找到一个好的机会。考虑到五一出行的重要性，经过多次商议后，我们最终决定启动部署架构优化的项目。

3.3 落地过程

3.3.1 识别--风险库匹配，提取 5 个风险点

这里有几个 SLA 的概念，给大家简单介绍一下：

微服务自耗时：指一个微服务的总耗时，减去调用其他服务的耗时，即只计算自己服务的消耗。一般要包括服务本地的计算逻辑、对数据库、缓存等访问。实际指标的计算是有点复杂的，需要考虑多线程异步调用的情况、回调的情况等等。这个指标是用来衡量单个微服务的响应时间是否劣化的重要指标。

网关自耗时：网关自身的消耗时间，一般是用网关总耗时减去后端服务的实际耗时，这段时间一般包括接受请求、路由计算、转发请求、接受响应等环节。这个指标是衡量网关自身响应时间是否劣化的重要指标。 file

这些是从数据、经验库里面识别出来的风险，然后从风险库里面选出来跟这次唯一相关的一些稳定性风险的类型。

上图我们看到微服务自身的劣化情况非常明显，缓存响应时间的劣化尤其严重，已经超过了 500%。网关劣化度不高，但是抖动率有提升。消息的容量目前确实有一些不足的迹象。最后一点就是机器资源浪费比较严重。

3.3.2 评估--判断风险，确定 2 个高优先级

对这些风险进行评估，需要从多方面综合判断风险影响，从而来确定优先级。一般会从六个维度来综合评估：

风险对全链路的影响总和

风险对核心链路的影响总和

风险对单链路的影响

风险的修复难度

风险发生后恢复难度

风险继续劣化的可能

基于以上维度综合分析后，我们发现优先级较高的风险是缓存响应时间超标、消息容量不足这两项。

3.3.3 方案--察打一体，明确 3 个任务

file 任务 1：云部署架构调整，切换可用区

缓存响应时间超标的影响是最大的。通过经验库的察打一体的定位能力，我们发现应用和缓存之间的网络延时特别长，达到了 2-3ms，而内部网络延时的标准一般在 0.5ms 以内，这明显是有很大的问题。通过后续详细的分析后，发现半年前购买的机器和各种云资源与之前的可用区不同，但是架构上没有支持多可用区，仍然当做一个集群在使用，导致每次访问都需要跨可用区，导致延时较大。综合评估后，考虑到改造成本，我们决定先切回一个可用区。

任务 2：调整消息存储时间，3 天缩短到 12 小时

消息容量不足直接原因很明确，就是磁盘的容量不足导致的。但是当时扩容遇到一个问题——因为历史原因，有部分应用消息的地址是直接写死的，而且目前已经无人维护，大家不敢修改，所以即使扩容也不一定能够解决这个问题。最后我们分析消息的使用场景，发现消息量最大的 2 个 topic，完全没有保留 3 天的必要，10 分钟后基本消息就无效了。所以最后选择将消息的存储时间调整到 12 小时，相当于容量提升了五六倍。这个容量足够五一业务高峰使用。

任务 3：调整应用的 JVM 参数，充分使用内存

最后，我们还额外解决了一个风险——应用机器的资源浪费。虽然不是必须修复的问题，但我们还是评估了一个方案，建议其调整 JVM 参数，充分利用可用内存。这样做可以充分利用内存资源。