こんにちは。リンクウェルのkitaです。
クリフォアの開発チームに所属しています。
クリフォアとはFlutterで作られたモバイルアプリのことで、様々な機能を提供しています。
クリフォアのことや使用している技術が気になった方は、以下の記事をご覧ください。
さて、先日クリフォアの開発チームでは、障害に強くなるために 障害対応避難訓練 を実施しました。この訓練を通していろいろと学びがあったので、訓練の内容や学びを紹介しようと思います。
障害対応避難訓練とは
テスト環境でわざと障害を発生させて、その障害に対してチームのメンバーが初動調査から解決までを素早く適切に行えるか訓練することを、障害対応避難訓練と呼びます。
なんで訓練をしたの？
クリフォアはローンチから約1年が経過し、その間、重大な障害は発生していません。
しかし、その結果こんな課題が見えてきました。
- 障害に対する感覚が薄れているのではないか？
- 新メンバーが多く、既存の障害対応フローを正確に理解できていないのではないか？
- いざ障害が起きても、すぐに動けないのではないか？
これらの課題を解決するために、訓練を実施することにしました。
訓練で達成したいこと
訓練で達成したいことは以下の3つです。
- 障害対応フローの理解
- チームで協力して障害を解決する力の強化
- チーム全員がインシデントコマンダーをできるように
ざっくり言うと、「障害対応が全然分からん！」から「我々がなんとかします！」と言える状態になることが目標です。
インシデントコマンダーとは
インシデントコマンダーとは、発生した障害に対して解決へ導く指揮官のことです。
インシデントコマンダーの役割は、発生した障害に対してチームメンバーをリードして素早く解決まで導き、メンバーと障害の再発防止策を考えることが主な役割となります。
訓練の内容
事前準備
訓練をするために事前に準備を行いました。
障害対応フローの確認
本番に近い形で訓練したいので、既存のフローを確認しました。
関係者への事前周知
本番障害と勘違いして混乱しないために、事前に訓練することを伝えました。
役割を決める
訓練の役割を決めました。
インシデントコマンダーとしてFlutterエンジニア1名、調査担当者としてエンジニアを2名アサインしました。
障害内容を決める
バックエンドにバグを仕込みホーム画面で問題を発生させることにしました。
今回の訓練の目的は障害フローを理解することなので、障害の事前共有や安全に実施するためにローカル環境で行いました。
※左が通常の状態で、右が障害が起きた状態です
当日の流れ
障害が発生していることをSlackで共有して訓練スタートです。
訓練スタート後、関係者はGoogle Meetに集合して以下の流れで障害対応をしました。
- ステークホルダーに障害が起きていることを共有
- インシデントコマンダーを中心に障害の調査開始
- 障害の原因を特定
- 影響範囲や修正目処をステークホルダーに共有
- 障害の修正・検証
- 収束の宣言
- 障害報告書の作成
- 振り返り
おおよその所要時間は以下のとおりです。
- 障害発生〜収束まで
- 1時間
- 障害報告書の作成
- 30分
- 振り返り
- 30分
訓練を実施した結果
訓練の流れは決めていたものの想定外のことが起きて混乱はありましたが、さまざまな学びを得ました。得られた学びについていくつか紹介したいと思います。
障害内容の認識がズレる
障害報告がテキストだけだったので、内容の解釈がメンバー間でズレました。画像や動画も要求して認識を揃えるのが大事だと実感しました。
言葉の統一が必要
同じ意味のことを、メンバーが違う言葉で表現していたことがありました。例えば、障害の暫定対応を応急処置や止血と表現していました。ユビキタス言語を作り共通の言葉を決めておくことで、スムーズな対応ができると感じました。
オンライン・オフラインの混在はコミュニケーションが難しい
弊社はハイブリッド勤務を可能としていることから、オフラインとオンラインを組み合わせたハイブリッド形式で訓練しました。その結果、複数の報告や議論が混線してしまうといったが起きたので、どちらかに寄せた方が良さそうだと感じました。
専門外の判断が難しい
Flutterエンジニアがインシデントコマンダーを務めたため、バックエンドの障害対応に対する意思決定をする場面で判断に困ることがありました。これに対する有効な解決策は出ていないのですが、調査者に任せる柔軟さは必要と思いました。
障害報告書のフォーマット改善
障害報告書のフォーマットはあるのですが報告書の書き方が統一されておらず、書き慣れていないメンバーが悩むことがありました。簡単に書けるようにフォーマットの改善が必要です。
Sentryの重要性を再認識した
弊社では障害通知にSentryを活用しているのですが、ローカル環境はSentryを繋げていません。そのため、本来ならばSentryの障害通知を元に原因を調査しますが、今回はアプリのログを直接取得するなど調査に影響がありました。このことから、Sentryの重要性を再認識し、ローカル環境でもSentryを繋げようという改善点が見つかったのは非常に良かったです。
暫定対応案の考案
クリフォアの機能はWebで対応できる機能が多くあるので、障害発生時にすぐにWebに誘導できる仕組みがあると便利という話が出ました。
まとめ
訓練を通じて、障害対応の大切さや多くの学びと改善点が見えてきました。また、チームとしても個人としても成長できたと感じていて本当に実施してよかったです。
サービスは、使ってくれるユーザーがいる限り障害が発生しないなんてことはないので、今後も訓練を継続させて、来るべき時のために備えていきます。また、今回の学びは他チームにも共有し、障害に強い組織を目指していきます。
もし、自分のチームが障害対応に不安を感じているなら、ぜひ一度訓練を実施することをおすすめします。
Discussion