システム障害対応は業者に丸投げせずに主体的に関わろう【2024年最新版】

普段システムを運用しているときには考えてもみないシステム障害ですが、いざ起きてしまった場合に企業のシステム担当者、web担当者の方はどのような行動を取るべきでしょうか。
備えあれば憂いなし、というのはまさにシステム障害について当てはまる言葉で、逆に言えばまったく備えがない状態で普段何も意識せずにシステムを運用しているという状況は、実はとても危険で恐ろしいことです。

システム障害は一般に、「ハードウェア障害」「ソフトウェア障害」「人為的ミスに起因する障害」の３つに分類できます。

「ハードウェア障害」は簡単に言うとハードウェア機器の「故障」です。
例えば、突然サーバーPCが故障して動かなくなった、停電や過電流、処理過負荷などによる機能停止、あるいは機能停止まで行かなくても原因不明の応答時間の大幅な遅れ、などがあります。

「ソフトウェア障害」は、正常だったデータが壊れている、ボタンを押してもアクションが起きない、使いたい機能が作動しないなどの機能的な不具合がよくあります。
機能的に不具合はないものの、画面が乱れる、表示がずれるなどの障害、セキュリティ攻撃などによるソフトウェアの停止や誤作動などもあります。

「人為的ミスに起因する障害」については、過失による誤操作や、その誤動作によるデータの破壊などがあります。

この３つのなかで、単純に機械を交換してもらえば済むというのは「故障」に対応してもらう一番目の「ハードウェア障害」のみです。
「ソフトウェア障害」「人為的ミスに起因する障害」については、セキュリティ対策を強化したり、人為的ミスが起こらないような運用方法に改めたりするなど、現在システムを稼働させている企業側での何らかの積極的な改善が不可欠になります。

また、ハードウェアの故障に関しても、故障が起きる前にその予兆（冷却ファンが止まっていて加熱していたなど）について事前にチェックする体制が社内にあれば、障害が起きなかった可能性もありますので、やはりすべての障害対応において、企業側が積極的にシステムの現状を把握して対策を取っておくという態度がとても重要になってきます。

障害をいち早く検知したら、もちろんその障害を取り除いて業務が正常に行われるように原状復帰することが大切です。
しかし、原状復帰さえすればよいというものではなく、障害が起きた原因やその後の対応などについてシステマティックに取り組むことが必要です。
障害が起きたときは往々にして、自分の知っている知識内でいきなりあれこれシステムをいじってしまうもので、そうしたときに偶然障害が治まったりすることもあります。

しかしこれでは、またいつ障害が起きるか分かりませんし、その障害に対してシステマティックに対処していなかったことによりもっと規模の大きく被害も甚大な二次災害を引き起こしてしまうケースもあります。

障害対応時の基本的な手順を押さえておくことで、場当たり的でないシステマティックな対処が可能になります。

障害が起きるときには、多くの場合何らかの前兆があります。
例えば「ハードウェア障害」であれば先程例に挙げた、ハードウェアのファンが回っておらず熱に弱いパソコンのサーバーが加熱して機能が停止してしまったというようなことです。

「ソフトウェア障害」では、ソフトウェア自体が立ち上がらなくなるという最悪のケースに至る前に、データの整合性が取れない、１つの処理に異様に時間がかかるなどの不具合の前兆があります。

「人為的ミスに起因する障害」では一般的な前兆というのはなかなか見つけにくいですが、ミスをきちんと記録し、ミスが起きたという事実とミスが起きにくいオペレーション改善案などについてきちんと部内で共有することなどが有効です。
例えば、月末近くになると必ず起きるミスや、受注したデータを物流会社に手配するときに起きやすいミスなど、会社ごとに「ミスのクセ」のようなものがありますので、「月末が来た」「物流会社に手配」などを広い意味で「予兆」と考えればよいでしょう。

障害を処理するためには以下の3つの基本方針を守ることが重要です。

障害が起きてしまった現場では、とにかく２の「障害の復旧」だけに目をとらわれてしまい、１の「障害の状態把握」がおろそかになりがちです。
過去にそっくりの障害が起きていて、そのときのノウハウを使えば数分で直るという場合も、状況把握ができていない場合にはまたゼロから対処しなければなりません。
また、再発防止策を取っておくことで二次災害を防ぐことが可能です。

先程解説した障害の３分類「ハードウェア障害」「ソフトウェア障害」「人為的ミスに起因する障害」のうち、今回の障害がどれに相当するのかをまず突き止めます。
もちろん「ハードウェア障害」と「ソフトウェア障害」が密接に絡んでいたり、「人為的ミスに起因する障害」が本来正常に動いていた「ソフトウェア障害」を引き起こしていたりするというケースもあります。

単純に障害の原因が特定できなくても慌てずに、まずは現状の状態把握をして「ハードウェア障害」「ソフトウェア障害」「人為的ミスに起因する障害」のどこに大きな問題があるのかを特定することが大切です。

故障箇所を特定する際に重要なことは、原因の切り分けを丁寧に行うことです。
具体的には不具合が起きるための再現手順として、「設定や動作を順番に辛抱強く１つずつ変える」ということが基本になります。
例えば会社から外へインターネット通信ができるのに、外から会社のwebサーバーが参照できないという場合に、「ハードウェア障害」を疑ってハブやスイッチなどの機器を別のものに交換してみるということをします。
そのときには決して、webサーバーを再起動させるような「ソフトウェア障害」を疑う行動を取ってはいけません。

「ハードウェア障害」「ソフトウェア障害」「人為的ミスに起因する障害」それぞれに対して、適切な措置を取ります。
ルーターなどハードウェアの故障であるとの疑いが強い場合には、ハードウェアメーカーのサポートセンターへ連絡を取ります。
webサーバーに問題ありという場合には、webシステムを構築してくれたシステム開発会社へ連絡を取ります。
社内でのwebサーバーへのアクセス操作に問題があるという場合には、同様のアクセス方法を取っている部署に改善方法を指示します。

上記の「外から自社のwebサーバーにつながらない」という例の場合、ハードウェアメーカー、システム構築会社、社内関係各部署から報告を受けます。
当たり前のことですが、オンサイトで障害対応してもらったのならば、関係各社が社内にいる間に障害が直ったことを確認します。
また、リモートで修復してもらった場合も、直ちに確認してなお不具合が存在していないかどうかチェックします。
これらの確認作業は１人ではなく複数で行うのが原則です。

障害の経緯と回復の現況、将来的な見通し（安全度）などについて関係者に通知します。

ここまでで、「2. 障害の復旧（原状回復）」までが終わりました。
IT部門の担当者以外はここまでで通常業務に復帰ですが、IT部門の担当者は引き続き「3. 原因の究明（再発防止）」に移ります。

障害が直ったらめでたしめでたし、という態度で終わらせないためには専門家に現状のシステムを診断してもらうことをお勧めします。
人間の体で言えば、手足のしびれがあってマッサージしたらなんとなく直ったというのは、対症療法に過ぎません。
何度もそうしたことがあるので病院にいったところ、恐ろしいことに脳梗塞を起こしていたと専門家に診断されるかもしれません。

同様にシステムにさらに問題が潜んでいないかどうかを調べるには、原状復帰をしてもらった業者に調査を頼むのがよいでしょう。

専門家の現状システム診断の結果も踏まえながら、今回の障害のレポートをまとめます。
内容は、障害に至った経緯と復旧作業で行ったこと、さらに専門家の現状のシステム診断を加えたもので構成し、最後に再発防止策を課題として書き込みます。

このドキュメントは関係者であれば誰でも閲覧できるような状態にしてナレッジを共有化します。
次回から障害が起きたときに過去の障害対策を参照することで、効率の良い対応ができるようになります。

以上が、
1. 障害の状態把握（5W1H）
2. 障害の復旧（原状回復）
3. 原因の究明（再発防止）
に則ったシステマティックな障害への対処法です。
場当たり的にならずにぜひこうした態度で障害を克服してください。

ここまで、障害に主体的に対応する基本的な流れについて説明してきました。
こうした流れを制度化してどのようなときでも実施できるようにするためにはノウハウを属人化せずに、チームで共有化することが大切です。

チームでナレッジを共有化するメリットは、障害が起きたときに複数で対応することで解決の糸口が広がるということがあります。
過去に社内で起きた障害を一緒に経験している人数が多ければ多いほど、複数人の目で多角的な視点で障害を分析できるようになります。

こうしたナレッジを共有できるためのチームを作るには、通常の業務を遂行するプロジェクトチームとは違ったコツが必要です。
その理由は通常のプロジェクトチームが、顧客キャンペーンや商品開発などポジティブタスクをこなす組織であるのに対して、障害対応のチームは現在のマイナス状況を回復するというネガティブな対象を扱うからです。

障害対応チームにおいては、「誰がこんなことやらかしたのだ？」という犯人探しや、「忙しいときに勘弁してくれ」という愚痴、「早く直してくれないと業務に支障が出る」などのIT責任者へのクレームなどが出てくるのが普通です。
こうなってしまっては、ナレッジの共有どころか、システマティックに障害対応にあたるということも忘れ去られて、チームのメンバーが好き勝手に不具合を直そうと手を動かし始めるといった状態が生じがちです。

こうした状況を回避するためには、チームのなかで役割分担を明確化することです。
例えば手の空いている人や、生じた障害にたまたま過去に対処したことがある人が対応にあたるということではなく、経験とスキルによって役割分担を大きく２階層に分けます。

当然ことながら、365日ノンストップで１人の人間がシステム全体の障害に備えるわけにはいきません。
そこで障害対応の初期段階の任にあたるサブチームを作り、さらに対応をエスカレーションする必要が出てきた場合により高度な対応の役割を担うサブチームを作ることがお勧めです。

IT部門の人員のスキルと経験を考慮して、初期段階の任にあたるサブチームでは入社数年レベルの社員から新人までをあて、より高度な対応の役割を担うサブチームには経験を積んだ人員が所属します。

初期段階の任にあたるサブチームではツールなども使いながらシステムの状況に気を配り、監視ツールなどから通知される障害のアラートを迅速に確認して障害の内容の把握に努めます。
さらに、社員からの障害報告の受付窓口も兼務し、何かあった場合には障害の状態把握（5W1H）を行います。

この時点で対応が可能であれば障害からシステムを復旧させて、事後報告をより高度な対応の役割を担うサブチームに行い、報告書を作ってナレッジの共有を行います。
自分たちのサブチームでは障害に対応できそうもない、と判断したときには高度な対応の役割を担うサブチームにエスカレーションして、問題解決を引き継ぎます。
問題を引き継いだ上位チームは障害の現状を再確認し、自分たちで対処できない場合には外部の適切な連絡先に連絡をするなどして原状復帰を目指します。

こうした役割分担をしておくことで、障害対応のナレッジの属人化を防ぐことができ、障害が起きたときにIT部門の人員自らが率先して主体的に関わるチームづくりができ上がってきます。

こうして、組織でナレッジを共有するための基礎づくりができ上がりました。
障害対応の最終段階として最後に具体的にナレッジを共有する手順をお伝えします。
それは個々の障害のナレッジの一般化、すなわち「障害対応マニュアルづくり」です。

マニュアルでは基本方針を明らかにするために、下記のような項目を明らかにして冒頭に記載します。

次にチームごとに、それぞれの役割を果たすために必要な手順を明文化します。
初動チームと上位チームとでは内容が異なってくるので、それぞれのチームで分冊の形で『障害対応マニュアル　初動チーム編』、『障害対応マニュアル　上位グループ編』としてまとめてもよいでしょう。

次に、個別の障害対処に関する部分の明文化ですが、障害は似ているように見えても細かくチェックするとその内容は個々に違った広がりを持ち、一見すると「ハードウェア障害」に見える項目でも「ソフトウェア障害」が絡んでいたり、「ハードウェア障害」と「ソフトウェア障害」と「人為的ミスに起因する障害」がすべて重なっていたりする場合もあります。

こうした現象面にとらわれていると、個別の障害記録になってしまい、マニュアルとしてケースを一般化することができません。
マニュアル化のコツは障害の現象面にとらわれることなく、あらかじめ設定してある初動チームの「監視項目」ごとにまとめるのがベストです。

例えば、webサーバーの稼働についての監視中にエラーが起きた場合には、「webサーバーの障害」という項目に「サーバーアクセス不能」などの障害を分類し、「プリンター」の監視中にエラーが起きた場合には「プリンターサーバードライバ無反応」などと記載します。

監視側が見つけた障害だけでなく、社員から上がってきた障害報告に関しても、上記の分類のなかに適切な場所を見つけます。
例えば、「webサーバーが見られないようだ」という場合には「サーバーアクセス不能」になりますし、「プリンターが使えない」という苦情も、「プリンターサーバードライバ無反応」などに分類できます。
事前と事後の報告の違いはあるものの、項目的には同一の箇所にまとめましょう。

最初は１冊のなかに分類を徹底して記載していきますが、分量が増えてきたら項目ごとに分冊して背表紙を付けていってもよいでしょう。

こうしてマニュアルを徐々に整備していきますが、精度を上げるためにはマニュアルを閲覧した人からのフィードバックをもらってそれを積極的に反映していく努力を継続しましょう。

マニュアルづくりに関わったチームのメンバー以外がマニュアルを読むことによって、分かりにくい状況説明や、不用意な専門用語、不明確な判断、具体性の欠けたオペレーションなどが明らかになります。
よりよいマニュアルづくりのために、こうした指摘はオープンに受け止め取り入れていきましょう。
最初から完璧なマニュアルなどはありません。
マニュアルが単なる障害報告書の寄せ集めにならないために、日々マニュアルを改定する努力を続けて、チームのナレッジ共有を確かなものにしていってください。

以上、システム障害対応を業者に丸投げせずに主体的に関わるための、障害対応のシステマティックな方法、チームづくりのコツ、障害対応にチームであたるためのマニュアルづくりについてお伝えしました。

障害が起きるたびに、パソコンに保存してある外部業者の電話番号を引っ張り出して電話をかけるということを繰り返しているのでは、万が一の障害対応の原状復帰を最短時間にすることも障害の起こりにくいシステムを作ってくことは期待できません。
障害対応に強いIT部門の組織文化は、この記事で説明したようなオペレーションを粛々とこなしていくことから生まれます。
そして、こうしたチームを作り上げるには、社内に強力なリーダーシップを持った経験と実績のあるキーマンも必要です。

人的な制約や費用的な面でどうしても、こうしたチームを作ることが困難な場合もあると思います。
障害検出ツールなどを使って、リモートで最低限の障害検出など部分的に請け負ってくれる業者もいますが、社内システムのすべてにわたって責任を持ってもらうためには、常駐の形で障害対応チームを派遣してもらうことなどが必要です。
ただし、費用が高額になるだけでなく基本的に社内に障害対応のノウハウは残りません。

このような場合システムの保守・運用についてコンサルティングを実施しながら、必要なマニュアルづくりまで指導してくれるパートナーがいれば、システム障害対応に強いチームづくりを正しい方向に向けて加速できます。
こうしたコンサルティングサービスについて最後にお伝えします。

BCP（事業継続計画）とは、企業が自然災害、大火災、テロ攻撃などの緊急事態に遭遇した場合に、中核となる事業の継続あるいは早期復旧を可能とするには何をしたらよいかを明らかにした計画書です。

BCPはシステムの障害よりももっと大きな災害を想定していますが、緊急時にも事業継続ができるようになるために、平常時に行うべき活動や緊急時における事業継続のための方法、手段などを取り決めておく計画のことで、ITの障害対応も含まれます。

東日本大震災以降、事業継続計画（BCP）への関心が高まり、中小企業でも何らかの対策を取る会社が増え、コンサルティングサービスを行う会社も増えました。

事業継続計画（BCP）のなかでも特にITに関する障害対応では、「インシデント」という言葉がキーワードになります。
インシデントという言葉の元々の意味は、「アクシデント」と似たような意味を持っていますが、事業継続計画（BCP）のIT障害対応の分野においては、 「オペレーションの中断が起こってしまった状態、業務を支える重要なプロセスの中断が起こってしまった状態」を指します。
また、現実に中断が起きなかったとしても中断を引き起こしそうな状態も「インシデント」に含まれます。

このインシデント管理プロセスには、大きく分けて６つの活動がありますが、これは、この記事で解説してきた「障害対応のシステマティックな方法、チームづくりのコツ、障害対応にチームであたるためのマニュアルづくり」に相当するものです。

なお、システム障害におけるインシデント管理の具体的方法については、おなじアイミツまとめ記事のこちらの記事などもぜひ参照してください。

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

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

システム障害に向けた組織づくりを進めることの重要性に対する認識は、東日本大震災以降中小企業にも急速に広まっています。
ただし、この記事でさまざまな形で指摘してきたように、主体的に自らの事業の継続性を確保するという態度が不可欠です。

システム的な障害に対処してもらうだけならば、システム保守代行サービスやシステム運用代行サービスがたくさんあります。
しかし、事業継続計画（BCP）レベルで真剣に障害対応を考えた場合、代行サービスに頼るだけでなく、主体的に障害対応のルールづくりと制度化を進めていくべきでしょう。
本来、事業の継続体制は代行業者に保証してもらうものではなく、事業主体が自ら確立していくことが基本です。

「アイミツ」にご相談いただければ、単なる保守代行サービスを超えた障害に強い組織づくり、BCPレベルの計画書作成のお手伝いをしてくれるコンサルティングパートナーをご紹介できます。
ぜひお声がけいただければと思います。