背景
こちらの記事を書いている中で、
「アラートのチューニングの思想も書いておいた方が良いな」
って思ったので、今回の記事を書きました。
なぜ最初から厳密なルールではダメなのか？
最初から厳密すぎるルールを設定すると、多くの問題が発生します。
ノイズの洪水
システムの正常な変動（一時的な負荷上昇など）を異常として検知してしまい、対応不要なアラートが大量発生します。こういたのを偽陽性と呼びます。
アラート疲れとインシデントの見逃し
アラートが頻繁に鳴ることで、担当者はアラート自体を無視するようになります。
その結果、本当に対応が必要な重大なインシデント（本物の脅威）が発生した際に、ノイズに埋もれて見逃してしまうリスクが劇的に高まります。
これは障害児の爆発半径拡大に広がります。
比喩 -上司からのマイクロマネジメント-
最初からルールがちがちでも、素早くデリバリーとかできないのは、皆さん仕事してても想像つきますよね？
口うるさい上司による、マイクロマネジメント。
あれがまさに、このアナロジーです。
何度も何度も口うるさく注意されてるとね、重大なリスクが何なのかわからんのですよ。
推奨されるアプローチ：段階的なチューニング
ステップ1：ブロードなルールから始める
まずは「明らかに問題である」というシンプルな条件（例：サービスが完全に停止している、エラー率が一定時間高く張り付いている）から始めましょう。
ステップ2：観測と分析（チューニング期間）
アラートが発報された際に、
「このアラートは本当に対処が必要だったか？」
「対処が不要だったとしたら、どのような条件を追加すればノイズを除去できるか？」
を分析します。
シャドウイング
新しいルールは、最初は通知を送らずにログだけに出力する「シャドウモード」で運用し、
どれくらいの頻度で発報するかを観測するのも有効な手法です。
ステップ3：ルールの精緻化
分析結果に基づき、ルールをより賢くします。
例えば、「CPU使用率が90%を超えた」という単純なルールから、
「CPU使用率が90%を超え、かつ、P99レイテンシーがSLAの閾値を超えた場合にのみ通知する」
のように、ユーザー影響に基づいた条件を追加していきます。
ここまでのまとめ
アラートの理想は、
発報されたら必ず対応が必要
な状態です。
最初から完璧を目指すのではなく、運用しながら継続的に段階的にルールを改善していくアプローチを取りましょう。
アジャイルアラートな組織
とでも言いましょうか。
それが何よりも、
アラートの信頼性を維持し、チームのアラート疲れを防ぎ、重大なインシデントの見逃しリスクを最小限に抑える
ための最も合理的な戦略です。
RDRAを使ったアラートの仕組みづくり
過去に入ってた案件でのアラートシステムの要件をざっくり触れる際に、
物は試しにRDRAに近いフレームワークUAFを使ってみたんですが、
めちゃくちゃ共通認識が合わせやすかったので、そこまで大きくない規模感なら、
RDRAで十分でしょう。
RDRAの持つトレーサビリティは、アラート設計の「なぜ、このアラートが必要なのか？」を明確にする上で強力な武器になります。
RDRAとアラート設計の相性
RDRAのフレームワークはアラート設計・運用と非常に相性が良いです。
特にいいなと思うのは、バリエーションの追加の部分ですね。
上記で触れたように、継続的にルールを追加したり、削除するなどのチューニングの際に、
RDRAのバリエーション列に付け加えたり、それによる修正すべき影響範囲の分析も行いやすいし。
R (Requirement: 要求モデル) とアラートの目的
RDRAでは、要求の背景や目的を明確にします。
これをアラート設計に適用すると、
「このアラートが鳴ることは、どのビジネス要求やSLA/SLOに対する違反なのか？」
に簡単に紐付けられます。
これにより、ビジネスインパクトのない不要なアラート（アラート疲れの原因）を排除しやすくなります。
D (Domain: ドメインモデル) と監視対象
ドメインモデルで定義されたエンティティやプロセスは、監視すべき対象そのものです。
R (Realization: 実現モデル) とアラートルール
「要求Rを実現するためには、ドメインDのこの状態を監視する必要がある」
というロジックから、具体的なアラートルール（実現手段）を導き出せます。
このトレーサビリティがあることにより、アラートの棚卸しや見直しが非常にやりやすくなります。
「このアラートに対応する要求はもう存在しないから、このアラートはもう削除しよう」
といった判断が論理的に行えます。
では、以下でRDRAを使った具体的なアイデアをちょっと触れてみましょう。
SLO駆動型アラート設計フレームワーク
重要なのは、
「アラートを技術的な事象ではなく、ビジネス要件の違反として扱う」
ことです。
これにより、アラート疲れの原因となる「対応不要なノイズ」を根本から排除します。
アラートの品質が低い最大の原因は、
アラートが鳴っても、ビジネス上どのような影響があるのか不明で、具体的な対応が取れない
ことです。RDRAを使い、全てのアラートをビジネス要件（特にSLO）に紐付けます。
1. R (要求モデル) でアラートの存在理由を定義する
まず、アラートの根拠となるビジネス要件を定義します。
SREのプラクティスであるSLO（Service Level Objective） を要求モデルの中心に据えます。
要求の例
REQ-01：決済サービスは、月間可用性99.95%を達成すること。
REQ-02：商品検索APIのP99レイテンシーは、200ミリ秒未満であること。
REQ-03：ユーザー登録プロセスは、99.9%の確率で成功すること。
アラート品質への効果
ノイズの排除
SLO（要求）に違反しないアラートは、原則としてPagerDutyで担当者を呼び出さない
というルールを設けます。
CPU使用率が一時的に高くても、レイテンシーSLOに影響がなければ、それはノイズと判断できます。
優先度付け
アラートの重要度は、紐付いている要求の重要度とSLOのエラーバジェット消費速度によって自動的に決定されます。
2. D (ドメインモデル) でアラートの内容を明確化する
アラートメッセージが技術的な内部用語で記述されていると、対応者はそれが何を意味するのか理解しにくいです。
そこで、ドメインモデルで定義されたユビキタス言語 をアラートに組み込みましょう。
ココが個人的にも非常に重要でして、ユビキタス言語を用いることで、
あとあと、開発者自身がアラートを見て、設計を改善したりしていけるようにするには、言葉の変換のコストを下げておく必要があるからです。
ドメイン定義
・エンティティ：顧客、注文、決済トランザクション
・ビジネスプロセス：商品検索フロー、決済プロセス
アラート品質への効果
・悪い例
Service 'prod-checkout-svc-pod-xyz' high latency.
・良い例 (RDRA適用後)
[P1 Alert] 決済プロセス (ドメイン) のレイテンシーがSLO (要求) に違反しました。
影響範囲：全ての顧客。
・状況認識の迅速化
アラート受信者は、技術的な詳細を掘り下げる前に、ビジネス上のインパクトを即座に理解できます。
3. R (実現モデル) でアラートのアクションを保証する
アラートを要求に紐付けることで、「対応不要なアラート」をなくすだけでなく、
「対応方法が不明なアラート」も撲滅します。
実現方法
アラートルールは、必ず要求モデルのIDと紐付けて管理しましょう。
アラートルールには、対応手順書（Runbook）へのリンクを必須項目とします。
Runbookが定義できないアラートは作成を許可しないようにします。
アラート品質への効果
実行可能性の保証
全てのアラートが具体的なアクション（Runbook）を持つことになります。
トレーサビリティ
「このアラートルールは、どの要求のために存在するのか？」が常に明確であり、
その要求が変更・廃止された際に、関連するアラートルールも見直し対象となります。
ECRS原則を使ったアラート業務改善
是非、上記のRDRAをパクったアラート設計と組み合わせてぜひ使ってほしいのが、もう１つあります。
それが私が日常的に使っている、ECRS原則です。
ECRS原則は、アラート業務の改善、特にアラート疲れの解消や運用負荷の軽減において、
非常に強力で体系的なフレームワークとして応用できます。
ECRSは元々、製造業の工程改善で使われる手法ですが、「ムダをなくし、効率化する」という点で、アラート運用にもそのまま適用可能です。
アラート業務における「ムダ」とは、
対応不要なアラート（ノイズ）
対応に時間のかかる非効率なプロセス
を指します。
1. Eliminate（排除）: 不要なアラートをなくす
これがやっぱり、最も効果的な改善策です。
「そもそも、このアラートは本当に必要か？」を問います。
SLOに基づかないアラートの排除
ユーザー体験やビジネスインパクトに直結しないアラート（例: 一時的なCPU使用率の上昇で、レイテンシに影響がないもの）は、うざいだけなんで、通知対象から排除しましょう。
自動修復による排除
アラートが発報された際に、自動修復スクリプトを実行して自己解決できる場合、人への通知自体を排除します。
2. Combine（結合）: アラートをまとめる
関連するアラートを一つにまとめ、ノイズを減らします。
相関分析によるアラートの集約
データベース障害が原因で、上流のサービスA, B, Cが同時にアラートを発報している場合、それらを「データベース障害」という1つの根本原因アラートに集約してしまいます。
これにより、担当者は10件のアラートではなく、集約された1件のインシデントに対応すればよくなります。
ダッシュボードの統合
障害調査に必要なメトリクスやログが複数のダッシュボードに散らばっている場合、
インシデント対応に必要な情報を1つのビューに結合します。
3. Rearrange（交換・順序変更）: 対応フローを見直す
プロセスや通知の順序を変更し、効率と精度を高めます。
通知チャネルの順序変更
重要度の低いアラートは、いきなりPagerDutyで呼び出すのではなく、まずは
Slackやメールに通知し、一定時間対応されなければエスカレーションする
という順序に変更します。
自動化の先行
アラートを人間に通知する前に、まず自動修復を試みるように順序を変更します。
4. Simplify（簡素化）: アラートの内容と対応を分かりやすくする
シンプルにすることで、アラートの理解や対応にかかる認知負荷を下げます。
アラートメッセージの簡素化
アラート本文に、「何が問題か」「ビジネスへの影響は何か」「対応手順書（Runbook）のリンクはどこか」を明確に記述し、分かりにくい技術用語を排除します。
対応プロセスの簡素化
アラートの確認（Ack）やクローズ操作を、チャットツールからワンクリックで実行できるようにし、対応プロセスを簡略化します。
まとめ
ECRSの視点でアラートを見直すことで、場当たり的な改善ではなく、体系的にアラートの品質と運用効率を向上させることができます。
