Blog
ブログ

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

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

このブログを読んでいる人の多くは、自宅、どこかのリモートオフィス、家族の家、あるいは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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。

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

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

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

by Mark Gabbard

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最適なアプローチ

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

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

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

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

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

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

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

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

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

一見すると、機械学習を継続的デリバリー（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社のサイトで公開されているものを日本語訳したものです。原文はこちらです。

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

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

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