エラーバジェット

プロダクト開発は速度で、運用は信頼性で評価される。だからリリースのたびに交渉になり、声の大きい側が勝つ。ある水準を超えると利用者は違いに気づかない（信頼性 99% のスマートフォンを使う人には 99.99% と 99.999% の差は分からない）のに、最後のわずかな差にいちばんコストがかかり、いちばん変更を止める。目標を明示すれば、目標と完璧の差が予算になる。30日で 99.9% なら失敗に使えるのは約43分で、残りがいくらかを両者が同じ数字で見られる。

Evernote は Google Cloud へ移ったあと、一部のサービスに暦月ごとの稼働率99.95%という最初の SLO を置き、メンテナンス時間も停止として数えた。SLO とエラーバジェットを使って開発の手をどこに割くか決め、Google と月に一度その実績を見直したという。2017年に複雑なバグを追っていたときは、SLO の計算で顧客への影響を数字にし、週のリリース枠を5回から2回に減らした。

逸脱の常態化：失敗を許す枠があると、チームは失敗をいつものことだと覚える。本来なら騒ぎになるはずの障害も予算から差し引かれるだけで、調べられずに終わる。