# オブザーバビリティを楽しくする: ゲームを活用してエンジニアのインシデント管理への自信を高めた方法

Site [llms.txt](/ja/llms.txt)

---

[Skyscanner](https://www.skyscanner.net) では、多くの組織と同様に、チームは個別の障害モードに対して特定のランブックに従う傾向があります。
現代の複雑な分散システムでは、エラーの大半が未知のものであるという欠点があり、ランブックは部分的にしか適用できません。

Skyscanner でテレメトリーデータを OpenTelemetry 標準に移行したことで、より豊富な計装が可能になり、オブザーバビリティに直接頼ることができるようになりました。
その結果、新しい[オブザーバビリティのマインドセット](https://charity.wtf/2019/09/20/love-and-alerting-in-the-time-of-cholera-and-observability/)を採用する準備が整いました。
これには、エンジニアが新しいエコシステムで効果的に作業できるようトレーニングすることが必要です。
これにより、エンジニアはプレッシャーの下でも、既知・未知を問わずあらゆる問題に効率的に対応できるようになります。

これを実現するために、知識を得る最良の方法は、ドキュメントや動画を一度見ることではないと私たちは考えています。
むしろ、これまでに見たことのない（あるいは少なくともめったに見ない）問題を含む実践的な演習を通じて学ぶことが効果的です。
これは、ファーストレスポンダーがインシデントを認知した時点から、ユーザーがインシデントの影響を受けなくなるまでの、問題緩和までの時間（TTM）を企業が短縮するのに役立ちます。

## 環境 {#environment}

まず、OpenTelemetry の計装とオブザーバビリティを使用したモニタリングとデバッグのベストプラクティスを示す環境をセットアップする必要があります。
そのために、公式の [OpenTelemetry Demo](/docs/demo/) を使用することを提案します。
これは Astronomy Shop と呼ばれる分散システムの現実的な例です。
[OpenTelemetry Protocol](/docs/specs/otlp/)（OTLP）のおかげで、Collector の標準 OTLP エクスポーターを、Skyscanner が選択したオブザーバビリティプラットフォームである [New Relic](https://newrelic.com/) に向けるだけで済みます。
New Relic は他のプラットフォームと同様に、テレメトリーデータを取り込むためにオープンスタンダードを全面的に採用しています。

このシステムにはプラットフォームに注入できるリグレッションが含まれており、Service Level Objective（SLO）、トレーシング、ログ、メトリクスなどの重要性を実証するのに役立ちます。
たとえば、下の画像に示すように、さまざまなコンポーネントを通過するトラフィックフローを観察できます。
OpenTelemetry エコシステムの一部はオープンソースであるため、OpenTelemetry のコントリビューターによってレビューされる新機能を簡単に導入できます。

![Astronomy Shop での分散トレーシングの例](tracing-example.png)

## オブザーバビリティゲームデー {#observability-game-day}

環境がセットアップされたら、オブザーバビリティゲームデーを導入できます。
これは、Google が使用し [Site Reliability Engineering book](https://sre.google/books/) で説明している Wheel of Misfortune プラクティスに基づいたイニシアチブです。

このゲームは本番インシデントをシミュレートします。
ゲームマスター（GM）と呼ばれるモデレーターがセッションを進行し、オーディエンスの誰かがホイールを回してインシデントまたは障害を説明します。
参加者はチームに分かれ、できるだけ早く問題を特定して解決する任務を与えられます。
解決策が最適でない場合、GM は新しいツールやビューを紹介して、インシデントへの別のアプローチを提供できます（ナレッジシェアリング）。
この演習は、異なるインシデントに対して複数回繰り返すことができます。

![Wheel of Misfortune の例](wheel.png)

## 結果 {#results}

オブザーバビリティゲームデーは、すでに Skyscanner の複数のチームで実施されており、各チームのオブザーバビリティエキスパート（アンバサダー）がセッションを運営しています。
参加者からは非常にポジティブなフィードバックが寄せられており、回答者の90%がゲームデー後に本番システムのデバッグに自信が持てるようになり、さらなるセッションを望んでいると回答しています。

- 実際のサービスに対して実行し、さまざまなデバッグ方法を比較対照できることは非常に価値がありました。
  スキルレベルに関係なく、全員がセッションから何かを得られたはずです。
  私自身も得るものがありました！
  セットアップしてくれて、そして私たちに広めてくれてありがとうございます。
  [Dominic Fraser](https://github.com/dominicfraser)（シニアソフトウェアエンジニア）
- オブザーバビリティと OpenTelemetry/New Relic のスキルアップのための、本当に素晴らしい（全社的な）イニシアチブです。
  個人的にもとても役に立ちましたし、すごく楽しかったです！
  :D - Polly Yankova（ソフトウェアエンジニア）

さらに、以下のことがわかりました。

1. OTLP により、標準的なアプリケーションをオブザーバビリティベンダーと統合することが驚くほど簡単になります。
   適切なエンドポイントに向けるだけで完了します。
2. 優勝チームは、リグレッションを分析するために主にトレーシングデータに頼っており、それが根本原因をより速く理解するのに役立ちました。
   トレーシング最高！
3. フロントエンドエンジニアは、ゲームデーがクライアントサイドのオブザーバビリティに焦点が当たっていないと感じたため、アップストリームに貢献することにしました（次のステップを参照）。
   これは私のプロジェクトへの初めてのコントリビューションで、素晴らしい経験でした！
   メンテナーはとても親切で、テストとリリースを手伝ってくれました。
   ありがとうございます！

## 次のステップ {#next-steps}

次のアクションは、社内のすべてのエンジニアリングチームでセッションを実施し、Skyscanner の学習コースに変換することです。
これにより、新しく入社したメンバーのオンボーディングプロセスでコンテンツを使用したり、長く在籍しているメンバーがリフレッシュとしていつでも復習したりできるようになります。
さらに、共通のフィードバックを観察した結果、ブラウザトラフィックによってトリガーされるインシデントなど、よりフロントエンドに特化したインシデントを含むように現在のインシデントを拡張することが有益であると判断しました。
これを実現するために、OpenTelemetry Demo に貢献し、他の関心のある方々にもこれらの機能を利用できるようにしました。
詳細については、[提出した PR](https://github.com/open-telemetry/opentelemetry-demo/pull/1345) をご覧ください。