DevOpsでは、オンコールプロセスについてよく話しますが、オンコール中の人間的な側面についてはどうでしょうか？例えば、シフト中のストレスや不安に対処する効果的な方法は何でしょうか？オンコール当番中に子供の世話をしなければならないなど、オンコールに専念しづらい生活状況とどのように両立すればよいでしょうか？また、共感的なチームカルチャーは、燃え尽き症候群や離職を防ぐのにどのように役立つのでしょうか？
2021年11月から12月にかけて、PagerDutyの９つのチームのオンコールエンジニアが集まり、オンコールの人間的側面についてディスカッションしました。ここでは、そのセッションで得られた５つの重要なポイントを紹介します。
- チーム内の共感が重要である
- 一日中グラフを眺めていてはいけない
- ポストモーテムはストレスになり、多くの労力を要する
- 緊急性の低いアラートは、夜間のノイズを減らす
- １週間のオンコールは燃え尽き症候群につながる可能性がある
それぞれの重要なポイントに入る前に、私たちが話を聞いたチームに関連するいくつかの指標を見てみましょう。
数字で見る
ここでは、「オンコールの人間的側面」セッションに参加したチームの主なデータを紹介します。
- オンコールのローテーション規模は？ オンコールの平均ローテーション人数は５人。
- セカンダリーのオンコールは？ 60％のチームが「ある」と回答。
- オンコールの頻度は？ オンコールの頻度は、平均して3.5週間に１回。
- オンコールのシフト期間は？ 平均的なシフト期間は１週間で、平日と週末でシフトを分けるチームも。
- 週に対応するオンコールの時間（中央値）は？ １週間のオンコール対応時間の中央値は４時間。９チームのうち２チームは、オンコールエンジニアが業務時間のほとんどをオンコール対応に費やす。
このヒストグラムに、オンコールに費やした時間をプロットしてみました。ご覧の通り、調査対象チームの55％が週０～５時間のオンコールに費やし、22％が５～10時間のオンコール、11％が30～35時間のオンコール、そして11％が40時間のオンコールに費やしていることがわかります。
ヒストグラム チーム別オンコール対応時間
さて、ここまででフォーカスグループの詳細をお伝えしましたが、それぞれの教訓についてさらに詳しく見ていきましょう。
教訓１：チーム内の共感が重要である
チームカルチャーは全てであり、安全な空間を創り出すための土台となります。オンコール中にオーバーライドをお願いしてもよいという規範を（言葉と行動で）強化することは、チームのオンコール体験の方針を打ち出す上で重要な部分です。カルチャーの変化は一夜にして起こるものではなく、時間をかけて発展させ、形成することができます。このカルチャー的な変化が起こっている間、チームにとって最も意味のある方法で、チームカルチャーの一部として積極的に奨励することが重要です。例えば、オーバーライドを要求した後、チームの振り返りの際に同僚に感謝し、積極的に強化することができます。また、チームの規範を文書化している場合は、そこに「オーバーライドを依頼してもよい」と書き加えることも提案できます。さらに、同僚やマネージャーとして、特に重大なインシデントの後に、オンコールエンジニアがどのように行動しているかを確認することが重要です。特に、その人にとって初めての大きなインシデントであればなおさらです。
最も重要なことは、オンコールエンジニアそれぞれの生活状況に、チームやマネージャーが共感することです。例えば、ペットや子供、高齢の両親がいる場合、オンコールへの専念が難しくなることがあります。また、愛する人の死など、ストレスの多いライフイベントに巻き込まれると、オンコールで感じるストレスがさらに大きくなる可能性があります。このような状況では、特につらい時期にあるエンジニアをオンコールから外す可能性について積極的に提案することが重要です。
教訓２：一日中グラフを眺めていてはいけない
オンコールだからといって一日中全てを監視することが仕事ではない、と覚えておきましょう。何か問題が起きたらあなたに電話がかかってくる、というシステムに対する信頼が必要なのです。自分でどうにもできないことは手放し、コントロールできることに感覚を研ぎ澄ませる必要があります。ローテーション間の引き継ぎはチームの作戦検討会議に任せ、シフトに備えます。また、緊急性の低いインシデントにはプッシュ通知が不要です。余計なことを気にしてストレスレベルを上げることはありません。
オンコールローテーション中に時間が許せば、次のオンコールエンジニアのためにオンコールの状況を改善することに力を注ぎましょう。例えば、ディスクが満杯になる、ログをローテーションする必要がある、アラートがうるさいなど、特定の問題が発生し続けている場合、それを長期的視点から解決するためのタスクに取り組みましょう。
教訓３：ポストモーテムはストレスになり、多くの労力を要する
複数のチームが連携して対応する必要がある大規模インシデントは非常にストレスが溜まりやすく、ポストモーテムの作業負荷が追加されればさらにストレスが溜まります。インシデントそのものを処理することと、その後にさらに１週間のストレスを抱えることは、まったく別のことなのです。もしリソースが許すなら、インシデントの第一レスポンダー以外の者がポストモーテムを行うという作業合意を作ることが有効です。さらに、インシデントが解決した後、そのストレスの大きさを認識し、ストレス解消のための時間を確保することも有効です。オンコールエンジニアに「クールダウン」期間を与え、仕事のスケジュールや生活の他の部分を取り戻すための柔軟性を持たせるイメージです。
教訓４：緊急度の低いアラートは、夜間のノイズを減らす
緊急対応が不要なら、オンコールエンジニアが就寝中に呼び出されないよう、低緊急としてアラートを設定することができます。これを効果的に行うには、緊急性の低いアラートの設定とオンコールエンジニアのオンボーディングを組み合わせて、緊急性の低いアラートに邪魔されないようなアラート設定を行う必要があります。オンコールエンジニアのオンボーディングでは、ユーザー通知設定の方法を説明し、新入社員の設定が正しいかどうかを確認することが効果的です。PagerDutyのローテーションに入る前のチェックポイントとなります。
教訓５：１週間のオンコールは燃え尽き症候群になる可能性がある
１週間まるまるオンコールになると、精神的にこたえることがあります。完全に仕事から解放されないからです。シフト中に呼び出しがなかったとしても、呼び出しを今か今かと待ち構えていることに変わりはありません。オンコールのローテーションに最適な長さは見つけづらいです。以下のような、いくつかの要因に左右されるためです。
- チーム内のオンコールエンジニアの好み。これは、オンコールスケジューリングに関する考えを収集するために、チームでアンケートを取って測定することができます。
- オンコールエンジニアのシフト終了後の気分。これは、オンコール終了時の「Yelpレビュー評価」（１（最悪）～５（最高））を使って長期的に追跡することができます。
- チームのサービスの騒がしさ。アラートが頻発するとストレスが溜まるので、オンコールのローテーションを短くすることが望ましいです。 １週間のオンコールではなく、平日と週末のローテーション、営業時間と営業時間外のローテーション、毎週を短く区切って２日、２日、３日のシフトとする、などの選択肢を検討することも可能です。
オンコールチームのベストプラクティス
オンコールはストレスになる可能性がありますが、共感的なチームカルチャーとチームの好みに合ったオンコールの設定があれば、燃え尽き症候群を減らすのに大きな効果を発揮します。オンコールのベストプラクティスと、共感的なチームカルチャーを醸成する方法についてもっと知りたいですか？オンコールチームのベストプラクティスガイドをご覧ください。
クレジット
- Amy Wood, Ashwin Jiwane, Charlotte Sarfati, Chelsea Vandermeer, Hunter Watson, Japa Swadia, Katherine ChengLi, KP Singh, Liam Stewart, Marcos Wright-Kuhns, Mandi Walls, Possum Nuada, Quintessence Anx, Roma Shah, Russ Smith, Todd Whitney, Tom Graft そして Vivian Chan、これらの議論とブログ記事に協力くださった皆さんに心から感謝いたします。
この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
カテゴリー ：インシデント＆アラート
