线上事故对一个软件工程师意味着什么
“嘿，哥们！赶紧来监控室，你刚刚发布的版本导致系统接单量陡降，版本我们已经回滚了”。作为一个软件工程师，接到这样一个电话，心里瞬间肯定“叮咚”一下，会恐慌、质疑、焦躁。
没错，这正是2021年遇到线上事故那刻，我心里的真实写照。一次大的线上事故，对一个软件工程师的职业生涯会产生诸多不利，小则影响当年的评优评先，大则被公司劝退或辞退。
事故的过程以及后果
现在回顾一下当时的事故，依然心有余悸。
由于公司业务的快速发展，部门需要整合，我们团队要从其它组接手一些新的项目。此次事故，就是新项目的一次发布引起的。
大概在2021年某天上午11:30左右，新项目版本开始发布，总共有6台机器。
- 先发布一台机器，业务日志没有任何报错，机器的CPU和内存都是正常，观察了大概5分钟，一切正常。
- 根据前期经验，一台机器没有问题，其它机器发布基本也不会有问题，于是剩下的5台机器就一起发布了。正好到了午饭时间，团队小伙伴都去午餐了，5台机器发布完，差不多30分钟，期间我去了趟卫生间。
- 就在我上卫生间的时候，接到运维小哥的电话：“系统接单量陡降，版本已经回滚”。
当时我完全是一脸懵的状态，系统接单跟我的发布有什么关系，服务的业务日志和监控没有任何异常啊！其实系统接单量，在我发布时候，就一直在持续降低，只是运维人员和我都没有关注到，期间大概持续了半个小时。
下午研发部门负责人，就召开了组内会议，告知了此次事故产生的影响和后期注意事项。由于对业务侧产生的影响较大，我作为第一责任人写了回溯报告，还向公司CTO进行了汇报。
鉴于我还处于新员工阶段，此项目也是刚刚接手，公司对事故没有进行公开处理，只是今年好的考评已与我无缘。
事故原因
直接原因：
- 发布的版本没有拉取master分支最新的代码，导致之前上线的功能不可用 间接原因：
- 和团队信息没有拉齐，版本发布时，其它小伙伴之前发布的代码没有合并到master分支
- 测试验证不充分，连基本的测试场景都没有覆盖到
- 运维人员也不够负责，发布期间连监控大盘也不关注
- 上线发布的机制缺失，代码评审，发布评审都没有
事故总结
谁发布谁负责，虽然其它环节也有责任，但是主要责任依旧是研发人员。基于此次事故，个人经验沉淀。
- 发布版本要通知，发布代码要评审
- 发布项目对上下游的影响，要非常清楚
- 监控大盘的各个业务指标要了解
- 核心链路的发布必须先灰度
- 发布出现异常有兜底措施
大家都有什么线上事故的经验，欢迎评论交流
