コンティンジェンシープランとは、想定外の事態が起きた時に備えて事前に定めておく対応策のことです。
この記事では、プログラムのリリース時に定めておくべきコンティンジェンシープランについて、具体的に述べていきます。
プログラムのリリース作業は、事前に定められた一定の時間内に、プログラムを入れ替えて稼働確認を行う、という作業です。
例えば、特定の日の22:00-24:00をメンテナンス時間として事前に通知し、メンテナンス時間中はシステムの開放を止めてプログラム入れ替えと稼働確認を行う、というような作業を指します。
リリース作業時における主な想定外の事態は、稼働確認での不具合の発見です。
不具合を発見した時に備えて、以下のようなコンティンジェンシープランを事前に用意しておくべきです。
１．切り戻し作業の手順の用意と実施
新しくリリースしたプログラムに不具合が存在していたとしても、リリース時間内に元のプログラムに戻して稼働可能な状態に戻せば、利用者にはリリース前と変わらない機能を提供することができます。
リリースによるサービス水準の低下を防ぐという意味では、最も確実な対応策となります。
ただし、切り戻し作業自体にリスクが存在する（切り戻し作業を失敗し、戻せなかったり、より自体が悪化したりする可能性がある）ため、切り戻し作業を行う可能性があるのであれば、作業手順を事前に確立させる必要があります。
データの移行を伴う場合は、データの事前のバックアップとその戻しも必要になるので、特に注意が必要です。
２．サービス水準の低下を許容する方針の検討
切り戻し作業を行うのが最も確実ではあるのですが、発見された不具合が軽微なものであれば、その不具合を許容した上で戻さずにリリース作業を完了させる手もあります。
また、法律改正への対応のような、外部の変更に応じた対応の場合は切り戻し作業の実施自体が難しくなる（自社の判断だけでは切り戻し作業ができなくなる）ため、この場合も不具合を許容、最悪の場合は機能制限を加えた上でリリース作業完了させる必要が出てくることが多いです。
不具合を許容するかどうかの判断はその時々で柔軟に判断する必要がありますが、それを誰が判断するのか（作業時の責任者は誰なのか）は事前に決めておくべきです。
また、機能制限のような作業を行う可能性があるのであれば、その作業手順も事前に確認・確立させる必要があります。
３．切り戻し等の作業を開始するタイミングの確認
稼働確認で不具合が発見されたとしても、リリース時間内に修正できるのであれば、修正するに越したことはありません。
また、切り戻しを行うのかサービス水準の低下を許容するのかの判断が必要になる可能性もあります。
このように、不具合が発見されたとしても、切り戻しの行わない、という判断をすることがあります。
しかし、切り戻し作業にも時間が必要なので、その判断をいつまでに行うのか、ということは事前に決める必要があります。
例えば、24:00までにサービスを再開する必要があり、切り戻し作業に（余裕を見て）30分かかる場合、切り戻しを行うかどうかの判断は23:30までに行う必要があります。
23:30までに修正が完了しなかったり、サービス水準低下の許容の判断ができなかったりするのであれば、安全側に倒すために23:30を迎えた瞬間に切り戻し作業を開始するべきです。
いかがでしたでしょうか。
今回は、後輩に指導したことを記事として残しました。
記事に書いたことは、保守作業に携わるエンジニアであれば意識するべきことです。
大規模なシステムでは書類の形でプランを作る必要がありますし、小規模なシステムであっても関係者間で事前に認識を共有しておくべきです。
指導した内容はこれからも記事として残すようにしていこうと思います！
コメント