こんにちは、Hです。
現在携わっているプロジェクトもいよいよリリースが近くに迫ってきました。
期待感というよりは緊張感、不安感が強いのが正直なところですが、やるべきことを1つずつこなして
無事にリリースに近づけていきたいと思います。
今日はそのリリースに対する計画についてのお話です。
■プロジェクトにおけるリリース計画
リリース計画というと「製品のリリース時期やサービス内容」といったことを想像されると思いますが、
ここで言うリリース計画は「リリース当日におけるスケジュール、ステップおよび障害発生時の対策準備」を指しています。
もちろんリリース日より以前から告知、対社外との調整等々やるべきことはたくさんあります。
ですがリリース当日はシステムの入れ替えに対する作業、入れ替え後の検証作業がてんこ盛りで
また各部署と連携を取りながら作業を進めていきます。
そのため手順や連絡ミスが起こらないようあらかじめ計画・調整をしておく必要があるわけです。
それではそのリリース計画ではどんなことを決めていくのでしょうか？
今、私たちで作成しているリリース計画書には下記のような項目があります。
・リリースのステップ概要
・リリースのステップ詳細（手順・タイムスケジュール）
・リリース当日の体制（体制表・連絡フロー）
・関連するサブシステム一覧
・障害発生時のレベル判定
・障害発生時の切り戻しプラン
このうち「リリースのステップ概要」と「障害発生時の切り戻しプラン」についてどんな感じで記載しているかちょっとだけ紹介しておきます。
■リリースのステップ概要
リリース当日のステップは大きく移行と検証のステップに分かれます。
システムの閉塞が開始されて、処理中のリクエストが存在しなくなったら、システムが停止されます。
そしてそこから移行に関する作業が開始されます。
リリース計画ではこれらの各ステップにおいて実施する作業をまとめていきます。
例えば「2.移行前ジョブ実行」では閉塞間際に登録データをジョブで処理してきれいな状態にしておくことを目的として実行します。しかしながら時間帯によっては実行できないジョブがあったりするので、あらかじめ実行するジョブを洗い出して個別に実行するための手順を用意します。
「3.データベース移行」ではテーブル作成・変更から始まり、データ移行やデータ検証などといった作業を実施していきます。
このステップでまとめた内容と作成した手順書をもとにリハーサルを実施して、手順確認及び所要時間を計測していくわけです。そしてそれがタイムスケジュールへと反映されていきます。このリハーサルをどれだけしっかりとするかによって当日の作業ミスの明暗を分けていくように思います。
■障害発生時の切り戻しプラン
どれだけ準備をしたとしても何か予期せぬことが起こるのがシステム障害です。
そのシステム障害が起こった時に一時的にシステムを元に戻そうというのが「切り戻しプラン」です。
それぞれのステップの区切りで切り戻し対応が必要なレベルの障害が発生していないかを判断します。
特になければ次のステップに進みますが、問題が発生していた場合、速やかに協議・判断をして切り戻しの実施有無を決定します。
ここで切り戻しの実行が決定されたら「X.切り戻し実行」が行われ、そのあとの検証作業へと進みます。
切り戻しのためにはデータベース、ジョブ、システムそれぞれの移行を元に戻す作業や
一部モジュールについてはリリースしたりと複雑な作業が要求されます。
もちろん切り戻しが実行されないようにすることが一番大切ですけどね。
■最後に
リリース当日は自分たちが携わったシステムのリリースだけでなく、他のサブシステムのリリースも同時に行われます。
そんな中で1つ1つの手順をしっかり守ってリリースを終えられるというのはとても素晴らしいことです。
また万が一、予期せぬ事態になったとしても準備の有無によってそのあとの対応が変わってきます。
「やるべきことはきちんと準備して、何か起きた時には冷静かつ素早く対応する。」
そんな心構えで今回のリリース当日は臨んできたいと思います。
