配布と運用：実行環境と復旧基準を決める

なぜ必要なのか

ブラウザーで読む公開記事の一覧が完成したとします。編集者は更新を公開し、読者は安定したリンクで訪れ、公開に失敗したら誰かが復旧します。

「自分のPCでは動く」だけでは、利用者がどう入手し、失敗時に誰が復旧するか分かりません。ブラウザーのページ、ダウンロードするゲーム、オンラインサービスでは届け方も運用も違います。期待する体験を、繰り返せる公開手順と復旧可能な実行環境につなぐ必要があります。

どう解決するのか

1. 利用者がどこで実行し、どう受け取るかを決めます。公開カタログはURLで開き、デスクトップゲームはパッケージやストアで入手できます。オンライン機能には、インストールされたクライアントと別に動き続けるサービスも必要かもしれません。一言の「配布」に含まれる責任を分けます。
2. 基盤を選ぶ前に、予算、運用時間、許容停止、許容するデータ損失、復旧担当を合意します。これらは全体の決定です。AIはその範囲内で手順を作れますが、有料資源の追加や可用性の変更には該当する判断が必要です。慣れた製品に合わせて後から制約を変えません。
3. ソースから利用者まで一回の公開を追います。再現可能な成果物を作り、プレビューや試験環境で検証し、版と設定を記録します。開発プロセスだけでなく提供するURLや導入パッケージを確認します。秘密情報や環境別設定を公開物に含めず、検証した物と配布する物を一致させます。
4. 切り替え前に失敗を計画します。どの信号で中止し、誰が応答し、以前の利用可能な状態へどう戻すかを決めます。古いプログラムへ通信を戻しても、新しいデータベース書き込みは自動で消えません。ファイルの交換とデータの互換性・復旧を分けて確認します。
5. 一部への先行公開が有用なら、比較対象、測定期間、拡大に必要な証拠を定めます。要求がない、または観測が欠けることは成功ではなく不確実性です。小さなサイトなら大きな段階公開の仕組みより、プレビューと切り替えで十分な場合があります。複雑さを実際のリスクに合わせます。

成果物、対象、検証、中止条件、復旧順序、担当者を短い手順書に残します。可能なら安全な環境で復旧を練習し、未検証部分も正直に記します。別の担当者が手順をたどり失敗を認識できることが大切です。計画自体はデプロイの許可ではありません。実行は、利用者が認めた公開作業の範囲内で行います。

どんな考え方なのか

ランタイムは実行場所、配布は入手方法、ホスティングはファイルやサービスを提供する役割です。デプロイとリリース手順がこれらを結びます。Google SREのカナリア指針は限定した公開での評価を説明します。ホストの商品名や切り替え方式を計画全体と考えず、合意した運用・復旧条件を満たす手順を選びます。