Category
インテグレーション&ガイド

2022年11月28日  (更新日:2022年12月5日)

PagerDuty、re:Invent 2022でAWS向け自動診断機能を発表。

今年もこの時期がやってきました。PagerDutyがAWS re: Invent 2022のためにシン・シティに戻ってきます! このグローバルカンファレンスでは、あらゆる規模の企業が参加し、クラウドの近代化、自動化、回復力をテーマに議論が行われます。現在の経済状況において、企業は常時接続のデジタル体験を顧客に提供しながら、運用を拡張し、コストを最適化することを求めています。オートマトンは、運用とコストの効率化をサポートする上で重要な役割を果たします。今年、私たちはre:Inventの会場に新しいソリューションを持参できることを嬉しく思っています。自動診断 for AWSは、エンジニアリングチームがより多くの時間をイノベーションに費やし、中断することがないよう支援します。また、re:Inventのプラチナスポンサーとして、AWSとの長期的な関係を深め、お客様と共同で自動化されたCloudOpsを提供できることを誇りに思っています。

クラウドは世界を食べている

ガートナーによると、"2023年までに、企業の全ワークロードの40%がクラウドインフラとプラットフォームサービスに展開され、これは2020年の20%から増加する "とのことです。この引用は、サービスとバックエンドインフラのさらなるデジタル化を目指す企業にとって、クラウドの導入が引き続き最重要課題であるという現実をさらに突きつけています。AWSは、これまでにないスケール、アジリティ、イノベーションのスピードを提供しますが、チームは、システム、プロセス、組織にわたって複雑性が増し、依存関係がますます大きくなっていることに直面します。この複雑な状況は、収益はもちろんのこと、顧客と従業員のエクスペリエンスを危険にさらす恐れがあります。

組織がクラウドに移行し、クラウドネイティブアーキテクチャを展開するにつれ、複雑さが増すと、より多くの(費用のかかる)インシデントを引き起こす可能性があります。多くの企業は、相互に接続された複数のサービス(多くは一時的に存在する)を含む複雑なクラウドアーキテクチャを使用しており、それらは異なるアベイラビリティゾーンやアカウントにまたがって展開されています。インシデントが発生すると、根本的な原因や、適切なアクセス権限や専門知識を持つ人を理解できないまま、解決に長い時間がかかることがあります。これは、多くのエスカレーションが発生し、開発者が価値の高い仕事から引き離されることを意味します。

インシデントは高くつくものです。大手小売業者の場合、サイトが1分ダウンするごとに、1分あたり20万ドル以上の売上が失われる可能性があります。また、インシデントが発生すると、エンジニアは新機能の構築やイノベーションに集中する代わりに、問題の解決に取り組むため、生産性コストが発生します。インシデントが原因で、あるいはインシデント発生中に顧客体験が低下すると、ブランドの評判という形でさらにコストがかかる可能性があります。これらの要因をすべて合わせると、インシデントがもたらすコストは、想定していたよりもはるかに高くなります。

レジリエンス(回復力)の重要性

顧客がデジタル体験をほとんど中断することなく楽しむためには、レジリエンスが不可欠です。しかし、現実は厳しいものです。物事が壊れ、サービスが停止することは避けられません。それは誰にでも起こることです。本当に重要なのは、どれだけ早く復旧してサービスを再開できるか、また、今後同様の事態が発生しないようにできるかです。ハイブリッド・インフラストラクチャを完全に可視化し、問題を迅速に検出・診断できるようにすることは、ビジネスとすべてのサービスを継続するために必要不可欠です。

レジリエンスはただ起こるものではなく、責任を共有するものです。お客様は、インシデントに耐え、迅速に対応できるように、インフラ、運用、および人員を設定する必要があります。チームが自分たちのサービスを構築し所有することで、明確な所有権と説明責任を定義することは、集中したリアルタイムのインシデント対応を確保するために不可欠な要素です。

PagerDutyは、エンドツーエンドのインシデント対応と高度な自動化機能によってチームを強化し、いつでも迅速かつ正確に正しい対応を指揮します。プロセスの自動化により、インシデントの迅速な診断と解決が可能になり、エスカレーションの回数とMTTRが大幅に削減されるため、エンジニアリングチームは継続的な改善とイノベーションに集中することができるようになります。

にんげんがおおい、時間がない

AWSのお客様の最新のクラウドアーキテクチャは、市場で利用可能な約250のAWSサービスと25,000のSaaSワークフローに、自社開発のソフトウェアやその他のレガシーシステムが組み合わされたものである。

このような複雑なクラウド環境でインシデントが発生した場合、根本原因を特定し、依存関係の中から他の可能性を排除し、誤検出をチェックするために、クラウドスタックの専門知識をフル活用することがしばしば必要とされます。このため、第一線の対応者は、複数の専門エンジニアにエスカレーションして診断を依頼し、最終的な解決者を決定する必要がある場合があります。

第一線の対応者は、AWS環境での診断内容を収集するノウハウやアクセス権がないことが多い。第一線の対応者の多くはジェネラリストであり、サービスにおける特定の問題を診断するために必要な調査に関する技術的な知識がない。また、セキュリティポリシーにより、技術的な調査を実行するためのスーパーユーザーアクセスもない。

このため、緊急対応要員は通常、インシデントのトリアージに必要なデータを得るために複数の専門家にエスカレーションしなければならず、インシデントの解決に多くの時間を費やし、より多くのチームメンバーに支障をきたすことになります。深刻な停電の場合、これはインシデントの解決にかかる時間を不必要に長くし、エンジニアを価値の高い作業から遠ざけてしまい、停電の全体的なコストを増加させることになります。自動化は、インシデントを迅速に解決するだけでなく、インシデントを自分で解決するために必要な診断データを最初の応答者に提供し、貴重なエンジニアリング時間を保護するという重要な役割を果たすことができるのです。

AWSの自動診断

Automated Diagnostics for AWSを使用すると、インシデント対応者が自分でインシデントのトリアージを迅速に行い、ヘルプをエスカレーションする必要性を減らし、顧客に対する解決を迅速化し、運用効率を向上させることができます。PagerDutyのAWS向け自動診断では、Amazon EC2、AWS Lambda、Amazon ECS、Amazon RDSなど、よく使われるサービス向けの診断ジョブテンプレートがあらかじめ用意されています。お客様は、これらのテンプレートジョブを特定の環境で動作するように簡単に設定し、ワークフロー内の診断ステップを拡張することができます。また、Automated Diagnostics for AWSでは、AWS向けの独自の診断ジョブや、PagerDuty Incident Response内のレスポンダーが呼び出したり、PagerDuty Event Intelligenceがトリガーする緩和・修復のための修正オートメーションを迅速に設計することが可能です。

カスタマーサービスチームと関係者は、リアルタイムのステータス情報によって調整され、より良いカスタマーサポート体験を提供することができます。自動化により、MTTRを25分短縮し、インシデントの解決に必要な人数を減らし、エスカレーションの回数を40%減らすことで、社内チームがより効率的に運営できるようになり、時間とコストを削減しながらカスタマーエクスペリエンスを向上させることができます。

AWSの自動診断。

インシデントのトリアージ、ミティゲーション、および解決を行う力を持つ最初のレスポンダーを強化し、MTTR を全面的に改善します。 あらかじめ組み込まれたジョブテンプレートと、重要なAWSツールやサービスへのプラグイン統合により、エンジニアへのエスカレーションを削減します。 AWS環境におけるインシデントレスポンスの効率を継続的に向上させ、エンジニアに時間を還元することができます。

自動診断 for AWSの詳細についてはこちらをご覧ください。

AWS re:InventでPagerDutyを紹介します。

re:Inventのブースでは、弊社チームとの交流、グッズの配布、ペイジーとの挨拶、ライトニングトークへの参加など、様々な機会が設けられています。

ブース#3819では、プロセスオートメーション、インシデントレスポンス、イベントインテリジェンス、カスタマーサービスなどの製品デモを行い、PagerDutyオペレーションクラウドがお客様のデジタルオペレーションをどのように向上させることができるかをご確認いただけます。また、パートナー企業によるライトニングトークも多数予定しています。

混雑を避け、弊社の会議室でのミーティングやデモをご希望の場合は、リクエストを送信してください。私たちのチームは、あなたの特定のニーズに合わせて会話を調整し、PagerDutyとAWSについてより多くを共有することができます。

11月28日(月)14:30 pm Venetian Theatre, Level 2, セッション #PRT217

SalesForce、Netflix、Sailpoint、Benefitfocusの業界リーダーによるパネルディスカッションに参加し、PagerDutyとAWSでどのように組織を変革したかを議論しましょう。

11月30日(水)18:00-20:00

Matteo's Ristorante Italianoで、弊社のリーダーや同業者の方々と一緒にカクテルと会話をお楽しみください。PagerDutyが、世界で最も革新的な企業が優れた顧客体験を提供するためにどのように役立っているか、詳しくご説明します。

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

続きを読む
インテグレーション&ガイド
2022年7月28日  (更新日:2022年11月29日)

新着情報 Incident Response、PagerDuty®Process AutomationソフトウェアとPagerDuty® Runbook Automation、インテグレーション、その他を更新しました。

PagerDuty Operations Cloudの新しいアップデートと機能拡張を発表できることを嬉しく思います。PagerDuty Summitの成功を受けて、製品のいくつかの領域で開発が続けられています。製品チームからの最近のアップデートには、インシデントレスポンス、PagerDuty® Process AutomationとPagerDuty® Runbook Automation、パートナーインテグレーションとエコシステム、そしてコミュニティーとアドボカシーイベントのアップデートが含まれています。インシデントレスポンスの自動化を支援し、他のチームにエスカレーションされる問題の量を減らすことに加えて、次のことが可能です。

-Incident ResponseとService Standardsの間の一貫性と予測可能性を向上させます。 PagerDuty CloudWatch Logsプラグイン、Systems Managerプラグイン、ECS Remote Commandプラグインなど、最新のPagerDuty® Process AutomationとPagerDuty® Runbook Automation AWS Plugins for Automated Diagnosticsについて説明します。 最近リリースされた他のAWSプラグイン(ECSとLambda)やAnsibleプラグインのアップデート、PagerDuty® Process AutomationとPagerDuty® Runbook Automationの多数のコアおよび商用アップデートに関する詳細を最新の4.4.0リリースでキャッチアップすることができます。 PagerDuty App for Slackの改良を含む**、最新のパートナー統合とエコシステムのアップデートをお楽しみください。次世代Slack V2 専用インシデントチャンネルの改善(早期アクセス)およびWebhooks V3など PagerDuty App for ZendeskのAutomation Actions** により、カスタマーサービスエージェントの生活を改善し、解決までの時間を短縮し、エンジニアリングチームへのエスカレーションを削減します。 製品廃止のお知らせ** とユーザー管理画面のコールトゥアクションで常に最新情報を入手 今後のイベントに登録し、最近のポッドキャストやTwitchストリームを閲覧し、コミュニティチームや製品チームのメンバーと一緒に新製品やソフトウェア業界のリーディングプラクティスを学ぶことができます。

インシデントレスポンス Service Standards Service Standardsは、チーム全体で「良い」とは何かを標準化する基準を定義することで、運用の成熟度を高め、より良いカスタマーエクスペリエンスを提供できるようになります。ベストプラクティスに従ってサービスを一貫して構成し、インシデント対応時の予測可能性を向上させます。組織全体にわたってサービスの所有権を拡大します。サービス設定の精度を向上させることで、分析機能を強化します。管理者とアカウント所有者は、デフォルトでサービス標準を表示できますが、権限を調整して、全てのユーザーが表示できるようにすることもできます。

検索機能の強化 全スケジュールとチームスケジュールの切替 詳細度に合わせて情報を折りたたんだり、拡大したりすることができます。 タイムウィンドウ表示によるスケジュール比較の容易化 オンコール対応者をシフト時間と共に効率的に表示

ナレッジベースで詳細をご覧いただくか、オンデマンドでウェビナーをご覧ください。

Service Standardsのデモ映像はこちらからご覧いただけます。

PagerDuty® Process AutomationソフトウェアとPagerDuty® Runbook Automation

自動診断のための新しいAWSプラグイン あなたのアプリやサービスはAWSにありますか?もしそうなら、AWS上のインシデントをより速く、より効率的にトリアージするのに役立つ自動診断のためのAWSプラグインを用意しました。これらの新しいプラグインは、既存のライブラリーに追加されます。

更新内容は以下の通りです。

CloudWatch Logsプラグインは、AWSインフラストラクチャーとアプリケーションから診断データを取得します。これにより、ユーザーはより簡単に、複数のアカウントや製品にまたがるAWSの自動診断を実行できるようになりました。

Systems Managerプラグインにより、構成管理、パッチ適用、監視およびセキュリティーツールエージェントの展開などのタスクをより迅速に実行し、正確に実行することができます。運用者は、セキュリティーのベストプラクティスを備えた単一のインターフェイスで、グローバルなEC2フットプリントを表示および管理できるようになりました。 ECS Remote Commandプラグインは、コンテナ上でコマンドを実行するための機構を提供します。これにより、開発者や運用者は、サービスを再展開する前に、実行中のアプリケーションからリアルタイムに診断データを取得することができます。

ブログをお読みいただくか、お問い合わせください。

PagerDuty®プロセスオートメーションソフトウェアとPagerDuty® Runbookオートメーション リリース4.4.0

商用製品ユーザーは、LambdaとECS(Fargate)の新しいAWSジョブステッププラグインを利用できるようになりました。

詳細はこちら

Lambda Custom Code Workflowステップでは、Jobステップで提供されたカスタムコードを入力として、新しいLambda関数を作成、実行、オプションで削除することができます。Runbook Automationのユーザーにとって最も有利なのは、ソフトウェアをインストールすることなく、カスタムスクリプトをジョブのステップとして実行できることです!

ご好評いただいているAnsibleプラグイン、最近の追加機能拡張と修正を行いました。

Ansibleインラインインベントリーを修正 Ansible Gradleを7.2に更新 Ansibleの行区切りをLFに正規化(unix) Ansible Ansibleのバイナリーディレクトリーへのパスを設定するフィールドを追加 Ansibleのバイナリーディレクトリへのパスを設定するフィールドを追加

詳細はこちら

また、その他のさまざまな商用アップデートやコア製品のアップデートについては、リリースノートで詳しく説明されています。

統合とパートナーエコシステム

PagerDuty App for Zendesk - Automation Actions

カスタマーサービス担当者は、PagerDuty App for Zendesk内で直接Automation Actionsを実行できるようになりました。この自動化により、効率が向上し、担当者の急増する作業負荷が軽減され、プレッシャーの高い顧客ケースに対応する際に担当者が手動タスクを実行しなければならない場合のミスの可能性が減り、労力を増やさずに担当者の生活を向上させるだけでなく、担当者も楽になります。また、カスタマーサービス担当者が自動的に問題を検証し、重要な情報を即座に取得して、対応チームが診断して解決できるよう支援します。Automation Actionsを実行することで追加されるコンテキストは、対応チームが解決時間を短縮するために瞬時にアクセスするために重要であり、バックエンドチームの負荷も軽減されます。エンジニアリングチームにエスカレーションされる問題の量を減らすことができ、緊急度が低い問題や顧客への影響が少ない問題などによる作業の中断を減らし、より効率的に作業できるようになります。

ナレッジベースで詳しく学ぶ

  • ブログを読む アカウントマネージャーに連絡する

PagerDutyアプリ for Slack専用インシデントチャンネル改良のお知らせ

次世代Slack V2のインシデント専用チャンネルの改善は、アーリーアクセスで、現在、お客様にご利用いただける状態になっています。これらの改善により、組織内のコラボレーションチームは、インシデントの専用インシデントチャンネル内から以下にアクセスすることができます。

全てのインシデントの詳細、履歴、および更新を表示 全てのインシデントアクションを実行 全てのレスポンダーをチャンネルに追加(レスポンダーが事前にSlackアカウントをPagerDutyにリンクしている必要あり) 専用のZoom会議ブリッジを投稿または作成

ブログを読む

Webhooks-V3-Update

Webhooks V3 のチーム統合を管理したいアクセス制限ユーザー、またはその知り合いの方はいらっしゃいますか?そのような場合、Manager Team Role の割り当てを受けることができます。これにより、グローバル管理者やアカウント所有者が日々の運用を管理する必要がなくなり、あなたと運用チームのメンバーに権限を与えることができます。

この機能のアーリーアクセスを有効にするには、PagerDutyサポートにご連絡ください。 ウェブフックについてもっと知る

製品廃止のお知らせ 今後予定されている非推奨製品について、チームにお知らせください。

V1/V2ウェブフック 現在、PagerDuty環境でV1/V2ウェブフック拡張を使用している場合、機能を維持するためにそれらをV3ウェブフックサブスクリプションに移行する必要があります。

移行ガイドに従ってください。

重要な日程

V1ウェブフック** – V1のウェブフック拡張は、2021年11月13日から非対応(新機能やバグ修正の停止)となり、2022年10月に動作停止となります。 V2ウェブフック** – V2ウェブフック拡張は、2022年10月にサポートが終了し、2023年3月に動作しなくなります。

必要な権限 管理者* またはアカウント所有者* は、アカウント全体を移行することができます。 チームマネージャー** は、割り当てられたチームのウェブフックのみを移行できます。

ウェブフックとは? ウェブフックを使用すると、PagerDutyアカウントで重要なイベントが発生したとき、例えばインシデントがトリガー、エスカレート、解決されたときにHTTPコールバックを受け取ることができます。イベントに関する詳細は、Slackや独自のカスタムPagerDuty Webhookプロセッサーなど、指定したURLに送信されます。

ご質問がある場合は、PagerDutyの担当者またはサポートチーム([email protected])までご連絡ください。

ウェブフックについてもっと知る

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

続きを読む
インテグレーション&ガイド
2022年10月27日  (更新日:2022年11月15日)

新着情報 Incident Response、PagerDuty®Process AutomationソフトウェアとPagerDuty® Runbook Automation、インテグレーション、その他を更新しました。

PagerDuty Operations Cloudの新しいアップデートと機能強化を発表することができ、とても嬉しく思います。製品チームによる最近の開発およびアプリのアップデートには、インシデントレスポンス、PagerDuty®プロセスオートメーション、およびコミュニティ&アドボカシーイベントのアップデートが含まれています。私たちは、お客様がクラウド運用を最適化するために自動化を進め、他のチームにエスカレーションされる問題の量を減らすお手伝いをし続けています。今すぐ始めて、学びましょう。

インシデント対応状況更新通知テンプレートのカスタマイズ、標準化、再利用性 PagerDuty®プロセスオートメーションとRundeckコミュニティの最新版4.7.0リリースとAWSの新しい自動診断機能でアップデート CollabOpsとCustomer Service Opsの統合に関する更新情報 Slackでメンテナンスウィンドウを表示する方 PagerDuty App for Salesforce v3.7とPagerDuty App for ZendeskのV3への移行について V1 Webhooks EOL (End-Of-Life), Event Rules EOL & Migration to Event Orchestration, and V2 Zendesk Integration EOLを含む製品廃止のお知らせ。 今後のイベントに登録し、最近のポッドキャストやTwitchストリームを閲覧し、コミュニティチームや製品チームのメンバーと一緒に新製品やソフトウェア業界のリーディングプラクティスを学ぶことができます。

インシデントレスポンス

ステータスアップデートの通知テンプレート EA

ステータスアップデートの通知テンプレートのアップデートをお知らせします。再利用可能なコミュニケーション・テンプレートを、影響度やサービスエリアなどに基づいてカスタマイズし、標準化できるようになりました。また、この機能は、APIを介して、あらゆるツールやコンテキストでニーズに合わせて活用することができます。

(上記特集 変数によるステータス更新通知テンプレートの設定)

(上特集:ステータス更新通知テンプレートの設定 プレビュー) アーリーアクセスプログラムフォームに記入して、最新のアップデートを受け取るためのアーリーアクセスリストに追加してください。 ステークホルダーとのコミュニケーションについて詳しくは、ナレッジベースをご覧ください。

PagerDuty®プロセスオートメーション

PagerDuty®プロセスオートメーションソフトウェアとPagerDuty®ランブックオートメーションバージョン4.7.0

このリリースでは、PagerDuty® Process Automation、PagerDuty® Runbook Automation、Rundeck Communityの新機能と機能強化をご確認ください。

CloudWatch Logs Saved Query Pluginです。このプラグインは、診断クエリの管理を簡素化します。ジョブのROI(投資対効果)を理解するためのインキュベーション機能、および多数のセキュリティとコンプライアンスの更新とバグ修正。 ROI Metrics データ (インキュベーション). ROI メトリクスの統合により、各ジョブ実行のユーザー定義値を追跡し、ジョブに対する主要な値のペアを保存して、ジョブ実行ごとの ROI を理解するのに役立ちます。

(上図:ROI Metrics Output)

Progress Badge プラグインを強化しました。Progress Badge プラグインは、ログ出力タブにレンダリングされるエモーティコンのステータスシンボルを含むグラフィックバッジを作成することができます。自動診断を実装しているユーザーにとって、ドメインの専門家が診断を消費しやすい方法で簡素化することができます。

(上の写真:失敗した状態のプロセスバッジ)

(上写真:成功した状態のプロセスバッジ)

(上図:インシデントアクティビティタイムラインのプロセスバッジの状態)

追加のアップデート バグフィックスやオープンソース製品の追加アップデートを確認できます。

詳しくはこちら

このリリースのTwitchストリーム・レビューを見る 2022年10月6日、オーク黄緑ギフトリリース(4.7.0)に関するリリースノート全文をご覧いただけます。

AWSの自動診断

私たちは最近、お客様がAWS環境の問題を迅速にトリアージできるように、PagerDutyのAutomated Diagnostics for AWSを発表しました。このソリューションは、PagerDutyのインシデントレスポンスとイベントオーケストレーションに接続されたオートメーションアクションとランブックオートメーションのシームレスな統合で構成されています。頻繁に使用されるAWSサービスのための事前構築された一般的な診断と、独自の診断を追加して構築する簡単な方法を提供します。

(上記特集:診断の自動化実行アクションメニュー)

(上記特集:プロセスオートメーション AWS CloudWatch Logs Plugin)

統合化

スラックのメンテナンス用窓

PagerDuty Slackインテグレーションを拡張して、Slackに直接メンテナンスウィンドウを表示したいと思ったことはありませんか?Mandi Wallsが最近、まさにそのような状況に対するウォークスルーを書いてくれました。

(上図:Slack Resultで複数のメンテナンス予定ウィンドウを表示)

PagerDutyアプリ for Salesforceの最新版をリリースしました。

PagerDuty App for Salesforceの最新バージョンv3.7がリリースされました。この最新版のメリットは以下の通りです。

Webhook ExtensionをPagerDuty webhooks v3にアップグレード-このアップグレードにより、webhooks v2のサービスレベルではなく、アカウントレベルで拡張機能を追加することができます。 新しいSalesforce Extensionページと、PagerDutyに接続されているSalesforceアカウントを確認できる機能 標準的な統合によるSalesforceインシデントオブジェクトのデフォルトのオブジェクトマッピング ルールセットのアクションをPagerDutyまたはルールセットフローの一部として作成されたSalesforceオブジェクトに限定するかどうかを選択する機能

(上図:PagerDuty App for Salesforce V3.7メインページ)。

詳しくはこちら

詳細はPagerDuty App for Salesforceインテグレーションガイドをご覧ください。 その他のご質問は、[email protected] までご連絡ください。

PagerDuty App for Zendesk v3への移行について

今すぐv3 PagerDuty App for Zendeskに移行すれば、Zendeskのサポートチケットイベントを引き続きPagerDutyに送信することができます。(この統合は2023年3月に終了します。)

今回のバージョンアップのメリットとしては、以下のようなものがあります。

Webhooksを利用したPagerDutyとZendesk間の双方向コミュニケーション チケットページでのPagerDutyの追加アクションとインシデントコンソールウィジェット ZendeskからPagerDutyのステータスダッシュボードを表示し、対話することができます。

(上図:Zendesk V3 Status Dashboard)

詳しくはこちら

詳細はPagerDuty App for Zendeskインテグレーションガイドをご覧ください。 その他のご質問は、[email protected] までご連絡ください。

製品廃止のお知らせ

今後予定されている製品の非推奨について、チームにお知らせください。

V1 Webhooks EOL

v1 WebhooksのEnd of Lifeは、2022年10月31日です。これは、次のことを意味します。

新しい v1 Webhook を作成したり、v1 Webhook 拡張機能への既存の接続を使用したりすることができなくなります。 v1 Webhooks を使用しているアプリやインテグレーションは動作しなくなります。

詳しくはこちら

v3 Webhooks への移行の詳細と手順については、この移行ガイドを参照してください。 その他のご質問は、[email protected] までご連絡ください。

重要な日程

V2 ZendeskインテグレーションEOL

PagerDutyのv2 App for Zendeskは2023年3月にライフサイクル終了となります。今すぐ移行して、ZendeskサポートチケットイベントをPagerDutyに引き続き送信してください。v3への移行の利点については、上記のIntegrationsセクションをご覧ください。

詳しくはPagerDuty App for Zendeskインテグレーションガイドをご覧ください。 ご質問やご不明な点がございましたら、[email protected] までご連絡ください。

イベントルールの廃止とイベントオーケストレーションへの移行

PagerDuty イベントルール End-Of-Life は2023年1月31日です。できます。

マイグレーションについて詳しくはナレッジベースをご覧ください イベントオーケストレーションの詳細 アカウントマネージャーへのお問い合わせ

この EOL をサポートするために、十分な移行経路を用意しています。さらに、EOLの日に、あなたが使っている残りのイベントルールをEvent Orchestrationに一対一で自動移行します。それ以降は、現在のイベントルールでできることは、すべてイベントオーケストレーションでもできるようになります。Event OrchestrationはEvent Rulesと同じ機能を持ち、同じバックエンドアーキテクチャを使用しているので、イベント処理には数十億イベント分のテストがすでに組み込まれていることを確認できます。

ウェビナー&イベント

以下のウェビナーやイベントに参加し、PagerDutyの最近の製品アップデートと、それがどのように顧客に利益をもたらすかについて、より詳しく学びましょう。これらは多くの中のほんの一部です。

ウェビナー

セキュリティのキャリアを考える

10月はサイバーセキュリティ意識向上月間です。PagerDutyのセキュリティチームはエンジニアがプラットフォームを安全に保つのを助け、従業員にセキュリティトレーニングを提供するなど、様々な活動を行っています。PagerDutyのポッドキャスト「Page It to the Limit」の最新エピソードでは、Megg SageとPatrick RoserieがPagerDutyでどのようにセキュリティに取り組んでいるか、またそれ以外についてもご紹介しています。

Evolve to resolve: より少ないインシデント、より速いレスポンス(11月製品発表!)。

SVP & GM of Emerging Products Jonathan Rende、シニアプロダクトチームメンバーのKat Gaines、Julia Nasser、Sam Ferguson、Hadijah Crearyと共に、最新の機能を深く掘り下げてご紹介しています。

インシデントワークフロー PagerDuty ステータスページとステータスアップデートの通知テンプレート インテリジェント・アラート・グルーピングのための柔軟なタイム・ウィンドウ 2022年に向けてアップデート! インシデントレスポンスOpsガイド

今すぐ登録し、席を確保しましょう

ライブコールルーティング。オンコールスタッフへの最速のコンタクト方法

PagerDutyのTim ChinchenとBen Wiegelmannと一緒にディスカッションしましょう。

Live Call Routingとは?ライブコールルーティングのワークフローとその理由 コード不要のライブコールルーティングのセットアップ方法 応答時間を短縮し、全体的な顧客体験を向上させるためにライブコールルーティングを使用している小規模から大規模の企業までの顧客の使用例

今すぐ登録

11月に開催されるイベントへの参加登録をお願いします

PagerDuty Community Twitch Stream

PagerDuty Twitch StreamとPagerDuty Community Twitch StreamのTwitchチャンネルで、デベロッパーアドボケイトが率いる最新のストリームに参加してください。過去のストリームはYouTube Twitch Streams Channelでご覧いただけます。

登録すると、ライブのお知らせや過去の録音を見ることができます。 私たちの放送を見逃しましたか?今後予定されている、または最近のTwitchストリーム(PagerDuty GarageとTerraform Time)、またはYouTubeビデオをご覧ください。 HowTo Happy Hour: Intelligent Alert Grouping With Mandi Walls, as well as Max Li and Everaldo Eguiar (Data Scientists from PagerDuty) (2022年9月30日) Process Automation and Rundeck OSS Release Notes v4.70 with Mandi Walls and Jake Cohen from PagerDuty (2022年10月12日) Twitchのストリームスケジュールを見て、11月に毎週開催されるストリームに参加してください。

もし、あなたのチームがこれらの機能拡張の恩恵を受けることができるのであれば、ぜひアカウントマネージャーに連絡して、14日間の無料トライアルに申し込んでください。

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

続きを読む
インテグレーション&ガイド
2022年9月1日  (更新日:2022年11月11日)

PagerDutyの世界危機対応月間が帰ってきました。新たな脅威からハイブリッドワークプレースを守るために

世界はますます複雑化しています。悪者による脅威は、社会を混乱させ、ニュースを席巻し、さまざまな形で私たちの生活に影響を与え続けています。COVID-19は、想定外の事態に備えた計画についていくつかの教訓を与えてくれましたが、同時に、多くの人が自分の働く場所を考え直すきっかけとなりました。ハイブリッドワークが多くの人にとって現実の仕事形態であり続ける中、危機対応と物理的セキュリティー管理を任務とする専門家は、もはや私たちの大半が同じ屋根の下で一つの安全プロトコルに従って働いているわけではない今、深刻な課題に直面しているのです。 PagerDutyは世界中で24時間体制で活動しています。そのため、デュートニアンの人々の安全を守るための24時間体制のオペレーションは、トレーニング、知識の共有、効果的なツールを通じて、全ての従業員が行動を起こせるようにすることから始まります。「世界危機対応月間」は、従業員の安全に関するワールドカップであり、私たちが行う全ての能力向上活動の成果を発表する場です。インタラクティブで、部門横断的で、楽しく、そしてシニアリーダーシップによって承認された活動です。 このブログでは、災害に対するチームの備えと、ハイブリッド化した世界における重要な物理セキュリティーイベントのギャップに対処することを目的とした「Harden the Target」イニシアチブで、PagerDutyを社内でどう使っているかを紹介します。

PagerDutyによるリアルタイムでのオーケストレーション

物理的なセキュリティーシステムで重大な違反や停止に直面した場合、チームはいつ、どこで、どのような事態が発生したかをリアルタイムで理解する必要があります。人間は、複数の物理的なセキュリティーイベントを同時に監視することは、機械と同じようにはできません。デジタル運用の原則をリアルタイムのアラートと自動化に適用することが、より良い洞察と実用的な情報を得るための鍵となります。PagerDutyの機能は、まさにこれを実現するのに役立ち、また戦力増強の役割も果たします。 PagerDutyのプラットフォームに統合することで、危機対応と物理セキュリティーの異なるシステム間で展開される重要なイベントに対応するための、より徹底した共通のオペレーションの概観図が得られることが分かりました。設定されたサービスと物理的セキュリティーの重要なイベントの種類が1対1であるため、何が起きているのかがよく分かり、潜在的に有害な活動に対応したり中断したりする平均時間が短縮されます。このプラットフォームの機械学習とインテリジェントなグループ化機能により、アクセス試行の失敗や機器停止の頻度など、トレンドとパターン認識のための追加情報を得られます。

この使用例では、物理的なセキュリティー管理のベストプラクティスとFEMAのエリアコマンドを、PagerDutyの従来のインシデントレスポンスに重ねています。このセットアップは、私たちの仮想Global Security Operations Center(GSOC)として機能します。PagerDutyの650以上の統合機能(Slack、Teams、Zoomなど)、メールクライアント、APIにより、ほぼ全ての物理セキュリティー、脅威情報、ステータス監視システムから重要なイベント情報を取り込み、そのデータでタイムリーに何かを実行できることが保証されています。 このプラットフォームを通じて、対応チームへのアラート、スタッフのための可聴アラームのセット、サードパーティーのビデオ分析を使用した契約セキュリティーチームのための自動化されたレスポンス作業の実行をオーケストレートできます。PagerDutyは、重要な物理的セキュリティーイベントを見逃すことなく、適切なタイミングで適切なチームにエスカレーションすることを保証します。

練習を重ねることで、反応の素地を作る

9月中は、週替わりの教育テーマ、PD.orgと連携したボランティア活動、ゲーミフィケーションによる防災セットづくりや災害映画トリビアなど、緊急事態への備えを社員に呼びかけています。また、「#stayready」をテーマに、地震などの自然災害や銃乱射事件のような人災に対応できるよう、従業員の準備を進めています。また、一緒に楽しみながら、お互いに重要な学びを得ることを目的としています。 また、緊急通信テストや地震訓練「The Great ShakeOut」など、システムテストや訓練を実施し、PagerDutyプラットフォーム上で連携しながら、対応習慣を定着させるようにしています。このプロセスを通じて、オンコールスケジュールを最新の状態に保ち、オンコール準備ツールを使って、全員がインシデントコマンダーとしてタイムセンシティブなアラートに対応できるように設定していることを確認しています。PagerDutyでは、チームに未来を築く力を与え、重要な物理的セキュリティーイベント用に設定されたプラットフォームによって、社員とビジネスに対する新たな脅威の先を行くためのツールボックスを手に入れたのです。PagerDutyが、あなたの組織が悪質な行為者によって引き起こされる多くの脅威に対応し、戦力として、または仮想GSOCとして機能するのに役立つかどうかを知りたい場合は、無料トライアルにサインアップしてください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

続きを読む
インテグレーション&ガイド
2022年8月15日  (更新日:2022年11月8日)

PagerDutyの活用によるデータサイエンスモデルのドリフトの最小化

_Thomas Pin(データサイエンティスト)著 _ PagerDutyには早期警告システム(EWS)モデルがあり、カスタマーサクセス部門とセールス部門が製品の使用状況と外部ビジネス要因に基づいてPagerDutyの既存顧客の健全性を確認するのに役立っています。この早期警告システムモデルは、アカウント解約につながる製品の使用状況の悪さを特定するための重要なインフラであり、最初の防衛線となっています。早期警告システムモデルの成功とカスタマーサクセス部門の多大な努力により、リスクの高い製品の使用は減少しました。このようなクリティカルなモデルの生産には、常に正確なスコアを生成し、常に更新することが最も重要なことです。

2021年1月、早期警戒システムモデルが、アップストリームの変更によって不正確な顧客リスクスコアをリリースし、結果として誤ったスコアが数日間公開されることになりました。とあるカスタマーサクセスマネージャーがこの不具合について問い合わせてくれたおかげで、すぐにモデルを診断し修復することができました。社内でDataDutyと呼ばれているデータプラットフォームとビジネスインテリジェンスチームは、今後同様の問題が起こらないように解決策を模索することになりました。

上に挙げた問題は、PagerDutyに限ったことではありません。データサイエンス界では、これはモデルドリフト の一例であり、アップストリームのデータ変更だけでなく、さまざまな形で現れます。DataDutyチームは、このような問題が発生した場合、自動テストとPagerDuty Alerts を使用してこの現象の影響を最小限に抑えることを決定しました。

PagerDuty

PagerDutyの製品は、モデルドリフトを回避するためのプロアクティブなパズルの重要なピースです。機械学習モデルが複数のプラットフォームを活用するようになると、複数のプラットフォームのログを取り込み、インシデントを作成し、優先順位に基づいてエスカレーションし、実務担当者に警告することは、PagerDutyのような専用のインシデントトリアージソフトウェアなしでは不可能になります。自動化されたテストがどれだけ堅牢であっても、その結果を適切なタイミングで適切な担当者に届けることができなければ意味がありません。PagerDutyのおかげで我々の戦略は成功し、モデルの実務担当者が気づく前に有害な変化を捉えることができました。

モデルドリフト

モデルドリフトは、コンセプト、データ、アップストリームの3つに分類され、それぞれ異なるアプローチで解決することが求められます。

コンセプト :モデル対象の定義の変化 データ :重要なインプットが重要でなくなる アップストリーム :根底にあったアップストリームデータの変化

コンセプトドリフトテスト

概念の変化を検出するテストは、データサイエンティストやステークホルダーが作り上げる構成であるため、なかなか書けません。しかし、早期警戒システムモデルの場合、ターゲットは「解約」(churn)であり、その定義は分かりやすいです。PagerDutyでは、「解約」はアカウントが有効化されるか無効化されることと定義されており、この定義は安定的に維持されています。

早期警戒システムモデルが顧客のリスクスコアを正しく予測していることを測定するために、いくつかのユニットテストを実施しています。

早期警告システム以前、PagerDutyの月次解約率はx%からy%の間でした。従って、月次解約率がz%以上であれば、問題であると考えられます。 早期警戒システムの全体的なスコアのセグメントは近年安定しており、個々のアカウントのスコアは時間の経過とともに増減する可能性があります。ただし、PagerDutyでは、アカウントの25%を低顧客リスクスコア、25%を中低顧客リスクスコア、25%を中顧客リスクスコア、25%を高顧客リスクスコアに配分することを想定しています。* 実際の数値ではありません。 早期警報システムの月平均スコアは従来、早期警報システムの平均スコアに対して2.5%の許容範囲内にあります。

もしこれらのテストのいずれかが失敗した場合、それは優先度が高いと分類され、PagerDutyはDataDutyのオンコールデータサイエンティストの1人にアラートを送り、モデルの「解約」の定義が正確かどうか、更新が必要かどうかを調査させることになります。

データドリフトテスト

時間の経過とともに、モデルの特徴量は早期警告システムモデルのスコアとの関連性が高くなったり低くなったりすることがありますが、PagerDutyはこうしたリスクを軽減するためのテストを開発しました。例えば、昨年は重要な指標の1つとして、「受任」されたインシデントの割合( インシデント受任率 )がありました。これは、アカウントの解約の可能性を予測するために関連する特徴量でした。しかし、最近になって緊急性の高いインシデントの承認率がより適切であることが分かり、当初の インシデント受任率 に取って代わりました。PagerDutyでは、特徴量ストア内の特徴量の関連性を判断するために、以下のようなテストを行っています。

コーエンのdは、2つの平均の間の効果量を推定します。早期警戒システムのモデルエンジンは、顧客分布と解約された顧客分布の間の平均値の間に有意な距離を持つ特徴量を持つことに依存しています。 尖度は、2つの分布の間の「尾の長さ」を測定します。顧客と解約顧客の分布の尾には、大きなギャップがあるはずです。 コルモゴロフ–スミルノフ検定は、連続した一次元の確率分布の等質性のノンパラメトリック検定で、標本と基準確率分布の比較や、2つの標本の比較に使用することができます。早期警戒システムのモデルでは、顧客と解約顧客について2つの分布を比較します。 t検定は、2つのグループの平均値に有意な差があるかどうか、また、それらがどのように関連しているかを判断するために用いられる推測統計です。他の全てが失敗したとき、特徴量のために有意性を計算します。

その場合、PagerDutyはインシデントを作成し、DataDutyのオンコールデータサイエンティストの1人がその差異を調査することになります。さらに、これらの指標は四半期ごとに調査され、早期警告システムモデル内に新しい特徴量を追加すべきかどうか検討されます。

アップストリームデータドリフト

早期警報システムモデルのアップストリームには、関連する測定基準を保存して潜在的に利用するための集計データテーブルがあります。現在、監視が必要な9つの主要集計テーブルと、集計テーブルが参照する50以上の基本テーブルがあります。データの整合性とアップタイムを維持するために、PagerDutyの技術スタックには以下のようなものがあります。データウェアハウスにはSnowflake、データの整合性を維持するためのMonte Carlo、ジョブのスケジューリングにはApache Airflow、そして問題が発生した場合にインシデントトリアージを実行するPagerDutyが含まれています。例えば、データの「不良負荷」が早期警報システムモデルに影響を与えた場合、PagerDutyはインシデントを作成し、DataDutyのオンコールデータエンジニアに通知します。

PagerDutyとモデルドリフトの例

以下は、DataDutyチームの1人がオンコール中に受信したPagerDutyアラートの実例です。

このデータサイエンティストは、早期警戒システムのモデルスコアに何か問題があるかもしれないというアラートを最初に受け取りました。これらのテストはコンセプトドリフトを捕捉するために設計されているからです。インシデントの発生源は、モデルドリフトテストが存在する「ews_unittest」ソースでした。次に、データサイエンティストはfailed_textを確認し、顧客のリスクスコアの配分が全て予想される許容値より低く、指標の1つにあまり変動がないことに気づきました。データサイエンティストはこれまでの経験から、集計テーブルが更新されなかったため、failed_textのメトリクスは「ゼロになった」可能性が高いと推測しました。数分の調査の後、彼らはこれがインシデントの根本原因であることを確認しました。彼らはこのインシデントをデータエンジニアに再割り当てし、問題のメトリクスの元となる集計テーブルを再読み込みし、モデルの計算を再実行するよう注釈を加えました。30分以内に、モデルは「オールクリア」のサインを出し、カスタマーサクセスマネージャーが問題に気づく前に、正しいスコアが本番環境に送り込まれました。これらの自動テストとPagerDutyの力により、DataDutyチームは組織の運営に影響を与える前に、DataDutyのデータエンジニアの日常とデータサイエンティストの日常を最小限の中断で診断し、インシデントを解決することに成功しました。

データサイエンスモデルが、正確さと稼働時間を重視する組織にとって重要な基盤となった場合、データサイエンスチームは、モデルのドリフトを監視し、問題の最初の兆候で適切なステークホルダーに警告するテストの追加を検討する必要があります。データモデル実務担当者間の信頼を築くことは、ビジネス用機械学習モデルの成功に最も重要です。Kevin Plankはかつて「信頼は一滴ずつ築かれ、バケツごと失われる」と言いました。モデルドリフトがモデルの信頼に影響を与えないようにしてください。

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

続きを読む
インテグレーション&ガイド
2022年7月27日  (更新日:2022年10月13日)

Kubernetes、Linux、その他一般コンポーネントの一般的な診断の自動化

9月14日に開催されるAutomated Diagnosticsウェビナーイベントに登録し、一般的なコンポーネントの一般的な診断方法と、すぐに始められるジョブテンプレートの提供方法について学びましょう。

今回は、PagerDuty Process Automationポートフォリオの一般的なユースケースであるAutomated Diagnosticsに関するシリーズの2回目です。

前回は、Automated Diagnosticsの基本について、また、Automated Diagnosticsを利用することで専門家へのエスカレーションを減らし、レスポンダーがより早くアクションを起こせるようにする方法についてお伝えしました。今回のブログでは、ユーザーにとって最も関係の深いコンポーネントの基本的な診断例について説明します。

しかし、その前に、前回の記事についてTwitterに寄せられた読者の声をもとに、Automated Diagnosticsが該当しないことを明確にしておきましょう。

Automated Diagnosticsとアラート相関は異なります。 アラート相関は、指定された信号の深さと、相関のある信号を適切に識別できるエンジンに依存します。Automated Diagnosticsの目的は、第一レスポンダーが問題の原因を三角測量し、問題を迅速に解決するか、より正確にエスカレーションするかです。 Automated Diagnosticsとモニタリングは別物です。 モニタリングは、パフォーマンスやアクティビティーにおいて望ましくない状態を特定することを目的としています。つまり、ほとんどのモニタリングは、第一レスポンダーのアクティビティーをエミュレートして真偽を確認したり、最初に取るべきアクションを特定したりすることを目的としていないのです。モニタリングは、アラートを上げることに重点を置いています。自動化された診断は、アラートが既に作成された後に、問題を修正する方法を決定することに重点を置いています。

とはいえ、Automated Diagnosticsでは監視ツールで収集したデータを利用することができます。ほとんどの人は、収集した全てのデータポイントに閾値を適用しているわけではありません。 実際、私たちがより一般的に使用している診断インテグレーションの1つは、CloudWatchのログ照会です。ログアグリゲーターを監視ツールと考えるかもしれませんが、純粋に問題を診断するために存在する監視ツールのデータを見ることが調査の最初のステップである場合もあるのです。

レスポンダーに自身の環境のオンデマンドまたは事前診断機能を提供することで、第一レスポンダーが原因を迅速に特定できるようになり、その結果、インシデントをサポートするために必要な人員を減らすことができます。通常、専門家でなければ取得できない「診断」データをレスポンダーに提供することで、トラブルシューティングのために多くの人員を投入する必要性が大幅に軽減されます。これにより、インシデントのコストを削減し、通常は手作業で行われる調査手順を自動化することで、平均応答時間(MTTR)を短縮することができます。

現状を把握する。インシデント対応の自動化

運用管理者は、自己回復や自動修復を可能にするというアイデアに期待することがよくあります。自動化によって解決を早めることは、「治療法を適用すること」と考えるのは自然な傾向です。しかし、多くの場合、「まったく同じインシデントは2つとない」という業界の理論が頭をもたげてきます。変動が大きい場合、自動化が実行される可能性が低くなるため、そのような自動化の価値は低下します。例えば、今日の問題を解決するためにコアサービスを再起動することは正しい方法かもしれませんが、明日には障害が連鎖し、さらに大きなインシデントにつながる可能性があります。

読者はここで、対応の初期段階に認知のギアを切り替えます。

しかし、非常に繰り返しが多くなる傾向があるのは何か、ご存知でしょうか。何が問題だったのかを診断し、何が起こったのかを判断するためにレスポンダーが行う調査手順そのものです。繰り返しが多いということは、自動化によって得られる価値も多いということです。例えば、Kubernetesディストリビューションでインシデントが発生したとします。インシデントの性質的にイメージリポジトリーかロードバランサーかを問わず、おそらくKubernetesログを引き出すという同じ診断ステップを取ることになるでしょう。

これらの診断手順はほとんどの場合、固定です。作業しているコンポーネントにより、発生したインシデントの優先順位は関係ありません。Automated Diagnosticsは、異なる種類のインシデントに適用できます。繰り返し発生する同種のインシデント専用に構築する必要はなく、一般的なコンポーネントのあらゆる種類と深刻度を対象に、お客様の環境に合わせてカスタマイズして適用することができます。これは、病院に行くようなものだと考えてください。特定の症状で緊急医療を受ける場合でも、年に一度の健康診断を受ける場合でも、診察室に入ってから体温、血圧、体重を測定します。

一般的な例

開発者の環境はそれぞれ異なりますが、一旦蓋を開けてみると、多くの環境は非常によく似ています。レスポンスの初期段階では、ほとんどの診断が3つの主要なデータソースから行われます。

アプリケーションデータ** システムデータ** 環境データ**

一般的な診断やコンポーネントは、レスポンス開始時に自動的に引き出される例がいくつかあります。これはレスポンダーがインシデントの重大性をよりよく理解するのに役立つだけでなく、レスポンダーが多くの専門家を巻き込みすぎて通常の業務を中断させないようにするのにも役立つでしょう。例えば、インシデント発生時にレスポンダーが使用するコンポーネントとしてKubernetes(k8s)を見てみましょう。k8s環境内でインシデントが発生した場合、この技術を維持するインフラエンジニアは通常、次のようなアクションを実行することになります。

k8sのPodからテールログを取得する k8sからセレクターラベルでログを取得する イメージリポジトリーを確認する デプロイメントを記述する Podでコマンドを実行する

これらのアクションに共通することは、1つだけです。インシデントを受任した一般的なL1レスポンダーは、これらのアクションをどのように構成すれば良いのか分かりません。しかし、PagerDutyのAutomated Diagnosticsのすぐに使えるジョブがあれば、L1レスポンダーは自動的にこれらの診断を実行し、ジョブを実行することができます。

一般的な診断やアラートの例としては、以下のようなものがあります。

CPU/メモリ消費型サービス よくあるアラート: CPU/メモリ使用率が高い よくある質問: どのサービスがCPUやメモリを消費しているか ファイルサイズ / ディスク消費量 よくあるアラート: CPU/メモリ使用率が高い よくある質問: どのファイル/ディレクトリーが最も容量を消費しているか システムログ:Linux/Windowsコマンド よくあるアラート: サーバー/サービスの問題 よくある質問: OSの問題か、アプリの問題か SQLデータベースコマンド よくあるアラート: データベースブロック/デッドロック よくある質問: 長時間稼働しているクエリーが他のデータベース要求をブロックしていないか ホストの可用性 よくあるアラート: ホストの停止 よくある質問: 実際にダウンしているのか、それとも誤検出による到達性の問題か アプリケーションのエラー:アプリケーションログまたはトレース よくあるアラート: 400/500エラーコード よくある質問: スタックトレースとは何か

既知の部品に対する一般的な診断のいくつかの例を示します。

Cloudwatchのログ:** 特定のアプリケーションとVPCのログを表面化させる。 ECS:** 停止したECSタスクのエラーを表示させる。 ELB:** 利用できないターゲットグループインスタンスをデバッグする。 Kubernetes:** Podsからセレクターラベルでログを取得する。 Linux:** サービスステータスを取得する。 Nginx:** エラーログを取得する。 Redis:** ログエントリーを低速にする。

また、これらはAutomated Diagnosticsソリューションガイドに掲載されている、ユーザーのために構築した30以上のすぐ使えるジョブテンプレートの一部に過ぎません。Automated Diagnosticsソリューションを使用するには、PagerDutyランブックオートメーションライセンスまたはProcess Automation(旧Rundeck Enterprise)ライセンスのいずれかが必要です。使用方法の詳細については、FAQを参照してください。どちらのライセンスもお持ちでない場合は、弊社までお問い合わせください。

PagerDuty内の診断の自動化

レスポンダーに通知されるインシデントには、アラートに対して「近視眼的な」見方をする監視ツールから提供される情報が多く含まれます。よくある例としては、CPU使用率の高さがアラートのトリガーとなり、レスポンダーに通知されるというものです。しかし、アラートに含まれる情報は表面的なもので、急増したCPUの原因が何であるかが特定されていません。

診断データ は、インシデントの「なぜ」「どこで」という質問に答えるのに役立つ、より深いレベルの情報です。モニタリングや相関ツールの中には、ユーザーに根本的な原因分析を提供するのに役立つものもありますが、そのほとんどは、異種のデータソースを統合ビューに照合するレスポンダーの調査/トラブルシューティングの手順をエミュレートする能力において不足しています。オンデマンドまたは事前実行の診断機能をレスポンダーに提供することで、最初のレスポンダーが自分で問題を解決する確率が高まり、インシデントを支援するための人員も少なくて済む可能性が高まります。Automated Diagnosticsの出番です。

使用するコンポーネントの一般的な診断についてもっと知りたいですか?PagerDutyのシニアソリューションコンサルタントのJustyn Robertsが登壇する9月14日に開催されるウェビナーイベントにご登録ください。Process Automationは初めてですか?デモをリクエストしてください。既にPageDutyのProcess Automationをお使いですか?Automated Dianosticsソリューションガイドをご覧になり、完全なソリューションを実現するためのエンドツーエンドプロセスをご確認ください。ご質問は、Twitterで@sordnamに直接ください。お話ししましょう。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

続きを読む
インテグレーション&ガイド
2022年6月7日  (更新日:2022年9月14日)     |    インテグレーション&ガイド

PagerDutyプラットフォーム上でのAutomated Actionsの拡張

PagerDuty Summitの初日です。専門的なプレゼンター、実用的なコンテンツ、教育セッションで、あなたのPagerDuty IQを高め、あなたのチームの運用エクセレンスを向上させる新しい方法をお見せできることを楽しみにしています。

このコンファレンスでは、私たちの大きなミッションが語られます。オペレーションに革命を起こし、チームが事後対応や修復作業に費やす時間を減らし、新しいイノベーションの実現により多くの時間を割けるようにすること です。PagerDutyでは、このオペレーションの未来は、ソフトウェアの構築と運用を行うデジタルチームだけでなく、組織内の全てのチームにまで広がると考えています。このミッションを実現するために多くのPagerDuty製品と機能が存在しますが、今回はPagerDuty Process Automation®ポートフォリオの一部で、最新かつ最高のPagerDuty Automation Actions®に焦点を当てたいと思います。

新しいアップデートとAutomation Actionsとの統合

Automation Actions は、第一線のレスポンダーをPagerDuty内の修正オートメーションに直接つなげます。インシデントが発生したときに専門家にエスカレーションする代わりに、対応者は安全に委譲された自動化機能を使用して、インシデントのトリアージと解決を自分で行うことができます。その結果、チームはMTTRを短縮し、専門家の業務中断を減らし、インシデントの診断と修復を迅速に行うことができます。

私たちは昨年、組織が自動化へのシンプルな第一歩を素早く始められるよう、Automation Actionsを発表しました。現在、Automation ActionsはPagerDutyプラットフォーム全体に統合されています。全てのユーザーが、ブリッジコールに持ち込まれた問題の診断などの手動で時間がかかる反復作業を取り除くことができます。

Automation Actionsを使った最新かつ最高の自動化機能を見てみましょう。

インシデント対応におけるAutomation Actions。** チームは、PagerDuty内で直接、自動化された診断を実行し、インシデントを修復することができるようになりました。このインテグレーションにより、繰り返しの多い手作業が自動化され、生産性が向上し、エンジニアがイノベーションに集中するための時間を取り戻せます。

カスタマーサービスオペレーションのためのAutomation Actions。** この統合により、カスタマーサービス担当者は、顧客の問題を検証し、自動化によって重要な情報を取得し、ケースの診断と解決を迅速に行うことができるようになりました。エージェントは、顧客に影響を与える問題を検証し、Service CloudのPagerDutyアプリケーションから直接自動化されたアクションを実行することができるようになりました。

Event OrchestrationのためのAutomation Actions。** ネストされたイベントルールと機械学習、正確な自動化トリガーを組み合わせることで、レスポンダーが呼び出される前にインシデントに対処できます。Event Orchestrationとの統合により、一般的な診断を自動化し、繰り返し発生し熟知された種類のインシデントの自己回復を可能にし、MTTRと専門家へのエスカレーションを削減することができます。

PagerDutyのモバイルアプリでの自動化アクション。** Automation Actionsの全てがモバイルに対応しました!Automation Actionsから同じ自動化を呼び出して、PagerDutyモバイルアプリから直接一般的なインシデントを解決します。

Slackでの自動化アクション。** このインテグレーションにより、インシデントレスポンダーはスクリプト可能な診断と修復アクションをSlackから直接展開できます。

あらゆる場所で自動化

デジタルの複雑性と依存性が高まる中で何にでも対応できるようにするためには、手動、硬直的、チケットキューをベースとしたオペレーションから、成果と顧客体験を重視し、運用スピードと回復力を実現し、機械学習とAIによって大幅に自動化された、継続的に改善されるシステムへと変革する必要があります。 そうすることで、チームはより積極的な姿勢に移行し、手作業の負担を軽減し、燃え尽き症候群を回避し、集中力を維持することができるのです。Automation Actionsを使用することで、チームはこの運用上のマイルストーンに到達できるだけでなく、自動化能力をさらに向上させ、成熟させ続けることができるのです。

PagerDutyサミットでAutomation Actions関連セッションもチェックしてください。

Normalize Automation** , Sean Noble, Principal Product Manager, PagerDuty Is it the Cloud? App? Database? Reduce Escalations by giving first responders automated diagnostics** , Jake Cohen, Senior Product Manager, PagerDuty

PagerDutyの自動化ポートフォリオについてもっと知りたい方は、自動化ハブをご覧ください。PagerDuty Automation Actionsについて、また、それがどのようにチームの時間とコストの節約につながるかを知りたい場合は、アカウントマネージャーに連絡するか、今すぐ詳細をご覧ください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

2022年6月5日  (更新日:2022年9月14日)     |    インテグレーション&ガイド

PagerDuty for Google Chatを提供開始

私たちPagerDutyの目標は、お客様が働いている場所で、お持ちのツールで対応できるようにすることです。私たちは、補完的なテクノロジーパートナーとの650以上のインテグレーションを提供できることを嬉しく思っています。これらのインテグレーションにより、お客様はPagerDutyプラットフォームから得られる価値を最大化することができ、また独自のインシデント対応プロセスを定義することができます。

本日、PagerDuty for Google Chatを発表することができました。PagerDuty for Google Chatは、GoogleがPagerDutyとの緊密な協力のもとに構築したものです。PagerDuty for Google Chatは、インシデントレスポンダーが通知を受け、解決を開始し、コンテキストを切り替えることなく目の前の問題に集中することを可能にします。 重要なアクションは、適切なチームメンバーを含むGoogle Chatの会話から開始することができ、また、追加のステークホルダーに適切なレベルの可視性を提供することができます。

GoogleスペースからPagerDuty for Google Chatをインストールするには、次の3つの簡単なステップを実行します。

コマンド「@PagerDuty」を入力します(アプリのインストール権限をGoogle管理者から付与される必要があります)。 インテグレーションを承認します(サブドメインのAdminまたはAccount Owner権限を持つPagerDutyアカウントにサインインします)。 PagerDuty ServicesとGoogle Spaceを連携させるために、「/pd_settings」コマンドを実行します。

PagerDuty for Google Chatがインストールされ、設定されると、以下のことが可能になります。

Googleチャットからインシデントを管理

インシデントレスポンダーは、トリガー、通知、承認、解決などのインシデント対応の主要なアクションを、すべてGoogle Chatの会話から離れることなく実行できます。

インシデント対応と解決の迅速化

レスポンダーは、自分やチームメイトが働いている場所で発生した新しいインシデントについて、Google Chatでリアルタイムに通知されます。デスクでも、外出先の携帯電話でも、どこにいてもです。

適切なチームメンバーとの協働

対応者は、専用のウォールーム(またの名をGoogle Space)を作成し、必要な専門家を追加することができます。これにより、ステークホルダーに可視性を提供し、より迅速なコラボレーションを実現することで、インシデントの解決を早めることができます。

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

2022年3月17日  (更新日:2022年9月13日)     |    インテグレーション&ガイド

ギャップを埋める:正しい方法で自動化を導入する

企業における自動化は新しいことではありません。エンジニアは何十年も前から自動化ツールやフレームワークを使って仕事をしてきました。構成管理ツール、継続的インテグレーションとデリバリーパイプライン、クラウドの形成など、自動化はビジネスシーンにおけるほぼ全ての技術的なユースケースの構成要素となっています。こうしたことが本当なら、なぜ自動化はいまだに多くの手作業と対になっているのでしょうか。

その答えは?IT部門とそれ以外の部門に自動化を広く普及させるには、まだ明らかな遅れがあるのです。例えば、今日の企業の大半は、製品、サービス、ヘルプデスク、その他の顧客向けアプリケーションなど、何らかの形でデジタルサービスを提供しています。そして、ほとんどの企業は、そのサービス提供の展開や維持のために、IT組織内である程度の自動化を活用しています。しかし、自動化は利用されていても、その価値が十分に発揮されていないことがよくあります。自動化の利用は通常、ビジネスの小さな領域に限定され、自動化を実装または構築した従業員のみがそれを使用し適用することができます。

私たちはこれをオートメーションギャップと呼んでいます。

オートメーションギャップ オートメーションギャップとは、組織内の自動化の利用が島ごとに存在し、各専門業務部門がサイロ化した自動化を活用しているというシナリオです。さらに、オートメーションギャップがあるということは、(専門家以外の)ほとんどの従業員が、自動化を実際に利用するための系統的な知識、スキルセット、組織全体のアクセス権を有していないことを意味します。

ITの視点から見ると、オートメーションギャップは業務を停滞させ、次のような大きなビジネス上の問題につながる可能性があります。

専門家へのエスカレーションが絶えず、イノベーション能力が制限される SLAペナルティーとインシデント解決の遅れによるエラー率の増加 予定外の仕事や依頼が殺到し、専門家が燃え尽きる 最終的には顧客の不満と収益の損失につながる

デジタル世界における技術革新のスピードと消費者の期待の高まりを考慮すると、オートメーションギャップがもたらす負の外部性は、日が経つにつれて悪化または拡大する一方でしょう。しかし、問題に対処し、ギャップを埋める前に、ギャップの存在の根本的な要因を特定し、理解できるようにする必要があります。

オートメーションギャップの特徴は、大きく3つの要素に分類されます。 ナレッジギャップ スキルギャップ アクセスギャップ

ナレッジギャップ あらゆる規模のデジタルファーストの組織は、顧客のニーズを満たし、イノベーションに歩調を合わせ、競争に勝ち残るために、常に変革を続けなければなりません。この進化を成功に導くためには、デジタルインフラも並行して適応し、進化していく必要があります。しかし、進化は一夜にして起こるものではありません。進化は、何年にもわたるDX、従業員や文化の変遷、新たな複雑性や技術的な依存関係を経て、レガシーインフラの上で発生するものなのです。適切な文書化と理解なしには、シームレスな実行はほぼ不可能です。

ナレッジギャップとは、1人の個人または社員が、IT組織内のあらゆる依存関係、システム、ベストプラクティスについて、専門家になれるわけではないことを理解することです。例えば5年以上勤続している元社員は、レガシーインフラのインシデントに取り組むための系統的な知識を持っているかもしれませんが、8カ月勤務しているオンコール対応者は、同じ基礎インフラについて微妙な理解を持っていないかもしれません。

スキルギャップ スキルギャップとは、ユーザーによって技術的なスキルセットが異なるという現実のことです。ナレッジギャップと同様に、スキルギャップも組織のデジタルインフラ全体における新しいテクノロジーと複雑性を専門に扱う従業員に起因しています。新しいシステムやプロセスが導入されると、多くの場合、それらを構築または実装した専門家 (SME)が、必然的にインシデントが発生したときに問題を適切にトリアージできる唯一の人物となります。このような専門性のボトルネックは、対応のライフサイクルに悪影響を与え、専門家を疲れさせ、修復作業の効率を低下させる可能性があります。このギャップは、特に人員削減の時期に顕著で、XシステムやYサービスに必要な理解とスキルを持つ専門家が、1人か2人しかいなくなった場合に生じます。

誰もがデータベースの管理方法や継続的インテグレーションのパイプラインの自動化方法を知っているわけではありません。実際、企業で最も高いスキルを持つ技術者は、通常そのような需要があるため、その作業を軽減できればビジネスのスケールに貢献します。繰り返し行われる診断や手順を常に中小企業にエスカレーションすることは、予定外の作業を生み出し、本来なら専門家が優先すべき価値の高い作業の妨げになります。このような技術的な役割を担う人材の獲得は増加の一途をたどっており、このギャップを解消することは、企業にとって長期的な取り組みがより一層重要となっています。

アクセスギャップ 最後に、アクセスギャップは、今日のベストプラクティスに従ってセキュリティー体制を維持することに関連しています。 最小特権アクセスの原則に従えば、スーパーユーザーの資格情報をITスタッフ間で広く配布したり、共有したりしてはいけません。ツール、情報、システムに適切にアクセスできなければ、解決に要する時間の長期化、修復作業の非効率化、中小企業が価値の高い作業に集中する時間の短縮など、アクセス不足に起因する悪影響が生じます。

では、PagerDutyはどのようにしてこのオートメーションギャップを埋め、ITオペレーション全体の敏捷性を向上させ、チームがより速くイノベーションを起こせるようにするのでしょうか。

アプリケーションオートメーション PagerDutyの自動化機能により、これまで専門エンジニアにしかできなかったことがエンドユーザーにもできるようになります。このプラットフォームは、自動化を他の関係者に安全に委譲し、エスカレーションの中断をなくし、待ち時間を劇的に短縮することで、これらのギャップを埋めるように設計されています。これらのプロセスは、既存のタスク自動化を運用ワークフローの個々のステップに組み込むことができ、一貫した運用体験を提供しながら、プロセスのユーザーから各ステップの特定のコンテキストを抽象化できます。

PagerDuty® Process Automationのポートフォリオは、以下の製品で構成されています。

PagerDuty® Automation Actions:PagerDutyのレスポンダーをキュレーションし、インシデントに関与するサービスの自動診断と修復につなげるPagerDutyアドオンです。 PagerDuty® Runbook Automation:エンジニアがランブックの手順を標準化・自動化し、サービスをセルフサービス型オペレーションとして委譲できるSaaSサービス。 PagerDuty® Process Automation On-Prem:エンジニアがエンドツーエンドの運用ワークフローを標準化・自動化し、関係者にセルフサービス型オペレーションとして安全に委ねることができるセルフホスティング型ソフトウェア群です。

PagerDutyの自動化機能は、エンドユーザーと認証情報やキーを明示的に共有することなく自動ワークフローを呼び出せるため、組織がアクセスギャップを安全に解消するのにも役立ちます。シングルサインオン(SSO)と統合してロールベースのアクセス制御を可能にし、プロセスレベルとステップレベルの両方で全てのアクティビティーを記録して、コンプライアンス要件を満たします。

PagerDutyの自動化機能がオートメーションギャップを埋める過程でどう役立つかについては、https://www.pagerduty.com/use-cases/automation/ をご覧ください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

2022年2月14日  (更新日:2022年9月12日)     |    インテグレーション&ガイド

PagerDutyからSlackの新ネイティブ機能が登場 - 今すぐ利用可能

PagerDutyでは、お客様の声に耳を傾けることにかなりの時間を費やしています。対話で学んだことを生かし、私たちはSlack Integrationに新しい機能セットを追加しています。これらの機能により、SlackからのPagerDuty活用がよりシームレスになり、インシデントレスポンダーはコンテキストを切り替えることなく作業に入れるようになり、対応時間を短縮し、最終的に高い顧客満足度を維持できるようになります。

最新のSlack V2 on Webhooks V3 Integrationでは、以下の機能が利用可能になりました。

SlackのSingle Connection Managementページ。インテグレーション管理用のページを1つ持つことで、設定に必要なクリック数を減らし、手順を省き、価値創造までの時間を加速させます。 このページでは、PagerDutyのチームとSlackチャンネルを接続するだけでなく、多対多のワークスペースとPagerDutyのマッピングを行えます。

ステークホルダー専用情報共有チャンネルで、レスポンダーによるインシデント報告の投稿を容易に。ステークホルダーチャンネルはインシデントチャンネルとは異なり、レスポンダーの対応速度を落とすことなく、ステークホルダーが適切なインシデントの詳細やアップデートを閲覧できるようになっています。レスポンダーは、コンテキストを切り替えることなく、Slack から "Stakeholder Updates and Resolution Notes"(訳注:ステークホルダー向けの最新情報と解決をまとめたメモ)を作れます。

柔軟なRundeckアクションによる診断と修復。インシデントレスポンダーはスクリプト化可能な診断と修復アクションをSlackから直接デプロイできるようになりました。Rundeck Actions on Slackの詳細については、こちらのブログをご覧ください。

これらのアップデートにより、Slackから直接仕事ができるようになると思います。あなたが働いている場所で働き続けられるように、近日中に新しい機能拡張を追加しますので、ご期待ください。 Slack V2以前のバージョンからご利用のユーザーの皆様へ、これらの機能と今後リリースされる全ての機能をご利用いただくために、管理者がWebhooks V3でSlack V2への移行を実施済みであることをご確認ください。ご不明な点がございましたら、サポートまで(サポートメールで)ご連絡ください。まだ弊社のお客様でない場合は、14日間の無料トライアルにご登録ください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

2022年2月3日  (更新日:2022年9月12日)     |    インテグレーション&ガイド

PagerDuty RundeckのアクションをPagerDuty Slackインテグレーション内で呼び出せすことが可能に

インシデントを迅速に解決するために、協力して問題を診断する

昨年、私たちはPagerDuty Rundeck Actionsをリリースしました。これは、PagerDutyのインシデント対応ワークフローにおいて、レスポンダーを一般的な問題の自動診断と修復に直接つなげるためのPagerDutyアドオン製品です。お客様と協力し、コミュニティーの声に耳を傾けた結果、PagerDuty Rundeck ActionsがPagerDutyのSlackと統合されたことを発表します。

オートメーションとコラボレーションの融合

今回のインテグレーションにより、レスポンダーはSlackチャンネルから直接、自動診断と修復アクションを展開できるようになりました。これにより、ターミナルからサービスにアクセスしてウインドウを切り替える必要がなくなり、より迅速かつ効率的にインシデントを解決し、専門家へのエスカレーションを減せます。

1つの問題に対処するために、2台のモニターに複数のウインドウを表示させる時代は終わりました。インシデントの状況をステークホルダーに伝えるだけでなく、同じウインドウから修復アクションを展開することができます。インシデントが発生すると、レスポンダーはSlackインスタンス内にインシデント専用のチャンネルをすばやく作成し、影響を受けるチームやステークホルダーとコラボレーションし、診断手順を実行し、オートメーションを呼び出してリアルタイムに問題を修復できます。

CollabOpsの実践

第一線のレスポンダーや担当者は、IT部門全体で構築したつながり(具体的にはPagerDuty・Rundeckと統合したアプリケーションやサービス)を活用し、チャットボットを導入してアクションを実行させることができます。問題をエスカレーションして上に受け渡すのではなく、このインテグレーションにより、仕事に適した人材がいる専用チャンネルにインシデントをすぐに投下し、修正に向けて共同作業を行えます。また、この統合は、インシデントが発生すると、そのロジスティクスを積極的にキャプチャーして記録し、文書化プロセスを完全に透明化して、全てのステークホルダーがアクセスできるようにします。

Rundeckアクションの仕組み

PagerDuty Rundeck Actions を使うと、エンジニアは手間がかかり繰り返し行われる診断手順の自動アクションを作成してレスポンダーに委任できるようになり、繰り返し行われるタスクに費やされる時間を削減できます。また、フェイルオーバーなどの一般的な低減アプローチやその他の修復手法の自動化も含まれます。 既知の問題に対するシンプルで繰り返し適用できる修復法も、イベントトリガーを使って人間の介入なしに発動できるので、緊急の問題だったものを解決済みの後処理に変えることができます。PagerDutyで作業するレスポンダーがインシデントの解決を加速できるように、Rundeck ActionsはAutomated Diagnosticsと修復をインシデント対応ワークフローにつなげます。 Automated Diagnosticsは、インシデント発生時にレスポンダーが呼び出せる、本番サービス用の自動化されたアクションのセットです。一般的なテストを手動で実行する専門家にエスカレーションするのではなく、第一レスポンダーはPagerDutyから安全にこの自動化を呼び出すことができ、インシデントタイムラインにリアルタイムで返されるレスポンスを確認できます。

PagerDuty Rundeck Actionsを使用すると、チームは以下のことが可能になります。 レスポンスタイムを最大30分短縮 Slack経由でレスポンスチーム全体に専門知識を共有 レスポンダーが呼び出される前に、人的支援と自己修復の自動化を開始 ファイアウォールやVPCの内側で安全な自動化を実行 手作業に代わる自動化されたアクションを導入 円滑なポストモーテムとオペレーター作業軽減のためのインシデントの文書化を充実

Rundeck Actionsがどのように機能するかについてもっと知るには、ナレッジベースをチェックしてください。さらに、アカウントマネージャに連絡するか、デモをリクエストしてください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

2022年4月4日  (更新日:2022年9月9日)     |    インテグレーション&ガイド

PagerDuty® Automation Actionsでチームの自動化能力を民主化する

現実を直視しましょう。インシデントは高くつくものです、本当に。しかし、本番環境におけるインシデントの高いコストは、必ずしもサービスの低下やネガティブな顧客体験が原因とは限りません。PagerDutyのレスポンスデータによると、インシデント収束までの時間の50%以上は、最初のレスポンダーによる調査と出動段階(私たちは「トリアージ」と呼んでいます)に費やされています。 言い換えると、問題を見極め、解決するのに適役を呼び出す部分です。

上記の統計を考慮すると、インシデントライフサイクルの影の経費は、インシデントを発見したエンジニア、問題に対応し根本原因を特定したオンコールエンジニア、その他インシデントライフサイクルに動員されるあらゆる分野の専門家の時間であることは明らかです。さらに、対応プロセス全体に手作業が加わると、コストがかさみます。非常に高くつきます。

実際のところ、開発組織の時間は、ビジネスの利益と同じくらい貴重で重要です。そして、サービスやアプリケーションの開発が複雑化するにつれて、「削減された時間」は、追跡、定量化、および継続的な改善を行うための、より重要な指標となります。インシデント対応プロセスのさまざまな側面を自動化する方法を見つけることは、チームの時間を節約し、全体的な効率を高めるのに役立ちます。どうすればいいのでしょうか?PagerDuty® Automation Actions(旧PagerDuty Rundeck Actions)の出番です。

PagerDuty® Automation Actions

PagerDuty® Automation Actionsアドオンは、第一線のレスポンダーをPagerDuty内の修正オートメーションに直接接続します。インシデントが発生したときに専門家にエスカレーションする代わりに、レスポンダーは安全に委譲された自動化機能を使用してインシデントのトリアージと解決を自分で行うことができます。その結果、チームはMTTRを短縮し、専門家の業務中断を減らし、インシデントを迅速に診断して修復することができます。

PagerDuty® Automation Actionsは、自動化された診断と修復をインシデント対応ワークフローに接続します。Automated Diagnosticsとは、インシデント発生時にレスポンダーが自動的に呼び出すことができる、本番サービス用のアクションのセットです。専門家にエスカレーションして一般的なテストを手動で実行させるのではなく、レスポンダーはPagerDutyから安全かつ確実にこの自動診断を実行し、インシデントタイムラインにリアルタイムで返されるレスポンスを確認することができます。

サービスの再起動や診断など、指定されたアクションを実行することができます。

これらの診断テストにより、レスポンダーは、大人数を巻き込んだり、一般的なレスポンダーの階層をエスカレーションすることなく、より効率的に適切な専門家にインシデントをエスカレーションして解決できます。専門家は、これらの一般的な診断の結果を見て、すぐに取りかかることができます。

さらに、チームはSlackインスタンスから直接これらのアクションを呼び出してインシデントについて共同作業を行うこともできます。これにより、ターミナルからサービスにアクセスしたり、ウインドウを切り替える必要がなくなり、より迅速かつ効率的にインシデントを解決できるようになり、専門家へのエスカレーションも減らすことができます。自動診断の利用が進むと、Event Intelligenceを利用した自動修復やトリガーなどの用途にも利用できるようになります。

PagerDuty® Automation Actionsは、組織の応答プロセスにおける4つの主要な問題領域を解決するのに役立ちます。

サイロ化された専門知識。** 第一線のレスポンダーは、組織の環境内にある全てのアプリケーションやサービスの遺伝子構成を把握しているわけではありません。 専門家への絶え間ない割り込み。** レスポンダーは、そのアプリケーションやサービスの専門家と思われるエンジニアにエスカレーションを行い、イノベーションを妨げ、インシデント収束を鈍化させています。 繰り返し、手動の診断手順。** インシデント発生時の最初のステップは、大体同じです。インシデントの解決に取り組む以前に、これらの同じ手動ステップを踏んでおく必要があります。 複雑で広大な本番環境。** どのシステムにアクセスし、どのようなアクションを取るべきかを知るには、時間を要することがあります。さらに、全ての対応者が特定の本番システムにアクセスする権限を持っているとは限らず、エスカレーションプロセスを難しく長引かせることがよくあります。

PagerDuty® Automation Actionsは、上記の課題を次のように解決します。

チーム間でオートメーションを委譲する。** 通常専門家が呼び出す自動化された手順を、第一線のレスポンダーに展開する。 より少ないエスカレーションで、より早くインシデントを解決する。** 一般的なリクエストや作業を自動化することで、エスカレーション先を特定する時間を減らし、より多くの時間を修正に費やすことができます。 人手を介した支援・自己回復の自動化を誘発する。** PagerDutyのEvent Orchestrationにより、レスポンダーが呼び出される前に診断アクションを呼び出すことができます。 セキュリティーを考慮した自動化の安全な発動。** レスポンダーは、インシデントの影響を受けるシステムに対して実行する権限を持つアクションのみを表示します。全てのアクションはログに記録されるため、強固なセキュリティー体制を維持することができます。

以上のことを簡単に箇条書きでまとめると、PagerDuty® Automation Actionsはチームを支援します。

応答時間を最大30分短縮、MTTRを最大25%短縮 エスカレーションされるインシデントの量を削減 対応チームに専門知識を共有 レスポンダーが呼び出される前に、人手を介した支援と自己回復の自動化を開始 ファイアウォールやVPCの背後にある安全な自動化を誘発 手作業に代わる自動化されたアクションを導入 事後検証の円滑化、オペレーターの作業軽減のためのインシデント文書化の充実

PagerDutyの自動化ポートフォリオについてもっと知りたい方は、自動化ハブをご覧ください。PagerDuty Automation Actionsについて、また、それがどのようにチームの時間とコストの節約につながるかを知りたい場合は、アカウントマネージャーに連絡するか、今すぐ詳細をご覧ください。

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

2022年3月29日  (更新日:2022年9月9日)     |    インテグレーション&ガイド

セルフマネージドオートメーションとSaaSオートメーションの選択における5つの考慮点

新しいものよりも伝統的なものの方が良い場合があります。ニューコークよりコカ・コーラ クラシックが好きな人もいるし、普通のトマトより伝統野菜としてのトマトが好きな人もいます。

クラウドコンピューティングについても、同じことを言う人がいるかもしれません。「(アプリやデータを)クラウドに置くのは嫌!自前のデータセンターで自分で動かした方が、より(安全だ、信頼性が高い、安い)から」。

話を戻します。私たちの新しいSaaS製品であるPagerDuty® Runbook Automationよりも、PagerDuty® Process Automation On Prem(以前はRundeck Enterpriseとして知られていました)のセルフマネージドバージョンを選択する正当な理由があるのです。昔のものの方が良いというのは今回は当てはまりません。Rundeckのオープンソースプロジェクトで開発された同じコードを使用しています。この場合、SaaSの自動化ソリューションが提供できる以上の柔軟性があれば、あなたの要件やユースケースをよりよく満たすことができるかもしれないということなのです。

どちらにするか迷っていますか?ここでは、あなたのユースケースに適したオファーを決めるのに役立つ5つの考慮事項を紹介します。

  1. アプリケーションとインフラはクラウドではなく自己管理か

アプリケーションとそのスタックは、自社のデータセンターや、クラウドのハイパースケーラー以外のホスティングプロバイダーで稼働しているかもしれません。これは、アプリケーションが最初にデプロイされたのがレガシーな理由であり、クラウドへの移行に投資するには戦略的すぎる(または戦略的でない)ことが原因である可能性があります。また、パブリッククラウドでは実現が困難な特殊な要件(いくつかを以下で説明します)がある場合もあります。簡単に言えば、あなたの会社がITに資本を投下し、専門性を高める場所を選択しているかどうかを反映しているのです。実際、自社でインフラを運用することがコスト抑制や収益性の源泉になる場合もあります。AWSの売上総利益率は60%以上と言われています。最後に、あなたの会社はデジタルサービスを大規模に提供しており、自社でインフラを運用することは、品質の確保やイノベーションのスピードアップの一環であるのかもしれません。

PagerDuty® Runbook Automationは、あらゆるクラウド環境またはセルフホスト環境に安全に接続できるように構築されており、多くの典型的なユースケースに対応することができます。しかし、チームのスキルセットが自己管理環境に向いている場合、PagerDuty® Process Automationソフトウェアを自分で実行する方がより理にかなっている可能性があります。このような場合、PagerDuty® Process Automation On Premを実行することで、経験豊富なエンジニアが専門知識を活かしてセルフサービスの自動化を構築し、それを他のユーザーに委ねることができるため、社内業務の拡張に役立ちます。PagerDuty® Runbook Automationをリモート環境に接続するのと同じ安全な接続性により、チームは異種のデータセンターを安全に接続して集中型自動化を行うことができます。実際、これらの環境へのリモートSSHアクセスを許可する必要性を削減または排除することで、セキュリティーをさらに向上させることができるかもしれません。

  1. より厳しいコンプライアンス基準を満たす必要があるか

HIPAA、PCI、FedRAMPの要件に適合する必要がありますか?ITプロバイダーがSOC2に準拠していることを要求していますか?もしそうであれば、少なくとも短期的には、SaaSを利用するよりもPagerDuty® Process Automation On Premを運用する方がよいかもしれません。

PagerDuty® Runbook Automationはこのような標準に準拠するように構築されていますが、私たちはこの3月にローンチしたばかりです。このような標準を達成するには、ある程度の運用実績が必要です。PagerDuty®には、高品質のサービスを構築してきた大きな経験があり、PagerDuty® Runbook Automationの開発にも活かされています。SOC2認証の取得については、できるだけ早く発表したいと考えています。より多くの認証の取得に近づくにつれ、予想される利用可能性をお伝えしていきます。

  1. データ主権要件に該当するか

多くの国では、個人を特定できる情報(PII)や財務データなど、国民に関する特定の種類のデータを自国の国境内に保存することを義務付けています。PagerDuty® Runbook AutomationはSaaSとして提供され、インターネット経由でアクセスできるあらゆるITインフラの自動化に利用することができます。ただし、現在は北米でホスティングされており、将来的にはヨーロッパでホスティングする予定です。

もしあなたの会社やアプリケーションがそのようなデータ主権要件の対象となるのであれば、代わりにPagerDuty® Process Automation On Premを利用することが理にかなっていると言えるかもしれません。私たちのSaaSサービスは、ユーザーアカウントに必要なもの以外の個人データを直接保存しません。しかし、作成するオートメーションがこのような規制の違反につながる可能性がある場合、自社のインフラ内に自社の自動化環境をホスティングすることで、コンプライアンスを示すことが容易になる場合があります。

  1. オートメーションに組み込むべきインフラとは

PagerDuty® Process Automation On Premは、PagerDutyが開発しサポートするプラグインと、Rundeckオープンソースコミュニティーが開発するプラグインの両方を幅広く提供します。これはオートメーション開発者がいくつかの種類のインフラをオートメーションに取り入れるための選択肢と柔軟性を提供します。

コミュニティーで非常に多くのプラグインが利用可能な理由の1つは、PagerDuty® Process Automation On Premが柔軟なプラグインAPIを備えていることです。これにより、ノード、ジョブステップ、UI統合、クレデンシャルストレージなど、ジョブ定義に利用したい自社製またはあまり一般的ではないインフラのための独自のプラグインをユーザーがシームレスに開発することができます。

PagerDutyは、厳しいセキュリティーと信頼性の要件を満たすために、当社のSaaSサービスであるPagerDuty® Runbook Automationを運営しています。つまり、私たちが提供できるプラグインは、これらの要件を満たすためにテストされ、認定されたものだけです。同じ理由で、カスタムプラグインも現時点ではサポートされていません。

PagerDuty® Process Automation On Premでファイアウォールの内側で使用するには十分安全ですが、PagerDuty® Runbook Automationではサポートされていないプラグインの一覧はこちらです。

自動化したいインフラの種類が多い場合、PagerDuty® Process Automation On Premが豊富な要件を満たす柔軟性を備えていることがお分かりいただけると思います。

  1. どのようなセキュリティー要件に対応する必要があるか

PagerDuty® Runbook Automationは、厳しい要件を満たすために強化されたセキュリティーで構築されており、セキュリティーとコンプライアンス要件への準拠を最適化することができます。例えば、PagerDuty® Runbook Automationは、HTTPSを使用してエンドポイントにコールバックするRunnerを使用してインフラに接続します。このため、ファイアウォールに追加のポートを開く必要がありません。Runbook Automationは、Okta、Ping、Azure ADなどのクラウドSSOや、Hashicorp Vault、CyberArk、Thycoticなどの機密管理SaaSサービスと統合されています。特権的なアクションへのアクセス制御を容易にし、スーパーユーザー資格情報を配布する必要性を低減します。ジョブレベルのログは、コンプライアンス監査も容易になることを意味します。しかし、秘密管理の場合、PagerDuty® Runbook Automationはオンプレミスのキーストアと接続しません。

しかし、あなたの会社のセキュリティー要件に合致するでしょうか?

オンプレミス認証や機密情報管理と統合する必要がある場合、またはこの分野で独自のニーズがある場合は、代わりにPagerDuty® Process Automation On Premが提供する柔軟性が必要かもしれません。

概要

PagerDuty® Runbook AutomationPagerDuty® Process Automation On Prem
最適な目的クラウドやSaaSの運用を管理するためオンプレミスの運用やインフラを管理するため
プラグインプリセットとカスタムなし全て利用可能+カスタム可能
キーストアクラウドのみオンプレミスまたはクラウド
データPDによる管理お客様による管理
アップグレードPDによる管理お客様による管理
スケールPDによる管理お客様による管理
安全なインフラPDによる管理お客様による管理

これらの違いについて、自社の要件と照らし合わせてみたいという方は、ぜひ私たちのチームと会話を始めてください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

2022年1月6日  (更新日:2022年8月31日)     |    インテグレーション&ガイド

スクラムセレモニー:初心者のためのガイド

スクラムセレモニーとは、スクラムイベントやミーティングの一種で、プロジェクトをよりタイムリーかつ効率的に進めることを目的としたものです。このセレモニーは、制作プロセスの重要なポイントで行うもので、チームメンバー間の組織的なコラボレーションとコミュニケーションを重視し、複雑な開発プロセスやキューを簡素化することを支援します。例えば、デイリースクラムは毎朝行われ、どの項目が完了し、どの項目に取り組んでいるか、そしてどの項目が先に控えているかを確認する儀式です。

スクラムセレモニーには、以下のような5つのスクラムイベントがあります。 スプリントプランニング:スプリントバックログを決定し、チームの期待値を設定するためにスプリントの最初に開催されます。 デイリースタンドアップ/スクラム:毎日(多くは一日の始まりに)行われる15分間のセレモニーで、チーム全体のアイテムの進行状況をスクラムチームメンバー全員に素早く報告します。 スプリント:スプリントは、スクラムチームメンバーが協力してスプリントバックログを完成させるためのイベントと考えられています。 スプリント/イテレーションレビュー:スプリントや特定のマイルストーンの終了時に開催され、完了した作業をレビューして発表します。 レトロスペクティブ:イテレーションの終わりに開催され、イテレーション中に何がうまくいったか、どんな問題が出てきたかを分析します。レトロスペクティブの目的は、継続的な改善を促し、開発を最善の方法で前進させることです。

スクラムやその他のアジャイル手法で非常に重要なのは、チームメンバーや利害関係者全員が制作のライフサイクルについて明確かつ共有した理解を持つことです。スクラムのセレモニーは、物事を整理し、前進させるための接着剤となります。 この記事では、これら5つのスクラムセレモニーについて、どのスクラムチームメンバーが関与するのか、それぞれのミーティングは通常いつ、どれくらいの時間行われるのか、そしてそれぞれのスクラムセレモニーの目的について詳しく見ていきます。

アジャイルメソドロジー&スクラム

企業やその規模にかかわらず、全ての開発チームの主要な目標の1つは、新しい製品やアップデートを迅速かつ効果的にユーザーに展開することです。定期的かつ確実なアップデートによって製品/サービスの体験を継続的に改善できれば、ユーザーとの信頼関係やロイヤリティーが徐々に構築されます。さらに、幸せな顧客を持つことによる収益性の向上は、利害関係者との良好な関係を維持することにつながります。

今日、テクノロジー企業は、信頼できるプレミアムなユーザー体験を提供するために、アジャイル開発方法論を用いて生産プロセスの改善に役立てています。そして、これらのアジャイル開発手法の中で、スクラムは明らかにNo.1であり、約60%の組織が製品開発にスクラムを活用しています。スクラムは、作業内容、進捗状況、タスクやアイテムの優先順位など、チームの完全な理解に基づくものです。

スクラムの5つのセレモニー

スクラムセレモニー#1:スプリントプランニング

スプリントプランニングは、スプリントの最初に行われるミーティングで、スプリントバックログ(スプリント中にチームが完成させるべき項目の全一覧)を決定します。また、このミーティングでは、スプリントを成功させるために、チーム全体への期待値を設定する必要があります。

スプリントプランニングに参加するのは誰ですか?** スクラムの全役割(開発者、スクラムマスター、プロダクトオーナー) スプリントプランニングはいつ行われますか?** それぞれの新しいスプリントの開始時 スプリントプランニングのミーティングの長さはどれくらいですか?** 1~2時間 スプリントプランニングはどのくらいの頻度で行うべきですか?** 全スプリントの前

スクラムセレモニー#2:デイリースクラム

デイリースクラムは、プロダクトバックログで何が起こっているかを全員に知らせるために、最も一般的には午前中に開催される短い毎日のミーティングである。このミーティングはかなり短時間であるべきですが、各メンバーが完了したもの、取り組んでいるもの、障害に遭遇していないかなどを議論する時間を確保する必要があります。

デイリースクラムに参加するのは誰ですか?** 全スクラムロール デイリースクラムはいつ行われますか?** 通常、作業の開始時 デイリースクラムの長さはどれくらいですか?** 15~20分 デイリースクラムはどのくらいの頻度で行うべきですか?** 毎日

スクラムセレモニー#3:スプリント

スプリントは、指定された時間ブロックの間にチーム全体が完了するように設定されたタスク(または仕事の塊)のリストです。これは、スプリントプランニングのセレモニーで示されるものです。

スプリントに参加するのは誰ですか?** 開発者 スプリントはいつ行われますか?** さまざまです スプリントの長さはどれくらいですか?** スプリントプランニングに基づき、各スプリントにはそれぞれブロック化された時間目標があります。スプリントの期間は数日から数週間、数カ月とさまざまですが、スプリントバックログの内容によって異なります スプリントはどのくらいの頻度で行うべきですか?** さまざまです

スクラムセレモニー#4:スプリント/イテレーションレビュー

スプリント/イテレーションレビューは 、スプリントやその他の特定のマイルストーンの完了後に開催されます。このセレモニーの目的は、完成した作品をレビューし、紹介することです。スプリント/イテレーションレビューでは、開発チームは完成した機能やアップデートをチーム全体に向けてデモンストレーションします。他のチームメンバーやステークホルダーからのフィードバックが得られるだけでなく、開発者にとっても自分の頑張りをアピールできるチャンスです。

ここで重要なのは、これはあくまで部分的なレビューであり、完全なレビューは「レトロスペクティブ」で行われるということです。

スプリント/イテレーションレビューに参加するのは誰ですか?** 全てのスクラムロール、ステークホルダー、プロジェクトの他のチームメンバー スプリント/イテレーションレビューはいつ行われますか?** スプリントやマイルストーンが終了したとき スプリント/イテレーションレビューの長さはどれくらいですか?** 最大4時間 スプリント/イテレーションレビューはどのくらいの頻度で行うべきですか?** スプリントが完了したとき

スクラムセレモニー #5: レトロスペクティブ

レビューが製品や完成した仕事に焦点を当てるのに対して、スプリントレトロスペクティブはプロセスに焦点を当てます。何がうまくいったのか、何が問題だったのか、プロセスの問題点を解消し、ツールを追加・調整し、人間関係やコミュニケーションを改善するための計画を立てる場でもあります。

レトロスペクティブに参加するのは誰ですか?** 全スクラムロール レトロスペクティブはいつ行われますか?** 完了したスプリントやその他のマイルストーンの終了時 レトロスペクティブの長さはどれくらいですか?** スプリントの長さ1週間につき最大45分(例:2週間のスプリントの場合、最大1.5時間のレトロスペクティブとなる) レトロスペクティブはどのくらいの頻度で行うべきですか?** スプリントが完了したとき

スクラムセレモニーのメリット

製品がますます複雑化する中、チームメンバー間の組織的なコミュニケーションとコラボレーションはこれまで以上に重要です。スクラムの5つのセレモニーは、チームメンバーが製品/プロジェクトについて共通の理解を持ち、製品ライフサイクルを通じて同期を保つことを支援します。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

2018年6月15日  (更新日:2022年7月13日)     |    インテグレーション&ガイド

Zenoss 3インテグレーションガイドを追加しました

Zenossは、普及しているオープンソースネットワーク、サーバーおよびアプリケーション監視システムです。あらゆるオープンソース監視システムで利用可能な最高のイベント管理システムの1つを提供します。Zenossのプラグインアーキテクチャにより、誰でも簡単に利用できるようになりました。PagerDutyは、PagerDuty APIを使用してオンコールスケジュール、アラート、インシデント追跡を提供することで、Zenossの機能を拡張します。 このガイドでは、Zenoss 3のインストールをPagerDuty ZenPackにインテグレートする方法について説明します。

詳しくはこちら

2018年3月9日  (更新日:2022年7月11日)     |    インテグレーション&ガイド

BMC Service Deskインテグレーションガイドを追加しました

BMC Remedy Service Deskは、モバイル向けにネイティブで構築された革新的なサービス管理プラットフォームです。美しく直感的なユーザーエクスペリエンスを提供します。BMC Remedyを使用すると、PagerDutyユーザーは、フォームに注意が必要な内容が記入されたときにアラートを受け取ることができます。

詳しくはこちら

2019年9月6日  (更新日:2022年6月2日)     |    インテグレーション&ガイド

PagerDutyとAmazon EventBridgeを使用したサーバレスイベント駆動型ワークフロー

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

2018年12月28日  (更新日:2022年5月19日)     |    インテグレーション&ガイド

アラート対応疲れを減らすためにSignalFxとPagerDutyでソーシャルシグナルを監視する

チームにこう伝えました。「SignalFxで重要なイベントが進行中の場合は通知してほしい」。しかし、システム監視の会社のCTOであるにもかかわらず、進行中のインシデントや潜在的な問題を常に把握するために、適切なアラートを作成することは思ったよりも困難でした。

どうして?

クラウドとオープンソースの登場により、ソフトウェアをより迅速に構築できるようになりましたが、今日の環境は次のようなさまざまな理由から、監視と管理が非常に複雑になっています。

監視するインスタンス数の爆発(ホスト、コンテナ、関数) サービスはまれに「正常動作」というメトリックを発したり、常に変化したりする マイクロサービス構成のため、個別に監視する必要があるサービスの量が増えている

私たちの経験による結論は、誤検知や繰り返される警告の嵐です。アラート疲れはチームがリアルタイムで問題を見つけて解決する能力を妨げるだけでなく、長時間対処されないとチームの士気を破壊し、本来予防可能なシステムダウンをもたらします。

アラート疲れを軽減するための戦略

アラート疲れを軽減することは、自らの焦点を広げることから始まります。きめ細かなメトリックの測定は、トラブルシューティングやフォレンジック分析には非常に役立ちますが、最も効果的なアラートは、アプリケーションの健全性に関する高レベルのインジケーターを構成するシグナルの組み合わせに依存します。特に、次の点を考慮する必要があります。

個々のインスタンスではなく、全体を監視

環境内の個々のコンポーネントのステータスを警告するのではなく、サービスごとまたはグループごとの健全性インジケーターを定義してモニターします。たとえば、サービスインスタンス間のAPI呼び出しの99%が要している遅延時間、ノードの特定クラスタの平均CPU使用率、コンテナのグループのAPIエラーの合計などを追跡します。

1436台のホストのシステムメトリックを集約

固定の閾値よりもパターンと傾向に関する警告

変化する環境に適応できるアルゴリズムで生成された閾値を使用する。分散システムはしばしばミステリアスな方法で動作するため、アラートが発生する前に正しいCPU使用率やAPIエラーの数を判断することは非常に困難です。

単純セッション数と週をまたいだ変化

定期的なパターン(たとえば平日の高トラフィック)や予測的なアラート(次のN日以内にクラスタがディスク領域を使い切るのを警告する)によって、システムの通常の動作と対応を必要とするものを区別できます。

グラフが示す容量のメトリックの傾向

アプリケーションのパフォーマンスの全体的な尺度の定義

さまざまなマイクロサービスのメトリックを組み合わせて、より高いレベルのシグナルとアラートを導き出す。たとえば、ログインユーザーあたりのページ読み込みの数と、API呼び出しの合計に対するAPIエラーの割合です。あるお客様は、すべてのマイクロサービスのメトリックを組み合わせて、デプロイしたバージョンのパフォーマンスが全体的に改善されたかどうかを示すヘルススコアを作成しています。

ソーシャルシグナルの測定

SignalFxでこれらのテクニックをすべて使用していたにもかかわらず、まだ誤検知のアラートが多すぎました。次の点に注意しました。

私はエンジニアリングリーダーなので、サービスオーナーやオンコールエンジニアのように細かいアラートを必要としません。アラートのサブセットをフォローするのは、警告なしにリストがすぐに古くなるため実用的ではありません 私たちはPagerDutyを使用していますが、私が常にオンコールのエスカレーションパスにいるとは限りません 私はSignalFxのステータスページのようなソースを見ることでマイナーな問題をフィルターすることができますが、その代りにインシデント対応に積極的に関わりたくても、アラートが届くのが遅すぎて気付くのが問題が大きくなった後だったということになりかねない

では、他にどのようなシグナルを検出できるでしょうか? 我々SignalFxは#outageという名前のインシデントについてのSlackのチャンネルを作っていました。また、このチャネルは、PagerDutyから重要なアラート通知を受け取って、議論の内容を保存します。運用してみると、重大な問題には多くのユーザーがSlackでコラボレーションし、PagerDutyを介してエスカレーションしているという事実を知ったので、私は#outageで人間の活動に関するメトリクスを収集することにしました。結果は次のようになりました。

私はAWS Lambdaセットを使ってメッセージを照会し分類し(例えば人間かボットか)、それをSignalFxに公開しました。次に、3人以上の人が#outageで5分以上タイピングしていると私に通知する検出システムを作りました。アラートはPagerDuty経由で私の電話に送信され、Slackに直接メッセージが送信されます。

進行中の潜在的な機能停止を警告する

これは驚くほどうまくいきました。誤検知が全くなくはありませんが、その数はほぼゼロになり、関心の高いインシデントは全て通知されました。興味深いことに、いくつかの潜在的なインシデントについてアクティブなアラートとしてではなく通知を受けましたが、エンジニアはいつものサービス観察の中でそれを発見していました。

ハードウェアとソフトウェアの監視は停止しない

最初は、アプリケーションとインフラのメトリクスだけを使用して「完全な」アラートが作成できないことに失望しましたが、これは素朴な期待だったかもしれません。正確なアラートを作成するにはシステム環境を理解するだけでなく、組織がどのようにインシデントに対応するかを知ることも必要です。

私の問題の解決には人間の行動を測定することで十分でしたが、今日のツールの多くが相互運用性とデータ非依存を志向していることを考えると、モニタリングに組み込む可能性のあるシグナルはたくさんあります。

インシデント管理と問題検出を統合する

リアルタイムのビジネスはリアルタイムの運用インテリジェンスを必要とし、今日のテクノロジーは従来の監視ツールで処理できる量よりもはるかに多くのデータを送信します。SignalFxは環境内の各コンポーネントからのストリーミングメトリックを収集し、数秒で分析とアラートを提供するため、問題が顧客に影響を及ぼす前にそれを見つけて解決することができます。

SignalFxとPagerDutyを使用すると、SignalFxでアラートがトリガーされたときにPagerDutyでインシデントを自動的に開くことができます。アラートに応じて異なるエスカレーションポリシーにマップし、正常に戻ったときに解決されたインシデントを自動的にマークします。

SignalFxは、組織が重要なシグナルをリアルタイムにあらゆる規模で監視するのを助け、かつてないほど迅速に革新することができるとの自信を持っています。

Arijit MukherjiはSignalFxのCTOで、システムの監視に情熱を傾けています。Facebookのメトリクスソリューション(ODS)のオリジナル開発者の一人であり、その後もFacebookのネットワーキングツール、データビジュアライゼーション、その他のインフラ監視ソフトウェアの開発を管理しました。10年以上にわたり監視の領域に重点を置いていましたが、20年以上にわたる彼の多様なキャリアは、IPテレフォニー、VoIP会議、ネットワーク仮想化にも及んでいます。

GET STARTED

本記事は米国PagerDuty社のサイトで公開されているものを日本語訳したものです。原文はこちらです。

<  1234567  >