谈谈事故和复盘

最近团队内一个小伙伴因为上线导致了一个事故，影响面还比较大。就产生了一些感慨和想法。

事故起因是因为上线导致了容器内某个路径下的配置文件被覆盖，从而引发了雪崩，导致其他的系统受到了影响。当然本质上这次上线修改的代码跟这个配置文件没有任何关系。

然后小同学在上线中没有去回归一下系统功能，咵咵咵的就点完了上线。

团队内的老同事都认为事故完全是因为该小伙伴上线不规范造成的，没有在预览机上观察。

我的观点是：

上线过程的不规范不是造成事故的根本原因。我们的规范只是为了规则事故的发生，或者事故影响面的扩大。

所以我们应该关注的除了上线规范这个事情外，还要分析一下事故产生的根本原因，怎么去解决，然后从根本上杜绝类似事件的发生。

那么，这次事件，我认为应该从以下几个方面考虑。

设计层面 - 架构设计不合理

1. 不同的业务放在同一个代码仓库里，A业务改A业务的需求，上A业务的节点；B业务改B业务的需求，上B业务的节点。 这种情况不出事就怪了，所以我们要做好代码隔离，不同的业务要有不同的代码仓库。即使需要共用同一个代码仓库，那在任何一个业务方改动了代码的时候，都要同步更新所有的上线节点。就算出问题也在第一时间发现，而不是过了十天半个月，或者更长时间后，另一个业务方将别的业务的改动带上线。

2. 不同的项目使用了同一套的配置文件，任何一方的配置发生了变动，都会同步到所有关注该配置文件的项目。 需要做配置隔离。除非是业务无关的基础组件/基础库，不应该出现多项目耦合情况。

基建层面

1. 部署平台不合理，部署平台的特性，会在上线的时候同步所有容器上的配置。 这里要说一下，这个部署平台A其实在去年已经不维护了，新的服务都已经部署了平台B上。这里只是说机制上的不合理，并不是非要分锅。

不过这一点几个老同事的说法是，你要在这个平台玩，你就要熟知这个平台的特性。并举了个redis原理的例子，你不懂这个，就瞎用，出了事你得负责。

这一点我是部分认可，我们确实要了解所使用的工具和平台。不过另一方面，平台设计的不合理，那也是值得说道说道的，不可能我上线了一个A项目，A的业务屁事儿没有，八竿子打不着的B业务挂了。我上哪儿说理去？

而且，工具和平台这种东西要尽量的傻瓜式操作，降低使用门槛，不然你这个工具一堆坑，我在使用之前还得先研究个一年半载，公司养的起吗？就算公司养的起，程序员恐怕也不愿意，不是浪费我们的时间吗，影响我的进步。

回到老同事说的redis的例子，我认为也不对。因为redis使用就是有门槛的，不然为什么面试的时候都要问呐，要确保你不用到公司了现学呀。

所以，我们不能说存在即合理。

所以说，平台的不易用，也是逃避不了的一个问题。

这里吐槽一下，某度的基建是真的难用，门槛很高。

维护交接层面

这个项目是从策略团队交接过来的。策略团队搞的工程项目确实很垃圾，当然这并不是他们擅长的事情，也不能过多吐槽。

但抛却工程技术，从工程规范上来讲，策略同学搞工程也太不规范了，居然还有些项目是直接登上服务器vim修改代码的。。。连代码管理都没有，更别提文档了。。。

回到这个事故，A部署平台去年已经不维护了，理论上来说应该迁移道B部署平台，然而策略同学没有迁移，就这么在没人维护的平台上裸奔了一年半载。。。

交接过来的就是一堆屎中屎，那怎么可能不出事呢？