障害対応訓練を小さく始めてみた

はじめに

ギフティでエンジニアをやっているjmakiと申します。先日、私の開発しているプロダクトでシステム障害対応訓練を実施しました。チーム内での訓練の実施実績がない状況から、一人で準備から推進までを行い「障害対応訓練を小さく始めてみた」ので、その中の取り組みや気がついたことを記事にします。

想定読者
- これまで障害対応訓練をやったことない方
- 障害対応訓練をやってみたいと思っているが、何から始めるか迷われている方
この記事を読むことで得られるもの
- 障害対応訓練の始め方・進める上での方法論やTips

そもそも障害対応訓練って何ぞ？

実際の障害発生時に備えた準備として、システムに意図的に障害を起こし、チームの対応力を確認・向上させる活動です。ざっくりとした表現ですが、災害が発生した時に慌てないように備えておく避難訓練のシステム版みたいなことです。

参加メンバーは障害対応訓練のスコープによって様々ですが、主に以下の役割で実施することが多いでしょう。

訓練推進者：障害を意図的に発生させ、訓練全体の進行を管理する人（今回は私が担当）
運用担当：そのサービスの運用担当のエンジニア等の実際に障害を検知し、調査・復旧作業を行う人
ビジネスサイド：営業やプロダクトマネージャーなど、顧客や対応メンバーとのコミュニケーションを担当する人
顧客役：マネージャーなど、実際の顧客の動きを想定してロールプレイをする人

これ以外にもさらに詳しく知りたい方は、システム障害対応の教科書という本に詳しく書かれているのでこちらを読みましょう。障害対応訓練は、普段のシステム開発時には得られない気づきを与えてくれる取り組みですが、実施には多少ハードルを感じてしまうこともあるかと思います。

以降、私が実際に行った準備から実施とその振り返りまで時系列に沿って書いていきますので、何かの参考になれば嬉しいです。

事前準備

1.訓練の目的の決定

まずは実施する訓練の目的を定めて言語化します。一般的な障害対応訓練の目的は様々ですが、冒頭で述べた通り我々のチームは障害対応訓練をやり慣れていなかったため、まずは「来るサービスローンチ前にチームのビジネス側とエンジニアを含めて、障害対応フローを確認し整理する」を目的としました。私の担当しているプロダクトは法人向けのSaaSシステムで様々なお客様に利用頂く予定であり、システム障害が発生した際の影響も大きいため、迅速に対応できるように障害対応フローを実践的に確認しておきたかったからです。

チームによって障害対応訓練をやる目的は様々だと思いますが、初手実施する場合は目的を盛りすぎずシンプルに始めてみるのが重要だと考えています。

2.障害対応訓練の内容の策定

次に障害対応訓練の内容である、故意に障害を引き起こす箇所を決めていきます。最初の目的を達成できるような訓練内容を考えていきます。今回はシンプルに外部接続の設定を手で変更して落とすことにしました。

また障害箇所を対応するメンバーに事前に公開するか否かについても検討が必要なポイントです。今回は障害箇所は非公開にして、チームメンバーには当日その場で判断して対応してもらうことにしました。「障害対応訓練を小さく始める」という観点では公開にした方が運営がやりやすい面もありますが、今回決定した目的から考えるとより実践に近い状態にした方が効果的と判断したからです。

3. 想定タイムテーブルを作る

次に想定のタイムテーブル等を作ります。障害対応訓練は不確定要素が多いので、このタイムテーブル通りに行かないことも多いでしょう。しかし初めて障害対応訓練を実施する上では目安があった方が他のメンバーもわかりやすいので、時間の見積もりはざっくりで良いので作成するのがオススメです。参考までに私が作ったタイムテーブルが下記です。

時間	内容
13:50頃	障害発生（訓練推進側(私)がステージング環境を操作）
14:00前後	検知
14:00〜15:00	障害対応（調査・リカバリー・報告）
15:00〜15:30	障害対応完了 & 障害報告書作成
15:30〜16:30	ポストモーテム作成 + 会自体の振り返り
16:30〜17:00	バッファ

実際に私たちが実施してみたところ、おおよそスケジュール通りに進みましたがかなり時間がギリギリになってしまったのでバッファは長めに設定しておくと安心できるかもしれません。

4.障害対応訓練内容の説明・周知

最後に実施日のスケジュールを抑えて、チームメンバーへの説明をします。可能なら事前にマネージャー等に顧客役をお願いできるとベターです。またメンバーへの共有が済んだら、チームメンバー以外にも障害対応訓練の実施を周知しておくと良いでしょう。もちろん実施時にびっくりさせないためです。

ちなみに副次的な効果ではありますが、事前周知自体が「うちのチームでちゃんと障害対応訓練をやっているぞ！」というアピールにもなるかもしれません。(今回も事前にその連絡をしたところ、リアクションがついたので実施自体の励みになりました。) さらに細かい点として、障害対応訓練の予定時間帯に、本当の障害が起きたらどうするかの整理もしておくと尚良しです。今回の私たちのプロダクトはサービスイン前だったので、その考慮は不要でした。

社内でのslackの周知の例

社内でのslackの周知の例

障害対応訓練実施

障害の発生・検知・解消

実施時間になったら障害を起こします。ここでも他の対応メンバーに作業内容がバレないようにできるだけこっそりやります。そして実際に障害が発生したことを確認して、チームメンバーの初動を確認したら、あとは運営者は基本的にはメンバーの障害対応を見守るだけです。ここで障害対応が停滞し、顧客への第一報が遅れたり復旧に手間取っている場合は適度にヒントや進め方のフォローのコメントを入れます。

私たちが今回実施した中ではメンバーのお陰で、おおよそスケジュール通りに対応できましたが仮に対応に滞りが出た場合でも、課題が浮き彫りになったということなので、ポジティブに捉えて振り返り時の議論に繋げましょう。

障害報告書・ポストモーテムの作成

無事、障害を解消することができたら障害報告書とポストモーテムを作成しましょう。

ちなみに一般的に障害報告書とポストモーテムの違いは

障害報告書: 主に発生した障害や対応手順に焦点を当て、再発防止策を記載する。社外向けの文書として、顧客やステークホルダーに状況を説明する目的。
ポストモーテム: より広範な視点から障害を分析し、組織的な改善点やプロセスの見直しまで含めて検討する。主に社内向けの文書として、チームや組織の内部で共有・改善が目的。

といわれています。実際の障害時にはこの二つを作成することが多いと思いますが、訓練では適宜目的に応じて何をどこまで詳細に作るかは事前に決めておくとスムーズです。後述しますが、個人的には最初の訓練では障害対応の動き方について振り返りに時間を使った方が有意義になりやすいかなと思っています。

訓練をやるときのポイント

さて時系列で一通り説明したので、以降は今回の大切にしたポイントを3つほど書きます。

ポイントその1: 最初は目的を増やしすぎずできるだけ小さく始める

障害対応訓練は一度だけ実施すれば良いものではなく、半年や一年などの期間で継続的にやり続けてブラッシュアップしていくものです。そのため慣れていない場合は目的や観点をいたずらに増やしすぎ、まずは小さく始めて組織やチームにそのメリットを理解してもらうことが重要だと考えています。障害対応訓練を継続的に実施していくには一人の推進力だけではなくチームの協力が不可欠だからです。

また小さく始めるという観点で、障害の内容の選定も重要なポイントだと思います。個人的には、初手に実施する上では、

影響範囲が大きいかつ、復旧の作業が大変ではないもの
ビジネス的にもサービスクリティカルなもの
事前の準備にも時間がかからず、サクッと試せるもの

という観点が重要だと考えます。エンジニアとしては、あるあるシチュエーション(例えば、アプリケーションサーバやDBに高負荷をかける等)を実施したい気持ちもありますが、これは事前の準備に思ったように負荷がかけられなかったりすると準備に時間が掛かるので、試しに小さく始めるという観点ではあまりコスパが良いとはいえないでしょう。今回はAmazon Route53の設定を変更することにしました。この辺りの外部通信する所を落とすというのは個人的におすすめです。

と、偉そうに書きましたがこの辺りはSRE Magazineの記事の「どんな障害を発生させるかを決める」を大いに参考にさせてもらいました。

https://sre-magazine.net/articles/6/mm-matsuda/

ポイントその2: なるべくリアルな障害対応に近づける

あえて書くまでもないかもしれませんが、訓練とはいえなるべく現実の事象に近づけた方が得られる学びが多いです。例えば、顧客への連絡パス(誰に、いつまでに、どのような手段で)や社内の報告フローがどうなっているかなども整理して、可能な限り本番と同じフローに近づけましょう。実際に今回も弊社の担当者から顧客役へ架電して繋がらない事象が発生し「重大なインシデントが発生した場合はとにかく第一報を伝えることを最優先とし、顧客の連絡パスの改めての整理が必要という課題」も見つかりました。

ポイントその3: ポストモーテムでは障害対応の動きについて深ぼる

前述した通り、今回は障害対応の各自の動きについて問題がなかったかについて振り返りに時間をかけました。その際に「誰が、いつ、何を実施したか」を事実をベースにしていくと、今後障害対応訓練を継続したときに改善が見えやすいと考えています。私たちは時系列に「やったことと、その時に迷ったこと・困ったとこ」ことを並べてその後改善策を議論するやり方を実施しました。

振り返りのmiro

振り返りの様子

全ては紹介しきれませんが、私たちの振り返りでは下記のような課題が出てきました。

ビジネス、エンジニアどちらも障害対応時の役割分担が明確にできておらず、作業が被ってしまったり情報共有できていない部分があった。
障害時の顧客からの個別の要望と復旧対応のどちらをエンジニアに優先的に依頼するか迷った。
ツールに慣れておらず、調査対象のログを探すのに時間がかかってしまった。

特に初めての障害対応訓練だと、大小様々な課題が出てくるので気持ちが落ち込むこともあるかもしれません。しかしここで、全てを無理に一度に解決しようとしないことが個人的に大切だと思っています。障害対応訓練で課題がたくさん見つかったこと自体はとてもポジディブなことです。チームでクリティカルと判断したものの優先して解決しつつ、継続して訓練を実施し改善していきましょう。

終わりに

障害対応訓練は、普段のシステム開発時には得られない気づきを与えてくれる重要な取り組みです。初手始めるには実施のハードルもあるかもしれませんが、とにかくまずは小さく始めてやってみることが大事だと感じています。私のチームでも定期的に実施してブラッシュアップしていく予定なので、また新たな気づきが得られたらブログ等でアウトプットしたいと思います。以上です。最後まで読んで頂きありがとうございました！