原因ではなく、返ったもので数える — データ起因の 500 と、200 の縮退応答

環境: Docker 28.4.0(linux/arm64)、nginx:1.31.6-alpine(nginx/1.31.6)の後ろに python:3.14-slim(Python 3.14.7、sqlite 3.46.1 の :memory:)の自前アプリ、さらに依存先(推薦サービスの模型)。乱数なしの決定的な構成で、2回実行して集計は一致しました。

• (a) 利用者は id 1〜100 あるが、バッチで作る集計行は 70 件まで。id 71〜100 は行が無く、アプリは 500 を返す
• (b) 集計行は 100 件揃っている。id 70 まで要求したあと依存先を止め、id 71〜100 は推薦を空にして 200 を返す

# app.py(抜粋。do_GET の本体から。インデントを詰めた)
stats = db.execute(
    "select logins, last_seen from profile_stats where user_id=?", (uid,)
).fetchone()
# (a) バッチ未完: stats が None のまま添字参照 → TypeError → 500
logins, last_seen = stats[0], stats[1]
try:
    recs = fetch_recs(uid)
    degraded = "0"
except (urllib.error.URLError, OSError, TimeoutError) as e:
    if MODE == "b":
        # (b) 依存先が落ちた: 既定値で埋めて 200、縮退を1列で申告
        recs = []
        degraded = "1"
        cause = f"deps:{type(e).__name__}"
    else:
        raise
status = 200
self._send(
    200,
    {"id": user[0], "name": user[1], "logins": logins, "last_seen": last_seen, "recs": recs},
    {"X-Degraded": degraded},
)

この 500 は、本実装が TypeError を捕まえて明示的に返したものです。nginx のログ形式は '$status $upstream_status $upstream_http_x_degraded $request_method $request_uri $request_time' です。2列目は nginx が上流(アプリ)から受け取った状態コード(第5回で扱う)、3列目はアプリの応答ヘッダ X-Degraded の値です。

# (a) a-nginx-sli.log
200 200 0 GET /profile/69 0.000
200 200 0 GET /profile/70 0.001
500 500 - GET /profile/71 0.000
500 500 - GET /profile/72 0.001
# (b) b-nginx-sli.log
200 200 0 GET /profile/69 0.001
200 200 0 GET /profile/70 0.001
200 200 1 GET /profile/71 0.016
200 200 1 GET /profile/72 0.003

(a) の 500 行に原因はありません。原因はアプリの標準出力にだけ残っていました。

app mode=a path=/profile/71 status=500 degraded=- cause=TypeError:'NoneType' object is not subscriptable dt=0.0001
app mode=a path=/profile/72 status=500 degraded=- cause=TypeError:'NoneType' object is not subscriptable dt=0.0000
app mode=b path=/profile/71 status=200 degraded=1 cause=deps:URLError dt=0.0156
app mode=b path=/profile/72 status=200 degraded=1 cause=deps:URLError dt=0.0022

(b) の URLError は、urllib が名前解決の失敗も接続拒否も包む例外で、このログからはどちらかを区別できません。

可用性 SLI = (全件 − 5xx) ÷ 全件 で数えると、(a) は (100 − 30) ÷ 100 = 70.00%、(b) は (100 − 0) ÷ 100 = 100.00% です。SLO 99% なら、100 件で許される悪い事象は (1 − 0.99) × 100 = 1 件。(a) の 30 件はその 30 倍で、(b) は 0 件と数えられます。

分母は同じ全件のまま、分子だけを2通りにしました。品質(1) = (全件 − 縮退の申告) ÷ 全件、品質(2) = (200 かつ縮退していない) ÷ 全件 です。

--- (a) ---
全件 N=100  status別={'200': 70, '500': 30}  x_degraded別={'-': 30, '0': 70}
5xx=30 4xx=0 degraded(=1)=0 200かつdegraded=0 -> 70
可用性 SLI  = (全件 - 5xx) / 全件               = (100 - 30) / 100 = 0.7000 = 70.00%
品質 SLI(1) = (全件 - degraded=1) / 全件         = (100 - 0) / 100 = 1.0000 = 100.00%
品質 SLI(2) = (200 かつ degraded=0) / 全件      = 70 / 100 = 0.7000 = 70.00%
--- (b) ---
全件 N=100  status別={'200': 100}  x_degraded別={'0': 70, '1': 30}
5xx=0 4xx=0 degraded(=1)=30 200かつdegraded=0 -> 70
可用性 SLI  = (全件 - 5xx) / 全件               = (100 - 0) / 100 = 1.0000 = 100.00%
品質 SLI(1) = (全件 - degraded=1) / 全件         = (100 - 30) / 100 = 0.7000 = 70.00%
品質 SLI(2) = (200 かつ degraded=0) / 全件      = 70 / 100 = 0.7000 = 70.00%

(a) では、品質(1) が 100.00% と出ます。可用性が 70.00% に落ちている同じログで、です。品質(2) は (a) も (b) も 70.00% です。品質(1) だけを「品質 SLI」として掲げると、500 の多い日ほど品質がよく見えます。