一、系统稳定性概述

聊到系统稳定性，我脑子里第一个蹦出来的画面，是几年前一个深夜的故障现场。那会儿我还在负责一个电商平台的后端，大促期间订单量暴涨，结果核心数据库连接池被打满，整个系统像多米诺骨牌一样塌了。嗯，那晚的教训让我彻底明白——稳定性不是锦上添花，而是系统的命根子。

什么是系统稳定性

说白了，系统稳定性就是系统在面对各种突发状况时，还能正常干活的能力。你想想看，一个系统上线后，用户访问它、依赖它，它就得扛得住流量波动、代码bug、硬件故障这些幺蛾子。

我个人习惯把稳定性分成两个层面来看：

• 静态稳定性：系统在正常负载下，各项指标平稳，不抖不飘。比如CPU使用率维持在40%左右，响应时间稳定在50ms以内。
• 动态稳定性：系统在异常场景下，能快速恢复，不崩溃。比如突然来了10倍流量，系统能降级、限流，而不是直接挂掉。

我在项目中遇到过一种情况：系统平时跑得挺稳，但一到月底结算就出问题。后来发现是定时任务和业务高峰撞车了。这就是典型的动态稳定性没做好——你只考虑了正常情况，没考虑异常叠加。

稳定性的核心指标

衡量系统稳定性，不能光靠感觉。我一般盯着三个核心指标看：可用性、可靠性、可维护性。这三个指标就像三根柱子，缺一根都不稳。

指标	定义	常见度量方式	我的经验值
可用性	系统在给定时间内能正常服务的时间比例	9的个数（99.9%、99.99%）	核心系统至少99.99%，非核心可以放宽到99.9%
可靠性	系统在特定条件下持续正确运行的能力	MTBF（平均故障间隔时间）、故障率	MTBF越长越好，我见过最差的系统每2小时崩一次
可维护性	系统出问题后，修复和恢复的难易程度	MTTR（平均修复时间）、变更成功率	MTTR控制在15分钟以内算及格

可用性

可用性是最直观的指标。用户能不能访问你的系统？能访问多久？这就是可用性要回答的问题。

我记得有一次，一个同事跟我说：「我们的系统可用性99.99%，很稳了。」我问他：「那你知道99.99%意味着一年宕机多久吗？」他愣了一下。我告诉他：52.56分钟。也就是说，一年里你有将近一个小时系统是挂的。对于金融、电商这类系统，这一个小时可能就是几千万的损失。

可用性的计算方式很简单：

可用性 = (总时间 - 宕机时间) / 总时间 × 100%

但要注意，这里的「宕机时间」不只是服务器挂掉的时间。还包括：

• 计划内停机（比如升级维护）
• 部分功能不可用（比如支付模块挂了，但浏览正常）
• 响应时间超过阈值（比如用户等了一分钟才看到页面）

可靠性

可靠性关注的是「系统会不会出错」。可用性高不代表可靠性高——比如系统一直在线，但返回的数据是错的，那有什么用？

我曾经遇到过一个案例：一个支付系统，可用性99.999%，但每1000笔交易就有1笔金额算错了。用户投诉不断，最后不得不下线重算。这就是典型的可靠性问题——系统没挂，但结果不可信。

衡量可靠性，我常用两个指标：

• MTBF（Mean Time Between Failures）：平均多久出一次故障。这个值越大越好。
• 故障率：单位时间内出故障的概率。比如每百万次请求出错多少次。

提高可靠性的手段，说白了就是「冗余+校验」。数据多存几份、接口多做幂等、逻辑多写单元测试。嗯，这些听起来简单，但真正落地时很多人会偷懒。

可维护性

可维护性是我最看重的指标，没有之一。为什么？因为系统总会出问题，关键是你能不能快速搞定它。

可维护性包括三个方面：

• 可观测性：出问题时，你能看到什么？日志、监控、链路追踪，这些是眼睛。
• 可变更性：改代码、加功能、修bug，能不能快速上线？
• 可恢复性：系统挂了，能不能快速恢复？有没有应急预案？

稳定性设计的重要性

你可能会问：稳定性设计到底有多重要？我直接说结论：它决定了系统的生死。

举个例子。2018年，某知名云厂商因为一个配置变更，导致全线产品宕机数小时。事后复盘发现，问题出在变更流程上——没有灰度、没有回滚方案、没有监控告警。说白了，就是稳定性设计没做到位。

稳定性设计不是事后补丁，而是从一开始就要考虑的事。我一般会从这几个角度入手：

• 架构层面：做冗余、做隔离、做限流降级。别让一个模块拖垮整个系统。
• 开发层面：写健壮的代码、做充分的测试、留好日志和监控。
• 运维层面：自动化部署、灰度发布、应急预案演练。

说白了，稳定性设计就是「花小钱办大事」。你提前投入10%的精力做稳定性，可能避免90%的线上故障。这笔账，怎么算都划算。