こんにちは、インフラエンジニアのryuです。
未経験からインフラエンジニアを目指して勉強していると、必ずどこかでこの話を聞くことになります。
「最初の配属は、たぶん運用監視だよ」と。
そして、少し不安になるのではないでしょうか。画面に出てくるアラートを見て、手順書のとおりに連絡して、記録を残す。その繰り返しで、本当に力がつくのだろうか、と。
私も同じ疑問を持ったことがあります。結論から言うと、運用監視の現場は、伸びる人と伸びない人がはっきり分かれる場所です。仕事の内容が同じでも、そのアラートを「作業」として処理するか、「材料」として使うかで、1年後の差が大きく開きます。
今日は、これから現場に入る人、あるいは今まさに監視の当番についている人に向けて、同じ時間の使い方をどう変えるかという話をします。
そもそも運用監視の現場では、何をしているの？¶
運用監視を、ビルの防災センターにたとえてみましょう。
ビルの地下には、たいてい監視室があります。各階の火災報知器や、エレベーターの異常、施錠状態のランプがずらりと並んでいて、担当者が常駐していますよね。何も起きていない時間は、ほとんどの表示が緑のままです。
サーバーの監視も、これとよく似ています。何十台、何百台という機器やサービスの状態が一覧になっていて、異常が出たところだけが赤くなる。担当者は、その赤を見つけて、決められた手順で対処します。
違うのは、ビルの火災報知器が「煙」を見るのに対して、サーバーの監視は「数字」を見ているという点です。応答時間、CPU使用率、ディスクの空き、プロセスが生きているかどうか。これらを一定の間隔で測り続け、決めておいた線を超えたらアラートを上げる。監視ソフトがやっているのは、突き詰めればそれだけです。
監視には種類がある¶
ひとくちに監視といっても、見ている対象はいくつかに分かれます。最初のうちは、この区別を知っておくだけで理解が進みます。
| 種類 | 何を見ているか | 例 |
|---|---|---|
| 死活監視 | サーバーやサービスが生きているか | 応答が返るか、プロセスが動いているか |
| リソース監視 | 資源が枯渇していないか | CPU・メモリ・ディスクの使用率 |
| ログ監視 | 記録に異常な文字列が出ていないか | エラー行や認証失敗の急増 |
| 外形監視 | 利用者から見て使えるか | 外部からページを開いて確認する |
現場でよく使われる監視ソフトには、Zabbix や Prometheus といったものがあります。名前を覚える必要はまだありませんが、どれも「測る」「しきい値と比べる」「通知する」という同じ骨組みでできている、という感覚は持っておくといいでしょう。
アラートは「しきい値」と「手順書」で回っている¶
監視の現場が回っているのは、ふたつの決めごとのおかげです。
ひとつは、しきい値。ディスク使用率が85%を超えたら警告、95%を超えたら緊急、といった線引きです。もうひとつが手順書で、そのアラートが出たときに誰へ連絡し、何を確認するかが書いてあります。
手順書は、現場の先輩たちが過去の障害から学んだことを、言葉にして残したものです。つまり、あなたの目の前にある手順書は、過去の失敗の記録でもあります。
だから手順書は宝の山なのですが、同時に落とし穴でもあります。理由は次に説明します。
「眺めるだけ」になってしまう、3つの理由¶
運用監視で伸び悩む人が悪いわけではありません。構造として、そうなりやすい理由があるのです。
ひとつ目は、手順書が優秀すぎることです。書いてあるとおりに動けば対応が完了してしまうので、なぜその手順なのかを考えなくても仕事が終わってしまいます。
ふたつ目は、アラートの数です。1日に何十本も鳴る現場では、一本ずつ意味を考えていられません。そのうち「またこれか」と、内容を見ずに処理する癖がついてしまいます。
三つ目は、視野の狭さです。自分が見ているのは全体のごく一部で、そのサーバーが何のために存在しているのか、誰が使っているのかが見えないまま時間が過ぎていきます。
補足すると、この3つはどれも本人の努力不足ではなく、現場の仕組みが生む副作用です。手順書が整っているのは良いことですし、アラートが多いのは監視対象が多い証拠でもあります。だから、環境のせいにして終わらせるのではなく、その仕組みの上で自分が何を持ち帰るかを決めておくほうが建設的でしょう。
この3つは、どれも「自分では気づきにくい」という点が厄介です。忙しく働いている実感はあるのに、振り返ると説明できることが増えていない。これから紹介する習慣は、その状態を防ぐためのものです。
同じ当番時間で差がつく、3つの習慣¶
特別な勉強時間を追加しなくても構いません。当番中の数分と、終わったあとの数分でできることです。
習慣1：アラート1本ごとに「何が・どこで」を言葉にする¶
アラートが鳴ったら、対応する前に、心の中で一文にしてみてください。
「Webサーバー3号機の、ディスクの空きが減っている」
たったこれだけです。でも、これを毎回やると、機器の名前と役割が自然に頭に入ります。そして何より、自分が何を見ているのか分からないまま手を動かす状態から抜け出せます。
慣れてきたら、確認したコマンドとその結果もメモに残しましょう。
# ディスクの使用率を確認する（-h は人が読みやすい単位で表示）
df -h
# サービスが動いているかを確認する
systemctl status nginx
メモは、自分の言葉で構いません。1行でも構いません。ログの読み方そのものに不安があるなら、未経験インフラエンジニアのためのログの読み方入門も合わせて読んでみてください。アラートの裏側には、必ずログがあります。
習慣2：手順書のコマンドを、1つずつ分解して調べる¶
手順書には、当たり前のようにコマンドが並んでいます。ここが、いちばんおいしい部分です。
たとえば手順書に ss -tnp と書いてあったとします。言われたとおりに打てば結果は出ますが、そこで終わらせずに、オプションの意味を1つずつ調べてみてください。
# 今どのポートで待ち受けていて、どのプロセスが使っているかを見る
ss -tnp
t はTCP、n は名前解決をせずに数字で表示、p はプロセス名を出す。分かってしまえば単純です。この調べ物を1日1つ続けると、1年で200以上のコマンドやオプションが身につく計算になります。基本のコマンドをまとめて押さえたい人は、Linuxコマンドの基本から始めるといいでしょう。
調べ方に迷ったときは、man コマンドや公式ドキュメントを開く癖をつけてください。検索結果の上位に出てくるブログは便利ですが、バージョン違いの情報が混ざりやすいという弱点があります。この点は公式ドキュメントの読み方でも詳しく書きました。
習慣3：気になった障害を、自分のラボで再現してみる¶
これが、いちばん効きます。
当番中に出会ったアラートのうち、ひとつでいいので、自宅の練習環境で同じ状態を作ってみるのです。ディスクを意図的に埋めてみる。サービスを止めてみる。設定ファイルをわざと壊してみる。
# 練習環境で、わざと大きなファイルを作ってディスクを圧迫する
fallocate -l 5G /var/tmp/dummy.img
df -h /var
# 確認が終わったら必ず削除する
rm /var/tmp/dummy.img
本番では絶対にできないことが、自分のラボなら好きなだけ試せます。壊して、直して、また壊す。この往復が、手順書の行間を埋めてくれます。練習環境の作り方は自宅で作るインフラ学習ラボにまとめてあるので、まだ環境がない人はそこから用意してみてください。
再現できると、次に同じアラートが鳴ったときの景色が変わります。「あのとき自分で壊したやつだ」と分かるからです。切り分けの練習を体系的にやりたい人は、障害の切り分けを独学で鍛える方法も参考になります。
記録は「未来の自分への引き継ぎ」として書く¶
3つの習慣を支えるのが、記録です。とはいえ、立派なノートを作る必要はありません。
私がおすすめしているのは、1件につき3行だけ書く方法です。何が鳴ったか、何を確認したか、結果どうだったか。この3行なら、当番の合間でも書けます。
9/17 02:40 バッチ実行中にディスク使用率が92%（DB用サーバー）
df -h と du で確認 → 一時ファイルが消えずに残っていた
先輩が手動で削除。恒久対応はチケット化されたらしい
三行目の「らしい」が大事です。分からなかったことを、分からないまま残しておく。そうすると、後日その答えを知ったときに線がつながります。逆に、分かったふりをして書いた記録は、あとで読んでも何も思い出せません。
夜勤やシフト勤務が入る現場では、生活リズムが崩れて勉強時間が取りにくくなります。だからこそ、勤務中に発生した出来事を材料にできるこの方法が現実的なのです。机に向かう時間を確保できない日でも、記録だけは積み上がっていきます。
監視で見ている数字は、構築や設計にそのままつながる¶
運用監視の経験は、次の仕事の前払いのようなものです。何を見ていたかが、そのまま設計の材料になります。
| 監視で見ていた値 | 次の仕事で効いてくる場面 |
|---|---|
| ディスク使用率の増え方 | 容量の見積もり、ログの保存期間の設計 |
| メモリの使用傾向 | サーバーのサイズ選び、クラウドのインスタンス選定 |
| 応答時間の変化 | 負荷分散やキャッシュを入れる判断 |
| 特定の時間帯に集中するアラート | バッチ処理の実行時間の調整 |
表を眺めていると、あることに気づかないでしょうか。どれも「今どうなっているか」ではなく、「どう変わってきたか」を見ている点です。ディスクが80%であること自体には、実はあまり情報がありません。先月は40%だったのに今月80%になったのなら、来月は溢れます。半年前からずっと80%なら、当面は問題ないと判断できます。
監視の画面を毎日見ている人は、この「変化の速さ」を肌感覚として持てます。これは書籍を読んだだけでは手に入らないもので、運用監視を経験した人の強みそのものです。
設計をする人は、机上の理論だけで数字を決めているわけではありません。実際にどれくらい使われているかという観測結果を土台にしています。その観測結果を毎日見ているのが、運用監視の担当者なのです。
考え方の面でも学べることがあります。世界的に読まれているサイト信頼性エンジニアリングの教科書では、アラートは「利用者に影響が出ている症状」を中心に設計すべきだ、という考え方が示されています。CPU使用率が高いこと自体は、必ずしも障害ではありません。利用者がページを開けないことが障害です。
鳴っているアラートが、利用者の困りごとと結びついているか。この問いを持てるようになると、監視の当番は「作業」から「観察」に変わります。
この視点は、何年か先に自分が監視の設計をする側に回ったとき、そのまま役に立ちます。
監視の現場にいるうちに、手を広げる順番¶
限られた時間で何から学ぶかは悩みどころです。おすすめの順番はシンプルで、自分が毎日見ている画面にいちばん近いものから広げていくというやり方です。
まずはLinuxです。監視対象のサーバーはLinuxであることが多く、コマンドが読めるだけで、手順書の意味がぐっと分かるようになります。次にネットワークです。「疎通できない」という言葉の中身が分かると、切り分けの範囲が一気に広がります。そのうえでクラウドに進むと、監視サービスの設定画面が、ただのメニューではなく仕組みとして見えてきます。
独学で順番に迷ったときは、InfraAcademy のLinuxロードマップを土台にするのが早道です。手を動かす課題に沿って進められるので、当番の合間に少しずつ埋めていけます。ネットワーク側から固めたい人はネットワークロードマップもあります。現場で毎日見ている画面と、学んでいる内容が重なると、学習の速度は驚くほど上がります。
未経験でこの仕事に飛び込むこと自体に不安がある人は、未経験でインフラエンジニアになるのはきついのかも読んでみてください。現場のきつさと、その先にあるものを率直に書いています。
半年後に何が言えるか、を基準にする¶
学習の指針として、ひとつだけ基準を持っておくといいと思います。
半年後に「ディスクのアラートが出たとき、どこを見て、何を判断しましたか」と聞かれて、自分の言葉で答えられるかどうか。答えられるなら、その半年は確実に前に進んでいます。手順書の番号しか思い出せないなら、習慣1からやり直せば大丈夫です。
焦らなくて構いません。監視の当番は、材料が毎日向こうからやってくる、かなり恵まれた環境なのですから。
まとめ¶
運用監視は、未経験からインフラエンジニアになった人の多くが最初に立つ場所です。そして、そこでの過ごし方は自分で選べます。
今日の要点を振り返ります。
監視の現場は、測って、しきい値と比べて、通知する、という骨組みで動いています。手順書とアラートの数は、考えずに処理する癖を生みやすいという落とし穴を持っています。だからこそ、アラートを一文にする、手順書のコマンドを分解する、自分のラボで再現する、という3つの習慣が効きます。
そして、監視で見ている数字は、そのまま構築や設計の材料になります。今は赤いランプを追いかけているだけに見えても、その観察はちゃんと積み上がっています。
明日の当番から、アラート1本だけでいいので、言葉にしてみてください。そこから景色が変わっていきます。
