GitLab誤刪生產數據庫？

謝謝邀請回答。

這方面有位朋友曾回答過，我分享下。

俗話說，出來混早晚要還的。俗話又說，常在河邊走，早晚要濕鞋。俗話還說，好了傷疤忘了疼。

好多人喜歡追捧小公司那套：全棧、devops[1]啥的。七八年前，有個人來我們組，過了一陣子他覺得不爽，他說：他們以前在某某某地方都可以自己直接進production環境去改東西的，為什么在微軟這里管的那么死？我們那時候數據庫操作只有dba有權限，我們那些做開發的只有讀權限。要在db里面改東西，要寫好步驟或腳本、給dba開一個ticket去做的。我們當時甚至連讀權限都沒有的，因為要防止有人寫很愚蠢的query把表給鎖了。我們當時都是去讀replica的。小公司沒這些限制這些分工，的確很爽啊，但記住，出來混遲早是要還的。當然，一百個這樣的公司里也許只有兩三個會遇到刪庫級別的大事故，剩下九十幾個幾年下來都安然無恙。這叫survivor's bias。大公司為什么成本高、動作慢？就因為有這些東西拖累。你想，如果gmail或者onedrive一下丟了好多郵件而且恢復不出來了，會怎么樣？整個公司也許就從此聲譽掃地了。我在Azure，Azure里面在安全和災備上花的力氣海了去了。

有人說到要做備份，要有災備方案，要演習。但這次gitlab發現備份也是壞的。怎么判斷備份是不是好的，這其實是一個哲學上（或者方法論上）的困境：你刻了一張盤，不可以播放，但是要確保有朝一日需要播放的時候可以放。這有點像家里的滅火器：你要確保滅火器可以用，但是又不能用，因為一只滅火器一用，就沒用了。有人說，你可以找一個測試環境，把備份恢復出來看看。我跟他們說：你可以這樣做，但是你沒法確保備份里面的每一條數據都是對的。你就算能驗證備份里面99%的數據是好的，但是萬一剩下1%里面有data corruption，也許到時候就是致命的：可能你的code沒法handle那種corruption，導致你的code就崩了。搞到最后，能用的也就是做做diff、弄個hash啥的。但是還是沒有根本性的解決這個方法論上的困境。

大公司里面那些做備份、disaster recovery的活其實不怎么受待見，因為做的東西說不定好多好多年才用到一次。等用到了，說不定做的人都已經走掉了。而且，到底好用不好用也不知道，再怎么演習也還是不能百分之百的確信。備份（跟容災不一樣）這事兒跟最近的Survivalist那檔子事有點像，都是很奢侈的一件事情，只有財大氣粗的人（公司）才搞得起。

--

[1] 別誤會我的意思，現在微軟里面也比以前敏捷很多，dev會干很多devops的事情，很多以前一季度上線一次的組現在都改進到每周上線甚至每天上線了。