最強SEのシステムトラブル対応～対応の流れ編～

システムトラブル対応は適切な順序で行うことが重要

トラブルを起こさないITシステムは少ない。これまで順調に稼動していたシステムが、ある日、突然システムトラブルを起こす場合も往々にして存在する。

そうした場合に、適切な順序で対応を行うことはシステムを含めたサービス全体の品質にとって非常に重要である。なぜなら、顧客は「システムが動いていること」を求めているのではなく、「システムを利用して業務を行うこと」を求めているからだ。

システムトラブル対応おいて最も重要なことは、顧客の業務（ユーザの利用）を継続させることである。本稿では、顧客の業務継続のためには、システムトラブルが発生した際にどういった順序で対応を行うべきなのか、ということについて考えてみたい。

システムトラブル対応の流れ

システムトラブル対応は、大きく以下の流れで行う。

それぞれの段階で、最優先される事項は異なる。当然、適切な動き方も段階により違ってくるので、今の段階で何を優先すべきかということを常に意識しながら、適切な行動を取れるようにしよう。

本稿では、上記の５つの段階のうち特に、システムトラブル対応における初期の対応となる１～３の段階における動き方をみていきたい。

また、動き方は各々の役割によっても大きく違ってくる。本稿では特に、「統括担当」者と「作業担当」者の動き方について考えてみたい。それぞれの役割については以下の記事を参考にして欲しい。

１．事象の確認

システムトラブルの状況を確認する段階。この段階においては事実を正しく、適切な範囲に連絡することが最も大切である。

＜必要な動きと役割分担＞

・関係者への報告　：　統括担当

システムトラブルによって影響を受ける可能性のある関係者への報告を行う。

・システムトラブル対応チームの編成　：　統括担当

システムトラブルの発生箇所に応じて、適切な作業担当を召集し、調査にあたらせる。また、影響範囲が大きくなることが予想される場合は統括本部を立ち上げ、関係者を招集する。

・発生している事象の確認　：　作業担当 , 統括担当 , 営業担当

システムトラブルが発生したことを検知し、統括担当に連絡を行う。システムトラブルの検知は当該システムの担当者である作業担当もしくは統括担当が行えるとベストだが、事象によっては顧客が第一発見者となる場合がある。そういった場合は、営業担当が統括担当に連絡を行おう。

＜ポイント＞

・簡潔に報告する

まずはシステムトラブルの発生を周知することが優先であるため、内容は簡潔に、迅速に報告しよう。

・事実を正しくおさえる

この段階では推測の情報は必要最低限にとどめ、事実として何が起こっているかを正しく連絡しよう。例えば、対象のログ名、画面名、処理名、サーバ名などの名称を伝える場合は正式名称で連絡をおこない、認識相違の発生を避けることがポイントだ。

・時系列をおさえる

発生した事象は、必ず時刻と合わせて連絡しよう。事象の前後関係が関係者に正しく伝わることで、次の動きに移りやすくなる。ログに出力された内容だけでなく、顧客から問い合わせを受け付けた時刻など、事象は時刻とセットで確認するようにしよう。

・何が想定と異なっているのかをおさえる

システムトラブルが発生している状況では、想定している結果と実際の結果が異なっているはずである。この段階では想定結果と実際の結果を正しく確認することが重要だ。場合によっては、想定結果のほうが誤っている（仕様の誤解）ということも有り得るからだ。

・情報源かをおさえる

事象が内部で検知したものなのか、顧客からの問い合わせで検知したものなのかを正しく記録しよう。誰がどういった情報を持っているかということを確認することで次の動きに移りやすくなる。

・不明点はその旨を明確に連絡する

この段階では不明な点が多々あるはずなので、そういった点は曖昧にせず、調査中である旨を連絡しよう。

２．影響範囲の特定/原因調査

システムトラブルの影響範囲を特定し、原因を発見する段階。この段階においてはシステムトラブルにより、顧客にどういった影響があるのかを特定することが最も大切である。

＜必要な動きと役割分担＞

・影響調査　：　作業担当

システムトラブルの影響範囲を特定し、潜在的なリスクを統括担当に連絡する。

・関係者への報告　：　統括担当

調査状況を随時関係者に連絡する。

・暫定対策の方針を検討　：　統括担当

調査によりわかった情報をもとに暫定対応として考えられる方法を検討する。

＜ポイント＞

・業務的な時限を意識する

この段階ではシステムトラブルにより影響を受けた顧客の業務がいつまでに完了しなければならないのか、ということを意識しつつ対応を進めよう。特に、統括担当は暫定対応の方針を定める際にはシステム的な対応が難しければ顧客に代替オペレーションを依頼するなどの方針を早急に定める必要がある。

・仮説検証を繰り返して原因を追究する

この段階では、障害の原因として想定される仮説をたて、それを検証するというプロセスを繰り返すことが必要だ。ここでも事実と仮説の混同が起きないように注意しよう。

３．暫定対策の実施

顧客の業務を継続させるための具体的な対応を行う段階。この段階においては顧客のサポートを行い、時限どおりに業務が完了することが最も大切である。

＜必要な動きと役割分担＞

・関係者への報告　：　統括担当

対応状況を随時関係者に連絡する。

・対応指示　：　統括担当

作業担当者に対して対応を指示する。顧客側で特別なオペレーションが必要な場合には、営業担当にも指示を行う。

・対応実施　：　作業担当

システム側で必要な復旧作業を実行する。

・対応結果の確認　：　営業担当

暫定対策の完了を顧客に連絡し、顧客側で正常に業務を継続できたことを確認する。

＜ポイント＞

・対策の着手時点で見込み時間を連絡する

顧客にとって、いつから業務を再開できるのかということが最も重要である。そのため、暫定対策の開始時点で、対応にどれくらいの時間がかかる見込みなのかということを顧客に連絡しておくことが顧客の不安を増大させないために必要だ。

・二次災害の可能性を考慮する

システムトラブルの対応時に二次災害を引き起こすことは絶対に避けなければならない事態である。そのため、暫定対策の内容が二次災害を起こしえないか、という観点でチェックすることが大切だ。過去に同じ方法で対応したことがある、モジュールをいリリース前の状態に安全に戻すなど、暫定対策には二次災害の可能性の低い方法を選択することが重要だ。

・手順書を準備する

二次災害を抑えるための方法の一つでもあるが、対応の実行時にコマンドのミスなどが発生しないよう、面倒でも手順書を作成し、関係者でチェックした上で実行しよう。また、実行時には何を行ったのかということを、きちんと作業ログに残しておくようにしよう。

まとめ

本稿では、システムトラブルが発生した場合の初動として、どういった順序で、何を行うべきか、について考えた。対応の段階ごとに、限られた時間の中で何を優先して実施すべきかということはシステムトラブルが発生する前に確認しておいて欲しい。

暫定対策の実施を行い、顧客の業務がひとまず継続できた段階から本質的な原因を追究し、再発防止策を含む本格対策の実施に移ることになる。これについては、初動とは別の体制、観点での対応が必要となるため、別の機会に考えたい。

システムトラブルの撲滅に、本稿の内容が参考になれば幸いである。