お客様からは、管理しきれないほどの大量のノイズや複雑性に対処しているため、根本的な原因を突き止め、迅速に解決することが難しいという声をよく聞きます。ノイズの選別、イベントの処理、コンテキストの収集に費やす労力は、多くの時間を浪費することになります。
そこで私たちは、Event Orchestrationを発表し、Event IntelligenceとDigital Operationsをご利用中のお客様に月曜日から提供し始めました。
PagerDutyのEvent Orchestration担当シニアプロダクトマネージャーであるFrank Emeryに、この機能を構築した理由と、お客様の行動やフィードバックがどう開発の方向性を決定したのか、その背景を詳しく聞いてみました。
Q: 新機能のEvent Orchestrationについて教えてください。
A: PagerDutyのプラットフォーム全体で見ると、20％のインシデントが５分以内に解決されています。解決が難しい大きなインシデントを５分以内で解決できることはありません。このことから分かるのは、インシデント対応には、診断テストの実行やサーバーの再起動など、必要ではあるが手作業に近いプロセスが存在し、それがチームの時間を奪い、生産性や集中力を低下させていることです。このようなケースでは、的確な自動化によってインシデントレスポンス時の手順を短縮することが可能です。場合によっては、インシデントを担当から外すこともできるかもしれません。これらのユースケースを、解決時間が15分や30分のインシデントの原因となる反復タスクに拡大すると、時間の節約、生産性、集中力の向上の可能性はさらに高まります。
それは、「インシデント発生時にお客様のチームが常に行っている手作業や繰り返しの作業に費やす時間を減らすために、当社のプラットフォームを利用できるようにするにはどうすればよいか」ということです。オートメーション化することで、すぐ処理できるイベントがレスポンダーの手を煩わす数を減らし、実際に彼らの専門知識が必要なインシデントに時間を割くことができるようにするには、どうすればよいでしょうか。
Event Orchestrationについて考えるとき、もしお客様がルールを設定する方法をより柔軟にし、より多くの自動化機能を前もって使用できるようにすれば、チームが通知を受ける前に、これらのすぐ解決策が分かるタスクをできるだけ多くカバーすることができるのではないでしょうか。
Q: Event Orchestrationは、Event Rulesとはどう違うのですか？
A: 私たちがうまくやったのは、Event Rulesを利用して、イベントの取り込みパイプラインに直接設置する意思決定エンジンを構築したことです。Event Orchestrationでは、複雑なロジックを備えた新しい条件言語を使い、条件に基づいて次善のアクションを広範に起動できます。ある例では抑制、ある例ではルーティング、あるチームではリアルタイムに取り込まれる自動診断や自動修復などの自動アクションを起動したいと思うかもしれません。
オーケストレーションで特定の状況を処理するように設定すると、マシンはロジックを使って状況を識別し、その状況に基づいて対処方法を決定します。これにより、誰かが通知を受ける前に、意思決定エンジンがこれらのタスクのいくつかを処理する道が開かれ、そもそも人間が必要な場合には、インシデント対応プロセスに増員し始めることができます。
Q: Event Orchestrationの利用を検討している人にとって、ハードルの低い利用例を教えてもらえませんか？
A: お客様のことを考えると、まず２つの使い方のどちらかをされることが多いでしょう。
１つ目は、ノイズリダクションです。ノイズは非常に一般的な問題で、スタックを監視するために接続されるあらゆるツールと、それらがどうアラートを送信するかを考えれば驚くことではありません。私たちは、重複排除や抑制といった他の機能や、インテリジェントアラートグルーピングといったMLオプションも用意していますが、お客様の中には、より正確な情報を得たいと考えている方もいらっしゃいます。ノイズリダクションにEvent Orchestrationを使うと、ユーザーは正確なルール条件を利用して、非常に多くのターゲット状況を設定し、チームのためにノイズをそらし、統合、抑制して、重要な信号のみを通過させることができます。
２つ目は自動化です。自動化がどこまで高度になるかは、運用の成熟度によって異なります。インシデントレスポンスの初期段階を自動化できる可能性は非常に高く、その多くのステップは実際に非常に繰り返されることが多いものです。
最もノイズの多いサービスについて考えてみてください。そのサービスのインシデントのうち、同じ初期診断手順を必要とするものがどれだけあるか考えてみてください。エンジニアからよく聞く話ですが、障害が発生すると必ず電話がかかってきて、問題解決のために誰かが何かを始める前に、毎回このような手順を踏まなければならないそうです。通常、これらのステップはスクリプトを実行したり、正しいコンテキストを見つけるために情報を収集したりするものです。多くのシナリオで必要とされる、よく知られた反復タスクである診断の自動化から始めることが、手軽ですぐに成果を上げやすいシナリオだと言えます。
もっと詳しく知りたいですか？Event Orchestrationの詳細については、ナレッジベースの記事、またはこちらのデモをご覧ください。
この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
カテゴリー ：ベストプラクティス
