こんにちは、アプリ開発グループのdomonrです。
今回は CloudSQL の DB バージョンアップを実施した際に感じた、「技術的な話以外で、何が大変だったか」をまとめました。 本記事では、互換性チェックやSQL構文のような技術的内容ではなく、「どう段取りを組み、どう判断し、どう連携したか」といったマネジメントの観点にフォーカスしています。 DBのバージョンアップを予定している方にとって、準備のイメージがつかめるきっかけになれば幸いです。
1. スケジュール設計
リリースのスケジュールは、ユーザー影響や運用リスクを最小化するための基盤です。週末やアクセス集中時間を避けるだけでなく、他プロジェクトやキャンペーンとの干渉を事前に調整することで、万一のトラブル時にも影響範囲を限定できるように設計しました。
また、メンテナンス後数日間のリスク回避期間を設け、原因切り分けがしやすい状態を意識しました。
✅ やってよかったこと
- 週初めのユーザーが少ない時間帯を選定
→ システム障害が発生した場合の顧客影響を最小限に抑えられた - 年度末・月末などの繁忙期を避けて調整
→ 負荷が集中する時期を避け、業務部門への負担を軽減 - 他プロジェクトや重要施策との競合を回避
→ 他チームのリリースストップやキャンペーン期間と重ならないようにスケジューリング - リリース後2日間は他リリースを控える運用
→ トラブル発生時、原因の特定や切り分けが容易になった
🛠 やったほうがよかったこと
- メンテナンスおよび影響時間の詳細な共有
→ 影響時間の詳細が早めに共有されていれば、事前に懸念事項の洗い出しがしやすかったと思う。具体的な終了時刻によって必要な対応が変わる可能性がある。
2. チーム体制の設計
トラブル発生時の迅速な対応は、明確な役割分担と体制設計に左右されます。全員が同時に作業するのではなく、アップデート作業と不具合対応を分離し、どちらも滞りなく進められる体制を構築しました。
✅ やってよかったこと
- 事前に報告経路と基準を策定
→ 誰にどのタイミングで報告するかが明確化され、緊急時もスムーズ - Slackチャンネルを事前開設し情報集約
→ リアルタイムで状況が共有でき、重複作業や連絡漏れを防げた
🛠 やったほうがよかったこと
- 不具合対応メンバーとの情報共有
→ 不具合対応メンバーと内容の共有が事前に行えていなかったので、事前に情報共有しておくと、より安心して対応できた
3. 告知・ステークホルダー調整
関係者への周知不足は大きなリスクになります。メンテナンス日時やリリース制限を余裕をもって告知し、各部署と認識を合わせることで無駄な調整や突発対応を減らしました。
✅ やってよかったこと
- 影響情報の事前整理と展開
→ メンテ期間、リリース停止、緊急対応フローを明文化 - 2週間〜1か月前の早期告知
→ 各部署が計画を調整する余裕を確保 - ユーザー向け案内とCS連携
→ 問い合わせやクレームリスクを低減 - Googleカレンダーで共有
→ 担当者が複数でもスケジュール確認が容易
🛠 やったほうがよかったこと
- 事前に他部署に頭出しをしておく
→ 全体共有の前に各部署にあらかじめ頭出ししておけると、全体共有時の調整がよりスムーズになった - 普段のメンテナンスとの差分を共有 → 普段のメンテナンスとの差分を共有しておくことで、より理解を得やすかった
4. 作業タイムラインの設計
作業手順とタイミングを明文化することで、混乱を防ぎました。集合から解散までの行程を分刻みで計画し、役割を明確に割り振りました。
✅ やってよかったこと
- 集合〜解散までのスケジュール化
→ 作業の抜け漏れを防止 - アクセス停止確認やバッチ再開の担当割り振り
→ スムーズな進行が可能に - 項目ごとに事前リハーサル実施し時間を計測
→ 考慮漏れや想定外の事態が発生するため事前に実施することで解消しておける - 想定外の遅延にも対応できるよう、余裕を持たせたバッファ時間が効果的だった → 作業2時間に対してメンテナンスを2時間
🛠 やったほうがよかったこと
- 進捗報告の担当者決め
→ 進捗報告タイミングと報告者を事前に決めておけるとスムーズに進められた - スケジュールの詳細化
→ 動作確認についても、内容と時間をもう少し細かく見積もっておけるとよかった 例: 動作確認後のテストデータの後処理対応の時間が確保されていなかった - 事前に準備可能な作業をできる限り行っておく
→ 作業が軽微なため当日に回した作業で想定外の事態が発生した。対応可能な作業は事前に実施しておけると、当日のリスクをより減らせた 例: revert PR を作成していなかったためにCIでのエラーが発生したりCI待ちの時間が発生した
例（タイムライン）
- 23:50 Gather集合
- 00:00 バッチ停止対象を停止する
- 00:00 メンテナンス開始
- 00:05 アクセスがなくなることを確認
- 00:10 アップデート作業開始(同時にバックアップ作成)
- 01:00 アップデート完了(川口)
- 01:00 動作確認開始
- 02:00 動作確認終了
- 02:30 切り戻し開始デッドライン
- 02:30 ~ 03:30 切り戻し作業予定
- 03:30 ~ 04:00 バッファ
- 04:00 メンテナンス解除、様子見(作業完了次第なので早まる場合あり)
- 04:00-04:10 アクセスできるかと気になるところ念の為最終確認
- 04:00 バッチ停止対象を再開する
- 04:10 解散
5. 切り戻し戦略
切り戻しは、サービス停止の長期化を避けるための重要な手段です。今回は、切り戻し可否の判断ラインとタイムリミットを事前に決め、準備を整えました。
✅ やってよかったこと
- 切り戻しはメンテ時間内に限定する方針を明確化
→ メンテナンス明け後はデータの不整合が発生するため切り戻しは行わない - 最終判断時刻の事前設定
→ 切り戻しにかかる時間を事前に計測し、メンテナンス終了時間から逆算して設定 - 接続先IPやバックアップ、リストア手順を事前準備
🛠 やったほうがよかったこと
- 切り戻し作業の詳細化
→ 切り戻しが発生しなかったのでよかったが、実際に切り戻しが発生した場合に備えて、もう少し詳細な手順を整えておけるとよかった
6. 動作確認の設計
すべての機能を網羅的に確認するのは現実的でないため、重要な業務フローに絞り込みました。限られた時間で効率的に品質を担保できる構成にしました。
✅ やってよかったこと
- 顧客影響の大きいフローに集中
- 事前に代表ケースを選定
→ 1回は必ず事前にリハーサルを行いできるだけ本番に近い形で実施して時間内に終わることを確認したほうがいい
🛠 やったほうがよかったこと
- 本番環境でのバッチの動作確認 → 本番環境でバッチの動作確認まで事前に準備しておけると、確認範囲がさらに明確になった
- Redash(BIツール)の考慮が漏れていた → ツールのよってはDBのバージョンに対応していない可能性があるので可能であれば事前に確認しておくと良い
7. テストデータと後処理の設計
テストデータの作成から後処理まで一連の流れを計画しました。これにより、確認後のデータ整合性問題を防ぐことができました。
✅ やってよかったこと
- 事前に対象のテストユーザーを作成
→ 当日の負荷を減らし事前に対象のIDを記載できるのでデータ削除時の漏れも防げる - テストデータを実際に発行し検証
- 確認後のデータ消去・無効化の実施
- ID共有により対応漏れ防止 → 事前に表を作成し記載漏れが起きにくいようにしておく
🛠 やったほうがよかったこと
- 後処理チェックリストの自動化
→ 人による後処理ミスをさらに防ぐため、記載したIDを元に確認用クエリを自動的に作成するなどの仕組みがあると良かった
8. インシデント対応のルール化
リリース後のトラブルをどう扱うかを事前に決め、迷いを減らしました。
✅ やってよかったこと
- クリティカルインシデントと通常バグの区別を明確化
→ クリティカルなもの以外はリリースストップ期間後にリリースする方針にすることで影響の切り分けを行いやすいようにしておく - 原則Hotfixで対応し切り戻しを最小化
→ 対応する場合は最小限の修正にとどめることで影響の切り分けを行いやすいようにしておく
🛠 やったほうがよかったこと
- 深夜対応後のメンバーの選定
→ 深夜対応のバージョンアップ作業にPJメンバーを全員アサインしていたため翌朝の待機メンバーにPJメンバーがいない状態になっていた
9. まとめ
DBバージョンアップは、事前の調整と準備次第でトラブルを大幅に減らせます。「いつ切り戻すか」「どの範囲を確認するか」を明文化することで、関係者全体の認識が揃い、スムーズな進行が可能になります。今回の経験をテンプレート化することで、今後のリリースにも応用できると感じました。
