2分で分かる動作確認のまとめ
読み方: 「何を確認したか → どの環境か → どの版か → 何が未実施か」の順に見ます。過去の合格は、その記録に書かれた版と環境での結果です。現在のコード全体の再試験結果や、閲覧者自身の実績には置き換えません。自分の記録と説明の型も使えます。
Ubuntuの結果票では、Hyper-VのVMへfoundation.yml（基本設定とDocker）を適用し、鍵での接続、Dockerの動作、2回目の不要な変更なしなどを確認しています。対象版は結果票に記載された44cf16aです。
AlmaLinux 9.7の結果票も、同じ基盤の適用と再実行を記録しています。ただし以前使ったVMの再利用で、別用途のサービスが残っています。新規構築・SSHだけの最小公開は未証明です。対象版は結果票の表記どおり537d9be相当です。
いずれも個人学習で、監視構成全体のsite.yml適用、72時間稼働、再起動後確認、本番運用の完了を示していません。以下の8月の自動テストとは別の記録です。
かんたんに言うとこのページは「作っただけのこと」と「実際に動かして確かめたこと」を分けて書いた記録です。実装済みはコードや資料を用意した状態、実測済みは日付と環境を残して実際に動かした状態、未実施（NOT RUN）はまだ実行していない状態を指します。
このページでは、コードや資料を作っただけのことと、実際に動かして確かめたことを分けて書いています。それぞれについて、実行した日、使った環境、対象版（試験に使ったプログラムの版）、実行したコマンド、結果を記録しました。くわしい内容はリンク先で確認できます。なお、このあと出てくる「証跡台帳」とは、いつ何をどこまで確かめたかをまとめた一覧のことです。
構築から復旧までを自動で確かめる23項目の試験を行いました。あわせて、前の版への切り戻し（新しい版に問題が出たときに、ひとつ前の版へ戻す作業）も試しました。ディスク、データベース、ネットワークの練習も行いました。実際に動かして見つけた問題29件と、誤って合格にしていた6件も記録しています。これは、使い捨ての一時的なUbuntu環境、WSL2（WindowsのなかでLinuxを動かす仕組み）、Docker（アプリを小さな箱に入れて動かす仕組み）などで得た結果です。継続して使う独立した対象サーバーでの受け入れ実績ではありません。
2026年8月の主な結果
主な確認内容
新しい版から前の版へ戻せることを確認
新しい版を動かしたあと、指定した前の版へ戻しました。戻したあとに、アプリの版が正しく戻ったかを確認しました。不要なファイルが消えていること、管理画面を外部へ直接公開しない設定であることも確かめています。ログを受け取れることも、もう一度確認しました。下に並ぶ長い英数字は、その版を表す記号（コミットID）です。一時的なUbuntu環境での結果で、継続利用するサーバーでは未実施です。
自動テストの詳細を見る同じ構築手順を2回実行
同じ自動構築の手順を2回実行し、2回目には不要な変更が発生しないことを確認しました。これは、同じ手順を何度実行しても結果が変わらないことを確かめるためです。2回目で何も変わらなければ、この手順は安心して繰り返せると言えます。使ったのはDockerがあらかじめ入っている一時的なUbuntu環境です。Dockerを最初から導入する部分は、この試験には含まれません。
23項目の記録を見る監視に必要な11個のサービスを起動
監視に必要な10個のサービスと、通知を受け取るテスト用サービスを起動しました。異常を検知した通知と、復旧した通知の両方を確認しています。テスト環境の中では、異常を知らせる仕組みが動いたと言えます。ただし、Slackへ実際に送信する試験ではありません。
起動・通知の記録を見るDockerの情報は読み取りだけ許可
監視サービスからDockerの情報を読む操作は許可し、設定を変える操作は拒否できることを確認しました。これは、監視に必要な情報だけを渡し、万一乗っ取られたときの被害を小さくするためです。ログも監視画面へ届いています。読み取り権限は残るため、考えられる危険と対策をセキュリティ方針に記録しています。
通信制限の記録を見るテスト環境内のネットワークを確認
一時的なUbuntu環境の中で、ネットワークの設定を確認しました。待ち受けポート（外からの通信を受け付ける番号）、ファイアウォール（決めた条件で通信を許可・拒否する関所）、サービス同士の通信も確かめています。別の管理用PCや継続利用するサーバー、社内DNS（社内で名前とアドレスを対応づける仕組み）を使った通信は未実施です。
ネットワーク確認の記録を見るアプリを1秒で復旧し、監視データも復元
アプリの動作を意図的に止め、1秒で自動復旧することを確認しました。わざと止めるのは、本番で同じことが起きても自動で元に戻せるかを確かめるためです。目標にした5分以内を満たしています。監視データ3種類もバックアップから元に戻せました。
復旧の記録を見る自動テストの結果 — 2026年8月22日 / 23項目すべて合格
かんたんに言うと人が手で操作する代わりに、決められた23項目をコンピューターが順番に試して、すべて合格した記録です。ただし、使い捨ての一時的な環境で行った結果です。
2026年8月22日、特定のコードの版を使って、構築から復旧までの23項目を自動で確認し、すべて合格しました。詳しい実行記録には、日付、コードの版、確認方法を残しています。8月19日の結果は、以前の確認範囲を示す記録として別に保存しています。
| 区分 | 確認済み | どこまで試したか | 状態 |
|---|---|---|---|
| 構築・再実行 | 同じ構築手順を2回実行し、2回目に不要な変更が出ないこと | Docker導入済みの一時Ubuntu環境 | 合格 |
| 起動・通知 | 11サービスの起動と、異常・復旧の通知 | テスト環境内の通知のみ。Slackへの送信は未実施 | 合格 |
| Docker情報の読み取り制限 | 情報は読めるが、設定を変える操作は拒否されること | 対象版 7622a9d の自動テスト内 |
合格 |
| ネットワーク | 通信経路、待ち受けポート、ファイアウォール、サービス間通信 | 同じ一時環境内のみ。別の管理PCや社内DNSは未実施 | 合格 |
| 障害・データ復旧 | アプリを1秒で復旧し、監視データ3種類を復元 | サーバー本体の故障と長時間の連続運転は未実施 | 合格 |
前の版へ戻す試験は、翌日の別の自動テストで合格しました。次のことは未実施（NOT RUN／まだ実行していないという意味）です。独立した対象サーバーでの切り戻しと受け入れ試験、72時間の連続運転、サーバー再起動後の確認、Slackへの実通知、AWS（インターネット越しに借りるサーバー）での構築（apply）と削除（destroy）、演習D-2、別の管理PCや社内DNSからの通信です。新しい最小OSへDockerを導入する確認も含みません。
4つの追加練習 — 2026年8月24日に実行
かんたんに言うとよくあるトラブルをわざと自分で起こして、直す練習をした記録です。B-1からB-4は、その練習に付けた番号です。
ディスク容量の追加、問題が起きた場所の確認、データベースの復元、ネットワーク設定の確認を練習しました。いずれもAI支援を使える学習環境で実行した結果です。下の表にある「220M→457M」は、使える容量が約220メガバイトから約457メガバイトに増えたことを表します。手元のWSL2とDockerで再現できる「問題箇所の確認」と「データベース復元」は、面接でも再実演できます。
| 演習 | 内容 | 結果 |
|---|---|---|
| B-1 ディスク容量の追加 | 使える領域を作り、容量が足りなくなった状態から領域を広げる | 5項目合格 / 不合格0（220M→457M） |
| B-2 問題が起きた場所の確認 | Web・アプリ・データベースのどこで止まっているかを順に確認する | 9項目合格 / 不合格0 |
| B-3 データベースの復元 | バックアップからデータベースを戻し、内容が元と一致するか確認する | 7項目合格 / 不合格0（復旧0.149秒） |
| B-4 ネットワーク設定の確認 | 同じネットワーク内と、別のネットワーク間の通信設定を確認する | 6項目合格 / 不合格0 / 環境の制約で3項目は未実施 |
自動テストで見つけた失敗から修正まで
成功した結果だけでなく、自動テストで見つかった問題と修正内容も残しています。詳しい記録には、テストの実行番号とコードの版を記載しています。
2026年8月19日：失敗から原因を考えて確認するまで
現象
最初はアプリを停止しても自動復旧せず、5分で試験を中止しました。
仮説と再試行
停止方法が自動復旧の動きに影響したと考え、実際のアプリ処理を停止する方法へ変えました。2回目は手元のコードが古いことに気づきました。
条件を揃えて合格
正しいコードを取り直して3回目を実行し、停止から13秒で復旧しました。2026年8月19日の記録で、目標にした5分以内の復旧を確認できます。
2回の失敗、考えた原因、手順の変更、3回目の成功を同じ記録に残しています。13秒は8月19日の結果で、8月22日の自動テストでは1秒で復旧しました。
2分15秒の動作確認記録
操作を最初から最後まで連続撮影した動画ではありません。8月22日に行った23項目の自動テストや、Slackへの実際の通知も、この動画には含まれません。