/* */

トラブった時にすべきこと

すいません。この記事はタイトル決めてから中身詰め込んでるんですけど、よく考えたら「トラブル」の定義や状況がたくさんありすぎて、絞り切れないことに気づきました。orz

ので、ITインフラ観点で、なるべく汎用的に使えるコツみたいなものを書いておきます。

基本的な心がけ

  • トリガー引いたのが自分だったとしても、隠し立てはやめましょう。被害拡大したら目もあてられません。田中の過去の経験からいうと、隠していたのがバレた時のダメージの方がはるかに大きいです。
  • やっちゃったことよりも、今後どうやってトラブルを起こさないようにするか、という方が大切です。
  • 契約は法人同士でしてます。個人の責任なんてないので、会社の責任だと割りきって、トラブルを楽しみましょう。
  • 偉い人を巻き込んで、責任を押し付けましょう。その分現場でハンドリングする余力が生まれます。

事前準備

  • 「想定される事象」「影響範囲」「対応」「報告経路」をリストアップしておく。
  • 構築フェーズだったら「リスク管理表」だし、運用だったら「監視対応一覧」「障害時対応一覧」みたいな名前になると思うけど、企業によって異なる。
  • 「リスト」は関係者間で合意しておいたほうが良い。
  • 想定外の事象について報告経路を決めておく。

トラブったら

  • 事前準備の「リスト」の範囲内だったら、リストに従って粛々と対応。
  • 想定外の事象については、サービス利用ユーザへの影響の有無、影響範囲を確認。
  • 報告経路に従って、偉い人に報告。影響が大きいほど早くした方が良い。一報を入れた後に、「○○分ごとに連絡入れます」とか、定期報告をその場で定義しておく。
  • 役割分担の定義。「コントロール役」「報告役」「原因調査役」を分けたほうが良い。

調査のコツ

  • 原因調査役が調査に集中できるよう、配慮する。
  • 全体構成図を印刷、もしくはホワイトボードに書き、影響範囲、データフローを書き込んでみる。
  • 対応内容を時系列で記録する。後の報告書作成時も役立つ。
    チャットツールを使って、関係者に展開すれば、報告と記録が同時にできる。
  • クライアントに近い部分から調査を進めていき、被疑箇所を潰していく。
  • 被疑箇所にたどり着いたら原因特定。
  • 被疑箇所がサーバ等ならばログでエラーを確認。エラーの意味がわからない場合はGoogle先生にブチ込む。英語力があるほど有利。
  • 原因が特定できたら、復旧見込みを報告。復旧後、再度報告。

トラブル後対応

  • 必要に応じて報告書作成。大体のフォーマットは「冒頭のお詫び文(笑)」「時系列」「原因」「是正策」。トラブルの大きさにより、偉い人、営業と相談したほうが良い。
  • 事前準備に記載した「リスト」にトラブル時にどうするのか記載し、次回のトラブルの際のルールを定めておく。

んんん。やはりどのフェーズ、どのペルソナをターゲットにしているのか不明確になってしまった。次の記事では、ケーススタディ書こうかな。