跳到主要内容

服务稳定性建设

一、稳定性为什么如此重要性​

2024年11月11日蚂蚁金服案例回顾

在万众瞩目的双十一购物节当天上午，蚂蚁金服的核心应用支付宝遭遇了一场突如其来的服务异常。用户纷纷反馈在付款环节遭遇障碍，屏幕上频繁跳出“支付失败”、“交易创建失败”及“服务异常”的提示，这无疑给用户的购物体验蒙上了一层阴影。幸运的是，这场风波在上午10点50分前得到了及时的控制与修复。支付宝官方迅速通过微博平台向广大用户表达了诚挚的歉意，并揭示了故障背后的真相——系统消息库局部故障所致。然而，据内部消息透露，更深层次的原因在于OceanBase数据库的一次运维操作“删除历史版本数据”未能如预期在高峰期通过自动预案关闭，最终导致了内存溢出。

2024年8月19日网易云音乐风波启示

今年8月19日，网易也遭遇了关键业务的大规模不可用事故。网易云音乐核心应用自下午14点50分左右开始出现故障，直至17点30分左右才逐渐恢复。据网络传言，此次事故与云存储故障有关。虽然具体的复盘材料尚未公开，但这一事件无疑再次敲响了系统稳定性维护的警钟。

2023年11月27日至28日滴滴案例警示

时间回溯至去年双十一后的不久，滴滴APP在11月27日晚至28日白天遭遇了长达近12小时的严重宕机事件。用户反馈称，期间滴滴APP无法打开页面、无法进行打车或骑车服务、导航功能异常以及费用结算混乱等问题频发，严重影响了用户的出行体验。经调查，此次故障的根本原因在于滴滴云K8s版本升级过程中出现异常，导致了计算服务的大规模不可用。事后，互联网上也出现了诸多关于此次事件的复盘文章，如《从滴滴的故障中我们能学到什么》，为行业内外提供了宝贵的经验与教训。

综上所述，无论是蚂蚁金服、滴滴还是网易，这些行业巨头的服务异常都深刻揭示了系统稳定性对于保障用户体验、维护品牌形象以及确保业务连续性的至关重要性。因此，加强系统稳定性建设、完善故障预防与应急响应机制、以及定期进行系统复盘与优化，已成为企业不可忽视的重要课题。

二、稳定性保障核心指标​

互联网后端系统的稳定性是确保服务质量和用户体验的关键因素。为了衡量和优化后端系统的稳定性，通常会关注以下几个核心指标

1、性能相关指标​

  • 响应时间（Response Time）：从用户发出请求到接收到响应的时间。直接影响用户体验，响应时间过长可能导致用户流失。度量单位毫秒（ms）或秒（s）。

  • 吞吐量（Throughput）：单位时间内系统处理的请求数或事务数。衡量系统的处理能力，高吞吐量表示系统能够处理更多的请求。度量单位每秒事务数（TPS）

  • 错误率（Error Rate）：系统处理请求时发生错误的百分比。高错误率可能表示系统存在严重的问题，如配置错误、资源不足或代码缺陷。度量单位百分比（%）

2、资源利用相关指标​

  • CPU使用率：CPU运行在非空闲状态的时间占比。反映CPU的繁忙程度，过高可能导致系统响应变慢，过低可能表示资源未被充分利用。度量单位百分比（%）。

  • 内存利用率：系统内存的使用情况。内存不足会导致系统性能下降甚至崩溃。兆字节（MB）或千兆字节（GB）。

  • 磁盘I/O：磁盘读写操作的速度和频率。磁盘I/O性能差会影响系统的整体性能。度量单位每秒读写次数（IOPS）和每秒传输的数据量（MB/s）。

3、故障恢复相关指标​

  • 平均检测时间 （Mean Time to Detect,MTTD），MTTD是指从故障发生到检测到故障的平均时间。它代表了系统或团队对故障反应的敏捷度，是衡量系统故障检测速度的关键指标。较短的MTTD意味着系统能够更快地发现潜在问题，从而迅速启动修复流程

  • 故障恢复时间（Mean Time to Recovery, MTTR），系统从故障发生到完全恢复所需的平均时间。用于评估系统的可恢复性，较短的MTTR表示系统能够快速从故障中恢复。度量单位时间（如小时、分钟、秒）。

  • 平均事故时间间隔（Mean Time Between Failure,MTBF）, MTBF是衡量系统两次故障之间平均运行时间的指标。MTBF越长，意味着系统的持续服务能力越强，即系统能够更长时间地稳定运行而不出现故障。

  • 平均故障定位时间 （Mean Time To Know,MTTK）, MTTK是指从故障发生到确定故障根本原因的平均时间。这一指标反映了团队对故障的认知和定位能力。较短的MTTK意味着团队能够更快地识别故障点，为后续修复工作奠定基础。

  • 平均事故解决时间 （Mean Time To Resolve,MTTR_1）, 与MTTR相比，MTTR_1涵盖了从故障发生到完全解决（包括数据修复）的平均时间。这一指标不仅考虑了故障的直接修复时间，还包括了数据恢复等后续工作所需的时间，因此更全面地反映了故障处理的整体效率和效果。

4、服务水平相关指标​

  • SLI（Service Level Indicator）：SLI是用于衡量服务质量和稳定性的具体指标，谷歌推荐的四大黄金指标：延迟（Latency）、流量（Traffic）、错误率（Errors）、资源利用率（Saturation）

  • SLO（Service Level Objective）：SLO是服务提供商和客户之间就服务质量达成的具体目标值。它是基于SLI制定的，举个例子，页面加载延迟时间SLO，针对页面加载时间的SLI，可以设定一个SLO为“在95%的情况下，页面加载时间要小于500毫秒”。

  • SLA（Service Level Agreement）：是一种具备法律约束力的商业承诺，一旦服务提供商未能达到协议中规定的服务水平，将依据协议条款进行相应的赔偿。一家企业与云服务提供商签订的SLA中，除了规定服务可用性的SLO（如“保证服务在99.9%的时间内可用”），如果未能达到这个标准，服务提供商应给予用户一定的经济赔偿或其他补偿措施。

  • 可用性（Availability）：在一定时间范围内系统正常运行的百分比。衡量系统的持久性和稳定性，高可用性意味着系统能够持续提供服务。度量单位百分比（%）。假设某电商平台一年的总运行时间为365天（即8760小时），如果其可用性为99.99%，那么每年的不可用时间就是8760小时乘以（1-99.99%），结果约为52.56分钟。某电商平台只有大约52.56分钟的时间是不可用的。

三、稳定性治理思路​

基于下图分析，我们的核心目标是降低MTTR 快速修复，增加MTBF,减少故障发生次数。我们可以从事前预防、事中止损、事后复盘三个方面着手，提高系统的稳定性水平。

事前​

1、容量治理，通过监控观察服务峰值流量对各种资源消耗，确保上下游系统能够处理预期和潜在的负载。业务增长或者促销活动前，通过全链路压测获得系统容量，根据需要进行扩容，限流配置。

2、代码优化规范

  •    完善日志打印，便于线上问题排查

  •    RPC 循环调用可修改为批量一次调用

  •    参数校验前置，避免无效调用后续的链路 

  •    对于无互相依赖的下游接口并行化调用

  •    事务范围最小

  •    资源未初始化成功，服务启动

  •   ...

3、强弱依赖梳理，核心接口进行链路梳理，根据业务场景判断下游服务是否可降级，业务代码中正确处理调用失败时强依赖的兜底逻辑，如调用下游权限接口失败阻塞整个请求；弱依赖配置超时时间或者熔断。

4、依赖反转：高等级服务不允许依赖低级别服务

5、针对接口的长尾抖动，配置超时重试，对于P99很低偶发超时这类请求，可以适当增加失败重试次数。

6、针对写接口，必要场景保证幂等

7、针对读接口，不可变或者一致性要求不高的场景增加缓存

8、机房容灾与演练，可以构建同城容灾和异地容灾能力，倘若一个数据中心出现故障，能够借助自动切换和故障转移的机制将流量转移至其他正常的数据中心，以此保障系统的可用性与可靠。

9、变更管控，需求迭代时技术方案考虑可监控、可灰度、可回滚。

10、资源隔离，根据业务的重要程度和实现成本考虑存储隔离、服务集群隔离等，限定故障半径，降低业务间的相互影响。

11、系统性能瓶颈优化：治理大key、热点key、消息堆积、数据倾斜、慢SQL等问题

12、质量保障平台建设，如diff工具，对于接口变更，调用线上Master分支接口和开发环境接口，比较两者响应差异。存在diff 则作为上线流程卡点，人工介入。类似质量左移的工具建设不一一举例。

13、架构治理：服务合理拆分，领域清晰。

事中​

14、监控与告警，通过数据埋点，建立必要的业务监控大盘和统计信息看板，定义监控指标（第一章节提到的核心指标）与报警规则，及时召回线上问题

15、资损防控：如果你的业务涉及资金安全，做好离线核对和实时核对

事后​

16、预案执行：事前做好业务场景出现故障是的与案，提升预案场景覆盖率，日常演练预案执行，问题发生时快速止血

17、事故复盘：分析故产生的原因，从以下角度总结经验教训，完善需求开发、测试与上线的流程。

  • 研发视角：技术方案设计、发布方案是否考虑周全？上线过程是否存在红线行为？

  • 测试视角：测试过程为什么没有发现？

  • 监控是否第一时间召回？故障响应速度能否更快，后续改进措施？

标签：
最后由 Vstay 于 更新