今天已经下班，也已经走到半路了，接到电话，线上出了点情况，要回单位一起评审一下。接到电话，原以为会很快，可以处理完赶回家吃饭，没想到搞到8点半，只好和家人说声抱歉了。
问题不是很难查，出了问题后，开发人员很快就定位到原因了，不过也仅限于这次的问题本身。在处理过程中，有几个感悟：
不一定要变更才会引入风险
这次的问题在生产上存在已久，但是概率很低，所以多年来一直没有出现。但在分析后，发现一个类似问题也会发生，而随便抽查一天的日志，竟然发现那个问题，这说明那个问题的概率得有多大啊，幸亏对业务没有影响，也因此一直都没有引起注意，没有暴露。
我一直都不喜欢别人在出问题时，还没分析就说“我没动过这里”、“XXX地方也是这么做的”。已经存在的东西未必就一定没有问题，在别的地方正确的东西，拿过来也未必一定正确。一切都要具体分析。我们也遇到过几千用户用了几年都没问题，某天就有一个用户出问题了。以前也发现过潜伏了十多年但一直没有被触发的缺陷。以我这些年的经验，小概率事件，只要时间足够，终会在某个时间发生，特别是按照墨菲定律，在某些关键时点发生。以前不出事不代表以后不出事，一切都要以事实说话。
经验还是很重要的
今天的问题，一看代码就明白问题的根源了，无他，惟手熟耳。类似的坑我也见过，不一定踩过，但一定是想过，所以很敏感，当听到问题在这段时，马上就能确定了。
如果是没有经验的人，看看代码挺正常的，没啥毛病，但落在有经验的人眼里，这代码风格明显不对，违反了编码的原则，因此引入了风险。平时还需要认真分析上下文，看看这风险是否会变成问题，但在明确问题在这都情况下 直接就能确定了。
经验这东西有点虚无缥缈，但确实存在。就像《重构》中说的，代码有种bad smell时就应该重构。但怎么处理好潜在的风险和变更风险之间的关系，我觉得也是需要思考的。一般来说，没有证据，只是bad smell的话，很难推动一个变更。如果有全自动化的测试，应该能大大降低变更风险，是一种有效的手段。
举一反三
今天的问题出在一个点上，但在发现问题后，顺便想想上下游有没有类似问题？认真排查了一下，果然下游也有类似的问题，不过下游的问题只影响单个用户，不排除已经出现过而大家没有注意。
出问题的场景是类似的，原因也是类似的。在这种情况下，我们需要能多想一点，不只是就事论事，而是要举一反三、见微知著，把点扩成线，把线扩成面，把事故变成经验，变成自己的财富。
未雨绸缪
问题发生了，后续处理也是很重要的。这次的事件发生后，及时定位并修复问题固然重要，但仓促修复可能会引入新的问题，而如果不及时修复，就必须面对问题可能再次发生的风险。人非圣贤孰能无过，谁也不能保证不出问题，但必须未雨绸缪，准备好应对措施。
这次的问题，经过分析发现可能在监控上是看不出问题的，只能查日志。为此，大家就对如何查、如何自动分析进行讨论，得出一个简单易行的方案。在有了检测手段，又有了应对手段后，大家终于可以放心地好好准备后续的报告了。
网友评论