Being On-Call

オンコール時の期待値と役立つ情報の概要

オンコールとは?#

オンコールとは、担当するシステムで発生した問題を調査し、解決するために、いつでも連絡が取れる状態にあることを意味します。例えば、PagerDutyで担当するサービスに対してオンコールの場合、そのサービスでアラームがトリガーされた場合、「通知」(モバイルデバイスへのアラート、電子メール、電話、SMSなど)が送信され、問題の詳細と解決方法が通知されます。問題を解決し、サービスを通常の状態に戻すために必要なあらゆる措置を取ることが求められます。

オンコールの責任は通常の就業時間を超えても継続し、オンコールの場合は深夜であっても問題に対応できることが求められます。これは恐ろしいように聞こえますが(実際、恐ろしいものです)、これはお客様が経験することであり、PagerDuty製品自体が解決しようとしている問題なのです!

責任範囲#

  1. 準備

    • ノートパソコンとインターネット環境を常に用意しておく(オフィス、自宅、MiFiドングル、テザリングプラン付きの電話など)。
      • MiFiを充電する方法を用意しておく。
    • チームアラートのエスカレーションは5分以内に行われるため、通知のタイムアウト(プッシュ、SMS、電話など)を適切に設定する。
    • 準備を整えてください(環境が設定され、必要なリポジトリの現在の作業コピーがローカルで機能しており、ワークステーション上の環境は設定およびテスト済みで、サードパーティサービスの認証情報が最新であるなど)。
    • 当社のインシデント対応に関する文書(これです!)をお読みいただき、重大なインシデントへの対応方法、さまざまな役割やコミュニケーション方法などをご確認ください。
    • オンコールの時間(プライマリ、バックアップ)を把握し、出張、休暇、予定などに応じて交代要員を手配してください。
  2. トリアージ

    • 可能な限りアラートを確認し、対応してください(下記「責任外」の最初の項目をご覧ください)。
    • 問題の緊急度を判断する:
      • それは今直ぐ対応すべきものか、重大なインシデントとしてエスカレーションすべきものか?(例えば「本番サーバーがダウンしている」状況や、セキュリティアラート) - そうしてください。
      • 夜間対応は不要だが、先を見据えて行う必要のある作業か? 例えば、ディスク使用率が高水準値だが、十分な空き容量が残っており、傾向から差し迫った危機が迫っているわけではない場合など。より適切な時間(就業時間中または翌朝)までアラートを無視し、その時間帯に修正作業を行う。
    • Slackで現在のアクティビティを確認します。 常にとは限りませんが、アラートを引き起こす可能性のあるアクションは、そこでアナウンスされていることがよくあります。
    • アラートと初期調査から、一般的な問題なのか、関連チームが調査すべき特定のサービスに関する問題なのかが示されていますか? もし、あなたが専門家として対応すべき問題ではないようであれば、他のチームにエスカレーションします。
  3. 修正

    • あなたは、どのような問題でも調査し、解決する権限を与えられています。
    • 必要に応じて他のチームメンバーを関与させる:妥当な時間内で原因を特定できない場合、またはサービス/アラートが以前に扱ったことのないものである場合は、ためらわずにエスカレーションしてください。
    • すぐ取り掛かる必要がない問題で、他の優先度の高い作業がある場合は、JIRAチケットを作成して(適切な重大度で)追跡してください。
  4. 改善

    • 特定の問題が繰り返し発生する場合、あるいはアラートが頻繁に鳴るが、実際には防止可能なであることが判明した場合、おそらくこれの改善は長期的なタスクとすべきでしょう。
      • 一杯になるディスク、ローテーションすべきログ、過剰なアラートなど
    • 情報を見つけるのが難しい、あるいは不可能な場合は、それを書き留めてください。知識ベースとドキュメントを常に再構築し、改善してください。あなたの頭の中のWikiやコードベースが、現在の構成と一致しない場合は、情報を補う可能性のあるリソースへのリンクやポインタを追加してください。
  5. サポート

    • オンコールの「シフト」が終了したら、次のオンコール担当者に、まだ解決されていない問題や、その他の特記すべき事項を知らせてください。
    • スケジュールに影響を与える変更(例:自身の追加/削除)を行う場合は、多くのメンバーがオンコールスケジュールに合わせて前もって調整しているため、他のメンバーに知らせてください。
    • お互いにサポートし合う:大量の通知を生成する可能性のある作業を行う場合は、オンコールのメンバーに知らせ、その間スケジュールをオーバーライドすることで、そのメンバーから「通知を奪う」ことができます。

責任外#

  1. オンコール期間中にすべてのアラートを最初に確認できることを期待してはいけません。

    • 通勤(およびその他の必要な気晴らし)は生活の一部であり、アラートがエスカレーションされる前に受信したり対応したりできないこともあります。そのためにバックアップのオンコールとスケジュールがあるのです。
  2. すべての問題を自分だけで解決するというのは期待値ではありません。

    • すべてを知っている人はいません。チーム全員があなたをサポートします。自信のない問題をエスカレーションすることを恥じる必要はありませんし、学ぶこともたくさんあります。私たちのモットーは「ためらわずにエスカレーションする」です。
    • サービスオーナーは、常に自分たちの業務についてより詳しく知っています。特に、私たちのドキュメントやお客様のドキュメントに不足がある場合、関連チームとダブルチェックすることでミスを回避できます。後々のことを考えて、念には念を入れましょう - そして、対象分野の専門家(SME)に最終確認してもらうのが最善である場合が多いです。

推奨事項#

貴社のチームがオンコールのローテーションを開始する場合、運用チームからのスケジュールに関するいくつかの推奨事項を以下に示します。

エスカレーション * チームマネージャーは、通常のローテーションの一部とすることができます(そして、そうすべきです)。これにより、何が起こっているのかをより深く理解することができます。

通知方法の推奨#

インシデントへの対応方法に合わせて、通知ルールを自由に設定することができます。設定方法がわからない場合は、運用チームがいくつかの推奨事項を用意しています。

モバイル通知

エチケット#

確認