最近有几件事情，分享与大家。

故障

第一件事情：背了一个故障，不大不小的P4资损故障，最终未追回金额约200块钱。

背景

原因说来挺简单的，跨团队的人找来需要配合做一个技改，需要下线一个A Topic的metaq消息，迁移到B Topic上。本来自然的改法就是创建一个新的B Topic订阅，将原来的A Topic的消费逻辑迁移过来。但是因为：

  1. B Topic比较特殊（流量巨大），导致申请B Topic订阅需要审批后找中间件的人手动创建订阅关系。
  2. B Topic在现在代码中已有订阅。

很自然的，改法变成了复用原有的B Topic订阅关系，修改订阅关系指定的Filter SQL，将A Topic的订阅逻辑合并进来，免去了审批，减少了计算资源，完成了任务。

天时

项目发布需要修改A Topic的消费逻辑。

地“利”

B Topic不支持灰度环境消费，需要发布线上，才能满足项目灰度要求。

所以考虑在项目发布前，单独开了一个前置发布窗口，准备代码发布上线

人和

发布前，项目组成员一起review了这段改动，大家都觉得应该新增订阅关系，但是基于背景的几点考虑，大家都一起陷入了思维定势，觉得这个改OK，也忽略了老代码的防御缺失。

第一批发布后，因为订阅关系的改变，导致未发布机器使用老代码消费了额外的消息，引发故障。

想要把事情做完的是一个很自然的诉求，大家都追求把事情做完。

上面这件事情是个很自然的把事情做完的过程，但是仅仅是把事情做完，往往会导致很严重的后果，比如上面的故障。如果第一步坚持走订阅审批，第二步走紧急发布审批，出现问题的几率会不小很多？

把事情做对，无疑需要耗费成倍的精力。

从组织层面，就需要思考怎么降低大家把事情做对的阻力，怎么引导大家从对的角度思考问题。

灰度问题

还是这个项目，发布后还在灰度验证阶段，需要依赖前台流量入口应用的灰度配置。今晚切了一个仓到灰度，找了该团队的同学帮忙配置灰度，他的做法是，直接修改一个已有的灰度规则，将里面的灰度规则替换成我们的灰度规则：

尽管实现的效果是一样的，我也没有异议，但是过了一个小时就出现了意外。这个灰度规则被该团队的另一个同学误停用了。原因也很简单，他不知道那个规则的目的，处于发布后停止灰度的考量，就统一停用了一批灰度规则。

导致的后果就是我又订了一个小时的数据。

正确的方式是怎么去做呢？那个误停用我规则的小伙伴就做了一个正确的示范：专规则专用

用上面第一个方法当然更简单，少了非常多的操作，但是也给我带来了后续的麻烦，而第二个方法却是更正确的方法，如果直接这么做了，显然可以减少后续无谓的投入。

因为是别人团队的灰度规则，我请别人代为配置，如果我要坚持别人做正确的配置，我和他都需要耗费额外的精力，但是我想了下，如果我坚持正确的方式，他应该不会表示反对，反而是如果我默许了，出了问题，反而他会觉得我没有好好把关，因为显然大家都更喜欢怪别人。

所以一样的，要从系统的角度去避免这个问题，做正确示范，不要让大家想当然。

妥协的顽疾

上面两件事情，显然出现问题后解决问题的投入要远远大于第一次把问题正确解决需要耗费的投入（从整个组织层面）。但是为什么第一时间都选择妥协于当下的投入？

我发现这里存在的认知误区：

  1. 把事情做完有明显的收益
  2. 把事情做对而且做完的边际收益很低
  3. 如果要麻烦别人，尽可能降低门槛才能打动别人

从代码工程师的角度思考，显然大家都想把事情做对，但是面临这三个普遍的误区，很容易步入“把事情做完”的误区。

要解决这个问题，有两个思路：

  1. 系统约束，而非制度约束：如代码规约扫描，自动化用例等
  2. 工程师的文化，给予大家把事情做对的鼓励，减少功利的做完事情的浮躁

显然这两个思路在对组织的要求是非常高的，从我做起的话，就要避免上面几个认知误区，共勉。