カットオーバー — 戻せる形で出ていけ

一言でいうと

カットオーバーはデプロイではなく、複数のチームが決められた順序で動く作業であり、その成否は、ロールバックを数字の基準であらかじめ決めておいたかにかかっています。

なぜ基準をあらかじめ決めるのか

「問題が起きたらロールバックしましょう」は、計画ではありません。明け方の3時に、人々が疲れているとき、「問題」の定義は人によって違い、その場で判断しようとすると、いつも同じことが起きます。「もう少し様子を見よう」が繰り返されて、元に戻せる時間を超えてしまうのです。

そのため、しきい値と観測区間、そして判断期限を、計画書に書いておきます。「04:00までにスモークが合格しなければ、元に戻す」のように時刻が決められていれば、その時刻に判断する人は、勇気を出す必要がありません。すでに決まっていることを実行すればよいのです。

カットオーバーは「デプロイ」ではない

開発者にとってデプロイは、ファイルを上げてサービスを再起動する作業です。SIでカットオーバー(cutover)は、それよりはるかに広い意味です。

[사전]  이행 계획 승인 · 백업 · 공지 · 서비스 중단 안내 · 배치 정지 · 연동 상대 통보
[본작업] DB 스키마 반영 → 데이터 이관 → 애플리케이션 배포 → 설정 반영 → 기동
[검증]  스모크 테스트 → 핵심 업무 시나리오 → 연동 시스템 상호 확인 → 배치 재개
[종료]  이행 결과 보고 → 상황실 운영 → 롤백 판단 시한 경과

このコードブロックの韓国語は、4つの段階を表しています。事前は、カットオーバー計画の承認・バックアップ・通知・サービス停止の案内・バッチ停止・連携相手への通知、本作業は、DBスキーマ反映からデータ移行、アプリケーションのデプロイ、設定反映、起動までの流れ、検証は、スモークテスト、主要業務シナリオ、連携システムの相互確認、バッチ再開の流れ、終了は、カットオーバー結果報告、対策本部の運用、ロールバック判断期限の経過です。

一度に複数のチームが、決められた順序で動きます。そのため、カットオーバーにはチェックリストとタイムラインがあり、各項目に担当者と想定所要時間、そして「期待結果」が付きます。期待結果がなければ、その項目が成功したかどうか、誰にも判定できません。

ロールバックは計画ではなく「基準」

「問題が起きたらロールバックしましょう」は、計画ではありません。明け方の3時に人々が疲れているとき、「問題」の定義は人によって違います。そのため、数字の基準をあらかじめ決めておきます。

指標	しきい値	観測区間	対応
注文APIのエラー率	5%超過	10分	ロールバック
ログインの応答時間p95	3秒超過	15分	様子を見て再評価
バッチの遅延	60分超過	1回	ロールバック
データ整合性の不一致	1件でもあれば	即時	ロールバック

そしてロールバックの判断期限を決めます。「明け方4時までに検証が合格しなければ、無条件で元に戻す」。この期限がないと、朝6時にも「もう少し様子を見よう」が繰り返され、結局、業務開始時間に、半分壊れたシステムでサービスを開始することになります。

バックアップなしで始めない

カットオーバーのチェックリストの1つ目は、常にバックアップです。そしてバックアップは、「取れた」ではなく、「復旧できる」ことを確認する必要があります。復旧を試したことのないバックアップは、バックアップではありません。

最低限、この3つは押さえます。

DBバックアップ(そして復旧所要時間の実測値。3時間かかる復旧は、明け方のカットオーバーではロールバックの手段になりません)
アプリケーションのアーティファクト(以前のWAR/JARと設定ファイル)
設定ファイル(Tomcatのserver.xml、context.xml、nginxのconf、ファイアウォールポリシー、バッチスケジュール)

特に設定ファイルのバックアップを忘れる事故がよくあります。アプリケーションはタグで元に戻したのに、server.xmlのコネクター設定やDBコネクションプールのサイズを、誰がいつ変えたのかわからない状態になります。

スモークテスト: 5分以内に終える

カットオーバー直後に行うスモークテストは、「機能がすべて動くか」ではなく、「致命的に壊れていないか」を5分以内に確認するものです。

サービスがポートを開いて応答するか(ヘルスチェック)
ログインできるか
DBコネクションが生きているか(照会1件)
連携相手のシステムへ出ていく呼び出しができるか(主要インターフェース1件)
エラーログに新しい例外が大量に出ていないか

これを自動化されたスクリプトとして作っておけば、明け方に手が震えても、判定がぶれません。人が画面を押して確認するスモークテストは、人が疲れるほど不正確になります。

統合テストでよく起きること

カットオーバー前の統合テストで出る欠陥には、パターンがあります。

環境の違い: 開発環境でだけ動くものです。原因の1位は設定ファイルとファイアウォール、2位はDBのデータ状態です(開発環境にはあるコード値が、本番環境にはありません)。
連携のタイミング: 相手システムのバッチが03:00に動くのに、こちらのバッチが02:50に動きます。文書には、どちらも「明け方のバッチ」としか書かれていませんでした。
文字セットと長さ: ハングルは、UTF-8では3バイト、EUC-KRでは2バイトです。カラム長20にハングル10文字を入れようとして、UTF-8で切れます。
権限: 本番環境のDBアカウントは、開発環境より権限が狭いです。CREATE TEMP TABLEができないことを、カットオーバー当日に知ることになります。

この4つは、カットオーバー前に本番環境と同じ構成の検証環境で1回リハーサルすれば、ほとんど取り除けます。リハーサルを飛ばしたカットオーバーは、明け方に即興演奏をすることになります。

カットオーバー結果報告書

明け方の作業が終わったら、結果報告書を書きます。形式は会社ごとに違いますが、必ず入れるものは次のとおりです。

実際の開始/終了時刻と、計画との差
実施した作業の一覧と、それぞれの結果
発生した課題と対応内容(対応できなかったものも書きます)
バックアップファイルの場所とロールバック手順(安定化期間中ずっと参照されます)
翌営業日の確認事項

この文書をきちんと書けば、安定化期間の障害分析が半分に減ります。「サービスインのとき、何を変えましたか」に答えられる唯一の文書だからです。

現場での姿

カットオーバー失敗の典型は、技術の問題ではなく順序の問題です。

バッチを止めずにデータ移行を始めたため、移行中に入ってきた案件が漏れます。
連携相手に通知しなかったため、相手システムがこちらの停止区間に電文を送り、それがすべて失敗として溜まります。
バックアップを取った時刻がスキーマ変更のあとだったため、戻そうとした瞬間に、戻すものがありません。

そして検証の段階では、スモークテストが長くなることが問題になります。5分以内に終わらないスモークは、判断期限を食いつぶし、肝心の「戻すか戻さないか」を決める時間を残しません。スモークは「主要な業務が動くか」だけを見て、残りは対策本部で見ます。

カットオーバー結果報告書に、実際のバックアップファイル名を書かせるのも、同じ理由です。「バックアップ完了」とだけ書かれた報告書は、肝心なときに、どのファイルなのかを教えてくれません。