COLUMN

お役立ち情報

「システム障害」で企業が対応すべきことは?原因と対策事例を紹介

  • このエントリーをはてなブックマークに追加
システム障害とは

企業の規模に関わらず、Webアプリケーションや会計システムなど事業活動を行うためのシステムは既に必須となっています。

システムを提供する会社にとっては、ユーザー企業は重要なパートナーとして期待される一方で、気を付けなければならないのがシステム障害への対応です。お客様に提供しているシステムが急に使えなくなることによる企業へのダメージは、直接的・間接的に大きな影響をもたらしてしまい、決して無視できません。

本記事ではシステム障害の原因と対策を解説します。

システム障害として記憶に新しいのは、“KDDI”の通信障害でしょう。スマートフォンは日常生活において不可欠なものですが、その重要なインフラが2022年7月2日深夜に通信障害を起こし、4日夕方まで完全回復に至らず、3,915万回線という幅広い影響をもたらしてしまいました。KDDI髙橋誠社長自身が謝罪し、障害の詳細と復旧状況の説明を説明し、全ユーザに200円の返金となりました。この返金が業績に与えた影響は約75億円。ここに燃料費高騰の影響が加わった結果、営業利益は前年比で146億円ほどの減益になりました。

このように、一旦、システム障害が発生すると、お客様にご迷惑をお掛けするだけではなく、障害が回復したあともその補償および関連対応で、提供企業自体も大きな損害をもたらすことになってしまいます。

以下は、システム障害が発生した場合の損失額について紹介した例ですが、システムの誤作動によりシステム障害が発生した場合には直接的な損失だけではなく、企業イメージダウンによる損失が、その何百倍にもなってしまうことが、注目されます。

先のKDDIの例だと、スマホを選択する時に“auは障害がおきやすそうだから、選択するのはやめておこう” という消費者の思考につながってしまうことで、将来の売上を減らしてしまうことなるのです。

ケース 誤動作 情報漏洩 開発失敗 稼働延期
件数 4 2 1 2
直接的な損失 逸失利益 4億7500万 212億5000万 41億7000万 17億4000万
人件費 2億5600万 30億5000万   3億3000万
雑費 1000万      
IT費 8500万 0 69億4000万 2億6000万
賠償・訴訟費 4800万 6億8000万 2億2000万 8500万
小計 8億7000万 250億 113億3000万 24億1000万
企業イメージダウンによる損失 4409億 112億3000万 325億2000万 36億1000万
イメージダウンの比率 約500倍 約0.45倍 約2.9倍 約1.5倍

出典:DEOS「システム障害時の損害額とDEOSによる削減目標

そこで、システム障害について、改めて発生原因や対応策について理解することで、その重要性を確認していきます。システム障害対応、予防策の検討・実施について自社では、カバーしきれないこともあるでしょう。外部の専門家に、システムの安定稼働の管理を委託することも選択肢となります。そうしたサービスについてもご紹介していきます。

□■□■IT業務のお悩みやお困りごと、コスト削減をお考えなら、解決手段があるはず!まずはITボランチへご相談(無料)ください。お問い合わせはこちらから□■□■

システム障害の定義とは?

システム障害とは何か?

そもそも「システム障害」とは何でしょうか?

お客様に提供しているシステムは、お客様の社内ネットワークを介して利用させているケース、インターネット等を通じて利用しているケースなどが考えられますが、システムのサービスが、利用できない状態に至ってしまい、提供会社のシステムの不具合に起因すると判断された場合をいいます。一部のお客様だけが、使えない状況の場合には、利用者のパソコンや通信状況が悪いことが原因だったりしますが、そういった事象はシステム障害とは言いません。
システム障害の原因は、大きくわけて3種類に分かれます。

ハードウエアの故障、ソフトウエアのバグ、そして人的な設定ミスです。システム障害が起こらないように万全を期すことが、まず重要ではありますが、KDDIでさえも、大障害を起こしたように、全ての障害を防ぐことは不可能だと言えます。

その他にもサイバー攻撃によるサーバダウン、サイトの改ざんなどもシステム障害の1つと言えなくもないのですが、今回の対象からはフォーカスせずにお伝えします。

システムの稼働を監視すること、障害が発生した時に、素早く原因を特定し復旧できる体制を整えることも重要となります。

システム障害の原因

システム障害は先にあげた通り、3種類に大別されますが、発生の原因については、それぞれの要素ごとに特徴があります。


3種類の障害のどれに該当するのかは、障害の切り分け作業を行った上で、特定される必要があります。利用者から、“システムが利用できない“申請があった場合に、すぐに、発生原因を特定することは困難なため、システムの監視を行うことが増えています。

ハードウェアの監視、ソフトウエアの稼働監視、設定変更の監視など、システムが正しく正常に稼働していることを監視することで、システム障害の原因を迅速に特定することに繋がります。

ハードウェア障害

システムを構成しているサーバーやネットワーク機器などのハードウェアが物理的又は論理的に破損、故障するなどして起きる障害のことです。物理的な故障については、機器の経年劣化、事故や災害による破損、製品不良による故障などが主な原因です。

劣化が進んでいないか、日々のメンテナンスや点検による予防が重要となります。それでも障害が発生しまった場合に備えて、予備のハードウェアを用意しておくことも考えられるでしょう。

ソフトウェア障害

システムを構成するOS、ミドルウエア、アプリケーションプログラムにおける不具合によって起きる障害です。
システムが急に使えなくなった場合、すぐにソフトウエア障害を特定することは難しいので、システムの監視によって、システムを構成するソフトウエアの稼働サービスを監視しておくことで、何が影響してシステムを止めてしまったのかを想定できます。

例えば、ハードディスク容量・CPU・メモリが不足してソフトウエアが停止してしまった場合には、リソース解放その強化を検討することになりますし、システムリソースは関係ないが、定期的にソフトウエアが停止しまうような問題の場合、ソフトウエアの“バグ”であったりします。

OSやミドルウェアであれば、メーカーへのエスカレーションを行ったり、最新のプログラムを適用することで修正されることもあります。

自社で開発したソフトウェアであれば、社内で原因の特定、改修、再発防止を講じることになります。
いずれの場合も、責任の所在と対応依頼先を常に把握しておき、迅速に連絡が取れるようにしておくことが大切です。

人的ミス

サーバーの設定、ネットワークの設定を誤ってしまったことで、その後、システム機能の一部または全部が使えなくなることもあります。

設定ミスは誰でも引き起こしてしまうリスクはあるので、設定変更を行う際の管理を厳格に行う必要があります。
設定変更を行う人と確認する人を分ける、設定変更ができる人を限定するなど、変更管理のプロセスをつくりあげることで、そのリスクを最小化できます。

また、もしもの為にバックアップを取っておくことも重要となります。

システム障害の対応事例を紹介

次に、実際に発生したシステム障害の事例から、どのような障害だったのか、その障害をどのように復旧させ、どのように対策していったのか、影響はどれくらい出たのかを説明していきます。冒頭にご紹介したKDDIの通信障害事例にも、ニュース掲載された事例をご紹介していきます。

みずほ銀行の事例

みずほ銀行は、過去に何度も大規模障害をおこしていました。
特に2021年は複数回発生。2月28日に全国の8割のATMが停止、キャッシュカードや預金通帳がATMに飲み込まれるなどの大混乱がおこりました。障害発生から数時間後もATMの前から動けない利用者が続出しました。また、3月にはATMなどで3度の障害が続き、さらに8月から9月にかけても障害が頻発。2021年11月には金融庁から業務改善命令まで受けていました。

そのような中、本年10月17日午前9時30分頃、みずほ銀行の法人向けインターネットバンキングサービスの一部にログインしにくくなる障害が発生しました。

障害が発生する数日前の10月14日には、みずほフィナンシャルグループ(FG)と傘下のみずほ銀行が、昨年11月に出された金融庁の業務改善命令に対する業務改善計画の進捗状況を報告したばかりでした。

その要因としては、主に2つの面があると考えられます」と指摘されています。
ひとつは、システムの構造に起因するもの。みずほの新勘定系システム『MINORI』は、富士通、日本IBM、日立製作所などで構築されるマルチベンダー方式で、システムが複雑になっていることが障害を誘発しているようです。

もう1点は、障害発生時の事前・事後の対応力にかけている点です。第一勧業銀行、富士銀行、日本興業銀行の3行合併の弊害からガバナンス問題が長く尾を引き、障害発生時にも経営層への連絡が大幅に遅れてしまい、そうした対応の遅れが被害の拡大に拍車をかけたと考えられています。

引用:「もはや通常営業」の皮肉も… なぜ、みずほ銀行でシステム障害が繰り返されるのか

Amazon(AWS)の事例

今や、企業システムでは、当たり前に使われるようになってきたAWSサービスも大規模障害を起こしています。
2021年9月2日木曜日午前7時半ごろに、Amazon Web Services(AWS)の東京リージョンで大規模な障害が発生しました。これによって、三菱UFJ銀行やみずほ銀行のスマートフォン用アプリ、全日空では羽田空港などでチェックインを行うシステムに障害が発生、日本航空では貨物の情報に関わる一部のシステムに影響が出るなど、幅広い社会サービスが影響を受け、大きな問題となりました。

障害が発生したのは、企業のデータセンターなどからAWSへ専用線で接続するためのネットワーク接続サービス「AWS Direct Connect」。この障害は、同日の午後1時42分に解消しました。

障害の原因はDirect Connectが接続される場所から東京リージョンのデータセンターへの途中にあるネットワークデバイスで障害が起きたことだと説明されています。ネットワークデバイスに導入された新しいプロトコルを設定したことで障害が発生したようです。該当のプロトコルを無効にしたことで復旧に至りました。ネットワークデバイスが保有しているOSの不具合と想定されます。

参考:AWSの大規模障害、原因はネットワークデバイス 新プロトコル処理に潜在的なバグ

どちらの障害事例も、社会への影響は非常に大きく、利用ユーザのサービスを停止してしまい、“また、みずほ銀行か!” “AWSも障害をおこすクラウドサービスである“ 、という社会的な悪評を印象付けてしまいました。

システム障害が起きた際に企業が対応すべきこと

システム障害時に企業が対応すべきこと

次にシステム障害が発生した場合の対応について確認していきます。
システム障害が発生した場合には、お客様にご迷惑をおかけしている状態をまずは解消しなければなりません。
そのため、システムの障害状態を把握し、その状況をお客様にお伝えした上で、復旧を最優先で行う必要があります。

直ぐに復旧が難しい場合には、定期的にお客様に状況をお伝えしていきます。復旧が完全にできた上で、障害発生の原因と対策を検討していきます。

障害の状態を把握する

お客様から、システムが使えないと申告があったら、まずは、障害の状態を5W1Hで正確に把握することが重要です。

  • Who どのお客様から障害の申告があったのか?
  • When いつからシステムが使えなくなったと申告があったのか?
  • What どのシステムが使えなくなったのか?
  • Where 使えないのは一部のお客様だけか、同じシステムを使っている複数のお客様から申告がはいっているか?
  • How  どんな症状が発生しているのか?

上記を理解することで、システムの障害箇所を迅速に特定することに繋がってきます。

申告があったお客様はもちろんのこと、同じシステムを利用しているお客様にも影響がありますので、どのような障害が発生しているのか。それによって、お客様にどの様な影響がでているのかを伝えることが必要です。

障害の原因を特定する

障害発生状況を正確に利用者がお伝えできたら、次はシステム復旧に向けて、どこに障害が発生していのかを特定しなければなりません。前述の通り、システム障害は、「ハードウェア障害」「ソフトウェア障害」「人的ミス」のいずれかによって発生することが大半です。

システムの監視を行っていた場合には、ハードウエアの障害か、ソフトウエアの障害かの確認は容易でしょう。例えば、ネットワーク障害の場合、システム障害が発生しているユーザの拠点・フロアなどを確認することで、ネットワークの疎通確認を行い、ネットワーク機器の障害ではないか?と過程し、ハブを替えてみる、スイッチを替えてみる、など原因の特定につながります。

ソフトウエア障害の場合には、一般的には、申告のあったユーザのPCの再起動をしてみる、複数のユーザから同一のソフトウエアだけが使えないといった申告があった場合には、そのソフトウエアを構成しているサーバー自体又はアプリケーションのサービスを再起動してみることで直接原因が特定できることが多いようです。

障害の復旧を確認する

原因箇所がおよそ特定できたら、可能な限り、早く復旧させることを優先します。先の例で、ネットワーク機器の障害が発生したことで、特定エリアのお客様でシステムが使えなくなった場合であれば、ネットワーク接続の延長にある、ネットワーク機器の交換をすぐに実施します。

ソフトウエア障害の例の場合には、ソフトウエアのサービスまたはサーバーの再起動をしてみたことで復旧することがあります。

サーバのメモリやCPU過負荷が原因でソフトウエアが正しく稼働していない状態だった場合には、再起動によってリソースが解放され、障害は解消されることがあります。再起動しても復旧しないような場合には、ソフトウエアを構成するファイルやデータが破損しているようなケースも考えられるため、バックアップファイルをリストアして、復旧させることもあるでしょう。

人的設定ミスの場合、システム障害の発生直前に何らかの設定変更作業が行われていないか、機器の入れ替え作業が行われていないかを確認することで、障害箇所を想定することができます。

直接原因と思われる事象に対して、復旧作業を適用したら、申請のあったユーザが正しく、システムを利用できるようになったかを確認します。その上で、複数の環境で接続を確認し、確実に復旧したことを確認します。

複数の環境でシステムの復旧が確認できたら、復旧の旨を告知します。この場合、障害発生の5W1Hに沿って、それが現在どうなっているかを明確にお伝えすることで、まずは復旧作業が完了となります。

担当者に修理や修正を依頼する

システムの復旧が完了したら、次は、その発生原因を引き起こした問題を改修することに注力します。

ハードウェア障害であれば、該当するメーカの保守窓口を介して機器交換を至急依頼し、システムの停止可能なタイミング(深夜など)に機器交換を実施します。サーバのリソース不足だった場合には、サーバの増強を図るためサーバ提供のベンダーにその旨を依頼し、作業を進めます。

ソフトウェア障害の場合は、該当する外部のベンダや社内のプログラマなど開発者に発生原因の調査と対応を依頼します。発生した原因がOSやミドルウェアの場合には、発生した問題を解消するためのパッチプログラムが提供されている可能性があるため、提供ベンダーに、その確認も含めて調査を依頼します。システムの不具合の場合は、不具合箇所を特定し、プログラムを更新することが必要です。

人的設定ミスの場合は、そのミスが発生した原因を調査依頼します。

問題点の振り返りと再発防止策の策定

システム障害をおこしてしまった直接的な原因が分かったら、次に取り組むべきことは、根本的な原因への対応です。
ハードウエアは経年劣化により、いつかは機能しなくなるものです。それを見越して、システムを設計できていなかった、機器を冗長構成にしておくべきなのに、それが行われていなかったなど、ハードウエア障害を最小化するための設計が不足していたことが考えられます。

ソフトウエア障害の場合には、OS・ミドルウェア・アプリケーションのバグの直接原因を未然に防ぐことは、困難なため、OS・ミドルウェアであれば提供メーカからのバグ情報を定期的に確認する、開発したアプリケーションであれば、リリース前のテストを強化することが、根本的なバグの最小化に向けての対策となります。

人的設定ミスは、根本原因への対応が最も求められる対象です。設定変更を1人で行っているとしたら、その体制に問題がありますし、設定変更作業自体を作業実施前に関係者に周知していなかったとしたら、プロセスの問題です。それらを改善する取り組みが根本原因への対応につながります。ITILで必要とされている変更管理、問題管理を社内で構築することです。

しかし、こうした根本原因への対応は、自社だけで取り組みでは、専門性がないことで、対応チームを迅速にアサインすることが困難なことが多いでしょう。そうした場合、専門家に依頼するなどして根本の原因を特定した上で、ITILなどの確立されたフレームワークに沿って、プロセスや体制を見直した上で、再発防止策を作り上げることも必要になります。

*参考:ITIL「 ITサービスマネジメントのベストプラクティスをフレームワークとして体系化した管理の考え方」

専門家の支援を受けて、最終的には、社内に情報共有し、マニュアルやドキュメントにまとめていくことになります。
例えば、ITボランチでは、そうした障害の根本原因への対応を分析したり、再発防止のプロセス、対策を支援する専門家サービスです。

ITボランチのIT保守アウトソーシングサービスは、情シス・社内SEとして、現任のITご担当者のお悩みをうかがい、解決する。豊富な経験、ノウハウで貴社の「専任IT担当者」を提供するサービスです。ベンダーやメーカーとしてではなく、貴社の社内IT担当者(情シス・社内SE)というスタンスでIT環境の現状を把握し、IT関連業務を包括してサポートしてくれるサービスとのことです。

システム障害への根本原因への対応も、自社に寄り添って支援してくれる期待がもてます。

システム障害の予防策を検討するなら、ITボランチに相談

今回は、システム障害についてご紹介しました。

自社で提供しているサービスのシステム障害が発生してしまうと、業務がストップしてしまい、自社の売上への影響を含めて甚大な損害をもたらしてしまう事態になります。KDDIの大規模障害の事例のように利用者への賠償金の支払いだけではなく、その後の風評による損賠は、その何十倍にもなってしまいます。

システム障害には、ハードウエア障害・ソフトウエア障害・人的ミスの3つが考えられますが、それらのリスクを想定し、予防策を施しておく必要があります。自社にはそうしたシステムの問題管理、変更管理に精通したスタッフがいないこともあるでしょう。

もし、社内に専門的な知識をもった担当者を設置できない、専任の担当者を置くほど業務量がないとお考えの場合は、アウトソーシングサービスを活用するのも有効な方法です。

ITボランチのIT保守アウトソーシングサービスでは、社内IT担当者(情シス・社内SE)というスタンスで、貴社のシステム環境を把握し、IT関連業務を包括してサポート致します。システムベンダや製品メーカとしてではなく、社内の専任IT担当者として専門知識を持ったSEが業務を担当しますので、システム障害の際にも迅速で適切な対応が可能となります。

貴社のシステムの安定的な運用のためにも、ぜひITボランチのIT保守アウトソーシングサービスをご検討ください。

ITボランチのIT保守サービスの詳細はこちらから

  • このエントリーをはてなブックマークに追加

SNSでもご購読できます。