SRE事例 システムトラブル発生時の対応訓練（ディザスタリカバリトレーニング）の紹介

こんにちは、Yahoo!ショッピングでシステム開発/運用を担当している村上です。
Yahoo!ショッピングではシステム運用を担当するエンジニアが在籍しています。
今回はシステムトラブル発生に対する対処法を実践的に共有する方法を紹介いたします。

SRE（サイト・リライアビリティ・エンジニアリング）とは

本題に入る前に、今回の取り組みの土台となったSREの取り組みについて紹介いたします。

SREとはシステム運用における非機能要件の達成や、手動運用タスクなどの課題に対してソフトウェアや自動化のアプローチで改善を図るエンジニアリング手法のことです。
Yahoo!ショッピングでも取り入れられはじめており、今年の4月よりSRE専門のチームが立ち上がっています。

今回はYahoo!ショッピングのSREチームの中で話題に上がったオンコール運用の改善のためのアイデアの紹介です。

背景

私が所属するチームでは以下のようなフローのオンコール体制を敷いています。
定型化が可能なアラート対応作業は監視チームが実施しますが、手順に例外が発生した場合はサービスのオンコール担当者にエスカレーションされます。

そのような中で、チームに以下の課題が発生していました。

• 運用の経験値に差があり、経験の浅い対応者では処置対応をしきれない事が多い。（高い確率で別のオンコール担当者にヘルプを求める必要がある）
• 新しく参画したメンバーは、おおむねの対応方針がわかっていたとしても、自身の判断に不安に感じることが多く対応が遅れてしまう。

通常、新規で参入したオンコール担当者は、トラブル発生時の対応をペアで行うことなどで少しずつ知見を深めていきます。

しかし、経験値を積むためのトラブルが発生しない場合はどうでしょうか？
もちろんトラブルが発生しないこと自体は望ましいことですが、実際にトラブルが発生した時に対応しきれない状況は、望ましくありません。

上記の問題を解決するために、何らかの手段でオンコール対応の経験値を高める必要があると感じていました。

オンコール対応力を向上させるために

オンコール対応のトレーニングについて何か有用な手段を探していたところ、書籍「SRE サイトリライアビリティエンジニアリング　――Googleの信頼性を支えるエンジニアリングチーム（Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy　編、澤田 武男、関根 達夫、細川 一茂、矢吹 大輔　監訳、Sky株式会社 玉川 竜司　訳）」の「28.4.2 ディザスタロールプレイング (p.422)」で以下のように紹介されているアクティビティが目に止まりました。

私たちが週に1回行うミーティングでは、犠牲者を1人選び、グループの前に出てもらいます。そしてシナリオが犠牲者に渡されます。多くの場合、このシナリオはGoogleの過去の歴史の中で実際に起きたことです。私はこの犠牲者のことをゲーム番組への出場者のようなものと考えていますが、このゲーム番組の司会者に対して犠牲者は問題を理解したり解決したりするために何をするか、あるいはどういった質問をするかを話し、司会者は犠牲者にそれぞれの行動や観察の結果何が起こるのかを話します。

つまり、あらかじめシナリオを用意しておき、過去に起きたシステムトラブルとその対応を追体験するゲームのようです。
これならシステムトラブルの発生を待たず、オンコール対応の経験値を上げる手段として有用に働いてくれると考えました。

ただ、こちらの取り組みをチームに取り入れてロールプレイを実践すると、本番のオンコール対応に十分に対応できるようになるのでしょうか？
その回答について、SREサイトリライアビリティエンジニアリングの「28.4.3 本物の破壊と修復 （p.423）」にて、以下のように語られていました。

ディザスタロールプレイングは、新人がこの道に没頭するための役に立ちます。とはいえ、本物のプロダクションシステムを実際に壊したり直したりすることで得られる経験はそれらに勝ります。

やはり実際にシステムを壊して復旧してみるのが一番勉強になるようです。さすがにプロダクションを壊すわけにはいかないため、別の環境を用意しました。システムが動いている環境でディザスタロールプレイングを実施することをここでは「ディザスタリカバリトレーニング」と呼び、こちらを実践してみることにしました。

準備

再現したいディザスタシナリオのたたきを作成

以下のように企画立案を行いました。

• 過去に起きた問題を整理
• チームリーダーや経験値の高い運用担当者に対して、問題のメカニズムや重要度をヒアリング
• 取り扱う問題を選択し、当日のシナリオを考える

リーダーと内容の合意

今回は以下のシナリオを取り扱うことで合意しました。

• データ不整合発生によるシステム連携停止トラブルの再現 （2種類）
• サーバーのセットアップ不良による画面表示の不具合トラブルの再現 （2種類）

トレーニング内の役割分担を定義

今回のトレーニングでは、以下の2つの役割を定義しました。

• ゲームマスター（GM）

  • ゲームのルール説明、進行、完了後の答え合わせ
  • ディザスタシナリオの仕掛けの起動
  • 参加者からの問い合わせ回答

• 参加者

  • 発生したシステムトラブルに対してオンコール担当として解決

環境準備

3日ほどかけて、以下の準備を行いました。

• システムトラブルのシナリオを再現するための環境を準備

  • 今回はdevelopセグメントと呼ばれる、本番環境から隔絶された環境でセットアップを行いました。

• トラブルを発生させるためのスクリプトの作成

  • シナリオの数だけ用意しました。例えば以下のようなものになります。

# わざと共有ストレージを外してシステムが正常に稼働しなくさせる
sudo umount -f /external_storage1

# ストレージが外れたままアプリケーションが一度動くと発生するデータベース不整合状態を再現する
mysql -udebug_user -e"UPDATE system.process_lock SET status='1' WHERE process_id='0001' LIMIT 1;"

• お客様からトラブル発生の申告を受けた際の台本の作成

  • 過去のインシデントチケットより流用しました。
  • 当日の緊張感を演出するために、なるべくリアルさを追い求めます。

• 当日、トレーニング参加者がコミュニケーションを行うための環境を用意

  • 今回は専用のSlackチャンネルとZoomのミーティングルームを用意しました。
  • 実際のエスカレーションでは社内の問い合わせ管理システムによるチケットが発行されますが、今回は省略しました。

• トレーニングのルールやタイムスケジュールを書いた説明書を用意

  • 今回は以下のルールと1時間の制限時間を設けました。

＜ルール＞

• 参加者は全員で1つのチームとしてSlackとZoomで連携して対応していただきます。
• チームはゲームマスターから連携されるエスカレーション内容を確認し、システムを復旧していく必要があります。
• 社内の手順書や技術文書のほか、ログやデータベースの調査、インターネット検索など何でも参照できます。
• エスカレーション内容に記載された情報が不足している場合があります。その場合、ゲームマスターに問い合わせてください。
• 今回対応する環境Devセグメントですが、Productionセグメントと同等に扱い、慎重に作業を行ってください。

開催

招集

• 以下のタイムスケジュールで進行しました。
  • ルール説明 / 環境説明 （10分）
  • ディザスタリカバリトレーニング （60分）
  • フィードバック （10分）
  • Q＆A （10分）

ゲームマスターとしての動き

以下の順番でどんどん仕掛けを発生させていきました。

1. 参加者がサーバーにログインし、なじんだ様子を確認
2. 仕掛け用のスクリプトと問い合わせ内容を発行
   • 参加者が対応に着手する様子を眺めつつ、参加者とQ＆A対応を通してコミュニケーションを取る
   • 1つ目の問題が収束するまで待つ （対応に慣れてもらう）
3. 10分くらい経過してから、次の仕掛けを発生させ、同時多発的にトラブルが発生する状況を作る
4. Q＆A対応を続け、様子を見ながら次の仕掛けを引き起こす （以下時間制限ギリギリまでループ）

参加者の様子

今回は5名の参加者が集まりました。
対象サービスを担当してから半年〜2年ほどのメンバーが参加しており、システムトラブルの対応経験もややばらつきがある状況です。

1. 1つ目のトラブル

   • こちらはデータベース上のデータ不整合に関する出題です。難易度が低かったこともあり、社内のアラート対応履歴を確認しながら落ち着いて対応をしていました。
     問い合わせ内容に記載されていた情報では不足していたことも把握し、うまくコミュニケーションが取れていました。

2. 2つ目のトラブル

   • 今回も同じくデータベース上のデータ不整合に関する出題です。少し難易度を上げたところ、対応に時間がかかっていました。〜ここからオンコール担当者同士の調査結果などが大量に書き込まれて原因究明の試行錯誤が始まる〜

3. 3つ目のトラブル

   • サーバーのミドルウェア不良によるもので、原因究明の難易度も高いものを用意しました。
     さらに2つ目の仕掛けも同時に発生していることから、誰が何の対応をするかでかなり混乱をしていたようです。
     少したってから対応チームを分けて対応をして作業効率がアップしました。〜ここでもオンコール担当者同士の調査結果などが大量に書き込まれていく〜このように2つ目と、3つ目のトラブルにそれぞれ同時に全員で対応していました。しかし、大量行の調査結果やコミュニケーションログが1つのチャンネルに乱立し、どれが何の対応に関するやりとりなのか交錯している状況になりました。
     • （しばらくしてから）その後、情報が交錯している状況を確認しあい、問題ごとの分担がなされました。

学び

参加者が感じた「やってよかった」なこと

以下の良い点がありました。

• トラブル対応手順書のインプットを楽しく行えた。
• 時間制限や本番環境同等の扱いをしなければいけない制限により、本当にトラブルが発生している時のような緊張感があった。
• 上記の緊張感の中で、実際に発生しそうなオペレーションミスが再現でき、参加者の学びになった。
• 手順書に書いてある内容の意味を吟味することで、手順化されていない対応内容を明らかにして、文書をブラッシュアップすることにつながった。

後日、実際のアラートが来た時に以前よりも積極的に対応に乗り出せる人が増えました。
同種のアラートでなくても実際にアラート対応と称してサーバー上でいろいろな調査や操作をしてみたこと自体が担当者の糧になったようでした。

また、実際にアラート対応をしてみると既存の知見のありがたみをじかに感じられます。
そこで、アラート手順書をもっとブラッシュアップしなければいけない。という気運が高まり、一部のメンバーのみで運用されていたアラート対応手順書に対して新しいメンバーがコントリビュートしようとする動きも見られました。

ゲームマスターから見た参加者の様子と改善できそうなこと

参加者の皆さんはそれぞれ自身の知見を生かして対応にあたっていました。
問題の本質に至るまでのアプローチが人によって結構異なるところがよく見えました。

• 過去の類似の対応チケットをひたすら掘り下げる
• 目を皿のようにしてアプリログを凝視してヒントや法則性を掴み取ろうとする
• 他の人が対応している内容に加勢して取り組みを加速させようとする

どれも少しずつ状況を好転させる手助けになっていたようですが、以下のような役割があるともっとうまく動けたように感じました。

• コミュニケーションの窓口を作る
• 全体の状況を監督する人がいる
  • 時間で区切って逐次現在の状況を取りまとめる
  • 必要に応じて、並列で対応するためにチームを分割する
• チームを分割した際にコミュニケーションのフィールドも分割するべき
  • 対応チャンネルを分けるほどでもなければスレッドを切ってやりとりを重ねる
  • 音声コミュニケーションでは、Zoomのブレイクアウトルームなどを立てて情報が交錯しないようにする

開催にあたって改善できそうなこと

実際にトレーニングを開催してみたところ、さまざまな良かったことや気付きが浮かび上がってきましたが、開催するまでの準備に手間がかかったことも事実です。
そこで、開催のハードルを下げるために工夫できたことも紹介します。

• 既存の統合開発環境を利用すればよかった
  • Yahoo!ショッピングでは組織を横断した統合開発環境が存在しています。その環境を時間を決めて借りることができれば、環境セットアップの工程を省略できたかもしれません。
• 過去のインシデント対応の中で後世に残したい事例をまとめておく
  • 十数年に渡ってサービスが運用されているため、過去にさまざまな出来事がありました。その中で今のメンバーに追体験させたい事例はどれなのか？　という優先順位付けが少々大変でした。日頃より「これは知見だね」と思った事例や、対応チケットをまとめておくとこういった取り組みをする際に非常に役立つと思います。
• 出題をメニュー化
  • 今回は初の開催でしたので、全て1から準備しての対応でした。しかし、何度か会を重ねて出題内容 （セットアップ手順、シナリオ、スクリプト含む） をメニュー化すれば、次回からはコスト低く開催できるかと思いました。

今後の展望

参加者からのフィードバックで、非常に楽しかったという声が多く上がりました。
新規参入者への業務知識のINPUTは時間がかかるものですが、このような取り組みで効率よくINPUTが行えると感じました。

また、発生自体が稀なトラブルに対して経験値を積む手段としても良いと感じました。
組織を横断した大きなトラブルのシナリオを追体験する場として活用することも期待しています。

以上、ディザスタリカバリトレーニングの紹介でした。
意外と小さな単位からでも始められるため、ぜひ実践していただけるとうれしいです。

（この記事に関連する採用情報「サービス・プラットフォーム開発エンジニア」もぜひご覧ください）