監視アラートを設計するときは、閾値だけでなく、通知を受けた人が何を判断し、どう動くかまで決めます。CPU使用率やエラー件数を集めていても、対応する人と手順が決まっていなければ、通知後の判断が止まってしまいます。
本記事では、企業の運用担当者が監視通知を整理するために、業務影響、通知条件、担当、初動、確認試験の順で設計する方法を紹介します。特定システムに共通して使える閾値や、製品の設定コマンドを示すものではありません。
測定することと、人を呼ぶことを分ける
測定データには、障害の検知、原因調査、長期的な傾向確認など、異なる使い道があります。すべてを即時通知の条件にせず、「今すぐ人の対応が必要か」を分けて考えます。
GoogleのSRE資料では、監視における「何が壊れているか」という症状と、「なぜ起きたか」という原因を区別しています。また、緊急の呼び出しは、利用者に見える症状や差し迫った問題を中心に設計する考え方を説明しています。Google SRE「Monitoring Distributed Systems」
例えば、受注登録のエラーが続く状態と、サーバーのCPU使用率が一時的に上がった状態は、同じ通知先・同じ優先度とは限りません。受注が処理できているか、状態が継続しているか、放置すると何が起きるかを確認します。
1. 守りたい業務と観測項目を対応させる
最初に「受注を登録できる」「必要な時間内に検索結果が返る」のように、利用者から見た必要な状態を置きます。次に、その状態を判断する観測項目を選びます。
GoogleのSRE資料は、利用者向けシステムの重要な観測軸として、応答時間、トラフィック、エラー、飽和度を挙げています。4つの主要なシグナル
以下は、その考え方を受注システムの検討に使うための仮例です。
| 確認したい状態 | 観測する内容の例 | 調査に使う情報の例 |
|---|---|---|
| 受注登録ができる | 登録処理の成功・失敗 | エラーログ、直近の変更 |
| 検索が待てる時間内に終わる | 検索処理の応答時間 | データベース処理、接続状況 |
| 処理量の変化を把握できる | リクエスト数や処理件数 | 時間帯、利用部門、予定作業 |
| 容量不足が迫っていない | 空き容量や使用量の増加 | 保存期間、増加要因 |
この表をそのまま実装するのではなく、必要な業務を測れているかを確認してください。画面が表示されることだけで、その後の登録まで成功するとは限らないためです。
2. 通知条件を、時間と対象を含めて書く
「エラーが増えたら通知」ではなく、どの対象を、どの期間で、どの条件と比較するかを記録します。
例えば、エラー件数とエラー率は別の見方です。説明用に、失敗10件、全体100件なら失敗率は10％、失敗10件、全体1万件なら0.1％です。同じ件数でも割合は変わります。どちらを判断に使うかは、業務影響と処理量に合わせて決めます。
通知条件の検討表には、以下を入れる方法があります。
| 項目 | 決める内容 |
|---|---|
| 対象 | 本番か検証か、サービス全体か一部の処理か |
| 集計 | 件数、割合、応答時間など、何を見るか |
| 判定期間 | 一時的な変動と継続状態をどう区別するか |
| データ欠損 | 計測できない状態をどう扱うか |
| 通知解除 | どの状態になれば回復と扱うか |
| 予定作業 | 保守や試験中の通知をどう扱うか |
閾値は、実際の正常時のデータ、業務が許容する状態、試験結果をもとに調整します。通知を減らすためだけに値を引き上げず、通知が必要な場面まで消えていないかを確認します。
3. 通知一件ごとに担当と初動を付ける
AWSの運用指針は、各アラートに対応手順、担当、エスカレーション経路を持たせることを勧めています。AWS「Have a process per alert」
通知を受ける人が迷わないよう、次の対応カードを作る方法があります。内容は自社の体制に合わせて決めます。
- 何が起きた可能性があり、どの業務に影響するか。
- 最初に担当するチームと、担当不在時の連絡先。
- 最初に見る画面、ログ、直近の変更履歴。
- 許可されている確認操作と、実施前の判断が必要な変更操作。
- 自分の範囲で判断できない場合の相談先。
- 回復を確認する方法と、結果の記録先。
例えば「アプリケーションを再起動する」とだけ書くと、対象を間違えたり、調査に必要な状態を失ったりするおそれがあります。まず確認する情報、操作してよい条件、中止する条件を付けます。
原因調査の道筋をまとめた文書はプレイブック、結果が分かっている作業の手順はランブックと呼ばれることがあります。AWSも調査の手順と、対処の手順を結び付ける方法を説明しています。AWS「Use playbooks to investigate issues」
4. 通知が届いてから対応できるまでを試す
設定画面の保存だけで完了にせず、通知先と手順を確かめる試験を計画します。本番へ障害を起こすことを前提にせず、テスト通知や検証環境など、影響を管理できる方法を選びます。
| 試験すること | 確認結果の例 |
|---|---|
| 条件の発火 | 意図したテスト条件で通知されたか |
| 到達 | 対象の担当者が受け取れたか |
| 初動 | 通知から必要な画面・手順へたどれたか |
| 引き継ぎ | 一次担当で判断できない場合の連絡先が分かったか |
| 回復 | 状態が戻ったときに解除・記録できたか |
確認できなかった経路は未確認として残します。例えば昼間の通知だけ試した場合、夜間の当番への連絡まで確認済みとは扱わないようにします。
5. 通知の結果から、残す・変える・統合するを判断する
運用後は、通知件数だけでなく、その通知で実際にどんな行動を取ったかを振り返ります。以下は見直し方の例です。
| 通知後の状況 | 見直す候補 |
|---|---|
| 担当者が毎回「対応不要」と判断 | 条件、優先度、記録だけにする可否 |
| 同じ事象で多数届く | 関連通知のまとめ方、重複条件 |
| 必要な通知が来なかった | 観測範囲、条件、欠損、通知経路 |
| 通知は来たが対応できなかった | 手順、権限、連絡先、担当範囲 |
良い通知かどうかは、数の少なさだけでなく、必要な対応につながったかで確かめます。最初は重要な業務を一つ選び、現在のアラートに「担当と初動」が付いているか確認してみてください。基盤の構成や運用の整理は、テクノヴァースのインフラ支援でもご案内しています。