Googleでもやっている障害対応訓練の「Wheel of Misfortune」をやってみた。

序文

こんにちは。MonotaROの伊藤です。

弊社では障害対応訓練の実施手法の一つであるWheel of Misfortune(略称:WoM)を実践しています。WoMの導入で、障害対応体制の強化を行うことができましたので、実施までの経緯や得られた学びなどを中心に紹介したいと思います

運用担当者の負荷が高まり続ける問題

運用担当者=社歴が長いベテランエンジニア

今までの運用担当者は、MonotaROでの在籍年数が長い経験豊富なベテランエンジニアが行ってきました。効果的なトラブル対応には、システムに関する経験とエンジニアとしての勘が有効だからです。下記でよくある障害対応のケースの一例をご紹介いたします。

  1. Slackのアラートチャンネルにエラー大量発生中という内容の通知が届きます。
  2. 担当者は該当箇所のエラーログを確認します。
  3. ログから原因を担当者は推測し、対応を実施します。
  4. 加えて原因が起きたコンポーネントから二次的に問題が起きていそうなシステムの調査を行い、対処を担当者は行います。

この挙げた例ではエラーログの確認だけを行っていますが、実際はDatadogなどのツールで監視している各システムのリソースのダッシュボードの確認であったり、BigQueryに挙げられているログの調査、Cactiのネットワーク監視ログの確認と状況に応じて様々な調査を行う必要がありました。 加えて、各コンポーネントが密に結合しているために一つのシステム障害が連鎖的に予想もしていない他のシステムに影響を与えている場合もあり、担当者はMonotaROのサービスを広く知っていないと問題の解消されたのか分からないといった問題もありました。

なので、運用担当者を増やすのが難しく、ベテランエンジニアの負荷が高まり続けるといった問題に運用チームは悩まされる事になったのです。

運用のスケールアウト

この問題の対策として以下の二つの手法を考え、実施しました。

  • 障害対応マニュアルの整備
  • 障害対応訓練の定期的な実施

障害対応マニュアルの整備では、アラートの仕組みについて改良を行い、調査を行わなくても障害の原因およびその場合の対応手法が分かるようにしました。 そしてその仕組みで本当に対応が可能なのかを障害対応訓練の実施を通じて検証を行おうとしたのです。

障害対応訓練をやってみよう

ここでいきなり躓いてしまいました。障害対応訓練の企画を最初に考えた時は、トラブルシナリオを用意し、実際に手を動かしてもらう想定で準備していました。ですが、準備を進める上で以下の二つの問題から、難しいと気付き、計画が止まってしまいました。

  1. 訓練が出来る環境を用意するのが大変だった。
  2. 訓練シナリオの準備が難しかった。

訓練環境の準備の問題

訓練計画を考える上で最も大きな課題は、訓練を実施してもらう環境を用意するのが大変だった事です。MonotaROの本番システムは各コンポーネントが密結合しています。なので、検証用として使い潰せる環境を用意する事自体が非常にコストがかかり、何度も実施する事は難しかったのです。 開発で使用されている環境や、リリース前の検証として使用されているステージング環境を使用する事も検討されましたが、これもまた困難である事が分かりました。破壊的な変更を行った場合にリリースフローに影響を与えてしまう事から実施の際には調整コストがかかることが問題でした。

訓練シナリオの問題

二つ目の問題として訓練のシナリオの準備が難しかった事があります。上記に記載している通り、MonotaROのシステムは各コンポーネントが密結合している状態です。なので、障害が起きた際は様々なコンポーネントに問題が連鎖的に波及していく可能性が高く、シナリオの考案者は全ての挙動について網羅的に理解している必要があり、これがシナリオの作成を困難としました。

外部からの助け

二つの問題により、完全に暗礁へと乗り上げてしまった障害対応訓練の実施計画なのですが、ここで一つの光明が外部からもたらされました。それがGoogle SRE Team & Policiesというセミナーです。このセミナーで教えて頂いた障害訓練手法の一つ、Wheel of Misfortune(以下はWoMと呼称)が私たちが困っていた問題を解決しました。

Wheel of Misfortuneとは

これは障害対応訓練の形式の中の一つです。過去の障害事例を元にシナリオを作成し、テーブルトークロールプレイングゲームのようにゲームマスターとプレイヤーが紙やドキュメントベースで会話をしながら、発生した障害の解決を目指すロールプレイを行うというものです。

(閑話となりますが、この語源はアメリカで人気だったクイズ番組のようです。 Wheel of Fortuneという名前のクイズ番組でクイズに回答し、ルーレットを回し賞金を得ていくというものです。 ですが、トラブル対応は幸運ではなく不運なので不運の輪となりました)

実施時の様子

以下のようなシナリオシートを共有し、訓練者の方のアクションに応じてその結果を追記していきました。

シナリオ開始時の様子

モニタリング画面の表示

WoMとDiRT(Disaster in Recovery Training)

なぜWoMという障害対応形式が私たちが抱えていた問題を解決したのかについて説明します。

Googleにおける障害対応訓練の手法は主に二つあり、最初の私達はDiRTと呼ばれる手法でこれを実施しようとしていました。DiRTは意図的にシステムに障害を起こし、対応者がいかに早く障害を復旧させる事が出来るかを学んで貰う訓練方式の事を指しています。 DiRTは対応者がシステムを操作し、障害を終息させるまでの過程を全て経験が出来るので効果的ですが、準備コストが高い為頻繁には実施する事が出来ません。

一方、WoMはシステムには対応者がコンソールを叩くなどといったシステムに触る事は基本的にしません。ほとんどが紙面上に記載されていく情報と口頭のみのやり取りで完結します。これにより、私たちが障害対応訓練で課題だと感じていた環境の準備の問題や複雑なシステムの挙動を全て網羅しなければ作成が出来ないシナリオのコントロール性などが解決されたのです。

Weathering the Unexpected - ACM Queue(DiRT論文)

障害対応訓練をやってみた結果

実際にWoM形式の障害対応訓練を行った結果、準備の段階で良い効果がありました。 これらについていくつかご紹介します。

準備時点で感じたメリット

手順書の不備を発見できたこと

シナリオを作成するだけで手順書の不備が多く見つかったのです。障害の対応手順書の多くはシステムについて習熟しているメンバーが作っており、暗黙の了解となってしまっていた確認項目や手順がありました。これにより、障害対応を手順書のみの知識で実施すると意図しない間違った操作や作業漏れが生まれてしまう事が分かりました。他に一度も発生していないが起こるかもしれないという事例で作成された対応パターンについて、作成から時間が経ってしまった事でマニュアル内のリンクが切れていたり、スクリーンショットで例示されたGUIでの操作画面のUIが大きく変更されていたりとマニュアルをそのまま実施する事が出来ない状態であった事も分かりました。

障害が起こりかねない場所を考えるきっかけになったこと

シナリオを考える事自体がトラブル防止となる事も分かりました。マニュアルどころか今まで考慮もされてこなかった、起きたら困るだろう障害をシナリオとして使う事が出来るため、それを考えるだけで既存システムにある潜在的なセキュリティリスクやパフォーマンスのボトルネックなどを見つけやすくなります。

(余談となりますが、WoMを教えて頂いたGoogleのSREエンジニア曰く、熟練のSREエンジニアは咄嗟にWoMを実施を依頼されてもその場ですぐに開始が出来るように複数のシナリオを常にストックとして頭の中に積んでいるそうです。この事は何時でもWoMが出来るという点でも良い事なのですが、これを行っている事により万が一に障害が起きても、色々なパターンについて想定が事前にされているために早くに動くことができます。)

やってみて良かったと感じたこと

準備の段階でも良い効果があったWoMですが、実際にやってみた事で得られたよかった事についていくつかご紹介いたします。

障害対応の体験が出来たこと

机上と口頭のみで実施する訓練なのですが、訓練者からは思っていた以上の臨場感があり本当に障害対応をしている気持ちになれたとのフィードバックを得ることができました。訓練者の方は一通り対応マニュアルを読んで頂いていたのですが、アラートからマニュアルを開いて対応をしていくという実作業の経験を積むことができていませんでした。ですが、今回の訓練により実際にどう動くべきなのかより強いイメージを得て頂く事ができ、障害対応の初動で困る事がなくなったという感想を頂きました。

対応マニュアルの読み方を学べたこと

各コンポーネントに対応マニュアルがありますが、このマニュアルには様々な障害パターンが記載されておりアラートからマニュアルに飛んでもどの対応を取るべきかは人間が調査し、判断する必要があるケースがあります。この切り分けについて模擬とはいえ、体験をして頂いた事で今後はよりスムーズに対応が出来るとのフィードバックを頂くことができました。

振り返りでマニュアルの改善を行えた事

訓練の実施後にはその振り返りを訓練者、ゲームマスター、観客が行います。この振り返りの場ではシナリオで発生した見落としや不明点について、どうすべきだったかが議論され、マニュアルの改善やアラートの仕組みの改善といった具体的なアクションまで落としこみます。このサイクルにより、マニュアル自体の改善が継続的に行われ続ける事が期待できます。

観戦者も障害対応について勉強ができたこと

この訓練では訓練者とゲームマスター以外に、対応を見て頂く観戦者の方も多くおり、この方々に障害対応がどのように行われているのか知る事ができ良かったとのフィードバックを頂きました。特に今後、開発者の方に開発をして貰ったシステムで障害が発生した場合のマニュアルの作成および障害対応自体の移譲を引き続き進めて頂く予定であり、それが実際にどのように活用されるのか体験して頂くことでより実戦的なマニュアル整備のきっかけとなる事も期待できます。

まとめ

今回は障害対応訓練の実施に至るまでの課題とその解消方法について紹介をしました。システム運用における課題として、スケールアウトしにくいという課題があります。特に密結合な複雑なシステムだと経験豊富かつ勘の鋭いエンジニアしか担当が出来ないという状態になりがちであり、新しい方に対応の経験を積んでもらう場もシステム構成上、用意しにくいといったケースが往々にしてあると思います。弊社の状況はまさしくそういうケースであり、これに対する解決策のひとつがWoMでした。

口頭と机上で全てが終わるために準備が容易かつ、実システムも用いない事から状況遷移のコントロールがやりやすいのがWoMです。DiRTよりも低コストで準備できる上、その実施によって得られるメリットは想像以上に大きいです。 運用担当者のトレーニング手法に困っていたら是非、一度実施を検討してみてはどうでしょうか?

モノタロウでは、このような運用の高度化に一緒に挑戦しSREの取り組みを進めていくメンバーを募集しています。年間2000億円の売上を上げる巨大ECサイトの開発・運用はチャレンジが多く刺激的です。

興味あるかも?という方は、是非カジュアル面談や選考へのご応募を検討いただければと思います! careers.monotaro.com

docs.google.com