应急处理流程和规范¶

线上故障定义¶

为了让产品研发人员可以更快速恢复问题、解决问题，也为探索更好的保证产品质量的方法，针对线上故障，需要规范的处理流程。

故障是产品存在的错误、毛病等各种问题，也是系统所需要实现的某种功能的失效或违背。何为线上故障？产品开发完成、测试通过并发布后，用户在使用过程中反馈的所有问题都属于线上故障。

线上故障分类¶

软件故障有多重分类方法，如按出现的开发阶段划分，按失效产生的后果来划分等。如何对线上故障分类呢？

步骤1 选择故障分类依据¶

故障有两个重要因素：严重性、优先级。线上故障的优先级在当前所有故障里面是最高的，所以我们对线上故障分类时直接根据其严重性（失效后产生的后果）来分类。

步骤2 定义故障级别¶

确定故障分类依据后，需要基于选择的分类依据制定故障级别。根据故障的影响程度，将线上故障的级别定义如下：
（1）致命故障 Critical：系统崩溃，停止运行，阻碍用户工作继续进行。
（2）严重故障Major：主流程不通，影响系统基本功能。
（3）一般故障 Minor：功能没有完全实现但不影响使用，功能菜单存在缺陷但不会影响系统稳定性。
（4）提示类故障Suggestion：建议优化类问题。

步骤3 制定故障等级列表¶

基于分类依据和故障级别定义制定对应的故障等级列表，后续有线上故障发生时，相关人员可直接参考该列表评估故障等级。下表是基于严重性定义以及区块链实际应用场景制定的一份故障等级列表，将线上故障分为如下4类：

故障级别	描述	错误内容举例
L1	群组或客户端不能正常工作；引起用户对产品严重不满意，造成投诉或放弃使用。	1）节点启动失败、因程序导致的节点连接异常、共识异常导等导致整个群组不能正常工作； 2） Console、SDK等客户端无法正常使用； 3）由程序引起的系统崩溃、死机、程序非法退出； 4）死循环、数据库发生死锁、与数据库连接错误； 5）因程序问题造成资金损失等； 6）安全类问题。
L2	严重影响系统基本功能使用	1）因代码问题引起的节点同步异常； 2）因代码问题引起的部分节点异常但群组能正常工作； 3）程序接口错误； 4）数据库保存调用错误，数据库表、业务规则、缺省值未加完整性等约束条件。 5）导致用户信息泄漏、用户数据丢失等问题。 6）模块无法启动或调用、关联程序调用冲突、内存溢出等稳定性问题、性能问题。
L3	影响系统基本功能使用，但有规避途径。影响次要功能实现或部分场景存在问题。	1）节点在某些场景下表现不符合预期； 2） Console、SDK等客户端在某些场景下表现不符合预期； 3） Console的命令参数未作相关限制； 4）次要功能没有完全实现但不影响使用； 5）脚本错误； 6）响应时间较长、查询时间较长、边界错误等； 7）不严重的概率性问题。
L4	较小错误，使操作者不方便，但不影响功能实现。	1） Console、SDK等错误提示信息等有错别字、语法错误； 2） Console命令的帮助信息描述不清楚； 3） Console命令的页面格式排版不整齐、不规范、不美观； 4） Console命令输入输出不规范； 5）日志种提示信息优化； 6）用户体验问题、优化建议等。

故障处理流程¶

线上故障时有发生，要做到及时响应每一次线上故障，尽快恢复业务，就需要一套规范化、标准化的处理流程来约束团队成员，可以按如下步骤制定故障处理流程。

步骤1 明确故障处理目标¶

对于线上故障的处理，首先需要团队成员对处理目标达成共识。故障处理的目标是尽快恢复服务到正常运行，在生产环境发生故障时要快速恢复服务，减少故障带来的损失以及故障对客户的影响。

步骤2 制定故障处理原则¶

线上故障发生时，团队成员应遵循统一的处理原则，才能快速、和谐地解决问题。对于线上故障，可以制定如下处理原则：
（1）第一时间恢复系统、快速止损，而不是彻底解决问题；
（2）明显资金损失时，要第一时间升级，快速止损；
（3）指标要围绕目标，快速启动应急过程与止损方案；
（4）当前负责人不能短时间内解决问题，则必须进行升级处理；
（5）处理过程在不影响用户体验的前提下，保留现场。

步骤3 定义故障处理时效¶

不同级别的故障影响范围不一样，也就要求处理时限不一样，需要事先对各等级的故障处理时效有明确要求，后续故障发生时各个责任人按照规定的时间要求完成任务。下表是基于故障等级列表定义的处理时限要求：

故障级别	严重程度	处理时限
L1	Critical 致命	立即解决，1小时内修复
L2	Major 严重	24小时内修复
L3	Minor 一般	下个版本解决
L4	Suggestion 提示/建议	尽量在下个版本解决

步骤4 明确故障参与人员及责任¶

下表是根据故障等级制定的故障参与人及责任：

故障级别	参与人员	责任
L1/L2	运维人员	1）评定故障等级、故障上报； 2）同现场用户沟通； 3）拉通开发、测试、项目经理讨论问题； 4）协助用户故障恢复
	项目经理	1）协调资源； 2）统筹组织、遇到问题时向上升级
	开发人员	提供故障恢复方法、定位问题、解决问题
	测试人员	重现问题、回归验证问题
	现场用户	1）搜集问题定位所需日志； 2）故障恢复操作； 3）故障解决后验证问题
L3/L4	运维人员	评定故障等级、故障上报
	项目经理	制定缺陷解决计划
	开发人员	制定缺陷解决计划、定位问题、解决问题
	测试人员	回归验证问题

步骤5 制定故障处理步骤¶

制定故障处理步骤是故障处理流程中最核心最重要的一步。处理步骤确定后，后续团队成员直接按照步骤执行即可。通用的线上故障处理一般可以分为5个阶段：发现问题、定位问题、解决问题、回顾问题、改进措施。

当然，由于每个故障的严重等级不同，因此处理流程也不同。由于L1/L2故障要求尽快修复，L3/L4级别故障在下个版本解决即可，因此，基于通用的线上故障处理方式，结合故障严重程度，故障处理步骤可以分为如下2种。

（一）L1/L2故障处理流程¶

L1/L2级别的故障处理流程如下:
1.故障定级、上报。
收到客户、终端使用用户上报的故障时，运维人员尽快确认故障的有效性，10分钟内评估影响面并定义故障级别。若为L1/L2级别，需立即通知相关人员（项目经理、产品、开发、测试等）成立故障紧急处理小组，组建故障处理群，将故障上报到群里，后续的故障原因排查、故障进展同步和讨论直接在该群里进行。

2.故障恢复、收集故障日志信息。
在运维故障处理过程中，当面对未知的突发事件，一方面是果断处置隔离异常，另一方面是综合收集分析各类信息，为后续定位根因做准备。

L1/L2级别故障发生后，故障紧急处理小组的首要任务是通过一系列措施让现网生产环境先恢复正常工作，快速止损，如修改配置文件、隔离故障点（如隔离故障节点、客户端等）、重启故障节点或应用、回滚节点或客户端至升级前版本（回滚操作需格外慎重，尤其是涉及数据变更时）。

3.故障定位。
基于收集到的现场日志信息，开发人员定位问题根因。在找到问题后需将故障原因和预计修复时间同步给运维人员/答疑值班人员。对于处理时间比较长的故障，紧急处理小组需要每隔30分钟对相关人员同步一次故障处理进展。

若当前定位人员不能短时间内找到问题根因，项目经理需要将该问题往上升级，组织更多的技术专家来一起攻关。

4.问题跟踪、测试设计。
开发人员找到问题根因后，测试人员在内部缺陷系统提交问题单跟踪，并根据故障影响范围设计相关测试用例。

5.故障解决。
找到问题根因后，开发人员需要基于现网生产环境使用版本在指定时间内修复缺陷。测试人员需在新版本回归验证故障是否修复以及测试故障周边功能点是否正常。开发、测试完成后发布新版本至现网，用户验证完成确保没问题后表示故障解决。后续开发人员需要将本次的修改点合入到相关版本。

6.故障复盘、回溯分析。
发生L1/L2级别的线上故障后，需要及时做复盘回溯分析，复盘时主要包括如下点。

复盘时间：故障复盘一般安排在故障处理结束后72小时内。
复盘人员：研发发起，项目经理、产品、开发、测试等相关人员参与。
复盘内容：
故障过程回顾；
故障原因分析；
改进预防措施制定；
故障定级。

故障复盘后一般会输出故障分析报告，包括：故障发生时间、故障报告时间、故障恢复时间、故障持续时间、故障影响范围、故障等级、故障处理人、故障描述、故障处理过程、故障原因分析、后续改进措施等。测试团队可以将这些线上故障资料搜集起来定期组织漏测回溯分析，作为后续测试团队的反向改进措施。

（二）L3/L4故障处理流程¶

L3/L4级别的故障不需要立马解决，其处理流程如下:
1.故障定级、上报。
收到客户、终端使用用户上报的故障时，运维人员尽快评估影响面并定义故障级别。若为L3/L4级别，将故障上报到技术群里。

2.收集故障日志信息。
收集故障点的错误日志信息用于后续问题定位。

3.制定故障解决计划。
对于L3/L4级别的故障，不需要立即解决生产环境问题，要走缺陷排期流程，也就是项目经理、开发人员需要结合当版本计划确定故障的修复计划。

4.问题跟踪、测试设计。
测试人员在内部缺陷系统提交问题单跟踪，并根据故障影响范围设计相关测试用例。

5.故障解决。
依据上述制定的故障修复版本计划，开发人员按时修复故障。测试人员在新版本回归验证故障是否修复、测试故障周边功能点以及数据是否正常。开发、测试完成后走新版本发布流程，用户获取新版本后验证故障是否已解决。

典型案例¶

场景：现网生产环境有4个节点，采用PBFT共识算法，其中一个节点采用MySQL存储模式，该节点进程异常。针对该故障处理流程如下：
步骤1 故障定级、上报
运维人员收到故障反馈后，评定故障为L2级。组织成立故障紧急处理小组，将故障上报到群里。

步骤2 故障恢复、收集故障日志信息
运维人员请用户搜集故障节点的相关日志信息。并让用户将故障节点移除共识列表，添加为观察节点，避免异常节点影响整条链的正常工作。

步骤3 故障定位
开发人员根据搜集的日志信息分析问题根因。该问题原因：表名带有特殊字符的时候，没有对表名加``字符。解决方案：SQL语句拼接的时候加上``字符。

步骤4 问题跟踪、测试设计
测试人员在内部缺陷系统提交问题单跟踪，并根据故障影响范围设计相关测试用例。

步骤5 故障解决
开发人员基于现网生产环境版本修复缺陷。测试人员取对应版本升级，在升级后环境回归验证故障是否修复，以及测试故障周边功能点是否正常。

步骤6 版本发布
开发、测试完成后发布新版本至现网，用户验证完成确保没问题后表示故障解决。待故障节点同步数据完成后，将观察节点加入共识列表。开发人员将本次的修改点合入到其他相关版本。

步骤7 故障复盘、回溯分析
故障解决后，研发侧发起故障复盘回溯分析，输出故障分析报告。

故障发生时间：2020年07月11日10:05:20
故障报告时间：2020年07月11日10:06:20（运维人员收到故障反馈的时间）
故障恢复时间：2020年07月11日10:10:30
故障持续时间：5分钟
故障影响范围：链上一个节点不能正常工作
故障等级：L2
故障处理人：XX（开发人员）、XX（运维人员）、XX（测试人员）
故障描述：4节点环境中，其中一个节点进程异常，不能正常工作。
故障处理过程：
2020年07月11日10:05:20，故障发生。
2020年07月11日10:06:20，收到用户反馈某节点异常工作。
2020年07月11日10:07:40，运维人员评定故障为L2级。
2020年07月11日10:10:30，运维人员搜集好故障节点日志信息，协作用户将故障节点添加为观察节点。
2020年07月11日10:30:30，开发人员故障定位完成，并基于现网生产环境版本修复好缺陷（sql语句拼接的时候加上``字符）。测试人员同步完成问题跟踪。
2020年07月11日11:00:30，测试人员回归验证完成。
2020年07月11日11:05:30，版本发布。
2020年07月11日11:35:30，用户基于新版本验证完成。
2020年07月11日11:45:30，生产环境升级，数据同步完成后，将观察节点加入共识列表。
故障原因分析：当节点采用MySQL存储模式，若表名带有特殊字符时，没有对表名加``字符。
后续改进措施：异常场景考虑不完整，后续测试设计中多考虑特殊字符、表名长度过长、过短等异常场景。