某公司DBA從刪庫到跑路，DBA應該背這個鍋嗎？
最近某公司DBA（資料庫工程師）刪庫被開，這真的是DBA的責任嗎？
作為DBA應該如何保護自己？大數據、AI（人工智慧）時代，互聯網公司又該如何保護數據呢？
請教大神們有什麼好的辦法和建議？
不說話，不做事，永遠不會犯這個錯。涉及到手工操作的，神仙也可能出紕漏。
這事兒都讓DBA背了，實在不妥。而且，應該最大限度的寬恕他才對。我幾年前年招過一個應屆生，入職沒幾個月，直接drop了一個庫，嚇得臉都白了，我默默的幫他恢復了數據，他則後來幹勁十足，現在也成了業內大牛了。
相反，公司領導層對這個問題夠不夠重視，技術管理系統夠不夠完善，操作規範是不是健全才是要重視的問題。
任何一個操作，總有true or false的可能，這就像寫程序，你不catch 異常，還老抱怨應用莫名氣的掛了。資料庫不像程序設計一樣，它不僅僅是門技術，同時也是公司資產，這種有狀態的資產，就是應該要建立完善的系統和規範才行，操作是不是合理，有沒有經過驗證，會不會影響業務，能不能導致性能問題，執行會不會出錯，出錯能不能回滾，回滾是不是及時，這些如果都能用技術或者自動來保障，那麼這個悲劇就不會上演。
這樣的事兒，如果沒有以上的保障，以後肯定還會再發生，而且肯定不止一次。今天你討論別人的時候，也許明天你就是被討論的對象。
利益相關：極數雲舟創始人，提供MySQL技術產品，其中Arkit產品是MySQL領域就健全的SQL審核和管控平台，可以避免以上問題發生。
題主好，貢獻一則回答，來自上上籤電子簽約運維組的數據安全專家。
——————————————————
大家好，我從事資料庫工作多年，下面是我的看法，希望可以幫到大家：
眾所周知，DBA是高風險的職業。數據泄露了，你是被懷疑的對象；資料庫宕機了，你是眾人矚目的焦點；數據丟失了，更是要被問責。DBA誤操作導致數據丟失的情況確實是難辭其咎，但是在公司上下與DBA人員的共同努力下，風險是可以被控制和規避的。一般說到保護數據安全的對策，大家很容易想到備份、容災、恢復演練等保護措施，但是「上工治未病，不治已病」，預防才是王道！據統計，90%以上的生產事故是人為導致的，所以保護數據安全的重中之重，是儘可能減少人為操作。
這裡我提幾個具體防範手段，如下：從公司管理層面1、上線操作流程化，這樣可以避免隨意上線操作，減少錯誤來源；2、上線操作自動化，減少人為操作的次數，減少人為操作導致錯誤的概率；3、制定安全操作規範，比如終端離席鎖屏、避免GUI（圖形化工具）方式操作生產庫、許可權最小化等；4、提供必要資金投入，包括人員（比如雙人操作）、備份和容災方面。
從DBA自身層面：
1、備份。備份重於一切，DBA主從推動備份恢復機制；2、恢復演練。 制定恢復演練驗證數據備份的有效性，避免恢復時備份不可用；3、容災。制定容災策略，如從庫、延遲從庫、同城災備、異地災備等；4、許可權控制。 不要使用管理員操作，使用root操作是大忌； 5、操作習慣。 避免疲憊時操作，這是筆者多年的經驗，因為疲憊時操作最容易出錯；6、流程。所有線上操作流程化，操作有審批、有許可和授權，儘可能避免做畫蛇添足的事。如果有條件，最好做一下災難演練，完善災難恢復手冊，做到手中有糧，心中不慌。除此之外，還有最最重要的一條： DBA要時刻對生產心存敬畏！做到了如上幾條，也就做到儘可能的保護數據了。DBA也不用每天如履薄冰，擔心背鍋了。
具體也可參考這個回答https://www.zhihu.com/question/56464092/answer/480680219
大家還有什麼好建議也隨時歡迎討論。
最後歡迎大家關註上上籤電子簽約。我們是行業內唯一同時擁有ISO27001、ISO27018、公安部信息安全三級等保、工信部「可信雲」四大資質認證的電子簽約平台，具備銀行級別的安全機制。簽合同，上上籤一下。
如果你問順豐這次事故的處理，我覺得沒什麼問題啊，這和公司請個專職司機，自己失誤撞死人的情形差不多，雖然公司會承擔部分賠償等損失，但此司機基本是沒機會呆下去了。除非上面有人力保，或者是"以人為本"的公司文化，認為是公司已經損失了幾百萬給這個人做培訓費，再炒掉連培訓費都給別人了，（但這類公司基本是那種小公司，反正也請不到人；或者那種壟斷、無欲無爭，毫無壓力之類的公司）
DBA就是本次事故負主要責任，這就是一個低級錯誤，並且造成"嚴重"損失，開除很正常。你看那封郵件抄送一堆group，就是這個影響不是自己一個人，或自己這個組能抗下來的，是影響了一大team人的KPI，總得給人家一個交代吧？不開你，除非運維的領導出來硬抗，但估計損失更大，及時止損更明智；另外，這個運維組今年的年終獎金等估計黃了，估計團隊其他人也對他很有意見，後續合作也有點困難了。
唯一和之前有異常就是以往這種事情都是悄悄的進行，這次連真實姓名都流出來了，讓此人以後比較難在這個行業混了；
－－－－－－－－－－－－－－－－
作為DBA應該如何保護自己？
我的回答是對工作要有敬畏之心。
生產環境執行變更類操作，這個操作風險極大，正常情況提前要寫好變更方案，方案裡面要寫失敗回滾方案，而且要在測試環境先進行測試通過後到正式環境實施，且還不論方案的層層審批。
從這個過程看，DBA不僅完全沒有按照正規流程進行操作，而且職業敏感的度完全不夠，涉及刪除操作居然不仔細審查即執行，SQL操作彈出提示居然還能無視。這樣如果不翻船天理難容。
這個事情dba是撇不開責任的，只是輕重而已，從保護自己同時保護公司數據資產的角度考慮，我覺得打鐵還需自身硬，首先要對生產數據有敬畏，要克服好奇心和毛躁的一上來就操作的習慣，不要用生產數據作試驗；其次，生產的變更在遵守規範的前提下，事前一定要做好測試，必須是真實的模擬，比如數據量、數據特點，還有使用的工具等，做到心中有數，要有回退的預案，不要把自己置於無路可退的境地；最後，要更多的磨鍊技能，汲取前輩們得經驗，為己所用，總有一些操作還是需要手工執行的，不可能全部自動化的。其他具體的細節技巧網上也可以很容易搜索到的。
但是順豐的管理、流程和技術控制上也都有責任，不能全推給DBA一個人來背鍋。DBA這個工種太高危了，誰沒有不小心出錯的情況，別的崗位出個錯沒事，DBA一出錯就開被出，也沒見給DBA開的工資有多少絕對高度，看來DBA自己得給自己買一個很高的失業保險。
DBA自己應該儘可能的把一些可能會發生的情況預想一遍，做好防止的措施，避免有時候犯渾掉坑裡。
順豐這個恢復時間也有些長啊，估計是預案沒錯好，也沒有做沒有延遲從庫，因為他這個動作備庫也是會被刪掉的，可能容災庫也會被刪，只有延遲從庫中還能快速全量的找回數據，這麼長時間我懷疑順豐沒有延遲從庫，恢復是從離線數據恢復的。
建議DBA把刪這個能力忘了吧，絕對不刪庫，不就是浪費些存儲資源嘛。真要刪多叫一些人後面盯著，犯渾了好拉你一把。
大家也可以參考這個回答：
企業如何避免雲服務/雲平台故障給自身業務帶來損失？?www.zhihu.com
養成良好的習慣，先備份後修改，先select然後再update delete，不要盲目自信，雖然麻煩一點，但是保險啊！
大不了，恢復資料庫，這是保底，在保底的基礎上，再錦上添花，別把錦弄沒了！
自己也有犯糊塗的時候，把公司4年的一個表一不小心沒寫條件給delete,首先冷靜，我有昨天的資料庫，在昨天的資料庫基礎中恢復這個表，然後增量部分，通過其他關聯表，寫游標補齊數據！即便退一步，沒有補齊增量補分數據，起碼損失是可控的！
1.打鐵還需自身硬 DBA做任何資料庫操作都要清楚該操作帶來的後果，對線上操作抱有敬畏之心，操作時謹慎謹慎再謹慎，重大操作提前做好回滾方案，給自己留好退路，這也是對一個專業DBA綜合素質的體現。
2.企業加強運維流程管理 操作要有審批流程，確保負責人員知曉，重大操作可雙人操作或安排檢查人員
3.積極推動運維自動化 減少操作複雜性，對高危操作進行提示或做許可權限制，減少操作人員出錯幾率
4.如果企業將資料庫全部風險完全轉嫁給DBA，那麼應體現高風險高收益原則，這點應在工資中體現。
絕對不進行任何刪庫的操作
推薦閱讀：
