這位刪庫的員工顯然是一時頭腦發熱的行為，猶如烈性傳染病一樣，以極快的速度幹掉宿主造成的危害其實對人群是較小的。要實現目標可以用更加有策略的方案。現代大部分企業的運維環境往往是經過這樣的步驟來登入和執行操作的：登入堡壘機，需要堡壘機許可權在堡壘機上登入到線上伺服器，需要目標伺服器許可權執行操作這裡的核心就是堡壘機是會記錄你執行的每一條命令的。執行過的命令會留存日誌。所以想要造成儘量大的危害，需要從三個角度工作：不刪除資料庫，而是在資料庫裡塞滿垃圾資料，把原資料修改成垃圾資料，清除垃圾資料比恢復資料庫困難很多倍，需要人工稽核每一條修改的合理性在堡壘機一層隱藏自己的行為，難以追查來源製造垃圾資料的過程溪水長流，讓公司發現問題時，可能已經過了幾十天甚至幾個月，資料庫舊備份已經不存在了刪除資料庫自然是很激烈的，但很多公司的資料庫許可權經過配置是不能刪除的。而ssh登入資料庫伺服器又是個很敏感的許可權，申請時就會被懷疑。溪水長流的製造垃圾資料可以選擇業務比較重要的庫，比如使用者餘額，庫存等等，涉及到錢的最好。在製造垃圾資料時，避免使用過於隨機的方式，而是可以用比如給使用者增加個20%的餘額之類的方法。這樣使用者沒發現自己餘額不足時是不會提起警惕的。等到公司發現時，損失就已經很大了。堡壘機上的審計日誌只會記錄自己直接輸入的命令。而自己編寫的指令碼再上傳是，執行過程是不會留下記錄的。如果還是擔心，可以加密自己的指令碼上傳，到了伺服器後再解密。指令碼本身可以避開shell、python等常用玩法，而用其他冷門一點的。這樣都可以增加發現的困難性。指令碼的定期執行，簡單的可以用cron，但應該選擇不常用使用者來執行cron，比如某個服務的賬戶。如果擔心cron被發現，也可以用supervisord，或者自己寫個常駐程序等方式來做。對於修改使用者餘額之類的操作，一個注意的要點是避免公司每天的對賬系統發現異常。儘管大部分公司並沒有該系統。通常一個公司對賬系統是允許有一定的誤差的，即每天的帳算不平。如果知道這個比例，使得自己每天修改賬戶的總額不超過該閾值最好，如果不知道，也可以嘗試用每天0.5%之類的比例。十幾年前聽過某航空公司每天算不平的帳有20萬左右。所以，只要自己修改資料庫每天不超過這個額度就可以慢慢的搞死這個公司。最後，如上的方法原則上用幾個月的時間還是可以追查出來責任人，所以跑路還是必要的。

對於涉事員工，若是情況屬實，肯定要吃牢房了，而且還攤上經濟賠償。

對於微盟會：

1若公司內部有完備的應急機制，立即啟動應急預案，第一時間確保系統正常，然後逐步恢復資料（要是沒有應對機制，只能說明運維部門不夠正規，或者領導不重視；另外，這樣的事情發生也說明內部管理不嚴謹）

2若能快速恢復業務，並做好客戶安撫工作，應急公關給力的話，相當於爆炸性的推廣效應。若是公司沒有能力應對此次危機，而且沒有出臺有力措施留住客戶，很可能造成使用者大量流失，從此一路下行。對於微盟的友商或者行業：大家正好趁機發力拉使用者；大家的運維投入會加大，流程規範會加強。

至於真正的原因呢，就不說了吧，能做出這種破壞級別的行為，要承擔什麼後果估計自己早就想明白了。

我們公司就是用的微盟產品，雖然網上傳的沸沸揚揚的是程式設計師被綠，但我覺得可能是疫情導致員工待遇受到不公平遭遇，加之在家辦公無法察覺員工心裡狀態，導致心態失衡的員工一氣之下做出的事情