オンコールを始める

Alert Fatigue

このページには、オンコールに期待されることと役立つ情報を要約します。

オンコールとはなにか？#

オンコールを始めるということは、担当システムで発生しうる問題の調査、修正をするために、いつでも連絡を取れる状態であることを意味します。たとえばPagerDuty内のサービスのオンコールを担当している場合、サービスに関するアラートがトリガーされると、あなたは"ページ (page)" （モバイルデバイスによるアラート、メール、電話、SMSなど）で、何が機能しなくなったか、それをどう修正すべきかを受け取ります。あなたには、問題を解決してサービスを通常の状態に戻すアクションが期待されます。

オンコールの責務は通常の業務時間を超え、問題が発生すれば、午前2時であっても対応することが期待されます。これは恐ろしく思えますが（そして起こりうること）が、これは私たちの顧客が遭遇することで、PagerDutyの製品が修正しようとしてる問題たちです。

責務#

準備
- ラップトップとインターネットの準備します（オフィス、自宅、MiFiドングル、テザリングプラン付きの電話など）。
- チームアラートのエスカレーションは5分以内に発生するように、通知タイムアウトがそれぞれ適切に設定、調整する（プッシュ通知、SMS、電話など）。
  - PagerDutyのテキストと電話が"Do Not Disturb"を回避してるか。
- 準備ができているか（環境がセットアップされ、必要なレポジトリがローカルにコピーされて動作し、ワークステーションでも環境がセットアップされており、サードバーティーサービスのクレデンシャルが最新であるか、など）
- 私たちのインシデント対応プロセス（このドキュメント）を読んで、深刻なインシデントの処理方法、コミュニケーション上の様々な役割とその方法について理解する。
- オンコール時間（プライマリ、バックアップ）の予定に注意し、旅行、休暇、予約などのスケジュールを調整する。
トリアージ
- 可能ならアラートに応答して対応する（下記の「義務ではない」を参照）。
- 問題の深刻度を判断。
  - すぐに対応する必要があるか、または重大インシデントにエスカレーションするか（プロダクションサーバーが炎上している、セキュリティの警告が出ている）。
  - 夜間に実施する必要がない作業か（例えばディスク使用率が一定値以上になったが、十分な空き容量があり増加傾向も穏やか）。より適切な時間（業務時間、翌朝）までアラートをスヌーズにして後で修正する。
- Slackで現在のアクティビティを確認。多くの場合は、アラートを引き起こす可能性のあるアクションがそこで告知されている（いつもではない）。
- アラートと初期調査が、一般的な問題なのか関連チームが調査する必要がある特定のサービスで発生しているか。あなたの専門ではないようなら、他のチームにエスカレーションする。
修正
- あなたには問題に飛び込みそれを修正できる権限がある。
- 必要に応じて他のチームを巻き込む。原因をなかなか特定できない場合、または対応したことがないサービスやアラートの場合は、遠慮なくエスカレーションする。
- 急ぐような問題ではなく、他に優先的な作業がある場合は、追従できるようJIRAチケットを（適切な優先度で）設定する。
改善
- 特定の問題が再発する場合、たとえばアラートが頻繁に送られているが回避可能である場合、おそらくより長期的な作業が必要になる。
  - ディスクがいっぱいになり、ログのローテーションが必要で、うるさいアラート...
- もし情報を見つけるのが難しかったり不可能な場合は書き留めておく。ナレッジベースとドキュメントのリファクタ、改善を継続的に行う。 wikiやcodebaseの意図が、現在の分類方法と異なる場合は、追加のリンクやポインターを追加する。
サポート
- あなたのオンコールシフトが終了したら、次のオンコール担当者に、まだ解決してない問題や他の注意すべき体験について知らせる。
- スケジュールに影響がある変更がある場合（例えば自分のシフトを追加、削除）は、オンコールスケジュールを事前に調整するため、他の人にも伝える。
- 互いにサポートし合う。大量のページが発生する可能性がある行動をする場合は、その期間のオンコールスケジュールを無効化して担当者からページを引き受けるのが礼儀です。

義務ではない#

全ての アラートに対して最初に応答することは期待されません。
- 実際には通勤などがあります、エスカレーションする前に受信や応答ができないこともある。そのためのバックアップオンコールとそのスケジュールである。
全ての問題を自分で解決することは期待されません。
- 誰もが、全てを知っているわけではない。チーム全体で手助けする。確信がもてない問題をエスカレーションすることは、恥ずべきことではないし学びもある。私たちのモットーは「エスカレーションをためらわない」
- サービスオーナーは、どのように動くかをよく知っている。特に私たちやサービスオーナーのドキュメントが足りないとき、関連チームとのダブルチェックによりミスを防げる。念には念を、多くの場合は専門家に任せるのがベストです。

推奨事項#

チームがオンコールローテーションを開始する場合、オペレーションチームからスケジュールに関する推奨事項があります。

常にバックアップスケジュールを組む。これは常に2人が同じオンコールで待機するということである。チームからメンバーを選ぶのではなく、連絡できるバックアップがいることがわかると、プライマリメンバーのストレス軽減にもなる。
- バックアップシフトは通常、プライマリシフトの直後に割り当てる。シフト中に前回のプライマリから追加のコンテキストを渡せる機会になる。また次のシフトで問題の発生を防ぐために修正するのにも役立つ。
エスカレーションの第3レベル（バックアップより後）はおそらくチーム全体にすべき。これは起こらないべき（オペレーションチームの歴史で1度だけ起こった）だが、そうなった場合は次に対応可能な人を探す必要がなくなる。

Escalation

チームマネージャーは通常のローテーションに組み込める（組み込むべき）。何が起こっているかのより良い洞察になる。
チームの新しいメンバーは、最初の2-3週間はオンコールのローテーションをシャドウイングすべき。全てのアラートを受け取り、何をしてるか追従する必要がある。（全ての新入社員はオペレーションチームをシャドウイングしているが、新しいチームメンバーがチームローテーションをシャドウイングするのも役立つ。）
エスカレーションタイムアウトは5分が推奨である。これは誰かが応答するのに十分な時間であるべき。もし5分以内に対応できない場合は、おそらく対応できる状況ではない。
オンコールを終わるとき、次のオンコール担当者のシフト中に発生しうる問題について、簡単な要約を担当者に提供する必要がある。サービスが安定しない、問題が再発する可能性があるなど。もしきちんとするならメールで報告してもよいが、通常は口頭で十分である。

通知方法の推奨事項#

あなたにとって最適な通知ルールを自由に追加できます。もし設定方法がわからない場合は、オペレーションチームはいくつかの推奨事項があります。

Mobile Alerts

プッシュ通知とメールを最初の通知に設定します。私達のほとんどは常に携帯電話を持っているので、通常はこれで十分です。
エスカレーションの時間まで毎分、電話とSMSのどちらか、または両方に通知します。プッシュでうまく通知できない場合、電話ほど強力なものが必要になる可能性があります。手遅れになるまで毎分電話します。 3回目までに連絡がとれないと、対応できない可能性があり、インシデントはエスカレーションされます。

エチケット#

オンコール担当者が正午に出社して疲れているようなら、それは彼が怠惰だからではありません。おそらく夜に緊急対応していました。気を遣いましょう。
他の誰かに通知されたインシデントに応答しないでください。あなたがインシデントにページされなかった場合は応答すべきではないです。代わりにあなたのメモをコメントしておきます。

Acknowledging

あなたがもし何かをテストをしていたり、ページが発生しうるアクションを実行する場合は、その期間のページを引き受けるようにします。テストしている期間のページを引き受けるよう、オンコール担当者に伝えます。
エスカレーションをためらわないでください。問題の解決法がわからない場合、誰かの手を借りることを恥ずかしく思わないでください。同様に誰かがあなたに助けを求めても、見下してはいけません。
もし1時間程度オンコールを頼まれたら、可能な場合は引き受けるようにしましょう。誰しもオンコールに対応できない可能性がある生活をしています。ある日、町の外からの友達と夜を過ごすために、オンコールの時間を交代できるのはあなたかも知れません。
オンコールシフト中にページを受け取ると、その問題を解決する責務があります。 3時間かかってシフトの残り時間が1時間であっても。次のオンコール担当者が良いといえば引き継ぐこともできますが、それが常に可能とは限りません。