システムのスピードと品質を両立する為のエラーバジェットとSLI/SLOという考え方

システムの可用性と機能のイテレーションスピードや市場投入までの時間はトレードオフ
(GoogleのGCPは機能のイテレーションスピードや市場投入までの時間を重要視している)

機能のイテレーションスピードを最大化した上で、システム可用性を担保する為にどうすれば良いか？

その最適解の1つがエラーバジェットという考え方

エラーバジェットとは？

エラー予算
損失可能なシステムの信頼性
許容できる可用性低下の妥協点とも言えます。

開発チームはこのエラーバジェットが基準値を下回ったタイミングでイテレーションは停止して以下を行います。

• システム信頼性の獲得
• エラーバジェットの消費状況の分析/原因特定/対処を行います。

システム信頼性はどう計測し、基準値はどうすれば良いか？
これがSLI/SLOです。

SLI/SLOとは？

SLI

システムの信頼性/安定稼働というものをどう計測するかの指標です。
例えば、リクエスト成功率、レイテンシなどを選定します。

シンプルに以下の様な感覚です。

• エラーがたくさん出たら安定稼働できていない
• レスポンスタイム低下していたら安定稼働できていない

SLO

SLIの数値をモニタリングして、何をもってシステムの信頼性が高いと言えるか、安定稼働しているといえるかの基準値がSLOです。

この運用によって生まれる開発風景

• エラーバジェットが尽きるまでは、機能のイテレーションスピードや市場投入までの時間を重要視する事ができる

• エラーバジェットが尽きた後は、新機能の優先度を下げ以下を行います。

• システム信頼性の獲得

• エラーバジェットの消費状況の分析/原因特定/対処を行います。

エラーバジェット消費の対応例

• QA環境や試験セットを改善し、本番環境への移行前に多くのリリースエラーを見つけ出す。
• ロールアウトの自動化
• モニタリング改善
• 不具合のあるリリースをより迅速に発見しロールバックする方法を開発する。

この結果、リリースの頻度が減ったり、リリースごとの変更点が減少してエラーバジェットへの影響が小さくなったりすることもあります。
しかし、一時的にリリースのスピードを落とす事は、将来的に元のスピードで安全にリリースできるようにするためです。