好久没遇到故障了，让技术大佬在公司会议上成了隐身存在，除了汇报进度什么都没有。这是不能容忍的。只有问题才能驱动团队的成长。风平浪静的时候，公司领导认为你做的不好，没有暴露的风险：既然你做的那么完美，那你有什么用。所以做得太好对团队来说未必是件好事——尤其是对一个有迫害妄想症的公司。上面的截图，我看过很多次，展示了一些令人沮丧的现实。对于团队来说，这没有什么不同。及时制造问题是合格管理者的责任。老板骂你一顿，然后继续依赖你，总比老板对你客客气气，然后把你扔进火坑要好得多。打就是亲，骂就是爱，客套就是下场。这是劣币驱逐良币，公司管理层应该避免这种情况。不过我们今天的话题不是这个，而是P1的故障。这不，昨天下午，公司领导的电话响了：“商户账号登不上去，是不是单点登录坏了？”要打完游戏吗？”“赶紧处理！出了这么大的事情，我们要协调一下！”“查看操作记录！是不是有人把数据库给删了。”事情很严重，一个客户直接给老板打了电话。我的脸。赶紧用测试账号登录后台。你输入的密码不对，请稍后再试。难怪有人想删库了。最近网络很不友好，还有玉石俱焚事件频发，在监管者赤裸裸的打压和剥削下，这玩意不小心中了彩票，大家都忙得不可开交，熟练的话，把终端拖到大屏显示器上，并输入命令行；有权就抱臂抱胸，吐口水，指指点点；骂一顿。光是讨论组就有十几个，信息量爆棚。在这一点，保持冷静是一种非常难得的品质。作为领导者，您必须控制自己的盲目指挥能力，减少打电话和@people，并保持基本的事件跟踪。调查人员会因为回复你乱七八糟的指令而错过排错的黄金时间。最后不要沉迷于leader，体会boss的无情。不，直到10分钟后，第一条有用的消息才生成。有同学查看了一下，发现所有的用户密码都被重置了。密码已重置的商家的重置时间惊人地一致。这也是由于在数据库表中增加了updateTime字段，证明操作是由业务发起的，而不是DBA手动修改的。DBA篡改的数据只能在binlog中查找记录，并不会体现在最后一次更新时间。从这一点也可以说明，如果有人真的在做某事，那不是DBA，而是程序员。这个程序员不是通过update语句修改的，而是直接调用的程序。大多数人直接想到阴谋论，因为最近加班太多，不给工资，很容易触动别人敏感的神经。能这样想，证明领导还是有些自知之明的。接下来，还有一个发现：所有的密码重置后，密码都不一样了。这更令人惊奇。如果是程序员或者DBA写的update语句，那么resetpassword应该是一致的。但是现在，用户密码都是随机的。会不会是鬼？通过对员工一一排查，发现故障期间没有代码发布行为，可以排除功能迭代的影响因素。此外，这个影响因素也不能乱报。老板很容易对员工的输出产生疑惑：为什么这么久连一个版本都没有更新，一更新TM就出问题。大概率是外招。可能有人在攻击。很久以前，老大被人安利后被打了个耳光，决定购买一家大厂的保安服务。经过技术研究，发现没有用，就谢绝了大厂。就在我准备放弃的时候，服务出了问题。流量和漏洞漫天飞舞，终于老老实实买了安全检测和安全防护。怎么会这么巧。还有一次，一个人来申请，说你的系统千疮百孔。技术总监以为他吹牛，没理会，没喝水就让他走了。结果晚上业务被疯狂攻击，几近瘫痪。怎么会这么巧。凡事必有果……但是公司做了很多得罪人的事情，一时间实在想不起来得罪了哪位大神。领导们支着下巴若有所思，却怎么也想不通。如果抓不到袭击者，首领就得自己承担责任。安全方面的事情还是需要专业人士来做，是时候让安全团队介入了。BlackTerm一打开，机械键盘一抖，键盘和屏幕开始滚动。一台主机，三台显示器，人物流动，宛如美好的生活。这个时候，相信安保人员的脑子都是乱的。因为他发现，事故是自己造成的。昨天，他只是用了一个安全扫描引擎，然后他在引擎中添加了安全扫描逻辑，并添加了弱口令验证检测功能。在执行这个逻辑的过程中，他一直在尝试登录，但是结果达到了重试的上限，最后触发了一个bug。杀死所有用户。心病需心医，系铃人需解。知道原因后，就可以采取行动了。安全工程师抽了抽，把原因告诉了脸色更冷的领导，认为这与P1的故障无关。领导想。要不是他演技好，兢兢业业，除了给他名声，还要给他一顶帽子，一个模特。后面的事情就容易多了。DBA从binlog中找出受影响的记录，然后整理成SQL语句，然后优雅的握手，问题就OK了。同时，这也说明了系统的脆弱性。如果安全工程师是竞争对手，那么事情就复杂多了，所以安全性还需要继续建设。背锅的战友们，弥补吧。由于问题发现及时，并未引起较大恐慌。这极大地体现了组织协调和应对突发事件的能力。我相信领导者会在公司会议上大放异彩。在接下来的几天里，我从他通红的脸上得到了证实。作者简介：品味小姐姐（xjjdog），一个不允许程序员走弯路的公众号。专注于基础架构和Linux。十年架构，每天百亿流量，与你探讨高并发世界，给你不一样的滋味。
