Category
インテグレーション&ガイド

2022年8月10日  (更新日:2022年8月10日)

ギャップを埋める:正しい方法でオートメーションを導入する

企業における自動化は新しいことではありません。エンジニアは何十年も前から自動化ツールやフレームワークを使って仕事をしてきました。構成管理ツール、継続的インテグレーションとデリバリーパイプライン、クラウドの形成など、自動化はビジネスシーンにおけるほぼ全ての技術的なユースケースの構成要素となっています。こうしたことが本当なら、なぜ自動化はいまだに多くの手作業と対になっているのでしょうか。

その答えは?IT部門とそれ以外の部門に自動化を広く普及させるには、まだ明らかな遅れがあるのです。例えば、今日の企業の大半は、製品、サービス、ヘルプデスク、その他の顧客向けアプリケーションなど、何らかの形でデジタルサービスを提供しています。そして、ほとんどの企業は、そのサービス提供の展開や維持のために、IT組織内である程度の自動化を活用しています。しかし、自動化は利用されていても、その価値が十分に発揮されていないことがよくあります。自動化の利用は通常、ビジネスの小さな領域に限定され、自動化を実装または構築した従業員のみがそれを使用し適用することができます。

私たちはこれをオートメーションギャップと呼んでいます。

オートメーションギャップ

オートメーションギャップとは、組織内の自動化の利用が島ごとに存在し、各専門業務部門がサイロ化した自動化を活用しているというシナリオです。さらに、オートメーションギャップがあるということは、(専門家以外の)ほとんどの従業員が、自動化を実際に利用するための系統的な知識、スキルセット、組織全体のアクセス権を有していないことを意味します。

ITの視点から見ると、オートメーションギャップは業務を停滞させ、次のような大きなビジネス上の問題につながる可能性があります。

専門家へのエスカレーションが絶えず、イノベーション能力が制限される SLAペナルティとインシデント解決の遅れによるエラー率の増加 予定外の仕事や依頼が殺到し、スペシャリストが燃え尽きる 最終的には顧客の不満と収益の損失

デジタル世界における技術革新のスピードと消費者の期待の高まりを考慮すると、オートメーションギャップがもたらす負の外部性は、日が経つにつれて悪化または拡大する一方でしょう。しかし、問題に対処し、ギャップを埋める前に、ギャップの存在の根本的な要因を特定し、理解できるようにする必要があります。

オートメーションギャップの特徴は、大きく3つの要素に分類されます。

ナレッジギャップ スキルギャップ アクセスギャップ

ナレッジギャップ

あらゆる規模のデジタルファーストの組織は、顧客のニーズを満たし、イノベーションに歩調を合わせ、競争に勝ち残るために、常に変革を続けなければなりません。この進化を成功に導くためには、デジタルインフラも並行して適応し、進化していく必要があります。しかし、進化は一夜にして起こるものではありません。進化は、何年にもわたるDX、従業員や文化の変遷、新たな複雑性や技術的な依存関係を経て、レガシーインフラの上で発生するものなのです。適切な文書化と理解なしには、シームレスな実行はほぼ不可能です。

ナレッジギャップとは、1人の個人または社員が、IT組織内のあらゆる依存関係、システム、ベストプラクティスについて、専門家になれるわけではないことを理解することです。例えば5年以上勤続している元社員は、レガシーインフラのインシデントに取り組むための系統的な知識を持っているかもしれませんが、8カ月勤務しているオンコール対応者は、同じ基礎インフラについて微妙な理解を持っていないかもしれません。

スキルギャップ

スキルギャップとは、ユーザーによって技術的なスキルセットが異なるという現実のことです。ナレッジギャップと同様に、スキルギャップも組織のデジタルインフラ全体における新しいテクノロジーと複雑性を専門に扱う従業員に起因しています。新しいシステムやプロセスが導入されると、多くの場合、それらを構築または実装した専門家 (SME)が、必然的にインシデントが発生したときに問題を適切にトリアージできる唯一の人物となります。このような専門性のボトルネックは、対応のライフサイクルに悪影響を与え、専門家を疲れさせ、修復作業の効率を低下させる可能性があります。このギャップは、特に人員削減の時期に顕著で、XシステムやYサービスに必要な理解とスキルを持つスペシャリストが、1人か2人しかいなくなった場合に生じます。

誰もがデータベースの管理方法や継続的インテグレーションのパイプラインの自動化方法を知っているわけではありません。実際、企業で最も高いスキルを持つ技術者は、通常そのような需要があるため、その作業を軽減できればビジネスのスケールに貢献します。繰り返し行われる診断や手順を常に中小企業にエスカレーションすることは、予定外の作業を生み出し、本来なら専門家が優先すべき価値の高い作業の妨げになります。このような技術的な役割を担う人材の獲得は増加の一途をたどっており、このギャップを解消することは、企業にとって長期的な取り組みがより一層重要となっています。

アクセスギャップ

最後に、アクセスギャップは、今日のベストプラクティスに従ってセキュリティー体制を維持することに関連しています。 最小特権アクセスの原則に従えば、スーパーユーザーの資格情報をITスタッフ間で広く配布したり、共有したりしてはいけません。ツール、情報、システムに適切にアクセスできなければ、解決に要する時間の長期化、修復作業の非効率化、中小企業が価値の高い作業に集中する時間の短縮など、アクセス不足に起因する悪影響が生じます。

では、PagerDutyはどのようにしてこのオートメーションギャップを埋め、ITオペレーション全体の敏捷性を向上させ、チームがより速くイノベーションを起こせるようにするのでしょうか。

アプリケーションオートメーション

PagerDutyの自動化機能により、これまで専門エンジニアにしかできなかったことがエンドユーザーにもできるようになります。このプラットフォームは、自動化を他の関係者に安全に委譲し、エスカレーションの中断をなくし、待ち時間を劇的に短縮することで、これらのギャップを埋めるように設計されています。これらのプロセスは、既存のタスク自動化を運用ワークフローの個々のステップに組み込むことができ、一貫した運用体験を提供しながら、プロセスのユーザーから各ステップの特定のコンテキストを抽象化できます。

PagerDuty® Process Automationのポートフォリオは、以下の製品で構成されています。

PagerDuty® Automation Actions:PagerDutyのレスポンダーをキュレーションし、インシデントに関与するサービスの自動診断と修復につなげるPagerDutyアドオンです。 PagerDuty® Runbook Automation:エンジニアがランブックの手順を標準化・自動化し、サービスをセルフサービス型オペレーションとして委譲できるSaaSサービス。 PagerDuty® Process Automation On-Prem:エンジニアがエンドツーエンドの運用ワークフローを標準化・自動化し、関係者にセルフサービス型オペレーションとして安全に委ねることができるセルフホスティング型ソフトウェア群です。

PagerDutyの自動化機能は、エンドユーザーと認証情報やキーを明示的に共有することなく自動ワークフローを呼び出せるため、組織がアクセスギャップを安全に解消するのにも役立ちます。シングルサインオン(SSO)と統合してロールベースのアクセス制御を可能にし、プロセスレベルとステップレベルの両方ですべてのアクティビティを記録して、コンプライアンス要件を満たします。 PagerDutyの自動化機能がオートメーションギャップを埋める過程でどう役立つかについては、https://www.pagerduty.com/use-cases/automation/ をご覧ください。

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

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

PagerDutyからSlackの新ネイティブ機能が登場 - 今すぐ利用可能

PagerDutyでは、お客様の声に耳を傾けることにかなりの時間を費やしています。 それらの会話から学んだことから、私たちはSlack Integrationに新しい機能セットを追加しています。これらの機能により、SlackからPagerDutyを活用することがよりシームレスになり、インシデント対応者はコンテキストを切り替えることなく作業を行うことができ、対応時間を短縮し、最終的に高い顧客満足度を維持することができるようになります。

最新のSlack V2 on Webhooks V3 Integrationでは、以下の機能が利用可能になりました。

Slackのシングル接続管理ページ。 統合管理用のページを1つ持つことで、設定に必要なクリック数を減らし、手順を省き、価値創造までの時間を加速させます。 このページでは、PagerDutyのチームとSlackチャンネルを接続するだけでなく、多対多のワークスペースとPagerDutyのマッピングを行うことができます。

ステークホルダー専用のアップデートチャンネルと、レスポンダーによるインシデントアップデートの投稿を容易にするアクセス権 ステークホルダーチャンネルはインシデントチャンネルとは異なり、レスポンダーのスピードを落とすことなく、ステークホルダーが適切なインシデントの詳細やアップデートを閲覧できるようになっています。対応者は、コンテキストを切り替えることなく、Slack からステークホルダー・アップデートと解決ノートを作成することができます。

柔軟な Rundeck アクションで診断と修復を行います。インシデント対応者はスクリプト可能な診断と修復アクションを Slack から直接デプロイできるようになりました。Rundeck Actions on Slack の詳細については、こちらのブログをご覧ください。

これらのアップデートにより、Slackから直接仕事ができるようになることを期待しています。あなたが働く場所で働き続けられるように、近日中に新しい機能拡張を追加しますので、ご期待ください。 Slack V2以前のバージョンからご利用のユーザーの皆様へ、これらの機能および今後リリースされるすべての機能をご利用いただくために、管理者がWebhooks V3上でSlack V2への移行を実行したことをご確認ください。 ご不明な点がございましたら、サポートまでご連絡ください(サポートメール)。まだ弊社のお客様でない場合は、14日間の無料トライアルにご登録ください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

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

PagerDuty RundeckのアクションをPagerDuty Slackインテグレーション内で呼び出せるようになりました。

インシデントを迅速に解決するために、共同で問題を診断する。

昨年、私たちはPagerDuty Rundeck Actionsをリリースしました。これは、PagerDutyのインシデント対応ワークフローにおいて、対応者を一般的な問題の自動診断と修復に直接つなげるためのPagerDutyアドオン製品です。お客様と協力し、コミュニティの声に耳を傾けた結果、PagerDuty Rundeck ActionsがPagerDutyのSlackと統合されたことを発表します。

オートメーションとコラボレーションの融合

今回の統合により、対応担当者はSlackチャンネルから直接、自動診断と修復アクションを展開することができるようになりました。これにより、ターミナルからサービスにアクセスし、ウィンドウを切り替える必要がなくなり、より迅速かつ効率的にインシデントを解決し、専門家へのエスカレーションを減らすことができます。 一つの問題に対処するために、ダブルモニターに複数のウィンドウを表示させる時代は終わりました。インシデントの状況を関係者に伝えるだけでなく、同じウィンドウから修復アクションを展開することができます。インシデントが発生すると、対応者はSlackインスタンス内にインシデント専用のチャンネルをすばやく作成し、影響を受けるチームや関係者とコラボレーションし、診断手順を実行し、自動化を呼び出してリアルタイムに問題を修復することができます。

CollabOpsの実践

第一線の対応者や担当者は、IT部門全体で構築したつながり(具体的にはPagerDuty + Rundeckと統合したアプリケーションやサービス)を活用し、チャットボットを導入してアクションを実行させることができます。問題をエスカレーションして上に受け渡すのではなく、この統合により、仕事に適した人材がいる専用チャンネルにインシデントをすぐに落とし、修正に向けて共同作業を行うことができます。また、この統合は、インシデントが発生すると、そのロジスティクスを積極的にキャプチャして記録し、文書化プロセスを完全に透明化して、すべての関係者がアクセスできるようにします。

ルンデックアクション 仕組み

PagerDuty Rundeck Actions を使用すると、エンジニアは面倒で繰り返し行われる診断手順の自動アクションを作成してレスポンダーに委任し、繰り返し行われるタスクに費やされる時間を削減することができます。また、フェイルオーバーなどの一般的なミティゲーションアプローチや、その他の修復手法の自動化も含まれます。 既知の問題に対するシンプルで反復可能な治療法も、イベントトリガーを使って人間の介入なしに発動させることができ、緊急の問題を解決済みの後処理に変えることができます。PagerDutyで作業するレスポンダーがインシデントの解決を加速できるように、Rundeck Actionsは自動診断と修復をインシデント対応ワークフローにつなげます。 Automated Diagnosticsは、インシデント発生時にレスポンダーが呼び出すことができる、プロダクションサービス用の自動化されたアクションのセットです。一般的なテストを手動で実行する専門家にエスカレーションするのではなく、第一応答者はPagerDutyから安全にこの自動化を呼び出すことができ、インシデントタイムラインにリアルタイムで返されるレスポンスを確認することができます。 PagerDuty Rundeck Actionsを使用すると、チームは以下のことが可能になります。 レスポンスタイムを最大30分短縮 Slack経由でレスポンスチーム全体に専門知識を配布 レスポンダーが呼び出される前に、人的支援と自己修復の自動化を開始 ファイアウォールやVPCの内側で安全な自動化を実行 手作業に代わる自動化されたアクションの導入 インシデントの文書化を充実させ、事後処理をスムーズにし、オペレータの作業を軽減します。

Rundeck Actions がどのように機能するかについてもっと知るには、ナレッジベースをチェックしてください。さらに、アカウントマネージャに連絡するか、デモをリクエストしてください。

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

続きを読む
インテグレーション&ガイド
2018年6月15日  (更新日:2022年7月13日)

Zenoss 3インテグレーションガイドを追加しました

Zenossは、普及しているオープンソースネットワーク、サーバーおよびアプリケーション監視システムです。あらゆるオープンソース監視システムで利用可能な最高のイベント管理システムの1つを提供します。Zenossのプラグインアーキテクチャにより、誰でも簡単に利用できるようになりました。PagerDutyは、PagerDuty APIを使用してオンコールスケジュール、アラート、インシデント追跡を提供することで、Zenossの機能を拡張します。 このガイドでは、Zenoss 3のインストールをPagerDuty ZenPackにインテグレートする方法について説明します。

詳しくはこちら

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

BMC Service Deskインテグレーションガイドを追加しました

BMC Remedy Service Deskは、モバイル向けにネイティブで構築された革新的なサービス管理プラットフォームです。美しく直感的なユーザーエクスペリエンスを提供します。BMC Remedyを使用すると、PagerDutyユーザーは、フォームに注意が必要な内容が記入されたときにアラートを受け取ることができます。

詳しくはこちら

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

スクラムの儀式。初心者のためのガイド

スクラムセレモニーとは、スクラムイベントやミーティングの一種で、プロジェクトをよりタイムリーかつ効率的に進めることを目的としたものです。このセレモニーは、制作プロセスの重要なポイントで行われ、チームメンバー間の組織的なコラボレーションとコミュニケーションを重視し、複雑な開発プロセスやキューを簡素化することを支援します。例えば、デイリースクラムは毎朝行われ、どの項目が完了し、どの項目に取り組んでいるか、そしてどの項目が控えているかを確認する儀式である。

5つのスクラムセレモニーには、以下のようなスクラムイベントがあります。

スプリントプランニング:スプリントバックログを決定し、チームの期待値を設定するためにスプリントの最初に開催されます。 デイリースタンドアップ/スクラム:毎日(多くは一日の始まりに)行われる15分間のセレモニーで、チーム全体のアイテムの進行状況をスクラムチームメンバー全員に素早く報告する。 スプリント:スプリントは、スクラムチームメンバーが協力してスプリントバックログを完成させるためのイベントと考えられている。 スプリント/イテレーションレビュー:スプリントや特定のマイルストーンの終了時に開催され、完了した作業をレビューして発表します。 レトロスペクティブ:イテレーションの終わりに開催され、イテレーション中に何がうまくいったか、どんな問題が出てきたかを分析する。回顧式の目的は、継続的な改善を促し、開発を最善の方法で前進させることです。

スクラムやその他のアジャイル手法で非常に重要なのは、チームメンバーや利害関係者全員が制作ライフサイクルについて明確かつ共有した理解を持つことです。スクラムのセレモニーは、物事を整理し、前進させるための接着剤となります。 この記事では、これら5つのスクラムセレモニーについて、どのスクラムチームメンバーが関与するのか、それぞれのミーティングは通常いつ、どれくらいの時間行われるのか、そしてそれぞれのスクラムセレモニーの目的について詳しく見ていきます。

アジャイルメソドロジー&スクラム

企業やその規模にかかわらず、すべての開発チームの主要な目標の1つは、新しい製品やアップデートを迅速かつ効果的にユーザーに展開することです。定期的かつ確実なアップデートによって製品/サービスの体験を継続的に改善できれば、ユーザーとの信頼関係やロイヤリティが徐々に構築されます。さらに、幸せな顧客を持つことによる収益性の向上は、利害関係者との良好な関係を維持することにつながります。

今日、テクノロジー企業は、信頼できるプレミアムなユーザー体験を提供するために、アジャイル開発方法論を用いて生産プロセスの改善に役立てています。そして、これらのアジャイル開発手法の中で、スクラムは明らかにトップドッグであり、約60%の組織が製品開発にスクラムを活用しています。スクラムは、作業内容、進捗状況、タスクやアイテムの優先順位など、チームの完全な理解に基づくものです。

スクラムの5つのセレモニー

スクラムセレモニー#1:スプリントプランニング

スプリントプランニングは、スプリントの最初に行われるミーティングで、スプリントバックログ(スプリント中にチームが完成させるべき項目の全一覧)を決定します。また、このミーティングでは、スプリントを成功させるために、チーム全体への期待値を設定する必要があります。

スプリントプランニングには誰が参加するのですか?** スクラムの全役割(開発者、スクラムマスター、プロダクトオーナー) スプリント・プランニングはいつ行われますか?** それぞれの新しいスプリントの開始時 スプリントプランニングのミーティングの長さはどれくらいですか?** 1~2時間 スプリント・プランニングはどれくらいの頻度で行うべきですか?** すべてのスプリントの前

スクラムセレモニー#2:デイリースクラム

デイリースクラムは、プロダクトバックログで何が起こっているかを全員に知らせるために、最も一般的には午前中に開催される短い毎日のミーティングである。このミーティングはかなり短時間であるべきですが、各メンバーが完了したもの、取り組んでいるもの、障害に遭遇していないかなどを議論する時間を確保する必要があります。

デイリースクラムに参加するのは誰ですか?** すべてのスクラムロール デイリースクラムはいつ行われますか?** 通常、作業の開始時 デイリースクラムの時間は?** 15-20分です。 デイリースクラムはどれくらいの頻度で行うべきですか?** 毎日です。

スクラムの儀式その3:スプリント

スプリントは、指定された時間ブロックの間にチーム全体が完了するように設定されたタスク(または仕事の塊)のリストです。これは、スプリントプランニングのセレモニーで示されるものです。

スプリントに参加するのは誰ですか?** 開発者 スプリントはいつ行われるのですか?** 異なります。 スプリントの期間は?** スプリントプランニングに基づき、各スプリントにはそれぞれブロック化された時間目標があります。スプリントの期間は数日から数週間、数ヶ月と様々ですが、スプリントバックログの内容によって異なります。 スプリントはどのくらいの頻度で行われますか?** 様々です。

スクラムセレモニー#4:スプリント/イテレーションレビュー

スプリント/イテレーションレビューは 、スプリントやその他の特定のマイルストーンの完了後に開催されます。このセレモニーの目的は、完成した作品をレビューし、紹介することです。スプリント/イテレーションレビューでは、開発チームは完成した機能やアップデートをチーム全体に向けてデモンストレーションします。他のチームメンバーやステークホルダーからのフィードバックが得られるだけでなく、開発者にとっても自分の頑張りをアピールできる機会です。

ここで重要なのは、これはあくまで部分的なレビューであり、完全なレビューは「レトロスペクティブ」で行われるということです。

スプリント/イテレーションレビューには誰が参加するのですか?** すべてのスクラムロール、ステークホルダー、プロジェクトの他のチームメンバーです。 スプリント/イテレーションレビューはいつ行われますか?** スプリントやマイルストーンが終了したときです。 スプリントレビュー/イテレーションレビューの時間はどれくらいですか?** 最大4時間です。 スプリント/イテレーションレビューはどのくらいの頻度で行うべきですか?** スプリントが完了したとき

スクラム・セレモニー #5: レトロスペクティブ

レビューが製品や完成した仕事に焦点を当てるのに対して、スプリントレトロスペクティブはプロセスに焦点を当てます。何がうまくいったのか?何が問題だったのか?プロセスの問題点を解消し、ツールを追加・調整し、人間関係やコミュニケーションを改善するための計画を立てる場でもあります。

誰がレトロスペクティブに参加するのですか?** すべてのスクラムの役割 レトロスペクティブはいつ行われますか?** 完了したスプリントやその他のマイルストーンの終了時に行います。 レトロスペクティブはどのくらいの時間行うべきですか?** スプリントの長さ1週間につき最大45分(例:2週間のスプリントの場合、最大1.5時間のレトロスペクティブとなる)。 レトロスペクティブはどれくらいの頻度で行うべきですか?** スプリントが完了したとき

スクラム・セレモニーのメリット

製品がますます複雑化する中、チームメンバー間の組織的なコミュニケーションとコラボレーションはこれまで以上に重要です。スクラムの5つのセレモニーは、チームメンバーが製品/プロジェクトについて共通の理解を持ち、製品ライフサイクルを通じて同期を保つことを支援します。

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

続きを読む
インテグレーション&ガイド
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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。

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

アラート対応疲れを減らすためにSignalFxとPagerDutyでソーシャルシグナルを監視する

チームにこう伝えました。「SignalFxで重要なイベントが進行中の場合は通知してほしい」。しかし、システム監視の会社のCTOであるにもかかわらず、進行中のインシデントや潜在的な問題を常に把握するために、適切なアラートを作成することは思ったよりも困難でした。

どうして?

クラウドとオープンソースの登場により、ソフトウェアをより迅速に構築できるようになりましたが、今日の環境は次のようなさまざまな理由から、監視と管理が非常に複雑になっています。

監視するインスタンス数の爆発(ホスト、コンテナ、関数) サービスはまれに「正常動作」というメトリックを発したり、常に変化したりする マイクロサービス構成のため、個別に監視する必要があるサービスの量が増えている

私たちの経験による結論は、誤検知や繰り返される警告の嵐です。アラート疲れはチームがリアルタイムで問題を見つけて解決する能力を妨げるだけでなく、長時間対処されないとチームの士気を破壊し、本来予防可能なシステムダウンをもたらします。

アラート疲れを軽減するための戦略

アラート疲れを軽減することは、自らの焦点を広げることから始まります。きめ細かなメトリックの測定は、トラブルシューティングやフォレンジック分析には非常に役立ちますが、最も効果的なアラートは、アプリケーションの健全性に関する高レベルのインジケーターを構成するシグナルの組み合わせに依存します。特に、次の点を考慮する必要があります。

個々のインスタンスではなく、全体を監視

環境内の個々のコンポーネントのステータスを警告するのではなく、サービスごとまたはグループごとの健全性インジケーターを定義してモニターします。たとえば、サービスインスタンス間のAPI呼び出しの99%が要している遅延時間、ノードの特定クラスタの平均CPU使用率、コンテナのグループのAPIエラーの合計などを追跡します。

1436台のホストのシステムメトリックを集約

固定の閾値よりもパターンと傾向に関する警告

変化する環境に適応できるアルゴリズムで生成された閾値を使用する。分散システムはしばしばミステリアスな方法で動作するため、アラートが発生する前に正しいCPU使用率やAPIエラーの数を判断することは非常に困難です。

単純セッション数と週をまたいだ変化

定期的なパターン(たとえば平日の高トラフィック)や予測的なアラート(次のN日以内にクラスタがディスク領域を使い切るのを警告する)によって、システムの通常の動作と対応を必要とするものを区別できます。

グラフが示す容量のメトリックの傾向

アプリケーションのパフォーマンスの全体的な尺度の定義

さまざまなマイクロサービスのメトリックを組み合わせて、より高いレベルのシグナルとアラートを導き出す。たとえば、ログインユーザーあたりのページ読み込みの数と、API呼び出しの合計に対するAPIエラーの割合です。あるお客様は、すべてのマイクロサービスのメトリックを組み合わせて、デプロイしたバージョンのパフォーマンスが全体的に改善されたかどうかを示すヘルススコアを作成しています。

ソーシャルシグナルの測定

SignalFxでこれらのテクニックをすべて使用していたにもかかわらず、まだ誤検知のアラートが多すぎました。次の点に注意しました。

私はエンジニアリングリーダーなので、サービスオーナーやオンコールエンジニアのように細かいアラートを必要としません。アラートのサブセットをフォローするのは、警告なしにリストがすぐに古くなるため実用的ではありません 私たちはPagerDutyを使用していますが、私が常にオンコールのエスカレーションパスにいるとは限りません 私はSignalFxのステータスページのようなソースを見ることでマイナーな問題をフィルターすることができますが、その代りにインシデント対応に積極的に関わりたくても、アラートが届くのが遅すぎて気付くのが問題が大きくなった後だったということになりかねない

では、他にどのようなシグナルを検出できるでしょうか? 我々SignalFxは#outageという名前のインシデントについてのSlackのチャンネルを作っていました。また、このチャネルは、PagerDutyから重要なアラート通知を受け取って、議論の内容を保存します。運用してみると、重大な問題には多くのユーザーがSlackでコラボレーションし、PagerDutyを介してエスカレーションしているという事実を知ったので、私は#outageで人間の活動に関するメトリクスを収集することにしました。結果は次のようになりました。

私はAWS Lambdaセットを使ってメッセージを照会し分類し(例えば人間かボットか)、それをSignalFxに公開しました。次に、3人以上の人が#outageで5分以上タイピングしていると私に通知する検出システムを作りました。アラートはPagerDuty経由で私の電話に送信され、Slackに直接メッセージが送信されます。

進行中の潜在的な機能停止を警告する

これは驚くほどうまくいきました。誤検知が全くなくはありませんが、その数はほぼゼロになり、関心の高いインシデントは全て通知されました。興味深いことに、いくつかの潜在的なインシデントについてアクティブなアラートとしてではなく通知を受けましたが、エンジニアはいつものサービス観察の中でそれを発見していました。

ハードウェアとソフトウェアの監視は停止しない

最初は、アプリケーションとインフラのメトリクスだけを使用して「完全な」アラートが作成できないことに失望しましたが、これは素朴な期待だったかもしれません。正確なアラートを作成するにはシステム環境を理解するだけでなく、組織がどのようにインシデントに対応するかを知ることも必要です。

私の問題の解決には人間の行動を測定することで十分でしたが、今日のツールの多くが相互運用性とデータ非依存を志向していることを考えると、モニタリングに組み込む可能性のあるシグナルはたくさんあります。

インシデント管理と問題検出を統合する

リアルタイムのビジネスはリアルタイムの運用インテリジェンスを必要とし、今日のテクノロジーは従来の監視ツールで処理できる量よりもはるかに多くのデータを送信します。SignalFxは環境内の各コンポーネントからのストリーミングメトリックを収集し、数秒で分析とアラートを提供するため、問題が顧客に影響を及ぼす前にそれを見つけて解決することができます。

SignalFxとPagerDutyを使用すると、SignalFxでアラートがトリガーされたときにPagerDutyでインシデントを自動的に開くことができます。アラートに応じて異なるエスカレーションポリシーにマップし、正常に戻ったときに解決されたインシデントを自動的にマークします。

SignalFxは、組織が重要なシグナルをリアルタイムにあらゆる規模で監視するのを助け、かつてないほど迅速に革新することができるとの自信を持っています。

Arijit MukherjiはSignalFxのCTOで、システムの監視に情熱を傾けています。Facebookのメトリクスソリューション(ODS)のオリジナル開発者の一人であり、その後もFacebookのネットワーキングツール、データビジュアライゼーション、その他のインフラ監視ソフトウェアの開発を管理しました。10年以上にわたり監視の領域に重点を置いていましたが、20年以上にわたる彼の多様なキャリアは、IPテレフォニー、VoIP会議、ネットワーク仮想化にも及んでいます。

GET STARTED

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

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社のサイトで公開されているものを日本語訳したものです。原文はこちらです。

2017年12月30日  (更新日:2022年5月13日)     |    インテグレーション&ガイド

システムダウンを回避するための7つの方法

7つのステップでアプリケーションの高可用性を確保する

2016年8月、デルタ航空はコンピュータシステムの大々的な停止を経験しました。これにより1億5000万ドル以上の損害を被り、全社の利益率が3%低下しました。2300便がキャンセルされ、顧客は空港に何時間も足止めされました。デルタ航空は移動できなくなった人のために、何千件ものホテル代と旅行クーポンを支払う必要がありました。

数百万ドルするアプリケーションやサービスでも、いつダウンするか分かりません。大きな問題が1つでも発生すると、数億ドルの損失が発生する可能性があります。しかし、次のような対策をとれば、これを大幅に回避することができます。

1.マイクロサービスアーキテクチャを採用する

伝統的に、アプリケーションはモノリシックなスタイルで、つまりアプリ全体が1つのプログラムとして開発されていましたが、今ではマイクロサービスアーキテクチャが大いに普及しつつあります。その開発、テスト、デプロイには、相互に依存しない小さなアプリケーション群を配置します。こうすると、アプリケーションのコンポーネントが互いに分離されているため、保守が非常に簡単になります。したがって、特定のコンポーネントの1つに障害が発生した場合、他のコンポーネントに影響を及ぼすことなくフィックスすることができます。モノリシックアプリケーションでは、障害が起こるとアプリケーション全体がダウンするため、問題を特定するのが困難です。マイクロサービスのアプローチは、アプリケーションのダウンに対する耐性を高め、高可用性を実現するための第一歩です。ただし、マイクロサービスアーキテクチャでは、生成されるモニタリングデータの量がはるかに多く複雑になるため、関連するアラートを相関させ、対処不可能なアラートを抑制して全体的なノイズを削減することが重要です。

2.リリースはより速く、より頻繁に

マイクロサービスアーキテクチャの最大のメリットは、Webアプリの場合は1日に複数回、モバイルアプリの場合は2週間に1回などの高速リリースを可能にすることです。以前は四半期ごとのメジャーリリースだったため、すべてのリリースでダウンが避けられませんでした。現代的なアプローチではリリースは断片化しています。デプロイメントは、いつでもバックグラウンドでアプリケーションの一部でのみ行われ、プラットフォームは常に稼働したままになります。これにより、ダウンするリスクが軽減されるだけでなく、リリース速度を上げて最先端の機能と価値を提供することができます。

3.品質保証チームの関与

品質と可用性が同時に高まります。多くの企業ではQA(品質保証)の重要性を理解することができず、最終段階までそれを無視しがちです。バギーなソフトウェアを防ぐために、QAチームは、可能な限り早期に開発プロセスに関与し、リリースのライフサイクルに密接に関わっている必要があります。QAチームは自動化とテスト戦略に力を注ぐべきです。テスト自動化フレームワークは、手動アプローチと比較してコストを大幅に削減し、時間を節約しながらエラーを最小限に抑えるのに役立ちます。さらに、テスターはバグを探すだけではありません。彼らは開発を適切な方向へ向けるために、要件定義にも積極的に関与しなければなりません。開発チームが最初から正しい方法を構築することによって、後々の憂いをなくすことができます。QAは継続的な改善なのです。

4.ディザスタリカバリー計画を立てる

アプリの中核サービスに障害が起きたときのために、優れたディザスタリカバリー計画が必要です。パブリッククラウドとプライベートクラウドによるハイブリッドアーキテクチャを採用している企業では、サーバに冗長性を持たせ、各クラウド間でバックアップを取ることが重要です。仮想化は、既存の物理サーバのイメージバックアップを作成するのに便利です。また、コンテナ化することはさらに有用です。これは、イメージバックアップが軽量でスペースをとらないためです。これらの戦略は、障害時でもデータを確実に利用できるようにします。さらに、adminがおらず権限がない場合でもバックアップを取れるよう、バックアップを自動化しておきましょう。自動化により、DevOpsチームはディザスタリカバリーをテストして、障害への準備を整えることができます。

5.ITSM変更管理を採用する

ITILのような標準化されたフレームワークがITSM(ITサービスマネジメント)変更管理に使用されていることを確認してください。変更はそれがなければ進歩がないほどITサービスにとって有益ですが、変更は常に文書化されなければなりません。変化の成功率を測定し結果を公表して、どのチームが成功率が低いかを調べます。ServiceNowのようなITSMツールは、変更管理の可視性と制御性に優れています。ITサービスの混乱を最小限に抑えながら、迅速かつ効率的に変更を加えることができます。

6.インシデント管理ツールを使用する

避けられないシステムダウンが発生した場合、チーム内の適切な人にリアルタイムで通知することが重要です。しかし、多くの場合、チームはあまりにも多くのアラートを受け取るため、MTTR(解決までにかかる平均時間)に影響する重要なイベントを見逃す可能性があります。PagerDutyのようなインシデント管理プラットフォームは、さまざまな監視システムからのアラートを管理しグループ化するのに役立ちます。それは、簡単に定義されたルールに基づいて対処不可能なアラートを抑止し、関連する対処可能なアラートをインシデントにグループ化し、優先度の高いインシデントだけを適切な人物に通知するようにします。さらに、PagerDutyは既存のすべての監視、チケットシステム、ChatOps、コラボレーションツールなどとの統合により、チームがインシデントの解決を迅速に行います。

7.障害訓練を行う

計画的に障害を起こすことによって、システムダウンに対する準備をします。Netflixはこのアプローチをとっていることで有名です。彼らは常にバックグラウンドで実行されていて、ランダムにサーバインスタンスをシャットダウンするChaos Monkeyというスクリプトを使用しています。これにより、本物のサーバダウンが発生した場合でも、常にチームは準備ができており、スムーズに顧客にサービスを提供できます。PagerDutyでも毎週「Failure Friday」を実施し、意図的にシステムに障害を発生させ、対応を継続的に改善しています。

完全な対策を達成することは不可能ですが、DevOpsチームを構成する人、プロセス、ツールに焦点を当てることで、それに近づくことができます。すべてのシステムダウンを解決する銀の弾丸はありませんが、これらの手順に従ってより信頼性の高いアプリケーションを構築し、顧客の信頼と忠誠を獲得し維持しましょう。

2018年11月23日  (更新日:2022年5月10日)     |    インテグレーション&ガイド

エラーを迅速に解決するための5つのベストプラクティス

私はソフトウェアを書くことが大好きですが、バグを扱うことは嫌いです。それは、あなたがしたいことからあなたを奪い、バグフィックスというウサギの穴にあなたを導きます。完全なアプリケーションロジック、深いコンテキスト、リアルタイムでのスタック全体の可視性を提供するオープンソースのエラー追跡プラットフォームであるSentryを使って、時間をかけてエラーを苦労なしで(少なくとも小さな苦労で)解決するためのいくつかヒントをお伝えしましょう。PagerDutyとのインテグレーションの解説もあります。

以下にベストプラクティスのリストがあります。私たちはあなたが午前3時に起こされたときに、「ウサギの穴」に素早く移動できることを願っています。

問題の影響を特定する

あなたは午前3時の深い眠りの霧の中でコンピュータにつまずき、あなたが今受信したPagerDutyの警告のことをクリアな頭で考えようとします。最初にやりたいことは、問題の影響を知ることです。

この問題はInternet Explorerにのみ影響するのか? 特定のデータセンターの顧客のみか? あなたは聞くべき最も良い質問を知っています。そして今はそれをする時です。

Sentryは、問題に割り当てられたタグ(さまざまなキーと値のペア)というシステムを実装し、問題ごとに要約します。タグでバグのホットスポットを発見し、ブラウザ情報について顧客との間で行き来することを避けることで、時間とストレスを低減できます。

問題を再現するためにユーザーの手順をトレースする

問題の原因が明白でない場合、ユーザーがどのように操作したかを理解することが役立ちます。Sentryは、ユーザーがブレッドクラムとして取得したパスを自動的に追跡します。もちろん、ログを検索して手動でつなぎ合わせることもできますが、楽とは言えない作業でしょう。

スタックトレースからコンテキストを取得する

この時点で、あなたはウサギの穴を見つけ、1、2歩中に入りました。もう少し進みましょう。そしてもう一歩。

理論的にはすでにバグを再現しているので、コードを掘り下げて、何が間違っていたのか、なぜそうなのかを知ることができます。これらの質問に答える鍵はコンテキストです。あなたがこの穴から抜け出る道を見つけるために必要なのは。

そのコンテキストを取得する1つの方法は、スタックトレースを調べることです。おそらく例外が起きた場所を知ることができます。スタックトレースは、バグの原因となる一連のイベントや、バグのコード行を見つけるための洞察を与えてくれて、とても助けになります。

もっとたくさんのコンテキストが必要ですか? Sentryはスタックトレースを見せてくれるだけでなく、未展開のソースコードやローカルスタックをなど、すべてのスタックトレースを強化します。

必要に応じてオリジナルの開発者を追加

バグを突き止めて何が原因であるのかが分かれば、あなたはそれを修正するまでいじることができます。さもなくば、正しい人にバグを処理させることによって、前にしていたこと(食べたり、寝たり、人生を楽しむなど)に戻ることができます。バグフィクスを任せることは楽しくないかもしれませんが、エラー解決プロセスを簡素化し、迅速化することが最終的に必要です。

PagerDutyのお客様は、デベロッパーをステークホルダーまたはレスポンダーとして追加することができます。

Sentryは、ソースコード管理プラットフォームとの深い統合を提供し、エラーを引き起こした可能性のあるコミット-suspect commits(疑いのあるコミット)-を明らかにします。

Sentryは、問題を最もうまく解決できる開発者も示します。

アラートの優先順位付け

正直に言えば、すべてのエラーに眠りから起こす価値があるわけではありません。もし対応不可能な通知ならば、何とかしましょう。有効なツールを利用してください。

あなたの管理下にないgoofyプラグインに起因する警告やJavaScriptエラーを除外したいですか? PagerDutyのイベント管理を使用するか、 Delete&Discardを使用してSentryから直接削除してください。

これらのベストプラクティスはSentryとPagerDutyでなくともできますが、なぜ最善のもの以外に煩わされるのでしょうか? 結局のところ、何万人もの顧客が間違うわけにはいきません。

そして、おそらくあなたが推測したように、SentryとPagerDutyは共同で素晴らしい仕事をします。実際に、PagerDutyとの公式のインテグレーションがあります。私たちのインテグレーションは、あなたが定義したインシデント対応やインテリジェンスワークフローに従い、PagerDutyを介してアラートを送信します。開発チームと運用チームにエスカレーションポリシーや通知の緊急性、アプリ内のあらゆる場所からの対応などにより、エラーやアラートを表示します。

Neil ManvarはSentryのソリューションエンジニアマネージャーです。長年のソフトウェア開発経験の後、NeilはDevOpsのソリューションエンジニアリングに移りました。常にオンコールで、Cinnabon(訳注:米国の菓子パンチェーン)の前ではいつも立ち止まります。_**

GET STARTED

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

2018年6月19日  (更新日:2022年3月14日)     |    インテグレーション&ガイド

Pepperdata インテグレーションガイドを追加しました

PepperdataソフトウェアのAdaptive Performance Coreは、CPU、RAM、ネットワーク、ディスクの使用状況をユーザの介入なしに観察し、再編成して、時間通りにジョブを完了させます。 Pepperdataは、マルチテナント、マルチワークロードクラスタのボトルネックを動的に防ぎ、多くのユーザとジョブを単一のクラスタ上で最大の性能で確実に実行できるようにします。 不十分なデータを使用し、変化する条件に対応できないクラスタ管理ツールやチューニングとは異なり、Pepperdataはパフォーマンスの問題をスケールの点で自動的に解決するために全プロセスの完全なメトリックをキャプチャします。

詳しくはこちら

2018年4月26日  (更新日:2022年3月11日)     |    インテグレーション&ガイド

ThousandEyesインテグレーションガイドを追加しました

ThousandEyesは、クラウド時代のIT性能管理を提供します。企業のネットワークの範囲を超えた詳細な可視性を提供し、クラウドアプリケーションの性能の根本的な原因を見つける助けになり、問題を分散したコラボレーションで迅速に解決できるようにします。このガイドでは、ThousandEyesとPagerDutyをインテグレートする方法について説明します。

詳しくはこちら

2018年6月13日  (更新日:2022年3月11日)     |    インテグレーション&ガイド

Zenoss 5インテグレーションガイドを追加しました

Zenossは、普及しているオープンソースネットワーク、サーバーおよびアプリケーション監視システムです。あらゆるオープンソース監視システムで利用可能な最高のイベント管理システムの1つを提供します。Zenossのプラグインアーキテクチャにより、誰でも簡単に利用できるようになりました。PagerDutyは、PagerDuty APIを使用してオンコールスケジュール、アラート、インシデント追跡を提供することで、Zenossの機能を拡張します。 このガイドでは、Zenoss 4のインストールをPagerDuty ZenPackにインテグレートする方法について説明します。

詳しくはこちら

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

Uptimeインテグレーションガイドを追加しました

UptimeはあなたのWebサイトとWebアプリケーションの稼働とパフォーマンスを監視する(訳注:いわゆる外形監視)サービスの中でもトップクラスのサービスです。Uptimeは5大陸の異なる30カ所から1分間隔であなたのWebサイトをチェックします。PagerDutyとの連携法を紹介します。

詳しくはこちら

2018年6月22日  (更新日:2022年3月11日)     |    インテグレーション&ガイド

Watcherインテグレーションガイドを追加しました

Watcherは、Elasticsearchのアラートと通知用の製品で、データの変更に基づいてアクションを実行できます。これは基本的に、Elasticsearchで何かをクエリーできたら、そのことをアラートするように設計されています。 クエリー、条件、スケジュール、および実行するアクションを定義するだけで、Watcherが残りの作業を行います。PagerDutyと連携させることで、その作業をメンバーに効率よく周知できます。

詳しくはこちら

2018年1月22日  (更新日:2022年3月11日)     |    インテグレーション&ガイド

Zabbixのインストレーションガイドを追加しました

Zabbix は、ネットワークサービス、サーバ、およびその他のハードウェアのステータス を監視するために設計された、非常に強力なオープンソースのエンタープライズクラスのネットワーク管理システムです。多くの組織のITインフラストラクチャを監視する上で重要な役割を果たしています。 このガイドでは、インストール済みのZabbix 1.xまたはZabbix 2.x環境を、PagerDutyにPythonスクリプトを使って統合する方法について説明します。

このガイドでは、Zabbixの中でスクリプト、メディアタイプ、ユーザ、アクションを設定する方法を説明します。LinuxディストリビューションのバージョンとZabbixの設定によってはそれに合わせて、下記の手順を少し変える必要があるかもしれません。

詳しくはこちら

2018年1月13日  (更新日:2022年3月11日)     |    インテグレーション&ガイド

Zabbix 3.xのインストレーションガイドを追加しました

Zabbix は、ネットワークサービス、サーバ、およびその他のハードウェア のステータスを監視するために設計された、非常に強力なオープンソースのネットワーク管理システムです。多くの組織のITインフラストラクチャを監視する上で重要な役割を果たしています。

PagerDutyはZabbixの機能を、PagerDuty APIを経由したオンコール・スケジューリング、アラートやインシデントトラッキングで拡張します。PagerDutyはZabbixの最もクリティカルなイベントを通知し、あなたが即座に対応できるようにします。

詳しくはこちら

<  1234567  >