# フィーチャーフレッシュネス ## 定義 フィーチャーフレッシュネス(Feature Freshness)とは、エラーバジェットモデルを**フィーチャーの新鮮さ**ドメインに拡張した概念であり、**レガシーバジェット**(Legacy Budget)とも呼ばれる。「サポートが切れるほど古くもなく、誰も使いたくないほど新しくもない」バンドを SLI/SLO/ポリシーで維持する。Thomson・Laing が SREcon19 Americas で提唱した (Source: [[@2019__SREcon19Americas__Extending the Error Budget Model to Security and Feature Freshness]])。 ### 「Old Faithful vs NEW Faithful」の比較 - **Old Faithful**(馬車): 安定しているが古く、新機能がなく誰も使いたくない状態。 - **NEW Faithful**(Lexus): 安定しつつ新機能を提供し、ユーザーが使い続けたい状態。 フィーチャーフレッシュネスは「NEW Faithful」の状態を維持するための仕組みである。 ### SLI/SLO/ポリシーの定義 | 要素 | 内容 | 例 (Kubernetes) | |---|---|---| | **SLI** | 使用中フィーチャーのリリースからの経過日数 | 143 days since k8s v1.11.x released | | **SLO** | 「どれだけブリーディングエッジでありたいか」を示す範囲 | 上限 = supported (サポート対象)、下限 = stable features | | **ポリシー** | SLO 範囲から外れそうになったらアップグレードする | 90 日毎にアップグレード (例: v1.12.12 - v1.13.6 の範囲) | Kubernetes の例: 新リリースが約 90 日毎に出て N-2 サポートポリシーがある場合、SLO は「サポート内かつ安定フィーチャーが使えるバンド」として設定する。SLI がバンドを上回りそうになったらアップグレードする。 ### SLO が「点」でなく「範囲」である理由 可用性のエラーバジェットでは SLO が「99.9% 以上」という単一閾値で定義されるが、フィーチャーフレッシュネスでは SLO が「上限と下限のある帯」として設定される。上限 = サポート切れ前(古すぎず)、下限 = 安定フィーチャー確保後(新しすぎず)。この帯を維持するポリシーが「ブリーディングエッジ度の調整」として機能する。(Source: p.41, [[@2019__SREcon19Americas__Extending the Error Budget Model to Security and Feature Freshness]]) ## 横断的知見 - **「新しすぎること」もリスクとして SLO で管理できる点が可用性バジェットとの重要な差異**: 可用性のエラーバジェットでは「悪い状態を最小化する」が目標だが、フィーチャーフレッシュネスでは「古すぎる状態と新しすぎる状態の両方を避ける」ことが目標になる。SLO を範囲として定義することで、保守的すぎる運用(古い安定バージョンに留まる)も問題として可視化できる。これは [[エラーバジェット]] の「予算を消費しすぎても使い切らなすぎても問題」という拡張版として解釈できる (Source: [[@2019__SREcon19Americas__Extending the Error Budget Model to Security and Feature Freshness]])。 ## 未解決の問い - フィーチャーフレッシュネスの SLI を「リリースからの経過日数」で定義した場合、フィーチャーの重要度や互換性破壊(breaking change)を重みとして考慮すべきか。 - SLO の「帯」の幅はどう決めるか。スポンサーのリスク許容度に依存するなら、どのステークホルダーが決定すべきか。 - k8s の N-2 サポートポリシーのように外部ベンダーが定義する場合は帯の設定が比較的簡単だが、内部開発のフィーチャーに適用する場合の帯の設定基準は何か。 - 複数の依存関係(k8s、Ubuntu、JVM 等)を同時に管理する場合、それぞれ別の SLO を設定すべきか、統一した「プラットフォーム鮮度スコア」として集約すべきか。 ## 関連 - 概念: [[エラーバジェット]] / [[脆弱性バジェット]] / [[SLI-SLO段階的導入]] - エンティティ: [[Jim Thomson]] / [[David Laing]] / [[Pivotal Software]] - ソース: [[@2019__SREcon19Americas__Extending the Error Budget Model to Security and Feature Freshness]] - 関連 MOC: [[structures/SRE - MOC]] ## 出典 - [[@2019__SREcon19Americas__Extending the Error Budget Model to Security and Feature Freshness]] (定義・k8s 事例・SLO 範囲設計・ポリシー)