リリース、カットオーバー、ローンチ、デプロイ・・・・呼び方はともかく、リリースはSI作業の中で最も気を使います。リリースに失敗してシステムが利用できなくなったり、データが消えてしまったりすると、ユーザーに迷惑がかかるだけでなく、開発者側にも大きな負担が発生するからです。ソフトウェア本体の開発と比べると軽視されがちですが、失敗したことがない人はいないぐらいとても難易度の高い作業です。
そこで、失敗すると生命や財産に多大な影響が発生するミッションクリティカルなシステムのリリースルールから、失敗を防ぐためのポイントを探ってみましょう。
環境
ミッションクリティカルなシステムのリリースルールを運用するためには、土台となる3つの環境が必要になります。
開発環境
普段、開発を行う環境です。PCやサーバといったコンピューター類だけでなく、VPNやLANといったネットワーク、ストレージもセットで構成されているのが一般的です。ネットワーク的には、外部から侵入できないようになっています。ここでリリース対象物のテストまで行います。
ステージング環境
ステージング環境はリリース対象物を開発環境からいきなり本番環境に適用するのはリスクが大きいので、予めリリースについて検証するための環境です。基本的に本番環境と同一のシステム構成ですが、予算の関係から最低限の構成となっている場合が多いと思います。この環境で、リリース対象物が適切であること、リリース手順が想定通りであること、リリース後にシステムが正常に動作することを担保します。
本番環境
実際にユーザーが利用する環境です。商用環境、プロダクション環境と呼んだりもします。ステージング環境で担保されたリソースや手順を用いてリリース作業を行います。
3つの環境は論理的に、場合によって物理的に分かれていて、互いに干渉しないようになっています。でないと、開発環境を触っていると思ったら実は本番環境だった・・・なんてことが起こりかねません。予算の都合上、開発環境とステージング環境が同一であることもあります。
ポイント
以前、日経SYSTEMSの記事にも書いたことがあるのですが、なによりもまず__運用の品質を開発段階にて作り込む__のがポイントです。精緻なリリース計画や正しい手順の実施以前に、仕組みとして運用品質を作りこむのです。そのためには、必ずしも独立した環境を用意する必要はなく、例えば実際のプログラムや本番環境にステージング用動作確認モードを予め機能として埋め込んでおけば良いのです。
ルール
以上を踏まえ、ミッションクリティカルなシステムのリリースルールを見ていきましょう。リリースルールは大まかに分けて以下の6つに大別できます。
- 計画する
- 作業の前提条件を確認する
- 手順、パラメーター、ファイル等を全て揃える
- 作業を実施する
- 動作確認をする
- 何かあったらすぐに元に戻す
（つづく）