对系统稳定性的几点思考

《中国制造2025》特别提到要深化互联网在制造领域的应用；加快开展物联网技术研发和应用示范，培育智能监测、远程诊断管理、全产业链追溯等工业互联网新应用；建设一批高质量的工业云服务和工业大数据平台。在互联网业务高速发展阶段，故障严重性及其造成的损失被增长带来的收益所掩盖，而当业务甚至整个行业进入平稳期，每次故障的损失都将显得更“痛”，业务更加伤不起。从行业发展和业务要求的角度都必须更加重视软件系统的可靠性和业务稳定性。

一、问题的提出

为了提升系统稳定性、可靠性，整个行业都在理念和实践上不断创新。互联网是特别注重实践和创新的领域，每年的技术大会、各大厂公众号、博客等都有很多的实践分享，行业内也竟相学习。互联网行业也非常重视理念，提出了SRE、AIOps智能运维、自动化、可观测性、DataOps、反脆弱/混沌工程、确定性运维、安全生产、云原生可靠性等理念，这些理念深入人心。然而，在工程师实际工作中，实践和理念之间仍然存在巨大的鸿沟，众多工程师仍是感觉迷茫：理念很美好，现实很骨感，到处学习别人的实践经验，没有成体系的工作指引和方法，工作重点不明确，有许多工作要做又不确定能提升多少可靠性。

我理解的“确定性运维”其内含应该包括几个方面，首先要有确定性的目标、确定性的工程方法。确定性的工程方法是实践和愿景之间的阶梯，依赖确定性运维过程和工作方法，才能实现确定的稳定性目标。

二、确定性的目标：进行定性与定量的度量

对可靠性进行定性与定量研究是互联网业界当前比较欠缺的环节。可靠性度量是提升可靠性的前提，所谓“无度量不改进”。确定的可靠性指标、核心服务、可靠性目标，可靠性数据收集，对可靠性异常后的故障量化定级，以及可靠性证明等环节。也包括可靠性工作的过程度量。

软件可靠性度量一般包括几个过程：确定对象、故障定义、数据收集、统计分析、输出度量结果等。首先，要确定度量的对象，明确要度量哪些重要服务的可靠性；然后，要对服务是否可靠做出定义，什么样的状态是符合预期的；接着，确定数据采集上报的方式、安排开发，确定指标统计口径，然后在软件运行一段时间后收集数据，包括质量数据和故障数据；最后，对数据进行统计分析，输出评估结果和度量结果。这个度量过程，通常由开发负责人和产品负责人、SRE、质量负责人等共同确定并达成一致，且在业务生存周期内保持一致。

度量分析依赖收集到的可靠性数据和故障报告。通过可靠性数据对故障进行多种维度的定性定量分析、分级分类，其结果可以帮助我们了解可靠性的基本特点，也可帮助我们自上而下地分析可靠性问题，并把改进要求和可靠性指标分拆到具体团队或模块，与相关团队制定可靠性目标。常见的度量方法，或者说可靠性的表示方法主要有以下几种。

可靠性度量方法

故障复盘后形成故障结论报告，在周期（如季度、月度）结束后进行统计分析。可用如下几种度量方法。

（1）按故障分级分布

» 影响值定级法

选取出业务核心服务，为每个核心服务制定一个影响矩阵，把服务进行分类分级，如核心服务、重要服务，定义一个对应表。比如某核心服务故障时长15分钟，故障期间指标平均下跌到80%左右，找到定级表属于P3级别故障。影响率一般取故障期间的总失败率，相当于是平均值，可量化黄金指标强烈抖动的情况。

（2）通过故障特征评估可靠性方法

确定了故障的严重程度/级别，就可以周期性地分析来评估可靠性的水平。

» 按次数分布

统计各个级别故障的次数，P1-P4故障次数，跟前一个周期进行对比。

» 按团队分布

故障复盘时要做故障责任归属，把故障按责任归属部门/团队进行分布，故障次数较多的团队要在技术和管理方面找问题；技术组件或服务也基本是按团队来划分责任归属的，因此也可按组件/服务进行分别统计。

» 按原因分布

包括导致产品功能故障或潜在脆弱的设计缺陷、代码Bug等直接原因；也包括外部因素（如网络、主机）引发的产品故障的间接原因。故障是复杂的，我们必须分析每个故障发生背后深层次的原因，对原因进行分类。

» 按业务/产品/模块分布

从业务层面、产品层面进行分布分析，分析故障影响的业务或产品，度量各个业务/产品的可靠性。当然，还可以按其他维度来进一步统计分析，根据公司具体的需要来进行即可。

（3）按故障时长度量

故障处理过程度量

» 发现时长、定界时长、定位时长、恢复时长

发现时长：在所有故障中从发生到发现（监控指标开始异常、发出告警时间）的时长；定界时长：从开始响应到确定问题边界、业务影响范围的时长；

定位时长：从发现故障到定位出根因时长；

恢复时长：从定位出原因到修复，业务恢复到正常水平的时长。

故障时长预算：达标时长或不可用时长

（4）按周期内失败率进行度量

（5）其他度量方法：首发率、责任故障与非责任故障

三、确定性的过程：建立软件可靠性工作大纲形成其他公司即使是较小的公司也能具有指导意义的大纲。在实践和理念之间建立工程化的方法。以故障修复的工程大纲为例：

1. 故障修复能力建设的目标

软件系统应急切换的目标是实现最短时间内修复故障。一般是通过预案实现一键或少数几个步骤恢复到正常服务状态，从而缩短故障时长。

2．定义(术语和定义)

故障修复时间：从故障发生到被修复的持续时长。

» 平均修复时间（MTTR：Mean Time To Repair）：度量软件系统修复能力的一个参数，是指周期内所有故障从发生到被修复的时间的平均值。

» 故障修复能力：产品在规定的条件下和规定的时间内，按规定的程序和方法进行修复时，保持和恢复到规定的状态的能力。

» 可修复性设计：是指产品的设计特性支持通过修复方法去改变软件的运行方式。

» 修复预案：预案是指根据评估分析或经验，对潜在的或可能发生的突发事件的类别和影响程度而事先制定的应急处置方案。预案要针对总结出来的故障场景，将经过验证的修复流程和运维操作编排成可快速执行的程序，下次故障出现时通过执行此程序快速恢复。

» 预案平台：是指提供执行程序、开发工具和编排执行流程的系统。

» 应急切换：也叫故障切换，是指在故障发生时通过预先设定的方案进行操作，把故障灾难节点隔离或把流量切换到正常服务的过程。

3．工作内容

为了实现通过预案快速切换从而修复故障，需要做好下列工作：

» 软件系统的各层架构（业务架构、应用架构、系统架构、基础设施架构等）需要被设计为可容灾、可被修复的。

» 分析评估潜在的风险场景，把过去曾经发生故障及其修复经验进行提炼，形成固定的处理模式，设计和开发形成针对特定场景的预案。

» 开发和设计应急切换的预案平台，通过平台可以调用各个依赖系统或管控系统的能力，把多个系统的能力进行整合。

» 预案流程可能涉及的依赖系统或管控系统实现关键功能的API化，才能通过软件的编排实现自动化切换的能力。

4.评价与度量

评价故障应急修复能力，可以从平均故障的时长、故障的修复时效、故障的覆盖比例（反过来就是没有覆盖的比例）、执行的次数等来进行评价。

平均故障时长（MBTF）：

MBTF是指周期内所有故障的平均时长。

MBTF=Sum(全部故障时长)/故障次数。

说明：如果有了预案且被高效执行，那么应该能大幅缩短故障的时长。全部故障也是可以分不同范围进行统计的。如统计P1-P4严重故障，或包括未被定级的故障；也可以统计由预案所修复的所有故障的MTTR；还可分析不同业务，不同集群的MBTF。

预案覆盖率：

统计周期内所有故障中有多少是通过预案进行修复的，反过来有多少故障是没有通过预案进行修复。这些没被覆盖的应该重点复盘。

预案覆盖率=(所有故障-由预案修复的故障)/所有故障*100%

说明：预案覆盖率应该尽可能高，通过风险识别、故障分析等方法等提前梳理需要开发预案的场景。

5.思路与方法论

没有预案之前，发生故障后，需要通过多个工程师共同分析诊断和决策、在多个系统/集群、多个架构层面进行人工分析、人工尝试性修复、多个运维管控系统执行多个操作的过程。应急切换和预案修复的思路是把过去修复故障的团队经验积累下来，系统地设计和梳理潜在的可靠性风险，把故障场景抽象化、修复过程自动化，通过API编排实现一键或少数几个步骤执行，更高效地修复故障，从而缩短故障时长甚至避免故障发生。

亲们，希望各位关注下ICT动态公众号，每天呈现新事物和信息，谢谢