インシデント対応で心がけていること
note初投稿です。
AI開発をしている小さな会社で情報システム部門とインフラの仕事をしています。
つい先日、他社でコーポレートIT部門のマネージャーをされている方とお話したときにアウトプットって大事だな！と改めて思ったので、さっそく仕事用のXとnoteのアカウントを作りました。
界隈の方を少しずつフォローしながらアウトプットを継続していこうかと思っています。
よろしくお願いします。
実は先月から訳あってスキルの棚卸を進めていることもあり、今回はコーポレートIT部門では欠かせないヘルプデスク業務、特にインシデント対応について整理してみようと思います。
大切にしている観点はこんな感じですが、結構多いですね。
書ききれるかちょっと心配になってきました。
そしてこれ、ヘルプデスクから離れてシステム運用におけるインシデント管理の観点も多分に入ってしまった感があります。ご容赦ください。
依頼者の目的、問い合わせの背景を理解する
依頼者が本当にやりたいこと、実現したいことを聞くようにしています。
例えば、外出先にいるメンバーから「VPN経路で社内サーバーにアクセスできない。すぐに復旧してほしい！」と問い合わせが入ったとき、本来の目的が社内サーバー上のファイルを開いて顧客に提示することだとわかれば、依頼者に（場合によっては直接顧客に）該当のファイルをメールで送るといった代案を提案できます。
インシデントによって生じる業務影響を理解する
インシデント対応を進める中で、このDBが応答していない、ネットワークが切断されているといったシステムの観点で障害箇所を特定していくと思いますが、そこから一歩踏み込んで、そのシステムに紐づく業務の観点で障害箇所を特定する（＝業務影響を理解する）ように心がけています。
特に大きなインシデントでは、こっちの業務は通常通りですがあっちの業務が止まっています。復旧までにかかる時間は◯時間の見込みです、というようにビジネスレイヤーで説明すると業務部門の責任者から理解を得やすいと思います。
まずは復旧ファースト
どうしてこうなった？何が問題だったんだ！？というのは確かに気になりますが、人的リソースの消耗を避けるため復旧フェーズでは原因追求を行わないよう心を配ります。
とりあえず暫定でもいいから素早く復旧させることができれば、原因追求と根本対策は後から落ち着いて進められます。
事実と仮説の切り分け、示された前提を疑う
事実と仮説が織り交ぜられている場合は切り分けて対応するようにしています。例えば以下のような問い合わせです。メールが届かない問題です。
社外の特定のメールアドレス宛のメールが届かない。
社内の他のメールアドレスから送信しても届かない。
同一ドメインの他のアドレス宛のメールは届く。
自社のドメインが先方のメールサーバーからブロックされているので、解除申請する手順を教えてほしい。
こんなとき、4の解除申請を代行することに気を取られてしまいそうになりますが、もう一度1〜4を読み直してみます。
すると、自社のドメインが先方のメールサーバーからブロックされているなら3は届かないはずだと気づきます。つまり3が事実なら4は誤った仮説かもしれないということです。
こういう場合は1〜3をもとに仮説を立て直すようにしています。
例えば、宛先のメールアドレスが存在しない（間違っている）、宛先のアカウントがユーザーの退職等により停止されている、宛先のアカウントが個別に送信元アドレスをブロックしている、宛先のアカウントの受信ボックスが容量オーバーになっているといった仮説が浮かびます。
不具合を再現させる
検証のために依頼者に多くの時間を割いてもらわないといけなかったり、特定の条件で発生する製品やサービスのバグが疑われるような場合は手元の環境で不具合を再現できないか検討します。
再現できれば依頼者とのやり取りが減りますし、後述するサポート窓口とのやり取りもずっと楽になります。
サポート窓口を戦力化する
有償の製品やサービスなら大抵の場合はサポート窓口があると思います。
即解決が難しそうな問題だと判断したら、できるだけ早いタイミングでサポート窓口に問い合わせるようにしています。
サポートとやり取りする場合は前述の再現環境があると便利です。
最初の問い合わせで不具合の再現条件を提示できる点と、手元の再現環境を使ってサポートから提示された解決手順を試すこともできるので対応の迅速化が期待できます。
なにより公式サポートには集積されたナレッジという自分達が持っていない超強い武器があります。召喚魔法を使う感覚で降臨していただきましょう。
レイヤー、コンポーネントに分解する
例えば、ネットワークの問題では、L3のチェックがOKならL4以上を調べる、L3のチェックがNGならL3以下を調べます。
WebシステムならDNS、CDN、Webサーバー、アプリケーション、データの層別に調べるといった感じで、システムを構成するレイヤー、コンポーネント別に当たりをつけるようにしています。
システムを構成する要素を細かく分解できて、各要素の役割が明確にわかるようになると、不具合箇所をピンポイントで特定しやすくなります。
行き詰まったときは調査の切り口を変えてみる
例えば、USBデバイスがPCに認識されず利用できないといった問題です。
PCに接続したときに表示されるデバイス名とエラーメッセージを切り口としてGoogle検索等で調査を進めても情報が得られない。そんなとき、メーカー名と製品名を切り口にメーカー公式サイトからダウンロードできるデバイスドライバをインストールしてみるといった感じです。
変更履歴を辿ろう
システムの不具合は直前に行われたアップデートによって引き起こされていることもあります。以前のバージョンで不具合が再現しないなら変更箇所のどこが原因か調査するきっかけになると思います。
できるだけ二人以上で対応する
一人でインシデント対応をすると仮説検証作業の沼やトンネルビジョンから抜け出せなくなることがあります。また、時間の経過とともに変化する状況を踏まえてタスクの優先順位をアップデートしたり、ステークホルダーに対応状況を定時連絡したり、関係者への協力要請を継続して行うといった調査作業以外のタスクも発生します。
そこで、実際に手を動かす作業者と状況を俯瞰する役は分けるようにしています。
問い合わせ窓口を集約する
問い合わせ窓口を一箇所に集約することでインシデントと対応内容の見える化が進みます。私の場合は小さな組織だったので、まずはSlackに専用チャンネルとヘルプデスク担当者のグループメンションを用意するところから始めました。
依頼者とのやり取りをオープンにする方が他の方から同様の問い合わせが来る件数は減ると思います。パブリックチャンネルのやり取りがそのままFAQになるためです。
依頼者のコミュニケーションスタイルに合わせる
ITヘルプデスクに限ったことではないですが、依頼者がコミュニケーションを取りやすい方法を探りつつ、スムーズなやり取りをするように心がけています。
組織の文化によるところも大きいと思いますが、チャットでの長文、短文のラリー、DM、絵文字、スタンプ、通話、meetなど、得意とする方法は人によって違ってきます。
問い合わせ窓口はオープンチャンネルの方が良いと前述しましたが、オープンチャンネルで発言するのが苦手な人だっています。
無駄のないロジカルなやり取りを好む方もいれば、相手の気持ちを汲み取りながら丁寧にコミュニケーションを取る方もいます。
忙しいと手を抜いてしまいがちになりますが、コミュニケーションの質は依頼者の困りごとを解決することと同じぐらい重要だと思っています。（これは自戒も込めて）
ドキュメントの定期的なアップデートを仕組み化(今後の課題)
よくある問い合わせ、ユーザーが実施する作業手順、社内ルール等の文書はドキュメント管理サービスに集約しています。
ドキュメントは問い合わせ件数の削減や新入社員の迅速な立ち上がり（オンボーディング）に効果的ですが、古いまま放置されていると間違いのもとになります。
そこで、作成者、責任部門、最新のアップデート日時をもとに定期的なアップデートを仕組み化しています。
仕組み化といっても現状は人力で精査して担当者にアップデートを依頼しているので、自動化できたら楽になるだろうと思ってます。
あとプルリクみたいな仕掛けもほしいですね。
この部分は古いからこのように修正しましょう！的なリクエストが出せたら面白そうです。
とりあえずこんなところです。
誰に需要があるか全くわからないまま書いてしまいましたが、誰かの参考になれば幸いです。
この記事が気に入ったらサポートをしてみませんか？