ITシステムの防災訓練をやろう




昔、会社で「システム」の防災訓練を企画して色々と良かったなぁと思ったので振り返りを兼ねて記事を書いてみる。

Contents

ITシステムの防災訓練とは

サービスの運用中に問題が起きたことを想定して(もしくはSTG環境で実際に問題を起こして)、その後の動き方をチームで体験することです。

おそらく新しいシステムがローンチしたときに、プロジェクトの後工程にてトラブル報告フロー等を定義していると思いますが

これらは運用フェーズに入ってからも実際につかえるのか、陳腐化していないかを定期的に確認をすることで本当のトラブルに備えます。

実際にやってみると、

・運用担当者にはメールが届かない(送信先にいない)。
・システムの更新でアラートが発生しなくなっていた。
・新しい担当者は再起動の手順や、問題の確認方法を知らない。
・バックアップはカラム追加等に追随していなくてリストアできない。
・一報、復旧の目標時間を達成できない。
・お客さんが求めている情報を取得できない。

システムの防災訓練での確認項目の洗い出し

防災訓練の実施者は、以下の観点に従って確認するべきポイントを定義します。他にもあるかも。

障害の発見

システムは正しくアラートを発出しているか

  1. アプリケーションやインフラの更新に伴って動かないアラートになっていませんでしょうか?
  2. 一時的に停止したアラートは今も正しく動作しているでしょうか?

監視担当者は適切に障害を認識できるか

  1. 多くの不要なアラートに、本当に検知しなくてはいけない情報が埋もれていませんか?
  2. 全ての担当者は緊急時に本番の環境にアクセスをして調査はできるでしょうか?
  3. すべての担当者が均一に障害を検知できる状態でしょうか?
     (特定の担当者は大量のアラートから特定の条件で抽出していたりしませんか?)

障害の報告

  1. 障害発生時の報告ルート、役割は正しく定義されているでしょうか?
  2. 障害時に報告する内容は、ログや監視ツールから適切に取得できるでしょうか?
  3. 障害報告までの時間は定められた時間内に報告できるでしょうか?

復旧

  1. 問題が起きている箇所の特定は容易にできるでしょうか?
  2. 再起動手順は正しく動作するでしょうか?
  3. バックアップは正しく戻すことができるでしょうか?

 

防災訓練の実施

防災訓練をする場合、報告される側(お客さん)を立ててその人にエンジニアは報告する形にします。

その上でお客さんの対応をしながら目標復旧時間内に復旧ができるかを確認する。

振り返りの会の実施

できていなかったことを洗い出して、その問題を継続して改善していってください。

これをやることで、安寧の日々が待っています。




シェアしてみる。

コメントを残す

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください