6.1 サービスレベルの指標、目標、エラーバジェット

概要と動機

Googleで先駆けられ『Site Reliability Engineering』の本に文書化された規律であるサイト信頼性エンジニアリング(SRE)は、本トピックが直接基づく語彙を提供しました。サービスレベル指標(SLI)は、サービスの健全性、リクエストのレイテンシ、エラー率、可用性の直接測定されたシグナルです。サービスレベル目標(SLO)は、その指標の目標範囲です。例えば、リクエストの99.9%が200ミリ秒以内に成功するなどです。そしてエラーバジェットは許容される不足分です。失敗が許されるリクエストの0.1%であり、排除すべき欠陥としてではなく、リスクを意図的に引き受けるために使うことができる使い切れるリソースとして扱われます。リスクのある変更を出荷すること、実験を実行すること、あるいは単に完璧な信頼性は達成可能ではなく、ある時点を超えるとそのコストに見合わないことを受け入れることです。

この最後の考え、ゼロに向けて最小化すべき数字としてではなく使い切れるリソースとしてのエラーバジェットは、本トピックにおける、そしておそらくこの部全体における単一の最も重要な概念です。それは多くの組織を悩ませる緊張を解消します。エンジニアリングは機能を出荷し合理的なリスクを取りたい。運用は最大限の安定性を望む。共有され定量化されたエラーバジェットなしには、これは終わりのない政治的に負荷の高い交渉になります。それがあれば、単純で客観的なルールになります。予算が残っている間は自由に使い、それが枯渇したら自動的に減速し安定性の仕事を優先します。これは哲学的な意見の相違を算術的なものに変えます。

大規模なチームにとって、SLOとエラーバジェットは、すべてのチームがそれを満たすことに静かに失敗しながら漠然とした罪悪感を感じている、到達不可能な、述べられていない絶対値ではなく、信頼性を測定可能で交渉可能にするものです。企業組織はSLOを使ってチーム間および顧客との明確な契約上の期待を設定します。重要な公共インフラを運用する政府組織はそれを使って、本物のシステムが維持できない不可能な完璧さの基準ではなく、擁護可能で公に正当化可能な信頼性の目標を設定します。

重要な原則

100%の信頼性はほとんどどんなシステムにとっても間違った目標である。 それは通常達成不可能であり、ある時点を超えてそれを追求することは、意味のあるユーザーへの利益なしに速度を積極的に犠牲にします。
SLOは、安心させるように聞こえるという理由で選ばれた恣意的な丸い数字ではなく、ユーザーが実際に気づき気にかけることを反映すべきである。
エラーバジェットは信頼性を使い切れるリソースに変え、エンジニアリングと運用の両方に、いつ速く出荷しいつ減速すべきかの共有された客観的なルールを与えます。
SLIは可能な限り、内部システムの自己報告された健全性だけからではなく、ユーザーの実際の体験から測定されなければならない。
エラーバジェットの枯渇は、それが起きるたびの場当たり的な議論ではなく、事前に決定された合意された対応を引き起こす。

推奨事項

本物のユーザー体験を反映するSLIを選ぶ

ユーザーが実際に問題を経験している間に「健全」と報告することがある単なる内部のサービスヘルスチェックではなく、実際のユーザー体験にできるだけ近い場所で測定される指標を選んでください。エッジやロードバランサーで測定されたリクエストの成功率とレイテンシです。ユーザーが実際には一度も気づかないこと(全体のリクエストが依然として失敗している間に技術的には稼働している内部コンポーネント)を測定するSLIは、どれだけ計測しやすくても間違ったものを測定しています。

恣意的な丸い数字ではなく、ユーザーが実際に必要とすることに基づいてSLOの目標を設定する

単に印象的に厳密に聞こえるという理由で「99.99%の稼働時間」のような目標を設定する反射に抵抗してください。代わりに、過去のインシデントデータ、ユーザーリサーチ、そして信頼性の各追加の増分を達成する実証されたコストに情報を与えられて、ユーザーが本物に気づき気にかける信頼性のレベルを調査してください。99.9%から99.99%に行くことは、99%から99.9%に行くことよりもしばしばはるかに多くのエンジニアリングの努力をかかり、減少し最終的には無視できるユーザーが知覚できる利益のためです。

エラーバジェットを、枯渇に対する事前に決定された対応を持つ使い切れるリソースとして扱う

SLOから直接エラーバジェットを計算してください(30日間にわたる99.9%の可用性目標は約43分の許容されたダウンタイムを許可します)。そして継続的にそれに対する支出を追跡してください。予算が枯渇したときに何が起きるかを、特定のインシデントの前に事前に合意してください。一般的で効果的なポリシーは、機能の仕事が一時停止し、チームの優先順位が予算が回復するまで自動的に信頼性の仕事に移ることです。この事前に決定されたルールは、個々のインシデントのたびにプレッシャーの下でそのトレードオフを再び争う必要性を取り除きます。

エラーバジェットを使って意図的で情報を与えられたリスクの決定を行う

健全な使われていないエラーバジェットは、蓄えておくものではありません。それは合理的なリスクを取る許可であり、高められているが許容可能なリスクを伴う変更を出荷すること、カオスエンジニアリングの実験を実行すること(姉妹書であるsoftware-engineering-guideのカオスエンジニアリングのトピックがこれを直接カバーしています)、あるいはよりリスクの高いアーキテクチャの変更を受け入れることです。なぜなら、その予算は特に手つかずのまま保存されるのではなく意図的に使われるために存在するからです。一度も使われないエラーバジェットは、過度に保守的なチームか、実際に達成された信頼性に対して緩すぎるSLOが設定されているかのどちらかを示唆し、どちらも調査する価値があります。

惰性ではなく証拠に基づいて定期的にSLOを見直し改訂する

何年も前に設定されたSLOは、もはや現在のユーザーの期待、システムのアーキテクチャ、あるいはビジネスの優先順位を反映していないかもしれません。過去に達成された信頼性、ユーザーのフィードバック、そしてその目標が、他の場所でより多くの速度を可能にするために引き締められる可能性のある容易に達成される目標であるか、あるいはチームが実質的に満たすことを諦めた非現実的な目標であるかではなく、依然として意味のあるトレードオフのポイントを表しているかどうかを確認して、定期的にSLOを見直してください。

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

アプローチ	長所	短所
正式なSLOなし(暗黙の「可能な限り信頼できる」)	設定のオーバーヘッドがない	速度と安定性の間の終わりのない根拠のない交渉。共有されたルールがない
願望的で非常に高いSLO(99.99%以上)	信頼性についての真剣さを示す	しばしば不必要なコスト。ユーザーが実際に気づくものを超えた逓減する収益
証拠に基づき、ユーザー体験に根拠づけられたSLO	本物の価値を反映する。擁護可能で達成可能	正しく設定するために実際のデータと分析が必要
事前に決定された枯渇への対応を持つエラーバジェット	場当たり的な交渉を取り除く。客観的で速い意思決定	事前に決定されたルールを実際に守るために組織的な賛同と規律が必要

中心にある緊張関係は願望と達成可能性です。高く願望的なSLOは品質についての真剣さを示すように感じられますが、ユーザーが実際に気づくものを超えて信頼性を追求することは、本物の利益なしに本物の速度を犠牲にし、チームが実際には決して満たさない非現実的な目標は、誰もがSLOをまったく真剣に受け止めなくなるよう教えます。この緊張を解消するには、願望やスコアカードで厳密に見せたいという欲求ではなく、ユーザーが何に気づくか、システムが過去に何を達成したか、各追加の増分がどれだけのコストがかかるかという実際の証拠にSLOを根拠づけてください。

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

私たちの現在のSLOは、ユーザーが実際に気づくことについての証拠に根拠づけられているでしょうか、それとも高い数字が適切に真剣に感じられるという理由で願望的に設定されたでしょうか。できるなら私たちの現在の目標の起源をたどり、それが本物のユーザーリサーチを反映しているか、それともエンジニアリングの直感だけを反映しているかを正直に評価してください。
私たちはエラーバジェットの枯渇に対する事前に決定された合意された対応を持っているでしょうか、それともそれが起きるたびにトレードオフが再び争われるでしょうか。正直な答えが後者であるなら、そのギャップは、次のインシデントがプレッシャーの下でその議論を強制する前に埋める価値があります。
私たちのエラーバジェットは実際に計算されたリスクの変更や実験に意図的に使われることがあるでしょうか、それともインシデントを通じて偶発的にのみ消費されるでしょうか。一度も意図的に使われない予算は、予算が可能にするために存在する正当な機会を逃している過度に慎重なチームを示しているかもしれません。
私たちのSLIは本物のユーザー体験から測定されているでしょうか、それともユーザーが実際に遭遇することを反映していないかもしれない内部システムの健全性からでしょうか。あなたの現在の計測をこの特定の区別に対して確認してください。それは他の点では成熟した信頼性プログラムでさえ一般的なギャップです。
私たちが最後に現在の証拠に対してSLOを見直したのはいつで、それを改訂することを正当化するような何か(ユーザーの期待、システムのアーキテクチャ、ビジネスの優先順位)が変わったでしょうか。最近の見直しを思い出せないなら、その不在自体が話し合う価値があります。
私たちの現在のSLOを信頼性のさらに一つの「9」だけ引き上げるには、エンジニアリングの努力においてどれだけのコストがかかり、そのコストは本物のユーザーへの利益によって正当化されるでしょうか。この具体的な費用便益の枠組みは、願望対達成可能性の緊張を抽象的な好みではなく実際の数字に根拠づけるのに役立ちます。

業種別の視点

スタートアップ。 正式なSLOは、チームが信頼性の問題に直接非公式に対応できる非常に早い段階ではしばしば不要です。稼働時間に依存する実際の有料顧客を持ったら、少なくとも大まかな非公式のSLOを採用してください。明示的な目標の規律は、緩く追跡されているものであっても、ほとんどの若い企業が考えるよりも早く機能のプレッシャーに対して信頼性の仕事を優先するのに役立つからです。

中小企業。 ほとんどの現代のホスティングと可観測性のプラットフォームは、最小限の設定で基本的な稼働時間とレイテンシのデータを報告します。これを使って、限られた運用能力で現実的に追跡したり行動したりできない願望的なものではなく、単純で達成可能なSLOを設定してください。

企業。 この規模でのSLOはしばしば本物の金銭的な結果を伴う契約上のサービスレベル契約の基盤であり、これは証拠に基づいた目標設定と規律あるエラーバジェットの管理を特に重要にします。便利な内部ヘルスチェックではなく本物のユーザー体験に根拠づけられたSLIに投資し、プレッシャーの下で必要になる前に、エグゼクティブの賛同を得て正式に事前に決定された枯渇対応のポリシーを確立してください。

政府。 重要なインフラの公共部門の信頼性目標は時に法的あるいは規制上の重みを持ち、監査や公の事件の間に発見された非現実的で達成されない目標は制度的な信頼性を大きく損ないます。本物で文書化されたユーザーと使命のニーズに基づいて目標を設定し、到達不可能な完璧さの基準を暗示するのではなく、エラーバジェットが表す意図的なトレードオフについて公に透明であってください。

事例

企業。 あるクラウドストレージ会社は、何年もの間、正式なSLOなしに「最大限の稼働時間」を目標としており、これは製品チーム(機能を速く出荷したい)とインフラチーム(最大限の慎重さを望む)の間の慢性的で解決されない緊張を導き、すべてのリリース計画会議で新たに争われていました。正式な99.95%の可用性SLOと明示的なエラーバジェット、事前に決定されたポリシー(予算が枯渇すると機能の仕事が自動的に一時停止する)を採用することは、この繰り返される交渉を完全に解消しました。両方のチームが同じ数字を見て同じルールに同意できました。そして会社は、健全な予算の期間中に出荷された機能の測定可能な増加と、翌年に予算が本物に枯渇した2つの期間における、ポリシーが意図した通りの測定可能で意図的な減速の両方を報告しました。

政府。 ある国家気象サービスの公共警報システムは、何年もの間、文書化された目標なしに「常に利用可能」という非公式な期待の下で運用されており、述べられていない実質的に不可能な基準を満たそうとするオンコールチームに相当な未対処の運用上のストレスを与えていました。新しく採用された正式なSLO、99.9%の可用性に明確に伝えられた公共のエラーバジェットの説明を伴うものは、運用チームに、予算内で計画的な保守時間を予定する明示的で擁護可能な許可を与えました。これは、以前の述べられていない「常に利用可能」という期待が、長期的なシステムの健全性のために本物に必要なときでさえ、政治的に困難にしていたことでした。エラーバジェットの概念を隠すのではなく直接説明する公のコミュニケーションは、サービス品質への約束の弱体化としてではなく、正直で成熟した運用の実践の兆候として好意的に受け止められました。

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

SLOとエラーバジェットを正式に採用することからの見返りは、速度と安定性の間のそうでなければ終わりのない政治的にコストのかかる交渉を、単一の共有された客観的なルールで解決することです。上記のクラウドストレージの例はこれを具体的に示しています。二つのチーム間の何年にもわたる繰り返される解決されない緊張は、単一の正式な目標と事前に決定されたポリシーによって解決され、以前は同じトレードオフを繰り返し再び争うことに向けられていた相当な組織的なエネルギーを解放しました。

総所有コストには、証拠に基づいた目標を正しく設定するための分析の努力と、それでも特に望まれる機能を出荷するプレッシャーの下でも事前に決定された枯渇対応を守る規律が含まれます。その規律のコストは本物ですが、すべての計画サイクルで無期限に組織的なエネルギーを消費する解決されない慢性的な交渉の継続的なコストよりもはるかに低いです。

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

背後に証拠のない願望的なSLOを設定する。 チームがもはや真剣に受け止めなくなる非現実的な目標、あるいはユーザーが気づかない利益を追い求める不必要に高価な目標を生み出します。
エラーバジェットの枯渇に対する事前に決定された対応がない。 それが起きるたびにプレッシャーの下で同じ困難なトレードオフの議論を強制します。
本物のユーザー体験ではなく内部システムの健全性からSLIを測定する。 ユーザーが実際に問題を経験している間に「健全」と報告することがあります。
健全なエラーバジェットを一度も実際に意図的に使わない。 過度の慎重さと逃した正当な機会を示している可能性があります。
一度目標を設定し、一度も見直さない。 ユーザーの期待、アーキテクチャ、優先順位が変化するにつれて、SLOは古くなる可能性があります。
プレッシャーの下でエラーバジェットのポリシーを任意として扱う。 都合が悪いたびに覆される事前に決定されたルールは、本物の意思決定の価値を提供しません。

成熟度モデル

レベル1、開始: 信頼性の目標は暗黙的あるいは願望的であり、正式なSLO、SLI、あるいはエラーバジェットは定義されていません。
レベル2、発展: いくつかのサービスは非公式のSLOを持っていますが、SLIは本物のユーザー体験を反映していないかもしれず、事前に決定された枯渇ポリシーはありません。
レベル3、標準化: 本物のユーザー体験のSLIと事前に決定されたエラーバジェットの枯渇ポリシーを持つ証拠に基づいたSLOが、重要なサービス全体で一貫して確立されています。
レベル4、管理: エラーバジェットは計算されたリスクテイキングに積極的かつ意図的に使われ、SLOは定期的な証拠に基づいたペースで見直され改訂されています。
レベル5、最適化: SLOとエラーバジェットは、速度と安定性のバランスを取るための共有された客観的なメカニズムとして組織全体に統合されており、組織は、根拠のない交渉がそれほど効果的には解決しなかったであろうこの枠組みが可能にした特定の決定を指し示すことができます。

議論のためのアイデア

私たちの現在のSLOは証拠に根拠づけられているでしょうか、それとも願望に根拠づけられているでしょうか。
私たちはプレッシャーの下で実際に守るであろうエラーバジェットの枯渇への事前に決定された対応を持っているでしょうか。
私たちが最後に計算されたリスクのために健全なエラーバジェットを意図的に使ったのはいつでしょうか。
私たちのSLIは本物のユーザー体験を測定しているでしょうか、それとも便利な内部ヘルスチェックでしょうか。
私たちのSLOをさらに一つの「9」だけ引き上げるには何がかかり、そのコストは正当化されるでしょうか。

主な要点

サービスレベル指標(SLI)は本物のユーザー体験を測定します。サービスレベル目標(SLO)はその証拠に基づいた目標です。エラーバジェットは意図的に使い切れる許容された不足分です。
100%の信頼性は通常間違った目標です。 あなたのSLOを、ユーザーが実際に気づくことと各追加の増分が本物にどれだけのコストがかかるかに根拠づけてください。
エラーバジェットを事前に決定された枯渇対応を持つ使い切れるリソースとして扱い、速度対安定性をプレッシャーの下で毎回再び争う必要性を取り除いてください。
便利な内部ヘルスチェックだけでなく、本物のユーザー体験からSLIを測定してください。
定期的にSLOを見直し改訂してください。 証拠に基づいて行います。システムとそのユーザーが変化するにつれて、古くなった目標は有用性を失うからです。

参考文献とさらなる読書

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 編。
Implementing Service Level Objectives, Alex Hidalgo 著。
Accelerate: The Science of Lean Software and DevOps, Nicole Forsgren、Jez Humble、Gene Kim 著。