0%

关于一次线上事故的反思

事故(Accident),一般是指当事人违反法律法规或由疏忽失误造成的意外死亡、疾病、伤害、损坏或者其他严重损失的情况,如交通事故、生产事故、医疗事故等。针对计算机行业,线上事故一般是指当事人因疏忽、失误造成的较为严重的线上bug,影响应用(web/app)的正常使用,进而对个人、企业造成损失的情况。

一、 暴露问题

  1. 并发问题code时一定要考虑,哪怕是再小的应用也会有并发
  2. 日志尽可能的多,尽可能的详细
  3. 事故发生时第一时间查看日志是发现和解决问题的最快方式
  4. 发现事故时不要犹豫,第一时间打patchhotfix进行止损,减少影响范围
  5. 不要怀疑现有大厂API的问题,如果发现API响应有问题,最大可能也是请求数据有问题导致的响应异常
  6. 团队协作的重要性,事故发生时小组内协调好处理方式,各自处理好各自的部分,而不是相同的问题每个人处理一次
  7. 多学几门语言,关键时刻能解决大问题
  8. 工作中多写些常用的小工具,如查询线上用户信息等以便快速处理
  9. 数据库缓存双写不一致问题
  10. 不要以为代码稳了,哪怕是自己写的,哪怕是自己验证过了
  11. 非研发人员的意见仅供参开,应更多的聚焦于事故本身,找到bug出处
  12. 架构师的意见更多的是代码整体的合理性,对业务不熟
  13. 第一时间公告,安抚受影响用户
  14. 数据回滚与否,对研发来说是最便捷的方式,对用户来说是最糟糕的方式
  15. 代码执行异常一定要抛出来,串行执行逻辑越重要的逻辑越要靠前执行(如支付系统,一定是支付完成后才进行后续修改订单逻辑)
    • 使用的NoSQL无法保证事务执行,且涉及数据和缓存双写问题
  16. 关于熬夜,真比不过年轻人了,有时间的话还是要多锻炼身体

二、事故/故障处理流程

  1. 事前

    • 标准化产品流程
      • 产品环节控制风险,流程要考虑完整,了解该类系统常见的漏洞,把握系统中可能出现的风险点,反复推敲并设置监控机制,出现问题第一时间告知相关人;
      • 各环节评审产品经理都需要参加,了解每一步的细节;
      • 技术方案要严谨,分机房上线、压力测试、回滚方案都不可缺少;
      • 核心系统要注意上下游使用者,避免留坑。
    • 企业定义好事故等级,并制定不同级别第一时间的应对策略,不同企业对等级定义不同,如:
      • P0:核心业务重要功能不可用且大面积影响用户; 响应时间:立即
      • P1:核心业务重要功能不可用,但影响用户有限,如仅影响内部用户; 响应时间:小于15分钟
      • P2:核心业务周边功能不可用,持续故障将大面积影响用户体验; 响应时间:小于15分钟
      • P3:周边业务功能不可用,轻微影响用户体验; 响应时间:小于4小时
      • P4:周边业务功能不可用,但基本不影响用户正常使用。 响应时间:小于6小时
    • 制定好预警方案,同步各风险环节需要介入的岗位同事和处理办法。
      • 出现问题前端可进行patch,后端可进行hotfix,运维可暂停应用对外服务等
  2. 事中

  3. 事后

    • 定位损失,书写事故报告
    • 提升优化计划,规避事故
    • 严格执行团队code review流程,对问题代码进行解读
    • 根据事故影响进行不同的赏罚以儆效尤
      • 企业的直接损失(游戏产品最为明显)
      • 企业股价的波动
      • 用户在产品不可用时所带来的经济损失
      • 潜在用户对产品的信心
      • 流失用户

三、参考

  1. 参考一
  2. 参考二
  3. 参考三
  4. 参考四