SLO とエラーバジェット — どこまで壊れてよいかを、先に数字で決める

What — 3 つの言葉

大事なのは、SLI が「利用者から見た体験」を数えていることです。CPU 使用率やメモリは、利用者が困っているかどうかと直接は結び付きません。CPU が 90% でも応答が返っていれば誰も困らず、CPU が 20% でも決済サービスが失敗していれば利用者は困ります（ログと監視）。

100% を目標にしない

「落ちないこと」、つまり 100% は、目標にできません。

• 利用者の回線、ブラウザ、決済サービス、クラウド。自分で直せないものが、すべて 100% ではない
• 99.9% から 99.99% に上げると、許される失敗は 43 分から 4 分になる。4 分では、人が気づいて何かをする前に使い切る
• 目標を 1 桁上げるたびに、費用と開発の遅さが大きく増える

目標を決めることは、「この程度の失敗は許す」と決めることです。許せる量が決まれば、それを何に使うかを選べます。新しい機能のリリース、実験、計画的なメンテナンス。

CPU > 80%        → 鳴る
メモリ > 85%     → 鳴る
エラー 1 件      → 鳴る
応答 > 1 秒      → 鳴る

1 日 80 件。大半は自然に戻る

Why — なぜ数字で決めておくのか

「どこまで壊れてよいか」を、誰も言えない

冒頭の事業側の質問に、誰も答えられませんでした。目標が無いと、すべての失敗が同じ重さに見えます。CPU の一瞬の上昇も、決済の 5% の失敗も、同じ「エラー」の通知です。

SLO があると、失敗に重さが付きます。「決済の成功率 99.9% の約束に対して、このままだと 6 時間で予算を使い切る」は、今すぐ動く理由になります。「CPU が一瞬 80%」は、予算を減らしていないので、動く理由になりません。

予算を使い切ったら、何をするかを先に決める

エラーバジェットのいちばんの価値は、安定と開発の速さの取り合いを、数字で決められることです。

• 予算が残っている → 新しい機能のリリースを続けてよい。多少の失敗は予算の中
• 予算を使い切った → リリースを絞り、安定性の改善に時間を使う

ただし、これは事前に、事業側と合意しておく必要があります。使い切ってから「リリースを止めます」と言っても、通りません。

目標の数字の決め方

目標は、次の 2 つから決めます。

1. 今の実績: 過去 30 日で、実際に何 % だったか。実績より大きく高い目標は、最初から守れない
2. 利用者が困り始める水準: 問い合わせや解約が増え始めるのは、どのくらいの失敗からか

たとえば、実績が 99.95% で、問い合わせが増えるのが 99.5% を下回ったときなら、99.9% が出発点になります。守れる数字から始め、運用しながら見直します。

演習 — まず自分で判断する

解説を読む前に、まず自分で判断してみてください。ここで一度詰まっておくと、 次の節の判断軸が「なるほど」ではなく「そう来たか」に変わります。