ADサーバーが消えた日 #ポエム – Qiita

※この記事は「本番環境などでやらかしちゃった人 Advent Calendar 2025」向けの体験談です。

ADサーバーが消えると、たくさん楽しいことが起きます。

1. 登場人物

まずは登場人物から。

  • Aさん:作業者。入社1年目。数回のメンテナンス作業経験あり。
  • :作業の確認者。入社5年目くらい。システム構築やメンテナンス作業の経験あり。
  • B課長:Aさんと私の上司。
  • C部長:B課長の上司
  • D事業部長:C部長の上司

2. システム構成

VMware製品を使用した DaaS(仮想デスクトップサービス)環境 です。
細かい構成要素はいろいろありますが、典型的なDaaSアーキテクチャでも同じような話は起きうるので、ざっくり以下のような構成だと思ってください。

image.png

  • すべての管理サーバーは仮想サーバーで、Active-Active構成で冗長化されています。

    • AD:Active Directory / DHCP / DNS Server
    • vCS:VMware vCenter Server
    • CS:Horizon Connection Server
    • ES:VMware Enrollment Server
  • ユーザーが利用する仮想デスクトップは、管理サーバー群とは別の ESXi 上で稼働しています。

    • vPC:仮想デスクトップ(VDI)

3. 月次の管理サーバーメンテナンス

管理サーバーは Windows Server なので、毎月の Windows Update が必要です。
再起動も発生するため、日中にやるのはリスクが高い。なので、 メンテナンス時間中(深夜) に作業をします。

今回のメンテ対象は AD1 と AD2。片系ずつ順番に作業する手順は以下の通りでした。

  1. 監視システムを抑止モードに設定:(監視システムは別環境。再起動するとアラートが飛ぶので一時停止)
  2. AD2 をシャットダウン
  3. AD2 のスナップショット取得
  4. AD2 を起動 → Windows Update 実行 → 再起動を繰り返しつつ更新プログラム適用
  5. AD2 の正常性確認。問題なければ再度シャットダウン
  6. AD2 の一番古いスナップショットを削除
  7. AD2 を起動し、正常性を確認
  8. AD1 をシャットダウン
  9. AD1 のスナップショット取得
  10. AD1 を起動 → Windows Update 実行 → 再起動を繰り返しつつ更新プログラム適用
  11. AD1 の正常性確認。問題なければ再度シャットダウン
  12. AD1 の一番古いスナップショットを削除
  13. AD1 を起動し、正常性を確認
  14. 監視システムの抑止モードを解除

4. 作業ミス発生:ADが「インベントリから」消える

手順 6 でミスってしまいました。
vmware エンジニアブログさんの画像をお借りして状況を説明すると、こんな画面構成でした(※イメージ)。

参照:https://www.climb.co.jp/blog_vmware/vmware-7072

image.png

本来やるべきだったのは:

  • 青枠:スナップショットのウィンドウで、一番古いスナップショットを削除

しかし実際にやってしまったのは:

  • 赤枠:仮想マシン自体を操作するメニューで、「インベントリから削除(Delete from Inventory)」を実行

昔の vCenter は、仮想マシンがオフになっていると「インベントリから削除」というメニューが出てくるのですが、眠すぎて「Delete」という文字しか目に入っていませんでした。

時刻は AM3時。 前日、私は 18時間ぶっ通しでモンハンをしていました。

Aさん「Deleteをクリックします」
私「はい」(← 超絶眠くて目が9割くらい閉じている。ほぼ寝てる)

Aさん「なんか違う気がするんですが、合っていますかね?」
私「項目が1個減ったので合っていると思いますよ」(← 寝不足)

ここでも、本来は 青枠のスナップショット一覧を確認すべきなのに、
赤枠の仮想マシン一覧を見て「減ってるからOK」と判断してしまいました。

その後、手順 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 Client 上でも存在を確認
  • AD / DHCP / DNS も一見正常に見える

メンテ終了 10分前にリカバリー完了。
「ギリギリ間に合った!やればできるじゃん!」と、妙な達成感がありました。
Aさんもニッコリです。私もニッコリ。

……

最後の手順 14:監視システムの抑止モードを解除をしました。
5分後、約8000件のアラートメール が飛んできました。

  • 監視室のパトランプが鳴り止まない
  • Aさんはフリーズ
  • 私の心拍数は爆上がり

このアラートメールは、もちろん 上司にも届きます

5. AD 両系リストアの影響:管理サーバ群がドメインに参加できない

ここでようやく、「さっきのリストアって、本当に正しいやり方だったのか?」という話になります。

この環境では、ADサーバー両系をスナップショット時点へロールバックしてしまったため、
他のサーバー(vCS, CS, ES など)との コンピュータアカウントが不整合になりました。

image.png

つまり、

  • vCS / CS / ES などの管理サーバーは、いずれもドメインに参加できない。
  • その影響でADサーバ以外の管理サーバーは名前解決が成立しない状態に。

そして致命的なのは、これら管理サーバーは「ドメイン参加した状態」を前提に構築されているという点です。

名前解決ができない = 何もできない

となり、結果的に:

  • 全管理サーバーをドメイン再参加させる必要あり
  • = 機能は全部入れ直し
  • ほぼ再構築

image.png

管理サーバー群を再構築するということは、そのサーバー群が制御している vPC も全セットアップし直しになります。

  • マスターPC からすべての vPC を再展開
  • 数も多いので、それなりに時間がかかるが、作業自体はそんなに大変ではない(管理サーバーの方がやばい)

image.png

運用面を十分考慮したアーキテクチャだったか?と言われると、正直微妙…
ただ、アーキテクチャの反省は一旦置いておいて、「なぜこんなことになったのか」にフォーカスします。

6. なぜ作業ミスは起きたのか?

D事業部長からC部長とB課長が3時間くらい会議室で詰められていました。
その後、私はB課長から物凄く怒られました。Aさんは泣いちゃいました。

ここから、なぜなぜ分析のスタートです。
「真因を探るには、最低5回は『なぜ』を繰り返せ」とよく言われますが、今回はインパクトが大きすぎたため、D事業部長から
更に深い真なる真因を出して対策せよ
というオーダーが入り、7回なぜをやることになりました。

Aさんの場合

Aさん向けのなぜなぜ。

  1. なぜ手順6で削除する場所を誤ってしまったのか?
    → Aさん「私の能力不足が原因です。大変申し訳ございません」

  2. なぜ能力不足なのか?
    → Aさん「私の能力が不足しているからです。大変申し訳ございません」

入社1年目でメンタルも消耗していたこともあり、すべて自分の能力の問題に帰属してしまう状態になっていました。

ここで一旦、Aさんへの追及はストップして私自身のなぜなぜ分析に移ります。

私の場合(7回なぜ)

  1. なぜ手順6の削除場所の誤りに気付けなかったのか?
    → 私「注意が不足していたため」

  2. なぜ注意が不足していたのか?
    → 私「寝不足だったため」

  3. なぜ寝不足だったのか?
    → 私「プライベートが充実しすぎて、睡眠時間を確保しなかったため」(= 18時間モンハン)

  4. なぜ睡眠時間を確保しなくても大丈夫だと思ったのか?
    → 私「Aさんなら問題なく、手順通りにやれると思ったから」

  5. なぜ Aさんなら問題なく手順通りにやれると思ったのか?
    → 私「すでに何度もメンテナンスを完遂した実績があったから」

  6. なぜ完遂実績が複数回あるだけで『大丈夫』だと判断したのか?
    → 私「日頃から一緒に作業していて、Aさんの作業レベルに一定の信用をしていたから」

  7. なぜ Aさんをそこまで信用してしまったのか?
    → 私「」

深淵の真因」が見えてきましたね。


直接原因への対策ももちろんやっています

ヒューマンエラーそのものを減らす対策も実施しました。

  • 手順の改善

    • スナップショットの取得と削除を、1つの手順の中で完結させる
  • 作業の自動化

    • 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 は事業部内に展開し、役職者は いつでも乱入可能

    • (役職者の中でローテーションを組んでランダムな時間に入るようにしていたらしい)
  • 作業者は画面共有し、作業画面 / 作業手順書 / チェックリスト が同時に見える状態にする

  • 確認者も同様に、作業者の画面と手順書 / チェックリストを常時表示

  • 作業中の画面を常時録画

  • 作業終了後:

    • 作業者と確認者は、録画データを視聴
    • その「視聴作業」もまた録画
  • 課長は、

    • 作業動画(作業者・確認者)2本
    • チェック動画(作業者・確認者)2本
      計4本を確認し、その様子も録画
  • 部のメンバー1名も同様に4本分を確認し、確認風景を録画

  • 部長は、

    • 課長と部メンバー1名分の「確認動画」2本をチェック

このような状況で、もし作業ミスが発生した場合、部長がすべての責任を負い、お客様対応を行う代わりに、作業者 / 確認者 / 部メンバー1名 / 課長全員に評価面のペナルティが発生。

ただし、

  • チェックのタイミングで作業ミスに気付き、部長にエスカレーションした場合はペナルティ回避

というルールにしました。つまり、 「見抜いた人が勝ち組」になる設計 です。


ぱっと見ブラックだが、実態はそこまででもない

ここまで読むと、「いやいや、これ完全にブラックでは?」と思われるかもしれません。

しかし、HZT 推進には 物理的に人と人を分離する必要があるため、副作用としてこんなルールが追加されました。

作業時は 必ずリモートワーク(原則在宅)

この話は コロナ前の出来事です。
当時はリモートワークが主流ではなかったのですが、HZT をきっかけに、メンテ作業に関わるメンバーはリモートワーク中心になりました。

結果として:

  • 在宅で作業できる
  • 集中しやすい環境で作業できる
  • 物理的な移動時間も削減できる

というメリットが大きく、むしろ積極的にメンテ作業に手を挙げる人が増えました。
(エンジニアにとって「リモートで働ける価値」がいかに大きいか、身をもって理解した瞬間です)


HZT の効果

HZT を導入してから半年間の結果です。

  • 重大トラブル:0件
  • 軽微なミスも大幅に減少
  • 後日のアンケートでは、「オフィスで複数人で作業するより、リモート環境の方が集中できる」という声が多数

「過度な信用に頼らず、記録と検証で品質を担保する」という意味で、HZT は汎用的な対策としても悪くないと感じています。

8. 最後に

ここからは少しだけ、2025年の視点で振り返った話です。

まず、今回の出来事を通して、

  • Zero Trust はセキュリティだけでなく、人間にも有効

ということがわかりました。一方で、同時にこうも感じました。

  • 相手を信じること
  • 目を見て「任せた」と言うこと
  • 同じ部屋で「おつかれ」と笑い合うこと

そういった、人と人との間にあった温度みたいなものが、少しずつ削られていく感覚がありました。

その後、私は退職しました。


ただ、データがある世界は、AIにはやさしい

ネガティブな側面はわかりやすいので、ここからは少しポジティブに考えてみます。

2025年現在、世の中的には 「AIエージェント元年」 と言われています。
どの企業も「Data & AI」と叫び、

  • AI には データが必要
  • データがなければ 学習も自動化もできない

という話は、もはや前提です。そう考えると今回の HZT のように、

  • すべての作業をオンラインで完結させ
  • すべてをログと映像で記録し
  • すべてを後から検証できる状態にしている

という業務変革をしたのは、AI から見れば最高の土壌です。なぜなら、「そこにデータがある」 からです。
もしかしたら当時の現場は今、AIで物凄く効率化できているかもしれない。


ということで、最後に少しポエムを入れてみました。
HZTはしんどかったけど良い経験になったかな~と思います。




元の記事を確認する

関連記事