こんにちは、インフラエンジニアのryuです。
障害の振り返りをしていて、こんな事実が出てきたことはないでしょうか。
新人はアラートに最初に気づいていた。でも、だれにも言わずに30分ほど一人で調べていた。先輩が気づいたときには、影響がお客様まで広がっていた。
振り返りの場で新人に理由を聞くと、たいてい返ってくる答えは同じです。「自分で直せると思った」「こんなことで先輩の手を止めていいのか分からなかった」。
これを「報連相ができない新人」で片付けてしまうのは、もったいないと私は思います。
多くの場合、抱え込みの原因は性格ではありません。いつ、だれに、何を伝えればいいのかが、どこにも書かれていないことにあります。
今日は、新人インフラエンジニアにエスカレーションを教えるための研修の組み立て方を考えてみます。
なぜ新人は、障害を一人で抱え込んでしまうのか？¶
まず、新人の頭の中で何が起きているのかを整理しておきます。原因が分かれば、研修で何を教えればいいかも見えてきます。
「聞く」ことにコストがあると感じている¶
新人から見ると、先輩はいつも忙しそうです。チャットで声をかければ、その人の作業を止めることになる。
しかも、声をかけた結果が「それ、ログ見れば分かるよ」だったら恥ずかしい。そう考えると、もう少し自分で調べてから、という気持ちになるのは自然なことです。
ここで起きているのは、聞くコストと、黙っているリスクの見積もりのずれです。新人は聞くコストを大きく、黙っているリスクを小さく見積もっています。現場の感覚はその逆です。
判断の基準が、先輩の頭の中にしかない¶
もうひとつの原因は、基準の不在です。
「おかしいと思ったらすぐ言って」という指示は、一見わかりやすく見えます。でも、新人には何が「おかしい」のかが分かりません。ディスク使用率が85％なのはおかしいのか。応答が普段より2秒遅いのはおかしいのか。
経験のある先輩は、その線引きを無意識にやっています。けれど、それは言葉になっていないので、新人に渡っていません。
たとえるなら、道を知っている人が「迷ったら電話して」と言うようなものです。迷っていることに気づけない人には、その電話をかけるタイミングがありません。
エスカレーションは「気合い」ではなく「基準」で教える¶
では、どうすればいいのでしょうか。答えはシンプルで、判断の基準を先に書いてしまうことです。
参考になるのが、Google のSRE本にある「Managing Incidents」の章です。そこでは、インシデントを宣言すべきかどうかの目安として、次のような問いが挙げられています。
別のチームの手を借りる必要があるか。お客様から見える障害か。1時間集中して調べても解決していないか。（Google SRE Book「Managing Incidents」の趣旨を要約）
同じ章では、インシデントは早めに、こまめに宣言したほうがよいという考え方も示されています。宣言してからあっさり直って閉じるほうが、何時間もたってから慌てて体制を組むよりずっとましだ、という理屈です。
ここで大事なのは、判断が「気持ち」ではなく「問い」になっていることです。問いであれば、新人でも答えられます。
自社向けの「エスカレーション基準表」を作る¶
SRE本の問いは、そのまま新人に渡すには少し抽象的です。そこで、自社の運用に合わせて具体化した表を作ります。
たとえば、次のような形です。
| 状況 | 目安 | 新人がやること |
|---|---|---|
| お客様・利用者に影響が出ている／出そう | 気づいた時点 | すぐに当番の先輩へ連絡。調査より先 |
| 手順書どおりに対応して、手順書と違う結果が出た | その場で | 手を止めて相談。次の手順に進まない |
| 原因の見当がつかない | 15分 | 調べた内容をまとめて相談 |
| 見当はついているが、直す操作に自信がない | 操作の前 | 実行予定のコマンドを見せて確認をもらう |
| 本番のデータ削除・再起動・設定変更を伴う | 操作の前 | 必ず二人で確認（ダブルチェック） |
数字は会社ごとに変えてかまいません。大事なのは、新人が迷ったときに見に行ける場所があることです。
「15分」という数字も、根拠があるわけではありません。ただ、書いてあれば新人は時計を見て判断できます。書いていなければ、30分でも1時間でも「まだ自分で調べるべきだ」と考えてしまいます。
「早すぎる相談」を叱らないと先に約束する¶
基準表を作っても、それだけでは足りません。新人が本当に相談できるかどうかは、相談したときの先輩の反応で決まるからです。
Google の re:Work が紹介している Project Aristotle では、効果的なチームの条件として心理的安全性がいちばん重要だとされています。チームの中で、質問やミスの報告をしても責められないと感じられるかどうか、という指標です。
新人にとって、最初の数回の相談は試金石になります。ここで「そんなことで呼ぶな」と返されたら、次からは呼ばなくなります。
だから研修の最初に、チームとして宣言しておきます。基準に沿って相談したことを、結果的に大したことがなかったとしても責めない。むしろ、早く言ってくれたことを評価する、と。
これは先輩側への研修でもあります。新人を受け入れる先輩が、この約束を知らなければ意味がありません。
何を伝えるか。報告には「型」を与える¶
基準ができて、相談してもいい空気ができても、まだ壁があります。いざ先輩に声をかけたとき、何をどう伝えればいいのか分からない、という壁です。
新人の最初の報告は、たいてい「なんか、サーバーがおかしいです」になります。これでは先輩は、状況を聞き出すところから始めなければなりません。
報告テンプレートを渡しておく¶
そこで、報告の型を先に渡しておきます。チャットに貼れるテンプレートにしておくと、緊張していても使えます。
【相談】web-prod-02 で応答遅延
■ 何が起きているか : 監視で /health の応答が 5 秒超（10:42 から）
■ 影響 : 利用者影響は未確認。エラー率は通常どおり
■ 確認したこと : CPU 30%、メモリ余裕あり。
nginx のエラーログに upstream timeout が出ている
■ まだ見ていないこと : アプリ側のログ、DB の負荷
■ 自分の次の一手 : アプリのログを確認しようと思っています
■ 相談したいこと : このまま調べてよいか、先に誰かに共有すべきか
ポイントは、最後の2行です。「自分の次の一手」と「相談したいこと」まで書かせると、先輩は判断だけすればよくなります。
同時に、新人にとっては考えを整理する練習になります。テンプレートを埋めている途中で、自分で答えに気づくこともよくあります。
「まだ見ていないこと」を書かせる理由¶
テンプレートの中で、いちばん大事なのは「まだ見ていないこと」の欄だと私は考えています。
新人は、分かったことだけを報告しがちです。でも先輩が知りたいのは、どこまで調べて、どこが空白なのかです。空白が分かれば、次に何を見ればいいかをすぐに指示できます。
また、見ていないことを書くのは、分からないことを認める練習でもあります。これができる新人は、現場に出てから伸びるのが早いです。
「だれに」伝えるかも、名前で決めておく¶
いつ・何を、が決まっても、もうひとつ迷うところが残ります。だれに伝えるか、です。
新人にとって「先輩に相談して」という指示は、意外と使いにくいものです。先輩が5人いれば、だれに声をかけるべきか分かりません。結果として、いちばん話しかけやすい人に偏るか、だれにも言えずに終わります。
そこで、連絡先は役割と順番で決めておきます。たとえば、平日の日中は「今週の一次当番」、つながらなければ「チームリーダー」、お客様影響があれば「サービス責任者」にも同時に共有する、といった具合です。
チャットであれば、個人宛てのメッセージではなく、チームの障害用チャンネルに書かせるのもおすすめです。個人宛てだと、その先輩が会議中なら30分止まってしまいます。チャンネルなら、手の空いている人が拾えます。
これは宅配便の再配達と似ています。届け先が「だれか家にいる人」なら困りますが、「不在なら宅配ボックス、それも無理なら営業所」と決まっていれば、荷物は止まりません。
研修の中で、エスカレーションを「練習」させる¶
ここまでの基準表とテンプレートは、配るだけでは身につきません。避難訓練と同じで、一度でも体を動かしておくことが大切です。
研修にエスカレーションの練習を組み込む方法を、3つの段階で紹介します。
| 段階 | 内容 | 狙い |
|---|---|---|
| 1. 机上演習 | 障害のシナリオを読み、どの時点で誰に何を言うかを書く | 基準表を使って判断する練習 |
| 2. 模擬障害 | 研修環境でわざと障害を起こし、報告テンプレートで連絡させる | 手を動かしながら報告する練習 |
| 3. 振り返り | 報告のタイミングと中身を、責めずに一緒に見直す | 次の判断に活かす |
段階2は「壊していい環境」でやる¶
模擬障害の練習には、本番と切り離された環境が必要です。サービスを止めたり、ディスクを埋めたりしても誰も困らない場所です。
こうした環境の作り方は、新人インフラエンジニアには「壊していい環境」がいるで詳しく解説しています。
シナリオは、最初は単純なものでかまいません。たとえば、Webサーバーのプロセスが止まっている、ディスクが満杯になっている、といったものです。
演習では、直せたかどうかより、何分後にどんな報告をしたかを見ます。基準表の目安を過ぎても一人で調べていたら、それがそのまま振り返りの題材になります。
振り返りは、ブレームレスで行う¶
振り返りの目的は、新人を評価することではありません。どこで判断に迷ったのか、なぜ報告が遅れたのかを言葉にすることです。
この考え方は、本番の障害で行うブレームレス・ポストモーテムと同じです。研修のうちに体験しておくと、本番の振り返りにも自然に参加できるようになります。詳しくは新人が育つ現場は障害から学ぶを参考にしてください。
当番デビューとOJTにつなげる¶
研修でエスカレーションを練習した新人は、次に実際の運用の中でそれを使います。ここで研修と現場がつながっていないと、せっかくの練習が活きません。
私がおすすめしているのは、研修で使った基準表とテンプレートを、そのまま現場の運用ドキュメントに置くことです。研修の中だけのルールにしないのがポイントです。
また、新人が夜間や休日の当番に入る前には、エスカレーションの連絡先と順番を必ず確認させます。当番に入るまでの段階の踏み方は、夜中の呼び出し当番、新人インフラエンジニアはいつから入れる？でまとめています。
日々のOJTでは、先輩が相談を受けたあとに一言だけフィードバックを返す習慣をつけると効果的です。「この報告は分かりやすかった」「次はこの情報も入れてくれると助かる」といった短いもので十分です。
OJTを仕組みとして回すための工夫は、“背中を見て覚えろ”では、もう育たないも参考になるはずです。
InfraAcademyで、報告できる土台をつくる¶
最後に、少しだけ研修の土台の話をさせてください。
エスカレーションの報告は、技術的な基礎がないと書けません。「nginx のエラーログに upstream timeout が出ている」と書くためには、ログの場所と読み方を知っている必要があります。
基礎が弱い新人ほど、何が分かっていないかも分からず、抱え込みやすくなります。逆に、Linux やネットワークの基本を体系的に押さえた新人は、「ここまでは確認した」と言える範囲が広がります。
InfraAcademy では、Linux・ネットワーク・AWS の基礎を、ブラウザ上で手を動かしながら学べる講座を用意しています。法人向けには、新人の進み具合を担当者が確認できるプランもあります。
新人インフラエンジニア研修の土台づくりを検討されている方は、InfraAcademyの法人プランをご覧ください。基礎の部分を任せていただければ、社内の研修はエスカレーションのような現場ならではのテーマに時間を使えるようになります。
まとめ¶
新人が障害を一人で抱え込むのは、性格の問題ではなく、基準と型が渡されていないことが原因です。
今日の内容を振り返っておきます。
- 新人は「聞くコスト」を大きく、「黙るリスク」を小さく見積もりがち
- エスカレーションは、時間や状況で決めた基準表で教える
- 早すぎる相談を責めないことを、チームとして約束する
- 報告にはテンプレートを渡し、「まだ見ていないこと」まで書かせる
- 研修の中で、机上演習・模擬障害・振り返りの順で練習させる
エスカレーションは、新人が一人前になってから覚えるものではありません。むしろ、一人では何もできない最初の時期にこそ、いちばん必要になる技術です。
研修の最初の週に、基準表を1枚配るところから始めてみてはいかがでしょうか。
