Tags

緊急かつ重要なデジタルインシデントにリアルタイムで対応するためには、オンコール対応者がどこからでもアクションを起こせるようにする必要があります。

しかし、オンコール対応者がアラートに圧倒されると、本当のアラートと偽のアラートの違いを見分けることができないため、ただ「無視」してしまうことがよくあります。例えば、メンテナンスまたはアップグレードによるサービスのダウンがあった場合、このイベントは複数のインシデントを引き起こす可能性があり、レスポンダーは実際のインシデントに関係しない偽のアラートを受け取る可能性があることを意味します。しかし、あるサービスがクリティカルなインシデントを引き起こし、レスポンダーが問題に飛び込み、迅速に問題を解決する必要がある場合もあります。

オンコールチームは、より直感的で柔軟なソリューションが必要です。モバイルデバイスでサービスを無効にしたり、インシデントアラートを一時停止したりすることができるため、中断することなくインシデント解決という重要なことに集中できます。

私たちは、効果的なインシデント管理は、中断を最小限に抑えながら、チームがより効率的に仕事をするのに役立つと信じています。そのため、PagerDutyモバイルアプリを通じて”Maintenance Widows”の一般提供を発表できることをうれしく思っています。

Maintaance Windows を使うと、レスポンダーは、メンテナンスモードの間、すべての統合を含むサービスを一時的に無効にすることができます。サービスがメンテナンスウィンドウにあるとき、サービスの全統合は事実上「スイッチオフ」になり、新しいインシデントが発生しないようにします。

メンテナンスウィンドウの作成、更新、削除がどこからでも簡単に行えます

モバイルアプリでメンテナンスウィンドウを作成するには、いくつかの簡単なステップを踏むだけです。

ハンバーガーメニューから「サービス一覧」を選び、ご希望のサービスを選択します。 設定をタップし、"create maintenance menu "をタップします。 このメンテナンスが行われる理由を説明するために、Descriptionを入力します。 メンテナンスの開始日と終了日（および時間）をスケジュールします。 メンテナンスウィンドウが終了すると、サービスはメンテナンスモードを終了し、新しいインシデントを再びトリガーすることができます。

設定から "end maintenance window"をタップすると、既存のメンテナンスウィンドウを削除できます。

複数のサービスのメンテナンスウィンドウを表示

PagerDutyのモバイルアプリでの操作では、一度につのサービスに対してメンテナンスウィンドウを作成できます。複数のサービスをカバーするメンテナンスウィンドウを作成したいユーザーは、ウェブアプリケーションから行えます。 複数のサービスをカバーするメンテナンスウィンドウのオプションの更新や削除は、モバイルアプリから行えます。

PagerDuty Mobileに追加されたこの最新機能は、オンコールチームが時間やワークライフバランスを犠牲にすることなく、インシデントを管理し対応することを可能にします。私たちは、チームがより良いサービスを提供し続けるために信頼できる情報を提供することで、PagerDutyのモバイル体験を継続して改善しています。

PagerDuty MobileとMaintenance Windowsについては、ナレッジベースの記事で詳しく説明されています。または、以下のQRコードからダウンロードし、お試しください。

iOS

Android

PagerDutyのインシデントレスポンスとモバイルアプリとの連携についてもっと知りたいですか？14日間の無料トライアルに参加し、PagerDutyがいかにチームを迅速かつ効率的に強化し、オペレーションクラウド全体のイノベーションを推進できるかを体験してください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

お客様からは、管理しきれないほどの大量のノイズや複雑性に対処しているため、根本的な原因を突き止め、迅速に解決することが難しいという声をよく聞きます。ノイズの選別、イベントの処理、コンテキストの収集に費やす労力は、多くの時間を浪費することになります。

そこで私たちは、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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。

by Andrew Marshall

2019年7月のニューヨークでのAWSサミットは、AWSとPagerDutyの両方にとってエキサイティングなものでした。AWSチームは、AWSでSaaSを提供するパートナー企業が、顧客が処理するイベントを簡単に挿入できるようにするAWS CloudWatch Events用のAPIセットであるAmazon EventBridgeを公開しました。PagerDutyは、EventBridgeをローンチパートナーとしてサポートすることで、AWSとの長年のパートナーシップを深化させています。AWSベースのクラウドインフラストラクチャを使用するPagerDutyのお客様は、EventBridgeのアドバンテージを利用して、PagerDutyのリアルタイムオペレーションプラットフォームをさらに活用できます。

AWS Lambdaについて少々

AWSがre：InventでサーバレスサービスAWS Lambdaを2014年に発表したとき、多くの開発者はLambdaの大きな可能性について懐疑的でしたが、Cloud Foundry Foundationの世界的な調査によると、22％の企業がすでにサーバーレステクノロジーを使用していることがわかりました。Lambdaが提供する価値はシンプルです。サーバをプロビジョニングせずにコードを実行できます。チームはほぼすべてのタイプのアプリケーションまたはサービスを自動的に実行でき、Lambdaはどんなコードでも実行しスケーリングします。EventBridgeはAWS Lambdaを使用して、PagerDutyなどのSaaSパートナーと提携することで、さらに多くのことを可能にします。

それで、EventBridgeって何?

EventBridgeはAWSの新しいサービスであり、チームは複雑な設定とインテグレーションに貴重な時間を費やすことなく、ネイティブAWSサービスをPagerDutyなどのサードパーティSaaSソリューションに接続するイベント駆動型ワークフローを作成できます。EventBridgeにより、PagerDutyの顧客はAWSがサポートするインテグレーションと機能のすべてを活用できます。

PagerDutyデータのインバウンドソース

EventBridgeを使用すると、PagerDutyユーザーは PagerDuty Eventsによってトリガーされるイベント駆動型ワークフローを簡単に作成できます。AWSコンソール内のインバウンドデータソースが信頼できるため、チームがデータにアクセスするために複雑なWebhookや他のマニュアル設定手順を使用する必要はありません。セットアップが完了すると、チームはPagerDutyイベントデータを使用して、AWSでイベント駆動型のワークフローをトリガーできます。

「AWS EventBridgeとPagerDutyを組み合わせることで、イベント駆動型のワークフローをリアルタイムで生成できます」とCox AutomotiveのリードソフトウェアエンジニアであるEd Kozlowski氏は述べています。「問題を検出すると、PagerDutyは、AWS Lambda関数をトリガーするアラートを生成してランブックを取得し、PagerDutyに詳細をポストできるため、問題をより迅速に解決し、お客様に最高のエクスペリエンスを提供できます」。

PagerDuty＋EventBridgeをどう使うか

幅広いAWSサービス製品と同様に、PagerDutyとAmazon EventBridgeでできることには制限がありません。とはいえ、顧客が即時のビジネス価値を実感するために実装できる次のような用途があります。

セキュリティ修復　オープンポートを（AWS GuardDutyを介して）検出するとします。これは明らかにセキュリティリスクであり、適切な対応者に警告する必要があります。PagerDutyとEventBridgeを使用すると、SecOpsまたはオンコールチームへのアラートをトリガーするだけでなく、直接オープンポートへのアクションを実行できます。この追加された修復アクションでは、たとえば、AWS Lambda関数を使用して、Amazon Virtual Private Cloudがポートを閉じます。 実行可能なコンプライアンス違反　同様に、AWS Identity and Access Management（IAM）ロールまたはアクセス許可違反がAWS CloudTrailを介してトリガーされたとしましょう。適切なサービスチーム、管理者、またはSecOpsにこの潜在的なセキュリティやコンプライアンスの問題を知らせてほしいが、警告だけでは修復に役立ちません。PagerDutyとEventBridgeを使用すると、このデータを使用してAWS Lambda呼び出しを自動的に行い、アクセスを完全にロックするか、別の構成変更をトリガーして問題に対処できます。

PagerDutyユーザーが活用できるその他のいくつかのユースケースには、次のものがあります。

リソースのデプロイ：サービスリソースをスケーリングまたは起動して、新しい需要に対応します。 エンドポイントの問題：Amazon Personal Health Dashboardを使用して、エンドポイントの問題に対処するための変更を行います。 カスタマーサービス：PagerDutyがインシデントに対処するときに、新しいSalesforce.com Service Cloudケースを自動的に作成するか、既存のケースを更新します。

AWSエコシステム内でPagerDutyのデータとアラートを実行可能にする準備はできていますか？ 詳細については、EventBridgeインテグレーションガイドや、PagerDutyのAWSインテグレーションスイートをご覧ください。

本記事は米国PagerDuty社のサイトで公開されているものをDigitalStacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。