造成重大宕机事故:这15招,屡试不爽

百家 作者:51CTO技术栈 2020-09-06 09:05:17

你没看错,本文探讨的主题是“让系统发生重大宕机事故的 15 个方法”。


图片来自 Pexels


仔细研究后你会发现,把系统搞宕机是一件非常有技术含量的事情,团队成员不是瞎子,老板也不是傻子,怎么可能眼睁睁地看着你搞破坏呢?


但是梦想还是要有的,梦想就像内裤,要有,但不用逢人就去证明你有。


我访谈了 5 位资深技术专家,在他们的职业生涯中都有过“删库跑路”、“rm -rf/*”等辉煌经历,总结了 15 个让系统发生重大宕机事故的方法,每一条都是一部血泪史。


1

每周超过 15 个线上 Bug


15 个线上 Bug,这是最低要求,上不封顶,越多越好,让团队成员对线上问题变得麻木不仁。


这是一个好的开始,虽然只是一小步,却是系统发生重大宕机事故的一大步。


2

每周超过 3 次线上事故


偶尔出现线上事故并不难,难的是坚持每周都出现 3 次以上线上事故,这需要有坚定的信念。


出现事故以后,让开发在线上进行代码调试,别急着恢复生产,走自己的路,让用户崩溃去吧。


3

新入职开发人员超过 50%


忙不过来就招聘新人,新人来了,立马上手改代码,这样很容易制造出一些莫名其妙的 Bug,离线上宕机的目标又跨进一大步。


4

让高 P 核心开发人员离职

让低等级人来交接


多弄走几个 P6、P7 的开发,让 P4 的人来交接,不需要交接文档,交接速度越快越好。节省成本,老板一定举双手赞成。


5

每周发版超过 4 次


每周要频繁发版,让开发、测试越手忙脚乱越好,线上环境操作次数越多越好,使劲折腾生产环境,常在河边走,就看你的鞋什么时候湿。


6

程序员连续 996 超过 45 天


996 是 TMD 福报,需求往死里压,不累吐血几个决不罢休,让开发身心疲惫,精神恍惚,出错概率又增加 10%。


7

迭代中需求变更率超过 40%


有一句话叫做“杀死一个程序员不用枪,只需要改三次需求”,三次太少了,需求变更率 40% 起步,越频繁越好。


还是友情提醒一下,产品经理的背包里常备一些板砖、跌打药、遗书之类的东西,临时去弄怕来不及。


8

开发、测试人员比例 8:1 以上


都是天才全栈工程师,还要啥测试啊。我就遇到过一个天才程序员站在我面前,我们注视了很久,惺惺相惜,直到手累了,我才慢慢放下镜子。

9

不使用 DevOps 工具


别弄啥自动化运维工具,找几个运维兄弟,临时手写 Shell 脚本,手越抖越好,玩的就是飘逸;double check?不存在的,因为信任,所以简单!相信,相信的力量!


10

不使用压测工具


是时候表演些真正的技术了,多表联结复杂 SQL,多线程开到飞起,代码裸奔......


11

上线无回滚方案


回滚方案?不成功便成仁,开弓没有回头箭,落子无悔大丈夫,上线成功与否,全靠运气。


12

运维随意更改线上配置


运维就是要放纵不羁爱自由。这就是我,颜色不一样的烟火,我就是我,我看到自己都冒火。


13

DBA 情绪不稳定


有人说 DBA 不自由,手机要实时在线、随时待命。做了 DBA 以后才知道,想删库就删库,想坐牢就坐牢,自由得很。


14

业务爆发式增长


技术这块已经安排得差不多了,还需要有一群爱折腾的市场和运营人员,秒杀一天搞上 10 场,拼团往死里整,促销“满 100 减 200”,一切以压垮系统为目的,证明技术都是傻 X。


15

经常发布重大版本


别整啥敏捷开发,统一两个月发版一次,要搞就搞大版本,系统宕机了还找不出是哪出的问题,因为几乎所有模块都改了,就问你酸爽不酸爽?


不管你愿不愿承认,我们在日常工作当中,都在或多或少地践行着以上 15 个方法。


希望你把这篇文章转给身边的朋友,时刻用“海因里希法则”给自己和团队敲警钟。


系统宕机只是一个结果,雪崩的时候,每一片雪花都在勇闯天涯,没有谁是真正无辜的。


作者:Mr.K

简介:知名电商公司技术老K级人物。文出过畅销书,武做过 CTO,若非生活所迫,谁愿一身才华。

编辑:陶家龙

出处:转载自公众号技术领导力(ID:jishulingdaoli

精彩文章推荐:

程序员违反竞业协议,被要求赔偿35万
那个写脚本的架构师,被开除了...
十张图说清Elasticsearch原理!

关注公众号:拾黑(shiheibook)了解更多

[广告]赞助链接:

四季很好,只要有你,文娱排行榜:https://www.yaopaiming.com/
让资讯触达的更精准有趣:https://www.0xu.cn/

公众号 关注网络尖刀微信公众号
随时掌握互联网精彩
赞助链接