夜間対応あり、当番あり。求人や先輩の話でそう聞くと、夜中にひとりで障害を直し続ける姿が浮かびます。ただ、当番の中身はそこまで単純ではありません。誰が最初に受けるのか、どこまで自分で動くのか、直せないときは誰に渡すのか。この記事では、その役割の分け方と渡し方を整理します。
この記事の結論
- 当番は、アラームを受ける人を時間帯ごとに決めておく仕組みです。目的は「誰も気づかない時間」を作らないことです。
- 一次対応は、影響の確認・手順書（ランブック）の実行・状況の共有までです。原因の深掘りは必須ではありません。
- 手順書の範囲外、または影響が大きいときは、基準に沿って二次対応・責任者・ベンダーなどへ渡します。
- 渡すのは失敗ではなく仕組みの一部です。判断の遅れのほうが被害を広げます。
- 対応後は記録を残して振り返り、手順書とアラームを直します。これが当番の負担を下げます。
- 学習者が今から備えられるのは、手順書を読む力・時系列で状況を書く力・切り分けの順番です。
運用当番（オンコール）とは何か｜「全部直す人」ではなく「最初に受ける人」
オンコール（運用当番）とは、システムのアラームや問い合わせを受け取る人を、時間帯ごとにあらかじめ決めておく仕組みです。決めておく理由は単純で、障害は仕事の時間に合わせて起きてくれないからです。受ける人が決まっていなければ、アラームが鳴っても誰も見ていない時間ができます。
ここで大切なのは、当番の役割は「全部を自分で直すこと」ではない点です。当番は障害対応の入口にいる人で、最初に気づき、状況を確かめ、決められた範囲で動き、必要なら次の人につなぎます。原因を完全に突き止めるのは、落ち着いてから別の人や場で行うこともあります。
この考え方は、AWS の Well-Architected フレームワークの「運用上の優秀性」の柱とも重なります。この柱は、チームの編成、ワークロードの設計、運用、改善を扱います。つまり運用は、個人の頑張りではなく、チームの仕組みとして設計するものだという立場です。
以降の「手順書の範囲」や「渡す基準」の具体的な運用は、特定の組織の取り決めに依存する一般的な説明です。AWS の公式な定義として書いているのではありません。
障害のとき、誰がどの順で動くのか
障害対応は、おおむね「検知 → 一次対応 → エスカレーション → 復旧 → 振り返り」の順に進みます。駅が変わるたびに、担当する人が変わると考えると掴みやすくなります。
FROM ALARM TO REVIEW障害の流れを5駅で
障害は検知から振り返りまで5つの駅を通り、駅ごとに担当が変わる
-
検知
アラームが当番に届く
-
一次対応
当番が手順書の範囲で動く
-
引き渡し
決まった相手へエスカレーション
-
復旧
二次対応・責任者が判断する
-
振り返り
記録を残し手順書を直す
| 段階 | 主な担当 | やること |
|---|---|---|
| 検知 | 当番 | アラームや問い合わせを受け取る。誰が受けたかが分かる状態にする |
| 一次対応 | 当番 | 影響の確認、手順書の実行、状況の共有 |
| エスカレーション | 当番 → 二次対応・責任者など | 基準に沿って、見たことと分かっていないことを添えて渡す |
| 復旧 | 二次対応・関係者 | 範囲を超える調査と判断。復旧を優先し、原因の究明は分けて考える |
| 振り返り | チーム全体 | 記録を残し、手順書とアラームを直す |
アラームを受けた直後に何を見るかは alarm-shoki-unyo で、障害のあとの振り返りの書き方は postmortem-toha で扱います。この記事では、役割と渡し方に絞ります。
CHECK 1ここまでの確認
運用当番の主な役割として最も近いのはどれか?
答えと解説
答え: 2. 検知を最初に受け、手順の範囲で一次対応をして、必要なら渡す
当番は「最初に受ける人」です。原因の完全な解明までが役割ではありません。読み直すのは「運用当番（オンコール）とは何か」の章です。
一次対応で「やっていいこと」と「やってはいけないこと」の線はどう引くのか
一次対応の線は、ランブック（手順書）の範囲で引くのが基本です。ランブックとは、「この事象が起きたら、この順で確認し、この操作をする」と事前に書いておいた手順のことです。
やっていいこと
- 影響を確かめる。誰に何が起きているか（止まっているのか、遅いのか、一部だけなのか）を見る
- 手順書に載っている確認や操作を、書いてある順で実行する
- 見たこと、やったこと、時刻を時系列で共有する
やってはいけないこと
- 手順書に無い操作を、自己判断で試す
- 自分の権限や担当の範囲を超えた変更をする
- 状況を伝えないまま、ひとりで抱え込む
一次対応で避けたい3つ
- 手順書に無い操作を、確信がないまま試す
- 影響の大きさを確かめる前に、原因探しに入り込む
- 共有せずにひとりで抱え込む
手順書に無いことを試すのは、善意でも危険です。未知の操作が状況を悪化させたり、あとで原因を調べる手がかりを消したりすることがあるからです。「何もしない」のではなく、「分かっていることを伝えて、決まった相手に判断を任せる」のが線です。
FIX OR HAND OVER自分で直すか渡すか
3つの門を1つでも通れなければ、自分で直さず渡す
一次対応の門
- 手順書手順書に載っている事象 手順どおり実行書いてある範囲
- 影響影響が大きい・広がっている すぐ渡す基準を超えている
- 権限自分の権限の外の操作 権限のある人へ許可されていない
CHECK 2ここまでの確認
手順書に載っていない事象が起きたとき、最初にすることは?
答えと解説
答え: 1. 状況を共有して、決まった相手へエスカレーションする
範囲外の操作は、被害を広げることがあります。見たことと分かっていないことを伝えて渡すのが一次対応の線です。読み直すのは「一次対応で、やっていいこと・いけないこと」の章です。
いつ・誰にエスカレーションするのか
エスカレーションとは、自分の範囲を超えると判断したときに、決まった相手へ状況を渡すことです。判断の材料は、大きく3つあります。
| 見るもの | 問い | 当てはまるとき |
|---|---|---|
| 手順書の範囲 | 書いてある事象か | 載っていないなら渡す |
| 影響の大きさ | 利用者や業務への影響は大きいか、広がっているか | 大きい・広がっているなら、すぐ渡す |
| 権限 | 自分にその操作が許されているか | 許されていないなら、権限のある人へ |
渡す相手は、組織ごとに決まっています。二次対応の担当、責任者、ベンダーやクラウド事業者の窓口など、事前に「誰に・どの順で」を決めておくのが普通です。何を「影響が大きい」とするかの基準も、組織の取り決めです。この記事では数値や具体的な時間は書きません。
迷ったら早く渡す
判断に迷う状況は、実は「基準に当てはまっていない」か「基準が曖昧」のサインです。渡し過ぎれば、起こされた人の手間が増えます。一方、渡すのが遅れれば、影響が広がり、復旧の開始も遅れます。後者のほうが被害が大きくなりやすいので、天秤は「早く渡す」側に傾けます。
SPEED OR HANDOVER迷ったときの天秤
迷ったら早く渡す。渡し過ぎの負担より、判断の遅れの被害が重い
渡し過ぎの負担
- 起こされた人の手間
- 結果的に不要だった呼び出し
判断が遅れた被害
- 影響が広がる
- 復旧の開始が遅れる
- 未知の操作で悪化しうる
支点は「基準に当てはまるか」。迷うこと自体が渡すサイン
渡すときは、次の3点を添えると相手が動きやすくなります。
- 何が起きているか（見えていること）
- いつから、どこまで影響が出ているか
- 何を試したか、まだ分かっていないことは何か
CHECK 3ここまでの確認
渡す判断が遅れると、何が起きやすいか?
答えと解説
答え: 2. 影響が広がり、復旧の開始が遅れる
渡すのは失敗ではなく仕組みの一部です。遅れた判断のほうが被害を広げます。読み直すのは「いつ・誰にエスカレーションするのか」の章です。
当番の負担を下げる仕組み
当番がつらくなるのは、夜間に呼ばれることそのものより、「同じ呼び出しが繰り返される」「手順書が古い」「誰も交代できない」といった仕組みの穴が原因のことが多いものです。負担は、個人の根性ではなく仕組みで下げます。
- 手順書の更新: 対応のたびに、足りなかった手順を書き足す
- アラームの整理: 対応が要らない通知や、何度も鳴るだけで動けない通知を減らす
- 交代制: 特定の人に当番が偏らないようにし、休める状態を作る
- 記録: 何が起きて、何をして、誰に渡したかを残す
対応のあとに記録を残して見直すところまでが、当番の仕事の一部です。ここから先の、原因と再発防止を整理する型は postmortem-toha にまとめています。
CHECK 4ここまでの確認
対応が終わったあとに、当番の仕組みとして欠かせないことは?
答えと解説
答え: 2. 記録を残し、手順書とアラームを見直す
同じ呼び出しを繰り返さないための見直しが、次の当番の負担を下げます。読み直すのは「当番の負担を下げる仕組み」の章です。
求人の「当番あり」「夜間対応」をどう読むか
求人票の「当番あり」は、それだけでは中身が分かりません。次の点を、求人票や面接で確認する項目として読みます。
| 確認する項目 | 見たいこと |
|---|---|
| 頻度 | どれくらいの間隔で当番が回ってくるか（数字は会社ごと。相場は書けません） |
| 手当 | 待機や対応に対して、どう扱われるか |
| 体制 | 何人で回すか。二次対応の担当や責任者は決まっているか |
| 最初に任される範囲 | 先輩と組むか。手順書の範囲から始められるか |
| 引き継ぎ | 当番を交代するときの記録の残し方が決まっているか |
「当番あり」の良し悪しは、有無ではなく、これらの仕組みが整っているかで決まります。
学習者が今のうちに備えられること
実際に当番を経験していなくても、学習のうちに練習できることがあります。
- 手順書を読む力: 公式ドキュメントや手順を、書いてある順に追って、前提と範囲を読み取る
- 時系列で状況を書く力: 「何時に何を見て、何が分かり、何をしたか」を短く書く練習
- 切り分けの順番: 影響の確認から入り、範囲を狭めていく順番を知っておく
どれも、特別な現場がなくても練習できます。身につくほど、「渡すときに伝わる」一次対応に近づきます。
まとめ。 運用当番は、全部を自分で直す人ではなく、最初にアラームを受けて、手順書の範囲で動き、範囲を超えたら決まった相手へ渡す役割です。渡すのは仕組みの一部で、迷ったら早く渡します。対応のあとは記録を残して手順書とアラームを直し、次の負担を下げます。次は、アラームを受けた直後の見方と、振り返りの型に進んでください。
参照ソース
- AWS Well-Architected フレームワーク｜Operational Excellence — 運用上の優秀性の柱が、チームの編成・ワークロードの設計・運用・改善を扱うこと（枠組みの根拠）
- Operational Excellence Pillar（AWS Well-Architected） — 運用を仕組みとして設計する関連資料。この記事のランブックやエスカレーションの説明は一般論で、この資料の記述としては書いていない
