Workflow
実際の運用の流れ
特定のプロジェクトの図ではなく、その下で回っているループそのもの。あらかじめ書いたものではなく、このラボを運用する中で抽出したもの。
01 / OBSERVE
実際の状態を確認する
「Synced」は「デプロイ済み」ではない。push が成功したことは、そのリポジトリがまだ存在する証拠にもならない——旧パスのリダイレクトが生きていて push は毎回成功を返したため、一日分の作業がまるごと削除予定のリポジトリに入っていたことがある。過去の計画の判断も、緑のチェックマークも含め、何かを信じる前に本物を確認する。
02 / FRAME
変更前に完了条件を定める
単純ではない作業は、実装前に計画として保存する。観測可能な成果、範囲、各事実の唯一の正本、重大なリスク、順序付きの検査、停止条件を先に定める。複数システムにまたがる作業では Harumi・Cloudflare・メンテナンスゲートのどこが所有するかも明記し、「他で管理」が見えない負債にならないようにする。その契約を読み戻したら、儀式として分析を繰り返さず実装に進む。
03 / CHANGE
一つの正本を、検査とともに変える
正本に対して、意味の通る最小の変更を行う。新しい規則には同じコミットで実行可能な検査を付け、重複する事実は生成するか一致を検証する。不可逆な操作の前には diff を取り、検査には失敗例も与える——緑しか出したことのない検査は、まだ何も証明していない。
04 / PROVE
その変更が本番にあることを証明する
main に push し、共通パイプラインで build と scan を行った後、ArgoCD が現在のコミットを反映し、ワークロードがその image を実行し、その image を生んだ pipeline が実際に通っていて、実際の経路が期待する挙動を返すことまで証明する。ArgoCD は CI の成否に関係なく Git から配るため、赤い pipeline の上の緑の sync は成功と見分けがつかない。path 単位の build 規則は、片方の component だけを進めて他方を置き去りにすることもある。「Synced」「pipeline passed」「latest」は途中の信号であり、単独では対象の変更を特定できない。
05 / RETAIN
結果を次の入力に変える
計画、正本の文書、障害記録、再利用する記憶を同じ一手で更新し、書き戻された状態を読み直す。内部の知識グラフはそれらの正本から再構築される読み取り専用の投影で、リンク切れ、曖昧な識別子、出所、鮮度を自動検査する。その出力が次の観測の基準になる。
LOOP MODEL
一つのループ、三つの時間軸
同じ仕組みが、異なる三つの役割を担う。それらを区別することで、「継続的改善」が検証不能な標語になるのを防ぐ。
ITERATION / 1 回の実行
境界を定めた一つの変更をループに通す
一回の反復は計測した状態から始まり、Plan で範囲を定め、本番の証明まで到達するか、失敗したゲートの状態まで戻る。途中を飛ばすことはない。
EVOLUTION / 複数回の反復
計測された摩擦からだけ運用方法を進化させる
繰り返す失敗が一般化できる場合に限り、runbook や再利用する skill を変える。変更した規則には失敗 fixture を付け、次の反復では記憶に頼らず強制できるようにする。
CLOSURE / 帰路
結果を再び観測可能にする
証明、Plan の状態、正本の知識を一致させ、改めて採取した実状態を新しい基準にする。この帰路が、配信パイプラインを閉じた学習システムへ変える。
閉ループは作業の終点ではない。リポジトリ、デプロイ済みリビジョン、実行時の証拠、計画、永続的な記録が一致し、次の観測として使えるようになる瞬間を指す。内部の運用証拠は非公開のまま保ち、知識グラフは整合しているように編集するのではなく、正本から再構築する。