オンコールを改善するためのマネージャー向けガイド

チームに透明性をもたらす

コミュニケーションを成功させるには、透明性が鍵となります。オンコール システムを展開したり既存のオンコール システムを変更したりする場合は、可用性に関する期待を明確にする必要があります。次のような従業員からの一般的な質問を検討して、明確に回答するようにします。

• エンジニアは夜間にオンコール業務を行うのですか?
• 夜間にオンコール業務を行う場合、翌日に在宅勤務できる柔軟性はありますか? オンコール対応従業員が睡眠を必要とする場合、翌日は勤務開始時間を遅らせられますか?
• 開発者は、オンコール業務中に開発作業を行う義務がありますか?
• 開発者は月に何回オンコール業務を行いますか? 1 人がオンコール業務を行う最大回数はどれくらいですか?
• オンコール対応従業員に対する報酬はどのようになりますか?

適切なトレーニングを提供する

オンコール チームのトレーニングに関するベスト プラクティスは次のとおりです。

• プロセスと一般的な課題の両方に対応するトレーニング プログラムを開発します。
• 最新のランブックを提供します。
• 新入社員に経験豊富なオンコール エンジニアのシャドーイングをさせます。
• 従業員が過去のインシデント レポートにアクセスして、現在対応中のインシデントと類似する過去のインシデントをどのように解決したかを確認できるようにします。

また、複数のエスカレーション チャネルを設定することもお勧めします。一般的なベスト プラクティスは、経験の浅いエンジニアを主要なオンコール ローテーションに加えて、上級エンジニアをバックアップまたは二次ローテーションとしてスケジュールする方法です。このことは、経験の浅いエンジニアが必要なオンコール スキルを習得すると同時に、専門知識を超えた課題が発生した際にパニックに陥らないようにするために役立ちます。

オンコール業務と開発業務を分離する

オンコール業務中に開発業務を行うと、通常、コンテキストの切り替えや中断が多数発生します。インシデントやオンコール要件が頻繁に発生する企業の場合は、特にそうです。

つまり、一般的には開発効率が低下してオンコール エンジニアのストレスが増加し、燃え尽き症候群、アラートによる疲弊、仕事への不満につながる可能性があります。また、オンコール対応従業員が特定のスプリントにどの程度貢献できるかを推定することは困難であるため、開発スプリントに悪影響が及ぶ可能性もあります。

そのため、ベスト プラクティスとして、オンコール業務と開発業務を分けることをお勧めします。オンコール対応従業員に空き時間があればオンコール関連のドキュメントや自動化の改善に取り組めるため、結果的にシステムやサービスの持続可能性が向上します。

オンコール プロセスを微調整する

健全なオンコール システムは、プロセスとシステムの微調整によってオンコール システムが絶えず改善されている場合にのみその健全性を維持できます。Jira Service Management などのインシデント管理ソリューションを利用して、オンコール スケジュール、ルーティング ルール、エスカレーション ポリシーをカスタマイズして、アラートを効率的に処理できます。この目標に向けて、次のことをお勧めします。

• アラートの優先度と緊急性を評価して、それに基づいてシステムを設定します。緊急性の低いアラートは朝まで待てるため、オンコール対応従業員が本当に必要な睡眠を取れるようになります。
• 根本原因、発生元のシステム、メッセージ、しきい値などの要因に基づいてアラートを分類することによって、誤検知を削減します。これによって、実用的なアラートを残りのアラートと区別しやすくなります。
• 関連アラートの重複を除外して、アラートによる疲弊を回避します。
• 課題を明確に記述して、オンコール エンジニアが効果的に意思決定して、ランブックに記録された知識を適用できるようにする充実したアラートを設計します。
• オンコール チームにアラート レポートと指標を提供して、システム内の脆弱な領域を特定して改善できるようにします (つまり、オンコール チームが何度も同じ課題によって忙殺されることがないようにします)。

オンコール レポートを確認して、必要に応じて調整する

公平性を保って従業員の燃え尽き症候群を回避するために、マネージャーはオンコール関連のレポートを見直して次の項目を確認する必要があります。

• 各チーム メンバーが呼び出される、または起こされる頻度
• 各チーム メンバーのオンコール勤務時間
• 各チーム メンバーのオンコール業務の時間配分および日数配分
• 必要に応じて業務を公平に配分するためのスケジュール調整

従業員の声を聞く

経営陣は、オンコール エンジニアと全員参加のミーティングを定期的に行って、問題、苦情、弱点がある箇所について話し合い、課題を解決するために措置を講じる必要があります。

オンコール システム、ツール、プロセス、従業員、ドキュメント、トレーニングは、設定したら放置してよい静的なものではありません。企業が成長してチームが学んで変化し、インシデントが時間の経過とともに変化していくにつれて、経営陣はオンコール プログラムを絶えず再評価して改善する必要があります。

うまくいっていること、うまくいっていないことを最も的確に伝えられるのは、オンコール エンジニアです。彼らの意見に耳を傾けて、変更を実装しましょう。また、オンコールの組織とプロトコルに関しては、経営陣が唯一の意思決定者ではないことを確認するのが最も重要です。チームが独自のプロセスとプラクティスを改善できるようにサポートするほど、チームはオンコールを受け入れるようになります。