新版だけ失敗していない？｜変更承認・カナリア・切戻し

リリース後の失敗率が低ければ、新版は正常でしょうか。新版を少人数へ試す段階では、全体の数字に問題が隠れることがあります。承認から展開、停止判断、運用への引継ぎまでを一つの事例で考えます。

事例：新版へ5%だけ流したら、失敗が増えた

同じ確認期間のリクエストは合計10,000件。新版に5%の500件を流し、20件が失敗しました。旧版の9500件では19件が失敗しています。この事例では、新版の失敗率が1%を超えたら展開を止める条件です。

段階的な展開を行う前に、変更の目的、影響範囲、担当者、評価期間、停止条件を承認します。確認に使う最低件数や比較する処理の種類も決め、少量の数字だけで成功を断定しないようにします。

変更・リリース・展開は、何を管理する？

利用者に必要な修正を安全に届けるには、変更してよいかの判断と、何をどの手順で実行するかをつなげます。用語だけで工程を覚えるより、確認する対象と責任者を対応させる方が判断しやすくなります。

1. 変更管理

   目的、影響、リスク、実施時期などを評価し、必要な承認を得ます。緊急時の経路も決めます。

2. リリース

   確認済みのプログラムや設定などを、一つの版として特定します。依存関係と試験結果を対応付けます。

3. 展開

   対象の環境へ配置し、通信や稼働する版を切り替えます。停止判断、確認、切戻しの実施手順を持ちます。

承認済みでも、実施時の条件が変われば再評価します。別の障害が発生した、前提の設定が変わった、必要な担当者が不在といった場合は、承認の時点と同じ状態とは限りません。

全体0.39%でも、新版は正常？

新版の失敗率は20÷500×100=4%。旧版は19÷9500×100=0.2%です。全体は(20+19)÷10,000×100=0.39%となり、新版の悪化が多数の旧版の成功に埋もれます。

この条件では新版が停止条件の1%を超えるため、5%のまま止め、正常な旧版へ戻す判断をします。25%、100%へ拡大しません。応答時間、データの整合、業務結果なども合わせて確認します。

新版と旧版で利用者や処理の種類が偏ると、失敗率の差に別の理由が含まれます。同じ時間帯、比較できる負荷、最低件数、測定の範囲をそろえます。割合だけでなく、失敗件数と重大性にも注意します。

展開方式は、どれを選ぶ？

カナリアは一部へ先に流し、問題がなければ対象を広げます。ブルーグリーンは旧と新の環境を用意して切り替える方式、ローリングは少しずつ実行対象を置き換える方式です。目的と制約に合わせて選びます。

方式は組み合わせる場合もあります。名称だけで無停止や安全性が保証されるわけではありません。セッション、処理中の要求、DB、外部の接続先を含む切替の振る舞いを試験します。

プログラムだけ戻せば、DBも戻る？

旧版と新版が同じDBを使うなら、構造を両方から利用できる条件が必要です。例えば新しい任意項目を追加してから対応する版を展開し、旧版の参照・更新が壊れないことを確認します。

旧版が動く間に、必要な列を削除したり、未対応の必須条件を追加したりしません。互換性を保つ段階、データの補完、旧版の停止を順番に計画します。単に列を追加しても、全列の位置へ依存する処理などは壊れ得ます。

展開前へプログラムを戻しても、新版が受け付けた注文は残ります。戻した旧版がそのデータを理解できるかを確認し、必要なら変換・照合します。データを丸ごと古い時点へ復元すると、新しい正常な更新も失うため、独立した判断が必要です。

切戻しの手順には、何を書いておく？

停止する条件、判断する責任者、通信の戻し方、処理中の要求、設定と成果物の版、データの保全、確認項目を記載します。切戻しに要する時間と実施できる期限も、リハーサルで確かめます。

コンテナのDeploymentのロールバックなどは、実行対象の定義を戻す仕組みです。共有DBの内容や、外部サービスへ行った更新を自動で巻き戻すものではありません。操作の範囲を明確にします。

同じ手順でやり直せる成果物と設定を保持します。手元で修正したものを直接使うと、確認した版と本番の版が一致せず、原因や復旧条件を追いにくくなります。

公開した後、運用へ何を渡す？

稼働する版、変更点、監視の指標、既知の制限、問い合わせの案内、担当窓口、切戻し手順を引き継ぎます。結果を記録し、必要な確認が終わってから変更を完了扱いにします。

利用者への案内やサポートの準備も、業務へ届ける作業の一部です。失敗がなくても、運用担当が新しい動作を判断できなければ、異常時の対処が遅れます。

演習1：新版の失敗率

条件：新版500件中20件失敗。停止条件は1%超です。

問い：失敗率と展開判断を答えてください。

解答例：4%で条件を超えるため、拡大を止めて旧版へ戻す判断をします。

根拠：20÷500×100です。

誤答の理由：全体10,000件を分母にすると、新版の問題が薄まります。

演習2：全体の数字

条件：旧版9500件中19件、新版500件中20件が失敗しました。

問い：全体の失敗率と、それだけで判断できない理由を答えてください。

解答例：0.39%。新版の4%を多数の旧版の成功が隠します。

根拠：39÷10,000×100で、版別の分布は表しません。

誤答の理由：0.39%だけを1%と比べると、新版に設定した停止条件を見失います。

演習3：DBの互換性

条件：ローリング展開で旧版と新版が同時に稼働します。

問い：新しい項目の追加で何を確認しますか。

解答例：旧版の参照・更新と新版の処理が両立する構造にし、補完や必須化を段階的に行います。

根拠：両版が同じデータへアクセスする期間があります。

誤答の理由：最初から未対応の必須列へ変えると、旧版の登録が失敗し得ます。

演習4：正常な注文を守る

条件：新版が正常な注文を登録した後で、プログラムを旧版へ戻します。

問い：DBを無条件に展開前へ戻してよいですか。

解答例：いけません。新しい注文を保全し、旧版との互換性や必要な変換を確認します。

根拠：プログラムの版とデータの時点は別です。

誤答の理由：バックアップへ丸ごと戻すと、展開後に受け付けた正常な注文も失う可能性があります。

演習5：同じ版を再現

条件：展開後の問題を調査し、以前の版へ戻したいとします。

問い：何を対応付けて保持しますか。

解答例：ソースのコミット、依存、ビルド成果物、設定、試験結果、稼働版を対応付けます。

根拠：名前だけでは、実際に配置した内容を再現できません。

誤答の理由：版名だけを残して手元で再生成すると、依存や設定の違いで結果が変わり得ます。

演習6：運用の引継ぎ

条件：段階展開は正常に完了しました。

問い：完了判断の前に運用へ何を渡しますか。

解答例：稼働版、変更点、監視条件、既知の制限、担当窓口、切戻し手順を渡し、結果を記録します。

根拠：異常時に判断・対処できる状態まで整えます。

誤答の理由：配置の成功だけで完了とすると、利用者の問い合わせや運用判断に必要な情報が不足します。

出典と仕様を確認する

IPA：APシラバス Ver.7.2

Google SRE：リリースエンジニアリング

Google SRE Workbook：カナリア展開

AWS：データ同期とスキーマ変更

Kubernetes：Deployment

関連テーマを続けて学ぶ

データ移行と切替条件

ソースの版と取消し