造成重大宕机事故：这15招，屡试不爽

 你没看错，本文探讨的主题是“让系统发生重大宕机事故的 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)

本文标题：造成重大宕机事故：这15招，屡试不爽
文章源于：http://www.shufengxianlan.com/qtweb/news12/428762.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联