障害対応フローを明確化するために必要なこととは何か【2024年最新版】

障害対応は単なる原状復帰だけを意味するものではありません。
もし障害対応が原状復帰だけを目的とするならば、状況に合わせて「とにかく動くように頑張る」という場当たり的な行動となってしまうでしょう。
そのような対応では、ハード機器のスイッチを入れ直したり、OSを再起動したりしているなかで、気が付かないうちに直っていたという場合もあるでしょうが、これではまたいつ同じような障害が起きるか分かりません。

本当の意味での障害対応とは、あらかじめ決められたフローに従って行います。
一般的な障害対策フローはもちろんありますが、自社にとって本当に役立つ障害対応のフローの中身を決定するには、現在どんなインフラやシステム、アプリケーションを導入しているか、またどんな業務を優先して障害を回復させるべきかなどの、現状把握や価値判断が必要です。

また、自社にとって有効な障害対応フローを明確化するには、「障害部分の原状回復ができたらそれでいい」という態度ではなく、障害対応を「運用管理業務」の一環としてとらえることが大切になってきます。

この記事では単なる障害原状回復テクニックとしての「障害対応」でなく、運用管理業務の一環としての「障害対応」とは何かを明らかにすることで、自社にとって最適な障害対応フローを確立するためのヒントをご提供します。

最初に障害対応の基本となる作業フローを紹介しておきましょう。

しかし、この障害対応フローはあくまでも一般的な流れを示したものに過ぎません。

例えば、社内のネットワーク全体がつながらなくなってしまった場合、当然のことながら多数の業務が同時にストップします。
そのときに、「何はともあれ、電子メールが送受信できるようにする」ということを優先するのか、それとも「発注業務に不可欠な帳票を出力するためにプリンターが使えるようにする」ことを優先するのかなど、会社によって復旧すべき優先順位は変わってきます。

優先順位が変わってくれば、対応フローはここで示したものと同じでも、その中身は企業ごとに異なってきます。

また、会社が一般家庭用の光回線をベースにした最小限のネットワーク構成を取っているのか、それとも本支店間をセキュアなVPNで結ぶようなセキュリティを重視したインフラを敷いているかなどによって、取るべき対応は初動からまったく違ってきます。

つまり、「障害対応」とは、自社のシステムの障害に対して適切な対応をすることなのです。
そのためには、障害対応を突発的なものではなく、「運用管理業務」の一環として考える必要があります。

狭い意味での「障害対応」とは、２の「障害時運用」だけを指しますが、この障害時運用を効果的に行うためには、通常時運用でサービスの開始終了などの運用、監視、統計情報収集をきちんと行い、保守・メンテナンス業務において業務継続計画立案、定期的なメンテナンス、計画的に行われるシステムの拡張などを実施し続けることが大切です。

また原状復帰というレベルで障害対応が完了したあと、障害発生の教訓をどう活かすかについては、自社がどんな障害対応ポリシーを大切にしているかによって中身が変わってきます。

次にこの「運用管理業務」の詳細を詰めるために必要な項目を検討していきます。

最初に必要なのは、障害対応すべき対象の資産価値をイメージすることです。
一般的にシステム管理コストは、対応すべき対象がどのような価値を持つかでランク付けされます。

もっとも、どのようなシステムでも止まってしまったりデータが毀損されてしまったりしては困るわけなので、平常時の状態から資産価値を判断することはイメージにしくいのも事実です。
システム管理コスト意識を導入するためには、「仮に障害を受けたときにどれくらいの損失を被るか」という視点で資産価値を計ることをおすすめします。

例えば、「プリンターに障害が起きて日常業務が半日止まってしまい、重要な商談用のプレゼン資料が間に合わなかった」というケースも機会ロスという点からは大きな損失ですが、「データベースサーバーに不具合があり、顧客データベースのデータの大部分が消失してしまった」ということに比べると具体的に金額に換算できる損失には差があることが分かります。

このように資産価値によってシステムが実現する機能をランク付けすることで、プリンターのメンテナンスや最新プリンターへの乗り換えなどプリンターが提供するサービスに対する総コストをどれくらいかけるべきか、データベースサーバーのバックアップ体制の強化と復旧のためのシステム構築や保守・運用体制の強化にどれくらいコストを増額すべきか、などの価値判断が可能になってきます。

このように「費用対効果」からシステム資産に対してどれくらいのコストをかけるかを判断することが重要なのですが、多くのシステム管理者は自社のシステムがどれくらいの価値を持っているのかを正確に把握していません。
「システムに優劣はない、どのシステムも止まらないようにするのが基本」というのは正論ではありますが、限られた人的リソースや予算を適切に配分するためには、この正論はあまりに役に立ちません。

また、具体的にそのシステムが止まった場合の損失から逆算して資産価値を客観的に評価しているシステム管理者もそれほど多くありません。
多くのシステム管理者のシステムに対する資産価値の認識は、「このシステムは止まると大変」「このシステムは絶対に止めてはいけない」などのレベルにとどまっており、実際の障害に遭遇した場合にどこまで対処していいのか正しく判断できずに損失を最小限に食い止められないことがあります。

では、システムの資産価値はどのようにして明らかにすべきかですが、これは「そのシステムが提供するサービスの目的」「サービスを利用するユーザー数と利用時間」「サービスが止まることによる想定される損失額」の３つを検討することで明らかになります。

システム管理担当のエンジニアは技術者なので、システム管理の現場では、そもそもそのシステムが何のために提供されているかという視点は持ちにくいという現実があります。
しかし、システムの目的を明確にすることで、そのシステムがダウンしている間に失われる利益も明確になります。

例えば、「24時間以内に必ず返答します」という苦情処理を目的としたCTIサービスに障害が出てしまった場合、手作業によって顧客対応をするための人員確保、残業コストなどは復旧するまでかかってきます。
また、それでも24時間という対応時間を過ぎてしまった場合には、企業の信用失墜という目に見えない大きな損失が避けられません。

このようにサービスごとの目的を把握するためには、そのサービスを実際に使っている部署の責任者などにヒアリングをすることが有効です。

止まってしまったサービスを１人しか使っていない場合と、常時本支店合わせて1,000人が利用しているという場合、利用ユーザー数のみで単純計算してもおよそ1,000倍の資産価値の開きが出てきます。

また同様に、１年間のうち夏の繁忙期２週間だけ集中的にサービスを提供するという場合と、年間を通じてサービスを途切れなく提供している場合でも、資産価値は変わってきます。

また、サービスが社内での利用者に限定されているか、それとも社外の取引先にも影響があるのか、さらにECサイトなどのように一般消費者も対象としているのか、それぞれのケースのユーザー数と利用時間によっても資産価値は大きく変わってきます。

例えば１日に100万円を売り上げているECサイトが３日間稼働できなかった場合には300万円分の機会損失が生じます。
社内システムなどではこうした単純な計算は難しいものの、例えば顧客データベースに１日アクセスできなかったことによる営業部での損失など、概算でサービスごとの不具合時の機会損失を計算することができます。

サービスが止まることによる想定される損失額を算出して比較検討すれば、想定される損失金額の大きい順にシステムが資産価値を持っているということが分かります。

システムの資産価値の洗い出しが済んだあとは、システムのリカバリーにどれくらいの費用がかけられるかを明らかにします。
これも、一般的なシステム管理者の方は苦手とする作業です。
システム管理者は「障害が起きたという非常事態をなんとしても復旧させなければならない」という強い意識を持っているのが普通です。
もちろんそうした責任感はシステム管理者に必須のものですが、かといって青天井に復旧のための予算を割いてよいということにはなりません。

例えば、プリンターの不具合があるたびにプリンターのサービスサポートセンターに電話をかけて、オンプレミスでの修理依頼をかけたとします。
確かにプリンターは復旧しますが、このときにかかる「出張費」「技術料」、場合によっては「部品交換費用」などを本当にいくらかけてもかまわないと判断してよいのでしょうか。

「障害対応」の現場では原状復帰が原則であるにせよ、「運用管理業務」の観点からは、運用管理業務全体の予算を超えた「障害対応」はNGです。

「このシステムが止まると大変なことになる」という場合、それに応じた予算を「運用管理業務」の観点からあらかじめ割いておくべきであり、その上限を超える部分に関しては障害対応の現場でそれ以上のことをするかどうか判断してはいけません。
えてして現場ではこうした緊急時の対応にブレが出てしまいがちですが、生み出す利益を超える管理コストが必要になるシステムを維持することはむしろ問題です。

個別のサービスにつき、このサービスはいくら利益を生むので（ストップするといくらの損失があるので）障害対応にはこれだけのコストをかけるのが相当である、という判断をしていくことが大切です。

ここまで、システム管理者の方が陥りがちな「障害対応」だけに目をとらわれてしまう考え方の欠点を指摘してきました。
次に、費用対効果をイメージした適切な障害対策フローの決定の方法を解説します。

運用管理業務の総コストを抑えるために最初に行うことは、システム構築の段階で自動化できる部分に予算を割くことです。
システムを導入したあとには必ず保守メンテナンス作業が必要になりますので、導入後のランニングコストを抑えるためには予算の許す範囲でその後の保守メンテナンス作業に、会社内部のスタッフの人件費やアウトソーシング費用などがかからないような工夫をすることが肝心です。

その後の保守メンテナンス作業についての具体的な費用決定にあたっては、「この金額までなら出せる」「この作業は最低限必要」という部分をすり合わせることが必要です。

「この金額までなら出せる」というスタンスからは、前年度の実績や業界のアウトソーシング費用などの相場を参考に、大まかな分野ごとに予算を割り振っていきます。

「この作業は最低限必要」というスタンスからは、障害対策ポリシー項目ごとに必要なコストを積み上げていきます。

そして最終的に予算の上限と必要な機能を突き合わせてすり合わせをし、「運用管理業務」の総コストを決定します。
くれぐれも「障害対応」だけにとらわれて予算を決定しないようにしましょう。
「障害が起きたという非常事態をなんとしても復旧させなければならない」「システムに優劣はない、どのシステムも止まらないようにするのが基本」という態度からは、適切な予算は見えてこないので注意してください。

「運用管理業務」のなかで「障害対応」を行うためには目標の設定が必要です。
障害対応だけに目をとらわれてしまうと、「目標イコール現状復帰」になってしまいますので注意しましょう。

具体的な目標指標としては、障害時運用においては、MTBF（Mean Time Between Failure：平均故障間隔）やMTTR（Mean Time To Repair：平均修復時間）といった項目がよく使われます。

こうした、障害対策時の直接的な目標指標だけでなく、以下のような性能に関する指標についても、通常時運用でしっかりと把握して、最初に決めた目標値を下回ったときにはその原因を明らかにしておくことが大切です。

運用を行っていくのに必要な施設などがあれば、その要件を決めておきます。
また、施設内で使用する設備、および備品なども検討の対象となります。

一般的なシステム運用管理であれば、施設というとコンピューターセンターなどがこれにあたるわけですが、ネットワークの運用管理の場合、ネットワークという基本的には機器間をケーブルで結んだものが対象ですので、あまり明確に「施設」と呼べるものはないかと思います。
ただしネットワークを構成するケーブルや機器類（ルータやスイッチなど）をネットワーク「設備」と考えれば、かなり広範囲にさまざまな事柄について決めていく必要があります。

例えばケーブルについて、メタルでよいのか、それとも将来的な拡張性を見込んでファイバーにするのか。
またケーブルの材質について、壁内や床下をはわせるにあたって、消防法などの見地から、特定の材質でなければいけない場合もあります。
さらに床下配線をする場合のフリーアクセスの利用の有無、床や壁面へのLANポートの設置などを検討します。
最近ではケーブルを床下に這わせるよりも、工事やメンテナンスの手間が省けるということで、無線LANを利用するケースが増えていますが、その場合のアンテナ設備などの検討も別途必要となります。

　それから、そもそもの「設備」範囲として、電源についての検討が必要になります。
当初の電源容量や以降の拡張性、バックアップ用の電源の有無、さらにLANポートと同様に、床や壁面への設置の要否なども検討します。

　このように設備面での検討は、場合によって費用にかなり大きく跳ね返るような工事を必要とする事柄が多くありますので注意が必要です。

先程プリンターの不具合があるたびにプリンターのサービスサポートセンターに電話をかけてしまうという例を取り上げましたが、例えばプリンターの障害対応は部品交換などに至らないケースでは自社内で完結させる、しかしデータベースの不具合については、社内では手を出さずどんなケースでも保守契約している会社に任せるなどの役割分担を明確にすることが大切です。

もちろん、社内に技術スタッフがいてどのような障害であっても、まず対応できるところまでは対応してからアウトソーシング先に連絡を取るということでもかませいません。
その場合にも「この作業までは自社、そこから先は深追いせずにアウトソーシング先に連絡する」などの明確なポリシーが必要です。

これも、システム管理者の意識としては24時間365日フル稼働を前提としてしまいますが、すべてのシステムが24時間365日フル稼働していなければならない、というわけではありません。
例えば、オフィス内の業務に必要なシステムは営業時間内、24時間アクセスを想定しているECサービスは24時間対応など、システムが提供するサービスによって運用管理を行う時間帯にはずれがあります。

こうした運用管理時間帯を洗い出すことによって、業務時間内は自社で運用管理をして障害対応も行い、夜間にも管理が必要なサービスはアウトソーシングを検討するなどの適切な業務分担が可能になり、運用コストも抑えることが可能になります。

運用管理時間帯と似ていますが、運用管理の対象となるシステムを常にリアルタイムでの監視が必要な部分と、そうでない部分に分けましょう。
同じリアルタイム監視でも有人による監視が必要なのか、機械監視でもよいのかによっても運用管理の方法とコストも変わってきます。

また、リモートからの監視と対応で十分なのか、それともオンプレミスでの監視と作業が必要なのかを軸にサービスを区分し、自社管理とアウトソーシング先に任せるなどの役割分担の決定に役立てます。

アウトソーシング先に業務を委託すれば、専門業者としての知識と経験による質の高い管理が期待できますが、自主運営に比較した場合のコストや対応の柔軟性（時間外など）で課題もありますから、役割分担は慎重に決めるようにしましょう。

ここまでの検討作業で、自社に最適化された障害対応フローの前提となるシステム運用ポリシーが決定できました。
障害対応フローを明確化する最終段階として、ここまでの検討作業をドキュメントに落とし込みます。

具体的には冒頭に指摘した「通常時運用」「障害時運用」「保守・メンテナンス」という項目ごとに、スケジュールであるとか、実施方法、および実施体制などに関してこれまで検討した内容を書き出していきます。

最後に、システム開発を外注した際にかかる費用相場をご紹介します。

システム開発の費用相場をご紹介しました。より正確な費用を知りたい方は料金シミュレーターをご利用ください。

以上、障害対応フローが知らず知らずのうちに、コストを無視した「原状復帰」マニュアルになってしまわないための注意点と、「運用管理業務」の一部としての障害対応のあるべき姿を整理してきました。

こうした原則をきちんと押さえておくことにより、万が一の障害時に自社に最適化された障害対応フローが実践できますし、アウトソーシング先と適切に作業分担することで責任の明確化やコストダウンも図れます。

障害対応についてのアウトソーシング先を上手に活用すれば、社内の人材をより本業に直結する部署に配置転換して会社の競争力を高めたり、運用面での人件費を抑えて、障害に強いシステムに再投資したりすることが可能です。
そのほかにも専門知識や経験の豊富なエンジニアが保守・メンテナンス作業を実施してくれることにより、業務の効率化や確実性が見込めます。

また阪神淡路大震災などの教訓から必要性が再確認された、バックアップ体制やリカバリーなど障害が起きてしまったあとのBCP（事業継続計画）を整備するためにも、外部の専門家の知恵が必要な場面が増えてきています。

アウトソーシング先に実際の運用管理業務を委託することで日々稼働しているシステムの障害を最小限にとどめつつ、中核となる事業の継続あるいは早期復旧を可能とするBCPの作成をコンサルティングしてもらうということも可能です。

こうした総合的な運用管理業務を託すことができるアウトソーシング先を見つけたい、という場合にはぜひ「アイミツ」にお声をおかけください。
「アイミツ」にご相談いただければ、システムの現状把握、運用管理ポリシーの策定支援から理想の障害対応フローを明確化し、障害時に実際に必要となる作業も任せることのできる会社をご紹介できます。

大手システム開発会社５選も併せてご確認ください。