オブザーバビリティの効果的な運用：既存のITワークフローに統合する方法

ツールはただ導入すれば済むわけではありません。たとえば、オブザーバビリティツールの立ち上げが完了しており、ダッシュボードは稼働中、アラートも生成されているとします。それにもかかわらず、いまだに手探りで進んでいる気がするのはなぜでしょうか？

チームがノイズに振り回されているうちに、新しいツールが次々と導入されます。そこでインシデントが発生すると、オブザーバビリティが責められます。しかし、これはツールの問題ではありません。プロセス統合の問題なのです。

よくある悪い典型例：オブザーバビリティを後から付け足す

よく見られるのは、オブザーバビリティをチームにおける計画、リリース、運用という流れの中に組み込むのではなく、問題が生じて初めて取り入れるパターンです。これは間違ったアプローチです。この方法ですと、インシデントが発生すれば、担当者はやはり慌てることになります。経営陣は答えを期待しているのに、言い訳ばかり聞かされます。資産は陳腐化するものです。理想的な可視化として始めたものが、悪い典型例になってしまうのです。

オブザーバビリティはそのようなやり方ではなく、ITプロセスに溶け込ませなければなりません。そのためには、変更管理、インシデント対応、リリース計画の際に、次のような質問を投げかける必要があります。

• オブザーバビリティに関してどのような作業が必要か
• 抑制ルール、新しいテレメトリ、ダッシュボードの更新が必要か

これらの質問は余分なことではなく、必須の要素です。

可視性の陳腐化に伴う損失

オブザーバビリティが後から付け足されただけだったり、変化に適応しなかったりすると、いずれ役に立たなくなります。抑制なしのメンテナンスウィンドウではチームが大量のノイズに翻弄され、信頼は損なわれていきます。本番では、監視範囲はシフトし、サービスは入れ替わり、依存関係も変化します。フィードバックループが存在しないため、死角は拡大し続けます。インシデントが発生して、初めて事の重大さに気付きます。

そうなると、「オブザーバビリティにあれだけの金額をつぎ込んだのに、見逃したのか？」という声が出てきます。これが実際の職場ではどのようになるのか、ご紹介しましょう。

本当にあった話：ポータルを停止に追い込んだ「失われたピース」

担当チームはそれまで、すべての職務を「適切に」遂行していました。そこに新しい社内ポータルが導入されました。ダッシュボードを立ち上げ、アラートを調整し、ワークフローをテストして、ローンチは順調にいきました。そして、自信が高まりました…あの日に崩れ去るまでは。

1カ月後、全社にわたる割引で、ポータルへのオプトインが必要となりました。始めの頃、登録は順調でした。ところが、最終日に登録が急増したため、バックエンドサービスが詰まってしまいました。そのためポータルがフリーズしました。

外形監視ではこの事態を見逃していました。必要なワークフローが、ローンチの際に用意されていなかったのです。ウォールーム(作戦指令室)のダッシュボードは「正常」を示しています。アラートは発生していませんが、チケットは山積みになっています。その時、人事担当VPから直接、次のようなエスカレーションが届きました。「事態を報告しているのがアソシエイト社員というのは、どういうことですか？」

もっともな質問です。回答は悲惨なものでした。事後分析で明らかになったのは、「オブザーバビリティに失敗したのではなく、一度も更新されていなかった。ビジネスは進化したが、監視範囲が適応していなかった」ということです。

オブザーバビリティをITプロセスに組み込む：統合の重要ポイント

オブザーバビリティが傍観者になってはいけません。組織が思考し、構築し、運用していくプロセスに根本から組み込む必要があります。では、どうすれば実現できるでしょうか。どこから手を付ければよいでしょうか。

ご安心ください。オブザーバビリティを活用でき、かつ活用すべき領域として上位のものを以下にご紹介します。

統合ポイント1：サービス管理

変更管理、インシデント管理、問題管理は、IT運用の基盤です。オブザーバビリティも同じく、根本から組み込まれているべきです。オブザーバビリティをサービス管理全体に深く組み込めば、優れた説明責任、コンテキスト、対応品質を実現できます。そうしたオブザーバビリティなら、ダッシュボードとアラートを実用的なインサイトに変換して、価値あるIT運用に活かせます。

統合戦術：

• 変更テンプレートを調整してオブザーバビリティの要件に適合させます。具体的には、必要なテレメトリ更新、検証手順、抑制計画などを調整し、計画されたアクティビティでアラートが過剰に発生することを防ぎます。
• ITSMデータをオブザーバビリティプラットフォームに取り込みます。これにより、テレメトリを、インシデント、チケット、問い合わせ件数の傾向と相関付けられるようになります。ウォーターマークと分析でシグナルを増幅し、豊富な情報を引き出せます。
• ステートフルアラートを用い、コンテキストへのディープリンクを使ってインシデントを自動的に開いて解決できるようにします。これで、インシデント管理プロセスを通じた説明責任が強化されます。ダッシュボードおよび根本原因のビューへのディープリンクを含めることで、トリアージを迅速化できます。
• 他のITサービスと同様に、非技術系チームがカタログからオブザーバビリティリクエストを送信できるようにします。これで、非技術系のチームもフォームに基づいてセルフサービスでリクエストを送信できるようになり、Observability as Code (OaC)が促進されます。

なぜ重要か：上記の統合によって、過剰なアラートが削減され、人が報告したデータとシステムメトリクスが相関付けられて、オブザーバビリティから提供されたシグナルに対する信頼が高まります。

統合ポイント2：ソフトウェアデリバリーとエンジニアリング

オブザーバビリティをリリースの一環として組み込みます。新しいコードをリリースする際には必ず、該当する機能を可視化できるようにします。オブザーバビリティにも、CI/CDパイプラインの他の部分と同レベルの厳密さ、速度、自動化が必要です。

統合戦術：

• ダッシュボードとアラートをコードとしてデプロイし、一貫性とトレーサビリティを保証します。これがOaCです。
• CI/CDを実施する際に、標準化したオブザーバビリティタグと導入メタデータを適用し、チーム、サービス、環境、バージョンのコンテキストによってテレメトリを強化します。
• チームのバックログでオブザーバビリティの不備を追跡して優先順位付けし、技術的負債と同等に扱います。
• テレメトリを使ってリリースKPIを検証し、意図した成果が得られたかどうかを確認します。
• 計画された変更中に情報イベントを発行してアラートを抑制することで、ノイズを減らしてリリースに対する注意を高めます。

なぜ重要か：CI/CDパイプラインに統合すると、オブザーバビリティの精度の低下を防止できます。また、すべてのサービスがすべての環境で確実に可視化され、追跡もアラート送信もできるようになります。

統合ポイント3：アーキテクチャとセキュリティのレビュー

初めからオブザーバビリティを前提として設計します。なぜなら、オブザーバビリティに関する初期の判断によって長期的な成功が左右されるためです。設計のレビューには、テレメトリ、タグ付け、アラートの準備の要件を組み入れます。すべてを稼働開始前に行うべきです。

統合戦術：

• レビュー時にオブザーバビリティタグとサービスIDを取り込みます。ダッシュボード、アラート、外形監視の情報源となる論理サービス、アプリケーション、コンポーネント、重要なユーザージャーニーなどです。
• メトリクス、ログ、トレースにわたるテレメトリの準備状況を検証します。特にインストルメンテーションや基準が新規で必要になる可能性がある新しい言語、パターン、技術スタックで重点的に実施します。
• オブザーバビリティ要件を早めに定義します。主要な属性、使用中のテクノロジー、計画済みの稼働開始日、担当するステークホルダーなどです。プラットフォームの容量とパイプラインが、想定されるテレメトリおよびオブザーバビリティの目標をサポートできることを検証します。
• テレメトリの量とプラットフォームへの影響を予測します。これには、アプリケーションパフォーマンス監視(APM)やリアルユーザー監視(RUM)のためのログの増大、エージェントの配備、ライセンス供与の要件などが含まれます。追跡と事前の計画には、確立されたオブザーバビリティのKPIを使用してください。
• サービス層とオブザーバビリティの目標を早期に定義し、本番に移行する前に、計画された監視と階層型オブザーバビリティサービスとの整合性を確保します。

なぜ重要か：オブザーバビリティに対応した設計によって、後から追加して繕うことをなくし、チームが初日から目標を明確に理解してインサイトを取得しやすくなります。

統合ポイント4：購買および取得

買う前にしっかり検討します。やみくもに統合してはいけません。性急な購買や取得によって、ツールの乱立、テレメトリの欠落、ベンダーロックインが生じることがよくあります。可視性を維持しながら自信を持って規模を拡大するために、評価とオンボーディング両方のプロセスにオブザーバビリティを組み込みます。

統合戦術：

• 新しいツールをオンボーディングする際に、オブザーバビリティ質問票を使います。これにより、テレメトリソース(ログ、メトリクス、トレース)、重要なユーザージャーニー、健全性チェックエンドポイント、ステータスページの可用性、ログのアーキテクチャなどの詳細を把握します。
• 購買時に可視性の目標を設定します。そうすることで、ベンダーが確実にオブザーバビリティスタックをサポートし、関連するデータを提供し、運用の透明性基準を満たせるようにします。
• M&Aデューデリジェンスの一環としてオブザーバビリティの成熟度を監査し、取得した技術スタックが自社の標準にどのように適合するか、また、不備や不足が発生しうるのはどこかを把握します。このインサイトをオブザーバビリティのセンターオブエクセレンス(CoE)に取り込んで、修復、合理化、統合の計画に活かします。計画では、取得したツールと社内推奨ツールセットとの調整や重複するプラットフォームの廃止なども検討します。

なぜ重要か：ツールの乱立を減らし、テレメトリを標準化し、すべてのプラットフォームがオブザーバビリティの目標を確実にサポートするようにできます。

統合ポイント5：社員、トレーニング、当事者意識

オブザーバビリティをツール管理者に任せきりにしてはなりません。オブザーバビリティの成功は、プラットフォームだけでなくそれに関わる人にもかかっています。当事者意識、活用支援、継続的な関与がなければ、どんなに優れたツールであっても「宝の持ち腐れ」になってしまいます。オンボーディングからパフォーマンスレビューにいたるまで、可視性は社内の共有責任とみなす必要があります。

統合戦術：

• オンボーディングと社内トレーニングにオブザーバビリティを組み入れます。そうすることで、新入社員がダッシュボード、アラート、テレメトリを解釈して操作する方法をすぐに身に付けられるようにします。
• オブザーバビリティの使用状況メトリクスをチームリーダーに提供します。つまり、作成されたダッシュボード数、制作されたディテクター数、ツールログイン回数などを提供し、普及度の測定やコーチングの改善を支援します。
• パフォーマンスレビューで、オブザーバビリティへの貢献度を評価します。その際は、影響度、イノベーション、説明責任の共有を重視します。
• オブザーバビリティの理解度をキャリアアップの要素として組み込みます。上級および主席テクノロジストであれば、現場でオブザーバビリティを自力で活用できるほどのスキルを実証するように求めます。
• 組織内でトレーニングを広範に実施し、スキルを向上させます。ベンダー提供のトレーニングリソースをすべてのチームに配布し、ベンダーのアカウントマネージャーと連携して、適切な社員に製品アップデートとベストプラクティスを提供します。

なぜ重要か：これにより、オブザーバビリティの文化を構築し、プラットフォーム担当チーム以外にも当事者意識を拡大できます。

統合ポイント6：本番前のテスト

本番環境で問題が起きるまで待っていてはなりません。本番前に、現実世界と同様の複雑な環境で最終リハーサルを行います。本番前のテスト環境では、パフォーマンステスト、QA、カオステストを実施します。この環境は、コードが顧客に影響を及ぼす前に早い段階でリスクを炙り出し、オブザーバビリティの監視範囲を検証するのに最適な場です。

ところが、これらの環境の監視が不十分なために、機会を逃したり、土壇場で不測の事態が発生することが珍しくありません。

統合戦術：

• 本番環境とほぼ同様の本番前環境で監視を実施します。対象にはログ、メトリクス、トレース、外形監視などを含めます。
• テスト実行時にダッシュボード、アラート、ディテクターを検証します。条件が平常どおりでも悪化しても、予期される動作が反映されることを確かめます。
• 本番環境にリリースする前に、オブザーバビリティの審査承認を求めます。たとえば、テレメトリの範囲、アラートの即時発動、タグ付けの完成度を確認します。
• 負荷テストチーム、カオスエンジニアリングチームと連携して、エンドツーエンドのオブザーバビリティを検証します。テレメトリが正しく収集されること、アラートが発動すること、ダッシュボードが状況を正確に反映すること、外形監視によって高負荷の下でも問題が検出されることを確認してください。
• 本番前を「本番マイナス1」と捉え、オブザーバビリティ階層化目標を適用します。これによって一貫性が強化され、サービスの重要度に応じて確実に可視性を実現できるようになります。

なぜ重要か：本番前環境でテストを予防的に実施し、不備や不足を早期に明らかにすることで、インシデントの影響を軽減し、信頼を高めることができます。

次の行動：ツールの用意にとどまらず、組み込みを開始する

ここまでお読みいただいていれば、オブザーバビリティは傍観者では済まないことは明らかなはずです。オブザーバビリティは、後から付け足すものではありません。計画、構築、対応のプロセスに根本から組み込まなければならないのです。継ぎ目を詳しく調べましょう。オブザーバビリティを、反応する箇所だけでなく、効果のある箇所に埋め込んでください。

次のインシデントで不備や不足が明らかになるのを待っていてはなりません。オブザーバビリティをプロアクティブに活用しましょう。

実際にお試しいただくこともできます。Splunk Observability Cloudの14日間無料トライアルを、今すぐ簡単に始めましょう！

このブログはこちらの英語ブログの翻訳、山村 悟史によるレビューです。