アプリケーション障害とサービス停止は、会社のオンライン販売、顧客サービス、社内プロセスに急激に大きな影響を与える可能性がある。2011年、みずほ銀行がシステム障害を起こしたことで、同社の大規模なATMサービスとインターネットバンキングサービスは数日間停止し、116万件、総額約100億ドルに相当する取引に遅れが生じた。ニュージーランドの通信会社で起きたソフトウェア障害では、4万7000の顧客が本来よりも早くデータ通信サービスの上限に達し、不正に課金された。同社は顧客に対して270万ドルの和解金を支払った。これらは大規模なソフトウェア障害の例で、上級役員が解雇される類のものだが、小さなアプリケーションの問題であっても、大金が必要になったり、経営への不満を抱かせる可能性はある。
IT部門はサービス停止の影響について、メルトダウンを予兆の段階で察知することも含めて、考慮しておく必要がある。この記事では、アプリケーション障害の兆候について議論し、最悪の事態に陥る前に問題を発見するためのアドバイスを紹介する。
1．障害を定義する
企業アプリケーションの障害にはさまざまな形があるが、もっとも多いのは顧客サービスや従業員の生産性を乱す日常的な問題だ。IT部門は問題のトラブルシュートや解決をしようとして貴重なスタッフの時間を無駄にし、事業部門は金銭的な損失を受ける。ソフトウェアに対する小さな修正が、業績に影響を及ぼす未知の問題を生む場合もある。Google、AOL、Bing、Shopzilla、その他のインターネット業界のリーダーたちは、応答時間がほんの少し長くなっただけでも（0.4秒か0.5秒でも）、理論的にはユーザーに対する影響はないはずであっても、サイトの利用頻度、そして収益にかなりの損失を与えることを知っている。企業は何をもって自社のコアシステムのアプリケーション障害とするかを、事業部門にとって、ユーザーにとって、あるいは顧客にとって受容できない結果はどういうものかという観点から、前もって定義しておくべきだ。
2．エンドユーザーから見た応答時間を調べる
従業員や顧客がヘルプデスクに電話をかけてくるのは、サイトやアプリケーション、トランザクションが目に見えて遅くなり始めたときだ。まず、受容可能な応答時間のしきい値を定義すること。これは、システムや関連するトランザクションの重要性によって変わる。このデータは、サーバのログ、ウェブサイトの指標化ツール、あるいは個々のアプリケーションで利用可能な監視データを含む、多様な情報源から得られる。企業は個々のシステムやウェブサイトの応答時間を集約するアプリケーション集中監視システムを持ち、IT部門が事業に必要不可欠なトランザクションに不具合が起こっていないかを1カ所で見て取れるようになっていると理想的だ。
3．トランザクション量を監視する
最近では、誰もが「ビッグデータ」の話題や、ウェブや他の場所から得られたペタバイト単位のデータストリームを収益化する方法について話している。データ量の爆発的増加に伴う問題は、予期しないトランザクション量の急増が起こり得るということだ。それらの急増がどのような時に起こりやすいかを知っておくことは、アプリケーションメルトダウンを避ける1つの方法だ。さもなければ、ストレージやサーバシステムが適切に準備されていないと、アプリケーションやウェブサイトがその圧力に負けてしまうかもしれない。
