事故(Accident)，一般是指当事人违反法律法规或由疏忽失误造成的意外死亡、疾病、伤害、损坏或者其他严重损失的情况，如交通事故、生产事故、医疗事故等。针对计算机行业，线上事故一般是指当事人因疏忽、失误造成的较为严重的线上bug，影响应用(web/app)的正常使用，进而对个人、企业造成损失的情况。
一、 暴露问题
- 并发问题
code时一定要考虑，哪怕是再小的应用也会有并发 - 日志尽可能的多，尽可能的详细
- 事故发生时第一时间查看日志是发现和解决问题的最快方式
- 发现事故时不要犹豫，第一时间打
patch或hotfix进行止损，减少影响范围 - 不要怀疑现有大厂API的问题，如果发现API响应有问题，最大可能也是请求数据有问题导致的响应异常
- 团队协作的重要性，事故发生时小组内协调好处理方式，各自处理好各自的部分，而不是相同的问题每个人处理一次
- 多学几门语言，关键时刻能解决大问题
- 工作中多写些常用的小工具，如查询线上用户信息等以便快速处理
- 数据库缓存双写不一致问题
- 不要以为代码稳了，哪怕是自己写的，哪怕是自己验证过了
- 非研发人员的意见仅供参开，应更多的聚焦于事故本身，找到bug出处
- 架构师的意见更多的是代码整体的合理性，对业务不熟
- 第一时间公告，安抚受影响用户
- 数据回滚与否，对研发来说是最便捷的方式，对用户来说是最糟糕的方式
- 如果回滚，确定数据是否回滚全面，如玩家数据回滚了，邮件未回滚，在后期实现算法时会有问题
- 代码执行异常一定要抛出来，串行执行逻辑越重要的逻辑越要靠前执行(如支付系统，一定是支付完成后才进行后续修改订单逻辑)
- 使用的NoSQL无法保证事务执行，且涉及数据和缓存双写问题
- 关于熬夜，真比不过年轻人了，有时间的话还是要多锻炼身体
二、事故/故障处理流程
事前
- 标准化产品流程
- 产品环节控制风险，流程要考虑完整，了解该类系统常见的漏洞，把握系统中可能出现的风险点，反复推敲并设置监控机制，出现问题第一时间告知相关人；
- 各环节评审产品经理都需要参加，了解每一步的细节；
- 技术方案要严谨，分机房上线、压力测试、回滚方案都不可缺少；
- 核心系统要注意上下游使用者，避免留坑。
- 企业定义好事故等级，并制定不同级别第一时间的应对策略，不同企业对等级定义不同，如：
P0：核心业务重要功能不可用且大面积影响用户； 响应时间：立即P1：核心业务重要功能不可用，但影响用户有限，如仅影响内部用户； 响应时间：小于15分钟P2：核心业务周边功能不可用，持续故障将大面积影响用户体验； 响应时间：小于15分钟P3：周边业务功能不可用，轻微影响用户体验； 响应时间：小于4小时P4：周边业务功能不可用，但基本不影响用户正常使用。 响应时间：小于6小时
- 制定好预警方案，同步各风险环节需要介入的岗位同事和处理办法。
- 出现问题前端可进行patch，后端可进行hotfix，运维可暂停应用对外服务等
- 标准化产品流程
事中
- 停服或hotfix屏蔽功能，减小影响范围
- 预估影响范围，决定处理方案，如回档或脚本处理
- 联系运维、DBA等相关人员，拿到玩家操作日志(自定义日志或数据库日志)
- 明确事务原因，确定算法
- 实现算法
- 验证算法
- 线上执行
事后
- 定位损失，书写事故报告
- 提升优化计划，规避事故
- 严格执行团队
code review流程，对问题代码进行解读 - 根据事故影响进行不同的赏罚以儆效尤
- 企业的直接损失(游戏产品最为明显)
- 企业股价的波动
- 用户在产品不可用时所带来的经济损失
- 潜在用户对产品的信心
- 流失用户