エラーバジェット とは？

開発チームは「早くリリースしたい」、運用チームは「安定させたい」で対立しがちでしょ？エラーバジェットは両者の共通言語になるんだ。予算が残っていれば「どんどんリリースしてOK」、使い切ったら「安定化に集中」。データに基づいてリリース判断ができるから、感情的な対立がなくなるよ

SLOが99.9%（月間稼働率）なら、エラーバジェットは100%-99.9%=0.1%。1ヶ月を30日とすると、30日×24時間×60分×0.1%=43.2分。つまり月間43分までの障害は「予算内」。この43分を使い切る前にリリース頻度を下げるか、使い残しがあれば大胆なデプロイに挑戦できるよ

エラーバジェットポリシーに従って対応するよ。一般的には①新機能のリリースを凍結、②信頼性向上のタスク（テスト追加、モニタリング強化、パフォーマンス改善）に集中、③次の計測期間でバジェットが回復したらリリース再開。ポリシーを事前に合意しておくのが重要で、障害が起きてから議論しても遅いんだ

SLOとエラーバジェットの考え方自体はチーム規模に関係なく有用だよ。まずは1つの重要なAPIのSLOを定義して、稼働率をダッシュボードで可視化するところから始めよう。完璧なSREプラクティスを目指す必要はなく、「信頼性を数値で語れるようにする」だけでも意思決定の質が上がるよ