6.3 オンコール、容量、運用負荷の指標

概要と動機

トピック6.1が導入した信頼性とトピック6.2が測定したインシデント対応は、どちらも本トピックが直接測定する人的システムに依存しています。ポケベルを持ち何かが壊れたときに対応するエンジニアであるオンコールのローテーションと、そもそもシステムが壊れ始める前にどれだけの負荷を吸収できるかを決定するインフラの容量です。組織は優れたSLO、よく設計されたエラーバジェット、そして本物に非難のないインシデント文化を持ちながら、それでも持続不可能な負荷を通じてオンコールのエンジニアを燃え尽きさせ、最終的にはそれらの他の実践が保護するために構築された信頼性そのものを劣化させることがあります。

本トピックは、運用負荷をそれ自体の指標ファミリーとして扱います。トピック3.2の幸福感と燃え尽きの測定に直接つながりますが、ポケベルを持つことの特定の急性ストレスに特有です。中断された睡眠、何も起きなくてもオンコールであることの心理的コスト、そして頻繁で不十分に分配されたインシデント負荷の累積的な代償です。それらのシステムを信頼できるものに保つ人々の持続可能性を一度も測定することなく、そのシステムの信頼性を綿密に測定する組織は、全体像の半分しか測定しておらず、測定されない半分は最終的に離職、消耗した対応者からの劣化したインシデント対応の品質、あるいはその両方として表面化する傾向があります。

大規模なチームにとって、オンコールと容量の指標は、トピック3.5の知識集中の懸念を反映する負荷分散の問題を明らかにします。少数のエンジニア、しばしば最も経験豊富な人々がインシデントを最も速く解決できるというまさにその理由で、不均衡な割合のページを吸収しています。これは燃え尽きのリスクとバス係数のリスクの両方を同時に生み出します。24時間稼働の重要なサービスを運用する企業と政府の組織は、離職を通じてのみ本物のコストを発見するのではなく、オンコールのローテーションを持続可能に配置するために本トピックの指標に依存しています。

重要な原則

オンコールの負荷は測定可能で管理可能なリソースであり、エンジニアが単に吸収しなければならない避けられない無制限の負担ではありません。
ページの頻度とページの分配はどちらも重要である。 チーム全体の平均は、少数の個人への深刻な集中を隠すことがあります。
オンコール中の中断は、実際にインシデントが起きなくてもコストを伴う。 連絡可能で責任を負っていることの心理的な重みです。
容量計画とオンコールの負荷はつながっている。 プロビジョニング不足のインフラはより多くのページを生み出し、オンコールの負担を直接増やします。
持続可能なオンコールのシステムは信頼性そのものを保護する。 消耗した対応者はインシデント中により遅くより誤りやすい決定を下すからです。

推奨事項

チームレベルの平均だけでなくページの頻度と分配を追跡する

チーム全体の平均ではなく、各個々のオンコールのエンジニアが受け取るページの数を測定してください。平均は深刻な集中を隠すことがあります。トピック3.5のバス係数とトピック2.9のレビュー負荷の懸念と同様に、オンコールの負荷はしばしばインシデントを最も速く解決できる少数の経験豊富な人々に集中します。これはまさに、燃え尽きのリスクと危険な単一障害点の両方を生み出すパターンです。この集中が現れたら、意図的にローテーションを再バランスしてください。

アクティブなインシデントの時間だけでなく、オンコールであることの心理的コストを測定する

オンコールであることは、実際のページがゼロのシフトでも本物のコストを伴います。可能性のある中断を予期することによる睡眠の質の低下、制約された個人的な活動、そして継続的な責任の低度のストレスです。可能な場合、一般的な満足度とは別に、特にオンコールの体験について調査データ(トピック3.7)を通じてこれを捕捉してください。チームは一般的な満足度を妥当だと報告しながら、オンコールが特にひそかに幸福感を蝕んでいることがあるからです。

持続可能なオンコールの頻度に明示的な制限を設定する

個人がどれだけ頻繁にオンコールであるべきかについて最大限の合理的な頻度を確立してください。一般的には4週間あるいは5週間に1週間以内です。そしてその制限に対して実際のローテーションの頻度を追跡してください。技術的には十分な人数がリストされているが、スキルのギャップや可用性の制約により実質的に2人か3人に依存しているローテーションは、名目上のスケジュールが何を示していても、実際にはその制限を満たしていません。

容量計画をオンコールの負荷に直接結びつける

プロビジョニング不足のインフラ、トラフィックの急増に対する不十分な余裕、不適切な自動スケーリングの設定は、定義上より多くのページを生み出し、オンコールの負担を直接増やします。インフラの容量利用率を追跡し、それをページの頻度と相関させてください。定期的に容量の上限近くで動作し、不均衡な割合のページを生み出すサービスは、単なる漠然とした運用上の苦情ではなく、容量への投資のための直接的な定量化可能な論拠です。

オンコールの指標を個人の評価ではなく人員配置と採用の決定に情報を与えるために使う

追加の人員、誤検知のページを減らすためのより良いツール、あるいは本物のインシデントの頻度を減らすためのアーキテクチャへの投資の論拠を作るために、チームレベルでオンコールの負荷データを集計してください。個人に直接触れるあらゆる指標についての本書の一貫した指針(トピック1.2、トピック3.4)に従い、特定のエンジニアのパフォーマンスを評価するために個人のページ対応の指標を決して使わないでください。目標は持続可能な人員配置とシステムの設計であり、個人の得点記録ではありません。

トレードオフ:長所と短所

アプローチ	長所	短所
正式なオンコール負荷の追跡なし	オーバーヘッドがない	燃え尽きのリスクとバス係数の集中が離職として表面化するまで見えないままになる
チーム平均のページ頻度のみ	計算が単純	深刻な個人への集中を隠す
個人レベルのページ分配の追跡	集中と燃え尽きのリスクを直接明らかにする	集計でのみ使い、個人評価には決して使わないよう注意が必要
発生源でページの量を減らすための容量への投資	根本原因に対処し、負担を持続可能に減らす	事前のインフラへの投資が必要

中心にある緊張関係は受容と投資です。高いページの量を単に信頼できるサービスを運用することの避けられないコストとして扱い、オンコールのエンジニアにそれを吸収するよう求めることは簡単ですが、その受容は最終的に、離職と消耗した対応者からの劣化したインシデント対応の品質を通じて組織にコストをかけます。この緊張を、無期限に単に耐えるべき避けられない負担としてではなく、本物の投資(容量の改善、誤検知を減らすより良いアラート、拡大されたローテーションの人員配置)を求めるシグナルとして高いオンコールの負荷を扱うことで解消してください。

チームで話し合うべき問い

ローテーション内の個人にわたる私たちの実際のページの分配はどうなっているでしょうか。単なるチームの平均ではなく。 実際の個人レベルのデータを取り出してください。妥当に見えるチームの平均は、一人か二人が劇的に不均衡な割合を吸収していることを隠すことがあります。
私たちは一般的な満足度とは別にオンコールであることの心理的コストを測定したことがあるでしょうか。 していないなら、オンコールの体験について特に専用の短い調査の質問が、あなたの一般的な満足度の調査(トピック3.2)が現在見逃している何かを表面化させるかどうかを話し合ってください。
私たちの名目上のオンコールのローテーションのスケジュールは現実を反映しているでしょうか、それともスキルのギャップや可用性により実質的に2人か3人だけに依存しているでしょうか。これについて正直になってください。8人の名前をリストしているが実質的に2人に依存しているスケジュールは、どんな合理的な持続可能性の制限も満たしていません。
私たちのサービスのどれが、その容量の余裕に対して不均衡な割合のページを生み出しており、追加のインフラへの投資がその負荷を直接減らすでしょうか。ページの頻度を容量の利用データと明示的に相互参照して、この事例を実際の証拠で構築してください。
オンコールの負荷データが、人員配置とアーキテクチャの決定に情報を与えるためではなく、個人のパフォーマンスを評価するために、非公式であっても使われたことがあるでしょうか。これは、トピック3.4が活動データについて警告する同じ個人評価の罠のリスクを、ここでは運用負荷に適用したものです。
私たちの最もページを受け取るオンコールのエンジニアを燃え尽きや離職で失った場合、私たちにどれだけのコストがかかり、それは今ローテーションを再バランスするか根本原因の修正に投資するコストと比べてどうでしょうか。この具体的な比較は、しばしば持続可能性だけへの抽象的な訴えよりも積極的な投資のためのより強い事例を作ります。

業種別の視点

スタートアップ。 オンコールはしばしば非公式で、必然的に創業者や小さな初期のエンジニアリングチームに集中しています。リスクは、意図的なローテーションの設計が検討されたことが一度もない早い段階で持続不可能なペースを常態化することであり、これは後で加わる新しい採用者にとってのデフォルトの期待になってしまうと、解消するのがはるかに難しくなります。

中小企業。 明確な持続可能性の制限(例えば4週間に1週間以内)を伴う単純で明示的なローテーションのスケジュールは、専用のオンコールのツールがなくても達成可能です。主な規律は、単にローテーションとその公平さを、非公式で述べられていない取り決めとして残すのではなく、見える明示的なものにすることです。

企業。 ページ分配の集中とそれに関連する燃え尽きとバス係数のリスクは、ここでうまくスケールしません。より多くのサービスとより多くの複雑さは一般的により多くの潜在的なページを意味し、専門知識の集中がその問題を悪化させるからです。個人レベルの負荷の追跡(人員配置の決定のために集計でのみ使用)、発生源でページの量を減らすための容量への投資、そして意図的なローテーションの再バランスに投資してください。

政府。 重要な公共インフラは、しばしば対応が遅れた場合に本物の結果を伴う24時間体制のオンコールのカバレッジを必要とし、これは持続可能な人員配置の重要性と、典型的な公共部門の人員の制約の下でそれを達成することの難しさの両方を高めます。オンコールの負荷データを使って、持続可能なオンコールの容量を裁量的な人員配置の好みとしてではなく直接的な定量化可能な信頼性の要件として枠組みづけて、人員配置の要求を明示的かつ直接正当化してください。

事例

企業。 あるクラウドインフラ会社は、初めて個人レベルのページデータを取り出した後、15人のオンコールのローテーションのうち2人のシニアエンジニアが、前年のすべてのページの60%以上を個人的に処理していたことを発見しました。これは彼らが複雑なインシデントの解決が最も速かったことと、他のローテーションのメンバーが自分で解決を試みるのではなく非公式に彼らに頼ることを学んでいたことの両方が理由でした。両方のエンジニアは、リーダーシップが以前にその調査のシグナルを特定の定量化可能なオンコールの集中データに結びつけていなかった状態で、会社の幸福感の調査(トピック3.2)で重大な燃え尽きの症状を報告していました。より広いローテーション全体で解決への自信を構築するための的を絞った訓練と、個人に割り当てられる連続したページの数への正式な上限を含む意図的な再バランスの取り組みは、6ヶ月以内に2人のエンジニアの割合を25%未満に減らし、報告された幸福感の対応する改善を伴いました。

政府。 ある地域の水道事業体のオンコールのエンジニアリングチームは、重要なインフラの監視のために名目上4人のローテーションで運用していましたが、容量利用データは、運用上限近くで一貫して稼働していた特定の老朽化したポンプ場が、ローテーション全体のほぼ半分のページを生み出していたことを明らかにしました。ページの頻度対容量の相関を予算要求における具体的な裏付けの証拠として直接使って資金提供されたその単一のポンプ場への容量のアップグレードは、翌年以内に組織全体のページの総量を約40%削減し、オンコールの負担が、純粋な人員配置あるいはプロセスの問題ではなく、実質的に変装した容量の問題であったことを実証しました。

ビジネスケース:動機、ROI、総所有コスト

オンコールと容量の負荷を意図的に管理することからの見返りは、回避された離職と、より遅くより誤りやすい決定を下す消耗した対応者からの回避された信頼性の劣化です。上記のクラウドインフラの例は複合的なリスクを直接示しています。管理されていない集中は燃え尽きとバス係数の露出を同時に生み出し、どちらかのシニアエンジニアを離職で失うリスクと比較して、単純でデータに基づいた再バランスの取り組みが穏やかなコストでそれを解決しました。

総所有コストには、個人レベルのページ分配を追跡するための計測(慎重に、集計でのみ使用)と、指示される場合には発生源でページの量を減らすための本物の容量への投資が含まれます。水道事業体の例は、この投資が直接かつ測定可能に元を取ることができることを示しています。単一の的を絞った容量の修正が組織全体の運用上の負担を実質的に減らしたからです。

アンチパターンと落とし穴

チームレベルの平均ページ数だけを追跡する。 燃え尽きとバス係数のリスクの両方を引き起こす深刻な個人への集中を隠します。
名目上のローテーションのスケジュールが現実を反映していると扱う。 実質的に2人か3人に依存しているスケジュールは、リストされている名前の数にかかわらず持続可能ではありません。
個人のページ対応データをパフォーマンスの評価に使う。 本書が一貫して警告する個人評価の罠を、ここでは運用負荷に適用して繰り返します。
根本原因として容量を調査するのではなく、高いページの量を信頼性の避けられないコストとして受け入れる。 頻繁に利用可能な直接の修正を見逃します。
オンコールの負荷データを幸福感の調査データに一度も結びつけない。 複合的な燃え尽きのリスクが離職として表面化する前にそれを特定し対処する機会を逃します。
実際のページがゼロのオンコールであることの心理的コストを無視する。 ローテーションの本物の負担を過小評価します。

成熟度モデル

レベル1、開始: オンコールの負荷はまったく追跡されていないか、個人の集中を隠すチーム全体の平均としてのみ追跡されています。
レベル2、発展: いくつかの個人レベルのページデータが存在しますが、それは幸福感の調査データや容量への投資の決定に結びつけられていません。
レベル3、標準化: 個人レベルのページ分配と容量利用の相関が、ローテーションの頻度への明示的な持続可能性の制限とともに一貫して追跡されています。
レベル4、管理: オンコールの負荷データは、幸福感の調査のシグナルに明示的に結びつけられ、容量への投資とローテーションの再バランスを積極的に推進するために使われています。
レベル5、最適化: 組織は、的を絞った容量への投資とローテーションの再設計からの運用負荷と幸福感の両方における具体的で測定可能な改善を指し示すことができ、持続可能なオンコールの人員配置が人員計画とインフラ計画への日常的で十分に正当化された入力です。

議論のためのアイデア

私たちの実際の個人レベルのページ分配は今どのようなものでしょうか。
私たちの名目上のローテーションのスケジュールは、実際に誰が最も多くのインシデントを解決しているかを反映しているでしょうか。
どの単一の容量への投資が私たちの現在のページの量を最も減らすでしょうか。
私たちはオンコールの負荷データを幸福感の調査のシグナルに結びつけたことがあるでしょうか。
私たちの最も重くページを受け取るエンジニアを燃え尽きで失った場合、私たちにどれだけのコストがかかるでしょうか。

主な要点

オンコールの負荷は測定可能で管理可能なリソースです。 深刻な集中を隠すことがあるチーム全体の平均だけでなく、個人レベルの分配を追跡してください。
オンコールであることは実際のページがゼロでも心理的コストを伴います。 一般的な満足度とは別にこれを測定してください。
容量計画とオンコールの負荷は直接つながっています。 プロビジョニング不足のインフラはより多くのページとより多くの負担を生み出します。
オンコールのデータを人員配置と容量の決定に使い、個人のパフォーマンス評価には決して使わないでください。
持続可能なオンコールのシステムは信頼性そのものを保護します。 消耗した対応者はより遅くより誤りやすい決定を下すからです。

参考文献とさらなる読書

Site Reliability Engineering: How Google Runs Production Systems, Betsy Beyer、Chris Jones、Jennifer Petoff、Niall Richard Murphy 編。
The Site Reliability Workbook, Betsy Beyer、Niall Richard Murphy、David K. Rensin、Kent Kawahara、Stephen Thorne 編。
The Burnout Challenge: Managing People to Avoid Burnout and Improve Wellbeing, Christina Maslach、Michael P. Leiter 著。
Seeking SRE: Conversations About Running Production Systems at Scale, David N. Blank-Edelman 編。