事故等级评定 and 事故处理流程制度（摘自rrc-wiki）
为加强和规范紧急事故/故障的处理和报告流程，保证事故/故障的快速恢复，使事故损失降低到最低程度，特制定本制度。
一、适用范围
- 本流程适用于XXX所有产品线，所有线上的事故处理。
- 线上事故是指在线上服务中出现的功能故障或中断、数据错误等现象，对用户体检、流量、收入、品牌产生严重影响的现象。
- 除通常意义上的线上事故外，上线后出现紧急回滚或紧急上线，亦属于事故范畴。
- 提前安排并通过审批的服务单点切换、停机、mysql加索引等在约定时间内处理所发生的服务中断，不在事故处理范畴。
二、处理原则
- 降低损失：以降低损失为第一处理原则，尽可能降低和挽回在用户体检、收入、技术团队名誉等各方面的损失。
- 先上报后处理：涉及适用范围内的所有事故或故障采取先上报后处理的原则，各级人员应严格执行通报制度，在规定时间内向相应管理层上报事故及处理情况。
- 及时总结：每一次事故都是一次深刻教训，也是最好的学习机会。要及时总结，积极应对，借助每一次事故，积累经验，壮大自身。
三、事故处理基本流程
- 通报
- 任何可能带来损失的线上服务的中断，无论原因，在收到事故信息开始计，5分钟内，发起向上通报，不得拖延。通报，以确保对方收到信息为准。
- 发现事故之后，必须在15分钟之内，以电话或钉钉形式通知主管及可能受影响的产品线，以减少损失扩大。
- 如果不能或不需在当天处理，需及时通报处理进展和后续的处理方案。
- 要求于事故当天发出事故报告，提交到wiki。事故报告以描述清楚业务影响、处理过程、产品和技术原因为主，如已有明确的改进措施，可附上。
- 处理
- 检查事故原因，在短时间内尽快排除故障，或者确认不是故障；
- 总结
- 一般事故至少需要记录（包括精确到分钟的时间线，精确的PV/UV、线索、金钱等损失）；严重事故及以上需要进行案例学习（Case Study），出台可执行措施，并监督执行，避免后续出现类似问题
- 在事故处理完成后，事故负责方应在一周内召集case study，进一步总结事故原因，分析事故造成的损失，界定事故级别，提出针对性的改进措施，并提交case study报告
- 【待定】对于事故造成严重损失的，参照事故级别，对事故相关责任人进行处罚。
---------------------------------------------------------------------------
错误举例：
事故记录
事故时间：
2018-01-17 19:43:00 至 2018-01-17 23:18:00
共计 3小时35分钟
事故影响：
1.新上架车源无法正常打开详情页，共影响车辆531辆
2.用户登录验证码无法正常校验通过，共拒绝登录人数60+人
事故时间轴：
2018-01-17 21:50:00 接到反馈，验证码无法正常校验通过，同时收到反馈，部分车辆详情页无法正常打开
2018-01-17 22:05:00 当晚没有携带电脑回家，和李建沟通，排查日志后，没有发现明显的慢请求或者错误日志，并且根据监控日志来看，没有大规模报警，初步判断与后端服务无关，当时有怀疑是redis写满导致的问题，由于查看了错误的redis配置，李建排查后反馈redis容量没有问题
2018-01-17 22:35:00 家中电脑临时搭建了环境，可以连接到我们内网环境后，排查了日志及各种redis写入的地方，均没有错误报出，连接线上redis机器后，尝试手动写入key，然后get出为空，查看配置文件与系统参数后，得出结论，redis已经写满，导致数据无法写入
2018-01-17 23:13:00 OP线上动态对redis进行了扩容，验证后正常，redis写入功能恢复，验证码登陆功能恢复正常
2018-01-18 01:05:00 将问题车辆全部进行了重新发布，车辆详情页恢复正常
事故后续跟进措施：
1.定位redis内存满时，返回正常的原因 2018-01-18
2.梳理redis集群的报警，添加内存监控报警 2018-01-18
事故反思
1.c2b服务监控报警不健全，导致无法第一时间排查到问题原因
2.切忌回家不携带电脑，或者家中要常备拥有查看线上服务权限的电脑，线上既是阵地，随时需要处于备战状态
