障害が起きたときこそ冷静・迅速に!着実に確認する手順とは?

システム運用のエンジニアであれば避けられないのが、障害対応です。しかし、何度経験しても冷静に対処することは難しいもの。まして、コロナ禍で急に配置転換された人や、経験が浅いエンジニアには、何をどういう優先順位で対応していいか、見当も付きません。人材不足の現場だと、教えてくれる先輩も限られますし、ひとり情シスだと言わずもがな。今回は、トラブルへ対処するポイントを説明します。

まずは発生した事象を整理しよう

障害発生を検知した場合、まずは落ち着いて現状を整理し、影響範囲と被疑箇所を特定しましょう。

例えば、顧客環境に設置されたサーバのデータを、VPN経由で自社環境に送付し解析するサービスを提供しているとします。そのデータが届かなくなってしまった場合、皆さんなら、何をチェックしますか?

顧客の環境だけで問題が発生している場合は、恐らく、影響はその1社で済むでしょう。しかし、自社に問題があってサービス全体に影響している場合は、範囲が大きくなります。まずは、問題が起きている環境が顧客か自社かを、早期に切り分けましょう。

意外と初歩的なミスが多い

調査の結果、顧客の環境が疑わしいことが分かったら、次のステップです。ネットワーク機器が故障している可能性もありますし、実は作業で機器の設定を変更しているのかもしれません。顧客環境でメンテナンスをしていて、連絡を忘れていただけということは、実はよくあります。

自社環境が原因の場合でも、初歩的なミスはあり得ます。突発的なメンテナンス作業が発生し、自分とは別のチームが十分な連絡なしに実施していて、不運にも作業ミスが発生して影響を受けてしまうようなことも、よくある話です。

どこまで通信が届いていて、どこで止まっているのか?基本を一つ一つ確認し、状況を関係者で共有しましょう。

〇 よくある障害のパターン

  •  メンテナンス作業をしていたが、事前連絡を忘れていた
  •  ファイヤーウォールなどのネットワーク機器で、設定ミスをしていた
  •  バージョンアップ作業後に、仕様が変わっていた
  •  サーバなどのケーブルが抜けてしまった・配線を間違えた
  •  経路のネットワーク機器(VPN機器、IDS/IPS、ロードバランサーなど)で不具合が発生した
  •  ネットワーク設計の不備で、スタンバイ機に切り替わらなかった

<PR>冷静でスムーズな対応には、マニュアル化とコミュニケーションが基本でも、なかなか上手くいかない…
そんな現場のストレスは、SaaS型統合運用管理サービス「UOM」でまとめて解決!詳しくはこちら

失敗例:調査に必死になり、報告が疎かになった

ここで、一つ失敗事例を紹介しましょう。

とある通信障害が発生し、担当者はエンジニアとして原因究明に集中しました。しかし、集中し過ぎるあまり、顧客や社内関係者への連絡が疎かになってしまいました。報告が不十分だったことで、不満に感じた顧客から状況説明を急かされ、しかも誤った内容を伝えてしまい、クレームとなってしまったのです。

障害が発生した場合、エンジニアは発生原因の究明と関係各所への説明を同時に求められますが、原因究明には長い時間掛かることも多いもの。かといって、全く説明しないと、適切な対応をしているのか疑われてしまいます。障害を調査する場合、真の原因が判明しなくても、何が正常に動作していて、どこが疑わしいかまでは、比較的すぐに判明することもあります。顧客に不信感を抱かれないためには、判明している事実を段階的に伝えることも重要です。

回避例:適切に状況説明していた

こちらは、前述とは逆で、失敗を回避できた事例です。

顧客環境に設置し、自社で保守していた機器で障害が発生して、通信ができなくなってしまいました。調査の結果、特定のネットワーク機器が原因だということまでは判明し、保守ベンダから交換の許可が下りました。しかし、回収した機器で同じ事象が再現するかどうかは不明で、原因究明が難しい状況でした。ここで担当者は、上長にエスカレーションし、顧客に十分な説明をした上で、何を優先すべきか判断してもらいました。

何気ないやり取りのようですが、原因の究明が困難になる可能性を伝えずに機器を交換すると、クレームになります。この事例では、原因究明よりも復旧を優先することになり、不具合の原因が判明しなかった点について、問題にはなりませんでした。

納得のいく報告までが、システム運用エンジニアの仕事です。すぐにトラブルを解消しても、報告のときに『今日、初めてその情報を聞いたが、当日教えてほしかった』といわれることもあります。目の前の事象の解決だけを考えるのではなく、適切な情報を提示しながら対応することで、後日の経緯報告もスムーズに処理できます。

どんなメンバーでも、判断に困らない工夫が必要

どのような情報を、どのタイミングで提示すべきか?経験の浅い運用エンジニアが判断することは難しいものです。顧客がメンテナンスの連絡を忘れていたような、軽微な事象までいちいち報告されると、上長が疲弊してしまいます。逆に、休日に起きたトラブルを把握できず、月曜朝に出社した上長が社内から突然経緯の説明を求められて、顔が青ざめるということも。どのような事象がどの段階になったら上長にエスカレーションすべきか、明確な基準を作っておきましょう。

どの現場も人材難なので、経験の浅いエンジニアが対応しなければならないことも増えていくはずです。どのようなメンバーでも判断に困らないように、フローを整理しておきましょう。

<PR>ミスを憎んで人を憎まず。人手不足の中、スキルが不十分なエンジニアを最大に活かすサービスを使いましょう!
システム運用を自動化できる、統合型サービス「UOM」を使えば精神的ゆとりも生まれます!詳しくはこちら

関連記事

∞∞∞∞∞∞∞ おすすめ記事 ∞∞∞∞∞∞

  1. 失敗や不十分な対策も次のヒントに – 情シス現場のホンネ2

    今回も引き続き、IIJが昨年秋に実施した、情報システム部門のエンジニアへのアンケートからご紹介します…
  2. 現場が疲弊する3つの脅威:もう一度システム運用を考える(1)

    新型コロナウイルスと共に人類が共存していく社会として、新しい日常「ニューノーマル」への適応が世界的に…
  3. システム運用をアウトソーシングする?しない?チェックはココだ!

    システム運用をアウトソーシングする?しない?チェックはココだ!

    今、多くの企業でシステム運用が負担になっています。その理由は、「把握すべきITシステムの増加」や「シ…
  4. 無駄な手順から見直そう:もう一度システム運用を考える(3)

    一般的には、発生した障害を通知するアラートの多くは、事前に作成された手順書に基づいて対応します。想定…
  5. チャットボットで問い合わせを効率化しよう!

    Webサイトで問い合わせをするときに、従来のようなフォームだけでなく、最近[チャットでお問い合わせ]…
ページ上部へ戻る