デプロイと監視 ― 現場の運用サイクル

導入

サービスは、公開して終わりではありません。新機能を出す（デプロイ）、問題が起きていないか見張る（監視）——この繰り返しが「運用」です。ここまで学んだコマンドが、日々どう回っているのかを見ておきましょう。

説明

新しいコードを本番サーバーに反映する デプロイ は、おおよそこんな流れです（第10章のスクリプトで自動化されることがほとんど）。

flowchart LR
    G["新しいコードを取得<br/>（git pull など）"] --> B["ビルド/準備"]
    B --> R["サービス再起動<br/>sudo systemctl restart（第7章）"]
    R --> C["動作確認<br/>curl で200が返るか（第6章）"]
    C --> W["ログ監視<br/>tail -f / journalctl（第7・9章）"]

デプロイ中・デプロイ後は、必ず確認します。ここで大活躍するのが、このコースで学んだ道具です。

• curl -I http://localhost … アプリがちゃんと 200 OK を返すか（第6章）
• systemctl status アプリ … サービスが active (running) か（第7章）
• tail -f logs/app.log | grep ERROR … 新しいエラーが出ていないか（第9章）
• top / df -h … 負荷やディスクは大丈夫か（第7章）

監視は、これを人がずっと見張るのではなく、自動化するのが現場です。第10章の cron で定期チェックを回し、異常があれば通知する。ログが溜まりすぎてディスクを圧迫しないよう、古いログを自動で整理（ローテーション）する。「仕組みが自分を見張る」状態を作るのが、運用の理想です。

flowchart TD
    subgraph 運用サイクル
      D["デプロイ<br/>（新機能を出す）"] --> M["監視<br/>（異常を見張る）"]
      M --> F["問題発見<br/>ログ・リソースから原因特定"]
      F --> X["修正・対応"]
      X --> D
    end

障害が起きたときの調査は、このコースの流れそのものです。「ping で届く？→ curl で返る？→ systemctl status で動いてる？→ journalctl/tail で何が起きた？→ top/df でリソースは？」。下の層から上の層へ、外から内へと切り分ける（第6章のTCP/IP階層の考え方）。この手順が身につけば、初めて見るトラブルにも落ち着いて対処できます。

この章のまとめ

• 運用は「デプロイ（出す）→監視（見張る）→対応」の繰り返し
• 確認には curl・systemctl status・tail -f・top・df がそのまま使える
• 監視は cron で自動化するのが現場。「仕組みが自分を見張る」状態を作る
• 障害調査は「外→内・下の層→上の層」で切り分ける