中嶋です。
皆様は監視通知の見直しは行っておりますでしょうか？
今回、初めて監視通知の見直しを行ったので記事にします。
概要
- Slackに通知しているサービス障害の通知を見直す
当時の状況
- インフラディビジョンが共通基盤として監視システムを運用している
- nagiosやsnmptrapの通知をSlackの warnings-xxx というチャンネルに流している
- warnings は nagiosのステータスから命名
- 通知先チャンネルが乱立している
- 当時20個弱のチャンネルが存在した
- 通知されても直ちに対応する必要がないものも多い
ゴール
- 適切な通知を適切な 場所・人・時間に発報できている状態にする。
やったこと
フェーズ1(ベースとなる仮案作成)
- ベースとなる案を考える
- チャンネルわけのパターンの仮作成
フェーズ2(調査・ヒアリング)
- 重要・緊急度に応じた通知の仕分け案作成
- 各種資料レビュー
- 監視条件の本案作成
- サービス側への確認・調整
- 監視システムの監視項目洗い出し
- 各通知内容毎の緊急度見直し
フェーズ3(新ルールの決定・反映)
- チャンネル作成・削除
- 各監視システムの通知設定変更
最終的な形
最終的なチャンネルの分け方や通知の種類、時間帯については下図の通りになりました。
やってみて
監視の見直しはこれまで1度もしたことがなく、初めての取り組みでした。
機器ごとで監視通知をしていたり、監視サービス毎に通知設定があったりとすべての監視に対して通知先の変更を行うのは大変でした。
ここは今後の課題だと思ってるのでどこかに集約や統合ができるのが理想だと考えてます。
サービス関係者を巻き込んでの大きなプロジェクトとなりましたが、
各サービス毎にサービス監視していることが多く、案外簡単に切り替えられました。
それまでの準備にしっかり時間をかけてパターンだしやその欠点利点を整理できていたのも大きな要因だと考えてます。
