こんにちは、インフラエンジニアのryuです。
運用チームを預かっている方から、こんな相談をいただくことがあります。
「夜間の呼び出し当番が、いつまでも同じ3人で回っているんです。新人にも入ってもらいたいけれど、さすがにまだ早い気がして」
この「まだ早い気がして」が半年続き、気づいたら1年経っている。そういう現場は、けっして珍しくありません。
そして厄介なことに、先送りしているあいだ、困っているのは新人ではなくベテランのほうです。夜中に起きるのも、休日にノートPCを開くのも、いつも同じ顔ぶれ。当人たちは「自分がやったほうが早い」と言いますが、その状態が続けば、辞めるときも同時に来ます。
今日は、新人インフラエンジニアをオンコール当番にどう組み込んでいくかという話をします。根性論ではなく、どの条件が揃ったら次の段階に進めるかを先に決めてしまう設計の話だと思ってください。
なぜ「まだ早い」が何年も続くのか¶
先送りが起きる理由は、実はひとつではありません。整理すると、だいたい次の3つに分かれます。
ひとつめは、基準が言葉になっていないこと。「一人で対応できるようになったら」と言いますが、その「できる」が誰の頭の中にもある感覚でしかありません。感覚が基準になっていると、判断する人によって答えが変わりますし、新人の側も何を目指せばいいのか分かりません。
ふたつめは、失敗したときのコストが読めないこと。深夜に新人が誤った対応をして被害が広がったら、という想像は誰でもします。ただ、その想像に対して「二次担当が必ず後ろにいる」「この操作までしか許可しない」といった具体的な歯止めを用意している現場は、あまり多くありません。
みっつめは、そもそも当番が過酷すぎること。アラートが一晩に10件も鳴る当番なら、新人どころか経験者でも入れたくないはずです。この場合、育成の問題ではなく運用の問題です。
この3つは、対処の順番が違います。ひとつめは今日決められること、ふたつめは体制で解けること、みっつめは当番を直さないと解けないこと。まとめて「新人がまだ育っていないから」と片付けてしまうと、どれも進みません。
先送りの本当のコストは、属人化として現れる¶
当番を固定したままにすると、負荷だけでなく知識も固定されます。夜間に起きた事象への対応は、たいてい日報や手順書には残りません。対応した本人の記憶に残るだけです。
同じ3人が3年間当番を続ければ、3年ぶんの「この症状ならまずここを見る」という判断が、その3人の中にしか存在しない状態になります。これはインフラが「あの人しかわからない」問題。属人化を解消する育成とナレッジ継承の設計でも触れた構図と同じで、育成を止めた結果として属人化が進みます。
だからこそ、当番へ入れることは「新人のための経験」であると同時に、「チームのための知識の分散」でもあります。
当番に入れる前に、何が揃っていればいいのか¶
段階の話をする前に、前提として揃えておくものがあります。ここが抜けていると、どんなに丁寧な育成をしても最初の当番で事故ります。
インシデント対応ツールを提供するPagerDutyのガイドでは、当番に入れる前にアクセス権を確認するチェックリストを作ることと、通知経路（メール・SMS・電話・チャット）が本人の環境で実際に届くかを確かめることを勧めています。当たり前のようですが、「呼び出しが鳴らなかった」という事故は、技術力ではなく設定漏れで起きます。
最低限、次のものは当番デビューの前に確認しておきたいところです。
| 確認項目 | 具体的に見るところ | よくある抜け |
|---|---|---|
| 通知が届くか | 通知経路を実際に鳴らしてテストする | 深夜のサイレントモードで鳴らない |
| 入れるか | 対象サーバー・踏み台・VPN・監視画面 | VPNの証明書が本人ぶんだけ未発行 |
| 権限の範囲 | どこまで自分の判断で操作してよいか | 「相談してから」の線引きが曖昧 |
| 連絡先 | 二次担当・責任者・ベンダーの番号 | 一覧が個人のブックマークにある |
| 手順の場所 | 手順書・構成図・過去の対応記録 | 検索できず、在り処を知る人に依存 |
| 環境 | 自宅からの接続確認、貸与端末、回線 | 一度も自宅から繋いだことがない |
この表は、そのままチェックリストとして配ってしまってかまいません。ポイントは、新人に「確認しておいて」と伝えるのではなく、日中の業務時間内に一度、全部を実際に通してみることです。読んで理解したかどうかではなく、手が動いたかどうかで判断します。
手順を「読める」ことと「探せる」ことは別物¶
もうひとつ、意外と見落とされるのが検索です。
深夜に叩き起こされた人間の頭は、思っている以上に動きません。そのときに必要なのは、手順を暗記していることではなく、目の前の症状から正しい手順書に3分でたどり着けることです。
研修では手順書を読ませますが、探させる訓練はあまりしません。日中に「この症状が出たとき使う資料を探して、URLを貼ってください」という練習を何度かやるだけで、最初の当番の手戻りはかなり減ります。
この練習には副産物があります。新人が見つけられなかった手順書は、たいてい置き場所か書き出しがおかしい。つまり、探せなかった事実そのものが、資料の不備を教えてくれます。新人を試しているつもりが、いつのまにか自分たちのドキュメントを点検していることになります。
デビューまでを4段階に分ける¶
前提が揃ったら、ここからが本題です。いきなり一次担当にするのではなく、4つの段階を踏みます。
この形はGoogleのSRE本でも紹介されているもので、新人SREはシステムを理解したうえでオンコールのシャドー（見習い同行）に入り、そこから徐々に責任を引き受けていくとされています。
段階ごとの合格条件を先に決める¶
段階を分けること自体より、各段階から次に進む条件を決めておくことのほうが重要です。ここが曖昧だと、結局「もう少し様子を見よう」で止まります。
| 段階 | やること | 責任 | 次に進む条件の例 |
|---|---|---|---|
| 1. シャドー | 当番と同じ通知を受け取り、対応を横で見る | 無し | 通知を受けて15分以内に状況を説明できる回が3回 |
| 2. 逆シャドー | 新人が手を動かし、先輩が横で見る | 形式上のみ | 主要な3系統の一次対応を、口頭補助なしで完了 |
| 3. 二次担当 | 一次からのエスカレーションを受ける | 限定的 | 判断に迷った点を自分から言語化できている |
| 4. 一次担当 | 最初の呼び出しを受ける | あり | 二次が必ず付く体制で、まずは平日夜から |
1段階あたり1〜2か月、全体で半年前後を見ておくと無理がありません。ただし、これは運用の複雑さによって変わります。扱うシステムが2〜3種類なら短くなりますし、顧客ごとに構成が違う受託運用なら、もっとかかります。
段階1と2で使う通知は、本物である必要はありません。Googleでは過去のポストモーテムを題材にした障害のロールプレイ（社内では「Wheel of Misfortune」と呼ばれています）を行っていて、進行役が状況を出し、担当役が対応を答えていく形式が紹介されています。新人にとっては、いきなり本番より心理的な負担がずっと軽くなります。
この練習の題材には、新人が育つ現場は障害から学ぶ。インフラのブレームレス・ポストモーテムを新人育成に組み込む設計で書いたような、自社の過去の障害記録がそのまま使えます。新しく教材を作る必要はありません。
手を動かす場所は本番の外に用意する¶
段階2で必要になるのが、壊してもいい環境です。深夜に初めてsystemctlを叩く、という状態は避けたい。
この点は新人インフラエンジニアには「壊していい環境」がいる。研修用サンドボックスの設計とコストの抑え方で詳しく書きましたが、当番デビューの文脈では、本番と同じ手順書が通る環境であることが特に重要になります。似ているだけの環境で練習すると、本番との差分のところで止まります。
鳴りすぎる当番は、育成の前に直す¶
ここまで育成側の話をしてきましたが、当番そのものが壊れている場合は順序が逆になります。
GoogleのSRE本では、運用業務に集中している状態でも、SREが受け取るのは8〜12時間の当番あたり最大2件程度であるべきだとしています。理由も書かれていて、原因分析・復旧・ポストモーテム作成・バグ修正まで含めると、1件あたり平均6時間かかるからです。
同じ本では、SRE全体の運用業務（チケット・当番・手作業）を50%以内に抑える上限も設けられています。超えた場合は、超過ぶんを開発チーム側へ戻す運用です。
この数字をそのまま日本の受託運用に当てはめることはできませんが、考え方は使えます。一晩に何件鳴っているかを3か月ぶん数えてみて、そのうち「人が起きて対応する必要が本当にあった」件数が何割かを出してみてください。
| 状況 | 先にやること |
|---|---|
| 一晩に5件以上鳴る | アラートの整理。育成はその後 |
| 鳴るが半分は放置でよい | しきい値の見直しと自動復旧の検討 |
| 月に数件、内容は毎回違う | 段階的な当番デビューに進んでよい |
| ほぼ鳴らない | 訓練の機会が足りない。ロールプレイで補う |
意外に見落とされるのが最後の行です。アラートが鳴らない現場は健全ですが、そのぶん新人が経験を積む機会もありません。この場合は、実地の当番ではなくロールプレイの回数で補う必要があります。
引き継ぎを型にする¶
もうひとつ、当番と当番のあいだをつなぐ引き継ぎも決めておきます。口頭で「特にありませんでした」だけだと、経過観察中の事象が落ちます。
引き継ぎに入れる項目は、多くなくてかまいません。未解決の事象、様子を見ている事象、当番中に変えた設定、次の当番が知っておくべき作業予定。この4つがあれば足ります。
書く場所も決めておいてください。個人チャットに流すと、次の当番が過去を遡れません。チームのチャンネルか、運用の記録を置いている場所に固定して、同じ書式で積み上げていくほうが後から効きます。半年もすれば、それ自体が「夜によく起きること」の一覧になります。
新人にとっては、この引き継ぎメモを書くこと自体がよい訓練になります。何が起きて、何をして、何が残っているかを言葉にする作業は、原因はだいたいログに書いてある。未経験インフラエンジニアのためのログの読み方入門で書いたような、事実と推測を分けて記述する力にそのままつながります。
労務上の前提も先に確認しておく¶
技術の話とは別に、確認しておくべきことがあります。待機を伴う勤務の扱いです。
宿直・日直として扱うには、労働基準法に基づく所轄労働基準監督署長の許可が必要で、厚生労働省は許可の基準を示しています。原則としてほとんど労働する必要のない勤務であること、回数は宿直で週1回・日直で月1回が限度とされること、手当の最低額が定められていることなどが含まれます。
自宅待機で呼び出しに応じる形のオンコールが、どの扱いに当たるかは実態によって変わります。ここは技術部門だけで判断せず、人事や社会保険労務士と相談して整理しておいてください。新人を入れるタイミングは、この整理が終わったあとです。
手当の有無や金額を曖昧にしたまま当番へ入れると、本人のモチベーション以前の問題になります。
研修とのつなぎ方¶
最後に、育成全体の中での位置づけを整理しておきます。
オンコール当番デビューは、独り立ちの最終段階に近い出来事です。逆に言えば、その前の段階で基礎が固まっていないと、4段階を踏んでも進みません。ログが読めない、プロセスの止め方が分からない、ネットワークのどこで切り分けるか見当がつかない。この状態でシャドーに入れても、隣で見ているだけになります。
前提となる基礎の作り方については、インフラ新人が独り立ちするまでを縮めるには？戦力化を早める育成の設計図にまとめています。
InfraAcademyでは、Linux・ネットワーク・AWSの実機演習を含むカリキュラムを法人向けに提供しています。当番デビューの前提になる「手が動く」状態までを外部の研修で作り、段階1以降のシャドーと引き継ぎは自社の現場で担当する、という分担は現実的です。研修の設計から相談したい場合は法人プランのご案内をご覧ください。基礎部分だけを切り出したい場合は、Linuxロードマップの内容が目安になります。
まとめ¶
新人インフラエンジニアをオンコール当番に入れる話を整理してきました。要点を振り返ります。
先送りが続くのは、基準が言葉になっていないからです。感覚ではなく、段階ごとの合格条件を先に決めてしまうこと。
当番デビューの前に、通知・権限・接続・連絡先・手順の在り処を、日中に一度すべて通しておくこと。事故の多くは技術力ではなく設定漏れで起きます。
シャドー、逆シャドー、二次、一次の4段階を踏むこと。段階1と2の題材は、自社の過去の障害記録で足ります。
そして、一晩に何件も鳴る当番なら、育成より先にアラートを整理すること。鳴らない当番なら、ロールプレイで訓練の機会を作ること。
当番を新人に開くことは、その人の成長のためだけではありません。3人の頭の中にしかない判断を、チーム全体の資産に変える作業でもあります。最初の1回さえ設計できれば、あとは回り始めます。
参考記事¶
- Google SRE Book: Accelerating SREs to On-Call and Beyond（第28章。シャドーイングと障害ロールプレイ）
- Google SRE Book: Being On-Call（当番あたりの事象件数と、運用業務50%の上限）
- PagerDuty Ops Guide: Building On-Call Culture（シャドーローテーションと事前チェックリスト）
- 厚生労働省 岡山労働局「断続的な宿直又は日直勤務については」（許可基準・回数・手当の最低額）
