自己紹介
はじめまして、ハメコ（@hameko）です。
現在はインフラエンジニアとして、社内システムのサーバ構築・運用に携わっています。
キャリアのスタートは運用監視。官公庁システムの24時間365日監視業務を1年半経験し、現在は構築フェーズにステップアップしています。
この記事は「運用監視から構築へステップアップした私が振り返る、運用の初歩」シリーズ第2部です。
前編では運用監視の現場で学んだことをまとめました。
今回はその経験が構築フェーズでどう活きたかを紹介します。
サーバ構築の基本
構築フェーズでは、以下のような業務に携わるようになりました：
- OS選定（RHEL, Ubuntuなど）
- サーバリソース設定（CPU、メモリ、ストレージ）
- 初期設定（ユーザー管理、タイムゾーン、ホスト名など）
- セキュリティ設定（ファイアウォール、SELinux、パッケージ管理）
- ネットワーク設定（IPアドレス、ルーティング、DNS）
運用監視の経験があることで、【後々の運用を意識した構築】ができるようになりました。
運用視点で設計する構成の工夫
構築時に意識するようになったポイント：
- 障害時の切り分けがしやすい構成
- ログの保存場所や容量の設計
- バッチ処理やジョブの可視化
- 冗長構成（HA）の重要性
- マシンリソースのゆとり
運用監視で「困ったこと」「見えづらかったこと」を思い出しながら、構成に反映するようになりました。
監視・ログ設計の重要性
運用監視経験があると、【監視設計の重要性】が身に染みてわかります。
ここは、運用監視経験がなかったら、何も考えていなかったと思います。
- 監視対象の選定（CPU, メモリ, ディスク, プロセス）
- アラートの閾値設定
- ログの出力形式と保存期間
-
journalctlやrsyslogの活用
構築時点で「監視しやすい設計」「ログが追いやすい設計」を意識することで、後々の運用が格段に楽になります。
運用監視経験が活きた場面
実際に構築業務で「運用視点があってよかった」と感じた場面をいくつか紹介します。
ケース1：ログ設計でトラブルを未然に防止
監視時代に「ログが見づらい」「どこにあるかわからない」と苦労した経験から、構築時にログの出力先や形式を明確に設計。
結果として、障害発生時の初動対応がスムーズに。
自分で作ったからこそ、分かるようになったのかもしれません。
ケース2：エスカレーションしやすい構成
基本一人で運用も行っているので、ベンダーへの問い合わせ対応や、
障害時に「どこに連絡すればいいか」「何を伝えればいいか」が明確になるよう、構成図やドキュメントを整備。
運用監視の現場での苦労が、構築時の工夫につながりました。
ケース3：監視設計の段階で「運用の目線」を入れられた
監視ツールの導入や設定を行う際、運用監視時代に「どこを監視しておけば安心か」「どんなアラートが無駄か」を体感していたため、
必要な監視項目を絞り込み、アラートの閾値も現場に合わせて調整できました。
結果として、無駄なアラートが減り、運用チームから「見やすくて助かる」と言われました。
ケース4：リソース設計で「監視目線」を活かせた
運用監視時代に、CPUやメモリの使用率が高騰してアラートが頻発する状況を何度も経験しました。
その経験から、構築時にはリソースの割り当てを意識して設計するようになりました。
例えば、仮想環境（VMware）でのCPUコア数やメモリ容量の設定を、実際の運用負荷を想定して調整。
「このくらいの負荷でアラートが鳴る」「このジョブはCPUを食いやすい」といった感覚が、構築時の判断に役立ちました。
まとめ：キャリアアップのヒント
運用監視の経験は、構築フェーズでも確実に活きます。
「ただの監視業務」と思われがちですが、【現場感覚・障害対応力・設計視点】など、構築に必要なスキルの土台になります。
これから構築フェーズに進みたい方は、ぜひ運用監視の経験を「資産」として活かしてみてください。
この2部構成の記事を通して、
「運用監視で得た経験はキャリアの土台となり、構築や設計に直結する」ことを伝えられたら嬉しいです。