インフラストラクチャKPIと稼働時間

なぜ必要なのか？

インフラKPIは、安定性に関する「感情」を測定可能な目標に変え、リスクと仕事の焦点を管理します。適切な指標は、技術的なSLIと業績（コンバージョン、Time-to-Wallet、 LTV）を結びつけ、イノベーションと信頼性の開発、負荷、共有の計画を立てることができます。

基本概念： SLI、 SLO、 SLA、エラー予算

SLI （Service Level Indicator）-測定された品質指標：成功した要求の割合、p95レイテンシ、間隔あたりの稼働時間。
SLO （Service Level Objective）-SLIターゲット（例："success ≥ 99。30日で9％"）。
SLA（契約）-ペナルティ/クレジットを含む外部の約束。常にSLOから派生しますが、SLOと同等ではありません。
エラー予算='1 − SLO'。これは、測定ウィンドウごとの最大許容故障率です。危険なリリースや実験についての決定を行うために使用されます。

例：

可用性SLO 99。30日で95％→エラー予算0。05% ≈ 21.カレンダーの月の「失敗」の6分。

4つのゴールド信号と追加

1.レイテンシー（p50/p90/p95/p99、テールは平均よりも重要です）。
2.エラー（5xx/タイムアウト/ビジネスエラー）。
3.トラフィック/スループット（RPS/QPS、 MBps）。
4.彩度（CPU/RAM/IO/FD/接続/GC/クォータ）。
追加：コールドスタート、キュー/バックログ、デプロイタイム、SLOコンプライアンス。

各種サービスのSLIモデル

HTTP/API

可用性： '（成功2xx/3xx −論理エラー）/（すべてのリクエスト）'

待ち時間：'p95'でクエリを成功させる。ホットルートのターゲット。
品質：「オーディエンス/スコープ」が正しいリクエストの割合（authZエラーなし）。

キュー/非同期

メッセージ処理時間： p95エンドツーエンド≤ N秒

Backlog：中央値<X、 tail p99 <Y。
配信エラー：≤ Z ppm。

DB/キャッシュ

操作レイテンシー：p95 get/put/commit。
彩度：接続プール使用率、キャッシュのヒット率。
エラー：タイムアウト、デッドロック、立ち退き嵐。

CDN/静的

ヒット率：ターゲットレベル≥；originのdegradation→loadの成長。
POPの可用性：Anycast、失敗は隣人によって償われます。

決済（業務用SLI）

Time-to-Wallet p95、入金/出力成功率％、PSP障害率。

可用性と稼働時間の計算

service availability='successful requests/all requests'（できれば'uptime minute'ではない）。
インフラストラクチャノードの代わりに'green time/window time'があります。
カレンダーウィンドウ：28-31日、スライディングウィンドウ：最後の30/90日。
作業時間/クリティカルウィンドウ：バックオフィスの場合は、スケジュールに従って稼働時間を考慮することができます（例：08：00-22：00現地時間）。

依存関係の構成（簡略化）：サービスAがBとCに依存している場合、独立した障害の場合：

'Availability （A） ≈ Av （B） × Av （C） × Av （A' B、 C）'-SLOを境界に置くことが重要です。

SLOキット例（サンプル）

ゲートウェイAPI： ≥ 99が利用可能です。95 ％/30d；p95レイテンシー≤ 120ミリ秒；エラー≤ 0。2%.

チェックアウト/支払い： 入金成功≥ 98。5 ％/30d；タイムツーウォレットP95 ≤ 90分；PSPタイムアウト≤ 0。3%.

データベース：p95読み取り≤ 10ミリ秒；p95書き込み≤ 25ms；レプリカラグP95 ≤ 150ミリ。
キャッシュ：ヒット率≥ 85％；eviction storms=0/30。

ペイアウト： p95処理≤ 5分；fraud-falls-positives ≤ 0。3%.

エラーの予算と変更管理

エラー予算がウィンドウの真ん中の前に50％+使い果たされている場合は、機能/リリースの「フリーズ」が導入され、安定化に焦点が当てられます。
予算がゆっくりと費やされている場合は、実験/カナリアをスピードアップすることができます。
予算の消費量を'release_id'経由で特定のリリース/インシデントに接続します。

アラート： 無駄に「夜に電話」しない方法

各メトリックではなく、SLOの劣化と重要な症状に対する警告。
マルチウィンドウ、マルチバーンレート：ショートウィンドウ（5-15分）+ロングウィンドウ（1-6 h）。
例：「5分で14 ×、 1時間で6 ×を燃やす」→通話ページ。
non-P1信号のための静かな時間；オーナーシップ・ルーティング。

ダッシュボードとビジュアリゼーションプラクティス

SLOパネル：サービスのコンプライアンス、残りの予算、依存関係マップ。
レイテンシーパネル：p50/p90/p95/p99、ルート/テナント/国/ASNによる分解。
エラーパネル：コード/理由、リリース/フィーチャーフラグとの相関。
容量パネル：CPU/RAM/IO/ネットワーク/FD/接続、傾向と予測。
ビジネスパネル：変換、ウォレットへの時間、預金/引き出し、保護の影響（WAF/アンチボット）。

インシデント、MTTR、死後

反応KPI：

MTTD（検出）、MTTA（受け入れて下さい）、MTTR/MTTC（回復/封じ込め）、時間通りにRCAのない％のインシデント。
Playbooks：誰がエスカレートするか、機能フラグ/ブロックを有効にする方法、リリースをロールバックする方法、ビジネスとのコミュニケーション。
死後（責任のない）：事実、タイムライン、根本原因（それら/プロセス）、アクション：即時/長期、回帰テスト、SLOへの影響。

パフォーマンス、彩度、劣化

ヘッドルーム：ターゲットリソースのヘッドルーム（例：CPU <70％ p95、 RAM <75％ p95）。
ホットパス：重要なルートのプロファイリング；'p99'は平均よりも重要です。
劣化モード：キャッシュのみ、読み取り専用、重要でないリクエストのドロップグラインド、「rate limit 「/quota。

数式と計算例

1）オンデマンドの可用性


availability = (total_requests - error_requests) / total_requests

ここで、'error_requests'=5xx+timeouts+businessエラー（設定可能）。

2）エラー予算（分）


error_budget_minutes = window_minutes (1 - SLO)

例：30日（43,200分）、SLO 99。95% → 21.6分。

3）燃焼率


burn_rate = observed_error_ratio / (1 - SLO)

SLO 99の場合。9％（予算0。1％）とエラー1％→burn_rate=10 ×。

4）複合可用性


A_total ≈ A_gw × A_auth × A_db × A_psp

小さな滝は全体的なAを打つ。

測定および例外ポリシー

スケジュールされていないウィンドウ（インシデント）-考慮されます。
計画されたメンテナンスウィンドウ-SLAがそのように規定されている場合にのみ考慮されます。SLOの場合、しばしば減算されない（または'planned_downtime'として別々にマークされる）。
合成と実際のユーザー：両方のチャンネル（RUM+合成チェック）を持つことは便利です。

アーティファクトの例

KQL/PromQL（アイデア）

5分でSLIエラー（5xx+タイムアウト）：

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

p95レイテンシのルート：

promql histogram_quantile(0. 95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, route))

燃焼率5m/1h：

promql
(
sum(rate(errors_total[5m])) / sum(rate(requests_total[5m]))
) / (1 - 0. 999)

SQL（決済業務SLI）

sql
SELECT date_trunc('minute', finished_at) AS ts,
100. 0 sum((status='SUCCESS')::int)::float / count() AS payment_success_pct,
percentile_cont(0. 95) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (finished_at - started_at))) AS ttw_p95_sec
FROM payments
WHERE finished_at > now() - interval '30 days'
GROUP BY 1 ORDER BY 1;

依存関係とカスケードの管理

チーム間のSLO契約：gateway↔auth↔wallet↔PSP。
劣化ポリシー：依存性が低下すると、サービスは「簡略化モード」に移行します。
フィーチャーフラグ：重要でない機能を無効にし、レイテンシテールを低減する「グレーリリース」。

キャパシティプランニングと予測

Shomes。RPS/MBpsは、トレンドやイベント（トーナメント、試合、プロモーション）によって予測します。
「ゴールデンパス」による負荷テスト、PSP/ペイアウトの個別テスト。
ピーク時の在庫：ターゲットファクター1。3 × -2。期待される負荷の0 ×。

SLO/KPI実装チェックリスト

1.重要なユーザーパスを特定し「、顧客の視点から」SLIを交渉します。
2.SLOターゲットとウィンドウを選択します（30/90日）。エラー予算を計算します。
3.ゲートウェイ/サービスにメトリックコレクションを構築し、コード/理由を正規化します。
4.バーンレートアラート（ショートウィンドウ+ロングウィンドウ）、ルーティング、およびオンコールを設定します。
5.SLOコンプライアンスを可視化し、リリース/フィーチャーフラグに関連付けます。
6.変更ポリシーと凍結プロセスに対する予算を作成します。
7.各過剰、回帰テストの回帰視点とRCA。
8.SLOを四半期ごとにレビューし、実際の予算の使用状況とビジネス目標を確認します。

よくある間違い

アプリケーションエラーを無視して「pingによるアップタイム」を測定します。
SLOは「in reserve」（99。999％）、しかし達成できず、何も解決しません。
ユーザーの症状ではなく、低レベルのメトリックに関するアラート。
依存関係マップがない→どこで燃えているのかはっきりしない。
SLOとリリースの間に接続はありません→誰が予算を「食べた」のかは明らかではありません。
p99 tails→good averageしかし、UX VIPユーザーを無視します。

iGaming/fintech固有の

スケジュールされたピーク：マッチ/イベント/プロモーション-事前に容量を増やし、キャッシュ/CDNをウォームアップし、特別な制限プロファイルを含める。
ビジネスSLI：タイムツーウォレット、入出金の成功、「ペイアウト速度」p95；ダッシュボードの根底にあります。
PSP/パートナー：プロバイダによる個別のSLO/ダッシュボード、自動ルートスイッチング。
Antibot/Anti-fraud：エラーの予算がないはずです。「正当なブロック」と「技術的なエラー」を分けます。
規制：ログストレージ、SLO/SLA計算の再現性、インシデントレポート。

よくあるご質問

SLOから計画された作業を差し引く必要がありますか？
通常はありません：SLOは、ユーザーが経験した経験を反映しています。SLAの例外を指定できます。

なぜP95、平均ではないのですか？
真ん中の1つは尾を覆います。UXは尾（p95/p99）を定義します。

製品全体に1つのSLOを使用できますか？
SLOツリーが必要です：クリティカルパス/コンポーネントによる製品と子による集計。

合計

強力なインフラストラクチャKPIシステムは、カスタムSLI、現実的なSLO、変更制御レバーとしてのエラー予算、スマートアラートとインシデント規律、およびRCAです。テクニカル指標をビジネスメトリクスに接続し、収集と可視化を自動化します。インフラストラクチャは予測可能になり、ピークシナリオでも稼働時間が制御されます。