来源|技术领导（ID：jishulingdaoli）您没看错。

本文讨论的主题是“导致主要系统停机的15种方法”。

经过仔细研究，您会发现执行系统停机非常重要。

有技术的东西，团队成员不是瞎子，老板不是傻子，怎么可能看着你造成伤害呢？但是，您仍然必须拥有梦想，梦想就像内衣一样，您必须拥有梦想，但是当您遇到别人时，您不必证明自己拥有梦想。

K先生采访了5位资深技术专家，这些专家具有光荣的经验，例如“删除图书馆并逃之;”。

和“ rm -rf / *”在他们的职业生涯中，总结了导致重大系统停机事故的15种方法。

，每一个都是流血的历史。

1.每周超过15个在线错误。

15个在线错误，这是最低要求，没有上限，越多越好，从而使团队成员对在线问题变得不敏感。

这是一个好的开始。

尽管这只是一小步，但对于主要的系统停机来说却是一大步。

2.每周超过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工具。

不要使用自动化的操作和维护工具，不要找几个操作和维护兄弟，并临时手写外壳脚本。

握手越多越好。

您的演奏很优雅；再检查一遍？什么都不存在，因为信任，所以简单！相信，信念的力量！ 10.请勿使用压力测量工具。

现在该执行一些真正的技术了，多表连接复杂的SQL，开放的多线程，裸奔的代码... 11。

上线时没有回滚解决方案。

回滚计划？如果不成功，你就会变得仁慈。

当您打开弓箭时，没有回头路可走。

当你是男人时，你不会后悔。

在线成功取决于运气。

12.操作和维护可以随意更改在线配置。

操作和维护是放纵对自由的热爱。

这是我，不同颜色的烟火，我是我，我看到自己在生火。

13. DBA在情绪上不稳定。

有人说DBA不是免费的，移动电话必须实时在线并随时待命。

成为DBA之后，我了解到，如果我想删除数据库，我将删除一个数据库；如果我想入狱，则将入狱，而且我非常自由。

14.爆炸性的业务增长。

这项技术几乎已经安排好了，一群热衷于抛掷的市场和运营人员需要每天最多做10场比赛，与各团体战斗直至死亡，提升“ 100减200”，所有这些都是为了压倒一切。

系统，证明技术都是愚蠢的。

15.经常发布专业