Blog
ブログ

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

株式会社ココナラは、デザインやウェブサイト制作などの仕事や、プライベートからビジネスまでの相談を気軽に依頼できるマッチングサービスを提供しています。同社はITインフラの運用において、多種多様なアラートを管理し、適格なアクションを割り当てられるインシデント管理ツール「PagerDuty」を活用しています。PagerDutyの導入以前は、アラートの発報に時間がかかり、オンコール当番だけに負荷がかかるという課題がありました。そこでPagerDutyを活用し、DatadogやAmazon Cloud Watch、Sentryなどの監視ツールと連携させることにしたのです。優先度を見極めた発報が行われ、アラートの絞り込みも可能になり、効率化が実現しました。現在は、オンコール当番制度もあるため、平均確認時間（MTTA）は日中で1分以内となっており、 平均修復時間（MTTR）についても暫定対応は1営業日程度に抑えられています。

詳しくはこちらのCodeZineの記事をご覧ください。

「PagerDutyでオンコールの負担を大きく軽減！エンジニア横断で対応するココナラのインシデント対応」

https://codezine.jp/article/detail/17145?p=1

インシデント対応における労力を軽減し、煩雑な作業を自動化できれば、チームはより迅速に問題の特定と解決に集中できます。そして、インシデントを迅速に解決するほど、新しい製品やサービスの構築に早く戻ることができるようになります。

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社がリードする

米国の先端セキュリティー技術企業である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は、ダウンタイム解決の迅速化、顧客への積極的なコミュニケーション、比類のないレベルのカスタマーサービスの提供を可能にするプロアクティブなチームにとって不可欠であることが証明されています。 最近私たちはPagerDuty for Customer Service in ServiceNow CSMの発売を発表し、CSOpsの機能を拡張しました。プラットフォームを切り替えることなく、リアルタイムのデジタルオペレーションをServiceNowに反映できる、既に緊密な統合をベースに、カスタマーサービスのエージェントとエンジニアリングチーム間のより緊密なつながりを構築しています。

PagerDutyのServiceNow向け新アプリは、ServiceNow CRMに統合された体験を提供し、カスタマーサービスチームが事例を最初から最後まで管理するために必要な可視性を提供します。PagerDutyの統合されたリアルタイムのカスタマーサービス運用により、各チームはServiceNow CSMからアクティブなケースのステータスを直接確認できます。チームはインシデントを作成し、開発チームやITOpsチームが作成したメモやステータスの更新を確認し、ServiceNowからPagerDutyでエンドカスタマーに正確かつ効率的に返答できるようになりました。これにより、カスタマーサービスと技術チームの間のギャップを埋め、適切な人材を適切なタイミングで関与させ、顧客の問題に先手を打つことができます。

もっと詳しく知りたいですか？統合ガイドをご覧ください。

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

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は、大規模なインシデント発生時の社内関係者とのコミュニケーションを効率化するために役立ちます。このたび、この機能に新たな機能が追加されました。この機能により、チームはコミュニケーションをカスタマイズできるだけでなく、影響やサービスエリアなどの条件を表す動的な変数挿入を使用して、再利用可能なテンプレートを作成し、標準化することができます。

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

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

あるツールを使いこなせたと、自信を持って言える人はどれくらいいるでしょうか。多くの人と同じく、製品の機能のほんの一部しか使っていないのではないでしょうか。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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。