Category
インシデント＆アラート

PagerDutyは、ラウンドロビンスケジューリングを発表できることをうれしく思います。ラウンドロビンスケジューリングは、チームメンバー間でオンコールシフトの責任を公平に分配することを可能にします。自動的に異なるユーザーまたはエスカレーションレベルのオンコールスケジュールに新しいインシデントを割り当てることで、チームが可能な限り効率的にインシデントを解決することを保証します。また、複数のユーザーで作業負荷のバランスをとることで、燃え尽き症候群のリスクも軽減されます。

同一サービスで発生した複数のインシデントのシームレスな解決

あるサービスでインシデントが発生すると、１人のレスポンダーがアラートを受信し、トリアージを開始します。インシデントが１つだけであれば対処可能です。しかし、アラートの量が多いサービスでは、レスポンダーが複数のインシデントに対応するために複数の方向に引きずられるため、インシデント対応中に混乱が生じる可能性があります。あるサービスで、30分以内に対処しなければならない５つの異なるアラートが同時に発生したとします。１人のオンコールエンジニアがその全てに対応することはできません。そこで、ラウンドロビンスケジューリングが役に立ちます。

ラウンドロビンスケジューリングでは、新しいエスカレーションポリシーを作成するか、既存のエスカレーションポリシーを編集して、”Users are assigned via round robin on the escalation level”（エスカレーションレベルではユーザーはラウンドロビンで割り当てられる）というボックスをチェックすれば、ユーザーは簡単にローテーションを設定することができます。

上記の例のような場合、ラウンドロビンの各担当者は、５つのアラートのうち１つをトリアージするよう割り当てられることになります。これにより、インシデント対応が効率化され、ダウンタイムが短縮され、顧客体験が向上します。

ラウンドロビンスケジューリングなし	ラウンドロビンスケジューリングあり
全てのインシデントが１人の担当者に割り当てられ、残りのメンバーはスケジュールにないためアイドル状態	インシデントをチーム内で公平に割り当て、それぞれが分担する
１人のレスポンダーが複数のアラートを処理しようとするため、MTTAとMTTRが増加する	各レスポンダーがアラートに最大の注意を払うことができるため、MTTAとMTTRが減少する
レスポンダーに余裕がなくなると、エスカレーションを余儀なくされる	入ってきた問題にすぐに対応できる別のレスポンダーがいるため、エスカレーションの頻度が少ない

さらに、ローテーションの対象者を特定するのも簡単です。ユーザーがエスカレーションポリシーを表示すると、ラウンドロビンのローテーションで誰が次になるかが緑の矢印で示されるので、問題が発生したときに誰がアラートを受けるかがあらかじめ分かるのです。

燃え尽き症候群を減らすために、仕事を分散し、必要に応じてエスカレーションする

大量の依頼を受けるオンコールチームでは、燃え尽き症候群が常に念頭にあります。 一人のチームメイトが複数の問題を同時に処理し、他のチームメイトが待機していることもあります。このようなオンコールシフトは、注意力不足、応答速度の低下、認知能力の低下などを引き起こす可能性があります。たとえオンコールシフトが月に一度しか発生しないとしても、それは離職率を高めるのに十分な圧力となり得ます。

ラウンドロビンスケジューリングは、各新規インシデントが、マネージャーもユーザーも含めて順次割り当てられるようにし、チームが責任のバランスをより良くとれるようにします。これは、エスカレーションの上位レベルにいるディレクターなど、優先順位の高いインシデント中にステップインする必要があるかもしれない人も含めて、オンコールスケジュールにいる全ての人にとって公正かつ予測可能なローテーションを維持するのに役立ちます。

ラウンドロビンスケジューリングを使用する

あなたのチームでオンコールボリュームを管理し、インシデント対応を合理化し、公平に作業負荷を分散する方法をお探しですか。ラウンドロビンスケジューリングは、BusinessとDigital Operationsの全てのプランで利用できるようになりました。現在ご利用中のお客様で、この機能へのアクセスを解除するためのアップグレードをご希望の場合は、PagerDutyアカウントチームまでご連絡ください。まだご利用でない方は、この機能を14日間無料でお試しいただけます。

ラウンドロビンスケジューリングの詳細については、こちらのサポートドキュメントをご覧いただくか、こちらのYouTubeショートムービーをご覧ください。

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

誰もがミステリースリラーを好みます。もしかすると、全員とは言えないかもしれませんが…、ハリウッドは間違いなくそうでしょう。ホームズものであれ、ポアロものであれ、観客は凶悪犯罪の犯人を追い詰めるページをめくるようなプロットを楽しむのです。私も含めて多くの人が、物語の最後に謎が「解ける」ミステリー・スリラーを好みます。後に続くような展開は想像力をかきたてますが（クリス・ノーラン監督の『インセプション』のラストを覚えていますか？）、探偵小説に関しては、私自身は「誰がやったのか」というハッキリとした答えを知る方が好きです。

探偵小説が完結するためには、犯罪の証拠が非常に明確で、真犯人が明らかになり、うまくいけば裁判にかけられるような詳細が提供されることが理想的です。

技術的な運用と重要なサービスのアップタイム維持の世界では、ハリウッドの探偵小説に似た明確な対立が生じます。重要なアプリケーションのパフォーマンス低下や、最悪の場合、完全な停止すると、エンジニアは問題をできるだけ早く修正できるように、事件の（明白な）原因を見つけようと急ぎます。チームは、自由に使えるツールを使って、オーバーロードした計算リソース、ハングしたクエリー、最大化したキューを追跡して切り分け、問題を修正するために迅速な行動を起こします。

しかし、これは探偵小説の始まりに過ぎません。この種の探偵ミステリーは、目撃者が犯人を、たまたま悪い時に悪い場所にいた人物だ、と認識するものです。しかし、証拠が増えるにつれ、やがて「真犯人」は遠くから壮大な計画を操っている悪の黒幕であることが明らかになります。しかし、「探偵」エンジニアにとっては残念なことですが、根本的な原因を解決したところで、その根本的な原因を示す証拠を「知らずに」消してしまう可能性が高く、サービスの再起動やポッドの再展開によって貴重なフォレンジックの証拠を消してしまうことになりかねません。

タイミング悪く雨に降られ、最も有力な手掛かりとなるはずの指紋が洗い流されたことに気付いた主任警部が、身の毛もよだつような思いをしているのは想像に難くありません。

最近では、開発者と運用エンジニアは、できるだけ早くサービスを復旧させながら、インシデントのコードレベルの根本原因を特定するのに役立つ重要な証拠を失わないようにするという、綱引きのような作業に取り組んでいます。

でも、モニタリング・ツールはそのためにあるのではないでしょうか？答えは、「時々当てはまる」です。問題によっては、高度な観測ツールを使って、設定やコードレベルのエラーを追跡できます。しかし開発者は、監視ツールで取得できない、より詳細なデータを必要とする場合があります。ヒープ、スレッド、TCPダンプ、リソースを大量に消費するデータベースクエリー、スタックトレースなどのデータは、「真犯人」を特定するために使用されますが、ほとんどの場合、サービスの復旧には必要ありません。そして、このようなデータの収集には時間がかかります。インシデント発生時には、サービスの可用性を回復することが何よりも優先されることは周知の通りです。

残念ながら、コンテナ化されたアプリケーションとコンテナオーケストレーションの採用・普及は、主に2つの理由から、この綱引きのような闘いを激化させるだけです。

マイクロサービスアーキテクチャーでは、Pod の再展開など、安全に可用性を回復するための方法がより迅速に提供されます。 このような環境では、開発者や運用エンジニアがコンテナ・イメージの表面積を最小限に抑えたいため、利用できるデバッグ・ユーティリティが少なくなります。

このような対立する勢力への対応には、「瞬時のスピード」で行動し、エビデンスを取得・保存し、その後すぐにサービスを再開できるソリューションが必要です。

このようなソリューションは、PagerDutyのOperations Cloudで提供されています。問題を検出すると即座にトリガーされるランブックを活用することで、デバッグレベルの証拠を取得し、S3などの永続的ストレージサービスに送信し、既知の修正を使ってサービスを復元できます。PagerDutyのユーザーは、オンプレミス環境とクラウド環境の両方に対応した統合済みの大規模なライブラリと、増え続けるランブックのテンプレートにより、MTTRと技術的負債チケット解決のためのバグ再現にかかる時間の両方を削減し、一見大胆に見えるこの目標を達成できます。PagerDutyの既存ユーザーは、次のリンクからRunbook Automationのトライアルをリクエストできます。

https://www.pagerduty.com/contact-us/runbook-automation/

新規ユーザーはここからPagerDuty Incident Responseを開始することができます。

また、Automated Diagnostics Solution Guideでは、これらのランブックの例をいくつか紹介していますので、ぜひご覧ください。

今回は複数回に渡るブログシリーズの1回目です。次回のブログでは、Kubernetes Ephemeral Containersを活用してKubernetesで動作するアプリケーションから証拠を取得するためのテンプレートジョブをご紹介します。

探偵の仲間たちよ、好奇心旺盛であれ。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

インシデントは予測不可能ですが、ステークホルダーとの最新情報の共有方法は予測不可能である必要はありません。Status Update Notifications Templatesは、大規模なインシデント発生時の社内関係者とのコミュニケーションを効率化するために役立ちます。このたび、この機能に新たな機能が追加されました。この機能により、チームはコミュニケーションをカスタマイズできるだけでなく、影響やサービスエリアなどの条件を表す動的な変数挿入を使用して、再利用可能なテンプレートを作成し、標準化することができます。

Status Update Notificationsとは何ですか？

あなたは今、優先順位の高いインシデントの真っ只中にいます。問題を収束させようと努力しているのに、12人（または２人）のステークホルダーから最新情報を求められて集中できない。複数の社内コミュニケーションチャネルに自分の回答をコピー＆ペーストしていても、ダイレクトメッセージが飛び込んでくるのは止まらない。このような状況に心当たりはありませんか？PagerDutyでは、これを「executive swoop and poop」と呼んでいます。基本的に、レスポンダーは更新要求が殺到し、本来の仕事であるインシデントの解決に手が回らなくなってしまいます。

インシデント発生時には、ステークホルダーに常に情報を提供することが重要です。そうすることで、インシデントに一丸となって対応し、解決までの時間を短縮し、顧客の信頼を維持することができます。しかし、ステークホルダーは、コミュニケーションに一定の形式と、彼らにとって重要な文脈を含むことを期待します。このようなコミュニケーションの書式設定と作成は、アドホックに行われる場合、対応者の全神経を集中させる必要があるかもしれません。Status Update Notificationsにより、チームはコミュニケーションの期待値を標準化し、アップデートの共有にかかる手間を軽減することができます。

この機能にはリッチテキストエディタが含まれており、会社のロゴを追加するなど、会社のコミュニケーション標準に合わせてテキストをフォーマットすることができます。また、ドラッグアンドドロップ機能により、インシデントの詳細や必要な情報を簡単に入力することができます。

テンプレートは、私のチームにどう役立つのでしょうか？

事故発生時、対応者は自分が担当するシステムやサービスについて、多くのことを記憶しておかなければなりません。そのため、集中力と批判的思考が必要とされます。ステータスアップデートの通知は、関係者とコミュニケーションをとるための迅速な方法であり、対応者がアップデートを共有するために費やす時間とエネルギーを軽減します。しかし、同じようなインシデントが発生すると、同じ通知を頻繁に送信する必要がある場合もあります。あるいは、P3とP0のコミュニケーションに異なる情報を持たせたいのに、毎回ゼロから通知を作りたくない場合もあります。

これらを全部プレーブックに書いて、wikiに保存することも可能です。しかし、そういったWikiは見つけにくいし、更新もほとんどされません。レスポンダーが必要とするときに、必要な場所に用意されているわけではありません。そこで、私たちはテンプレートを開発しました。これにより、チームは影響度や事業分野などに応じて、再利用可能なコミュニケーションテンプレートをカスタマイズし、標準化できるようになりました。この機能はAPIでも利用できるため、チームはどんな状況でも、ニーズに合わせてステータスアップデートの通知テンプレートをカスタマイズして活用できます。

テンプレートを使えば、インシデントコミュニケーションも簡単です。

関係者がインシデントにサブスクライブしていることを確認します。 ステータス更新]をクリックし、テンプレートを選択します。 テンプレートを編集し（必要な場合）、プレビューします。 ステータス更新の通知を送信します。

今日から始めるにはどうしたらいいですか？

Status Update Notification Templateが、ビジネスとデジタルオペレーション部門のお客様向けに一般提供されるようになりました。Status Update Notification Templateを使うことで、チームはより良いコミュニケーションができ、"swoop and poops "を減らせます。また、再利用可能なテンプレート形式なので、どんなコミュニケーションもすぐに用意できます。

もっと詳しく知りたい方は、こちらのナレッジベース記事をお読みいただくか、デモをご覧ください。

ステータスアップデートの通知テンプレートを実際に見てみたい方は、14日間無料でPagerDutyをお試しください。

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

ハイブリッドワークやリモートワークは、もはや当たり前のものになっています。労働者のオフィス復帰をキャンペーンしている企業は抵抗勢力に直面しており、採用希望者が望む柔軟性のある仕事に従業員を奪われていることに気づく雇用主もいます。

柔軟なワークモデルは、緊張した労働市場において競争優位性を持つようになりました。アクセンチュアの最新レポート「Future of Work」によると高成長企業の63％が「どこでも生産性」のあるワークフォースモデルを採用しています。しかし、このような柔軟性は、ワーカーが成功するために必要なツールとアクセスを確保するという新たな課題をもたらします。

これは、一刻を争うインシデントレスポンスにおいても当てはまります。ダウンタイムを最小限に抑え、重要なデジタルサービスを利用できるようにするには、適切なレスポンダーと専門家をリアルタイムに通知し、動員して問題を迅速に解決する必要があります。

PagerDutyは2009年の設立以来、シームレスなモバイル体験に対するお客様のニーズを理解し、優先してきました。私たちのアプリは、レスポンダーに最新のインシデントを案内するプッシュ通知を送信することができます。彼らはすぐにそのインシデントを認識し、目の前の問題に取り組むことができますし、そのインシデントを他のレスポンダーに割り当てることもできます。これらは全て、彼らの２つの手の中で完結されます。そのため、当社のモバイルアプリケーションは、iOSとAndroidのアプリケーションストアで常にほぼ5つ星にランクされています。

私たちは、ユーザーがどこからでも作業や対応ができるように、モバイルアプリの機能向上と体験の強化に投資を続けています。この度、PagerDuty Mobile Home Screenのアップデートが一般公開されましたので、お知らせいたします。

モバイルホーム画面の刷新によるインシデントレスポンスの向上

新しいPagerDuty Mobile Home Screenでは 、「My Open Incidents」が前面に表示されるため、最近の上位インシデントと関連する詳細が簡単に確認できます。また、デジタルオペレーションをより広く認識したいレスポンダーは、オンコールシフトや影響を受けている技術サービスなど、インシデント以外の情報にも簡単にアクセスすることができます。

未解決のインシデントのリストが長く、優先順位がつけにくい場合、目の前のタスクを判断するのは難しいものです。「My Open Incidents」では、自分に割り当てられている最新のオープンインシデント3件がすぐに表示されます。さらに詳細が必要な場合は、インシデントのセルをタップして詳細ページに移動すると、最新のメモ、変更イベント、過去のインシデントなどの追加情報を確認できます。アクションを起こしたい場合は、アプリから承認と解決を行うことができます。

「View All Open Incidents」をタップすると、あなたの全インシデントのリストが表示されます。 インシデント画面は、以前に表示したタブを記憶しているので、素早くアクセスでき、ナビゲーションタップの回数を減らすことができます。

On-Call Shifts

レスポンダーは、次にいつオンコールになるかをすぐに確認したいことがよくあります。 "Oncall "セクションには、現在の上位3つのシフトが表示されますので、それに応じて計画を立てることができます。より多くの情報を得たい、もしくはアクションを起こしたい場合は、点線のボタンをクリックすると、あなたのスケジュール、エスカレーションポリシー、オーバーライド、およびオンコールシフトを表示することができます。

Recently Impacted Technical Service

オープンインシデント（発生中のインシデント）を調査しているときでも、オンコールスケジュールをチェックしているときでも、レスポンダーはしばしば環境で何が起こっているかをスキャンしたいと思うものです。「Recently Impacted Technical Service」をホーム画面に配置することで、レスポンダーは影響を受けたサービスをより詳細に確認することができます。セルをタップすると、サービスの進行状況の詳細、エスカレーションポリシー、変更イベントが表示されます。

これは、私たちが今年展開した一連の新しいモバイルアプリの機能拡張の最新版にすぎません。詳しくは、ナレッジベースの記事をご覧ください。

PagerDutyは初めてですか？

PagerDutyを使ったことがなく、チームで試してみたいという方は、14日間の無料トライアルに登録して、PagerDutyがウェブのUIとモバイルアプリを使って、優れたインシデント対応を管理するためにデジタルオペレーションをどう支援するかを学んでください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

新興企業であろうとFortune500社であろうと、コストの最適化、ツールの統合、効率化の努力は最優先事項です。インシデント対応プロセスで労力を省き、自動化を進めることは、解決までの時間を短縮するだけでなく、チームの効率化にも役立ちます。リソースが限られた世界では、開発者と対応者の時間と集中力を守ることが、総運用コストの削減とカスタマーエクスペリエンスの最適化に欠かせません。

今月初め、PagerDutyは、お客様がチームの効率と生産性を向上させるためのいくつかの製品の進化を発表しました。その中でも最も期待されているのが、インシデント対応を自動化するIncident Workflowsの導入です。この機能は、本日よりEarly Accessのお客様を対象に提供を開始します。

インシデント対応プロセスにおける全ての手動ステップを考えてみてください。複数のチームに影響を与える優先度の高いインシデントは、できるだけ早く問題を解決するために総力を挙げて取り組む必要があるため、混乱が生じる可能性があります。ただでさえストレスの多いプロセスに、毎回X,Y,Zを確実に実行することを念頭に置いていると、さらに大きな負担がかかってしまいます。このような繰り返しの多い手作業は、自動化するのに最適な候補となります。

自動化によってインシデント対応の労力を減らし、定型タスクを処理できれば、チームはより迅速に問題の特定と解決に集中できます。そして、インシデントを迅速に解決できればできるほど、新しい製品やサービスの構築に早く戻ることができるようになります。

Incident Workflowsは、インシデントの種類に応じて、必要なアクションを自動的に編成します。Response Playsからのアップグレードとして、カスタマイズ可能なインシデントワークフローをノーコード／ローコードビルダーで作成できるようになり、あらゆるユースケースに対して適切なインシデント対応をエスカレーション、動員、調整するためのマニュアル作業が軽減されるようになりました。レスポンダーの追加、関係者の登録、コンファレンスブリッジの起動など、一般的なインシデントアクションをシーケンス化し、IFTTTロジックを使用して自動的に組織化された対応をトリガーできます。

（訳注：原文ではここでインシデント発生時にSlack上にチャネルを作り必要なメンバーを参加させるといったワークフローを設定するショートデモ動画を紹介しています。次のリンクでそのショートデモを見られます。 PagerDuty Incident Workflowsの紹介　）

ここでは、Incident Workflowsを強力にする機能を詳しく見ていきましょう。

条件付きトリガー

インシデントの種類が異なれば、必要な改善手順も異なります。条件付きトリガーを使用すると、緊急度、優先度、ステータスの変更など、特定のインシデントフィールドの基準が満たされたときにワークフローを開始するロジックを作成し、これらのニーズに対応できます。例えば、インシデントがP3からP1にアップグレードされた場合、条件付きトリガーを設定して、重大インシデントに特化したワークフローを開始できます。また、自動化をさらに進めたいユーザーは、Event Orchestrationを使用して優先度を設定し、Incident Workflowsがその優先度の変更を主なインシデントのワークフローのトリガーとしてピックアップできるようにすることも可能です。

また、レスポンダーがインシデントの詳細ページから直接ワークフローを開始できるようにする手動トリガーも利用できます。手動トリガーを追加すると、Incident WorkflowsはPagerDutyウェブアプリ、モバイルアプリ、Slack、Microsoft Teams、またはAPIから直接トリガーできるようになります。

CollabOpsアクションの強化

ワークフローを設定することで、コラボレーションチャンネルを設定する時間を短縮しましょう。ワークフローアクションを使用して、Zoomコンファレンスブリッジを起動したり、全てのインシデントレスポンダーとインシデントの更新を含む、インシデントごとのSlackチャンネルを作成したりできます。MS Teams Meetingを作成するための同様の機能は、近日中に提供される予定です。前述のとおり、チームの要望に応じて、SlackやMS Teamsで手動トリガーを設定することも可能です。

容易なコミュニケーション

効果的なインシデント対応には、社内外のステークホルダーに対してタイムリーで透明性のあるコミュニケーションを行うことが不可欠です。私の同僚である Hannah Culver が説明したように、ビジネス側の対応計画を準備しておくことは、社内の部門横断的なチーム間の連携を強化し、また顧客対応チームが積極的なコミュニケーションを通じて顧客の信頼を維持するのに役立つのです。Incident Workflowsは、インシデントへのレスポンダーの追加、ステークホルダーの登録、ステータスの更新を自動化し、インシデントについて知る必要のある全員にリアルタイムで情報を提供することで、このパズルを簡単に解決できます。

統一プラットフォームでエンドツーエンドの自動化を実現

Incident Workflowsは、PagerDutyプラットフォームの他の自動化機能と組み合わせることで、チームがより迅速に解決し、収益への影響を最小限に抑えられるように構築されています。例えば、Event Orchestrationでは、優先順位を変更してIncident Workflowsを自動的にトリガーすると同時に、Automation Actionで自動診断を開始し、適切なレスポンダーが呼び出され、Incident Workflowsが起動したインシデント専用のSlackチャンネルに達するまでに、スクリプトが既に実行されているようにできます。

結論

Incident Response中、レスポンダーは中核となる責任であるインシデントの解決に専念する必要があります。Incident Workflowsは、標準化された反復可能な方法で、その他の不可欠でありながらも退屈なタスクを自動化できます。インシデント対応プロセスを標準化することで、チーム間で適切なアクションを取ることができ、インシデント解決の時間を短縮できます。Incident Workflowsは、Business and Digital Operationsプランに含まれているため、この素晴らしい新機能を追加費用なしで利用できます。エンドツーエンドのインシデント対応を１カ所で実現できるのですから、技術を寄せ集める必要はもうありません。ツールの統合について質問している経営陣は、きっとこの機能を高く評価することでしょう。

これは、お客様が独自のユースケースに対応できるような拡張性を提供するためのPagerDutyの旅の第一歩にすぎません。Incident Workflowsの詳細については、Knowledge baseの記事をご覧ください。また、Early Accessへのサインアップをお勧めします。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

こんにちは！私はリチャード・チャオ、PagerDutyのプラットフォームチームのソフトウェアエンジニアリング部門でインターンをしています。私はワーテルロー大学でコンピューター工学を学ぶ2年生でもあります。この記事では、2018年のMarch Hackdayプロジェクトを紹介します。最小限のコーディング知識でTwitterトレンドのアラート・システムを40分以内で作成できるガイドです。

PagerDutyを活用してTwitterで自分のブランドを監視するシステムを作る―しかも40分以内で

ソーシャルメディアの時代、ブランドの評判の管理より複雑なことはありません。公開企業の66.7％がTwitterでメンションする中、あなたは適切なタイミング、例えば顧客が最もよく見ている時間に興味深く影響力のあるコンテンツを宣伝したいとします。それと同時に、主要なPR活動を監視して迅速にチームを動員できるように準備させておき、ブランドが顧客と収益を失わないようにしたいとします。そのために必要とされるものは競争力です。それは、チャンスなのかトラブルなのかに関係なく、ソーシャルメディアで何かが起こったらすぐにそのトレンドのトップに立つことを意味します。

導入事例

今日は、ほとんどの人はToronto Raptors（訳注：カナダ・オンタリオ州トロントに本拠を置く全米プロバスケットボール協会所属のチーム）について話しているようです。おそらく、これはぼくらのジャージの5割引セールを宣伝するのにベストなタイミングでしょう。

PagerDutyソリューション

ほとんどの企業はPagerDutyを使い、顧客に影響を与える不具合の管理や、適切な対応者へのアラート送信、インシデントが従業員と顧客満足度に及ぼす影響の分析などを行っています。

しかし、PagerDutyをTwitterのトレンド・アラート・システムとして活用できることも知っているのでしょうか？

PagerDutyの良いところは、ニーズに合わせて簡単に拡張できることです。このガイドの最後まで行けば、Twitterのキーワード、メンション、リツイートをリアルタイムで追跡し、ソーシャルメディアの活動が急増したときにeメール、SMS、または電話で即座にアラートする自動化されたアプリケーションができ上がっています。一番おいしい点は、これにかかる時間は40分以下で、コーディングに関する知識もほとんど必要ないことです。では、早速作業に入りましょう。

ステップ… 別名 “Engineering Stuff”

ステップ1：Twitterアプリケーションを設定します。

新しいTwitterアカウントの作成 このプロジェクトにはあなたの会社のTwitterアカウントを使用する必要はないので 、セキュリティとテストのため新しいTwitterアカウントを作成することをお勧めします。 Twitter APIキーの取得 メールを確認してください。 Twitter APIを使用するには、Twitterがアプリケーションをあなたのアカウントに関連付けるためのトークンが必要です。https://apps.twitter.com/にアクセスして新しいアプリを作成します。 Keys and Access Tokensタブの下で、トークンを生成します。後でキーをコピーできるように、このタブを開いたままにしておきます。

あなたのTwitterアカウントを開発用に設定する必要があります。

ステップ2：プロジェクトコードをダウンロードします。

PagerDutyはGitHubを使用してコードリポジトリの管理をします。

プロジェクトコードをダウンロードするため、Gitがインストールされていることを確認してください。 https://github.com/pagerduty/twitter-trend-alert-system にアクセスしてください。ターミナル/CMDで、”git clone https://github.com/pagerduty/twitter-trend-alert-system ”を実行してプロジェクトコードをダウンロードします。 このプロジェクトはPython 2.7.14を使用しています。インストールしていない場合は、https://www.python.org/downloads/にアクセスしてください。 “pip -version”と入力してインストールを確認してください。

プロジェクトを設定するには、READMEに記載されている指示に従ってください。この時点ではDatadog APIキーが欠落しているはずです。

ヒント: このガイドでは、ローカルコンピュータでプロジェクトを実行します。これを無期限に実行したい場合は、小さなサーバーで実行することをお勧めします。

この作業が完了する前に、Twitterに投稿されたすべてのステータスをフィルタリングし、リストされたキーワードを含むステータスのみを返すプロセスがあります。

ステップ3：PagerDutyを設定します

あなたの会社が現在PagerDutyを使用していない場合は、https://signup.pagerduty.com/accounts/newにアクセスして無料の14日間の試用アカウントを作成する必要があります。

オンボーディングページはスキップできますが、通知を設定していることを確認してください：

サービスを設定するまであと少しです。

まず、エスカレーションポリシー（EP）を設定します。通常、EPは状況を適切な人にエスカレートさせ、誰かがインシデントに対応できるようにします。ここで詳しい情報を見つけることができます：https://support.pagerduty.com/docs/quick-start-guide#section-create-an-escalation-policy ホームページから、Configuration → Escalation Policies → New Escalation Policy へ移動します。 EPの名前を作成します。

次にサービスを設定します。サービスは関連情報を裏付けるために設計されています。詳細については、https://support.pagerduty.com/docs/quick-start-guide#section-create-a-serviceをご覧ください。 Configuration → Services → Add New Service の順に選択します。 きちんとした名前をつけてください。 DatadogをIntegration Typeの欄に表示させてください。 How should responders be notified（レスポンダーにどのように通知するか）というフィールドは、状況によって異なります。あなたが話題のトレンドをモニターしたいならば緊急性の低いサービスをお勧めします。一方、重大な顧客サポートに関わるインシデントを監視したい場合は、緊急性の高いサービスをお勧めします。低緊急度サービスと高緊急度サービスの違いの詳細については、https://support.pagerduty.com/docs/service-settings#section-use-case-1-critical-and-non-critical-incidentsを参照してください。

ヒント: なぜDatadog？

PagerDutyには連携する200以上のインテグレーションがあり、そのうちの1つがDatadogです。あなたのチームが他のツールを使用している場合でも、PagerDutyがそれとインテグレーションできる可能性は非常に高いです。また、インプルななREST APIを使用することもできます。

あるコンテンツがトレンドになっている時や、熱いソーシャルメディアの状況を管理する必要がある場合、適切な時に適切な人に通知するためのアラートサービスを提供しています。

ステップ4：Datadogホストを作成します。

https://app.datadoghq.com/signupで新しい試用アカウントを作成します。 指示に従って、MacまたはWindowsコンピュータにDatadog Agentを設定します。Macではターミナルでコードスニペットを実行します。Windowsではインストーラーをダウンロードして使用します。

https://app.datadoghq.com/account/settings#apiにアクセスし、APIキーをコピーします。そして設定ファイルに貼り付けます：

このクイックガイドに従って、PagerDutyのDatadogとのインテグレーションを行ってください。すでにサービスを設定しているので、次のような画面が表示されます。

アプリを実行します。アプリケーションの起動方法については、README.mdを参照してください。最初のツィートが追跡された後、この指標はDatadogに存在するはずです。 Monitors→New Monitors** の順に移動して、新しいメトリック・モニターを作成します。

メトリックに_tweet_countを選択します。 システムが動作することを確認するために、低いアラート閾値（例では5）を設定します。例えば、

分かりやすいメッセージをタイトルに追加し、説明に@pagerdutyがタグ付けされていることを確認してください。次の図を参照してください。

Saveをクリックすると、数分間であなたの電話にアラートが表示されます。 これで完全なTwitter Trend Alert Systemを持っていることになりました。

ステップ5：ブラッシュアップ

順調に機能できたので、これからはアラートを解決しましょう。

テスト設定からのアラートを避けるために、Datadogの閾値を上げましょう。Monitors→Manage Monitorsの順に移動します。メッセージタイトルのmonitorの上にマウスカーソルを置き、Editをクリックします。アラートの閾値を100,000などの大きな数値に変更します。

PagerDutyでは、通話やテキストメッセージに返信することでアラートを解決できます。あるいは、Webサイトからインシデントを解決することもできます。

次のステップ

あなたは今、完全に動作しているTwitter Trend Alert Systemを持っています。今こそ、ソーシャルメディアのトレンドを効果的に活用する時です。

PagerDutyがシステムの機能をどのように強化するかに興味がありますか？

弊社の製品を最大限に活用するための次のいいステップがあります：

エスカレーションポリシー ：特定の広報インシデントには経営幹部の決定が必要です。連絡を取る時間を短縮し、エスカレーションポリシーを設定して通知を受けるようにします。 ステークホルダーユーザー：あなたの社内に重大な広報インシデントが起こったことを通知されたい人がいますか？ 次は利害関係者のユーザーを設定することを検討してください。 操作コマンドコンソール (OCC)：大規模なインシデントの際にTwitterで顧客がどのように反応しているかを監視します。

本記事は米国PagerDuty社のサイトで公開されているブログをそのまま日本語に翻訳したものです。原文はこちらを参照してください。

インシデントのコストはどのように測定するか

テクノロジー業界の多くの人々は、インシデントのコストを、ダウンタイムや影響を受けた顧客や従業員の数といった観点のみから語ります。そして、表面的には正しい見方であることが多いのです。ニュースにもなりますし、顧客の評判と信頼はあらゆるビジネスの成功に欠かせないことは明らかです。

しかし、インシデントの直接的なコストとしてあまり認識されていないのが、インシデント発生時に関与する必要がある人数です。顧客に影響を与えるほど深刻なインシデントであろうとなかろうと、根本原因の調査、トラブルシューティング、インシデントの解決、チームの責任の放棄などに多くの人が関わります。

PagerDutyのデータによると、レスポンダーの時間の50％は、x環境、またはyサービスでの追加サポートのために誰を呼び出すのが最善かを判断する（そして実際に問題があるかどうかを見極める）ために費やされています。この統計によると、インシデントの寿命の50％は、実際の改善活動ではなく、インシデントの初期段階（診断とトリアージの段階）に費やされていることになります。

結論から言うと、インシデントごとにかかる工数と手動アクションの数は、急速に増加する可能性があります。

インシデント対応の自動化

インシデントの深刻度を診断し、何が（どのように）うまくいかなかったのかの構造を理解するなど、インシデントの初期の再発段階に自動化を適用することは、最終的なインシデントの是正を成功させるために非常に重要です。

自動化は人の観点からも重要です。インシデントが発生するたびに同じ作業を繰り返し、チームが疲弊しないようにする必要があります。診断データを第一レスポンダーが確実に利用できるようにすることは、事故対応のルーティング効率と全体的なワークフローに最も重要です。

先に進む前に、まず診断データの定義について説明します。診断データは、インシデントレスポンダーによって取得されるデータで、通常、監視ツールによって提供される情報よりも具体的です。たとえば、監視ツールは、CPUやメモリーが急増したときに警告を発しますが、インシデントレスポンダーは、CPUやメモリーを最も多く消費するプロセスを見ることで調査を行います。したがって、この場合、プロセス名またはID、およびそれらに関連するコンピューターの消費量が「診断データ」となります。

さて、Automated Diagnosticsの定義は分かりましたが、なぜ必要なのでしょうか。それは、Automated Diagnosticsを導入すると、インシデントの発生期間を短縮し、対応にかかる人数を減らすことで、インシデントのコストを削減できるからです。

MTTRの問題点

ここで「問題」という言葉は適さないかもしれませんが、最後まで読んでください。MTTRという指標は、粒度の細かい実用的な洞察を得るには広すぎるのです。MTTR（Mean Time to Repair）は、IT業界では何十年も前から保守性の指標として定番となっています。MTTRには多くの用途があり、一般的な回復速度を説明するのに適していますが、その欠点は一般的であるということです。そして今、レスポンダーの時間の50％は、追加サポートのために誰を呼び出すのが最善かを判断するために費やされていると安全に推測できるため、MTTT（トリアージまでの平均時間）やMTTI（調査までの平均時間）など、MTTRタイムライン内の他の指標にも目を向けるようになりました。

MTTI/MTTT**。ITインシデントを検出してから、組織がその原因や解決策の調査を開始するまでの平均時間。MTTD（平均検出時間）からMTTR（平均修復時間）開始までの時間を表す。_

PagerDutyでは、最初のレスポンダーが受任してからリゾルバーが受任するまでの時間として測定しています。この指標は、インシデント発生時に水面下で実際に何が起きているのかを知るのに役立ちます。自社のデータを観察した結果、MTTIはMTTRの中で最も時間を消費する要因の１つであると推測することができました。現代のビジネスでは、エンジニアが時間と注意を払う必要があるタスクは、ビジネスにとって高価なものなのです。 本当に 高価なものです。

Automated Diagnosticsの活用

ここで、MTTIとAutomated Diagnosticsに話を戻しましょう。MTTIは、レスポンダーが手動で診断データを取得し、xサービスとyインシデントに基づいてどのチームにエスカレーションするかを解読しなければならないという技術的タスクによって長引くだけではありません。解決に必要な専門知識によって、担当者とその制約も変わってきます。例えば、多くの場合、最初のレスポンダーは、データベースやネットワークの「視点」から問題を調査する方法を知りません。それは、彼らのスキル（データベースやネットワークのバックグラウンド）、アクセス、またはチーム的知識（例えば、特定のアプリコンポーネントがサードパーティーのサービスとの複雑なインテグレーションに依存していること）の不足が原因である可能性があります。

このような調査やデバッグの作業を自動化し、チームや担当者にこれらの作業を委ねることができれば、MTTI、ひいてはMTTRにプラスの連鎖効果をもたらすことができます。

なぜAutomated Diagnosticsにこだわる必要があるか

Automated Diagnosticsでできることは以下の通りです。

通常、手作業で収集される情報をファーストレスポンダーに提供するパスを設計することで、希少な専門家へのエスカレーションを削減 対応チームに専門知識を共有 ファイアウォールやVPCの背後にある安全な自動化の呼び出し 人の手を借りずにトラブルシューティングと解決を迅速化 新人エンジニアへの教育のスピードを向上させ、インシデント対応組織の全レベルで最適な効率性を確保

始めましょう

あなたは決断しました。今こそ道を切り開く時ですが、何から始めればいいのでしょうか。

マーケティングのスラングを使えば、「海を沸かそうとしてはいけない（訳注：無理な仕事を引き受けてはいけない）」ということです。複雑さもリスクも低いアクションをいくつか試してみてください。例えば、最もノイズの多いサービスを詳しく調べたり、さまざまな監視アプリケーションから簡単なデータを取得したり、ディスクの使用状況を調べたりすることができます。しかし、この機能を長期的に展開するための戦略を持つことが重要です。確かに、多数のソースからデータを取得し、それをインシデントに追加するスクリプトを書くことは可能です。しかし、それではスケーラブルであることとは程遠くなります。

診断データを取得するために、さまざまなインフラやツールについて考えることは重要です。異機種混在のダイナミックな環境と連動するための標準化されたアプローチが必要です。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

共著者：PagerDutyデータサイエンティストVI、Chris Bonnell氏

引き続き、IAG（Intelligent Alert Grouping）の活用・改善方法について、第３回目をお届けします。最初の投稿では、インテリジェントアラートグループ化機能を紹介しました（こちら）。２回目の投稿では、IAGがどのようにマージを使用してアラートをグループ化するのかを説明しました（こちら）。本日は、IAGのマッチングを向上させるためにアラートタイトルを使う方法について説明します。

アラートタイトルが表示される場所 - 再確認

アラートがプラットフォームでトリガーされると、eメール、テキスト、またはアプリ自体からのプッシュ通知など、いくつかの経路で通知が行われることがあります。どの経路であっても、表示される最小限の情報は、アラート番号、サービス、およびアラートタイトルです。これは、いくつかの注目すべき場所に表示されます。アラートの受信方法によっては、これらの一部または全部が見慣れたものかもしれません。緊急度レベル（例：高）は、連絡方法を決定するために使用されますが、目に見える形で表示されないことに注意してください（ただし、インシデントの詳細には表示されます）。

電話のプッシュ通知とテキスト通知

例えば、iPhoneのロック画面を見てみましょう（同じインシデントについてのテキストメッセージ通知や電話着信）。

これはブログ投稿のために全てのチャンネルにアラートをプッシュしています。ここでは、アラートのタイトル、番号、サービスが表示されていることが分かります。テキストメッセージも似たような感じです。

メール通知

これらは少し違っているように見えます。メールの件名にはあまり詳細が書かれていませんが、メッセージの本文にはアラートの詳細が記載されています。

なぜ、アラートタイトルの表示場所を見直すのですか？

私のような方なら、実際の状況やサービスに関するアラートタイトルや説明文を書いていたときは、人間の脳に最適化させていたのではないでしょうか。証拠は上にも表れています。このアラートタイトルはブログ記事のタイトルのようだし、文頭に「Title」という識別子を強引に含んで、それが表示される場所を強調しています。これは人間のためのもの。読者の皆さんが画像から情報を読み取る際に、私が特定の部分に注目してもらいたくて故意にやりました。

もし、人間以外のために設計するとしたら？例えば、機械学習に適した設計ならどうでしょう？機械学習について知っていることや学んだことを何でも取り込み、それらを活用しようとメッセージを歪め始めるでしょう。

私が皆さんにお伝えしたいのは、このことです。インテリジェントアラートグループの体験を向上させるために機械学習を取り入れる際にも、人間のことを念頭に置く必要があるということです。

アラートタイトルを活用する

人のためにアラートタイトルを構築するとき、忘れてはならないことがあります。

簡潔であること。ご覧の通り、プッシュ通知もテキスト通知も文字数制限が短いです。 OSやウェブブラウザーによって制限が異なります。例えば、Androidの場合、プッシュするタイトルの文字数制限は65文字で、さらに説明文の文字数制限は240文字です。iOSの場合は、タイトルと説明文を合わせて178文字となっています。

明確であること。タイトルが分かりにくくなったり、何も伝わらなかったりするほど簡潔であってはなりません。 タイトル欄を優先するあまり、他の欄をおろそかにしないこと。 ウェブインターフェイスと同様に、PagerDutyモバイルアプリでは、他のインシデント、そのサービス、その説明を含む完全なインシデント情報を利用することができます。最初に表示されるからといって、タイトルフィールドに情報を盛り込みすぎないでください。

これらの詳細については、インシデントレスポンス運用ガイドの「アラート発信の原則」のページをご覧ください。

機械学習では、以下のことに注意しましょう。

識別性と頻度を上手に利用する。 データモデルは（人間と同じようには）読むことができない。 データモデルは意図を推論することができない。

その理由は、機械が「自然言語処理」と呼ばれるものをどのように行っているかを理解するためです。自然言語処理とは、スペルチェックや文法チェッカーが「it's」と「its」を区別して著者に通知したり、オートコレクトがどの単語と活用、どの形式（活用、自然下降）を提案するかを知るためのものです。アラートタイトルに適用される自然言語処理では、タイトルを匿名化し（詳細は後述）、「文トークン化」と「単語トークン化」というプロセスでそれぞれ文と単語に分解し、単語を見出し語化（レンマ化）して、最終結果を頻度の決定と他のアラートとの相関性の検索に使用します。

匿名化から始めると、例えば特定のIPアドレスをxx.xx.xxに置き換えるように、そうでなければあまりにも一意な情報をその情報のパターンに置き換えることが目的です。このテキストは、一意な情報によって本来関連するはずのタイトルが関連しなくなることを防ぎます。関連する可能性のあるコンテキストが完全に削除されるわけではありません。レンマ化とは、活用語や屈折変化をレンマと呼ばれる基本形に単純化する工程のことです。再び例で説明します。{“dogs”, “dog’s”, “dogs’”, “dog”}は全て“dog”にレンマ化され、同様に{“is”, “are”, “be”, “were”}は”be”にレンマ化されます。つまり、“The dog's bones.”と“The dogs' bones.”のような文は、この段階でどちらも{“the”, “dog”, “bone”, “.”}にレンマ化されるのです。

この時点で、インテリジェントアラートグループモデルは、N-gram（N個の単語のグループ）とインシデント言語のパターンに関する知識の両方を使用して、アラートタイトルから情報を抽出し、意味のある相関関係を作成します。前回の記事で紹介した例をもう一度見てみましょう。

最初のパターン memory usage high (> N %) on server $NAME in region $REGION ２つ目のパターン memory usage on host is high (> N %)

既にN %と$NAMEで少し匿名化しましたが、これらのタイトルにあるものをトークン化する練習をしてみましょう。 トークン化、レンマ化された最初のパターン。 {“memory”, “use”, “high”, “(“, “>”, “N”, “%”, “)”, “on”, “server”, “$NAME”, “in”, “region”, “$REGION”} トークン化、レンマ化された第２パターン。 {“memory”, “use”, “on”, “host”, “be”, “high”, “(“, “>”, “N”, “%”, “)”}

パターンが意味することの影響を考えると、２番目のアラートでは、そこに置かれた値によって変化する唯一の用語はNです。もし閾値が現在のメモリー使用量ではなく、一貫したものであれば、Nは全く変化しないか、タイトルに表示される値が１つか２つしかない可能性があります。それに対して、最初のアラートのタイトルには、サーバー名とその地域の一意性がより強くなっています。つまり、用語は１つまたは全く変化しないのではなく、３つの変化する用語があるわけです。言語処理装置に関する限り、２番目のパターンのアラートは１番目のパターンよりも相関関係がある可能性がはるかに高いです。

これからの方向性

アラートのタイトルを作成する際には、人間と機械学習の両方を考慮することが重要です。人間はアラートやインシデントの詳細情報を利用して追加のコンテキストや情報を得ることができますが、インテリジェントアラートグループではタイトルフィールドのみを使用するため、機械学習の最適化を若干意識するとよいでしょう。自然言語処理の基本については、Towards Data Scienceブログの「Introduction to Natural Language Processing for Text」ブログ記事をご覧ください。一般的にアラートやインシデントに含めるべき情報についてのベストプラクティスは、当社のインシデントレスポンス運用ガイドをご覧ください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

共著者：PagerDutyデータサイエンティストVI、Chris Bonnell氏

EIアーキテクチャーシリーズの第４回目、「Intelligent Alert Grouping（インテリジェントアラートグルーピング）」についてご紹介します。前回は、インシデントのマージを使用してIntelligent Alert Grouping をトレーニングする方法（こちら）と、デフォルト マッチングを改善するためにアラートのタイトルを設定する方法について説明しました。今回は、サービスデザインがIntelligent Alert GroupingやPagerDutyアプリの使用感にどのような影響を与えるかについて説明します。

サービスについて

サービスを設計したり、再設計したりする前に、組織で機能するサービスの定義を持つことが重要です。この定義は、理解できるほどは具体的である必要がありますが、複数のチームがサービスとは何かを抽象的には同じように理解できるように広いものである必要があります。PagerDutyでは、次のような定義を使っています。

サービスとは、チームによって完全に所有される、価値を提供する機能の個別部分である。

担当チームは、サービスを構築し維持するチームであり、あらゆるインシデントに対応することも含まれるため、把握しておくことが重要です。サービスとオーナーシップについての概説は、サービスの定義に関する完全なサービスオーナーシップ運用ガイドを参照してください。

サービスやその所有者について考えるだけでなく、サービス名にも気を配る必要があります。Service Directoryに目を通すと、追加の制度的知識がなくても、それぞれのサービスが何であるか簡単に理解できるようになるはずです。簡単に言うと、「Payment Service」という名前のサービスがあったり、あらゆるトランザクションサービスがギリシャ神話の神々にちなんで名付けられているという社内文書を知っているか参照して、どのギリシャ神が支払いを処理するサービスに相当するかを調べるかの違いです。この点については、Full Service Ownership Ops Guideの「Naming Services」のセクションで詳しく説明しています。

PagerDutyアプリでは、サービスはビジネスサービスとは区別されます。ここまでは、全てサービスに関連する話です。また、ビジネスサービスとの混同を防ぐため、弊社のドキュメントでは技術サービスと表記している場合があります。ビジネスサービスは、技術サービスや他のビジネスサービスの集合体であり、通常、ビジネスロジックおよび／またはステークホルダーに従います。Intelligent Alert Groupingは技術サービスのみを利用し、ビジネスサービスは利用しないため、この記事でサービスと書いた場合、技術サービスのみを指します。

粒度

サービスをどう分けるか、そのバランスを考えてもすぐには分かりませんし、万能の解決策もありません。基本的には、粒度の高いものと低いもののバランスを取り、時には置き換えすることになります。例えば、PagerDutyのアプリケーションでは、１つの監視ツールで、その構成機能を全部別のサービスに分解しています。一方、より広範で粒度の低いサービスの使い方としては、iOSとAndroidの開発を別々のチームが担当している場合でも、あらゆるモバイルアプリケーションを１つのサービスとして提供することが挙げられます。後者の例では、サービスの構成方法について単一の推奨事項が存在しない理由は、組織にモバイルチームが１つしかないとか、モバイルチームがないとか、異なる基準で分割されたモバイルチームがあるためだとよく分かります。

では、どうすればよいのでしょうか。私たちは、サービス定義のナビゲートに役立ついくつかのアドバイスを抽き出せます。まず始めに、オーナーシップについて説明します。PagerDutyアプリケーションでサービスを定義する主な理由の１つは、インシデント対応のためです。つまり、サービスの問題に対処できるのは誰かを知ることは、サービスを所有しているのは誰かを知ることなので、組織内で誰がサービスを所有しているかによって、PagerDutyでサービスをどのように定義するかを決めることができます。これは、完全なサービスオーナーシップモデルではないものの、望ましいエスカレーションパスが分かっているサービス構造が既にある場合、その知識を活用できる点で重要です。この場合、Intelligent Alert Groupingがインシデントをグループ化すると、サービスが希望するエスカレーションパスに関連付けられるだけにしても、このコンテキストではそれが重要であり、達成する最終結果になるのです。

また、現在のプロジェクトを見直して、どれが事実上機能単位になっているかを確認し、それらをPagerDutyで１サービスとして定義する必要があります。こうすることで、エスカレーションパスが同じプロジェクトは正しくグループ化される一方で、エスカレーションパスの関係で複数のプロジェクトが単一のサービスとして定義され、可視性が損なわれるというシナリオを防ぐことができるはずです。もう少し踏み込んで、常にインシデントが同時に発生している２つ以上のサービスがある場合、それらを１つのサービスに集約する必要があるかもしれません。具体的な例として、メトリクス、ハートビート、ログなどの個別のコンポーネントを持つモニタリングマイクロサービスがあるとします。これらがそれぞれPagerDutyサービスを持っている場合、ほとんどの場合、インシデントがこれら全サービスに同時にまたがることになるので、モニタリングマイクロサービス自体として１つのサービスにまとめる必要があります。一方、同じ人が働いているからと言って、別々のプロジェクトが１つのサービスとして定義されている場合、そのサービスは十分に粒度が揃っていない可能性があります。このシナリオでは、PagerDutyアプリに関する限り、サービス内のエンティティーは全て１つの「もの」であるため、どのエンティティーが他のエンティティーよりも注意を払う必要があるかを判断するのが難しくなります。

次に何をするべきか

既存のサービス、あるいはこれから作成されるであろうサービスを見て、それらをチェックすることから始めましょう。

エスカレーションパス 名称 機能単位

そして、PagerDutyアプリケーションでサービスを定義する際の指針として使用します。Intelligent Alert Groupingは、関連するサービスの下にアラートをグループ化することで、そこからの作業を行います。サービスをゼロから設計したり、サービスの定義を見直したりする場合は、「フルサービス オーナーシップ運用ガイド」で、レスポンスの命名とオーナーシップに関するベストプラクティスを参照し、「（技術）サービス」と「ビジネスサービス」に関するドキュメントもご覧ください。次回は、このシリーズの最終回で、これまで取り上げた内容を全て再録する予定です。ei-architecture-seriesタグを使うと、このシリーズの記事をご覧いただけます。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

Co-authored by Chris Bonnell, PagerDuty Data Scientist VI

Intelligent Alert GroupingについてのEIアーキテクチャーシリーズの最終回へようこそ。このシリーズを楽しんでいただけたなら幸いです。もし私たちの過去の投稿を見たいなら、ei-architecture-seriesタグをお使いください。少し時間をとって、私たちが学んだことを全て振り返ってみましょう。

記事のポイント

Intelligent Alert Grouping（IAG）のデフォルトの動作は、インシデント管理における抽象化されたパターンに基づいており、また機械学習モデルも利用しています。つまり、このツールは、いわば経験則に基づいた推測を数多く行うことができますが、個々の環境では完全に一致するものを生成できない可能性があります。それを補うために、マージ、タイトル、サービスデザインなどを活用することで、グループ化の動作を改善することができます。

マージ動作

インシデントは、PagerDutyアプリケーションのマージと呼ばれるプロセスによってグループ化されます。一般に、どのインシデントも他のインシデントとマージすることができます。特にIAGでは、この投稿でレビューしたように、個々のアラートを新しいインシデントにマージすべきか分離すべきかを判断しようとするときに、Alert Titleフィールドを分析します。アラートが不適切に共通のインシデントにマージされた場合、それらを分離し、あるべき場所に移動させるための措置を講じることができます。機械学習モデルは、反復するたびに行動を強化するため、アラートが残るか、マージされるか、移動されるかによって、今後の行動が改善されます。

アラートタイトル

IAGはAlert Titleフィールドを基にマージ動作を行うため、以前の投稿で一般的な機械学習の原理を用いたアラートタイトルの基本を説明しました。ここでは、３つの重要なポイントがあります。

アラートのタイトルは、人間と機械学習の両方に役立つべきもので、機械学習寄りにするため、残りのインシデントの詳細は詳細に記述すべきです。 機械はコンテキストを理解できないので、コンピューターが「一意」「共通」を区別できるようにするのが重要であることを忘れないでください。 プッシュ通知で表示されるアラートタイトルの部分には字数制限があるため、人間向けのテキストはタイトルの後半ではなく、前半に配置するようにしましょう。

これらの実装方法を掘り下げるには、前述の記事の機械学習の部分と、Towards Data Scienceブログの「Introduction to Natural Language Processing for Text」のブログ記事をご覧ください。

サービスデザイン

最後に紹介した概念は、サービスデザインのことです。 一般的な考え方としては、同じサービス上の類似したアラートはデフォルトで、他のサービス上のアラートよりも相関性が高いと想定されます。サービス定義をどの程度細かくするかによって、PagerDutyアプリケーションで「サービス」をどのように実装するかが決まるため、ここではかなり多くのことを説明できました。一般的なルールとして、２つの「もの」が別々のサービスであるべきかどうか分からない場合は、望ましいエスカレーションの経路を模倣してください。もし両者が同じチームや人によって所有されているのであれば、PagerDutyアプリケーションで両者を１つのサービスとみなすことで、エスカレーションを尊重し続け、アラートの相関性をより高くするという利点も得られます。もし、異なるチームが担当している場合や、アラートの相関性を高めたくないという理由で論理的に区別している場合は、別々のサービスとして定義してください。所有するチームについては、一般的なサービス定義と所有権のベストプラクティスについて詳しく知りたい場合は、フルサービス所有権運用ガイドをご覧ください。

今後の方向性

ここまでです。Intelligent Alert Groupingをフル活用する方法について、時間を割いて学んでいただき、本当にありがとうございました。もしこれらの記事を長期的に参照したい場合は、ei-architecture-seriesタグをブックマークしてください。さらに議論を深めたい場合は、当社のコミュニティーフォーラムをご覧ください。より詳細なQ&Aについては、サポートチームにお問い合わせください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

今日、ほとんどのサポート組織は、何らかの形で従来の階層型サポートモデルを採用しています。これは、エスカレーションと顧客の引き継ぎのプロセスに基づいているものです。このモデルでは、顧客の問題は、サポート階層の複数のレベルを介してエスカレーションされ、３つの階層が一般的なワークフローとなります。

この典型的な３層構造のサポートシステムの例では、Tier 1は入ってくる顧客の問題を受ける最初の防御線であり、一般的なテクニカルサポートを提供します。Tier 1サポートで解決できない問題は、より深い技術的知識とサポートスキルを持つTier 2にエスカレーションされます。このレベルでも解決できない場合は、対象となるアプリケーションの専門家であるTier 3のスペシャリストにエスカレーションされます。

このモデルは、それほど深刻でなく繰り返し発生する問題には有効ですが、今日の常時接続のデジタル世界において、優先度が高く重要なインシデントに対処する場合には、全く適していません。おそらく、今日のカスタマーサービス組織で広く見られるこの従来のサポートモデルの考え方を疑うべき時が来ているのでしょう。

このモデルは、エスカレーションと顧客の引き継ぎのプロセスに基づいているため、以下のようないくつかの欠点があることは驚くことではありません。

解決までの時間、First Reply Timeが長い。** 全チケットが同じトリアージのキューに従うため、最終的に適切な担当者にたどり着くまでは、その問題に対処する能力がないエージェントのもとで時間を浪費することになります。このモデルでは、適切な専門家にたどり着くまでに障壁があり、問題についての重要な文脈や情報が途中で失われることが多く、不必要な遅延が発生します。 長いバックログ項目。** Tier 1レベルで解決できないお客様の問題は、他のサポート層への待ち行列に入ります。このケースは、リアルタイムでアクティブに作業されている状態から、バックログのアイテムになるのです アカウンタビリティーの低下。** 階層化モデルは、エスカレーションと顧客対応のプロセスに基づいています。最前線のスタッフが問題を専門家にエスカレーションすることを求められると、アカウンタビリティーが低下し、インシデントからエンドツーエンドで学ぶ機会も減少します。 顧客にネガティブな体験をさせる。** 複数のサポート担当者に問いを繰り返さなければならなかった経験のある人なら誰でも、このことが顧客満足度にマイナスの影響を与えると理解してるはずです。

これは、サポート組織は階層型サポートモデルを廃止すべきである、と言っているのではありません。階層型サポートは、それほど深刻でない問題や単発の質問に対応するには非常に効果的です。しかし、重要で緊急性の高いインシデントになると、階層型モデル特有の非効率性が、最終的に顧客離れにつながる負の顧客体験をもたらす可能性があります。

IIntelligent Swarming℠は、オーソドックスな階層型サポートに代わるフレームワークを提供します。このフレームワークでは、キュー内の作業よりもリアルタイムの作業、サイロ内の作業よりもコラボレーション、一方的なエスカレーションよりもケースのオーナーシップを優先します。

インテリジェントスウォーミングモデルでは、チケットを受け取ったカスタマーサービス担当者が、その案件を最後まで担当します。サポートに階層はなく、お客様の引き継ぎもありません。チケットの所有者であるエージェントが解決できない場合、そのエージェントは即座に問題の「スウォーム」化を行う専門家チームを引き込みます。このような的を絞ったアプローチはインテリジェントスウォーミングと呼ばれ、適切な人が適切なタイミングで動員され、協調した対応を行います。これは、多くの人が対応策に参加しても、必ずしも問題解決に適した専門家であるとは限らないという、インシデントに対する協調性のないスウォーミングとは対照的なものです。インテリジェントスウォーミングのフレームワークでは、ケースオーナーが専門家チームと情報を共有し、解決に向けて協力し合います。

このモデルには、いくつかの利点があります。

この理論を実践するためには、カスタマーサービス担当者が適切な情報にアクセスし、専門家と協働できるようにする必要があります。つまり、組織全体からリアルタイムのサービス障害データを提供してもらうことです。また、運用チームとの双方向のコミュニケーションを可能にする双方向通信チャネルを確立することも必要です。また、機械学習機能を使って、顧客に影響を与える前にインシデントを特定することも可能です。

PagerDutyでは、サポートエージェントがインシデントの履歴コンテキストを可視化し、テクニカルリソースからの監視データを提供することで、問題の全体像を把握し、正しい解決策を特定できます。エージェントがチケットで助けを必要とする時は、PagerDutyの一連の機能を使って迅速に追加支援を引き出すことで、スウォーミングモデルをさまざまな方法で実現できます。

エージェントは、インシデントにレスポンダーを追加することで（「Add responders」という分かりやすい名前の機能があります）、PagerDutyで迅速にスウォームリクエストを始められます。これにより、組織全体から必要な専門家が直ちにループに入れられ、コラボレーションのための会議ブリッジを設定するオプションも用意されています。追加されたレスポンダーは、緊急性の高い通知ルールで通知され、重要な問題を見逃すことがないようにします。

PagerDutyのエージェントは、レスポンスプレイ（ボタンをクリックするだけでインシデントに対して実行できる定義済みアクションのセット）を利用して、スウォームの開始に関連する定番のワークフローを自動化することもできます。これらの定義済みアクションには、対応者の追加、カンファレンスブリッジの設定、関係者のインシデントへのサブスクライブ、ステータスアップデートの公開などが含まれます。レスポンスプレイは、特定のサービスに結びついたインシデントに対して自動的に実行されたり、PagerDutyを使っている誰もが手動で開始したりでき、実行されるアクションが問題の規模に適していることを確認できます。

最後に、PagerDutyはZendeskなどのチケットツールやSlackなどのChatOpsツールとネイティブに統合されているため、エンジニアリングチームと簡単に双方向のコミュニケーションが可能です。また、エージェントが使っているツールからPagerDutyのインシデントをトリガーできるため、コンテキストスイッチの必要がなく、適切なチームや専門家にすぐに接続して問題を解決できます。PagerDutyをオールインワンの対応オーケストレーションおよびコラボレーションツールとして使用することで、チームは簡単に問題をスウォーミングし、顧客とエージェントの両方にとってよりシンプルで合理的なエクスペリエンスを実現できます。

スウォーミングや階層型プラクティスを使用するかどうかにかかわらず、今日、あらゆる顧客問題をサポートするためのよく知られたアプローチが存在します。適切なスウォーミングの手法を事前に構築しておけば、適切なタイミングで適切な専門知識を自動的に活用できます。また、即時対応が必要でない重要度の低い問題については、階層化されたアプローチを自動化（自動エスカレーションポリシーやオンコール通知など）することです。

デジタルイノベーションとユーザーエクスペリエンスによって定義されるようになるパンデミック後の世界では、カスタマーサービス機能を強化する新しい方法を検討する時期が来ています。

Intelligent Swarming℠は、サービスイノベーションコンソーシアム™のサービスマークです。

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

DevOpsでは、オンコールプロセスについてよく話しますが、オンコール中の人間的な側面についてはどうでしょうか？例えば、シフト中のストレスや不安に対処する効果的な方法は何でしょうか？オンコール当番中に子供の世話をしなければならないなど、オンコールに専念しづらい生活状況とどのように両立すればよいでしょうか？また、共感的なチームカルチャーは、燃え尽き症候群や離職を防ぐのにどのように役立つのでしょうか？ 2021年11月から12月にかけて、PagerDutyの９つのチームのオンコールエンジニアが集まり、オンコールの人間的側面についてディスカッションしました。ここでは、そのセッションで得られた５つの重要なポイントを紹介します。

チーム内の共感が重要である 一日中グラフを眺めていてはいけない ポストモーテムはストレスになり、多くの労力を要する 緊急性の低いアラートは、夜間のノイズを減らす １週間のオンコールは燃え尽き症候群につながる可能性がある

それぞれの重要なポイントに入る前に、私たちが話を聞いたチームに関連するいくつかの指標を見てみましょう。