事故处理

事故原因

• 组内信息不对称：产品对于业务、技术|测试对于产品的业务理解有偏差导致最终上线的功能出现问题，引发操作失败或者数据问题；

• 组间信息不对称：很多功能很有可能是跨系统跨部门甚至跨公司，由于信息不一致或者理解偏差，有可能会导致实现方案不一致，引发操作失败或者数据问题；

• 技术实现缺陷：普通情况下无问题，当特殊组合情况或者流量、数据量超出一定范围时引发的系统不可用、崩溃或者数据问题；

• 数据信息泄露：关键数据泄露；

事故阶段

事前

1. 消除组内信息不一致：对于一些复杂度较高的功能点，最好能够确保大家的理解是一致的，因此如果条件允许，需要能够做到参与软件开发流程的各位能够提供相应的文档供大家评审，产品对应产品需求文档，技术对应技术方案文档，测试对应测试用例，同时最好有人能够跟进这些步骤履行了；

2. 消除组间信息不一致：对于跨系统、跨部门、跨公司的功能项，需要有一个总体跟进人，能够对多方业务都能有比较好的理解，同时参与多方的方案评审，确保信息一致，方案无误，按时执行；

3. 技术方案缺陷：符合业务逻辑的方案开发完毕后，可以应对一般情况下的使用。不过还是会有一些漏掉的逻辑问题、性能问题、可用性问题困扰系统使用，常见的预防方式有压测（通过压测探知系统的承载能力）、隔离（尽量避免系统因为某些模块的原因导致整体不可用）、预案（能够有失败转移、降级、限流之类的手段）；

4. 提前暴露问题：测试环境的部署架构、数据量最好可以保持与线上环境靠近，让问题提前暴露；

事发

1. 监控：最好能够做到各个服务的监控，包括业务系统、中间件。中间件可以搭建开源的管控平台监控，业务系统不仅需要监控机器状态，还应监控核心模块状态，如果条件允许可以监控一些长流程的链路；

2. 报警：必要的报警措施，主动发现错误，避免错误发生时间拉长，影响范围拉大，一般有邮件、短信、微信报警等；

事中

1. 回滚：如果发现功能有问题导致操作，通过tag回滚版本，对于本次版本更新的数据，时间允许应该考虑如何回滚；

2. 降级：对于一些引发数据错误的问题，应该及时降级，避免扩大事故范围；

3. 补偿：对于一些因为网络抖动引发的问题，如果可以重试，在合适的时间点做手工补偿，对于一些贯穿整条链路的数据错误应该及时补偿，补偿时最好做double-check，避免修出新问题；

事后

1. 复盘；

2. 思考；

3. 修复；

事故分级

首先需要明确分级维度，可以参考事故持续时长、事故影响范围、事故恶劣程度；

• 事故持续时长：

  1. 1 小时以上（一般事故）；

  2. 1 小时~1 天（较大事故）；

  3. 1 天及以上（严重事故）；

• 事故影响范围：

  1. 数据量较小、补救时间在 1 小时以内（一般事故）；

  2. 数据量较大、补救时间在 1 小时~1 天（较大事故）；

  3. 数据量很大、补救时间在 1 天以上（严重事故）；

• 事故恶劣程度

  1. 事发后及时补救（一般事故）；

  2. 事发后未及时补救（至低较大事故）；