こんにちは、hacomono SRE の大西です。
hacomonoに入社して半年が経過し、だいぶ自社のシステムの全容がわかるようになってきました。
今回は私が全容がわかるようになるまでに自分がトライしてきたことや、社内に協力を得てきたことの一部についてお話させていただきたいと思います。
テーマは「障害訓練」です。
1. 障害訓練とは？
今回はわかりやすいようにサーバダウンを例としてお話をさせていただきます。
サーバダウンはWebサービスの開発に関わってきた人であれば一度は経験したことがあるかと思います。
障害訓練はそのサーバダウンを意図的に発生させ、そのサーバダウンを解消するまでの一連の流れを訓練することになります。
大きく分類すると、障害の流れは以下の4ステップになります。
- 障害を検知
- 障害対応者が気づく
- 障害の対応行う
- 再発防止を計画
2. 私と障害訓練
私が障害訓練について考えるきっかけになったのは10年近く前の話になります。
当時データベースの一部が不具合によって整合性が合わず、バックアップから復旧の作業を行うこととなりました。
その際にRDSの「Point-in-timeリカバリ」の機能を使用し、1秒単位で指定して特定の時間まで戻せると考えていました。
しかしながら、いざ復旧させようと思った時に実行できなかった理由がいくつかありました。
- 復旧作業中にデータベースに対してアクセスができるのか
- 復元時間はどれぐらいかかるのか
- 復元中にINSERTされてしまったデータはどこにいくのか
後からわかったことですが、Point-in-timeリカバリは既存のDBを元に戻す機能ではなく、特定の時間まで巻き戻した新しいRDSのインスタンスを立ち上げる機能でした。
当時の私はそのことがわかっていなかったため、Point-in-timeリカバリの機能を使えず翌日の朝まで放置することとなってしまいました。
この時、バックアップとは復旧作業を行うことができて初めてバックアップに対応している言えるものだと学びました。
これがきっかけで私は機能を開発した後のことをよく考えるようになりました。
同じように障害対応も事前に障害の対応方法を把握できれば障害に強いサービスを提供できるのではないか？と考えました。
3. 障害の流れ
改めての確認にはなりますが、多くの障害はこのような時系列で物事が進みます。
色で分けてありますが、対応項目には求められる能力や対応者が違ってきます。
私はこれをSTAGE0 ~ STAGE3と表現しております。
それぞれのSTAGEについて説明を記載します 。
3.0. STAGE 0
識別: ○○の環境で
検知: ☓☓のメトリクスが
判別: しきい値△△%を超えたので
通知: □□の手段で障害を通知する
例: WebサーバでCPU使用率が5分間ずっと100%の状態のためSlackに障害を通知する
3.1. STAGE 1
確認: ○○さんが通知に気づき動作確認等を行う
社内周知: 障害が起きていることを社内で伝える
顧客報告: 現状起こっていることをユーザーに対して第一報を行う( ≠ 原因の報告 )
例: カスタマーサポートの大西さんが、Slackの通知に気づき動作確認を行う。
障害が起こっていることが確認できたので、社内全体に対してメンションをつけて障害が起こっていることを連絡する(休日の場合エンジニアのオンコール担当に電話を行う)
現状サイトにアクセスできないことをユーザーに対してお知らせをする(Twitterやサイト内のお知らせページ等)
3.2. STAGE 2
原因調査: 何が原因で障害が起こっているかを認識する
応急対応: 抜本的な解決ではなく、復旧を優先して行う
顧客報告: 障害が解消したことを原因も含めてユーザーに報告を行う
例: Webサーバにてボトルネックが発覚したためサーバに大きく負荷がかかった。
ボトルネックにはアクセスを一時的にできないように変更し、サーバの再起動を行った。
ユーザーには障害の解消と一時的な機能の停止の報告を行う。
3.3. STAGE 3
振り返り: 障害の対応の時系列等をまとめて、あらためて障害を分析し再発防止策を検討する
恒久対応: 振り返りで上がった項目に対応する
例: 障害が起きた翌日に落ち着いた状態で改めて障害について振り返る。
- 何故障害が起こったのか？
- 障害対応をスムーズに行えたか？
- 今後も発生しうるのか？
- どのようにして再発を防止するのか？
振り返り後はタスク化し、優先度を決めていつまでに対応するか？を決めて恒久対応を行う。
4. 各STAGEの特徴
各ステージにて行うことは先程紹介させていただいたので、ここからはステージの特徴についてお話をさせていただきます。
私がこの障害訓練において特に重く置いているのは、「STAGE 1」になります。
障害自体を早く解決することができればとても喜ばしいことです。
ただ、実際にはAWSやGCPの障害であったり自社の力ではどうやっても解決できないケースも多々あるかと思います。
そういった際に重要なのは「障害であってもユーザーの不満度を下げる」ことです。
サーバに繋がらないのであれば代替手段を提供したり、困っているユーザーに対して状況をしっかり説明することで同じ障害時間であっても不満度を下げるように行動をします。
そのため、一番コントロールのしやすい社内の連絡体制であったり、オンコール対応の当番表の作成などをしっかり整備することが重要です。
また、いくら技術力があってもサーバを再起動する認証情報を持っていなかったり、サーバがどこにあるのかがわからなければ対応できません。
他にもどれだけ優秀な人でも通知に気づけなければ対応ができません。
そういった社内の情報の偏りや体制を整備することもSTAGE 1には含まれています。
私の経験では例えば以下のようなものがあり、これは社内体制や事前の準備で全て解決する部分だと思っております。
1. インフラ担当しか認証情報の場所を知らず、そのインフラ担当が障害に気づいていない
翌朝までサーバダウンし続ける
2. エンジニアが全員外出中のため、PCがなくて障害対応できない
サーバ再起動するだけでいいのに、2時間程度放置される
3.エンジニアが障害の原因まで特定できているのに、ユーザーへの連絡方法を知らない
解消してるのにユーザーに通知ができず、まだ障害が起こっていると思われ続ける
4.障害報告のフォーマットを決めておらず、障害報告を1から書くので時間がかかる
ユーザーからの電話が殺到しコールセンターがパンクする
5. hacomonoの実績
私が入社し、慣れてきたタイミングでこの障害訓練を社内で提案をしました。
障害訓練というものを初めて聞く人が多いため、このブログに書かれているようなことを丁寧に説明することからはじめました。
hacomonoでは他の社員の方々に障害訓練の考えを受け入れてもらうことができ、実践を何度も行うことができました。
5.1. カスタマーサポートと障害訓練
私がまず障害訓練を行ったのはカスタマーサポートのチームでした。
イメージとしてはエンジニアが最初に実践するように思われていましたが、私はカスタマーサポートを一番に行いました。
それは緊急時にユーザーに対して障害報告を行うのはカスタマーサポートのチームだからです。
この報告速度が遅いのであれば、優秀なエンジニアが揃っていたとしても現在の状態をユーザーに報告することができないためです。
現状の弊社では自動的にユーザーに通知を行うようなシステムを導入していないため、障害時は人が手を動かすことを前提に障害対応は設計されております。
この障害訓練においては実際に障害は起こさずに、私が「障害が発生しました！」と連絡するだけで障害を再現できます。
このカスタマーサポートのチームにおいての実績としては、以下のようになります。
- Before: 1時間の訓練時間を設けたが、社内の障害報告フローが終わらなかった
- After: 障害報告フローを見直し、30分前後で終わるようになった
これは最初にお話させていただいた私のバックアップからの復旧問題と全く同じ問題だったのです。
障害報告フローを作ってあとはそれを実践すれば良いという考えでしたが、実際には1時間かけても終わらないような作業になっていました。
障害があって1時間何も報告がなければ、ユーザーは不安や不満を抱いてしまいます。
ネガティブな感情は印象に強く残りがちなので、できるだけ低減することは今後も継続していきたいと考えています。
5.2. エンジニアと障害訓練
エンジニアの障害訓練は主にSTAGE 2の原因の調査と解決能力が大きく求められてきます。
そのため、故意にサーバを破壊してそれを修復してもらいカスタマーサポートを通じて報告を行うというストーリーではじめました。
例えば以下のようなものになります。
1. 原因調査にすぐ入ってしまった
【カスタマーサポート】ユーザーに第一報を送るためにいつから障害が発生しているかを知りたい
【エンジニア】カスタマーサポートとのコミュニケーションが疎かになった
2. 求めている情報をスムーズにやり取りできない
【カスタマーサポート】障害の範囲、発生時刻、復旧見込みがほしい
【エンジニア】サーバ上で何が起こっているのか？を説明してしまう
3. ユーザーに説明できる言葉になっていない
【カスタマーサポート】ユーザーのわかる言葉に変換するコストが発生する、なんなら自分もよくわかっていないので不安
【エンジニア】エンジニアしかわからないような言葉で説明をしてしまう
そういった課題はありつつも一つずつ解決し、原因の調査と解決能力の向上も行うことができました。
これは一例ですが、突然ニュース等で取り上げられたようなことを障害訓練として行いました。
やっていること自体はただの負荷試験と同じような状況です。
今まではサーバのスケールアップ対応しかできないメンバーがいたのですが、今では全メンバーがスケールアウト対応をさせることができるようになりました。
6. 障害の日常化
ここまで色々障害訓練について説明させていただきましたが、最後に全てをひっくり返すような発言になりますが所詮は訓練です。
実際に障害が起こる時は毎回未知の出来事でどうやって対応するかはその場で判断することがたくさんあります。
そもそも障害が起こる箇所が明確にわかっているのであれば、障害が起こらないように日々改善を行っているため、常にぶっつけ本番のような状態にあります。
下手をすると二次災害まで起こしてしまいかねない状況です。
どんなベテランでも冷静な状態ではなく、必ず心が揺れた状態に陥ってしまいます。
また、訓練以上の成果を本番で出すことは難しいです。
いつ障害が来るのか？障害が来たらどのように対応すればいいのか？など心の準備ができている状態よりも早いタイムで障害を解決することはほぼ無理です。
自分達の障害対応能力を計測する意味でも障害訓練は役立ちます。
そんな状況を少しでも解消し、冷静に対応できるような状況を作り出したいと考えております。
そのためにできることは、「障害訓練を行い障害の日常化」をhacomonoでは推進しております。
7. 訓練の始め方がわからない人へ
hacomonoでは障害訓練についてあっさり理解していただくことができ、参加メンバーに対してしっかり説明さえすれば良いという形で始まりました。
ただ、多くの会社ではそれほど簡単に進まないというのは私も経験し、過去に何度も苦労しました。
物事を判断するにはデータがなければ採用されにくく、説得力のある説明ができないことが多々あります。
そのため、いきなり大きく始めるのではなく小さく始めるのがポイントです。
最初に「障害訓練とは？」の説明会を行い、実際にテスト環境でサーバを落として復旧作業をやってみると色々わかってきたりします。
例えばいつも障害対応をしてくれる人を訓練メンバーから外してみたりすると、誰も復旧できなかったり対応方法のドキュメントを探せなかったりします。
誰かに依存している状態である場合、その人が睡眠中は対応できなくなってしまうため「サービスダウンが8時間続いてしまう」というデータが取れます。
感覚ではなく事実を元に提案すると、提案された側も判断しやすくなります。
たくさんの資料を作って未来を予想した資料よりも、現在起こっている事実を数十秒で話す方が目的や課題が明確になっているので焦点を絞って話もできます。
最初の1回をどう説得するか？は各社で状況が違うため明確にお答えすることはできませんが、2時間程度あれば障害訓練の説明会と1回の小規模な障害訓練はできるかと思っています。
大きく動く前にまず最初の1回をどうやって始めるか？を検討してみましょう。
さいごに
私たちも日々、以下の課題に対する改善を進めておりますが、なかなか追いつかない現状があります。
- PdM、開発共に手が足りておらず、開発・フロー両面で細かい改善の方になかなか手が回せていない
- お客様に価値を素早く届けるためのデプロイ高速化
- 組織拡大に伴うコンテキスト境界の設計
もし、これらの課題解決にご興味お持ち頂けた方がいましたら是非ともお話させて頂ければと思います。
その他、課題・今後の取り組みをまとめた採用ウィッシュリストというものを作っていますので、こちらもぜひご覧ください。
