又一P1故障，锅比脸圆

原创：小姐姐味道（微信公众号ID：xjjdog），欢迎分享，转载请保留出处。

好久没遇到故障了，以至于技术老大在公司会议上，都成了隐形的存在，除了汇报进度一无是处，这是不能容忍的。

只有有问题才能驱动团队的成长。风平浪静的时候，公司领导以为你做的不好，没有暴露风险：既然已经做的这么完美了，要你何用。

所以做的太好了，对团队来说未必是一件好事---尤其是对于有受迫害妄想症的公司来说。

上面这个截图，我已经见过很多次了，展示了一些无奈的现实。对于团队来说，也没啥两样。

及时制造问题，是一个合格的管理者应尽的责任。老板骂你一顿，然后接下来继续倚仗你；比老板对你客客气气，然后接下来扔你进火坑，要妙的多。

打是亲，骂是爱，客客气气要完蛋。

这就是劣币驱逐良币，公司管理要避免出现这种情况。但我们今天的主题不是这，而是一个P1故障。

这不，昨天下午，公司领导的电话就被打爆了：

“商户的账号都登陆不上了，单点登录崩了么？”

“这次影响面很大，用户什么都操作不了了，系统要完玩么？”

“抓紧处理！出了这么大的事，要协调起来！”

“查一下操作记录！是不是有人删库。”

事情很大，有客户直接call了老板。圣旨层层传递，终于到了苦逼的研发部。

躲在角落里的我，一脸蒙圈。赶紧使用测试账号登录后台。

您输入的密码错误，请稍后再试。

这也难怪有人想到了删库。最近互联网戾气严重，频繁出现玉石俱焚的事件。在各主管毫无掩饰的压迫和剥削下，这玩意一不小心就中彩了。

所有人都手忙脚乱的忙活起来。技术好的，把终端拖拽到大屏显示器上，噼里啪啦打着命令行；权利大的，叉着胳膊抱在胸前，唾沫四溅指点江山；脾气爆的，找几个管事的负责人劈头盖脸一顿臭骂。

光讨论组就拉了十几个，信息铺天盖地而来。

到了这个时候，保持冷静是非常难能可贵的品质。作为领导，要控制自己瞎指挥的本事，少call电话少@人，保持基本的事件追踪即可。排查人会因为回复你这些乱起八糟的指令，错过了问题排查的黄金时段。

不要到最后过足了领导的瘾，领教了老板的狠。

这不，直到10分钟后，才产生第一条有用的信息。

有同学排查发现，所有的用户密码都被重置了。密码被重置的商户，重置时间都出奇的一致。

这也是得益于在数据库表中加了updateTime这个字段，证明操作是由业务发起的，而不是DBA人为修改的。

DBA篡改的数据，只能到binlog里去找记录，而不会体现在最后更新时间上。

从这一点也可以说明，要是真有人搞事的话，不是一个DBA，而是一个程序员。

这个程序员不是通过update语句进行的修改，而是直接调用的程序。

大多数人直接想到了阴谋论，因为最近加班太狠了，又不给钱，容易触发到某个人敏感的神经。

能这么想，证明领导们还是有点自知之明的。

接下来，又有另外一个发现：所有的密码被重置之后，密码都是不相同的。

这就更加神奇了。如果是程序员或者DBA写的update语句，那么重置密码应该是一致的才对。而现在，用户密码都是随机的，难道是鬼干的么？

通过员工的挨个调研，发现在故障的这段时间里，并没有代码的发版行为，可以排除因为功能迭代这个影响因素。再说了，这个影响因素也不能乱报，容易让老板对员工的产出产生怀疑：怎么过了这么长时间连个版本都没更新，一TM更新就出问题了。

那大概率是外部搞鬼了。可能是有人在攻击。

很久之前，老板被人安利后，一拍脑袋，决定购买某大厂的安全服务。技术调研之后，发现并没有什么卵用，于是婉拒大厂。

正打算放弃的时候，服务就出问题了。流量和漏洞铺天盖地而来，最终老老实实买了安全检测和安全防护。

怎么就这么巧。

还有一次，有个小伙来应聘，说你们的系统千疮百孔。技术总监认为他在吹牛皮，无视之，水都没喝就让走了。结果，在晚上服务受到了疯狂的攻击，接近瘫痪。

怎么就这么巧。

百因必有果...

但这种得罪人的事，公司没少干，一时间还真想不出是得罪了哪位大神。领导们托着下巴冥思苦想，不得要领。要是捉不住这个攻击者，这锅就得有领导亲自背了。

安全的事情，还是得专业的人来做，该安全团队的人出马上阵了。

黑Term一开，机械键盘一抖，键盘和屏幕就晃晃悠悠滚动起来。一个主机，三个显示器，字符流淌如优美的生活。

这个时候，我相信安全人员的脑子是懵逼的。

因为他发现，事故，是由他自己引起的。

昨天，他刚刚使用了一款安全扫描引擎，然后，他在引擎中增加了一个安全扫描逻辑加弱口令验证检测功能，这个逻辑在执行期间，一直尝试登录，结果达到了重试次数上限，最终触发了bug。搞死了所有用户。

心病还须心药医，解铃还须系铃人。知道了原因，措施就好办。

安全工程师扭扭捏捏把原因告诉了面色逐渐变冷的领导，心想这P1的锅是没得跑了。

领导心想。如果不是他平素里表现良好，尽职尽责，除了给他个锅带，还要给他搞顶帽子，抓个典型。

后续的事情就容易多了，DBA从binlog里找到受影响的记录，然后整理成SQL语句，然后潇洒的一甩手，问题就OK了。

同时，这也证明了系统的脆弱性。假如安全工程师是竞争对手的人，那事情就复杂的多了，所以安全还需要继续建设。背锅的同志，将功补过吧。

由于问题发现及时，并未引起较大恐慌。这极大的体现了组织的协调能力，和应对紧急事件的响应能力。

我相信，领导一定会在公司会议上大放光彩。从接下来几天他红扑扑的脸上，我得到了验证。

作者简介：小姐姐味道  (xjjdog)，一个不允许程序员走弯路的公众号。聚焦基础架构和Linux。十年架构，日百亿流量，与你探讨高并发世界，给你不一样的味道。我的个人微信xjjdog0，欢迎添加好友，进一步交流。

这里有几篇味道相近的文章