一次事故反思

大概在一个月前，匹配系统搞出了一次事故。当时写完了事故反思，奈何在提交的时候博客登录态丢了，也没有保存，就懒得再写了。在这个深夜重新写一下吧。

时隔这么久，事故的细节可能已经忘了，但这个过程中还是能留下一些的。

事故说明

事故是匹配系统引入了一个新概念，这个新概念对匹配系统整个进行了一个大的改动，复杂度可以说是指数级的增长。
定这个方案的时候，组长没有和总监（也是匹配系统的设计者）去探讨这个技术方案。最初接需求的时候是另一个哥们儿做的，在眼看要做完的时候，那哥们儿直接离职走了，需求也就到了我手里。最终的结果是由于对匹配系统的掌握不够，加上复杂度确实比较高，最终考虑不周，导致匹配系统在那3天里一直是不稳定的状态。

后来还是删掉了这个东西，才让系统比较稳定的跑着。

事故反思

0、需求合理性

新加的这个东西是boss想要这个，东西乍得听起来确实不难，但从系统的角度，引入这个概念之后是指数级的复杂度增长，带来极大的开发难度。

1、技术方案评审

如果是2天以上的项目，要和项目组技术同学进行技术评审。
如果是比较复杂的开发任务，或比较核心的系统的需求，最好拉上总监进行技术评审。

2、人员安排

这个需求从评审，到方案制定，到开发，开始都不在我手里，眼看着都做了一大半，结果那哥们儿直接离职走了。
然后我才临危受命接了这个需求，导致对需求的理解不那么透彻。内哥们儿直接拍屁股走人，他写代码的时候是怎么想的都问不到，只能自己去理解。

人员安排上尽量要固定一个程序员。

这块也有一个要注意的点，如果自己真的没把握，要及时反馈上去

3、开发时间

上面总是压时间，从对匹配系统几乎不了解，到要求的提测时间，总共也就两周时间。这个时间搞完还是有一定难度的。
这块也是，如果没把握要把状况反映一下（不过在这事情之前组长好像不太能听得进去）

4、精力问题

这个需求所影响到的四个系统，匹配是比较大的一个系统，另外三个系统的改动比较小，但还是我一个人做的。把精力也分到了别的系统上，也是一个小问题点所在。

5、灰度问题

之前在C端的系统中也是我推动了灰度，开发了灰度系统，更多的是针对用户去做灰度。
但匹配这边由于是核心系统，基本上都是一刀切的功能，所以没有使用灰度。如果能有灰度会把风险降到最低。

但这次事故也说明了，大的功能改动或核心系统的改动，能做到灰度就尽量做到灰度。

6、事故预案

在上比较大的功能的时候，最好定一套事故预案，分析都有可能出现哪些问题，并且针对每一种可能出现的问题都给一套事故预案。

7、bug修复与错误数据修复

组长为了用户能尽快提现，在没有理清具体错误的情况下，单纯强制更新了当天的错误数据，用户是能提现了，但也有隐患是后期造成了一些脏数据。

以上。