Blog
ブログ

2022年8月23日  (更新日:2022年11月8日)

組織が大規模なサービスをうまく構成するのに役立つ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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。

続きを読む
インシデント&アラート
2022年8月15日  (更新日:2022年11月8日)

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

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

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

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

PagerDuty

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

モデルドリフト

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

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

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

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

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

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

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

データドリフトテスト

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

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

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

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

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

PagerDutyとモデルドリフトの例

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

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

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

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

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

5つの簡単なステップで根本を探る(原因分析)

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

  1. Outlier Incident

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

  1. Past Incidents

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

  1. Related Incidents

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

  1. Probable Origins

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

  1. 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
2022年8月9日  (更新日:2022年11月8日)

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

続きを読む
DevOps
2022年10月26日  (更新日:2022年10月31日)

PagerDutyとDataOps:より良いデータで組織の意思決定を改善することを可能にします。

はじめに

多くの企業で業務のデジタル化が進んでおり、その大半はクラウドに移行しています。 この変革に伴い、データチームはこれまで以上に大規模で複雑なデータセットを分析し、下流のチームが日常的により迅速かつ正確な意思決定を行えるようにしなければならなくなりました。その結果、ほとんどの組織では、顧客データ、製品データ、利用データ、広告データ、財務データなどを扱う必要があります。これらのデータセットは、構造化されているものもあれば、半構造化されているものもあり、また非構造化されているものもあります。要するに、様々なタイプのデータが、複数のソースから無限に、しかも高速に到着しているのだ。

このようなビッグデータの量、速度、多様性(一般に3Vと呼ばれる)の増大により、データライフサイクルの管理に対する従来のアプローチでは不十分となり始めたのです。同時に、2000年代前半の終わりごろから、ソフトウェア開発チームは、ソフトウェア開発ライフサイクルにアジャイル手法を採用しはじめました。これらの方法論は、DevOps(DevelopmentとOperationsの合成語)として知られるようになりました。 次の図は、DevOpsのプロセスを高いレベルで示しています。

デブオプスプロセス

一方、データの専門家は、隣のソフトウェア開発の同僚を見習い、DevOpsの方法論と概念を自分たちの複雑なデータ環境に適用し始めました。 これが、DataOpsのアプローチをもたらしたのです。

では、DataOpsとは何でしょうか?

DataOpsは、ソフトウェアおよびデータエンジニアリング、品質保証、インフラストラクチャの運用を単一の軽快な組織に統合するプラクティスです。DataOpsは、組織がデータアプリケーションを開発・展開する方法を最適化します。プロセスの進化、組織の連携、複数のテクノロジーを活用し、データの作成、移動、変換、消費に関わるすべての人(開発者、データエンジニア、データサイエンティスト、アナリスト、ビジネスユーザー)が関係を構築できるようにします。DataOpsは、コラボレーションを促進し、サイロを取り除き、より良いビジネス上の意思決定を行うために組織全体でデータを使用する能力をチームに提供します。全体として、DataOpsは、チームがデータを収集して準備し、分析し、完全なデータセットからより迅速かつ正確な意思決定を行えるようにします。また、DataOpsは、データの品質を監視することで、データのダウンタイムや障害を低減します。

DataOpsは、組織のデータ環境に共通するさまざまな課題に対応します。その中には、以下のようなものがあります。

サイロを取り払い、チーム間のコラボレーションを促進する。 データエンジニア、サイエンティスト、アナリストが協力しなければならない。 文化的な大転換が必要です。企業は、社員がデータドリブンのアイデアで迅速に反復することを認める必要があります。 効率性と俊敏性の向上 - チーム間のコミュニケーションとコラボレーションを強化し、自動化を利用することで、バグや不具合への対応を劇的に減らすことができます。 データの品質を向上させる。 DataOpsは、データ専門家がデータを自動的にフォーマットする機能を提供し、複数のデータソースを使用して、チームがデータを分析し、より良い意思決定を行うのを支援します。 データチームがデータ品質を監視しているため、データのダウンタイムや障害が発生しない。

データ観測可能性とは?

「データ観測性」は、複数のツールやデータライフサイクル全体にわたって、組織のデータの健全性を監視・管理するためのツールや手法を提供します。データ観測性によって、組織は、問題がビジネスユーザーに影響を与える前に、リアルタイムで積極的に問題を修正することができます。

Data ObservabilityとDataOpsの関係とは?

データ観測可能性は、DataOpsを可能にするフレームワークです。 DataOpsチームは、アジャイルアプローチを使用して、エンタープライズデータからビジネス価値を引き出します。しかし、誤ったデータや不正確なデータに問題があると、特に問題(別名:データダウンタイム)がビジネスに影響を与える前に検出されない場合、深刻な問題が発生する可能性があります。幸いなことに、AIを活用したデータ観測機能により、組織はデータダウンタイムを検出、解決、防止することができます。

Data Observabilityツールは、データに関するものである。鮮度、統計的分布、ボリューム、スキーマ、そして系統。 データ観測ツールの正しい使用は、より質の高いデータ、信頼性の向上、そして運用面でより成熟した環境をもたらす。

DataOpsのステークホルダーは誰ですか?

確かに、組織内のすべての部門間の関係を構築する強力な中央データチームを構築することは、データ運用の成熟度を達成するための重要な要因です。データチームは通常、最も関連性の高いデータセットを公開し、意思決定、分析、およびデータモデルが単一の真実の源から行われるようにします。一方、データアナリストやビジネス部門のユーザーは、質問をしたりデータから答えを引き出したりして、これらのデータセットを利用します。注意深く意図的に役割と責任を定義することは、組織が矛盾、重複、非効率を避けるのに役立ちます。

データオプス ペルソナ

ここでは、データのライフサイクルに関わる最も一般的なプロフィール(別名:ペルソナ)を紹介します。

データエンジニア。** データエンジニアは、データを収集し、パイプラインを構築してソースシステムからデータストアに取り込み、アナリストやデータサイエンティストがデータにアクセスできるようにする役割を担っています。データのクレンジングと変換を行い、コアデータセットを公開します。クリーンで精選され、必要な人がアクセスできるデータをタイムリーに提供するのが、ERPの役割です。最も伝統的なデータ環境では、ETL(Extraction, Transformation, and Loading)の頭文字をとってETLと呼ばれます。 データサイエンティスト。** 統計学の知識を応用し、予測・処方モデルを構築します。統計学以外にも、データマイニング、機械学習、深層学習などの専門家であることが多い。例えば、金融業界では、数学に強いことから、伝統的に「クオンツ」と呼ばれています。 データアナリスト/ビジネスアナリスト。* データの専門家で、通常、事業部門または機能部門(販売、マーケティングなど)に所属しています。 組織の運営方法、戦略目標、データが必要な場所や方法などに精通している。* ビジネス上の質問をデータクエリに変換します。 エグゼクティブが目標を達成するために必要な情報や主要な指標を深く理解しています。フロントエンドBI(ビジネスインテリジェンス)ツールのエキスパートです。 データプラットフォーム管理者。** インフラが正常に動作し、十分な容量があり、インフラに依存しているすべての部門に高品質のサービスを提供できるように管理する。トランザクション・データベース、データウェアハウス、データレイク、BIツールなどを担当する。さらに、アクセスポリシーの策定、インフラストラクチャの管理、ライセンスコストの管理も行います。 Line of Business データ消費者。** データの最終的な利用者であり、通常、意思決定のためにデータを使用する。BIツールに依存し、データの内容に基づいて行動を起こす責任がある。例えば、営業リーダーは、営業活動に基づいて、特定の地域にもっと投資することを決定するかもしれない。マーケティング・マネジャーは、ROI指標に基づいて、特定のタイプのキャンペーンにキャンペーン資金を割り当てることを決定するかもしれない。 チーフ・データ・オフィサー。** データチーム全体の運営を監督する。通常、CEO、CTO、場合によってはCIOにレポートする。

PagerDutyのDataOpsプロセスにおけるステークホルダーたち

上の図は、PagerDutyのDataOpsプロセスにおいて、ステークホルダーを従来の責任範囲に配置したものです。 間違いなく、組織によって重なる部分は様々でしょう。

PagerDutyのDataOps

PagerDutyでは、PagerDutyと数少ないテクノロジーパートナーを活用したDataOpsの実践を行いました。PagerDutyとDataOpsの原則を適用することで、私たちは以下のことを実現しました。

複数のデータウェアハウスから単一のデータウェアハウスに移行し、MuleSoft、Segment、Fivetran、Kafka、Sparkパイプラインからのデータセットを単一のソースオブトゥルースに統合することができます。 自動化とデータテクノロジーのパートナーシップを活用することで、複数のデータワークロードから得られるデータのSLAを満たすことができます。 Observability を活用して、ユーザーが知る前にデータを検出し、解決し、インシデントを予防することができます。 データチームのフォーカスを、管理業務からデータ駆動型の洞察とデータサイエンスにシフトする。 データ利用事例の急増に対応するため、データ環境の将来性を高める。 BIから新しい人工知能(AI)アプリケーションまで、複数の部署に所属する400人以上の社内ユーザーと数千人の顧客からの要求に対応するためです。

PagerDutyにおけるDataOpsの環境

上の図は、私たちのDataOps環境を構成する主要なコンポーネントのいくつかを描いたものです。 各組織のデータニーズやデータ環境はそれぞれ異なりますが、私たちの問題やアーキテクチャがそれほどユニークでないことはお分かりいただけるでしょう(複数のデータウェアハウス、複数のETLツール、厳しいSLA、データセットに対する膨大な要求)。おそらく皆さんは、すでにご自身のデータ環境とアーキテクチャの類似点や、共有されている高レベルの問題をいくつか発見していることでしょう。

PagerDutyはDataOps環境でも活用できます。

PagerDutyデジタルオペレーションプラットフォームは、データの問題が発生するとすぐにデータチームと下流のデータユーザーや消費者に警告を発し、データのダウンタイムを防ぎます。現在公開されている6つのDataOpsまたはデータ関連の統合をエコシステム内で発表できることを嬉しく思います。これらのテクノロジーパートナーは、組織全体におけるデータパイプラインとデータ品質の問題を解決します。 コラボレーションを改善し、摩擦を減らし、アライメントを改善することでデータの失敗を減らします。

  • Monte Carlo: エンド・トゥ・エンドのデータ観測性を提供し、データのダウンタイムを事前に解決します。 Lightup : 企業がクラウドスケールで優れたデータ品質を達成できるよう支援します。 アリゼ : 機械学習(ML)モデルの問題を監視し、トラブルシューティングし、解決するための観測可能なプラットフォームです。 WhyLabs: データおよびモデルの監視を提供することで、コストのかかるAIの失敗を防止します。 Prefect: リアルタイムアラートによるデータパイプラインの構築と監視 アストロノマー パイプラインのリアルタイムデータ監視により、データのダウンタイムを削減します。

PagerDuty DataOpsエコシステム

最も重要なことは、これらの新しいDataOpsとPagerDutyの統合は、データパイプラインオーケストレーション、テストとプロダクション品質、デプロイの自動化、データサイエンス/ MLモデル管理などの主要な領域をカバーしているということです。 PagerDutyとこれらのPagerDutyエコシステムテクノロジーパートナーを組み合わせることで、部門横断的なチーム間の緊密なコラボレーションを促進し、より少ないデータダウンタイムでより良い、より迅速な意思決定を達成することができますので、是非お試しください。 同様に、PagerDutyインテグレーションを構築しようと考えている場合は、開発者アカウントにサインアップして開始してください。

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

続きを読む
ベストプラクティス
2022年10月24日  (更新日:2022年10月28日)

NOCプロセスの二日酔いになる3つの可能性

NOC(ネットワークオペレーションセンター)のプロセスは、何十年もの間、定石とされてきました。しかし、これらのプロセスの一部は、そろそろ進化する時期に来ています。デジタルトランスフォーメーションとクラウド時代の到来により、DevOpsが台頭し、それに伴いサービスオーナーシップも台頭してきました。サービスオーナーシップとは、開発者が自分たちが提供するソフトウェアをライフサイクルのあらゆる段階でサポートする責任を負うことを意味します。これにより、開発チームは顧客やビジネス、そして提供する価値により近い存在となります。

また、従来のNOCのインシデント処理方法からの脱却も必要です。しかし、組織がサービスオーナーシップに移行するにつれ、古いNOCのプロセスがいくつか残っています。ここでは、3つの一般的なNOCプロセスの残存物と、それらを交換または更新する方法について説明します。

プロセスの二日酔い。L1レスポンダーが問題を解決できない

かつてNOCは、技術的な問題の司令塔であった。NOCは脳のように機能し、関連する付属機器に信号を送ります。ネットワークに問題がある?ネットワークへのルート。セキュリティの問題?セキュリティーの問題?NOCの中心的な役割は、問題を解決するために適切なSMEを関与させることでした。これは、誰が何を担当しているかを把握するために、スプレッドシート(時には物理的な連絡帳も!)を掘り起こすことを意味します。

すべてがオンプレミスで対面式だった時代には、これは理にかなっていました。サービスも少なく、インシデントも部署ごとにきちんと分けることができました。もしデータベースに問題があれば、データベースのオンコールレスポンダーを呼び出すことができます。その担当者(おそらくオフィスにいるか、直接対応できるほど近くにいる人)は、データセンターに行き、調べることができました。

しかし、リモートワークやクラウドの時代には、世界中に散らばる数十、数百のチームによって数百、数千のサービスが管理されており、名簿方式はもはや用済みになっています。どのチームがどのサービスを担当しているのか、正確なスプレッドシートを維持することは不可能に近いのです。また、組織が変われば、記録はすぐに古くなります。サービスはチーム間で移動することができます。チーム間の移動や、退職・入社に伴い、チームも変化する。L1レスポンダーは、効率的かつタイムリーに適切な担当者を特定するために、大変な努力をしなければならないのです。

組織は、適切な担当者を見つけるためのこうした手作業のステップを排除し、あらゆる問題に飛び込んで対応できる中小企業に直接インシデントを転送する方法を必要としているのです。これは、さまざまな方法で実現できます。一部の組織では、DevOpsサービス所有権モデルが正しい道筋となります。コードを書く人は、インシデント発生時にサービスに対応し、修正するよう割り当てられます。アラートは、サービスをサポートする開発チームのオンコール担当者に直接送られ、そこからSMEが対応します。

他の組織では、L1レスポンダーが防御の第一線として機能した後に、分散したオンカルのチームにエスカレーションしてサービスを提供するというハイブリッドアプローチが理にかなっている場合もあります。L1レスポンダーは、問題を他のチームに接続するルーティングセンターであってはなりません。その代わりに、インシデントを自ら解決する権限を与える必要があります。L1レスポンダーに、トラブルシューティングとインシデントの選択的解決の両方の能力を与えることで、より効果的にL1レスポンダーをセットアップすることができます。自動化とランブックのようなリソースにアクセスすることで、L1レスポンダーは診断と修復のプロセスを加速させることができます。L1 レスポンダーに自動化を導入することで、組織は不必要なエスカレーションを回避し、L1 が問題を迅速に解決できるようになります。

プロセスの二日酔い。重大インシデントが発生しない、または発生が遅すぎる

時は金なり」という言葉を聞いたことがあります。そして、NOCがインシデントに確実に対応するための主要な方法であったとき、NOCはさらなる責任を負っていました。NOCは、リソースが適切に管理されていることを確認する必要がありました。つまり、問題に対応するために不必要な人員を配置しないことだ。NOCは、重大なインシデントを早く呼び出したり、微細な問題で人々を中断させたりすると、しばしば非難を浴びます。このような混乱は、中小企業を技術革新のための仕事から遠ざけてしまうことになります。そのため、NOCの対応者は、より大きな問題が起きていることが明らかな場合にのみ、重大インシデントを呼び出すことが極めて重要だったのです。

しかし、今は「時は金なり」ではなく、「稼働時間は金なり」なのです。大規模な事故が発生した場合のコストは、追加で人員を投入する場合のコストよりも大きくなります。例えば、オンラインショップでショッピングカートの機能がダウンしたとします。お客様が商品をカートに入れられない分、何十万ドルもの損失を被ることになります。さらに、ここ数年で、顧客の期待は高まっています。お客様は、アプリ、ツール、プラットフォーム、ストリーミングサービスなどが中断することなく機能することを期待しています。そして、そうでない場合は、顧客の信頼を損なうことになります。実際、PWCによると、3人に1人の顧客が、気に入っていたブランドで1度でも悪い経験をしたら、そのブランドとの取引をやめると回答しています。

組織は、顧客への影響を軽減するために、重大なインシデントをより早く連絡する必要があります。確かに、これは、不必要に誰かを起こすことを意味するかもしれません。しかし、サービスのオーナーシップがあれば、その可能性ははるかに低くなります。サービスを担当する中小企業は、L1レスポンダーよりも、いつ重大インシデントを呼び出すべきかをよりよく理解しています。そのため、誤報が少なくなります。

プロセスの二日酔い。出入りの激しい戦争部屋

NOCは、しばしば大規模なインシデントのコミュニケーションハブとして機能します。これは、問題解決に取り組む対応者が作業を継続するのに役立ちます。多くの企業がすべてを(そしてすべての人を)オンプレミスで管理していた時代には、ウォー・ルームがありました。人々はそこに集まり、NOCコーディネーターは皆に最新情報を提供しました。現在では、チームやシステムが分散しているため、物理的なウォー・ルームは過去のものとなっています。多くの企業は、ビデオ会議ブリッジやチャットチャンネルを備えた仮想のウォー・ルームの代わりに、インシデント発生中もオープンにしています。

他のステークホルダーは、このウォー・ルームを物理的な部屋と同じように扱い、好きなように立ち寄りたいかもしれません。しかし、この仮想世界では、これらの利害関係者がインシデント対応者に質問をすることになります。これでは解決は遅れます。出入りの激しいバーチャルワールームを持つ企業では、ミスコミュニケーションやフラストレーションがより多く発生する可能性があります。対応者は中断されることにフラストレーションを感じ、利害関係者はコミュニケーションの欠如にフラストレーションを感じるのです。

これを軽減する方法の1つは、ウォー・ルームを参加者以外には閉鎖することです。もし誰かがインシデント対応チームの一員でないなら、対応チームの仮想ウォー・ルームにアクセスする必要はないでしょう。その代わりに必要なのは、内部の連絡役です。これは、インシデント対応チームから指名されたコミュニケーターである。

社内コミュニケーション・リエゾンは、インシデント情報を集約し、関連するステークホルダーに伝達します。これを容易にするために、コミュニケーション担当者は、ステータスアップデートの通知テンプレートを使用することができます。このテンプレートは、特定の対象者に向けたコミュニケーションの作り方を規定するものです。これにより、利害関係者は意思決定に必要なすべての情報を受け取ることができます。また、対応担当者は、最新情報を共有するために、目の前の事故の作業を中断する必要はありません。

二日酔いは楽しくないが、必ず終わる

NOCは、多くの組織でインシデントを管理するために試行錯誤されている方法です。しかし、このデジタルトランスフォーメーションの時代に移行すると、NOCの方法は時代遅れになります。シームレスなコミュニケーションと迅速な対応は、お客様の信頼を維持するための鍵です。今後、チームはSMEを直ちに巻き込み、重大なインシデントを早急に連絡することになるでしょう。また、インシデント発生中は主要なステークホルダーとコミュニケーションをとり、境界線を設定することになるでしょう。

そして多くの場合、チームはこの移行をサポートするためのデジタルオペレーションプラットフォームを必要としています。PagerDutyは、重大インシデントのベストプラクティスを組織に導入し、重要インシデントを迅速に解決し、将来の発生を防止することを可能にします。14日間無料でお試しいただけます。

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

続きを読む
DevOps
2022年10月19日  (更新日:2022年10月27日)    |    ベストプラクティス

デジタル・エブリシングの世界においてCXOが直面する4つの課題

多忙な経営者にとって、イベントに参加し、セッションを聴く時間を取ることは贅沢なことです。しかし、私は、チームを率いるための最も優れたアイデアの多くは、新しいアイデアに耳を傾ける時間を取ることから生まれていることを知っています。課題は、山ほどあるコンテンツのどこに知恵の塊が埋まっているかを見極めることです。

PagerDuty Summit 2022は約15時間のコンテンツを作成し、その多くはサイトの信頼性エンジニア、プラットフォームチーム、エンジニアリングマネージャー向けのものでした。しかし、より上級のエグゼクティブにとっても、素晴らしい収穫がありました。私たち経営者は、イノベーション、業務効率化、リスク軽減を通じて成長を促進しています。そして、私たちの最大の課題の多くは、これらの成果を推進するために、チームの人々をどのように導いていくかということにあります。

PagerDutyサミットで発表された内容の中から、エグゼクティブにとって最も有益な洞察を探ってみました。その多くは、同じような課題に直面している他のシニアリーダーからの意見です。各セクションからリンクされているリプレイをご覧ください。

説明責任を果たす文化を形成する

説明責任は常に上り坂を転がるようなものです。経営者は説明責任を負うべきですが、局所的な説明責任の欠如は、「私の問題ではない」症候群につながります。しかし、組織が大きくなり、システムが複雑になると、説明責任を分散させることは難しくなります。

DevOpsの「You build it, you run it」というマントラは、説明責任の文化を受け入れることを意味します。以前にも書きましたが、どんな文化でも、物事がうまくいかないときにどうなるかがリトマス試験紙になります。どのような成果物があるのでしょうか?ダッシュボードが緑色のときは喜んで説明責任を果たすが、システムがダウンしたときには消極的になるのだろうか?

チームメンバーが問題に対処する能力を備えていないと感じると、説明責任は上滑りします。さまざまな業界の技術系リーダーが、物事がうまくいかないときにどのようにチームに力を与えているかについての素晴らしい洞察は、シドニーサミットの「Delivering Value(価値を届ける)」という基調パネルでご覧いただけます。シドニーサミットの基調パネル「Delivering Value: A two-way Street」をご覧ください。Nine社テクノロジー部門ディレクターのAndre Lachmann氏、Carsales社クラウド&プラットフォームサービス部門トップのSourav Lala氏、Wesdigital社エンジニアリング部門トップのGurnam Madan氏の話を聞くことができます。

マダンは、正しい基礎の上に正しい信頼を得ることについて話しています。これはどういう意味でしょうか?PagerDutyでSLAとSLOを遵守することについての彼の話を聞いてください。また、管理された環境で物事を壊すために、カオスエンジニアリングを取り入れることを推奨しています。"壊れるのを待つのではない"。 Lachmann氏は、プレッシャーが高いときに適切な人を巻き込むことができることの重要性を強調しています。何しろ、"毎日がメディア界のスーパーボウルのようなもの "なのですから。 Lalaは、顧客はおろか、チームが気づく前にインシデントを解決することを目指し、高いハードルを設定している。彼は、クラウド、自動化、PagerDutyを駆使して、これを実現しています。

同じものをより多く作る:オペレーションの効率化

経済的な不確実性を抜きにしても,同じものをより多く使おうとしていない企業はあるのだろうか?ガートナー社のレポート「The Chief Technology Officer's First 100 Days」によると、業務効率はCTOの成功を測る一般的な指標の1つです¹。しかし、すでにあるリソースをさらに活用するためには、変化というコストがかかります。

組織の行動を変えるように導くことは、効率化イニシアチブの成否を左右する。ResultsCX社のIT担当SVPであるJamie Vernon氏は、"Cultural Adoption of Automation"というセッションで、変化を導くための素晴らしい洞察を披露してくれた。結局のところ、自動化は、それを採用するための変化を管理することができれば、業務効率化を推進する上で大きな可能性を秘めているのです。

Vernonは、自動化を行う本物の理由を理解することを強調しています。「あなたの動機,情熱,熱意,本物であること......それが,あなたが関係者にそれを売り込む方法の一部となるのです」。人間は、パターンを見つけ、ルーチンを設定するようにできています。人は、変化という不快な状況に対処するために、説得力のある理由を必要とします。

Vernon氏は、より多くのスタッフに助けを求めているチームに対して、素晴らしいアイデアを紹介しています。彼は、自動化の取り組みをどのようにRITAに擬人化したかを説明する。チームはRITAを、チームの後輩を迎え入れるように訓練した。

もう1つのセッションは、Schneider社のもので、チームの変化を可能にするための素晴らしい青写真を提供してくれました。Jared Vils氏とDana Dickrell氏は、「The AIOps Outcome That Smashed It」の中で、74チームにわたる480人のレスポンダーをどのようにオンボーディングしたかなど、多くのことを取り上げています。また、この記事の中盤では、組織を巻き込むために制作した社内向けビデオについても紹介しています。業務効率化を推進すべき取り組みが停滞している場合、ここで素晴らしいアイデアを見つけることができるでしょう。

カスタマーエクスペリエンスの点と点を結ぶ

フォレスター・リサーチによると、82%のお客様が、自分たちが感謝され、尊敬されていると感じるブランドにはもっとお金を使う可能性があると答えています。1つのネガティブな体験が、5つのポジティブな体験を消し去る可能性があるのです。

ポジティブな体験を提供することは「全員参加」の状況ですが、すべてのチームが同じようにそれを経験するわけではありません。Anaplan のアメリカ地域カスタマーサクセス担当副社長である Fiona Gill との炉辺談話で、彼女は内部協力の必要性を強調しています。結局、顧客対応チームは、顧客から頻繁かつ直接的なフィードバックを得る。しかし、開発者とエンジニアは、顧客と接触する機会が少ない。

サイロで仕事をするのは簡単ですが、それではカスタマー・エクスペリエンスをリスクにさらしてしまいます。Gillは、顧客が良い体験をしていない場合、現場の人々が直接体験していることを強調します。これは、エンジニアリング・チームにとって重要なシグナルです。あなたのエンジニアリングチームは、どのようにその情報を入手していますか?

難しいこと 変化、レガシー、信頼

説明責任と同様に、「困難な問題」もまた、経営幹部まで上り坂を転がり落ちるように進む傾向があります。しかし、困難な問題にうまく取り組むには、組織を巻き込むことが必要です。難しい問題については、"Real Talk "をお勧めします。シドニーサミットのキーノートパネル「Real Talk: PagerDuty's Product Impact」がおすすめです。TelstraのGroup Principal Products and ServicesのFiona Mullerと、XeroのSite Reliability EngineeringのGeneral ManagerであるIain Phillipsが参加しています。

行動を変えるのは大変なことです。説明責任と業務効率化については、先に説明しました。しかし、レジリエンス・エンジニアリングなど、何事にも同じことが言える。「私たちは SRE を支援チームとして扱っています」と Iain Phillips は言います。変化を可能にすることを誰かの仕事とすることは、長い道のりです。しかし、変化を強制することはうまくいきません。例えば、Fiona Muller は、Telstra 社のツールが義務的ではなく、有機的に推進されていることを説明しています。

レガシー(または「遺産」)に対処するのも難しい。そう、新興企業やいわゆるクラウドネイティブでさえも、である。厳格な「バイ・モーダル」アプローチでは、ヘリテージ・アプリケーションに取り組むチームの士気を低下させることになりかねない。あなたのチームがDevOpsやSREを採用する際、どのようにヘリテージ・アプリケーションやインフラを導入しているのだろうか?Fiona Muller 氏が Telstra 社の取り組みから得た洞察を語ります。

最後に、信頼は獲得するのが難しいものです。PagerDutyのCEOであるJenn Tejadaは、「信頼は滴り落ちて得られるものであり、バケツの中で失われるものである」と言うのが好きです。Fiona Mullerは、彼女のチームがセキュリティと信頼性に多くの時間を費やしている理由について、この言葉を繰り返しました。「人々は悪いことについては長く記憶し、良いことについては短く記憶するものなのです。

リーダーとして、自分自身に投資し、学ぶための時間を毎日取っていることを望みます。このような仲間の洞察が役に立ったかどうか、教えてください。

脚注

¹ガートナー『最高技術責任者の最初の100日』サマンサ・サール、ニック・ジョーンズ、アルン・チャンドラセカラン、2022年9月7日。GARTNERは、米国および海外におけるGartner, Inc.および/またはその関連会社の登録商標およびサービスマークであり、本書では許可を得て使用しています。無断転載を禁じます。

²Forrester Research, Customer Service Unplugged: 共感できるカスタマーサービスを拡大する方法、マックス・ボール、2022年7月26日

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

2022年2月16日  (更新日:2022年10月20日)    |    ベストプラクティス

Customer Service Ops - 新機能リリース

ここ数年、ストリーミング、ショッピング、仕事、ヘルスケアなど、私たちの世界はますますデジタル化しています。顧客はこれらのデジタル体験がシームレスであることを望んでいます。これはあらゆる企業にとって重要な優先事項となっています。なぜなら、企業の売り上げやブランドの評判は顧客満足度に左右されるからです。 このようなシームレスなデジタル体験を保証するために、テクノロジーチームは信頼性、ユーザー体験、新機能の構築に過去と比べ倍以上の努力を払ってきました。しかし、デジタルの世界は完璧ではありません。問題が発生した場合でも、顧客を安心させ、維持するために、企業はこれまで以上にカスタマーサービス(CS)チームを必要としています。 PagerDuty for Customer Serviceは、カスタマーサービスチームがプロアクティブになり、ケースに費やす時間を短縮し、SLAを達成し、比類のないレベルのカスタマーサービスを提供できるよう支援します。 昨秋当社は、Salesforce Service Cloud用の PagerDutyアプリケーションを発表しました。これにより、ユーザーは Salesforce Service Cloudで直接作業でき、コンテキストを切り替える必要性が減りました。これにより、カスタマーサービスチームは、迅速かつ効率的に、そして部門を越えて仕事ができるようになりました。今回、カスタマーサービスエージェントのユーザーのために、さらに多くの機能を発表できることを嬉しく思います。これらの新機能により、チームは顧客に影響を与える問題の影響範囲を把握し、より迅速に対応できるようになります。

Incident Subscription Incident Subscriptionにより、CSエージェントは、リアルタイムのサービスステータスコンソールを介して、SFDC内で直接インシデントを閲覧(サブスクライブ)できるようになりました。シングルクリックで、エージェントはインシデントの進捗と解決に関するリアルタイムのアップデートを受け取ることができます(以前のように、チケットとインシデントを手動で「リンク」させる設定は必要はありません)。一度サブスクライブすれば、エージェントは自分のキューにある他の顧客チケットを処理することができ、影響を受けた顧客とのループを閉じるときにPagerDutyが再エンゲージするのを知ることができます。

ダッシュボードトグル この新機能により、カスタマーサービスエージェントは、自分たちに特化・関連したStatus Dashboardを持てるようになります。顧客向けサービスに特化したビジネスサービスのStatus Dashboardを作成できるため、バックエンド全体のシステムヘルスと顧客に直接関連するシステムヘルスを分けて表示することができます。これにより、CSはよりシンプルになります。

PagerDutyのインシデントタイトルをSalesforceのデータでカスタマイズする エージェントはさらに、Salesforceのケースから得た重要な情報に基づいてチームがPagerDutyのインシデントをカスタマイズできるよう、強力に支援できます。このデータにより、顧客と問題と緊急性を特定し、複数のケースをPagerDutyのインシデントにリンクさせることが容易になります。エージェントは、ケースをドリルダウンしたり、ツール間でコンテキストを切り替えたり、ケースの進行に関するリアルタイムの更新を確認したりすることなく、どのインシデントに関連するのかを一目で確認し、できるだけ多くの詳細を提供することができます。

PD WebでリンクされたSF案件の可視化 インシデントが顧客に与える影響範囲や、問題によって影響を受ける顧客の数を気にしたことがありますか? もう悩むことはありません。PD Web、モバイル、電子メールのいずれでも、PD for Customer Serviceはインシデントに関連するケースをリンクしてレポートします(逆もまた然り)。なぜでしょうか?カスタマーサービスエージェントは、受け取ったケースの数に基づいて、特定のインシデントの緊急性を正当化できるからです。また、インシデント対応では、障害に対してどれだけの顧客が不満を抱いているかを確認できます。結局のところ、顧客はデジタル資産の健全性を示す重要な信号なのです。 これらの新機能により、サポートチームとレスポンスチームの間のサイロを継続的に解消し、あらゆるインシデントに迅速かつ容易に対応するための方法を、カスタマーサービスチームに提供していきます。これにより、カスタマーサービスエージェントは、ケースを最初から最後まで自分で管理できるようになります。

PagerDuty Customer Service Opsについて詳しくはこちら。さらに、営業に連絡するか、14日間の無料トライアルに申し込むと、すぐに始められます。

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

2022年6月28日  (更新日:2022年10月20日)    |    ベストプラクティス

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

2022年9月22日  (更新日:2022年10月18日)    |    DevOps

PagerDutyモバイルアプリでメンテナンスウィンドウを作成・管理

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

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

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

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

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

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

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

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

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

複数のサービスのメンテナンス窓口。

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

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

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

iOS

Android

PagerDutyのインシデントレスポンスとモバイルアプリとの連携についてもっと知りたいですか?14日間の無料トライアルに参加し、PagerDutyがいかにチームを迅速かつ効率的に強化し、オペレーションクラウド全体のイノベーションを推進できるかを体験してください。

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

2022年6月22日  (更新日:2022年10月17日)    |    ベストプラクティス

インシデント対応向上のためにサービスオーナーシップを大規模に基準化するには

サービスオーナーシップはDevOpsのベストプラクティスで、チームメンバーが開発ライフサイクルの各段階で、自分たちが提供するソフトウェアのサポートに責任を持つというものです。このレベルのオーナーシップにより、開発チームは顧客と事業と提供価値により密になることができます。

サービスオーナーは、そのサービスの主題の専門家(SME)であり、サービスオーナーシップモデルでは、あらゆる生産上の問題への対応にも責任を負います。このモデルに移行するチームにとって、オンコールになることは大変なことに思えるかもしれません。週末や夜間にラップトップを抱えてインシデントに対応するという恐ろしい話を聞いたことがありませんか?

オンコールは大変なことです。しかし、サービスオーナーシップのようなベストプラクティスは、オンコールシフトに秩序と予測可能性を導入し、理想的には全員の生活の質を向上させることができるのです。

なぜサービスオーナーシップが重要なのか

次のシナリオを想像してみてください。システムのどこかに問題があるためにミーティングに呼ばれましたが、サービスオーナーが決まっていないため、SMEが誰なのか誰も知りません。15分が20分になり、30分になり..。その間、さらに多くの人が電話に飛びつくが、何の進展もなく...。

こんな混沌としたインシデント対応は貴重な時間を浪費し、非効率の典型です。そして、最悪なのは、このようなことが常に絶えないことです。

こんな事態は避けなければなりません。しかし、その前に、なぜ多くのチームが手作業によるインシデント対応に負担を感じ、いつまでも引きずってしまうのか、その理由を考えてみましょう。対応が遅くなる理由を考えてみると、それは、いくつかの非常に重要な質問に答えられないことに集約されます。

どのサービスが影響を受けるのか? サービスの依存関係は? それぞれのサービスのオーナーは誰?

先に挙げた例のようなミーティングは、これらの質問に答えようとするものですが、後手に回ってしまいます。これらの質問に答えることができない限り、チームは立ち止まったまま、インシデントの解決に進めないのです。

テクノロジーのエコシステムが変化し続け、あらゆる規模の企業でより複雑になるにつれて、このような状況はますます一般的になってきています。何百ものサービス、マイクロサービス、分散型オーナーシップによって、何か問題が発生したときにどのように行動を起こせばよいのかが分からなくなっています。

サービスオーナーシップは、組織がより積極的にインシデント対応に取り組むのに役立ちます。とはいえ、これは簡単なことではありません。文化を変えることは難しく、DevOpsとサービスオーナーシップへの移行に何とか成功した組織は、ベストプラクティスに従うことと、サービスオーナーシップを採用するためのプロセスを持つことが、組織全体の定着と規模の拡大に役立つことに同意するはずです。

組織がサービスオーナーシップを採用できれば、サービスオーナーから経営陣のステークホルダー、顧客に至るまで、全ての人がメリットを得られます。サービスオーナーは、必要なときだけ呼び出されます。ステークホルダーは、インシデントによって何が影響を受けるかを把握し、技術チームと協力して影響を軽減できます。また、顧客はサービス中断中も明確な応対を受けられ、以前ほど復旧まで待たされていると感じなくなります。

顧客の期待がかつてないほど高まり、カスタマーエクスペリエンスが重要な鍵を握る世界において、インシデントに対応する人々の生活を向上させながら、組織を競争優位に立たせることができるのです。

実際のところ、サービスとは何なのか

サービスを定義することは、一見したところ意外と難しいものです。サービスをさまざまな方法で分割している組織を見てきましたが、クラウドに展開されているサービスと一致するほど単純なものではありません。組織によっては、分割できない要素の存在も考慮する必要があります。では、どのように物事を管理しやすいピースに分割し、チームが責任を持てるようにすればよいのでしょうか。

PagerDutyでは、サービスを "価値を提供し、チームが完全に所有する機能の個別ピース"と定義しています。別の言い方をすれば、サービスは監視するエンティティーを表し、インシデントを適切なエスカレーションポリシーに関連付ける関連インシデントのコンテナとして機能する、ということです。

つまり、監視し、インシデントを関連付け、特定の担当者を待機させるのであれば、それはサービスだ ということになります。これはより広範な定義であり、従来とは異なるサービスをチームがどのように定義するかについて、より柔軟性を持たせることができます。

しかし、レスポンダーは、問題に対処するための十分な準備をするために、これらの境界線だけでなく、それ以上の情報を知っておく必要があります。ここで、サービスの構成が大きな違いを生むことになります。

サービスが適切に構成されているとはどういうことか

PagerDutyでは、サービスオーナーシップの導入を進めようとしている組織にとって価値があると思われる一連の標準を確立しました。これは私たちがサービスをどう作成するかのガイドラインであり、「良い」とはどんなものかを決めるものです。

この基準はフレキシブルなものでもあります。全サービスが同じように構築されるわけではありませんし、私たちの基準のいくつかは、それぞれの状況には当てはまらないかもしれません。この基準は、お客様がオンコールをより効率的にし、第一線で働くオペレーターの負担を軽減するための出発点として考えてください。

大事なのは、サービスオーナーシップはプロセスであって、ToDoリストでチェックすべきボックスではないということに留意することです。運用の成熟度によっては、基準を設定し、採用するペースは異なるかもしれません。

比較的小規模で、サービスオーナーシップの経験が浅く、クラウドベースのサービスを中心に扱っている場合は、数日で基準を設定し、それに従ってサービスを構成できるかもしれません。ゼロから始める場合は、さらに簡単です。最初のサービスを作るときに基準を適用すれば、以前に設定したサービスに戻って変更する必要がなく、長期的にうまく導入できます。

しかし、数百、数千のサービスを持つ大規模な組織では,この移行は難しいかもしれません.このような組織では、次のような問いかけをすることで、今後の進め方を検討できます。

既存のサービスのうち、今すぐ基準を設定できるものは何か、またその基準は何か。 いくつかの基準は、全てのサービスに適用するのが簡単であると気づくかもしれません。たとえば、サービスには、それが何をするものかを正確に説明する名前が必要です。このように、大多数のサービスが従うべきと分かっている基準があれば、実装を始める適した場所です。このような変更を行うよう、パイロットチームにどのように依頼できるかを考えてみてください。 新しいサービスを作るためのプロセスはどのようなものか。 基準は決まっていても、現在のサービスを全てその基準に合わせるのは大変な仕事です。大規模な組織であれば、全てのサービスを一度に再構成することは通常不可能です。また、サービスを再構成することは、最初に正しく設定するためのプロセスに従うことよりもフラストレーションがたまる可能性があります。 長期的な目標は何か。そのためのスケジュールはどのようなものか。 サービスによっては、これらの基準が必要ないものもあるかもしれません。残りのサービスについては、期限を決めて計画を立て、追加のチームのオンボーディングを開始し、時間をかけて少しずつ変更していきましょう。 どのように依存関係を知るか。 基準を作成し、適用するだけでなく、サービス同士がどのように対応し、互いに影響し合っているかを知ることも重要です。基準を確立する一方で、構成プロセスでこの情報を体系化することをどのように奨励するかについて考えてください。

これらの質問に個別に答えることは、大きな差別化要因にはならないかもしれません。しかし、それらがどのように拡張されるかを考えるとき、インシデントへの対応に大きな違いが生まれます。

インシデント対応にどのように役立つか

インシデント対応では、重要でない仕事に時間や労力を浪費しないことが重要です。インシデントを解決するためにチームが集中する必要があるものに、全てを絞り込む必要があります。

サービスオーナーシップは、対応プロセス全体を通じて、このことを明確にするのに役立ちます。

例えば、サービスの設定が適切であれば、適切な緊急性と最小限のアラートノイズでアラートが表示されるため、最も重要な信号のみに対応し、それに応じて優先順位をつけることができます。また、サービスの所有者を把握できるため、適切な担当者を迅速に配置することができます。成熟度が上がれば、サービスの自動化シーケンスを作成し、サービスを正常な状態に戻すための作業を軽減することも可能になります。

また、サービス上で何が変更されたかを確認できるため、何が問題だったのかを診断するのも簡単です。また、サービスマッピングにより、システムに対する全体的な影響を把握することができます。

問題解決中は、サービスに必要なインテグレーションを迅速に行い、ステークホルダーに情報を提供することができます。インシデントの影響を受けると分かっている関係者だけに連絡を取り、組織内でも影響を最小限にとどめることができます。

最後に、インシデントからよりよく学ぶことができます。サービスのSMEとして、過去の文脈を把握し、その学習結果を対応プロセスにフィードバックすることで、長期的な耐障害性を高めることができます。

サービスオーナーシップを組織全体に拡大すると、こうした改善によって顧客とチームメンバーの両方に劇的な変化がもたらされます。サービスオーナーシップの導入や運用の成熟度を向上させ、そのプロセスをガイドしてくれるパートナーをお探しなら、14日間無料でPagerDutyをお試しください。大規模なサービスオーナーシップの基準化についてもっと知りたい方は、こちらのウェビナーをご覧ください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

2018年5月17日  (更新日:2022年10月13日)    |    インシデント&アラート

HOW-TO:Twitterトレンド・アラート・システムの作り方

こんにちは!私はリチャード・チャオ、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社のサイトで公開されているブログをそのまま日本語に翻訳したものです。原文はこちらを参照してください。

2022年3月2日  (更新日:2022年10月13日)    |    ニュース&告知

女性が個人のコントリビューターとして技術分野でリードすることの意味

テクノロジー企業での業務は、ソフトウェア開発の仕事だけではありません。PagerDutyのようにソフトウェアを事業としている企業では、あらゆる職務がテクノロジーに関わります。PagerDutyの多様性イニシアティブは、CAPインターンシッププログラムから取締役会まで、組織のあらゆるレベルに及んでいます。 女性史月間と国際女性デーの今年は、昨年に引き続き、女性に焦点をあてたプログラムを充実させたいと考えています。2021年のイベントを見逃した方は、 録画をご覧いただけます。今年のウェビナーでは、ゲストスピーカーにDevOps InstituteのチーフアンバサダーであるHelen Bealを迎え、その後PagerDutyとユーザーコミュニティーの幹部がパネルディスカッションを行います。3月23日のイベントについての詳細と参加申し込みはこちらから。

ウェビナーに加え、パネルディスカッションも開催し、当社のソーシャルメディアアカウントでライブストリーミング配信します。私たちは、女性経営者が何に刺激を受け、どう組織を運営しているかを話すのが大好きです。今年はパネルを拡大し、PagerDuty、お客様、そして私たちのコミュニティーで技術専門職として活躍する女性の話をもっと聞きたいと思いました。これらのディスカッションはTwitterアカウントでフォローできますし、質問をしたい場合はTwitchでも視聴できます。ライブを見逃した方もご安心ください。TwitchやYouTubeアカウントで録画したものを見ることができます。

今週はPagerDutyの最高ダイバーシティー責任者であるRoshan Kindredから話を聞きます。Roshanは昨年夏にPagerDutyに入社し、公平性と帰属意識に対する情熱を持ち続けています。私たちはRoshanと、DE&I、キャリア成長、そして女性が技術キャリアで自分自身を主張する方法について話をします。3月7日(月)2pm EST / 11am PSTにご参加ください。

火曜日は、PagerDutyチームのJess Ritterと、H&R BlockのBrittany Woodsと一緒にSREについてお話します。JessはSREデリバリーチームで、私たちの製品をお客様に届けるために必要なものを全開発チームが持てるよう保証しています。BrittanyはH&R BlockでServer Automationのマネージャーをしています。彼女は昨年、ポッドキャストのエピソードにも参加しています。このパネルは、3月8日(火)2pm EST / 11am PSTに開催されます。

水曜日は、人々がテクノロジーから最も連想する仕事であるソフトウェア開発に取り組む人たちに話を聞きます。パネルディスカッションでは、PagerDuty RundeckチームのJulianna Green、Event OrchestrationsチームのNeha Wadhwa、モバイル開発チームのSanthoshi Shakar、そしてApp FoundationsチームのHannele Kormanoが登壇予定です。このパネルは3月9日(水)2pm EST / 11am PSTに開催されます。

木曜日のパネルは、セキュリティーとコンプライアンスに焦点を当てます。セキュリティーエンジニアIIのNeha Guptaをはじめ、ScaleSecのシニアクラウドセキュリティーコンサルタントのSarah Gori、Elasticのセキュリティーエンジニアリング生産性担当シニアQAエンジニアのTanisha L. Turnerが参加する予定です。セキュリティーパネルは3月10日(木)2pm EST / 11am PSTに実施します!

最後に、金曜日は、プロダクトチームとプロダクトマーケティングチームの女性を特集します。PagerDutyのプロダクトマネージャーとプロダクトマーケティングマネージャーは、さまざまな技術的経験を持ち合わせています。プロダクトマネージメントチームからはJulianna NasserとMya Kingが、プロダクトマーケティングからはVivian Chanが参加します。3月11日(金)3pm EST / 12pm PSTにご参加ください(このパネルは、スケジュールの都合で他のパネルより1時間遅く開催されます)。 私たちのパネルは、PagerDutyで女性が担っている全ての役割を網羅しているわけではありませんが、2022年の国際女性デーを記念して、これらのストーリーを皆さんと共有できることを誇りに思っています。もし、あなたがこれらの役割のいずれかに自分自身を重ねているのであれば、boards.greenhouseから応募して参加してください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

2022年8月2日  (更新日:2022年10月13日)    |    DevOps

Slack on Webhooks V3の専用インシデントチャンネルの改善 - アーリーアクセス

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

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

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

  1. Slackにて

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

  1. PagerDuty Web 経由

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

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

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

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

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

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

次はどうする?

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

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

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

2022年8月1日  (更新日:2022年10月13日)    |    ベストプラクティス

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

2022年7月12日  (更新日:2022年10月13日)    |    DevOps

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

2022年8月3日  (更新日:2022年10月13日)    |    ニュース&告知

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 – ELBELBターゲットのヘルスステータスを取得するロードバランサーに関連するTarget Groupsのうち、不健全なTargetの一覧を取得します。ELB Instance Statuses
AWS – RDSデータベースの保存状態を確認するインスタンスの状態をRDSデータベースで確認します。RDS Instance Status
AWS – VPCUDP転送プロトコルを使用した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別ウェブサーバーリクエスト数トップ10CloudWatchのログを照会し、当社のウェブサーバー(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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一般的な例

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

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

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

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

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

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

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

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

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

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

PagerDuty内の診断の自動化

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

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

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