設計 → 構築 → 試験 → 監視 → 復旧 → 引き渡しを順番に学習
かんたんに言うとサーバーを1台つくる仕事は、決めて（設計）、組み立てて（構築）、確かめて（試験）、見張って（監視）、壊れたら直して（復旧）、次の担当者へ渡す（引き渡し）という順番で進みます。このページは、その6つの工程を自分で一通りやってみた記録です。
主作品「Server Monitor」は、Ubuntuサーバー1台を題材にした学習課題として作りました。上の6工程それぞれについて、プログラム、設定ファイル、作業手順、結果票（確認した項目と結果を書き込む記録用紙）をひとまとめにしています。そのうえで、実装済み・実測済み・未実施（NOT RUN）の3つに分けて示しています。
2026年8月22日: 自動テスト用の一時的なUbuntu環境で、一連の動作を確認しました。確認したのは、構築、もう一度同じ手順を実行したときの結果、11個のサービスの起動、通信の制限、監視、復旧、バックアップからの復元です。23項目すべて合格しています。なお、Dockerはあらかじめ導入済みの環境です。
2026年8月23日: 新しい版を確認したあと、前の版へ戻す「切り戻し」の自動テストにも合格しました。詳しい結果はGitHub上に公開しています。ただし、継続して使い続ける実機（本物のパソコンやサーバー）や仮想マシンでは、まだ実施していません。
対象読者: Linux未経験の方も対象です。手を動かすには、練習用のLinuxを1つ用意してください。用意するものは、UbuntuまたはRHEL系（Red Hat系のLinux）のVM（仮想マシン。パソコンの中に作るもう1台のコンピューター）です。Windowsをお使いなら、WSL2（Windowsの中でLinuxを動かす機能）とターミナル（文字で命令を打つ画面）でもかまいません。環境をお持ちでない場合は、先に学習環境を0から用意するをご覧ください。
changed=0：構成管理ツール（Ansible）を2回目に実行しても、変わった箇所が0件という意味です。冪等性（同じ操作を何度実行しても結果が変わらない性質）を確認するために使います。
D-1 / D-2：障害復旧演習の呼び名です。D-1は、アプリのプロセス（動いているプログラム）をわざと止めて、自動で復旧するかを見る演習です。D-2は、サーバー本体が壊れた想定で、別のサーバーへ復元する演習です。D-2はこのLabではNOT RUNです。
NOT SET / NOT RUN / NOT READY：NOT SETは値がまだ確定していない状態、NOT RUNは手順はあるが未実行の状態、NOT READYは完了と判定するための条件がまだ揃っていない状態を指します。
主な確認結果
かんたんに言うと下のカードは、自分で試して記録が残っている結果の一覧です。カードをクリックすると、その根拠になった記録ファイルを見られます。
現在の実測済み・NOT RUNは、現行main（GitHubで公開している最新版）の証跡台帳（確認した記録をまとめた一覧表）を正本、つまり最も信頼できる原本とします。23項目の自動テストと前の版へ戻すテストは、2026年8月22日・23日の一時環境での履歴です。監視サービス9個の起動と13秒での復旧は8月17〜19日の履歴です。2分15秒の動画も当時の画面とログを再構成したもので、連続した操作録画ではありません。
テスト環境にはDockerが最初から入っていました。何もないOSへの導入はDocker公式のUbuntu向け導入手順を想定しています。ただし、この導入作業そのものはまだ行っていません。次の項目もすべてNOT RUN（手順はあるが未実行）です。何も入っていないOSからの構築、独立した対象hostと管理端末での受け入れ、実際のSlack通知、AWSのapply/destroy、D-2、別サーバーへの復旧、再起動後・24時間・72時間の確認、そして本番環境での利用です。
作成した12種類の番号付き成果物
実際の構築案件では、作業のたびに決めたことと確かめたことを書類として残します。ここでは、その流れをまねて、00から11まで番号を付けた12種類の資料を自分で作りました。番号順に読むと、何を決め、どう作り、どう確認し、どう引き渡すのかが追えます。
- 00目的と条件資料を見る
- 01全体の設計資料を見る
- 02詳しい設計資料を見る
- 03設定値の一覧資料を見る
- 04通信の設計資料を見る
- 05構築手順資料を見る
- 06動作確認の手順資料を見る
- 07引き継ぎ確認資料を見る
- 08変更を戻す手順資料を見る
- 09実機での確認手順資料を見る
- 10立ち上げ・受け入れ資料を見る／対象hostはNOT RUN
- 11作業結果・引き渡し報告原本を見る／実案件欄はNOT SET
05 構築手順書の要点（要約）
資料そのものは長いため、流れだけをここに要約します。詳しい手順・コマンド全文は原本をご覧ください。
- 作業前確認：作業を始める前に、条件を先に決めて固定します。決めるのは、対象VM（作業する仮想マシン）、sudo（管理者の権限で命令を実行する仕組み）が使えるかどうか、対象IP、作業時間、ロールバック条件（元に戻すと判断する基準）、対象commit SHA（変更履歴の1点を指す番号）です。作業中に迷わず、後から同じ状態を再現できるようにするためです。
- 準備〜構築：まず、作業する側のパソコン（管理端末）にAnsibleを用意します。次に、inventory（作業対象のサーバー一覧）と、パスワードなどの秘密値（vault）を設定します。そのうえで
--check --diffを付けて実行し、実際には変更せずに何が変わるかだけを先に確認します（プレフライト確認）。問題がなければ本番どおりに実行します。 - 冪等性確認：同じplaybook（Ansibleの作業手順書ファイル）をもう一度実行し、
failed=0かつchanged=0であることを記録します。2回目でも何も変わらなければ、手順が何度実行しても安全だと言えます。 - 構築後確認・障害試験：まず、サービスが動いているか、ポート待受（外からの通信を受け付けている状態）になっているかを確認します。そのうえでD-1（プロセス停止）演習を行い、異常に気づくまでの時間と復旧までの時間を記録します。止まったときに何秒で戻せるかを数字で言えるようにするためです。
- ロールバック・作業終了：問題があれば、変更前のcommit（変更履歴の1点）まで戻します。これがロールバック（元の状態へ戻すこと）です。最後に結果票とログを保存し、作業結果報告書へ写して作業を終えます。
構築・運用の確認一覧
表に出てくる道具の名前を先に補足します。Prometheusは数値を集める道具、Grafanaは集めた数値をグラフで見せる画面、Lokiはログを集める道具、Alloyはそれらへデータを送り届ける役、Alertmanagerは異常を知らせる役です。webhookは、異常が起きたときに別のプログラムへ自動で知らせを送る仕組みを指します。
| 工程 | 設定・資料 | 動作確認したこと | 次に確認すること |
|---|---|---|---|
| 設計 | 要件、基本・詳細設計、パラメータ、ネットワーク | 実装済み（文書） | 実案件のレビュー・承認はNOT SET |
| 構築 | Ansible、Docker Compose、Webアプリ、監視構成 | 実測済み：2回目changed=0、11サービス起動 | Docker未導入の最小OS・対象hostはNOT RUN |
| 試験 | 試験仕様書、結果票、ネットワーク確認手順 | 実測済み：一時Ubuntu環境で23項目合格 | 独立した対象hostと管理端末での受け入れはNOT RUN |
| 監視 | Prometheus、Grafana、Loki、Alloy、Alertmanager | 実測済み：監視・ログ・手元のwebhook通知を確認 | Slack実通知と72時間稼働はNOT RUN |
| 復旧 | アプリ停止、ネットワーク障害、復旧手順書 | 実測済み：D-1と同一環境へのデータ復元 | D-2と別サーバーへの復元はNOT RUN |
| 引き渡し | チェックリスト、切り戻し、受け入れ、作業結果報告 | 実装済み：原本・自動採録スクリプト | 対象hostの受入判定はNOT READY / NOT RUN |
第二志望の補助学習：ここから下は、ITサポートの仕事を想定した設計例です。Windows、Microsoft 365、Active Directory（社内のパソコンと利用者アカウントをまとめて管理するMicrosoftの仕組み）についての問い合わせ対応を学ぶために作りました。実際の組織の環境を構築・運用した実績ではありません。第一志望のLinuxサーバー設計・構築とは分けて掲載しています。
かんたんに言うと下の図は、会社の中のネットワークを用途ごとに部屋分けした設計例です。VLANはその「部屋」にあたる区切りで、外部に見せるサーバー、社内サーバー、社員のパソコン、来客用Wi-Fiを別々にしています。分けておくと、1か所で問題が起きても他へ広がりにくくなります。
想定運用シナリオ
- 問い合わせ受付後、端末・ネットワーク・アカウント・ライセンスを順に確認する。
- 確認した結果は、問い合わせ記録（チケット）へ添付しやすいJSON・CSV・HTMLの形式で残す。
- 利用者影響、再現性、変更履歴、セキュリティ影響を見てエスカレーションを判断する。
- 対応後は再発防止メモとナレッジ更新候補を残す。
セグメント設計の考え方
- DMZ VLAN 10: 外部へ公開するサービスだけを置く区画。ここから社内側のVLANへ戻る通信は、ACL（通信を許可・拒否する条件の一覧）で明示的に許可したものだけ通す。
- Server VLAN 20: AD/DNS/DHCP/ファイル/監視。クライアントVLANから必要ポートのみ許可。
- User VLAN 30: 業務端末。サーバーVLANへは必要ポートのみ、Guest VLANは完全分離。
- Guest / IoT VLAN 40: インターネット出口のみ許可。社内資産には到達不可。
- Microsoft 365: クラウド側の利用者管理であるEntra IDと、同期の仕組みであるEntra Connectを使い、社内に置いたAD（Active Directory）とアカウント情報をそろえる。条件付きアクセスの設定で、会社の基準を満たした端末以外は接続させない。
| 対象 | 確認観点 | 使用スクリプト・確認記録 | 最初の対応 / 引き継ぎ基準 |
|---|---|---|---|
| 端末ヘルス | OS、空き容量、更新、Defender、Firewall、BitLocker | Collect-PcInventory.ps1 Test-SecurityBaseline.ps1 |
警告項目をチケットへ添付し、設定変更が必要な場合は管理者へ引き継ぐ。 |
| ネットワーク | 本人のみか全体か、IP、DNS、ゲートウェイ、外部到達性 | Test-NetworkTriage.ps1 network-triage.sample.csv |
複数端末で不可ならネットワーク機器・回線側として上位担当へ連携する。 |
| 性能・ログ | CPU、メモリ、ディスク、直近エラー、発生時刻 | Test-DiskCapacity.ps1 Get-RecentSupportEvents.ps1 |
ディスク90%以上、同一エラー反復、業務停止がある場合は影響範囲を添えて引き継ぐ。 |
| AD / M365 | 休眠アカウント、所属グループ、ライセンス割当、利用率 | Get-StaleUserAccounts.ps1 Get-M365LicenseInventory.ps1 |
権限変更・停止・ライセンス回収は申請情報と承認の有無を確認してから実施担当へ渡す。 |
受付
現象、発生時刻、対象者、業務影響、再現条件を確認。
原因の場所を絞る
端末、ネットワーク、アカウント、サービス側のどこに原因があるかを、順番に切り分けます。
結果を保存
確認コマンド、ログ、スクリーンショット、出力ファイルを添付。
対応・連携
自分の担当範囲で解決しない場合は、影響した範囲と考えられる原因を添えて引き継ぎ。
再発防止
同じ問い合わせを繰り返さないために、手順書の更新、よくある質問（FAQ）への追加、監視項目の追加、定期点検の対象にすることを検討します。
関連する学習内容
最初に見ていただきたいのはLinuxサーバーの構築手順と確認資料です。Windows、Microsoft 365、Active Directory、クラウド、問い合わせ対応の資料は補助学習として掲載しています。
以下は関連資料へのリンクです。英字の名前が並びますが、SLOはサービスの品質目標、Error Budgetは許される失敗の量、Runbookは手順書、Postmortemは障害の振り返り記録、Production Readinessは本番で使ってよいかの点検表を指します。