那些年，我們假裝世界末日已經來了
在 IT 世界裡，有一種活動，大家表面上說很重要，但心裡都默默希望它永遠不要真的派上用場——它的名字叫做 災難恢復（Disaster Recovery, DR）。
而 DR Drill（災難恢復演練），就是那種「假裝公司已經炸掉一次」的年度大型角色扮演活動。
一、什麼是 DR Drill？
簡單說：
👉 不是在等災難發生，而是先假裝它已經發生了。
DR Drill 就像消防演習，只是比較安靜、不會有哨聲，但工程師的心跳一樣快。
我們會假設某一天：
-
主機房斷電
-
Storage 掛點
-
網路消失
-
老闆打電話來問：「網站為什麼打不開？」
然後問一個殘酷的問題：
「如果現在真的出事，我們救得回來嗎？」
二、為什麼 DR 一定要演練？
因為 DR 文件 ≠ DR 能力。
很多公司都有一份 DR 文件，厚度堪比研究所論文，裡面寫滿了：
-
RPO = 15 分鐘
-
RTO = 1 小時
-
切換流程 Step 1 到 Step 28
但問題是——
這份文件上一次被照著做，是什麼時候？
DR Drill 的存在，就是為了揭穿殘酷的真相：
-
帳號密碼是不是早就失效
-
IP 位址是不是三年前的舊資料
-
「這台 VM 是誰管的？」沒人知道
-
關鍵人員今天剛好請假
沒有演練，DR 只是 PPT 等級的信仰。
三、DR Drill 的三大常見幻想
在真正演練前，大家通常會有以下錯誤期待：
幻想一：
「平常都沒問題，DR 也一定沒問題。」
👉 錯。
DR 就像降落傘，你永遠不知道它會不會在第一次用時才發現裝反了。
幻想二：
「切換應該按個按鈕就好吧？」
👉 半錯。
現在很多系統確實可以「一鍵 Failover」，
但前提是——
你有先確認那顆按鈕真的有接線。
幻想三：
「演練不要太認真，怕影響正式系統。」
👉 大錯特錯。
不認真的 DR Drill，只是在練習「如何在災難時更慌張」。
四、一次真正的 DR Drill，通常會發生什麼事？
流程大概是這樣的：
-
宣布演練開始
大家嘴上說 OK，Slack 群瞬間安靜。 -
模擬主站台失效
有人小聲問：「真的要關嗎？」 -
開始切換到 DR Site
-
VM 起來了
-
網路通了
-
但應用程式連不到 DB
-
-
開始查問題
「這個防火牆規則是誰加的？」
「為什麼 DR 環境沒有這個憑證？」 -
修修補補
工程師邊修邊在心裡記帳：「下次一定要改。」 -
宣布演練成功
表面歡樂，內心疲憊，但系統真的變更強了。
五、DR 測試不只是「能不能開機」
真正成熟的 DR 測試，會看這幾件事：
-
RPO 有沒有真的達成？
資料少了 3 小時 ≠ 成功 -
RTO 是理想還是現實？
文件寫 1 小時，實際跑 4 小時，老闆的臉色就是 KPI -
應用層有沒有一起測？
VM 起來但系統不能用，只是「漂亮的失敗」 -
人有沒有準備好？
DR 不是只有機器，還有值班人員的腦袋
六、為什麼 DR Drill 常常被拖延？
因為它有三個 IT 世界最可怕的特性：
-
沒出事時，看不到價值
-
會暴露問題
-
需要跨部門合作
但現實是：
👉 你不在演練時流汗，就會在災難時流淚。
七、做完 DR Drill，最重要的一件事
不是寫報告、不是簡報、不是寄信給老闆。
而是：
真的把發現的問題修掉。
-
文件更新
-
腳本修正
-
自動化補齊
-
權限重新確認
否則下一次演練，還是同一批 Bug 出來跟你打招呼。
八、結語：
DR Drill 不是在詛咒公司出事，而是在保證——
真的出事時，公司還活著。
真正專業的 IT 團隊，不是從不出錯，
而是 在世界還沒崩壞前，就已經演練過怎麼救它。
所以，下次當你聽到有人說：
「我們要做 DR Drill。」
請不要嘆氣，
那代表你正在替未來的某一天——
少一次通宵，多一次安心。
沒有留言:
張貼留言