PagerDuty のベストプラクティスからオンコール管理を学んでみた
こんにちは。
ご機嫌いかがでしょうか。
"No human labor is no human error" が大好きな吉井 亮です。
世の中の多くのアプリケーションは24時間稼働が前提だと思います。予期せぬインシデントが発生した際の対応はどうしているでしょうか？
N+N で冗長構成を組みサービス停止を回避するのが一般的です。ただやはり回復に人手が必要なケースはどうしてもあります。
24時間の運用体制を整えるために必須である「オンコール管理」を学びたく、PagerDuty 社が公開しているベストプラクティスを読んで自分なりの解釈でサマリーしてみました。
序章
ほとんどのサービスが常に稼働していると顧客からは想定されています。最新のサービスは複雑化してきているため汎用オペレーションセンターで全ての特異なアラートに対応するのが難しくなってきています。
これまでオンコールの責任を追わなかったチーム (開発者やSRE、プラットフォームエンジニアだろうと推測します) が時間外対応することの期待が高まっています。
予測可能なオンコールスケジュールを作成することはチームにとって有益です。チームメンバーが受ける予定外の中断を減らすことが可能です。
DevOps や SRE モデルを検討するチームが増えてくるにつれ、幅広い個人がオンコール責任を負うことも増えてきました。
影響力のある変化は、アプリケーション開発チームが大きな役割を果たすようになってきたことです。コードを最も知っている者をオンコールチームに含めることは大きなメリットです。
オンコールスケジュールはチームの健全性を明確に把握できます。
- メンバーはいつ対応すればよいか知る
- いつ休暇をとっていいか
- 携帯電話を引き出しにしまって寝ていいか
- マネージャーはメンバーの公正性を評価
- 最も電話をとっているのは誰か？
- AM 3時に対応しているのは誰か？
Technical Preparetions (技術的な準備)
チームにオンコールを導入するための準備について説明します。
全てのメンバーは自宅で使用できる会社支給の機器を持っている必要があります。ラップトップ、モニター、充電器、コネクタ、携帯電話などが含まれます。
家庭からインターネットへのアクセスは適切な速度と信頼性が必要です。
チームに機器が支給されたらナレッジベース、クラウドプラットフォーム、その他必要なリソースへのアクセス権を与えます。
VPN やゲートウェイを経由することもあります。オンコールローテーションに割り当てられる前に全てのアクセスを確認しておきます。
メール、SMS、電話、チャットなど、どの通知ルートが最も効果的であるかチームと相談して決めます。
Setting Team Torms (チーム規範の設定)
責任
オンコール対応者の責任はアラートを受信するだけではありません。目的の1つは平均応答時間 (MTTA) と平均解決時間 (MTTR) を短縮することです。
オンコール対応者はインシデントをトリアージする責任を負います。これは自分たちで直せるのか？追加の対応者に連絡するか？別チームを呼び出すか？重大なインシデントにエスカレーションするか？ などです。
PagerDuty には、「エスカレーションすることを決してためらわないでください!」という格言があります。(素晴らしい!!!) インシデントが時間に左右されないならチケットを作成して別チームに割り当てます。
ただし、重大なインシデントの場合、エスカレーションをためらうと損害を広げる可能性があります。
さらにオンコール対応者は既存のプロセスを改善する責任もあります。
アラートに意味がある十分なコンテキストは含まれていましたか？ 対応に使うドキュメントは最新でしたか？ 次に対処する人が苦労しないためにすることは何でしょうか？
責任ではない
プラットフォームで発生する全ての問題がオンコール対応者の責任ではありません。オンコール経験の少ない従業員は犠牲を払ってでも問題を解決する義務があると感じがちです。
アラートを受信できない状態にあったりアラートを見逃すこともあります。オンコール対応者の燃え尽き症候群を避け士気を維持するために考慮すべき点があります。
- オンコール対応者が全てのアラートに毎回初回応答することを期待しない
- オンコールシフト中は通常タスクの負荷を減らす
- インシデントに付加価値を見いだせない場合は、次の担当者へスタータスを変更してもいいことをオンコール対応者が思い出す
- オンコール対応者がすでにインシデントに対応しているならば、追加のインシデントは他のメンバーが担当する
- オンコール対応者が燃え尽きてしまった場合は、他の誰かがシフトを引き継ぐ、その人が食事や睡眠をとれるようにする
引き継ぎ
オンコールシフト終了時にはチームミーティング形式の引き継ぎを行います。オンコール対応者がシフト中のインシデントを要約します。メール、共有ドキュメント、インシデント管理ツールに保存された内容の引用でも構いません。
目的は、次の対応者が全ての情報とコンテキストを持っていることを確認することです。
依存関係を含む最近のデプロイメント、修復作業、ToDo アクションアイテムなどです。
オンコールと生活
オンコールチームの全てのメンバーが人間だということを忘れてはいけません。人間らしい生活を維持するために考慮することはあります。
- 休暇
- 緊急事態
- 計画外のことが起こった際にオンコールスケジュールを上書きする
- オンコールスケジュールを一貫して保つ
- ローテーション期間
- シフト時間
- ローテーション切り替え、シフトチェンジのタイミング
Building an On-Call Culture (オンコール文化の構築)
オンコールを新しくチームに導入するには、メンバーとマネージャーがチームのダイナミクス、信頼、コミュニケーションについて考える必要があります。
これまでオンコールの責任を負っていなかったチームに責任を負うことを伝えるのは難しいことです。オンコールにネガティブな印象を持っている人はいます。
成功するオンコールチームの重要な要素は共感です。報復を恐れることなくインシデントを解決するための権限が与えられているとメンバーに共感してもらいます。
階層構造から意思決定に至るまで高いレベルの心理的安全性を備えたチームは、意思決定の麻痺に費やす時間が減り、解決のための時間が増えます。
成功するオンコールチームは新しいメンバーの研修に時間を費やします。
シャドウオンコールローテーションは新しいメンバーが専門家の責任を負うことなくインシデントの通報を聞くチャンスです。
インシデント対応を行っているチームの多くは MTTA、MTTR、CIRT (クリティカルインシデント応答時間) などの指標を追跡してチームのパフォーマンスを測定しています。
バグやエラーでインシデントが発生した場合、それを永続的に修正することでシステム全体の信頼性が向上します。
チーム間のコミュニケーションのためにできるだけ多くの共通ツールを使うことが大切です。
例えば、ネットワークチームからデータベースチームにインシデントを引き継ぐ場面を想像します。コンテキストやこれまでの作業の確認を行うために共通ツールの利用が必須です。
Recommendations for Managers (マネージャーへの推奨事項)
人道的なオンコール
多くのアラート、低コンテキスト、作業できないアラートなどの悪い状況を避けます。
チームの健康と幸福の維持はマネージャーの優先度の上位にあるはずです。
そのためのいくつかの基本ルールを設けるとよいでしょう。
- スケジュール変更は余裕を持って行います
- 通勤や移動などで不在になる場合はバックアップメンバーにお知らせます
- 大きな問題や夜間対応が連続し担当者がストレスを感じている場合はプライマリから外します
- 深夜作業の翌日は勤務時間を遅らせる処置をとります
チーム参加
オンコール業務を公平に感じさせるために、メンバー全員が平等にオンコール業務に参加していることを確認することが重要です。
シフト交換やスケジュール変更に注意を払い、誰かが不釣り合いな量のオンコールを担当しないようにします。
メンバーを失うこともあります。メンバーの離脱は完全に防ぐことはできません。しかし、疑念を和らげることに注力します。
アクションアイテムをフォローアップし、繰り返される修正に優先順位を付け、他チームへの要求を支持します。
Implementation Suggestions (実装に関する提案)
オンコール実装に慣れていない人のためにいくつかのガイドを紹介します。
アラート疲労を管理しましょう。アラートは本番環境のものですか？ 介入が必要ですか？ 緊急ですか？
全てのアラートがアクション可能であり、対応するドキュメントが存在する必要があります。外部依存ががあるアラートはそのエスカレーション先と共有します。
どのサービスにどのレベルの応答が必要か定義し、必要のないサービスに優先度を割り当て過ぎないように注意します。
すでに 24365 の NOC に依存している場合、NOC をレベル１、自分たちのチームをレベル2 として体制を作ります。
異なるタイムゾーンにメンバーがいるなら、ほとんどを日中のシフトにし、睡眠時間中の勤務を制限します。
週末や夜間に対応する必要がないインシデントはアラート通知しないようにします。翌朝の対応を習慣付けます。
MTTA と MTTR はチームが協力して基準を満たすために使用すると効果的です。
Nest Step (次のステップ)
PagerDuty でのプロファイルの設定から、インシデント対応から事後分析に至るまでのトピックに関する高度なリソースの検索方法までを紹介します。
個人的まとめ
PagerDuty のベストプラクティスからオンコール管理を学びました。
10年以上前ですが、私はかなりつらいオンコールスケジュールを経験しました。
ここに書かれていることの真逆と言っても過言ではない環境でした。
当時はまだ体系だった知識が世に広まっているわけではなく、体力と権力でオンコールさせられていた印象です。
DevOps や SRE モデルに浸透によって新しくオンコールメンバーに配置される方がいる一方で、組織としてメンバーをケアする手法も理解が進んでいると感じています。
個人の体力に頼らないオンコール体制の構築はモダンな運用に欠かせない要素だと改めて感じました。
宣伝
私が運営に参加している Ops JAWS では 2023-09-04 19:00 〜 からインシデント管理をテーマにしたイベントを開催します。
Youtube Live とオフラインのハイブリッド開催となっています。お気軽に参加ください。
Discussion