障害・トラブル時の連絡の型｜信頼を守る報告
サイトで決済できないとの連絡を受けたとき、原因を調べ終わるまで黙っているのは適切ではない。まず利用者に何が起きているかを…
text: HYPE編集部
エンジニアの記事一覧へサイトで決済できないとの連絡を受けたとき、原因を調べ終わるまで黙っているのは適切ではない。まず利用者に何が起きているかを伝え、その後に進捗と復旧見込みを更新する必要がある。障害報告を段階に分けて整理する。
第一報は原因より影響を伝える
障害を発見した時点で確認済みの症状、影響範囲、暫定対応を整理する。推測の原因を確定事項のように伝えない。
サイト障害の連絡で、原因の推測を長く書く前に利用者へどんな影響があるか伝える。閲覧できないページ、影響を受ける操作、発生を確認した時点、現在の対応状況を区別する。全体停止と一部機能の不調は違うため、確認できた範囲だけを報告する。復旧時刻がまだ分からないなら、未定と明記して次の更新方法を示す。
連絡先と判断者を決めておく
技術担当だけが状況を抱えると顧客対応が遅れる。顧客窓口、復旧判断、対外告知の担当を事前に決める。
障害の影響を受ける顧客と社内の技術担当では、必要な連絡内容が異なる。責任者、連絡媒体、夜間の連絡手順を通常時に決めておく。発注者の窓口が一人しかいない場合、担当者が不在になった際の代替経路も重要だ。チャットだけに重要事項を残すと流れてしまうため、状況を記録する場所を一つ決める。
体系立てて学びたい場合は、Webスキルを学ぶオンラインスクール デイトラのようなオンラインスクールも選択肢になります。
障害時は、復旧作業と並行して、誰が関係先へ連絡し、誰が公表範囲を判断するのかを先に決めておく必要があります。IPAの情報セキュリティに関する案内も参照し、連絡系統を平常時の資料として残しておきましょう。
更新予定の示し方
次に何を調べるか、何が分かれば更新するかを示す。根拠のない復旧時刻を約束するより現在地を共有する。
次報を出す時刻を示すなら、原因が特定できていなくても現状を更新する。新情報がない場合にも「調査継続中」「影響範囲は現時点で変更なし」など確認済みの内容を伝える。曖昧な「もうすぐ直ります」は利用者の予定を狂わせる。更新が遅れると分かった時点で理由を示し、報告の空白を放置しない。
切り戻しの条件
変更を続けるほど影響が広がることがある。直前の変更、バックアップ、元に戻せる条件を点検して判断する。
更新を適用した直後に不具合が発生したなら、元の状態へ戻す判断もあり得る。ただしデータの移行が伴う変更は単純に戻せない場合がある。切り戻しの条件、実行権限、復元対象、確認手順を事前に整理する。影響の大きい操作を急いで繰り返す前に、バックアップの状態と利用中のデータを確かめる必要がある。
公開や納品の環境を整えるなら、レンタルサーバー エックスサーバーのようなレンタルサーバーも候補になります。
復旧後の報告を分ける
サービスが動いた時点の復旧報告と、原因分析・再発防止の報告は別にする。調査が続いているなら未確定と記す。
サービスが使える状態になったことと、原因が完全に分かったことは別の報告に分ける。復旧の告知では、再開した機能と残る注意点を伝える。その後の報告では発生経緯、検出方法、暫定処置、再発防止策、未解決事項を整理する。調査が続く点を隠さず、何をいつ再確認するのか決める方が信頼性は高い。
復旧の連絡と原因の報告を分けると、未確定の推測を事実として広げずに済みます。内閣サイバーセキュリティセンターがサイバーセキュリティ政策や注意喚起の情報を発信していることも踏まえ、確定した事実から順に報告へ移しましょう。
信頼は記録と改善で守る
作業ログ、監視、顧客への連絡履歴を残す。反省文よりも担当・期限・検証方法のある改善策にする。
トラブルをゼロにすると約束するより、検知と報告を改善する方が現実的だ。対応の履歴を残し、初動が遅れた原因や連絡先の不備を振り返る。顧客に影響があったなら契約上の報告義務や補償条件も確認する。過去の対応記録をもとに運用手順を更新すれば、次に同様の問題が起きたときの判断が速くなる。
学んだことを仕事につなげる入口として、スキルマーケット ココナラで小さな案件から始める方法もあります。
障害第一報の記載項目
たとえば管理画面のログインに問題がある場合、最初の報告には確認した現象、影響を受ける操作、調査の実施状況、利用者が控えるべき行動を含める。再現確認ができていない内容は断定しない。対応窓口を明示し、次にどこで更新を受け取れるか案内する。原因の推測を書いてから撤回するより、確認済みの範囲を正確に伝える方が安全だ。
復旧を知らせるときは、すべての機能が戻ったのか一部だけなのか区別する。再試行を依頼する場合には、既存の操作結果が二重に反映されないか確認する必要がある。停止中に蓄積したデータの整合性も、単に画面が開くこととは別に点検したい。
報告書へ残す時間軸
発生の推定時刻と、担当者が異常を検知した時刻は一致しないことがある。報告では両者を分け、分からない情報を確定したように書かない。監視ログの時刻を使う際は時間帯にも気を付ける。
対応中のチャットには多くの発言が残る。後の説明用に、事象を確認した時刻、実施した変更、その時点で分かった影響を時系列で整理するとよい。
原因が外部サービスに関係する場合も、顧客への説明責任がなくなるわけではない。確認できた事実と外部からの回答を区別し、利用者が取るべき行動を正確に伝える。
再発防止策の「注意する」「確認を徹底する」だけでは実行を検証しにくい。監視条件、試験手順、責任者、記録の保管場所などを具体的に決め、後から改善の有無を確かめる。
障害の説明で使う専門用語は、顧客の担当者が必要な判断をできる程度に言い換える。「データベース接続エラー」だけでは、申込者が入力した内容が保存されているか分からない。確認済みの情報から業務への影響を示し、次に利用者がしてよい操作を説明する。技術的な原因の詳細は別資料としてまとめる方法もある。
事故の規模によっては通常のチャット連絡だけでは足りず、関係部門への報告が必要になる。顧客への説明と社内での原因調査を混同せず、それぞれに必要な記録を残す。
検知、連絡、暫定対応、復旧確認の時刻をそろえて残すと、後から経過を検証できます。総務省のサイバーセキュリティに関する案内も確認し、記録の粒度を自社の運用に合わせて決めておきましょう。
仕事と売上につなげるための判断
障害対応の信頼は、障害がなかったことにする表現からは生まれない。発生時に何を伝え、誰が判断し、何を改善したかが残っていることが重要だ。運用保守の見積もりでも、監視だけでなく報告作成や復旧後の振り返りを含むかを明確にしておく必要がある。
出典
CTA
仕事の取り方や単価の決め方で迷ったら、HYPEへご相談ください。→ お問い合わせはこちら
※本記事にはプロモーションを含みます。
合わせて読みたい
つくる人の仕事のヒントを、週1で
新しい記事と、学び・案件のヒントをメールでお届けします。
RECOMMEND
注目のコンテンツ
