システム障害を極小化させるコツ

前回は、「段階的な本番リリースやパイロット稼働でシステム障害の発生リスクの影響を最小限に抑える手法がオススメです」というお話をしました。
前回投稿してから、ずいぶん間があいてしまいましたが、お付き合いください。

本番と同じ環境で事前テストができない場合、事前テストができたとしても、未知のデータや、これまでのテストケースにない状況が発生するなど、システム新規稼働やシステム変更後の本番リリースには、不測の事態が発生することが考えられます。

「この世の中に絶対はない！」という視点に立てば、事前テストを十分やったとしても、本番稼働はどういう結果になるか、うまくいく保証はないので、「段階的な本番リリースやパイロット稼働などの手法」を検討することが求められます。

その背景目的とは？

「段階的な本番リリースやパイロット稼働」とは、いきなりシステムの新規稼働や、システム変更の本番稼働を全利用者に対して行うのではなく、最初はごく一部の利用者にだけ、例えば全体5％程度に限定しリリースして使わせることです。

そうすることで、もし本番稼働したシステムに不備や不具合が発生しても、障害の影響を受ける利用者がごく一部に限られるので、リカバリ対応も容易になり、ビジネスへの影響も少なくできるメリットがあります。

システムの利用者全員にいきなり全適用して障害が発生したら、その影響は膨大になってしまう。そのリスクを避けるために、「段階的な本番リリースやパイロット稼働でシステム障害の発生リスクの影響を最小限に抑える手法がオススメです」というわけです。

「段階的な本番リリースやパイロット稼働」はどうやってやるのか？

「段階的な本番リリースやパイロット稼働」と言っても、そう簡単にはできません。
新規システムやシステム変更の発注者である顧客は、特定の日に新しい業務やサービスを利用開始したいわけです。

その顧客にどう納得させるのか。その判断基準は、万一発生するかもしれないシステム障害の影響度に依ります。
そのシステム障害のリスク許容後が、高ければ高いほど、「段階的な本番リリースやパイロット稼働」を実施する価値はあります。

逆に、それほど重要でないシステム、システムの利用者が社内内部の関係者に限られるなど、システム障害の影響が大きくない場合は、「段階的な本番リリースやパイロット稼働」の優先度は下がり、やる手間を省くことも考えられます。

要するに、システム障害時のリスク許容度に応じて、発注主である顧客とよく話し合う必要があるのです。

もしシステム障害が発生して、それでシステムが止まっても、その日はシステム利用者側で手で事務処理を代替するとか合意できれば、無理して「段階的な本番リリースやパイロット稼働」をやる必要はありません。

あと、システムそのものが「段階的な本番リリースやパイロット稼働」にそぐわない場合もあります。例えば、ネットワーク切り替えなどはその典型例です。ネットワークのインフラ基盤の切替えは、一発勝負的なところもあり、「段階的な本番リリースやパイロット稼働」と言うわけにはいかないケースが多いです。

「段階的な本番リリースやパイロット稼働」ができない場合は？

システム障害時の影響が大きく、やりたくても「段階的な本番リリースやパイロット稼働」が出来ない場合は、どうするのか？

その時は、腹をくくって、障害発生時のリカバリ対応、復旧対応を即時にできる体制を組むしかありません。新規システム稼働時や、システム変更の切替え時に、障害が発生したら調査が即開始できるよう、必要な要員の待機体制、連絡体制を取ります。

障害が発生するか、しないかわからないものに対し、人を張り付けるのですからお金がかかりますが、背に腹はかえられません。

予め想定される障害原因、障害の可能性をシミュレーションして、想定される障害箇所ごとに調査担当者を決めておき、障害発生に備えるのです。

復旧不可能な場合は、旧システムに戻す手順を準備しておきます。何があっても、対応が取れるよう可能な要員リソースを動員するのです。

また、システム障害発生時には利用者への連絡網、連絡手段、連絡する周知文書も事前に用意しておきます。

まとめ

今回は、「段階的な本番リリースやパイロット稼働でシステム障害の発生リスクの影響を最小限に抑える手法」についてお話しました。

次回は、「事前の十分なテスト」や「段階的な本番リリースやパイロット稼働」を実施しても、システム障害が発生した場合、「障害発生時の対応待機体制」をもってして、どのような対処するかを経験談を交えてお話したいと思います。