はじめに
「監視業務の経験があります」
転職活動中にそう言っていた時期があります。でも今振り返ると、あれは監視じゃなかった。
やっていたのは「メールやSlackに飛んできたアラートを見て、手順書の番号を上長に報告する」だけ。アラートが何を意味するのか、なぜそのしきい値なのか、何も理解していませんでした。
監視ツールは触っていた。CloudWatchのダッシュボードも開いていた。でも、見ていたのは「アラートが来たかどうか」だけ。
本当の意味での「監視」ではなかったんです。
この記事は、同じことをやっている人に「次のステップ」を伝えたくて書きました。
この記事を読むと、以下のことができるようになります。
- 「アラートの受け取り」と「監視」の違いを説明できる
- CloudWatchで何を見ればいいかの基本的な視点が身につく
- 障害発生時に「どこを確認するか」の思考フローがわかる
「アラートを受け取る」と「監視する」は別のことだった
私がいた現場の運用フローはこうでした。
見た目は「監視」していますが、実態は通知の中継です。
本当の監視は、アラートを受け取る前の段階から始まっています。
アラートは「すでに問題が起きた」ことを知らせるものです。監視とは、その前に「何かおかしい」と気づくための継続的な観察行為です。
私が気づいていなかった3つのこと
1. しきい値に根拠がなかった
当時の現場では、CloudWatchのアラートが設定してありました。「CPU使用率80%で通知」「メモリ90%で通知」。
でも、なぜ80%なのか、90%なのか、誰も説明できなかった。引き継ぎのときに「こうなってるから」と教わっただけ。
本来は、そのサーバーの通常時のCPU使用率がどれくらいで推移しているかを把握した上で、「通常より著しく高い状態」を定義するのがしきい値設計です。
EC2のCPU使用率が普段20〜30%で動いているサーバーなら、80%はすでに危機的な状況かもしれない。逆に、バッチ処理時に毎回70%になるサーバーなら、80%は誤検知だらけになります。
2. ログを読んでいなかった
アラートが発火したとき、ログを見る前に上長へエスカレーションしていました。
でも現場のエンジニアにとって、最初にほしい情報は「何が起きたか」です。アラートはそれを教えてくれません。ログが教えてくれます。
CloudWatchのロググループを開いて、アラート発火時刻の前後のログを確認する。エラーメッセージは何か、どのリクエストで起きているか、直前に何かデプロイや設定変更があったか。ここまでセットで伝えられると、エスカレーション先の判断が格段に速くなります。
3. 「正常」を知らなかった
異常を検知するには、正常を知っている必要があります。
当時の私は、そのシステムの「普段の姿」を知りませんでした。
- 通常時のCPU・メモリ・ディスクの推移はどうか
- アクセスのピーク時間帯はいつか
- デプロイやバッチ処理が走るとメトリクスはどう変動するか
これを知っていれば、「今日のメトリクスはちょっといつもと違う」という変化に気づけます。知らなければ、アラートが来るまで何もわかりません。
CloudWatchで「本当の監視」をするための見方
CloudWatchで見るべき指標と、その意味を整理します。
EC2のCPU使用率（CPUUtilization）
| 状況 | 考えられる原因 |
|---|---|
| 突然スパイクして戻る | 定期バッチ・アクセス集中・メモリ不足によるスワップ |
| 徐々に上昇して下がらない | メモリリーク・ゾンビプロセス・不正アクセス |
| ずっと低いのに突然ゼロになる | インスタンスの停止・ネットワーク切断 |
CPU使用率だけ見ていても不十分です。必ずメモリ・ディスク・ネットワークのメトリクスをセットで確認する習慣をつけてください。
RDSのデータベース接続数（DatabaseConnections）
接続数が急増しているとき、アプリケーション側でコネクションプールが正しく機能していない可能性があります。接続が増え続けると、最終的に「Too many connections」エラーでDBに接続できなくなります。
# CloudWatch Insights でエラーログを確認する例
fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 50
ALBのレイテンシ（TargetResponseTime）
レスポンスタイムが通常より上昇しているとき、原因はEC2・RDB・外部API呼び出しのどこかにあります。一つずつ切り分けることで、ボトルネックを特定できます。
障害発生時の思考フロー
アラートが来たとき、私が今やっている確認の順番です。
以前との違いは「仮説を持って報告する」かどうかです。
「CPUが80%超えました」より「CPUが80%を超えています。同時刻にデプロイが走っており、ログにOOMKillerのメッセージがあります。メモリ不足の可能性が高いと思います」の方が、対応が10倍速くなります。
監視オペレーターが次のステップに進むためにやること
「アラートを受け取るだけ」の状態から抜け出すために、今日からできることを3つ挙げます。
1. 担当しているシステムの「正常値」を記録する
1週間、CloudWatchで各メトリクスを毎日確認して、通常時の推移をメモする。朝・昼・夕・深夜でどう変わるか、バッチが走るときはどうなるか。これだけで「異常に気づく目」が育ち始めます。
2. 次のアラートでログを開いてみる
エスカレーション前に、CloudWatchのロググループを開いてアラート発火時刻のログを見てみる。何が書いてあるかわからなくてもいい。「ERRORという文字列が見える」「さっきまでなかったメッセージが増えた」という観察から始めてください。
3. しきい値の根拠を先輩に聞く
「なぜこのしきい値なんですか？」という質問は、先輩に設計の意図を語ってもらえる最高の入口です。答えてもらえた知識は、そのシステムを理解する核になります。
まとめ
この記事では以下のことを解説しました。
- アラートの受け取りは「監視」ではなく、監視の出発点に気づくことが大切
- 正常時のベースラインを知ることが、異常を検知する前提になる
- CloudWatchのメトリクス・ログを組み合わせて「仮説を持った報告」ができると現場での評価が変わる
- 今日からできることは「正常値の記録・ログを開く・しきい値の根拠を聞く」の3つ
監視オペレーターの仕事は、やり方次第でスキルアップの宝庫です。同じ画面を見ていても、何を考えながら見るかで、1年後のキャリアが大きく変わります。
ハンズオンラボでは、未経験からでも「作って覚える」をモットーにしたITハンズオンイベントを定期開催しています。
面白かったら
「👇いいね」で応援