【ITSM】#6:リリース管理

こちらも文字通り読み取ると、いくつか抜け落ちてしまう可能性がありますね。
リリース管理は、いわゆるシステム開発・改修から運用させるまでの間を管理することになります。そのため、リリース直前直後のみの管理ではない、ということになります。

このため、普段からITシステム開発・改修している人にとっては特別なことをやるわけではありません。要件定義・設計・開発・単体テスト・結合テスト・UAT・リリースという流れとなります。

ここで大事な点は、
・メンテナンスウィンドウ
・リリース後の対応
ですかね。

変更管理にて承認されたものが、次々とリリース管理へ移ってきます。その中には、大なり小なりいろんなものが含まれています。
そこで、テストが終わった順にリリースしていく、とすると、様々なリスクが想定されてしまいます。例えば、毎日リリースすることになるかもしれません。リリースする際には、システムによってはユーザへ事前アナウンスをしますし、非稼働時間の作業が発生したりします。これを毎日実施することになったら、ユーザもIT担当者も大変疲れます。次のトピックにも関わりますが、リリースしてゴールではないので、その後の継続的な運用をヘルシーに保つことを考えると、これは悪手です。
ということで、毎月決まったメンテナンスウィンドウを設け、ここに間に合う開発・改修をまとめてリリースする、ということが効率的な運用となります。
もちろんこれはあくまで例ですので、これが毎週メンテナンスウィンドウを設けてもいいです。大事なことは、定例化しておくことで、逐一リリース日の調整をしなくて済むことです。ユーザも分かりやすいし、IT側も分かりやすいのです。

次にリリース後の対応です。ITSM/ITILでもよく言われていることとして、リリース直後が一番インシデントが発生する。という点です。
いろんなものをリリースしていくほど、そういうことが発生するリスクがあります。所詮は人が作ったものなので、完璧ということはなかなかあり得ません。問題は、それをすぐに検知して復旧することになります。が、いろんなものをリリースすると、どれが原因なのか？がすぐに分からなくなります。そうなると、復旧までに時間がかかり、事業やユーザに迷惑がかかります。ひいてはIT部門への信頼が落ちてしまいます。
そういったことまでを想定して、リリースする件数を決めておくべきですし、もし不具合が出てしまった場合の切り戻し計画・リソース計画も合わせて考えておくべきです。

そんなことに気をつけておけ、というのはなんともITSM/ITILらしいベストプラクティスだと思いました。いろんな会社がやらかしてきたことをしっかりと踏まえて、（リソースが不足していようが面倒臭かろうが）こうすべきと書いている点を、個人的にはとても信頼しています。
改めて、ITSMツールがなぜそういう作りになっているか、という出発でもいいのでITSM/ITILを深掘りして勉強していくと、ちゃんと理由や背景があって、（面倒だけども）やったほうがいい、と思えるでしょう。

以上