共计 1399 个字符，预计需要花费 4 分钟才能阅读完成。
让云平台产生重大宕机事变的 15 个办法
把零碎搞宕机是一件十分有技术含量的事件 ，团队成员不是瞎子，老板也不是傻子，怎么可能眼睁睁地看着你搞破坏呢？
然而幻想还是要有的， 幻想就像内裤，要有，但不必逢人就去证实你有 。
作为资深技术专家肯定要经验过删库跑路”、“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 个办法。心愿你把这篇文章转给身边的敌人，时刻用“海因里希法令”给本人和团队敲警钟。
