稳定性是技术和业务发展的基础和关键，而保障服务长期稳定是技术团队的核心工作。
一、稳定性的定义和挑战
依据《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名宇航员都在该次事故中丧生。
-
2013年12月6日舟山港撞船事件
巴拿马型散货船“J”轮（引航员在船）满载货物驶过下篮山。为适合当时能见度不良的环境与情况，“J”轮主机采用SLOW AHEAD航行，因潮汛较大涨水顺流航行，引航员用雷达标绘和AIS观察到溜网重北面出口船舶“H”轮及佛渡水道过来的“X”轮（引航员在船，虾峙门出口，船长168米，船宽25米，前后吃水9.2米）的动态，并发现“H”轮位置过于靠近进口航道，主动VHF联系“H”轮并与之确认红灯会。随后在高频里听到交管中心呼叫“H”轮，要求其向右调整航向走虾峙门出口航道，同时要求“X”轮跟随“H”轮出口，“X”轮在高频上回答并同意。
“J”轮与“H”轮左对左交会过程中，看见“X”轮在“J”轮左船头相对方位40度左右，距离约0.4海里，且其船首向对“J”轮船首，并观察到“X”轮右转趋势不明显，引航员判断与该船已经形成了非常危险的局面，立即用高频与之联系，同时操右满舵，主机由SLOW AHEAD直接加车至FULL AHEAD；经多次呼叫“X”轮但始终没有应答。引航员连续密切关注其动态变化，当断定碰撞已不可避免时，紧急操左满舵尝试以尾反移量和减小碰撞角度来减轻碰撞程度。
在稳定性初期治理时，由于人力有限，可以优先做高影响、大概率的。在进入深入攻坚阶段后，就不能再无视墨菲定律了。
Q：这个虽然代码是坨屎，但是系统很稳定，就不重构了
确实会出现复杂混乱的代码反而运行很稳定：
是否要重构，需要看业务场景，评估风险，慎重重构这部分。
七、稳定性保障运营的关键认知
7.1、快速止损
当故障发生时，第一时间不是定位，而是快速止损。
7.2、避免火鸡综合症
火鸡综合症：有一群火鸡，农场主每天中午十一点给它们喂食。一名火鸡科学家观察这个现象近一年，都没有例外，于是它宣布发现了宇宙中的伟大定律：“每天上午十一点，会有食物降临！”
感恩节早晨，火鸡科学家向大伙儿公布了这个定律，但这天上午十一点食物没有降临，农场主提着刀子把它们都宰了……
形式越好，越成功时，我们患火鸡综合症的风险就越大，火鸡综合症越严重，遇到的黑天鹅事件就越辣手。
7.3、光说不练假把式
要贴近真实的演练，可控的演练就是必须的， 可控主要从下面三个方面下手： 爆炸半径、兜底预案、应急止损能力。
7.4、海恩法则(Heinrich's Law)
海恩法则(Heinrich's Law)，是德国飞机涡轮机的发明者德国人帕布斯·海恩提出的一个在航空界关于安全飞行的法则，
海恩法则指出： 每一起严重事故的背后，必然有29次轻微事故和300起未遂先兆以及1000起事故隐患。
法则强调两点：
1、事故的发生是量的积累的结果；
2、再好的技术，再完美的规章，在实际操作层面，也无法取代人自身的素质和责任心。
可以用我们的一句古语“千里之堤溃于蚁穴”来解释。
千丈之堤，以蝼蚁之穴溃；百尺之室，以突隙之炽焚。——《韩非子·喻老》
因此很明显，重大事故不是直接就发生，而是由多个看起来轻微的隐患积累而成。
对网站系统来说，一些小事故同时发生，会聚合成大事故。比如，下面几个事故同时发生时：
- 监控数据的不准确，导致误判；或者监控是单点的，监控挂了这段时间同时发生的其他事故；
- 流量秒级突增，线程池瞬间被打满，而且来不及扩容。
- 放量限流配置不合理，补充机器后，瞬间再次被打垮。
八、总结
稳定性是技术和业务发展的基础和关键，而保障服务长期稳定是技术团队的核心工作，各种侥幸心理都要最终还债的。
标签：风险,方法论,事故,保障,稳定性,发生,故障,Time From： https://www.cnblogs.com/ghj1976/p/wen-ding-xing-bao-zhang-fang-fa-lun.html