【実録】300台のサーバが沈黙。システム障害対応の舞台裏でリーダーはどう動いたか

インフラエンジニアとしてキャリアを積む中で、避けては通れないのが「大規模システム障害」です。特に、物理レイヤの予期せぬ挙動は、時に冗長化構成という安全神話をいとも簡単に打ち砕きます。

今回は、私がかつて若手エンジニアとして経験した、「FCスイッチのサイレント故障」という壮絶な障害対応の記録を共有します。

300台の仮想サーバが沈黙したあの日、現場のリーダーがどのように舵を取り、チームを復旧へと導いたのか。そのプロセスには、現代のITサービスマネジメントにも通じる重要な教訓が凝縮されていました。

今回は、私が若手時代に経験した「27時までの死闘」を、リーダーシップの観点から論理的に整理しました。

※当時の現場の緊迫感や、作業者としての私の心の動きについては、Noteでドキュメンタリー調の記事として公開しています。あわせて読むと、より「現場のリアル」が伝わるはずです。

システム構成と「見えない」異常の発生

当時のシステムは、複数の物理ストレージと仮想化基盤サーバを、2台のFC（ファイバーチャネル）スイッチ経由で接続する標準的なSAN（Storage Area Network）構成でした。Active-Standby構成により、万が一の故障時も自動で切り替わるはずの、堅牢な仕組みだったはずです。

しかし、その日は違いました。19時、突如としてすべての仮想サーバが無応答状態に陥ります。

• 発生した事象: FCスイッチ内のバッファ領域がファームウェアのバグにより枯渇。
• 「半死に」の状態: 通信データは一切転送できないにもかかわらず、スイッチ自体はキープアライブ（生存確認）に応答し続けたため、待機系へのフェールオーバーが発生しなかった。
• 現場の混乱: 監視ツールもハードウェアのLEDも「正常（緑色）」を示しており、一見すると異常箇所が特定できないという、インフラエンジニアにとって最も厄介な「サイレント故障」でした。

障害対応のタイムライン：空白の8時間を追う

現場がどのように原因を突き止め、復旧作業に当たったのか。その客観的な記録です。

時刻	状況と対応のプロセス	現場の主な動き
19:00	事象発生・初動調査	全仮想サーバが無応答。ハイパーバイザー側からストレージへのパスを確認するが、接続エラーが頻発。
20:00	影響範囲の特定	WindowsはOSレベルでハングアップ、Linuxは画面が黒くOSが認識できない状態。ハードウェア故障を疑い、総当たりでログを精査。
21:00	被疑箇所の断定と決断	仮想化基盤とストレージ双方のログの共通点から「FCスイッチの内部フリーズ」を特定。リーダーがスイッチの強制再起動を指示。
22:00	一次復旧とOSの選別	再起動により接続が回復。Windowsサーバはファイルシステムのレジリエンスにより自動復旧。アプリの起動確認へ移行。
23:00	Linuxサーバの二次障害	多くのLinuxサーバが「ディスク破損の可能性」によりOS起動不可。1台ずつレスキューモード等でのディスク修復（fsck）を開始。
25:00	全OS起動完了	300台すべてのOS起動を確認。並行して業務アプリケーションの起動と正常性確認を実施。
27:00	完全復旧・収束	全システムが正常稼働していることを確認。事象収束を宣言し、解散。

現場を支えた「リーダーシップ」の3つの本質

この緊迫した8時間の中で、リーダーが取った行動には、単なる技術力以上の価値がありました。

① 「戦力の逐次投入」を避けるリソース管理

障害発生は定時後。当初、現場には数名しか残っていませんでした。しかしリーダーは、初報から30分で「これは長期戦になる」と判断。迷わず非番のメンバーに連絡し、駆けつけを依頼しました。

結果として、深夜の過酷なディスク修復作業を10名体制で分担できたことが、27時という（この規模としては）迅速な復旧を可能にしました。「誰が何をすべきか」というリソースの最適化は、技術判断と同じくらい重要です。

② 外部の雑音を遮断する「シールド」としての役割

300台のサーバが止まれば、顧客や各ステークホルダーからの問い合わせは怒涛のごとく押し寄せます。

リーダーは、電話対応や状況報告を一手に引き受け、作業者の視界から「焦り」を排除しました。技術者がログの1行、コマンドの結果の1つに集中できる環境を死守したのです。これがなければ、焦りによる操作ミスでさらに被害が拡大していたかもしれません。

③ アナログな「可視化」による連帯感の醸成

Linuxサーバの復旧が難航した際、リーダーが最初にしたのは、全対象サーバをリスト化した「物理的なチェックシート」の作成でした。

デジタルな管理も大切ですが、深夜の疲弊した現場では「紙にチェックを入れる」という達成感と、チーム全体の進捗が一目でわかる可視化が、メンバーのモチベーション維持に大きく貢献しました。早く終わったメンバーが自然と他のサポートに入る、自律的なチームがそこにはありました。

今回の対応が成功した大きな要因は、単なる技術的な知識だけでなく、チームを統制するリーダーシップが機能したことにあります。有事の際ほど重要になる『技術力という裏付け』と『統率力』のバランスについて、より深く考察した内容もぜひ参考にしてください。

運用の敗北を認め、次への教訓とする

後日の詳細調査で、原因はFCスイッチのファームウェアバグと判明しました。エンジニアとして悔しいのは、どんなに完璧な二重化を組んでいても、このような「バグによるサイレント故障」は防ぎようがないという事実です。

• 暫定対応: 修正パッチが出るまで、数ヶ月にわたり「定期的な手動再起動」という、エンジニアの誇りとは裏腹な泥臭い運用を続けました。
• 得られた知見: 「冗長化されているから安心」という盲信を捨て、キープアライブが正常でもサービスが死んでいる「ハーフデッド」な状態を想定した監視設計の重要性を痛感しました。

まとめ：リーダーは「背中」で語る

大規模障害の現場において、リーダーが「すべての答え」を知っている必要はありません。

大切なのは、「誰よりも早く事態の深刻さを認め、戦力を整え、メンバーを信じて作業に没頭させること」です。

当時のリーダーが見せた、顧客の前に立って現場を守る後ろ姿。そして、深夜2時にメンバー全員でチェックシートを埋めていったあの時間は、今の私のエンジニア人生の大きな糧となっています。

インフラを支える皆様。もし明日、あなたの現場で「正常なのに動かない」という矛盾が起きたなら、この記事を思い出してください。技術は裏切っても、冷静な判断とチームの結束は、必ずあなたを夜明けへと導いてくれるはずです。

---

障害現場では、技術力のあるリーダーほど「自分でコマンドを打ったほうが早い」という誘惑に駆られます。しかし、リーダーが作業に没頭した瞬間、チームの俯瞰的な視点は失われます。

大規模障害を乗り切るために必要なのは、「あえて作業を任せ、自分は判断に徹する」というマネジメントへの脱皮です。私が「自分でやったほうが早い」という呪縛をどう解いたのか、そのステップをこちらにまとめています。