PagerDuty、分散環境やゼロトラスト環境での運用を簡素化する新しい自動化機能を発表
Rundeck by PagerDutyは、組織が運用のサイロを埋め、ITタスクを自動化することで、チームがより多くの時間を構築に集中し、火消しに割く時間はできるだけ短くするよう、長年支援してきました。このミッションは今日でも真実ですが、私たちのビジョンは、この現実を拡張し、信頼を築き続けながら、全ての業務に革命を起こすことです。
PagerDuty Operations Cloudは、影響力の大きい作業をより迅速かつ効率的に解決するために、プリプロダクションやプロダクション、分離型やセキュア、マルチクラウドやオンプレミスなど、あらゆるIT環境において価値を提供します。私たちは、お客様がいる場所でお会いし、お客様が必要とする価値を提供したいと考えています。
今日から、このビジョンは現実のものとなりました。
PagerDuty Runbook AutomationとPagerDuty Process Automationの次世代アーキテクチャー を導入することで、お客様がクラウド、リモート、ハイブリッド環境での自動化を管理する方法を簡素化できることを大変嬉しく思います。
この最新の機能こそが、Runbook AutomationがPagerDuty Operation Cloudに不可欠な要素だという理由です。PagerDutyは、あらゆるインフラ、マルチゾーンのハイブリッド環境、ネットワークなどを自動化し、私たちがよく知る、予定外の、時間的制約のある、インパクトの大きい仕事を解決できるようになりました。
セキュアなインフラ全体にわたる自動化を標準化
技術革新の急速な進展に対応するために、自動化が不可欠であることは明らかです。また、企業は成長と変革を維持しながら、同じリソース、あるいはさらに少ないリソースでより多くのことをこなさなければなりません。さらに、分離された環境と異種サービスは、ハイブリッドクラウドの現実とセキュリティーや規制要件の増加によって複雑さを増しています。このようなIT環境の乱立は、部門や技術的なサイロに加え、新たな次元の組織のサイロを生み出すことになりました。
従来の自動化ツールは、最新の分散環境におけるセキュリティー要件の複雑さを想定して作られていなかったということです。その結果、エンジニアは各環境のオペレーションを手動で実行しなければならず、長い待ち時間、より多くの人員の時間消費、より高いレベルのエンジニアの労力を引き起こしています。この断片的な自動化の問題を解決するためには、さらに何かが必要です。各プロジェクトや環境に新しい自動化オペレーションを手動で構築することなく、インフラ全体を完全に可視化し、分散した自動化ジョブをシームレスに実行する機能が必要です。
この新機能により、各環境で自動化ステップを手動で起動する代わりに、エンジニアは単一の管理画面から自動化タスクを管理・実行し、その自動化を多くの分離された環境に分散させることができるようになりました。
その結果、チームは次のことができるようになります：
クラウドやデータセンター環境での自動運用を可能にすることで、より迅速な運用を実現します。 ハイコンプライアンスやゼロトラストアーキテクチャーで運用する際のセキュリティーの簡素化 全てのゾーン、環境、ネットワークにおいて、タスクの解決を迅速化し、作業時間を短縮することで、省力化できます。。
新機能によってどのように実現されるかをよりよく理解するために、現在・将来のお客様のために解決したい課題について触れてみましょう。
セキュリティを考慮したスケールと効率化を可能にする
自動化によって新しいレベルのスケールとイノベーションの可能性が開けることは事実ですが、同時に複雑さ、接続性、セキュリティーに関する重大な課題ももたらされます。これはテクノロジーチームにとって、維持する必要のある孤立した環境内の依存関係、チェックする必要のある分散したネットワークエンドポイント、安全に管理・実行する必要のあるリモートとローカルの環境に広がる断片的な自動化の島を追加することを意味します。
お客様からお聞きする大きな課題の１つは、高いセキュリティーとコンプライアンスを要する環境での自動化の管理と実行に関するものです。多くの場合、エンジニアは、各ゾーン内の多くのセキュリティーの機微とプロセスの依存性のために、いくつかの分離された環境のそれぞれを手動で管理する必要があります。
PagerDuty Runbook Automationは、以下のような厳しい要件を持つお客様の分散したオペレーションをつなぐパイプ役となります：
環境がバラバラ？問題ありません：** Runbook AutomationとProcess Automationは、リモート環境での自動化ステップのオーケストレーションをローカルと同じように承認し、同じジョブ定義に多くの環境を組み込むことができるようになりました。これにより、自動化を妨げるネットワークサイロを排除し、これらの環境で適切に実行するために手動でログインする必要がなくなります。 コンプライアンス監査？大丈夫です：** Runbook AutomationとProcess Automationは、アクセスコントロールとロギングをオートメーションに組み込み、これらの機能をリモート環境に拡張することで、全て中央のコントロールプレーンでコンプライアンスを簡素化します。 ゼロトラストセキュリティー？問題ありません。** 高いセキュリティー要件を持つお客様のために、Runbook AutomationとProcess Automationは、SSHなどのポートをファイアウォールで開くことなく接続を可能にし、リモートオペレーションを可能にしました。この新機能により、お客様が独自のBastionやJumpホスト、パブリックエンドポイントを導入する必要性が減り、自動化への安全な接続が簡素化されます。
PagerDuty Runbook Automationがリモート環境で自動診断プロセスを実行し、環境状態を把握する例図。
新しいRunnerの機能
Runnerは、オートメーションサーバー自体からではなく、指定されたエンドポイント上で実行するノードステップのために構築されたリモート実行ポイントです。Process AutomationとRunbook Automationの両方で利用可能なRunnerは、データセンター、リモート環境、オートメーションクラスター間のネットワーク/通信を安全に開放します。
新リリースでは、プライベートネットワーク内でローカルに実行するAnsible、Docker、Kubernetesなどの一般的なインフラと統合された次世代Runnerを提供しています。この新しいアーキテクチャーにより、ジョブ作成者は複数の環境を組み込んだ自動化ジョブを開発できるようになりました。
新機能のハイライト
リモート環境から安全で弾力性のある接続を提供する次世代ランナーで、どこでもオートメーションを実行できます。 標準化されたオートメーションのオーケストレーションをあらゆる環境で動作させることができる分散型オートメーションステップで、複雑なアーキテクチャとジョブをサポートします。 強化されたRunner UIとAPIにより、設定、ステータス、認証情報の管理など、中央の自動化環境からのRunnerの管理を簡素化します。 Ansible、WinRm、Kubernetes、Dockerなどの一般的なテクノロジー用のリモートRunnerで利用できるプラグインで既存のスタックを統合し、ローカルおよびリモート環境で実行することができます。
プロセスオートメーションとランブックオートメーションは、リモート環境でのAnsibleやKubernetesの実行ステップを持つオートメーションワークフローと同じ幅を提供できるようになり、お客様のために新しい分散オートメーション機能のこの道を切り開くことで、さらに強化されていくでしょう。
今後の展望
Runbook AutomationとProcess Automationのこれらの新しい自動化機能は始まりに過ぎず、お客様がより幅広い安全な環境においてトリガーとなるワークフローを作成するための柔軟性を提供することによって、PagerDuty Operations Cloudの価値を強化しています。
3月30日（木）に開催されるウェビナーに登録し、PagerDutyプロセスオートメーションポートフォリオの最新リリースについて詳しく聞いてみませんか？ご不明な点やご興味のある方は、お問い合わせいただくか、プロセスオートメーションのページをご覧ください。
この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
ニュース＆告知
PagerDutyの気候公平性投資の道のり：学習、パートナーシップ、そして次のステップ
PagerDutyは、ミッションドリブンの各組織が緊急のニーズに即応できるよう支援することを目的として、2019年にインパクトファンドを立ち上げました。それ以来、私たちは既に400万ドル以上を分配して、人、製品、声の力を動員し、より公平な世界の構築を支援するために、Time-Critical Health（緊急性の高い健康問題）とJust & Equitable Communities（公正で公平なコミュニティー）という２つの重点分野での戦略的な慈善投資を優先して進めています。2022年、Googleは公正で公平なコミュニティーへの投資を優先するためにClimate Equity Fundを立ち上げました。
気候変動は、私たちが地球規模で直面する喫緊かつ複雑な課題です。これは、気候変動の影響が世界中の経済的・社会的に疎外されたコミュニティーに不均衡に影響を与えるため、公平性の観点から重要です。これらのコミュニティーは普通、気候変動の原因にほとんど貢献していませんが、彼らを癒しと成長の中心に据えるソリューションを構築するために相談されたり、投資されたり、信頼されたりすることはめったにありません。コミュニティーソリューションは重要ですが、それだけでは不十分です。企業にとって、絶滅の危機に瀕した地球への解決策に積極的に取り組むことは、長期的な価値創造にとって重要です。環境保護主義者で登山家のDavid Brower（訳注：自然保護団体Sierra Clubの初代事務局長を務めた著名な環境保護主義者）が言ったように、「死んだ惑星でやるべき仕事はありません。」
学習と資金調達の原則
気候の公平性をサポートすることが不可欠であることを念頭に置いて、私たちは昨年、深い学習の旅に没頭してきました。私たちは昨年の冬、好奇心と謙虚さを備えた資金提供者として参加することを目的として、この作業を開始しました。私たちの目標は、セクターとそのリーダーのニーズに耳を傾け、学び、フォローすることでした。2022年２月に４つの気候公平性組織に25万ドルの初期投資を行いました。これらの組織やその他の気候リーダーとのパートナーシップから得た重要な教訓には、次のようなものがあります。
- 世界の慈善寄付のうち、気候変動の公平性に向けられるのはわずか２%で、コミュニティー主導のグループに向けられる寄付は１％未満です。この深刻な資金不足に注意を喚起し、解決のためにより多くの資金とリソースを活性化するために、これらの数字を共有します。 長期的に成功するためには、気候変動の影響を最も大きく受けるコミュニティーを中心に据えた気候ソリューションが必要です。 企業の資金提供者にとって、気候変動の公正な取り組みに真摯に取り組むことは、社内と社外の仕事です。言い換えれば、コミュニティーの取り組みに資金を提供することは良いことですが、十分ではありません。また、私たちのビジネス慣行が意図しない否定的な結果にどうつながるか可能性があるかを含め、私たちの貢献について全体論的に考える必要があります。害を加えるシステムを永続させておいて、その症状を緩和するために慈善活動を利用することはできません。
私たちのパートナーシップ、対話、学習から得た情報に基づいて、気候変動に対する公平な慈善活動を前進させるための４つの資金調達原則を策定しました。
私たちの資金は、ギャップを埋めるときに最も効果的です。私たちは有色人種と女性が率いる組織、例えば気候変動の矢面に立たされている地域や最前線のコミュニティーとそのリーダーを中心とした気候ソリューションを引き続き優先します。 継続的な学習と関与は、資金提供者としての信頼を築き、最終的には気候の公平性の分野でリーダーになるための鍵です。私たちは相互学習を求め、学んだことをオープンソースにして他の人に利益をもたらします。 最前線の組織への直接的な資金調達と仲介者を通じた資金調達を組み合わせて、多様なポートフォリオの構築を目指します。 ミッション関連の投資、プログラム関連の投資、インパクト投資など、あらゆる分野で慈善資本を活用します。資本の展開方法を多様化することで、ソーシャルインパクトのイノベーターやリーダーを、そのインパクトとビジネスモデルにとって最も価値のある種類の資金調達でサポートすることができます。
新しいパートナーシップ
これらの基本原則に沿って、コミュニティーで構築された気候ソリューションを実現している２つの驚異的な組織とのパートナーシップを発表できることをうれしく思います。これらの組織は、無制限の助成金、スキルベースのボランティア活動、PagerDuty Operations Cloudプラットフォームへのアクセス、広報強化など、PagerDutyのあらゆるサポートを受けられます。これらの組織とその影響について詳しく知ることをお勧めします。
Navajo Power Home：Navajo Power Homeは、アリゾナ州、ニューメキシコ州、ユタ州の２万7000平方マイルを超える地域であるナバホ保留地のオフグリッド住宅にソーラーサービスを提供しています。ナバホ保留地の家庭の３分の１は、信頼できる電力にアクセスできません。Navajo Power Homeは、フルサービスの太陽光発電を提供することで、この状況を変えています。この投資は、先住民主導の組織が受け取った気候資金の0.3％に影響を与え、Navajo Power Homeが 2030 年までに１万以上の家庭に手頃な価格でクリーンな電力を供給するのに役立ちます。
「電気のないナバホ保留地で育ったことで、多くの家族が最初から暗闇の中にいましたが、太陽光発電のおかげで、今では電化製品を活用し、子供たちに宿題をさせ、食べ物を冷蔵しておけます。これにより、ここナバホ保留地での生活が楽になります。」– Navajo Power Homeのゼネラルマネージャー、Jerry Williams氏。
Beneficial Returns：Beneficial Returnsは、ラテンアメリカと東南アジアの社会的影響力のある起業家に融資を提供し、コミュニティーが直面する課題に対する気候変動に強いソリューションを構築します。彼らのポートフォリオには、エクアドルの先住民農家を支援し、インドネシアで浄水技術を開発し、メキシコの家庭に太陽光発電をもたらす社会的企業が含まれます。私たちは、７年間にわたってPagerDuty.orgインパクトファンドに返還されるミッション関連の投資ローンと、一般的な運用コストに対する少額の助成金を組み合わせて、Beneficial Returnsに投資しています。この創造的な資本の取り決めにより、Beneficial Returnsは、気候変動の影響を過度に受けている地域の社会起業家をサポートすると同時に、全範囲のソーシャルファイナンスで私たちの学習の旅をサポートすることができます。
PagerDutyの気候公平性の旅は次にどこへ？
これは気候変動に対する私たちの慈善活動の始まりにすぎません。2023年も、コミュニティー主導の取り組みと気候の公平性に関する技術ソリューションを引き続きサポートしていきます。私たちは、完全にパートナー主導のアジェンダでパートナーをまとめるために、史上初の年次パートナー会議を計画しています。私たちの目標は、パートナーがその影響力を拡大するために必要なリソースとネットワークに接続することです。慈善活動に加えて、私たちはビジネスの観点から気候ソリューションに取り組んでおり、意図しないマイナスの結果を軽減しています。2023年のGoogleの優先事項には、Science-Based Targets Initiative（SBTi）を通じて短期的な気候目標を設定することにより、パリ協定に沿った気候への取り組みを確立することと、職場、情報システム、財務その他の重要なビジネス分野のための強力な環境ポリシーを策定することが含まれます。 私たちは、デュートニアン、パートナー、企業のソーシャルインパクトの仲間たち、投資家と、私たちの進歩と学んだことを共有し続けます。
この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
ベストプラクティス
PagerDuty Process Automationでの自動化がビジネスにもたらす価値を計算する
IT部門の予算が厳しい昨今、プロジェクトの正当化や拡大には、投資対効果の証明が不可欠です。よいニュースは、自動化は必要な人間の労力を減らすことでコストを削減 できるということです。これは、ロボット掃除機に投資するのと似ています。初期費用はかかりますが、人間が掃除機をかける必要がなくなるので、時間（とお金）を節約できるのです。
自動化プログラムによってもたらされる価値の報告は、自動化の対象によってその価値が大きく異なるため、困難なケースがあります。プロジェクトの提案では、特定の手動タスクを自動化することで、時間やコストの削減を予測できます。このような節約を追跡し報告することで、プロジェクトのビジネスインパクトを示せます。では、トラッキングとレポーティングはどう簡素化できるのでしょうか。
PagerDuty Process Automationには、ROI Metric Dataプラグインという機能があります。ROI Metric Dataプラグインは、自動化が実行されるたびに価値を提供するというシンプルな原則に従っています。自動化開発者は、自動化で節約した時間:10などの主要な値を定義することで、価値の指標を指定します。
ジョブが実行されるたびに、これらのメトリクス値は実行のログエントリーに追加されます。また、このプラグインは、実行に関する他のメタデータとともに、これらの実行のJSONレコードを抽出するエンドポイントを提供し、これらのメトリクスを長期的にコンパイル、計算、分析することが可能です。 ではここから、自動化プロジェクトが提供するビジネス価値追跡のためのパターンをいくつか紹介します。
人件費削減による節約を報告する
タスクを自動化することで得られる最も直接的なメリットは、代替となる労働力のコスト削減です。PagerDuty Summit 2022でBrinks社のRobert Powers氏が共有したこのユースケースを例に挙げます。同社では、データ転送を繰り返し行っており、スタッフが5～10時間かけて手作業で行っていました。
このプロセスをPagerDuty Process Automationで自動化することで、毎週１人の仕事の1/4を占めていたこのプロセスを、自動タスクに変え、人間による作業時間を０にしました。
データ転送自動化プロジェクトのコスト、機会、利益の基準
ROI Metric Data Pluginを使ってこのシナリオで生成された価値を追跡するには、このプロセスの実行記録にこのメトリックを含めるために、値10でメトリックhours_savedを定義するだけです。これにより、このプロセスの実行ごとに節約された時間の合計を示す、簡単なメトリックをエクスポートできるようになります。自動化ジョブに機能を追加すると、これらの値は時間の経過とともに変化する可能性があるため、このような任意のキーバリューのアプローチを選択しました。この方法では、データをグラフ化する際に、キー名を変更しない限り、新しいバージョンの自動化の値を古いバージョンと比較できます。
あなた自身のシナリオでは、自動化を試みる作業を手作業している担当者が、どのくらいの時間をかけているかを判断したいところでしょう。これは望む最終結果に応じて正確にできます。見積もりでもいいですし、観察によって平均的な時間を割り出すこともできます。平均値や推定値は、hours_savedなどのキーとペアにした値になります。コスト削減や作業量分布の変化を追跡したい場合は、従業員の職種別にこれらを分けられます。キーと値のペアを、さらにDBA_hours_saved、senior_engineer_hours_savedなどに定義するだけです。投資対効果を計算したい場合は、自動化を作成するために必要な時間も記録しておく必要があります。また、分析時に値を金額で定義したり、時間を金額に換算したりすることもできます。
ここでは、ジョブの実行ごとに記録される2つのキーと値のペアを作成しました。Hours_Saved : 1.25 と Dollars_Saved : 250 です。
ジョブ実行データをTableauなどのお好みのレポートツールにアップロードしてください。ユーザーやジョブごとに異なる指標の集計を時系列でグラフ化できます。例えば、ユーザーによる手動実行とスケジュールされたジョブ実行で節約できた時間を表示できます。節約した金額は、定義したメトリクスから直接計算することも、異なる時間メトリクスをコストに変換することによっても計算できます。
ここでは、スケジュールされたジョブ実行とユーザーによるジョブ実行によって、お金と時間の節約につながることを示すログデータをチャート化した例を紹介します。
これらの指標を投資対効果に変換するには、自動化の導入に関連するコストを追加する必要があります。上記で紹介したお客様の事例では、20FTE時間（同等の人件費を想定）が自動化されたプロセス作成のためのコストとなりました。これに１年以上のメンテナンスが含まれると、次のようになります。520 FTE時間節約 - 20 FTE時間（自動化するための時間） = 500時間節約（運用開始1年目のみ）
自動化の成果でメトリクスを調整する
自動化が実行されればいつでも価値を提供するという原則に基づき、自動化の結果に応じた価値の算出が望まれるでしょう。これは、失敗したオートメーション実行をフィルターすることにつながります。
自動化の実行が失敗する理由はさまざまです。ジョブ定義自体に問題がある場合もあれば、ジョブを終了させないノードやワークフロー・ステップから報告されたエラーもあります。このような失敗した実行は、値計算の対象から除外することをお勧めします。
失敗したステップを含むジョブ実行例
アナリティクスを実行する際、統合されたシステムからの外部障害による失敗をフィルターするよう選択できます。
節約した時間やお金、仕事の状況が分かるチャート例
ROI Metric Data Pluginはバージョン4.7からPagerDuty Process Automationで利用できるようになり、PagerDuty Runbook Automationの一部として利用することもできます。ROI Metric Data Pluginを使用した作業の詳細については、Process Automation Documentationを参照してください。
まだPagerDuty Process AutomationまたはPagerDuty Runbook Automationのユーザーでない方は、今すぐデモまたはトライアルを予約してください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
ベストプラクティス
PagerDutyでオンコールの負担を大きく軽減！エンジニア横断で対応するココナラのインシデント対応-CodeZineの記事から
株式会社ココナラは、デザインやウェブサイト制作などの仕事や、プライベートからビジネスまでの相談を気軽に依頼できるマッチングサービスを提供しています。同社はITインフラの運用において、多種多様なアラートを管理し、適格なアクションを割り当てられるインシデント管理ツール「PagerDuty」を活用しています。PagerDutyの導入以前は、アラートの発報に時間がかかり、オンコール当番だけに負荷がかかるという課題がありました。そこでPagerDutyを活用し、DatadogやAmazon Cloud Watch、Sentryなどの監視ツールと連携させることにしたのです。優先度を見極めた発報が行われ、アラートの絞り込みも可能になり、効率化が実現しました。現在は、オンコール当番制度もあるため、平均確認時間（MTTA）は日中で1分以内となっており、 平均修復時間（MTTR）についても暫定対応は1営業日程度に抑えられています。
詳しくはこちらのCodeZineの記事をご覧ください。
「PagerDutyでオンコールの負担を大きく軽減！エンジニア横断で対応するココナラのインシデント対応」
ニュース＆告知
PagerDutyの新しいIncident Workflowsを深堀りする
インシデント対応における労力を軽減し、煩雑な作業を自動化できれば、チームはより迅速に問題の特定と解決に集中できます。そして、インシデントを迅速に解決するほど、新しい製品やサービスの構築に早く戻ることができるようになります。
11月の発表で最も期待されたものの1つが、インシデント対応の手動ステップを自動化するIncident Workflowsでした。本日、この機能が一般的利用可能になったことをお知らせできることをうれしく思います。PagerDutyをご利用のお客様は、本日よりご利用いただけます。
Incident Workflowsとは何ですか？
インシデント対応プロセスにおいて、専門家への連絡、コンファレンスブリッジの設定、Slackチャンネルの開設、ステータス更新の送信など、手動で行う手順を全て考えてみてください。インシデントが発生するたびにこれらのステップを覚えていては、ただでさえストレスの多いプロセスに不必要な認知負荷がかかることになります。このような繰り返しの多い手動タスクは、自動化の最適な候補となります。
Incident Workflowsは、インシデントの種類に応じて、必要なアクションを自動的に編成します。Response Playsのアップグレード版として、カスタマイズ可能なインシデントワークフローをノーコード／ローコードビルダーで作成できるようになり、エスカレーション、動員、あらゆるユースケースに対応する正しいインシデントレスポンスの調整に必要な手作業が軽減されます。レスポンダーの追加、ステークホルダーの登録、コンファレンスブリッジの起動など、if-this-that ロジックを使用して一般的なインシデント対応アクションを自動的にトリガーすることが可能です。
ここでは、その仕組みを紹介する短いデモをご紹介します。
では、Incident Workflowsを強力にする機能を詳しく見てみましょう。
条件付きトリガー
インシデントの種類によって、必要な改善手順も異なります。条件付きトリガーを使用すると、優先度、緊急度、ステータスの変更など、特定のインシデントフィールドの基準を満たしたときにワークフローを開始するロジックを作成できます。例えば、全てのP1およびP2インシデントに対して自動的にトリガーされる重大インシデントワークフローを定義できるようになりました。また、自動化をさらに進めたいユーザーのために、Event Orchestrationを使って優先度を設定し、Incident Workflowsがその優先度の変更を主なインシデントワークフローのトリガーとしてピックアップすることも可能です。
また、レスポンダーがインシデントの詳細ページから直接ワークフローを開始できる手動トリガーを利用することもできます。手動トリガーを追加すると、インシデントワークフローはPagerDutyウェブアプリ、モバイルアプリ、Slack、Microsoft Teams、またはAPIから直接トリガーできるようになります。
CollabOpsアクションの強化
ワークフローを設定することで、コラボレーションチャネル設定の時間を短縮できます。ワークフローアクションを使ってZoomコンファレンスブリッジを立ち上げたり、全てのインシデントレスポンダーとインシデントの更新を含む、インシデントごとのSlackチャンネルを作成したりできます。Microsoft Teamsのユーザーの方向けには、同等の機能を開発中ですので、ご期待ください。
簡単なコミュニケーションとコーディネート
効果的なインシデント対応には、社内外のステークホルダーに対してタイムリーで透明性のあるコミュニケーションを取ることが不可欠です。私の同僚であるHannah Culverが説明したように、[ビジネス対応計画を準備しておくことは、社内の部門横断的なチーム間の連携を強化し、また顧客対応チームが積極的なコミュニケーションを通じて顧客の信頼を維持するのに役立ちます。Incident Workflowsは、インシデントへのレスポンダーの追加、ステークホルダーの登録、ステータスの更新を自動化し、インシデントについて知る必要のある全ての人にリアルタイムで情報を提供することで、このパズルを簡単に解決できるようにします。
外出先でも解決
Incident Workflowsは、iOSとAndroidデバイスのPagerDuty Mobileでも利用可能です。犬の散歩中でも、デスクから離れていても、PagerDuty Mobileはあなたが行動を起こす必要のある、トップにあるオープンインシデントについてのアラートを出します。インシデントの詳細画面から、事前に設定したカスタム対応ステップのインシデントワークフローを手動で起動し、好みのモバイルデバイスから適切なチームと連携してインシデントの解決をスタートできます。モバイルデバイスからのIncident Workflowsのトリガーについては、Knowledge Baseで詳細をご覧ください。
統一されたプラットフォームでエンドツーエンドの自動化を実現
Incident Workflowsは、PagerDutyプラットフォームの他の自動化機能と組み合わせることで、チームがより迅速に解決し、収益への影響を最小限に抑えられるように構築されています。例えばEvent Orchestrationでは、優先順位を変更してIncident Workflowを自動的にトリガーすると同時に、 Automation Actionsで自動診断を開始し、適切なレスポンダーが呼ばれ、Incident Workflowが起動したインシデント固有のSlackチャンネルに到達するまでにスクリプトが実行済みになるようにできます。
まとめ
Incident Response中、レスポンダーは核となる責任を負うインシデント解決に専念できます。Incident Workflowsは、標準化された反復可能な方法で、その他の重要ながらも退屈なタスクを自動化できるようになります。インシデント対応プロセスを標準化することで、チーム間で適切なアクションが取られるようになり、インシデント解決までの時間を短縮できます。Incident Workflowsは、BusinessおよびDigital Operationsプランに既に含まれているため、この素晴らしい新機能を追加費用なしでご利用いただけます。エンドツーエンドのインシデント対応を一カ所で実現できるのに、技術をバラバラにする必要はありません。ツール統合について問い続ける経営陣は、きっとこの機能を高く評価することでしょう。
これは、お客様が独自のユースケースに対応できるような拡張性を提供するためのPagerDutyの旅の第一歩にすぎません。インシデントワークフローの詳細については、KBの記事をご覧いただき、今すぐお試しください。
この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
インシデント＆アラート
急いで！全ての証拠をつかもう。インシデント後のフォレンジック用にアプリの状態をキャプチャーする
誰もがミステリースリラーを好みます。もしかすると、全員とは言えないかもしれませんが…、ハリウッドは間違いなくそうでしょう。ホームズものであれ、ポアロものであれ、観客は凶悪犯罪の犯人を追い詰めるページをめくるようなプロットを楽しむのです。私も含めて多くの人が、物語の最後に謎が「解ける」ミステリー・スリラーを好みます。後に続くような展開は想像力をかきたてますが（クリス・ノーラン監督の『インセプション』のラストを覚えていますか？）、探偵小説に関しては、私自身は「誰がやったのか」というハッキリとした答えを知る方が好きです。
探偵小説が完結するためには、犯罪の証拠が非常に明確で、真犯人が明らかになり、うまくいけば裁判にかけられるような詳細が提供されることが理想的です。
技術的な運用と重要なサービスのアップタイム維持の世界では、ハリウッドの探偵小説に似た明確な対立が生じます。重要なアプリケーションのパフォーマンス低下や、最悪の場合、完全な停止すると、エンジニアは問題をできるだけ早く修正できるように、事件の（明白な）原因を見つけようと急ぎます。チームは、自由に使えるツールを使って、オーバーロードした計算リソース、ハングしたクエリー、最大化したキューを追跡して切り分け、問題を修正するために迅速な行動を起こします。
しかし、これは探偵小説の始まりに過ぎません。この種の探偵ミステリーは、目撃者が犯人を、たまたま悪い時に悪い場所にいた人物だ、と認識するものです。しかし、証拠が増えるにつれ、やがて「真犯人」は遠くから壮大な計画を操っている悪の黒幕であることが明らかになります。しかし、「探偵」エンジニアにとっては残念なことですが、根本的な原因を解決したところで、その根本的な原因を示す証拠を「知らずに」消してしまう可能性が高く、サービスの再起動やポッドの再展開によって貴重なフォレンジックの証拠を消してしまうことになりかねません。
タイミング悪く雨に降られ、最も有力な手掛かりとなるはずの指紋が洗い流されたことに気付いた主任警部が、身の毛もよだつような思いをしているのは想像に難くありません。
最近では、開発者と運用エンジニアは、できるだけ早くサービスを復旧させながら、インシデントのコードレベルの根本原因を特定するのに役立つ重要な証拠を失わないようにするという、綱引きのような作業に取り組んでいます。
でも、モニタリング・ツールはそのためにあるのではないでしょうか？答えは、「時々当てはまる」です。問題によっては、高度な観測ツールを使って、設定やコードレベルのエラーを追跡できます。しかし開発者は、監視ツールで取得できない、より詳細なデータを必要とする場合があります。ヒープ、スレッド、TCPダンプ、リソースを大量に消費するデータベースクエリー、スタックトレースなどのデータは、「真犯人」を特定するために使用されますが、ほとんどの場合、サービスの復旧には必要ありません。そして、このようなデータの収集には時間がかかります。インシデント発生時には、サービスの可用性を回復することが何よりも優先されることは周知の通りです。
残念ながら、コンテナ化されたアプリケーションとコンテナオーケストレーションの採用・普及は、主に2つの理由から、この綱引きのような闘いを激化させるだけです。
マイクロサービスアーキテクチャーでは、Pod の再展開など、安全に可用性を回復するための方法がより迅速に提供されます。 このような環境では、開発者や運用エンジニアがコンテナ・イメージの表面積を最小限に抑えたいため、利用できるデバッグ・ユーティリティが少なくなります。
このような対立する勢力への対応には、「瞬時のスピード」で行動し、エビデンスを取得・保存し、その後すぐにサービスを再開できるソリューションが必要です。
このようなソリューションは、PagerDutyのOperations Cloudで提供されています。問題を検出すると即座にトリガーされるランブックを活用することで、デバッグレベルの証拠を取得し、S3などの永続的ストレージサービスに送信し、既知の修正を使ってサービスを復元できます。PagerDutyのユーザーは、オンプレミス環境とクラウド環境の両方に対応した統合済みの大規模なライブラリと、増え続けるランブックのテンプレートにより、MTTRと技術的負債チケット解決のためのバグ再現にかかる時間の両方を削減し、一見大胆に見えるこの目標を達成できます。PagerDutyの既存ユーザーは、次のリンクからRunbook Automationのトライアルをリクエストできます。
https://www.pagerduty.com/contact-us/runbook-automation/
新規ユーザーはここからPagerDuty Incident Responseを開始することができます。
また、Automated Diagnostics Solution Guideでは、これらのランブックの例をいくつか紹介していますので、ぜひご覧ください。
今回は複数回に渡るブログシリーズの1回目です。次回のブログでは、Kubernetes Ephemeral Containersを活用してKubernetesで動作するアプリケーションから証拠を取得するためのテンプレートジョブをご紹介します。
探偵の仲間たちよ、好奇心旺盛であれ。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
インシデント＆アラート
Knightscope社、ロボット稼働を維持するためにPagerDutyを活用
セキュリティーがより高度かつ利便性が高まるにつれ、企業は競争力の維持のために、より効率的にリソースを活用する方法を模索する必要があります。従業員のリソースが限られている、サービスの遅れに対する顧客の許容度が低いなど、企業の能力を制限する課題がある中、信頼性が高く、手ごろな価格のソリューションが必要とされています。この場合、従来のセキュリティー業界の概念を壊すことを意味します。組織は、自動化とテクノロジーを頼りにして、目標を達成しているのです。
Knightscope社がリードする
米国の先端セキュリティー技術企業であるKnightscope社は、過去9年間にわたり、Autonomous Security Robotsで業界をリードしてきました。同社は、ショッピングモールや駐車場、近隣、カジノなどの公共の場で人や車を監視するためのAutonomous Security Robotsを設計、製造、配備しています。ロボットとプロアクティブなモニタリングによって、セキュリティーリスクを抑止しレポートすることで、公共の安全を革新してきました。Knightscope社のミッションは、「アメリカを世界で最も安全な国にする」という野心的なものです。
Knightscope社が2015年に最初のロボットを出荷したとき、セキュリティーロボット業界はまだ黎明期でした。競合が少なく、業界の風景はまっさらな状態だったため、Knightscope社はパイオニアとなりました。同社は自律型セキュリティーロボットの分野に真っ先に飛び込み、今では100台以上の自律型セキュリティーロボットと契約しています。
多くの労力が必要
Knightscope社の全てのロボットは、基本的には同社のAPIソフトウェアのための器です。ロボットが収集したデータこそが、同社の真の商品なのです。システムを稼働するためには、複数の部門が連携し、可能な限り効率的に作業する必要があります。Senior Operations ManagerのJane Miller氏は、Knightscope社のNetwork Operations Center（NOC）を管理し、クライアントのロボットを24時間365日稼働するための保守を担当しています。「NOCは、私たちのロボットの技術的な問題を解決するための最初の防衛線なのです」と、Miller氏は述べています。
NOCは、ロボット内のコンピューターのハードディスクが満杯になるなど、営業時間外も含め、いつでも潜在的なソフトウェアやハードウェアの問題に対処する必要があります。また、Knightscope社のソフトウェアは自律型警備ロボットで動作しているため、ソフトウェアの不具合とは別に、ロボットの容器自体に問題が発生することもあります。例えば、荒らされたり、車にひかれたりすることもあります。どのような判断をすればいいのか分からない状況で、人間の介入が必要になることもあります。このような場合、オンコールで対応するチームメンバーは、適切なチームに引き継ぐ準備として、問題解決や診断完了をしておく必要があります。
Miller氏は、Knightscope社のソフトウェア・インターフェースによってクライアントがロボットと対話できる、Security Operations Center（KSOC）の技術的なクライアントサポートも担当しています。ここでは、クライアントがロボットから送られてくる映像を見たり、ロボットがSecurity Teamに電話をかけるようプログラムされた緊急電話システムを利用したりできます。また、脅威やアクセス制限区域に侵入を発見した場合、音声アナウンスを促すことも可能です。
さまざまなシステムや部門が存在することによって、問題解決は複雑化する可能性があります。同社はテクノロジーカンパニーなので、全システムとチーム連携のために信頼と実績のある方法が必要だと理解しているのです。
PagerDutyはNightscope社のソリューションです
Knightscope社は2015年からPagerDutyを利用して、リアルタイムな運用管理を行っています。PagerDutyのAPIを独自のロボットソフトウェアに接続し、ロボットのハードウェア、ソフトウェア、自律的な意思決定を監視しているのです。ソフトウェアの一部が予期せずクラッシュした場合や、ロボットが物理的なヘルプを必要とする場合、ロボットとの接続が失われた場合などは、チームはPagerDutyを介してプロアクティブな通知を受け取ります。また、PagerDutyはロボットの健康状態に関するデータも提供し、新しいソフトウェアのリリースやバグフィックスが期待通りに動作しているかどうかを確認します。
「また、ハードウェアやソフトウェアに問題がある場合は、セキュリティーの観点からロボットが必要なことを全て行っているかどうかを確認します。何か問題があれば、PagerDutyが知らせてくれて、私たちが対処します。新たな問題が発生した場合は、調査し、研究開発チームにエスカレーションします」とMiller氏は言います。
PagerDuty Incident Responseはここでその価値を発揮します。ロボットが正常に動作していない場合、「PagerDutyを使って、ロボットがクライアントをサポートするために必要なことを全て行っているかどうかを確認しています」とMiller氏は語っていました。実際、Knightscope社で働き始めた新入社員にとって、何か問題が発生したときに、大量のデータをかき集める代わりにPagerDutyが教えてくれるというのは大きな安心材料となっています。
PagerDutyは、Knightscope社が新しい機能とプラットフォームを開発し続ける中で、適応性と信頼性があることを証明してきました。テクノロジー企業、特に業界のディスラプターが驚異的な進歩の最前線にいるとき、そのシステムは軽快で素早く変化できることを保証する必要があります。「私たちはまだスタートアップ文化にいるので、常に物事に変化を与え続けています。チームにとって、PagerDutyを新しいテクノロジーに統合し、適応しながら成長するのは本当に簡単なことでした。このおかげで、私たちはいつでもクライアントと一緒に仕事ができる状態にあります。」とMiller氏は言います。
Knightscope社は以下のような部分から、PagerDutyの利便性を感じています。
使いやすさ** ー PagerDutyのカスタムAPIを使って簡単に自社のソフトウェアと統合できる 適応性と俊敏性** ー 新しい機能、プラットフォーム、テクノロジーを簡単に実装できる 柔軟性** ー ローテーションスケジュールや通知を簡単に作成、変更できる 費用対効果** ー 24時間365日利用可能なオンサイトロボットにより、人の労働力を削減できる
未来が変化している
Knightscope社の未来の可能性は無限大です。テクノロジーの世界においては、変化は確実なものなのです。優先順位、危機、予算、信頼できる従業員へのアクセスなどが常に変化する中、Knightscope社のような企業は、効果的で一貫したソリューションを生み出す方法を常に模索しています。同社はセキュリティーの新時代を切り開き、その目標を達成するためにPagerDutyを頼りにしているのです。
PagerDutyがどのよう組織に役立つかを知るには、アカウントマネージャーに連絡するか、今すぐ14日間の無料トライアルをお試しください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
PagerDuty for Customer ServiceでServiceNowの機能を拡張する
ここ数年、デジタル社会はますます発展しています。私たちは皆、ストリーミングやショッピング、あるいは単にサーフィンをするためにオンラインを利用しています。この新しい世界では、カスタマーエクスペリエンスがかつてないほど重要になっています。顧客はできるだけシームレスに動作することを望んでおり、問題が発生すると、顧客の信頼とビジネスが失われます。
多くの企業にとって重要な優先事項は、システムをできるだけスムーズに稼働させ、お客様の満足とロイヤルティーを維持することです。しかし、デジタルの世界では時折、不具合が生じることがあり、物事を円滑に進めるために、カスタマーサービスチームが対応の中心になることが多いのは周知の通りです。
PagerDuty for Customer Serviceは、ダウンタイム解決の迅速化、顧客への積極的なコミュニケーション、比類のないレベルのカスタマーサービスの提供を可能にするプロアクティブなチームにとって不可欠であることが証明されています。 最近私たちはPagerDuty for Customer Service in ServiceNow CSMの発売を発表し、CSOpsの機能を拡張しました。プラットフォームを切り替えることなく、リアルタイムのデジタルオペレーションをServiceNowに反映できる、既に緊密な統合をベースに、カスタマーサービスのエージェントとエンジニアリングチーム間のより緊密なつながりを構築しています。
PagerDutyのServiceNow向け新アプリは、ServiceNow CRMに統合された体験を提供し、カスタマーサービスチームが事例を最初から最後まで管理するために必要な可視性を提供します。PagerDutyの統合されたリアルタイムのカスタマーサービス運用により、各チームはServiceNow CSMからアクティブなケースのステータスを直接確認できます。チームはインシデントを作成し、開発チームやITOpsチームが作成したメモやステータスの更新を確認し、ServiceNowからPagerDutyでエンドカスタマーに正確かつ効率的に返答できるようになりました。これにより、カスタマーサービスと技術チームの間のギャップを埋め、適切な人材を適切なタイミングで関与させ、顧客の問題に先手を打つことができます。
もっと詳しく知りたいですか？統合ガイドをご覧ください。
この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
新着情報：Incident Response, PagerDuty® Process Automation Software & PagerDuty® Runbook Automation, Mobile App Experienceをアップデート
PagerDuty Operations Cloudの新しいアップデートと機能拡張を発表することができ、とても嬉しく思います。製品チームによる最近の開発およびアプリのアップデートには、インシデントレスポンス、PagerDuty® Process Automation、PagerDuty Mobile App、インテグレーション、Community & Advocacy Eventsのアップデートが含まれています。私たちは、お客様がクラウド運用を最適化し、他のチームにエスカレーションされる問題を減らすために、さらなる自動化を支援し続けています。今すぐチェックして次のことをご理解ください。
Status Pagesの活用により、お客様にリアルタイムのステータスを通知 分析レポートとステータスアップデートの通知テンプレートを更新し、より迅速で柔軟なIncident Responseを実現 PagerDuty® Process AutomationとRundeck Communityの最新版4.9.0 Release
今後のイベント、最近のポッドキャストやTwitch Streamの番組、コミュニティーチームや製品チームのメンバーが新製品やソフトウェア業界のリーディングプラクティスを紹介します。
Incident Response関係
Status Update Notification Templateが一般公開に
Status Update Notification Templateが一般公開されました。組織ごとのテンプレートを利用することで、影響度やサービスエリアなどに応じてコミュニケーションをカスタマイズし、標準化できるようになりました。この機能はAPIでも利用できるようになるため、チームはあらゆる状況下でニーズに合わせてステータスアップデートの通知テンプレートをカスタマイズして活用できます。このデモで、実際にテンプレートを使う様子をご覧いただけます。
詳しくはナレッジベースをご覧ください。
Incident Workflowsを一般公開
適切な対応を行うために必要な手作業を減らすことで、インシデント対応プロセスをより柔軟に制御できます。ノーコード／ローコードビルダーを使い、あらゆるユースケースに対応する独自のIncident Workflowsを作成し、if-this-thatロジックを使い組織的なレスポンスをトリガーします。Incident Workflowsは、BusinessとDigital Operationsプランでのみ利用可能で、Response Playsを完全に置き換えるものです。Response PlaysをIncident Workflowsにアップグレードしてください。デモはこちらでご覧になれます。
詳しくはナレッジベースの記事をご覧ください。ウェブ、モバイルともに近日中に一般公開予定です。
インシデントEAにカスタムフィールドを追加
カスタムフィールドにより、ユーザーはインシデントの重要な情報を柔軟に表示させることができます。各チームは、既存の複数の記録システムからデータを集約して、インシデント対応の360度ビューにすることができ、対応者が重要なデータを検索する時間を短縮し、最終的にMTTRを短縮できます。インシデントのカスタムフィールドは、ウェブとAPIで利用できるようになる予定です。詳細はナレッジベースの記事でご確認いただき、アーリーアクセスにご登録ください。
Incident Activity Report PagerDuty AnalyticsのIncident Activity Reportの新版は、現在、アーリーアクセス可能です。このレポートには、チームがインシデント対応を次のレベルに引き上げるためのさまざまな機能強化が施されています。インタラクティブな視覚化、ドリルダウン機能、レスポンダーの作業に関する詳細なデータにより、このレポートは貴重な洞察を提供し、チームがインシデント解決時間を向上させるのに役立ちます。 このレポートでは、インシデントに関与したレスポンダーの数と、MTTAからMTTRまでの作業時間を知ることができます。アーリーアクセスプログラムに登録し、ナレッジベースの記事で詳細をご覧ください。
カスタマーサービスOps関連
Status Pages PagerDutyのStatus Pagesが利用可能になりました。お客様は、PagerDutyを単一の真実のソースとして、システムのリアルタイムのステータスについて、お客様に積極的に情報を提供することができます。この新製品により、お客様は公開ページを作成し、自社ブランドの一貫したルック＆フィールのためにカスタマイズすることができます。さらに、Human-in-the-Loopサポートを活用することで、必要に応じて人間の承認を得た上で、自動的にリアルタイムのアップデートを投稿できるようになります。詳細は、ブログまたはナレッジベースでご確認ください。
(図：Status Pagesのプレビューとシステムステータス）
(図：Status Pagesをカスタマイズ)
PagerDuty for Customer service In ServiceNow CSM PagerDuty for Customer service In ServiceNow CSMが利用可能になりました。カスタマーサービスチームは、ServiceNowからPagerDutyのアクティブなインシデントのステータスを確認できるようになりました。この新しいアプリケーションにより、各エージェントはインシデントを作成し、開発チームやITOpsチームが作成したメモやステータスの更新を確認し、ServiceNowからPagerDutyでエンドカスタマーに正確かつ効率的に応答することができます。これにより、カスタマーサービスと技術チームの間のギャップを埋め、適切な人材をリアルタイムに関与させ、顧客の問題に先手を打つことができます。ServiceNowアプリストアでご確認ください。
PagerDuty® Process Automation Software、PagerDuty® Runbook Automation、Rundeck関連
PagerDuty® Process Automation, PagerDuty Runbook Automation, and & Rundeck Community Version 4.9.0
PagerDuty® Process Automation、PagerDuty Runbook Automation、Rundeck Communityの新機能と機能拡張をご確認ください。このリリースでは、Plugin Groupsのベータ版を導入し、プラグインの設定を簡素化することで、より多くの自動化をより速く構築できるようになりました。プラグインスイートごとに定義されたプロパティーを使って、プロジェクトやシステムレベルでプラグインのプロパティーを設定するためのグラフィカルなインターフェイスが用意されました。詳細については、リリースノートをご覧ください。
詳しくはこちら
このリリースのTwitchストリームレビューを見る 2023年1月11日にリリースされたバージョン4.9.0に関するリリースノートを読む。
統一されたログイン体験
お客様がより簡単にPagerDutyにログインできるように、プロセスを合理化してログイン手順が変更されました。- PagerDutyへのログインに関する質問に答えるためのナレッジベースの記事も作成しました（こちら）。 PagerDutyのサブドメインで新しいログインエクスペリエンスを有効にするには - アーリーアクセスプログラムにサインアップしてください。
モバイル向けのナビゲーションを最新に
PagerDuty Mobileの新機能「Modernized Navigation」は、ナビゲーションをより速く、より効率的にするための機能です。この機能は、2023年2月6日からアーリーアクセスでiOS向けに提供されます。これを使えば、非表示のハンバーガーメニューに戻ったり、画面を起動し直したりすることなく、画面間を簡単に移動できるようになります。つまり、ある画面から別の画面へ、余分なステップを踏まずに素早く移動できるようになるのです。また、複数の画面を同時に操作している間でも、ユーザーの履歴は保存されます。デモ動画をご覧になるか、アーリーアクセス・プログラムに登録して、さらに詳しい情報を入手してください。
IBM、Asana、Zohoとの新たな統合を実現
PagerDutyは、DevOps、IT、Observability、Security、Business Operations、Customer Serviceなどのテクノロジーパートナーとの700以上の統合を実現しています。今月は、ツールスタックの可能性を最大限に引き出す、以下のような新しい統合を発表することができました。
IBM Instanaは、PagerDutyのための新しいAction Framework統合の技術プレビューを開始しました。InstanaのEnterprise Observability Platformは、フルアプリケーションスタックのリアルタイムな発見、マッピング、監視を行います。この新しい統合は、Instanaから直接PagerDuty Process Automationを呼び出して、問題を迅速に解決します。 新しいAsanaとPagerDutyのインテグレーションは、開発部門やIT部門を超えた組織全体の可視性と俊敏性を向上させるのに役立ちます。Asanaのタスクに注意が必要な場合、チームは手動で PagerDuty のインシデントを作成することから、Asanaのルールを介して、サービスを発行するために必要なコンテキストで自動的にキックオフすることが可能です。PagerDutyとAsanaを接続することで、各チームは手作業を減らし、インシデントの応答時間を短縮しながら、エスカレーション要求に対してタイムリーな応答やアラートを提供できます。 Zohoの新しいPagerDuty用ManageEngine OpManagerインテグレーションは、ルータ、スイッチ、ストレージデバイス、VM、ファイアウォールなど、あらゆる種類のネットワークデバイスのインシデントを迅速に解決するのに役立ちます。
製品廃止のお知らせ
今後予定されている製品廃止について、あなたのチームにお知らせください。
V1 Webhooks EOL
v1 WebhooksのEnd of Lifeの日付は、2022年10月31日です。これはつまり
新しい v1 Webhookを作ったり、v1 Webhook拡張機能への既存の接続を使ったりすることができなくなります。 v1 Webhooksを使っているアプリやインテグレーションは動作しなくなります。
詳しくはこちら
v3 Webhooksへの移行の詳細と手順については、こちらの移行ガイドを参照してください。 その他のご質問は、[email protected] までご連絡ください。
重要な日程
2022年10月31日（v1 Webhooks EOL)
v2 Zendesk Integration EOL
PagerDutyのv2 App for Zendeskは2023年3月にライフサイクル終了となります。今すぐ移行して、ZendeskのサポートチケットイベントをPagerDutyに送信してください。
v3への移行の利点は、上記のIntegrationsのセクションでご覧いただけます。ご質問やご不明な点がございましたら、[email protected] までご連絡ください。
ウェビナー＆イベント
以下のウェビナーやイベントに参加し、PagerDutyの最近の製品アップデートと、それがどのように顧客に利益をもたらすかについて、より詳しく学びましょう。これらはたくさんある中のほんの一部です。
PagerDutyとAWSによるセキュリティーとコンプライアンスの自動化
金融サービス、ヘルスケア企業、そして今日のあらゆるビジネスは、厳しい規制要件に準拠する必要があり、IT運用チームや開発者に多くの手作業によるオーバーヘッドを発生させます。アマゾンウェブサービス（AWS）がコンプライアンスに準拠したワークロードの構築にどのように役立つか、またPagerDutyが自動化を通じてIT運用のセキュリティーとコンプライアンスをどのように最適化できるかをお聞きください。品質向上とコスト削減を実現しながら、コンプライアンス・プロセスを合理化する方法をご紹介します。
今すぐ見る
Event Intelligence 101 with PagerDuty University
Event Intelligence機能が、どのようにシステムノイズの低減、迅速なトラブルシューティング、手作業の排除に役立つか、Hannah Lodiseが詳しく説明します。
今すぐ登録
Getting Started Workshop: Rundeck By PagerDuty
デベロッパーアドボケイトの Mandi Wallsがランブックオートメーションの基礎と一般的な使用例について説明します。この 30 分のセッションで彼女は、Rundeck オープンソースの設定と使用方法、そしてコミュニティーウェルカムプロジェクトをあなたの環境で動かすためのステップを示すサンプルウェルカムプロジェクトに一緒に取り組みます。
今すぐ見る
PagerDuty ステータスページ。あなたとあなたの顧客が必要とする唯一の真実の情報源
PagerDuty Status Pagesは現在公開中です。このウェビナーでは、PagerDutyとお客様がどのようにStatus Pagesを使用しているか、そしてなぜStatus Pagesがチームのツールの統合、効率化の推進、サイロの解消に不可欠であり、カスタマーサービスとエンジニアリングチームが連携してお客様に情報を提供し続けているかを、直接ご説明します。
今すぐ見る
Terraform四半期ラウンドテーブル
日付と時間 2023年2月21日 10:00am PT (米国・カナダ)
PagerDutyのMandi WallsとJosé Antonio Reyesが、TerraformとPagerDutyでInfrastructure as Codeを実装する際のベストプラクティス、学習、考慮すべき点について、業界の同業者の意見を聞き、自身の経験を共有するために参加します。
今すぐご予約を
PagerDuty Community Twitch Stream
PagerDuty Twitch StreamとPagerDuty Community Twitch StreamのTwitchチャンネルで、デベロッパーアドボケイトがリードする最新のストリームに参加してください。過去のストリームはYouTube Twitch Streams Channelでご覧いただけます。
登録すると、ライブのお知らせや過去の放送を見ることができます。 私たちの放送を見逃しました？最近のTwitchストリーム（PagerDuty GarageとTerraform Time）またはYouTubeビデオをご覧ください。 笑顔のあるサービス。PagerDutyのMandi WallsとDavis Godboutによるサービスグラフとサービススタンダード（2022年9月30日開催） PagerDuty Process Automation and Rundeck Open Source v4.9.0 Release Notes with Mandi Walls, Jake Cohen, and Forrest Evans (January 17 ,2023).
Twitchのストリームのスケジュールを見て、2月に毎週開催されるストリームに参加してください。
もし、あなたのチームがこれらの機能拡張を利用できるのであれば、ぜひアカウントマネージャーに連絡して、14日間の無料トライアルに申し込んでください。
この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
Status Update Notifications Templatesで「executive swoop and poop」にさよなら
インシデントは予測不可能ですが、ステークホルダーとの最新情報の共有方法は予測不可能である必要はありません。Status Update Notifications Templatesは、大規模なインシデント発生時の社内関係者とのコミュニケーションを効率化するために役立ちます。このたび、この機能に新たな機能が追加されました。この機能により、チームはコミュニケーションをカスタマイズできるだけでなく、影響やサービスエリアなどの条件を表す動的な変数挿入を使用して、再利用可能なテンプレートを作成し、標準化することができます。
Status Update Notificationsとは何ですか？
あなたは今、優先順位の高いインシデントの真っ只中にいます。問題を収束させようと努力しているのに、12人（または２人）のステークホルダーから最新情報を求められて集中できない。複数の社内コミュニケーションチャネルに自分の回答をコピー＆ペーストしていても、ダイレクトメッセージが飛び込んでくるのは止まらない。このような状況に心当たりはありませんか？PagerDutyでは、これを「executive swoop and poop」と呼んでいます。基本的に、レスポンダーは更新要求が殺到し、本来の仕事であるインシデントの解決に手が回らなくなってしまいます。
インシデント発生時には、ステークホルダーに常に情報を提供することが重要です。そうすることで、インシデントに一丸となって対応し、解決までの時間を短縮し、顧客の信頼を維持することができます。しかし、ステークホルダーは、コミュニケーションに一定の形式と、彼らにとって重要な文脈を含むことを期待します。このようなコミュニケーションの書式設定と作成は、アドホックに行われる場合、対応者の全神経を集中させる必要があるかもしれません。Status Update Notificationsにより、チームはコミュニケーションの期待値を標準化し、アップデートの共有にかかる手間を軽減することができます。
この機能にはリッチテキストエディタが含まれており、会社のロゴを追加するなど、会社のコミュニケーション標準に合わせてテキストをフォーマットすることができます。また、ドラッグアンドドロップ機能により、インシデントの詳細や必要な情報を簡単に入力することができます。
テンプレートは、私のチームにどう役立つのでしょうか？
事故発生時、対応者は自分が担当するシステムやサービスについて、多くのことを記憶しておかなければなりません。そのため、集中力と批判的思考が必要とされます。ステータスアップデートの通知は、関係者とコミュニケーションをとるための迅速な方法であり、対応者がアップデートを共有するために費やす時間とエネルギーを軽減します。しかし、同じようなインシデントが発生すると、同じ通知を頻繁に送信する必要がある場合もあります。あるいは、P3とP0のコミュニケーションに異なる情報を持たせたいのに、毎回ゼロから通知を作りたくない場合もあります。
これらを全部プレーブックに書いて、wikiに保存することも可能です。しかし、そういったWikiは見つけにくいし、更新もほとんどされません。レスポンダーが必要とするときに、必要な場所に用意されているわけではありません。そこで、私たちはテンプレートを開発しました。これにより、チームは影響度や事業分野などに応じて、再利用可能なコミュニケーションテンプレートをカスタマイズし、標準化できるようになりました。この機能はAPIでも利用できるため、チームはどんな状況でも、ニーズに合わせてステータスアップデートの通知テンプレートをカスタマイズして活用できます。
テンプレートを使えば、インシデントコミュニケーションも簡単です。
関係者がインシデントにサブスクライブしていることを確認します。 ステータス更新]をクリックし、テンプレートを選択します。 テンプレートを編集し（必要な場合）、プレビューします。 ステータス更新の通知を送信します。
今日から始めるにはどうしたらいいですか？
Status Update Notification Templateが、ビジネスとデジタルオペレーション部門のお客様向けに一般提供されるようになりました。Status Update Notification Templateを使うことで、チームはより良いコミュニケーションができ、"swoop and poops "を減らせます。また、再利用可能なテンプレート形式なので、どんなコミュニケーションもすぐに用意できます。
もっと詳しく知りたい方は、こちらのナレッジベース記事をお読みいただくか、デモをご覧ください。
ステータスアップデートの通知テンプレートを実際に見てみたい方は、14日間無料でPagerDutyをお試しください。
この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
お客様とのコミュニケーション向上コスト削減を実現するPagerDuty Status Pagesの導入
2023年、顧客維持のための戦いは、全ての人が予測する「ビジネスが不況を生き残れるかどうか」を決定づける、最大の要因の１つになるでしょう。Salesforceが発表した「2022 State of Service Report」によると、顧客維持の中心にあるのは優れたサービスであることが分かりました。48%の顧客は、何か問題が発生した場合、よりよいカスタマーサービスを求めてブランドを切り替えると回答しています。オープンなコミュニケーションは、顧客がカスタマーサービスの質を評価する際の重要な要素であると捉えているのです。顧客は、最も回復力のあるデジタルシステムでさえ、時折問題が発生する可能性があることを理解しています。しかし、そんな問題によって取り引きや企業との交流が妨げられ、全てが不透明なまま放置されることは許さないでしょう。
お客様の信頼とロイヤリティーを高めるには、問題の進行状況について積極的かつ詳細なコミュニケーションを確立することが重要です。しかし多くの企業では、顧客との迅速かつ積極的なコミュニケーションに必要なプロセスが手作業や引き継ぎ、複雑さによって、必要以上に多くなっています。
PagerDuty Status Pagesは、このような複雑な状況を打破するために開発されました。PagerDuty Status Pagesは、組織のオペレーションを視覚的にリアルタイムで把握できるため、ブランドはあらゆる状況下で顧客に積極的に情報を提供し、支援できます。インシデントが発生した場合、PagerDutyユーザーは、PagerDuty Operations Cloudから直接、顧客とリアルタイムのオペレーションアップデートを安全に通信し、好みのオーディエンス別通信サービスを活用できるようになります。この新しいアドオン機能は、PagerDutyのカスタマーサービスとインシデント対応ソリューションを、当社のパートナーや顧客にも拡大するものです。
メリット
私たちは、サービス担当者の生活をより快適にし、お客様の時間とコストの節約を目指しています。現在、積極的なコミュニケーションにより、チームはお客様が気付く前に、問題があることをお知らせできています。これにより、障害発生時にカスタマーサービス部門に送られるチケットの数を減らし、各チケットの人件費削減につながります。また、最新情報を入手するための信頼できる唯一の情報源を持つことで、特に時間が最重要となる場合に、エンジニアリングチームに送られる問題についての、他リクエストも回避できます。DevOpsとCSOpsの両チームは、認識が一致するため、時間とリソースを節約できるのです。
特に大規模な障害やイベントの際に、オープンな透明性を確保できるようになったことも、お客様にとって大きな価値となります。PagerDuty Status Pagesを利用することで、顧客との信頼関係を築き、サービスに問題が発生したときにすぐに知り、顧客が最も気になるステータスについて常に情報を得られます。これは全て同じ場所にある、信頼できる唯一の情報源なのです。
この記事は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で業務の効率をもっと上げる
あるツールを使いこなせたと、自信を持って言える人はどれくらいいるでしょうか。多くの人と同じく、製品の機能のほんの一部しか使っていないのではないでしょうか。Microsoft WordやExcelのような高機能なソフトウェアでは、ほとんどのユーザーが知っている機能は半分以下で、日常的に使っている機能はさらに少ないと考えて間違いないでしょう。そして、長く使っているソフトウェアほど、この「機能があるのに使ってない」という罠に陥りやすいのです。
それに気づいたのは、１年半ほど前に、チームに加わった同僚が、私たちの教育用ビデオにクローズドキャプションを生成するために、より効率的な方法を見つけたよと教えてくれたのがきっかけでした。私はそれがAdobe Creative Suiteのツールかどうかを尋ねました。
「いや、実はYouTubeなんだよ！」と同僚は答えました。
「え？すごい！」と 私はいいました。同時に「どうして知らなかったんだろう？」と、ショックを受けました。この６カ月間、私たちはクローズドキャプション機能のために別のツールにお金を払っていましたが、その間ずっと、GoogleアカウントでYouTubeの無料キャプション機能を使うことができたのです。
最近、Slackのリマインダー機能を知って、またまた驚きました。これまでは翌日のToDoリストを作成し、Googleカレンダーにチームメイトのフォローアップ、主治医への電話、ガス代の支払いなどのリマインダーを登録していました。彼は、私がカレンダーに次々と予定を追加していくのを面白がって見ていました。
「何をしてるんだい？」と彼は聞きました。
「明日やらなければならないことのリマインダーを設定している」と私は答え、神聖な日課を邪魔されたことに軽くイラつきました。
すると彼は「Slackのリマインダー機能を使ったら？」と言いました。「そうすれば、カレンダーの半分をリマインダーで埋め尽くされることもなく、みんながミーティング予約しづらくなるなんてこともないだろうから」と。
「そんなことができるなんて知らなかった！」YouTubeの件もそうですが、この機能を今まで気づかなかったことが信じられませんでした。
翌日のSlackリマインダーのスケジューリングを始めながら、「そんなことができるなんて知らなかった！」というお客様の言葉をよく耳にするなあと思いました。考えてみれば、当たり前でもあるのですが。私たちはよく、特定の使用目的のためにツールを購入します。そして問題解決を急ぐために、いわば目隠しをして、目的達成に役立つ機能だけに目を向けます。そして「問題は解決した！」と宣言するのです。そのソフトの機能の、10分の１しか理解していないことに気がつかずに。何年経っても同じボタンをクリックし、同じスクリプトを実行し、UXを向上させる新機能の数々にも気がつかないままでいます。
最も進みやすい道を選ぶのは人間の本性です。しかし、多くのハイテク企業が少しのコストと労力で多くのことをこなすことを求められている今、おそらく効率化を考え始めるには、既に投資したものから始めるのがよいのではないでしょうか。
このことに光を当てる事業領域の一つが、Customer Educationです。PagerDutyでは、カスタマートレーニングとイネーブルメントをPagerDuty Universityで行っています。そのコースへの評価でよく目にするコメントは、「PagerDutyが（数カ月、あるいは数年前から存在する機能で）こんなことができるなんて知らなかった！」というものです。PagerDutyをオンコール管理やアラートのために使い始め、その基本的な機能より先に踏み出すことがなかったお客様もいらっしゃるかもしれません。彼らは、PagerDutyを単一のユースケースで使うことに慣れきってしまい、その製品ポートフォリオがデジタル業務全体のユースケースに対応する複数のソリューションを実際に包含していることに気付いていないのです。
現在のマクロ経済環境の圧力に直面している組織にとって、PagerDutyのエンドツーエンドのデジタルオペレーション機能は、ツールの乱用を減らし、コンテキストの切り替えを減らすことで生産性を向上させます。PagerDuty Universityは、インシデント前の作成（イベントの充実とルーティング）からインシデント後の動員（対応の自動化）、ビジネス全体のオーケストレーション（ステークホルダーとのコミュニケーションの自動化）、さらにその先まで、このエンドツーエンド体験の認識を促すことでお客様を支援します。お客様は、単一の問題に対処するポイントソリューションに投資するのではなく、必要なときに必要なソリューションを活用し、PagerDutyでデジタルオペレーションの進化を続けるに当たって、追加の機能や製品を導入するのです。
Customer Educationに携わる当社の人間は、お客様が価値に気づくまでの時間（Time to Value）を短縮するだけでなく、オンボーディング後もその後も、投資の見返りを確実に得られるようにすることが、自分たちの仕事だと理解しています。これはPagerDuty Universityにとって、お客様がEvent IntelligenceやIncident Workflows（早期アクセスでどうぞ！）などの PagerDutyの高度な機能と、Customer Service OperationsやProcess Automationなどの他製品やユースケースを適切に使えるようにすることを意味します。ツールの統合、コスト削減、労力の自動化、カスタマーエクスペリエンスの向上などは、お客様がトレーニング後に得られる最大のROIの一部です。
当社のインストラクター主導のトレーニングコースは、お客様の目標達成を中心に考えられています。PagerDutyの全ての機能をトレーニングするのではなく、まずお客様が解決しようとしているビジネス上の課題を理解し、その目標への到達のために、効率的にガイドするトレーニングを構築しています。SaaSではよくTime to Valueという言葉が使われますが、私たちはテクニカルトレーニングチームを“Guides to Value”と考えています。
PagerDuty Universityの無料オンデマンドトレーニングコースはインストラクター主導のトレーニングを補完するもので、各製品の機能を実際のシナリオに基づいて掘り下げ、これらの機能が使用される大きな背景や解決すべき問題をユーザーが常に理解できるようにします。自習用のeラーニングモジュールは、無料アカウントを試用しているお客様、新機能を確認したいお客様、または単にオンデマンドトレーニングのセルフサービスを好むお客様に適しています。
Education Servicesで働く私たちが学びを愛している事実は、驚くことではありません。その学習意欲を生かして、全ての核心となるカスタマーサクセスを推進していきます。導入の推進、オンボーディングの改善、業界のベストプラクティスの伝授など、お客様の「PagerDutyでこんなことができるなんて知らなかった！」という声を聞くことがないよう、努めています。
この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
Toil：エンジニアの悩みは尽きない
このブログは、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 コミュニティへの還元。住居のない家族に衛生用品を提供し、尊厳のある生活を支援
このブログはTechnical Trainer for PDUのCamden Louieと、Technology EcosystemのMay Tongによって共著されました。
このボランティアの機会は、Phylicia Jones (PJ)を偲んで捧げられます。あなたが恋しいです。PagerDutyでのボランティア活動と貢献に、感謝の意を申し上げます。
10月、20人以上のDutonainsたちがサンフランシスコに集まり、Compass Family Servicesのために50個以上の衛生キットを組み立てました。サンフランシスコの家庭は、COVID-19やここ数年の地域の経済的変化によって特に影響を受けており、「危険にさらされている人々が安定した住居に住み、精神的にも肉体的にも健康で、経済的に自立できるように」支援するCompass Family Servicesなどの組織が必要となっています。ホームレスの家族に衛生キットを提供することで、その人が自身の尊厳を感じられるようになるでしょう。2022年には150個以上のキットがBay AreaのDutonainsから寄付されました。これは会社の価値観である「#Ack&Own」と「#RunTogether」を実践するチームメンバーによる、ボランティアの寄付によって支えられています。
会社の賞を活用し資金を寄付することで、Dutoniansが結集し、2021年、サンフランシスコで行われるオフィス復帰後初の対面式ボランティアのために、500ドル以上を集めました。今期はキャンペーンの声がけと購入でシャンプー、コンディショナー、ボディソープ、石鹸、靴下、マスク、洗面器、歯ブラシ、歯磨き粉を集めることに成功し、キットを作ったのです。 私たちは、このボランティアの機会を23年度の残りの期間、サンフランシスコのオフィスで継続することを目標としています。これにより、将来的には他の地域住民のためにキットを寄付することが可能になります。
これまでのキャンペーンの統計
今期は 50 個以上の衛生キットを組み立てました 今期は450以上のアイテムがキットの組み立てに使用されました。2022年には全体で1,350のアイテムが使用され、合計150個のキットが作られる予定です 寄付金：500ドル以上 ボランティア参加者：20名以上 ボランティア時間 40時間以上
このボランティアの機会に金銭的な寄付をしてくださったSFボランティアと、Dutonianの皆さんに特別な感謝を捧げます。そしてKandace Bonaとそのスタッフが企画したご馳走付きパーティーに感謝します。
この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
信頼と全面的な支援におけるパートナーシップの中心。Code the Dreamからの物語
PagerDutyでは、信頼を運用するビジネスを行っています。私たちのテクノロジープラットフォームは、お客様のデジタルオペレーションの中枢神経系であり、PagerDutyの社会貢献部門であるPagerDuty.orgでは、この信頼に基づくアプローチを全てのステークホルダーに適用しています。私たちは、社会的インパクトを与えるパートナーのニーズを中心に、慈善活動、製品、ボランティア、技術的なプロボノ支援、声など、全社的な資産を動員しています。この"Giving Tuesday"では、私たちのパートナーの一社であるCode the Dreamにスポットライトを当てます。Code the Dreamは、米国のテクノロジー産業が多様な人口を反映し、多様な才能がわれわれの最大の課題を解決するために活用されるような世界を目指しています。同社の革新的なモデルは、多様で低所得な背景を持つ人々を採用し、モバイルおよびウェブアプリケーションを構築するためのトレーニングを提供し、技術者としてのキャリアを開始するための有給見習い期間を提供することです。Code the Dreamのプログラムが社会経済的に与える影響は多岐にわたります。生徒たちが作るアプリケーションが現実世界の問題を解決するだけでなく、生徒たち（およびその家族やコミュニティー）は経済的な成果を上げられるのです。
Code the Dreamとは、2021年のワクチンエクイティーのための資金調達の一環で初めてつながりました。Code the DreamはPagerDuty.orgから、米国内の移民・季節農民を支援するアウトリーチ従事者に役立つモバイル、およびデスクトップ用アプリ、"Vamos Outreach"の拡張のための無制限助成金を受け取りました。移民・季節労働者は、米国の経済と食糧生産に不可欠な存在で、米国の農業従事者の73％を占めていると推定されています。しかし、彼らはCOVID-19の発生リスクが高く、ワクチンや文化的に共鳴するワクチンに関する情報を入手することができません。この1年間で、コード・ザ・ドリームは機能を更新し、バモス・アプリを全米6州に拡大しました。農作業支援者が農作業者とワクチンに関する重要な情報を共有し、コード・ザ・ドリーム学生の有給見習いを増やせるようにしました。
小切手の先にあるもの、助成金の先にあるもの
私たちは、信頼に基づいた実践と全面的なアプローチをサポートすることで、パートナーへのパワーシフトを図ります。これは、パートナーのニーズをサポートするクリエイティブな方法を見つけるために、頻繁、かつ継続的に会話をすることを意味します。Code the Dreamにとって、これはCode the Dreamのニーズを理解するためのオープンな対話を開始することであり、彼らのチームとPagerDutyの社員をつないで、生徒のメンターとしてボランティアに従事してもらうことを意味しました。また、Code the Dreamのワクチンの公平な供給への活動への支援を通じて、毎年開催される会社のキックオフや製品開発会議などのPagerDutyの主要イベントに、Code the Dreamのリーダーに参加してもらいました。PagerDutyの社員は、短いキャリアアドバイスビデオを作成し、就職面接の成功、完璧な履歴書の作成、技術的な問題解決のスキルと自信の構築、昇給の要求、企業技術部門での仕事の進め方など、Code the Dreamの学生たちの質問に答えています。共同経営者のDaisy Magnus-Aryiteyは、私たちのパートナーシップについて次のように述べています。「PagerDutyのサポートにより、私たちの実習生はVamosアプリを更新することができました。このアプリは、多くの組織が移民である農民たちにCOVID-19ワクチンへのアクセスを提供するために使用されているものです。PagerDutyのボランティアからの指導やアドバイスで、私たちの生徒たちはモチベーションを上げることができました。このような多面的な支援により、技術革新がわれわれ全員から生まれ、われわれ全員に利益をもたらす世界というCode the Dreamのビジョンに近づいているのです」
過去1年間、PagerDutyとCode the Dreamのパートナーシップは、助成金の提供からプロボノボランティア活動、ブランドの向上へと深化し、当初のワクチンの公平性に焦点を当てたものから、Code the Dreamの目標をサポートするための幅広いパートナーシップへと発展してきました。助成金の支給期間は終了しましたが、PagerDutyの社員は引き続きCode the Dream SKILL-ITプログラムのメンターとしてボランティアに参加し、キャリアの軸となる人材や既存のコーディング、ウェブ、アプリ開発のスキルを高めようとする人材を支援しています。このプログラムの一環として、PagerDutyの社員は、企業におけるインポスター（過小評価）症候群の克服、新しい職場で自分の道を見つけること、最高のキャリアアドバイスなどの技術トピックのセッションを毎月開催しています。
PagerDutyの社員も同様に、私たちのボランティアパートナーシップから恩恵を受けています。彼らはCode the Dreamの学生の旅について学ぶことで刺激を受け、テクノロジーがどのように構築されるかに影響を与えるためにテクノロジー業界の多様化に尽力しているため、還元を続けているのです。PagerDutyのソフトウェアエンジニアであるSolomon Tolosa氏は、Code the Dreamのメンターとしてボランティアをしており、「フルタイムまたはパートタイムの仕事、子育て、勉強を両立している多くの学生とつながりました。よいメンターを持つことは、ゲームチェンジャーとなり、学生が技術業界でキャリアをスタートさせるための努力に大きな違いをもたらします。Code the Dreamには、学生たちの旅の一部になる機会を与えてくれたことに感謝しています。」
コミュニティーの必要性
Code the Dreamは、多様な背景を持つ低資源地域の若者に、人生を変えるような技術分野でのキャリアへの道を提供し、学生の人生だけでなく、彼らのコミュニティーにも影響を与えるという使命を担っています。今年のGiving Tuesdayには、さまざまな背景を持つ学生がソフトウェア開発者になるための支援を行います。
時間の提供： Code the Dreamが成功するのは、ボランティアのおかげです。ボランティア募集の詳細は、Code the Dreamのウェブサイトをご覧ください。 寄付をする ：50ドルの寄付で、Code the Dreamは学生1人にプロの開発者による1時間の指導を行うことができます。
この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。
PagerDuty、re:Invent 2022でAWS向け自動診断機能を発表。 組織によるインシデントの迅速な解決を促し、より多くのイノベーションを実現が可能に
今年もこの時期がやってきました。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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。
