アラームと通知システム

1）役割と目標

信号システムは「メッセージの送信」ではなく、意思決定回路です。時間のずれを強調し、アクションを提供し、タイムリーさと沈黙のバランスを維持します。

• 優先順位付けとクリアなプレイブックにより、MTTD/MTTRを削減します。
• ノイズキャンセルによるアラート疲労の軽減。
• 通知から直接アクションを与える（ack、スヌーズ、runbook、自動アクション）。
• プライバシーと同意を守る（オプトイン/オプトアウト、ログストレージ）。

2）イベントとレベルの分類

2.1イベントタイプ

メトリクス/異常（SRE、製品、金融）。
ビジネスルール（制限、詐欺、KYC、支払い）。
システム（展開、劣化、ライセンス）。
ユーザー（行動トリガー、RG/責任ゲーム）。

2.2重大度レベル

重要-即時応答、損失/安全のリスク。
KPI/SLOの大幅な劣化。
ミディアム-営業時間中に必要なアクション。
Low/Info-オブザベーション/コンテキスト、ダイジェストへの自動畳み込み。

2.3優先度

「Impact × Urgency」マトリックス→P1..P4。チャンネルとSLA反応にリンクします。

3）アーキテクチャとスレッド

シグナルの生産者→イベントのシーナ→ノーマライゼーション（enrich、 dedup）→相関→修正（policy engine）→ルーティング→カナラ納品→環境設定の中心→ログ/分析。

• Enricher：テナント、役割、地域、プレイブックリンクを追加します。
• Deduper-Groupの繰り返しイベントをキーで指定します。
• Correlator：インシデントに関連する信号を接着します。
• ポリシーエンジン：YAML/DSLルール、静かな時間、エスカレーション。
• 配信：アプリ内、電子メール、プッシュ、SMS、 webhook、チャット統合。

4）ルールとポリシー（YAML例）

yaml policies:
- id: p_sre_critical match: { domain: "infra", severity: "critical" }
route:
primary: { channel: "pager", targets: ["oncall_sre"] }
fallback: { channel: "sms", delay: "2m" }
suppress:
flapping: {window: "10m," threshold: 5} # suppressing frequent twitching duplicates: {key: ["service, ""cluster,"" error _ code"], ttl: "15m"}
escalate:
after: "10m"
to: ["sre_manager"]
auto_assign: true
- id: p_product_medium match: { domain: "product", severity: "medium", kpi: "conversion" }
route:
primary: { channel: "inapp", audience: "product_owners" }
digest:
window: "1h"
max_items: 10 quiet_hours:
tz: "Europe/Kyiv"
ranges: ["22: 00-07: 00"] # only P1 digests/pager at this time

5）重複排除、相関、フラッピングの抑制

Dedup： group ID 'dedup_key=hash （service' metric 'dim）'；TTL ≥フラッピングウィンドウ。
相関：関連する信号をトポロジ（servis→zavisimost）、時間（± N分）、コンテキスト（release、 incident）で結合します。
フラップ：ヒステリシスを上げるか抑制する提案との「M分あたりのN事象」→1つの信号「検出されたフラップ」をしきい値にします。

6）ルーティングおよびRACI

責任：誰が最初の通知/ドラッグを取得します。
説明責任：誰がSLAの後にエスカレートします。
相談：スレッド/チャットチャンネルで言及する人。
通知：誰がダイジェスト/結果を残します。
役割とコンテキスト（テナント、地域、製品ストリーム）で割り当てます。

7）配達チャネルおよびニュアンス

レトライ：5xx/429/タイムアウト→バックオフ+ジッタ；「再試行後」の尊敬。Idempotence： Webhookの'X-Notification-Id'。

8）環境設定センター

イベントタイプ、レベル、チャンネル別にオプトイン/オプトアウト。
静かな時間、15/30/60分のための手動スヌーズ。
しきい値/感度（例≥ 3 σ異常）。
言語/ロケール、時間/通貨形式。
ロールバインディング：SRE/Product/Financeのプリセット。
透明性：ユーザーが信号を受け取った理由を示します（ルールへのリンク）。

9）コンテンツ設計： メッセージ構造

• Title： Brief、 with trigger： 「［P1］ ［PSP_TR］ 3DS障害の急増（+12％）」。
• コンテキスト：期間、影響を受けるセグメント/リージョン、データソース。
• 理由/仮説：「PSP_X 18：20 UTCのリリースに関連しています。」
• SLA/締め切り： 「10分でエスカレーション」
• CTA："プレイブックを開く"、"フォールバックを有効にするPSP_Y、" Ack （30分）"。
• リンク：グラフ、インシデントスレッド、メトリック、runbook。
• メタデータ：'trace_id'、 'incident_id'、 'dedup_key'。

トーン：事実、ドラマ化はありません。数字と単位はデコードなしで略語を避けます。
ローカライズ：変数→プレースホルダ、翻訳はリソースに格納されます。numbers/dates-ロケール別。

10）通知からのアクション（実行可能）

時間パラメータを持つAck/Snooze。
インシデントスレッドに割り当て/招待します。
Runbook-Openコンテキストオートコンプリートによるソリューションステップ。
ワンクリック修復（安全な場所）：ルートの切り替え、上限の引き上げ、ジョブの再起動（確認と監査）。
自動補完フィールドでチケット（Jira/GitHub）を作成します。

11）信号品質： メトリックとターゲット

精密 のための80％を します。
リコール（すべてのインシデントの中で検出されたインシデントの割合）≥ 70％です。
騒音：ユーザー（ターゲット天井）ごとの平均信号/時間。
Ack時間p50/p95、エスカレーションレート、スヌーズレート（ノイズ指標として）。
MTTD/MTTA/MTTR（ドメインおよびチャネルの点で）。
Silenced-but-should-alert（ルールによるギャップ）は別のダッシュボードです。

12）騒音制御： 技術

ヒステリシスとしきい値のためのスライドウィンドウ。
検出前のアンチエイリアシング（EWMA）。
集計：30の小さなものの代わりに、トップの貢献者と1つのバッチ/ダイジェスト。
コンテキスト制限：最大N通知/時間/チャネル/ユーザー。
自動フィードバック：ユーザーがスヌーズを3 ×連続でクリックした場合→しきい値を上げる/チャンネルを変更することを提案します。

13）セキュリティ、プライバシー、コンプライアンス

WebhookのためのHMAC署名、秘密の回転、'X-Key-Id'。
RBAC/ABAC：ロール/テナントによる信号の可視性。
PIIの最小化、ログのマスク、監査アクション（ack/assign/runbook）。
通知の同意と理由（ルール/ポリシー）-ペイロードで。
保持/TTL通知ログ、インシデントの法的保持。

14）スキームとペイロード

イベント（内部）

json
{
"id": "sig_01HX",
"domain": "payments",
"severity": "high",
"priority": "P2",
"title": "The 3DS failure graph has grown to 8. 2% (+3. 1 pp), "
"occurred_at": "2025-11-03T17:55:00Z",
"context": { "psp": "PSP_X", "country": "TR", "release_id": "rel_241103_1820" },
"metrics": { "baseline": 5. 1, "current": 8. 2, "delta_pp": 3. 1 },
"dedup_key": "payments    PSP_X    TR    3DS_FAILURE",
"runbook": "rbk_psp_3ds_spike",
"slo": { "ack_deadline_sec": 600 }
}

お知らせ（不可知性チャンネル）

json
{
"notification_id": "ntf_91ab",
"signal_id": "sig_01HX",
"targets": ["oncall_payments"],
"channels": ["inapp","slack","webhook"],
"cta": [
{"id": "ack," "label": "Confirm (30 min)," "payload": {"ttl ":" 30m"}},
{"id": "runbook," "label": "Open playbook," "payload": {"id ": "rbk _ psp _ 3ds _ spike"}},
{"id": "fallback," "label": "Enable fallback, PSP_Y" "confirm": true}
],
"hmac": "sha256=AbCd..."
}

15）プロダクトのUXパターン

受信ボックス：クリティカル/ハイ/その他のタブ、数量バッジ。
インシデントフィード：相関シグナル、アクションのタイムライン、「何が行われたのか」。
フィルタ：ロール、ドメイン、地域、時間、「未回答のみ」。
リスト内のクイックアクション（ack/snooze/assign）。
説明：「なぜそれを見るのか」（ルール、しきい値、データ）。
ダイジェスト：朝/夕方、TZでローカライズ。

16）テストプラン

ユニット：dedupキー、ヒステリシス、フラッピング、ペイロードのシリアル化。
統合：ルーティング、静かな時間、エスカレーション、チャンネルのリトレイ。
E2E： シナリオP 1の異常からチケット閉鎖まで。静かな時間のP2→ダイジェスト。
混乱：リンクの損失（SMTP/SMS）、遅れ、信号の雪崩、時計スキュー。
A11y/i18n：スクリーンリーダー、キーボードのack/snooze、数字/日付のローカライズ。

17）品質のダッシュボード

ドメイン別の精度/リコール。
Ackの時間p50/p95および時機を得た確認されるの共有。
ユーザー/時間ごとのノイズとトップノイズのルール。
エスカレーション率と「偽エスカレーション」。
Suppressed vs Delivered（どれだけ抑制/消化されるか）。
ユーザーからのフィードバック：/messages、ノイズに関するコメント。

18）チェックリスト

デザイン・デザイン

• イベント分類とレベルは一貫している
• 静かな時間/エスカレーションポリシーについて説明します
• Dedup/Correlation/Flapping構成
• チャンネル、レトラ、Webhook Idempotency
• プリファレンスセンター（オプトイン/アウト、スヌーズ）
• コンテンツテンプレートとローカライズ
• プレイブックとワンクリックアクション（監査済み）
• 品質指標とダッシュボード

操作

• しきい値の最適化四半期
• A/Bルール（しきい値、ウィンドウ、ダイジェスト）
• 通常の「トップノイズ」とCAPAレビュー
• チャンネル秘密回転（HMAC、 SMTP、 SMS）
• 予定されているゲームデーテスト

19）実施計画（3つの繰り返し）

反復1-ベースライン（2〜3週間）

分類、重大度/優先度、プリファレンスセンター（アプリ内+メール）。
Dedup、簡単なキー/時間の相関、静かな時間。
メッセージテンプレート、プレイブック、ack/snooze/assign。

反復2-信頼性とノイズ低減（3〜4週間）

フラップ/ヒステリシス、ダイジェスト、チャット統合、およびWebhook （HMAC、リトレイ）。
SLAによるエスカレーション、品質ダッシュボード（精度/リコール、ノイズ）。
ワンクリック修正（確認と監査）。

イテレーション3-最適化とスケール（連続）

トポロジー/リリース、しきい値の自動提案による相関。
A/Bルールは、「しきい値が機能するとき」を予測します。
ノイズレビューと通常のゲーム日。

20） ミニFAQ

アラート疲労に対処する方法は？
Dedup、相関、ヒステリシス、ダイジェストおよびプリファレンスセンター+通常のノイズとA/B閾値レビュー。

MLは異常に必要ですか？
有用ですが、決定論的なルールと説明可能なしきい値から始めます。MLはアドオンのようなもので、常にExplainを使っています。

なぜユーザーは「余分な」メールを受け取るのですか？
ルールの一致、静かな時間、「なぜ配信」監査、チャンネル/時間制限の設定、ダイジェストをチェックします。

合計

強力な信号システムは、スマートフィルタリングと正しい優先順位付け+ワンクリックアクションです。分類とポリシーを形式化し、dedup/correlation/hysteresisを実装し、ユーザーに制御（好み、スヌーズ）を与え、信頼性の高い配信と透明性を提供する。"信号はノイズ源ではなく制御ツールになります。