<dd id="yzu3f"><tr id="yzu3f"><kbd id="yzu3f"></kbd></tr></dd>

              黑基Web安全攻防班
              安基網 首頁 資訊 職場族 查看內容

              又一程序員刪庫跑路!

              2018-9-22 07:52| 投稿: xiaotiger |來自: 互聯網


              免責聲明:本站系公益性非盈利IT技術普及網,本文由投稿者轉載自互聯網的公開文章,文末均已注明出處,其內容和圖片版權歸原網站或作者所有,文中所述不代表本站觀點,若有無意侵權或轉載不當之處請從網站右下角聯系我們處理,謝謝合作!

              摘要: 據微博網友大佬坊間八卦爆料,順豐的一個工程師手誤把線上系統一個庫刪除了,然后跑路了: 又一程序員刪庫跑路! 根據郵件內容,事件詳情如下: 在接到該變更需求后,按照操作流程要求,登陸生產數據 ...

              9月 19 日晚,據微博網友大佬坊間八卦爆料,順豐的一個工程師手誤把線上系統一個庫刪除了,然后跑路了:



              根據郵件內容,事件詳情如下:

              在接到該變更需求后,按照操作流程要求,登陸生產數據庫跳轉機,通過navicat-mysql客戶端管理工具,連入SHIVA-OMCS的RUSS庫進行操作。

              但在操作過程中,該運維發現選錯了RUSS 數據庫,打算刪除執行的sql。

              在選定刪除時,因其操作不嚴謹,光標回跳到RUSS庫的實例上,在未看清所選內容的情況下,便通過delete執行刪除,同時,他忽略了彈窗提示,直接回車,導致RUSS庫被刪除。

              因工作運維人員工作不嚴謹的操作,導致OMCS運營監控系統發生故障,該系統上臨時車線上發車功能無法使用并持續約590分鐘。同比9月5日的929條臨時車需求,此次故障對業務產生了嚴重的負面影響。



              根據順豐規定,予以開除,并通報公司批評。



              此外,據說該員工任職順豐科技IT數據中心應用交付技術部互聯網產品運維組,職務IT運維開發高級工程師。

              目前,此事已經在圈內傳開了:




              網友們在網上也是議論紛紛,有幸災樂禍調侃型的:不如,rm -f / 刺激



              也有人調侃稱:刪的時候肯定很激動



              也有人調侃:付出如此巨大的代價,培養起了一個運維工程師的安全意識,然后竟然把他開除了?



              還有就是關于是否備份的討論:



              不過最狠的還是屬這一條,反手丟給你一本Mysql從刪庫到跑路:




              看看有沒有什么后路好走啊哥們~

              0. 國內呆不下了,趕緊出國

              首先,不要選動車,要選最近的一班飛機,盡快出國,能走高速走高速,不然選人少的路線。

              沒錯,我們 DBA 都是常備護照的。

              切記,注意看高德地圖實時路況。

              我們有個前輩就是刪庫之后開車就上二環,下午五點鐘。警察到的時候他還堵在路上。

              1. 只不過是把數據干掉了


              權限問題永遠是大問題,做好權限回收,開發數據庫和線上數據庫分離,線上數據庫管理權限(一般指修改表結構權限與刪表權限)禁止回收,也不提供給業務直接用。

              不然參考 0。

              公司管理上,最好有自己的 DB 運維產品,線上數據庫只允許查,改的話要有審批流程。

              至于查數據要不要脫敏、導入導出流程,就看自己產品的規劃和排期了。

              至于 DBA 怎么保證不手滑,這個每個人有每個人的習慣。

              2. 刪庫什么的都是小 case


              清理數據庫之前一定要檢查進程,是否存在數據庫進程,如果存在則寧愿不搞也不要深夜搞。

              公司清理數據庫要有下線流程。下線一定要走流程。寧愿多租幾天機房也不要丟掉數據。

              不然參考 0。

              原則是:

              rm 文件之前先檢查進程是否存在。

              絕不手工 drop 庫表,如果非要 drop,則應該寫成 rename,truncate 也是類似,寫成 rename 和 create table like 兩條 sql。

              刪表之前可以根據表文件的最后修改時間進行再次確認,不確認就找人

              review,有下線流程則走下線流程。

              3. 備份,備份,備在何處?


              冷備,熱備都要有,一定要每天一備。

              冷備便是應對這種情況。

              公司應該有自己的 DB 備份方案,并且保證執行到位。

              4. 人算不如天算


              關于這一點,可以單獨拉一個大專題出來了,核心內容是 mysql 高可用。

              簡單起見,推薦這篇文章:避免硬件故障的核心解決方案是冗余。


              硬件層面的 raid,軟件層面的主從、熱備都是為了保證某一個節點宕機,其他節點仍然能繼續工作。

              所有庫都要有主從備份,一方面做讀寫分離,一方面也是為了備份、高可用。

              即便有半同步復制,有些極端情況下可以認為,mysql binlog 沒有同步到從庫上,仍然可能存在 binlog 丟失(數據丟失)的風險。

              所以應對這點,比較好的開源解決方案有 2:TiDB 和 Mysql GR。

              5. 升級也能失敗?


              說起來很簡單,升級無非是:

              準備升級


              過程原理


              手工升級后拓撲


              工具(mha)升級后拓撲


              6. 操作之前有個流程

              一般自己操作的時候,都不會有太多的顧忌。

              但是要是拿給別人看,就要考慮一下了。

              如果別人不只要看,還要 review,那這樣就比較難犯重大的錯誤了。

              如果有些操作需要夜間一個人搞,那么一定要提前列好準備,這個就比較正式了。

              包括:

              1. 梳理具體的執行步驟、執行命令和每個步驟的預計結果。

              2. 如果某些步驟出錯,是否要求回滾、預先制定回滾方案。

              3. 詳細記錄執行記錄,每一步都要有反饋。

              4. 事先梳理好收尾工作。

              5. 強關聯業務要事先通知,考慮到時間段和別的業務高峰,盡量讓對方也安排人留守觀察。

              6. 一定要嚴格按照步驟來進行操作。寧愿延期,不要加戲。

              7. 留幾個問題

              1. 如果你有機會進行 mysql 遷移和升級工作,你認為無法寫入數據造成的影響大,還是寫入臟數據造成的影響大?

              2. 如果數據庫掛了,機器可以啟動但是 mysql 進程無法啟動,你這里又有昨天的備份可以恢復,你該怎么做?

              3.想要刪庫完全不出問題,那么刪庫流程該怎么設計?

              好了,公司還是要有自己的 DB 產品,再簡陋也要有。


              小編推薦:欲學習電腦技術、系統維護、網絡管理、編程開發和安全攻防等高端IT技術,請 點擊這里 注冊賬號,公開課頻道價值萬元IT培訓教程免費學,讓您少走彎路、事半功倍,好工作升職加薪!

              本文出自:https://www.toutiao.com/a6603632110961951236/

              免責聲明:本站系公益性非盈利IT技術普及網,本文由投稿者轉載自互聯網的公開文章,文末均已注明出處,其內容和圖片版權歸原網站或作者所有,文中所述不代表本站觀點,若有無意侵權或轉載不當之處請從網站右下角聯系我們處理,謝謝合作!


              鮮花

              握手

              雷人

              路過

              雞蛋

              相關閱讀

              最新評論

              最新

              返回頂部
              十一选五奖金对照表