SREとは｜SLI・SLO・SLAの違いとエラーバジェット計算

SLI で測り、SLO で目標を決め、目標との差（エラーバジェット）でリリースを続けるか止めるかを決めます。SLA は、その SLO を利用者との約束にしたものです。

flowchart TD
    A[SLI<br>良い割合を測る] --> B[SLO<br>目標 99.9%]
    B --> C[エラーバジェット<br>1 - SLO]
    C -->|残る| D[リリース<br>続ける]
    C -->|尽きた| E[変更を止め<br>直す]
    B -.->|約束| F[SLA<br>破ると補償]

確認環境：Python 3.11.15・GNU Awk 5.2.1・nginx 1.24.0（Ubuntu 24.04）。nginx に $request_time を足したログ形式を設定して実際のログ行を確かめ、同じ形式で作った30日分のサンプルログ（141,107行）から SLI・エラーバジェット・バーンレートを計算しました。早見表の数値も Python で計算しています。定義・数値の目安は Google の『Site Reliability Engineering』（SRE 本）と『The Site Reliability Workbook』（sre.google で公開）で確かめています（確認日 2026年10月17日）。

SREとは：Googleの定義

SRE（Site Reliability Engineering、サイト信頼性エンジニアリング）は、Google が始めた、サービスの信頼性をソフトウェアエンジニアリングで守る方法です。 SRE 本の序章は、SRE を次のように説明しています。

SRE is what happens when you ask a software engineer to design an operations team. （SRE は、ソフトウェアエンジニアに運用チームを設計させたときに生まれるもの）

手作業の運用を人を増やして回すのではなく、自動化・測定・目標値で回すのが特徴です。SRE 本の序章は、SRE の原則（tenets）として次の8つを挙げています。

「100% は、ほぼすべてのものにとって間違った信頼性の目標」というのが SRE の出発点です（SRE 本 序章）。利用者とサービスのあいだには、利用者の PC・家庭の Wi-Fi・プロバイダー・電力網などがあり、それらを合わせた可用性は 99.999% よりずっと低い、と SRE 本は説明しています。その先でサービスだけを上げても利用者には違いが分かりにくく、変更の速さと費用が犠牲になります。

SREとDevOpsの違い

『The Site Reliability Workbook』は、両者の関係を 「class SRE implements interface DevOps」（SRE は DevOps というインターフェースを実装したクラス）と表現しています。DevOps が考え方、SRE はそれを具体的なやり方と役割にしたもの、という関係です。

表はワークブックの「How SRE Relates to DevOps」の章をもとにまとめたものです。

SLI・SLO・SLAの違い

SLI は「測った値」、SLO は「その目標」、SLA は「目標を守れなかったときの約束ごとを含む契約」です。 SRE 本の定義は次のとおりです。

SRE 本は、SLO と SLA の見分け方を 「SLO を守れなかったら何が起きるか」を聞くこととしています。明確な結果（返金など）が決まっていれば SLA、決まっていなければ SLO です。

SLO は SLA より厳しくしておきます。 SRE 本にも「利用者に示す SLO より厳しい社内 SLO を使うと、問題が目に見える前に対応する余裕ができる」とあります。上の例では、社内の SLO 99.9% を割っても、SLA の 99.5% までには余裕があります。

SLA の項目と目標値の例は、関連記事「SLAの項目例と目標値一覧 SLO・SLIとの違いと合意書ひな形」で扱っています。

SLI の作り方：良いイベント ÷ 全イベント

ワークブックは、SLI を 「良いイベントの数 ÷ 全イベントの数」の形にすることを勧めています。0%（何も動かない）〜100%（何も壊れていない）の範囲になり、SLO・エラーバジェットと同じ物差しで扱えます。

可用性の測り方には2つあります。SRE 本によると、Google は「時間」ではなく「リクエストの成功率」を使っています。

稼働率（時間ベース）の計算と直列・並列の構成での求め方は、関連記事「可用性設計と稼働率の計算｜直列・並列の計算式と停止時間の早見表」で扱っています。

エラーバジェットとは：停止してよい時間の早見表

エラーバジェットは「1 − SLO」で、SLO を守ったまま失敗してよい量です。 SRE 本の序章にも「the error budget is one minus the availability target」とあります。SLO 99.9% なら、エラーバジェットは 0.1% です。

可用性ごとに、全部止まった場合に何分まで止まってよいかを Python で計算しました。

"""可用性ごとのエラーバジェット（停止してよい時間）を計算する"""
def fmt(minutes):
    if minutes >= 60:
        return f"{minutes / 60:.2f} 時間"
    if minutes >= 1:
        return f"{minutes:.2f} 分"
    return f"{minutes * 60:.1f} 秒"

print(f"{'SLO':>8} | {'30日':>10} | {'4週（28日）':>10} | {'1年（365日）':>10}")
for slo in [0.99, 0.995, 0.999, 0.9995, 0.9999, 0.99999]:
    row = [fmt((1 - slo) * days * 24 * 60) for days in (30, 28, 365)]
    print(f"{slo:>8.3%} | " + " | ".join(f"{c:>10}" for c in row))

99.99% の1年 52.56 分は、SRE 本の「Embracing Risk」の章の数字と一致します。9 が1つ増えるごとに、止まってよい時間は10分の1になります。 99.99% の30日 4.32 分は、人が呼び出しに気づいて PC を開くあいだに尽きる長さです。手での対応を前提にするなら、99.9% あたりが現実的な目安になります。

リクエストベースなら「件数」で考えます。 SRE 本の例では、1日 250 万リクエストで日次の目標 99.99% なら、その日は 250 件までエラーを返しても目標を守れます。

測る期間は、ワークブックでは 4週間の移動窓（直近28日） がよい汎用の期間とされています。この記事のサンプルでは、計算を分かりやすくするために直近30日を使っています。

エラーバジェットの使い方

SRE 本の「Embracing Risk」の章では、エラーバジェットは次のように使われます。

• プロダクト側が SLO を決め、監視システム（中立の第三者）が実際の値を測る
• 2つの差が、その期間に残っている「失敗してよい量」になる
• 残っているあいだはリリースを続け、使い切ったらリリースを止めて信頼性に力を入れる

開発チームと SRE が「もっと出したい」「止めたい」で言い合うのではなく、同じ数字を見て決められることが、エラーバジェットの一番の利点です。

nginxのアクセスログでSLIとエラーバジェットを計算する

ここからは実物です。nginx のアクセスログから、可用性とレイテンシの SLI、エラーバジェットの消費、バーンレートを計算します。

① nginx のログに応答時間を足す

nginx の標準の combined 形式には応答時間がありません。レイテンシの SLI を測るため、$request_time（クライアントから最初のバイトを読んでから、最後のバイトを送ってログを書くまでの秒数。ミリ秒の精度）を足します。

http {
    log_format sli '$remote_addr - $remote_user [$time_local] "$request" '
                   '$status $body_bytes_sent "$http_referer" "$http_user_agent" '
                   'rt=$request_time urt=$upstream_response_time';
    access_log /var/log/nginx/access.log sli;

    server {
        listen 80;
        location /healthz { access_log off; return 200 "ok\n"; }   # 監視の死活確認は数えない
        location / { proxy_pass http://127.0.0.1:8000; }
    }
}

nginx 1.24.0 で、0.8秒かかる URL と 500 を返す URL を用意した上流のアプリにリクエストを送ったときのログです。

127.0.0.1 - - [17/Oct/2026:02:07:05 +0900] "GET /api/items HTTP/1.1" 200 13 "-" "curl/8.5.0" rt=0.000 urt=0.001
127.0.0.1 - - [17/Oct/2026:02:07:05 +0900] "GET /api/items HTTP/1.1" 200 13 "-" "curl/8.5.0" rt=0.001 urt=0.001
127.0.0.1 - - [17/Oct/2026:02:07:05 +0900] "GET /slow/report HTTP/1.1" 200 13 "-" "curl/8.5.0" rt=0.800 urt=0.800
127.0.0.1 - - [17/Oct/2026:02:07:05 +0900] "GET /err/checkout HTTP/1.1" 500 16 "-" "curl/8.5.0" rt=0.002 urt=0.002

/healthz は access_log off にしたので、ログに出ていません。監視からの死活確認を SLI に入れると、利用者の体験と関係ない成功が混ざって SLI が良く見えます。 SLI に数えるリクエストは、ログの段階で分けておきます。

② 30日分のサンプルログを作る

同じ形式で、30日分（2026年9月17日〜10月16日）のログを Python で作りました。夜は少なく昼は多い流れにし、次の3つの障害を入れています。

"""SLI 計算の練習用に、nginx の access.log（30日分）を作る"""
import math
import random
from datetime import datetime, timedelta, timezone

random.seed(245)
JST = timezone(timedelta(hours=9))
start = datetime(2026, 9, 17, 0, 0, tzinfo=JST)
end = datetime(2026, 10, 17, 0, 0, tzinfo=JST)
paths = ["/api/items", "/api/items/42", "/api/cart", "/api/checkout", "/"]

# 障害の時間帯：(開始, 終了, 5xx の割合, 遅い応答の割合)
incidents = [
    (datetime(2026, 9, 24, 14, 0, tzinfo=JST), datetime(2026, 9, 24, 14, 40, tzinfo=JST), 0.30, 0.0),
    (datetime(2026, 10, 3, 10, 0, tzinfo=JST), datetime(2026, 10, 3, 12, 0, tzinfo=JST), 0.0, 0.30),
    (datetime(2026, 10, 16, 23, 0, tzinfo=JST), end, 0.05, 0.0),
]

def poisson(lam):
    l, k, p = math.exp(-lam), 0, 1.0
    while True:
        p *= random.random()
        if p <= l:
            return k
        k += 1

with open("access.log", "w") as f:
    t = start
    while t < end:
        lam = 2.0 + 4.0 * max(0.0, math.sin((t.hour - 6) / 24 * 2 * math.pi))  # 1分あたりの平均件数
        err_p, slow_p = 0.0002, 0.003
        for s, e, ep, sp in incidents:
            if s <= t < e:
                err_p, slow_p = max(err_p, ep), max(slow_p, sp)
        for sec in sorted(random.randint(0, 59) for _ in range(poisson(lam))):
            ts = t + timedelta(seconds=sec)
            status = 500 if random.random() < err_p else random.choices([200, 404], [98, 2])[0]
            rt = random.uniform(0.35, 2.5) if random.random() < slow_p else random.uniform(0.005, 0.12)
            ip = f"203.0.113.{random.randint(1, 254)}"
            f.write(f'{ip} - - [{ts.strftime("%d/%b/%Y:%H:%M:%S %z")}] "GET {random.choice(paths)} HTTP/1.1" '
                    f'{status} 512 "-" "Mozilla/5.0" rt={rt:.3f} urt={rt:.3f}\n')
        t += timedelta(minutes=1)

$ python3 gen_log.py && wc -l access.log
141107 access.log

141,107 行、16MB のログになりました。

③ まず awk で可用性の SLI を見る

ステータスは空白で区切った9番目の欄です。5xx を「悪いイベント」として数えます。

awk '{n++} $9>=500{bad++} END{printf "total=%d bad=%d SLI=%.4f%%\n", n, bad, (n-bad)/n*100}' access.log
# 5xx が多かった時間帯（日時の時まで）
awk '$9>=500{print substr($4,2,14)}' access.log | sort | uniq -c | sort -rn | head -3

total=141107 bad=90 SLI=99.9362%
     52 24/Sep/2026:14
      8 16/Oct/2026:23
      2 10/Oct/2026:15

4xx は「悪いイベント」に入れていません。 404 や 400 の多くは、利用者の入力やリンク切れが原因で、サービスが壊れているわけではないからです。429（制限超過）を数えるかなど、何を悪いイベントにするかは SLO の文書に書いておきます。SRE 本も「SLO は、どう測るか・どんな条件で有効かを決めておく」としています。

④ Python で SLI・バジェット消費・バーンレートを出す

可用性（5xx 以外）とレイテンシ（5xx 以外で 300ms 以内）の2つの SLI について、30日のエラーバジェットの消費と、直近のバーンレートを計算します。

"""nginx の access.log から SLI・エラーバジェット・バーンレートを計算する
使い方：python3 sli.py access.log
"""
import re
import sys
from datetime import datetime, timedelta

SLO_AVAIL = 0.999      # 可用性 SLO：5xx 以外の割合
SLO_LATENCY = 0.99     # レイテンシ SLO：300ms 以内の割合
LATENCY_MS = 300
WINDOW = timedelta(days=30)

LINE = re.compile(r'\[(?P<time>[^\]]+)\] "(?P<req>[^"]*)" (?P<status>\d{3}) .* rt=(?P<rt>[\d.]+)')

events = []  # (時刻, 可用性で良いか, レイテンシで良いか)
skipped = 0
with open(sys.argv[1]) as f:
    for line in f:
        m = LINE.search(line)
        if not m:
            skipped += 1
            continue
        t = datetime.strptime(m["time"], "%d/%b/%Y:%H:%M:%S %z")
        status, rt = int(m["status"]), float(m["rt"])
        events.append((t, status < 500, status < 500 and rt * 1000 <= LATENCY_MS))

now = max(e[0] for e in events)
recent = [e for e in events if e[0] > now - WINDOW]
total = len(recent)

def report(name, idx, slo):
    good = sum(1 for e in recent if e[idx])
    bad = total - good
    sli = good / total
    budget = total * (1 - slo)          # 30日で許される「悪い」リクエスト数
    print(f"[{name}] SLO {slo:.1%}")
    print(f"  SLI          : {good:,} / {total:,} = {sli:.4%}")
    print(f"  エラーバジェット: {budget:,.0f} 件（= {total:,} × {1 - slo:.1%}）")
    print(f"  消費          : {bad:,} 件 = {bad / budget:.1%}　残り {budget - bad:,.0f} 件")

def burn_rate(idx, slo, window):
    w = [e for e in recent if e[0] > now - window]
    bad = sum(1 for e in w if not e[idx])
    return (bad / len(w)) / (1 - slo), bad, len(w)

print(f"対象：{recent[0][0]:%Y-%m-%d %H:%M} 〜 {now:%Y-%m-%d %H:%M}（30日）　読めなかった行 {skipped}")
report("可用性", 1, SLO_AVAIL)
report(f"レイテンシ {LATENCY_MS}ms 以内", 2, SLO_LATENCY)

print("\n[日別] 可用性で悪いリクエストが多い日（上位3日）")
daily = {}
for t, ok, _ in recent:
    d = daily.setdefault(t.date(), [0, 0])
    d[0] += 1
    d[1] += (not ok)
for day, (n, bad) in sorted(daily.items(), key=lambda x: -x[1][1])[:3]:
    print(f"  {day}  {bad:>3} 件 / {n:,} 件　バジェットの {bad / (total * (1 - SLO_AVAIL)):.1%}")

print("\n[バーンレート] 可用性 SLO 99.9%（Google SRE Workbook の多窓アラート）")
rules = [("ページ", "1時間", timedelta(hours=1), "5分", timedelta(minutes=5), 14.4),
         ("ページ", "6時間", timedelta(hours=6), "30分", timedelta(minutes=30), 6),
         ("チケット", "3日", timedelta(days=3), "6時間", timedelta(hours=6), 1)]
for kind, ln, long_w, sn, short_w, th in rules:
    bl, badl, nl = burn_rate(1, SLO_AVAIL, long_w)
    bs, bads, ns = burn_rate(1, SLO_AVAIL, short_w)
    fire = bl > th and bs > th
    print(f"  長い窓 {ln:<4} {bl:5.1f}（{badl}/{nl}）  短い窓 {sn:<4} {bs:5.1f}（{bads}/{ns}）"
          f"  しきい値 {th:>4} → {kind + 'を送る' if fire else '通知なし'}")

b1, _, _ = burn_rate(1, SLO_AVAIL, timedelta(hours=1))
left = 1 - sum(1 for e in recent if not e[1]) / (total * (1 - SLO_AVAIL))
print(f"\n直近1時間のペース（{b1:.1f}倍）が続くと、残り {left:.1%} は約 {left * 30 * 24 / b1:.1f} 時間で尽きる")

$ python3 sli.py access.log
対象：2026-09-17 00:01 〜 2026-10-16 23:59（30日）　読めなかった行 0
[可用性] SLO 99.9%
  SLI          : 141,017 / 141,107 = 99.9362%
  エラーバジェット: 141 件（= 141,107 × 0.1%）
  消費          : 90 件 = 63.8%　残り 51 件
[レイテンシ 300ms 以内] SLO 99.0%
  SLI          : 140,378 / 141,107 = 99.4834%
  エラーバジェット: 1,411 件（= 141,107 × 1.0%）
  消費          : 729 件 = 51.7%　残り 682 件

[日別] 可用性で悪いリクエストが多い日（上位3日）
  2026-09-24   52 件 / 4,683 件　バジェットの 36.9%
  2026-10-16   10 件 / 4,583 件　バジェットの 7.1%
  2026-10-10    4 件 / 4,781 件　バジェットの 2.8%

[バーンレート] 可用性 SLO 99.9%（Google SRE Workbook の多窓アラート）
  長い窓 1時間   62.5（8/128）  短い窓 5分    71.4（1/14）  しきい値 14.4 → ページを送る
  長い窓 6時間   11.2（8/717）  短い窓 30分   57.1（4/70）  しきい値    6 → ページを送る
  長い窓 3日     0.9（13/13969）  短い窓 6時間   11.2（8/717）  しきい値    1 → 通知なし

直近1時間のペース（62.5倍）が続くと、残り 36.2% は約 4.2 時間で尽きる

出力から読み取れることです。

SLI だけを見ると「99.94% で目標達成」ですが、バジェットで見ると「残り3分の1、しかも今まさに減っている」と分かります。 エラーバジェットは、同じ数字を「あとどれだけ失敗できるか」に言い換えたものです。

バーンレートとアラート：多窓・多バーンレート

バーンレートは、SLO に対してエラーバジェットを使う速さです（ワークブック「Alerting on SLOs」）。計算は「その窓のエラー率 ÷ (1 − SLO)」です。

• バーンレート 1：30日のバジェットを、ちょうど30日で使い切るペース
• バーンレート 62.5：上の出力の直近1時間。エラー率 6.25%（8/128）は、許される 0.1% の 62.5倍

30日のバジェットを使い切るまでの時間は、30日 ÷ バーンレートです。Python で計算しました。

ワークブックは、SLO 99.9% の場合の目安として、次の3つのアラートを勧めています。

長い窓と短い窓の両方がしきい値を超えたときだけ通知します。 長い窓だけだと、障害が直ったあとも1時間ほど鳴り続けます。短い窓（長い窓の12分の1が目安）を足すと、直れば早く止まります。上の出力では、5分の窓が1件／14件で 71.4 になっています。件数が少ない窓は1件で大きく振れるので、短い窓だけで判断しない理由がここにも出ています。

ワークブックの Prometheus の例は、次の形です（ratio_rate1h などは、窓ごとのエラー率を事前に計算するレコーディングルール）。

expr: (
        job:slo_errors_per_request:ratio_rate1h{job="myjob"} > (14.4*0.001)
      and
        job:slo_errors_per_request:ratio_rate5m{job="myjob"} > (14.4*0.001)
      )
    or
      (
        job:slo_errors_per_request:ratio_rate6h{job="myjob"} > (6*0.001)
      and
        job:slo_errors_per_request:ratio_rate30m{job="myjob"} > (6*0.001)
      )
severity: page

Prometheus と Grafana の構築と PromQL は、関連記事「Prometheus Grafana入門｜監視構築とPromQL一覧」で扱っています。監視項目としきい値の決め方は、関連記事「監視設計の項目一覧｜死活・リソース・ログ監視のしきい値例とテンプレート」で扱っています。

エラーバジェットを使い切ったら：エラーバジェットポリシー

使い切ったときに何をするかを、事前に文書（エラーバジェットポリシー）で決めておきます。 障害の最中に決めると、毎回の言い合いになるからです。

flowchart TD
    A[直近4週の<br>バジェット] --> B{残っている}
    B -->|はい| C[通常どおり<br>リリース]
    B -->|いいえ| D[P0と修正以外<br>の変更を止める]
    D --> E[SLO内で<br>再開]
    A --> F[1回で20%超<br>ポストモーテム]

ワークブックのポリシーの例は、次の内容です。

上のサンプルでは、9月24日の障害が1回で 36.9% を使ったので、このポリシーならポストモーテムの対象になります。

トイルとは：減らす運用作業の見分け方

トイル（toil）は、サービスを動かすための作業のうち、手作業で・繰り返し・自動化できて・長く残る価値のないものです。 SRE 本は、次の6つの特徴を挙げています（すべてを満たさなくても、当てはまるほどトイルに近い）。

SRE 本では、運用作業（トイル）は各 SRE の時間の 50% 未満を目標にしています。Google の SRE への四半期ごとの調査では、トイルの平均は約 33% でした。50% を超えるのは、自動化に手を回せず、運用の作業が増える一方になっている合図です。

ポストモーテムとは：非難しない振り返り

ポストモーテムは、障害のあとに「何が起き、なぜ起き、何を直すか」を書き残す文書です。 SRE 本の「Postmortem Culture」の章は、非難しない（blameless）ことを前提にしています。原因は個人やチームの悪い行動ではなく、それを許した仕組みに求めます。

SRE 本が挙げる、ポストモーテムを書くきっかけは次の5つです（当てはまるものを選ぶと印が付きます）。

• 1利用者から見える停止・劣化が、決めたしきい値を超えた例：エラーバジェットの20%超を1回で使った
• 2データが失われた（種類は問わない）量が少なくても対象
• 3当番の人が手で対応したリリースの切り戻し、トラフィックの切り替えなど
• 4解決までの時間が、決めたしきい値を超えた復旧に時間がかかった理由を残す
• 5監視が失敗した多くは、人が手で障害を見つけたことを意味する

SRE 本の序章には、「呼び出し（ページ）が鳴らなかった障害のポストモーテムは、さらに価値が高い」ともあります。監視の穴を示していることが多いからです。

ポストモーテムの書き方と例文は、関連記事「障害報告書の書き方｜例文つきテンプレートと再発防止策の立て方」で扱っています。障害時の当番の組み方は、関連記事「オンコール体制のルールとローテーションの組み方｜当番表と引き継ぎ手順」で扱っています。

SLOの決め方：最初の1つを作る手順

SRE 本とワークブックの勧めをもとに、最初の SLO を1つ作る順番です。

SRE 本の「Service Level Objectives」の章にある Chubby（Google の分散ロックサービス）の例も、目標の決め方の参考になります。Chubby は期待以上に安定していたため、使う側が「落ちない前提」で依存を増やしてしまいました。そこで SRE は、SLO を満たすが大きく超えないようにし、四半期に一度も SLO を下回らなかった場合は、計画した停止を起こして依存の問題を早めに見つけるようにしています。SLO は高いほどよい、ではありません。

よくある質問

Q. SRE とは何の略ですか。 A. Site Reliability Engineering（サイト信頼性エンジニアリング）の略です。Google が始めた、運用をソフトウェアエンジニアリングで行う方法で、それを担う人を Site Reliability Engineer と呼びます。詳しくは「SREとは：Googleの定義」の節にあります。

Q. SLA と SLO の違いは何ですか。 A. SLO はチームの目標値、SLA は SLO を含む利用者との約束で、守れなかったときの結果（返金など）が決まっています。見分け方は「守れなかったら何が起きるか」です。SLO は SLA より厳しくしておきます。

Q. SLI と SLO の違いは何ですか。 A. SLI は測った値（例：5xx 以外の割合 99.94%）、SLO はその目標（例：30日で 99.9%）です。SLI を「良いイベント ÷ 全イベント」で決め、その値に目標を付けたものが SLO です。

Q. エラーバジェットとは何ですか。 A. 1 − SLO で、SLO を守ったまま失敗してよい量です。99.9% なら 0.1% で、30日間なら全停止で 43.2 分、リクエストなら全体の 0.1% 件です。残っていればリリースを続け、使い切ったら止める判断に使います。

Q. SRE エンジニアは何をする役割ですか。 A. SRE 本では、運用作業を時間の 50% までに抑え、残りの時間で自動化・監視・容量計画・障害対応の仕組みなどを作る役割とされています。SLO とエラーバジェットを決めて守り、障害のあとはポストモーテムを書きます。

Q. SLO は 100% にすべきですか。 A. SRE 本は「100% は、ほぼすべてのものにとって間違った目標」としています。利用者の PC や回線を合わせた可用性は 99.999% よりずっと低く、その先でサービスだけを上げても違いが伝わりにくいからです。

まとめ

• SRE は、運用をソフトウェアの仕事として扱う Google の方法。運用作業は時間の 50% まで
• SLI（測った値）→ SLO（目標）→ SLA（約束）の順に決める。SLO は SLA より厳しく
• エラーバジェット = 1 − SLO。99.9% なら30日で 43.2 分、9 が1つ増えるごとに10分の1
• nginx のログ 141,107 行では、SLI 99.94% で目標は守れていたが、バジェットは 63.8% 消費、1回の障害で 36.9%
• アラートは バーンレートで。1時間 14.4・6時間 6 でページ、長い窓と短い窓の両方で判断する
• トイルは手作業・繰り返し・自動化できる作業。ポストモーテムは非難せずに仕組みを直す

参考・出典

確認日はいずれも 2026年10月17日です。

• Google『Site Reliability Engineering』Introduction：https://sre.google/sre-book/introduction/
• Google『Site Reliability Engineering』Embracing Risk：https://sre.google/sre-book/embracing-risk/
• Google『Site Reliability Engineering』Service Level Objectives：https://sre.google/sre-book/service-level-objectives/
• Google『Site Reliability Engineering』Eliminating Toil：https://sre.google/sre-book/eliminating-toil/
• Google『Site Reliability Engineering』Postmortem Culture: Learning from Failure：https://sre.google/sre-book/postmortem-culture/
• Google『The Site Reliability Workbook』Implementing SLOs：https://sre.google/workbook/implementing-slos/
• Google『The Site Reliability Workbook』Alerting on SLOs：https://sre.google/workbook/alerting-on-slos/
• Google『The Site Reliability Workbook』Example Error Budget Policy：https://sre.google/workbook/error-budget-policy/
• Google『The Site Reliability Workbook』How SRE Relates to DevOps：https://sre.google/workbook/how-sre-relates/
• nginx ドキュメント「Module ngx_http_log_module」：https://nginx.org/en/docs/http/ngx_http_log_module.html

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。