🔧 阿川の電商水電行
AD 伺服器消失時，會發生很多有趣的事情。
1. 登場人物
首先介紹登場人物。
- A先生：作業者。入職一年。擁有幾次維護作業經驗。
- 我：作業確認者。入職大約五年，擁有系統構建和維護作業的經驗。
- B科長：A先生和我的上司。
- C部長：B科長的上司。
- D事業部長：C部長的上司。
2. 系統構成
使用 VMware 產品的 DaaS（虛擬桌面服務）環境。
雖然有許多細節構成，但即使在典型的 DaaS 架構中，也會發生類似的情況，請粗略地想成以下的結構。
- 所有的管理伺服器均為虛擬伺服器，採用 Active-Active 結構 進行冗餘。
- AD：Active Directory / DHCP / DNS 伺服器
- vCS：VMware vCenter Server
- CS：Horizon 連接伺服器
- ES：VMware 註冊伺服器
- 用戶使用的虛擬桌面是在與管理伺服器群不同的 ESXi 上運行。
- vPC：虛擬桌面（VDI）
3. 每月管理伺服器維護
管理伺服器為 Windows Server，因此每個月需要進行 Windows 更新。
因為需要重新啟動，所以在白天進行作業的風險很高。因此，我們在 維護時間內（深夜） 進行作業。
這次的維護對象是 AD1 和 AD2。每次進行作業的步驟如下所示。
- 將監控系統設置為抑制模式：（監控系統在不同的環境中。重新啟動會發出警報，因此進行暫停）
- 關閉 AD2
- 獲取 AD2 的快照
- 啟動 AD2 → 執行 Windows 更新 → 重啟並應用更新程序
- 確認 AD2 的正常性。如果沒有問題，再次關閉。
- 刪除 AD2 的 最舊快照。
- 啟動 AD2 並確認正常性。
- 關閉 AD1
- 獲取 AD1 的快照
- 啟動 AD1 → 執行 Windows 更新 → 重啟並應用更新程序
- 確認 AD1 的正常性。如果沒有問題，再次關閉。
- 刪除 AD1 的 最舊快照。
- 啟動 AD1 並確認正常性。
- 解除監控系統的抑制模式。
4. 發生作業錯誤：AD 被「從清單中」刪除
在 步驟 6 中發生了錯誤。
借用 VMware 工程師博客的圖片來解釋情況，畫面結構如下（※圖示）。
原本應該要做的是：
- 藍框：在快照窗口中，刪除最舊的快照。
但實際上做的是：
- 紅框：在虛擬機器操作菜單中執行「從清單中刪除（Delete from Inventory）」。
舊版 vCenter 當虛擬機器關閉時會出現「從清單中刪除」的選項，但因為太困了，只看到了「Delete」這個字。
時刻是 凌晨3點。 前一天我 玩了 18 小時的怪物獵人。
A先生：「我點擊 Delete。」
我：「好的。」（← 極度困倦，眼睛快要閉起來，幾乎在睡著）
A先生：「我覺得好像不太對，這樣正確嗎？」
我：「一個項目減少了，所以我認為這是正確的。」（← 睡眠不足）
在這裡，原本應該要檢查 藍框的快照清單，而我卻看著 紅框的虛擬機器清單，判斷「項目減少了所以是正確的」。
之後進入了步驟 8 的後續步驟，當進入步驟 12 要刪除 AD1 的快照時，再次感到違和。
A先生：「我刪除了快照，但紅框的項目沒有減少呢。」← 步驟上是正確的
我：「是的。」
A先生：「啊，對不起，我錯誤地在藍框那裡作業。對不起，我刪除它。」← 錯誤的
我：「好的。」
結果，AD1 也成功從清單中刪除了。
在接下來的步驟 13 中試圖啟動 AD1 時。
A先生：「按照步驟啟動，但 AD1 不見了。」
我：「什麼？」（← 這時才真正清醒過來）
眼前出現的是：
- AD1 和 AD2 都不存在的 vCenter 畫面。
全身冒出奇怪的冷汗。 「啊，這完全是作業錯誤。」 我的腦袋理解到這一點花了幾秒鐘。
「嗯？等一下，為什麼在 AD1 的時候才第一次發現？」冷靜下來想一想， 如果在 AD2 時有進行正常性確認（步驟 7），應該在那時就能發現。
是的，A先生 跳過了步驟 7。
作業者常見的「跳讀」。
而我也沒有意識到這一點。
好吧，如果 AD 伺服器只有一台不在，那麼簡單的還是可以恢復。
但這次是 兩台都不在。
兩台都不在的情況下，能否順利恢復？這本來就可以恢復嗎？我心裡想著，
「啊，因為只是從清單中刪除，所以資料依然在儲存空間裡！」
「從那裡恢復應該可以的吧！！」
維護結束的時刻剩下 1小時。
「還有時間進行恢復」我告訴自己，默默開始恢復作業。
本來在這裡就應該向上司升級報告，但
- 希望在維護時間內解決
- 不想被罵（很重要）
這種情緒壓倒了我，我開始成為作業者，從 ESXi 的資料儲存空間進行恢復作業。
最終結果是：
- AD1 / AD2 的虛擬機器成功復活
- 在 ESXi 的 vSphere 客戶端上確認存在
- AD / DHCP / DNS 也似乎正常
維護結束 10分鐘前 完成了恢復。
「剛好趕上！原來能做到！」心中湧現出一種奇妙的成就感。
A先生也露出了笑容，我也笑了。
……
最後一步驟 14：解除監控系統的抑制模式。
5分鐘後，約有8000封警報郵件 飛了過來。
- 監控室的警報燈響個不停
- A先生呆住了
- 我心跳加速
這些警報郵件，當然也會發送到 上司那裡。
5. AD 雙伺服器恢復的影響：管理伺服器群無法參加域
這時我終於想到了，「剛才的恢復，真的正確嗎？」這個問題。
在這個環境中，因為 AD 伺服器雙方都已經回滾到快照時點，
導致其他伺服器（vCS, CS, ES 等）之間的 電腦帳號不一致。
也就是說，
- vCS / CS / ES 等管理伺服器都無法參加域。
- 因此影響到非 AD 伺服器的管理伺服器無法建立名稱解析的狀態。
致命的是，這些管理伺服器是 建立時已假設「參加域的狀態」。
無法進行名稱解析 ＝ 什麼都無法做
結果造成：
- 所有管理伺服器都需要重新參加域
- ＝ 所有功能都需要重新安裝
- ＝ 幾乎重新構建
重新構建管理伺服器群就意味著，該伺服器群所控制的 vPC 也必須全數重新設置。
- 從主伺服器重新部署所有的 vPC
- 數量很多，雖然需要一些時間，但作業本身並不會太困難（管理伺服器才是嚴重問題）
如果問這個架構是否充分考慮了運作面，那麼老實說就是微妙……
不過，先不談架構的反思，讓我們專注於「為什麼會發生這種情況」。
6. 為什麼會發生作業錯誤？
D事業部長對 C部長和 B科長進行了約三小時的會議。
之後，我被 B科長狠狠地斥責。A先生也哭了。
接下來，開始進行為什麼分析。
「要找出真正的原因，至少要重複五次「為什麼」」這句話很常被說到，但由於這次的影響太大，D事業部長下達了
「找出更深入的真正原因並對策」
的命令，因此進行了 七次為什麼 的分析。
A先生的情況
針對 A先生的分析。
- 為什麼在步驟 6 中選錯了刪除的地方？
→ A先生「是我的能力不足造成的，十分抱歉。」 - 為什麼能力不足？
→ A先生「因為我的能力不夠，十分抱歉。」
入職一年，心理上受到很大壓力，變得全然將一切歸咎於自己的能力問題的狀態。
在此暫時停止針對 A先生的追究，轉向我自己的為什麼分析。
我的情況（7次為什麼）
- 為什麼沒有注意到步驟 6 的刪除錯誤？
→ 我「因為缺乏注意力。」 - 為什麼缺乏注意力？
→ 我「因為睡眠不足。」 - 為什麼會睡眠不足？
→ 我「因為私人生活太充實，沒有確保睡眠時間。」（＝ 18 小時的怪物獵人） - 為什麼覺得不需要確保睡眠時間？
→ 我「因為我以為 A先生能夠毫無問題地按照步驟執行。」 - 為什麼認為 A先生能夠毫無問題地按照步驟執行？
→ 我「因為他已經有多次成功完成維護的經驗。」 - 為什麼僅因為有多次成功經驗就判斷「沒問題」？
→ 我「因為平時一起作業，對 A先生的作業能力有一定的 信任。」 - 為什麼如此信任 A先生？
→ 我「」
「深邃的真因」慢慢浮現了。
對於直接原因的對策當然也正在進行中
我們也實施了減少人為錯誤的對策。
- 改善步驟
- 將快照的獲取和刪除結合為一條步驟中完成
- 作業自動化
- 使用 RPA（UiPath / WinActor 等）和 PowerShell / Python 等進行自動化
- 特別是刪除類的作業風險較高，因此修改為 必須通過 CLI 進行的制度。
在向 B科長報告這些之後，也與 C部長 / D事業部長進行了評審。
（最終，我們將 UiPath ＋ PowerShell 自動化了這次的定期維護作業，針對所有管理伺服器群進行了自動化。）
D事業部長也對 B科長和 C部長進行了為什麼分析，結果發現：
- B科長：信任我和 A先生。
- C部長：信任 B科長。
也就是說，整個組織都處於「他們應該是沒問題的吧」的現場狀態（某種意義上，這是一個很好的工作環境）。
7. 根本原因的對策及效果
在事業部內建立了 「原則上不信任任何人的行為方針」。
在網路安全的世界裡，有這樣的想法：
「永遠不可信任，必須不斷驗證。」
這是基於 Zero Trust 安全模型的理念。
我們設計了人類版的這個模型，以後會多次提到，因此使用 HZT（Human Zero Trust model）來表示。
HZT 的基本方針
HZT 的根本思想非常簡單。
「所有作業都必須記錄下來。」
為此，我們構建了以下體系。
- 作業者和確認者禁止 現場溝通
- 離線對話不留下記錄，且面對面時容易產生某種程度的信任。
- 所有作業需在 線上會議中進行
- 線上會議的 URL 在事業部內共享，職位成員可 隨時參加
- （據說在職位成員中進行輪替，隨機時間進入會議）
- 作業者共享屏幕，保持作業畫面 / 作業手冊 / 檢查清單同時可見。
- 確認者也同樣，將作業者的畫面與手冊 / 檢查清單常時顯示。
- 作業過程中的畫面必須持續錄影。
- 作業結束後：
- 作業者和確認者一起觀看錄影資料
- 這一「觀看作業」也再次錄影。
- 科長要檢查：
- 作業視頻（作業者/確認者）兩段
- 檢查視頻（作業者/確認者）兩段
共計四段，並錄製過程。
- 部門成員也同樣檢查四段視頻並錄影確認過程。
- 部長要檢查：
- 科長和部門成員一段的「確認視頻」兩段。
在這樣的情況下，如果發生作業錯誤，部長將承擔所有責任，並進行客戶對策，作業者 / 確認者 / 部門成員一名 / 科長全員都會受到評價處分。
但如果在檢查時發現作業錯誤並報告給部長，則可避免處罰的規則。因此，設計為 「發現問題的人會成為贏家」。
看起來很黑暗，但實際上不那麼糟糕
讀到這裡，或許你會覺得，「這簡直是完全黑暗嗎？」。
但是，由於 HZT 的推廣需要 物理上分離人與人，因此附帶增加了這條規則。
作業時 必須採用遠端工作（原則上居家）
這段故事發生在 疫情前。
當時遠端工作並不是主流，但因為 HZT 的緣故，參與維護作業的成員開始以居家工作為主。
結果是：
- 可以在家作業
- 可以在專注的環境中作業
- 也減少了物理移動時間
這些優點相當明顯，反而積極參與維護作業的人數增加。
（對工程師來說「可以遠端工作的價值」是何等重要，立即理解了這一點的時刻）。
HZT 的效果
從 HZT 實施後的六個月結果。
- 重大故障：0 件
- 輕微錯誤大幅減少
- 後來的問卷調查中出現許多聲音表示「相比在辦公室多個人一起作業，遠端環境更容易集中注意力」。
在「不過度依賴信任，而是依靠記錄與驗證來保證品質」的意義上，我覺得 HZT 作為 通用的對策也並不差。
8. 最後
在此稍微回顧一下2025年的視角。
首先，通過此次事件，明白了：
- Zero Trust 不僅對安全有效，對人類也同樣有用。
同時，也感受到：
- 信任對方
- 眼神對視並說「我交給你了」
- 在同一個房間裡笑著說「辛苦了」
這些 人與人之間的溫度感，似乎逐漸被削減。
之後，我辭職了。
然而，數據導向的世界，對 AI 來說是友好的。
負面的方面容易理解，所以接下來稍微從正面來思考。
在2025年當前，社會上被稱為 「AI代理元年」。
所有企業都在呼號「數據與 AI」，
- AI 需要 數據
- 沒有數據就無法 進行學習和自動化
這些已經成為前提。想想 HZT 的做法，
- 所有作業皆在線上完成
- 所有過程都有日誌與影像記錄
- 所有過程都可以在事後進行驗證
這樣的業務改革對 AI 而言無疑是 最佳的土壤，因為 「這裡有數據」。
或許當時的現場現在正在被 AI 高效化。
所以最後加上一點詩意。
原文出處：https://qiita.com/katohiro_fi/items/fd4277347f5b0aa767a2
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
