運用ダッシュボード
（事業・管理）
1）目的と原則
運用ダッシュボードは、プラットフォームの健全性を監視し、行動を起こすための「単一のウィンドウ」です。ユーザーロール（SRE、製品、財務、コンプライアンス、サポート、パートナー）のコンテキストにおけるメトリクス、イベント、アラート、およびビジネスキーの数値を集計します。
原則：- デザインによって実行可能：各ウィジェットにはアクションボタン（ロールバック、パウズ、再実行、再ルーティング）があります。
- Role-aware：詳細の権利とレベルは、役割/テナント/地域によって異なります。
- 真実のソース：数字は請求/ログ/請求書に収束します。
- ほぼリアルタイム+歴史性：インシデントの秒/分、トレンドの月/年。
- 説明：任意の集計が'trace_id'でrawイベントに展開されます。
2）役割とスクリプト（誰が来て、なぜ）
SRE/プラットフォーム：可用性、p50/p95/p99レイテンシ、エラー/リトレイ、容量、1kイベントあたりのコスト。
プロダクト/操作：E2E-Success率、転換、パートナーのonboarding時間、phicheflags。
Finance/FinOps：単位あたりの収益/COGS/CM、出力/入力、予算とキャップ、偏差。
コンプライアンス/セキュリティ：領収書/署名、PII要求、SoD違反、再認証状態。
サポート/CS：パートナーおよび地域によるチケットキュー、MTTA/MTTR、 SLA。
パートナー/テナント：独自のSLOメトリクス、Webhookのステータス、使用状況、クォータ。
3）ノーススターとキーSLI/SLO
North Star：各地域のターゲットp95の重要なルートでの成功率をE2Eします。
SLI（例）：- チャネル/地域ごとの可用性。
- p50/p95/p99レイテンシ。
- エラー率とレトレイの割合。
- Webhook配信成功率（レシート付き％）。
- 1kイベントと1ユニットあたりの出力/入力のコスト。
- インシデントの概要：MTTA、 MTTR、 error-budget burn。
- 空室状況≥ 99。95 ％/region/channel。
- p95 ≤ 120 ms（ショーケース）、≤ 250 ms（チェックアウト/見積もり）。
- Webhookの成功≥ 99。5分で5％。ウィンドウを開きます。
- クォートとチェックアウトの間のΔ=0（割り当てルールに従って1つのマイナーユニットを±）。
- P1 ≤ 10分、MTTR ≤ 60分の反応時間。
4）ダッシュボードデータアーキテクチャ
イベントバス：テレメトリー（トレース/メトリック/ログ）、ビジネスイベント、請求、コンプライアンス。
ストリーミング/集計：ほぼリアルタイムのためのT+5s/T+1mの窓；保証された配達のためのCDC/outbox。
ストレージ：時系列（RAM）、 OLAP（長い履歴）、WORMログ（監査）。
セマンティックレイヤー：メトリックの辞書、単位、地域とテナントによる正規化。
原料へのリンク：'trace_id'/'event_id'へのドリルダウンと署名（receipt_hash)。
5）インターフェイスおよびウィジェットの設計
グローバルヘッダー：フィルタ（時間、地域、テナント、製品、環境）、ステータスインジケータ。
タイル（KPI）： E2E成功、可用性、P95、エラー率、コスト/1k、出力。
チャート：スパークラインの傾向、地域別のヒートマップ、パーセンタイルチャート。
表：トップミス、劣化したパートナー、クォータを超えた場合、未接続事件。
アクションセクション：「プロモーションを一時停止する」「、ロールバック機能」「、クォータを上げる」「、配信を再開する」。
Context-help：メトリック/テクニックとSLOとのコミュニケーションに関するヒント。
6）ダッシュボードモジュール（推奨セット）
1.プラットフォームの健全性：可用性/遅延/エラー、バーンダウンエラーバジェット。
2.パートナー統合：Webhookステータス、領収書、idempotent takes、 lagキュー。
3.チェックアウトと価格：vitrina↔checkoutコンプライアンス、'fx_version'、 'tax_rule_version'、失敗事例。
4.Content/Directories：パブリッシュ時間、キャッシュ/無効化エラー、鮮度。
5.RTPと制限（該当する場合）：theor。観察されたRTP、限界の作動、露出。
6.FinOps： COGS/unit、 egress/ingress、 compute/storage、 budgets/cap-alerts。
7.セキュリティ/コンプライアンス：SoD、 JIT、 MFA、署名された操作、PII要求、およびログ。
8.サポート：キュー、MTTA/MTTR、理由、自動ランブック。
9.リリース/フィーチャーフラグ：リリースステータス、カナリア領域、インシデントとの自動接着回帰。
10.実験：A/Bガードレール、SLI/ROIへの機能の影響。
7）アラート、ルーン、エスカレーション
ノイズキャンセルと'trace_id'重複除外によるP1-P3アラートのレベル。
自動ランブック：トリガーされたとき-チェック/修正の開始（キャッシュのクリア、ルーティングの切り替え、プロモーションの一時停止）。
エスカレーション：マトリックス24 × 7、応答SLO、チャンネル（チャット/音声/SMS）、「赤いボタン」。
事後：因果レポートテンプレートとアクションアイテム。
8）複数の地域性および複数のテナント
スライス：地域/テナント/チャネル/プロバイダ、独立したSLOおよび予算。
信頼性ゾーン：PIIデータ/ファイナンス-それぞれの領域にのみ表示され、残りは集計されます。
コスト意識：同じp95で価格でルートを比較します。最適化の推奨事項。
9）セキュリティとプライバシー
RBAC/ABAC：役割による可視性とアクション；プロダクト/テナントの所有権のためのReBAC。
署名と領収書：財務/重要なイベント-ハッシュとDSSE領収書。
PII衛生：トークン化、マスキング、承認されたジャブを介したアクセスのみ。
監査：設定/ロール/制限変更、再現性のためのWORMログ。
10）メトリックデータモデル（例）
'metric' '{name、 unit、 type： counter/gauge/hist、 owner、 sla_ref}'
'dim' '{region、 tenant、 product、 provider、 version、 environment}'
'point' '{metric、 value、 ts、 dims{}、trace_id、 signature？}'
'event' '{type、 severity、 subject_id、 payload_hash、 receipt_hash、 ts}'
'slo' '{name、 target、 window、 burn_rate、 owners［］、runbook_url}'
'alert' '{slo_ref、 condition、 status、 ack_by、 acknowledged_at、 runbook_step}'
11） ダッシュボードAPI/webhooks
'POST/ingest/metrics'-受信メトリック（スキーム、制限、認証）。
'POST/ingest/events'-ビジネスイベント（バージョン/署名）。
'GET/kpis？フィルタ……'-ウィジェットの集計。
'GET/traces/{ trace_id}'-ディーププロモーション。
Вебхуки： 'IncidentRaised'、 'QuotaCapReaced'、 'PriceMismatch'、 'WebhookDeliveryLag'、 'SecuritySoDViolation'。
12）データ品質とテスト
データ契約：受信時のスキームと検証、バージョン管理（'expand→migrate→contract'）。
異常：省略/ジャンプの監視、しきい値「フラットライン「/」ノイズ」。
サンプリング：高QPSメトリクスのために-スライド、表現性を維持しながら。
Backfill：セキュアバージョンタグ付きのバックロード。
13）ダッシュボード自体のメトリック（メトリックのメトリック）
UI/APIの可用性≥ 99。9%.
レイテンシp95 APIリクエスト≤ 300 ms。
「完全性」（Completeness）-ウィンドウにデータを送信したソースの割合≥ 99です。5%.
鮮度：インクリメンタルアップデートは30秒≤遅延します。
Correctness： 参照レポートとの不一致≤ 0。1%.
14）ダッシュボードの経済とFinOps
1kイベントあたりのコストは、プロバイダ/地域によって分解されます。
出力/入力ヒートマップ、キャッシュ/ルーティングの推奨事項。
予算/キャップアラート：80/90/100％、自動取引および優先順位付け。
15）可用性とUX
夜のテーマ、短いキャプション、ステータスアイコン。
キーボードナビゲーションとa11y：コントラスト、alt、 ariaタグ。
保存されたプリセット：「SRE duty」、 「finance」、 「partner」。
スナップショットと共有：フィルターとリンク/エクスポートで状態をキャプチャします。
16）リスクとアンチパターン
Dash-sprawl：メトリクスの1つの辞書なしで20種類のダッシュボード。
虚栄心のメトリクス：SLO/アクションに接続しない美しいグラフ。
数値の不一致：レポート≠請求/監査。
騒々しいアラート：疲労とP1脱落。
ドリルダウンがない：プライマリと原因に到達することは不可能です。
17）実装チェックリスト
- 役割とスクリプトを定義する。North StarとSLI/SLOに同意します。
- メトリックと単位の辞書を作成する。データ契約を正式化します。
- ingest （metrics/events/traces）、 OLAP、 WORM監査を構成します。
- キーモジュール（健康、パートナー、チェックアウト、FinOps、セキュリティ）を実装します。
- ルーンとエスカレーションによるアラートを含める。「赤いボタン」。
- rollback/pause/re-route/raise-limitアクションを追加します。
- 地域/テナント別にヒートマップを作成する。フィルターおよびプリセット。
- 請求/請求書で発信桁を確認します。
- ゲームデー（GameDay）：プロバイダの切断、レトラの雪崩、価格の非同期。
- 毎週のSLOレビューと死後の品質。
18） RACI
19） FAQ
すべてのレポートをダッシュボードに置き換えることはできますか？
いいえ、そうではありません。ダッシュボード-RAMとアクションのための；正式なレポート/監査-個々のアーティファクト。
どのくらいの「リアルタイム」が必要ですか？
インシデントの場合-秒/分、経済学の場合-分/時；一貫性は、絶対的な「オンライン」ではなく、重要です。
アラートのノイズに対処するには？
SLO指向の条件、集計、'trace_id'による重複除外、優先順位付けおよび自動ランブック。
メトリックの正確さを確認するには？
リファレンスレポート、テストフィード、コントロールサンプル、WORMログとの定期的な調整。
概要：運用ダッシュボードは「美しいボード」ではなく、管理ツールです。単一のSLI/SLO、インターフェイスからのアクション、原材料へのトレース、請求および監査との厳密な一貫性。イベントアーキテクチャ上に構築し、役割ごとにコンテキストを与え、ルーンとエスカレーションを追加し、予測可能な操作、迅速な意思決定、持続可能な成長を得ることができます。