從微軟藍屏事件聊到數據庫系統中的紙牌屋,你明白了些什么?
2024 年 7 月 19 日,全球約有 850 萬臺 Windows 電腦崩潰,無法重啟,陷入藍屏死機狀態。這次故障影響了全球各地的企業和政府,波及運輸、金融服務、醫療保健等絕大多數行業。
故障發生幾小時后,藍屏原因找到,是美國網絡服務提供商 CrowdStrike 更新錯誤所致。
第二天,紅迪(reddit)網的 AskReddit 社區(該社區旨在「討論一些下飯的問題」),出現了一篇緊跟時事的帖子:「為紀念微軟藍屏事件,來聊聊你在工作中闖的最大的禍」。
圖片
讓我們從「很久很久很久以前的一場悲劇」開始欣賞打工人干的好事。
網友 pm1966 公司曾經的 DBA 在測試時注釋了 WHERE 子句,導致數百萬條記錄在幾秒鐘內消失。事情發生在周五下午,混亂持續了整個周末。
他現在的評價是,這事不能完全歸咎于他;但假如他對自己的數據庫編程更有信心,他本可以迅速發現這個錯誤。
圖片
網友 slyiscoming 想到了大量數據造成的堵塞。他曾經為客戶關閉一個大型數據庫,服務器花了 3 天時間才恢復。他還在更新一個生產型客戶的測試環境時,工作到凌晨 3 點,才將更改回滾,因為當時他們還沒有回滾腳本。
圖片
網友 quiggyfish 因為沒有重視備份,花了團隊大量的精力,才從誤刪所有數據庫的災難性事故中復原。
圖片
網友 eury13 當時在一家初創軟件公司工作。某天臨下班時,他在內部管理平臺上照常注銷取消訂單的客戶賬戶。CEO 突然路過,注意到平臺上離職員工的名字,并要求他將這些賬戶一并注銷。
但前員工的一些用戶賬戶被硬編碼到了他們的代碼庫中,這意味著一旦這些賬戶被注銷,系統就會因無法完成各種進程而癱瘓。
團隊通過重新啟用舊的用戶賬戶解決了這個問題,他也沒有惹上麻煩。但要為這種麻煩事加班,真是糟糕……
圖片
同一個公司,同一個 eury13,還有一個故事,是關于數據庫開放寫入權限的后果。
他們的公司管理賬戶時,必須手動更改 SQL 數據庫。某次他弄錯了 ID 號,因此錯誤地注銷了一個用于系統監控的賬戶。監控工具發現后發送了大量警報,在各種系統中引發連鎖故障,系統又癱瘓了。
雖然他又一次沒有被解雇,監控賬戶重新打開,一切恢復正常,但他事后想想,那家公司的系統簡直是個紙牌搭的房子。他們沒有任何控制措施來防止像這樣的無辜失誤造成巨大的連帶問題。
圖片