準備を整える
レビュー可能にする。
有効化、強化、加速、復旧にまたがるローンチ作業を割り当てて確認するための対話式プランです。アカウントなしでも利用できます。サインインした SIU のオーナーは、任意でカテゴリごとの進捗を非公開で保存できます。これはリリースゲート、監視、または本番管理を行うものではありません。
これを使って: 決定論的な優先順を使って所有権と検証を可視化し、不明とスキップを暗黙の完了ではなく明示的な結果として維持してください。
次の 既知のステップに取り組む。
- レーンを選び、決定論的な優先順の各項目に状態を割り当てます：準備済み、不明、またはスキップ。不明は証拠取得を促し、スキップは説明責任ある判断を要します.
- 各項目について所有者と検証の記述を確認してください。所有者フィールドは役割または責任者の氏名のみに編集し、計画に認証情報や顧客データを記載してはいけません。
- 携帯可能な引き渡しが有用な場合は、現在のプランをデバイスにダウンロードしてください。任意の SIU アカウント保存はサイトラベルとカテゴリ別のアクション状態のみを保存し、URLs、認証情報、ファイル、自由形式の所有者メモは除外されます。
公開 管理ボード。
決定順： 項目は番号付けされた優先順を保ちます。証拠がない場合は「不明」を選択してください。「スキップ」は責任を負う判断がある場合のみ選んでください。
有効化
リリースが進む前に、最小限の意思決定、担当者、および顧客向けの基本事項を確定する。
- 01リリースの意図と変更される顧客経路を明記する
小さく明確な範囲は、レビュアーと対応者に共通の出発点を提供する。
責任者: リリース担当者 · 検証: レビュアーが、変更された経路、意図した顧客成果、リリース期間を一つの短い記録で指し示せること。 - 02顧客向けの連絡先とエスカレーション文言を確認する
変更中に臨時の文言で対応することなく、顧客が影響を報告できる明確な手段が必要である。
責任者: 顧客コミュニケーション担当者 · 検証: オンコールまたはサポートの連絡先が承認済みチャネルで到達可能であり、公表文言に責任を負うレビュアーがいること。 - 03主要な顧客ジャーニーをローンチ前に実際にたどる
ブラウザで確認できるジャーニーは、ビルド結果だけでは見えない問題を明らかにすることがある。
責任者: プロダクトまたはQA担当者 · 検証: チームが開始URL、期待される結果、および必要なサインインや支払いの境界を顧客データを使わずに記録していること。
強化
適切な担当者とともに、リリースおよびその復旧経路を検査、制限、逆転しやすくする。
- 04リリース識別子と可逆的な変更記録を残す
正確な参照は、変更を一時停止または巻き戻す必要がある場合の推測を減らす。
責任者: リリース担当者 · 検証: リリース識別子、デプロイ元、承認者、既知のロールバック経路が対応担当者から参照できること。 - 05指定されたオペレータが正しいアクセス経路を持っているか確認する
アクセスに関する想定が未検証だと、エスカレーションが遅くなる。
責任者: プラットフォーム担当者 · 検証: 非本番環境または承認済みのドライランで、担当者が記載されたツールにアクセスできることを確認すること。なお、この計画内で認証情報を共有してはならない。 - 06依存関係およびサードパーティの変更範囲をレビューする
サードパーティの変更は、アプリケーションコードが変わっていなくてもローンチ経路を変える可能性がある。
責任者: エンジニアリング担当者 · 検証: リリース記録に、新規または変更された依存関係、外部エンドポイント、および各項目を評価できる担当者が記載されていること。
加速
観察可能でレビューされたローンチ経路を維持しつつ、回避可能な配信負荷を削減する。
- 07画像候補を実際の配置で検査する
ソース画像だけでは、顧客が実際に受け取るバイトが判別できない。
責任者: デザインまたはパフォーマンス担当者 · 検証: 優先度の高い画像について、意図するレンダリング幅、代替テキストのアクセシビリティ、レスポンシブ候補の有無をチームが記録していること。 - 08変更される経路のレビュー可能な配信予算を設定する
測定の文脈を明示することは、無制限の性能保証より有用である。
責任者: パフォーマンス担当者 · 検証: チームが計測指標、テストの文脈、許容範囲を文書化していること。普遍的な速度主張を導くものではない。 - 09リリース後に観察する経路を少数選定する
所有者のいないURLリストより、対象を絞ったチェックの方が解釈しやすい。
責任者: リリース担当者 · 検証: 最大5つまでの相対パスが、それぞれ対応者と期待される応答または観察メモとともに割り当てられていること。
復旧
顧客が必要とする前に、冷静な引き継ぎ、エスカレーション経路、および可逆的な対応を準備する。
- 10インシデント、技術、コミュニケーションの意思決定役割を割り当てる
役割の明確化は、単一人物がすべての問題を診断できると仮定することなく、協調した対応を支える。
責任者: インシデント対応担当者 · 検証: 各役割に対して、責任者の氏名またはリリース期間中の明確なエスカレーション経路があること。 - 11一時停止やロールバックの判断境界をリハーサルする
圧力が高まる前に承認と検証手順が分かっているほど、可逆的な手順は安全である。
責任者: リリース担当者 · 検証: チームが承認されたトリガー、誰が承認するか、およびアクションの前後に取得すべき証拠を把握していること。 - 12ライブのサービスステータス作業をStatus Is Downと連携する
SIUは計画上の指針を提供する。ライブのサービスステータス作業はSIDで扱うべきである。
責任者: コミュニケーション担当者 · 検証: コミュニケーション計画が、ライブのサービス通知や更新のために該当するSID宛先を指し示していること。
リリースの決定前に、準備済みでないすべての項目を該当する所有者と確認してください。
検証の記述を、実際のリリース環境および文書化された対応プロセスと照合して確認してください。
稼働中のステータスおよび進行中のインシデント作業は SID とチームのインシデントワークフローにルーティングしてください。
クライアント側の計画エクスポートです。これはリリース承認、監視記録、または本番制御ではありません。
ソースノート、 借用された確実性ではありません。
計画の根拠: Google SRE、CISA、OWASP、web.dev、MDN の参照資料（リンクされた SIU ガイドで使用）
- CISA — Planning: Response & Recovery ↗CISA はインシデントおよび災害復旧計画、業務影響の優先付け、連絡経路、および内部報告の構造を重視しています。
- Google SRE Book — Production service best practices ↗ガイダンスは監督された段階的なロールアウトを推奨し、予期しない挙動が検出された場合はまずロールバックを行い、その後診断して復旧時間を短縮することを勧めています。
- OWASP — Software Supply Chain Security Cheat Sheet ↗OWASP は依存関係のインベントリ、適切な場合の自動 SBOM 生成、監視、バージョン固定、ビルドツールのインベントリ、および出所管理を推奨しています。
- web.dev — Responsive images ↗web.dev は画像のバイト数が大きくなる可能性を説明し、適切なユースケース向けにレスポンシブ画像の候補、srcset、sizes、picture を解説しています。
作成者： SIU Enablement の編集草案; 出典に基づく運用ガイダンス。 レビュー者： リリースオーナーは各プランをレビューする必要があります。任意のアカウント保存はサイトラベルとカテゴリ別アクション状態のみを非公開で保持し、SIU はリリースを承認しません。 再検証： 重要なリリース前、および所有権、ツール、顧客経路が変更されたときに再検証してください。