作者介绍
数列科技联合创始人、CTO——陆学慧
TakinTalks稳定性社区发起人。参编《信息系统稳定性保障能力建设指南1.0》和《稳定性保障服务商能力要求》。2017年联合创立数列科技，专注于高可用性领域，为企业提供稳定性解决方案，帮助快速稳定地应对技术挑战。
温馨提醒：本文约5000字，预计花费9分钟阅读。
背景
最近一两年，我和很多公司的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 三个核心策略
我们实践下来应该在以下三个维度不断深化：采集更丰富的数据、积累更丰富的经验库、从劣化场景不断消化风险。
丰富的数据和经验库大大地降低风险的发现、解决和管理的成本，抓住劣化的场景可以尽早逐步消灭风险，降低故障的发生概率。
2.2 经验库
2.2.1 什么是经验库
先解释一下什么是经验库。经验库是用来积累并产品化经验的模块，它有一个核心的特点——察打一体。以性能容量领域的经验库为例，它需要能够做到发现链路的容量瓶颈在哪个节点，这是察；同时，也能确定瓶颈节点的问题原因是什么，这是打。比如，下单接口性能容量不达标时，经验库可以实时诊断出瓶颈点具体在哪个微服务上，而且可以给出直接原因，如：打印太多日志导致的瓶颈、微服务代码中有较大事务导致并发度上不去等等。
（部分性能相关经验库示例）
2.2.2 经验库繁多但能穷举
经验库需要经过长时间的积累，才能逐步发挥其价值。如图的SLA经验库，整个系统中的SLA指标非常庞大，有非常丰富的管理维度，也需要从链路到节点的全面覆盖。
（SLA经验库示例）
维度包括：响应时间类、容灾部署类、发布变更类、故障发现类、请求正确率类、服务耦合类、架构隔离类等。
链路和节点全面覆盖包括：链路、应用服务节点、容器节点、物理机节点、数据库节点、缓存类节点、消息类节点、搜索类节点等。
经验库的数量和种类都如此之多，那它可以穷举吗？答案是肯定的。即使没办法做到100%，哪怕能做到七八成，就已经能够解决很大部分问题了，可以把风险控制的成本和琐事都降下来。
2.3 数据
2.3.1 采集维度需更丰富
提到运维的常用数据，大家往往想到的是Metrics、Trace和Log。而其实想要做好技术风险管理，还需要更丰富、更多种类的数据，才能降低整体的执行成本。
经验库的特点是察打一体，需要具备诊断原因的能力，所以需要的数据维度会更丰富。比如——
- MySQL中一张表的数量超过2000万时，普通的SQL也会变慢。而且如果大表出现慢SQL，则会极大影响到整个库的稳定性，所以大表是一个很危险的现象。判断这样的情况，我们就需要用到每个数据库中每张数据表的数据量这样的数据。
- 配置类数据，正常来说应该使用配置中心或者参数中心管理，但有很多公司的开发，会将配置类数据放在数据库中管理。而配置数据它需要大量频繁地访问，且不太需要变更，所以它放在数据库里其实不合适。它会让整个链路的 RT 响应时间变长，且变得很不稳定。为了发现这种情况，我们需要用到数据库的表结构数据、数据库的行数、数据库某张表的读写比例等等。比如，一个很简单的判断规则，如果这张数据库里的某张表，它的列数不超过 10 ，行数不超过 5000 ，读写比例大于 1000 （即 1000 次读只有1次写），满足这一条件的数据，我们就把它归为配置类数据。把这种数据风险扫描出来后，就能通过技术风险管理的手段将其提前消化掉。
2.3.2 重视前期数据建设的投入
我个人的经验是，数据采集的工作和总体成本是不能忽视的。因为在很多公司里，数据采集和打通的工作难度比较大，前期确实需要投入一些建设成本，比如找到一些业务方配合，才可能逐步把数据建立起来。但是后期这种比较丰富的数据带来的效率提升是特别明显的。
在经验库中我们会记录每次经验匹配对数据的要求，从而帮助我们快速识别出缺少的数据。如下图页面所示，红色的部门就是缺少数据的，我们就可以知道还要再去采集哪些类型的数据过来，以让整个经验库更加完善。
（经验库示例-红色部分为缺少数据）
2.4 劣化场景
2.4.1 系统劣化的3个阶段
我们把系统的稳定性分为三个阶段：劣化、技术债、重构。
设想一个稳定性的系统，因为版本的不断更新，响应时间自然会不断劣化。我们有一个统计数据，即一个月的时间，接口响应时间劣化10%以上的接口数量占比25%左右。
随着劣化不断累积，就会在系统内部逐步留下技术债。大家都知道系统哪里有明显不稳定的地方，但是改动起来已经需要一定的成本了，且不是想改就能立马改掉的。这种状态就会导致出现故障的可能性大大增加。
技术债的累积，就会导致稍不注意就发生故障，而且修复成本很高，最终演化为被迫重构系统了。
2.4.2 劣化的4个主要场景
劣化一般是由于应用的版本变更、数据量的增加逐步导致，一般包括：接口响应时间劣化、业务容量劣化、业务正确率劣化、部署架构劣化等等。
在每次应用发布后，出现劣化现象时，是一个非常好的逐步推动消化技术风险的场景。比如发布后，链路响应时间相较于发布前增加5%，相较于1个月前增加15%。此时将这样的风险发布出来，推动解决，是一个大家比较容易接受的场景。
三、以上策略落地效果怎么样？
以上是理论层面的分享，那么是否能落地？落地效果如何？接下来我将分享具体客户的应用实践，我们在案例中看看落地数据 经验库和劣化的策略。
3.1 业务背景
这家公司是一家新能源企业，前两年新能源汽车业务迎来爆发式增长，导致系统的稳定性也遇到不小的挑战——故障频发、告警不断。
新能源汽车一般都有一个可以在APP上控制车辆的功能，从下图中可以看到，用户每操作3次，就会因为各种原因失败1次。可以看到系统已经处于高负荷的状态运行，随时可能出现问题——今年春节出行高峰发生了系统崩溃。
今年五一高峰是疫情后的第一个小长假，预计出行人数会爆发式增长。然而系统的稳定性面临了很多挑战。比如，MQTT（一个物联网消息系统）连接数不足、数据库容量不足且无法扩容、内部的消息系统经常堆积、网关经常超时等等。从上图的描述中，可以看到技术债已经很多了。
3.2 实施契机
这家企业早些时候已经安装了数据采集的客户端，并且在系统逐渐劣化的过程中已经识别出了很多风险，比如微服务自消耗超时、缓存响应时间超标、网关耗时过长、消息容量不足以及应用机器内存使用率不足等等。
虽然已经意识到了有这么多风险，但之前一直没有下定决心逐步消除它们，也没有找到一个好的机会。考虑到五一出行的重要性，经过多次商议后，我们最终决定启动部署架构优化的项目。
3.3 落地过程
3.3.1 识别--风险库匹配，提取5个风险点
这里有几个SLA的概念，给大家简单介绍一下：
- 微服务自耗时：指一个微服务的总耗时，减去调用其他服务的耗时，即只计算自己服务的消耗。一般要包括服务本地的计算逻辑、对数据库、缓存等访问。实际指标的计算是有点复杂的，需要考虑多线程异步调用的情况、回调的情况等等。这个指标是用来衡量单个微服务的响应时间是否劣化的重要指标。
- 网关自耗时：网关自身的消耗时间，一般是用网关总耗时减去后端服务的实际耗时，这段时间一般包括接受请求、路由计算、转发请求、接受响应等环节。这个指标是衡量网关自身响应时间是否劣化的重要指标。
这些是从数据、经验库里面识别出来的风险，然后从风险库里面选出来跟这次唯一相关的一些稳定性风险的类型。
上图我们看到微服务自身的劣化情况非常明显，缓存响应时间的劣化尤其严重，已经超过了500%。网关劣化度不高，但是抖动率有提升。消息的容量目前确实有一些不足的迹象。最后一点就是机器资源浪费比较严重。
3.3.2 评估--判断风险，确定2个高优先级
对这些风险进行评估，需要从多方面综合判断风险影响，从而来确定优先级。一般会从六个维度来综合评估 ：
- 风险对全链路的影响总和
- 风险对核心链路的影响总和
- 风险对单链路的影响
- 风险的修复难度
- 风险发生后恢复难度
- 风险继续劣化的可能
基于以上维度综合分析后，我们发现优先级较高的风险是缓存响应时间超标、消息容量不足这两项。
3.3.3 方案--察打一体，明确3个任务
任务1：云部署架构调整，切换可用区
缓存响应时间超标的影响是最大的。通过经验库的察打一体的定位能力，我们发现应用和缓存之间的网络延时特别长，达到了2-3ms，而内部网络延时的标准一般在0.5ms以内，这明显是有很大的问题。通过后续详细的分析后，发现半年前购买的机器和各种云资源与之前的可用区不同，但是架构上没有支持多可用区，仍然当做一个集群在使用，导致每次访问都需要跨可用区，导致延时较大。综合评估后，考虑到改造成本，我们决定先切回一个可用区。
任务2：调整消息存储时间，3天缩短到12小时
消息容量不足直接原因很明确，就是磁盘的容量不足导致的。但是当时扩容遇到一个问题——因为历史原因，有部分应用消息的地址是直接写死的，而且目前已经无人维护，大家不敢修改，所以即使扩容也不一定能够解决这个问题。最后我们分析消息的使用场景，发现消息量最大的2个topic，完全没有保留3天的必要，10分钟后基本消息就无效了。所以最后选择将消息的存储时间调整到12小时，相当于容量提升了五六倍。这个容量足够五一业务高峰使用。
任务3：调整应用的JVM参数，充分使用内存
最后，我们还额外解决了一个风险——应用机器的资源浪费。虽然不是必须修复的问题，但我们还是评估了一个方案，建议其调整JVM参数，充分利用可用内存。这样做可以充分利用内存资源。
3.3.4 验收--70%资源渡过五一高峰
最终顺利渡过五一高峰，只收到了3次告警，没有其他稳定性相关问题或者故障中断等情况发生。
1）用户体验提升：核心功能，因为超时错误原先每天影响40000 客户，基本消失
2）超时、堆积告警基本消失：早晚高峰平均28条消息堆积告警，每次堆积几十万条，基本消失
3）硬件成本降低：RT降低后，集群容量提升40%以上，整体硬件缩容了30%
四、总结与展望
通过上述案例，我们可以回顾之前提到的核心策略，即丰富数据、积累经验库和治理劣化场景。这三个策略在这个案例中得到了应用。
由于篇幅限制，还有一些业务架构和技术架构优化、日常发布中的劣化治理的案例无法一一分享。然而，从这个案例中，大家可以看到数据 经验库的方式，持续积累，可以用很低的成本来解决稳定性风险多而散且重复发生的问题。（全文完）
Q&A
1、想问一下这个经验库是怎么积累出来的？有没有什么经验可以分享一下。
2、系统确实有性能问题，怎么能确保这样实施真的能出效果？比如问题是否真的能定位、经验库是否能覆盖等等。
