FACTUAL ACTIVITY RECORD · 実際の作業をもとにした活動記録
本番運用と監視の安全境界をつくる
明示確認付きの配信・復旧、定期smoke、local service監視を一つの運用へまとめる
目的
本番Workerを配信した後の状態確認、失敗時の復旧、公開面と管理面の境界監視、local serviceの稼働確認が個別の手順に分かれ、誤操作や確認漏れを機械的に止める仕組みが不足していた。
本番操作を明示承認された手動実行へ限定し、秘密情報を記録せず、配信前後と復旧後を同じ条件で検証できる運用が必要だった。
実装
production delivery workflowにdeployとrollbackの二操作を持つ手動workflowを追加した。対象refと入力文字列を完全一致で検査し、rollbackではUUID形式のversion指定を必須にした。新versionは通信を流さずuploadし、選択したversionを100%へ切り替える。
配備metadata検証は構造化出力からversion IDだけを抽出し、単一versionが100%であることを検証する。配信後smokeが失敗した場合は直前versionを再確認して復旧し、復旧後のactive versionとproduction smokeも再検査する。
- 公開画面、公開API、管理redirect、公開側管理APIの拒否、Access challengeを定期smokeで確認する。
- redirect先やresponse本文をlogへ出さず、Accessのhostとpathだけを判定する。
- local Connectorはrunning、定期Runnerはrunningまたは待機かつ直近終了正常を条件にする。
- DB migrationをWorker配信へ自動連結せず、forward recovery、backup restore、Access障害切離しをrunbookへ分ける。
現行planでは環境承認機能を利用できない制約があったため、実効gateを手動起動、対象ref限定、完全一致確認へ固定した。上位planへ移行した場合に環境保護と必須確認を追加する手順も運用文書へ残した。
一次workflow差分から、deployとrollbackを完全一致の確認語とversion入力で分離するgateを示す。error表示を省いた公開説明では、判定条件は維持した。
図を描画しています…
確認したこと
確認結果
58件のtest、lint、typecheck、Worker build、bundle secret scan、workflow構文検査が通った。
5つのproduction boundary smokeとlocal serviceのrunning・待機・直近終了判定を検証できた。
構造化された現在のdeployment情報からversion IDを取得し、曖昧な段階配信や不正なIDをfail closedにできた。
運用workflow、監視script、復旧runbookは対象へ反映された。専用credential設定と初回手動実行はcutoff後の運用事項として未確認だった。
完了とした根拠
本番操作の承認条件、version検証、失敗時復旧、公開・管理境界smoke、local service監視、秘密情報の非露出を実装し、静的検査とtestで確認できたことをもって完了とした。