21

又一P1故障,锅比脸圆

 4 years ago
source link: http://mp.weixin.qq.com/s?__biz=MzA4MTc4NTUxNQ%3D%3D&%3Bmid=2650521203&%3Bidx=1&%3Bsn=ecb07970219397695e8c058085ecc1a9
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

e6JBVrU.gif

原创:小姐姐味道(微信公众号ID:xjjdog),欢迎分享,转载请保留出处。

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

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

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

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

7z6JfqI.png!web

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

怎么就这么巧。

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

怎么就这么巧。

百因必有果...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

EnUneen.gif


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK