一次生产事故后感

今晚我们的其中一个产品出现了一次生产事故，前端所有请求都发送失败。

我是中途被通知出了事故的，这事甚至惊动了一些领导。

期间怀疑是我做的前端改动导致的问题。

最终排查，发现是ngix的配置错误导致的，通过修改配置修复了问题。

事情虽然结束过去，也不会直接追究到我的责任，但是想想，还是有问题。

如果后端同事被追究责任，这种处理方法可能不太好。

这种杀一个程序员祭天的做法我认为是很不恰当的。我认为不应该将问题的责任仅归咎到一个开发人员头上。（我也不是说应该归咎于测试人员或其他任何一个个人）

因为显而易见的事实是，人经常是不可靠的，人很容易犯错，出错的概率跟人的身心状态、身处的环境、身边发生的事情密切相关。这次是别人，下次难保就不是我。

如果真的希望生产环境更可靠，我们更应该依靠的不应该仅仅是人的细心、谨慎，更应该依靠工具、方法、流程。

我们用的很多技术、工具、方法本身也是为了降低因为人的不确定性（或不可靠性）对我们的项目或提供的服务的影响，如各种CI\CD工具，自动化测试技术、测试和发布流程等等。

所以这次事件，如果先定性为流程上的问题，那么问题就出在我们没有对出问题的环境进行测试，而这个测试环节是我们的发布流程中没有的。

这是流程的缺失，解决方法就是补上这个缺失，具体怎么补和补到什么程度可以后面再讨论。那么在补上这个流程确实后，至少下次相同问题出现的概率会大大降低。

因为人的不确定性，就不容易因为下一次人的失误（忘记、粗心等），导致又一次失误，进而又要杀一个程序员祭天，而下一个祭天的，谁知道会不会是你或者我？

而如果从流程上补上漏洞，我们提供的产品和服务的可靠性自然提高了，祭天出现的几率也就大大降低了。（其实祭天的目的不正是为了提高我们的产品/服务的可靠性吗？）

我们的流程应该是持续改进的，至少每次出现生产事故后都改进流程，那么我们出现生产事故的概率和次数也将持续降低。

好了，那么接着聊聊这次这个事件有哪些可选的改进？

首先，改进也有成本，我们也要考虑成本和收益。

这次事件，因为是全部接口都访问失败，这么彻底的错误，可以通过基本的冒烟测试发现。所以针对这次事件，在发布后增加一轮在发布环境上的冒烟测试即可。

同时因为我们项目的测试人员有限，透支任何一个岗位的成员都是不可取的，因为透支意味着更容易出错。

所以最差的选项，是让测试人员手动进行一次简单的冒烟测试；更好的选项是使用自动化测试技术进行简单的冒烟测试。

因为冒烟测试的要求和技术含量相对比较低，编写一个自动化脚本的难度和成本也较低。

前端可以使用cucumber或其他框架，实现一个E2E测试用作冒烟测试，这需要在CI\CD环境支持并在工具上配置，如Jenkins。

如果成本允许，也可以在前端（当然后端也可以）实现一个简单的契约测试（contract testing），对接口进行简单的测试，如对几个重要接口发送测试请求，看是否有响应或响应是否符合预期，以此判断服务端是否正常工作。

通过E2E实现的冒烟测试+对接口进行的契约测试（可选），基本上可以大大降低相同事故再次发生的概率了。

此外，我们还需要指定一些操作规范，例如发布规范。例如里面有两条：

1. 不能直接修改生产环境配置

2. 任何改动不能不经过测试就部署上线

当然具体的规范不同团队不同，这个规范也应是持续改进的。

当再次发生事故时，首先我们调研事故的原因，然后分析这次事故是由于我们团队成员违规操作（不遵守规范的操作）导致的，还是因为我们的流程漏洞导致的。

如果是违规操作导致，那么对不起，违规的人担主要责任，该祭天祭天。

如果是流程漏洞导致的，那么团队一起担责，并在解决问题后改进流程补上漏洞。

这样除了可以降低事故发生率、提高产品可靠性，也能避免团队成员人人自危、战战兢兢，减少这些负面情绪可以让团队有更多精力投入到有效的工作中，共同担责也能提高团队的凝聚力。

好了，暂时就想到这么多。

Recommend