本番の障害が、新人インフラエンジニアの初めての障害対応になっていませんか。机上で回す障害対応訓練の始め方

こんにちは、インフラエンジニアのryuです。

新人インフラエンジニアが、初めて障害対応を経験したのはいつだったか。育成担当の方は、思い出せるでしょうか。

多くの現場では、答えは「本番で障害が起きたとき」だと思います。先輩の横で画面を見ていて、気づいたら終わっていた。そんな形で最初の障害を経験する新人は珍しくありません。

障害は予定を立てて起きてくれません。だから、障害対応は現場で自然に覚えるもの、と考えられがちです。

ただ、それだと新人が障害対応を練習できる回数は、実際に起きた障害の件数で決まってしまいます。障害が少ない現場ほど、新人は練習できないまま当番に入ることになります。

今日は、本番環境に一切触れずに、会議室と過去の障害記録だけで始められる机上の障害対応訓練について考えていきます。

障害対応は、なぜ本番でしか覚えられないのか？¶

障害対応がうまい人は、知識が多いだけではありません。症状を見て、どこから疑うかをすぐに決められます。

この「どこから疑うか」は、手順書を読んでも身につきにくい部分です。似た症状を何度か見て、そのたびに考えた経験から少しずつできあがっていきます。

問題は、その経験を積む場が本番しかないことです。本番の障害では、先輩は復旧を急いでいます。新人に考えさせる時間はありませんし、新人が間違った手を打てば被害が広がります。

結果として、新人は見ているだけになります。何度か障害に立ち会っても、自分で判断した経験はゼロのまま、という状態が起こります。

この点について、GoogleのSREチームは古くから訓練で補ってきました。『Site Reliability Engineering』の新人SREを当番に立ち上げる章では、定期的に障害のロールプレイを行う伝統があると紹介されています。

GoogleのSREが続けている「Wheel of Misfortune」とは？¶

GoogleのSREが行っているロールプレイは、Wheel of Misfortune（不運の輪）と呼ばれています。Google Cloudのブログでは、次のように説明されています。

Wheel of Misfortuneは、緊急事態への対応方法を試すためのロールプレイのシナリオである。この演習の目的は、完全に模擬された緊急事態を通じて学ぶことにあり、昔ながらのロールプレイの形式で、エンジニアがデバッグとトラブルシューティングの手順をたどっていく。 （Google Cloud Blog "Shrinking the time to mitigate production incidents—CRE life lessons" より意訳）

進め方はシンプルです。システムに詳しい先輩が進行役（ゲームマスター）になり、過去に起きた障害をもとにシナリオを用意します。

進行役は、まず「どうやって障害に気づいたか」を伝えます。たとえば「監視から、Webサーバーの応答時間が悪化したというアラートが来ました」という形です。

新人は、自分なら何を確認するか、どのコマンドを打つかを口で答えます。進行役はそれに対して「その結果、こういう出力が返ってきました」と返します。これを繰り返して、原因の特定と復旧までたどり着けるかを見ます。

同じ記事では、この訓練の良さとして、本番に何の影響も与えない安全な環境で行えることが挙げられています。失敗しても誰も困らない場所で、判断の練習ができる。これが机上訓練のいちばんの価値です。

本番で障害を起こす訓練との違い¶

Googleには、DiRT（Disaster Recovery Testing）と呼ばれる、本物の障害や架空の障害を計画的に起こして対応を試す全社的な取り組みもあります。こちらは実際にサービスを止めることもあるため、切り戻しの計画や承認の仕組みが欠かせません。

新人の育成という目的なら、まず取り組むべきは机上のロールプレイのほうです。二つを比べると、次のようになります。

実機で手を動かす練習をさせたい場合は、研修用の検証環境で障害を再現する方法もあります。壊してよい環境の作り方は、研修用サンドボックス環境の記事で紹介しています。

机上訓練で身につくもの・身につかないもの¶

机上訓練は万能ではありません。コマンドを正しく打つ力や、出力を素早く読む力は、実機で手を動かさないと身につきにくい部分です。

一方で、次のような力は机上のほうがむしろ鍛えやすいと感じています。

• 症状から、どの層を先に疑うかを決める力
• 調べた結果を、先輩や関係者に短く報告する力
• 自分で抱えずに、エスカレーションを判断する力

どれも本番では新人に回ってきにくい役割です。机上訓練は、本番で経験できない部分を補うものと考えると位置づけがはっきりします。

机上の障害対応訓練をどう準備するか？¶

ここからは、実際に訓練を始めるための準備を見ていきます。必要なものは多くありません。

シナリオは過去の障害記録から作る¶

シナリオを一から考える必要はありません。自社で過去に起きた障害の記録が、いちばん良い素材になります。

ポストモーテム（障害の振り返り資料）を残している現場なら、それをそのまま使えます。振り返りの書き方については、ブレームレス・ポストモーテムの記事で詳しく解説しています。

過去の記録をシナリオに作り替えるときは、次のような形に整理しておくと、進行役が当日迷いません。

【シナリオ】Webサーバーの応答が遅い（2025年○月の障害をもとに作成）

■ 最初に伝えること
  19:40 監視から「Web01 の応答時間が 5 秒を超えた」とアラート。
  問い合わせ窓口から、画面の表示が遅いという連絡が2件。

■ 新人の確認に対して返す情報
  - uptime / top      → load average が 12 前後。CPU の us は 20% 程度
  - df -h             → /var が 100%
  - ログの確認        → アプリのログが 1 時間で 20GB 増えている
  - 誰に連絡するか    → アプリ担当の連絡先は運用手順書の3章

■ 正解の流れ（進行役だけが持つ）
  ディスク逼迫の確認 → 増えているファイルの特定 → アプリ担当へ連絡
  → 不要ファイルの退避で暫定復旧 → 原因調査はアプリ担当と日中に

■ 見たい観点
  - 最初の10分で、報告を1回入れられたか
  - 自分で消してよいファイルかどうかを確認したか

ポイントは、新人の確認に対して返す情報をあらかじめ用意しておくことです。進行役が即興で作ると、話の筋がぶれたり、つい答えを教えてしまったりします。

役割を決めておく¶

訓練には、最低でも次の3つの役割がいると進めやすくなります。

記録係を新人に任せるのはおすすめです。他人の対応を横から見ると、自分が対応者のときには気づかなかった抜けがよく見えます。

進行役は、答えを教えたくなる気持ちをこらえるのが一番の仕事です。対応者が詰まったときは、答えではなく「ほかに見られる情報はありますか？」と問いを返すようにします。

訓練当日の進め方と振り返り¶

1回の訓練は、60分あれば十分です。長くやると集中が切れ、振り返りの時間が削られてしまいます。

時間の配分は、たとえば次のようにしておくと回しやすくなります。

振り返りの時間を削らないことが大切です。訓練の学びの多くは、シナリオを進めている最中ではなく、あとで自分の判断を見直すときに生まれます。

振り返りで見るのは、正解したかどうかではない¶

振り返りでは、原因にたどり着けたかどうかはあまり重視しません。見るのは判断の順番と、報告の仕方です。

たとえば、次のような問いを使います。

• 最初に確認したことは何で、なぜそれを選んだのか
• 報告を入れたのは何分後で、どんな内容だったか
• 自分だけで判断してはいけない場面はどこだったか

3つ目の問いは特に大切です。障害対応でいちばん困るのは、新人が一人で抱え込んで報告が遅れることだからです。エスカレーションを研修で教える方法は、新人が障害を一人で抱え込む理由を扱った記事にまとめています。

記録を育成の資料にする¶

記録係が残したメモは、そのまま育成の資料になります。同じシナリオを半年後にもう一度やってみると、判断の早さや報告のタイミングがどう変わったかが比べられます。

また、訓練の中で「この情報はどこに書いてあるのか分からなかった」という声が出たら、それは手順書や連絡体制の穴です。訓練は新人のためだけでなく、チームの運用を見直すきっかけにもなります。

新人の段階に合わせて、訓練の難易度を上げていく¶

同じ訓練を同じ難しさで繰り返すと、新人は飽きてしまいます。段階に合わせて、シナリオと役割を少しずつ変えていきましょう。

最後の段階で、新人を進行役にするのがポイントです。シナリオを作るには、障害の流れと判断の分かれ目を深く理解していないといけません。人に教える側に回ると、知識が定着しやすくなります。

夜間の呼び出し当番に入る前の準備として、この訓練を組み込むのも効果的です。当番デビューまでの段階づくりは、夜間当番のオンボーディングの記事で解説しています。

机上訓練は、本番の障害を減らすための仕組みではありません。本番の障害が起きたときに、新人が初めて判断する場面にしないための仕組みです。

最初の訓練でよくあるつまずき¶

初めて訓練をすると、いくつか同じようなところでつまずきます。事前に知っておくと、当日あわてずに済みます。

一つ目は、進行役が情報を出しすぎることです。新人が黙ってしまうと、つい「ログを見てみたら？」と言いたくなります。ここで答えを言うと、新人は次から進行役の顔色をうかがうようになります。

二つ目は、シナリオが難しすぎることです。最初の1回は、原因が1つで、確認するべき場所も少ない障害を選びましょう。新人が最後までたどり着けた、という経験を先に作るほうが、次の訓練への意欲につながります。

三つ目は、訓練を評価の場にしてしまうことです。訓練の結果を人事評価に使うと、新人は間違えないことを優先して、口に出す量が減ります。訓練はあくまで練習の場だと、最初にはっきり伝えておきましょう。

訓練を続けるための工夫¶

訓練は、始めることより続けることのほうが難しいものです。忙しい時期になると、真っ先に削られてしまいます。

続けるためには、まず頻度を決めてしまうことです。月に1回、60分と決めてカレンダーに入れておくだけでも、実施率はかなり変わります。

また、シナリオは1回作れば何度も使えます。チームで共有のフォルダを作り、訓練のたびに1本ずつ増やしていくと、1年後には新人研修に使えるシナリオ集ができあがります。

先輩の負担が心配な場合は、進行役を持ち回りにするのも方法です。進行役を務めると、先輩自身もシステムの理解を見直すきっかけになります。

外部の研修と組み合わせる¶

机上訓練は、Linuxやネットワークの基礎が身についている前提で成り立ちます。df や ss の出力の意味が分からない段階の新人には、訓練の前に基礎を固める時間が必要です。

InfraAcademyでは、Linux・ネットワーク・AWSの基礎を、実機での演習を交えて学べるカリキュラムを法人向けに提供しています。基礎の部分を外部の研修に任せ、自社の障害事例を使った訓練を現場で行う、という分担にすると、先輩の負担を減らしながら育成を進められます。

新人インフラエンジニア研修の内容や進め方については、InfraAcademyの法人プランをご覧ください。

まとめ¶

今日は、新人インフラエンジニアのための机上の障害対応訓練について解説しました。要点を振り返ります。

• 本番の障害だけに頼ると、新人が自分で判断する経験はなかなか積めない
• GoogleのSREは、Wheel of Misfortuneというロールプレイで障害対応を練習している
• シナリオは過去の障害記録から作り、確認への返答をあらかじめ用意しておく
• 振り返りでは正解かどうかより、判断の順番と報告のタイミングを見る
• 段階に合わせて難易度を上げ、最後は新人を進行役にする

障害は予定どおりには起きませんが、訓練は予定を立てて行えます。まずは過去の障害を1件選んで、60分の訓練から始めてみてください。

参考¶

• Shrinking the time to mitigate production incidents—CRE life lessons（Google Cloud Blog）
• Accelerating SREs to On-Call and Beyond（Google SRE Book）
• dastergon/wheel-of-misfortune: A role-playing game for incident management training（GitHub）