The Operations Loop 検証記録 — 登録成功から障害復旧まで

AI_Manager

検証の基準は、画面が開くかどうかではなく、データとパスが実際につながっているかどうかだ。この記事では、2026-09-20のVirtualBox実習で実行したタスクと観測結果を記録する。設計上の期待、実際のテスト、まだ実施していない範囲を区別する。

この記事の流れ

1. 検証環境と判定基準
2. 実際の正常オンボーディング記録
3. 正常なパスに至るまでに発見し修正した問題
4. バックアップと隔離復元
5. 中央ノード障害テスト
6. Proxy切断と遅延データの再送
7. 資産データの保護とパス検証
8. インターネットのない環境でのターゲットインストールとパッケージ検証
9. アーキテクチャ画面検証
10. 検証チェックリストと境界
関連資料と構成情報

1. 検証環境と判定基準

Rocky Linux 10.2、Zabbix 7.0.30 LTS、NetBox 4.7.1、AWX 24.6.1を使用した。中央の2台のVMとクォーラム、Gateway、Provision、3つの環境のProxy/Bastionを構成した。すべてのVMは1台の物理PCのメモリ、CPU、ストレージを共有する。

正常なオンボーディングは、PXEインストール → 承認されたSSHパス → 実際の資産収集 → NetBoxネイティブIPAM → Zabbix登録 → NetBoxベースのAWX inventory sync → 実際の最新値の確認まで、すべて成功して初めて合格となる。API登録のレスポンスと最新データの受信は別のチェック項目である。

2. 実際の正常オンボーディング記録

PRODターゲットは、空の32GiBディスクと内部ネットワークNIC1つでインストールした。2026-09-20 04:13 KSTにBastion経由のSSHでRocky 10.2、10.77.20.101/24、SELinux Enforcing、PXEインストール完了の目印を確認した。インストールのために4GiBにしたRAMは、正常終了後に1GiBに調整した。

証拠	観測結果
AWX Workflow	22, successful
実行時刻	04:28:27~04:31:05 KST, 約158秒
Onboard Job	23, successful
NetBox inventory update	24, successful
Verify Job	26, successful
Git コミット	58bb87b9842c159b1986784062916c4d9eb97c00
NetBox アセット	VM ID 1, fml-prod-app-01
IP 関係	VM Interface ID 1 → IPAddress ID 1 → primary_ip4 10.77.20.101/24
収集状態	complete, collection_errors 空の配列
Zabbix	hostid 10683, proxyid 1, templateid 10343
実際の収集	system.uptime itemid 50799, state 0, エラーなし

Verify Jobは lastclock=1789846239, lastvalue=942 を確認し、検証時刻は 1789846262 であった。検証時点より23秒前に収集した実際の uptime 値である。この値は例として作成した数値ではなく、Job 結果から読み取った記録である。

NetBoxには vCPU 1、ゲスト使用可能メモリ 954MiB、ディスク 32768MiB、Rocky Linux 10.2、仮想化タイプ virtualbox、管理 NIC enp0s3、PROD環境と実際のパーティション構造が保存された。ゲストのメモリ観測値 954MiB と VirtualBox 割り当て値 1024MiB は異なる値である。

AWX の NetBox inventory には ansible_host=10.77.20.101, ansible_user=labadmin, fml_environment=prod, fml_subnet=20 が取り込まれた。単にアセット名だけを同期したのではなく、管理 IP と Bastion 経路の計算に必要な環境変数を一緒に確認した。

DEV も空のディスクから PXE インストールした後に Workflow 30 を実行した。05:00:40~05:03:34 KST に Onboard 31, inventory update 32, Verify 34 がすべて successful で終了した。Zabbix host 10684, proxy 2, uptime item 50884 で PROD とは異なる環境に接続された。

STG はインストールの完了検出により自動実行

STG の最初の SSH 信頼を VirtualBox serial console の公開鍵・fingerprint で承認した後、インストール RAM を 4GiB から 1GiB に減らした。インストール完了コントローラーが承認キー、インストールマーカー、hostname・machine ID を確認し、SCM・bootstrap inventory を同期した。その後、手動の Workflow 実行なしに Job 38 を開始した。

STG の証拠	結果
Workflow 38	10:11:29~10:14:25 KST, successful
Onboard / inventory / Verify	39 / 40 / 42 すべて successful
Git コミット	8877198864680095a1a8b5684d3382b9034237e9
NetBox	VM 3 → Interface 3 → IPAddress 3, 10.77.40.101/24
収集状態	complete、collection_errors 空の配列
Zabbix	host 10685、proxy 3、uptime item 51005
検証データ	lastclock 1789866845、lastvalue 292、verified_at 1789866862
コントローラーの状態	該当のmachine IDとWorkflow 38をsuccessfulとして保存

検証時刻より17秒前の実際のuptime値まで確認した。AWXのNetBoxインベントリでも、PROD・DEV・STGの3ホストと各管理IP・環境変数が照会された。最初のSSH身元承認は意図的に残した管理段階であり、未承認キーをバイパスして自動接続したわけではない。

3. 正常な経路まで発見して修正した問題

実行	失敗地点	原因と修正
Workflow 7 / Job 8	Agent RPM metadataのダウンロード	Minimal ISOにBaseOS/AppStreamパスがなく404。実際のMinimalリポジトリに変更
Workflow 12 / Job 13	NetBox APIローカルタスク実行前	インベントリの権限昇格変数がdelegate_to localhostにも適用され、EEにないsudo呼び出し
Workflow 17 / Job 18	同じローカル作業	既存のinventory変数の影響まで考慮し、task varsのansible_become=falseとEE Pythonパスを明示
Workflow 22 / Jobs 23・26	全体的なフロー	資産・IPAM・監視登録、インベントリ更新、実際の収集検証に成功

失敗した作業も削除しなかった。修正コミットと次のJob結果を比較できるように残した。NetBox/Zabbix登録前に失敗した場合を、実際の資産が重複生成された状況と混同しない。

4. バックアップと分離復元

2026-09-20 04:40 KSTにNetBox DBをpg_dump custom formatでバックアップし、本番NetBox DBとは異なるnetbox_restore_20260919194012にpg_restoreした。復元DBからVM ID 1、fml-prod-app-01、primary_ip4_id 1を照会した。

バックアップのSHA-256は06914eb419d88edb97245ed435177b396309a625b65eb14b72ae9fb627667390である。既存DBを上書きせず、別途の検証DBを使用した。この結果はNetBox論理DB復元テストであり、すべてのVM・メディア・AWX・Gitを一度に復旧するディザスターリカバリテストではない。

5. 中央ノード障害テスト

最初のテスト直前、PostgreSQL leaderはops02、ops01はsync standbyであり、レプリケーションラグは0だった。Zabbixはops01 active、ops02 standbyだった。1号機の電源を強制的に落とし、VMの電源損失を再現した。

VIP 10.77.10.10は2号機に移動した。しかし、切り替え区間でNetBox backendが500を返し、VIPは503を返した。Zabbixはその後2号機でactive作業を開始し、3つのプロキシからの接続を受け付けた。このテストを「無停止HA成功」とは判定しなかった。

観測ツールの最初のログファイルは、SELinuxポリシーに合致しないパスのため作成されなかった。したがって、そのテストで精密なRTOは算出しない。ログ記録パスを/var/logの下に移し、正常な記録を確認した後に再テストを行った。

NetBox 4.7.1の実際の設定コードを確認したところ、cachingのSENTINEL_TIMEOUTはタスクキューと同じ方式でマッピングされていなかった。timeoutのみを追加した二回目のテストでも、キャッシュの照会一回に55.6秒がかかった。この時、1号機の電源遮断後のNetBoxからの最初の成功応答は約104秒後だった。その後、ローカルSentinel優先照会と明示的なリトライ制限を合わせて適用した。

修正後、DB・Redis・Zabbixがアクティブな2号機の電源損失

05:08:20.777 KSTにops02を強制終了した。直前までops02がPostgreSQL primary・Redis master・Zabbix activeであり、ops01はDB sync standby/lag 0であった。1号機から5秒間隔、リクエストタイムアウト4秒で独立したAPIを照会した。以下の値は、障害命令時刻から当該状態を最初に観測した時刻までのものであり、精密な内部切り替え時間や保証SLAではない。

項目	最初の正常観測	障害命令後
PostgreSQL ops01 primary	05:08:57.775	約37秒
NetBox既存資産API照会	05:09:02.318	約42秒
Zabbix API応答	05:09:02.318	約42秒
AWX ping	05:09:30.637	約70秒
障害以降に収集時刻を持つZabbixの値	05:10:12.302	約112秒

05:10:11に2号機が停止した状態で、NetBox資産のcommentsにテスト用マーカーをPATCHし、GETで読み込んだ後、元の内容に復元した。資産ID 1およびprimary IPは維持された。照会画面が開くだけでなく、稼働中DBパスへの書き込みも確認した。AWXのping回復は、実行中だったジョブの無停止を意味するものではない。このテスト中に新しいジョブを実行して成功した結果として過大解釈しない。

2号機は05:11:19に再起動した。PostgreSQLはtimeline 3に沿って復旧し、05:18の点検でsync standby/lag 0であることが確認された。NetBoxは初期化とPython workerの起動のために準備が遅れ、05:23の点検でhealthy・HTTP 200を確認した。サービスの生存時間と、障害ノードが再び予備容量に復帰する時間は異なる。

修正後VIP・DB・Zabbixアクティブ1号機の電源喪失

反対方向もテストした。05:24:28.045 KSTにops01を強制終了した。ops02でVIP 10.77.10.10を確認し、PostgreSQL primaryは約39秒後、エラー後のZabbix API正常応答は約44秒後、NetBox資産照会は約69秒後、障害後時刻の監視値は約111秒後に観測された。資産IDと管理IPは維持された。

AWXはops01にのみ存在するため、ノードが停止している間はアクセスできなかった。05:26:44にops01を再起動した後、05:29:24にAWX pingが回復した。この値はAWX自体のHA成功ではなく、元のノード復旧に伴うサービス再開である。再起動後、PostgreSQLはtimeline 4のsync standby/lag 0に戻り、NetBox Appもhealthyであった。

両方のテストにおいて、切り替え区間のタイムアウト・HTTP 500/503が含まれる。「無停止」とは記載しない。類似のテストにおける改善前後の数値は、当時のDBのアクティブ位置や負荷が異なるため、単純な割合で性能改善効果を断定しない。

6. Proxyの切断と遅延データの再転送

05:12:43 KSTにGatewayでPROD Edge 10.77.20.10 → 中央帯域TCP 10051のみを遮断した。SSH・Agent→Proxy・DEV経路は維持した。中央PRODのuptimeはclock 1789848759で停止したが、DEVは30秒周期で更新され続けた。

PROD ProxyのSQLiteを読み取り専用で照会したところ、中央にまだ存在しないclock 1789848879などの値がproxy_historyに存在していた。SQLiteの総行数には整理前の転送完了行も含まれる可能性があるため、行数自体を「未転送数」として解釈しなかった。

一時ポリシーにtimeout=240を指定したが、05:18:52の確認時にもルールが残っていた。該当するテストルールを明示的に削除し、実際の遮断区間は約6分9秒と記録した。タイマーオプションだけに頼って4分後に復旧したとは記載しない。反復テストでは、外部の復旧予約とルールの不在確認を合わせて実施する。

05:19:30の中央history.getの結果には、1789848789、8819、8849、8879から9119まで、切断中に収集した値が再び現れ、30秒間隔を維持した。最新の値も1789849149に更新された。転送中断中のローカル収集 → ディスク保管 → 復旧後の本来の時刻の履歴反映を実際のデータで確認した。この短いテストは、24時間のバッファ保持・ディスクフル・Proxy VM自体の障害までを検証したものではない。

7. 資産データの保護と経路検証

実際のPROD収集結果を基準に、同じNetBox登録を再度実行した。VM ID 1とIPAddress ID 1が維持され、同じ名前・アドレスがそれぞれ1つずつ存在した。収集時刻の更新と重複資産の生成を区別した。

注入した条件・実際の経路	判定
PROD資産へのDEV管理IPの伝達	API変更前に拒否、mutation 0
既存のアセットと異なるmachine IDを渡す	API変更前に拒否、mutation 0
別のアセットで使用中のIPを渡す	新規アセット作成前に拒否、mutation 0
CPU・ディスク・ネットワークの収集失敗を明示的に注入	既存のCPU・パーティション・製品フィールドを保持し、partialを表示
正常な収集結果を再適用	complete状態を復元
異なるmount namespaceの製品プロセス	ホストのバージョン実行ファイル・JARの参照を呼び出さない
中央 → PROD対象直接SSH	拒否
中央 → 各環境Bastion SSH	許可
PROD → DEV SSH	拒否
PROD → 外部 1.1.1.1:443	拒否
PROD → ローカルProxy・内部RPMリポジトリ	許可

部分的な収集失敗はテスト用に作成した入力であり、実際のディスク故障事例として紹介するものではない。拒否条件を先検査した後に変更し、一部のAPIのみ成功した状況では成功したオブジェクトを無条件に削除せず、再実行につながるようにした。

8. インターネットのない対象へのインストールとパッケージ検証

PXE対象はInternal Network NICを1つだけ持ち、NAT・ブリッジNICはない。OSはProvisionのRocky 10.2 Minimalインストールツリーから取得した。PRODのAgent RPMキャッシュをクリアした後、内部リポジトリ2つだけを有効化してzabbix-agent2 7.0.30を再インストールした。実際の6.4MBのダウンロードとGPG検証、サービスのactiveを確認した。

外部接続が拒否された同一の対象で、内部repo metadataとCA検証を使用するNetBox HTTPSが200を返した。中央全体の新クローズドネットワーク再インストールは別範囲である。今回確認したのは、インターネットのない対象のOSインストール・Agentデプロイ、および内部API連携である。

9. アーキテクチャ画面検証

画面・機能	結果
1920×1080 フルスクリーン	中央サービスと3環境の12ノード、タブ・説明・下部フローが画面内に表示
画面合わせ倍率	graph-scroll client 1590×740、scroll 1590×740。デフォルト倍率で切れなし
本文幅 784px	全体構造を表示、説明パネルのみ独立スクロール
モバイル 390×844	本文の横方向のはみ出しなし、小さな構成要素も下部の説明エリアに配置
全体 / 自動化 / モニタリング / 障害	タブとNetBox・IPAMの段階、Witness/NFSの障害説明を確認
拡大・復帰	125%拡大、全体表示100%、全画面表示の開始・終了を確認
ブラウザエラー	収集されたconsole errorなし

アーキテクチャの障害状態とフローの再生は説明用である。サーバーにコマンドを送信したり実際の状態を表示したりする運用ダッシュボードではない。

10. 検証チェックリストと境界

点検項目	結果・根拠
Rocky実インストール / SELinux Enforcing	PROD・DEV・STGの実ゲスト確認
NetBox詳細フィールド・IPAM・primary IP	実資産・Interface・IPAddressの関係確認
NetBoxベースのAWX inventory	Workflowのsource updateと接続変数の確認
Zabbix API登録以降の実データ	PROD・DEV・STGのuptime・lastclock確認
インストール完了検知 → AWX自動実行	承認者確認後、STG Workflow 38自動実行・成功
資産再実行・アドレス競合・識別子変更	重複なし、競合入力変更前は拒否
部分的な収集失敗時の既存値保存	障害注入テスト通過後、正常観測に復元
中央アクティブノードの電源喪失	DB昇格・API再開・新しい監視データ・書き込み確認
障害ノードの復帰	PostgreSQL sync standby、lag 0、App healthy
Proxy送信切断	SQLite保管と中央履歴のbackfill確認
環境通信制限 / Bastion経路	許可・拒否経路別の接続確認
内部RPMダウンロード / 署名	キャッシュをクリアした実際の再ダウンロード・再インストール成功
NetBox 論理DBバックアップ・復元	別DBでの同一資産・IP参照確認
フルスクリーン・モバイルアーキテクチャ	FHD 1920×1080、本文784px、モバイル390px確認
物理サーバー UEFI/BMC/RAID	未実施
中央全体の新規定常閉域再構築	手順作成、全体再インストール試験未実施
NFS・quorum・Gateway・Proxy VMの単体障害	影響分析、該当障害インジェクションは未実施
全体システムのディザスタリカバリ・負荷・長時間耐久試験	未実施

実際の物理サーバーのUEFI PXE、BMC・RAID自動化、2つの物理ホスト間の障害、ストレージ全体障害、すべての商用DB/WAS製品バージョンの検出は、このVM実習で検証されたとはみなさない。各機能の実装と実際の試験範囲を分離する。

オンライン初期インストールと、インターネットのない環境へのインストール・エージェント配布も区別する。中央全体を新しい閉域網で最初から再インストールする試験には、持ち込みバンドルの依存関係検証も含める必要がある。既存サービスの外部NICを切断しただけの結果をもってこれに代えることはできない。

本実習で通過した項目と次の検証課題を同じ表にまとめた。個人のPC1台の結果を、運用SLAやあらゆる障害におけるデータ損失なしの保証として表現してはならない。