全社横断で障害訓練を実施してみた ー GMOメディアの取り組み🚨

はじめに

GMOメディアでシステム部門を管掌しています。

エンジニア組織として障害対応能力の向上は常に課題として認識しており、2025年11月28日に全社横断で障害訓練を実施しました。本記事では、訓練の経緯、実施内容、そして得られた気づきについてまとめます。

障害訓練実施の背景

弊社では、各サービスで発生した障害を月次で集計・可視化し、エンジニアマネージャー定例（EMキープ）で振り返りを行っています。この振り返りの中で、以下のような課題が浮き彫りになりました。

• エスカレーションフローの理解度にばらつきがある
• 障害対応できる人が限られている（特定のベテランに依存しがち）
• 新しいメンバーが障害対応を経験する機会が少ない

これらの課題を解決するため、「実際に障害を発生させて対応を経験する」という訓練を企画しました。

訓練の目的とスコープ

目的

1. エスカレーションフローの理解を深める
2. 障害対応できる人を増やす

やらないこと

• 土日に張り付いて検知できるようにすること（ただし気付ける努力は必要）
• 技術的な障害訓練（障害は意図せず発生するため）

今回の訓練は「技術的な復旧スキル」よりも「フローの確認と実践」に重点を置いています。

事前準備

訓練実施前に、各チームで以下の準備を行いました。

• プロダクト別のエスカレーションフローの定義と見直し（事業部メンバー・緊急連絡先含む）
• 最低限のプロダクトアーキテクチャ理解（構成、リリース方法、ログの見方、サーバメトリクスの見方）

訓練の実施形式

レッドチーム方式の採用

今回の訓練では、エンジニアマネージャー（EM）がレッドチームとして障害を仕掛ける形式を採用しました。メンバーには実施タイミングを含めて一切知らせず、本番さながらの緊張感で対応してもらいました。

実施日の選定

実施日は 私（管掌役員）の誕生日 に設定しました🎂

これは完全に遊び心ですが、「いつ来るか分からない」という本番の障害に近い状況を作り出すためでもあります。次回以降は推測されてしまうため、EMメンバーの誰かの誕生日（平日限定） に実施することを検討しています。

事業責任者への事前共有

事業責任者クラスには以下の2点を事前に共有していました。

1. ランダムなタイミングで訓練を実施する旨
2. 当日の訓練開始時にSlackで訓練中である旨

しかし、本番の障害と認識して慌てた責任者もいたようです😅

これはある意味、訓練の臨場感が出ていた証拠かもしれません。事業責任者を含めた連携フローの確認という意味でも、良い副次効果がありました。

実施内容

2025年11月28日、6つのプロダクトチームが同時に障害訓練を実施しました。

チーム	実施時間帯	実施内容（EMが仕掛けた障害）
チームA	15:00〜16:00	DoS攻撃シミュレーション
チームB	16:00〜18:00	DBを壊す＆不正金額の特定
チームC	15:00〜16:00	外部APIアカウント停止シナリオ
チームD	15:00〜16:00	ローカルPCからのDBコネクション過多
チームE	14:00〜16:00	CloudSQLへの接続不可
チームF	14:00〜16:00	DBパスワードの不正値設定（503エラー）

各チームがサービス特性に応じた障害シナリオを設定し、ステージング環境で訓練を行いました。

振り返りと気づき

訓練後、各チームから以下のような振り返りが上がりました。

【良かった点】

初動の迅速さ
チームEでは、エラー報告から障害対応チャンネルへの集合、スレッドでの会話開始までがスムーズでした。全員が出社していたため、物理的に集まって対応できたのも大きなプラスでした。

役割分担の実践
チームDでは、DB・インフラチームとプロダクトエンジニアが自然に役割分担し、DBチームがIP特定やコネクション調査を担当、プロダクトエンジニアはアプリケーションに集中できました。

チームワーク
「足りてないことを指摘しあってカバーしていた」という声が複数のチームから上がりました。

【改善すべき点】

1. 連絡チャンネルの誤認

複数のチームで「どのチャンネルで対応すべきか」が曖昧になっていました。チームFでは、当初別のチャンネルで対応しようとしたところ、正しいチャンネルへ移動するよう指摘を受けるケースがありました。

対策: 障害対応フローのドキュメントに各サービスの対応チャンネルを明記し、定期的に周知する

2. 事業部への連絡漏れ

エンジニアは技術的な修正（コード修正、LB設定、コンテナ対応など）に集中するあまり、事業部への報告が後回しになりがちでした。

対策: 役割分担を明確化し、「報告担当」を最初に決めるフローを追加する

3. 障害レベル定義の混乱

「重大障害の定義」と「グループ管理向けの障害レベル基準（レベル1,2,3）」が異なることで、エスカレーション判断に迷いが生じました。

対策: 障害レベルと重大障害の基準を一元化したドキュメントを整備する

4. 障害検知の遅れ

チームFでは、障害発生から気づくまで約20分かかりました。

対策: Slackの通知設定を見直し、アラートチャンネルの投稿は必ず通知が来るよう設定を徹底する

5. ドキュメントの場所が分かりにくい

「障害対応フローのドキュメントがどこにあるか分からなかった」という声がありました。

対策: 関連ドキュメントにリンクを追加し、Qに1回は読む機会を設ける

振り返りマトリクス

各チームの振り返り結果を一覧化しました。チーム横断で共通する課題が見えてきます。

評価観点別マトリクス

評価観点	チームA	チームB	チームC	チームD	チームE	チームF
初動スピード	⚠️	✅	⚠️	✅	✅	⚠️
チャンネル認識	⚠️	✅	⚠️	✅	⚠️	⚠️
役割分担	⚠️	✅	❌	✅	⚠️	✅
事業部連携	⚠️	✅	⚠️	⚠️	⚠️	✅
原因特定	✅	✅	✅	✅	✅	✅
障害管理ツール起票	✅	✅	✅	✅	✅	✅

✅ = 問題なし　⚠️ = 改善の余地あり　❌ = 要改善

課題の出現頻度

連絡チャンネルの誤認・不明確    ████████████ 4チーム
事業部への連絡遅れ・漏れ        ██████████   4チーム  
役割分担の不明確さ              ████████     3チーム
障害検知の遅れ                  ██████       2チーム
ドキュメント所在の不明          ██████████   4チーム
障害レベル定義の混乱            ████         2チーム

優先度の高い全社共通アクション

優先度	アクション	該当チーム数
🔴 高	各サービスの障害対応チャンネルを一覧化・周知	4/6
🔴 高	障害対応フロードキュメントのリンク整備	4/6
🟡 中	役割分担テンプレートの作成（報告担当の明確化）	3/6
🟡 中	Slack通知設定の棚卸し	2/6
🟢 低	障害レベル定義の統一	2/6

emergencyチャンネルの活用

横断チームからは「emergencyチャンネルを使った方が良い」という提案がありました。

• グループ報告シミュレーションとして活用できる
• 連動障害の可能性を考慮した横断的な情報共有ができる

また、「個別の対処・言動含めた記録をしておく」ことの重要性も確認されました。あるチームではHuddleで対応を録画しており、振り返りに活用しています。

今後に向けて

今回の訓練を通じて、各チームの障害対応力の現状と改善ポイントが明確になりました。

訓練の頻度

年に1回〜半年に1回の実施を予定しています。人の入れ替わりが多いチームは、頻度を上げることも検討します。

次回の実施タイミング

前述の通り、EMメンバーの誕生日（平日） にランダムで実施予定です。誰の誕生日になるかは...その日が来るまでのお楽しみです。

継続的な改善

訓練で見つかった課題は、エンジニアMGRキープで継続的にフォローアップし、共通のルール化を進めていきます。

過去の取り組みからの学び

あるチームでは、以前Q単位で1年ほど障害訓練を実施していました。当時の課題として「メンバーがルールを守らずマンネリ化した」という経験があります。訓練を形骸化させないためにも、適度な緊張感と目的意識を持って継続することが重要です。

おわりに

障害訓練は「やって終わり」ではなく、見つかった課題を改善し、次の訓練に活かしていくサイクルが大切です。

今回の訓練では、以下の3点が特に重要だと再認識しました。

1. フローの可視化と定期的な周知
2. 報告と技術対応の役割分担
3. チームで補い合う文化の醸成

障害対応は属人化しやすい業務ですが、訓練を通じて「誰でも初動対応ができる」状態を目指していきます。

そして何より、レッドチーム方式で「いつ来るか分からない」緊張感を持たせることが、実践的な訓練には効果的でした。事業責任者が本番と勘違いして慌てたエピソードも含めて、組織としての障害対応力を高める良い機会となりました。

同じような課題を抱えている組織の参考になれば幸いです。