「うるう」年などに起因するシステム障害に備えるには

今年はオリンピックイヤーであり、閏（うるう）年。先月は日本を含め世界各地でこれに起因とみられる様々なシステム障害が発生しており、こうした障害時のトラブル発生に備えておくには何が必要かを踏まえ、解説します。

システム障害事例

とあるドラッグストア大手の事例ですが、お客さまから処方箋を受領、処方内容に従って調剤、会計までのフロー。しかしながら会計フロー時のレセプトコンピュータソフトウェアに「うるう年」が要因とみられる障害が発生したため料金の会計処理ができなくなる事態が発生。支払いができなかったお客さまには後日料金を支払っていただくことで事なきを得ましたが、こうしたことが続けば「顧客離れ」につながりかねません。

また海外でもニュージーランドでは全国のセルフガソリンスタンドにおいて障害が発生、多くの店舗を閉鎖せざるを得ない状況に陥りました。

５つの想定される要因

日付の計算プログラムの不備	年や時刻を正しく計算できないOSやアプリケーションプログラムでは、最悪の場合に日付処理を誤り、システムが不整合を起こして停止
オーバーフロー	日付や時刻を表示するためのプログラム内の変数の値がオーバーフローして停止
データベース設計ミス	日付情報を格納する際、設計時にうるう年を考慮していないとデータの整合性が失われ、処理が停止
ライブラリやフレームワークの不具合	システムによっては外部のライブラリやフレームワークを利用しており、そうした外部要因に依存する不具合発生
セキュリティ証明書の期限切れ	有効期限が誤って計算され、セキュリティプログラムが誤作動して処理が停止

過去に重大な影響を及ぼしたのは

著名なのがいわゆる「2000年問題」。システム障害が発生した要因は二つ。一つめはデータベースやメモリ使用の容量を抑えるために考案された年号の下2桁だけを取り出す様、設計されたプログラム処理に起因したもの。二つめはうるう年の判定にプラグラム側が失敗したもの。当時は、処理が停止したプログラムが続出して業務に大きな悪影響を及ぼした企業も多かったようです。

見通し

こうした「西暦年」を起因としたシステム障害の問題が生じそうなのが、「2025、2036、2038」年と言われています。と言うのも25年は元号換算で昭和100年に相当しており、プログラムやデータベース内部で昭和換算されていた場合に下2桁の数値を昭和00年と誤認識されると処理が停止する恐れがあるのです。36年はコンピュータシステム同士の時刻を同期させるプロトコルNTP（Network Time Protocol）が桁あふれを起こす可能性があり、NTPの誤動作に起因するシステム障害が危惧されています。また38年はUNIXやUNIXとの互換システムにおいて1970年1月1日0時0分0秒からの経過時間を32bitで表すと2038年1月19日において桁あふれが生じる可能性が高く、誤動作しやすいのです。

障害発生に向けた対策には

自社で利用しているOSやアプリケーションプログラム、データベースに関する問題を検証、改修にむけた調査や予算を確保することです。ベンダーや専門家、コンサルタントに助言を求め作業を確認すべきでしょう。特に集中的に取り組むべきなのはレガシーシステムと言えそうです。問題が残っている可能性が最新システムより非常に高く、システムやプログラムに問題がないかの確認テストと検証が絶対に必要だと断言しておきます。

次に必要な対策がバックアップと復旧計画の策定です。システム障害が発生した場合に備え、適切なバックアップ体制の確立と復旧計画を綿密に策定しておけば障害が発生したとしても、迅速に復旧できるため後顧の憂いを減らすことにつながるのです。

お問い合わせはこちら

費用やスケジュール・サービス詳細に関するご不明点や疑問点などもお気軽にお問合せください。原則翌営業日までにご回答しておりますが、内容によりお時間がかかる場合も…

PlatSupplyConsulting