SLAを覚えた後は「何を測るか」を具体化する
SGのSLAとサービスレベル管理では、合意と測定、応答と解決を区別しています。本記事は、システムの信頼性目標を運用判断へつなげるSLOとエラーバジェットに絞ります。SGの学習事項を周辺の運用実務と結び付ける解説であり、これらの全用語がそのまま試験に出ると主張するものではありません。
利用者の要求が正常に完了した割合をSLIとして測り、一定期間に99.9%以上を目指すという目標をSLOとします。SLAは顧客との合意や契約条件を含み、未達時の扱いが定められる場合もあります。社内のSLOを決めたからといって、自動的に顧客への返金条件が成立するわけではありません。
- SLI：観測する値定義した有効要求のうち、正常完了した割合
- SLO：目指す水準定義した集計窓で99.9%以上
- SLA：利用者との合意対象、測定条件、未達時の扱い等は合意内容で確認
当サイトの整理。すべてのSLAに同じ罰則・返金条件があるわけではありません。
独自例：20,000件に対する失敗の許容量は20件
ある集計期間に、有効要求が20,000件あり、正常完了が19,988件、失敗が12件だったとします。SLOは正常完了率99.9%以上です。正常完了率は19,988÷20,000＝99.94%で、この期間の集計値では目標を満たしています。
許容される失敗率は100−99.9＝0.1%。件数へ直すと20,000×0.001＝20件です。既に12件失敗しているため、同じ総要求数20,000件を固定した評価では残り8件、許容量の40%が残っています。20件を「必ず失敗してよい」と使い切るための枠ではなく、信頼性と変更判断を話し合うための指標です。
| 項目 | 式 | 値 |
|---|---|---|
| 正常完了率 | 19,988÷20,000×100 | 99.94% |
| 許容失敗件数 | 20,000×(1−0.999) | 20件 |
| 消費した許容量の割合 | 12÷20×100 | 60% |
| 残り | 20−12 | 8件（40%） |
件数ベースの予算は、停止時間そのものではない
この例の20件は、要求件数を分母にした失敗許容量です。20件を20分と読むことはできません。同じ1分の停止でも、閑散時間に要求が2件しか来ない場合と、繁忙時に1,000件来る場合では、失敗件数への影響が違うためです。
別の目標として、30日間の全分を対象に時間ベースの稼働率99.9%以上と定義した場合、30×24×60×0.001＝43.2分が計算上の許容時間となります。ただし、これは測定対象が異なる別例です。営業時間、計画停止、部分障害をどう扱うかなど、実際の合意を確かめてから使います。
要求件数で測る
- 分母：有効要求20,000件
- 許容：失敗20件
- 混雑する時間の失敗は件数へ大きく影響
時間で測る別の例
- 分母：30日＝43,200分
- 許容：43.2分
- どの時間・停止を数えるかを別途定義
二つは同じ障害を同じ重さで評価する指標ではありません。
要求が増えた後は、分母と予算を計算し直す
残り8件という値は、先ほどの20,000件という集計に対する値です。後で有効要求が10,000件増え、そのうち30件が失敗すると、累計は30,000件・失敗42件になります。許容量は30件、正常完了率は29,958÷30,000＝99.86%で、目標未達です。消費率は42÷30＝140%となります。
「失敗が追加で8件に達するまでは、どんな状況でも安全」とは言えません。評価期間が動くローリング窓なら古い要求と失敗が窓から外れるため、件数が減ることもあります。暦月なのか直近28日なのかを決め、異なる窓で計算した割合を比較しないようにします。
再試行をどう数えるかで、数字の見え方が変わる
利用者の一つの操作に対し、内部で三回再試行した場合を考えます。通信試行を一回ずつ数えるSLIと、利用者の操作が期限内に成功したかを測るSLIでは、分母も成功の定義も異なります。最後に成功したから途中の遅延や失敗をすべて無かったことにしてよいとは限りません。
監視用の確認通信、ボット、対象外の入力エラーなどを除外するなら、何をなぜ除外するかを先に定義します。未達になってから都合の悪い要求だけを外すと、同じ品質を測れなくなります。成功率が高くても画面の応答が遅ければ不便なので、必要に応じて遅延の指標も別に確認します。
予算を超えたら、変更の内容と方針を確認する
GoogleのSRE資料では、エラーバジェットを信頼性と変更速度のバランスに用い、方針を合意しておく考え方を示しています。ただしGoogleの例示方針を、すべての組織で同じように採用すべきとするものではありません。事業への影響、必要な安全措置、権限を踏まえて自分の運用方針を作ります。
今回の架空のチームが「目標未達なら通常の新機能変更は保留し、復旧と原因調査を優先する。ただし重大なセキュリティ修正は別途評価する」と合意していたなら、その方針に沿って判断します。未達だからセキュリティ修正も機械的に止める、逆に緊急という名前だけで確認を省く、どちらも適切ではありません。
全体が達成していても、一部の利用者は困っているかもしれない
全要求の成功率99.94%という値は、すべての地域や機能が同じ品質だったことを意味しません。要求の少ない重要機能だけが失敗していても、大量に使われる別機能の成功に埋もれる場合があります。利用者が完了したい作業を基準に、機能や地域など必要な切り口を考えます。
ただし細分化しすぎて、少数件の割合だけで毎回方針を変えるのも避けます。件数、対象、期間、業務への影響を添えて判断します。監視の数字が良いことと、障害やセキュリティ事故がないことを同義にはしません。
学習では、式と運用判断を分けて説明する
復習時は、まず何を分母にしたどの期間の指標かを一行で書き、その後に許容量と消費率を計算します。さらに「数値が未達だから何をするか」は、合意した方針と影響に基づく別の判断として説明してください。予算という名前に引かれて、お金の支出枠と混同しないことも大切です。
監視ログと対応判断やバックアップと復旧も、測定値からどの行動へつなぐかという視点で読めます。資格対策の入口はSG講座、比較はサイバーセキュリティの学習ガイドを確認してください。