一次生产事故后感

2021年7月21日 15点热度 0条评论

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

 

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

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

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

 

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

 

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

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

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

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

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

 

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

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

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

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

 

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

 

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

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

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

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

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

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

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

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

 

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

 

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

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

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

 

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

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

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

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

 

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

 

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