リリース検証シナリオ
デプロイ直後に「とりあえず様子を見る」で終わると、回帰の発覚が遅れ復旧コストが膨らみます。本ガイドでは、デプロイ前後にWhaTapで何をいつ確認すべきか、ロールバックを決定する 基準 は何かを整理します。
このガイドが向いている方
- 日次・週次のデプロイ周期が速いチーム
- CI/CDパイプラインに品質ゲートを付けたいエンジニア
- カナリア・ブルーグリーンなど段階的デプロイを運用するチーム
- デプロイ後「なんとなくおかしい」と基準なしで判断する状況を減らしたいチーム
事前準備
- チームダッシュボード / アラートを運用中 → Quick Wins 3種 完了
- デプロイ時刻の記録 が可能(Jenkins、GitHub Actions、ArgoCDなどのCI/CDログ、またはチームWiki)
- ロールバック手順がチーム内で合意済み(最低でも「誰がロールバックを判断するか」)
リリース検証のタイムライン
デプロイ前 デプロイ直後10分 デプロイ後1日 デプロイ後1週
↓ ↓ ↓ ↓
① ベースライン ② 急性回帰 ③ 遅延回帰 ④ トレンド検証
確保 検知 検知 & 振り返り
① デプロイ前、ベースライン確保
ゴール: 「正常」 の基準値をデプロイ直前にキャプチャする
デプロイ直前の30分〜1時間分の次の値を記録しておくと、デプロイ後の比較が明確になります。
- ダッシュボード から次の指標をスナップショットとして保存してください。
- TPS(平均・ピーク)
- 平均 / 最長応答時間
- エラー率
- アクティブTX数
- ヒットマップのパターンをスクリーンショットで保存してください(回帰後の比較用)。
- 記録方法は次の3つのうち1つを選択してください。
- CI/CDパイプラインのステップで自動キャプチャ
- チームのリリースノートテンプレートに数値フィールドを設定
- Flexboard URLとデプロイ時刻をチームチャンネルに残す
ベースラインがあって初めて回帰が見える
「遅くなった気がする」より、「デプロイ前180ms → デプロイ後260ms、+45%」のほうが意思決定にずっと有用です。
② デプロイ直後10分 、急性回帰の検知
ゴール: 明らかな即時回帰がある場合、10分以内に検知 → 必要ならロールバック
使用メニュー: アプリケーションダッシュボード + 該当製品のFlexboard
注視する指標(優先順)
表 | リリース直後に注視する指標
| 指標 | 回帰のシグナル | 即時対応の候補 |
|---|---|---|
| エラー率 | 1%超の急増、特に5xx | ロールバックを強く検討 |
| 平均応答時間 | ベースライン比30%↑が持続 | 原因分析と並行、閾値超えでロールバック |
| TPS | 異常な急落(依存サービス呼び出し失敗の可能性) | ログ・トレースを確認 |
| エージェント接続 | Inactive発生 | プロセス起動失敗を確認 |
手順
- デプロイ完了通知を受けた時点から 10分タイマー を開始してください。
- ダッシュボードを30秒〜1分間隔でリフレッシュして ください(自動更新が速ければ手動リフレッシュは不要です)。
- 異常な指標を見つけた場合:
- ヒットマップ・トランザクション でパターン確認 → デプロイ前との点分布の変化
- トランザクショントレース でサンプルを1件掘る
- 必要に応じて 障害対応シナリオ の流れへ切り替え
- ロールバックの判断 は、事前に合意した トリガー基準 に従う(次セクション)
ロールバック・トリガー基準の例
チームが事前に合意しておく客観的な基準:
- エラー率1%超が5分持続 → 自動ロールバックまたは即時ロールバック決定
- 平均応答時間50%↑が10分持続 → ロールバック検討
- 新しい例外クラスの5xxエラー発生 → 原因確認の上で判断
直感と基準を区別する
「なんとなく嫌な感じ」は回避の理由にはなり得ても、判断基準にはなりません。トリガー基準があってこそ 人ではなく数値がロールバックを決める 形になり、感情的な負担も減ります。
③ デプロイ後1日、遅延回帰の検知
ゴール: 即時の回帰はなかったが、時間が経ってから現れる問題を捉える
代表的な遅延回帰のタイプ
- メモリリーク: デプロイ後1〜12時間でヒープメモリが徐々に増加
- コネクションリーク: DBコネクションプールの枯渇傾向
- GC頻度の増加: ウォームアップ後も正常に戻らない
- 特定時間帯のみ異常: バッチ処理や定期スケジュールとの相互作用
手順
- デプロイ後24時間が経過したら、ダッシュボード を 2日間範囲 で照会してください。
- デプロ イ前24時間とデプロイ後24時間を直接比較してください。
- ヒープメモリ・コネクションプール・GCの推移を確認してください。関連ドキュメント: ヒープメモリのアラート、DBコネクションプール
- 日次レポートでエラー種別の一覧を確認してください。
- トラフィックの時間帯ごとに性能変化を点検してください(ピーク時の再現性)。
④ デプロイ後1週、トレンド検証と振り返り
ゴール: 「このデプロイは長期的に良い変化だったか」を判断する
確認項目
- レポート で 週次レポート を使い、デプロイ前週とデプロイ後週を比較してください。
- Apdex、エラー率、TPS、応答時間の平均/p95/p99
- 該当週の イベント履歴 を確認し、新しいイベントルールの発動頻度が増えていないかを確認してください。
- ユーザーフィードバック(あれば)と技術指標が一致しているかを突き合わせてください。
デプロイ振り返りの記録(チームWiki)
リリース ${バージョン} 振り返り — ${YYYY-MM-DD}
## デプロイ概要
- 目的:(機能 / 改善 / 修正)
- 範囲:(影響を受けるサービス)
## 性能変化(デプロイ前後1週間の比較)
- TPS: X → Y (+Z%)
- 平均応答: X ms → Y ms
- p99応答: X ms → Y ms
- エラー率: X% → Y%
## イベント
- 回帰と判断したイベント:(あれば)
- 新たに発動したイベントルール:(あれば)
## 判断
- 成功 / 経過観察 / 部分回帰 / ロールバック
## 次のデプロイに反映すること
- (チェックリスト強化、新イベントルール、テストケースなど)
段階的デプロイ(カナリア・ブルーグリーン)運用のコツ
- エージェント名をバージョン・デプロイタイプで区別(例:
svc-v1.2-stable,svc-v1.3-canary)→ Flexboardやイベントタグでバージョン別比較が容易 - カナリアの割合が小さいときは 指標変化が埋もれないよう カナリアのみフィルタしたダッシュボードを別途保持
- トラフィックがカナリアへ移行している間、エラー率・応答時間を自動比較 するFlexboardを設計
自動化で引き上げる
デプロイパイプラインに品質ゲートを組み込む
- デプロイ直後5分、エラー率1%超で自動ロールバック するフックをCI/CDに追加
- WhaTap Open API で直近n分の指標を照会し、ゲートの判断に活用
MCPでデプロイ振り返りの下書きを自動生成
WhaTap MCP を活用すれば、AIエージェントに「直近のデプロイ前後1週間の指標比較レポートを作って」と依頼することで、振り返りの下書きを自動作成できます。数値収集の時間を大幅に短縮します。
結果確認
- デプロイ直前のベースラインが 記録 されている(どこかに)
- デプロイ後10分 / 1日 / 1週間の三時点で、誰が何を見るか が明確
- ロールバック判断は 事前合意の数値基準 に沿って行われる
- デプロイ1週間後、チームWikiに 振り返りの記録 が残る
リリース検証のルーチンが定着すると、「デプロイ後の漠然とした不安」が「体系化された検証フェーズ」に変わります。回帰の検知速度が上がる分、デプロイ周期も安全に短縮できます。
次のステップ
- 回帰検知時の対応ルーチン → 障害対応シナリオ
- デプロイ前後の指標を定期共有 → 性能レポーティングシナリオ
- チームダッシュボード・権限・アラート 体系の整備 → チームコラボレーションシナリオ