SRE として Adversarial Game Day (敵性ゲームデイ) を行う方法

"火について学ぶ"、その最高のタイミングはまさに"火がついている"ときです。

—Jen Hammond、New Relicエンジニアリングマネージャー

この Blog Post は How to Run an Adversarial Game Day の意訳です。

数か月前、New Relicエンジニアリングチームの1つに属するCassandraデータベースノードが消滅しました、消えてしまったのです。当時、チームには3人の新しいメンバーがいましたが、Cassandraクラスターの管理に採用した手順書とAnsible Playbook は残念なことに両方とも古くなっていました。そのような状況でも、3人のメンバーはこのデータベースノードを支援なしで再起動しなければなりませんでした。何とか再起動は実行できましたが、その実行には30分以上かかりました。New Relicの顧客が特定のデータベースノード上のデータにアクセスできなかった時間が30分だったことを意味しています。

今述べた状況は実際に起きた事実ではありません！

冒頭から説明してきたCassandraノードの障害はシミュレーションであり、New Relicの Senior Site Reliability Engineer の David Copelandによって造られた用語である「Adversarial Game Day (敵性ゲームデイ)」の一部です。システムに故意に障害を発生させ、システムとそれを管理するチームがどのように回復を行えるかを確認するカオスエンジニアリング のサブセット、この考えかたはNew Relic SRE のベストプラクティスです。Adversarial Game Day は、悪意のある攻撃者（敵性）がシステムの非実動バージョンに障害を加えた場合、チームがその状況からどの程度回復できるかを確認するための日なのです。私たちの日常業務では通常、Game Day で行われるような状況には遭遇しにくいため、潜在的なリスクや問題を発見することができません。たとえば New Relicでの Adversarial Game Dayから発見できたことの一例は「デプロイの失敗に対するロールバックメカニズムがチームにない」といったことや、「機能横断型チームがトラブルシューティングのためにアクセスが必要なシステムにアクセスできない」等の緊急時の対応における潜在的な問題があるとわかりました。

私たちは Game Dayを行うことで「信頼性の実践力」を証明しようと常々試みています。現代のソフトウェアの世界では「障害は避けられない」ものです。たいていの場合、私たちはシステムの信じられないほどのアップタイムを想像し自己満足に陥ります。しかし冒頭の例で見たように、このような考え方は計画外のインシデントに対応する能力に深刻な影響を与える可能性があります。結局のところ、カオスエンジニアリングと Adversarial Game Day は、実行可能な計画と明確な方向感覚でカオスを管理することに他ならないのです。

それではまず、New Relicが Adversarial Game Day をどのように実行しているかについてご説明しましょう。

なぜ Game Day を行うのか？

SNAFUcatchers、Dr. Richrd Cookと呼ばれる研究者のグループによって書かれたSTELLAレポートの中で、エンジニアたちは、多くの場合、システムがどのように見えるかについては異なるメンタルモデルを持っています。

どういう意味でしょうか？まず実際に動作しているコードとそれが存在するリポジトリ、テストと検証スイート、生成するアーティファクト、およびそれらのアーティファクトが実行されるシステムがあることを想像してください。これらのすべては、デプロイツール、オブザーバビリティツール、およびUIとCLIで構成されるツール群の下にあります。人間はシステムと直接やり取りするのではなく、これらのツールの表現とやり取りしているのです。システムに関する情報をこれらの「ツールが表現する情報」から得ているのです。実際にコードが動作していることを「見る」ことはなく、間接的な表現を介しているのです。そして、各チームメンバーはそれらの情報表現から異なる理解を行います。

これはプラトンの「洞窟の比喩」 の話に似ています。この比喩では「囚人は生まれた時から洞窟に鎖でつながれ、目の前の壁だけを見ることができる状態にい続けている場合、囚人は壁に映る影が真実だと知覚します。しかし彼らが鎖から解放され洞窟から追い出されても、今までに見たことがない洞窟の外にある自然界の太陽や光を見て適切に合理化し理解することができません。」という意味をさしています。これと同様に、エンジニアがラップトップモニターで実行されているツールに名前を付けてそれを真実だと思い続けている場合、それを現実と理解してしまいます。システムの信頼性がどこにあるのかを把握していない場合、危険を冒してすら現実を無視するでしょう。

Game Day はいつ行うべきか？

少なくとも、システムがサービスレベル目標（SLO）を上回っている場合は、四半期ごとに1日は Game Dayを実行する必要があります。顧客とのサービスレベル契約（SLA）を定量化するパフォーマンスメトリック（応答時間、スループット、可用性など）が四半期に設定した目標を超えている場合でも、1日は Game Day を実行する必要があります。回復力をテストせずに、あまりにも頻繁により多くの依存関係を高性能なサービスにロードすると、それらの依存関係がインシデント発生時にドミノのように転がり止まらなくなるからです。

例えば他には、新しいチームメンバーがオンボーディングする日などは、Game Day を開催するための素晴らしい口実になります。 New Relic で、私たちはしばしば新しいチームメンバーのために Adversarial Game Day を開催します。この演習はシステムの知識を試すだけでなく、New Relic SRE のインシデント対応プロセス に親しんでもらうための機会でもあるのです。

また、ユーザーに新機能をリリースする前に Adversarial Game Day を開催するべきでしょう。この演習がないと、顧客がどのtripwire (HIDS) にヒットするかはわかりません。「堅実な」製品をお持ちの場合、普通の Game Day はかなり退屈かもしれませんが、オンコールエンジニアはリリース後の夜も楽に眠ることができるようになります。また、新機能で何か問題が発生した場合に備えて、緊急事態に対処するための準備も整えることができます。

誰が Adversary (敵)を演じるべき？

敵は重要な役割であり、通常、攻撃対象となるシステムの最も完全なメンタルモデルを持つ人物が果たすべきです。これは「バス因子」をテストする優れた方法でもあります。ある特定の人物がバス (車両) の事故で不在となった場合に、その人物しか知り得ない業務があると、業務全体にどのような影響を及ぼすか、という考え方です。チームの残りのメンバーは、現実の事件にどのように対応できるでしょうか？

敵対計画を作成する際、前四半期のインシデントを考慮します。その全四半期のインシデントの根本的な問題を実際に修正した経験はありますか？インシデントは、システムのメンタルモデルを改善または悪化させましたか？インシデントを再現することは、チームのメンタルモデルがシステムの現実を実際に反映していることを確認する良い方法です。

システムについて5分以内に回答できる質問の範疇は、Adversarial Game Day の適切な目標にはなりません。Game Day は、チームの集合的な知識から何が欠けているのかを発見することです。あなたのチームがあなたのシステムについて知らないことを明らかにしたい。それを念頭に置いて、New Relicでの Game Day は最大で3時間実行しています。

誰が Game Day に参加すべき？

New Relic では新機能のリリースを見越して Game Dayを最後に実施したとき、他のチームのインシデント管理の練習もしたかったので、2つのエンジニアリングチームを Game Day の参加チームに含めました。

Game Day において私はチームを混合して「対応チーム」と「敵チーム」を作成しました。敵は新機能に攻撃を投げかけます。ゲームが進むにつれて、対応チームはアラートベストプラクティスを使用していたにも関わらず、通知を送信できていないアラートがあることを発見しました。この機能を設計したチームは、アラート設計に何らかの間違いを犯したことに気付きました。彼らは絵コンテに戻り、アラートを修正し、その後アラートが予想どおりに動作するか確認する別の Game Day を行いました。

Adversarial Game Day に参加するのはとても楽しいことですが、地理的な要因を排除しないでください。計画外のインシデントが発生した場合、必ずしもメンバーが同じ部屋にいるとは限らないので、リモートの参加者がいるという前提に立つのは素晴らしい考えです。事実、リモートの参加者を含めると実際のインシデントで使用するコミュニケーションツールをテストするのにも役立ちます。

Game Day 当日は、他のチームにとって意図しない結果になる可能性があるため、事前に試合日を共有するようにしてください。実際にダウンストリームサービスがお客様のサービスに依存しているチームは、システムがアップストリームダウンタイムに対して回復力があるかどうか、またはアラートが適切に構成されているかどうかを確認する良い機会であることがわかります。

本番環境で Game Day をするのはやめましょう

理想的には Game Day を本番働環境で実行したいものです。ただし、ユーザーをつまずかせる可能性のある障害をシステムに導入できない場合があります。サービスレベルのインジケータ（SLIS）またはエラーバジェット、そしてあなたの稼働時間は、Game Day をサポートできるかどうかわかりません。開発環境またはステージング環境を使用するか、サンドボックスでシステムのバージョンをスピンアップします。重要なことは、ユーザーが日々経験することを厳密に模倣できるバージョンのシステムでゲームを実行することです。Adversarial Game Day の目標は、システムのメンタルモデルを改善して、平均解決時間（MTTR）を改善することです。

使用するツールは？

システムに障害を挿入するために使用できる巧妙なツールは多数ありますが、場合によってはシンプルであることが最適です。アーキテクチャ図を見て、何が間違っているのかを尋ねます。あなたの顧客はあなたのシステムについてどんな間違った仮定をすることができますか？悪意のある攻撃者は何ができますか？それらの答えを理解し、その動作をエミュレートする単純なbashスクリプトを作成します。

New Relic ではToxiproxyやオープンソースツールShopifyが好まれています。Toxiproxyを使用すると、プロキシとクライアントを介した相互依存サービス間のネットワーク接続を「改ざん」できます。たとえば、最近では Game Day でAPIをテストするために、Toxiproxyを使用してAPIサービスとデータベース間の接続を切断しました。これを行うと、APIはデータベースのIPアドレスを含むエラーメッセージで応答しました。これは興味深いものですが、顧客に見せたいものではありません。

Game Day に採用できるツールはたくさんあります。参考までに GitHubのカオスエンジニアリングリソースのキュレーションリストをご覧ください。

実際のインシデントのようにGame Day を実行しましょう

現実世界の計画外の出来事のように Game Day を実行してください。スクライブを割り当てて、トラブルシューティングのソフトスポットと監視とアラートのギャップについてメモを取ります。顧客サポート担当者を招待して、顧客への影響の可能性を説明できるようにします。システムのチームのメンタルモデルをテストしている場合もありますが、システム障害が顧客に与える影響を理解する必要があります。

Game Day から48時間以内に、"非難なしのふりかえり"を開催してたくさんの質問をしてください。例えば：

• 何がより良くなったでしょうか？チームは何を学びましたか？システムのメンタルモデルは改善されましたか？
• 監視と警告は計画どおりに機能しましたか？
• あなたのMTTRは何でしたか？今後改善できますか？
• チームでRunbookを自動化して、被害緩和を迅速化できますか？
• アーキテクチャ図を更新する必要がありますか？
• 依存チームのアラートと監視は機能しましたか？
• これらの依存サービス間の関係をリファクタリングする必要がありますか？

得られた洞察から、システムの復元力を向上させるための作業を割り当てていきましょう。

学んだことを共有する

最後に学んだことを共有します。うまくいけば、あなたは他のチームに Adversarial Game Day を開催するよう促します。

これらすべてのアドバイスはさておき、 Adversarial Game Day の実施において 100% 正しい方法はありません。また、テストするものに関してチームごとに異なるニーズがあります。Adversarial Game Day を実施して、SRE チームを「洞窟の比喩」にいる状態から追い出しましょう。システムの完全で統一された視点を得るのは難しいかもしれませんが、Game Day は真実を明らかにするための最良の方法です。

SRE チームで Game Day を開催してみたいかたは New Relic までご相談ください。