Blog
ブログ

インシデントを解決しようとしているときに、重要な情報を異なる記録システムから探し出すことは、ただでさえストレスの多い状況をさらに過酷なものにします。余分なクリック、余分なログイン、コピー＆ペースト、他の対応者との情報の共有など、全てが時間を浪費し、ヒューマンエラーの余地を増やします。PagerDuty のお客様は、Custom Fields on Incidentsを使って、インシデントデータを強化できるようになりました。この新機能により、チームはあらゆる記録システムから重要なインシデントデータを取り込み、レスポンダーの手元に置けるため、インシデントを迅速に解決するために必要な情報を得られます。

興味を持たれましたか？PagerDutyのお客様がCustom Fieldsをどのように使っているか、トップ５のユースケースをご紹介します。

1. インシデントの影響のラベル付け

Custom Fieldsの最も一般的な使用例は、インシデントの影響をキャプチャーして評価することです。あるSaaS企業では、インシデントによって影響を受けた地域、コンポーネント、顧客を特定するためにCustom Fieldsを使用しています。対応担当者がインシデントレコードを開くと、Custom Fieldsは異なるシステムからこの重要な情報を１つの明確で一貫性のある場所に集約します。これにより、レスポンダーは当面のインシデントの下流への影響を迅速に理解できるようになります。

2. 重要なITSMデータと同期する

多くの組織は、PagerDutyとITSMチケット発行システムの両方を使用しています。場合によっては、両方のデータを同時に処理する必要があります。ある金融機関では、情報を検索するためにタブを切り替えるのではなく、Custom Fieldsを使ってPagerDutyのインシデント詳細ページに関連するITSMフィールドを追加しています。例えば、ITSMインシデント、または問題のID番号を PagerDutyのビューに添付できます。

3. サードパーティー、または自社製ツールへのリンクを添付する

多くの場合、PagerDutyインシデントからサポートツールに直接リンクすると便利です。これは、例えば、ドキュメンテーションのための自家製ツールやサードパーティーベンダーなどが当てはまります。ある旅行会社は、PagerDuty Custom Fieldsを使って、関連するインシデントにサードパーティーの事後ポストモーテムリンクを追加しています。これにより、情報の追跡と相互参照が容易になります。また、組織がインシデントの事後分析に関する２週間の SLAを遵守するのにも役立ちます。

4. 地域ごとに会議ブリッジを接続する

ある多国籍金融機関は、Custom Fieldsを使って、複数の地理的地域にまたがるオペレーションセンターとステークホルダーにさまざまな会議ブリッジを接続しています。特に、この新しい柔軟なフィールドを使って、URLである「ステークホルダーブリッジ」をキャプチャーしています。今では、さまざまなグループが別々のソースからリンクや電話番号を探し出す必要がなくなり、全員をまとめることがこれまで以上に迅速かつシンプルになりました。

5. インシデント対応の役割分担

インシデント対応中には、いくつかの役割を担う必要があります。これには、インシデントコマンダー、代理、書記、主題専門家などが含まれますが、これらに限定されません。このような役割分担を明確にし、チームを円滑に運営するために、ある自動車サービス会社では、Custom Fieldsを使って対応ロールを追加しています。これにより、チームは、解決に向けて積極的に取り組んでいるときでも、過去のデータをレビューしているときでも、特定のインシデントに対する役割と責任を問う必要がなくなりました。

結論

これらの使用例は、Custom Fields が組織にどんな価値をもたらすかを理解するための出発点ですが、Custom Fieldsを適用する方法には限界がありません。どんなユースケースであれ、 Custom Fields はインシデントをエンドツーエンドで管理する単一の場所としてPagerDutyを活用するのに役立ちます。Custom Fields on Incidentsは通常、BusinessとDigital Operations planをご利用のお客様向けにウェブ、モバイル、APIからご利用いただけます。既存のお客様は、今すぐCustom Fieldsをお試しいただけますPagerDutyのご利用を検討中のお客様、あるいは下位プランをご利用のお客様は、製品ツアーをチェックしてCustom Fieldsの動作をご確認ください。

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

自動化は、マクロ経済情勢が不透明で不安定な中、効率性と拡張性を求める企業にとって、ゲームチェンジャーとなっています。プロセスの合理化、生産性の向上、ヒューマンエラーの発生率の低減は、自動化がもたらすメリットのほんの一部に過ぎません。

しかし、組織が自動化を導入する際には、これらの新しく進化するアセットを保護するための、最新のセキュリティー対策の確実な実施が非常に重要です。他のセキュリティーモデルがビジネスシーンの大部分を支配する一方で、セキュリティー実装コンセプトとして、急速に台頭しているのが、ゼロトラストです。

PagerDuty Runbook AutomationとPagerDuty Process Automationの次世代アーキテクチャーを最近リリースしたことで、私たちは、組織が現代のエンタープライズ向けにゼロトラストのセキュリティーアーキテクチャーを実装し、その中で成長するのを支援する理想的なパートナーとして位置付けられています。

詳細については、以下の記事をご確認ください。

ゼロトラストセキュリティーとは？

ゼロトラストセキュリティーは、場所に関係なく、本質的に信頼できるユーザーやデバイスは存在しないと想定することで、従来の境界ベースのセキュリティーアプローチに挑戦するモデルです。リソースへのアクセスを許可する前に、ID、デバイス、ネットワークトラフィックの継続的な検証と妥当性確認を重視します。多要素認証、きめ細かなアクセス制御、暗号化、監視によってこれを実現し、企業はデータ漏洩や不正アクセスのリスクを最小限に抑えられるのです。

従来の境界ベースのセキュリティーパラダイムを転換し、「誰も信用しない」アプローチを採用することで、ゼロトラストセキュリティーは、最新の自動化イニシアチブとシームレスに連携する全体的なフレームワークを提供します。さらに、世界がますます複雑になり、破産の脅威にさらされやすくなるにつれて、ビジネスの内部構造プロセスの進化にプラスの影響を与える可能性も含んでいます。

出典: https://www.microsoft.com/en-us/security/business/zero-trust

何が重要なのか？

ゼロトラストセキュリティーは、従来のセキュリティーモデルと比較して優れたアプローチであることが目立ちますが、その主な理由は、現代的な技術的考え方への根本的な転換と包括的な実装にあります。

内部ネットワークが本質的に信頼できるという前提に依存する境界ベースのセキュリティーモデルとは異なり、ゼロトラストセキュリティーは「誰も信用しない」という哲学を採用しています。厳格なアクセス制御、継続的な認証、あらゆるレベルでの厳格な監視を実施し、全てのユーザー、デバイス、ネットワークコンポーネントが信頼されない可能性があるものとして扱われるようにします。このアプローチにより、攻撃対象が大幅に減少し、ネットワーク内での横方向の移動が防止されるため、外部からの脅威と内部者のリスクの両方に対して非常に効果的です。

さらに、ゼロトラストセキュリティーは、コンテキストに基づいて権限を動的に調整する適応型アクセス制御を提供し、生産性を損なうことなくセキュリティーを強化します。強固な認証、暗号化、セグメンテーションを組み合わせることで、ゼロトラストセキュリティーは、高度な脅威から組織を強化する、全体的かつプロアクティブな防御戦略を提供します。そして、ダイナミックで相互接続された昨今のデジタルランドスケープの深い分野に最適な選択肢となるのです。

あらゆる規模の企業は、ゼロトラストのようなセキュリティーモデルを導入することで、以下のようなメリットを享受できます。

機密データの保護**:機密データの保護：ゼロトラストセキュリティーは、貴重なデータへのアクセスが厳格に管理・認証されることを保証し、不正アクセス、データ侵害、潜在的な財務的・評判的損害のリスクを低減します。 内部脅威の軽減** : ゼロトラストセキュリティーは、いかなるユーザーやデバイスも暗黙のうちに信頼されるべきではないと仮定することで、内部脅威のリスクに対処します。これにより、組織は潜在的なリスクを特定し、被害が発生する前に対処できます。 進化するサイバー脅威への適応** :従来のセキュリティーモデルは、内部ネットワークトラフィックが安全であることを前提として、境界ベースの防御に依存することがよくありました。しかし、高度な持続的脅威やゼロデイエクスプロイトなどの最新のサイバー脅威は、従来の防御を回避する可能性があります。ゼロトラスト セキュリティーでは、よりきめ細かなアプローチを採用し、継続的な監査、多要素認証、厳格なアクセス制御を導入することで、こうした進化する脅威から保護します。 リモートとモバイル ワークのサポート** :リモート ワークの増加とモバイル デバイスの使用増加に伴い、企業はネットワークとデータのセキュリティーを確保するという新たな課題に直面しています。ゼロトラストセキュリティーにより、企業はユーザーの場所やデバイスに関係なく、安全なアクセス制御を導入できます。この柔軟性により、従業員は強力なセキュリティー体制を維持しながらリモートで作業できるようになります。 コンプライアンスと規制の要件を満たす** :ゼロトラストセキュリティーの導入は、アクセス制御の実施、データの使用状況の監視、サイバーセキュリティーへのプロアクティブなアプローチの実証によって、組織がこれらの要件を満たすのに役立ちます。 顧客の信頼の構築** :今日のデータドリブンの世界では、顧客は個人情報のセキュリティーとプライバシーを重視しています。強固なゼロトラストセキュリティー対策を導入することで、企業は顧客との信頼を築き、機密データの保護とサイバーリスクの軽減に取り組む姿勢を示せるのです。

PagerDuty Process Automation + ゼロトラスト

デジタルトランスフォーメーションの取り組みは、ビジネスを迅速に拡張するためにクラウドテクノロジーに依存していますが、運用とクラウドインフラストラクチャーの自動化には、セキュリティーに関する新たな課題があります。主な課題は、SSHゾーンへの直接アクセスが廃止されたゼロトラストアーキテクチャーを義務付ける、制限されたアプリケーション環境で自動化を実行するために、エンジニアが最も安全なプロトコルを必要としていることです。

さらに、何百ものリモート環境と地理的な地域にわたって、優れたパフォーマンスを発揮する自動化をデプロイ・管理するには、多大なエンジニアリングの労力が必要です。最後に、回復力のある自動化ランブックの作成には時間がかかり、さまざまな複雑な環境で調整する際にエラーが発生しがちです。

PagerDuty Runbook Automationを使うと、エンジニアは、SSH ファイアウォール ルールに依存することなく、リモート環境内の強化されたRunners、または AWS SSMを通じて実行をトリガーする中央システムから自動化を実行できるようになります。

PagerDuty Runbook Automationは、ゼロトラスト原則を使用してタスクをリモート環境にディスパッチします。

新しいRunnersは、AnsibleやKubernetesのような一般的なプラグインを活用でき、エンジニアが多くのリモートのセキュアな環境をターゲットとし、各環境内でタスクが独立してルーティングされ実行される場所と方法を明示する新しいタイプのランブックを作成できます。これにより、パフォーマンス、スケール、フォールトトレランスが向上します。

PagerDuty Runbook AutomationとProcess Automationは、高いセキュリティー要件を持つお客様のために、SSHなどのポートをファイアウォールで開くことなく接続を可能にし、リモートオペレーションを可能にします。この新機能は、お客様が独自のbastionやジャンプホスト、パブリックエンドポイントを導入する必要性を減らすことで、オートメーションへのセキュアな接続を簡素化します。

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

PagerDuty Operations Cloudは、お客様が緊急インシデントのライフサイクル全体を管理できるようにするプラットフォームです。当社のお客様の多くは、インシデント対応チームを強化し、機能を成長および拡張するための主要な原動力として、Process Automationを活用しています。

緊急インシデントに起因する作業は、企業の収益や顧客へのサービス提供能力に影響を与えるため、先送りすることはできません。多くの場合、この作業は繰り返し行われるため、ファーストレスポンダーに委任できます。しかし、このようなインシデントの正確な診断と修復に必要な深いコンテキストは、本番環境に閉じ込められており、専門家の知識、スキル、アクセス権限が必要です。レスポンダーは、既に過労状態にある専門家にインシデントをエスカレートさせなければならないことがよくあります。これは、混乱が生じ、苛立たしい、反復的な作業となる可能性のある時間のかかるプロセスです。

インシデント解決プロセスの反復的で時間のかかるタスクを自動化することで、エンジニアは解放され、創造性と批判的思考が必要なより価値の高い活動に集中できるようになります。これにより、MTTRの短縮、顧客エクスペリエンスの向上、イノベーションの迅速化、収益の保護、収益性の向上につながります。

PagerDuty Automated Incident Resolutionは、あらかじめ構築されたカスタマイズ可能な診断と修復の機能を提供し、ファーストレスポンダーが本番環境内で原因を特定し修復を開始できるようにします。そのため、時間を節約し、対応を支援する人数を少なくできます。この繰り返しを自動化すると、MTTRが 25％高速化され、コストと中断が少なくとも 50％削減されます。

Automated Incident ResolutionによってMTTRがいかに短縮されるかをお客様に実感していただくため、先月、Runbook Automation for Incident ResolutionのIn-Product Trialを公開しました。このトライアルは、BusinessおよびDigital Operationsのお客様のみが利用できます。PagerDutyユーザーは、ウェブUIを使用して自動化タブからトライアルをリクエストできます。

アカウント所有者には、eメールで承認リクエストが表示されます。承認後、アカウント所有者はAutomation Actionsのトライアルを設定し、わずか数分で完全に機能するRunbook Automationインスタンスを取得できます。ユーザーには、オートメーションのオーサリングを開始するのに役立つ、以下のようなビジュアルガイドが表示されます： Runbook Automation (RBA) Instanceの作成、Runner（環境でオートメーションジョブを実行できるプログラム）の追加、Automation Actions （PagerDutyからオートメーションジョブとワークフローを起動できる）の追加、Actionsの実行（PagerDutyのインシデント詳細ページから）、オートメーションの出力の表示。

インシデント対応プロセスをさらに自動化・最適化するために、このトライアルを最大限に活用することをお勧めします。お客様より、Incident Resolution Automationの成功事例をお聞きできることを楽しみにしています。

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

2023年の初め、私は最近のウェビナーで、ForresterのPrincipal AnalystであるCarlos Casanova氏と、AIOpsが組織変革の成功をどのように促進できるかについての素晴らしい対談をしました。その内容によると、Carlos氏は、AIOps市場をテクノロジー中心（主にAPM/Observabilityプレーヤー）とプロセス中心の２つの陣営に分けたそうです。そしてPagerDutyは、複数のテクノロジーを活用したプロセス中心のソリューションです。

プロセス中心のAIOpsソリューションを使うと、組織はデータに関する追加のコンテキストと洞察を得られます。これにより、行動するまでの時間が短縮され、データ品質の向上、意思決定の強化、ルーティングと通知の効率の向上、そして最終的にはITが提供するサービスの価値が高まります。

このように、より大きなコンテキストでスピードを上げることができるため、重要なインシデントの時間を縮めることができるのです。注意すべき重要な点は、最初のルーティングは仮想オペレーターによって行われる可能性があるということです。つまり、自動化により追加のトリアージ／デバッグ情報が生成されたり、人間のレスポンダーが介入する前に修正が完了する可能性があるということです。

Carlos氏と私は、会話を通じて、対応者のためによりよいコンテキストを作り出すというテーマに何度も立ち返りました。AIOpsの中核的なユースケースを解決するために、どのような機能が最も重要だと考えているか尋ねたところ、彼は次のように答えました。「異なるアラート間の相関関係を迅速に特定することで、個人が対処しているノイズが大幅に軽減されます。影響を受ける全ての個人にこのクリーンなデータ信号を提供することは、業務を改善するために不可欠です。このデータがあれば、環境内で何が起きているのか、より簡単かつ迅速に把握できます。そして、取るべき正しい行動を迅速に決定し、迅速な修復のために誰が関与する必要があるかを決定し、必要な労力を減らして、他のイベントやアラートのために時間を確保できるようになります。

しかし、チームは往々にして開始に苦労します。私たちは、「待つことや計画することのコストは、おそらく、着手して反復することのコストに見合わない」ということに同意しました。同氏はさらに、「全体的な取り組みは困難に見えるかもしれませんが、すぐに達成できる可能性はあります。待つことはお勧めできません。小さな戦術的な取り組みから始めて、より大規模で長期的な戦略目標に積み上げて、進歩を示し、価値を実証し、勢いを築きましょう。」と付け加えています。

つまり、コンテキストを素早く取得し、自動化で素早く対応し、これらの勝利を見るためにすぐにプロセスを開始するという、スピードも継続的なテーマなのです。しかし、プレッシャーが増大し続けていることも私たちは知っています。

チームは、景気後退や減速の影響を受けています。チームが効率を上げ、成功を測定する方法について尋ねたところ、自動化が成功の鍵になると話しました。

Carlos氏は、こう答えました。「頻繁に発生する単純なシナリオは、その修復の全部または一部を自動化するのに最適な候補です。５～10個の単純なシナリオを完全に、あるいは部分的にでも自動化することで、組織は自動化することに抵抗があるような複雑なシナリオに集中するために、個人の時間を大幅に確保できるのです。」

しかし、プロジェクトでパフォーマンスを発揮する前のフォーミング、ストーミング、ノーミングも認識する必要があります。成功の測定方法や考え方にも変化があり、それを受け入れなければなりません。

「AIOpsは、IT部門のワークロードを軽減して、デリバリーチームが『より少ない労力でより多くのことを実行できる』ように支援することもできます。これらの変更により既存のメトリクスが無効になることに留意することが重要です。個人が単純で低レベルのアクションを実行しなくなるため、新しいベースラインを確立する必要があります。例えば、ある技術者が１週間に300件のインシデントを手動で解決しているとします。そのうち30件は単純なもので、簡単に自動化された修復が可能です。これらのインシデントのMTTRは90%低下する可能性があります。しかし単純なインシデントを排除しても、技術者が代わりに処理するのは中くらいに複雑なインシデント10件だけです。これは、技術者が１週間に処理するインシデントが20件減少することを意味します。技術者の平均MTTRは上昇し、インシデントはキューに長く留まり、中・高難易度のインシデントの比率が高くなります」とCarlos氏は述べています。

私が遭遇する最も一般的な質問の１つは、「どうやって始めればよいか」ということです。従来、AIOpsは何年もかかる可能性のある取り組みと見なされてきました。多くの不確実性と変化を抱えて旅を始めるのは気が遠くなるかもしれません。PagerDutyはイベントの相関関係をワンクリックで作成することでプロセスを大幅に簡素化し、チームがすぐに価値を見出せるようにしましたが、これでAIOpsへの旅が終わるわけではありません。

Carlos氏は、AIOpsを始めるに当たって、また、利用可能なOpExの減少に直面した際に得たインサイトをシェアしました。「予算は常に課題ですが、AIOpsの価値を実証し、明確に説明することで、そのハードルをある程度は克服できます。組織とのエクスペリエンス向上の価値を語る、ビジネスケースの物語を作成しましょう。強化されたコンテキスト関連データを使用してルーティングと通知を改善することで、同じ従業員がより少ない労力で、より多くのワークロードを処理できるようにする方法を実証してください。より経験豊富な上級スタッフメンバーに基づいた提案的なアクションが提供されるため、パターンと傾向によって下位レベルのリソースがより高度なアクションを実行できるようにする方法を説明します。これらのことは、組織が現在直面している経済的課題に対処し、提供する製品やサービスの質を向上させるのに役立ちます。組織は、選択したソリューションが迅速なタイムトゥバリューを持つことを示すのが重要です。例えば、ユーザーエクスペリエンスを向上させるために、ソリューションはトランザクションの完全な視覚化をどれだけ早くサポート担当者に提供して、停止を解決できるでしょうか?応答時間を短縮するには、ソリューションで環境を分析し、新しいアラートを即時または自動で処理できる単一のインシデントにどの程度迅速に関連付けることができるでしょうか？経済的に困難な時代には、タイムトゥバリューが非常に重要です。」

多くのお客様にとって、タイムトゥバリューはROIよりもさらに重要です。デジタルの戦場で勝者と敗者を分けるのはスピードです。避けられない問題にいかに早く対処し、改善を繰り返すことができるかが、チームを競合他社から引き離し、優れた顧客体験を提供することにつながります。

I&Oのリーダーは、経済的不確実性によりコストを削減し、より少ないリソースでより多くの成果を達成することを余儀なくされており、既存のリソースの拡張と最適化に役立つ新しいツールとアプローチを必要としています。AIOpsは、大量のデータとイベントを処理し、ルーティングと応答をリアルタイムで管理し、インシデントをより迅速に解決するための信頼できる方法をチームに提供します。ビジネスのこれらの課題に対処する方法を学ぶことに興味がある場合は、このウェビナーで、Carlos氏との残りの会話を聞いてみてください。

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

ビジネスを維持するには、運用アクティビティーを管理・調整し、影響の大きい緊急の作業を優先し、日々の精度を維持する必要があります。ミッションクリティカルで一刻を争う危機対応においては信頼が最も重要であり、エラーの許容範囲が狭いということは、生成AIの誤謬や誤検知の余地や許容度が低いことを意味します。

これが、PagerDutyのロードマップが常にユーザーの仕事を容易にするために設計されたイノベーション、つまり目的を持ったイノベーションに焦点を当ててきた理由です。PagerDutyは長年にわたりAIと機械学習に取り組んでいる、AIOpsの業界リーダーです。そして、PagerDutyが生成AIを評価したのはその視点からでした。生成AIそれ自体を目的とすることではなく、PagerDuty Operations Cloud全体でより多くの価値をどのように解き放つことができるかを自問したわけです。

コード作成の副操縦士からインシデント対応アシスタントに至るまで、生成AIは大きなチャンスをもたらします。生成AIの操作の容易さと優雅さ、つまり自然言語インターフェイスを通じた基本的な直観性により、自動化の可能性を最大限に引き出すステップ関数の機会が生まれます。自動化が生産性と能力を向上させながら時間とお金を節約する可能性があることに疑問の余地はありませんが、自動化の取り組みはそれ自体の抽象化の重みで消滅する可能性があります。

生成AIは、エンタープライズグレードの自動化に消費者スタイルのシンプルさをもたらし、自動化の可能性の実現をより現実的なものにします。ソフトウェア開発のペースはますます加速し、ソフトウェアが増えると複雑さが増し、DevOpsの重要性がこれまで以上に高まります。

ここでは、PagerDutyがPagerDuty Operations CloudにもたらすAIサポートの最初の3つの生成機能を共有します。

生成AIによるステータス更新

計画外に作業が中断された場合、解決にはコミュニケーションと調整が不可欠です。業界のベストプラクティスでは、対応方針を定めるために（少なくとも）30分ごとにステークホルダーとリーダーに定期的にステータスを更新することが推奨されています。しかし、これらのアップデートの作成には時間がかかり、チームのキャパシティーが既に急増しているときには、独自の認知的負荷がかかります。PagerDutyの顧客には、重大なインシデントが発生した際には、ステータス更新だけを担当する専任の担当者が3人いるケースもあります。

ここがPagerDutyの生成AI導入開始に最適な場所でした。ステータス更新機能に生成AIが統合されることで、チームは誰に何を言うべきかのサイクルを保存でき、数回クリックするだけでペルソナベースのステータス更新の下書きを生成できます。この新機能はAIを活用して現在のインシデントに関連する全てのデータを処理し、概要を自動生成して、イベント、進捗状況、課題に関する重要なインサイトを提供します。この機能により、インシデント管理ワークフローが強化され、時間を節約するだけでなくコミュニケーションが合理化され、チームは実際の解決作業に集中できるようになります。

生成AIによるインシデントポストモーテム

ポストモーテムはオペレーショナルエクセレンスの定番であり、サイト信頼性エンジニアリング（SRE）で推進されることが多いベストプラクティスです。これは、何が問題だったのか、どこを改善できるのか、そして最も重要なことに、同じ間違いを何度も繰り返さないようにする方法を知ることができます。

ただし、時間をかけてポストモーテムを文書化するのは難しい場合があります。グループレビューのために関連する全てのデータポイントを収集するのは、時間のかかる手動の（場合によっては感情的な）プロセスです。

しかし、仮想のチームメンバーが最初から最後まで事件を監視しており、そのチームの唯一の仕事がタイムリーで公平なポストモーテム報告書のドラフトを作成することだと想像してみてください。生成AIを適用して包括的なインシデント後の報告書ドラフトの生成を自動化することで、まさにそれが実現できます。

動画でも分かるように、インシデントが解決されると、ユーザーはポストモーテムレビューを生成して、ログ、メトリクス、および関連するSlackまたはMicrosoft Teamsの会話などのインシデントに関する全ての利用可能なデータの収集という時間のかかる作業を、リアルタイムでこなしてくれます。次に、主要な調査結果、根本原因、改善領域を強調した詳細なレポートが作成されます。さらに、PagerDutyは、今後同様の問題が発生するのを防ぐために調整された推奨アクション項目のリストを生成します。

この機能は時間を節約するだけでなく、重要な学習内容を把握するための出発点を提供し、継続的な改善の文化を促進し、チームが将来の校正にさらに多くの時間を費やすことができるようにします。ミッションクリティカルな作業において生成AIの力を解き放つためには、結局は人間が必要、というアプローチです。

上記のステータス更新の例と同様に、自動化されたインシデントポストモーテムでは、専門知識、判断力、監視力を提供する人が必要となり、レポートを広範囲に公開する前に検証して改良する必要があります。

生成AIによるプロセス自動化

PagerDutyは、PagerDuty Operations Cloudプラットフォーム全体で当初から自動化を使用しており、多くのパートナーと提携して、計画外の作業をより迅速に管理および解決できるワークフローを自動化するスクリプトとプラグインを提供しています。PagerDutyユーザーは、クラウドでもオンプレミスでも、インフラストラクチャーの自動化だけでなく、Ansible、Terraform、Power Automateの推進のために毎日PagerDutyを利用しています。ただし、スクリプトとツールがまだ存在していない場合は、実際にスクリプトをコーディングするという面倒な作業を自分で行う必要があります。

しかしそれもおしまいです。PagerDutyでは生成AIを使用して、ユーザーの自動化ニーズに対応する共同作成者を用意しました。これは、チームに追加の開発者がいて、やりたいことを実行する方法を研究し、自動化を作成する仕事をまかせられるようなものです。そして何よりも、お気に入りのスクリプト言語で実行し、ある言語から別の言語に簡単に移行できるため、最終的には完全に制御できます。PagerDutyは、パワーや柔軟性を失うことなく、これまでハイコードであったエクスペリエンスにローコード機能をもたらします。例えば、「特定のユーザーをOkta内のグループに追加する自動ワークフローを作成してください。実行時にメールとグループでユーザーを指定できるようにしてください」と生成ボタンを押して、魔法が起こるのを見てください。

PagerDutyは、生成AIが学習を加速し、労力を排除して生産性を向上させながら、より多くの創造性を発揮できるようになる旅の初期段階にいます。

新しいテクノロジーにはリスクが伴います。長年にわたってプラットフォーム全体にAI、機械学習、自動化機能を導入してきたように、そのリスクの適切な管理はPagerDutyのDNAに組み込まれています。だからこそ、「人間が関与する」ことがPagerDutyのAI研究における中心的な理念となっているのです。だからこそ、迅速に取り組んでいながらも、PagerDutyでは忠実性、セキュリティー、正確さの原則を念頭に構築に取り組んでいます。

可能性は無限です。皆様からのフィードバックやご意見をお待ちしております。最も重要なことは何でしょうか？　これらの機能のウェイティングリストに登録して、開発の最新情報を入手してください。今後数力月以内にこれらの機能のリリースを開始する予定です。

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

Capturing Application StateとEphemeral Containers for Debugging Kubernetesに関する以前のブログでは、特定のツールを導入して後の分析のために診断を収集する一方で、インシデントの対応者にインフラやアプリの問題を解決する手段を提供できることの価値について説明しました。

これにより、サービスをできるだけ早く復旧させる必要性と、後の恒久的な解決のために十分なデバッグデータを確保する必要性のバランスがとれ、同時に開発チームはコンテナを無駄なく、パフォーマンス高く稼働させられます。

インシデント発生時にアプリと環境の両方の状態をキャプチャーすることで、レスポンダーやサービスオーナーがツール、認証情報、環境の間でコンテキストを切り替える時間を短縮し、より正確で迅速な対応と問題解決を可能にします。

このシリーズの以前のブログでは、Kubernetesのような最新のクラウドネイティブなプラットフォームや、コンテナ、特にデバッグツールがネイティブに搭載されていないコンテナに必要な独自のアプローチに焦点を当てた技術を説明しました。

全てのアプリをクラウドネイティブに移行できるわけでもなく、多くの人がコンテナ化されたアプリと従来のアプリの両方のハイブリッドシナリオの中で仕事を続けています。

コンテナの一時的な性質やコンテナイメージの厳格なポリシーを抜きにしても、将来のインシデント発生を回避するため、根本原因分析に役立つ瞬時の証拠を取得する必要性があることは確かです。

障害発生時やパフォーマンス低下時に自動的に状態をキャプチャーする機能を説明するユースケースを確認し、興味深いシナリオをピックアップして深く掘り下げてみましょう。

これは網羅的なリストではありませんが、従来のアプリ環境でデバッグ状態キャプチャーがどのように使用されているか、いくつかの例をご紹介します。

インフラとネットワーク

１つまたは複数のインフラ・コンポーネント上でリソースを消費するトッププロセス TCPダンプ、スレッド／メモリ／コアダンプ

データベース

最も多くのリソースを消費するクエリー 現在のクエリーの状態 アプリ固有のクエリーの実行

アプリ固有

Java – jstackなどのツールでスレッド／ヒープダンプを実行する Windows – Proc Dump Python – スレッドダンプの実行 全て – アプリ固有のログファイル

追加のログファイル

デバッグ状態のキャプチャーは、ログアグリゲーターによってキャプチャーされない可能性のある任意のファイルから、全体または一部のログを取得できます。

PagerDuty Process Automationは、自動診断プロジェクトの一環として、アプリと環境の状態をキャプチャーするための多くの事前構築されたテンプレートワークフローを提供します。これらのワークフローは柔軟で拡張性があるため、特定のユースケースに対応するようにカスタマイズすることが可能です。

さらに深く掘り下げる

ここでは、インシデントの長期的な解決策を特定するために役立つ、環境状態のキャプチャーの具体的な例について詳しく見ていきましょう。

ユースケース１– データベースのデバッグを収集する

Process Automationの SQL RUNステップを使用して、インラインステートメントを追加するか、既存のスクリプトを実行できます。私のアプリはMariaDB（MySQLのフォーク）なので、MySQLクエリー実行のために以下のパラメータを使用できます：

SHOW FULL PROCESSLIST;

（注：クレデンシャルは既存の外部ストアから取得され、ワークフローの一部としてステップを実行するときに安全に渡されるため、情報を公開することなく安全に委譲できます）

その出力をインシデントプラットフォーム（私の場合はもちろんPagerDuty）に渡し、データベースサービス内でインシデントが発生した場合に自動的に収集するようにジョブを設定しています。

この情報は、アプリ、Chatops ツール、またはポストモーテム内で、私のレスポンダーの両方が自動的に利用できるようになりました。この場合、誰かがインシデントの時点でベンチマークテストを実行しているのが分かります！また、以前のブログ記事と同様に、より複雑なバージョンをAWS S3 Bucketのようなストレージ環境に投稿し、後で分析することも容易でしょう。

ユースケース２– アプリのデバッグを収集する

私の可観測性ツールは、アプリがいつ失敗したかをすぐに知らせてくれますが、失敗した理由については必ずしも情報を提供するとは限りません。この２つ目のユースケースは、私のpythonアプリのアドホックコマンドを実行して、私のアプリのサンプリングプロファイラーであるpy-spyを、当社の自動化プラグインの１つと組み合わせて、後で取り出すためにファイルをS3に安全に移動するものです。

データをS3ストレージに直接出力します。

この例では、私のpythonアプリのワーカーの状態をスレッドレベルでハイライトし、そのまま開発者の手元に届き、参照する必要がある限り保存されます。

もちろん、これらのコマンドは排他的なものではなく、複数のチェックを連鎖させてより広範なビューを提供することも簡単にできます。

ユースケース３– 従来のインフラのデバッグ状態のキャプチャー

３つ目のユースケースでは、一連のbashコマンドをリモートマシンにデプロイし、トリガーイベントで再び実行する必要があります。これは主に、開いているファイルやネットワーク接続などの診断を表示しますが、特定の呼び出しをトレースするために使用できるツールbpftraceも実行します：

Process Automationでは、スクリプトを定義してデプロイし、その出力を保存して、環境の状態のスナップショットを収集できます：

結論

監視ツールからの信号は、従来の環境であっても、幅広い可視性の恩恵を受け、レスポンダー、DevOps エンジニア、または SRE が迅速かつ安全な意思決定を行えるようになります。また、開発者がすぐに取り掛かれないこともあり、問題が発生したときに追加情報や状態をキャプチャーする機能が必要になるケースも多々あります。

Debug State Captureは、レスポンダーに追加のコンテキストを提供し、さまざまなツールを使いこなす時間を短縮し、その後の分析のためにより深いデータセットを収集する機能を提供します。

もっと詳しく知りたいですか？今すぐRunbook Automationのトライアル版を始めましょう。

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

PagerDuty REST APIは、ユーザーがPagerDutyプラットフォーム内のオブジェクトやワークフローにプログラムでアクセスするための200以上のエンドポイントをご提供します。チームはこれらのAPIを活用し、ユーザー、チーム、サービス、その他環境のコンポーネントの作成と管理を効率化します。

これまで、REST API へのアクセスはAPIキーを介して認可・認証されてきました。これらのキーはWeb UIで管理され、アカウント内のオブジェクトにオール・オア・ナッシングでアクセスできるため、多くのチームにとっては寛容すぎるものでした。そこでPagerDuty Engineeringは、OAuth2.0 Tokensで使うAPIスコープの総合セットを作ることに取り組んでいます。

PagerDuty REST APIの各オブジェクトには少なくとも１つのスコープであるreadがあり、多くのオブジェクトにはwriteもあります。アプリがアカウントの他の全てにアクセスできるかどうかを心配することなく、正しく動作するために必要なアクセスだけを持つように調整できるようになります。

現在APIキーを使っている人は、当分の間APIキーを使い続けることができます（将来的には廃止される可能性があるのでご注意ください）が、Scoped OAuthに移行することで、チームがアクセスを管理し、最小特権の原則を守ることができます。

API スコープの紹介ビデオについては、YouTubeチャンネルのこのビデオをご覧ください。

アプリをセットアップする

スコープによるAPIアクセスを設定する際に最初に気付くのは、アクセスがアプリで管理されるようになったことでしょう。これらは、「Integrations」メニューの「API Access Keys」セクションで管理することはできません。代わりに「App Registration」（以前は「Developer Mode」として知られていました）にアクセスし、アプリの設定プロセスを進める必要があります。これらの設定は、アカウントの管理者と所有者に限定されています。

アプリを作成する際に、Scoped OAuthを追加するオプションがあります：

Scoped OAuthをサポートするアプリの場合、次のダイアログで、このアプリのアクセスに由来するTokenが使えるようにするオブジェクトを選択できます。ユースケースに応じて、必要なだけ選択できます：

Saveをクリックすると、このアプリアクセス用のトークンをプロビジョニングするために使用されるClient IDとClient Secretという２つの重要な情報を含むポップオーバーウィンドウが表示されます。

トークンのプロビジョニングに必要なので、証明書やパスワード、シークレットに使っている金庫などの場所やアプリに保管しておきましょう。

スコープの検索

上記の画面キャプチャーから分かるように、APIを介してアクセスされるオブジェクトに応じて、トークンが必要とする可能性のあるスコープが多数存在することになります。

幸いなことに、 APIドキュメントが更新され、全てのオブジェクトエンドポイントに必要なスコープが含まれています。各タイプのリクエストには、スコープと、リクエストに読み取りアクセスと書き込みアクセスが必要かどうかを含むメモが付いています。大まかには、情報の一覧表示や取得に使われるGETメソッドによるリクエストは読み取りアクセスのみ、PUT、POST、DELETEリクエストは書き込みアクセスが必要です。

トークンのリクエスト

アプリ内のScoped Clientに関連付けられたトークンは、アプリの作成時に受け取った認証情報を使用して、https://identity.pagerduty.com/oauth/token から要求されます。リクエストの形式は、こちらのAPIドキュメントに記載されています。その他の必要なデータは、地域（USまたはEU）とサブドメイン（youraccount.pagerduty.com）です。リクエストする各トークンは、どのスコープで有効になるかを指定する必要があります。

curl -i --request POST \

https://identity.pagerduty.com/oauth/token \

--header "Content-Type: application/x-www-form-urlencoded" \

--data-urlencode "grant_type=client_credentials" \

--data-urlencode "client_id={CLIENT_ID}" \

--data-urlencode "client_secret={CLIENT_SECRET}" \

--data-urlencode "scope=as_account-us.companysubdomain incidents.read services.read"

トークンに含まれるスコープは、組織が希望するトークンの管理方法に応じて、アプリに含まれるスコープの完全なセットにすることも、それらのスコープのサブセットにすることもできます。トークンは JSONドキュメントで返されます。

{

"access_token": "pdus+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",

"scope": "as_account-us.companysubdomain incidents.read services.read",

"token_type": "bearer",

"expires_in": 2592000

}

これらのトークンには有効期限があります。これは、無期限のAPIキーからの大きな変更です。トークンは30日ごとにローテーションする必要があります。

さらに、トークンがチェックインされていないことをリポジトリースキャナーで確認できるように、各PagerDutyトークンは「pd+」で始まるので、トークンが簡単に識別できるようにpdus+またはpdeu+のどちらかになります。

トークンが作成されたら、それをどのように配布・管理するかはユーザー次第です。トークンはWeb UIにはリストされず、プラットフォーム上でも入手できません。アプリページ内から、アプリに関連付けられた全てのトークンを取り消すことができますが、個々のトークンを取り消すことはできません。

トークンの使用

カスタムスクリプト経由で API にアクセスしている場合は、新しいトークンを使用するためにいくつかの更新を行う必要があります。

curlやwgeなどのコマンドラインツールを使ってhttpsリクエストを行うシェルスクリプトの場合、Authorizationヘッダーを更新する必要があります：

--header "Authorization: Bearer $TOKEN"

同様に、Postmanなどのツールでは、AuthorizationをBearerトークンに設定する必要があります。Postmanでこれを行う方法の詳細については、 Postmanのドキュメントを参照してください。

PagerDutyのAPI用のさまざまなクライアントライブラリーのいずれかを使用している場合は、それらのプロジェクトのドキュメントを確認して、コードの変更が必要かどうかを判断してください。例えば、pdpyrasでは、OAuth2.0トークン専用のセッションコンストラクターが使用できます。

REST API v2 with an OAuth2 access token:

session_oauth = pdpyras.APISession(OAUTH_TOKEN, auth_type='oauth2')

お使いのプログラミング言語によっては、より洗練されたソリューションやOAuth2.0トークンのサポートが利用可能な場合があります。 また、開発者サイトのドキュメントには、複数の言語用のサンプルコードが含まれています。

トークンとアプリの管理

アプリとトークンの粒度をどのように設計するかは、あなたと組織のセキュリティー要件次第です。始めるのに役立ついくつかの推奨方法があります。

トークンのプロビジョニングをするのは？

Scoped OAuthトークンは30日間の有効期限があるため、PagerDuty APIにプログラムでアクセスするチームが多い組織では、Client IDとClient Secret 各チームと共有し、各自でトークンを用意するほうが簡単でしょう。管理者は、チームやアプリケーションの種類ごとにアプリを作成し、誰がAPIにアクセスし、どのオブジェクトにアクセスできるかを制御できます。

小規模なチームや、リソースへのアクセスをより詳細に管理する必要がある場合は、Client IDとClient Secretをアカウント管理者に保持させ、管理者がトークンを作成し、安全なストレージを介してチームに共有するとよいでしょう。

完全なスコープのアプリ、限定されたスコープのトークン

多くの異なるオブジェクトへのアクセスが必要となるユースケースの場合、全てのコープを含めるようにアプリをプロビジョニングできます。トークンは、許可された全てのスコープのサブセットで要求できるため、個々のトークンは、クライアントアプリケーションがAPIで使うものだけに制限できます。

この方法により、PagerDutyアカウントで管理する必要があるアプリの数を減らすことができます。管理者は、チームまたは部門にアプリをプロビジョニングし、より限定された範囲のトークンを提供できます。

ぜひお試しください

Scoped OAuthは、現在アーリーアクセス機能として提供されており、2023年5月末には全てのアカウントで一般利用できるようになる予定です。ぜひお試しの上、ご意見をお聞かせください。https://pagerduty.digitalstacks.net/free-trial-2/?from-blog からアーリーアクセスにお申込みいただくか、担当者までお問い合わせください。コミュニティーフォーラムに参加して質問することもできます。

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

分散したチームがインシデントを管理するために使用するツールの数は年々増加し、ツールのスプロールにつながっています。手動プロセスを投入すると、多大な労力と複数の障害点が発生します。バラバラのツールやシステムを維持することは、扱いにくいだけでなく、コストもかかります。

PagerDuty Operations Cloudに追加された最新機能により、チームがインシデント管理スタックをこれまでより簡単に統合できるようになりました。Incident Workflows、Custom Fields on Incidents、Status Update Notification Templatesに導入される新しいイノベーションは、組織が手動の事後対応状態から、よりプロアクティブで予防的なインシデント対応アプローチに移行するのにさらに役立ちます。

これらの機能を統合的に使用することで、相乗効果が生まれ、比類ないレベルの業務効率化とビジネスの加速を実現します。この相互運用性は、PagerDuty Operations Cloudが、サードパーティーのツールや自前のソリューションを必要とせず、統一されたプラットフォーム上でインシデントの発生から解決までを管理できるようにするための中核となるものです。では、何が新しくなったのか、詳しく見ていきましょう。また、製品ツアーでぜひ、ご自身の目でアップデートを確認してみてください。

インシデントデータを強化するためのCustom Fields

更新メッセージを一から手作業で作成するのではなく、ステータス更新の作成方法を自動化することで、効率性と一貫性を高められます。レスポンスチームは、「Business Impact」、「Conference Bridge」、「Slack Channel」など、テンプレート内の拡張されたフィールドのセットにアクセスできるようになりました。テンプレートは間もなくカスタムフィールドもサポートする予定です（アーリーアクセスにサインアップしてください）。これらの新しいフィールドは、レスポンスチームがステークホルダーへのコミュニケーションに、目下のインシデントに関する重要なコンテキストを追加するのに役立ちます。また、Incident Workflowsのワークフローアクションの一部としてテンプレートからコミュニケーションを作成することもできます。

ステークホルダーコミュニケーションのために強化されたテンプレート

更新メッセージを一から手作業で作成するのではなく、ステータス更新の作成方法を自動化することで、効率性と一貫性を高められます。レスポンスチームは、「Business Impact」、「Conference Bridge」、「Slack Channel」など、テンプレート内の拡張されたフィールドのセットにアクセスできるようになりました。テンプレートは間もなくカスタムフィールドもサポートする予定です（アーリーアクセスにサインアップしてください）。これらの新しいフィールドは、レスポンスチームがステークホルダーへのコミュニケーションに、目下のインシデントに関する重要なコンテキストを追加するのに役立ちます。また、Incident Workflowsのワークフローアクションの一部としてテンプレートからコミュニケーションを作成することもできます。

Incident WorkflowsとServiceNow、Jira Serverとの統合

ITSMツールの有効性と効率性を向上させましょう。PagerDutyのお客様は、ServiceNowインシデントレコードとJira問題レコードからPagerDuty Incident Workflowsを実行できるようになりました。これは、顧客が既に働いている場所から強力なワークフロー自動化にアクセスできることを意味します。この機能は、v7.9 ServiceNowアプリ（Utah認定）、v4 Jira Serverで利用できるようになりました。詳細については、ServiceNowとJira Serverの統合に関するKB記事をご確認ください。

拡張されたIncident Workflowアクション

Incident Workflowsを使ってインシデント対応プロセスの手動ステップを自動化することにより、運用コストを削減します。本日、Incident Workflowsで自動化できるPagerDutyの機能の範囲をさらに拡大する、Q2に開始予定の新しいアクションのセットを発表します。これらには、Automation Actionsの実行、Status Update Notification Templatesを使ったステータス更新の送信、Microsoft Teams会議またはチャネルの作成、インシデントへのメモの追加、インシデントの再割り当て、インシデントの優先度の変更が含まれます。

結論

本日の発表では、PagerDutyが、お客様がインシデントをエンドツーエンドで管理できるようにすることで、収益へのリスクを軽減し、労力を最小限に抑えられるように、製品や機能を設計している方法のいくつかをまとめています。私たちの製品は、行動するためのプラットフォームとしてまとまっており、チームが重要な作業を自動化し、加速することを可能にし、最終的にオペレーションを変革し、ビジネスをより速く前進させられるのです。PagerDuty Operations Cloudの威力は、製品群全体のシームレスな統合によってもたらされる相乗効果にあり、これらの機能が協調して機能することで、よりプロアクティブで予防的なプロセスを採用する障壁が低くなります。

最新リリースについての詳細は、発表ウェビナーにご登録ください。当社の製品チームが、これらの機能について詳しく説明し、デモを行います。

最新の機能を実際にご覧いただくには、製品ツアーをご覧ください。

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

時間とお金を節約することは常に重要ですが、最近では、ミッションクリティカルなビジネス上の義務となっています。PagerDutyでは、組織が効率性の変革的な向上を実現し、即時的な財務上の影響と長期的なビジネスの成功の両方を推進できるよう支援します。

PagerDutyは、運用の成熟度のどの段階においても、あらゆる組織に明確な価値を提供します。

10人のチーム当たり年間35万6000ドルの節約 解決時間70%短縮 ROI 795% 回収期間2力月

※IDC Business Value White Paper「PagerDuty Helps Organizations Optimize Their Digital Operations Management」#US47011820（PagerDuty後援、2021年1月）

以上をそのまま信じる必要はありません。お客様の実体験が雄弁に物語っています。PagerDutyが世界の業界リーダーにどのように価値を生み出しているかを示す例をいくつか紹介しましょう。

SAPがPagerDuty導入で得た価値

SAPはエンタープライズアプリケーションソフトウェアのマーケットリーダーです。また、世界のトランザクション収益の4分の3以上がSAPシステムに関係しているため、稼働時間は非常に重要です。

SAPはビジネスをデジタル変革し、顧客対応サービスをクラウドに移行する必要がありました。また、顧客エクスペリエンスに影響を与え、収益を危険にさらす可能性のある影響の少ないインシデントが確実に減少するようにする必要もありました。

特にSAPの規模を考慮すると、このタスクは当初、「言うは易く行なうは難し」のように思われていました。多くのチームは、組織全体に拡張できないカスタムの社内ツールを使用していました。特定のサブプロセスが急速に動いている自動化の「島」がありましたが、この加速は大規模には起こっていませんでした。ビジネスユニットやグローバルシアター全体にわたって非常に多様なツールとプロセスが存在することも、コラボレーションを特に負担にしていました。

SAPのGlobal Cloud Servicesチームは現在、PagerDutyを使用して重大なインシデント対応を調整しています。PagerDutyは、チームとステークホルダー間のコミュニケーションの改善を支援し、インシデントのステータスに関するリアルタイム情報を提供し、多くの場合、応答時間を数時間から数分に短縮しました。

PagerDutyは、SAPがわずか数力月で以下のような驚くべき成果の達成に貢献しました。

重大なインシデントに必要な対応者の数を25%削減 応答時間を30%短縮 解決時間を26%短縮 チーム間のコラボレーションとサービスオーナーシップの向上 さまざまな外部ツールや社内ツールとのシームレスなインテグレーション

SAPのグローバルクラウドサービスチームがどのようにオペレーショナルエクセレンスを向上させたかについて詳しくは、こちらをご覧ください。

Brink’sがPagerDuty導入で得た価値

Brink'sは資金管理の有名なリーダーであり、100カ国以上の顧客にサービスを提供する16000台以上の安全なトラックを運営しています。テクノロジーは資金を動かし続けますが、数年前、同社はビジネスを成長させるにはテクノロジーのアップグレードが必要であることに気付きました。

チームはワークフローを手動で管理し、反復的で日常的なタスクに多大な時間と費用を費やしていました。さらに、IT環境に変更を導入する試みには時間がかかり、一貫性もありませんでした。そして、Brink'sはPagerDutyに助けを求めました。

PagerDuty Process Automationは、労力を軽減し、より迅速な導入と移行を促進することで、その価値をすぐに実証しました。これにより、ビジネスに機敏性、拡張性、コスト削減をもたらしながら、従業員の生活が楽になりました。同社は、エンジニアが仮想マシンをプロビジョニングするのにかかる時間を短縮するなど、PagerDutyを活用した自動化を他のステークホルダーやサービスにもさらに拡大しました。

使いやすいソリューションを選択し、十分に文書化されたプロセスを自動化することで、Brink’sのチームはすぐに価値を実現し、次のような迅速な投資収益率を実現しました。

手動ミスのリスクを軽減しつつ、手動タスクに費やす時間を99%削減 年間500以上のFTEエンジニアリング時間を削減 セルフサービスの自動ワークフローにより、開発者の待機時間を2週間から3分に短縮

Brink’sが自動化をどのようにうまく活用してビジネス、ひいては顧客の継続的かつ反復的な改善を推進したかについて詳しくは、こちらをお読みください。

コストを削減し、成長を加速

PagerDuty Operations Cloudは、組織が重要な作業を予測、自動化、加速し、運用を変革できるようにするためのアクションプラットフォームです。チームが優先度の高い作業に集中し、運用コストを大幅に削減し、イノベーションと成長を根本的に加速できるようにする重要なインフラストラクチャーとなります。

SAPとBrink’sの成果は、PagerDutyが時間とコストの節約にどのように役立つかを示しており、その価値はあらゆる規模と業界の顧客に当てはまります。

PagerDutyが時間とお金の節約にどのように役立つかについて無料トライアルにサインアップしてください。

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

「The Last of Us」を見たことがある方は多いでしょう。この番組は同名のゲームに基づいています。Pedro Pascal（『The Mandalorian』より）と彼の最新の代理出産であるBella Ramsey（『Game of Thrones』より）が登場します。その冒険はさまざまな理由から困難を伴います。最も注目すべきはゾンビです。2003年、真菌の冬虫夏草が世界的なゾンビの蔓延を引き起こしました。20年後、少数の人類が残された世界で耐え、生き残ろうとしています。シーズン1をまだ見ていない人はネタバレに注意。生存は難しく、ゾンビは恐怖です。

インシデント対応が生死に関わることはほとんどありませんが、この番組を見ているようなアドレナリンの急増につながる場合があります。そして、あなたが直面するかもしれないインシデントの中には、これまで「The Last of Us」で見てきたゾンビと類似したものもあります。これらのインシデントには、あらゆる困難を乗り越えて生き残るのに役立つ「ヘッドショット」があります。

ランナー

「The Last of Us」で最初に登場するゾンビはランナーです。ゾンビになりたてで、長期間感染したものと比較すると、まだ人間のように見えることがあります。殺すのは簡単ですが、彼らを危険にしている要因が1つあります。それは、ゾンビになりたてのため予期できないということです。2003年の世界終末を生きていた人々にとって、ゾンビは単なるフィクションにすぎず、（Billを除いて）誰も世界の終わりに備えていませんでした。2023年を待ち望んでいる人々にとって、ランナーは不愉快な存在です。彼らは通常、あなたが知っている人たちで、エピソード5の終わりで見たように、急に発症します。

これをインシデントに例えると、どこからともなく起こる、稀な、または異常なインシデントです。システムは問題ないのに、「どうして見逃してしまったんだろう？」と思うことでしょう。あなたならどうしますか？　ノイズの中から何か問題が起こっていることを知らせるサインを探しましょう。感染者の場合、けいれん、咳、または予期せぬ気分の変動が起こる可能性があります。

インシデントにも同様の警告サインがあります。レイテンシーが少し高いですか？　それだけでは何でもないかもしれません。しかし、速度の遅さに関する苦情の増加に気づいたカスタマーサポートと組み合わせると？　ランナーがいるかもしれません。モニタリングだけでは限界があり、機械と人間の両方からのデータを理解する必要があります。データをエコシステムの変化と関連付けることで、ランナーに噛まれる前に攻撃することができます。

ストーカー

あなたの家の庭でうようよしているようなゾンビです。特に強いわけではなく、発見も難しくないので、倒すのはそれほど難しくありません。廃墟と化したガソリンスタンドの地下に行くつもりですか？　もちろんストーカーがいるでしょう。空っぽのショッピングモール？　そう、知っていたはず、EllieとRileyです！　ストーカーとの遭遇は決して楽しいものではなく、危険な場合もありますが、大抵は普通のプレーヤーならストーカーには対処できます。しかし、一度に数人のストーカーが現れた理、同じ日に12体のストーカーと立て続けに遭遇したり、毎日2～3人のストーカーと一年中戦っていたらどうなるでしょうか？

もう分かりますよね。ストーカーは拷問のようなものです。絡まなければならないほど危険が増すような、最も一般的なインシデントのようなものです。避難訓練とも違い、迷惑千万です。1回だけなら大したことはありませんが、毎日1回はキツいです。すぐにまた修正する必要があるものをその都度修正する作業は、とても付加価値の高い作業とは呼べません。

JoelとEllieの世界では自動化は実現できません。しかし、ゾンビのいない私たちの生活では、インシデント対応をより効率的にすることができます。よくある問題や頻繁に発生するインシデントの場合、人間の介入なしで問題を解決する自動修復機能を作成すると、すぐに解決できます。これは、組織内で自動化の取り組みを推進するための優れた方法でもあります。小さいながらも頻繁に発生する問題の解決は、ROIにダイレクトに貢献します。これを活用して、他の種類のインシデントに対する自動化の取り組みも進めることができます。

クリッカー

クリッカーは、倒すのが難しい不気味で執拗なハンターです。彼らは目が見えないので、ソナーを利用して獲物を狩ります。頭が硬い殻で覆われているため、ヘッドショットは通用しません。彼らは「The Last of Us」で最も恐れられ嫌われているタイプのゾンビの1つです。インシデントに遭遇したときに、通常の解決策が期待通りに機能しないことを想像してみてください。しかも敵は非常に危険です。

番組でもクリッカーを殺すのはほぼ不可能と思われるため、これをインシデントと関連づけるのは最も難しいかもしれません。見つかる前に逃げるが勝ちですが、インシデントの場合はそうもいきません。このゾンビがインシデントだとしたら、まだ2〜3人しか実際に遭遇したことのないヤバいヤツです。聞いたことだけはあるような、技術スタックの奥深くに潜んでいるものです。このインシデントについて知っている人がクラスにほとんどいなかったりすると、一度発生すると、実際よりも巨大な問題のように感じられます。

クリッカーの首にナイフを突き刺すように、この種のインシデントには解決策があります。そして、成功の鍵はやはり知識と計画です。クリッカーの頭に鎧があることが分かっているなら、首を狙いましょう。接近戦ですが効果的です。そして、十分な人数がクリッカーから生き残れば、その知識を広げることができます。

インシデントの場合、クリッカーを修正する最良の方法は、ドキュメント、ランブック、およびコンテキストの履歴です。誰かが問題を解決する方法を知っています。その知識を共有すれば、チームはプロセスを文書化し、次回この恐ろしい（ただし修復可能な）問題が発生したときのランブックを作成できます。さらに、チームはAIを利用して過去のインシデントデータを参照できます。類似したインシデントからは、学びがたくさんあります。過去のインシデントデータから、インシデントに対して何が機能し、何が機能しなかったかを理解することができます。AIのサポートがない場合でも、常に履歴に目を通し、コンテキストを確認しましょう。全ての情報を一元管理して、誰もが参照できるようにすることも大切です。発生する全ての問題を解決する方法は分からないかもしれませんが、その知識は見つけられるようになります。たとえ完璧な「ヘッドショット」がなかったとしても、大きな武器になるでしょう。

ブローター

ブローターは、ある時点では人間だったものというよりも、「Stranger Things」のデモゴルゴンに似ています。彼らは力ずくで、または手榴弾のように空中に投げる有毒な菌の塊によって、近くにいるほとんどの人々を殺しまくります。これまでのところ、「The Last of Us」では1体だけを見たことがありますが、非常に強烈で、カンザスシティーの戦闘人口のほとんどを殲滅していました。ブローターとの遭遇は何としても避けるべきです。兆候があれば、問題が悪化する前に早期に対処する必要があります。ゾンビがトンネルを埋め尽くしているのに、反乱軍が他の対応で手いっぱいだった様子を覚えていますか？　誰かが修正する必要がある技術的な積み残しだったのです。

現実はそんなものです。例え発生メカニズムが正確に分からなくても、問題があることは分かっていて、このままではブローターという大きなインシデントが起きてしまいます。これに対処する最善かつ唯一の現実的な方法は、エンドツーエンドのインシデント対応フローの調整です。次のようなインシデント対応の主要なコンポーネントを必ず理解してください。

エスカレーションポリシー インシデント発生時の役割と責任 内部と外部の両方の通信標準 対応者の重労働を軽減するワークフローの自動トリガー

計画を立てることで、よりスムーズに、より迅速に、顧客への影響を少なくしながらインシデントを解決できるようになります。

あなたが一番恐れているゾンビはどのタイプですか？　あなたを夜遅くまで対応に当たらせているのはどれですか？　迫り来るブローターでしょうか、あるいは続々と舞い込むストーカーに関する通知でしょうか？　「The Last of Us」ではゾンビに対する治療法は見つからないかもしれませんが、テクノロジーインシデント対応をより簡単に、自分と顧客にとって悲惨なものにしないようにすることは十分可能です。

PagerDutyは、デジタル業務の改善を支援します。現在どのような課題に直面しているとしても、あなたが単に生き残るだけでなく、克服して成長できるよう支援します。詳細についてはお問い合わせください。

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

PagerDutyの社会的影響部門であるPagerDuty.orgでは、ミッション主導型のチームがより公平な世界と持続可能な未来を構築できるよう支援しています。PagerDuty.orgの慈善活動、技術的プロボノ、および製品サポートプログラムについて書きましたが、今日は、PagerDuty.org基金を通じて当社全体の社会的影響力のあるリーダーに提供しているユニークなプログラムについてさらに詳しく共有したいと思います。PagerDuty.org基金の目的は、公平な世界のビジョンを推進することであり、これは、資金提供先の組織の種類やそのリーダーによってのみ行われるわけではありません。PagerDuty.orgの資金調達慣行、特に慈善活動資金を割り当てる際に誰に発言権と意思決定権を与えるかは、PagerDuty.orgのビジョンの実現において同様に重要な役割を果たします。

PagerDutyでは、従業員リソースグループ（ERG）のリーダーと地域コミュニティーの社会的影響リーダーが、影響力のある顧客とコミュニティーパートナーをサポートすることで、全社にわたる集団的な影響力の推進に貢献しています。2019年以来、これらのリーダーにリソースを提供して、地域のコミュニティー中心のパートナーシップを構築し、PagerDutyの従業員（俗にデュートニアンと呼ばれます）をコミュニティーに還元する有意義な機会に参加させてきました。2022年に、私たちは社会的影響を与えるリーダーたちにコミュニティー補助金として割り当てるために、寄付者からアドバイスを受けた基金から6万ドルを割り当てて、このプログラムを正式に正式に決定しました。当社の資本フレームワークと補助金交付慣行に沿ったパートナーの選択をサポートするために、トレーニング、ツール、テンプレートを設計し、主導しました。年末までに、PagerDutyのソーシャルインパクトリーダーの85%が、顧客を擁護するという当社の文化的価値観に根ざしたパートナー中心のアプローチを適用することで、世界中の12の組織に資金を割り当てました。これは、ユーザーを第一に考え、ユーザーが簡単に利用できるようにすることに重点を置いています。PagerDuty.orgと提携してください。

意思決定権を共有して公平性を高める

PagerDuty.org基金は当社のPledge 1%株式コミットメントによって資金提供されており、世界中のデュートニアンが当社の成功を推進することでPagerDutyのインパクトファンドの価値に貢献しています。慈善活動の資金がどこにどのように振り向けられるかについて彼らに発言権を与えることは、慈善活動において公平性と権力の共有を実践する方法の1つです。PagerDutyのインクルージョン、ダイバーシティ、公平性（ID&E）チームと緊密に連携して、このプログラムを構築しました。「当機関のERGリーダーが、彼らがサービスを提供する層をサポートする組織と長期的なパートナーシップを確立できるようにすることで、私たちは影響範囲の拡大と、有意義な変化を促す動機の拡大に貢献します。このプログラムは、新興リーダーの企業リソースへのアクセスを増やすことで、#TakeTheLeadに対する当社の文化的価値を体現しています」とPagerDutyのシニアID&Eプログラム マネージャーのCarmel Ulbrickは述べています。

コミュニティーパートナーにスポットライトを当てる

昨年、デュートニアンの社会的影響力のリーダーたちは、このプログラムを通じて12の組織への資金分配を支援し、初期段階ではいくつかの肯定的な結果をもたらしました。このプログラムを通じて資金提供を受けたパートナーの1つがKids in Techです。その使命は、低所得世帯の子供たちを刺激し、教育し、21世紀のイノベーション経済のリーダーになるよう力を与えることです。「PagerDutyのサポートにより、当社のプログラミングでリーチできる子どもたちの数を60%拡大するためのリソースの構築に投資することができました」とKids in Techの創設者兼CEOのOlu Ibrahim氏は述べています。

PagerDuty.orgのコミュニティー助成プログラムの影響は、社会的影響力を持つリーダーたちにも感じられています。「アトランタの同僚やRiSE ERG（従業員リソースグループ）メンバーとともに、私は青少年の指導を通じて地域社会に貢献することに情熱を注いでいます。PagerDutyの助成金により、コミュニティーパートナーであるEmpowrはメンターシッププログラムを立ち上げ、アトランタの黒人とラテン系の高校生にコーディングを教えるために必要な物品を購入できます。助成金に加えて、デュートニアンは今年、Empowrチームと学生たちと定期的にボランティア活動を行って、その影響力をさらに高めることを目指しています」と、PagerDutyの黒人従業員をサポートするERGであるRiSEの共同リーダーであるMya King氏は述べています。

「PatriotDutyは退役軍人のコミュニティーをサポートすることに尽力しており、彼らが労働力にもたらす貴重なスキルと経験を認識しています。私たちはHire Heroes USAと提携して、退役軍人が民間のキャリアにうまく移行できるよう支援しています。私たちのパートナーシップは、16000人の退役軍人の平均初任給6万ドルの職場への移行を支援し、キャリアアドバイス、トレーニング、コーチング、メンタリングで彼らをサポートします」と、退役軍人をサポートするPagerDutyのERGであるPatriotDutyの共同リーダーであるDonavon Roberson氏は述べています。

コミュニティー助成金プログラムの次の展開

PagerDutyでは、従業員が成功し、成長し、コミュニティーにポジティブな影響を与えることができるチェンジメーカーの文化を育成するために継続的に取り組んでいます。 コミュニティー助成金プログラムは、社内の社会的影響力を持つリーダーに提供する革新的な特典で、チームと関わり、ビジネス全体に社会的影響力の考え方を拡大できます。PagerDutyの社会的影響力を持つリーダーとコミュニティーパートナーシップへの投資を継続する中で、リーダーがコミュニティー補助金の意図する影響を追跡し始めるための追加ツールとトレーニングを構築しています。透明性の高い学習ツールとオープンソースツールは、インパクトアプローチに不可欠です。継続的な学習への取り組みの一環として、Pledge1%コミュニティーやImpact Cloudコミュニティーなど、参加しているピアコミュニティを通じてトレーニング資料とプロセスを共有します。

最近発行された年次影響レポートを通じて、より広範な影響活動について知識を深め、以下のリンクをクリックして、このコミュニティー助成プログラムを通じて資金提供されている各組織について詳しく学びましょう。

Kiva

St. Felix Centre

The Tech Girls Movement Foundation

Kids in Tech

Hire Heroes USA

BANCO ALIMENTAR DE LISBOA

Empowr

San Francisco Education Fund

Mind in the City Hackney and Waltham Forest

San Francisco AIDS Foundation

Disability Rights Education & Defense Fund

YMCA OF SAN FRANCISCO

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

以前のブログでは「バンドエイド」式の修正を適用する前に、インシデント中に関連する全ての診断結果を取得することの難しさについて説明しました。最も一般的で具体的な例としては、コンテナで動作しているアプリが、目先の問題を解決するために、コンテナを以前のバージョンや同じバージョンに再デプロイしてしまうことが挙げられます。１ミリ秒単位のパフォーマンスと１秒単位のアップタイムがカスタマーエクスペリエンスに結果的な影響を与える企業では、こうした短期間での修正をする必要があります。ただし、エンジニアがこれらのインシデントに対する長期的なソリューションの開発を任されると、ビジネスのコストは非常に大きくなります。メジャーインシデントと（再発する）マイナーインシデントの両方で、エンジニアは、インシデント発生時のアプリと環境の状態の証拠を収集するために、途方もない時間を費やさなければなりません。このような診断データの大部分はモニタリングツールにあるため永続的に記録されていますが、コンテナのライフタイムにしか利用できない情報を取得するためには、コンテナ内でシェルを取得しなければならない場合があります。Kubernetesでは、これはkubectl execコマンドを使用して行われます。適切なパラメーターを指定すると、ユーザーは実行中のコンテナでライブシェルを取得して、コマンドの実行を開始して診断データを取得できます。例えば、ユーザーがJavaコンテナにシェルを作れば、jstackを呼び出してアプリのスレッドダンプを取得できます。

しかし、多くの運用チームは誰にもその権限を許可していません。セキュリティー上の理由と、Kubernetesでの操作に精通している人数が限られているため、* 実稼働中のポッド*（重大なインシデントが発生する場所）に実行権限を持つ人は非常に限られています。その結果、インシデント中に診断データを取得するために、Kubernetesへのアクセス権と専門知識を持つ個人は定期的に助けを求める必要があります。このプロセスでMTTRが増え、関与する必要がある人の数が増えるため、インシデントのコストが増加します。

これらの理由から、ユーザーが実行中のポッドにexecする必要をなくす自動化を使うことをお勧めします。この自動化アーキテクチャーでは、問題が発生すると、自動化されたランブックが呼び出され、そのランブックがデバッグデータを取得して、それを永続的なストレージの場所（S3、Blob Storage、SFTPサーバーなど）に送信し、エンジニアにデバッグ データがどこにあるかを通知して、彼らがそのデータを見つけて使えるようにします。

PagerDuty Process Automationは、まさにこのユースケース用に、事前に構築されたテンプレート化されたランブックを提供します。アラートがPagerDuty内でインシデントを作成すると、これは自動的に（またはボタンのクリックによって）ランブックをトリガーして、ポッドでコマンドを実行し、永続的なストレージに出力し、インシデント内のそのデータの場所に関する詳細を提供します。

インシデントの発生中と発生後に、デバッグデータへのリンクがエンジニアに提供されます

当社の商用自動化製品（Process AutomationとRunbook Automation ）とオープンソースのRundeckの両方のユーザーは、こちらの手順に従って自動化されたランブックをダウンロードして開始できます。

この自動化されたRunbookは、デバッグに必要なコマンドラインユーティリティー（バイナリー）がコンテナイメージに既に含まれている場合に最適です。例えば、コンテナ化されたJavaアプリの多くは、コンテナイメージにjstackユーティリティーが付属しています。しかし、デバッグユーティリティーがコンテナイメージの一部として出荷されていない場合はどうなりますか？または、ますます一般的になっているように、コンテナが「distro-less」であり、シェルさえ提供しない場合はどうなりますか？

ここでKubernetesエフェメラルコンテナの出番です。ポッドの定義を変更したり、ポッドを再展開したりする必要なく、実行中のポッドに（任意のイメージの）コンテナをアタッチするメカニズムをユーザーに提供します。 プロセスの名前空間を共有することで、元のコンテナがクラッシュした状態であっても、エフェメラルコンテナはPod内の別のコンテナに対してデバッグユーティリティーを使用できます。 Ivan Velichkoによるブログで、エフェメラルコンテナとのプロセス名前空間の共有について詳しく説明しています。

ソース: https://iximiuz.com/en/posts/kubernetes-ephemeral-containers/

kubectl execを使う場合と同じく、エフェメラルコンテナを適切に活用するには、Kubernetesクラスターでkubectlコマンドを実行するためのアクセスが必要です。そして前述したように、コマンドを適切に構築する方法を知るには、Kubernetesに関する高度な知識が必要です。

kubectl debug -it -n ${namespace} -c debugger --image=busybox --share-processes ${pod_name} (Kubernetesエフェメラルコンテナを使うためのサンプル コマンド)

デバッグユーティリティーのないコンテナやdistro-lessコンテナを使うユーザーに対応するために、私たちは、エフェメラルコンテナの機能を利用する新しい Kubernetes プラグインを作成しました。

このプラグインを私たちは、診断出力をキャプチャーし、出力を永続的な場所に送信する自動ランブックのテンプレート内で使いました。Process AutomationとRunbook Automationのユーザーは、ここから、Runbook Automation診断プロジェクトの一部としてダウンロードすることで、このテンプレートジョブを使い始められます。

Process AutomationやRunbook Automationアカウントをまだお持ちでない場合は、ここをクリックしてPagerDuty の自動化製品を使い始めてください。

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