SRE ツール
SLI・SLO・SLA の違い、可用性のパーセンテージが実際に何分のダウンタイムを許すのか、エラーバジェットとバーンレートをアラート閾値へ落とす計算、そして cron スケジュールの検証方法までをまとめた SRE 向けの実務リファレンスです。
3 ツール
SLI・SLO・SLA は別の数値
SLI は測定値(good events ÷ valid events)、例えば「300ms 未満かつ 5xx 以外で返せたリクエストの割合」。SLO はその比率の目標で、99.9%/30日ローリングのように窓を伴います。SLA はより緩い目標に返金クレジットを紐づけた契約です。
難しいのは数値ではなく SLI の定義です。同じ 99.9% でも、429 をエラーに数えるか、ヘルスチェックを分母に含めるか、測定点がエッジか内部かで中身は変わります。ナインの前に分子と分母を決めます。
SLO が決まると行動を変える数値、エラーバジェット = 100% − SLO が出ます。99.9%/30日なら 0.1% を落とせ、完全停止換算で43.2分。リリースや移行が消費し、次の窓で補充される通貨です。
可用性を実際の「分」に直す
ナインが1つ増えるごとに、許容ダウンタイムは1/10になります。
| 可用性 | 年(365日) | 30日月 | 週 | 日 |
|---|---|---|---|---|
99% | 3日15.6時間 | 7.2時間 | 1.68時間 | 14.4分 |
99.5% | 1日19.8時間 | 3.6時間 | 50.4分 | 7.2分 |
99.9% | 8.76時間 | 43.2分 | 10.1分 | 1.44分 |
99.95% | 4.38時間 | 21.6分 | 5.04分 | 43.2秒 |
99.99% | 52.6分 | 4.32分 | 60.5秒 | 8.64秒 |
99.999% | 5.26分 | 25.9秒 | 6.05秒 | 0.86秒 |
99.99% の月間許容4.32分は、オンコール体制ではなく自動フェイルオーバーの話です。
バーンレート: SLO からアラート閾値へ
バーンレートは実測エラー率を SLO が許すエラー率で割った倍率です。消費バジェット = バーンレート × (観測窓 ÷ SLO 期間) により、短時間の観測を月全体の主張に変換できます。
| バーンレート | 99.9% SLO のエラー率 | 30日分を使い切るまで | 対応 |
|---|---|---|---|
1× | 0.1% | 30日 | 通知不要 |
6× | 0.6% | 5日 | ページング(6h窓・5%消費) |
14.4× | 1.44% | 50時間 | ページング(1h窓・2%消費) |
100× | 10% | 7.2時間 | 即ページング |
1000× | 100%・完全停止 | 43.2分 | インシデント |
速い閾値には短い確認窓(14.4× は5分、6× は30分)を併用します。遅いバーンはチケットへ。
どのツールでどの問いに答えるか
パーセンテージを時間に直すならSLA稼働率計算ツール(年・30日月・週・日の許容ダウンタイム、90%〜99.999% プリセット付き)。判断を動かす段階ではエラーバジェット計算ツールで、SLO・窓(日数)・想定リクエスト数から割合・許容ダウンタイム・許容失敗件数(99.9%/30日/100万なら1,000件)が出ます。部分劣化でも意味を保つのは件数です。
何を失敗と数えるかはHTTPステータスコード一覧で決めます。コード番号から名称・クラス・1行の意味を引く表で、番号でも語句でも絞り込めるため、400(リクエストを解釈できない)と 422(構文は妥当だが意味的に不正)の切り分けはその場で付きます。307 と 308 にはメソッドを保持すると明記されていますが、301 が POST をどう扱うかは書かれていません。クライアントは GET に書き換えてボディを捨てることがあり、POST エンドポイントの恒久移動に 308 が要るのはそのためです。実応答はHTTPヘッダーチェッカー——api.sitekits.dev 経由で最終ステータス・リダイレクト回数・応答時間・全ヘッダーを返します。ボディは取得せず、private/localhost は SSRF ガードで拒否。ボディや認証ヘッダー、POST を伴う手動プローブ(シンセティックチェックの当たりを付ける用途)にはREST APIテスターを使います。リクエストはブラウザから指定した対象へ直接飛び、sitekits のサーバーは経由しません。そのぶん対象側の CORS ポリシーがそのまま適用されます。周辺はHTTPハブに。301・302・303・307・308 を並べたリダイレクト選択表もそちらにあります。
レイテンシは HAR をHARビューアで開き、添付前にHARサニタイザーへ通します(authorization・cookie・x-api-key・全ボディが [REDACTED])。
スケジュール・窓・時計
信頼性の作業が静かに壊れるのは cron です。crontabエディタは5フィールドの式を解析し、次の8回の発火時刻をブラウザのローカルタイムゾーンで並べます。下の表は2つのことを同時に示しています——どの cron にも共通するフィールドの範囲と、このエディタが実際に解釈する狭い文法(整数と *・リスト・範囲・ステップの組み合わせだけ)です。
| フィールド | 範囲 | エディタが受け付ける形 | 他の cron では有効・ここでは拒否 |
|---|---|---|---|
| minute | 0–59 | *, 5,20, 0-30, */15 | — |
| hour | 0–23 | 同じ | — |
| day-of-month | 1–31 | 同じ | L・W(Quartz、AWS) |
| month | 1–12 | 同じ | JAN〜DEC の名前(Vixie、cronie) |
| day-of-week | 0–6(0=日) | 同じ | 日曜の 7 と SUN〜SAT(Vixie、cronie)、5#3(Quartz) |
右端の列はすべて Invalid cron expression (expected 5 fields) という同一のメッセージで弾かれます。5フィールド揃っていても同じ文言なので、0 3 * * 7 はフィールド数の誤りに見えて実際は語彙の誤りです。日曜は 0 と書きます。行単位のマクロ(@daily・@reboot)や秒を含む6フィールド方言も同じ理由で拒否され、逆順の範囲も不可です(22-2 は 22-23,0-2 と書きます)。静かに間違うのは 5/15 だけで、これは単一値の 5 として解釈されます。Kubernetes 系のパーサは 5-59/15 に展開するため、範囲を明示して書いてください。
表に収まらない点が3つ。日付の組み合わせでは POSIX のどちらか一致が効き、day-of-month と day-of-week が両方制限されている 0 0 1 * 1 は毎月1日と毎週月曜の両方で発火します。ただしエディタは「制限されているか」を文字列で判定し、* で始まる日フィールドはすべて無制限として扱います。ステップはこの判定を素通りするため、day-of-month の */3 は無制限とみなされて 0 0 */3 * 1 はANDになり、1日・4日・7日…に当たる月曜だけに発火します(どちらか一致にしたいなら同じ日付を 1-31/3 と書きます)。ステップは時計ではなくフィールドを分割するので、分の */7 は :00〜:56 まで走ったあと :00 に戻り、4分の隙間ができます。そしてプレビューはブラウザのタイムゾーンで計算される一方、サーバーの時計は通常 UTC です。
Unix時間変換は 1e12 未満を秒、以上をミリ秒として解釈し、タイムゾーン変換は同一の瞬間を12の IANA ゾーンに DST 込みで展開します。他はSRE向けツールに。
よくある落とし穴
契約の「月」と計算機の「月」は違う
計算機は30日固定・365日固定です。暦月で測る 99.9% は2月(28日)40.32分、7月44.64分——同じ文言で1割ぶれます。
可用性は依存の連鎖で掛け算になる
99.9% の必須依存3つを直列にすると 0.999³ = 99.70%、月あたり約2.16時間で43.2分ではありません。
時間ベースと件数ベースは互換ではない
許容ダウンタイムは停止中エラー率100%が前提です。5%失敗の部分劣化は件数バジェットを 50× で焼く一方、外部監視の稼働時計はほぼ動きません。
監視間隔が測定解像度の下限になる
60秒間隔の監視は20秒の停止を捉えられず、1回の失敗が約1分——99.99% の月間バジェットの23%です。スリーナイン超はリクエストログで測ります。