この記事について
監視の運用改善を検討する中で、「毎朝30分かかっている朝チェック」の原因を分析しました。
結論として、問題は「見るべき情報が多い」ではなく「見る場所が散らばっている」でした。Pull型（見に行く）からPush型（届く）への転換で解決できそうです。
前提
- サービス運営中
- CloudWatch / ログ / AWSダッシュボードは揃っている
- 障害頻度は数ヶ月に1回程度
- 事業フェーズ的に監視への大規模投資は難しい
課題
毎朝30分ほどかけて、手作業で監視情報を確認している状態でした。
確認しているもの：
- CloudWatchのメトリクス
- 各種ログ
- 外部APIのステータス
- AWSコスト
原因分析
30分の内訳を確認したところ、大半は「考える時間」ではありませんでした。
- AWSコンソールを開く
- ダッシュボードに移動
- 期間を変更
- 別サービスの画面に移動
- 外部APIのステータスページを開く
- ……
画面をあちこち渡り歩く時間が大半を占めていました。
情報は足りています。問題は、見る場所が散らばっていることでした。
解決の方向性
見る情報を減らすのではなく、見る場所を減らす。
具体的には、Pull型からPush型への転換です。
Jenkinsで毎朝レポートを自動生成し、チャットに投稿する仕組みを作ります。
実装ステップ
-
棚卸し
現状、何を・どこで・どういう順番で見ているか洗い出す -
代表値の選定
毎朝見るべき最低限の値を絞る -
Jenkinsジョブ作成
レポート生成 → チャット投稿の仕組みを作る -
運用・調整
足りないものは足す、いらないものは削る
補足：なぜ朝チェックを残すのか
監視には2つの役割があります。
アラート設計は「異常時に気づく仕組み」。朝チェックは「普段の感覚を保つ」ための習慣です。
障害頻度が低いフェーズでは、アラートが鳴る機会は少ないです。ただ、普段の感覚が鈍ると、いざアラートが鳴ったときに「本当にやばいのか」が判断できなくなります。
朝チェックの効率化は「手抜き」ではなく、感覚を維持しながら続けられる形にするということです。
まとめ
| 項目 | 内容 |
|---|---|
| 問題 | 朝チェックに毎朝30分かかる |
| 原因 | 画面遷移コスト（情報量ではない） |
| 解決策 | Pull型 → Push型への転換 |
| 実装方針 | Jenkinsで朝レポートを自動生成 |
実装編は別途まとめる予定です。
こうした設計判断のプロセスをまとめています。
https://tielec.blog/