ラボルで定期実施しているシステム障害対応訓練について

こんにちは。ラボルのかわむらです。

ラボルでは、定期的に「システム障害対応訓練」を実施しています。

今回は、なぜそのような訓練を始めたのか、どういう感じで訓練しているのか、どのような成果が得られているのかについて紹介していきます。

なぜ訓練を始めたのか
どういう感じで訓練をしているか
- システム障害に関することを明文化
- 実施している訓練について
どのような成果が得られたか
最後に

なぜ訓練を始めたのか

訓練を定期実施している背景としては、障害発生時に対応フローや影響範囲の確認観点が曖昧で、開発者ごとに復旧までのアプローチが異なったり、考慮漏れが起こり二次被害に繋がる可能性があったりしました。また、ラボルは金融サービスを扱っているということもあり、障害発生時に影響範囲を適切に把握したり、障害を伝播させないような正確で迅速な対応がより求められています。

もちろん障害を発生せないことが一番望ましいですが、現実的に100%防ぐことは困難です。万が一システム障害が発生した場合に誰でも正確で迅速な対応ができるようにしておくことが重要です。障害が発生しないと高をくくっていると、障害発生時にあたふたして被害が拡大してしまう可能性もありますからね。

と言うような背景から、ラボルでは開発環境等でシステム障害を意図的に発生させ、それに対して開発メンバーが復旧作業を行うという訓練を実施することとなりました。

どういう感じで訓練をしているか

まずラボルでは以下の内容を明文化することから始めました。

背景
対応フロー
ロール分け
システム障害指標

これらを明文化してチームで共通の認識を持っておくことで、実際のシステム障害発生時にも共通の意思疎通がある程度できるようになります。

システム障害に関することを明文化

対応フロー

背景は先に述べたのでスキップするとして、対応フローは以下のようなものを用意しました。

これはオーソドックなものですが、大きな障害が発生したときにはパニックになりフロー通りに出来ない可能性もあるので、事前に頭に入れたり、障害発生時にフローを確認するのには役立ちます。青色の枠で囲っているところがロール分けとシステム障害指標です。

障害対応するときは概ね上記のようなフローになるかと思います。

ロール分けについて

障害発生直後ステークホルダに報告したあと、すぐに障害対応のロールを決めます。

ラボルでは以下のロールを設けています。

司令塔
作業員
記録係

訓練時はなるべく上記のロールを各々が全うできるように進めています。これはロールの立ち回りに慣れるためです。実際の障害発生時には一番知っていそうな人に聞いたり、全員で原因を解明に奮闘したりもするかもしれませんが、全員が全員障害発生時にいるとは限らないので、各々ロールに慣れておく必要があります。

ラボルで各ロールがどのような動きをするべきなのかを定義しています。なるべくこれを意識しながら訓練しています。まあときどきの臨機応変さは重要ですけどね！

司令塔

障害現場の指揮を取る人。他ロールは司令塔にのみ従う
- 障害の調査対象や対応方法の決定は司令塔が行う
障害を俯瞰して観測し、作業員への支持を適宜行う
- 作業員が行っている以外の原因候補とかを考えられると良い。作業員はそこまで手が回らないので
作業員から現状をヒアリングし、ステークホルダへの報告を行う
- 他者からの邪魔が作業者に入らないようにする

訓練を始めたばかりのときは、他部署の人や部外者みたいなロールを作って司令塔にちょっかい出して、司令塔がそれを弾けるかみたいなこととかもやったりしました。司令塔は一番重要なロールなので作業者の手が回らない範囲や、司令塔にしか出来ない俯瞰して先導することが重要です。適宜ステークホルダへの報告も忘れずに。

作業員

障害の調査、復旧を行う作業者
- ログやメトリクス、データなどを漁ったりする
司令塔のみの支持に従い、司令塔のみに報告する
- 司令塔以外の支持は無視する
暫定対応の考案を行う

作業員が一番手を動かすことになります。作業者は一番障害に近いので、気になることがあったらすぐに司令塔に支持を仰いだり相談したりすることが重要です。ログやメトリクス、データを正確に早く見ていく必要があるので、日頃からそういう操作をしておく癖をつけておくといいです。

記録係

時系列で障害復旧までの記録を行う
障害発生時刻や、ステークホルダへの報告時刻、原因判明時刻、暫定対応時刻等

これは正直誰でも出来ます。障害対応は出来ないと不安な方は「率先して記録係します！」と申し出ましょう。slackを使って記録を投稿していくことでtimestampも記録されるのでおすすめです。記録を正確にしておくと、次の障害に活かせたり、ユーザへの報告の際により詳細な内容を伝えられたり出来ます。

システム障害指標

ラボルではシステム障害指標というものを設けています。

指標に合わせて対応を細かく決めているというわけではないですが、開発者同士で、このくらいの障害だったら、このくらいまでに、このくらいの対応できると良いよねと共通認識を持てるようにしています。

指標分類をある程度することによって、どのくらい深刻な状況なのかなどが判断することが出来るようになり、それによって対応タイミング、対応方法が変わってきます。

ラボルでは以下の3つの指標を定義しています。

ユーザ影響範囲
- 全ユーザ、限定範囲ユーザ、単一ユーザなのかどうか
深刻度
- 主要機能が使えないのか、サブ機能が使えないのか等々
継続性
- 今も継続している障害なのか、今は継続してない一時的な障害かなど

ユーザの影響が範囲広く、深刻で現在も継続している障害であれば夜中でも早朝でも、緊急の対応を行うべきです。また、現在継続もしてないし、深刻度も低い障害なら真夜中にタクシーを走らせて会社に向かったりする必要はないかもしれません。

実施している訓練について

明文化の内容がかなり長くなってしまいましたが、実際に実施している内容を紹介します。

訓練内容は各開発者が定期的に考えて、それ以外の人がその障害対応を行う感じで進めています。

訓練内容は以下の内容を事前に作成します。

システム障害タイトル
- あとから追いやすいように、わかりやすいシステム障害のタイトルを決めます
  - 例)操作ミスによるDB Schema Drop障害（こわいですね
シナリオ
- どういう流れでその障害が発生したのか、発覚したのか
- 現場にはどういう人がいて、どういうタイミングなのか（平日、夜間、土日なのかとか）
訓練する開発者に対して期待すること
- どういう復旧方法があり、どういう理由でそれをすべきなのか
  - 影響範囲やシステム障害の深刻度に合わせてメンテをしたり、定期バッチを止めたり
- どのタイミングでどのいう人に、どんな連絡をすべきなのか

上記を用意し訓練を実施します。

訓練作成者は実施後にフィードバックを行います。期待することに対して出来てたか、出来ていなかったか？悪かった動きや良かった動きなどなど。

また、最近「今後すべきこと」という内容を一つ一つの障害訓練の中に入れるようにしました。

これは障害訓練作成や訓練を通して、事前にやっておけばこの障害防げるんじゃないかとか、この障害が発生した場合は影響範囲はこの範囲になるから、予め対応マップみたいなものを用意したほうがいいんじゃないか、とかを記録するものです。

ここはかなり重要だと感じています。訓練を実施することで開発者個々の能力が上がったり、いろいろな障害に対応出来るようになったりはしますが、上記資料作成や対応を行っていくことで、今後人が増えた場合や辞めた場合にも、組織にノウハウが蓄積されてるのでシステム障害発生時に誰でも正確で迅速な対応がしやすくなると思います。

どのような成果が得られたか

各開発者がある程度各ロールになりきって対応することが出来るようになったり、実施した訓練に対して何をどう考えて、どう復旧していくのかということが出来るようになりました。

ただこれは訓練を行えばもちろん出来るようになることで、意図していたものでした。これ以外で得られた成果としては、

未然に防げる障害をピックアップできる
現在使っているシステムのサブ機能について深く知れる
単純に楽しい

未然に防げる障害をピックアップできる

これは「今後すべきこと」で説明しましたが、訓練作成や訓練自体を通して、その障害が未然に防げるかを自ずと考えるので、防御可能なものであれば、未然に防ぐことが出来ます。

様々なシステム障害を様々な開発者が考えるので、少しずつではありますが、いずれ発生したかもしれない障害を防ぐことが出来ます。

例えば開発者の操作ミスによるDB Dropやtable Dropであれば、そもそもそういう権限をDBを操作するユーザに与えなければいいだけです。こういう風に未然に防げれば新卒の開発者も安心して操作できるようになりますし、他の開発者も安心して見守ることが出来ますね。

現在使っているシステムのサブ機能について深く知れる

普段から開発者が使うシステムの主要機能であればある程度深く知っていると思いますが、障害が発生したときにしか使わない機能はなかなか使う機会も無いですし、いざ本番環境で障害が発生したときに、使おうとしても不安になります。またそれがより良い選択であるかも分かりません。

これらを障害訓練を通して、深く知ることで実際の障害発生時に落ちつて適切に対応することが出来るようになります。

DB Dropしてしまって、DB毎復旧しないといけなくなった場合には、複数のDBリストア方法があります。例えばAWS AuroraのDBリストア方法は複数ありますが、それぞれ事前に試したり、こういうサービスでこういうDB障害を発生させてしまった場合には、このリストア方法が良いなど事前に把握しておくことができます。また、リストア時間はどのくらいかかるか、新しいDBエンドポイントになるのか、セキュリティグループは引き継がれるのか、など実際に動かしてみて分かることもあります。