障害対応のロールプレイング訓練について

座学で学んだことを実際の障害で実践することの困難さ

SRE本やあるいは【障害対応】インシデント管理プロセスについてのような記事で障害対応の方法論について読んだことがある人はいると思います。
しかし、実際に障害が発生した状況でこれらを実践できる人・組織は多くありません。
私は過去SREチームのリーダーとして組織へ座学でインシデント管理プロセスをレクチャーしたことがあるのですが、その後、まったくそれらが行われずに障害対応されているシーンを何度か目にしました。

その後なぜそうなってしまったのかを考えたのですが、主な要因は緊張度が高く時間的なプレッシャーもかかったシーンで座学で学んだことをその場で実践するのが難しい、というシンプルな理由であるとわかりました。実際、私自身も何度かの障害対応を経てインシデント管理プロセスの実践が安定してできるようになったので、一度座学で聞いただけの人が実行できないのはある意味当然でした。

そこで、これを解決するために行ったのがロールプレイング訓練です。

ロールプレイング訓練

ロールプレイング訓練とは、実際に障害が起こった状況を可能な限り再現し、その中でインシデント管理プロセスを実践する訓練のことです^[1]。
だいたい以下の流れで行います:

1. ロールプレイング訓練実行者(以後ゲームマスター)が関係各位にこれから障害対応のロールプレイング訓練を行うことを告知
2. ゲームマスターが本番で仮想的に障害を発生させる (Datadogでアラートを発生させ^[2]、PagerDutyでオンコールを鳴らす)
3. 障害対応に当たるメンバーへ実際に障害が発生したときと同じ作業・コミュニケーションを取ってもらう
   • ただし、実際にインフラを変更したりデプロイをすると危険なので、そこだけは XXX実行します とゲームマスターに伝え、ゲームマスターは こういう結果が返ってきました 成功しました 失敗しました などと返す
4. 状況が解決できたと判断したら、ゲームマスターはロールプレイング訓練の終了を宣言する

このロールプレイング訓練の効果を最大化するためのポイントがいくつかあります。

ポイント

1. 限りなく本物の障害発生時に近い状況で訓練をする

可能ならアラートは開発環境ではなく本番環境で、PagerDutyなどのオンコールも鳴ったことにするのではなく、実際に鳴らして訓練をしましょう^[3]。
これには2つの理由があります。
1つは、障害の対応メンバーが実際の本番で障害が起こったときにどうなるのかを知らなければ、障害発生時に効果的な対応ができないためです。開発環境でのアラートがどこで鳴るのかを知っていてもあまり意味がなく、本番で障害が発生したときに鳴る場所こそ知っている必要があります。
もう1つは、実際にやってみると本番環境でアラートが鳴らない/電話が鳴らない/Slackチャンネルに通知が出ない、ということがよくあるためです。アラート、特に本番環境のアラートというのは普段鳴らないため、いつの間にか機能が壊れていても長い期間気づかないことがあります。ロールプレイング訓練はそれを事前に気づくための機会にもなります。

本番環境で訓練を行うことに不安を感じる人もいるかもしれませんが、訓練ですら本番環境を触るのが不安ということは実際に障害が発生したときの対応はもっと困難になります。実際に障害が発生したときに効果的な対応をするためにも、本番に近い状況で訓練をすることが重要です。

2. 実際の障害が発生したときと同じコミュニケーションを行う

訓練されていない障害対応で一番欠落しやすいのがコミュニケーションです。
普段よくコミュニケーションしている開発チーム内は問題ないのですが、開発チーム外のステークホルダー(営業チーム、サポートチーム、事業責任者など偉い人)への連絡は足りなかったり不適切であることが多いです。

ただ、ここについてもぶっつけ本番で適切なコミュニケーションをすることはできないので訓練する必要があります。
そこで、ロールプレイング訓練では予めステークホルダー(障害発生時に連携する先の人)へ以下を伝えます。

1. X月X日に障害対応のロールプレイング訓練を行います
2. つきましては、実際に障害が発生したときと同じレスポンス・指示などをください
   • 特に過剰に(頑張って)反応してもらう必要はないです
   • 逆に、訓練だからとあまり手を抜かないでもらえると嬉しいです。必要な情報が足りなければ、訓練中/後にフィードバックしていただければ実際の障害が発生したときに備えて改善できます

そして、訓練に参加するメンバーには実際にステークホルダーへSlack, Google Meetその他で連絡してもらいます。例えば、全体チャンネルで次のような告知を出すでしょう。

@channel
【これは訓練です】
現在XXXで障害が発生しており、一部のページで5xxエラーが発生しています。
きっかけは直前のリリースだと思われますが、切り戻しても状況が復旧しません。
現在、原因を調査しています。

これは、普段行わないコミュニケーションを予め準備しておく狙いがあります。
例えば普段はまったく全体チャンネルで @channel を行わない人、あるいは事業責任者とほとんど話さない人がいると思います。そういった人が障害対応でコミュニケーション担当者となっても役割を果たせるよう、予め練習する必要がある、ということです。

3. 最低でも年に1回は行う

人間なのでいくら良い訓練をやったとしても数ヶ月経てば忘れてしまいます。
できれば半年に1回、最低でも年に1回は行いましょう。
新メンバーの加入タイミングなどもよい機会です。

この訓練は、よく練られたシナリオの訓練を数年に1回するよりは、半年に1回必ず行う方が良いと思います。というのは、実際の障害発生のシナリオというのは予測が不可能なため、そのような場合に有効なのはどれだけインシデント管理プロセスを忠実に行い、秩序だった対応ができるか、だからです。

脚注

1. ちなみにこれらの定義やロールプレイング訓練という呼び名は僕が勝手に呼んでいるもので、SRE本などを論拠に置いてない我流のものです。もっとcanonicalな方法論があればそっち参照したほうがいいかもしれません。いわゆるゲームデイに近いものだとは思っています

2. 僕はこれを実現するため、よくcurlテストの条件式を 200 OKじゃなければアラート から反転させて 200 OKならアラート に書き換えていました

3. DatadogやPagerDutyにはアラートを人為的に発生させるテスト機能があります