トラブった時にすべきこと
すいません。この記事はタイトル決めてから中身詰め込んでるんですけど、よく考えたら「トラブル」の定義や状況がたくさんありすぎて、絞り切れないことに気づきました。orz
ので、ITインフラ観点で、なるべく汎用的に使えるコツみたいなものを書いておきます。
基本的な心がけ
- トリガー引いたのが自分だったとしても、隠し立てはやめましょう。被害拡大したら目もあてられません。田中の過去の経験からいうと、隠していたのがバレた時のダメージの方がはるかに大きいです。
- やっちゃったことよりも、今後どうやってトラブルを起こさないようにするか、という方が大切です。
- 契約は法人同士でしてます。個人の責任なんてないので、会社の責任だと割りきって、トラブルを楽しみましょう。
- 偉い人を巻き込んで、責任を押し付けましょう。その分現場でハンドリングする余力が生まれます。
事前準備
- 「想定される事象」「影響範囲」「対応」「報告経路」をリストアップしておく。
- 構築フェーズだったら「リスク管理表」だし、運用だったら「監視対応一覧」「障害時対応一覧」みたいな名前になると思うけど、企業によって異なる。
- 「リスト」は関係者間で合意しておいたほうが良い。
- 想定外の事象について報告経路を決めておく。
トラブったら
- 事前準備の「リスト」の範囲内だったら、リストに従って粛々と対応。
- 想定外の事象については、サービス利用ユーザへの影響の有無、影響範囲を確認。
- 報告経路に従って、偉い人に報告。影響が大きいほど早くした方が良い。一報を入れた後に、「○○分ごとに連絡入れます」とか、定期報告をその場で定義しておく。
- 役割分担の定義。「コントロール役」「報告役」「原因調査役」を分けたほうが良い。
調査のコツ
- 原因調査役が調査に集中できるよう、配慮する。
- 全体構成図を印刷、もしくはホワイトボードに書き、影響範囲、データフローを書き込んでみる。
- 対応内容を時系列で記録する。後の報告書作成時も役立つ。
チャットツールを使って、関係者に展開すれば、報告と記録が同時にできる。 - クライアントに近い部分から調査を進めていき、被疑箇所を潰していく。
- 被疑箇所にたどり着いたら原因特定。
- 被疑箇所がサーバ等ならばログでエラーを確認。エラーの意味がわからない場合はGoogle先生にブチ込む。英語力があるほど有利。
- 原因が特定できたら、復旧見込みを報告。復旧後、再度報告。
トラブル後対応
- 必要に応じて報告書作成。大体のフォーマットは「冒頭のお詫び文(笑)」「時系列」「原因」「是正策」。トラブルの大きさにより、偉い人、営業と相談したほうが良い。
- 事前準備に記載した「リスト」にトラブル時にどうするのか記載し、次回のトラブルの際のルールを定めておく。
んんん。やはりどのフェーズ、どのペルソナをターゲットにしているのか不明確になってしまった。次の記事では、ケーススタディ書こうかな。