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

医師が健康上の緊急事態に対処するために、緊急治療室でオンコール スケジュールが必要であるのと同様に、DevOps チームがパフォーマンス、デプロイ、可用性に影響するソフトウェアやシステムの課題に効率よく対応するには、オンコール スケジュールが必要です。

しかしオンコール プラクティスを開発することは、口で言うほど容易くありません。オンコールに対応することは、従業員にとって困難で負担の大きい作業となる場合があります。チームの対象範囲、拡張性、生活の質の適切なバランスを見つけることが、継続的な課題となります。

ベスト プラクティスが変化して企業が成長するにつれて、最もアジャイルで迅速なチームは新しいアプローチを取り入れてそれを実現しています。

開発した人が維持する責任を持つ

つい 10 年ほど前までは、IT インシデントへの対応は運用チームの主な仕事でした。組織は一般的に、階層化されたチーム構造 (レベル 1、レベル 2、レベル 3 など、スキル レベルや給与レベルが高いほど上位の階層になる) を採用していました。

この構造を採用する目的は、運用コストの削減でした。通常、レベル 1 にはエントリ レベルの従業員が含まれます。レベル 1 で課題を解決できなかった場合は、より上級の (したがって、より費用のかかる) 従業員で構成されたレベル 2 にエスカレートしていました。課題が解決されるまでこのプロセスが続きます。

しかし、常時稼働サービスの増加に伴い、システム間の相互依存性とアップタイムに対する顧客の期待の両方も高まりました。最近では、シニア レベルの開発者をインシデントに早期に投入するよりも、対応の遅延の方が、評判、顧客満足度、収益の損失に関して企業のコストが増加する場合があります。

この変化し続けるテクノロジー ランドスケープの結果として、対応チームの構造を変えることが必要になります。DevOps に移行して、「開発した人が維持する責任を持つ」という概念を取り入れましょう。

ここでのアイデアはシンプルです。つまり、コードに最も精通している開発者が関連する課題を最短時間でトラブルシューティングする最適な人物であるということです。DevOps のおかげで、このロジックによって、現在では開発者がオンコールに対応してコードが正常に動作することを確実にし、インシデントの MTTA と MTTR を短縮することが一般的になっています。

このアプローチに付随するメリットとして、デプロイ前のテストがより厳密になることです。コードを担当する開発者に営業時間外に通知できるようになったため、当事者意識が高まるとともに、コードをダブル チェック、トリプル チェックするインセンティブが高まります。その結果、ますます多くの企業が、システムの信頼性と耐障害性が向上していると認識しています。

チームから敬遠されないオンコール プラクティスを構築する

オンコールが不当に非難されることには、納得のいく理由がある場合があります。バランスが取れていないオンコール プログラムは、ワークライフ バランス、健康、睡眠に悪影響を及ぼす可能性があります。オンコール勤務でひどい体験をした従業員やオンコール経験のない従業員は、社会的生活とワークライフ バランスが目前で雲散霧消する様を想像するかもしれません。

しかし、実際には、必ずしもオンコールが原因で生活の質の低下につながるわけではありません。オンコール業務のバランスを取ってチームの希望を考慮し、インシデントやオンコール アラートを可能な限り防止して削減する堅牢なシステムを構築することで、チーム全体の負担を最小限に抑えて共有するプラクティスを作成できます。

経営陣がこれを成功させるには、チームに率直に透明性をもたらし、多くのトレーニングを提供し、オンコール業務と開発業務に対する期待事項を公正に設定して堅牢なプロセスを開発します。また、チーム自体の意見と同意を活用して継続的に確認し、改善を行うようにします。

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

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

• エンジニアは夜間にオンコール業務を行うのですか?

• 夜間にオンコール業務を行う場合、翌日に在宅勤務できる柔軟性はありますか? オンコール対応従業員が睡眠を必要とする場合、翌日は勤務開始時間を遅らせられますか?

• 開発者は、オンコール業務中に開発作業を行う義務がありますか?

• 開発者は月に何回オンコール業務を行いますか? 1 人がオンコール業務を行う最大回数はどれくらいですか?

• オンコール対応従業員に対する報酬はどのようになりますか?

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

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

• プロセスと一般的な課題の両方に対応するトレーニング プログラムを開発します。

• 最新のランブックを提供します。

• 新入社員に経験豊富なオンコール エンジニアのシャドーイングをさせます。

• 従業員が過去のインシデント レポートにアクセスして、現在対応中のインシデントと類似する過去のインシデントをどのように解決したかを確認できるようにします。

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

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

オンコール中に開発業務を行うというのは、とりわけインシデントが頻繁に発生する、オンコール要件のある企業において、コンテキストの切り替えや中断が頻繁に発生することを意味します。

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

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

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

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

• アラートの優先度と緊急性を評価して、それに基づいてシステムを設定します。緊急性の低いアラートは朝まで待てるため、オンコール対応従業員が本当に必要な睡眠を取れるようになります。

• 根本原因、発生元のシステム、メッセージ、しきい値などの要因に基づいてアラートを分類することによって、誤検知を削減します。これによって、実用的なアラートを残りのアラートと区別しやすくなります。

• 関連アラートの重複を除外して、アラートによる疲弊を回避します。

• 課題を明確に記述して、オンコール エンジニアが効果的に意思決定して、ランブックに記録された知識を適用できるようにする充実したアラートを設計します。

• オンコール チームにアラート レポートと指標を提供して、システム内の脆弱な領域を特定して改善できるようにします (つまり、オンコール チームが何度も同じ課題によって忙殺されることがないようにします)。

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

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

• 各チーム メンバーが呼び出される、または起こされる頻度

• 各チーム メンバーのオンコール勤務時間

• 各チーム メンバーのオンコール業務の時間配分および日数配分

• 必要に応じて業務を公平に配分するためのスケジュール調整

従業員の声を聞く

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

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

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

親しみやすいオンコール文化の醸成

オンコール エンジニアは、企業の成功に多大な責任を負います。このため、特に原因が不明の重要な課題の対処時には、ストレスと緊張が一般的な問題であるのは当然です。

シニア オンコール エンジニアと管理チームが設定したオンコール文化によって、従業員がストレスや緊張に対処する方法やオンコール勤務についての考え方を定義します。

オンコール エンジニアの目的と企業のオンコール文化の両方のために、管理チームは親しみやすいオンコール文化を醸成するよう注意を払って、常にシステムの問題、リスク、弱点を見つけて解決することが目標であると明確にする必要があります。

Atlassian では、オンコール システムを常に改善するだけでなく、誰も責めることのない事後分析を実施しています。その事後分析では、責める相手を探し出すのではなく改善することに重点を置いています。

積極的なオンコール文化をサポートするソリューションである Jira Service Management の詳細をご覧ください。強化されたコミュニケーション機能、一元化されたアラート、柔軟な自動化、高度なレポート機能を備えたシステムを構築し、インシデント対応をレベルアップしましょう。