长春二道网站建设,东莞网站建设(曼哈顿信科),怎么利用代码做网站,怎么在后台设计网站一分钟精华速览
SRE 团队每天面临着不可控的各类风险和重复发生的琐事#xff0c;故障时疲于奔命忙于救火。作为技术管理者#xff0c;你一直担心这些琐事会像滚雪球一样#xff0c;越来越多地、无止尽地消耗你的团队#xff0c;进而思考如何系统性地枚举、掌控这些风险故障时疲于奔命忙于救火。作为技术管理者你一直担心这些琐事会像滚雪球一样越来越多地、无止尽地消耗你的团队进而思考如何系统性地枚举、掌控这些风险怎么能更低成本地推进风险治理
本文根据多家企业 SRE 实战总结重点分享稳定性和架构优化的核心策略。实践已经验证多且散的风险是可以被低成本解决的。
作者介绍 数列科技联合创始人、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 三个核心策略
我们实践下来应该在以下三个维度不断深化采集更丰富的数据、积累更丰富的经验库、从劣化场景不断消化风险。
丰富的数据和经验库大大地降低风险的发现、解决和管理的成本抓住劣化的场景可以尽早逐步消灭风险降低故障的发生概率。
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%
四、总结与展望
通过上述案例我们可以回顾之前提到的核心策略即丰富数据、积累经验库和治理劣化场景。这三个策略在这个案例中得到了应用。
由于篇幅限制还有一些业务架构和技术架构优化、日常发布中的劣化治理的案例无法一一分享。然而从这个案例中大家可以看到数据经验库的方式持续积累可以用很低的成本来解决稳定性风险多而散且重复发生的问题。全文完 本文由博客一文多发平台 OpenWrite 发布
