Blog
ブログ

2020年8月21日  (更新日:2022年3月10日)

リモートインシデント対応でPagerDutyを常にオンに保つ

2020年7月初め、多くの地域で、サービスプロバイダーのルータの設定ミスによる大規模なインシデントが発生しました。これにより、サービスの障害が連鎖的に発生し、いくつかの有名なSaaSに広範囲の停止と混乱を引き起こしました。

障害が発生したとき、我々PagerDutyのチームはすぐにイベントやインシデントの世界的な急増に気付きました。いくつかの組織内でアラートやインシデントが増加することは珍しくありませんが、今回のケースでは、複数の地域で多数発生していました。これは懸念材料でした。

インシデントの量が異常に増加した場合には、問題に対処するために総力を挙げて対処できるように、予防措置としてメジャーインシデント対応を積極的に展開しています。対応者にタイムリーに通知を行うために、PagerDutyのモバイルアプリを使用して、必要な関係者がどこにいようとも、即座に連絡を取るようにしています。

この特定の問題は、私たち全員がリモートで仕事をしている時に起きたので、私たちはSlackとZoomを使って対応を調整しました。PagerDutyとSlackとのインテグレーションを利用して、インシデント責任者、エキスパート、利害関係者、記録係からなる完全にリモートのチームを編成し、サンフランシスコ、トロント、アトランタで協力して大規模なインシデント対応を3分以内に完了させました。

当社のインシデント責任者が対応を調整し、カスタマーサポートが内部と外部の情報更新を管理し、専門分野のエキスパートが取るべき必要な手順を議論し、記録係が対応の進捗状況とコミュニケーションを文書化しました。

幸いなことに、当社のシステムがインシデントトラフィックの急激な増加に対応できることを迅速に判断し、問題を沈静化することができました。

リモートインシデント対応の重要性

完全に遠隔地での作業環境でのこのような大規模なインシデントは、場所に関係なく、インシデントを迅速に受任し、チームとして対応することの重要性を浮き彫りにしました。PagerDutyでは、分散化した作業と対応の文化は、初日から私たちのプロセスに組み込まれています。実際、当社のインシデント対応ドキュメントを見てみると、対処中に対応者の物理的な接近を必要とするプロトコルは1つも見当たりません。PagerDutyプラットフォームを使えば、どこにいても、インシデントに瞬時に対応し、作業することができます。

また、SlackやZoomのようなコラボレーションツールを利用して、インシデント発生時にリアルタイムでコミュニケーションを取ることもできます。今回のケースでは、PagerDutyとSlackのインテグレーションが、インシデントの状況と関係者への情報更新のための中心的なハブとなりました。Slackで当社のチームメンバーは主要な利害関係者に通知し、役割を割り当て、仮想的な場所に集まり、インシデントに真正面から取り組むことができました。

さらに、インシデントが解決したあとにも、Slackは事後検証のプロセスに役立つため、将来の対応プロセスにも貢献します。記録係はSlackインテグレーションを使用して、対応中に発生したすべてのことを文書化して記録します。誰が対応したのか、誰が対応しなかったのか、なぜエスカレーションしたのかなど、起きたことをすべて見ることができるので便利です。これにより、インシデントの全体像を把握して理解することができ、将来インシデントが発生した場合でも、より迅速に対応して解決するためのプロセスを改善することができるようになります。

私たちの分散型エンジニアリングの文化は、PagerDutyが何があってもお客様のために常にオンになっていることを保証することを可能にしています。PagerDuty をコラボレーションツールや明確に定義されたプラクティスと共に真実の単一ソースとして使用することで、事実上どこからでもインシデントに効果的に対応することができます。多くの場合、オフィス内のオーケストレーションから仮想的な対応に移行することは困難だと思うでしょうが、PagerDuty を使用することで、ほとんどの場合、通常通りの業務を行うことができます。

チームがどのように PagerDuty を使ってリモートインシデントレスポンスを行うかについては、分散型コミュニケーションに関するこのブログを参照してください。

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

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

PagerDuty:私たちは常にオンです

COVID-19の急速な感染拡大に伴い、多くの企業が完全なリモートワークに移行しています。顧客、ベンダー、パートナーがオンラインであることは、企業にとってこれまで以上に重要です。PagerDutyでは、従業員、その家族、そして私たちが属するより広い地域社会の健康と安全に主眼を置いていますが、他の最優先事項の1つは、特にこのような困難な時期には、顧客へのコミットメントです。

ご存知の方もいらっしゃるかもしれませんが、現在、全世界の従業員がリモートで仕事をしており、出張を停止しています。これが今のところの新しい常識かもしれませんが、リモートワークは当社にとって新しいことではなく、当社は最初からこのようなシナリオを想定して作られています。

当社の従業員は世界中に分散しており、分散したリモート環境での当社プラットフォームの開発と運用に慣れています。つまり、この事態にもかかわらず、お客様のデジタルビジネスが24時間365日稼働するように、PagerDutyを稼働させ続けることができます。

お客様へのコミットメント

デジタル運用管理のマーケットリーダーとして、当社はこの分野で最大規模、最も信頼性が高く、回復力のあるプラットフォームを提供しています。当社のお客様からは、昼夜を問わず、いつでもシステムに問題が発生したときに、リアルタイムで適切な対応を行うための支援を受けることができるとの信頼をいただいています。では、それをどうやって実現しているのでしょうか。

当社のチームメンバーが分散しているのと同様に、当社のプラットフォームアーキテクチャも分散しています。当社は、複数の物理的なデータセンターからなる地理的に独立したクラウドリージョンに分散して配置されています。当社のアーキテクチャは、お客様からのトラフィックの急増を想定しています。例えば、旅行業界やEコマース業界とは異なり、予測可能なトラフィックパターンには季節性がありません。1万2700人以上のお客様からの予期せぬトラフィック量の増加に最善の準備をするために、必要に応じて動的にスケーリングできるように準備しています。

当社は、「失敗の金曜日」シリーズでカオスエンジニアリングを実践し、お客様のために信頼性と回復力を維持する能力を実践していることで知られています。時間をかけて障害シナリオのシミュレーションに取り組んできた結果、現在では「Failure Anydays」(失敗はいつでも起こる)を実施しています。そう、当社のチームの1つまたは複数が、お客様へのサービス提供の質に影響を与える可能性のある問題を迅速に特定して軽減するために、制御された障害テストをいつでも実施しているのです。2013年以来、当社のプロセスと実践をお客様と共有してきたので、失敗からの学習への投資は新しいものではありません。私たちは、プラットフォームアーキテクチャ、ベストプラクティス、そしてお客様への取り組みを維持するために懸命に努力し続けるチームに適した要素を備えていると確信しています。

ダウンタイムといえば、PagerDutyでは予定されたダウンタイムはありません。あなたの時計は止まることはありません。当社のサービスレベルアグリーメント(SLA)は、お客様に提供する可用性とパフォーマンスの両方をカバーします。メンテナンスのために計画的なダウンタイムを実施することはありません。問題が発生した場合、設定された配信期間内にお客様が通知を受け取ることができるように、プラットフォーム製品に冗長性を持たせています。

多くの企業がリモートワークへのシフトを行おうとしているか、または行っています。そして今、これまで以上にデジタルビジネスが稼働し続けることが不可欠です。PagerDutyはそれを助けるためにここにいます。

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

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

2020年春のローンチ:新しいデジタル時代の新機能

進行中のパンデミックとその結果としての景気後退は、市場の状況を劇的に変化させました。その結果、エンジニアチームは、完全リモート環境に突然移行することによる影響を軽減するために、財務リスクを最小限に抑え、コストを削減する必要性をますます感じることになりました。

一部の人にとっては、ビジネスの継続性を維持するための苦労がありました。つまり、皆が自宅で仕事をしているときもビジネスの物理コンポーネントは実行し続けています。他の人にとっては、社内外の顧客に対するデジタルサービスへの依存度を強調することが課題の中心となっています。最近の調査で判明したように、すべての組織や部門が同じように影響を受けるわけではありません。

このような環境では、会社の種類に関係なく、ビジネス目標はコストを削減し、収益を保護し、デジタルトランスフォーメーションを加速するという3つのニーズに集約されます。困難なように思われるかもしれませんが、楽観的な見方があります。適切なテクノロジーソリューションを導入することで、組織は予算を拡大し、プロセスをより効率的にし、シームレスなデジタル体験で顧客を満足させることができます。

PagerDutyは、お客様の課題解決を支援するために、対応チームの効率を向上させ、デジタルファーストの世界でお客様との関係を保護できるようにする最新のリリースを発表しました。

積極的なインシデント対応

デジタルサービスへの信じられないほどのアクセスに直面している場合でも、それがまもなく予定されている場合でも、あらゆる組織が積極的にインシデント対応することが重要であると考えています。積極的になるとは、技術スタッフとビジネススタッフの両方にデジタルサービスを活用するためのツールを提供し、問題が発生しても無知の状態から始まらないようにすることです。デジタルの世界では、秒単位の時間が重要であり、重要な個人がその場でインフラや対応手順について学習することはできません。今こそ行動の時です。そのため、デジタルの準備が非常に重要です。

積極的なインシデント対応に関する新機能とアップデートされた機能により、すべてのチームにデジタルサービスとその依存関係、ハイパーケアを提供し、収益に影響する危機になる前に問題を回避するために必要な運用指標を提供します。

サービスプロファイルを使用すると、エンジニアリングマネージャーと対応者はランブック、抑制されたアラート、過去のインシデント、通信チャネルなど、サービスに関する関連情報を整理、検索することができます。

サービスダッシュボードは、運用メトリックとKPIを分析して、組織間の調整を行い、より良いビジネス成果を実現します。

サービスの依存関係(アーリーアクセス可能)は、ユーザーがPagerDutyのサービス間の関係を理解し、問題をより迅速に特定、トリアージ、修正し、チーム全体でより効果的にコラボレーションするのに役立ちます。

可視性コンソール(アーリーアクセス可能)は、サービスパフォーマンスのリアルタイムの統合ビューを提供し、UIが一新された高度なフィルタリングとカスタマイズ可能なレイアウトが含まれるようになりました。このツールは、チームがインシデント対応に積極的なアプローチを取り、ハイパーケアの瞬間に顧客のニーズを満たすのに必要なコンテキストを提供します。

インテリジェントな対応と自動化

チームがまだハンドブックを調べて問題への対応方法を決定している、または手動で過去のインシデントを調べて何が関連しているのかを確認していては、時間やリソースを最大限に活用できません。チームの効率を改善して収益を保護する最も簡単な方法の1つは、価値の低いアクティビティや労力を自動化して削減し、貴重なリソースを他の場所に再展開できるようにすることです。

インテリジェントな対応と自動化のための最新のソリューションは、何が最も重要であるかに焦点を当てたリアルタイム情報を提供します。また、作業の重複を減らし、マシンが手動タスクを自動化できるようにすることで、対応者の負担を軽減します。自動化でより少ないリソースでより多くのことを実行できるようになり、ビジネスの回復力が向上し、収益が保護されます。

イベントインテリジェンスの一部であるモバイルインテリジェントトリアージは、チームによる作業の重複を防ぎます。機械学習は、問題とコラボレーションの履歴レコードを利用し、関連するインシデントをマージすることで、誰が責任を持ち、問題に取り組んでいるかをより正確に特定できるようにします。

インシデントの再開**(アーリーアクセス可能)は、対応者の柔軟性が向上し、インシデントの重複が減少し、問題が予期せずに再発したときに、より迅速な再動員が可能になります。

Rundeck、Ayehu、Pliant、Amazon EventBridgeとのインテグレーションは、ワークフローマニュアル自動化し、レスポンスプレイの一部として対応チーム内のコミュニケーションを改善することができます。

リアルタイムビジネスオーケストレーション

今日、テクノロジーチームは、デジタルサービスに対する顧客の需要の劇的な増加だけでなく、完全に分散されたチーム間でのインシデントコミュニケーションの管理にも取り組んでいます。一方、顧客は依然として完璧な体験を期待しています。インシデントが発生した場合、ビジネス面での対応と技術的な対応を緊密に統合することが重要であると考えています。これは、既存の技術プロセスの自然な拡張である必要があり、手動のプロセスを伴うことや、追加のツールをセットアップをしなくてもいいことが必要です。

当社の最新の機能強化は、サイロを分解し、すべてのチームに適切なレベルの情報を提供することで、重要な瞬間に作業とコミュニケーションをより効率的に行えるようにし、最終的にはより良い顧客体験につながります。

モバイルステータスダッシュボードは、ビジネスの利害関係者に、ビジネスサービスに関する情報更新への外出先でのアクセスを提供します。

ステータス更新ブランディングはブランド化された通知により、通知受信者のエンゲージメントと信頼を高めます。

Salesforceとのインテグレーションにより、チームはワークフローをカスタマイズして適切なリソースを適切なタイミングで動員できるようになるため、デジタルサービスのカスタマーサポートにおけるクラス最高の統一フロントが実現します。標準のSalesforceオブジェクトと統合して、PagerDutyで対応するアクションをトリガーします。

オンコールスケジューリングタイムライン(制限付きアクセス)および* ハンドオフ通知の拡張機能*により、オンコールシフトとチームメンバーが担当するサービスの可視性が向上し、競合、ワークロード、シフトのオーバーライドを管理する簡単な方法がユーザーに提供されます。

Microsoft Teamsとのインテグレーションにより、対応者はチーム内の重要なインシデントの詳細を表示できます。また、新しいインシデントを受任、解決、トリガーするだけでなく、インシデントのメモをすべて1つのインターフェイスから追加できます。

新しいインテグレーションとAPI

詳細が重要であることはわかっており、小さな改善や拡張されたインテグレーションでも、停止に迅速に対応し、最高のパフォーマンスで運用するチームの能力にすべての違いをもたらすことができます。そのため、私たちはSalesforce、Microsoft Teams、Jiraなどのツールとの統合を強化し、テクノロジースタック全体の可視性を最大化して、すでに知っているツールやお気に入りのツールから作業できるようにするために懸命に取り組んできました。さらに、ビジネスサービスとレスポンスプレイAPIにより、主要なデータと機能にアクセスできます。

最新のリリースの詳細については、このリンクをご覧ください。

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

続きを読む
ニュース&告知
2020年7月20日  (更新日:2022年3月10日)

インテリジェント対応と自動化で、少ない労力で多くのことを行う

良くも悪くも、私たちの社会はは効率化に取りつかれています。オンラインバンキングやEコマースアプリからスマートIoTデバイスに至るまで、私たちの生活の隅々にその痕跡があります。しかし、私たちは個人生活のほぼすべての面で自動化を使用しているにもかかわらず、PagerDutyとDimensional Researchが実施した共同研究では、90%の企業が問題解決のための自動化をほとんど、あるいは全く行っていないことがわかりました。なぜでしょうか。私たちは簡単なことをより簡単にするため、私たちの生活の中で毎日自動化を利用しているのに、なぜ仕事でもそれを利用していないのでしょうか。

頑張らずに賢く働く

社内では「技術の達人」と呼ばれているにもかかわらず、仕事を終わらせるために面倒な手動のプロセスに頼っているIT担当者の多さに驚くことでしょう。

多くのITチームは、時間やリソースを最大限に活用できていません。その代わりに、問題への対応方法を決定するためにハンドブックに目を通したり、過去のインシデントを手作業で調べて関連性があるかどうかを確認したりしています。しかし、チームの効率を向上させ、収益を守るための最も簡単な方法の1つは、インテリジェントな対応と自動化であり、繰り返し可能な手順を自動化することで、貴重なリソースを他の場所に再配分することができます。

2020年春に発表された最新の機能強化では、インテリジェント対応と自動化に3つの方法でアプローチしています。(1)人とプロセスの調整、(2)対応チームが必要なときに適切なコンテキストと情報を提供する、(3)使いやすい自動化機能を提供することで、問題を迅速に診断して解決できるようにする。これがどのように機能するかを詳しく見てみましょう。

新機能の詳細 インテリジェントトリアージ

PagerDutyイベントインテリジェンスの一部として、モバイルで利用できるようになったインテリジェントトリアージは、チーム作業の重複を防ぐことができます。これにより、複数のチームに影響を与えるインシデントについて、何が本当の原因となっているかを判別するために、Related Insidents機能を使用することができます。Related Insidentsは、イベントインテリジェンスの機械学習機能をノイズ削減の域を超えて拡張し、サービス全体にわたってリアルタイムのコンテキストに基づいた洞察を対応者に提供します。

目下のインシデントに関連している可能性のある他のサービスで同時発生しているインシデントを調査することで、対応者は影響の幅と範囲をより深く理解し、重複したコミュニケーションを回避し、問題解決のためにチームがお互いを邪魔しないようにすることができます。インテリジェントトリアージは、機械学習を利用して以下のことを可能にします。

ビジネス全体で今現在何が起こっているかを見る 問題がローカルなものなのか、他に影響を与えるものなのかを理解する 適切なチームメイトを募り、協力して問題を解決する MTTRの改善

インシデントの再開

時には、インシデントが実際には解決されていないにもかかわらず、対応中に誤ってインシデントをクローズしてしまうことがあります。あるいは、インシデントが終了したと思って大規模なインシデントを解決済みにしたにもかかわらず、その後すぐにモニタリングやカスタマーサポートなどの他のチャネルを通じて、同じ原因に起因する進行中の症状に気づくこともあります。

大丈夫です、間違いは起こります。私たちは皆人間です。だからこそ、PagerDuty は新しいアラートをトリガーすることなく、応答者がインシデントを再開することができる新機能(アーリーアクセス可能)をリリースしました。このシンプルでありながら重要なアクションは、対応者の柔軟性を高め、インシデントの重複を減らし、重大なインシデントの症状が再発していることが判明した場合に、対応チームの再動員をより速く、より簡単にします。また、ServiceNowのような隣接するツールを同時再開することができます。

ランブックオートメーションのインテグレーション

もう1つの方法は、運用上の「ランブック」で取得した手動または部分的に自動化された手順をすべて自動化して、自動化されたインテリジェントなインシデント対応プロセスに接続することです。Amazon EventBridgeとの既存のインテグレーションに加え、ランブック自動化のために新しくリリースされたRundeck、Ayehu、およびPliantとのインテグレーションは、Amazon EventBridgeとの既存のインテグレーションに加えて、手動のITレスポンスプレイワークフローを自動化し、対応チーム内のコミュニケーションと解決スピードを向上させることができます。

Rundeck 統合のランブック自動化機能を使ったインシデント対応の例を見てみましょう。

「Eコマースビジネスのピーク時にサーバがダウンして、顧客がチェックアウトしたり、カートの中の商品を購入したりすることができなくなりました。PagerDutyはインシデントが発生したことを適切な人に警告しました」

さて、どうしますか。どのようにして対応者がインシデントを診断し、解決するための迅速な行動を取ることができるでしょうか。もし彼らが同僚や他のチームにエスカレーションしなければならない場合、あなたは時間をロスすることになります。wikiを閲覧したり、マニュアルのランブックを調べたりする場合も時間の無駄になります。

そうではなく、対応者が行動を起こすために必要な自動化されたオペレーション手順に安全にセルフサービスでアクセスできるようにしましょう。Rundeckによるランブックの自動化により、対応者の誰もが専門家と同じように診断や修理の手順を安全に実行できるようになり、インシデント時間をより短くし、より少ないエスカレーションで済むようになります。

RundeckとPagerDutyのインテグレーションにより、以下のことが可能になります。

PagerDutyのインシデントの開始時に自動的にRundeckジョブをトリガーする。例えば、最初の対応者がPagerDutyにログインする前に診断を開始したり、修理アクションを試したりする PagerDutyのWebやモバイルUIでカスタムアクションを使って、インシデント発生時にRundeckジョブをトリガーする Rundeckジョブが自動的にPagerDutyのインシデントノート/タイムラインを更新する Rundeckジョブが失敗した場合にPagerDutyインシデントをトリガーする

このシナリオでは、ランブックの自動化を利用することで、Eコマースビジネスはリソースをより効率的に展開し、MTTRを改善し、停止の結果として失われる収益を保護することができます。

インテリジェントな対応と自動化を実現

これらの新機能は作業の重複を減らし、機械による手作業の自動化を可能にすることで対応者の負担を軽減します。PagerDutyはチームに少ない労力でより多くのことを行う能力を与えることで、企業の回復力を向上させ、顧客との関係性と獲得した収益を保護することを支援します。

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

続きを読む
ベストプラクティス
2020年7月8日  (更新日:2022年6月10日)

PagerDutyの新機能:仕事のやり方、場所、愛するツールにフィット

by Vera Chen

2020年6月、リアルタイム性を高めるための製品のアップデートと機能強化を発表しました。

私たちは、ユーザーが外出先でのデジタル操作をより良く管理できるように、PagerDutyモバイルアプリのコア機能と美しさを強化することに引き続き注力しています。私たちは、ソフトウェア対応システムからのデジタルデータを利用して、あらゆる信号をリアルタイムの洞察と行動に変換する以上のことを目指しています。ネイティブインテグレーションのエコシステムを継続的に拡張して、チームが必要なときに必要な方法で作業し、対応できるようにすることで、それを実証します。

PagerDutyは、チームが必要な重要な情報とコンテキストを準備していることを確認することで、問題を未然に防ぎ、システムを最高のパフォーマンスで運用し続けることができます。

あなたが今いる場所で仕事をする

PagerDutyを使えば、チームはデスクトップからでもモバイルからでも、どこでもリアルタイムで仕事を管理することができます。インシデント対応者もビジネス関係者も、PagerDutyは認知の負荷を軽減し、重要な瞬間に素早く適切な行動を取れるようにすることを目的としています。

モバイルアプリのロック

PagerDutyでは、セキュリティを非常に真剣に考えており、PagerDutyのモバイルアプリにセキュリティの追加レイヤーを提供しました。ユーザーはアプリからログアウトすることなく、PINロックを有効にしてセッションを短縮できるようになりました。管理者は、ユーザーにPINまたは生体認証のロック解除を要求するように要求するセッションタイムアウトを設定することもできます。この機能がアクティブになると、ユーザーはPINを設定し、ログインし直すだけでPINをリセットできます。

インシデントアクションのメニューの変更

PagerDutyのモバイルアプリは、インシデントの詳細を管理し、伝達する方法を合理化します。ビジネスに影響を与える重要なインシデントが発生した場合、担当者はすぐに対応して解決する必要があります。インシデントアクションのメニューが更新されたことで、インシデントに関する重要なアクションを迅速に実行することが容易になりました。迅速な対応は、インシデントが顧客や収益に悪影響を及ぼす前に迅速に解決し、重要なサービスのダウンタイムを短縮します。

REST APIによるセルフサービスの拡張性

PagerDutyの開発者プラットフォームを介してアプリケーションにリアルタイムのアクションの追加が可能です。このプラットフォームを利用することで、小規模ビジネス向けのウィジェットや企業向けの自己回復製品など、開発者がアプリケーションにリアルタイムワークフローを簡単に構築することができます。

手動タスクを自動化し、より多くの人にリアルタイムワークフローを提供するために、PagerDuty REST APIも拡張していますので、サードパーティやカスタムツールとシームレスにインテグレーションすることができます。

アナリティクスAPI(アーリーアクセス)

アナリティクスAPIのアーリーアクセスが可能になりました。生のインシデントデータと関連するメトリクスを表示することができます。Analytics APIアーリーアクセスプログラムへの参加については、[email protected]までお問い合わせください。

ビジネスサービスAPI

公開されているビジネスサービスAPIやTerraformプロバイダを利用することで、チーム管理者はチームのビジネスサービスを定義したり、プライベートビジネスサービスを作成したり、テクノロジーの問題がビジネスにどのような影響を与えているかについて、全員が同じ言葉を使うことができるようになります。チームごとにビジネスサービスを定義することで、チームを横断した大規模なビジネス中断が発生した際に、誰もが理解できるサービスの全体像を構築することができます。

上はビジネスサービスAPIのデモで、ビジネスサービス作成の例を確認できます。ビジネスサービスAPIを使用してビジネスサービスを削除、取得、一覧表示、更新する方法です。

レスポンスプレイAPI

PagerDutyのレスポンスプレイで、あらかじめ主要なインシデントへの対応を計画しておけば、非常時でも簡単かつ正確、即座に行動することができます。レスポンスプレイは、次のことを有効にします。

大規模インシデントのための迅速かつ正確なマルチチームレスポンスの起動

関連する対応者と主要な利害関係者を特定し、積極的な対応計画を立てる

チャット、Web、モバイルアプリ、モニタリング、カスタムインテグレーションを介したインシデントへのチーム対応のコーディネート

組織全体の利害関係者がアクセス可能な、重大インシデント解決に関するステータスの更新

レスポンスプレイAPIの詳細はこちらで。

アプリイベントトランスフォーマー

PagerDutyとのインテグレーション機能がないツールをお使いでしょうか。イベントトランスフォーマーを使えば、独自のインテグレーションを素早く作成して、PagerDutyアカウント全体に展開することができます。イベントトランスフォーマーは、サーバレスのJavaScript(ES6)関数で、Event API v2標準イベントフォーマットでPagerDutyに送信されたwebhookペイロードを変換するために使用されます。すべてのイベントトランスフォーマーは、新しいアプリフレームワークの一部としてPagerDutyでホストされています。

PagerDutyアプリでのイベントトランスフォーマーの使い方についてはこちらをご覧ください。

愛用のツール:Jira ServerとData Center、Microsoft Teams

私たちはインテグレーションのエコシステムを拡大し続けており、新しいネイティブインテグレーションを追加しました。PagerDutyとJira Server、Data Centerとのインテグレーションは、複雑なワークフローを持つチーム間の同期とコラボレーションを促進します。さらに、PagerDutyは幅広い機能を持つチームの人々とチャネル(エンジニアリング、DevOps、ITOps、カスタマーサービス、マーケティングなど)を正しいインシデント解決プロセスとワークフローに接続し、PagerDutyとMicrosoft Teamsとのインテグレーションにより、リアルタイムのChatOpsを推進します。

PagerDuty+Jira ServerとData Centerのインテグレーション

リモートワークや外出先での作業を効率化する方法を学ぶ中で、日々使用するツールスタックを最適化することにますます注目が集まっています。PagerDuty+Jira Server and Data Centerのインテグレーションにより、以下のことが可能になります。

複数のJiraとPagerDutyアカウントを接続して、組織のスケーリングに合わせて変化させることができます

JiraのIssueサイドバーから強化されたPagerDutyアクションを実行し、PagerDutyを通じてリアルタイムのインシデント対応を促進します

高度なワークフロールールを使用して、Jiraでより多くのことを自動化し、ダウンタイムと停止を減らします

JiraとPagerDutyアカウント間のユーザーを双方向のユーザーマッピングでリンクし、インシデント対応をより良く、より包括的に理解することができます

Video

詳細については以下をご覧ください。

上のPagerDuty+Jira ServerとDate Centerのインテグレーションハウツービデオ

PagerDuty+Jira ServerとData Centerのインテグレーションガイド

Blog:Jira ServerとData Centerのための新しいインテグレーションで、より多くの仕事が可能に

PagerDuty+Microsoft Teamsのインテグレーション

分散型やリモートワークへのシフトの増加により、多くの企業やユーザーが日々の業務を共同作業や管理するためにMicrosoft Teamsに依存するようになってきました。PagerDutyはMicrosoft Teamsとのインテグレーションで、デスクにいてもモバイルデバイスを使った外出先でも、リアルタイムのChatOpsを推進し、どこにいても仕事ができるようにします。Teamsのインテグレーションを有効にすると、以下が可能になります。

Teams内での受任、解決、メモの追加により、重要な対応行動を自動化し、アプリ間の切り替えの必要性を軽減します

グラフやランブック、サードパーティ製ツールへのリンクなど、インシデントの詳細を表示し、より詳細な状況を把握することで、解決までの時間を短縮し、ビジネスへの全体的な影響を軽減します

サービスをチームのチャンネルに接続して、ユーザーとチームのつながりを維持します

下記のPagerDuty Microsoft Teamsの概要でインテグレーションの動作を見ることができます。

video>>>

What’s New: PagerDuty Fits the Way You Work, Where You Are, and With the Tools You Love! | PagerDuty

また、すぐに始めたい方は、下記のPagerDuty Microsoft Teamsインテグレーションのハウツービデオをご覧になることもできます。

video>>>

What’s New: PagerDuty Fits the Way You Work, Where You Are, and With the Tools You Love! | PagerDuty

詳細については、以下をチェックしてください。

PagerDuty+Microsoft Teamsインテグレーションページ

PagerDutyとMicrosoft Teamsのインテグレーションの概要

PagerDuty+Microsoft Teamsインテグレーションガイド

上のPagerDuty Microsoft Teamsハウツービデオを見て、インテグレーションを開始し、インストール、設定、テストを行う

ブログ:PagerDutyとMicrosoft TeamsでリアルタイムのChatOpsの推進

2020年6月のアップデートと機能強化による新機能の利用を開始するには、ナレッジベース、プラットフォームリリースノート、モバイルリリースノートを確認してください。

続きを読む
ニュース&告知
2020年7月8日  (更新日:2022年3月8日)

インシデント対応から得た分散型コミュニケーションの教訓

新型コロナウイルス(COVID-19)の報告例が世界中で増加し続けていることから、多くの企業では、従業員の感染を最小限に抑える方法として、リモートワークへのシフトが進んでいます。しかし、多くの企業は現在、業務を完全なリモートワークに移行するためにはどうすればよいのか、悩んでいるのが現状です。

企業が急速に分散型組織への移行を考えようとしている中、インシデント対応のパターンを見ることで、数多くの教訓を得ることができます。

リモートワークへの移行

企業がますますリモートワークを採用するようになってきている中で、ITとエンジニアリング職はこの変化の先頭に立ってきました。

20年前は、エンジニアリングチームが物理的に同じ場所にいて、オンプレミスのサーバルームで本番アプリケーションを実行し、プライベートなイントラネットですべての作業を行うのが一般的でした。IT チームとエンジニアリングチームは現場にいて、運用チームがサーバールームにクラッシュカートを走らせるころ、開発チームとマネージャーは、インシデント対応のための作戦室である会議室に集まり始めていました。重大なインシデントが発生した場合、マネージャーがネクステル社の携帯電話を使って、その日外出していたエンジニアに無線で連絡を取り、トラブルシューティングを支援できるようにVPN接続を指示することもありました。

この10年間で、クラウド環境とアプリケーションを使用するようになったことで、世界中のどこからでも本番用アプリケーションにアクセスできるようになりました。今日では、これらのチームが分散して活動することが一般的になっています。その結果、ITとエンジニアリングチームは、リモートで作業する際の効果的な方法を開発する最前線に立っています。

オンサイトサーバ、イントラネット、物理的なインシデント対策室の時代は、多くの組織では一般的に、より近代的なソリューションに取って代わられてきています。これらのソリューションとワークフローがどのように組み合わされているかを検証することは、分散型ワークへのシフトをどのように行うべきか悩んでいる組織に役立つでしょう。

10年間のリアルタイム運用管理の教訓

PagerDutyは10年以上にわたり、何千もの組織がリアルタイムのオペレーションを管理するのを支援してきました。私たちの生活は、デジタルファーストの体験にますます接続されるようになり、世界は常にオンになっていることを意味します。顧客は完璧さを求めており、問題が発生したときの解決までの時間は、数時間ではなく、ほんの数秒しかありません。リアルタイムオペレーションを効果的に管理することは、1秒1秒が重要な時に、適切な人員が適切なタイミングで対応し、コミュニケーションを調整することです。これは、世界中のどこにいようとも、すべてのチームやチームメンバー、部門、リーダーがリアルタイムで起こっているアクションに関与し、情報を得て、連携することを確実にすることを意味します。

PagerDutyは、インシデント対応のリーダーとして広く認識されています。そこで私たちは、リモートチームのための効果的なコミュニケーションを管理する方法について、私たちが教えることができる教訓を見てみることから始めるのが当然のことだと考えました。PagerDutyでは、私たちのチームがどこにいても、リアルタイムの仕事を効果的に管理するために、私たち自身のプラットフォームだけでなく、他のいくつかのリモート生産性ツール(PagerDutyではSlackとZoomを使用しています)を利用して、発生したインシデントに対応しています。

大規模なインシデントが発生した場合、当社の社員はPagerDutyのプラットフォームを使用して、解決に向けて作業を進める際に必要に応じて、様々なチームにまたがって適切なその分野の専門家に連絡を取ることができるようにしています。物理的な作戦室は、ビデオ会議ブリッジ(必要に応じて、バックアップの電話回線があります)と、すべての重要なコミュニケーションをキャプチャする専用のチャットルームの組み合わせに置き換えられました。

リモートで仕事をする際には、いくつかのコミュニケーション方法が鍵となります。

インフォーマルなコミュニケーションチャネルは、フォーマルなコミュニケーションチャネルに置き換えるべきです 口頭での説明に頼るのではなく、知識を書き留めて記録すべきです 必要に応じて情報を制限するのではなく、内部で情報を共有しましょう

インシデントが発生した際には、その場しのぎの通信チャネルを持つのではなく、私たちのチームは、よく知られた明文化された通信チャネルを使用します。インシデントが発生し彼らの参加が要求されたとき、彼らはすでにどの通信チャネルに参加すべきかを知っているはずです。しかし、万が一に備えて、PagerDutyプラットフォームは、ワンクリックでそれらのチャネルに参加するためのリンクが埋め込まれた通知を送信します。

インシデントの管理は、速いペースで行われるストレスの多い仕事です。その作業を調整するために必要なコミュニケーションの多くは、ビデオ会議で口頭で行われます。しかし、知識を確実に書き留めて記録するために、すべてのインシデントコールには、重要な事実と取られたアクションを記録し、対処すべきフォローアップ項目を追跡することで、インシデント中の重要なイベントのタイムラインを作成する記録係が割り当てられています。当社のビデオ会議ソリューションでは、通話の自動テープ起こしを作成することができます。しかし、記録係によって作成されたメモは、発生した出来事を迅速に把握したい場合の参考資料として活用することができます。

記録係は、専用のチャットチャネルでタイムラインを記録します。そうすることで、他の対応者は(対応者として、またはオブザーバーとして)参加したときに、タイムラインを参照して見逃したことをすぐにキャッチアップすることができます。オブザーバーは、状況をよりよく理解したい場合は、専用のチャットチャネルやビデオ通話(聴取専用モード)に参加することをお勧めします。

インシデントが発生している間、当社のチームは通常、社内外の利害関係者に更新情報を送信し、最新のイベントを知らせます。内部の利害関係者には経営幹部、ビジネスオーナー、顧客対応チームなどが含まれ、外部の利害関係者には顧客が含まれます。これらの通知はPagerDutyプラットフォームによって管理されています。しかし、その通知を送信するまでの意思決定は、何を伝えるかの合意を含めて、記録係のタイムラインの一部として記録され、専用のチャットチャネルにも記録されます。

このように口頭でのコミュニケーションと記録されたコミュニケーションのバランスが取れているため、分散したチームが迅速に作業し、より広い組織に効果的にコミュニケーションを取ることができます。記録係のタイムラインを専用のチャットチャネルに記録することで、既存のPagerDutyとのインテグレーション機能を使用して、インシデント後のレビューに自動的に組み込むことができるようになります。

ここでは、インシデントの解決に至るまでの出来事を要約し、原因となった要因を特定し、将来的にこの種のインシデントを軽減するのに役立つであろう 合意された行動項目を文書化しています。これらの事後検証は社内で共有され、物理的な場所に関係なく、どのチームでもイベントをよりよく理解できるようになります。

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

続きを読む
ベストプラクティス
2020年6月30日  (更新日:2022年3月10日)    |    インテグレーション&ガイド

Elixir at PagerDuty:ステートフルサービスによる処理の高速化

PagerDuty の核となる部分の1つは、ユーザーにインシデント通知を送信することです。しかし、ただの通知ではなく適切なタイミングでの適切な通知である必要があり、すでにインシデントに対処しようとしているときにスマホをスパムマシン化させないようにする必要があります。2018年にはElixirを使って、PagerDutyの通知をすべてスケジュールするサービスを書き換えました。

この記事では、通知がどのように機能するのか、また、書き換えを成功させるためにErlang VM(別名BEAM)とElixirをどのように活用したのかを見てみましょう。

古代の歴史

当初は、すべての通知はモノリシックなRailsアプリから直接送られていました。

2014年には、スケジューリング動作がScalaの新しいサービスに実装されました。Artemisです。当時のArtemisは斬新なもので、同期、マルチリージョン、永続的なキューを実現するために自作のCassandraでバックアップされたWorkQueueライブラリを使用していました(当時のKafkaはこれらのボックスをすべてチェックしていたわけではありません)。

この抽象概念の上にあるArtemisは事実上ステートレスでした。キューをポーリングし、作業アイテムをロックし、作業を行い、ロックを解除し、忘れます。このきめ細かいロックは効果的で、どこにいてもアイテムの作業ができ、関係のない作業アイテムを同時に実行することができます。

最近の歴史

私たちは、システムのブラックボックスの動作(すなわち、その入力と出力)を見直し、Artemisの複雑さとインフラコストと対比させました。何かをしなければなりませんでした。私たちは、マイナーな改善作業か、大規模な改修か、あるいは完全な書き換えを行うかを検討しました。

完全書き換えの危険性を慎重に検討した結果、リスクを上回るメリットがあると判断し、進めることにしました。これは通常、リスクの高い提案と考えられていますが、Scala、WorkQueue、Cassandraの使用を止めたかったので、この状況ではうまくいきました。当社のエンジニアは、これらの技術が組織内で人気を失っていくにつれて(また、オリジナルのコード作成者が去っていくにつれて)、これらの技術に馴染みが薄くなってきていました。

Cassandraの3つのアンチパターンは以下の通りです。

Cassandraをキューとして使用しない インターネットで同期レプリケーションはしない 非常に広い列は、Cassandraの水平方向のスケーリングをブロックする

私たちは3つすべてをやっていました。新しい技術スタックを使用し、基礎となるデータモデルを完全に変更しようとしていたので、完全な書き換えはより意味がありました。

当時、PagerDutyは新しいサービスのためにElixirを使い始めていました。ElixirはErlang VM(BEAM)上で動作するコンパイル言語で、ScalaがJVMにコンパイルするのとよく似ています。Elixir/Erlangランタイムは、独立した軽量なプロセスからなる全く異なるパラダイムをもたらします(1つのVMで10万個のプロセスは普通です)。Erlangは数値計算や共有メモリ計算にはあまり向いていませんが、非同期に行わなければならい多くのことがある場合には優れています。

通知スケジューリングの仕組み

PagerDuty では、カスタムのコンタクトメソッドと、それらのコンタクトメソッドをいつ使用するかを示す通知ルールを設定することができます。例えば、以下のようなものです。

携帯電話番号を追加する インシデントが割り当てられたときにすぐに電話をかける通知ルールを追加する インシデントがあなたに割り当てられてから5分後に電話をかける通知ルールを追加する(インシデントがまだ開いていて、あなたに割り当てられていて、それを受任していない場合)

同じ電話番号でも、連絡方法が異なる(例えば、「電話 555-555-0123」と「SMS 555-555-0123」は別)ため、それぞれの連絡方法は別々に扱われます。緊急度の低いインシデントと緊急度の高いインシデントが混在することもありません。情報通知(「私が担当しているインシデントがエスカレーション、受任、解決されたらすぐに教えてください」)はこれらのルールと相互作用しますが、この例では関係ありません。

例えば、インシデント#1があなたに割り当てられたとします。あなたに知らせるために電話をしてみますが、あなたは出ないかもしれません。数秒後、別のインシデント(#2)があなたに割り当てられたとします。私たちはあなたに電話をかけたばかりなので、すぐにはそれを通知しません。私たちはこの動作を「ペーシング」と呼んでいます。これは、あなたがインシデントを解決しようとしているときに邪魔をしないためです。

ペーシングの間隔が切れたら、インシデント#2と、あなたがまだインシデント#1に割り当てられているという事実をお伝えします。あなたがその時も電話に出なかったとしましょう(シャワーを浴びていたのかもしれません)。

5分後、次の通知ルールが適用されます。しかし今回は、インシデント#1については今すぐに、インシデント#2については数秒後に通知する必要があることに気づきました。今回は、あなたに一度だけ電話をして、積極的に両方のことを伝えることにします。この動作を「バンドル化」と呼んでいます。

もしインシデントのどちらかが誰かに受任されたか、または解決された場合、私たちはそれらについてあなたに伝え続けることはありません。

まとめ:ハンドリングされていないインシデントについて連絡する間隔を管理するルールがあります。私たちは、合理的な範囲でできるだけ少ない通知を送るようにしながら、その都度発生しているすべてのことをお知らせするようにしています。

通知スケジューリングサービス

Notification Scheduling Service(別名NSS)を入力してください。この問題の美しいところは、それ自体が並列化に適しているということです。PagerDuty の各ユーザーへの通知は、お互いに全く相互作用しません。各ユーザーは島です。各ユーザーの小さな島の中にあっても、個々の連絡方法(例えば、「緊急度の高いインシデントの場合は+1-555-555-0123に電話してください」と「緊急度の低いインシデントの場合はMarvinDroidにプッシュ通知してください」)は、「このインシデントに割り当てられたユーザー」を各ユーザーのルールに従った連絡方法にマッピングする場合を除いて、他のユーザーとは相互作用しません。

私たちは各ユーザーをErlangプロセスとしてモデル化し、関連するUserChannelsを管理しています(これもErlangプロセスとしてモデル化されています)。これにより、新しい情報を素早く取り込むことができます(各インシデントの時間ルールごとに未来の日付の通知トリガーをキューに積みます)が、各UserChannelは自分のペースで状態を進化させることができます。インシデント#1についてユーザーAに伝える必要があることを知ると、ユーザーAのユーザープロセスにメッセージを送信します。そのユーザープロセスはユーザーの通知ルールを参照し、関連するすべてのUserChannelに、このインシデントについていつユーザーに知らせるべきかを伝えるメッセージを送信します。

NotificationBundlesはNSSの第二段階でピックアップされ、あなたに送信する実際の通知内容を決定します。これには少し時間がかかりますが、これらのNotificationBundlesはすべて別々の連絡方法とユーザーに送信されるので、作業を並列化することができます。

PagerDutyは小さなシステムではありませんが、コンピュータ用語では、我々が扱うオープンインシデントの数は「ビッグデータ」ではありません。私たちは、この関連する状態のすべてをメモリに保存しているので、より速く行動できるようになっています。これは、状態のないArtemisのシステムとは正反対です。各ユーザーを Kafka パーティションに関連付け、与えられたパーティションを処理する NSS のインスタンスが最大でも1つ(通常は正確に1つ)あることを保証します。これにより、User と関連する UserChannels がシステム内でsingletonになるのは簡単です。粒度の粗いパーティションロックを使えば、プロセスが小さな作業をしようとするたびに同期をとる必要がなくなります。現在データを処理している部分を除いて、その特定のデータの変更を担当するシステムの部分はありません。ユーザーとUserChannelは、状態の変更とともにidempotency メタデータを維持し、クラッシュの回復や定期的なソフトウェアのデプロイを可能にします。

各ユーザーに独立したパーティションを与えるのは素晴らしいことですが、Kafka はパーティションの数に比較的制限があります(クラスタあたり約 50k)。その代わりに、Kafka駆動のアプリケーションでは通常のように、トラフィックをパーティションに分割します。異なるライフサイクルを持つ異なる種類のデータがあるため、「並列パーティション」を持つ複数のトピックを使用することになりました。これらのトピック間のメッセージは同期する必要はありませんが、特定のユーザーのすべてのトラフィックが同じパーティションセットに表示されるようにすることでメリットがあります。この例では、3 種類の受信メッセージがあります。

インシデントの割り当て、状態の更新 ユーザーの連絡方法と通知ルールの更新 下流システムからのフィードバック(例:「この電話は完了しました」など)

システム内のパーティションごとにパーティションオーナーを実行して、そのパーティションから3つのトピックを同時にconsumeする(例えばパーティション1のパーティションオーナーは、インシデント更新トピックのパーティション1、通知ルールトピックのパーティション1、制御メッセージのパーティション1のデータをconsumeして処理するように調整する)。

下の図では、ユーザーAとBのデータはすべてパーティション番号1のみで終了し、ユーザーCとDのデータはすべてパーティション番号2のみで終了します。

変更の成果

NSSが状態を維持することで、すべての実行中の作業を高速にアクセスできるメモリに保持することができます。ロックはパーティションレベルでのみ発生し、作業のピースごとに細かくロックするオーバーヘッドを回避します。独立した動作を管理するために軽量プロセスを使用することで、順序が重要なところでは一度に1つのことに集中し、順序が重要でないところではシステムが同時に多くのことを行うことができるようになります。この新しいインフラは、サイズは(計算とデータストレージの点で)10分の1、ラグタイムは半分、スループットは10倍です(追加の水平方向のスケーリングのための余地は十分にあります)。2019年1月以来、私たちは通知トラフィックの100%をそれを介して実行しています。

この記事は、私たちが何をしたのか、そしてElixirで何が可能なのかの表面をかいつまんだだけです。このような背景を踏まえて、第2弾をお届けしたいと思っています。

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

2020年6月30日  (更新日:2022年3月9日)    |    ニュース&告知

積極的なインシデント対応で障害を未然に防ぐ

もし各種業務とその依存関係を俯瞰的に把握し、インシデントや障害が起こりそうな指標を見極める能力を持っていたら、あなたの日常生活にどのような影響を与えるでしょうか。想定外の事態に対応するのではなく、混乱に先手を打つために数分、数時間の猶予が与えられたら、ビジネスにとってどのような意味があるのでしょうか。企業にとって、プロアクティブ(積極的)なインシデント対応を可能にすることは、費用の節約、ブランドの評判の保護、対応チームの燃え尽きを減らすことに直結します。

プロアクティブであるということは、技術スタッフとビジネススタッフの両方に、デジタルサービスの方向性を示すのに必要なツールを提供することを意味し、問題が発生した場合に、無知の状態からスタートしないようにします。一刻を争うデジタルの世界では、オンコール対応者は、インフラや対応手順をその場で学ぶことはできません。だからこそ、デジタル対応の心構え、準備が非常に重要なのです。

そして、それは遠い夢のように思われていたかもしれませんが、プロアクティブなインシデント管理はもはや単なるおとぎ話ではありません。2020年春発表のPagerDutyの最新の機能強化では、すべてのチームにまたがるデジタルサービス、依存関係、ハイパーケアを提供し、問題が収益に影響を与える前に対処するのに必要な運用上の指標を得ることができます。PagerDutyがどのようにそれを可能にするか見てみましょう。

イノベーションを掘り下げる

ダイナミックサービスディレクトリ内のサービスプロファイル

昨年秋、当社はすべてのサービスを1カ所で追跡して管理する方法として、Dynamic Service Directoryを導入しました。このディレクトリを構築したのは、IT技術スタックの複雑さと変化の速さが増しているため、従来の作業方法、つまりコンポーネントを追跡するための集中化された手動のアプローチでは、クラウドネイティブの世界では拡張性がないからです。

別のチームによる発見とマッピングを含む、時間のかかる手動のアプローチの代わりに、PagerDutyのDynamic Service Directoryは、プラットフォームの定期的な使用を通じて収集されたサービス情報を提示します。ディレクトリは自動化を可能にする豊富なAPIを持っているだけでなく、中央集権ではなくチームベースでもあります。

回答者が利用できる情報量を増やすために、Service Profileと呼ばれるDynamic Service Directoryの新しい機能強化をリリースしました。Service Profileは、各サービスの周りに情報アーキテクチャを作成することで、サービスに意味とコンテキストをもたらします。これにより、エンジニアリングマネージャーとオンコール対応者は、チームの所有権、オンコール対応者、過去のアラートやインシデント、依存するサービス、ランブック、優先する通信チャネルなどの各サービスの情報を確認することができます。

サービス依存関係

組織の規模が大きくなるにつれて、複雑で横断的な大規模インシデントを解明したり、インフラがどのように接続されているかを理解することが難しくなり、潜在的な脆弱性につながる可能性があります。また、チームが最善の努力をしても、手動で管理されたWikiや静的なCMDB(構成管理データベース)では、依存関係の状態についての視点が限られています(時代遅れとまではいかないまでも)。

だからこそ、PagerDuty に Service Dependencies(サービスの依存関係)を導入しました。Service Dependencies は、問題の特定、トリアージ、修正を迅速に行うために、サービス間の関係を理解することを可能にします。ユーザーは直感的なユーザーインターフェイスを介して複数のサービスと依存関係のレベルをナビゲートし、誰がいつサービスを変更したかなどの重要な情報を公開することができます。Service Dependencies は対処の自動化を推進し、脆弱性に関する貴重な洞察を平時に提供し、組織が独自のインフラについて持っているメンタルモデルと一致させることができます。

サービスダッシュボード

従来型のIT組織では、エンジニアリングチームがインシデントがサービスにどのような影響を与えるかを認識していなかったり、不確かであったりすることは珍しくありません。このような理解がなければ、ビジネス関係者の期待に先手を打ったり、チームを改善に集中させることができません。

エンジニアリングチームがこの問題を克服するために、新たに提供されたサービスダッシュボードでは、運用上のメトリクスと KPI を可視化して、部門間の連携とビジネス成果の向上を実現します。この一元化された表示により、サービスの構築者と運用者は、製品の可用性、リソース配分をより効果的に管理し、チームとサービスの継続的な改善を推進するために協力し合うことができます。

新しいビジビリティコンソール

現在、多くのお客様がワークフローを物理的な目に見えるネットワークオペレーションセンター(NOC)から仮想環境に移行し、NOCオペレーターが自宅で作業する必要性を感じています。しかし、これらのオペレーターは、サービスパフォーマンスの統合されたビューをまだ必要としています。

PagerDutyのVisibility Consoleは、アーリーアクセスとしてユーザーにデジタルオペレーションのリアルタイムビューを提供します。改訂され適応されたエクスペリエンスには、高度なフィルタリングとカスタマイズ可能なレイアウトも含まれています。この強力なコンソールは、運用の準備を促進するだけでなく、ハイブリッド運用組織のNOCとアプリケーションチーム間のギャップを埋めるのにも役立ちます。最も重要なことは、このツールにより、チームはインシデント対応に積極的なアプローチを取ることができ、ハイパーケアの瞬間に顧客のニーズを満たすために必要なコンテキストを提供することができるようになります。

プロアクティブなインシデント対応を行うためには、インシデントが発生したときに対応できるように、チームが管理しているワークフロー、自動化、サービスに関する情報を持っている必要があります。現在の経済環境では、コスト削減、顧客との関係の維持、企業の回復力の確保という点で、このアプローチがもたらす影響を過小評価すべきではありません。

これらの新機能は、プロアクティブなインシデント対応を実現するために PagerDuty を使用する多くの方法のほんの一例です。もしあなたの企業にとってこれらのツールのどれかが有効だと思われたなら、無料トライアルを試してみるか、当社までご連絡ください。

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

2020年6月23日  (更新日:2022年3月10日)    |    インテグレーション&ガイド

PagerDutyとMicrosoft Teamsを使ったリアルタイムChatOps

7500万人以上のアクティブユーザーがいるMicrosoft Teamsは、多くのグローバルビジネスに欠かせない存在であると言っても過言ではありません。さらに、MicrosoftのCEO Satya Nadella氏は最近、Microsoftが5月1日に2億人の会議参加者を記録したことを明らかにしました。Microsoft Teamsの爆発的な成長は、最近のリモートワークの急増と関連していますが、それ以前にも多くの企業は長い間、世界中の人々をつなぐためにTeamsを利用してきました。

ご存知でない方もいらっしゃるかもしれませんが、Microsoft Teamsはコラボレーションハブであり、従業員はチャット、ビデオ会議を介した接続、SharePoint、Word、PowerPoint、Excelなどの一般的なMicrosoftツールを介したコラボレーションをすべてリアルタイムで行うことができます。これらのMicrosoftツールを使用してコラボレーションする機能は、PagerDutyのユーザーがChatOpsを駆動するためにTeamsを使用する主な理由の1つです。

PagerDutyのユーザーは、会社全体でリアルタイムのオペレーションを推進するために、Microsoft Teamsとのインテグレーションを使用することができます。チームが PagerDuty のデジタルオペレーションのためのプラットフォームと Microsoft Teams のコラボレーションハブを組み合わせると、強力な ChatOps 機能を備えた真のリアルタイムオペレーションを可能にするテクノロジースタックになります。

どこにいても仕事ができる

多くのPagerDutyユーザーにとって、Microsoft Teamsは我々のプラットフォームの第3のインターフェイスとなり、ユーザーはデスクトップやモバイルのインターフェイスと同じようにリアルタイムの操作を行うことができるようになります。

PagerDutyのインテグレーションにより、Microsoft Teamsのインターフェイスから重要なインシデントの詳細を表示することができますが、それはほんの始まりに過ぎません。ユーザーはTeams内で重要なインシデントアクションを実行することもできます。これには、インシデントの受任と解決、メモの追加、さらにはTeams内で直接新しいインシデントをトリガーすることも含まれます。また、サービスをTeamsのチャンネルに直接接続して、全員が同期してつながりを保つこともできます。

PagerDutyとMicrosoft TeamsでHybridOpsを強化する

今日の組織は、エンジニアリング、DevOps、IT運用、カスタマーサービス、マーケティングなど、様々な機能を持つチームで構成されています。PagerDutyユーザーがMicrosoft Teamsインテグレーションを使用している場合、日常業務の間も、何か問題が発生したときも、共有データを使用することでチームが連携して作業を続けることができます。あなたがどのようなチームにいても、PagerDutyは、それぞれの担当者とチャネルを正しいインシデント解決プロセスとワークフローに接続することができます。ユーザーは、運用モデルや機能に関係なく、共通のメトリクスを使用して、業務を段階的かつ継続的に改善することができます。

Microsoft Teamsでデータと人をつなぐ

分散化したチームでは、各個人がどこにいても重要なドキュメントにアクセスする必要がありますが、Microsoft Teamsでは、リモートオフィスを含むどこにいてもコラボレーションが可能です。Microsoft Teamsでは、Word文書やPowerPoint、Excelファイルへのアクセス、共有、編集が可能です。これにビデオ会議やチャット機能を組み合わせることで、Teamsのユーザーは自分に最適な方法でコラボレーションを行うことができます。

TeamsのワンストップコラボレーションプラットフォームをPagerDutyに接続すると、最適なデータセットとインシデントコンテキストを使用して、リアルタイムでインシデントに対応できるようになります。

Teamsからのインシデント受任、解決、メモ

PagerDutyのお客様の中で、すでにTeamsを利用している方と話をした結果、ユーザーがアプリ間の切り替えをしないようにすることが、私たちが提供できる最も求められている機能の1つであることは明らかでした。私たちは、このような「今いる場所で仕事をする」機能を新しいインテグレーションで実現しました。

インシデントが発生したとき、対応者はほとんどの場合、何かの最中です。その「何か」とは、ほとんどの場合チームメンバーとMicrosoft Teamsによるコミュニケーションです。PagerDuty for Teams とのインテグレーションにより、ユーザーは PagerDuty で何もしなくても、Teams UI から直接インシデントを受任したり、解決したりすることができます。すべてが同期されます。また、Teams からその場でメモを追加して、全員が最新の情報を入手できるようにすることもできます。

簡単設定でフレキシブル

PagerDuty for Microsoft Teams を使い始めるのは簡単で、Microsoft Teams 用の PagerDuty アプリは、Microsoft Teams マーケットプレイスのアプリストアからインストールできます。一度インストールしてしまえば、PagerDuty サービスを Teams のチャンネルに簡単に接続することができ、各ユーザーとチームのつながりを維持することができます。

一度接続すると、PagerDutyの設定ページにはPagerDutyとTeamsの接続が表示され、ニーズの変化に合わせて簡単に接続したり外したりすることができます。さらに、アプリのコマンドを使って簡単に Teams チャネルにサービスを接続できます。

PagerDuty for Microsoft Teamsを使い始める準備はできていますか? Microsoft ストアで探してください。また、インテグレーションについての詳細はこちらをご覧ください。

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

2020年6月16日  (更新日:2022年3月10日)    |    インテグレーション&ガイド

Jira ServerとJira Data Centerとのインテグレーションでリモートワーク

このブログを読んでいる人の多くは、自宅、どこかのリモートオフィス、家族の家、あるいはZoomの背景が本物ならば宇宙船ミレニアム・ファルコンのコックピットから読んでいるかもしれません。私たちは皆、上手に「今いる場所で仕事する」方法を学ぼうとしていますが、それには毎日使うツールスタックを最適化することも含まれます。Atlassian の Jira Server と Data Center 製品を利用している PagerDuty ユーザーのために、我々はユーザーがリアルタイムで仕事をし「今の場所で仕事をする」ことができるように、いくつかの変更を行いました。

Jira Server と Jira Data Center との強化されたインテグレーション機能を一般公開します。このインテグレーションには、ユーザーが PagerDuty サイドバーを使用して Jira の課題からインシデント対応を調整できるようにする機能が含まれています。また、複雑なワークフローを持つチーム間の同期とコラボレーションを推進し、PagerDuty と Jira Server と Data Center 間でユーザーとアカウントをマッピングすることができます。最も人気のある PagerDuty 統合の1つとして、ユーザーの皆様からのフィードバックに基づいて開発された新機能です。

もちろん、これらの機能を表示しないようにしたい場合は、非表示にすることもできます。

高度なワークフロールールを使用してJira でより多くのことを自動化する

デジタルビジネスを成功させるためには、デジタルサービスが完璧に稼働していなければなりません。PagerDuty のリアルタイムオペレーションプラットフォームは、主要なワークフローを自動化することで、ダウンタイムの削減を実現します。PagerDuty は、これらの高度なワークフローを Jira とのインテグレーションに追加しました。Jira ServerとData Centerのお客様は、複雑なワークフローを動かす高度なルール設定を Jira インターフェイスから使用できるようになりました。Jira ユーザーは、ビジネスを実行するために必要な正確なワークフローを使って、リアルタイムのオペレーションを推進することができます。

双方向ユーザーマッピング

フィードバックに基づいて、ユーザーマッピングも追加したので、Jira と PagerDuty のアカウントをリンクして、チームメンバーがどのようにインシデントに対応したかを完全に把握することができるようになりました。ユーザーマッピングでは、PagerDuty のきめ細かいパーミッションを PagerDuty アプリで使用することができます。また、すべての変更が毎回リアルタイムで行われるように、フォールバックユーザーとのミスコミュニケーションを防ぐことができます。

マルチアカウントサポート

チームが成長し、高度に分散化するにつれ、Jira ユーザーを個別のアカウントに対応させることが現実的な問題となります。チームと対応者が全員同じページにいて、漏れがないようにするために、複数の Jira インスタンスを PagerDuty にマップする機能を追加しました。また、複数の PagerDuty アカウントを Jira にマッピングすることもできます。最新のインテグレーションにより、あなたのエンタープライズビジネスは生産性を妨げることなく、グローバルに拡大する準備ができています。

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

2020年6月9日  (更新日:2022年11月18日)    |    ニュース&告知

PagerDutyの新機能:関連インシデント、ビジネスレスポンス、モバイルステータスダッシュボード、新しいインテグレーション

by Alex Ware

常時オンの世界では、デジタル運用を管理するための積極的で予防的なアプローチが必要です。PagerDuty は、システムの健全性をひと目で把握できる要約を提供することで、効率の良いリモート修復を支援する最新リリースを発表しました。

PagerDutyはオンコール管理とインシデント対応機能で知られていますが、インシデントのビジネスへの影響を可視化できるなど、他にも機能があります。これらすべてが一体となって、チーム内の効率化を促進し、重要な問題の管理とトラブルシューティングのコストを削減します。また、新たに開発されたブランドメッセージングを用いて、利害関係者にリアルタイムで情報を提供しながら、統一的なビジネス対応をサポートします。

根本原因分析に役立つ関連インシデント

新たに開始された関連インシデント機能により、ユーザーは重要なアプリやサービスをリアルタイムで可視化し、すべてを1カ所で把握することができます。関連インシデントは機械学習を利用しており、他のサービスで現在どのようなインシデントが発生しているかを表示します。この機能は、イベントインテリジェンスを使用して、複数のチームに影響を与えるインシデントのトリアージ時間を短縮するのに役立ちます。また、重複したコミュニケーションを減らし、障害の全体的な範囲を理解し、問題解決のためにお互いに干渉しないようにします。関連インシデントでは以下のことができます。

他のサービスで同時に発生しているインシデントの中で、関連する可能性のあるものを表示する

リアルタイムの機械学習アルゴリズムを適用するイベントインテリジェンスを使用して、サービス全体のアラートと人間の対応行動を解析、ベクトル化、クラスタ化し、関連するインシデントの提案を行う

「いいね」投票をしたり、サービス間でインシデントをマージしたりすることで機械学習を訓練する

Salesforce V2インテグレーション

PagerDuty Summit 2019では、開発チームとカスタマーサービスチームの連携を強化するために、PagerDuty内のインシデントをSalesforce Support CloudのケースにリンクさせるSalesforce Service Cloudとのインテグレーションをリリースしました。Salesforce V2 のインテグレーションにより、Marketing Cloud、Commerce Cloud、Quip などの Salesforce オファリングのサポートが追加されたため、以下のようなことが可能になりました。

顧客の問題、販売機会、その他の活動に関する対応とアクションを組織全体でオーケストレーションする

PagerDuty の更新(Acknowledge、Resolve、Reassign など)があるとすぐに、関連情報を含む Salesforce オブジェクトを作成したり、更新したりする

Salesforce Cloudのインターフェイス内から、インシデントの優先順位を設定したり、レスポンスプレイを実行したり、インシデントを再割り当てしたりする

任意の Salesforce Cloud 標準オブジェクトとのインテグレーション

ビジネスレスポンスブランディング

多くの企業は重要な情報やコミュニケーションのためのブランドガイドラインを持っています。PagerDutyはビジネスブランドガイドラインをリリースしました。これにより、情報を受信した対応者はそれが経営陣からのものであることを知ることができ、ビジネス関係者やエンジニアはクリティカルな事態の間でも企業ガイドラインを遵守することができます。会社のプロセスを遵守し、メッセージングの信頼性を高めるために、ステータス更新メールに会社のロゴを含めることができます。

モバイルステータスダッシュボード

モバイルステータスダッシュボードでは、エグゼクティブや管理職向けのステータスダッシュボードにコンシューマーユーザーエクスペリエンスの状況を組み込み、スマートフォンやiPadからビジネスシステムのステータスを簡単に表示できるようにしました。

モバイルステータスページでは、技術的な知識を持たないビジネスユーザーに重要な障害のステータスを知らせ、すべてのビジネス関係者がアクセスレベルに関係なく、モバイルアプリで主要なビジネスサービスの状態を確認できます。この機能は、ほとんどの iOS および Android デバイスで利用できます。

ライブコールルーティングのためのカスタム呼び出し

ライブコールルーティングは、顧客から掛かってきた電話やボイスメールをオンコールの対応者に転送することで、カスタマーサポートを充実させることができます。この機能を使うと、専用の電話番号(ローカルまたはフリーダイヤル)が提供され、その番号への着信やボイスメールをPagerDutyのオンコール対応者に転送します。

ライブコールルーティングでカスタムメッセージが使えるようになりました。録音されたMP3ファイルを再生し、以下のように発信者をサポートします。

企業とブランディングを一致させる

クリティカルなイベント発生時に追加サポートを提供する

顧客が正しい番号に発信したことを確認する

顧客を適切なリソースに誘導する

API提供の拡張

ビジネスサービス

チームや人などのオブジェクトのタグ付けと検索

中央集中や分散チームのためのイベント管理ルール

当社の API を使用して、ビジネス・テクニカルサービスの階層を自動化し、時代遅れの散在する Wiki への依存をやめ、ビジネス関連情報を必要な場所に置くことで、情報提供を合理化します。

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

2020年5月28日  (更新日:2022年3月11日)    |    インテグレーション&ガイド

Kafkaサービスのためのインテリジェントなヘルスチェック

ヘルスチェックは、回復力を維持し、システムの継続的な運用を確保するために不可欠です。理想的には、ヘルスチェックはシステム内の問題を可能な限り早期に検出して、システムが自動的に修正するか、サービスオーナーに問題を通知して手動で解決できるようにしなければなりません。

Amazonの主任ソフトウェアエンジニアであるDavid Yanacek氏が述べているように、システムに適切なヘルスチェックを作成することは難しいかもしれません。しかし、適切に行われていれば、ヘルスチェックは効果的にサービスのダウンタイムを減らし、サービスが依存している顧客に与える影響を軽減することができます。

この記事の主な焦点は、PagerDutyのEvent Ingestion Admin(EIA)サービスのために実装されたヘルスチェックになります。EIAはイベントAPIの管理インターフェイスで、ユーザーは様々なイベントタイプの情報や、イベントが当社のシステム内に読み込まれ処理されている間のイベントの状態を見ることができます。今回は、様々なKafkaトピックからイベントを読み込み、それらのイベントをElastiCacheに保存するEIAのConsumerアプリケーションに焦点を当ててみたいと思います。このブログを読んだ後には、Kafkaに依存したシステムのヘルスチェックの書き方や、発生する可能性のある合併症への対処法が見えてくると思います。

何が不健全なのか?

EIAの問題は、Elixirロガーが新しいログを処理できないためにシステムが予期せずクラッシュした後に表面化しました。また、EIA が Kafka からの新しいメッセージの読み込みを停止する可能性が常にあることも知っていましたし、問題がより深刻になるまで気づかないことも知っていました。

このように、EIA のヘルスチェックで解決しなければならない問題が 2 つありました。(1) Kafka Consumerがforwardしていることを確認すること、(2)Elixir ロガープロセスが黙ってクラッシュすることなく動作し続けることです。これらのいずれかが機能しなくなった場合、健全性チェックは失敗し、システムを安定した状態に戻すために必要なアクションが発動されます。

問題が検出されると、問題を修正するのは非常に簡単です。次のコードは、ヘルスチェックのエンドポイントが何をすべきかをシンプルに示しています。

図1: ヘルスチェックエンドポイント

ヘルスチェックの先頭には Consul と呼ばれるネットワークツールがあります。これは、サービスの発見、ヘルスチェック、ロードバランシングなどを提供する役割を担っています。私たちのケースでは、Consul は基本的にConsumerアプリケーションの ナイーブなアプローチ

EIA は多数の Kafka トピックを読み込み、各トピックには 64~100 のパーティションがあります。各トピックのConsumerごとに別のコンテナをスピンアップし、それぞれが独自のヘルスチェックを持ち、ヘルス状態に基づいて個別に再起動することができます。

まず、Elixir GenServer(汎用サーバ)を作成することから始めました。GenServerは、アプリケーション内の他のプロセスと通信しながら、コードを非同期に保存、状態表示、実行できるプロセスです。特に、ヘルスチェックのGenServerは、イベントの現在の状態を更新し、現在の状態に基づいてアプリが健全かどうかを判断する役割を担っています。

これを行うためには、いくつかのステップを踏まなければなりませんでした。イベントが取り込まれて処理されるたびに、GenServerの状態は、イベントが正常に処理された最後の時間を示すタイムスタンプで更新されます。Consulが このアプローチにはいくつかの問題がありました。2つのConsumerが同じ速度でメッセージを読み込んで処理することはありません。例えば、 それに比べて、 一度失敗したら、試してみて、もう一度試してみる

時間ベースのアプローチでは十分ではないことがわかったので、次のアイデアは Kafka のConsumerオフセットを利用することでした。使用するオフセットには、現在の(最新の)オフセットとコミットされたオフセットの 2 種類があります。現在のオフセットはトピックに送信された最後のメッセージを指し、コミットされたオフセットはConsumerによって正常に処理された最後のメッセージを指します。

Consumerアプリが正常に動作しているかどうかを確認するために、forwardしているかどうかを確認したいと考えました。最新のオフセットが移動している(つまり、新しいメッセージを読み込んでいる)ので、コミットされたオフセットも同様に移動している(つまり、新しいメッセージを処理している)ことになります。このソリューションでは、メッセージがいつ入ってきたかどうかは問題ではないので、最初のアプローチからの問題が解決されます。

このソリューションを実装するために、ヘルスチェックのGenServerは、より複雑な情報をステートに保存する必要がありました。以下はステートを抜粋したものです。

ステートには、メタデータ(異なるオフセットを取得するために必要)とパーティション情報という2つの主要なコンポーネントが保存されています。各パーティションには、コミットされたオフセットと最新のオフセット、そしてパーティションの健全性を決定するフラグが格納されています。新しいイベントが入るたびに、GenServer は新しいオフセットで更新されます。ネットワークツールがヘルスチェックのエンドポイントにpingすると、ステートはすべてのパーティションが不健康であるかどうかをチェックするために繰り返されます。もしそうであれば、Consumerコンテナは再起動されます。

プリプロダクション環境でテストを実行した結果、ヘルスチェックは正常に機能していました。これらの変更を本番環境に適用した後、GenServer が本番環境のトラフィックに追いつけず、ヘルスチェックプロセスがクラッシュし続け、アプリケーションが不安定な状態になっていることがすぐに明らかになりました。私たちは変更を元に戻し、振り出しに戻りました。

3度目のチャンス

以前のアプローチでの最大のボトルネックは、EIA が処理しなければならないトラフィックの量でした。幸いなことに、その答は手元のソリューションからそう遠くないものでした。各イベントの後にGenServerの状態を更新する代わりに、ヘルスチェックは10秒ごとに各パーティションを更新してチェックすることができました。これがどのように実現されたのか、ヘルスチェックの主な機能を見てみましょう。

画像3: ヘルスチェックの実装

GenServerが初期化されると、状態のパーティションデータはNULLに設定されます。最初にConsulがヘルスエンドポイントにpingを打つと、GenServerは各パーティションのコミットされたオフセットと最新のオフセットをフェッチしてステートにセットします。それ以降の実行では、Kafka の各パーティションの現在のコミットされたオフセットと最新のオフセットが、ステートに保存された古いオフセットと比較されます。forwardしている場合は、パーティションの健康状態がtrueに更新され、ステートがオフセットで更新されます。各パーティションを見て更新すると、ステートは反復され、トピック全体が健全かどうかをチェックし、適切な値をConsulに返します。

この方法では、EIA が消費するイベントの数は問題にならないので、健康チェックの GenServer は以前よりもかなり少ない作業をすることになります。これは本番に向けてプッシュバックされ、無事に動作しました!

別れの想い

プロセス全体を通して私が得た重要なポイントの1つは、問題に対する答が最初は必ずしも明らかではないということです。システムとその要件によっては、それが正しいものになるまでに何度も反復する余地があります。Kafka を初めて使う人にとって、システムが健全かどうかを判断するためにツールを活用する創造的な方法を考え出すことは、興味深く、最終的には非常にやりがいのあることでした。もしあなたがKafkaに依存したサービスで同じようなことをしようとしているのであれば、私たちが学んだ教訓を共有して、あなたのプロセスがどのように進んだかを聞いて、あなたを助けたいと思います。

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

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

サービスベースとチームベースのアプローチのどちらを選ぶべきか

by Mark Gabbard

インシデント対応プロセスをどのように設定していますか?

PagerDutyのアプローチは、お客様のインフラ、お客様の顧客向けアプリケーション、お客様の製品を総合的に調べることです。これらの項目を「サービス」と表現して、それらを総合した「ビジネスサービス」を構成します。この設定により、チームはサービスをより効率的に管理できるようになり、インシデントが発生したときに、応答者はより迅速にコンテキストを取得できるようになります。

まず、サービスについて説明しましょう。サービスは持続するように構築されており、通常、元々サービスを開発したチームよりも長生きします。言い換えれば、人々は出入りし、チームは常に再編成されるということです。また、サービスを所有するチームの変更は、年に一度だけとか、再編成時にだけに行われるのではありません。特定のプロジェクトでは、わずか数週間で新しいサービスを開始し、古いサービスを継承し、所有権を変更します。

そのため、インシデント対応プラットフォームをチームやサービスに合わせる(さらに悪いのはサービスをまったく提供しない)場合、チームの再編成が発生するたびにインシデント対応のセットアップ全体をやり直す必要があります。さらに、チームの変化に伴い、組織の知識と重要な分析データが失われます。悪夢のようですね。

そのため、PagerDutyはインシデント管理プロセスをサービスに合わせて容易に調整できるようにプラットフォームを構築しました。これにより、チームは時間の経過とともに成長し、変化することができ、サービスの状態とトレンドをより明確に把握できるようになりました。サービスのデリバリーや保守、改善に影響を与えることなく変更を行うことができるため、最終的にはダウンタイムの長期化と顧客への悪影響を軽減できます。

時間の経過に伴うビジネスインパクトやサービスの稼働状態、トレンドの可視性を向上

ほとんどの企業と同じように、インシデントプロセスのセットアップ、運用サポートや構成をチーム単位で行うことができます。つまり、チームベースのアプローチを取ります。これは、ITSM、DevOps、ITOpsのチームが混在し、ビジネスチームと技術チームがビジネスサービスを定義し、他の多くのチームも異なるサービスを持っていることを意味します。

では、チームベースの設定からサービスベースの設定にどのようにして移行するでしょうか。それは、ほとんどの人が考えるよりも簡単です。

最初に、顧客が特定のタスクや成果を実行するためにやり取りする製品やアプリケーションの部分にあたる最上位レベルのビジネスサービスを特定します。たとえば、「ログイン、ショッピングカート、検索」はすべてビジネスサービスです。次に、そのビジネスサービスを支える技術サービスを特定します。各技術サービスは、複数のチームが長期的なメンテナンスに携わっている場合でも、理想的には一度に1つのチームが所有し、開発する必要があります。

ビジネスサービスとそれをサポートする技術サービスを特定すると、さまざまな興味深いことができるようになります。たとえば、チームはビジネス全体で何が起こっているかをリアルタイムで確認できるようになり、単独の問題なのか、より大きな影響を与えているのかをよりよく理解できるようになります。これにより、問題が複数のチームやサービスにまたがる場合に、より適切に連携した対応が可能になります。

イベントが、環境内のサービスから別のサービスにルーティングされても、個々のサービスが環境にどのように反映するか、何が起こっているのかを誰もが簡単に伝えることができます。さらに、対応者はインフラ全体で発生している他のインシデントを把握できます。

例えば、Site Reliabilityエンジニアリングチームに所属していて、サービスが停止したという通知を受信したとします。同時に、データベースチームの別の対応者も同じ通知を受けました。あなたは、複数のサービスに関連するインシデントを表示できるため、それがデータベースの問題であることがわかり、データベースチームが対処することがわかった時点で、あなたによる問題の処理を中止できます。

ビジネスとビジネスニーズに対応

今日のほとんどの企業には、インシデント管理プロセスのためのチームベースの対応セットがあります。初期の段階では対応セットの設定は簡単ですが、成長と拡張に伴い、長期的な管理が実際には困難になります。なぜでしょうか。

このアプローチで生成されたサイロは、対応者に混乱をもたらします。インシデントが発生したときに、協調的で効果的な対応はより困難です。これは、対応者が実際に影響を受けたものを調べるために時間を費やす必要があるためです。何をすべきかを考える前に「サービスAとサービスBのどちらがページに表示されているのか、どの程度の対応が必要か」を考えるべきです。覚えておいてください。ほとんどのチームは少なくとも10の異なるサービスを所有しており、アラートが異なるサービスにルーティングされるようにイベント情報を整理しておくと、何が起こっているのかをよりよく理解するのに役立ちます。

これとは対照的に、技術サービスとビジネスサービスの橋渡しをする、サービス優先のアプローチを採用している組織は、特定のサービスの重要性に関するコンテキストを提供できるため、ビジネスと顧客に明確なインパクトを与えます。また、コミュニケーションのための共通言語を提供し、簡潔で実用的なステータスの変化を知る必要がある人と自動的に情報共有できるようにします(例:サービスAは見積りから現金までのシステムをサポートしているため、インシデントが発生した場合には、SLAがなく必須ではない内部サービスBより高いレベルの対応が必要、などの情報)。

チームベースのセットアップは簡単

前述したように、インシデント管理プロセスの構成と設定にチームベースのアプローチを使用すると、最初は簡単です。ただし、長期的にはマイナスの方がプラスよりも大きくなります。たとえば、チームベースのアプローチでは次のことはできません。

インシデントのビジネスインパクトをリアルタイムで評価する

サービスがアプリケーションの信頼性や安定性に及ぼす影響を分析する

問題の影響範囲を正確に評価する。これは通常、複数のサービスにまたがるので重要

重大なインシデント発生中に通知すべきビジネス関係者を迅速に決定する

加えて、チームベースのアプローチには、チームの変更や再編成に応じて変更を加える柔軟性がありません。さらに、組織の変更がある場合は常にチームとサービスを再構築する必要があります。

最適なアプローチ

インシデント管理プロセスを設定するため、チームベースのアプローチとサービスベースのアプローチのどちらを採用するか決定する前に、「オンコールを設定するのはなぜか」を考えてみましょう。

最も可能性の高い回答は、問題が発生したときに迅速に対応するチームや担当者が必要なため、ということです。また、多くの企業では、チームファーストのアプローチで構成を設定しています。これは、チームがあり、全員がオンコールローテーションに参加していることを確認する必要があり、この方法だと簡単に設定できるからです。

誤解しないでほしいのですが、チームは非常に重要です。しかし、インシデント管理の設定とサービスのセットアップを最初に行うことをお勧めする理由は、それによって次のことが得られるからです。

サービスの健全性を理解し、プロセスを改善するために必要な可視性

ホットスポットを特定するためのトレンドに関する洞察

どのチームがどのサービスをサポートしているかを簡単かつ迅速に確認する能力と、複数のチームを通過して問題のサービスに到達する前にそれらのレイヤーを理解する能力

結局のところ、企業が本当に気にしているのは、ビジネスを遂行できること、そして、迅速に対応する必要がある影響を与えるあらゆることです。そのための最善の方法は、サービスベースのアプローチを使用することです。サービスベースのアプローチを使用すると、何に取り組む必要があるのか、どのように優先順位を付ける必要があるのかを理解できるようになるため、問題のサービスを探すためにいくつものチームのレイヤーを掘り返すことで時間を無駄にすることがなくなります。

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

2019年11月12日  (更新日:2022年3月10日)    |    ニュース&告知

Slackインテグレーションの一般提供を開始

by Andrew Marshall

PagerDutyの製品管理担当副社長Rachel Obstlerが4月にSlack Frontiersの「Slackによるインシデントの予測、監視、管理」パネルで新しいSlackインテグレーションのベータ版を発表したとき、私たちはこのインテグレーションに関心を持っていただけることを期待していました。

しかし、まだベータ版であるにもかかわらず、すぐにトップレベルのインテグレーション製品になるとは予想していませんでした。そしてこのほど、PagerDutyのSlackインテグレーションが一般公開されました。この記事では、Slack Integrationの主要な機能のいくつかを紹介し、ベータユーザーからのフィードバックを共有します。

どこにいても働ける

現代のOpsやDevOpsチームは、日々ますます多くのツールに依存しています。各ツールにはそれぞれ目的がありますが、必要なコンテキストを取得するためにアプリを切り替えることで、特に複雑なインシデントに対処するときには、素早さと集中力が低下することがあります。PagerDuty for Slackとのインテグレーションでは、PagerDutyインシデントに関するコンテキストの作成、エスカレーション、収集をSlack内から行えます。アプリを切り替える必要がないで、PagerDutyのデスクトップやモバイルインターフェースを使用する場合でも、Slackでリアルタイムオペレーションを管理する場合でも、PagerDutyがこれ1つで利用できます。

Fuzeのインシデント管理マネージャであるCorey Forman氏は、このインテグレーションについて次のように述べています。

「DevOpsチームとエンジニアリングチームがSlackのヘビーユーザであるため、PagerDutyのインテグレーションを各チームチャネルに追加するのは簡単です。アラートを受信し、インシデントを受任し、追加のリソースを通知し、トラブルシューティングの会話を継続する機能は、他にはないこのアドオンの真価です」。

SlackからのResponse Playの実行

Response Playの実行などのPagerDutyのリアルタイム操作機能はSlack内から操作できます。Response Playを実行するPagerDutyの対応チームは、インシデント管理プロセスをSlackアプリの中から素早く簡単に実行できるため、時間を節約し、集中力を維持できます。

ウォールームと他のスラックチャンネルの作成

チームがSlackのようなChatOpsツールに依存するようになった主な理由の1つは、全員が同じページと共通のダイアログスレッドに参加できるように指定されたチャネルを作成できるからです。PagerDutyから新しいウォールーム(または任意のSlackチャンネル)を作成したり、既存のウォールームに参加したりする機能を追加する際には、私達はこれを念頭に置いていました。また、追加のSlackチャンネル対応者をミックスに招待する機能も加えました。チームは、チャネル内のすべてのディスカッションとアクションをキャプチャして、事後レビューに使用できます。

Slack通知に対応

response作業には、豊富なインシデントコンテキストが不可欠です。PagerDuty for Slackでは、関連するインシデント・ファクトとデータ・ポイントをすべてSlack内に表示することで、対応者の武器となります。また、custom incident response playsを実行し、Slack通知から直接対応者を追加することもできます。

WallCraftのAleksey Smirnov氏は「PagerDutyのSlackインテグレーションは、チームに新しいレベルの可視性をもたらします。Slack内でGrafanaアラートを表示できるので、時間を大幅に節約できます」と述べています。

Slackからオンコール情報の表示

最新のオンコールシフトのスケジュールは、インシデント管理計画とインシデント対応に不可欠ですが、スケジュールを覚えていないこともありえます。PagerDuty for Slackのインテグレーションにより、チームはSlackのインターフェースから最新のオンコール情報とタイムラインを表示できます。

「以前は『今夜の当番は誰?』という会話がSlackでよくありました。SlackとPagerDutyのインテグレーションで、誰がオンコールなのかが分かり、Slackを離れずにアラートを知ることができるようになりました」と前出のForman氏は述べています。

Slackからインシデントのトリガー

Slackから直接PagerDutyインシデントをトリガーすることもできます。SlackのようなChatOpsツールは、チーム内やチーム間をリアルタイムでつなぎます。多くの場合、この個人間のやり取りはリアルタイムで問題を特定するのに役立ちます。問題が発生している最中にSlackからインシデントを発生させることができるため、チームはSlackを離れることなく、その時点で規定されたアクションを素早く起動することができます。

組織内の様々なITOpsチームとの接続

現代の企業の多くには、NOCからCentral Ops、DevOpsなどの様々なチームが存在します。PagerDuty for Slackのインテグレーションは、これらの異なる構造のOpsチーム、セキュリティやカスタマーサービスなどの他のチームを共通のインシデント管理フレームワークに接続して、チーム内とチーム間のコミュニケーションを改善します。また、チームはSlackbotを使って、Slackのインテグレーション機能の使用方法を学習できます。

SlackとPagerDuty間のアクセス許可の調整

チームのPagerDuty PermissionのセットをSlackユーザーと同じにすれば、個人とチームが簡単に連携できます。PagerDuty for Slackインテグレーションにより、権限を複製したり再設定する必要はありません。

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

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

AIと機械学習を利用してHarnessとPagerDutyでの継続的デリバリーを強化する

一見すると、機械学習を継続的デリバリー(Continuous Delivery)に適用するのは、ハンマーでピーナッツを割るように聞こえるかもしれません。 つまり、デプロイメントの自動化は実際どれだけ難しいのでしょうか?

調べた結果、それは私たちが考えるよりも複雑です。

新しいデプロイメントをプロダクションに移すと、通常2つの結果になります。

サービスは起動し、すべてがOKだと思う。 サービスは起動せず、何もかもが壊れてる。

現実には、上の2つの点は、組織の95%がデプロイメントの成功を測る方法(上=良い、下=悪い)を表しています。 幸せなPagerDutyのお客様は、2番目のシナリオ(携帯電話にアラートとインシデントの嵐が届く状況)はよくご存じです。 しかし、シナリオ1は、誤解を招く可能性があります。サービスが動いているからといって自動的に健全性、性能、品質がOKだという証拠ではないからです。

手動でデプロイメントのヘルスチェックをする短所

Harness(訳注:Continuous Delivery-as-a-Service プラットフォームのサービス提供会社)で最初の25人の顧客から私たちが学んだ1つは、大部分の組織では一般的に3〜5人のエンジニアがいて、手動で実稼働展開を確認す​​るのに1時間以上かかるということです。例えば当社の顧客のBuild.comは5-6人のチームリーダーがNew RelicとSumo Logicのデータを手動で分析するのに1時間かかっていました。これは通常、複数のコンソール/ブラウザウィンドウを開き、bashスクリプト、アプリケーションパフォーマンス監視、ログ分析ツール間でコンテキストを切り替えることを意味します。

人間の脳は短期記憶を使う際は8-10​​項目しか集中できず、様々なシステムからのすべてのデータが集中していることを考えると、2018年の人間は非常に簡単にミスをします。数十万回の時系列メトリックと、展開後に数百万回のログエントリーがあることを考えれば、 手作業による分析とヘルスチェックは難しい問題です。

AIと機械学習がヘルスチェックを支援するようにする

Harnessでは、ソフトウェアアーチファクトのプロダクションへのデプロイメントを自動化するだけではありません。 AIや機械学習を使ってヘルスチェックを自動化します。 私たちはこのContinuous Verification(継続的検証)と呼んでいます。

主に隠れマルコフモデル、記号集約表現(訳注:Symbolic Aggregate Representation。いわゆるSAX)、k-平均法クラスタリング、およびいくつかのニューラルネットなどの教師なし機械学習アルゴリズムを使用して、APM(アプリケーション性能指標値)とログデータから異常や性能低下の検出を自動化します。

Harnessは、新しいソフトウェアアーチファクトを数秒で展開して、任意のAPMツールまたはLogツールに接続し、パフォーマンス(応答時間/スループット)と品質パースペクティブ(エラー/例外/イベント)から、アプリケーションの動作モデルを自動的に生成できます。

Harnessはこれらのモデルを以前のデプロイメントと比較し、新しい異常や性能低下を即座に示します。 人間が処理や分析をするのに要する時間に比べ、機械学習アルゴリズムでは数秒しかかかりません。

たとえば、以下のスクリーンショットはAppDynamicsのAPMデータをHarnessで検証した結果です。

上記の画像では、Harnessが展開後に2つのビジネストランザクションがパフォーマンス低下を示していることが分かりました。 以下の図では、「Request Login」という1つのトランザクションで、応答時間が31msから165msに増加したことを示しています。 この分析はすべてAI と機械学習で自動化されています。

SplunkからのアプリケーションログについてHarnessが検出したエラー/例外の異常の別の例を次に示します。

赤い点は、デプロイ後からアプリケーションログに入るようになった新しいエラーを示します。 灰色と青色の点は、すべてのデプロイで通常観察されるベースラインのイベントまたはエラー/例外を表します。

ハーネスは、k-平均法クラスタリングといくつかのJacardおよびコサイン距離演算(訳注:ふつう、集合の類似度を示す)を使用して、これらのビジュアルを生成します。 任意の点をクリックすると、イベントのスタックトレースと根本的な原因も表示されます。

AI / 機械学習インテリジェンスによるロールバックの自動化

Harnessは、Continuous Verificationのインテリジェンスを使用して、デプロイメントのロールバックを自動化することもできます。 Harnessは、Dev / DevOpsチームがより速く展開できるようにしながら、新しい異常や性能低下に遭遇するたびにロールバックできるようにするセーフティネットと考えてください。

今後のPagerDutyのHarnessサポートにより、各組織はPagerDutyを通知チャンネルとして、また検証ソースとして使用することができます。 たとえば、Harnessはデプロイの前にPagerDutyに対して、運用中に発生しているアクティブなインシデントがあるかどうかを確認するクエリを送信できます。Dev / DevOpsチームが最後に望むのは、本番環境に展開することです。

まとめると、Harnessは、 継続デリバリー・サービス( Continuous Delivery as-a-Service )を提供することで、各組織が本番環境でエンドユーザーへのソフトウェアの展開と配信を自動化することを支援します。私たちは、顧客が何かを壊すことなく迅速に動けるよう支援します。

Steve BurtonはHarness.ioのCI / CD DevOps Evangelistです。 Harnessに入る前は、AppDynamics、Moogsoft、GlassdoorでGeekをやっていました。 彼は2004年にSapientでJava開発者としてキャリアをスタートしました。 テクノロジーで遊んでいないときは、通常はF1を見たり、インターネットで車を研究したりしています。

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

2019年9月17日  (更新日:2022年3月10日)    |    インシデント&アラート

ビジネス関係者にもインシデントの最新状況を知らせる

by Adam Keller

想像してみてください。航空会社のデータセンターでチケット発券システムがダウンするような重大なITインシデントが起こりました。舞台裏では、エンジニアが問題の診断と修正を急いでいます。しかし、昨今のシステムは非常に複雑であるため、問題の解決には予想よりも長い時間がかかり、システムがダウンしてから数時間が経過しています。

一方、乗客は長い列を作り、地上係員に怒りをぶつけ、ソーシャルメディアで人々とフラストレーションを共有しています。カスタマーサービス要員には何が起こっているのかわからず、乗客と同様の情報にしか与えられていないにもかかわらず、なんとか状況を説明して全員を落ち着かせようと最善を尽くしています。

ここで、顧客が直面しているのは技術的なインシデント対応で、カスタマーサービス要員、フライトクルー、手荷物係などの内部関係者に情報を提供するなどのビジネス的な対応は存在しないか、あっても行き当たりばったりなので、インシデントの影響を悪化させ、会社のブランドや評判に深刻な損害を与えてしまいます。

そこで我々は、PagerDuty Solution for Business Responseをご用意しました。

ビジネス対応のためのPagerDutyソリューション

この例のように、ビジネスや顧客に影響を与える重大なインシデントが発生した場合、技術面の対応者(つまり、プライマリレスポンダー)だけが行動を起こす必要があるのではありません。会社全体の関係者(エンジニアと非エンジニア)も動員する必要があります。

これらの「二次対応者」は、例えばメディアへの説明ポイントをまとめるなど、ビジネス上の負の影響を軽減するために、最新のインシデント解決の進捗状況を知る必要があります。航空会社の例では、顧客サービスチームとチケット発券業者は、このインシデントがビジネスにどのような影響を与えるかを理解し、ホテルクーポンの提供や乗客の再予約が必要かどうかを決定する必要があります。

PagerDuty Solution for Business Responseは、インシデント対応に当たる技術チームの手をわずらわせることなく、簡潔で実用的なステータス更新を、それを知る必要のある人と自動的に共有することにより、インシデント発生時のビジネス部門と顧客とのコミュニケーションを円滑にします。

「顧客がデジタル製品に24時間年中無休でアクセスできることをますます期待するにつれて、システムダウンの潜在的な悪影響が増大します。インシデント発生中、技術的な対応はビジネス的な対応とうまく統合されないことが多く、このコミュニケーションのギャップは消費者の体験を左右します。PagerDutyのビジネスレスポンスソリューションは、技術とビジネス利害関係者の両方にインシデントを迅速に通知し、問題を修復するための調整されたアクションを実行できるよう構築されました」。

–Rachel Stephens、RedMonkアナリスト

ユーザーは、通知方法をカスタマイズすることもできます。たとえば、PagerDutyのWebサイトのステータスダッシュボードを表示するだけでなく、SMSやメール、PagerDutyモバイルアプリを介してプッシュ通知を受信するように設定できるため、特定のインシデントが発生したことをリアルタイムで知ることができます。

リアルタイム更新のステータスダッシュボード

PagerDutyのステータスダッシュボードには、事前に選択されたビジネスサービスの健全度が表示されるため、従業員はシステムの現在の状態を一目で把握し、過去に起こったことを確認し、メンテナンスやアップグレードなどの今後のサービス変更予定を確認できます。エンジニアは、技術的アクションとビジネスアクションの協調が最も重要なときに両方を調整する洗練されたインシデントレスポンスプレイとフローを設定することもできます。

PagerDutyのビジネス対応ソリューションの利点

Modern Incident Response製品の上に構築されたPagerDuty Solution for Business Responseは、ユーザーにインシデントの状況認識をシームレスかつ自動的に通知するので、技術面の対応者とビジネス関係者/利害関係者の両方がリアルタイムのインシデント情報を使用して対応を調整できます。追加の有料アドオンは必要ありません。利点は次のとおりです。

顧客との関係を積極的に管理することで、企業とブランドに対する顧客の信頼が高まります。関係者と従業員は、顧客から質問される前にインシデントを認識します リアルタイムでインシデントに対応できるようにすることで、ビジネス関係者と対応エンジニアの生産性を向上 顧客に影響を与えるインシデントが発生した場合に、技術的対応とともに、ビジネス対応活動を迅速に開始できる サービスの健全度が一目でわかるライブステータスダッシュボード リアルタイムのターゲットを絞ったステータス更新とビジネス部門自らの関与により、IT部門の負担なしで主要な利害関係者と積極的に関与する機能

Business Responseが実際にどのように機能するか、さらにお知りになりたい方は、次のビデオをご覧ください。

サブスクライバー(情報購読者)の追加、ステータス更新の追加、ステータスダッシュボードでビジネス対応を調整する:https://youtu.be/MaUmLBgLDBE 利害関係者チームや関連対象者向けの特定のビジネスサービスのみを含むカスタムダッシュボードを作成する:https://youtu.be/Ug1s_fsheu4 サブスクリプションの管理と通知ルールの表示:https://youtu.be/XX2aP200wSw ユーザーとチームを追加して、ステータス更新の受信と公開をする:https://youtu.be/C39wNKK_RMw

PagerDuty Solution for Business Responseは、Modern Incident Responseプランのお客様が利用できるようになりました。ステータスのボタンをクリックするだけで準備完了です。この機能にご興味がある場合は担当者に連絡し、詳細についてサポート技術情報をご覧ください。

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

2019年9月9日  (更新日:2022年3月9日)    |    ニュース&告知

【2019年8月リリースの概要】 新しいモバイル機能、強化されたセキュリティと分析、Amazon EventBridgeとのインテグレーション

PagerDutyは2019年8月、新しいリリースを発表いたしました。このリリースでは、いつでもどこからでもリアルタイムで安全に作業できるように、新しい製品機能と拡張機能のセットが提供されます。

このリリースでは、デジタルオペレーションを最適に管理するためのより良いプラットフォームを構築するというお客様のニーズに引き続き応えています。機能強化には、モバイルアプリの新しいイノベーションと、メールドメインの制限を追加することによるプラットフォームセキュリティの強化が含まれます。また、分析スコアカード機能をより柔軟にし、Amazon EventBridgeとの新しいパートナーエコシステムのインテグレーションを追加しました。

モバイルプラットフォーム

すべてのインシデントが24時間以内に解決できるわけではないため、ユーザーが24時間以上アラートをスヌーズするオプションを追加し、営業時間外のアラートをより柔軟に管理できるようにしました。長時間スヌーズは現在iOSアプリで利用可能ですが、Androidでも近日中に提供される予定です。

設定についての警告

ユーザーは設定メニューで PagerDutyインスタンスのセットアップを最適化する方法を見つけることができます。警告をタップして、連絡方法と通知ルールを更新します。たとえば、ユーザーがSMSやメールなどの連絡方法を追加するのを忘れた場合、連絡方法の追加を推奨する警告がポップアップ表示されます。

ビジネスサービスのステータス更新

ビジネスレスポンス用PagerDutyソリューションをローンチしました。これは、アドオンのModern Incident Response上に構築されています。この新しいソリューションには、ビジネス関係者に明確で簡潔な情報を提供する新しいステータスダッシュボードが含まれているため、チームはインシデント発生時のリアルタイムのビジネスおよび技術的対応をより適切に連携、調整できます。

ユーザーはインシデントに優先度レベルを割り当て、モバイルアプリから直接ビジネスサービスに関連付けることができます。この新機能により、技術担当者はビジネス系サブスクライバーに通知でき、ステータスダッシュボードの適切な場所に情報が表示されるようになります。

iPadレイアウトの改善

新しいiPad用のレイアウトにより、より大きな画面をより有効に活用し、インシデントをタップして詳細を表示できます。また、分割画面のサポートもあり、PagerDutyアプリをカレンダー、Slackなどの他のアプリと一緒に使用できます。

eメールドメイン制限付きの強化されたプラットフォームセキュリティ

メールドメインが制限されているお客様用に、セキュリティレイヤーを追加しました。これにより、承認されたメールドメインを持つユーザーのみがPagerDutyセッションにアクセスできるようになります。管理者とアカウント所有者は、ユーザーがログイン情報を作成または変更したり、メールアドレスに連絡したりするときに、メールドメイン許可リストにあるドメインのみを使用するように制限することができます。

新しい分析スコアカード検索と購読、購読解除機能

新しい分析スコアカード検索により、ユーザーはチーム名またはカスタムスコアカード名を検索することにより、利用可能なスコアカードのリストから特定のスコアカードをすばやく見つけることができるようになりました。以前は、ユーザーはスコアカードのリストを目で見て必要なものを見つける必要がありました。特に、多くのチーム、多くのスコアカードを購読しているリーダーや大規模な組織のユーザーにとっては、時間がかかるイライラする作業でした。

また、ユーザーはスコアカードのサブスクライブを設定、解除できるようになりました。これにより、チームに所属していない場合でも、チームの運用指標を確認できます。サブスクライブ/サブスクライブ解除機能を追加することにより、ユーザーはUIに表示するスコアカードの中から見たいものだけを表示できるため、カスタマイズされ、すっきりしたユーザーエクスペリエンスを体験できます。たとえば、マネージャーやエグゼクティブのマネージャーは、さまざまなチームグループに参加することなく、関心のあるデータを表示するためにサブスクライブできます。

パートナーエコシステムインテグレーション

Amazon EventBridge

PagerDutyとAmazon EventBridgeとのインテグレーションにより、チームはネイティブAWSサービスをPagerDutyに接続するイベント駆動型のワークフローを簡単に作成できます。Amazon EventBridgeを使用すると、PagerDutyのお客様は、AWSがサポートする幅広いインテグレーションと機能を活用できます。

この8月リリースの新機能にご興味がある場合は、詳細についてのサポート技術情報をご覧ください。

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

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

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

by Andrew Marshall

2019年7月のニューヨークでのAWSサミットは、AWSとPagerDutyの両方にとってエキサイティングなものでした。AWSチームは、AWSでSaaSを提供するパートナー企業が、顧客が処理するイベントを簡単に挿入できるようにするAWS CloudWatch Events用のAPIセットであるAmazon EventBridgeを公開しました。PagerDutyは、EventBridgeをローンチパートナーとしてサポートすることで、AWSとの長年のパートナーシップを深化させています。AWSベースのクラウドインフラストラクチャを使用するPagerDutyのお客様は、EventBridgeのアドバンテージを利用して、PagerDutyのリアルタイムオペレーションプラットフォームをさらに活用できます。

AWS Lambdaについて少々

AWSがre:InventでサーバレスサービスAWS Lambdaを2014年に発表したとき、多くの開発者はLambdaの大きな可能性について懐疑的でしたが、Cloud Foundry Foundationの世界的な調査によると、22%の企業がすでにサーバーレステクノロジーを使用していることがわかりました。Lambdaが提供する価値はシンプルです。サーバをプロビジョニングせずにコードを実行できます。チームはほぼすべてのタイプのアプリケーションまたはサービスを自動的に実行でき、Lambdaはどんなコードでも実行しスケーリングします。EventBridgeはAWS Lambdaを使用して、PagerDutyなどのSaaSパートナーと提携することで、さらに多くのことを可能にします。

それで、EventBridgeって何?

EventBridgeはAWSの新しいサービスであり、チームは複雑な設定とインテグレーションに貴重な時間を費やすことなく、ネイティブAWSサービスをPagerDutyなどのサードパーティSaaSソリューションに接続するイベント駆動型ワークフローを作成できます。EventBridgeにより、PagerDutyの顧客はAWSがサポートするインテグレーションと機能のすべてを活用できます。

PagerDutyデータのインバウンドソース

EventBridgeを使用すると、PagerDutyユーザーは PagerDuty Eventsによってトリガーされるイベント駆動型ワークフローを簡単に作成できます。AWSコンソール内のインバウンドデータソースが信頼できるため、チームがデータにアクセスするために複雑なWebhookや他のマニュアル設定手順を使用する必要はありません。セットアップが完了すると、チームはPagerDutyイベントデータを使用して、AWSでイベント駆動型のワークフローをトリガーできます。

「AWS EventBridgeとPagerDutyを組み合わせることで、イベント駆動型のワークフローをリアルタイムで生成できます」とCox AutomotiveのリードソフトウェアエンジニアであるEd Kozlowski氏は述べています。「問題を検出すると、PagerDutyは、AWS Lambda関数をトリガーするアラートを生成してランブックを取得し、PagerDutyに詳細をポストできるため、問題をより迅速に解決し、お客様に最高のエクスペリエンスを提供できます」。

PagerDuty+EventBridgeをどう使うか

幅広いAWSサービス製品と同様に、PagerDutyとAmazon EventBridgeでできることには制限がありません。とはいえ、顧客が即時のビジネス価値を実感するために実装できる次のような用途があります。

セキュリティ修復 オープンポートを(AWS GuardDutyを介して)検出するとします。これは明らかにセキュリティリスクであり、適切な対応者に警告する必要があります。PagerDutyとEventBridgeを使用すると、SecOpsまたはオンコールチームへのアラートをトリガーするだけでなく、直接オープンポートへのアクションを実行できます。この追加された修復アクションでは、たとえば、AWS Lambda関数を使用して、Amazon Virtual Private Cloudがポートを閉じます。 実行可能なコンプライアンス違反 同様に、AWS Identity and Access Management(IAM)ロールまたはアクセス許可違反がAWS CloudTrailを介してトリガーされたとしましょう。適切なサービスチーム、管理者、またはSecOpsにこの潜在的なセキュリティやコンプライアンスの問題を知らせてほしいが、警告だけでは修復に役立ちません。PagerDutyとEventBridgeを使用すると、このデータを使用してAWS Lambda呼び出しを自動的に行い、アクセスを完全にロックするか、別の構成変更をトリガーして問題に対処できます。

PagerDutyユーザーが活用できるその他のいくつかのユースケースには、次のものがあります。

リソースのデプロイ:サービスリソースをスケーリングまたは起動して、新しい需要に対応します。 エンドポイントの問題:Amazon Personal Health Dashboardを使用して、エンドポイントの問題に対処するための変更を行います。 カスタマーサービス:PagerDutyがインシデントに対処するときに、新しいSalesforce.com Service Cloudケースを自動的に作成するか、既存のケースを更新します。

AWSエコシステム内でPagerDutyのデータとアラートを実行可能にする準備はできていますか? 詳細については、EventBridgeインテグレーションガイドや、PagerDutyのAWSインテグレーションスイートをご覧ください。

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