稳定性是技术和业务发展的基础和关键,而保障服务长期稳定是技术团队的核心工作。
一、稳定性的定义和挑战
依据《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