让云平台产生重大宕机事变的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个办法。心愿你把这篇文章转给身边的敌人，时刻用“海因里希法令”给本人和团队敲警钟。