第4部サーバーと運用

第14章サーバー運用の実務 — 構築・監視・ログ・障害対応

サーバーは、立てて終わりではありません。むしろそこからが本番です。動き続けさせ、異常にいち早く気づき、壊れたときは元に戻す——地味だけれど会社を支えるこの「運用」の実務こそ、IT部門の腕の見せどころです。このコースの最終章では、構築・監視・ログ・バックアップ・障害対応・自動化という運用の全体像を、具体的なコマンドとともに一気に通します。ここまで積み上げてきた知識が、すべてつながる瞬間です。

🎯 この章で学ぶこと

運用とは「動き続けさせる」こと。構築から廃棄までのライフサイクル
サーバー構築の基本(OS選定・SSH接続・systemctl・パッケージ管理)
監視の3本柱(死活監視・リソース監視・閾値アラート)と確認コマンド
ログはどこにあり、どう見るか(/var/log・journalctl・ローテーション)
バックアップと冗長化、そして「復旧を試す」ことの大切さ
障害対応の切り分け手順と、よくある原因
自動化・構成管理でヒューマンエラーを減らす考え方

14.1 運用とは「動き続けさせる」こと

サーバーの仕事には、大きく「構築」と「運用」の2つのフェーズがあります。初心者はつい「構築(立ち上げ)」がゴールだと思いがちですが、実際にはサーバーの一生の大半は運用——つまり「日々、正常に動き続けさせること」——に費やされます。むしろ「立てて終わり」で放置されたサーバーこそ、最も危険な存在です。

サーバーには、人間や製品と同じようにライフサイクルがあります。この流れ全体を面倒見るのが運用者の役割です。

構築 — OSを入れ、必要なソフトを設定して稼働させる
監視 — 正常に動いているか、常に見張る
保守 — パッチを当て、ログを整理し、バックアップを取る
障害対応 — 異常が起きたら原因を突き止め、復旧する
廃棄 — 役目を終えたら、安全にデータを消して停止する

本章は、この「構築」から「障害対応」までを順にたどります。運用の世界には、派手さはありませんが、確かな技術と規律があります。

14.2 サーバーの構築

まずはサーバーを立ち上げる「構築」からです。ここでは、実務で最も広く使われるLinuxサーバーを前提に進めます。

OS選定と初期設定

サーバーのOSには、無料で安定して動くLinuxがよく選ばれます。Linuxにも種類(ディストリビューション)があり、企業では RHEL / Rocky Linux 系や Ubuntu / Debian 系がよく使われます。どれを選ぶかは、社内の実績やサポート体制で決めます。OSを入れたら、まず「使わないサービスを止める」「必要なユーザーを作る」「時刻を正しく合わせる」といった初期設定(第12章の堅牢化の第一歩)を行います。

SSHでの接続

サーバーは目の前にモニターをつないで操作するのではなく、手元のPCからSSH(第11章)でネットワーク越しに接続して操作するのが基本です。第2部で学んだターミナルの技術が、ここで生きてきます。

$ ssh admin@192.168.1.50
admin@192.168.1.50's password:
Last login: Tue Jul  8 09:15:22 2026 from 192.168.1.10
admin@web01:~$

プロンプトが admin@web01 に変わりました。これで、遠隔地のサーバー web01 の中に入り、目の前のPCと同じようにコマンドを打てます。

サービス管理(systemctl)

Linuxでは、Webサーバーやデータベースといった常駐プログラムをサービス(デーモン)として管理します。その操作の司令塔が systemctl コマンドです。第12章で学んだNginxを例にすると、次のように扱います。

# サービスの状態を確認する
$ systemctl status nginx
● nginx.service - A high performance web server
     Active: active (running) since Tue 2026-07-08 09:20:11 JST; 2h ago

# 起動・停止・再起動
$ sudo systemctl start nginx      # 起動
$ sudo systemctl stop nginx       # 停止
$ sudo systemctl restart nginx    # 再起動

# サーバー起動時に自動で立ち上がるようにする
$ sudo systemctl enable nginx

特に enable は運用で重要です。これを設定しておかないと、サーバーを再起動したときにサービスが自動で立ち上がらず、「再起動したらサイトが表示されなくなった」という事故につながります。

パッケージ管理(apt / yum)

ソフトのインストールや更新は、パッケージ管理ツールで行います。1つずつ手でダウンロードするのではなく、コマンド1つで、必要な部品(依存関係)ごと自動で入れてくれる仕組みです。Ubuntu系では apt、RHEL系では yum(または dnf)を使います。

# Ubuntu系: パッケージ一覧を更新し、全体をアップグレードする
$ sudo apt update
$ sudo apt upgrade

# Nginxをインストールする
$ sudo apt install nginx

⚠️ パッチ適用は「計画的に」

第12章で「パッチを当て続けることが重要」と学びました。ただし本番サーバーで、いきなり apt upgrade を実行するのは危険です。更新によって設定が変わったり、サービスが再起動して一時的に止まったりすることがあるからです。実務では、まずテスト環境で試す→影響を確認→計画したメンテナンス時間に本番へ適用→問題があれば戻せるようにしておく、という手順を踏みます。「セキュリティのために当てる」と「業務を止めない」の両立が、運用者の腕の見せどころです。

14.3 監視 — 異常に「先に」気づく

構築が終わったら、次は監視です。監視の目的はシンプルで、「利用者が気づく前に、運用者が異常に気づく」こと。ユーザーから「サイトが見られない」と電話が来てから動くのは、最悪の運用です。監視には大きく3つの柱があります。

死活監視 — 生きているか

まず基本は「そのサーバーやサービスが、そもそも生きているか」の確認です。ネットワーク的に応答するかは ping(第9章)で、サービス(プロセス)が動いているかは ps で確認します。

# サーバーが応答するか(死活)
$ ping -c 3 192.168.1.50

# Nginxのプロセスが動いているか
$ ps aux | grep nginx
root      812  0.0  0.1  nginx: master process
www-data  813  0.0  0.2  nginx: worker process

リソース監視 — 余裕があるか

次に、CPU・メモリ・ディスクに余裕があるかを見ます。これらが限界に達すると、サーバーは急激に遅くなったり、止まったりします。第1章・第3章で学んだメモリやスワップの知識が、ここで直接役立ちます。基本の3コマンドを押さえましょう。

コマンド	見るもの	ひとこと
`top`	CPU・メモリの使用状況(リアルタイム)	「今」何が重いかを一覧で見る
`free -h`	メモリの空き状況	`-h`で人間に読みやすい単位(第2章)
`df -h`	ディスクの空き容量	満杯は障害の最頻出原因(14.6)

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        50G   47G  3.0G  95% /
tmpfs           2.0G     0  2.0G   0% /dev/shm

この df -h の出力は、運用者が最も頻繁に見る画面の1つです。Use% 95% は「ルートディスクが95%埋まっている」という危険信号。あと少しで満杯になり、ログも書けず、サービスが止まる寸前です。この段階で気づければ、大事に至る前に手を打てます。

閾値アラートと監視ツール

とはいえ、人間が24時間 df を打ち続けるわけにはいきません。そこで監視ツールを使い、「ディスク使用率が80%を超えたら通知する」といった閾値(しきいち)を決めて、自動でアラートを飛ばします。代表的なツールに Zabbix(ザビックス) や Prometheus(プロメテウス) があります。これらは各サーバーのCPU・メモリ・ディスクなどを定期的に集めてグラフ化し、異常な値になったらメールやチャットで担当者に知らせてくれます。「異常に先に気づく」を仕組みで実現するのが、監視ツールの役割です。

✅ 監視は「正常な状態」を知ることから

アラートの閾値を適切に決めるには、まず「平常時が、どういう数値なのか」を知っておくことが欠かせません。ふだんのCPU使用率が20%のサーバーで急に80%になったら異常ですが、もともと70%で回っているサーバーなら70%は正常です。この「平常運転の姿(ベースライン)」を把握していると、些細な変化にも気づけます。監視ツールが日々のグラフを蓄積してくれるのは、まさにこのためです。

14.4 ログ管理 — 記録を残し、読み解く

サーバーは、自分の身に起きたことをログ(記録)として書き残しています。障害の原因究明も、不正アクセスの検知も、すべてはログから始まります。「ログを制する者が運用を制する」といっても過言ではありません。

ログはどこにあるか

Linuxでは、多くのログが /var/log ディレクトリの下に集まっています。まずはこの場所を覚えましょう。

場所	中身
`/var/log/syslog`(または `messages`)	システム全体の一般的なログ
`/var/log/auth.log`(または `secure`)	ログイン・認証の記録(不正アクセス調査の要)
`/var/log/nginx/`	Webサーバーのアクセスログ・エラーログ

journalctl でログを見る

近年のLinux(systemd採用)では、journalctl というコマンドでログをまとめて検索・閲覧できます。先ほどの systemctl と対になる、運用の必携コマンドです。

# Nginxサービスのログだけを、新しい順に追いかける
$ journalctl -u nginx -f

# 直近のエラー(優先度: error以上)だけを絞り込む
$ journalctl -p err --since "1 hour ago"

-u nginx で特定サービスに絞り、-f で新しいログをリアルタイムに追いかけます。--since "1 hour ago" のように時間で絞り込めるのも便利です。障害時は、まずこうして「エラーが出ていないか」「いつから様子が変わったか」をログで確かめます。

ログローテーションと集約

ログは放っておくと際限なく増え続け、やがてディスクを食いつぶします(14.6の頻出障害)。これを防ぐのがログローテーションです。「古いログは圧縮し、一定期間より古いものは自動で削除する」という仕組みで、Linuxでは logrotate がこれを担います。

さらにサーバーが何十台にもなると、1台ずつログを見て回るのは非現実的です。そこで、全サーバーのログを1か所に集める(ログ集約)という考え方が出てきます。集約基盤(いわゆるログ管理システムやSIEM)にログを送り、横断的に検索・分析できるようにします。

💡 他コースへのつながり — ログは分析と検知の源

ログを「読み解く」技術は、運用の枠を超えて広がります。入門コース第13章では、Pythonでログファイルを解析し、集計やパターン抽出を行う手法を学びました。まさにこの /var/log のログが、その解析対象です。また、セキュリティコース第7章では、ログから不正アクセスや攻撃の兆候を検知する方法を扱います。認証ログ(auth.log)に大量のログイン失敗が並んでいれば、それは攻撃のサインかもしれません。運用のログ管理は、自動化やセキュリティへの入り口でもあるのです。

14.5 バックアップと冗長化 — 失っても取り戻せるように

第12章で、DBサーバーのデータは「会社にとって代えのきかない財産」だと学びました。それを守る最後の砦がバックアップです。どれだけ監視を頑張っても、ハードは壊れ、人はミスをします。「失われる前提」で備えるのが運用の鉄則です。

まず区別を整理しましょう。第12章で触れたとおり、冗長化(RAID等)は「止めない」ための備え、バックアップは「元に戻す」ための備えです。両方が必要です。

冗長化 — RAID、冗長電源、ロードバランサ(第12章)。部品や1台が壊れてもサービスを継続する
バックアップ — データを定期的に別の場所へ複製する。誤削除・破損・災害から復元する

バックアップの取り方には定石があります。一人情シスコース第6章で詳しく扱う3-2-1ルールです。すなわち、データは3つ持ち、2種類の異なる媒体に保存し、うち1つは遠隔地(オフサイト)に置く。こうしておけば、1つの拠点が丸ごと被災しても、データは生き残ります。

⚠️ 「復旧できないバックアップ」は無いのと同じ

運用現場で最も怖い落とし穴が、「バックアップは取っていたが、いざ復旧しようとしたら戻せなかった」という事態です。バックアップファイルが壊れていた、手順が誰も分からない、実は途中から取得に失敗していた——こうした悲劇は現実に起こります。だからこそ、定期的に「復旧を試す(リストアテスト)」ことが欠かせません。バックアップの目的は「取ること」ではなく「戻せること」です。取りっぱなしで満足せず、必ず戻せるかを確かめてください。

14.6 障害対応の基本 — あわてず、切り分ける

どれだけ備えても、障害はいつか必ず起きます。そのとき運用者に求められるのは、天才的なひらめきではなく、あわてず、順序立てて原因を絞り込む力です。これを切り分け(トラブルシューティング)といいます。感覚に頼らず、次の手順を淡々と踏むのが、結局は最短の近道です。

再現・現象の確認 — 何が、いつから、どの範囲で起きているのか。事実を正確につかむ(「遅い」ではなく「特定ページが5秒かかる」)
ログの確認 — journalctl や /var/log でエラーを探す(14.4)。「いつから様子が変わったか」を突き止める
仮説を立てる — 集めた事実から「原因はこれではないか」と見当をつける
検証する — 仮説が正しいか、1つずつ確かめる。当たっていなければ、次の仮説へ
記録を残す — 何を確認し、何をしたか、どう直ったかを書き残す。次の同種障害への財産になる

ここで大切なのは、一度にあれこれ触らないことです。あせって設定を次々いじると、何が効いたのか分からなくなり、かえって傷口を広げます。「1つ変えて、確かめる」を守りましょう。第12章の3層アーキテクチャで学んだ「層で切り分ける」発想も、ここで直接役立ちます。

経験を積むと、「よくある原因」の見当がつくようになります。運用者が繰り返し出会う定番の原因を挙げておきます。

よくある原因	典型的な症状	確認方法
ディスク満杯	書き込み失敗、サービスが起動しない	`df -h`(14.3)
メモリ枯渇	極端に遅い、プロセスが強制終了される	`free -h`、`top`
証明書の期限切れ	HTTPSでブラウザに警告、接続不可	証明書の有効期限を確認
設定ミス	変更した直後から動かない	直近の変更履歴とログを確認

✅ 証明書の期限切れは「予防できる障害」

HTTPS(第11章)で使うサーバー証明書には有効期限があり、切れるとブラウザに警告が出て、サイトに接続できなくなります。これは予定された日に必ず起きる障害なので、本来は完全に防げます。監視ツール(14.3)で「証明書の残り期限」を監視し、切れる前にアラートを出すよう設定しておきましょう。近年は証明書の自動更新も普及しています。「起きると分かっている障害」を未然に潰すのも、立派な運用の技術です。

14.7 自動化と構成管理 — 手作業をなくす

ここまでの作業を、サーバーが1台なら手でこなせます。しかし10台、100台となると、1台ずつ手作業で設定するのは非現実的で、しかも手作業はミスの温床です。「1台だけ設定を入れ忘れた」「コピペを間違えた」——こうしたヒューマンエラーが、そのまま障害になります。そこで運用の世界では、手作業をなくし、自動化する方向へ進んできました。

その第一歩が、繰り返す作業をスクリプトにまとめることです。第5章で学んだシェルスクリプト(Linux)、第6・7章で学んだPowerShell(Windows)が、まさにここで活躍します。「毎朝ログを集計してメールする」「新しいサーバーの初期設定をひとまとめに実行する」といった定型作業をスクリプト化すれば、速く・正確に・何度でも同じ結果を再現できます。

さらに進んだ考え方が構成管理とInfrastructure as Code(IaC:コードとしてのインフラ)です。これは、サーバーの設定内容そのものをコード(設定ファイル)として記述し、その通りに自動で構築するという発想です。代表的なツールに Ansible(アンシブル) などがあります。IaCには大きな利点があります。

再現性 — 同じコードから、いつでも同じ構成のサーバーを作れる(第13章のコンテナの発想と同じ)
記録性 — 「どう設定したか」がコードとして残る。手順書の陳腐化や属人化を防ぐ
変更管理 — 設定の変更履歴を追え、問題があれば以前の状態に戻せる

💡 「手順書」から「コード」へ

従来、サーバー構築は分厚い手順書を見ながら手作業で行うものでした。しかし手順書は更新が追いつかず古くなりがちで、担当者しか分からない「属人化」も起きます。IaCは、その手順を人間ではなく機械が読めるコードにすることで、この問題を解決します。第13章のコンテナイメージも、この「環境をコードで再現する」大きな流れの一部です。運用の未来は、こうして着実に「手作業を減らし、コードで管理する」方向へ進んでいます。

🛡️ セキュリティ・運用の視点 — 運用の3本柱が「可用性」を守る

この章で学んだことを、セキュリティの視点から束ね直しましょう。運用の中心にあるのは監視・ログ・バックアップという3本柱です。この3つはそれぞれ、情報セキュリティの三要素(CIA:機密性・完全性・可用性)、とりわけ可用性(Availability=必要なときに使える状態を保つこと)を守るために働きます。

監視は、異常を早期に捉え、サービスが止まる前に手を打つことで可用性を守ります。ログは、障害の原因究明を可能にして復旧を早めるとともに、不正アクセスの検知(セキュリティコース第7章)を通じて完全性・機密性も支えます。バックアップは、最悪データが失われても取り戻せる、可用性の最後の砦です。

第12章で「冗長化は可用性を守る」と述べたことも、ここにつながります。ハードの冗長化(RAID・冗長電源)と、運用の3本柱。この両輪がそろって初めて、「サービスを止めない」という可用性が現実のものになります。派手さはなくとも、この地道な運用こそが、会社の情報システムを日々静かに支えているのです。

14.8 コースの総括 — ここから先へ

おめでとうございます。これで全14章、このコースのすべてを走り抜けました。最後に、ここまで積み上げてきたものを振り返りましょう。

私たちは、第1部でコンピュータとOSの「仕組み」——CPU・メモリ・ストレージ、0と1の世界、プロセスや権限——という一番の土台から始めました。次に第2部で「ターミナルとシェル」を手に馴染ませ、黒い画面を怖れず操る力を身につけました。そして第3部で「ネットワーク」——パケットが届く仕組み、IPアドレス、DNS、HTTPやSSH——を学び、コンピュータ同士がどう会話するかを理解しました。最後の第4部で「サーバーと運用」にたどり着き、その知識が実際のサービスとして、どう構築され、動かされ、守られているのかを見届けました。

この流れは、決してバラバラの知識の寄せ集めではありません。仕組み → ターミナル → ネットワーク → サーバー運用と、一つひとつが次の土台になるように積み上がっています。サーバーの障害対応でログを読むときには第2部のターミナルが、ポートを確認するときには第3部のネットワークが、「なぜメモリ不足で遅くなるのか」を理解するときには第1部の仕組みが——すべてが自然につながって働きます。この「つながり」こそが、あなたがこのコースで手に入れた最大の財産です。

そして、この土台は他のコースへの入り口でもあります。ここで得た知識は、🐍 Python入門コースの自動化、🧑‍💻 一人情シスコースの実務、🛡️ セキュリティ中級・上級コースの防御、そのすべての足場になります。本文のあちこちで他コースへ橋を架けてきたのは、そのためです。

IT技術は、これからも変わり続けます。新しいツールや流行りの言葉は、次々と現れるでしょう。けれど、あなたはもう大丈夫です。「その裏で、何が、なぜ、どう動いているのか」を問う力を、このコースで身につけたからです。流行に振り回されるのではなく、仕組みから理解する——その姿勢さえあれば、どんな新技術も、既知の土台の上に位置づけて学んでいけます。学び続けるあなたを、心から応援しています。ここまで本当にお疲れさまでした。そして、ようこそ運用の世界へ。

まとめ

運用とは「動き続けさせる」こと。サーバーは構築して終わりではなく、監視・保守・障害対応まで一生を面倒見る
構築の基本はSSH接続、systemctlによるサービス管理、apt/yumによるパッケージ管理。enableと計画的なパッチ適用を忘れない
監視の3本柱は死活監視(ping/ps)・リソース監視(top/df/free)・閾値アラート(Zabbix/Prometheus)。異常に先に気づく
ログは/var/logとjournalctlで追う。ローテーションで肥大を防ぎ、集約で横断分析する
冗長化は「止めない」、バックアップは「戻す」。3-2-1ルールで備え、必ず復旧を試す
障害対応はあわてず切り分ける(再現→ログ→仮説→検証→記録)。定番の原因はディスク満杯・メモリ枯渇・証明書期限切れ・設定ミス
手作業はミスの温床。スクリプトと構成管理(Ansible)、IaCで自動化・再現性・記録性を高める

練習問題

問題 14-1

朝、ユーザーから「社内Webシステムにアクセスできない」という連絡が入りました。あなたはサーバーにSSHで入れる状態です。「あわてず切り分ける」手順に沿って、最初に確認すべきことを順に3つ挙げ、それぞれ何のコマンド・場所を見るかを述べてください。

解答を見る

切り分けの手順に沿うと、たとえば次のように進めます。

現象と範囲の確認 — 全員か特定の人か、いつからか、他のサービスは無事かを聞き取り、事実を正確につかむ。まず ping でサーバー自体が生きているかを確認する。
サービスとリソースの確認 — systemctl status nginx でWebサーバーが動いているかを見る。あわせて df -h でディスク満杯、free -h でメモリ枯渇という定番原因をチェックする(ディスク満杯はサービス起動失敗の最頻出原因)。
ログの確認 — journalctl -u nginx --since "1 hour ago" や /var/log/nginx/ のエラーログで、いつから何のエラーが出ているかを突き止める。

ここまでで多くの場合、原因(サービス停止・ディスク満杯・証明書期限切れ・設定ミスなど)の見当がつきます。重要なのは一度に触らず、1つ確認しては次へ進み、対応を記録することです。

問題 14-2

ある会社では、毎晩サーバーのデータを外付けディスクに自動バックアップしています。「これで安心だ」と担当者は言いますが、運用の観点から、まだ足りない点を2つ指摘してください。

解答を見る

復旧を試していない可能性 — バックアップは「取ること」ではなく「戻せること」が目的です。ファイルが壊れていたり、途中から取得に失敗していたりしても、リストアを試さなければ気づけません。定期的に復旧テスト(リストアテスト)を行い、本当に戻せるかを確認すべきです。
保存先が1か所に偏っている — 外付けディスクは同じ拠点にあるため、火災・水害・盗難で本体とバックアップが同時に失われる恐れがあります。3-2-1ルール(3つのコピー、2種類の媒体、うち1つは遠隔地)に照らすと、遠隔地(オフサイト)への保管が足りません。クラウドや別拠点への複製を加えるべきです。

詳しくは一人情シスコース第6章のバックアップ設計を参照してください。

問題 14-3

「監視・ログ・バックアップは、情報セキュリティの三要素(CIA)のうち、主にどれを守るための取り組みか」を答え、その理由を簡潔に説明してください。

解答を見る

主に可用性(Availability)——必要なときにシステムが使える状態を保つこと——を守るための取り組みです。理由は次のとおりです。監視は異常を早期に捉え、サービスが止まる前に手を打てるようにします。ログは障害の原因究明と迅速な復旧を可能にします(さらに不正アクセスの検知を通じて完全性・機密性も支えます)。バックアップは、最悪データを失っても取り戻せる最後の砦です。これらとハードの冗長化(RAID・冗長電源)が両輪となって、「サービスを止めない=可用性」を実現します。運用の3本柱は、地味ながら可用性を支える中核なのです。