先日、お客様の新規システムのリリースがあり、開発担当のリリース支援として現地で待機していたときのこと。
ちなみに、新旧システム間のデータ移行が想定通りに進まず、最終的には切り戻しとなりました。データ移行はお客様側の作業。「切り戻し」とは、新システムのリリースで何らかの問題が発生した際に、旧バージョンのシステムに戻すことを指します。
今回、移行対象のデータ量が多かった上に、たびたび移行データの不備 (不整合) が発生していたようです。データを直しつつリトライしていたようですが、さすがに終わる見通しが付けられなかった模様。
そもそも、対象がECサイトのシステムであり、メンテナンスにより深夜から日中にかけてサービス停止していたため、さすがにビジネス的なインパクトが大きかったと思います。
とは言っても、さすがに切り戻しを判断するのが遅すぎたように思えます。
所感
なんとかデータ移行とリリースをやり切ってサービスインするという意思は感じたけど、もう少し早いタイミングで切り戻しを決断できなかったものか。
もしかしたら、自分たちが見えている範囲ではやり切れるという自信があったのかもしれません。しかし落とし穴は見えないところにあるものです。
リリース計画やリリース手順を準備していても、計画通りにいかないことはあると思います。そして、計画にない作業を手探りで進めていると、次第に冷静さを欠いていくものです。特に、リリース作業のような非日常の状況下だと。
その結果、適切なタイミングで大事な判断ができず、ズルズルと長い時間に亘ってわるい状況が続いていったりします。
こういう状況になる前に勇気を持ってストップをかけられるか、切り戻しの判断ができるか、これが大事だと思いました。もちろん、切り戻しの作業をリリースの計画に含めておくことは重要です。切り戻しで事故ったらどうしようもないので。
ただ、当事者の立場だとなかなかこういう決断は難しいものです。なので、マイルストーンを置いてそれに従うことを徹底するのがポイントかなと思います。それか、当事者以外のひとがスケジュールを管理するとか、とにかく機械的に判断できる状態にするのが重要かと思いました。
また、システム自体も、切り戻し可能かつ切り戻ししやすいアーキテクチャにするのが大事だと思います。
その他
今回、自分はリリース支援の立場で、直接リリース作業に関わっていたわけではないのですが、いろいろと学びがありました。ちなみに、前日夕方から仕事しており、そのまま深夜リリース、翌日夕方過ぎまで立ち合いしていたため、28時間勤務となりました。
