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

9月14日に開催されるAutomated Diagnosticsウェビナーイベントに登録し、一般的なコンポーネントの一般的な診断方法と、すぐに始められるジョブテンプレートの提供方法について学びましょう。

今回は、PagerDuty Process Automationポートフォリオの一般的なユースケースであるAutomated Diagnosticsに関するシリーズの２回目です。

前回は、Automated Diagnosticsの基本について、また、Automated Diagnosticsを利用することで専門家へのエスカレーションを減らし、レスポンダーがより早くアクションを起こせるようにする方法についてお伝えしました。今回のブログでは、ユーザーにとって最も関係の深いコンポーネントの基本的な診断例について説明します。

しかし、その前に、前回の記事についてTwitterに寄せられた読者の声をもとに、Automated Diagnosticsが該当しないことを明確にしておきましょう。

Automated Diagnosticsとアラート相関は異なります。 アラート相関は、指定された信号の深さと、相関のある信号を適切に識別できるエンジンに依存します。Automated Diagnosticsの目的は、第一レスポンダーが問題の原因を三角測量し、問題を迅速に解決するか、より正確にエスカレーションするかです。 Automated Diagnosticsとモニタリングは別物です。 モニタリングは、パフォーマンスやアクティビティーにおいて望ましくない状態を特定することを目的としています。つまり、ほとんどのモニタリングは、第一レスポンダーのアクティビティーをエミュレートして真偽を確認したり、最初に取るべきアクションを特定したりすることを目的としていないのです。モニタリングは、アラートを上げることに重点を置いています。自動化された診断は、アラートが既に作成された後に、問題を修正する方法を決定することに重点を置いています。

とはいえ、Automated Diagnosticsでは監視ツールで収集したデータを利用することができます。ほとんどの人は、収集した全てのデータポイントに閾値を適用しているわけではありません。 実際、私たちがより一般的に使用している診断インテグレーションの１つは、CloudWatchのログ照会です。ログアグリゲーターを監視ツールと考えるかもしれませんが、純粋に問題を診断するために存在する監視ツールのデータを見ることが調査の最初のステップである場合もあるのです。

レスポンダーに自身の環境のオンデマンドまたは事前診断機能を提供することで、第一レスポンダーが原因を迅速に特定できるようになり、その結果、インシデントをサポートするために必要な人員を減らすことができます。通常、専門家でなければ取得できない「診断」データをレスポンダーに提供することで、トラブルシューティングのために多くの人員を投入する必要性が大幅に軽減されます。これにより、インシデントのコストを削減し、通常は手作業で行われる調査手順を自動化することで、平均応答時間（MTTR）を短縮することができます。

現状を把握する。インシデント対応の自動化

運用管理者は、自己回復や自動修復を可能にするというアイデアに期待することがよくあります。自動化によって解決を早めることは、「治療法を適用すること」と考えるのは自然な傾向です。しかし、多くの場合、「まったく同じインシデントは２つとない」という業界の理論が頭をもたげてきます。変動が大きい場合、自動化が実行される可能性が低くなるため、そのような自動化の価値は低下します。例えば、今日の問題を解決するためにコアサービスを再起動することは正しい方法かもしれませんが、明日には障害が連鎖し、さらに大きなインシデントにつながる可能性があります。

読者はここで、対応の初期段階に認知のギアを切り替えます。

しかし、非常に繰り返しが多くなる傾向があるのは何か、ご存知でしょうか。何が問題だったのかを診断し、何が起こったのかを判断するためにレスポンダーが行う調査手順そのものです。繰り返しが多いということは、自動化によって得られる価値も多いということです。例えば、Kubernetesディストリビューションでインシデントが発生したとします。インシデントの性質的にイメージリポジトリーかロードバランサーかを問わず、おそらくKubernetesログを引き出すという同じ診断ステップを取ることになるでしょう。

これらの診断手順はほとんどの場合、固定です。作業しているコンポーネントにより、発生したインシデントの優先順位は関係ありません。Automated Diagnosticsは、異なる種類のインシデントに適用できます。繰り返し発生する同種のインシデント専用に構築する必要はなく、一般的なコンポーネントのあらゆる種類と深刻度を対象に、お客様の環境に合わせてカスタマイズして適用することができます。これは、病院に行くようなものだと考えてください。特定の症状で緊急医療を受ける場合でも、年に一度の健康診断を受ける場合でも、診察室に入ってから体温、血圧、体重を測定します。

一般的な例

開発者の環境はそれぞれ異なりますが、一旦蓋を開けてみると、多くの環境は非常によく似ています。レスポンスの初期段階では、ほとんどの診断が３つの主要なデータソースから行われます。

アプリケーションデータ** システムデータ** 環境データ**

一般的な診断やコンポーネントは、レスポンス開始時に自動的に引き出される例がいくつかあります。これはレスポンダーがインシデントの重大性をよりよく理解するのに役立つだけでなく、レスポンダーが多くの専門家を巻き込みすぎて通常の業務を中断させないようにするのにも役立つでしょう。例えば、インシデント発生時にレスポンダーが使用するコンポーネントとしてKubernetes（k8s）を見てみましょう。k8s環境内でインシデントが発生した場合、この技術を維持するインフラエンジニアは通常、次のようなアクションを実行することになります。

k8sのPodからテールログを取得する k8sからセレクターラベルでログを取得する イメージリポジトリーを確認する デプロイメントを記述する Podでコマンドを実行する

これらのアクションに共通することは、１つだけです。インシデントを受任した一般的なL1レスポンダーは、これらのアクションをどのように構成すれば良いのか分かりません。しかし、PagerDutyのAutomated Diagnosticsのすぐに使えるジョブがあれば、L1レスポンダーは自動的にこれらの診断を実行し、ジョブを実行することができます。

一般的な診断やアラートの例としては、以下のようなものがあります。

CPU／メモリ消費型サービス よくあるアラート： CPU／メモリ使用率が高い よくある質問： どのサービスがCPUやメモリを消費しているか ファイルサイズ ／ ディスク消費量 よくあるアラート： CPU／メモリ使用率が高い よくある質問： どのファイル／ディレクトリーが最も容量を消費しているか システムログ：Linux／Windowsコマンド よくあるアラート： サーバー／サービスの問題 よくある質問： OSの問題か、アプリの問題か SQLデータベースコマンド よくあるアラート： データベースブロック／デッドロック よくある質問： 長時間稼働しているクエリーが他のデータベース要求をブロックしていないか ホストの可用性 よくあるアラート： ホストの停止 よくある質問： 実際にダウンしているのか、それとも誤検出による到達性の問題か アプリケーションのエラー：アプリケーションログまたはトレース よくあるアラート： 400／500エラーコード よくある質問： スタックトレースとは何か

既知の部品に対する一般的な診断のいくつかの例を示します。

Cloudwatchのログ：** 特定のアプリケーションとVPCのログを表面化させる。 ECS：** 停止したECSタスクのエラーを表示させる。 ELB：** 利用できないターゲットグループインスタンスをデバッグする。 Kubernetes：** Podsからセレクターラベルでログを取得する。 Linux：** サービスステータスを取得する。 Nginx：** エラーログを取得する。 Redis：** ログエントリーを低速にする。

また、これらはAutomated Diagnosticsソリューションガイドに掲載されている、ユーザーのために構築した30以上のすぐ使えるジョブテンプレートの一部に過ぎません。Automated Diagnosticsソリューションを使用するには、PagerDutyランブックオートメーションライセンスまたはProcess Automation（旧Rundeck Enterprise）ライセンスのいずれかが必要です。使用方法の詳細については、FAQを参照してください。どちらのライセンスもお持ちでない場合は、弊社までお問い合わせください。

PagerDuty内の診断の自動化

レスポンダーに通知されるインシデントには、アラートに対して「近視眼的な」見方をする監視ツールから提供される情報が多く含まれます。よくある例としては、CPU使用率の高さがアラートのトリガーとなり、レスポンダーに通知されるというものです。しかし、アラートに含まれる情報は表面的なもので、急増したCPUの原因が何であるかが特定されていません。

診断データ は、インシデントの「なぜ」「どこで」という質問に答えるのに役立つ、より深いレベルの情報です。モニタリングや相関ツールの中には、ユーザーに根本的な原因分析を提供するのに役立つものもありますが、そのほとんどは、異種のデータソースを統合ビューに照合するレスポンダーの調査／トラブルシューティングの手順をエミュレートする能力において不足しています。オンデマンドまたは事前実行の診断機能をレスポンダーに提供することで、最初のレスポンダーが自分で問題を解決する確率が高まり、インシデントを支援するための人員も少なくて済む可能性が高まります。Automated Diagnosticsの出番です。

使用するコンポーネントの一般的な診断についてもっと知りたいですか？PagerDutyのシニアソリューションコンサルタントのJustyn Robertsが登壇する9月14日に開催されるウェビナーイベントにご登録ください。Process Automationは初めてですか？デモをリクエストしてください。既にPageDutyのProcess Automationをお使いですか？Automated Dianosticsソリューションガイドをご覧になり、完全なソリューションを実現するためのエンドツーエンドプロセスをご確認ください。ご質問は、Twitterで@sordnamに直接ください。お話ししましょう。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

新しいものよりも伝統的なものの方が良い場合があります。ニューコークよりコカ・コーラ クラシックが好きな人もいるし、普通のトマトより伝統野菜としてのトマトが好きな人もいます。

クラウドコンピューティングについても、同じことを言う人がいるかもしれません。「（アプリやデータを）クラウドに置くのは嫌！自前のデータセンターで自分で動かした方が、より（安全だ、信頼性が高い、安い）から」。

話を戻します。私たちの新しいSaaS製品であるPagerDuty® Runbook Automationよりも、PagerDuty® Process Automation On Prem（以前はRundeck Enterpriseとして知られていました）のセルフマネージドバージョンを選択する正当な理由があるのです。昔のものの方が良いというのは今回は当てはまりません。Rundeckのオープンソースプロジェクトで開発された同じコードを使用しています。この場合、SaaSの自動化ソリューションが提供できる以上の柔軟性があれば、あなたの要件やユースケースをよりよく満たすことができるかもしれないということなのです。

どちらにするか迷っていますか？ここでは、あなたのユースケースに適したオファーを決めるのに役立つ５つの考慮事項を紹介します。

1. アプリケーションとインフラはクラウドではなく自己管理か

アプリケーションとそのスタックは、自社のデータセンターや、クラウドのハイパースケーラー以外のホスティングプロバイダーで稼働しているかもしれません。これは、アプリケーションが最初にデプロイされたのがレガシーな理由であり、クラウドへの移行に投資するには戦略的すぎる（または戦略的でない）ことが原因である可能性があります。また、パブリッククラウドでは実現が困難な特殊な要件（いくつかを以下で説明します）がある場合もあります。簡単に言えば、あなたの会社がITに資本を投下し、専門性を高める場所を選択しているかどうかを反映しているのです。実際、自社でインフラを運用することがコスト抑制や収益性の源泉になる場合もあります。AWSの売上総利益率は60%以上と言われています。最後に、あなたの会社はデジタルサービスを大規模に提供しており、自社でインフラを運用することは、品質の確保やイノベーションのスピードアップの一環であるのかもしれません。

PagerDuty® Runbook Automationは、あらゆるクラウド環境またはセルフホスト環境に安全に接続できるように構築されており、多くの典型的なユースケースに対応することができます。しかし、チームのスキルセットが自己管理環境に向いている場合、PagerDuty® Process Automationソフトウェアを自分で実行する方がより理にかなっている可能性があります。このような場合、PagerDuty® Process Automation On Premを実行することで、経験豊富なエンジニアが専門知識を活かしてセルフサービスの自動化を構築し、それを他のユーザーに委ねることができるため、社内業務の拡張に役立ちます。PagerDuty® Runbook Automationをリモート環境に接続するのと同じ安全な接続性により、チームは異種のデータセンターを安全に接続して集中型自動化を行うことができます。実際、これらの環境へのリモートSSHアクセスを許可する必要性を削減または排除することで、セキュリティーをさらに向上させることができるかもしれません。

2. より厳しいコンプライアンス基準を満たす必要があるか

HIPAA、PCI、FedRAMPの要件に適合する必要がありますか？ITプロバイダーがSOC2に準拠していることを要求していますか？もしそうであれば、少なくとも短期的には、SaaSを利用するよりもPagerDuty® Process Automation　On Premを運用する方がよいかもしれません。

PagerDuty® Runbook Automationはこのような標準に準拠するように構築されていますが、私たちはこの３月にローンチしたばかりです。このような標準を達成するには、ある程度の運用実績が必要です。PagerDuty®には、高品質のサービスを構築してきた大きな経験があり、PagerDuty® Runbook Automationの開発にも活かされています。SOC2認証の取得については、できるだけ早く発表したいと考えています。より多くの認証の取得に近づくにつれ、予想される利用可能性をお伝えしていきます。

3. データ主権要件に該当するか

多くの国では、個人を特定できる情報（PII）や財務データなど、国民に関する特定の種類のデータを自国の国境内に保存することを義務付けています。PagerDuty® Runbook AutomationはSaaSとして提供され、インターネット経由でアクセスできるあらゆるITインフラの自動化に利用することができます。ただし、現在は北米でホスティングされており、将来的にはヨーロッパでホスティングする予定です。

もしあなたの会社やアプリケーションがそのようなデータ主権要件の対象となるのであれば、代わりにPagerDuty® Process Automation On Premを利用することが理にかなっていると言えるかもしれません。私たちのSaaSサービスは、ユーザーアカウントに必要なもの以外の個人データを直接保存しません。しかし、作成するオートメーションがこのような規制の違反につながる可能性がある場合、自社のインフラ内に自社の自動化環境をホスティングすることで、コンプライアンスを示すことが容易になる場合があります。

4. オートメーションに組み込むべきインフラとは

PagerDuty® Process Automation On Premは、PagerDutyが開発しサポートするプラグインと、Rundeckオープンソースコミュニティーが開発するプラグインの両方を幅広く提供します。これはオートメーション開発者がいくつかの種類のインフラをオートメーションに取り入れるための選択肢と柔軟性を提供します。

コミュニティーで非常に多くのプラグインが利用可能な理由の１つは、PagerDuty® Process Automation On Premが柔軟なプラグインAPIを備えていることです。これにより、ノード、ジョブステップ、UI統合、クレデンシャルストレージなど、ジョブ定義に利用したい自社製またはあまり一般的ではないインフラのための独自のプラグインをユーザーがシームレスに開発することができます。

PagerDutyは、厳しいセキュリティーと信頼性の要件を満たすために、当社のSaaSサービスであるPagerDuty® Runbook Automationを運営しています。つまり、私たちが提供できるプラグインは、これらの要件を満たすためにテストされ、認定されたものだけです。同じ理由で、カスタムプラグインも現時点ではサポートされていません。

PagerDuty® Process Automation On Premでファイアウォールの内側で使用するには十分安全ですが、PagerDuty® Runbook Automationではサポートされていないプラグインの一覧はこちらです。

自動化したいインフラの種類が多い場合、PagerDuty® Process Automation On Premが豊富な要件を満たす柔軟性を備えていることがお分かりいただけると思います。

5. どのようなセキュリティー要件に対応する必要があるか

PagerDuty® Runbook Automationは、厳しい要件を満たすために強化されたセキュリティーで構築されており、セキュリティーとコンプライアンス要件への準拠を最適化することができます。例えば、PagerDuty® Runbook Automationは、HTTPSを使用してエンドポイントにコールバックするRunnerを使用してインフラに接続します。このため、ファイアウォールに追加のポートを開く必要がありません。Runbook Automationは、Okta、Ping、Azure ADなどのクラウドSSOや、Hashicorp Vault、CyberArk、Thycoticなどの機密管理SaaSサービスと統合されています。特権的なアクションへのアクセス制御を容易にし、スーパーユーザー資格情報を配布する必要性を低減します。ジョブレベルのログは、コンプライアンス監査も容易になることを意味します。しかし、秘密管理の場合、PagerDuty® Runbook Automationはオンプレミスのキーストアと接続しません。

しかし、あなたの会社のセキュリティー要件に合致するでしょうか？

オンプレミス認証や機密情報管理と統合する必要がある場合、またはこの分野で独自のニーズがある場合は、代わりにPagerDuty® Process Automation On Premが提供する柔軟性が必要かもしれません。

概要

	PagerDuty® Runbook Automation	PagerDuty® Process Automation On Prem
最適な目的	クラウドやSaaSの運用を管理するため	オンプレミスの運用やインフラを管理するため
プラグイン	プリセットとカスタムなし	全て利用可能＋カスタム可能
キーストア	クラウドのみ	オンプレミスまたはクラウド
データ	PDによる管理	お客様による管理
アップグレード	PDによる管理	お客様による管理
スケール	PDによる管理	お客様による管理
安全なインフラ	PDによる管理	お客様による管理

これらの違いについて、自社の要件と照らし合わせてみたいという方は、ぜひ私たちのチームと会話を始めてください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

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

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

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

ステークホルダー専用情報共有チャンネルで、レスポンダーによるインシデント報告の投稿を容易に。ステークホルダーチャンネルはインシデントチャンネルとは異なり、レスポンダーの対応速度を落とすことなく、ステークホルダーが適切なインシデントの詳細やアップデートを閲覧できるようになっています。レスポンダーは、コンテキストを切り替えることなく、Slack から "Stakeholder Updates and Resolution Notes"（訳注：ステークホルダー向けの最新情報と解決をまとめたメモ）を作れます。

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

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

インシデントを迅速に解決するために、協力して問題を診断する

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

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

今回のインテグレーションにより、レスポンダーはSlackチャンネルから直接、自動診断と修復アクションを展開できるようになりました。これにより、ターミナルからサービスにアクセスしてウインドウを切り替える必要がなくなり、より迅速かつ効率的にインシデントを解決し、専門家へのエスカレーションを減せます。

１つの問題に対処するために、２台のモニターに複数のウインドウを表示させる時代は終わりました。インシデントの状況をステークホルダーに伝えるだけでなく、同じウインドウから修復アクションを展開することができます。インシデントが発生すると、レスポンダーはSlackインスタンス内にインシデント専用のチャンネルをすばやく作成し、影響を受けるチームやステークホルダーとコラボレーションし、診断手順を実行し、オートメーションを呼び出してリアルタイムに問題を修復できます。

CollabOpsの実践

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

Rundeckアクションの仕組み

PagerDuty Rundeck Actions を使うと、エンジニアは手間がかかり繰り返し行われる診断手順の自動アクションを作成してレスポンダーに委任できるようになり、繰り返し行われるタスクに費やされる時間を削減できます。また、フェイルオーバーなどの一般的な低減アプローチやその他の修復手法の自動化も含まれます。 既知の問題に対するシンプルで繰り返し適用できる修復法も、イベントトリガーを使って人間の介入なしに発動できるので、緊急の問題だったものを解決済みの後処理に変えることができます。PagerDutyで作業するレスポンダーがインシデントの解決を加速できるように、Rundeck ActionsはAutomated Diagnosticsと修復をインシデント対応ワークフローにつなげます。 Automated Diagnosticsは、インシデント発生時にレスポンダーが呼び出せる、本番サービス用の自動化されたアクションのセットです。一般的なテストを手動で実行する専門家にエスカレーションするのではなく、第一レスポンダーはPagerDutyから安全にこの自動化を呼び出すことができ、インシデントタイムラインにリアルタイムで返されるレスポンスを確認できます。

PagerDuty Rundeck Actionsを使用すると、チームは以下のことが可能になります。 レスポンスタイムを最大30分短縮 Slack経由でレスポンスチーム全体に専門知識を共有 レスポンダーが呼び出される前に、人的支援と自己修復の自動化を開始 ファイアウォールやVPCの内側で安全な自動化を実行 手作業に代わる自動化されたアクションを導入 円滑なポストモーテムとオペレーター作業軽減のためのインシデントの文書化を充実

Rundeck Actionsがどのように機能するかについてもっと知るには、ナレッジベースをチェックしてください。さらに、アカウントマネージャに連絡するか、デモをリクエストしてください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

新年の抱負を決めなければならない時期がやってきました。そこで、私たちは一足先に新年の抱負を発表します。2023年は、エンジニアリングやイノベーションなど、楽しいことに集中できるよう、労苦を軽減する年にしましょう。

12月のシーズンズ ”フリージング”にご参加いただけていたらうれしいのですが、この時期はプロダクション段階から離れるため、オートメーションなど、新しいアイデアを検討しやすいタイミングでしょう。このブログは、シーズンズ ”フリージング”のコンテンツへのリンクですので、プロダクションに戻っても検討できます。

解決策1：エンジニアリングを多く、労苦を少なく。

お客様は今でも、労苦に悩まされているとおっしゃいます。PagerDutyが実施した調査によって、回答者の43%が、時間の11%から30%をルーティンワークである手作業に費やしていることが分かりました。これは、年間合計でおよそ8日間、割り込みや反復作業に費やしていることになります。新年には、既存のプロセスにオートメーションを導入することで、この時間を取り戻すことをお勧めします。

まずは、反復作業や「バリューライン以下」の作業をリストアップし、自動化することから始めましょう。例えば、サーバーの再起動、ログの取得、チケットのオープン／クローズ／アップデート、インフラのプロビジョニング、ユーザーアカウントの更新など、数え上げればきりがありません。

次に、特定の専門家とステークホルダーの意見をまとめ上げて、これらの反復的なタスク完了のために標準化する方法について合意し、PagerDuty Process Automation製品、またはRundeckオープンソースを使って自動化してみましょう。労苦については、Damon Edwards氏のブログでもっと知ることができます。

これらの運用タスク完了の方法を標準化したら、エンドユーザーにセルフサービスとして委任することで、このオートメーションの価値を最大化します。今日から、あなたの組織でセルフサービスの自動化を検討しましょう。ビデオで学ぶ

ITプロセスをセルフサービスオートメーションとして委ねるための、インパクトの大きなユースケース セルフサービス・オートメーション作成のための設計原則 委任型セルフサービスをエンドユーザーの働き方に適合させる方法

「オートメーション、委任、お祝い！」の道を順調に進んでいますね。

PagerDutyがどのように変更フリーズを管理するか、フリーズからの解凍、そしてフリーズをいかに活用して労苦に取り組むのかについては、このTwitchエピソードをぜひご覧ください。

解決策2：診断の自動化で中断を減らす

同じインシデントに対する厄介なページにうんざりしていませんか？ノイズを無視するのはお勧めできませんが、PagerDuty Automated Diagnosticsは、一般的で繰り返し発生するインシデントに対する中断を減らす、素晴らしい方法です。重要なのは、最も一般的なトラブルシューティングの手順を自動化し、レスポンダーがPagerDutyのインターフェイス内でオートメーションを呼び出すことができるようにすることです。診断の自動化により、専門エンジニアの日常業務の中断を抑え、解決までの時間を全体的に短縮できます。

Automated Diagnosticsに役立つリソースをご紹介します

このブログでは、応答プロセスの初期段階における問題点と、チームが自動診断に関心を持つべき理由について詳しく説明します。 また、Kubernetes、Linux、その他の一般的なコンポーネントの一般的な診断を自動化するための、すぐに使えるジョブテンプレートをいくつか用意しています。詳しくはこちらのブログをご覧ください。 自動診断ソリューションの設定、使用例、診断例の詳細については、Automated Diagnosticsソリューションガイドをお読みください。

解決策3：インテグレーションにより、既存のオートメーションをさらに活用する

多くの企業には、現在使用中のオートメーションがあることでしょう。しかし、そのオートメーションを安全に、そして広く利用できるようにすることが課題となっています。さまざまな企業が、Pagerduty Process AutomationやRundeckを使ってオートメーションを一元化し、標準化しています。

この作業を簡単にするために、PagerDuty Process AutomationとRundeckにはたくさんのすぐに使えるプラグインがバンドルされています。プラグインはスクリプト、インターフェース、ユーティリティーのラッパーを提供します。全リストをご覧ください。

非常に人気のある組み合わせの1つは、AnsibleをPagerDuty Process AutomationまたはRundeckに統合することです。多くのユーザーがAnsibleのプレーブックをPagerDuty Process AutomationやRundeckに統合し、複数のツールにまたがるワークフローのオーケストレーションやスケジューリングを行っています。このビデオでは、PagerDuty Process Automation、またはRundeckとAnsibleを使うメリットと、使い始めるためのヒントについて説明します。

2023年の新年の抱負をぜひお聞かせください。TwitterでRundeckをタグ付けして、共有してください。

PagerDuty Process Automationについてもっと知りたい方はこちらへどうぞ。

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

ITの運用は、いつの時代も難しいものです。やるべきことが多すぎるし、時間も足りません。頻繁に中断され、労力のレベルが高いことは明らかに救いようがありません。さらに経営陣からは、「なぜ時間がかかるのか」「なぜ故障が多いのか」「なぜコストがかかるのか」というプレッシャーが絶え間なく襲ってきます。 このような状況を改善するために、私たちは何度も新しいツールに賭けてきました。新しいプラットフォーム（仮想化、クラウド、コンテナ、Kubernetesなど）や新しいおオートメーションツール（Ansible、Terraform、Pulumiなど）を繰り返し使ってきたのです。それぞれに利点がありますが、平均的なエンジニアにとって、運用にかかるストレスや過負荷が根本的に変わったといえるでしょうか。 また、企業は過去20年間、ITILやCOBITのような管理フレームワークを惜しみなく使ってきました。ここでも、平均的なエンジニアは、状況が良くなったといえるでしょうか、それとも悪くなったと言うのでしょうか。 このような中で、ほとんど疑問視されることのない常識があります。それは、チケットを使って運用業務を管理することです。 チケットは、運用組織で最もよく使われる作業管理ツールになっています。必要なものがあったら？チケットをオープンしてください。誰かがあなたに、何かをリクエストしようとしたら？あなたのキューにチケットが表示されます。 チケットドリブンの働き方はとても一般的なため、組織全体へのチケットキューの追加について再考する人はあまりいません。 しかし、もし私たちがチケットについて誤解していたとしたらどうでしょう。もし、チケットの列が、目に見えないところに隠れている、運営上の重要なトラブルの原因だとしたらどうでしょう？チケットキューが、しばしば利益よりも害を及ぼしていることを検証してみましょう。

チケットの何が問題なのか？

それは、キュー（待ち行列）

チケット単体では、単なる記録なので比較的無害です。問題は、そのチケットをどこに置くかということです。チケットはチケットキュー（待ち行列）に入れられますが問題はそこから始まるのです。 キューは遅延、リスク、変動性、オーバーヘッドを増やし、品質、モチベーションを下げます。 これは私的な意見ではありません。待ち行列のコストは、物理的な製造や製品開発など、他のさまざまな分野での広範な研究から得られたものです。待ち行列理論は、その学術的な研究領域として尊重されています。 この記事の続きで、私は「チケット」と「キュー」を多少入れ替えて使うことにします。ただ、問題を起こすのはキューの列の部分であることは知っておいてください。

チケットはコミュニケーションの問題を増加させる

チケットキューでの通信を強いられると、必ず中断やミスコミュニケーションが発生します。チケットに関するあらゆる問題を考えてみると、リクエストが誤解される。リクエストを読む人がコンテキストを欠いているか、異なるコンテキストで作業している、あるいはリクエストする側が間違ったリクエストをしたり、リクエストの意味を理解していない、さらにはリクエストがキューに残っている間に、リクエストのパラメータが（どちらの当事者も知らないうちに）変更されていたり、もはや有効でなくなっていたりする、などといった事象が挙げられます。

チケットはフィードバックと学習を遅らせる

リーン開発からDevOps、リーンスタートアップまで、ほとんど全ての現代の経営哲学は、組織はすぐに学習するというコンセプトに基づいています。分析と意思決定が素早く行われるように、全てのフィードバックのループをより厳しくしているのです。

しかし、Scott Prugh が言うように、「キューは学習しない」のです。キューは、遅延を発生させ、各リクエストのコンテキストをはぎ取ってしまい、フィードバックループに対立します。チケットドリブンのリクエストキューがまん延していると、学習する組織になるのは難しいでしょう。

チケットはボトルネックを助長する

チケットキューを利用したチームの働き方は、ボトルネックを助長する性質があります。まず、チケットキューは、キャパシティーのミスマッチがある場合によく使用されます。例えばチケットキューは、専門家チーム（例：ネットワーク、データベース、セキュリティー）のリクエストをバッファリングするためによく使用されます。そしてこの専門家チームは、リクエストに対して人数が少ないことが多いです。リクエストを送るチームは、キューに要求を「詰め込む」ため、キューの長さと応答時間を増加させます。キューはフィードバックを遅らせるため、リクエスターはしばしば容量の不一致に気付かず（あるいは気にせず）、キューに詰め込み続けます。このような行動は、キューの長さと応答時間の両方を増加させ、ボトルネックを悪化させるのです。 さらに、キューが長くなると、キューの処理に責任を持つチームは、本能的に、自分たちのキャパを守るために内向きになります。この自然な反応は、キューの背後にいるチームの最適化につながりますが、多くの場合、組織全体を犠牲にすることになります。例えばファイアウォールチームが緊急でない変更は月曜日と木曜日にしか行わないとした場合、そのチームの作業負荷を最適化するのに役立つとしても、組織の他の部分には遅延が発生します。

チケットはサイロ化した仕事のやり方を増やす

チケットキューは、チームがサイロ化し、分離した状態で作業を続けてしまうためのバッファーとして機能します。チームがバラバラになればなるほど、チームはサイロ化した専門家の労働力のプールのようになってしまうのです。 このようなスペシャリストへのリクエストは、チケットキューを通じて行われ、リクエストは半手動、または手動によって一度だけ実現されるため、変動性が高く、優先順位や状況を把握するのが難しくなります。 ボトルネックへの対応と同様、管理職はチームの生産量を守ることに重きを置きます（組織全体のニーズには目を向けません）。サイロの影響が強まれば強まるほど、断絶、ミス、遅れが生じます。チケットキューは、このような負のスパイラルを助長するのです。

チケットは組織を「スノーフレーク」にする

チケットキューのデフォルトであるFIFO （First In, First Out）の性質は、一回限りの処理を促します。あるチケットがキューの先頭に来ると、チケットキューで作業している人たちは行動を始め、限られた時間の中でできるだけ多くのコンテキストを集めようとし、自分たちの視点で正しいことを行い、次のチケットに移ります。 このように、１つのリクエストから別のリクエストに飛び移り、それぞれが一見バラバラなコンテキストを持つという仕事の進め方は、「スノーフレーク」（snowflake）を引き起こす主な原因でます。「スノーフレーク」とは、技術的には正しく（完璧ですらあっても）、再現性のない一過性のものを表す言葉です。手動で更新されたサーバーは、スノーフレークの典型的な例といえるでしょう。手動で更新したサーバーは、雪の結晶の典型的な例といえます。動作している状態にすることはできるかもしれませんが、おそらく、フリート内の他のサーバーとはわずかに異なります（そして多くの場合、検出できない形になっています）。 スノーフレークにかかるコストは、最初は、わずかなものに思えるかもしれません。しかし環境が大きくなるにつれて、そのコストは急速に膨れ上がって高くなり、一見すると難解な状態を作り出してしまうのです。 Keith Chambersによるこの指摘が有名です。「小さな予期せぬ変化が原因で大きなインシデントとなり、数時間から数日間チームの生産性が失われる『吹雪の日』を経験した企業はどれだけあるだろうか？」

チケットは価値の流れを見えなくする

リーン開発、アジャイル、DevOpsの動きの多くは、価値の提供のために必要がある作業の体系的なビュー（このエンドツーエンドの体系的なビューは、しばしば「バリューストリーム（value stream、価値の流れと呼ばれる）の構築のために、障壁を破壊することにありました。全ての知識労働においてコンテキストが重要であるため、各作業がより広いシステムのどこに位置付けられるか、の理解がとても重要なのです。 透明性を提供し、コンテキスト構築のために行われた全作業の後、一連の個々のチケットに分解することは、価値の流れを不明瞭にし、コンテキストを散乱させます。しかし実際、仕事をどんどん小さな単位に分解することは、チケットシステムのベストプラクティスとしてよく見受けられます。

チケットは管理のオーバーヘッドになる

チケットキューは、ただ現れて、ただ処理するだけではありません。誰かがキューをセットアップし、ルールを定義しなければなりません（ルールはそのルール内、もしくはルールに沿った形を学ぶ、というオーバーヘッドを追加してしまうことが多いです）。誰かがチケットシステムそのものを維持しなければなりません。優先順位、衝突、ポリシーの問題も継続的に管理する必要があります（多くの場合、高価なプロジェクト管理オーバーレイを使用します）。これらの作業にはコストがかかり、他の付加価値の高い作業に費やせる時間と労力を割いてしまいます。

チケットは何のためにあるのですか？

誤解を恐れずにいえば、チケットは悪いものばかりではありません。ただ、チケットを使いすぎたり、間違った理由で使われたりしているだけです。 私の意見では、チケットシステムは例外（例えば、バグや改善リクエストの記録）を提起するのに有効です。また、承認作業が避けられない場合に、人と人のコミュニケーションを記録するためのチケットシステム使用には、いくつかのメリットがあります。 チケットキューは、各リクエストが細かく、分断されている場合にも有効です（例：従来のカスタマーヘルプデスクや、チケット販売の興行など）。しかし同時に、これらのリクエストのほとんどは、セルフサービスオートメーションの有力な候補となります。 企業のソフトウェアベースのサービスを提供し、運用するために必要な複雑な知識作業に関しては、チケットキューはよくてもコストがかかり、最悪の場合破壊的であるという証拠が明確にあるようです。

チケットキューをできるだけなくすにはどうしたらいいか？

より多くの組織がチケットドリブンののリクエストキューがもたらす有害な副作用に気付くにつれ、キューからできるだけ多くの仕事を取り除く、という基本的なパターンが現れていくと私は予想しています。

可能な限り引き継ぎを回避するための作業設計の見直し 先進的な考えを持つ企業は、「サービスオーナーシップ」や「プロダクトアラインドチーム」と呼ばれる、ライフサイクルのできるだけ多くを（他のチームに仕事を引き継ぐことなく）処理できるチーム作りに注力しています。引き継ぎをなくせば、当然ながらチケットキューは不要になります。

セルフサービスのオートメーションにより、チケットキューをなくす チケットキューをなくすことができない場合の優れた代替案は、そのキューをセルフサービスに置き換えることです。セルフサービス自動化により、業務活動の定義と実行の両方を、従来の組織の境界を越えて委任できます。チケットキューをプルベースセルフサービスインターフェースに置き換えることで、待ち時間がなくなり、フィードバックループの短縮やコンテキスト中断の回避、コストのかかる労力の省略につながります。残る数少ないチケットキューは、真に期待されるものや一回限りのものです。

今こそ行動を起こす時

今こそ、業界として、チケットキューの常識を疑うべき時です。チケットにはその役割がありますが、使いすぎによって皆に不利益を与えてきました。PagerDutyではもっと簡単に物事を達成するためのよい方法を、ユーザーの皆さんと共に探し、実現していきます。ぜひ、あなたもご参加ください。

PagerDuty Process Automationの詳細については、弊社にお問い合わせください。

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

PagerDuty Operations Cloudの新規アップデートと機能強化を発表することができ、とてもうれしく思います。製品チームによる最近の開発およびアプリのアップデートには、インシデントレスポンス、PagerDuty®Process Automation、およびコミュニティー＆アドボカシーイベントのアップデートが含まれています。私たちは、お客様によるクラウド運用の最適化のために自動化を進め、他のチームにエスカレーションされる問題の量を減らすお手伝いをし続けています。今すぐ始めて、学びましょう。

Incident Response Status Update Notification Templates（インシデント対応状況更新通知テンプレート）のカスタマイズ、標準化、再利用 PagerDuty®Process AutomationとRundeck Communityの最新版4.7.0リリースとAutomated Diagnostics for AWSのアップデート CollabOpsとCustomer Service Opsのインテグレーションに関する更新情報) -Slackでメンテナンスウィンドウを表示する方法 -PagerDuty App for Salesforce v3.7とPagerDuty App for ZendeskのV3への移行について V1 Webhooks サポート終了(End-Of-Life), Event Rules EOLと Event Orchestrationへの移行, V2 Zendesk Integration EOLを含む製品廃止のお知らせ。 今後のイベントに登録し、最近のポッドキャストやTwitchストリームを閲覧し、コミュニティーチームや製品チームのメンバーと一緒に新製品やソフトウェア業界のリーディングプラクティスを学べます。

Incident Response Status Update Notification Templates EA Status Update Notification Templatesのアップデートをお知らせします。再利用可能なコミュニケーションテンプレートを、インパクトやサービスエリアなどに基づいてカスタマイズし、標準化できるようになりました。また、この機能は、APIを介して、あらゆるツールやコンテキストでニーズに合わせて活用することができます。

（上図：変数によるStatus Update Notification Templatesの設定）

（上図：ステータス更新通知テンプレートの設定 プレビュー） Early Accessプログラムに参加して、最新のアップデートを受け取るためのアーリーアクセスリストに追加してください。 ステークホルダーとのコミュニケーションについて詳しくは、Knowledge baseをご覧ください。

PagerDuty®Process Automation PagerDuty®Process AutomationソフトウェアとPagerDuty®Runbook Automationバージョン4.7.0

このリリースでは、PagerDuty® Process Automation、PagerDuty® Runbook Automation、Rundeck Communityの新機能と機能強化をご確認ください。

CloudWatch Logs Saved Query Plugin：このプラグインは、診断クエリーの管理を簡素化します。ジョブのROI（投資対効果）を理解するためのインキュベーション機能、および多数のセキュリティーとコンプライアンスの更新とバグ修正を行いました。 ROI Metrics データ (インキュベーション) ：ROI メトリクスのインテグレーションにより、各ジョブ実行のユーザー定義値を追跡し、ジョブに対する主要な値のペアを保存して、ジョブ実行ごとの ROI を理解するのに役立ちます。

(上図：ROI Metrics出力)

Progress Badge プラグインを強化：Progress Badge プラグインは、ログ出力タブにレンダリングされるエモティコンのステータスシンボルを含むグラフィックバッジを作成できます。Automated Diagnosticsを実装しているユーザーにとって、ドメインの専門家が診断しやすい方法で簡素化できます。

（上図：失敗ステータスのプロセスバッジ）

（上図：成功ステータスのプロセスバッジ）

（上図：インシデントアクティビティタイムラインのプロセスバッジのステータス）

追加のアップデート： バグフィックスやオープンソース製品の追加アップデートを確認できます。

詳しくはこちら

このリリースのTwitchストリームのレビューを見る 2022年10月6日、Orc Yellowgreenリリース（4.7.0）に関するリリースノート全文をご覧いただけます。

Automated Diagnostics for AWS

私たちは、お客様がAWS環境の問題を迅速にトリアージできるように、PagerDuty　Automated Diagnostics for AWSを発表しました。このソリューションは、PagerDutyのインシデントレスポンスとイベントオーケストレーションに接続されたAutomation ActionsとRunbook Automationのシームレスな統合で構成されています。頻繁に使用されるAWSサービスのため、事前に構築された一般的な診断と、独自の診断を追加して構築する簡単な方法をご提供します。

(上図：Automate Diagnostics Run Actionsメニュー）

(上図：Process Automation AWS CloudWatch Logs Plugin)

インテグレーション

Slackのメンテナンスウインドウ

PagerDuty Slackインテグレーションを拡張して、Slackに直接メンテナンスウインドウを表示したいと思ったことはありませんか？Mandi Wallsが最近、まさにそのような状況に対するウォークスルーを書いてくれました。

(上図：Slack Resultで複数のメンテナンス予定ウインドウを表示)

PagerDuty App for Salesforceの最新版をリリース

PagerDuty App for Salesforceの最新バージョンv3.7をリリースしました。この最新版のメリットは以下の通りです。

Webhook ExtensionをPagerDuty webhooks v3にアップグレード-このアップグレードにより、webhooks v2のサービスレベルではなく、アカウントレベルで拡張機能を追加することができます。 新しいSalesforce Extensionページと、PagerDutyに接続されているSalesforceアカウントを確認できる機能 標準的な統合によるSalesforceインシデントオブジェクトのデフォルトのオブジェクトマッピング ルールセットのアクションをPagerDutyまたはルールセットフローの一部として作成されたSalesforceオブジェクトに限定するかどうかを選択する機能

(上図：PagerDuty App for Salesforce V3.7メインページ）。

詳しくはこちら

詳細はPagerDuty App for Salesforceインテグレーションガイドをご覧ください。 その他のご質問は、[email protected] までご連絡ください。

PagerDuty App for Zendesk v3への移行について

今すぐv3 PagerDuty App for Zendeskに移行すれば、Zendeskのサポートチケットイベントを引き続きPagerDutyに送信できます。（この統合は2023年3月に終了します。）

今回のバージョンアップのメリットとしては、以下のようなものがあります。

Webhooksを利用したPagerDutyとZendesk間の双方向コミュニケーション チケットページでのPagerDutyの追加アクションとインシデントコンソールウィジェット ZendeskからPagerDutyのステータスダッシュボードを表示し、対話することができます。

(上図：Zendesk V3 Status Dashboard)

詳しくはこちら

詳細はPagerDuty App for Zendeskインテグレーションガイドをご覧ください。 その他のご質問は、[email protected] までご連絡ください。

製品廃止のお知らせ

今後予定されている製品の非推奨について、チームにお知らせください。

V1 Webhooks EOL

v1 WebhooksのEnd of Lifeは、2022年10月31日です。これは、次のことを意味します。

新しい v1 Webhook を作成したり、v1 Webhook 拡張機能への既存の接続を使用したりすることができなくなります。 v1 Webhooks を使用しているアプリやインテグレーションは動作しなくなります。

詳しくはこちら

v3 Webhooks への移行の詳細と手順については、この移行ガイドを参照してください。 その他のご質問は、[email protected] までご連絡ください。

重要な日程

V2 ZendeskインテグレーションEOL

PagerDutyのv2 App for Zendeskは2023年3月にライフサイクル終了となります。今すぐ移行して、ZendeskサポートチケットイベントをPagerDutyに引き続き送信してください。v3への移行の利点については、上記のIntegrationsセクションをご覧ください。

詳しくはPagerDuty App for Zendeskインテグレーションガイドをご覧ください。 ご質問やご不明な点がございましたら、[email protected] までご連絡ください。

イベントルールの廃止とイベントオーケストレーションへの移行

PagerDuty イベントルール End-Of-Life は2023年1月31日です。

マイグレーションについて詳しくはナレッジベースをご覧ください イベントオーケストレーションの詳細 アカウントマネージャーへのお問い合わせ

この EOL をサポートするために、十分な移行経路を用意しています。さらに、EOLの日に、あなたが使っている残りのイベントルールをEvent Orchestrationに一対一で自動移行します。それ以降は、現在のイベントルールでできることは、すべてイベントオーケストレーションでもできるようになります。Event OrchestrationはEvent Rulesと同じ機能を持ち、同じバックエンドアーキテクチャを使用しているので、イベント処理には数十億イベント分のテストがすでに組み込まれていることを確認できます。

ウェビナー＆イベント

以下のウェビナーやイベントに参加し、PagerDutyの最近の製品アップデートと、それがどのように顧客に利益をもたらすかについて、より詳しく学びましょう。これらは多くの中のほんの一部です。

ウェビナー

セキュリティのキャリアを考える

10月はサイバーセキュリティ意識向上月間です。PagerDutyのセキュリティチームはエンジニアがプラットフォームを安全に保つのを助け、従業員にセキュリティトレーニングを提供するなど、様々な活動を行っています。PagerDutyのポッドキャスト「Page It to the Limit」の最新エピソードでは、Megg SageとPatrick RoserieがPagerDutyでどのようにセキュリティに取り組んでいるか、またそれ以外についてもご紹介しています。

Evolve to resolve: より少ないインシデント、より速いレスポンス（11月製品発表！）

SVP & GM of Emerging Products Jonathan Rende、シニアプロダクトチームメンバーのKat Gaines、Julia Nasser、Sam Ferguson、Hadijah Crearyと共に、最新の機能を深く掘り下げてご紹介しています。

インシデントワークフロー PagerDuty ステータスページとステータスアップデートの通知テンプレート インテリジェント・アラート・グルーピングのための柔軟なタイム・ウィンドウ 2022年に向けてアップデート! インシデントレスポンスOpsガイド

ライブコールルーティング。オンコールスタッフへの最速のコンタクト方法

PagerDutyのTim ChinchenとBen Wiegelmannと一緒にディスカッションしましょう。

Live Call Routingとは？ライブコールルーティングのワークフローとその理由 コード不要のライブコールルーティングのセットアップ方法 応答時間を短縮し、全体的な顧客体験を向上させるためにライブコールルーティングを使用している小規模から大規模の企業までの顧客の使用例

11月に開催されるイベントへの参加登録をお願いします

PagerDuty Community Twitch Stream

PagerDuty Twitch StreamとPagerDuty Community Twitch StreamのTwitchチャンネルで、デベロッパーアドボケイトが率いる最新のストリームに参加してください。過去のストリームはYouTube Twitch Streams Channelでご覧いただけます。

登録すると、ライブのお知らせや過去の録音を見ることができます。 私たちの放送を見逃しましたか？今後予定されている、または最近のTwitchストリーム（PagerDuty GarageとTerraform Time）、またはYouTubeビデオをご覧ください。 HowTo Happy Hour: Intelligent Alert Grouping With Mandi Walls, as well as Max Li and Everaldo Eguiar (Data Scientists from PagerDuty) (2022年9月30日) Process Automation and Rundeck OSS Release Notes v4.70 with Mandi Walls and Jake Cohen from PagerDuty (2022年10月12日) Twitchのストリームスケジュールを見て、11月に毎週開催されるストリームに参加してください。

もし、あなたのチームがこれらの機能拡張の恩恵を受けることができるのであれば、ぜひアカウントマネージャーに連絡して、14日間の無料トライアルに申し込んでください。

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

このブログは、Damon Edwardsが執筆した人気ブログのアップデート版です。

私たちの業界では、必要だけれども会社を前進させない仕事に対して、いつもローカライズされた表現を使っていました。SREの流行では、このような仕事を“Toil”（=骨折り仕事）と呼んでいます。

“Toil”という概念は、私たちの時間を奪い、社員のエンジニアとしての能力を発揮させず、会社を前進させない仕事を特定し、それを抑制するための公平な枠組みを提供することで、統一された力を発揮します。

なぜ“Toil”が問題なのか

残念ながら、「時間が足りない、やることが多すぎる」というのが、運用組織におけるデフォルトの労働条件です。新機能の導入、インシデントへの対応、サポート依頼、技術的負債の返済など、計画的な仕事と非計画的な仕事が無限に存在するのです。

1日の時間が限られている中で、自分が取り組んでいることが実際に効果を発揮するためには、どうすればよいのでしょうか。

チームや組織全体が、付加価値の高い仕事を最大限に生かし、そうでない仕事を排除するには、どうすればよいのでしょうか。結局のところ、組織とチームの決定が仕事の大部分を左右するのです。

エンジニア組織の価値と社員の人間力を最大化するためには、「間違った」労働を特定し、それを抑制し、「正しい」労働を最大化するための客観的なフレームワークが必要です。“Toil”とは何かを理解し、その量を抑制することは、会社に経済的利益をもたらし、仲間のエンジニアの労働生活を向上させます。

Toilの定義とは？

“Toil”という言葉を最初に広めたのはGoogleで、SREの動きもあり、その後、IT運用に押し出されるようになりました。

SREとは、一言でいえば、ソフトウェアエンジニアリングの手法と新しい考え方をIT運用に導入し、高い信頼性と拡張性を持つシステムを構築することです。Googleが「Site Reliability Engineering」という本を出版して以来、SREというトピックへの関心は急上昇しています。

この本の中で、Vivek Rauは、「Toilとは、生産サービスの運営に関連する作業のうち、手動で、反復的に、自動化可能で、戦術的で、永続的な価値を持たず、サービスの成長に伴い直線的に拡大する傾向のあるものである」という優れた定義を明らかにしています。

これらの属性が多ければ多いほど、自信を持ってその仕事を“Toil"に分類できるでしょう。しかし、仕事が "Toil "に分類されたからといって、その仕事が取るに足らないものであったり、不必要であったりするわけではありません。それどころか、ほとんどの組織は、”Toil”がなければ止まってしまうでしょう。

“No Toil”という目標は、理屈ではよいことでしょう。しかし、現実には、“No Toil”という目標は、ビジネスでは達成できないものです。技術組織は常に流動的であり、新しい開発（期待されるもの、予期されないもの）は、ほとんどの場合、 “Toil”を引き起こします。顧客に価値を提供するために必要な仕事だからといって、それが常に付加価値のある仕事であるとは限りません。労力は時に必要かもしれないが、永続的な価値（＝顧客による価値認識の変化）を付加するものではないのです。長期的には、 “Toil”の必要性を除去していきたいものです。

最善策は、 “Toil”の削減と、組織全体で“Toil”を管理可能なレベルに維持することです。手間は、分かっていても自動化する時間や予算がない場合にも発生します（半手動の導入、スキーマ更新/ロールバック、ストレージクォーターの変更、ネットワーク変更、ユーザー追加、容量追加、DNS変更、サービスフェイルオーバーなど）。また、予期せぬ事態が発生した場合、手動での介入を必要とするインシデントが発生します（例：再起動、診断、パフォーマンスチェック、構成設定の変更）。

“Toil”の代わりに人がすべきことは何か？

エンジニアが付加価値のない作業に時間を費やす代わりに、付加価値のあるエンジニアリング作業にできるだけ多くの時間を費やせるようにしましょう。

また、Vivek Rauの分かりやすい定義から引用すると、エンジニアリングワークは、人間の判断を必要とし、永続的な価値を持ち、他者に活用される創造的で革新的な仕事と定義できます。

”Toil”に対してエンジニア仕事の比率が高い組織で働くと、誰もが目標に向かって泳いでいるように感じられます。”Toil”に対してエンジニア仕事が低い組織で働くと、よくても立ち泳ぎか、悪いと沈んでいくような感覚になります。

高いレベルの”Toil”は有害である

”Toil”は、少しであれば無害に思えるかもしれません。しかし、”Toil”は放っておくとすぐ蓄積し、個人と組織両者にとって有害なレベルになってしまいます。

高レベルの”Toil”が個人にもたらすものは、以下のとおりです。

不満がたまり、達成感が欠如する 燃え尽き症候群 ミスが増え、修正に時間がかかり、手戻りが発生する 新しいスキルを身につける時間がない キャリアの停滞（付加価値の高いプロジェクトを提供する機会がないため、キャリアに傷がつく）

高レベルの”Toil”が組織にもたらすものは、以下のとおりです。

チームの余裕の不足 過剰な運用サポートコスト 戦略的イニシアティブが進まない（「みんな忙しいのに、何もできない」症候群） 優秀な人材の維持ができない（組織の機能が知られると、優秀な人材を獲得できない）

“Toil”の最も危険な点は、それを解消するためにエンジニアリングワークを必要とすることです。

工数を削減するためには、手作業の必要性を自動化するための自動化機能を構築するか、そもそも手作業の必要性を軽減するためにシステムを強化するためのエンジニアリング時間が必要です。

“Toil”を削減するために必要なエンジニアリング作業は、一般的に、外部オートメーション（サービス外部のスクリプトや自動化ツール）の作成、内部自動化（サービスの一部として提供される自動化）の作成、または保守介入を必要としないようにサービスを強化することのいずれかです。

“Toil”は、将来の“Toil”を防ぐためのエンジニアリング作業に必要な時間を食いつぶします。注意を怠ってしまうと、組織内の“Toil”のレベルは、それを阻止するのに必要な能力を組織が持てないところまで上昇する可能性があるのです。Technical Debt（技術的負債）のメタファーを用いると、これは 「エンジニアリングの破産」といえるでしょう。

SREの働き方とそれに伴うメリットは、チームにエンジニアリングワークのための十分な余裕があるかどうかにかかっています。この余裕の要件が、“Toil”がSREの中心的なコンセプトである理由です。もし、“Toil”がエンジニアリング業務の余裕を食いつぶしてしまったら、SREモデルは成り立ちません。”Toil”に永遠に埋もれているSREは、SREではありません。新しい肩書きを持った、従来の長い間苦しんできたシステム管理者に過ぎないのです。

PagerDutyが“Toil”を気にする理由

私たちの大きな目標のひとつは、運用担当者のワークライフを改善することです。“Toil”を削減し、エンジニアリングの時間を最大化することは、まさにその通りです。

ユーザーは、“Toil”を削減するためにPagerDuty Process AutomationとRundeckをどのように使用しているかを示してくれました。

その利点は、以下の通りです。

手順の標準化により、バラツキやミスを減らして労力を軽減すること。 これまで多くの“Toil”を必要とした作業を自動化することで、“Toil”を軽減するエンジニアリング作業を容易にすること セルフサービスを可能にし、他者が運用作業を自分でできるようにすることで、あるチームが他のチームのために運用するのを阻止すること

PagerDuty Runbook Automationについてのお問い合わせがあればこちらまでご連絡ください。

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

今年もこの時期がやってきました。PagerDutyがAWS re: Invent 2022のためにシン・シティに戻ってきます！このグローバルコンファレンスでは、あらゆる規模の企業が参加し、クラウドの近代化、自動化、回復力をテーマに議論が行われます。現在の経済状況において、企業は常時接続のデジタル体験を顧客に提供しながら、運用を拡張し、コストの最適化を求めています。Automatonは、運用とコストの効率化をサポートする上で重要な役割を果たします。今年、私たちはre:Inventの会場に新しいソリューションを持参できることをうれしく思っています。 Automated Diagnostics for AWSは、エンジニアリングチームがより多くの時間をイノベーションに費やし、中断しないよう支援します。また、re:InventのPlatinum Sponsorとして、AWSとの長期的な関係を深め、お客様と共同で自動化されたCloudOpsを提供できることを誇りに思っています。

クラウドは世界を食べている

Gartnerによると、「2023年までに、企業の全ワークロードの40%がクラウドインフラとプラットフォームサービスに展開され、これは2020年の20%から増加する」とのことです。この言葉は、サービスとバックエンドインフラのさらなるデジタル化を目指す企業にとって、クラウドの導入が引き続き最重要課題であるという現実をより突きつけています。AWSは、これまでにないスケール、アジリティ、イノベーションのスピードを提供しますが、チームは、システム、プロセス、組織にわたって複雑性が増し、依存関係がますます大きくなっていることに直面します。この複雑な状況は、収益はもちろんのこと、顧客と従業員のエクスペリエンスを危険にさらす恐れがあります。

組織がクラウドに移行し、クラウドネイティブアーキテクチャを展開するにつれ、複雑さが増すと、より多くの（費用のかかる）インシデントを引き起こす可能性があります。多くの企業は、相互に接続された複数のサービス（多くは一時的に存在する）を含む複雑なクラウドアーキテクチャを使用しており、それらは異なるアベイラビリティゾーンやアカウントにまたがって展開されています。インシデントが発生すると、根本的な原因や、適切なアクセス権限や専門知識を持つ人を理解できないまま、解決に長い時間がかかることがあります。これは、多くのエスカレーションが発生し、開発者が価値の高い仕事から引き離されることを意味します。

インシデントは高くつくものです。大手小売業者の場合、サイトが1分ダウンするごとに、1分当たり20万ドル以上の売上が失われる可能性があります。また、インシデントが発生すると、エンジニアは新機能の構築やイノベーションに集中する代わりに、問題の解決に取り組むため、生産性コストが発生します。インシデントが原因で、あるいはインシデント発生中に顧客体験が低下すると、ブランドの評判という形でさらにコストがかかる可能性があります。これらの要因を全て合わせると、インシデントがもたらすコストは、想定していたよりもはるかに高くなります。

レジリエンス（回復力）の重要性

顧客がデジタル体験をほとんど中断することなく楽しむためには、レジリエンスが不可欠です。しかし、現実は厳しいものです。物事が壊れ、サービスが停止することは避けられません。それは誰にでも起こることです。本当に重要なのは、どれだけ早く復旧してサービスを再開できるか、また、今後同様の事態が発生しないようにできるかです。ハイブリッド・インフラストラクチャーを完全に可視化し、問題の迅速な検出・診断は、ビジネスと全てのサービスを継続するために必要不可欠です。

レジリエンスはただ起こるのではなく、責任の共有です。お客様は、インシデントに耐え、迅速に対応できるように、インフラ、運用、および人員を設定する必要があります。チームが自分たちのサービスを構築し所有することで、明確な所有権と説明責任を定義することは、集中したリアルタイムのインシデント対応を確保するために不可欠な要素です。

PagerDutyは、エンドツーエンドのインシデント対応と高度な自動化機能によってチームを強化し、いつでも迅速かつ正確に、正しい対応を指揮します。プロセスの自動化により、インシデントの迅速な診断と解決が可能になり、エスカレーションの回数とMTTRが大幅に削減されるため、エンジニアリングチームは継続的な改善とイノベーションに集中できるようになります。

人間が多く、時間がない

AWSのお客様の最新のクラウドアーキテクチャーは、市場で利用可能な約250のAWSサービスと2万5000のSaaSワークフローに、自社開発のソフトウェアやその他のレガシーシステムが組み合わされたものです。

このような複雑なクラウド環境でインシデントが発生した場合、根本原因を特定し、依存関係の中から他の可能性を排除し、誤検出をチェックするために、クラウドスタックの専門知識をフル活用することがしばしば必要とされます。このため、最前線のレスポンダーは、複数の専門エンジニアにエスカレーションして診断を依頼し、最終的な解決者を決定する必要がある場合があります。

最前線のレスポンダーは、AWS環境での診断内容を収集するノウハウやアクセス権がないことが多いです。最前線のレスポンダーの多くはジェネラリストであり、サービスにおける特定の問題を診断するために必要な調査に関する、技術的な知識を持ちません。また、セキュリティーポリシーにより、技術的な調査を実行するためのスーパーユーザーアクセスもありません。

このため、最初のレスポンダーは通常、インシデントのトリアージに必要なデータを得るために複数の専門家にエスカレーションしなければならず、インシデントの解決に多くの時間を費やし、より多くのチームメンバーに支障をきたします。深刻な機能停止の場合、インシデントの解決にかかる時間を不必要に長びかせ、エンジニアを価値の高い作業から遠ざけてしまい、停電の全体的なコストを増加させることにつながります。自動化は、インシデントを迅速に解決するだけでなく、インシデントを自分で解決するために必要な診断データを最初のレスポンダーに提供し、貴重なエンジニアリング時間を保護するという重要な役割を果たすのです。

Automated Diagnostics for AWS

Automated Diagnostics for AWSを使用すると、インシデントレスポンダーが自分でインシデントのトリアージを迅速に行い、ヘルプをエスカレーションする必要性を減らし、顧客に対する解決を迅速化し、運用効率を向上させます。PagerDutyのAutomated Diagnostics for AWSでは、Amazon EC2、AWS Lambda、Amazon ECS、Amazon RDSなど、よく使われるサービス向けの診断ジョブテンプレートがあらかじめ用意されています。お客様は、これらのテンプレートジョブを特定の環境で動作するように簡単に設定し、ワークフロー内の診断ステップを拡張できます。また、Automated Diagnostics for AWSでは、AWS向けの独自の診断ジョブや、PagerDuty Incident Response内のレスポンダーが呼び出したり、PagerDuty Event Intelligenceがトリガーする緩和・修復のための修正オートメーションの迅速な設計が可能です。

カスタマーサービスチームとステークホルダーは、リアルタイムのステータス情報によって調整され、よりよいカスタマーサポート体験を提供できます。自動化により、MTTRを25分短縮し、インシデントの解決に必要な人数を減らし、エスカレーションの回数を40%減らすことで、社内チームがより効率的に運営できるようになり、時間とコストを削減しながらカスタマーエクスペリエンスを向上させられるのです。

Automated Diagnostics for AWS

インシデントのトリアージ、ミティゲーション、および解決を行う力を持つ最初のレスポンダーを強化し、MTTR を全面的に改善します。 あらかじめ組み込まれたジョブテンプレートと、重要なAWSツールやサービスへのプラグイン統合により、エンジニアへのエスカレーションを削減します。 AWS環境におけるインシデントレスポンスの効率を継続的に向上させ、エンジニアに時間を還元できます。

Automated Diagnostics for AWSの詳細についてはこちらをご覧ください。

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

_Thomas Pin（データサイエンティスト）著 _ PagerDutyには早期警告システム（EWS）モデルがあり、カスタマーサクセス部門とセールス部門が製品の使用状況と外部ビジネス要因に基づいてPagerDutyの既存顧客の健全性を確認するのに役立っています。この早期警告システムモデルは、アカウント解約につながる製品の使用状況の悪さを特定するための重要なインフラであり、最初の防衛線となっています。早期警告システムモデルの成功とカスタマーサクセス部門の多大な努力により、リスクの高い製品の使用は減少しました。このようなクリティカルなモデルの生産には、常に正確なスコアを生成し、常に更新することが最も重要なことです。

2021年1月、早期警戒システムモデルが、アップストリームの変更によって不正確な顧客リスクスコアをリリースし、結果として誤ったスコアが数日間公開されることになりました。とあるカスタマーサクセスマネージャーがこの不具合について問い合わせてくれたおかげで、すぐにモデルを診断し修復することができました。社内でDataDutyと呼ばれているデータプラットフォームとビジネスインテリジェンスチームは、今後同様の問題が起こらないように解決策を模索することになりました。

上に挙げた問題は、PagerDutyに限ったことではありません。データサイエンス界では、これはモデルドリフト の一例であり、アップストリームのデータ変更だけでなく、さまざまな形で現れます。DataDutyチームは、このような問題が発生した場合、自動テストとPagerDuty Alerts を使用してこの現象の影響を最小限に抑えることを決定しました。

PagerDuty

PagerDutyの製品は、モデルドリフトを回避するためのプロアクティブなパズルの重要なピースです。機械学習モデルが複数のプラットフォームを活用するようになると、複数のプラットフォームのログを取り込み、インシデントを作成し、優先順位に基づいてエスカレーションし、実務担当者に警告することは、PagerDutyのような専用のインシデントトリアージソフトウェアなしでは不可能になります。自動化されたテストがどれだけ堅牢であっても、その結果を適切なタイミングで適切な担当者に届けることができなければ意味がありません。PagerDutyのおかげで我々の戦略は成功し、モデルの実務担当者が気づく前に有害な変化を捉えることができました。

モデルドリフト

モデルドリフトは、コンセプト、データ、アップストリームの３つに分類され、それぞれ異なるアプローチで解決することが求められます。

コンセプト ：モデル対象の定義の変化 データ ：重要なインプットが重要でなくなる アップストリーム ：根底にあったアップストリームデータの変化

コンセプトドリフトテスト

概念の変化を検出するテストは、データサイエンティストやステークホルダーが作り上げる構成であるため、なかなか書けません。しかし、早期警戒システムモデルの場合、ターゲットは「解約」（churn）であり、その定義は分かりやすいです。PagerDutyでは、「解約」はアカウントが有効化されるか無効化されることと定義されており、この定義は安定的に維持されています。

早期警戒システムモデルが顧客のリスクスコアを正しく予測していることを測定するために、いくつかのユニットテストを実施しています。

早期警告システム以前、PagerDutyの月次解約率はx％からy％の間でした。従って、月次解約率がz％以上であれば、問題であると考えられます。 早期警戒システムの全体的なスコアのセグメントは近年安定しており、個々のアカウントのスコアは時間の経過とともに増減する可能性があります。ただし、PagerDutyでは、アカウントの25％を低顧客リスクスコア、25％を中低顧客リスクスコア、25％を中顧客リスクスコア、25％を高顧客リスクスコアに配分することを想定しています。* 実際の数値ではありません。 早期警報システムの月平均スコアは従来、早期警報システムの平均スコアに対して2.5％の許容範囲内にあります。

もしこれらのテストのいずれかが失敗した場合、それは優先度が高いと分類され、PagerDutyはDataDutyのオンコールデータサイエンティストの１人にアラートを送り、モデルの「解約」の定義が正確かどうか、更新が必要かどうかを調査させることになります。

データドリフトテスト

時間の経過とともに、モデルの特徴量は早期警告システムモデルのスコアとの関連性が高くなったり低くなったりすることがありますが、PagerDutyはこうしたリスクを軽減するためのテストを開発しました。例えば、昨年は重要な指標の１つとして、「受任」されたインシデントの割合（ インシデント受任率 ）がありました。これは、アカウントの解約の可能性を予測するために関連する特徴量でした。しかし、最近になって緊急性の高いインシデントの承認率がより適切であることが分かり、当初の インシデント受任率 に取って代わりました。PagerDutyでは、特徴量ストア内の特徴量の関連性を判断するために、以下のようなテストを行っています。

コーエンのdは、２つの平均の間の効果量を推定します。早期警戒システムのモデルエンジンは、顧客分布と解約された顧客分布の間の平均値の間に有意な距離を持つ特徴量を持つことに依存しています。 尖度は、２つの分布の間の「尾の長さ」を測定します。顧客と解約顧客の分布の尾には、大きなギャップがあるはずです。 コルモゴロフ–スミルノフ検定は、連続した一次元の確率分布の等質性のノンパラメトリック検定で、標本と基準確率分布の比較や、２つの標本の比較に使用することができます。早期警戒システムのモデルでは、顧客と解約顧客について２つの分布を比較します。 t検定は、２つのグループの平均値に有意な差があるかどうか、また、それらがどのように関連しているかを判断するために用いられる推測統計です。他の全てが失敗したとき、特徴量のために有意性を計算します。

その場合、PagerDutyはインシデントを作成し、DataDutyのオンコールデータサイエンティストの１人がその差異を調査することになります。さらに、これらの指標は四半期ごとに調査され、早期警告システムモデル内に新しい特徴量を追加すべきかどうか検討されます。

アップストリームデータドリフト

早期警報システムモデルのアップストリームには、関連する測定基準を保存して潜在的に利用するための集計データテーブルがあります。現在、監視が必要な９つの主要集計テーブルと、集計テーブルが参照する50以上の基本テーブルがあります。データの整合性とアップタイムを維持するために、PagerDutyの技術スタックには以下のようなものがあります。データウェアハウスにはSnowflake、データの整合性を維持するためのMonte Carlo、ジョブのスケジューリングにはApache Airflow、そして問題が発生した場合にインシデントトリアージを実行するPagerDutyが含まれています。例えば、データの「不良負荷」が早期警報システムモデルに影響を与えた場合、PagerDutyはインシデントを作成し、DataDutyのオンコールデータエンジニアに通知します。

PagerDutyとモデルドリフトの例

以下は、DataDutyチームの１人がオンコール中に受信したPagerDutyアラートの実例です。

このデータサイエンティストは、早期警戒システムのモデルスコアに何か問題があるかもしれないというアラートを最初に受け取りました。これらのテストはコンセプトドリフトを捕捉するために設計されているからです。インシデントの発生源は、モデルドリフトテストが存在する「ews_unittest」ソースでした。次に、データサイエンティストはfailed_textを確認し、顧客のリスクスコアの配分が全て予想される許容値より低く、指標の１つにあまり変動がないことに気づきました。データサイエンティストはこれまでの経験から、集計テーブルが更新されなかったため、failed_textのメトリクスは「ゼロになった」可能性が高いと推測しました。数分の調査の後、彼らはこれがインシデントの根本原因であることを確認しました。彼らはこのインシデントをデータエンジニアに再割り当てし、問題のメトリクスの元となる集計テーブルを再読み込みし、モデルの計算を再実行するよう注釈を加えました。30分以内に、モデルは「オールクリア」のサインを出し、カスタマーサクセスマネージャーが問題に気づく前に、正しいスコアが本番環境に送り込まれました。これらの自動テストとPagerDutyの力により、DataDutyチームは組織の運営に影響を与える前に、DataDutyのデータエンジニアの日常とデータサイエンティストの日常を最小限の中断で診断し、インシデントを解決することに成功しました。

データサイエンスモデルが、正確さと稼働時間を重視する組織にとって重要な基盤となった場合、データサイエンスチームは、モデルのドリフトを監視し、問題の最初の兆候で適切なステークホルダーに警告するテストの追加を検討する必要があります。データモデル実務担当者間の信頼を築くことは、ビジネス用機械学習モデルの成功に最も重要です。Kevin Plankはかつて「信頼は一滴ずつ築かれ、バケツごと失われる」と言いました。モデルドリフトがモデルの信頼に影響を与えないようにしてください。

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

PagerDuty Summitの初日です。専門的なプレゼンター、実用的なコンテンツ、教育セッションで、あなたのPagerDuty IQを高め、あなたのチームの運用エクセレンスを向上させる新しい方法をお見せできることを楽しみにしています。

このコンファレンスでは、私たちの大きなミッションが語られます。オペレーションに革命を起こし、チームが事後対応や修復作業に費やす時間を減らし、新しいイノベーションの実現により多くの時間を割けるようにすること です。PagerDutyでは、このオペレーションの未来は、ソフトウェアの構築と運用を行うデジタルチームだけでなく、組織内の全てのチームにまで広がると考えています。このミッションを実現するために多くのPagerDuty製品と機能が存在しますが、今回はPagerDuty Process Automation®ポートフォリオの一部で、最新かつ最高のPagerDuty Automation Actions®に焦点を当てたいと思います。

新しいアップデートとAutomation Actionsとの統合

Automation Actions は、第一線のレスポンダーをPagerDuty内の修正オートメーションに直接つなげます。インシデントが発生したときに専門家にエスカレーションする代わりに、対応者は安全に委譲された自動化機能を使用して、インシデントのトリアージと解決を自分で行うことができます。その結果、チームはMTTRを短縮し、専門家の業務中断を減らし、インシデントの診断と修復を迅速に行うことができます。

私たちは昨年、組織が自動化へのシンプルな第一歩を素早く始められるよう、Automation Actionsを発表しました。現在、Automation ActionsはPagerDutyプラットフォーム全体に統合されています。全てのユーザーが、ブリッジコールに持ち込まれた問題の診断などの手動で時間がかかる反復作業を取り除くことができます。

Automation Actionsを使った最新かつ最高の自動化機能を見てみましょう。

インシデント対応におけるAutomation Actions。** チームは、PagerDuty内で直接、自動化された診断を実行し、インシデントを修復することができるようになりました。このインテグレーションにより、繰り返しの多い手作業が自動化され、生産性が向上し、エンジニアがイノベーションに集中するための時間を取り戻せます。

カスタマーサービスオペレーションのためのAutomation Actions。** この統合により、カスタマーサービス担当者は、顧客の問題を検証し、自動化によって重要な情報を取得し、ケースの診断と解決を迅速に行うことができるようになりました。エージェントは、顧客に影響を与える問題を検証し、Service CloudのPagerDutyアプリケーションから直接自動化されたアクションを実行することができるようになりました。

Event OrchestrationのためのAutomation Actions。** ネストされたイベントルールと機械学習、正確な自動化トリガーを組み合わせることで、レスポンダーが呼び出される前にインシデントに対処できます。Event Orchestrationとの統合により、一般的な診断を自動化し、繰り返し発生し熟知された種類のインシデントの自己回復を可能にし、MTTRと専門家へのエスカレーションを削減することができます。

PagerDutyのモバイルアプリでの自動化アクション。** Automation Actionsの全てがモバイルに対応しました！Automation Actionsから同じ自動化を呼び出して、PagerDutyモバイルアプリから直接一般的なインシデントを解決します。

Slackでの自動化アクション。** このインテグレーションにより、インシデントレスポンダーはスクリプト可能な診断と修復アクションをSlackから直接展開できます。

あらゆる場所で自動化

デジタルの複雑性と依存性が高まる中で何にでも対応できるようにするためには、手動、硬直的、チケットキューをベースとしたオペレーションから、成果と顧客体験を重視し、運用スピードと回復力を実現し、機械学習とAIによって大幅に自動化された、継続的に改善されるシステムへと変革する必要があります。 そうすることで、チームはより積極的な姿勢に移行し、手作業の負担を軽減し、燃え尽き症候群を回避し、集中力を維持することができるのです。Automation Actionsを使用することで、チームはこの運用上のマイルストーンに到達できるだけでなく、自動化能力をさらに向上させ、成熟させ続けることができるのです。

PagerDutyサミットでAutomation Actions関連セッションもチェックしてください。

Normalize Automation** , Sean Noble, Principal Product Manager, PagerDuty Is it the Cloud? App? Database? Reduce Escalations by giving first responders automated diagnostics** , Jake Cohen, Senior Product Manager, PagerDuty

PagerDutyの自動化ポートフォリオについてもっと知りたい方は、自動化ハブをご覧ください。PagerDuty Automation Actionsについて、また、それがどのようにチームの時間とコストの節約につながるかを知りたい場合は、アカウントマネージャーに連絡するか、今すぐ詳細をご覧ください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

私たちPagerDutyの目標は、お客様が働いている場所で、お持ちのツールで対応できるようにすることです。私たちは、補完的なテクノロジーパートナーとの650以上のインテグレーションを提供できることを嬉しく思っています。これらのインテグレーションにより、お客様はPagerDutyプラットフォームから得られる価値を最大化することができ、また独自のインシデント対応プロセスを定義することができます。

本日、PagerDuty for Google Chatを発表することができました。PagerDuty for Google Chatは、GoogleがPagerDutyとの緊密な協力のもとに構築したものです。PagerDuty for Google Chatは、インシデントレスポンダーが通知を受け、解決を開始し、コンテキストを切り替えることなく目の前の問題に集中することを可能にします。 重要なアクションは、適切なチームメンバーを含むGoogle Chatの会話から開始することができ、また、追加のステークホルダーに適切なレベルの可視性を提供することができます。

GoogleスペースからPagerDuty for Google Chatをインストールするには、次の３つの簡単なステップを実行します。

コマンド「@PagerDuty」を入力します（アプリのインストール権限をGoogle管理者から付与される必要があります）。 インテグレーションを承認します（サブドメインのAdminまたはAccount Owner権限を持つPagerDutyアカウントにサインインします）。 PagerDuty ServicesとGoogle Spaceを連携させるために、「/pd_settings」コマンドを実行します。

PagerDuty for Google Chatがインストールされ、設定されると、以下のことが可能になります。

Googleチャットからインシデントを管理

インシデントレスポンダーは、トリガー、通知、承認、解決などのインシデント対応の主要なアクションを、すべてGoogle Chatの会話から離れることなく実行できます。

インシデント対応と解決の迅速化

レスポンダーは、自分やチームメイトが働いている場所で発生した新しいインシデントについて、Google Chatでリアルタイムに通知されます。デスクでも、外出先の携帯電話でも、どこにいてもです。

適切なチームメンバーとの協働

対応者は、専用のウォールーム（またの名をGoogle Space）を作成し、必要な専門家を追加することができます。これにより、ステークホルダーに可視性を提供し、より迅速なコラボレーションを実現することで、インシデントの解決を早めることができます。

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