回復力のあるシステムの構築：インターコムでの可観測性への道のり
公開: 2022-07-14インターコムでは、何よりも顧客体験に重点を置いています。サービスの可用性とパフォーマンスが最優先事項です。 それには、チームとシステム全体での可観測性の強い文化が必要です。
その結果、アプリケーションの信頼性に多くの投資を行っています。 しかし、予測できない障害は避けられません。障害が発生した場合、それを修正するのは人間です。
私たちは社会技術システムを運用しており、逆境に直面したときに回復する能力をレジリエンスと呼びます。 レジリエンスの重要な要素の1つは、可観測性です。これは、人間が実行しているシステムの内部を「見る」ことができるようにするための手順です。
この投稿では、可観測性のより強力な文化を構築するための道と、その過程で学んだ教訓を探ります。
インターコムでの可観測性とはどういう意味ですか？
インターコムでは、学ぶために出荷します。 私たちの本番環境は、コード、インフラストラクチャ、サードパーティの依存関係、およびお客様が集まって客観的な現実を作り出す場所です。これは、私たちの仕事の影響を学び、検証する唯一の場所です。 可観測性とは、人間が生産について質問し、答えを得る継続的なプロセスと定義しています*。
それをもう少し分解しましょう：
- 継続的なプロセス：成功した可観測性とは、人々が可能な限り頻繁に観察することを意味します。
- 制作に関する質問：私たちは、私たちの定義が広く、一般的であり、私たちが提供するワークフローの広い範囲を代表するものであることを望んでいました。
- 回答*：アスタリスクに注意してください。 あなたに答えを与えるツールはありません。本当の答えを見つけるためにあなたがたどることができるリードを提供するだけです。 あなたはあなた自身のメンタルモデルとあなたが実行しているシステムの理解を使わなければなりません。
ステージ1：問題と解決策
可観測性の独自の定義を武器に、既存の慣行を評価し、問題ステートメントを作成しました。 最近まで、私たちの可観測性ツールは主にメトリックに基づいていました。 典型的なワークフローでは、さまざまな属性の組み合わせによってスライスおよびダイシングされたメトリックを含むグラフでいっぱいのダッシュボードを確認しました。 人々は相関関係を探しますが、多くの場合、洞察を満たさずに去ります。
「メトリクスは簡単に追加して理解できますが、カーディナリティの高い属性（顧客IDなど）が欠落しているため、調査を完了するのが困難です。」
指標は簡単に追加して理解できますが、カーディナリティの高い属性（顧客IDなど）が欠落しているため、調査を完了するのが困難です。 以前は、少数の可観測性チャンピオンが二次ツール（ログ、例外など）を使用してワークフローを継続し、カーディナリティの高い情報にアクセスして全体像を構築しようとしていました。 そのスキルには絶え間ない練習が必要でした。製品の提供に忙しい製品エンジニアの大多数に非現実的な質問をします。
この統合された可観測性の経験の欠如を、解決すべき問題として特定しました。 切断された、セットアップが不十分な、高価なツールのセットを習得しなくても、誰でも簡単に本番環境について任意の質問をしたり、洞察を得たりできるようにしたかったのです。 この問題を軽減するために、テレメトリのトレースを2倍にすることにしました。
トレースを2倍にする前に使用した典型的な運用ダッシュボード
なぜトレースするのですか？
可観測性ツールは、背後に人間がいるツールにすぎません。人間には、優れた視覚化が必要です。 どの種類のデータが視覚化を強化するかは問題ではありません。ツールを使用すると、さまざまな視覚化をシームレスに切り替えて、問題に関する別の視点を得ることができます。
トレースには、他のテレメトリデータに比べて大きな利点があります。トレースは、トランザクションに関する十分な情報をエンコードして、事実上すべての視覚化を強化します。 トレースの上に可観測性ワークフローを構築することで、基盤となるデータやツールを切り替えることなく、スムーズな統合エクスペリエンスが保証されます。
トレースを利用できる視覚化の種類の一部
ステージ2：トレースの実装
インターコムでは、小規模から始めて、成功がどのように見えるかを決定し、その過程で進捗状況を監視します。 私たちの主な目的は、トレースによって可観測性ワークフローがより効率的になることを確認することでした。 そのためには、できるだけ早くエンジニアの手に痕跡を残す必要がありました。
「アプリケーションを最初からトレースでインストルメント化する代わりに、すでに依存関係にある既存のトレースライブラリを使用しました」
時間を節約するために、概念実証には既存のベンダーであるHoneycombを使用しました。 過去に構造化されたイベントにツールを使用している間、私たちはすでに彼らと素晴らしい関係を築いてきました。
アプリケーションを最初からトレースでインストルメント化する代わりに、すでに依存関係にある既存のトレースライブラリを使用し、トレースデータをHoneycombネイティブ形式に変換するための小さな調整を実行しました。 単純な決定論的サンプリングから始め、処理したすべてのトランザクションの約1％を保持しました。
チームメイトがトレースを採用できるようにする
組織を痕跡にシフトすることは簡単なことではありません。 トレースはメトリックやログよりも複雑で、学習曲線が急になります。 インストルメンテーション、データパイプライン、およびツールはすべて重要ですが、最大の課題は、チームメートがトレースを最大限に活用できるようにすることです。 概念実証が本番環境で実行されると、私たちはすぐに可観測性の文化の構築に焦点を合わせ始めました。
「エンジニアだけに焦点を当てたわけではありません。ディレクター、技術プログラムマネージャー、セキュリティチームのメンバー、カスタマーサポートの担当者と話をして、トレースが特定の問題の解決にどのように役立つかを強調しました。」
味方を見つけることが成功の鍵でした。 すでに可観測性に長けているチャンピオンのグループを集めました。 彼らは私たちの仮定を確認し、チーム内の痕跡についての情報を広めるのに役立ちました。 ただし、エンジニアだけに焦点を当てたわけではありません。ディレクター、技術プログラムマネージャー、セキュリティチームのメンバー、カスタマーサポートの担当者と話をして、トレースが特定の問題の解決にどのように役立つかを強調しました。
私たちのメッセージを調整することは、サポートを固定するのに役立ちました。 新しいツールの導入には常に一定のリスクが伴います。可能性を示し、人々を興奮させることで、成功の可能性を高めました。
ステージ3：適切なベンダーを決定する
イネーブルメントプログラムが開始されると、最新のトレース中心のベンダーを検討し始め、潜在的な候補を評価するための一連の基準を策定しました。
ワークフロー：探索的ワークフローが最も重要であると特定しました。これにより、エンジニアは生産データを任意にスライスおよびダイシングし、視覚化と高カーディナリティ属性を介して洞察を得ることができます。 問題を診断することの大部分はそれを見つけることができることであり、それは「正常」がどのように見えるかを理解することを意味します。 問題が発生したときだけでなく、できるだけ頻繁に質問することで、エンジニアが生産を簡単に探索できるようにしたかったのです。
「データのサンプリングと保持の方法を完全に制御したかったのです」
サンプリングと保持の制御：データのサンプリングと保持の方法を完全に制御する必要がありました。 決定論的サンプリングは、迅速に立ち上げて実行するのに役立ちましたが、契約制限を下回っている間、スマート動的サンプリングを使用して、より選択的で、より多くの「興味深い」トレース（エラー、遅い要求など）を保持したいと考えました。
正確なデータの視覚化：どのサンプリング手法を使用する場合でも、視覚化で「真の」近似値を公開することにより、可観測性ツールが透過的に処理できるようにしたかったのです。 ベンダーごとにこの問題へのアプローチは異なります。エラー率やボリュームなどの主要なインジケーターのメトリックを推測するために、すべてのデータをグローバルアグリゲーターに送信する必要があるベンダーもあります。豊富なインストルメンテーションによって生成される大量のデータを考えると、これはオプションではありませんでした。
価格設定：ツールから得られる価値と相関する、シンプルで予測可能な価格設定スキーマが必要でした。 保持および公開されたデータの量に対する課金は公正であるように思われました。
エンゲージメントメトリクス：ベンダーが優れたパートナーであり、主要な使用メトリクスとエンゲージメントのレベルを公開することで、ツールの採用と有効性を追跡できるようにしたいと考えました。
完璧なベンダーは存在しないので、妥協する準備をしてください。 最終的に、Honeycombは、特定したメインワークフローに適しているだけでなく、サンプリング、価格設定、使用状況の指標のチェックボックスをオンにしたため、コストのかかるベンダーの移行を回避できたと結論付けました。
困難な1年間の作業の後、可観測性プログラムの技術的な部分を完了しました。 これが私たちが達成したことです。
- 私たちのメインのモノリスアプリケーションは、高品質の属性が豊富なトレースで自動計測されていました。
- エンジニアは、コードにカスタムインストルメンテーションを追加するための便利なメソッドの小さなセットを持っていました。
- Honeycomb Refineryを導入して、データを動的にサンプリングし、より多くの「興味深い」トレースを保持しました。 エンジニアには、よりきめ細かい制御のためにカスタム保持ルールを構成することをお勧めします。 最も価値のある取引のために、そして経済的に実行可能な場合、私たちは人々に必要なデータを提供するために100％の保持を提供しました。
ステージ4：採用の増加
Honeycombにコミットし、データパイプラインの作業を完了した後、焦点を有効化に戻しました。 可観測性の文化を構築するには、人々が簡単に乗り込めるようにする必要があります。 チームが新しい可観測性ツールを採用するのを支援した方法のいくつかを次に示します。
開発環境でのトレース
エンジニアがインストルメンテーションのトレースに慣れ、コードに追加するように促すために、Honeycombで公開されたトレースを使用して、ローカル開発環境からのオプションのトレースを提供しました。 これは、コードが本番環境に到達したときに表示されるのとまったく同じ方法で、新しいカスタムインストルメンテーションを視覚化するのに役立ちました。
ログは読み取りと解釈が難しい場合がありますが、トレースビューははるかに構造化され、整理されています
Slackbotクエリのショートカット
制作に問題がある場合、最後に必要なのは、適切なクエリをスクランブルすることです。 「Webパフォーマンスを表示」メッセージにカスタムボットリアクションを追加しました。 Slackbotリンクをたどると、サービスごとに分類されたWebエンドポイントのパフォーマンスが開きます。
可観測性ツール内で人気のあるクエリへのショートカットを提供するSlackbotを使用して、可観測性ワークフローを合理化します。
ステージ5：考察と次のステップ
採用の測定
可観測性ツールの投資収益率（ROI）を測定することは困難です。 アクティブユーザーの数を追跡することは、エンジニアがツールを使用する頻度の良い指標であり、Honeycombの使用状況メトリックから多くの恩恵を受けました。
このグラフは、可観測性の有効化が開始されてからのアクティブなHoneycombユーザーの数の増加を示しています
さらに進んで、これらのエンゲージメントの有用性を測定しました。 可観測性ツールから得られた洞察が貴重である場合、人々はそれらを仲間と共有すると仮定しました。 私たちのエンジニアリングワークフローはGithubの問題に大きく依存しているため、Honeycombが言及またはリンクされている問題（トレース、クエリ結果など）の数を採用指標のプロキシとしてカウントすることにしました。 2021年の終わりに向けて有効化を倍増すると、Honeycombに言及する問題の数が急増し、正しい方向に進んでいることが証明されました。
タイトルまたは説明にHoneycombが記載されているGitHubの問題の数を示す棒グラフ
予期しないワークフロー
強固な可観測性基盤を構築することで、これまで想像もできなかったワークフローが可能になりました。 これが私たちのお気に入りのいくつかです：
コストプログラムへの通知：すべてのトラフィックをトレースし、SQLクエリ、Elasticsearchリクエストなどのスパンがあるため、インフラストラクチャの個別の共有部分（データベースクラスターなど）の使用率の急上昇を調査し、それらを単一の顧客に帰することができます。 このデータを個々のインフラストラクチャコンポーネントのコストと照合することで、提供するすべてのトランザクションに概算の値札を付けることができます。 可観測性は、予期せず、インフラストラクチャコストプログラムの不可欠な要素になりました。
セキュリティ監査の改善：選択したトランザクションを100％保持できるため、本番データコンソールとのすべてのやり取りを維持でき、セキュリティが顧客データへのアクセスの可視性を高めるのに役立ちます。
次は何ですか？
可観測性の文化を構築することは、引き続き技術プログラムの一部です。私たちは、オンボーディングマテリアルの改善、R＆Dオペレーションへのトレースによる可観測性のさらなる織り込み、およびフロントエンド機器の調査に焦点を当てます。
私たちのチームに参加することに興味がありますか？ ここで私たちのオープンエンジニアリングの役割をチェックしてください。
