你沒看錯，本文探討的主題是“讓系統發生重大宕機事故的 15 個方法”。

[[340888]]

 

圖片來自 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 以上

都是天才全棧工程師，還要啥測試啊。我就遇到過一個天才程序員站在我面前，我們注視了很久，惺惺相惜，直到手累了，我才慢慢放下鏡子。

[[340889]]

 

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)