稳定性是业务和技术发展的基础，保障服务长期稳定是技术团队的核心工作。
一、稳定性的定义和挑战
依据《ISO IEC 25010-2011 SQuaRE》标准，稳定性定义：
- “对用户而言，可用的、应对故障（Faults)的能力，受性能、可用性、可维护性等因素影响。”
- 其中，高可用则为能应对大流量的稳定性能力。
最影响稳定性的四大挑战为:
- 故障的随机性(比如：软硬件、网络故障等)，
- 系统规模（比如：交易链路长、外部依赖关系多），
- 系统变化(比如：节假日流量、功能迭代发布等)，
- 故障产生的重大影响（比如：高峰期健康宝不可用、饭点前外卖不可用）。
前三点是引发系统故障的重要因素。
二、稳定性运营框架
按照事故发生的时间维度分为：事前、事中、事后。
- 事前：目标预防，即不发生故障或发生时损失小；
- 事中：目标快速止损，这就要求尽早发现，快速定位，快速恢复；
- 事后：目标同样或类似的事故不再发生，这就需要复盘和改进；
相关简写说明
| 简写 | 完整 | 说明 |
|---|---|---|
| MTBF | Mean Time Between Failure | 平均故障时间 |
| MTTR | Mean Time To Repair | 故障平均修复时间 |
| Pre-MTBF | 故障前，故障预防 | |
| Post-MTBF | 故障后，故障改进 | |
| MTTI | Mean Time To Identify | 平均故障发现时间， 故障发现：故障发生到响应 |
| MTTK | Mean Time To Know | 平均故障认知时间， 故障定位：根因或是根因范围定位出来为止 |
| MTTF | Mean Time To Fix | 平均故障解决时间， 故障恢复：采取措施恢复业务 |
| MTTV | Mean Time To Verify | 平均故障修复验证时间， 故障恢复验证：故障解决后验证业务恢复所用时间 |
| Failover | 失效转移， 是一种备份操作模式，当主要组件由于失效或预定关机时间的原因而无法工作时，这种模式中的系统组件（比如服务器、网络或数据库）的功能被转嫁到二级系统组件。 |
三、稳定性能力模型
提升稳定性，目前常见的需建设的能力如下：
这些能力需要根据当时科技情况，团队情况，定期完善补充。
四、稳定性运营报表
4.1、风险清单
做风险管理时，应该有个归属应用和依赖的二维表，并对每个服务的每个依赖做综合评估。
具体到某个依赖时，应该有更详细的评估，比如MySQL可能要评估下面项，并基于这些综合给风险危害和风险发生概率评分。
- 当从库宕机时，有啥风险？发生概率
- 当主库宕机时，有啥风险？发生概率
- 当磁盘空间满时，有啥风险？发生概率
- 当写流量突增2倍时，有啥风险？发生概率
- ...
上面风险清单需要定期Review，看是否有遗漏或需要调整的。
4.2、风险报告
汇报时，应该按照影响和发生概率对目前风险治理吞吐、人力投入做报告。
4.2.1、风险吞吐表
表格内容主要反映风险发现和被响应的进展。
比如表格中的A组，在高影响高概率的档位，有10个风险待治理需求，过去一个周期新增了2个，治理了3个，有1个状态未更新。
如果每项风险需要拆分成多个工作项做治理，而且周期长，可以在表1的基础上，再提供一个治理任务吞吐表，依次显示待整理的任务（过去一个周期新增治理任务数，完成任务数）
4.2.2、稳定性人力投入表
表格内容主要反映各团队在稳定性的人力投入情况。
五、组织保障
- 员工治理： “踩红线” 的惩罚机制进行规范约束；
- 员工意愿： 需要有现实的激励，不仅仅部门荣誉奖励；还应调薪和年终奖系数倾斜，并在更高组织上校准；对长期从事稳定性加固和运营的晋升机制。
- 员工能力： 常态化培训、考试、评比机制，长期灌输底线意识，做到深入人心。
- 职责清晰： 专人持续负责，确保做事有连续性；攻防分家，避免自编自演。
六、常见问题
Q：我们要追求100%的稳定么？
答：我们不是追求极致的稳定，而是在业务发展和稳定之间取平衡。
一般来说，任何软件系统都不应该一味地追求100%可靠，因为对最终用户来说，99.999%和100%的可用性是没有实质区别的（99.999%的可用性是每天0.6s，每月26s，每年5m的不可用），注意：这个并不适用于心脏起搏器和防抱死刹车系统等。
从最终用户到服务器之间，有很多中间系统（用户的笔记本电脑、家庭 WiFi、网络提供商和输电线路等）这些系统综合起来可靠性要远低于 99.999%。所以就算我们花费巨大精力将系统变为100%可靠,也并不能给用户带来任何实质意义上的帮助。
Q：发生概率低的风险，我们可以忽略么？
按照墨菲定律（Murphy's Law）： “只要发生事故的可能性存在，不管可能性多么小，这个事故迟早会发生的。”
相关案例例子：
- 1986年1月28日，挑战者号在进行代号STS-51-L的第10次太空任务时，因为右侧固态火箭推进器上面的一个O形环失效，并且导致一连串的连锁反应。在升空后73秒时，爆炸解体坠毁。机上的7名宇航员都在该次事故中丧生。
在稳定性初期治理时，由于人力有限，可以优先做高影响、大概率的。在进入深入攻坚阶段后，就不能再无视墨菲定律了。
Q：这个虽然代码是坨屎，但是系统很稳定，就不重构了
确实会出现复杂混乱的代码反而运行很稳定：
是否要重构，需要看业务场景，评估风险，慎重重构这部分。
七、稳定性保障运营的关键认知
7.1、快速止损
当故障发生时，第一时间不是定位，而是快速止损。
7.2、避免火鸡综合症
火鸡综合症：有一群火鸡，农场主每天中午十一点给它们喂食。一名火鸡科学家观察这个现象近一年，都没有例外，于是它宣布发现了宇宙中的伟大定律：“每天上午十一点，会有食物降临！”
感恩节早晨，火鸡科学家向大伙儿公布了这个定律，但这天上午十一点食物没有降临，农场主提着刀子把它们都宰了……
形式越好，越成功时，我们患火鸡综合症的风险就越大，火鸡综合症越严重，遇到的黑天鹅事件就越辣手。
7.3、光说不练假把式
不能演戏，要贴近真实的演练，可控的演练就是必须的， 可控主要从下面三个方面下手： 爆炸半径、兜底预案、应急止损能力。
7.4、海恩法则(Heinrich's Law)
海恩法则(Heinrich's Law)，是德国飞机涡轮机的发明者德国人帕布斯·海恩提出的一个在航空界关于安全飞行的法则，
海恩法则指出： 每一起严重事故的背后，必然有29次轻微事故和300起未遂先兆以及1000起事故隐患。
法则强调两点：
1、事故的发生是量的积累的结果；
2、再好的技术，再完美的规章，在实际操作层面，也无法取代人自身的素质和责任心。
可以用我们的一句古语“千里之堤溃于蚁穴”来解释。
千丈之堤，以蝼蚁之穴溃；百尺之室，以突隙之炽焚。——《韩非子·喻老》
很明显，重大事故不是直接就发生，而是由多个看起来轻微的隐患积累而成。
对网站系统来说，一些小事故同时发生，会聚合成大事故。比如，下面几个事故同时发生时：
- 监控数据的不准确，导致误判；或者监控是单点的，监控挂了这段时间同时发生的其他事故；
- 流量秒级突增，线程池瞬间被打满，而且来不及扩容。
- 放量限流配置不合理，补充机器后，瞬间再次被打垮。
八、总结
稳定性是业务和技术发展的基础，保障服务长期稳定是技术团队的核心工作，各种侥幸心理都要最终还债的。
