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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。
インテグレーション&ガイド
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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。
インテグレーション&ガイド
リアル(タイム)になりつつあるSecOps
AWS Security HubとPagerDutyがリアルタイムオペレーションを強化
クラウドに移行する企業は、強力なセキュリティ体制を維持し、コンプライアンス要件を満たすことができるようにする必要があります。コンプライアンスを確実にすることに加えて、企業はまた、異なるインターフェースおよびプラットフォームにわたって大量のイベントデータを生成する複数のセキュリティツールを結びつけるという課題に直面しています。この課題に対処するために、AWS re:Invent 2018で AWS Security Hubに新しいセキュリティサービスが発表されました。
AWS Security Hubとは?
Security Hubは、 Amazon GuardDuty 、Amazon Macie、Amazon InspectorなどのAWSセキュリティサービスからのイベントデータを1画面に表示します。さらに、Security Hubを使うと、AWSは多数のサードパーティ製セキュリティツールをプラグインして、好みのファイアウォールまたはエンドポイントソリューションを引き続き使用し、AWSネイティブサービスと一緒に表示するために、Security Hubにイベントデータを送信できるようにします。
AWSセキュリティハブ+PagerDuty
また、Security Hubはコンプライアンスチェックを実行し、潜在的な問題を防ぐためチームが迅速に行動できるようにカスタムアクションを作成するのに役立ちます。Security Hub内での対応および修復プロセスの一環としてPagerDutyとのインテグレーションを使用すると、各組織はCloudWatchイベントを介したGuardDuty検索ルールをPagerDutyに送信するカスタムアクションをすばやく設定できます。
Security Hub設定内でカスタムアクションを設定するのは非常に簡単です。これにより、チームはAWSまたはサードパーティのセキュリティツールから特定されたセキュリティ問題を選択し、すぐにPagerDuty内にインシデントを作成して適切な開発チームとセキュリティチームに通知し、彼らは共同で調査と対応に当たれます。
Security Hubとの新しいインテグレーションに伴い、当社もre:Invent 2018でいくつかの新しい AWS Integrationsを発表しました。
もっと知りたいですか? 14日間の無料トライアルを提供しています。組織にPagerDutyを採用する準備はできましたか? それならば AWSマーケットプレースでも購入できます。(訳注:Digital StacksでPagerDutyを契約するメリットについてもご覧ください)
本記事は米国PagerDuty社のサイトで公開されているものをDigitalStacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
インテグレーション&ガイド
OverOps統合ガイドを追加しました。
OverOpsを使用すると、開発中にコードブレークがいつ、なぜ発生したのかを知ることができます。プロダクションJVMでの、完全なアプリケーションコールスタック、ソースコード、キャッチ/キャッチされなかった例外、ログに記録されたエラーやワーニングを参照できます。
詳しくはこちら
インテグレーション&ガイド
PagerDuty + Atlassian:モダンインシデント対応を前進させる新しいエクステンション
「常時稼働・即時対応」の顧客の要求と期待の高まりに応えるため、デジタルオペレーションは人々の仕事の仕方を変えつつあります。 また、最も興味深いマクロなトレンドの1つは、IT運用チームと開発チームだけでなく、ビジネス全体がどのように顧客への対応力をレベルアップさせるよう注力しているかを見ています。 良いにつけ悪いにつけインシデント対応は、時間の制約のある中での組織全体の取り組み(カスタマーサポート、エグゼクティブ、コミュニケーション/マーケティング、セールスなどを含む)で効果的な対応を策定するための非常に良い例になります。重大インシデントはビジネス上の問題であり、製品上の問題ではありません。 現代のインシデント対応には、優れたコミュニケーションとコラボレーションが不可欠です。
Atlassianはこの現実解を与えてくれます。 当社が既に用意しているJIRA、HipChat、およびStatusPageとの深い統合に加えて、 PagerDutyのStride向けエクステンションの一般向けの提供開始をここに発表します。 Strideは完全なチームコミュニケーションソリューションで、何かPagerDutyでのインシデントが発生したときにチーム全体の可視性を向上させるのに最適です。 しかし、最も重要なことは、Strideが、重大インシデントのような危機の時に組織を調整するのに役立つということです。 特に、効果的なインシデント対応を推進するために、Incident Commanders、Deputies、Scribesの優れた機能を提供します。 (Incident Commandに精通していない場合は、 https://response.pagerduty.com/を参照してください )。
Incident CommandのStride機能をご紹介します。
PagerDutyのStrideサイドバーの使い方
PagerDutyはChatOps(GitHubの商標です)の初めに関連していることを誇りに思っていますが、ChatOpsの悪い応用例の1つは、対応中のインシデントの詳細を理解させるために新しいレスポンダーにチャットログ全体を読み上げるよう強制することです。それに対してStrideのサイドバーは、インシデントに関して関連性が一番高い情報のスナップショットを提示しておく場を提供します。インシデントに関連する冗長な会話はルームで行われ、一方でサイドバーのアクティブなインシデントの表示には、インパクト、イベント、重要な決定事項、および実行されたアクションの要約が含まれます。
このタイプの情報はまさにScribeがキャプチャし続ける必要があるものであり、リアルタイムでキャッチアップするためにも、後でタイムラインを編集するためにも最適です。 共通の基礎情報はコミュニケーションの重要な概念であり、インシデント対応にとって特に重要です。インシデント・コマンダーは、共通の基礎情報を維持するために、これらの種類の要約を定期的に(音声でのコールでは口頭で)行うように訓練されています。 スピードを上げるために人々に「チャットログを読め」と強制しないでください! (興味があれば、ExomiteのDan Slimmon氏はVelocity Santa Clara 2016で素晴らしい話をしています。ご覧ください。)
Stride Decisions
効果的なインシデント対応の重要な原則の1つは、すべての意思決定権限がインシデント・コマンダーに与えられることです。 これは、リスクの高い決定が顧客の影響を緩和するために必須な重大インシデントでは特に重要です。 トレーニングで使用する1つの例を示しましょう。ダウンタイムが発生すると同時に全Webサーバーを再起動するのは一般的ではありませんが、既に他の方法ですべての顧客が影響を受けている場合は、再起動が正しい選択かもしれません。
Stride Desicionsは、そのハード・ディシジョンをレスポンスが記述されているときにインラインで簡単に記録できます。 この種の意思決定ポイントの記載は、あなたの対応チームの共通の基礎情報を更新する素晴らしい方法です。 ただ覚えておいてください:あなたは決定を下す権限を持っていますが、あなたは常にあなたの Subject Matter Experts(SMEs)の専門知識を活用すべきです。 あなたは自分の意思決定について承認する必要はありませんが、実行する前に「何か強い反対意見」を求めておくのは、事後の偏った見方を防ぐために常に良い考え方です。
Stride Action
インシデントコマンドが有効な間に、統制のとれた状態を保つのが難しいことがあります。 決定が下されると、いろいろな行動がしばしば続きます。Stride Actionsは、さまざまな調査や実験を追跡し、それによって幅広い顧客への影響を理解し、それが顕在化するまえに緩和する方法を知るために最適です。
この種の機敏を要するアクションについては、次の3つを強く推奨します。
Assign them(担当に割り当てる)、つまり個人名( “Dave Cliffe”)または機能( “Network on-call”)で指定すること。 Time-box them(締め切りを示す)、担当者はより多くの情報を得る余裕がどのくらいあるかを知ることができます(これは緊急性を意識させるためにも役立ちます)。 Receive acknowledgement (誰かが受任したという通知を受け取る)、インシデント・コマンダーは彼らがタスクを理解していることを知っています。
事後検証をないがしろにしないこと
混乱が収まり、顧客への影響が少なくなったとき、インシデント・コマンダーがすべき最後の1つは、事後検証をさせることです。 すべてのインシデントは、学習の機会であることを覚えておいてください。 システムの技術的側面だけでなく、チームのコミュニケーションの仕方を理解することで、今後の対応がさらにうまくいくようになります。だからインシデント対応プロセスを定期的に確認してください。 PagerDutyとJIRAの統合は、レスポンスチームが特定したアクション項目をフォローアップするための素晴らしい方法を提供します。
モダンなインシデント対応には、反復と学習を通じて向上する正確で自動化された共同のレスポンスを可能にしながら、分散型のオーナーシップを取り入れる新しいアプローチが必要です。 PagerDuty StrideエクステンションをJIRAとStatusPageの統合と連携させることで、PagerDutyとAtlassianは効果的なオペレーションのための優れたプラットフォームを提供します。 ぜひ試してみて、あなたの考えをお聞かせください!
その他のリソース:
Strideスタートガイド モダンインシデント対応トレーニング インシデント対応のベストプラクティス
本記事は米国PagerDuty社のサイトで公開されているものを日本語訳したものです。原文はこちらです
インテグレーション&ガイド
Icinga 2インテグレーションガイドを追加しました
IcingaはNagiosからフォークしたオープンソースのシステム、ネットワーク監視ソフトです。このガイドではPerlベースのプラグインを使用して、IcingaのインストールとPagerDutyへのインテグレーションを解説します。
詳しくはこちら
インテグレーション&ガイド
IBM Bluemix Integrationガイドを追加しました
IBM Bluemixクラウドプラットフォームは、アプリケーション、インフラストラクチャー、サービスなどで問題を解決しビジネスを推進します。Bluemixは複数のデータソースの統合、システムの拡張、コグニティブサービスの組み込みにより、ビジネス価値を迅速かつ安価に推進します。
詳しくはこちら
PagerDuty:私たちは常にオンです
COVID-19の急速な感染拡大に伴い、多くの企業が完全なリモートワークに移行しています。顧客、ベンダー、パートナーがオンラインであることは、企業にとってこれまで以上に重要です。PagerDutyでは、従業員、その家族、そして私たちが属するより広い地域社会の健康と安全に主眼を置いていますが、他の最優先事項の1つは、特にこのような困難な時期には、顧客へのコミットメントです。
ご存知の方もいらっしゃるかもしれませんが、現在、全世界の従業員がリモートで仕事をしており、出張を停止しています。これが今のところの新しい常識かもしれませんが、リモートワークは当社にとって新しいことではなく、当社は最初からこのようなシナリオを想定して作られています。
当社の従業員は世界中に分散しており、分散したリモート環境での当社プラットフォームの開発と運用に慣れています。つまり、この事態にもかかわらず、お客様のデジタルビジネスが24時間365日稼働するように、PagerDutyを稼働させ続けることができます。
お客様へのコミットメント
デジタル運用管理のマーケットリーダーとして、当社はこの分野で最大規模、最も信頼性が高く、回復力のあるプラットフォームを提供しています。当社のお客様からは、昼夜を問わず、いつでもシステムに問題が発生したときに、リアルタイムで適切な対応を行うための支援を受けることができるとの信頼をいただいています。では、それをどうやって実現しているのでしょうか。
当社のチームメンバーが分散しているのと同様に、当社のプラットフォームアーキテクチャも分散しています。当社は、複数の物理的なデータセンターからなる地理的に独立したクラウドリージョンに分散して配置されています。当社のアーキテクチャは、お客様からのトラフィックの急増を想定しています。例えば、旅行業界やEコマース業界とは異なり、予測可能なトラフィックパターンには季節性がありません。1万2700人以上のお客様からの予期せぬトラフィック量の増加に最善の準備をするために、必要に応じて動的にスケーリングできるように準備しています。
当社は、「失敗の金曜日」シリーズでカオスエンジニアリングを実践し、お客様のために信頼性と回復力を維持する能力を実践していることで知られています。時間をかけて障害シナリオのシミュレーションに取り組んできた結果、現在では「Failure Anydays」(失敗はいつでも起こる)を実施しています。そう、当社のチームの1つまたは複数が、お客様へのサービス提供の質に影響を与える可能性のある問題を迅速に特定して軽減するために、制御された障害テストをいつでも実施しているのです。2013年以来、当社のプロセスと実践をお客様と共有してきたので、失敗からの学習への投資は新しいものではありません。私たちは、プラットフォームアーキテクチャ、ベストプラクティス、そしてお客様への取り組みを維持するために懸命に努力し続けるチームに適した要素を備えていると確信しています。
ダウンタイムといえば、PagerDutyでは予定されたダウンタイムはありません。あなたの時計は止まることはありません。当社のサービスレベルアグリーメント(SLA)は、お客様に提供する可用性とパフォーマンスの両方をカバーします。メンテナンスのために計画的なダウンタイムを実施することはありません。問題が発生した場合、設定された配信期間内にお客様が通知を受け取ることができるように、プラットフォーム製品に冗長性を持たせています。
多くの企業がリモートワークへのシフトを行おうとしているか、または行っています。そして今、これまで以上にデジタルビジネスが稼働し続けることが不可欠です。PagerDutyはそれを助けるためにここにいます。
本記事は米国PagerDuty社のサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
ServiceNowエンタープライズインテグレーションガイドを追加しました
ServiceNow Enterprise は、エンタープライズ環境に高度な自動化とプロセスワークフローを提供する強力な サービスプラットフォームです。PagerDutyの堅牢なオンコールスケジューリング、通知、エスカレーションにより、ServiceNowのワークフローやチケット機能を活用することができます。 このガイドは、ServiceNow IstanbulおよびHelsinkiの認定を受けており、お客様の環境にPagerDutyをインテグレートするプロセスを案内します。
詳しくはこちら
ServiceNow Expressインテグレーションガイドを追加しました
ServiceNow Express は、中小企業向けに高度な自動化とプロセスワークフローを提供するプラットフォームです。ServiceNow Express をインテグレートすることにより、PagerDutyの堅牢なオンコールスケジューリングと通知、エスカレーションにより、ServiceNowのワークフローとチケット機能を活用することができます。
詳しくはこちら
Honeybadgerインテグレーションガイドを追加致しました
Honeybadgerは、Ruby on Railsアプリケーションのエラー管理スイートです。 アプリケーションからエラーデータを収集し、ユーザーフレンドリーな形式で表示することで、問題をより迅速かつ容易に追跡し解決します。 HoneybadgerとPagerDutyを組み合わせることで、アラートによってこれらのエラーに関する情報をチームに配信し、記録的な速さで問題を修正できます。
詳しくはこちら
HipChatサーバースラッシュコマンド統合ガイドを追加しました
HipChatは、デスクトップやモバイルデバイス向けの140 以上の統合とネイティブクライアントを持つ、チーム向けの永続的に使えるグループチャットです。 この統合により、HipChatからPagerDutyにインシデントをトリガーすることができます。 このガイドの情報は従来の、HipChat Server integrationとlegacy HipChat integrationを補完するものです。
詳しくはこちら
HipChatエクステンションガイドを追加しました。
※ HipChat Cloudとの統合はこちらを参照してください。
HipChat は、デスクトップやモバイルデバイス向けの140以上の統合とネイティブクライアントを持つ、チーム向けの永続的に使えるグループチャットです。HipChatからPagerDutyのインシデントをトリガーできるようになります。HipChat Serverとの統合には別の記事を用意しております。そちらをご覧ください。
HipChatエクステンションガイドについて詳しくはこちら
Graylogインテグレーションガイドを追加しました
Graylogはオープンソースのログ収集、検索、管理ツールです。Graylogストリームがアラートをトリガーすると、あらゆる通知をPagerDutyで表示するように設定できます。PagerDutyをオンコールスケジューリングとチームへの通知のための集中化された場所として利用できます。
詳しくはこちら
Freshserviceインテグレーションガイドを追加しました
Freshserviceは、クラウド上のプラグアンドプレイITILサービスデスクです。 インシデント、問題、変更、リリース、資産管理などのコア機能をクラウド上でカバーしています。
このインテグレーションには、 REST APIキーが必要です。このキーは 、管理ユーザーとアカウント所有者のみが生成できます。 また、REST APIを使用するには、 基本プラン以上が必要です 。 ナレッジベースで REST APIキーの生成について詳しく読むことができます。
詳しくはこちら
Errorceptionインテグレーションガイドを追加しました
Errorceptionは、JavaScriptのエラーがユーザーのブラウザで発生しているのを見つけるために一番簡単な方法です。ページにスクリプトタグを挿入するだけで、リアルタイムで発生するエラーを記録することができます。Errorceptionのサービスフックを設定することにより、ErrorceptionからのJSエラー通知をPagerDutyインシデントとして受け取ることができます。
詳しくはこちら
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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。
Dynatraceインテグレーションガイドを追加しました
Dynatrace はアプリケーションとサービスを監視し、問題を分析し、問題が発生したときに通知します。また、Dynatrace はアプリケーションアーキテクチャ全体を自動的に学習し、適切な視覚化をインテリジェントに選択して提供することで、データや環境を容易に理解できるようにします。カスタマイズされたインフォグラフィクスは、アプリケーション環境のあらゆる側面に関する最も重要な事実を伝えます。
詳しくはこちら
- PagerDuty最高製品開発責任者による「AIと自動化が実現するオペレーショナル・エクセレンス」講演録画が公開
- PagerDuty、新しいアップデートで運用効率を向上
- PagerDuty 8月の製品アップデート情報
- Juneteenthを受け入れる:インクルージョンへの旅
- Custom Fields on Incidentsのユースケーストップ5
- ゼロトラストセキュリティーの正体と、気にしておくべき理由
- 5 年間の社会的影響: 公約 1% に対する進捗状況を振り返る (そしてこれから)
- AIOpsと自動:Forresterの主席アナリストであるCarlos Casanova氏をゲストスピーカーとして迎えた対談
- Runbook Automation for Incident Resolutionの新製品トライアルを活用する
- PagerDuty Operations Cloudに生成AIを投入