事件回顧

一個gitlab公司的同學， 為線上的數(shù)據(jù)庫進行負載均衡的操作。 碰巧這個時候，被OODS工具，導致數(shù)據(jù)庫各種數(shù)據(jù)飆高。由于這個異常的攻擊導致某個備用的數(shù)據(jù)庫落后于主庫4GB。 在嘗試了多個方法無效之后，原來希望啟動一個新的實例，結(jié)果錯誤的刪除了整個實例。最后通過手動復制代碼，花了6個小時，將所有被刪除的數(shù)據(jù)復制了回來。

說人話，就是一個工程師，由于在一次日常工作中，由于被攻擊和長時間的加班導致腦子不清楚， 錯誤的將一個備份數(shù)據(jù)文件刪除了。差一點從刪庫到跑路成為現(xiàn)實。

注：GitLab 是世界上最著名源碼代管服務網(wǎng)站

事件問題分析

我覺得這個事件是一個小概率的事件湊在一起才能發(fā)生的。因為gitlab號稱有5個備份機制，但是在這一次事件中全部失效。但是小概率事件的發(fā)生肯定有原因的。

• 最大的問題是不應該讓這種線上的操作存在可以清空這個數(shù)據(jù)庫的操作。
• 其次是數(shù)據(jù)的回滾和備份需要經(jīng)常測試驗證，而不是留下一堆不可用的腳本和文檔
• 對于數(shù)據(jù)選型，應該選擇具有良好的運維能力的技術體系， 從整個過程看， 很有可能對于PostgreSQL 的特性熟悉程度不夠。

公司系統(tǒng)如何更好避免類似問題

多機房備份

對于任何一個分布式的系統(tǒng)來說， 數(shù)據(jù)備份，數(shù)據(jù)可用都是構(gòu)建一個高可用的系統(tǒng)的基礎。

• 是需要保證系統(tǒng)服務的穩(wěn)定性。
• 是系統(tǒng)的數(shù)據(jù)能夠通過異地備份的方式進行存儲。
• 是備份的數(shù)據(jù)同步出問題之后的回補機制的驗證需要經(jīng)過比較嚴密的測試，保證線上可用。

減少黑屏操作

很多程序員， 特別是新人程序員， 會覺得在黑色的命令行屏幕上敲敲命令行完成操作是一件很酷的行為。 但是我想說， 這絕對是電影看多了。直接使用命令行操作，雖然效率高， 但是存在很多不可控的風險。所以現(xiàn)在很多公司都必須有自己的運維系統(tǒng)，通過點擊系統(tǒng)（白屏）來完成相關的操作（最少刪除的時候， 會有一個彈出那個提示）， 避免了手動敲擊命令行（黑屏）之類的相關操作。

少加點班，減少疲勞駕駛

據(jù)不完全統(tǒng)計， 用于疲勞駕駛導致的事故排名很高。同理，由于批勞操作， 肯定會存在很多的誤操作，因為聯(lián)系工作了十多個小時之后， 很有可能頭腦不清晰，隨便l亂操作就出錯了。 更合理的是， 對于運維同學能夠通過倒班的形式而不是持續(xù)加班的形式， 可以解決不少的問題。

個人數(shù)據(jù)備份

• 對于個人來說， 所有的重要的文件， 無論是代碼還是數(shù)據(jù)問題，照片都是需要進行定時的備份， 養(yǎng)成數(shù)據(jù)備份的習慣，例如使用iCloud進行自動備份可能更好。
• 所有的云端存儲最好是進行多公司存儲， 因為現(xiàn)在無論騰訊還是百度， 各個大公司都提供了云存儲的服務，將數(shù)據(jù)保存在不同公司的服務器上，可以極大提高數(shù)據(jù)的安全性，畢竟幾個大公司一起出問題的概率很小
• 如果個人是一個標準的技術宅， 可能考慮自己搭建一套NAS，為自己量身訂造一套家庭數(shù)據(jù)中西， 也是一個很贊的選擇。

結(jié)語

小心使得萬年船，對于任何的線上系統(tǒng)都要保持足夠的敬畏， 避免用戶出現(xiàn)各種意外， 是一個工程師的基本素質(zhì)。 同時持續(xù)使用系統(tǒng)和產(chǎn)品而非人肉的操作來代替運維的工作，可以少點背鍋的人。
版權申明 本文為林炎小寶原創(chuàng)，轉(zhuǎn)載請聯(lián)系