SLA、 SLO、信頼性KPI

1）利用規約と相違点

SLI （Service Level Indicator）-品質の測定可能な指標（たとえば、成功したリクエストの割合、p95レイテンシ）。
SLO （Service Level Objective）-タイムウィンドウあたりのSLI値をターゲットにします（例："success ≥ 99。28日で9％"）。
Error Budget-許可されているSLO障害率は'1 − SLO'です。
SLA（サービスレベル契約）-罰金/クレジット（外部）の契約上の義務。
信頼性KPI-運用プロセスメトリック（MTTD/MTTA/MTTR/MTBF、％自動軽減、アラートカバレッジなど）。

💡 規則：SLA ≤ SLO；外部契約は、サービスの内部目的より厳格であってはなりません。

2） SLIの選び方（ゴールデンシグナルに基づく）

1.レイテンシー-キーエンドポイントのp95/p99。
2.トラフィック-RPS/RPM/メッセージフロー。
3.エラー-5xx/ビジネスエラーの共有（たとえば、PSP障害による支払いの減少を除く）。
4.飽和-リソース飽和（CPU/RAM/IO/lag）。

良いSLI基準：

ユーザー認識のエクスペリエンスと相関します。
技術的に利用でき、測定で安定した。
私達は制御します（改善のための行為は可能です）。
低コレクションコスト。

3）数式と例

3.1可用性


Availability = Успешные запросы / Все запросы
Error Budget (за период) = 1 − SLO

例：SLO 99。30日で9％→エラー予算=0。1％、これは利用不能の43分12秒に相当します。

3.2レイテンシー

レイテンシによるSLOは、しきい値に収まる要求の割合として定式化されます：


Latency SLI = доля запросов с duration ≤ T
SLO пример: 99% запросов ≤ 300 мс (rolling 28d)

3.3支払い（ビジネスレベル）


Payment Success SLI = (успешные проводки — внешние отказы PSP) / все попытки

💡 サービス障害から「顧客カードによる拒否」を除外する。プラットホームの罪悪感だけを含んで下さい。

4）欠陥のある予算と燃焼率

予算エラー-革新（リリース、実験）のための「燃料タンク」。

燃焼率-予算の消費速度：

速いチャネル（~ 1 hの検出）、
遅いチャネル（~ 6-12 h/24 h上の傾向）。

しきい値のアイデア：

燃焼率>14。1時間に4-SEV-1（私たちは~ 100分で毎日の予算を食べます）。
6時間の焼跡率>6-SEV-2（急速な低下）。

5） SLOによる警告（マルチウィンドウ、マルチバーン）

エラーインジケータ：5xxまたはレイテンシー違反の割合。

PromQL（一般化）の例：

promql
Доля ошибок за 5 минут sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

Быстрый burn (1m окно)
(
sum(rate(http_requests_total{status=~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
) / (1 - SLO) > 14.4

Медленный burn (30m окно)
(
sum(rate(http_requests_total{status=~"5.."}[30m])) /
sum(rate(http_requests_total[30m]))
) / (1 - SLO) > 2

レイテンシによるSLOの場合、パーセンタイルヒストグラムを使用します：

promql p95 latency histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

6） SLI/SLOの例

6.1 APIゲートウェイ/エッジ

SLIエラー：5xx応答速度<0。1％（28d）。
SLIレイテンシー：p95 ≤ 250 ms（日）。
SLO：可用性≥ 99。95％（四半期）。

6.2支払い方法

SLI-Success：成功した（クライアント障害を除く）≥ 99。8％（28d）。
SLI-Latency：承認≤ 2秒間99％（日）。
SLO： Time-to-Wallet P95 ≤ 3ミリ（24時間）。

6.3データベース（PostgreSQL）

SLI-Lag：レプリケーションラグp95 ≤ 1 sec （day）。
SLIエラー：クエリーエラーレート≤ 0。05％（28d）。

SLOクラスタの可用性≥ 99。95%.

6.4キュー/ストリーミング（カフカ）

SLI-Lag：消費者遅延p95 ≤ Nメッセージ（時間）。
SLI耐久性-99エントリ≥確認します。99％（28d）。

SLO： ブローカーの可用性≥ 99。9%.

7）信頼性プロセスKPI

MTTD（検出する平均時間）

MTTA（……承認するには）

MTTR（……復元するには）

MTBF（……障害の間）

自動緩和によるインシデントの％

SLO/アラートカバレッジ（ターゲット≥ 95％）

canaryステージとのリリースのシェア

チーム/機能による誤った予算の消費

8） SLOを現実的に置く方法

1.現在のベースラインの信頼性を測定します（3〜4週間）。
2.「機密」ユーザーパス（ログイン、デポジット、ゲーム）を定義します。
3.各偏差（時間、お金、評判）のコストを考慮してください。
4.野心的で達成可能な目標（ベースラインで10〜30％の改善）を選択します。
5.四半期ごとにレビューします。

アンチパターン：

直ちに正当化することなく「5つのニーン」。
ユーザーに表示されないメトリック（例えば、UXとの通信なしのCPU）によるSLO。
SLO→フォーカススプレーが多すぎます。

9） SLOおよび予算報告

標準レポート（毎週/毎月）：

SLOごとの完了：実際のvsターゲット、トレンド、信頼。
エラー消費の概要：誰（リリース/インシデント）よりどれだけ予算が「燃やされているか」。
悪化のトップ5の原因、CAPA計画とタスクのステータス。
ビジネスへの影響：コンバージョン、ND、リテンション、LTV。

10）リリースポリシーとのコミュニケーション

エラー予算<50％→無料リリース。
50-80％→「慎重モード」：低リスク/カナリア計算のみ。

💡 80％→の解放の凍結、安定および負債の焦点。

11） SLA（契約）-アイテムテンプレート

可用性の義務：例えば、99。9％/月。
不可抗力：合理的な制御を超えたDDoS、第三者プロバイダー。
測定ウィンドウと責任領域：メトリクスのソース、計算方法。
クレジット/ペナルティ：レベルの表（例えば、60〜120分の利用不可→クレジットX％）。
エスカレーションと通知の手順：締め切り、チャンネル。
データとプライバシー：マスキング、ストレージ、リーガルホールド。
反復防止計画（CAPA）違反の場合。

💡 外部SLAは、特定の検証可能なSLIと計算方法を参照する必要があります。

12）測定ツール

パッシブメトリクス：Prometheus/Mimir/Thanos、輸出業者。
ログ：成功/エラーをビジネスレベルでカウントするためのLoki/ELK。
合成：cronによるアクティブサンプル（ログイン/デポジット/ゲーム）。
トレース：p99ボトルネックのためのテンポ/イェーガー。
支払い/ファイナンス：支払いSLIの根本的な真実の情報源。

13）クエリの例（テンプレート）

成功したAPIリクエストの割合（クライアントとしての4xxを除く）：

promql
1 - (
sum(rate(http_requests_total{status=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m]))
)

SLOカード：

yaml slo:
name: "API Availability"
window: "28d"
target: 0.999 sli: "1 - 5xx%"
owner: "Platform SRE"
alerting:
fast_burn: {window: "1h", factor: 14.4}
slow_burn: {window: "6h", factor: 6}

支払いの成功（ログ/ストリーム内のビジネスイベントの場合）：


success_rate = (count_over_time({app="payments"}     = "status=success"[5m]))
/ (count_over_time({app="payments"}     ~ "status=(success    fail)"[5m]))

key>フィルターを絞り込んで「顧客の減少」を除外します。

14） FinOpsおよび信頼性

9あたりのコスト：9を追加するコストは指数関数的に増加しています。
利益曲線：収益の増加/損失の減少が追加の「9」のコストを≥最適。
SLOポートフォリオ：異なるパスの異なるレベル（重要な支払いは「高価」、レポートは「安価」）。

15） SLO/アラート品質-チェックリスト

SLIは、UXおよびビジネスメトリクスと相関します。
ウィンドウと集計は一貫しています（ローリング28d/クォーター）。
マルチウィンドウアラート、フラッピングなし、ロールベースのルーティング。
ドキュメント：所有者、数式、ソース、runbook。
誤った予算とバーンインジケータを備えたSLOデモパネル。
定期的に目標を見直す（四半期ごと）。
主なシナリオの合成テスト。

16）実施計画（4つの繰り返し）

1.週1：ユーザーパスのインベントリ、SLIドラフト、基本的なダッシュボード。
2.第2週：SLO形式化、予算設定、アラート（高速/遅い書き込み）。
3.週3：インシデント/リリースプロセスとの統合、ルールの凍結。

4.週4+： 契約SLA、四半期ごとのレビュー、「9」 Finopsモデル

17）ミニFAQ

サービスごとに1つのSLOが必要ですか？
より良い2-3キーのもの（成功+レイテンシ）代わりに数十のセカンダリのものの。

予算が使い果たされた場合はどうなりますか？
凍結リリース、安定化とCAPAに焦点を当て、実験的な機能を削除します。

リリース速度と信頼性の間の競合を回避する方法は？
「予算に」リリースを計画し、カナリア計算とフィーチャーフラグを実装します。

［結果］

信頼性は、異なるメトリクスのセットによって制御されませんが、システムによって：SLI→SLO→予算エラー→バーンアラート→インシデントプロセス→CAPA→SLA。定義、データソース、レポートを標準化し、目標をユーザーエクスペリエンスと経済学にリンクさせ、実際のROIに基づいて定期的にnineをレビューします。

SLA、 SLO、信頼性KPI

MTTD（検出する平均時間）

MTTR（……復元するには）

自動緩和によるインシデントの％

canaryステージとのリリースのシェア

［結果］

お問い合わせ

迅速な連絡

動画はまもなく更新されます

現在、私たちはプロジェクトで非常に多忙です