生产事故对于一线的研发人员始终都是一根紧绷的弦。业务需求又多又紧急，质量和效率要双重保证，即使研发人员对代码质量慎之又慎，其实也无法保证100%不出现生产问题。
既然问题总是无法避免，那么设计怎样的制度才能不影响研发效率，又能较好的提升研发人员的质量意识呢？
一次线上事故
2021年某个阳光明媚的日子，我正在对某次需求进行生产环境的发布，发布完成大概半个小时后，接到运维人员的电话。
运维人员说：“你刚刚发布的服务，引起了业务单量骤降，版本已经进行回滚恢复。”
当时正在吃午饭的我，被立即叫到监控室，和运维人员进行了一番交流和讨论，确实是我本次版本发布引起的问题。
事故回溯
引起事故的根本原因其实很简单，就是我当时发布版本的时候，团队另一个同学前一天也发布了一个版本，而我发布的版本没有把他的代码合并进来，导致了这次问题。
当然这其中本身就涉及到很多研发流程的问题：
- 为什么发布版本这么频繁？
- 同一个团队发布上线和代码合并，没有形成标准的流程和规范吗？
- 为什么这么简单的问题，测试都没有发现？
- 上线发布的时候，监控告警形同虚设吗？
这些问题，不同的公司都会有一套自己的研发标准，来规避人为失误导致的风险。但是总的来说，研发标准设置的严格就会影响上线效率，设置的不严格就会影响上线质量，那么有一套适合自己公司的研发标准就非常重要，这既要保证质量，又不能过于影响效率。
但是不管研发标准定义的如何精准，生产事故在哪家公司，都不能完全避免。这个时候就涉及到事故的责任，到底由谁来承担？
事故追责
事故直接责任人肯定是一线研发人员，毕竟事故是由他直接引起的。那么，把责任归结到开发人员身上正常吗？
我们公司当时其实把责任都归结到我一个开发人员身上了。我记得团队负责人和部门负责人带着我，测试人员一起去跟CTO进行事故回溯，并且团队负责人明确跟我说这次事故的责任由我承担，同时部门负责人也对我进行了严厉的批评，带着这种备受压迫的心态去汇报，结果自然也不会好。
2021年这件事情对我产生了莫大的影响，有些人可能就选择离职了，而我选择了坚持。
这件事情处罚我对吗？
客观上来说，事故由我引起，我是第一责任人没有错，但是一线开发人员谁能保证100%不犯错，而且往往是做得越多，错得也就越多。
站在公司的角度来说：
- 研发人员开发的功能有bug是不可避免的，应该是要设计更好的流程和制度来规避
- 同时也必须告诫所有人，犯错了就是要担责的（要一个开发人员全部担责肯定是不对的？），不然怎么保证大家对生产环境的敬畏心理
站在部门负责人的角度来说：
- 研发同学犯了错，进行批评教育，应该也是合适的，要树立态度和威信
站在团队负责人的角度来说：
- 必须要敢于担责，要开发人员来承担这是缺乏担当的表现
- 要有共情的能力，犯了错要批评没有错，但是要学会识别和理解开发人员
站在我自己的角度来说：
- 这个错误是可以避免的吗？不能给自己找更多的借口
- 这件事处罚我是可以接受的，但是我绝对不会让同样的错误出现第二次
最终结果
这次事故公司最终并没有给我什么处罚，甚至事后HR还跟我进行了一次谈心，怕自己产生过大的心理压力。
但是这次事故，却让我对以后生产发布生产了莫大的敬畏心理，而且学会了全盘监控整体的业务变化，对整体的业务流程掌握的更加透彻。从那以后直到现在，我再也没有出现过任何生产事故。
思考
研发出了生产事故，要不要处罚？
我觉得是不能处罚的，但是要在研发人员心中建立敬畏感。这个可以从事故回溯报告中，来验证研发人员对这件事情的态度和责任心。
流程制度比人要更可靠：
- 测试对质量的把控要更加严格，测试的同学更要反思为什么这么严重的问题，没有验证出来
- 监控和告警要更加实时可靠，靠人为发现问题，永远比系统自动发现问题要慢一拍
研发人员自己对事故一定要认真反思，客观的借口当然是存在，但是一定要从事故中有所成长和收获。
