過剰なアラートの防止

1）問題と目的

アラート疲労は、システムがあまりにも多くの無関係または実行可能な通知を送信するときに発生します。ボトムラインはページを無視し、MTTA/MTTRを成長させ、実際のインシデントをスキップすることです。
目標：SLOやPlaybookにリンクすることで、シグナルをまれで有意義で実行可能にすること。

2）シグナルタクソノミ（チャネル=結果）

ページ（P0/P1）-人を目覚めさせる。手動アクションが必要になり、runbookがある場合のみ。
チケット（P2）-時間/日の非同期作業。目覚めませんが、SLAによって追跡されます。
ダッシュ専用（P3）-アクティブなアクションなしの観察/トレンド。ノイズは発生しません。
Silent Sentry-バックグラウンド（RCA/post-mortems）のメトリック/監査。

3）「正しい」アラートの設計

• 客観的/仮説（私たちが保護するもの：SLO、セキュリティ、お金、コンプライアンス）。
• トリガー条件（しきい値、ウィンドウ、ソースクォーラム）。
• Runbook/Playbook（短いステップID+リンク）。
• オーナー（チーム/ロールグループ）。
• 完了基準（閉じるとき、自動解像度）。
• 脆弱性クラス（ユーザーインパクト/プラットフォーム/セキュリティ/コスト）。

4） SLO指向の監視

SLI/SLO→プライマリ・シグナル：可用性、レイテンシー、ビジネス・オペレーションの成功。

• ショート：1時間で予算の5％→ページ。
• ロング：6時間で予算の2％→チケット。
• コホート：地域/プロバイダー/VIPセグメント別アラート-偽グローバルアラームの数が少なくなります。

5）騒音低減技術

1.クォーラムプローブ：2つ≥独立したソース（異なるリージョン/プロバイダ）が問題を確認した場合にのみトリガーされます。
2.重複排除-集計キー：service+region+code。
3.ヒステリシス/デュレーション：スパイクをフィルタリングするための「レッドゾーン≥ N分」。
4.Rate-limit： Xアラート/時間/サービス以下。1ページ+要約を超えた場合。
5.自動スヌーズ/インテリジェント抑制：ルートが消去されるまで、Tウィンドウ→Ticketへの翻訳で繰り返しアラートが発生します。
6.イベント相関：数十の症状の代わりに1つの「マスターアラート」（例：マイクロサービスから5xxを詰め込む「DB unavailable」）。
7.メンテナンスウィンドウ：スケジュールされた作業により、予想される信号が自動的に抑制されます。
8.異常+ガードレール：異常-SLO信号による確認がない場合、チケットとしてのみ。

6）ルーティングと優先順位

優先順位：P0 （Page、 15 min updates）、 P1 （Page、 30 min）、 P2 （Ticket、 4-8 h）、 P3 （observation）。
ラベルによるルーティング：service/env/region/tenant→オンコールに対応。
時間のエスカレーション：5分→P2→Duty Manager/ICのackなし。
静かな時間：非クリティカルのための夜間；ページのP2/P3はできません。
疲労ポリシー：エンジニアが>Nページ/シフトを持っている場合-P2に再配布し、信号汚染をエスカレートします。

7）警報の質： 整理

実行可能性≥ 80％：ページの大部分はrunbookアクションにつながります。
False Positive ≤ 5％ for Pageシグナル。
Time-to-Fix-Alert ≤ 7日-不完全なアラートを修正/削除する必要があります。
Ownership 100％-各アラートには、その定義を持つ所有者とリポジトリがあります。

8）コードライフサイクルとしてのアラート

1.PR（目的説明、条件、ランブック、所有者、テストプラン）を作成します。
2.Sandbox/Shadow： shadow alertはchat/logに書き込みますが、ページは作成されません。
3.カナリア：制限されたオーディエンスオンコール、測定FP/TP。
4.Prod：レート制限+観察2-4週間を含める。
5.毎週のレビュー：品質指標、編集/出金。
6.非推奨：信号がより高いものを複製するか、実行できない場合。

9）成熟度の指標（ダッシュボードで表示）

MTTA/MTTR （MTTR/MTTR/MTTR）

通話時間あたりのアラート（中央値/95パーセンタイル）。
％actionable（完了したステップがあります）および偽陽性の率。
トップトーカー（≥ 20％のノイズを生成するサービス/ルール）。
アラートを修正する平均時間。
バーンレートのカバレッジ：2つのウィンドウでSLOアラートを使用したサービスの共有。

10）チェックリスト「アラートの衛生」

• アラートはSLO/SLIまたはビジネス/セキュリティに関連付けられています。
• ランブックと所有者があります。接触および戦争部屋チャネルは指定されます。
• 2つのウィンドウ（短い/長い）とソースのクォーラムが設定されています。
• Dedup、 rate-limit、 auto-resolve、およびauto-snoozeが含まれています。
• Windowsのメンテナンスと抑制は、リリース/移行に指定されています。
• 影/カナリアが渡されました；測定されたFP/TP。
• アラート品質指標レポートが含まれています。

11）ミニテンプレート

アラート仕様（YAMLアイデア）

yaml id: payments-slo-burn severity: P1 owner: team-payments@sre purpose: "Защитить SLO успеха платежей"
signal:
type: burn_rate sli: payment_success_ratio windows:
short: {duration: 1h, threshold: 5%}
long: {duration: 6h, threshold: 2%}
confirmations:
quorum:
- synthetic_probe: eu,us
- rum: conversion_funnel routing:
page: oncall-payments escalate_after: 5m controls:
dedup_key: "service=payments,region={{region}}"
rate_limit: "1/10m"
auto_snooze_after: "3 pages/1h"
runbook: "rb://payments/slo-burn"
maintenance:
suppress_when: [ "release:payments", "db_migration" ]

標準更新テキスト（ノイズを低減するため）

Импакт: падение success_ratio платежей в EU (-3.2% к SLO, 20 мин).
Диагностика: подтвержден кворумом (EU+US синтетика), RUM — рост отказов на 2 шаге.
Действия: переключили 30% трафика на PSP-B, включили degrade-UX, след. апдейт 20:30.

12）プロセス： 毎週「アラートレビュー」

1.トップトーカー→編集/削除。

2.ページ信号のFP/TP→しきい値/windows/quorumを調整します。

3.ダウングレード（ページ→チケット）およびその逆の申請者。

4.Time-to-Fix-Alertステータス-遅延はサービス所有者にエスカレートされます。

5.SLOアラートとランブックの存在によるカバレッジのチェック。

13）リリースおよび運用へのリンク

アノテーションをリリースすると、一時停止が自動的に追加されます。
ウィンドウを変更する：リリース後の最初の30分間-SLO信号のみ。
Playbookには、ルートに集中するための「lower/suppress non-key alert」ステップが含まれています。

14）安全性とコンプライアンス

セキュリティ信号（ハッキング/漏洩/異常アクセス）-静かな時間なしで、別々のチャネル。
すべての抑制/静かなウィンドウの監査ログ：誰、いつ、なぜ、締め切り。
重要なアラート（イベント署名）の不変性の要件。

15）アンチパターン

「すべてのグラフ=アラート」→雪崩。
売上のしきい値「！=0エラー」。
1つの探査機/1つの領域が真実の源です。
runbook/ownerのないページ。
無期の永続的な「一時的な抑圧」。
「後で修正」不具合のアラート-何年も蓄積します。
リリースノイズと生産インシデントの混合。

16）導入ロードマップ（4〜6週間）

1.インベントリ：すべてのアラートをアンロードし、所有者とチャンネルを配置します。
2.SLOカーネル：重要なサービスのためのダブルウィンドウでバーンレートのルールを導入します。
3.ノイズコントロール：クォーラム、デッドアップ、レート制限を有効にし、毎週のレビューを開始します。
4.Runbookカバレッジ：Playbookでページ信号の100％を閉じます。
5.Fatigポリシー：ページ制限/シフト、Quiet Hours、ロード再配布。
6.自動化：Alert-as-Code、 Shadow/Canary、品質指標に関するレポート。

17）ボトムライン

沈黙は監視の欠如ではなく、SLOとプロセスに関連する十分に設計された信号です。クォーラム、ダブルウィンドウ、デッドアップ、および厳格なルーティングにより、アラートはまれで正確かつ実行可能になります。チームは眠っている、ユーザーは満足している、事件は制御されています。