毎朝30分の監視確認、問題は情報不足じゃなくて画面遷移コストだった
結論
監視の朝チェックに毎朝30分かかっていた原因は、「見るべき情報が多い」ではなく「見る場所が散らばっている」でした。
解決の方向性は、ダッシュボードを見に行く（Pull型）から、レポートが届く（Push型）への転換。Jenkinsで毎朝レポートを自動生成してチャットに投稿する仕組みを作る予定です。
以下、そこに至るまでの経緯です。
背景
あるプロジェクトに外部から参画したとき、「監視の運用を整えたい」というオーダーをもらいました。
サービスは稼働中で、CloudWatchもログもダッシュボードも揃っています。障害頻度は数ヶ月に1回程度。監視体制が崩壊しているわけではありません。
ヒアリングで出てきた課題感はこんな感じでした。
- アラートの設計が甘いかもしれない
- 見るべきメトリクスが整理されていない
- 外部APIの監視が手薄
- コストの可視化も気になる
どれも「やったほうがいい」ことではあります。ただ、事業フェーズ的に監視に大きく投資する段階ではなく、今は開発優先。それは正しい判断だと思います。
そんな中で、ひとつ気になる話が出てきました。
「毎朝30分くらいかけて、手作業でいろんな画面を見て回っている」
30分かかる理由
深掘りしてみると、30分の大半は「考える時間」ではありませんでした。
AWSのコンソールを開いて、ダッシュボードに移動して、期間を変えて、別のサービスの画面に行って、外部APIのステータスページを開いて……。画面をあちこち渡り歩く時間だったんです。
情報は足りています。ただ、見る場所が散らばっている。
課題は「監視が足りない」ではなく、「監視の確認に手間がかかりすぎている」でした。
朝チェック効率化でいいのか？
ここで少し立ち止まりました。
朝チェックを効率化しても、アラート設計が甘い問題は残ります。外部APIの監視が手薄な問題も残ります。本当にそこからやるべきなのか。
整理してみると、監視には2つの役割がありました。
アラート設計や外部API監視は「異常が起きたときに気づく仕組み」。朝チェックは「普段の感覚を保っておく」話。役割が違います。
障害が少ない今のフェーズでは、アラートが鳴る機会は少ないです。でも、普段の感覚が鈍っていると、いざアラートが鳴ったときに「これ本当にやばいのか？」が判断できなくなります。
毎朝数字を見ているからこそ、「いつもの波形」が身体に入る。朝チェックを効率化するのは「手抜き」じゃなくて、感覚を保ちながら続けられる形にするということです。
Pull型からPush型へ
30分かかっている理由は画面遷移コストでした。見る情報を減らすのではなく、見る場所を減らす必要があります。
過去に別のプロジェクトで、Jenkinsで毎朝レポートを自動生成してチャットに投稿する運用をやったことがありました。一度作ってしまえば「届いたものを読むだけ」になります。
今回も同じアプローチでいけそうです。
次にやること
-
今見ているものを棚卸しする
何を、どこで、どういう順番で見ているのか洗い出す -
毎朝見るべき代表値を絞る
全部載せるのではなく、まず最低限のものだけ -
Jenkinsジョブを作って、チャットに投げる仕組みを作る
最初はシンプルに。凝らない -
運用しながら調整する
足りないものがあれば足す、いらないものは削る
一気に完璧を目指すとたぶん頓挫するので、小さく始めて回していきます。
まとめ
正直、これが正解かはわかりません。
ただ、監視体制の強化は今のフェーズではコスパが悪い。でも普段の感覚は鈍らせたくない。だから「感覚を保ちながら、続けられる形にする」という方向性は、たぶんあってそうな気がしています。
実装編はまた別途。
こうした設計判断のプロセスを、もう少し丁寧にまとめています。
Discussion