通知 / 告知
通知先
- 顧客
- 必要に応じて、ビジネスパートナー
- ローンチの影響を受けるアプリケーションチーム
- サポートチーム
- ネットワークチーム (ネットワーク変更時や問題発生時に備えて待機)
- セキュリティチーム (問題発生時に備えて待機)
- マーケティングチーム (告知の準備、問題発生時の対応)
- ソーシャルメディアチーム (ソーシャルメディアの監視や対応の準備)
- 営業チーム (顧客からの質問に対応できるよう準備)
- カスタマーサクセスチーム (顧客からの質問に対応できるよう準備)
通知計画
- 対象オーディエンス (社内向け・社外向けの両方を考慮)
- メッセージ
- タイミング
- 依存関係
- 担当者 (誰が送信するか)
- 手段 (どのように伝えるか)
- テストメッセージと配信 (該当する場合。通知が送信されることを確認するためにテストを実施)
通知の配信
- ひとつの方法は、比較的小さな通知バッチから始め、問題が見つからなければ、時間をかけてバッチの規模を大きくしていくことです。
- また、世界各地に向けて時差に合わせたスケジュールで順次バッチ配信することで、システムに一度にかかる負荷を分散しつつ、各タイムゾーンで最適な時間に通知が届くようにして、メッセージが読まれる可能性を高めることもできます。
- 個々の顧客や地域、あるいはアプリケーションに適したその他の区分など、ユーザーの一部を対象にソフトローンチを行うこともできます。
停止時間帯 (必要な場合)
カットオーバー計画 (必要な場合)
- 必要に応じて、カットオーバー計画と切り戻し計画を文書化していますか?
- 変更前に何らかのバックアップは必要ですか?
- 事前に必要なデータ変更はありますか?
- 変更が必要な DNS レコードはありますか?
- ファイアウォールの変更はありますか?
- 新たな監視対象はありますか?
- 展開が必要なソフトウェアはありますか?
Go / no-go の基準
- エラーを最小限に抑えながら、ユーザー登録数が増加している
- 想定どおりの率でユーザーのログインが発生しており、エラーも最小限に抑えられている
- 報告されるサポート課題が一定のしきい値を下回っている
- データ破損につながるおそれのある問題が確認されていない
- ユーザー登録またはログインのうち、短時間では解決できないエラーになる割合が高い
- 短時間では解決できないサポート課題の件数が多い
- データ破損につながるおそれのある状態が確認された
- 重大度の高いセキュリティ上の問題が見つかった
ロールバック
待機連絡先
成功基準
リスクと緩和策の計画
- ソフトウェアのバグ
- ユーザーのブラウザー設定とアプリケーションの互換性の問題
- ネットワーク障害/停止
- DoS攻撃
- ホスティング環境の障害
- 負荷/容量の問題
- データ/破損に関する問題
- セキュリティ脆弱性の発覚