オンコール管理に対するさまざまなアプローチの長所と短所

オンコールとは?

オンコールとは、従業員が正式に勤務時間中ではないとしても、緊急のサービス課題が発生した場合に、特定の従業員が特定の時間に対応できるように指定する仕組みです。

オンコールは、多くの IT、開発者、サポート、運用の各チーム内で重要な責任を負い、顧客から年中無休の可用性を期待されるサービスを提供しています。チーム メンバーはオンコール ローテーションによって交代で担当して、24 時間体制または通常の営業時間外のみでサポートを行います。オンコール エンジニアには自動監視ソリューションとアラート ソリューションに加えて、サービスの可用性の中断に即座に対応する権限が付与されます。

IT およびソフトウェア チームでの高まるオンコールの重要性

オンコール勤務は、不当な非難を受けることがあります。一部のベテランの IT 技術者は、働きすぎて疲弊したチームが必要なサポートを得られなかったためにインシデントに適切に対応できなかったというつらい経験をしています。

オンコールでのサポートが適切に行われれば、そのような不安の多くを軽減できます。効果的なオンコール計画が立てられていると、拡大するサービスに合わせてチームを拡張し、重要な IT 機能に対して一貫したサポートを提供し、迅速なインシデント対応を実現できます。

優れたオンコール管理計画には、単にダウンタイムを切り抜けることに留まらない多くのメリットがあります。障害が発生するたびに、チームは新しいスキルを習得する機会を得られます。たとえば、重要なサービスをより深く理解する、障害に対する対応方法を確認する、障害を減らすための設計方法やインシデント対応計画を改善する方法を把握するなどの機会です。

また、共同責任の文化において構築した優れたオンコール プログラムがあれば、仲間意識が高まって燃え尽き症候群が減り、その結果、従業員の定着率が向上します。

オンコール勤務の長所と短所

DevOps を実践する組織では、ソフトウェア チームが構築するサービスの信頼性と可用性について多くの責任を負っています。これはかつて、運用チームの独占領域でした。これら多くのチームにとって、「構築した者が運用する」は新しいモットーです。コードに最も精通している開発者は多くの場合は、課題を最短時間で最適な方法でトラブルシューティングできます。

また、開発者はこのプロセスを通じて、実際に障害が起こりにくいより優れたソフトウェアを構築します。このように責任が移行したことで、開発者はより厳格にコードをテストしています。実際に、サービスに課題がある場合に営業時間外に呼び出されるのは開発者自身であるためです。

その結果、システムの回復性が高まり、インシデントに対応できる人員が増え、燃え尽きる従業員が少なくなります。

優れたオンコール プログラムがなければ、組織は DevOps の文化的メリットのすべてを実現できなくなります。または、インフラストラクチャを拡張する要求を満たせなくなります。1 つのチームのインシデントに対応する負担が他のチームよりも多くなると、日常業務をしっかりはこなせなくなります。開発者はインシデントから得られるフィードバックを実装できなくなり、インシデント対応者はシステムを強化する余力がなくなります。

責任が片寄っている場合、オンコール スケジュールに対応する予定の従業員は実際に仕事から離れられなくなって、容易に燃え尽き症候群になり得ます。

しかし、組織の真の業務担当要件を考慮し、開発者チームと IT 運用チーム全体にわたる時間負担のバランスを取り、継続的な改善のためにデータを捕捉できる計画があれば、あらゆる面でメリットがもたらされます。その結果、顧客により良いサービスを提供できるようになるだけでなく、従業員がスキルと製品を向上させられます。また、実際にオンコール勤務を楽しみにするようになるでしょう。

オンコール開発者の役割を向上させる方法

「一晩中このデプロイを監視して潜在的なサービス停止に対応するのが待ち遠しい」などと言ったエンジニアは、いまだかつていません。

構築するサービスを維持する役割を担う開発者が増えるのに伴い、開発者がオンコールの責任を負う準備が整っているのを確認することが重要です。また、これを査定する最適なタイミングは採用プロセス時です。

現在、優秀なエンジニアリングの人材を求めて激しい競争が繰り広げられていることは公然の事実です。誰もが収入の多寡のみによって動機付けられているわけではないため、就業時間外の開発業務に対してより多額の賃金を支払っても、取引は成立しない可能性があります (オンコール報酬について詳しくは後述します)。面接を受けるソフトウェア エンジニアは当然、私生活の時間を削ってオンコール スケジュールに対応する必要がある頻度について質問するでしょう。

有能な開発者と SRE のチーム全体で責任を公平に分散する文書化されたオンコール計画があることを実証すれば、組織がオンコール管理を掌握していると新入社員を安心させる上で非常に役立ちます。文書化された計画があれば、面接時に完全な透明性を示せるため、応募者がオンコール作業に取り組む準備を整えていることを確認できます。

オンコールを開発者にとって親しみやすいものにする 5 つの簡単な方法

1. オンコールの責任を明確に定義する
   オンコール中の責任を明確に定義する必要があります。このことは、燃え尽き症候群、混乱、フラストレーションの回避に役立ちます。オンコール対応の意味について、インシデント対応プロセスと期待事項を文書化することをお勧めします。
2. アラートが適切な担当者に割り当てられていることを確認する
   アラート ツールの通知が効果的に届くことを確実にします。適切な通知と無効化を活用して明確なアラート フローを確保することで、多くの問題を回避できます。
3. 第 1 対応者と第 2 対応者を確保する
   誰かがオンコールに対応しているからといって、人生が止まるわけではありません。予期せぬ個人的な緊急事態によって勤務中の開発者が職場を離れる場合があるのと同様に、オンコール勤務時にも同じことが起こり得ます。サポート要員を確保すると、このような中断による潜在的なダメージが抑制されます。
4. スケジュールを微調整する
   チームは静的なものではなく、それはオンコール スケジュールも同じです。オンコール プラクティスを継続的に見直し、調整、改善する文化を醸成することをお勧めします。
5. 関連するすべての診断ツールにアクセスできて精通していることを確実化する
   運用の健全性、アプリケーションのパフォーマンス、リソースの使用率などを追跡するために使用するツールは、チームごとに異なります。オンコール エンジニアが使用するツールに精通して、そのツールに対する適切なアクセス権があることを確実にしてください。

IT サポートおよびサービスの役割のためにオンコールを改善する方法

オンコール対応により多くの時間を費やしているのは、開発者だけではありません。IT サポート チームや IT サービス チームにとっても、ビジネスの機能をサポートするために 24 時間体制のサポートがますます不可欠になっています。

これらのチームは、ストレス、燃え尽き症候群、不明確な役割と責任、ツールへのアクセスなど、オンコールの開発者と同じ多くの課題に直面しています。

IT チームは多くの場合、顧客と同じ建物内にいるというストレスが加わります。インシデントに関する顧客からの中断 (メール、Slack、対面でも) によって、作業が遅れることがあります。

IT インシデントを管理しやすくする上で役立つ戦術を次に示します。

• 迅速かつ透明性のあるコミュニケーション: IT インシデントを積極的に伝えることで、あなたがインシデントに注意を払っており、しっかり管理していることを示します。
• 重要な内容を把握する: ほとんどの IT サービス チームは、何らかの形式のサービス デスク ソフトウェアを使用しています。各チケットの詳細を把握するために、自由形式のデータ入力フィールドだけを使用しないことが重要です。
• 監視システムを設置する: 従来、多くの IT 運用チームはパフォーマンス ダッシュボードを個人的に監視して、システム停止を見張っていました。チームのために、この処理を監視ツールやアラート ツールに任せましょう。

オンコール報酬

優れたオンコール報酬計画では、従業員の専門知識や就業時間後に勤務した時間に対して報酬を支払います。従業員が適切に配慮されていると感じれば、ビジネスに関心を持って事業の成功に貢献してくれるようになります。

雇用主と従業員の最低賃金、残業時間、最低年齢の要件を定める連邦法である米国の FLSA (公正労働基準法) によると、従業員がオンコール対応しているが自分の思うように自由に時間を使える場合、これらの従業員は「仕事を待機している」とみなされるため、働いていることにはなりません。

FSLA によると、自由時間が制限されて就業時間外に自由に行動できない場合、このオンコール時間は「勤務時間」とみなされて、報酬の対象になる可能性があります。

現地の法律は異なる場合があるため、必ず専門家に相談してください。その後、競争力があり公平なオンコール報酬計画を目指して、共同責任の文化をサポートしましょう。

1. インセンティブ オンコール

インセンティブ オンコールの報酬計画では、自発的にオンコール時間に勤務することを選択した従業員に対して、休暇日数の追加、柔軟な勤務時間、基本給与の増額、またはこれらの組み合わせによって報酬を提供します。

オンコール報酬に対するこのアプローチには、サービスに対する当事者意識が高まるというメリットがあり、システムの回復力が強化されることにつながります。

十分な休暇を提供して競争力のある給与を支払うことで、従業員は自分の仕事が高く評価されていることを認識できて、燃え尽き症候群や離職率を減らせます。

2. 予定された残業に対する支払い対象のオンコール

支払い対象のオンコール報酬とは、シフト中に課題が発生しない場合でも、従業員がオンコール勤務に費やした時間や予定されている勤務時間に対して直接報酬が支払われるということです。

このオンコール報酬モデルの明白なメリットは、具体的なインセンティブにあります。ポケベル (またはノート パソコンや携帯電話など) を携帯することで支払いを受けられるとわかれば、問題が発生しない場合でもオンコール時および対応可能な状態でいる義務を妥当であると容易に判断できるようになります。

3. 費やした時間に対する支払い対象のオンコール

オンコール報酬に対するもう 1 つのアプローチは、従業員がインシデントに対応したときにのみ支払う方法です。この計算には次のような方法があります。

• オンコール勤務に対して支払われた合計金額
• アラート/課題への対応に費やした時間に対する時間給
• 対応したアラートと課題の件数の割合

このモデルのメリットは、従業員が通常の営業時間外に働いた追加作業に対して支払いが行われることです。潜在的な欠点は、アラートや課題が減少すると経済的に不利になるため、システムの全体的な整合性を損なう可能性があることです。

4. 予定された残業時間および課題に費やした時間に対する支払い対象のオンコール

これは、前述の 2 つのモデルを組み合わせたものです。一部の企業では、オンコール スケジュールでの勤務と、受信したアラートと対応した課題の追加件数の両方に対して支払いを行っています。このオンコール報酬モデルの利点は、従業員が組織から求められた追加の時間と労力に対して十分な報酬を受けていると感じることです。さらに、従業員が困難な課題で行き詰まり、自分のプライベートの時間を失った場合、その犠牲に対して金銭的に報酬が支払われます。しかし、ソフトウェアにバグがあったことに対して間接的な報酬を支払うことが、会社の文化の観点から合理的であるかどうかをもう一度検討してください。

その他の考慮事項

オンコール報酬計画の典型的なモデルをここまで示してきました。これ以外にも、必要に応じて考慮すべきことがいくつかあります。

• 営業時間内外に受信したアラート件数

この件数は、営業時間後にオンコール スケジュールで対応する時間、または営業時間内の特別なオンコール チームが必要かどうかを判断する上で重要となります。

• インシデントの対応に費やした時間

組織のインシデントの複雑さと重要性はさまざまです。1 人のオンコール エンジニアが、1 つの課題を数分間で処理する場合も、インシデントの対応に一晩中かかる場合もあります。通常のオンコール シフト中に費やす時間と労力を考慮する必要があります。報酬を公平なものにするために、これを測定する必要があります。

• 平均確認時間または平均解決時間

エスカレーション ポリシーによって規定されているとおり、課題を迅速に解決するには平均確認時間が重要です。一定期間にわたる平均確認時間と平均解決時間を測定すると、マネージャーが追加のインセンティブを決定するのに役立ちます。