今晚我们的其中一个产品的其中一个比较偏的环境出现了一次生产事故， 前端所有请求都发送失败。
我是中途被通知出了事故的，这事甚至惊动了一些领导。
期间有怀疑是我做的前端改动导致的问题。
最终排查，发现是ngix的配置错误导致的，通过修改配置修复了问题。
事情虽然结束过去，也不会直接追究到我的责任，但是想想，还是有问题。
这次事故中，肯定是有人为的过失的，对于过失我们当然应该指出并纠正，还要要求下次不再犯。那么对这个事情的处理是不是这样就够了呢？
我认为还是不够的。
网络上也有过不少出大事故就杀一个程序员祭天的说法，我相信在一些公司里确实有这样的情况发生。但是，我认为出了问题，将问题的绝大部分责任归咎在一个开发、测试或任何一个个人头上，这种做法未必恰当。
因为显而易见的事实是，人经常是不可靠的，人很容易犯错，出错的概率跟人的身心状态、承担的压力、身处的环境等因素密切相关。这次是别人，下次难保就不是我。
如果真的希望生产环境更可靠，我们更应该依靠的不应该仅仅是人的细心、谨慎，更应该依靠工具、方法、流程。
我们用的很多技术、工具、方法本身也是为了降低因为人的不确定性（或不可靠性）对我们的项目或提供的服务的影响， 如各种CICD工具， 自动化测试技术、测试和发布流程等等。
所以这次事件，如果先定性为流程上的问题，那么问题就出在我们没有对出问题的环境进行测试， 而这个测试环节是我们的发布流程中没有的。
这是流程的缺失， 解决方法就是补上这个缺失， 具体怎么补和补到什么程度可以后面再讨论。 那么在补上这个流程确实后，至少下次相同问题出现的概率会大大降低。
这就不容易因为人的不确定性，在下一次有人出现失误（因为忘记、粗心等）时，导致又一次生产问题，进而又要杀一个程序员祭天， 而下一个祭天的，谁知道会不会是你或者我？
而如果从流程上补上漏洞， 我们提供的产品和服务的可靠性自然提高了，祭天出现的几率也就大大降低了。（其实祭天的目的不正是为了提高我们的产品/服务的可靠性吗？）
我们的流程应该是持续改进的，至少每次出现生产事故后都改进流程，那么我们出现生产事故的概率和次数也将持续降低。
好了，那么接着聊聊这次这个事件有哪些可选的改进？
首先，改进也有成本，我们也要考虑成本和收益。
这次事件，因为是全部接口都访问失败，这么彻底的错误，可以通过基本的冒烟测试发现。所以针对这次事件，在发布后增加一轮在发布环境上的冒烟测试即可。
同时因为我们项目的测试人员有限， 透支任何一个岗位的成员都是不可取的，因为透支意味着更容易出错。
所以最差的选项，是让测试人员手动进行一次简单的冒烟测试； 更好的选项是使用自动化测试技术进行简单的冒烟测试。
因为冒烟测试的要求和技术含量相对比较低，编写一个自动化脚本的难度和成本也较低。
前端可以使用cucumber或其他框架，实现一个E2E测试用作冒烟测试，这需要在CICD环境支持并在工具上配置，如Jenkins。
如果成本允许，也可以在前端（当然后端也可以）实现一个简单的契约测试（contract testing），对接口进行简单的测试，如对几个重要接口发送测试请求，看是否有响应或响应是否符合预期，以此判断服务端是否正常工作。
通过E2E实现的冒烟测试+对接口进行的契约测试（可选），基本上可以大大降低相同事故再次发生的概率了。
此外，我们还需要指定一些操作规范，例如发布规范。 例如里面有两条：
1. 不能直接修改生产环境配置
2. 任何改动不能不经过测试就部署上线
当然具体的规范不同团队不同，这个规范也应是持续改进的。
当再次发生事故时，首先我们调研事故的原因， 然后分析这次事故是由于我们团队成员违规操作（不遵守规范的操作）导致的，还是因为我们的流程漏洞导致的。
如果是违规操作导致，那么对不起，违规的人担主要责任，该祭天祭天。
如果是流程漏洞导致的， 那么团队一起担责， 并在解决问题后改进流程补上漏洞。
这样除了可以降低事故发生率、提高产品可靠性，也能避免团队成员人人自危、战战兢兢，减少这些负面情绪可以让团队有更多精力投入到有效的工作中，共同担责也能提高团队的凝聚力。
本文主要是想分享我对于这次事故的一些想法，这些方法可能未必适用于你所在的项目和团队，但如果能在你下次遇到类似问题时，可以让你想到多一种可能或解决方法，那我认为本文就有价值了。
说了那么多，依然不能脱离一个大前提，即“任何方法都有其适用的环节和前提”，流程也不是万能的。本文说的内容是否适用，还是要请你自行判断。
好了，暂时就想到这么多。
谢谢观看