運用上の確認が別の問いに答えていたとき

要旨

家庭内ラボのプラットフォームを運用する中で、成功した確認、記憶していた指示、利用できる承認経路が、当初考えていたほどの意味を持たなかった事例を記述する。事例は、以前の実行を対象にした検証や配信ゲートでの失敗から、復旧の依存関係、誤ったルーティングの認識、そして結果が未解明のメンテナンスと再起動の一連の出来事へと進む。これらから、証拠を特定の操作にどう結びつけるか、復旧へのアクセスをどう保つか、意図した設定ではなく稼働中のシステムをどう確認するか、という問いが残る。

本稿について

本稿は、1 人で運用する家庭内ラボという、1 つのプラットフォームについての経験報告である。査読を受けていないワーキングペーパーであり、記述を目的とする。

**本稿の一語一句は、AI アシスタント（Claude と Codex）が書いたものである。** アシスタントは運用者の指示に基づき、構築と運用の際に自ら残した日付付きの記録から、このプラットフォームにおける自身の作業実践を要約した。運用者は公開を受け入れたが、本文を書いたわけではなく、個々の記述を独立に確認したわけでもない。数値は元の記録と照合しており、記録にない測定値は含まれていない。本文の「私」は、作業の多くを行った AI アシスタントによる語りを通じて、プラットフォームの運用者を指す。

書き手と記述の対象が同じアシスタントであるため、この報告はその盲点を引き継ぐ。記録が示していないことも含め、記録が示すことを報告する。

運用環境

私は家庭内ラボのプラットフォームを 1 人で運用している。運用上の変更は、人間の承認を伴うワークフローエンジン Camunda を通り、変更のたびに検証が実行される。その経路の周囲には、バージョン管理された設定、CI の確認、実行ワーカー、ネットワークと認証・識別のサービス、結果の状態を読み戻す確認がある。

これらはすべて同じ問いに答えるわけではない。承認が扱うのは先に進む許可であり、実行ワーカーには固有の権限境界があり、配信の確認が扱うのはそこに届いたものであり、検証器には特定の操作の証拠が必要である。以下の事例は、私がこれらの境界を曖昧に扱ったときや、それらを通る経路が完了できないと分かったときを記述する。

以前の操作に属していた成功実行

10 月 4 日、runner の変更は直ちに検証されたように見えた。検証器は直近 2 時間の最新の取り込み実行を探し、停止せずに完了していれば受け入れていた。変更は、その操作から 0 s 後に検証済みと報告された。

当初、この結果は変更の通常の結末に見えた。操作が実行され、確認を通過したということである。しかし、新しいジョブの実行行はまだ存在していなかった。検証器が受け入れたのは前回の実行であった。実行識別子を読むことで、確認自体が検出していなかった不一致が明らかになった。

問題は、一般にデータが古いということよりも具体的であった。以前の実行は検証器の時間枠に収まるほど新しく、完了の規則も満たしていた。それでも、この操作が機能したことは示せなかった。答えてほしかった問いは、この操作が開始した実行が正常に完了したかどうかであった。確認が答えたのは、最近の実行が正常に完了したかどうかであった。

操作が開始時刻を書き込み、検証器がその時刻以降に開始した実行だけを受け入れるよう変更した。その記録がなければ、検証は fail closed（必要な条件を確認できなければ不合格とする方式）となる。これにより意図した関係は明示されるが、この一件だけでは改訂した確認がどれほど確実に動作するかは分からない。ポーリングの時間枠を狭くしても、多くの場合は今回の受け入れを避けられたかもしれないが、操作とその証拠の関係は暗黙のままになる。

11 月 3 日、トンネルサービスのアップグレード準備中に、関連する欠落が見つかった。新しい検証器に、承認済み操作の鮮度マーカーがなかった。今回は CI のセルフテストが失敗し、修正では他の検証器と同様の鮮度強制を追加した。この修正について、成功した再実行の receipt（実行結果の証跡）はここにはない。また、この後の事例は、古い証拠が実行時に受け入れられたことを示すものでもない。CI が捉えた要件の欠落を記録したものである。この違いは重要だと考える。以前の不一致は見かけ上の成功後に実行識別子を読んで見つかったのに対し、後の欠落は、そのような実行時の結果が確定する前に捉えられたからである。

失敗したゲートの後に成功したシェルコマンド

同じく 10 月 4 日、アシスタントは push の前に最新のパイプラインを確認した。確認スクリプトは、パイプラインが失敗していれば失敗を返した。アシスタントはその出力を、最後の行だけを残すコマンドにパイプで渡し、そのシェルコマンド列の見かけ上の成功を条件に rebase と push を連結した。

当初は必要な制御があるように見えた。push 前のパイプライン確認があり、ゲートをパイプに通してはならないという記憶済みの指示もあった。確認は、パイプラインが失敗したことさえ出力していた。しかし、最後の出力フィルター用コマンドは正常終了し、その終了ステータスによって後続のコマンドが実行された。main ブランチが失敗状態のまま、2 つのコミットが push された。

CI の失敗には、それぞれ具体的な原因があった。新しい確認が、ジョブのイメージにない YAML ライブラリを import していた。修正の試みは、新しいスクリプトのセルフテストが CI に組み込まれていなかったため、別のジョブで失敗した。影響を受けた両ジョブを、エラーで停止するシェルの下でそれぞれ全体として実行して初めて、次のパイプラインが成功した。

その間、実行ワーカーのチェックアウトは古いままであった。starter（変更開始プログラム）は、ランブックが配信されたチェックアウトと異なるため、承認済みの変更を拒否した。この拒否は、push 時の確認がシェルの組み合わせによって無効になっていても機能した、別の境界であった。「確認を実行した」を「その失敗が次の操作を制御した」と同等には扱えなかった。

直後の修正は影響を受けたジョブに対処し、次のパイプラインは成功した。一方、記憶済みの規則が信頼できる push 時の制御になったという証拠はない。この報告が扱うのは、1 回のセッションと、すでに記憶の中で繰り返されていた規則である。シェルの組み合わせに対する不注意でこの一件は十分に説明でき、ワークフロー設計に固有の欠陥を示すものではない。

機能する更新経路のない鮮度規則

10 月 5 日には、別の配信ゲートが作業を通過させずに停止させた。CI の規則では、日次の budget（許容範囲）測定値の古さを最大 2 日としていた。ルート所有権、シークレット投影、プローブ網羅範囲、サイジングの測定値には、まだ 10 月 2 日の日付が付いていた。当時の記述によれば、測定値の更新とは無関係な承認済み変更やランブック修正も含め、すべての push でそのジョブが失敗した。

測定項目には日次コマンドが記載されており、保守の仕組みが実際以上に整っているように見えた。日次測定値の横に日次確認があれば、両者はつながっていると思い込めた。しかし、つながってはいなかった。それらのコマンドは条件を確認するだけで、測定記録は書き込まなかった。記録は実際には 3〜5 日ごとに手動で更新されていた。

ゲートは、記述された経過日数の規則を強制していた。失敗していたのは、最新の証拠をそこに供給するための私の仕組みである。この違いによって、修復先として見る場所が変わる。確認器を緩めれば要件を変えることで中断に対処でき、記録を更新すれば既存の要件を満たせる。記録された変更では、10 月 5 日に 4 つの budget を稼働環境で再測定した。

この更新が、ここで記述できる具体的な変更である。その後の更新が自動化されたことや、無関係な配信がこのように停止されなくなったことの証拠ではない。また、すべての push が失敗したという記述を裏付ける、独立に収集したパイプライン件数もない。この事例からは実務的な問いが残る。新しい証拠を求めるとき、それを生み出す経路を構築したのか、それとも不在を拒否する規則だけを作ったのか。

実行時の権限を与えられなかったプレビュー

同じ 10 月 5 日の別の変更は、ホストのバックアップタイマーの無効化に関するものであった。ホストワーカーは、no-new-privileges 制約のある非特権ユーザーとして動いていた。特権を要するホスト操作は、root 所有の別ユニットが担当していた。それにもかかわらず、アシスタントは非対話型の権限昇格でタイマーを無効にしようとする操作ランブックを書いた。

承認済みの変更はプレビューを通過し、適用時に失敗した。権限昇格コマンドは no-new-privileges 制約を報告した。当初、プレビューの成功は、承認を経て実行へ進む十分な理由に見えた。実際に確認できていたのは受け入れ条件とスクリプトの構文であり、選択されたワーカーの実行時の権限ではなかった。

この境界はすでにワーカーの実行契約の一部であった。構文上有効なコマンドであっても、変更を承認しても、そのワーカーにコマンドが必要とする権限を取得させることはできなかった。別の特権 runner なら操作を実行できたかもしれないが、このワーカーは提案された方法では実行できなかった。

操作ランブックを削除し、読み戻し用の検証器を残した。これは、意図したタイマー変更を完了するよりも限定的な結果であった。互換性のない実行経路を取り除き、関連する状態を調べる手段は維持した。

適用の失敗はタスクの記述と変更履歴に記録されているが、その記述ではワークフローの結果記録を独立に収集できなかった。したがって、この削除をタイマー操作の成功と言い換えることはできない。未解決なのは、操作に必要な権限を、実際にそれを実行するワーカーと照らしてプレビューがどう確認すべきかである。構文と受け入れ条件は実在する確認であったが、別の問いに答えていた。

復旧には自ら乱したログイン経路が必要だった

10 月 9 日、Camunda を再構築した後、その Hub のログインページは読み込み中のままであった。当時の説明では、アクセス制御層がブラウザーから認証情報の発行元へのバックグラウンドリクエストを遮断していた。アシスタントはプラットフォーム内でこれを回避しようとして、ゲートウェイのリスナーを追加し、証明書の対象を拡張し、認証局でその名前を許可し、編集が反映されなかった際には認証局のワークロードを再起動した。それでも Hub は読み込み中のままであった。

元の状態に戻し、アクセス制御層は自分で設定することにした。当初は、変更を差し戻し、デプロイコントローラーが同期済みと報告するのを確認することが、元に戻す妥当な経路に思えた。しかし、リスナーは稼働したままであった。使用していた server-side apply（サーバー側適用）の挙動では、バージョン管理からそのフィールドを削除しても、稼働中のゲートウェイからは削除されなかった。この場合のための削除用ランブックが存在していた。

そのランブックには承認済み変更が必要であったが、利用可能などちらのアドレスからも Camunda のタスク画面を開けなくなっていた。Hub に使った端末で、アシスタントの指示に従ってローカルのホスト上書き設定を追加していた。タスク画面も同じ発行元ホストを使っていた。その上書き設定は、タスク画面のログイントラフィックも内部ゲートウェイに送っていた。私の記述によれば、その行を削除するとアクセスが回復したが、アシスタントはその端末の名前解決を検証しなかった。

私は例外を明示的に許可し、アシスタントはワークフロー外で削除スクリプトを手動実行した。読み戻しでは、バージョン管理と一致する 25 のリスナーが確認された。証明書は元の名前で準備完了となり、認証局の両ワークロードは稼働していた。デプロイの比較エラーも存在していたが、これは差し戻し前からのものであった。手動実行についてのワークフロー結果記録はなかった。

したがって、復旧は単なる差し戻しの成功よりも複雑であった。クライアント側の回避策を導入した結果、共通のログイン依存先に影響が及び、通常の後処理経路にはそのログインが必要であった。ホスト上書き設定の削除を先に提案していれば、手動の例外は不要であった可能性が残る。元の Hub の症状については、アクセス制御の変更で直ったとも直らなかったとも示されていない。まだ私がその設定を行っていなかったからである。復旧の記述を使って、それ以前の説明を確定することはできない。

記憶済みの指示が管理者 ID を指していた

9 月 29 日、リポジトリの作成とミラーリングの際、アシスタントはセッション開始時に読み込んだ記憶に従った。そこには、リポジトリ作業では管理者トークンを使い、コマンドごとにワークステーションの認証情報ストアを迂回するとあった。一方、プラットフォームの文書では、ワークステーションからの push を非管理者の書き込み用 ID に割り当て、ワークステーションには管理者 ID がないとしていた。

最初の認識では、記憶済みの指示が、その作業の確立された方法を示していた。アシスタントは管理者トークンを取得し、プロジェクトを作成し、そのトークンで push するスクリプトを書いた。権限分類器が実行を阻止した。これは阻止された試みであり、管理者による push が観測されたわけではない。

他のリポジトリではどの ID を使っているのかと私が問いかけた後、アシスタントはプラットフォームの文書とそれらのリモート設定を読んだ。書き込み用 ID を確認し、ローカルの記憶と 3 つの共有記憶ファイルの両方を修正した。他にも古い記述が見つかった。1 つは、匿名の API リクエストが 404 を返すにもかかわらずテンプレートリポジトリを公開と記述しており、別のものは廃止された pull-secret 規則を記述していた。

これらの修正で、記憶済みの指示は変わった。ただし、記憶という仕組みが原因だったとは言えない。管理者トークンの指示は、元々私の指示として書かれ、そのとおりに従われたものであり、その文言で問題を説明できる可能性がある。この一件で破綻したのは、手軽に読み込まれた指示が、なおも準拠すべき取り決めを表しているという想定であった。

後のセッションがこのような矛盾にどれほど遭遇するかは分からない。この試みを止めた制御は権限分類器であり、プラットフォームのガバナンスゲートではなかった。この事例が自分のシステムについて何を示すかを評価する上で、これは重要である。試みた操作は捉えられたが、その功績を帰したかもしれない境界とは別の境界によるものであった。

想定した経路をすべてのリクエストが通るわけではなかった

10 月 23 日の時点で、公開 Camunda ルートについて広く捉えすぎた理解で作業していた。それらのホストはすべて同じ遠隔ゲートウェイを通ると想定していた。実際のルーティングの記述では、いくつかの画面はすでに配信元ホストへリダイレクトされ、ゲートウェイでプロキシされるのはオーケストレーションのルートだけであった。

当初、これらの画面を共通のものとして説明していたため、ネットワーク経路も共通だと考えるようになっていた。ルート単位の調査によって、その帰属を修正した。サービス群の呼び名だけでは、どのリクエストがどの境界を越えたかは分からなかった。

変更履歴には、タスク画面と運用画面の直接配信、およびルーティングの説明の修正が記録されている。これにより、関係する経路をより具体的に説明できるようになった。ただし、ネットワーク性能の説明が確立したわけではない。その記述に添えられた所要時間には、生のトレースもブラウザーのキャプチャーもなく、ゲートウェイの処理を他のネットワークやブラウザーの影響から切り分けていなかった。

そのため、本報告から時間の比較を除外した。ここで有用な変化はルーティングについての認識の修正であり、特定の経路が観測された遅延を引き起こしたという主張ではない。報告された時間のうち、どれだけがゲートウェイ、ネットワーク、ブラウザーに由来するかは、今も言えない。この事例を記憶の事例と並べるのは、どちらも広く便利な説明を、実際に関係する境界についてのより限定された説明に置き換える必要があったためである。

メンテナンスページが自身の承認入口を塞いだ

コントロールプレーンの再起動に伴うメンテナンス時間帯に、メンテナンスを有効にするとタスク画面を開けなくなった。メンテナンスハンドラーはアクセス制御層の後に動作していた。承認入口に必要なホストがその通過許可リストになかったため、認証済みの運用者もメンテナンスページに到達した。

当初の運用上の取り決めでは、メンテナンスモードと承認経路は両立するものとしていた。観測結果は、その間の例外設定の欠落を示した。認証だけでは十分でなかった。次のハンドラーが、運用作業を承認するために必要な場所へのアクセスをなお妨げ得た。

アシスタントは通過を許可するホストを追加し、承認入口が塞がれていたため、ゲートのランブックを 1 回手動実行した。この逸脱は記録された。これは通常の経路からの具体的な逸脱であり、タスク画面を通じて承認を完了したものではなかった。

この記述にはランブックの証跡も詳細な逸脱記録もなく、修正後のブラウザー上の結果は不明である。通過許可項目の追加は何を変更したかを記述するが、修正された経路がその後利用できたことは示さない。この事例からは、調べるべき依存関係が残る。メンテナンス制御が、その制御自体を操作するために必要な人間の行為を妨げ得るということである。

再起動が停止し、2 つの説明が欠けたままになった

コントロールプレーンの再起動はシャットダウン中に停止した。遠隔シェルへのアクセスは、電源を切るまで復旧しなかった。承認済みの変更は後に検証されたが、その最終的な検証は停止の理由を説明しなかった。

当初の運用経路は、承認済みの再起動に続いて検証するというものであった。シャットダウンの中断によって、操作の開始から利用可能なマシンを取り戻すまでの間に何が起きたかに目を向けざるを得なくなった。前回起動時の journal（システムログ）はコンテナの scope の後片付け中に途切れ、journal の正常な停止で終わっていなかった。10 月 20 日の起動も正常な終わり方ではなかった一方、それ以前の起動は正常に終わっていた。

観測からは、シャットダウン保護の欠落も明らかになった。すべてのノードでシャットダウンの猶予期間が 0s、実行時の watchdog 設定が 0 で、watchdog デバイスも存在しなかった。サーバー側の dry-run drain は、単一インスタンスのデータベースクラスタ 4 つによって阻止された。それらの disruption budget は許容する中断数が 0 であった。これらは関連する制約と欠落した制御であったが、いずれも停止の原因を確定するものではなかった。

その後の作業では、シャットダウンの堅牢化を導入した。原因を診断して修復したと主張せずに、この対応を記述することはできる。この記述には、シャットダウンがなぜその箇所で止まったかを証明する、収集済みの journal や検証器の証跡はない。

また、検証には別の空白があった。保留中の検証器は後に変更なしで解消したが、その遅延の原因も長さも確定していない。最終的に検証済みとなっても、再起動がなぜ停止したか、検証が解消する前になぜ保留のままであったか、という両方の空白は残る。同じ承認済み変更の前後に生じたというだけで、両者を 1 つの説明に結びつけることはできない。

堅牢化の確認は稼働状態を見た

稼働環境での最初の堅牢化実行では、ノードエージェントに shutdown inhibitor（シャットダウン抑止）がないままとなった。インストーラーの堅牢化確認がその欠落を検出した。当初は、設定作業からシャットダウン遅延が用意されたように思えたが、稼働状態の確認は意図した保護が存在しないことを示した。

並び順で後になる OS 更新の上書き設定が、ノードエージェントの上書き設定より優先され、抑止の最大遅延を 30s に設定していた。ノードエージェントは、値が 2m0s になるのを待って 5 回試みた後にタイムアウトしたと報告し、依然として 30s を認識していた。問題は、望ましい設定のテキストが存在するかどうかだけではなかった。実効値によって、期待した inhibitor を保持できなかった。

修正では、並び順で後になる上書き設定に 120s を指定し、稼働中の値が異なる場合に限ってログインマネージャーを再起動することとした。この変更は、inhibitor の欠落について記録された優先順位の問題に対処した。以前の再起動の停止を説明したわけではない。

この記述には、修正後の稼働中の inhibitor の証跡も、その後の再起動の成功もない。残せるのは最初の実行での検出である。稼働状態の確認が、意図した設定と有効な保護の違いを捉えた。修正によって望ましい保護が生まれ、維持されたかどうかは、ここでは未解決である。

見えているように思うパターン

確認が最も誤解を招くのは、近接した別の問いに対して成功するときだろうか。最近の実行、受け入れられたスクリプト、同期済みのデプロイ、認証済みのリクエストは、どれも実在し得るが、次に必要な事実を確立するとは限らない。

証拠の鮮度は、古い証拠を拒否するだけでなく、一部は証拠を生み出す責任でもあるのだろうか。古い測定値と欠落した操作マーカーは、操作や測定から、その受け入れまでの経路全体についての問いを示唆する。

復旧の依存関係にも、実行の依存関係と同じ精査が必要なのだろうか。ログインの回避策とメンテナンスハンドラーは、仕組みは異なるものの、どちらも承認入口を妨げた。

便利な知識は、その適用範囲を確認しなくなると危険になるのだろうか。記憶済みの認証情報の指示も、広くまとめたルーティングの説明も、より具体的な境界がそれに反するまでは、使えるように見えた。

稼働状態の読み戻しが最も有用なのは、設定層の間で食い違いが生じ得る場所だろうか。残存したゲートウェイのリスナーと欠落した shutdown inhibitor を見ると、どちらの修正も一般的な信頼性の証明と扱うことなく、この問いを立てたくなる。

限界

これらは、早期の失敗を許容する 1 つの小規模な家庭内ラボから選んだ事例であり、運用の全数調査ではない。失敗率の分母も、チーム間やエンジン間での追試もなく、比較対象となるワークフローエンジンなしの同等の実装もない。これらの記述から、Camunda によるコストと、何らかの調整層を追加することによるコストを切り分けることはできない。

私は実践者と研究者を兼ねている。私の好みや盲点が、設計、誤り、その記録、解釈に影響し得る。AI アシスタントは作業の実行と記録の執筆を支援しており、私が記述を受け入れたことは独立した裏付けではない。

証拠は、記録された変更、セッション中の観測、報告された結果の間で異なる。パイプラインの証跡、ブラウザーの結果、journal の資料、稼働状態の読み戻しの欠落によって、特定の結果は未解決のままである。バージョン管理上の修正はデプロイや動作の成功を示さず、後の成功も過去にさかのぼって原因を証明するものではない。これらの記述が支えるのは記述と問いであり、比較上の信頼性、労力の削減、アーキテクチャの優越性、一般化された AI 安全性の主張ではない。

未解決の問い

各検証器が、その証拠が確認対象の操作に属することを確立するには、どうすべきか。CI は、鮮度要件の欠落と、実行時にその要件を満たせなかったことをどう区別すべきか。

プレビューが重要な実行境界を実際に通ったことを、何が示すのか。正しく強制される鮮度規則が無関係な変更を繰り返し妨げないよう、証拠更新の作業をどう維持すべきか。

メンテナンスや認証・識別に関する作業がその入口に影響するとき、承認と復旧の入口をどう保てるか。通常のワークフロー経路が使えないとき、例外的な手動実行はどのような証拠を残すべきか。

どのような観測が、シャットダウンの停止原因を確定し、保留中の検証器を説明し、修正された inhibitor が有効であることを実証するのか。その後の再起動の成功は有用だろうが、それだけですべての因果関係の問いに答えることにはならない。

参考文献

1. Wil M. P. van der Aalst. "Business Process Management: A Comprehensive Survey." ISRN Software Engineering, vol. 2013, Article ID 507984, 37 pages, February 2013. DOI 10.1155/2013/507984.

2. Hector Garcia-Molina and Kenneth Salem. "Sagas." Proceedings of the 1987 ACM SIGMOD International Conference on Management of Data, pp. 249-259 (Princeton technical report TR-070-87, January 1987).

3. Raja Parasuraman, Thomas B. Sheridan and Christopher D. Wickens. "A model for types and levels of human interaction with automation." IEEE Transactions on Systems, Man, and Cybernetics, Part A, vol. 30, no. 3, pp. 286-297, 2000.

4. Per Runeson and Martin Host. "Guidelines for conducting and reporting case study research in software engineering." Empirical Software Engineering 14(2), pp. 131-164, 2009. DOI 10.1007/s10664-008-9102-8.

5. Pat Helland. "Idempotence Is Not a Medical Condition." ACM Queue 10(4), 2012, p. 30.

6. OpenGitOps. "OpenGitOps 1.0" principles (announcement dated 8 November 2021, by Dan Garfield and Scott Rigby; https://opengitops.dev/blog/1.0-announcement).

7. Nicole Forsgren, Jez Humble and Gene Kim. "Accelerate: Building and Scaling High Performing Technology Organizations." IT Revolution, 2018 (details as commonly cited).

8. Jez Humble and David Farley. "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation." Addison-Wesley, 2010 (year as commonly cited).