Blog
ブログ

PagerDutyでインシデントを割り当てられたとき、最初にすべきことは何でしょうか？すぐに「受任！（Acknowledge）」と思った方は間違っていませんが、その後は、できるだけ早く、痛みを伴わずに問題を解決することが大切です。解決への第一歩は、最初にインシデントの原因を調査し、簡単に修正策を講じられるようにすることです。 PagerDutyのプラットフォームでは、Root Cause Analysis（根本原因分析）*は、レスポンダーであるあなたにできるだけ多くのコンテキストと実用的なインテリジェンスを提供することを目的とした一連の機能を指します。過去に発生したインシデントや関連するインシデント、インシデントの発生頻度に関する情報を表示することで、レスポンダーは根本原因を特定するために必要な状況認識を素早く得ることができ、迅速なトリアージと、そして最終的には早期解決につながるツールを手にすることができます。また、過去のデータに基づき、発生源と思われる場所がハイライト表示され、状況を把握しやすくなります。 ここでは、インシデントの詳細ページで、潜在的な根本原因を調査するのに役立つ5つの場所を紹介します。

1. Outlier Incident

インシデントを最初に開くとき、［Outlier Incident］分類ラベルを探します。このラベルはインシデント名の直下にあり、"Frequent", "Rare", "Anomaly "のいずれかの分類ラベルが表示されます。この分類ラベルに基づいて、このインシデントが以前に発生したことがあるかどうか、また過去の経験に基づいてどう対応すべきかをすぐに判断することができます。ラベルにカーソルを合わせると、それぞれの定義が表示されます。

2. Past Incidents

サービス上でインシデントが発生した頻度を決定したら、ページのさらに下にある［Past Incidents］タブに移動します。ヒートマップが表示され、このオープンインシデントのような過去のインシデントが過去６カ月間にいつ発生したかが示されます。色のパターンを探す（色が濃いほどインシデントが集中している）か、ヒートマップの色にカーソルを合わせると、関連するインシデントの詳細が表示されます。その下には、オープンインシデントのような過去のインシデント上位５件（もしあれば）の詳細と、それらがいつ発生したか、誰が最後にインシデントを変更したかについての情報が表示されます。注：その人は、インシデントに際して何をしたか尋ねたり、それに関するメモを見たい場合、素晴らしいリソースになります。過去のインシデントの詳細ページを開くには、ハイパーリンクされたタイトルをクリックします。

3. Related Incidents

もう一つの簡単な情報源は、［Related Incidents］タブです。ここでは、同じサービス上の類似のインシデントしか表示されない過去のインシデントとは異なり、全サービスからあなたの問題に関連する可能性のある進行中のインシデントがあるかどうかを確認できます。ビジネス全体のインシデントの範囲（これは孤立したものか、より大きな問題の一部か）を理解することは、影響を理解し、問題を解決するために協力する必要がある人を迅速に特定するのに役立ちます。

4. Probable Origins

インシデントの詳細ページにある［Probable Origins］ウィジェットを使用して、トリアージ作業を素早く始められます。このウィジェットは、インシデントが現在のオープンインシデントの類似イベントの直前に発生したか、または直後に発生したかなどの履歴データに基づいて、発生源の可能性のパーセンテージを計算します。

5. Change Correlation

最後に、インシデントの原因となった可能性のあるインフラやコードの変更に気付いている場合、解決を大幅に加速できます。インシデントの詳細ページの［Recent Changes］に表示される［Change Correlation］は、時刻、関連サービス、PagerDutyの機械学習に基づいて、インシデントに最も関連する最近の変更イベントを３つ表示します。最近の変更イベントには、プラットフォームがイベントを表面化させた理由が表示されるため、潜在的な原因を簡単に絞り込めます。

ナレッジチェック！ 正しいでしょうか、間違いでしょうか？： [Past Incident]タブには同じサービスのResolved Incidentsが表示され、[Related Incidents]には他のサービスのOpen Incidentsだけが表示されます（ページ下部の回答を参照）。

いかがでしたでしょうか？これら５つの、コンテキストをすばやく取得し、トリアージ作業を開始するために調べられる場所を忘れないでください。

インシデントを迅速に解決し、ダウンタイムをさらに短縮するには、この一連のRoot Cause Analysys機能をNoise ReductionとEvent Orchestrationの機能と組み合わせるとよいでしょう。再確認が必要な場合は、PagerDuty UniversityのEvent Intelligenceコースを受講し、Event Intelligence認定を取得して、ハードワークではなく、スマートな作業ができることを証明してください。

次のステップのためのリソース：

Event Intelligenceコースは、PagerDuty University eLearning Portalでご覧いただけます。

Noise Reduction Event Orchestration Root Cause Analysis

Event Intelligence Certification Exam（認定試験）の情報は、このページの "Specialty Product Certification" でご覧いただけます。この新シリーズの発売を記念して、30日間、試験への登録を無料にしますので、今すぐご登録ください。

*脚注：このカテゴリーの機能を「Root Cause Analysis」と呼んでいますが、PagerDutyは根本原因を予測したり特定したりするものではありません。むしろ、PagerDutyの機能は、インシデントに関連するコンテキストを作成し、より迅速な解決を促進するためのものです。また、業界では、真の「root cause」が１つであることを示すような用語ではなく、「probable」cause または「 proximate」causeという用語を採用する方向に変化していることも注目に値します。

ナレッジチェックの回答：誤りです。過去のインシデントは同じサービス上で解決された過去のインシデントのみを表示するという記述は正しいのですが、関連インシデントは全サービス（現在のインシデントが起きているサービスを含む）上で未解決の、または最近解決した他のアクティブなインシデントを調べ、現在のインシデントに関連しているインシデントがあるかどうかを確認します。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

毎年、Radarリポートには驚きに満ち溢れています。私たちと共に、多大な利益を得ている何千ものお客様にとっては驚きではないでしょうが、PagerDutyは2022年のGigaOm Radar for AIOps Solutionsでリーダーに選ばれたことを大変喜んでいます。

GigaOmは、Radarのベンダーを評価するために広範な基準を使用しています。リポートによると 「今年は、既存のツールを置き換える必要があるAIOpsソリューションと、大きな混乱なしにITツールボックスに追加できるソリューションを区別しています」とのこと。これは、PagerDutyがLeaderに位置付けられ、Tool DisplacementでOutstanding と評価された鍵の一つです。

Time to ValueとTCOは、かねてよりPagerdutyのビジネスバリューの特徴です。お客様はPagerDutyを信頼して、既存のシステムを取り替えることなく、迅速にその価値を最大化することができます。 私たちのSaaSプラットフォームは、シンプルなセットアップ、素早い統合、使いやすいイベントルーティングとエンリッチメントを提供し、これらは全て「導入の容易さ」の優れたスコアにとって重要な要素となっています。

650以上の統合機能を持つPagerDutyは、データ消費、システム統合、クラウド監視の分野で「Exceptional」と評価されました。このような幅広い機能により、実務担当者は事実上カスタマイズの必要なく、迅速な価値創造を実現することができます。UI、Terraform、APIプロバイダーにより、専門家はモニタリング、CI/CD、DevOps、セキュリティー、BizOpsなどの全てのデータソースを活用し、新しいチームメンバーでも迅速に問題を解決するために必要なåコンテキストを作成することができます。 当社のEvent Orchestrationは、シンプルかつ強力なルーティング、エンリッチメント、問題への自動応答を可能にします。膨大で複雑なルールベースからシンプルなノードベースのグラフルーティングに移行することで、SREとDevOpsチームは、コンテキストを作成し、診断を提供し、必要に応じて自動的に問題を解決するためにイベントを使用する方法を正確にコントロールすることができます。シンプルなグラフィカルインターフェイスは、簡単な実験的方法を提供し、基盤となる Terraformプロバイダーはセルフサービス機能を可能にし、中心チームから負担を取り除くことができます。この総合的なセルフサービス機能は、「Manageability」で「Outstanding」と評価されました。

GigaOm は、AIOps に対する自動化優先のアプローチの優位性を認識しました。Rundeck と Catalytic の買収により、当社のプラットフォームは、ビルトインのAutomation Actionsと柔軟なワークフローという形で、プラットフォーム全体に包括的な自動化の統合を提供することができるようになりました。人とマシンのワークロードのバランスをとることは、生産性を維持し、燃え尽き症候群を防ぐために重要です。インシデント解決の最初のレスポンダーとして自動化を活用することで、労力を軽減し、解決までの時間を短縮することができます。レスポンダーが必要ない場合、一般的な問題の兆候を特定し、自動修正により機械の速さで処理することができます。自動修復はごく一部のよく知られた修正に対応できますが、多くの場合、自動化はインシデント対応と調査の中心であるレスポンダーを補強する、第二の手の役割を果たします。 Radarはまだ1年目ですが、ここ数年のEvent Intelligenceの成功に基づき、お客様のために機能を拡張し、新たなビジネス成果を提供することに全力を注いでいます。今年は、お客様のために200億件以上のイベントを処理する予定です。SaaSプラットフォームとしての長年のデータを活用し、お客様がどのようにノイズを減らし、問題を解決しているかを理解することで、機械学習、自動化、分析を拡大し、チームは生産の維持とよりよいソリューションの提供に集中できるようになりました。

リポートはこちらからご覧いただけます。また、PagerDutyのAIOps向けソリューションの詳細については、こちらをご覧ください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

今日のAWSを中心としたクラウドアーキテクチャーは、通常、2万5000以上のSaaSサービス、自社開発サービス、レガシーシステムに、約250のAWSサービスやワークフローが実装された複合型となっています。このような環境でインシデントが発生した場合、企業が一元的なクラウドプラットフォームを構築しているかどうかに関わらず、個別の専門知識が必要になることが多くあります。このように複雑さが増している中、第一レスポンダーは、問題の最終的な解決者を決定する前に、複数の異なるサービス所有者や専門エンジニアにエスカレーションして見立てを聞かなければなりません。

インシデント対応において、これらの新しいクラウド環境は、組織の既存の重要なアプリケーションやサービス（新旧両方）とシームレスに統合することが非常に重要です。サービス品質を向上させ、レスポンダーが専門知識の橋を容易に渡れるようにするために、Automated Diagnosticsのための新しいAWSプラグイン統合を直ちに利用いただけるようになったことを発表でき、嬉しく思います。

Automated Diagnosticsのための新しいAWSプラグイン

Automated Diagnosticsのための新しいAWSプラグインは、AWS環境でのAutomated Diagnosticsの迅速な立ち上げを容易にし、AWSのユーザーでもあるお客様により行き届いたサービスを提供します。

Automated Diagnosticsのための新しいAWSプラグインは以下の通りです。

CloudWatch Logsプラグイン。** このプラグインは、AWSのインフラストラクチャーとアプリケーションから診断データを取得します。これにより、ユーザーはより簡単に、複数のアカウントと製品にまたがるAWSのAutomated Diagnosticsを実行できるようになりました。 Systems Managerプラグイン。** このプラグインは、構成管理、パッチ適用、監視およびセキュリティーツールのエージェント展開などのタスクの迅速な実行と正確性を可能にします。ユーザーは、上記のタスクに自動化を適用して、より速く実行することができるようになりました。 ECS Remote Commandプラグイン。** このプラグインは、コンテナ上でコマンドを実行するための仕組みを提供します。これにより、開発者や運用者は、サービスを再デプロイする前に、実行中のアプリケーションからリアルタイムに診断データを取得することができます。 Lambda Custom Code Workflowプラグイン。** ジョブステップで提供されるカスタムコードをインプットとして、新しいLambda関数を作成、実行、オプションで削除します。ソフトウェアをインストールすることなく、カスタムスクリプトをジョブステップとして実行できます。

複雑そうですか？心配ありません、ちゃんと対策しています。

AWSユーザーのための新しいAutomated Diagnosticsジョブテンプレート

また、AWS用の新しい構築済みテンプレートをリリースしました。お客様の特定の環境に合わせたインシデント詳細の強化をすぐに開始することができます。これらのテンプレートは、最小限の構成で使用できるように設計されています。ユーザーはゼロから始める代わりに、対応中のインシデントの調査、デバッグ、トリアージに必要なデータを取得する、すぐに使えるジョブ定義のライブラリーを利用できるようになりました。

新規ユーザーはAWSの診断の自動化をより早く開始でき、既存ユーザーは既存のPagerDuty Process AutomationプロジェクトにAWSの診断を簡単に追加することができます。

ジョブテンプレートの例をいくつか紹介します。

AWS – EC2	インスタンスのステータスと関連するIAMロール	EC2インスタンスのステータスと関連するIAMロールを取得します。	Remote command（またはSSM)
AWS – ECS	停止したECSタスクのエラー	停止したECSタスクにエラーがないか確認し、エラーの原因に関する詳細情報を提供します。	Stopped ECS Tasks
AWS – ELB	ELBターゲットのヘルスステータスを取得する	ロードバランサーに関連するTarget Groupsのうち、不健全なTargetの一覧を取得します。	ELB Instance Statuses
AWS – RDS	データベースの保存状態を確認する	インスタンスの状態をRDSデータベースで確認します。	RDS Instance Status
AWS – VPC	UDP転送プロトコルを使用したIPアドレス	CloudWatchのログを照会し、UDP転送プロトコルを使用しているホストを特定します。	CloudWatch Logs
AWS – VPC	サブネットのスループット上位10ホスト	CloudWatchのログを照会し、指定したサブネットのスループットの上位10ホストを特定します。	CloudWatch Logs
AWS – VPC	拒否されたリクエストの多い送信元IPアドレス上位10件	CloudWatchのログを照会し、rejected-requestsが最も多いソースIPアドレスの上位10個を特定します。	CloudWatch Logs
AWS – VPC	パブリックIP別ウェブサーバーリクエスト数トップ10	CloudWatchのログを照会し、当社のウェブサーバー（Nginxなど）へのパブリックIPリクエストの上位10件を特定します。	CloudWatch Logs

これは氷山の一角に過ぎません。私たちは、AWSを利用するお客様が必要な時に自動化を実行できるように、既存のプラグインをベースに開発、構築し、いくつかのインタラクティブなガイドを提供することを目指します。

共通診断についてもっと知りたいですか？9月14日に開催されるウェビナーイベント「Common Diagnostics for Common Components（共通コンポーネントのための共通診断）」にご登録ください。PagerDuty Process AutomationによるAutomated Diagnosticsを実際にご覧になるには、デモをご請求ください。

すでにPageDuty Process Automationをお使いですか？Automated Diagnosticsソリューションガイドで、完全なソリューションを実現するためのエンドツーエンドプロセスをご確認ください。

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

本日、Dedicated Incident Slack Channelの改良版のアーリーアクセスを開始することができました。この改良は以下の通りです。

全てのインシデントの詳細、履歴、およびアップデートを表示する 全てのインシデントアクションを実行する 全レスポンダーをチャンネルに追加する ズームコンファレンス専用ブリッジの掲載または作成

この機能を利用するためには、Slack on WebHooks V3にアップグレードし、PagerDutyサポートにアーリーアクセスをリクエストする必要があります。 正しいバージョンでアーリーアクセスができたら、専用のインシデントチャンネルを作成する方法が2つあります。

1. Slackにて

Slackのインシデント通知から、「View | Create Channel」を使用して、デフォルトのネーミングスキーマで新しいインシデント専用チャンネルを作成します。チャンネルがすでに存在する場合は、チャンネルのハッシュタグが付いたメッセージが投稿されます。

2. PagerDuty Web 経由

Incident Pageで、「Set the Channel」でチャンネルを設定する。アーリーアクセス中は、「BETA」タグが表示されます。

その後、ユーザーは既存のチャンネルを選択するか、新しいSlackチャンネルを作成することができます。

新しいチャネルを作成する場合、ユーザーはデフォルトの名前を受け入れるか、新しい名前を割り当てることができます。チャンネルは公開にも非公開にも設定できます。

注：PagerDutyアカウントに複数のSlackワークスペースが接続されている場合、ユーザーはチャンネル接続に必要なワークスペースを選択することができます。

作成すると、PagerDutyのウェブのUIとSlackではこのように表示されます。

この新機能を活用していただくことを期待するとともに、ご意見をお待ちしています。

次はどうする？

この機能は、Slack on Webhooks V3をご利用の全てのお客様に対して、来月には公開する予定です。

また、チャンネル作成の効率化・自動化により、この機能の充実を図っています。

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

顧客の期待値の変化

ここ数年、顧客からの要求が大幅に増加し、カスタマーサービスの担当者はプレッシャーを感じています。最近のZendesk CX Trendsレポートによると、68％の担当者が腰が引けてしまっていると感じているそうです。PagerDutyでは、カスタマーサービス担当者がより幸福であれば、顧客との交流がより前向きになり、ブランドとの関係もより強固になると考えています。

カスタマーサービスチームがこの問題に対処できるよう、PagerDutyはZendeskとのインテグレーションを深め、カスタマーサービスチームが可能な限り迅速かつ効率的にインシデントを解決できるよう支援し続けています。最新のリリースでは、PagerDuty Automation ActionsがZendeskのPagerDutyアプリケーション内で利用可能になった ことを発表でき、嬉しく思います。

自動化でカスタマーサービス担当者を強化する

PagerDuty Automation Actionsは、レスポンダーをPagerDuty内の修正オートメーションにつなぐことで、インシデントの診断と修復を迅速に行うことができます。Zendesk向けPagerDuty Applicationの最新リリースでは、担当者が自動的に問題を検証し、チームが診断して解決するための重要な情報を即座に取得することができます。

担当者は、顧客に影響を与える問題を検証し、Zendesk用のPagerDutyアプリケーションから直接自動化アクションを実行する権限を与えられています。これにより、問題解決にかかる時間を短縮し、問題解決チームのために重要な顧客情報を即座に追加することでバックエンドチームの負担を軽減します。また、エンジニアリングチームにエスカレーションされる問題の数を減らすことができます。例えば、緊急性がない場合や、お客様がサービスを利用する上で影響がない場合などです。

Automation Actionsで、カスタマーサービス担当者の負担を軽減

カスタマーサービス担当者は、急増する仕事量を増やすことなく、重要なインシデントに対処する権限を与えられなければなりません。自動化は、その負担を軽減し、チームがより多くのことを行えるようにするのに役立ちます。ここでは、自動化が担当者の日常を楽にするためのいくつかの方法を紹介します。

自動化は、繰り返される類似の問題に対する一貫した対応を確立するのに役立ちます。プロセス改善のための事後報告にも有用です。 カスタマーサービス担当者がケースに対応する際の効率を向上させられます。 解決までの時間を短縮できます。 顧客との関係構築と維持に、より多くの時間を割けるようになります。 顧客からのプレッシャーにさらされたケースに対応する際に、担当者が手作業で行わなければならないミスの可能性を自動化によって減らせます。

PagerDuty Automation ActionsとZendeskの連携について詳しくは、PagerDutyのナレッジベースをご覧ください。また、アカウントマネージャーに連絡するか、今すぐデモをリクエストすることができます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一般的な例

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

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

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

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

これらのアクションに共通することは、１つだけです。インシデントを受任した一般的な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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。

PagerDuty Summit 2022の注目のセッションを紹介します。Part 2では、次の3つの講演を紹介します。

"Real Talk: PagerDuty’s Product Impact"PagerDutyの製品担当SVPのJonathan Rendeが、Anaplanの米州担当副社長兼カスタマーサクセス責任者のFiona Gillさんに、PagerDutyが彼らの最も重要な指標、チーム、そしてデジタルオペレーション全体に与える影響について、お聞きしました。 "Delivering Value: A two-way street"PagerDutyのチーフカスタマーオフィサーのManjula Talrejaが、LogicMonitorのCEOであるChristina Kosmowskiさんと対談し、企業が顧客と接する際に「価値」をどのように考え、PagerDutyが組織内でどのようにその価値を創造しているのかについて議論しました。 "Leadership in a Digital-First World"DocuSignのCEOであるDan SpringerさんとPagerDutyのCEOであるJennifer Tejadaがデジタルファーストの世界でのリーダーシップはどうあるべきかを対談しました。

「カスタマーサービスソフトウェアはこの10年で大きく進化したが、どれも同じ問題を解決しているように見える！」。これは、全体的な応答時間と解決時間の短縮に関する最近のブレインストーミングの会話で、あるカスタマーサービスリーダーが発した言葉です。

現代のカスタマーサービス担当者の役割は、ますます複雑になってきています。カスタマーサービス担当者は、高度な共感とコミュニケーションを必要とする最前線の顧客対応に努めなければならないだけでなく、顧客に影響を与える混乱が生じたときに、複数のシステム、チャネル、「信頼できる情報源」を駆使して、バックオフィスのエンジニア／開発／ITチームとコミュニケーションをとり、協力しなければならないという負担がかかっています。テクノロジーの進化と社内システム、ツール、プロセスの複雑化は、問題をさらに深刻にしています。

この点を説明するために、金融サービス会社ABCに勤務するカスタマーサービス担当者の例で、ログイン失敗に関するチケットを受け取った場合を考えてみましょう。カスタマーサービス担当者は、ヘルプデスクシステムのキューの一番上にあるチケットを受け取りますが、このチケットに加えて、同様の問題に関する50件のチケットがキューに蓄積していることに気づきます。オンラインポータルにパフォーマンスの問題がある可能性があることに気づいたカスタマーサービス担当者は、エンジニアリングチームに問題をエスカレーションし、支援を求めました。

このシナリオでは、従来のカスタマーサービスソフトウェアに関連するカスタマーサービスワークフローとプロセスの限界が見え始めています。このソフトウェアは、カスタマーサービス担当者が単発の顧客要求を迅速に解決して対応できるようにチケットキューを整理して優先順位をつけるなど、フロントオフィスでの顧客とのコミュニケーションやチケットに関する問題を解決する素晴らしい機能を備えています。しかし、システム停止やバグなどの中核的な問題を解決するために、バックオフィスのエンジニア／開発／ITチームの支援を必要とする場合はどうでしょうか。

カスタマーサービス担当者は、技術的な問題をエスカレーションするためのワークフローやプロセス、そして解決に向けた進捗状況の可視化など、多くの課題に直面しています。典型的なワークフローは、次のようなものです。

顧客がパフォーマンスの問題に遭遇し、カスタマーサービスにヘルプデスクチケットを提出する。 カスタマーサービスは、ヘルプデスクシステムでチケットを受け取る。 カスタマーサービス担当者は、コミュニケーションプラットフォームのタブを切り替える。SlackやTeamsの共有チャンネルで呼びかけ、（場合によっては個々の専門家に）表面化した技術的な問題にバックオフィスでも気づいているかどうかを確認する。 この例では、エンジニア／開発／ITチームは気づいていない。カスタマーサービス担当者は、社内のWikiやスプレッドシートを参照し、どのチームがサービスを担当しているかを把握する。 カスタマーサービス担当者は、別の社内ヘルプデスクシステム（Jiraなど）に移動し、社内チケットを提出する。 エンジニア／開発／ITチームがインシデントを解決すると、コミュニケーションプラットフォームに更新が投稿される。 カスタマーサービス担当者は、ヘルプデスクチケットシステムとコミュニケーションプラットフォームを同時に切り替えて、情報を収集し、顧客に対応しなければならない。

さらに、可視性の問題から、カスタマーサービス担当者は自分自身や他の人に問いかけます。

バックオフィスのチームは、顧客に影響を与えるテクノロジーの問題を認識しているのか。 修正作業は行われているのか。 この問題について、顧客に伝えられることは何か。 この問題の解決に向けた進捗状況はどうか。どれくらい時間がかかるか。

最悪なのは、顧客のチケットが技術チームに引き渡されると、カスタマーサービスの評価基準となるビジネスルールや成功基準が適用されなくなることです。その結果、初回コンタクト解決率、応答時間、解決時間、および顧客満足度に悪影響が生じます。これは、タイムリーな顧客対応に必要な手段や可視性をカスタマーサービスが欠いているためです。

今日、ほとんどのカスタマーサービス組織は、技術チームからサイロ化されています。このサイロ化の影響は、コラボレーションを促進するためのツールやシステムによってさらに悪化します。例えば、カスタマーサービスは、面倒なコピー＆ペースト作業によってさまざまなプラットフォームで情報を重複させ、他のチームが技術的な問題を解決している間に、複数のシステムに注意を散らしていることがよくあります。

カスタマーサービスとエンジニアの両チームとの会話からは、顧客体験を向上させるために、コミュニケーションの壁を取り払い、コラボレーションすることを強く望んでいることが分かります。エンジニア／開発チームは、デジタル資産の健全性を示すもう一つの重要なシグナルとして顧客を扱い、ダウンタイムを減らすことに注力しています。一方、カスタマーサービスチームは、顧客の期待に応えるために応答時間と解決時間を短縮することに引き続き注力しています。技術的な問題が最初に顧客から提起された場合、カスタマーサービスチームは、顧客に影響を与える混乱を正しくエスカレーションするための合理的な方法を必要としています。特に技術チームによる技術的な問題の解決を含むときは、顧客チケットのライフサイクルの始めから終わりまでが完全に可視化されていなくてはなりません。

そこで、次のような疑問が生じます。バックオフィスのチームが顧客に影響を与える障害に気づいていない場合、カスタマーサービスが顧客の問い合わせやリクエストに迅速に回答し、最前線からテクノロジーの問題をエスカレーションするために必要な可視性と情報をどのように提供すればよいのでしょうか。

異なるアプローチ

カスタマーサービスと技術チームの連携がうまくいっていないことが、ダウンタイムやレスポンス、解決時間の増加につながっていることを組織が認識したとき、異なる視点が必要になります。デジタル資産の健全性を示すもう一つの重要なシグナルとして、顧客を認識するのは今なのです。

「顧客は重要なシグナルである」が受け入れられると、組織はカスタマーサービスと技術チームの間の壁を取り払う方法を見出します。PagerDutyを他のテクノロジースタックの中枢神経系として、またリアルタイムオペレーションを行うメカニズムとして活用することで、各チームはインシデント対応プロセスに従事するために選択したシステムを離れることなく「自分の持ち場で働く」権限を与えられます。

PagerDutyをインシデント対応に関わる他のテクノロジースタックと統合することで、各チームは自分が選んだシステムで作業を行うことができます。PagerDutyは、各チームが作業を行うさまざまなシステムやプラットフォームにインシデント情報を配信し、「唯一の信頼できる情報源」となるのです。

カスタマーサービスエージェントが「ABC社」でインシデント関連のチケットを受け取るという以前のシナリオとは異なり、ワークフローは以下のステップに簡略化されます。

顧客がパフォーマンスに問題を感じ、ヘルプデスクチケットをカスタマーサービスに提出する。 カスタマーサービスは、ヘルプデスクシステムでチケットを受け取り、会社のバックエンド技術に問題があることに気付く。 カスタマーサービス担当者は、ヘルプデスクチケットのシステムUIに直接ある内部ステータスダッシュボードで、デジタル資産の健全性を確認できる。 技術的な問題が技術チームに知られていない場合、カスタマーサービスは、特定のビジネスサービスを担当するチームに対して「インシデント」を作成し、トリアージする。アラートは修復に携わるメンバーだけに飛ぶ。 カスタマーチケットとPagerDutyインシデントの間には、双方向のリンクが自動的に作成される。解決までの進捗は、チケットプラットフォームのチケット／ケースビューに流れる。 カスタマーサービス担当者は全ての情報をリアルタイムで受け取ることができ、顧客対応にかかる時間を短縮することができる。

そして何より、このコラボレーションプロセス全体は、カスタマーサービス担当者が日常業務で使用しているチケットシステム内で直接行われるのです。

カスタマーサービスチームと技術チーム間のコミュニケーションとコラボレーションプロセスを最適化することで、エスカレーションプロセスにおいて顧客に影響を与えるような混乱が発生するリスクを軽減することができます。カスタマーサービスチームは、複数のシステムを行き来したり、プラットフォーム間で同じ情報を重複させたりする必要性を排除できます。その結果、初回コンタクトの解決、応答時間、解決時間、そして最終的には顧客満足度が改善されます。

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

2020年は、私たちの働き方に革命をもたらしました。多くの人が一夜にして、フルタイムのオフィスワークから100％リモートワークへと移行しました。そして今、再びオフィスでの仕事が視野に入ってきたため、企業はフレキシブルな働き方を継続する方法を考えています。しかし、これには課題が増え、この働き方に合ったツールが必要とされています。

PagerDutyのモバイルアプリケーションは、App StoreやGoogle Playで星4.8の評価を得ており、高い認知度を誇っています。私たちは、適切な人にすぐに連絡することがいかに重要かを理解しています。だからこそ、レスポンダーがいつでもどこでも重要な仕事を解決できるように、iOSとAndroidに多大な投資を行ってきました。

このブログ記事では、最も必要な情報を見つけるための新しいナビゲーションインターフェース、過去および現在のインシデントを通じたインシデントインテリジェンスの向上、自動診断の起動と修正アクションを実行するための自動化の活用など、最もエキサイティングな改善点をいくつかご紹介します。

必要な情報を簡単に見つけられる

レスポンダーは、自分がいつオンコールになるのか、どのようなサービスのためにオンコールになるのかを知る必要があります。万が一、呼び出しを受けた場合、自分が担当する技術サービスがどのように機能しているかを確認できることが極めて重要です。そして最も重要なことは、これらの情報をモバイルアプリから一目で確認できることです。複数の画面を参照したり、アプリの奥深くに埋もれた情報を探したりする必要はありません。

新しいPagerDutyモバイルホーム画面エクスペリエンスでは、レスポンダーが必要とする最も重要な情報が容易に利用可能です。このデザイン変更により、オープンインシデント、オンコールシフト、影響を受けるテクニカルサービスを中心に表示し、アプリ内のナビゲーションに必要なタップ数を減らすことができます。

デザイン変更されたホーム画面は、現在、早期アクセス可能です。試してみたい方は、この早期アクセスフォームに必要事項を記入し、「新しいモバイルホーム体験」の選択をすると、案内が送られてきます。

フレキシブルに働くということは、最も重要な瞬間に、クリティカルインシデントの状況を自由に把握できることを意味します。インシデントが発生したら、できるだけ早く対応し、影響を軽減するための最善の方法を決定する必要があります。

その方法の１つが、新しいモバイルインシデント詳細画面です。この画面では、視覚的に分かりやすく、最も重要な機能全てにアクセスできるため、インシデント対応に迅速に取り組むことができます。インシデントで作業している他のレスポンダーのメモ、変更イベント、過去のインシデント、最新のアラートなど、インシデントに関する最も重要な情報をすぐに利用することができます。

また、更新版のモバイルインシデント詳細画面にある新しいカルーセルでは、プレーの実行、優先度やメモの追加、ステータスアップデートの投稿などを行うことができます。

過去または現在におけるクリティカルインシデントのコンテキストを獲得する

インシデントが発生したとき、最大のハードルの１つは、「以前にもあったか」という質問に答えることです。もしあれば、以前に動作したプレーを実行したり、自動化シーケンスを実行することで簡単に解決できるかもしれません。しかし、そのような過去の状況を見つけることはしばしば困難であり、それは誰にも許されない無駄な時間です。

PagerDutyモバイルアプリのPast Incidents（過去のインシデント）機能では、現在アクティブなインシデントと同じサービス上で発生した、類似したメタデータを持つインシデントが表示されます。この追加コンテキストにより、正確なトリアージが容易になり、解決までの時間が短縮されます。例えば、自分やチームの誰かが過去に同様のインシデントに巻き込まれたことがあるかどうかを確認し、詳細を調べてどのような改善策が取られたかを知ることができます。 Change Events（変更イベント）。システム内の変更は、しばしばインシデントの影の犯人です。特に、多くの組織が１日に何十回、何百回も新しいコードを出荷している場合、どの変更がインシデントを引き起こしたかを正確に特定するのは難しいため、見過ごされがちです。しかし、「Gartner社の推定によると、全てのパフォーマンスインシデントの約85％は追跡可能」です。変更イベントにより、お客様の環境に影響を与える変更を確認し、潜在的な根本原因を特定することができます。変更イベントは、モバイルアプリの２つのエリア（新しいモバイルインシデントの詳細画面と、サービスの詳細画面）で簡単に確認できます。目的のインシデントをタップして変更イベントにスクロールするか、サービスディレクトリーに移動してサービスを選択し、最大２つの変更イベントを表示できます。表示されるイベントの詳細には、日時、概要、サービス、タイプ、リンク、ソースが含まれます。 インシデント対応におけるもう１つの重要な情報は、問題の影響範囲を理解することです。この情報を得るための１つの方法は、Service Dependencies（サービス依存関係）を理解することです。大規模で顧客向けのビジネスサービスが、技術的なサービスインシデントによって問題が発生している場合、問題の範囲をよりよく理解するために、より速く、より文脈的なインテリジェンスで対応する必要があります。モバイルアプリのサービス依存関係画面では、どのサービスが影響を受けるかを表示して、範囲をよりよく理解することができます。サービス依存関係は、サービスディレクトリーの各サービスのプロファイル内に表示されます。

自動化を活用した迅速な対応

テクノロジー環境がより複雑になるにつれ、人々の時間と認知資源を節約することがこれまで以上に重要になっています。これは、人間ではなく、機械が最初の防衛線として機能することを意味します。

反復的な手作業やよく理解されている事象を自動化することで、対応者の不必要な労力を軽減し、本業に集中できるようにし、最も必要とされている事象にのみ注意を向けるようにできます。これを実現する１つの方法が、指先のタップで実行できる自動化です。

PagerDuty Automation Actionsは、PagerDutyモバイルで一般的に利用できるようになり、いつでもどこからでも自動診断と修復アクションを実行できるようになりました。繰り返し行われる診断と修復のステップを自動化することで、手動で行っていた作業を代替し、生産性を向上させることができます。スクリプトを実行するだけでなく、過去に実行したスクリプトや出力レポートをモバイルアプリから直接表示することができます。これらはリアルタイムで更新されるため、見落としがありません。

PagerDutyモバイルアプリケーションに追加されたこれらの最新機能は、時間、品質、顧客体験を犠牲にすることなく、レスポンダーが思い通りに作業できるよう支援します。フレキシブルな働き方は今後も続きます。PagerDutyの強力なモバイルアプリケーションは、あなたがそれを最大限に活用できるよう支援することを約束します。PagerDutyのモバイルアプリケーションをまだお試しでない方は、今がチャンスです。QRコードを使って、どちらかをダウンロードしてください。

iOS

Android

重要：モバイル体験の安全性を確保するために

PagerDutyモバイルに多くの新しい素晴らしい機能が追加されました。モバイルアプリが革新的で安全であり続け、ユーザー体験を向上させるために、新しい最小システム要件を導入します。2022年6月27日より、PagerDutyモバイルアプリの将来のバージョンでは、Android 9.0かiOS 14.0以降が必要となります。モバイルアプリのアップデートを継続的に受信するために、お使いのデバイスが最新に保たれていることをご確認ください。

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

ここ数年、企業と従業員の双方にとって、ビジネスと文化の根本的な転換が起きています。

COVID-19は、デジタル業務に早くから投資してきた企業にチャンスをもたらし、他の企業は現状維持に苦心しました。後者は、記録的な従業員の燃え尽き症候群をもたらし、俗に言う「大退職」と呼ばれる事象を生じさせました。

CNBCの調査によると、2022年3月に450万人の米国人労働者が、燃え尽きた、仕事に不満がある、自分の人生を見直すなどの理由を主として仕事を辞めています。また、2021年のPagerDutyのユーザー調査によると、回答者の64％が自組織で離職率が上昇したと答え、過去１年間で離職率が上昇しなかったと答えたのは34％のみでした。

大退職時代が続く中、企業は従業員の生産性を維持し、離職率を下げるための新たな方法を模索しています。私たちは、ベストプラクティスに投資することが大きな違いを生むことを、お客様との経験から知っています。

デジタルオペレーション成熟度モデルは、一般的な行動を段階的に説明し、リアルタイムのオペレーション上の課題に対処する準備ができているかどうかによって、成熟度を分類します。チームは、デジタルトランスフォーメーションの旅を容易にするベストプラクティスとプロセスに投資することで、成熟度を高め、より積極的になることができます。

デジタルオペレーション成熟度モデルとは

デジタルオペレーション成熟度モデルは、対応チームが現在の成熟度を評価し、システム停止やシステム障害の検出、トリアージ、動員、対応、解決をより短時間で行うための新しいデジタルオペレーションを構築することを支援します。

このモデルには、５段階のオペレーション成熟度が含まれています。

Manual（手動型）。** 開発者が目の前の問題に奔走し、リクエストには夜通しでその場しのぎの対応が必要。 Reactive（受動型）。** システム障害や顧客からのクレームが発生すると、調整と計画なしに常に消火態勢に入る。 Responsive（反応型）。** 問題が発生すると、調整と計画が合理化され、解決される。 Proactive（積極型）。** シームレスで協調的な問題管理により、顧客が気づく前に問題を解決する。 Preventative（予防型）。** 問題が発生する前に先手を打ち、過去と現在のインシデントから継続的に学ぶ。

デジタル運用成熟度モデルの目標は、DevOpsチームがITインフラの一貫性、信頼性、回復力を管理・維持するために、積極型および予防型の段階に移行することを支援することです。また、ワークフローとワークライフバランスがより予測しやすくなるため、従業員の燃え尽きが減少します。

オペレーション成熟度向上によるメリット

2021年、PagerDutyのプロダクトマーケティングアナリストであるTejere Oteriは、優れたオペレーションプラクティスがビジネスインパクト、オペレーションの健全性、人的要因に与える影響を理解するために調査を実施しました。調査結果を分析した際、Tejereは、受動型組織の参加者と予防型組織の参加者の回答の仕方に違いがあることに気づきました。

チームの仕事量について質問したところ、受動型組織の参加者の33％が仕事量は均等に分散していると感じていましたが、大多数は仕事量の改善を希望していました。同じ質問を予防型組織にしたところ、83％が仕事量は均等に分散していると感じており、そう思わないという回答は意外にもありませんでした。

また、Tejereは、受動型組織は予防型組織に比べて、従業員の離職率が２倍高くなることを発見しました。具体的には、予防型組織は反応型組織に比べて、プライベートな時間や睡眠時間を仕事のためのインシデントに費やすことが少なく、燃え尽きが少なく、離職率が高まる可能性が低いことがデータ分析から明らかになりました。

成熟度モデルを製品の使い方にマッピングしたらどうなるか

オペレーション成熟度モデルをお客様に紹介し、お客様全体に見られる傾向を明らかにするために、私たちはこのモデルを製品の使用行動にマッピングしました。PagerDutyのシニアプロダクトアナリティクスマネージャーであるScott Bastekは、PagerDutyの製品導入を通じて各成熟段階を調べ、いくつかの興味深い発見をしました。

受動型チームは、インシデントの特定を監視ツールに頼っており、MTTRを短縮するための強固な対応策を構成するまでには至っていない。 反応型チームは、オンコールスケジュールに力を入れ、現状を維持するために複数の防御レベルを設定することで、問題が発生したときに解決することができる。 積極型チームは、サービス依存関係や変更イベントなどの高度なインシデント対応機能を導入し、問題が発生した時点で問題を理解し、診断する。 予防型チームは、ノイズ除去、イベントオーケストレーション、分析レポートなどを活用して、インシデントの発生を未然に防ぐ。

デジタルオペレーション成熟度モデルのどの辺りに位置するか

従業員の燃え尽きや離職を懸念するリーダーは、現在の成熟段階を評価し、運用成熟度モデルに示された例を参考に、新しい運用プロセスを導入する必要があります。最高の運用成熟度を達成するには、オンコールスケジューリング、調整済み課題管理、イベントインテリジェンス、およびプロセス自動化ツールを使用してDevOpsチームに投資することが最適です。これらの投資により、DevOpsチームは全てのインシデントに対してより積極的かつ予防的になり、組織全体のMTTAとMTTRの量を減らすことができます。

デジタルオペレーション成熟度モデルの詳細については、「Getting from Reactive to Proactive and Beyond（受動型から積極型へ、そしてその先へ）」をご覧ください。このビデオでは、Scott BastekとTejere Oteriがオペレーション成熟度のレベルについて掘り下げ、その結果についてより詳細な統計分析と考察を提供しています。

また、組織が最高の運用成熟度を達成するための例として、PagerDutyの最新eBookと最新の「デジタル運用の現状レポート」をダウンロードすることができます。

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

信頼できる電力源を持つことは、私たちの多くが当たり前のことと思っています。特に医療施設では、生命維持のために電力に依存している弱い立場の患者を守るため、安定した信頼できる電力を確保することが重要です。

しかし、サハラ以南のアフリカの農村部では、信頼できる電力を持つ病院は約28％に過ぎないと推定されています。停電がいつ、どのように発生するかを把握するためのデータがほとんどないため、病院職員による管理はますます困難になっています。

Nexleaf Analyticsは、この課題の解決に取り組んでいます。Nexleafは、中低所得国においてより良い健康上の成果を得るためのデータと技術ソリューションを生み出しています。健康推進団体、政府、地域コミュニティーと協力することで、大規模な意思決定のための実用的なデータを提供しています。Nexleafの使命は、人々の健康を向上させる持続的なソリューションを構築するために必要なデータを各国が確実に入手できるようにすることです。

データおよびアナリティクスの事例

電力供給が不安定な場合、地方の病院ではさまざまな問題が発生します。例えば、電力が不安定な場合、多くの病院はディーゼル発電機に頼っています。これはバックアップ電源を確保する唯一の方法ですが、不安定な電力システムに高コストで非効率的に備えざるを得ないことを意味します。こうした施設の多くは、停電の傾向を把握するためのベースラインデータがないため、病院職員はいつ停電が起こるか推測し、常に厳戒態勢を敷いています。また、ディーゼル燃料費の予算予測にも問題があります。

停電の時間やコストを正確に示すデータがなければ、これらの病院が追加資金を正当化することは困難です。Nexleaf Analyticsの医療機器プロジェクトマネージャーであるAmos Momanyi氏は、次のように述べています。「私たちの主な目的は、電力データの需要を記録し、データを可視化することによって支援できる問題や課題が何であるかを理解することでした」

PagerDuty、Nexleaf、Center for Public Health and Developmentの３社では、停電がいつどのように発生するかを理解し、停電発生時に医療施設を維持するためのプロトコルを確立することを目的としたパイロットプログラムを実施しました。ケニアの15の地方病院が、いくつかの目標を掲げてこのプログラムに参加しました。

電力データに対する要求を文書化する データの可視化によって支援される問題や課題を理解する アラートとデータが停電の解決にどのように役立つかを理解する

PagerDutyの威力

Nexleafは、PagerDutyと接続されたIoTセンサーを導入し、SMSとオンラインアプリケーションで病院職員に通知を送れるようにしました。これにより、職員は停電の根本原因を容易に把握できました。例えば、ある病院では、近隣の施設と電力を共有しているため、午前６時に停電が発生することがわかりました。この病院では、電力供給を予測可能にするために、電力使用時間を別の時間帯にずらしました。

PagerDutyプラットフォームのデータは、医療施設がディーゼルエンジン増強の必要性を説明し、予算超過の理由を正当化するのにも役立ちました。さらに良いことに、このデータは数カ月先の財務予測の精度を高めるのに役立ちました。

最も重要なのは、PagerDutyからのリアルタイム通知により、生物医学エンジニアが施設にいなくても停電の発生が検知できるようになったことです。アラート受信後、病院職員は迅速に行動し、施設に電力を再供給できます。これにより、手動でバックアップ電源を監視する必要がなくなり、患者の容体に大きな影響を及ぼす恐れのある停電を防ぐことができました。「PagerDutyのおかげで、停電による機器の不具合を原因とする死亡事故を未然に防げるようになりました」とMomanyi氏は述べています。

未来は明るい

パイロット運用の成功により、病院とその職員はさまざまな解決策を見出すことができました。病院の職員は、施設の電力管理に関する効果的かつ効率的な意思決定に役立つ電力データのユースケースを決定するために取り組みました。プログラムに参加した施設ではPagerDutyを使い続けており、Nexleafは新たな施設へとソリューションを拡大しつつあります。

Nexleaf Analyticsの歩みについては、Summit '22のセッションの全容をこちらでご覧ください。

PagerDutyのリアルタイムオペレーションがどのように非営利団体に力を与えるか、今すぐ14日間の無料トライアルをお試しください。

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