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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。
インテグレーション&ガイド
新着情報 PagerDuty® Process Automation Software & PagerDuty® Runbook Automation, Integrations, and More!
PagerDutyオペレーションクラウドの新しいアップデートと機能強化を発表することに興奮しています。製品チームによる最近の開発およびアプリのアップデートには、PagerDuty®プロセスオートメーション、パートナー統合およびアプリエコシステム、コミュニティ&アドボカシーイベントのアップデートが含まれています。私たちは、お客様がクラウド運用を最適化し、他のチームにエスカレーションされる問題の量を減らすために、あらゆる場所を自動化できるよう支援し続けています。今すぐ始めましょう。
最近リリースされたPagerDuty + Sumo Logic Job Step PluginとPagerDuty + AWS ECS Node Executor Pluginの詳細、およびPagerDuty® Process AutomationとRundeck Communityのアップグレード、バグ修正、パッケージ更新を最新の4.5.0 Releaseでキャッチアップすることができます。 PagerDuty App for Jira Cloudのサイドバーの更新、PagerDuty App for Jira Data Center Recertification、PagerDuty App for BMC Helix/Remedy を管理するKTSLへのサポート移行を含む、最新のパートナー統合とアプリエコシステムの更新をお楽しみ下さい。 イベントルールの廃止、イベントオーケストレーションへの移行、V1/V2 Webhooksの廃止など、製品廃止情報を常に把握してください。 今後のイベントに登録し、最近のポッドキャストやTwitchストリームを閲覧し、コミュニティチームや製品チームのメンバーと一緒に新製品やソフトウェア業界の最先端のプラクティスを学べます。
PagerDuty® Process Automation
PagerDuty® Process AutomationソフトウェアとPagerDuty® Runbook Automation 4.5.0
最新のPagerDuty® Process Automation Version 4.5.0には、以下の内容が含まれています。
Sumo Logic Job Step Pluginをリリースしました。Sumo Logicインスタンスと連携することで、インシデント診断のためのログ取得などの運用タスクを自動化できるようになりました。 AWS ECS Node Executor Puglin ユーザーは、単一のジョブステップまたはコマンドタブから、複数のECSコンテナにコマンドを実行できるようになりました。これにより、インシデント発生時にコンテナを再展開する前にタイムクリティカルな診断を取得するなどのタスクを容易に実行できるようになりました。
ハイライトをご覧いただき、プラグインなどの追加アップデートや修正についてご確認ください。
アップグレード、修正、パッケージの更新は、Rundeckオープンソース製品にもあります。それらの詳細や、GitHub で公開されているプルリクエストを見ることができます。
2022年8月10日のNessie Orchid Tower Release (4.5.0)についての詳細はこちら。
パートナーインテグレーションとアプリエコシステム
PagerDuty App for Jira Jira Data Center:マーケットプレイスアプリを1年間正式に再認定
既にPagerDutyをJira Data Centerと統合し、重要なサービスリクエストに取り組み、Jira Serverの課題とPagerDutyのインシデント間を双方向同期してインシデント解決を加速している方に朗報です。私たちはまた、Jira Data Center用のPagerDutyアプリを1年間正式に再認定し、AtlassianマーケットプレイスにおけるData Center Approved Statusを維持しました。
アプリの詳細はknowledge baseでご確認ください。
PagerDutyアプリ for Jira Cloud。Jira CloudのサイドバーにPagerDutyを表示する新オプションを今年9月に提供開始
Jira Cloudの新規顧客には、全Jira プロジェクトでPagerDutyがデフォルトでサイドバーに表示されません。 既存のJira Cloudプロジェクト管理者は、プロジェクトごとに Jiraサイドバー上の PagerDuty を非表示または表示する機能があります。
(上図:Jira CloudでPagerDutyのサイドバーがdisabledにされています)
(上図:PagerDutyのサイドバーをJira Cloudでenabledにできます)
ご不明な点がございましたら、PagerDutyアカウントチームまたはカスタマーサポート([email protected])までご連絡ください。
BMC Helix用PagerDutyアプリ/Remedy:パートナーKTSL社への所有権移管について
PagerDutyは、BMC HelixとRemedyのインテグレーションの所有権を、サービスマネジメントと統合の専門家であるBMC Eliteパートナー、KTSLに移管しました。今後、KTSLがこのインテグレーションをビルドし、サポートします。
製品廃止のお知らせ
今後予定されている製品の廃止について、チームにお知らせください。
Event Rulesの廃止とEvent Orchestrationへの移行
PagerDuty は、2023年1月31日にEvent RulesをEOL (End-of-Life)=停止することを決定しました。私たちは、お客様のために最も堅牢で信頼性の高いイベントドリブンのエンリッチメントとオートメーション体験の構築にリソースを捧げることを確実にするために、この決定を下しました。Event Orchestrationは、Event Rulesの次の進化形として年初にリリースされ、現在では、ユーザーがルールの量を圧縮し、ノイズ除去を改善し、よく理解されている手作業をより効果的に自動化するための最良の方法となっています。
このEOLをサポートするために、十分な移行経路を用意しています。さらに、EOLの日に、あなたが使っている残りのイベントルールをEvent Orchestrationに一対一で自動移行します。それ以降は、現在のイベントルールでできることは、全てEvent Orchestrationでできるようになります。Event OrchestrationはEvent Rulesと同じ機能を持ち、同じバックエンドアーキテクチャーを使用しているので、イベント処理には数十億イベント分のテストが既に実施済みだと確認できます。
(上図:PagerDuty Event Orchestration)
マイグレーションについて詳しくはknowledge baseをご覧ください Event Orchestrationの詳細 アカウントマネージャーへのお問い合わせ
V1/V2 Webhooks
現在、PagerDuty 環境で V1/V2 webhook 拡張を使用している場合、機能を維持するために V3 webhook サブスクリプションに移行する必要があります。
移行ガイドに従ってください。
重要な日程
V1 Webhooks** - V1 Webhook 拡張は、2021 年 11 月 13 日からサポート対象外(新機能やバグフィックスがない)となり、2022 年 10 月に機能停止となります。 V2 Webhooks** - V2 Webhook 拡張は、2022年10月にサポートが終了し、2023年3月に動作しなくなります。
必要なパーミッション
Admins* またはAccount Owners* は、アカウント全体を移行することができます。 Team Manager** は、割り当てられたチームのウェブフックのみを移行できます。
ウェブフックとは何ですか? ウェブフック(webhook)を使うと、PagerDutyアカウントで重要なイベントが発生したとき、例えばインシデントがトリガー、エスカレート、または解決したときに、HTTPコールバックを受け取ることができます。イベントに関する詳細は、Slackや独自のカスタムPagerDuty ウェブフックプロセッサーなど、指定したURLに送信されます。
ご質問がある場合は、PagerDutyの担当者またはサポートチーム([email protected])にご連絡ください。
Webhooksについてもっと知る。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
DevOps
組織が大規模なサービスをうまく構成するのに役立つPagerDuty Service Standards
DevOpsのベストプラクティスであるサービスオーナーシップは、多くの企業で採用が進んでいる手法です。サービスオーナーシップのメリットは多岐にわたり、開発チームと顧客、ビジネス、提供される価値との距離を縮めることができるなどの利点があります。開発者は、革新的で顧客満足度の高い機能を開発するインセンティブを得られるため、「構築し、所有するモデル」は、顧客体験に明確な効果をもたらします。
しかし、サービスオーナーシップへの移行は、特に数百、数千のサービスを抱える大企業にとっては困難です。サービスの定義や境界、誰が所有するかなど、全てが大変な作業となります。また、組織が迅速に拡張できるような方法でサービスが構成されていることを確認することは、テクノロジーエコシステム全体において不可能に近いことです。しかし、このレベルの可視性を獲得することは、より良いビジネス成果を得るために非常に重要です。
この問題に対処するため、PagerDutyは全プランでService Standardsを正式版として提供します。PagerDutyは、サービスベースのアーキテクチャーを通じてサービスのオーナーシップを重視しており、従来は個々のチームがサービスをどのように構成するかを決定することが可能でした。しかし、Service Standardsを利用することで、組織の全チームがベストプラクティスがどんなものかを理解でき、また、サービスオーナーシップに慣れていないチーム間で、チームと組織の両方にとって有益な方法で、その知識を標準化する柔軟性を手に入れることができます。 Service Standardsは、全てのチームが、サービスの構成がサービスオーナーシップのベストプラクティスを順守していることを確認するのに役立ちます。これは、サービスが有益であり、適切なツールと統合され、適切な人材によってサポートされていることを意味します。Service Standardsでは、サービスオーナーシップを採用するだけでなく、組織全体でそれを拡大するために、チーム全体に標準を導入するための可視性と手段を提供します。
Service Standardsの導入
サービスを設定する場合、組織内の各チームはそれぞれ異なる方法をとります。インシデント発生時に全チームが迅速に行動するために必要な情報を持っているサービスもあれば、そうでないものもあります。このように統一性がないため、情報が失われたり、純粋にチーム固有の知識として閉じられたりして、エコシステム全体に問題が発生する可能性があります。また、マネージャーや管理者が、自分たちの担当するサービスが健全な状態かどうかを知ることは不可能に近いのです。 Service Standardsは、個々のエンジニアがより上手にサービスを設定する方法を理解するのに役立つだけでなく、マネージャーや管理者が組織全体でこれらの標準を拡張するためのガイドを提供します。
成功のためのガイドラインで、より良いサービスを設定する
クラウドへの移行に伴い、あらゆる組織のサービスの数は飛躍的に増加し、中央の管理・作成チームではその負荷を処理しきれないことが多くなっています。さらに複雑なのは、サービスオーナーが、それぞれ異なる方法でサービスを構成していることです。命名規則から説明文、適切な人材が待機しているかどうかに至るまで、サービスは提供する情報の深さにおいてさまざまです。
その結果、多くの手戻りが発生することがよくあります。こんなシナリオを想像してみてください。新しいサービスを立ち上げたものの、本番稼動前にブロックされてしまう。その結果、さまざまな変更や修正を加えて出荷するように言われる。そして、これらの要件は成文化されておらず、広く知られていないことが多いため、チームは何度も間違いを犯し、サービス作成プロセスに苦痛と労力を上乗せすることになります。
お客様からよく聞きます。実際、「"良い"とはどういう状態ですか」という質問が上位を占めます。本当のところ、場合によりけりで、チームそれぞれに合った固有のものであることは間違いありません。
Service Standardsを使えば、チームは会社の方針に従って「良いこと」とは何かを標準化することができます。PagerDutyは、サービスがよく構成されているとみなされるために必要な深さとコンテキストを持つために、各サービスが満たすべき9つの標準を提供します。これらは全てオンとオフの切り替えが可能になっています。
説明責任を果たすための監査サービス
また、Service Standardsは、マネージャーや管理者に対して、設定要件が大規模に満たされることを保証するために必要なレベルの制御を提供します。管理者は、これらの標準を組織の他のメンバーが閲覧できるように公開するかどうかを決定し、可視性を決定することができます。また、企業のニーズに応じて、9つの標準のオン/オフを切り替えることもできます。より詳細なレベルでは、管理者はこれらの標準をサービスのサブセットのみに適用して、より柔軟に対応することができます。また、サービスのパフォーマンスデータはPagerDutyからエクスポートし、必要に応じて共有することで、説明責任を果たし、進捗状況を示すことができます。
試してみませんか
Service Standardsは、全組織がサービスオーナーシップのベストプラクティスを展開できるようにします。この機能により、エンジニアは何が本番環境に適しているかを理解し、新しいサービスを出荷するために必要な労力を軽減できます。管理者やマネージャーにとって、Service Standardsは、テクノロジーエコシステム全体の説明責任を促進し、進捗を評価する方法を提供するのに役立ちます。やがてこれは、迅速な状況を求めるファーストレスポンダーのためのインシデント対応を改善し、組織レベルでの運用の成熟を促進するのに役立ちます。
詳細については、最近のウェビナー「How to Standardize Service Ownership at Scale for Improved Incident Response」をご覧いただくか、こちらのKnowledge baseの記事をご覧ください。
Service Standardsを実際に見てみたい方は、PagerDutyを14日間無料でお試しください。
この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
インシデント&アラート
IHS Markitの事例:PagerDutyとServiceNowによるインシデント管理の一元化
今日のデジタル社会では、企業は常に変化を強いられています。クラウドへの移行や大規模なDevOpsの展開などが、全てイノベーションを推進するというお題の下で行われています。しかし、モノリシック構成からマイクロサービスへ移行すると、アプリケーションはますます分散化します。問題が発生したとき、顧客はチームやサービスの数、アーキテクチャーの複雑さなど気にも留めません。ただ、必要なときに必要なサービスが動くかどうかが重要なのです。
そのためには、チーム、サービス、データなど、全てを一元管理することが重要です。緊急の仕事がチケット管理ツールで一元管理されては困ります。
そこで、ITサービスマネジメントツールとデジタルオペレーションプラットフォームを組み合わせることで、中央のITと分散型チームとの間のギャップを埋めることができます。PagerDutyとServiceNowを組み合わせることで、レスポンダーたちは遅滞なく行動を起こすための自動化を利用できるようになり、全アクティビティーの完全な履歴を維持しながら、数秒でリアルタイムの対応を実現することが可能になります。この組み合わせにより、インシデントに対するビジネスレスポンスも合理化され、関係者は常に最新の情報を得られます。
この”better together”アプローチは、現代の企業スタックで活用されているインシデント対応プロセスの代表的なものです。PagerDutyは、IHS Markitのようなお客様にもご利用いただいています。
文化の衝突
IHS Markit は、金融サービスプロバイダー、政府機関、その他主要産業に対して、分析およびインテリジェンスを提供しています。英国ロンドンに本社を置き、全世界で1万6000人の従業員を擁しています。
IHS Markitは、急速に拡大するハイブリッド運用をまとめ、ビジネス全体を完全に可視化し、集中管理されたコマンドセンターからインシデントを管理する必要がありました。同社は買収によって成長し、現在では約700の顧客向けサービスと300の社内向けサービスを提供していました。この規模でのインシデントの追跡は非常に困難であり、ビジネスのさまざまな領域が持つ相反する要件によって、さらに困難になっていました。
DevOpsチームは** 、あらゆる監視のニーズを完全に制御しながら「アジャイルで自律的で素晴らしい」状態を維持したいと考えていました。DevOpsの主要な要件は、チームがチケットを発行したり、ServiceNowにログオンする必要がないようにすることでした。 オペレーションコマンドセンター(OCC)チームは** 、より伝統的なITIL(IT Infrastructure Library)構造に基礎を求め、ServiceNowをベースにシステムを構築していました。このチームは、より優れたスケジューリングとエスカレーションポリシーを求めましたが、"既存の成熟したインシデント管理プロセスへの影響はゼロ "でした。 コンプライアンス** IHS Markitは、さまざまな規制下で多くの製品を扱っているため、ServiceNowの共通の記録システムで管理し記録を追跡することを望んでいました。 経営陣は** 、チームがDevOpsと連携しているか、より伝統的なITILを基にしているかに関わらず、全チームにわたりグローバルな監視を行うことを求めました。経営陣は、ServiceNowがこの可視性を提供することを望んでいました。
IHS Markit は既にPagerDuty を導入していましたが、その利用を拡大したいと考えていました。IHS MarkitのObservability担当ディレクターであるJohn Kennedy氏は、"インシデント管理を全社的に水平展開し、適切に管理できる1つのエンタープライズサービスにまとめたいと考えていました"と説明しています。
全ての人のためのソリューション
これを実現するために、IHS MarkitはServiceNowのインシデントとPagerDutyを統合しました。IHS MarkitはPagerDutyのカスタマーサクセスチームと協力し、PagerDutyのプラットフォームをカスタマイズして全ての要件に対応し、運用を改善しました。
これにより、DevOpsチームはPagerDuty内でサービスのオーナーシップを維持できるようになりました。これらのチームにとって、ServiceNowとの統合は「ステルス」導入されたもので、プラットフォームにログインすることなく、全てがServiceNowで追跡・記録されました。
OCCチームにとって、PagerDutyとServiceNowの統合は、既存のインシデント管理プロセスをそのまま維持することを保証するものでした。PagerDutyをまだ導入していなくても、誰もがPagerDutyのダッシュボードを介して主要なインシデントを監視することができます。インシデントマネージャーはワンクリックで、上級管理者や製品の専門家など、さまざまなスキルを持つ専門チームを迅速に呼び出すことができました。
また、PagerDutyはシステム全体を一望できるため、コンプライアンスと経営陣の可視化の要件も満たしています。
「全ての重大インシデント管理はPagerDutyで行われ、インシデントがPagerDutyの外で発生した場合は、重大インシデントの管理者がPagerDutyと同期するようになっています」とJohn氏は説明します。「そのうえで、レスポンスプレイを使って経営者を呼び寄せ、迅速な意思決定ができるようにしているのです。その結果、特にMTTRの面で大きな効果を得ています」。
このBetter Together連携により、中央のIT部門は、分散したチーム全体への可視性とアクセスを確保することができます。これは、IHS Markit が成長を続けていく上で不可欠なものです。
IHS Markitの次なる目標は?
今後、IHS Markit は可視性の一元化を進めていく予定です。「アジャイルとDevOpsの方法論が全社的に大きく広がっており、インシデント管理のコンバージドモデルの次の進化を考える必要があります 」とJohnさんは述べています。
また、DevOpsが「アジャイルかつ自律的」であることを維持することも、主要な焦点となることでしょう。「そのため、ServiceNowのテクニカルサービスを考え、その階層にフックする必要があるかどうかを判断する必要があります」と、Johnさんは説明します。「ガバナンスも重要ですーつまりシステムの品質を維持し、それをどのように一元管理するかということです」。
DXが進み、チームがこれまで以上に分散する中で、緊急の仕事を管理するビジネスプロセスをリアルタイムで運用できることが重要です。PagerDutyがServiceNowやその他のITSMツールをどのように強化し、解決時間の短縮と連携強化を実現するかについては、以下のリソースをご覧ください。
ITSMツールとPagerDutyの組み合わせで、リアルタイムに仕事をするためのダイナミックなデュオを作る方法
ITSMの強化
ソリューション概要 PagerDutyでITSMワークフローを拡張する
そして、PagerDutyの動作を確認する準備ができたら、14日間無料でお試しください。 訳注:IHS Markitは2022年2月にS&P グローバルに買収されました。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
ベストプラクティス
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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。
インテグレーション&ガイド
5つの簡単なステップで根本を探る(原因分析)
PagerDutyでインシデントを割り当てられたとき、最初にすべきことは何でしょうか?すぐに「受任!(Acknowledge)」と思った方は間違っていませんが、その後は、できるだけ早く、痛みを伴わずに問題を解決することが大切です。解決への第一歩は、最初にインシデントの原因を調査し、簡単に修正策を講じられるようにすることです。 PagerDutyのプラットフォームでは、Root Cause Analysis(根本原因分析)*は、レスポンダーであるあなたにできるだけ多くのコンテキストと実用的なインテリジェンスを提供することを目的とした一連の機能を指します。過去に発生したインシデントや関連するインシデント、インシデントの発生頻度に関する情報を表示することで、レスポンダーは根本原因を特定するために必要な状況認識を素早く得ることができ、迅速なトリアージと、そして最終的には早期解決につながるツールを手にすることができます。また、過去のデータに基づき、発生源と思われる場所がハイライト表示され、状況を把握しやすくなります。 ここでは、インシデントの詳細ページで、潜在的な根本原因を調査するのに役立つ5つの場所を紹介します。
- Outlier Incident
インシデントを最初に開くとき、[Outlier Incident]分類ラベルを探します。このラベルはインシデント名の直下にあり、"Frequent", "Rare", "Anomaly "のいずれかの分類ラベルが表示されます。この分類ラベルに基づいて、このインシデントが以前に発生したことがあるかどうか、また過去の経験に基づいてどう対応すべきかをすぐに判断することができます。ラベルにカーソルを合わせると、それぞれの定義が表示されます。
- Past Incidents
サービス上でインシデントが発生した頻度を決定したら、ページのさらに下にある[Past Incidents]タブに移動します。ヒートマップが表示され、このオープンインシデントのような過去のインシデントが過去6カ月間にいつ発生したかが示されます。色のパターンを探す(色が濃いほどインシデントが集中している)か、ヒートマップの色にカーソルを合わせると、関連するインシデントの詳細が表示されます。その下には、オープンインシデントのような過去のインシデント上位5件(もしあれば)の詳細と、それらがいつ発生したか、誰が最後にインシデントを変更したかについての情報が表示されます。注:その人は、インシデントに際して何をしたか尋ねたり、それに関するメモを見たい場合、素晴らしいリソースになります。過去のインシデントの詳細ページを開くには、ハイパーリンクされたタイトルをクリックします。
- Related Incidents
もう一つの簡単な情報源は、[Related Incidents]タブです。ここでは、同じサービス上の類似のインシデントしか表示されない過去のインシデントとは異なり、全サービスからあなたの問題に関連する可能性のある進行中のインシデントがあるかどうかを確認できます。ビジネス全体のインシデントの範囲(これは孤立したものか、より大きな問題の一部か)を理解することは、影響を理解し、問題を解決するために協力する必要がある人を迅速に特定するのに役立ちます。
- Probable Origins
インシデントの詳細ページにある[Probable Origins]ウィジェットを使用して、トリアージ作業を素早く始められます。このウィジェットは、インシデントが現在のオープンインシデントの類似イベントの直前に発生したか、または直後に発生したかなどの履歴データに基づいて、発生源の可能性のパーセンテージを計算します。
- Change Correlation
最後に、インシデントの原因となった可能性のあるインフラやコードの変更に気付いている場合、解決を大幅に加速できます。インシデントの詳細ページの[Recent Changes]に表示される[Change Correlation]は、時刻、関連サービス、PagerDutyの機械学習に基づいて、インシデントに最も関連する最近の変更イベントを3つ表示します。最近の変更イベントには、プラットフォームがイベントを表面化させた理由が表示されるため、潜在的な原因を簡単に絞り込めます。
ナレッジチェック! 正しいでしょうか、間違いでしょうか?: [Past Incident]タブには同じサービスのResolved Incidentsが表示され、[Related Incidents]には他のサービスのOpen Incidentsだけが表示されます(ページ下部の回答を参照)。
いかがでしたでしょうか?これら5つの、コンテキストをすばやく取得し、トリアージ作業を開始するために調べられる場所を忘れないでください。
インシデントを迅速に解決し、ダウンタイムをさらに短縮するには、この一連の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」が1つであることを示すような用語ではなく、「probable」cause または「 proximate」causeという用語を採用する方向に変化していることも注目に値します。
ナレッジチェックの回答:誤りです。過去のインシデントは同じサービス上で解決された過去のインシデントのみを表示するという記述は正しいのですが、関連インシデントは全サービス(現在のインシデントが起きているサービスを含む)上で未解決の、または最近解決した他のアクティブなインシデントを調べ、現在のインシデントに関連しているインシデントがあるかどうかを確認します。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
DevOps
PagerDuty、2022年のGigaOm RadarでAIOpsソリューションのリーダーとしてデビュー
毎年、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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。
New! AWSユーザー共通のAutomated Diagnostics機能
今日の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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。
Slack on Webhooks V3の専用インシデントチャンネルの改善 - アーリーアクセス
本日、Dedicated Incident Slack Channelの改良版のアーリーアクセスを開始することができました。この改良は以下の通りです。
全てのインシデントの詳細、履歴、およびアップデートを表示する 全てのインシデントアクションを実行する 全レスポンダーをチャンネルに追加する ズームコンファレンス専用ブリッジの掲載または作成
この機能を利用するためには、Slack on WebHooks V3にアップグレードし、PagerDutyサポートにアーリーアクセスをリクエストする必要があります。 正しいバージョンでアーリーアクセスができたら、専用のインシデントチャンネルを作成する方法が2つあります。
- Slackにて
Slackのインシデント通知から、「View | Create Channel」を使用して、デフォルトのネーミングスキーマで新しいインシデント専用チャンネルを作成します。チャンネルがすでに存在する場合は、チャンネルのハッシュタグが付いたメッセージが投稿されます。
- PagerDuty Web 経由
Incident Pageで、「Set the Channel」でチャンネルを設定する。アーリーアクセス中は、「BETA」タグが表示されます。
その後、ユーザーは既存のチャンネルを選択するか、新しいSlackチャンネルを作成することができます。
新しいチャネルを作成する場合、ユーザーはデフォルトの名前を受け入れるか、新しい名前を割り当てることができます。チャンネルは公開にも非公開にも設定できます。
注:PagerDutyアカウントに複数のSlackワークスペースが接続されている場合、ユーザーはチャンネル接続に必要なワークスペースを選択することができます。
作成すると、PagerDutyのウェブのUIとSlackではこのように表示されます。
この新機能を活用していただくことを期待するとともに、ご意見をお待ちしています。
次はどうする?
この機能は、Slack on Webhooks V3をご利用の全てのお客様に対して、来月には公開する予定です。
また、チャンネル作成の効率化・自動化により、この機能の充実を図っています。
この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
最新情報:ZendeskでPagerDutyのAutomation Actionsが利用可能に
顧客の期待値の変化
ここ数年、顧客からの要求が大幅に増加し、カスタマーサービスの担当者はプレッシャーを感じています。最近の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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。
新着情報 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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。
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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。
カスタマーサービスにおける次の進化
「カスタマーサービスソフトウェアはこの10年で大きく進化したが、どれも同じ問題を解決しているように見える!」。これは、全体的な応答時間と解決時間の短縮に関する最近のブレインストーミングの会話で、あるカスタマーサービスリーダーが発した言葉です。
現代のカスタマーサービス担当者の役割は、ますます複雑になってきています。カスタマーサービス担当者は、高度な共感とコミュニケーションを必要とする最前線の顧客対応に努めなければならないだけでなく、顧客に影響を与える混乱が生じたときに、複数のシステム、チャネル、「信頼できる情報源」を駆使して、バックオフィスのエンジニア/開発/ITチームとコミュニケーションをとり、協力しなければならないという負担がかかっています。テクノロジーの進化と社内システム、ツール、プロセスの複雑化は、問題をさらに深刻にしています。
この点を説明するために、金融サービス会社ABCに勤務するカスタマーサービス担当者の例で、ログイン失敗に関するチケットを受け取った場合を考えてみましょう。カスタマーサービス担当者は、ヘルプデスクシステムのキューの一番上にあるチケットを受け取りますが、このチケットに加えて、同様の問題に関する50件のチケットがキューに蓄積していることに気づきます。オンラインポータルにパフォーマンスの問題がある可能性があることに気づいたカスタマーサービス担当者は、エンジニアリングチームに問題をエスカレーションし、支援を求めました。
このシナリオでは、従来のカスタマーサービスソフトウェアに関連するカスタマーサービスワークフローとプロセスの限界が見え始めています。このソフトウェアは、カスタマーサービス担当者が単発の顧客要求を迅速に解決して対応できるようにチケットキューを整理して優先順位をつけるなど、フロントオフィスでの顧客とのコミュニケーションやチケットに関する問題を解決する素晴らしい機能を備えています。しかし、システム停止やバグなどの中核的な問題を解決するために、バックオフィスのエンジニア/開発/ITチームの支援を必要とする場合はどうでしょうか。
カスタマーサービス担当者は、技術的な問題をエスカレーションするためのワークフローやプロセス、そして解決に向けた進捗状況の可視化など、多くの課題に直面しています。典型的なワークフローは、次のようなものです。
顧客がパフォーマンスの問題に遭遇し、カスタマーサービスにヘルプデスクチケットを提出する。 カスタマーサービスは、ヘルプデスクシステムでチケットを受け取る。 カスタマーサービス担当者は、コミュニケーションプラットフォームのタブを切り替える。SlackやTeamsの共有チャンネルで呼びかけ、(場合によっては個々の専門家に)表面化した技術的な問題にバックオフィスでも気づいているかどうかを確認する。 この例では、エンジニア/開発/ITチームは気づいていない。カスタマーサービス担当者は、社内のWikiやスプレッドシートを参照し、どのチームがサービスを担当しているかを把握する。 カスタマーサービス担当者は、別の社内ヘルプデスクシステム(Jiraなど)に移動し、社内チケットを提出する。 エンジニア/開発/ITチームがインシデントを解決すると、コミュニケーションプラットフォームに更新が投稿される。 カスタマーサービス担当者は、ヘルプデスクチケットシステムとコミュニケーションプラットフォームを同時に切り替えて、情報を収集し、顧客に対応しなければならない。
さらに、可視性の問題から、カスタマーサービス担当者は自分自身や他の人に問いかけます。
バックオフィスのチームは、顧客に影響を与えるテクノロジーの問題を認識しているのか。 修正作業は行われているのか。 この問題について、顧客に伝えられることは何か。 この問題の解決に向けた進捗状況はどうか。どれくらい時間がかかるか。
最悪なのは、顧客のチケットが技術チームに引き渡されると、カスタマーサービスの評価基準となるビジネスルールや成功基準が適用されなくなることです。その結果、初回コンタクト解決率、応答時間、解決時間、および顧客満足度に悪影響が生じます。これは、タイムリーな顧客対応に必要な手段や可視性をカスタマーサービスが欠いているためです。
今日、ほとんどのカスタマーサービス組織は、技術チームからサイロ化されています。このサイロ化の影響は、コラボレーションを促進するためのツールやシステムによってさらに悪化します。例えば、カスタマーサービスは、面倒なコピー&ペースト作業によってさまざまなプラットフォームで情報を重複させ、他のチームが技術的な問題を解決している間に、複数のシステムに注意を散らしていることがよくあります。
カスタマーサービスとエンジニアの両チームとの会話からは、顧客体験を向上させるために、コミュニケーションの壁を取り払い、コラボレーションすることを強く望んでいることが分かります。エンジニア/開発チームは、デジタル資産の健全性を示すもう一つの重要なシグナルとして顧客を扱い、ダウンタイムを減らすことに注力しています。一方、カスタマーサービスチームは、顧客の期待に応えるために応答時間と解決時間を短縮することに引き続き注力しています。技術的な問題が最初に顧客から提起された場合、カスタマーサービスチームは、顧客に影響を与える混乱を正しくエスカレーションするための合理的な方法を必要としています。特に技術チームによる技術的な問題の解決を含むときは、顧客チケットのライフサイクルの始めから終わりまでが完全に可視化されていなくてはなりません。
そこで、次のような疑問が生じます。バックオフィスのチームが顧客に影響を与える障害に気づいていない場合、カスタマーサービスが顧客の問い合わせやリクエストに迅速に回答し、最前線からテクノロジーの問題をエスカレーションするために必要な可視性と情報をどのように提供すればよいのでしょうか。
異なるアプローチ
カスタマーサービスと技術チームの連携がうまくいっていないことが、ダウンタイムやレスポンス、解決時間の増加につながっていることを組織が認識したとき、異なる視点が必要になります。デジタル資産の健全性を示すもう一つの重要なシグナルとして、顧客を認識するのは今なのです。
「顧客は重要なシグナルである」が受け入れられると、組織はカスタマーサービスと技術チームの間の壁を取り払う方法を見出します。PagerDutyを他のテクノロジースタックの中枢神経系として、またリアルタイムオペレーションを行うメカニズムとして活用することで、各チームはインシデント対応プロセスに従事するために選択したシステムを離れることなく「自分の持ち場で働く」権限を与えられます。
PagerDutyをインシデント対応に関わる他のテクノロジースタックと統合することで、各チームは自分が選んだシステムで作業を行うことができます。PagerDutyは、各チームが作業を行うさまざまなシステムやプラットフォームにインシデント情報を配信し、「唯一の信頼できる情報源」となるのです。
カスタマーサービスエージェントが「ABC社」でインシデント関連のチケットを受け取るという以前のシナリオとは異なり、ワークフローは以下のステップに簡略化されます。
顧客がパフォーマンスに問題を感じ、ヘルプデスクチケットをカスタマーサービスに提出する。 カスタマーサービスは、ヘルプデスクシステムでチケットを受け取り、会社のバックエンド技術に問題があることに気付く。 カスタマーサービス担当者は、ヘルプデスクチケットのシステムUIに直接ある内部ステータスダッシュボードで、デジタル資産の健全性を確認できる。 技術的な問題が技術チームに知られていない場合、カスタマーサービスは、特定のビジネスサービスを担当するチームに対して「インシデント」を作成し、トリアージする。アラートは修復に携わるメンバーだけに飛ぶ。 カスタマーチケットとPagerDutyインシデントの間には、双方向のリンクが自動的に作成される。解決までの進捗は、チケットプラットフォームのチケット/ケースビューに流れる。 カスタマーサービス担当者は全ての情報をリアルタイムで受け取ることができ、顧客対応にかかる時間を短縮することができる。
そして何より、このコラボレーションプロセス全体は、カスタマーサービス担当者が日常業務で使用しているチケットシステム内で直接行われるのです。
カスタマーサービスチームと技術チーム間のコミュニケーションとコラボレーションプロセスを最適化することで、エスカレーションプロセスにおいて顧客に影響を与えるような混乱が発生するリスクを軽減することができます。カスタマーサービスチームは、複数のシステムを行き来したり、プラットフォーム間で同じ情報を重複させたりする必要性を排除できます。その結果、初回コンタクトの解決、応答時間、解決時間、そして最終的には顧客満足度が改善されます。
この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
PagerDuty Summit 2022 ハイライト Part 2
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がデジタルファーストの世界でのリーダーシップはどうあるべきかを対談しました。
これまで以上に強力に。PagerDutyのモバイルアプリを刷新し、インシデント対応のさらなる向上を目指す
2020年は、私たちの働き方に革命をもたらしました。多くの人が一夜にして、フルタイムのオフィスワークから100%リモートワークへと移行しました。そして今、再びオフィスでの仕事が視野に入ってきたため、企業はフレキシブルな働き方を継続する方法を考えています。しかし、これには課題が増え、この働き方に合ったツールが必要とされています。
PagerDutyのモバイルアプリケーションは、App StoreやGoogle Playで星4.8の評価を得ており、高い認知度を誇っています。私たちは、適切な人にすぐに連絡することがいかに重要かを理解しています。だからこそ、レスポンダーがいつでもどこでも重要な仕事を解決できるように、iOSとAndroidに多大な投資を行ってきました。
このブログ記事では、最も必要な情報を見つけるための新しいナビゲーションインターフェース、過去および現在のインシデントを通じたインシデントインテリジェンスの向上、自動診断の起動と修正アクションを実行するための自動化の活用など、最もエキサイティングな改善点をいくつかご紹介します。
必要な情報を簡単に見つけられる
レスポンダーは、自分がいつオンコールになるのか、どのようなサービスのためにオンコールになるのかを知る必要があります。万が一、呼び出しを受けた場合、自分が担当する技術サービスがどのように機能しているかを確認できることが極めて重要です。そして最も重要なことは、これらの情報をモバイルアプリから一目で確認できることです。複数の画面を参照したり、アプリの奥深くに埋もれた情報を探したりする必要はありません。
新しいPagerDutyモバイルホーム画面エクスペリエンスでは、レスポンダーが必要とする最も重要な情報が容易に利用可能です。このデザイン変更により、オープンインシデント、オンコールシフト、影響を受けるテクニカルサービスを中心に表示し、アプリ内のナビゲーションに必要なタップ数を減らすことができます。
デザイン変更されたホーム画面は、現在、早期アクセス可能です。試してみたい方は、この早期アクセスフォームに必要事項を記入し、「新しいモバイルホーム体験」の選択をすると、案内が送られてきます。
フレキシブルに働くということは、最も重要な瞬間に、クリティカルインシデントの状況を自由に把握できることを意味します。インシデントが発生したら、できるだけ早く対応し、影響を軽減するための最善の方法を決定する必要があります。
その方法の1つが、新しいモバイルインシデント詳細画面です。この画面では、視覚的に分かりやすく、最も重要な機能全てにアクセスできるため、インシデント対応に迅速に取り組むことができます。インシデントで作業している他のレスポンダーのメモ、変更イベント、過去のインシデント、最新のアラートなど、インシデントに関する最も重要な情報をすぐに利用することができます。
また、更新版のモバイルインシデント詳細画面にある新しいカルーセルでは、プレーの実行、優先度やメモの追加、ステータスアップデートの投稿などを行うことができます。
過去または現在におけるクリティカルインシデントのコンテキストを獲得する
インシデントが発生したとき、最大のハードルの1つは、「以前にもあったか」という質問に答えることです。もしあれば、以前に動作したプレーを実行したり、自動化シーケンスを実行することで簡単に解決できるかもしれません。しかし、そのような過去の状況を見つけることはしばしば困難であり、それは誰にも許されない無駄な時間です。
PagerDutyモバイルアプリのPast Incidents(過去のインシデント)機能では、現在アクティブなインシデントと同じサービス上で発生した、類似したメタデータを持つインシデントが表示されます。この追加コンテキストにより、正確なトリアージが容易になり、解決までの時間が短縮されます。例えば、自分やチームの誰かが過去に同様のインシデントに巻き込まれたことがあるかどうかを確認し、詳細を調べてどのような改善策が取られたかを知ることができます。 Change Events(変更イベント)。システム内の変更は、しばしばインシデントの影の犯人です。特に、多くの組織が1日に何十回、何百回も新しいコードを出荷している場合、どの変更がインシデントを引き起こしたかを正確に特定するのは難しいため、見過ごされがちです。しかし、「Gartner社の推定によると、全てのパフォーマンスインシデントの約85%は追跡可能」です。変更イベントにより、お客様の環境に影響を与える変更を確認し、潜在的な根本原因を特定することができます。変更イベントは、モバイルアプリの2つのエリア(新しいモバイルインシデントの詳細画面と、サービスの詳細画面)で簡単に確認できます。目的のインシデントをタップして変更イベントにスクロールするか、サービスディレクトリーに移動してサービスを選択し、最大2つの変更イベントを表示できます。表示されるイベントの詳細には、日時、概要、サービス、タイプ、リンク、ソースが含まれます。 インシデント対応におけるもう1つの重要な情報は、問題の影響範囲を理解することです。この情報を得るための1つの方法は、Service Dependencies(サービス依存関係)を理解することです。大規模で顧客向けのビジネスサービスが、技術的なサービスインシデントによって問題が発生している場合、問題の範囲をよりよく理解するために、より速く、より文脈的なインテリジェンスで対応する必要があります。モバイルアプリのサービス依存関係画面では、どのサービスが影響を受けるかを表示して、範囲をよりよく理解することができます。サービス依存関係は、サービスディレクトリーの各サービスのプロファイル内に表示されます。
自動化を活用した迅速な対応
テクノロジー環境がより複雑になるにつれ、人々の時間と認知資源を節約することがこれまで以上に重要になっています。これは、人間ではなく、機械が最初の防衛線として機能することを意味します。
反復的な手作業やよく理解されている事象を自動化することで、対応者の不必要な労力を軽減し、本業に集中できるようにし、最も必要とされている事象にのみ注意を向けるようにできます。これを実現する1つの方法が、指先のタップで実行できる自動化です。
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%が自組織で離職率が上昇したと答え、過去1年間で離職率が上昇しなかったと答えたのは34%のみでした。
大退職時代が続く中、企業は従業員の生産性を維持し、離職率を下げるための新たな方法を模索しています。私たちは、ベストプラクティスに投資することが大きな違いを生むことを、お客様との経験から知っています。
デジタルオペレーション成熟度モデルは、一般的な行動を段階的に説明し、リアルタイムのオペレーション上の課題に対処する準備ができているかどうかによって、成熟度を分類します。チームは、デジタルトランスフォーメーションの旅を容易にするベストプラクティスとプロセスに投資することで、成熟度を高め、より積極的になることができます。
デジタルオペレーション成熟度モデルとは
デジタルオペレーション成熟度モデルは、対応チームが現在の成熟度を評価し、システム停止やシステム障害の検出、トリアージ、動員、対応、解決をより短時間で行うための新しいデジタルオペレーションを構築することを支援します。
このモデルには、5段階のオペレーション成熟度が含まれています。
Manual(手動型)。** 開発者が目の前の問題に奔走し、リクエストには夜通しでその場しのぎの対応が必要。 Reactive(受動型)。** システム障害や顧客からのクレームが発生すると、調整と計画なしに常に消火態勢に入る。 Responsive(反応型)。** 問題が発生すると、調整と計画が合理化され、解決される。 Proactive(積極型)。** シームレスで協調的な問題管理により、顧客が気づく前に問題を解決する。 Preventative(予防型)。** 問題が発生する前に先手を打ち、過去と現在のインシデントから継続的に学ぶ。
デジタル運用成熟度モデルの目標は、DevOpsチームがITインフラの一貫性、信頼性、回復力を管理・維持するために、積極型および予防型の段階に移行することを支援することです。また、ワークフローとワークライフバランスがより予測しやすくなるため、従業員の燃え尽きが減少します。
オペレーション成熟度向上によるメリット
2021年、PagerDutyのプロダクトマーケティングアナリストであるTejere Oteriは、優れたオペレーションプラクティスがビジネスインパクト、オペレーションの健全性、人的要因に与える影響を理解するために調査を実施しました。調査結果を分析した際、Tejereは、受動型組織の参加者と予防型組織の参加者の回答の仕方に違いがあることに気づきました。
チームの仕事量について質問したところ、受動型組織の参加者の33%が仕事量は均等に分散していると感じていましたが、大多数は仕事量の改善を希望していました。同じ質問を予防型組織にしたところ、83%が仕事量は均等に分散していると感じており、そう思わないという回答は意外にもありませんでした。
また、Tejereは、受動型組織は予防型組織に比べて、従業員の離職率が2倍高くなることを発見しました。具体的には、予防型組織は反応型組織に比べて、プライベートな時間や睡眠時間を仕事のためのインシデントに費やすことが少なく、燃え尽きが少なく、離職率が高まる可能性が低いことがデータ分析から明らかになりました。
成熟度モデルを製品の使い方にマッピングしたらどうなるか
オペレーション成熟度モデルをお客様に紹介し、お客様全体に見られる傾向を明らかにするために、私たちはこのモデルを製品の使用行動にマッピングしました。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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。
公共衛生のためのより良いデータ。NexleafとPagerDutyによるヘルスケアの監視方法
信頼できる電力源を持つことは、私たちの多くが当たり前のことと思っています。特に医療施設では、生命維持のために電力に依存している弱い立場の患者を守るため、安定した信頼できる電力を確保することが重要です。
しかし、サハラ以南のアフリカの農村部では、信頼できる電力を持つ病院は約28%に過ぎないと推定されています。停電がいつ、どのように発生するかを把握するためのデータがほとんどないため、病院職員による管理はますます困難になっています。
Nexleaf Analyticsは、この課題の解決に取り組んでいます。Nexleafは、中低所得国においてより良い健康上の成果を得るためのデータと技術ソリューションを生み出しています。健康推進団体、政府、地域コミュニティーと協力することで、大規模な意思決定のための実用的なデータを提供しています。Nexleafの使命は、人々の健康を向上させる持続的なソリューションを構築するために必要なデータを各国が確実に入手できるようにすることです。
データおよびアナリティクスの事例
電力供給が不安定な場合、地方の病院ではさまざまな問題が発生します。例えば、電力が不安定な場合、多くの病院はディーゼル発電機に頼っています。これはバックアップ電源を確保する唯一の方法ですが、不安定な電力システムに高コストで非効率的に備えざるを得ないことを意味します。こうした施設の多くは、停電の傾向を把握するためのベースラインデータがないため、病院職員はいつ停電が起こるか推測し、常に厳戒態勢を敷いています。また、ディーゼル燃料費の予算予測にも問題があります。
停電の時間やコストを正確に示すデータがなければ、これらの病院が追加資金を正当化することは困難です。Nexleaf Analyticsの医療機器プロジェクトマネージャーであるAmos Momanyi氏は、次のように述べています。「私たちの主な目的は、電力データの需要を記録し、データを可視化することによって支援できる問題や課題が何であるかを理解することでした」
PagerDuty、Nexleaf、Center for Public Health and Developmentの3社では、停電がいつどのように発生するかを理解し、停電発生時に医療施設を維持するためのプロトコルを確立することを目的としたパイロットプログラムを実施しました。ケニアの15の地方病院が、いくつかの目標を掲げてこのプログラムに参加しました。
電力データに対する要求を文書化する データの可視化によって支援される問題や課題を理解する アラートとデータが停電の解決にどのように役立つかを理解する
PagerDutyの威力
Nexleafは、PagerDutyと接続されたIoTセンサーを導入し、SMSとオンラインアプリケーションで病院職員に通知を送れるようにしました。これにより、職員は停電の根本原因を容易に把握できました。例えば、ある病院では、近隣の施設と電力を共有しているため、午前6時に停電が発生することがわかりました。この病院では、電力供給を予測可能にするために、電力使用時間を別の時間帯にずらしました。
PagerDutyプラットフォームのデータは、医療施設がディーゼルエンジン増強の必要性を説明し、予算超過の理由を正当化するのにも役立ちました。さらに良いことに、このデータは数カ月先の財務予測の精度を高めるのに役立ちました。
最も重要なのは、PagerDutyからのリアルタイム通知により、生物医学エンジニアが施設にいなくても停電の発生が検知できるようになったことです。アラート受信後、病院職員は迅速に行動し、施設に電力を再供給できます。これにより、手動でバックアップ電源を監視する必要がなくなり、患者の容体に大きな影響を及ぼす恐れのある停電を防ぐことができました。「PagerDutyのおかげで、停電による機器の不具合を原因とする死亡事故を未然に防げるようになりました」とMomanyi氏は述べています。
未来は明るい
パイロット運用の成功により、病院とその職員はさまざまな解決策を見出すことができました。病院の職員は、施設の電力管理に関する効果的かつ効率的な意思決定に役立つ電力データのユースケースを決定するために取り組みました。プログラムに参加した施設ではPagerDutyを使い続けており、Nexleafは新たな施設へとソリューションを拡大しつつあります。
Nexleaf Analyticsの歩みについては、Summit '22のセッションの全容をこちらでご覧ください。
PagerDutyのリアルタイムオペレーションがどのように非営利団体に力を与えるか、今すぐ14日間の無料トライアルをお試しください。
この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
Live Call Routingとは?
13年以上にわたってデジタル運用のビジネスに携わってきた私たちが学んだ本質的なことが1つあるとすれば、それは、全ての事業がレジリエンスを構築するために独自のアプローチを持ち、特注の技術スタックとプロセスで実現しているということです。
世界中の多くのPagerDutyのお客様が、Live Call Routing(LCR)を使ってオンコールチームへの直接アクセスを提供し始めています。簡単に言うと、LCRはPagerDutyのアドオン機能です。企業は電話やボイスメールをオンコール中のレスポンダーに動的にルーティングすることで、インシデント対応のためのカスタマーサポートを拡張できるようになります。
LCRは、顧客やスタッフがインシデントを迅速に報告できるようにする、オンコールチームへのホットラインとお考えください。LCRは、このプロセスを自動化し、オンコールチームが迅速かつ効果的にインシデントを受信して解決できるようにすることで、電話によるインシデント運用の複雑さを解消します。全ての着話はオンコールチームのスケジュールに基づいてルーティングされるため、誰でもすぐに適切なレスポンダーに連絡を取ったり、インシデントとなるボイスメールを残したりすることができます。
今日のLive Callに関するビジネス上の課題は何か
従業員がシステム障害について助けを求めている場合でも、顧客がシステム障害を報告している場合でも、人が報告したインシデントは、最初のレスポンダーがITチケットを作った時点で文書化されます。しかし、そのレスポンダーがその問題の専門家(SME)でない場合もあり、その時は適切な助けを得るために、ビジネス全体の複数のチームに問い合わせます。場合によっては、専門家が不在であったり、休暇中で代替要員がいなかったりします。レスポンダーが代わりの専門家に簡単に助けを求められるシステムがないため、解決策を見いだせずにインシデント対応が立ち往生してしまいます。
企業にとって真の課題は、平均受任時間(MTTA)と平均解決時間(MTTR)を短縮することです。従来のITチケットシステムは、インシデントを記録する手段ではありますが、解決までの時間を短縮する手段ではありません。
LCRのメリットにはどのようなものがあるか
LCRは、顧客に最高のサービスを提供することを保証します。例えば、顧客は直通電話でオンコールスタッフとリアルタイムに会話できます。オンコールスケジュールを調べずに済み、MTTAとMTTRを大幅に削減できます。さらに、LCRのおかげで、同じグローバルなオンコールスケジュールとエスカレーションルールを介してお客様の電話を転送し、適切なチームのレスポンダーが問題に対処できるようになります。
レスポンダーが通話中で、かかってきた要求に答えられないとします。この場合、顧客はボイスメールを残すことができ、LCRは自動的に次に対応可能なレスポンダーのためにインシデントを生成します。また、LCRは、PagerDutyを介して簡単に域内や国際電話番号を割り当てられます。世界中の顧客をサポートするためにオンコールチームを設定できるのです。
Live Call Routingの一般的な使用例
お客様インタビューに基づき、Live Call Routingの一般的なユースケースをいくつか挙げました。
重要なパートナーのための専用回線。** ある決済サービスでは、広い地域で80%の収益をあげている重要なパートナーがいます。このパートナーに「VIP」待遇を与え、Live Call Routingを有効にした専用電話番号を提供し、緊急事態の発生時にいつでもサポートチームに電話できるようにしたいと考えています。このパートナーは過去数年間、この番号に1度しか電話しませんでしたが、結果として地域全体のサービス停止や、数百万ドルの損失、数百万人の顧客からの信を失う事態を未然に防げました。 資産にホットライン番号をタグ付け。** カリフォルニア沿岸で、ボートからジェットスキーまで100種類以上の乗り物をレンタルしている事業者があります。各船舶には、レンタルする人が助けを求めるための固有のホットライン番号が設定されています。しかし、これでは、レンタル事業者とそのレスポンダーは多くのレンタル商品にわたって複数のホットライン番号を管理しなければならず、どの電話番号がどの船舶のものか、どのインシデントに対処すべきかをレスポンダーが見分けることが難しくなってしまいます。この企業は、全てのレンタル船舶に対応できる「1つのホットライン番号」でLive Call Routingを有効にし、電話をかけてきた人がリストからサービスを選べるようにしました。インシデントは適切に識別され、適切な専門家に転送されるため、短時間でインシデントに対応できるようになりました。 社内チームへの直通電話。** あるテクノロジー企業には1000人以上の従業員が在籍し、世界中にさまざまな顧客サービスを提供する複数のチームが存在します。あるサービスがダウンした場合、担当チームとそのスケジュールを追跡できません。情報がチーム間で共有されておらず、アクセスもできないためです。Live Call Routingは、複数のサービスの全てのインシデントに対応できる直通電話を設定し、担当の適切なチームに直接電話をつなぐことができます。各チームはインシデントを迅速に解決し、業務を効率化することで、世界中でより良い顧客サービスを提供することができます。
なぜPagerDutyのLive Call Routingか
PagerDutyのLive Call Routingは、インシデントを適切な専門家につなげ、人が介在するインシデントを管理する方法を変革します。コールルーティング、連絡網、グローバル番号割り当てなどの柔軟な機能により、適切なスタッフを待機させるためのよくある管理の複雑さを全て排除し、対応時間を短縮します。
PagerDutyのLCRは24時間365日体制で、顧客から報告されたインシデントが直ちに適切な個人またはチームへ転送され、エスカレーションされることを確認します。最も重要なことは、インシデントの通知と対処を希望する通信手段によって行うことで、インシデントを管理することができるということです。人が呼んだインシデントがボイスメールに入ったとしても、それは自動的にインシデントとなります。
あなたの声をお聞かせください
私たちは常にお客様とお話しし、Live Call Routingを活用するためのお客様のアイデアや使用例について知りたいと考えています。私たちは、質問にお答えし、アイデアを交換し、Live Call Routingがあなたの組織に適しているかを検証できる「Office Hour」を設けました。Calendlyを使って30分の無料セッションに申し込んでください。
Live Call Routingのシニアプロダクトマネージャー、Ben Wiegelmannによる「Always Reach On-Call Responders Immediately with Live Call Routing」を見て、Live Call Routingとその機能についての詳細をご覧ください。一般的な使用例を紹介し、MTTAとMTTRを改善する主な機能を実演しています。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。