Being On-Call
オンコール時の期待値と役立つ情報の概要
オンコールとは?#
オンコールとは、担当するシステムで発生した問題を調査し、解決するために、いつでも連絡が取れる状態にあることを意味します。例えば、PagerDutyで担当するサービスに対してオンコールの場合、そのサービスでアラームがトリガーされた場合、「通知」(モバイルデバイスへのアラート、電子メール、電話、SMSなど)が送信され、問題の詳細と解決方法が通知されます。問題を解決し、サービスを通常の状態に戻すために必要なあらゆる措置を取ることが求められます。
オンコールの責任は通常の就業時間を超えても継続し、オンコールの場合は深夜であっても問題に対応できることが求められます。これは恐ろしいように聞こえますが(実際、恐ろしいものです)、これはお客様が経験することであり、PagerDuty製品自体が解決しようとしている問題なのです!
責任範囲#
-
準備
- ノートパソコンとインターネット環境を常に用意しておく(オフィス、自宅、MiFiドングル、テザリングプラン付きの電話など)。
- MiFiを充電する方法を用意しておく。
- チームアラートのエスカレーションは5分以内に行われるため、通知のタイムアウト(プッシュ、SMS、電話など)を適切に設定する。
- PagerDuty からのテキストメッセージや電話が 「おやすみモード」の設定を回避 できることを確認してください
- 準備を整えてください(環境が設定され、必要なリポジトリの現在の作業コピーがローカルで機能しており、ワークステーション上の環境は設定およびテスト済みで、サードパーティサービスの認証情報が最新であるなど)。
- 当社のインシデント対応に関する文書(これです!)をお読みいただき、重大なインシデントへの対応方法、さまざまな役割やコミュニケーション方法などをご確認ください。
- オンコールの時間(プライマリ、バックアップ)を把握し、出張、休暇、予定などに応じて交代要員を手配してください。
- ノートパソコンとインターネット環境を常に用意しておく(オフィス、自宅、MiFiドングル、テザリングプラン付きの電話など)。
-
トリアージ
- 可能な限りアラートを確認し、対応してください(下記「責任外」の最初の項目をご覧ください)。
- 問題の緊急度を判断する:
- それは今直ぐ対応すべきものか、重大なインシデントとしてエスカレーションすべきものか?(例えば「本番サーバーがダウンしている」状況や、セキュリティアラート) - そうしてください。
- 夜間対応は不要だが、先を見据えて行う必要のある作業か? 例えば、ディスク使用率が高水準値だが、十分な空き容量が残っており、傾向から差し迫った危機が迫っているわけではない場合など。より適切な時間(就業時間中または翌朝)までアラートを無視し、その時間帯に修正作業を行う。
- Slackで現在のアクティビティを確認します。 常にとは限りませんが、アラートを引き起こす可能性のあるアクションは、そこでアナウンスされていることがよくあります。
- アラートと初期調査から、一般的な問題なのか、関連チームが調査すべき特定のサービスに関する問題なのかが示されていますか? もし、あなたが専門家として対応すべき問題ではないようであれば、他のチームにエスカレーションします。
-
修正
- あなたは、どのような問題でも調査し、解決する権限を与えられています。
- 必要に応じて他のチームメンバーを関与させる:妥当な時間内で原因を特定できない場合、またはサービス/アラートが以前に扱ったことのないものである場合は、ためらわずにエスカレーションしてください。
- すぐ取り掛かる必要がない問題で、他の優先度の高い作業がある場合は、JIRAチケットを作成して(適切な重大度で)追跡してください。
-
改善
- 特定の問題が繰り返し発生する場合、あるいはアラートが頻繁に鳴るが、実際には防止可能なであることが判明した場合、おそらくこれの改善は長期的なタスクとすべきでしょう。
- 一杯になるディスク、ローテーションすべきログ、過剰なアラートなど
- 情報を見つけるのが難しい、あるいは不可能な場合は、それを書き留めてください。知識ベースとドキュメントを常に再構築し、改善してください。あなたの頭の中のWikiやコードベースが、現在の構成と一致しない場合は、情報を補う可能性のあるリソースへのリンクやポインタを追加してください。
- 特定の問題が繰り返し発生する場合、あるいはアラートが頻繁に鳴るが、実際には防止可能なであることが判明した場合、おそらくこれの改善は長期的なタスクとすべきでしょう。
-
サポート
- オンコールの「シフト」が終了したら、次のオンコール担当者に、まだ解決されていない問題や、その他の特記すべき事項を知らせてください。
- スケジュールに影響を与える変更(例:自身の追加/削除)を行う場合は、多くのメンバーがオンコールスケジュールに合わせて前もって調整しているため、他のメンバーに知らせてください。
- お互いにサポートし合う:大量の通知を生成する可能性のある作業を行う場合は、オンコールのメンバーに知らせ、その間スケジュールをオーバーライドすることで、そのメンバーから「通知を奪う」ことができます。
責任外#
-
オンコール期間中にすべてのアラートを最初に確認できることを期待してはいけません。
- 通勤(およびその他の必要な気晴らし)は生活の一部であり、アラートがエスカレーションされる前に受信したり対応したりできないこともあります。そのためにバックアップのオンコールとスケジュールがあるのです。
-
すべての問題を自分だけで解決するというのは期待値ではありません。
- すべてを知っている人はいません。チーム全員があなたをサポートします。自信のない問題をエスカレーションすることを恥じる必要はありませんし、学ぶこともたくさんあります。私たちのモットーは「ためらわずにエスカレーションする」です。
- サービスオーナーは、常に自分たちの業務についてより詳しく知っています。特に、私たちのドキュメントやお客様のドキュメントに不足がある場合、関連チームとダブルチェックすることでミスを回避できます。後々のことを考えて、念には念を入れましょう - そして、対象分野の専門家(SME)に最終確認してもらうのが最善である場合が多いです。
推奨事項#
貴社のチームがオンコールのローテーションを開始する場合、運用チームからのスケジュールに関するいくつかの推奨事項を以下に示します。
-
常にバックアップのスケジュールを用意しておく。つまり、2人の担当者が同時にオンコールとなることを意味します。チームのメンバーをランダムに選ぶのではなく、特定のバックアップ担当者に連絡できることを知っていれば、オンコールの主担当者のストレスを大幅に軽減できます。
- バックアップシフトは通常、プライマリーシフトの直後に来るべきです。これにより、前のシフトの担当者がシフト中に発生した追加の状況を伝える機会が生まれます。また、次のシフトに問題を先送りする意図で、問題を放置するのを防ぐことにも役立ちます。
-
バックアップスケジュールに次ぐエスカレーションの第3レイヤーは、おそらくチーム全体となるでしょう。これは、決して起こってほしくないことですが(運用チームの歴史の中で一度だけ起こったことがあります)、実際に起こった場合には、ただ次の手が空いている人に対応してもらうだけで済むので便利です。
* チームマネージャーは、通常のローテーションの一部とすることができます(そして、そうすべきです)。これにより、何が起こっているのかをより深く理解することができます。
-
チームの新しいメンバーは、最初の数週間はオンコールのローテーションをシャドーイングすべきです。彼らはすべてのアラートを受け取り、あなたがしていることについてフォローすべきです。(すべての新入社員は、1週間のオンコールの間、運用チームのシャドーイングをしますが、新しいチームメンバーがチームのローテーションのシャドーイングをすることも有用です。 ただし、同時にシャドーイングすることは避けてください)。
-
エスカレーションのタイムアウトは5分に設定することをお勧めします。対応できるのであれば、5分間は十分な時間です。5分以内に対応できないのであれば、その人はおそらくそのインシデントに対応できる状態ではないでしょう。
-
オンコールから外れた場合は、次のオンコール担当者のシフト中に発生する可能性のある問題について、簡単な概要を伝えるべきです。サービスが不安定になっている、問題が再発しそうである、など。正式な報告書を作成したい場合は、電子メールで送付することもできますが、通常は口頭で概要を伝えるだけで十分です。
通知方法の推奨#
インシデントへの対応方法に合わせて、通知ルールを自由に設定することができます。設定方法がわからない場合は、運用チームがいくつかの推奨事項を用意しています。
- 通知の最初の手段として、プッシュ通知と電子メールを使用します。ほとんどの人は常に携帯電話を所持しているので、これが賢明な最初の手段であり、通常は十分です。
- その後、エスカレーションの時間まで、1分ごとに電話および/またはSMS通知を使用します。プッシュ通知が機能しなかった場合は、電話など、より強力な手段が必要である可能性が高いです。1分ごとに電話をかけ続けます。3回目の電話に出なかった場合は、対応が不可能である可能性が高く、インシデントをエスカレーションします。
エチケット#
-
昼の12時にオンコール担当者が疲れた様子でオフィスに入ってきたとしても、それは彼らが怠けているからではありません。おそらく夜中に呼び出されたのでしょう。少し大目に見て、親切にしてあげましょう。
-
他の誰かの担当外のインシデントを確認してはいけません。そのインシデントであなたに通知が鳴らなかったのであれば、確認してはいけません。代わりにメモをコメントとして追加してください。
-
何かをテストしたり、通知を発生させることが分かっているアクションを実行する場合、テストを行っている間は自分で「通知を取る」のが通例です。テストを行う間、次の1時間は自分が通知を取ることをオンコール担当者に知らせます。
-
「エスカレーションを躊躇しないこと。」問題の解決方法がわからない場合は、他の誰かを巻き込むことを恥ずかしいと思わないでください。同様に、他の誰かが助けを求めてきた場合、その人を見下してはなりません。
-
他のメンバーが希望し、あなたが対応できる場合は、1時間程度オンコールシフトをカバーすることを常に検討してください。私たちには誰しも、オンコールシフトに代えがたい生活があります。いつか、今度はあなたに代わって誰かがオンコールシフトを引き受けてくれたおかげで、遠方から来た友人と過ごせる夜が来るかもしれません。
-
オンコールシフト中に問題が発生し通知で呼び出された場合、その解決はあなたに責任があります。たとえシフトの残り時間が1時間しかなくても、3時間かかったとしてもです。次のオンコール担当者が同意すれば引き継ぐことはできますが、引き継ぎが可能だと決めてかかるべきではありません。