可用性の維持・向上のための振り返り: Error Actual Analysis

## 概要

* 現在、チームで取り組んでいる振り返り(Error Actual Analysis)を紹介します
    * Error Budget の取り組みにプラスして行うことで可用性の維持・向上を意図しています

※ Error Actual / Error Actual Analysis は一般的な用語でなくここでの独自用語です

## Error Actual Analysis の目的

1. **SLO違反を未然に防ぐ**
2. **SLO違反していない状態で過剰に反応しないようにする**

## Error Actual Analysis とは

* **Error Actual Analysis** とは、**Error Actual (実績) を分析(Analysis)することでError Budget (予算) の枯渇を未然に防ぐための振り返り** のこと
    * Error Budget の消費率を確認するのではなく、**Error Budget を消費したエラーの内訳** を洗い出し、改善に向けた施策を打つためのもの (Error Budget の運用を補完する)

### Error Budget とは

* Error Budget = 100% - SLO(%)
    * SLO(サービスレベル目標) とは
        * システムの可用性を担保するための基準となる目標値(≒ 目標稼働率)
            * 必ずしも可用性だけではないが、ここでは簡単のため、最も基本となる可用性として取り上げる
    * Error Budget は **エラーを起こしても良い予算(信頼性低下の許容量)** を表している
    * 例: Availability の SLO 99.9% → Error Budget 0.1%分 
        * SLO 違反 = Error Budget 枯渇

### Error Budget の役割

* Error Budget が枯渇した場合、リリースの回数を減らすなどのアクションを取り、SLOの維持・改善を図ることができる
* 一方で、Error Budget に余裕がある場合に、即時のアクションを取らない意思決定も可能である
* 参考
    * [なぜSLOがあるのか](https://cloud.google.com/blog/ja/products/gcp/availability-part-deux-cre-life-lessons)

### Error Actual

* **Error Actual : Error Budget の消費量 & 消費内訳** 
    * 消費内訳の例: **メールアドレス変更登録リクエストのエラー** がBudget消費80%の内約半分を占めている

### Error Actual Analysis の 意義

* Error Budget を使い切らなかった場合に明確なアクションが定義されていない
    * → 将来的に Budget 枯渇の原因となるエラーを事前に察知し損なうリスクがある
* Error Budget を使い切らなくても定期的にその内訳(Error Actual)を洗い出し、分析することで将来の枯渇リスクを減らすことができる
* Burn Rate の監視とは意義が異なる[^diffburnrate]

## Error Actual Analysis 運用の全体像

* Error Actual Analysis の実施するMTGを定期的に実施する
    * 毎週、2-5人、20-45分程度で実施
* 定期的にBudget 消費内訳を分析し、タスクを起票することで、Budget 枯渇を防ぐ

### 注意点

* 毎日はやりすぎ
    * 毎日MTGを実施してしまうと、結果的に過剰に反応することになり、Error Budget を設定した意味がなくなる
* SLO 自体のチェックは毎日見ること(これは SLO / Error Budget の運用でそうなっているはず)


Error Actual Analysis は以下のステップで進めます。

## ① Budgetの消費内訳の列挙

* **MTG 前** に行っておく
* 前回から今回までの間の Budget の消費内訳を列挙
    * ツールなどでリクエストごとにエラー数をまとめておく

* エラー数順に列挙した例

| メソッド | URL | エラー数 | 成功数 | 総数 | エラー率(=エラー/総数) |
| --- | --- | --- | --- | --- | --- |
| POST | https://hoge.example.com/v1/pet | 4 | 830 | 834 | 0.004796 |
| GET | https://hoge.example.com/v1/user/logout | 2 | 9477 | 9479 | 0.000211 |
| GET | https://hoge.example.com/v1/pet/{petId} | 1 | 52756 | 52757 | 0.000019 |
| POST | https://hoge.example.com/v1/store/order | 1 | 127110 | 127111 | 0.000008 |


### ポイント

* 何が Budget を削っていたかがわかるようにしておく
    * → 影響が大きいものが何かがわかるようにしておくことで、[② 調査対象のピックアップ](#② 調査対象のピックアップ)を実施しやくすなる
* エラー数以外の情報も追加することで、後のステップで役立つ
    * リクエストごとのエラー率
        * → [② 調査対象のピックアップ](#② 調査対象のピックアップ)` のピックアップの際に利用できる
    * エラーの詳細情報
        * → [④ エラーの原因調査 & タスク化](#④ エラーの原因調査 & タスク化) の調査の際に利用できる

## ② 調査対象のピックアップ

* **MTG 前** に行う
* 列挙されてものから、調査が必要なものをピックアップする
* 標準的な **ピックアップの基準** 
    * 同一のエラーが 1週間で 3 回以上発生しているかどうか
        * 総リクエスト数に応じて回数は変更する
        * 上の例だと `POST https://hoge.example.com/v1/pet` が対象となる
* 調査対象が、1-5個くらいになるようにピックアップの基準を設定する
    * 翌週(翌スプリントなど)に調査・改善着手を実施できる程度の個数

### ポイント

* 闇雲にすべてを実施してしまうと、 **Budget を設定した意味** がなくなるので、適切なピックアップの基準を設けて置くこと
* ユースケースに応じて、エラー数の他のピックアップの基準を追加・変更することも可能
    * 例1: 増加見込みのリクエストのエラーであれば
        * ← 利用が増えることが見込まれるAPIに着目しておくことで将来のBudget消費を抑えることが期待できる
    * 例2: エラー率が0.5%を超えるものなら
        * ← エラーが起きやすいものを調査することで、共通原因の他のエラーを減らすことが期待できる

## ③ 改善タスクの効果確認

* **MTG 中** に行う
* 以前の Error Actual Analysis で実施したSLO改善タスクによって改善されているかを評価
* 評価の基準
    * 改善対象のエラーの数が減り、[② 調査対象のピックアップ](#② 調査対象のピックアップ) のピックアップから外れているかどうか？
* 評価の結果
    * エラーが十分減少し、ピックアップされていない場合
        * Error Budget の消費が抑えられ、将来のリスクも減少したことを称える
    * エラーが十分減少せずに再びピックアップされている場合
        * **[危険信号]** 原因特定の仕方自体や検証方法に問題がある可能性が高い
        * → 調査手法を再検討し、調査に必要な情報が足りないなら監視の強化などを検討する

## ④ エラーの原因調査 & タスク化

* **MTG 中** に行う
* エラーの原因をその場で調査する
* 追加調査 or 原因解消 のタスクを起票

### ポイント

* 時間が限られているので、予備調査の時間を3分-5分程度とし、時間をかけすぎないようにする
    * チームの人数が多い場合は手分けして実施する
* 調査してわかったことを前提にしてタスク化を実施
    * 調査は完了しなくても良く、わかったところまでの情報を基にタスクを作成する
* **数が多くて時間内に終わらない場合**、調査対象が多すぎることを意味している
    * → ピックアップ基準が甘すぎるので、[② 調査対象のピックアップ](#② 調査対象のピックアップ)のピックアップ基準の見直しを実施
    * ※ Error Budget が枯渇している状態であれば、早急な対応が必要なので別途時間を確保して対応する


[^diffburnrate]: Error Budget の burn rate の監視は、Budget の消費の勢いに注目するもので、主に短期(時間・日)で Budget の枯渇を未然に防ぐために利用されることが多い。Error Actual Analysis では、Budget の消費内訳に注目し、エラー詳細を確認するもので、 特に中長期(週・月)でのBudget 枯渇を未然に防ぐことにも繋がる。この性質のため、消費の内訳が変化しやすく、エラー詳細も変わりやすいフェーズ(サービス成長期など)に特に有効と考えられる