一、稳定性为什么如此重要性
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分钟的时间是不可用的。
完善日志打印，便于线上问题排查
RPC 循环调用可修改为批量一次调用
参数校验前置，避免无效调用后续的链路
对于无互相依赖的下游接口并行化调用
事务范围最小
-
资源未初始化成功，服务启动 -
...
-
研发视角：技术方案设计、发布方案是否考虑周全？上线过程是否存在红线行为？ -
测试视角：测试过程为什么没有发现？ -
监控是否第一时间召回？故障响应速度能否更快，后续改进措施？