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

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

昨年、私たちは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インテグレーションガイドをご覧ください。 その他のご質問は、support@pagerduty.com までご連絡ください。

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インテグレーションガイドをご覧ください。 その他のご質問は、support@pagerduty.com までご連絡ください。

製品廃止のお知らせ

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

V1 Webhooks EOL

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

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

詳しくはこちら

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

重要な日程

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

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

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

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

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

企業における自動化は新しいことではありません。エンジニアは何十年も前から自動化ツールやフレームワークを使って仕事をしてきました。構成管理ツール、継続的インテグレーションとデリバリーパイプライン、クラウドの形成など、自動化はビジネスシーンにおけるほぼ全ての技術的なユースケースの構成要素となっています。こうしたことが本当なら、なぜ自動化はいまだに多くの手作業と対になっているのでしょうか。

その答えは？IT部門とそれ以外の部門に自動化を広く普及させるには、まだ明らかな遅れがあるのです。例えば、今日の企業の大半は、製品、サービス、ヘルプデスク、その他の顧客向けアプリケーションなど、何らかの形でデジタルサービスを提供しています。そして、ほとんどの企業は、そのサービス提供の展開や維持のために、IT組織内である程度の自動化を活用しています。しかし、自動化は利用されていても、その価値が十分に発揮されていないことがよくあります。自動化の利用は通常、ビジネスの小さな領域に限定され、自動化を実装または構築した従業員のみがそれを使用し適用することができます。

私たちはこれをオートメーションギャップと呼んでいます。

オートメーションギャップ オートメーションギャップとは、組織内の自動化の利用が島ごとに存在し、各専門業務部門がサイロ化した自動化を活用しているというシナリオです。さらに、オートメーションギャップがあるということは、（専門家以外の）ほとんどの従業員が、自動化を実際に利用するための系統的な知識、スキルセット、組織全体のアクセス権を有していないことを意味します。

ITの視点から見ると、オートメーションギャップは業務を停滞させ、次のような大きなビジネス上の問題につながる可能性があります。

専門家へのエスカレーションが絶えず、イノベーション能力が制限される SLAペナルティーとインシデント解決の遅れによるエラー率の増加 予定外の仕事や依頼が殺到し、専門家が燃え尽きる 最終的には顧客の不満と収益の損失につながる

デジタル世界における技術革新のスピードと消費者の期待の高まりを考慮すると、オートメーションギャップがもたらす負の外部性は、日が経つにつれて悪化または拡大する一方でしょう。しかし、問題に対処し、ギャップを埋める前に、ギャップの存在の根本的な要因を特定し、理解できるようにする必要があります。

オートメーションギャップの特徴は、大きく３つの要素に分類されます。 ナレッジギャップ スキルギャップ アクセスギャップ

ナレッジギャップ あらゆる規模のデジタルファーストの組織は、顧客のニーズを満たし、イノベーションに歩調を合わせ、競争に勝ち残るために、常に変革を続けなければなりません。この進化を成功に導くためには、デジタルインフラも並行して適応し、進化していく必要があります。しかし、進化は一夜にして起こるものではありません。進化は、何年にもわたるDX、従業員や文化の変遷、新たな複雑性や技術的な依存関係を経て、レガシーインフラの上で発生するものなのです。適切な文書化と理解なしには、シームレスな実行はほぼ不可能です。

ナレッジギャップとは、１人の個人または社員が、IT組織内のあらゆる依存関係、システム、ベストプラクティスについて、専門家になれるわけではないことを理解することです。例えば５年以上勤続している元社員は、レガシーインフラのインシデントに取り組むための系統的な知識を持っているかもしれませんが、８カ月勤務しているオンコール対応者は、同じ基礎インフラについて微妙な理解を持っていないかもしれません。

スキルギャップ スキルギャップとは、ユーザーによって技術的なスキルセットが異なるという現実のことです。ナレッジギャップと同様に、スキルギャップも組織のデジタルインフラ全体における新しいテクノロジーと複雑性を専門に扱う従業員に起因しています。新しいシステムやプロセスが導入されると、多くの場合、それらを構築または実装した専門家 （SME）が、必然的にインシデントが発生したときに問題を適切にトリアージできる唯一の人物となります。このような専門性のボトルネックは、対応のライフサイクルに悪影響を与え、専門家を疲れさせ、修復作業の効率を低下させる可能性があります。このギャップは、特に人員削減の時期に顕著で、XシステムやYサービスに必要な理解とスキルを持つ専門家が、１人か２人しかいなくなった場合に生じます。

誰もがデータベースの管理方法や継続的インテグレーションのパイプラインの自動化方法を知っているわけではありません。実際、企業で最も高いスキルを持つ技術者は、通常そのような需要があるため、その作業を軽減できればビジネスのスケールに貢献します。繰り返し行われる診断や手順を常に中小企業にエスカレーションすることは、予定外の作業を生み出し、本来なら専門家が優先すべき価値の高い作業の妨げになります。このような技術的な役割を担う人材の獲得は増加の一途をたどっており、このギャップを解消することは、企業にとって長期的な取り組みがより一層重要となっています。

アクセスギャップ 最後に、アクセスギャップは、今日のベストプラクティスに従ってセキュリティー体制を維持することに関連しています。 最小特権アクセスの原則に従えば、スーパーユーザーの資格情報をITスタッフ間で広く配布したり、共有したりしてはいけません。ツール、情報、システムに適切にアクセスできなければ、解決に要する時間の長期化、修復作業の非効率化、中小企業が価値の高い作業に集中する時間の短縮など、アクセス不足に起因する悪影響が生じます。

では、PagerDutyはどのようにしてこのオートメーションギャップを埋め、ITオペレーション全体の敏捷性を向上させ、チームがより速くイノベーションを起こせるようにするのでしょうか。

アプリケーションオートメーション PagerDutyの自動化機能により、これまで専門エンジニアにしかできなかったことがエンドユーザーにもできるようになります。このプラットフォームは、自動化を他の関係者に安全に委譲し、エスカレーションの中断をなくし、待ち時間を劇的に短縮することで、これらのギャップを埋めるように設計されています。これらのプロセスは、既存のタスク自動化を運用ワークフローの個々のステップに組み込むことができ、一貫した運用体験を提供しながら、プロセスのユーザーから各ステップの特定のコンテキストを抽象化できます。

PagerDuty® Process Automationのポートフォリオは、以下の製品で構成されています。

PagerDuty® Automation Actions：PagerDutyのレスポンダーをキュレーションし、インシデントに関与するサービスの自動診断と修復につなげるPagerDutyアドオンです。 PagerDuty® Runbook Automation：エンジニアがランブックの手順を標準化・自動化し、サービスをセルフサービス型オペレーションとして委譲できるSaaSサービス。 PagerDuty® Process Automation On-Prem：エンジニアがエンドツーエンドの運用ワークフローを標準化・自動化し、関係者にセルフサービス型オペレーションとして安全に委ねることができるセルフホスティング型ソフトウェア群です。

PagerDutyの自動化機能は、エンドユーザーと認証情報やキーを明示的に共有することなく自動ワークフローを呼び出せるため、組織がアクセスギャップを安全に解消するのにも役立ちます。シングルサインオン（SSO）と統合してロールベースのアクセス制御を可能にし、プロセスレベルとステップレベルの両方で全てのアクティビティーを記録して、コンプライアンス要件を満たします。

PagerDutyの自動化機能がオートメーションギャップを埋める過程でどう役立つかについては、https://www.pagerduty.com/use-cases/automation/ をご覧ください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

現実を直視しましょう。インシデントは高くつくものです、本当に。しかし、本番環境におけるインシデントの高いコストは、必ずしもサービスの低下やネガティブな顧客体験が原因とは限りません。PagerDutyのレスポンスデータによると、インシデント収束までの時間の50％以上は、最初のレスポンダーによる調査と出動段階（私たちは「トリアージ」と呼んでいます）に費やされています。 言い換えると、問題を見極め、解決するのに適役を呼び出す部分です。

上記の統計を考慮すると、インシデントライフサイクルの影の経費は、インシデントを発見したエンジニア、問題に対応し根本原因を特定したオンコールエンジニア、その他インシデントライフサイクルに動員されるあらゆる分野の専門家の時間であることは明らかです。さらに、対応プロセス全体に手作業が加わると、コストがかさみます。非常に高くつきます。

実際のところ、開発組織の時間は、ビジネスの利益と同じくらい貴重で重要です。そして、サービスやアプリケーションの開発が複雑化するにつれて、「削減された時間」は、追跡、定量化、および継続的な改善を行うための、より重要な指標となります。インシデント対応プロセスのさまざまな側面を自動化する方法を見つけることは、チームの時間を節約し、全体的な効率を高めるのに役立ちます。どうすればいいのでしょうか？PagerDuty® Automation Actions（旧PagerDuty Rundeck Actions）の出番です。

PagerDuty® Automation Actions

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

PagerDuty® Automation Actionsは、自動化された診断と修復をインシデント対応ワークフローに接続します。Automated Diagnosticsとは、インシデント発生時にレスポンダーが自動的に呼び出すことができる、本番サービス用のアクションのセットです。専門家にエスカレーションして一般的なテストを手動で実行させるのではなく、レスポンダーはPagerDutyから安全かつ確実にこの自動診断を実行し、インシデントタイムラインにリアルタイムで返されるレスポンスを確認することができます。

サービスの再起動や診断など、指定されたアクションを実行することができます。

これらの診断テストにより、レスポンダーは、大人数を巻き込んだり、一般的なレスポンダーの階層をエスカレーションすることなく、より効率的に適切な専門家にインシデントをエスカレーションして解決できます。専門家は、これらの一般的な診断の結果を見て、すぐに取りかかることができます。

さらに、チームはSlackインスタンスから直接これらのアクションを呼び出してインシデントについて共同作業を行うこともできます。これにより、ターミナルからサービスにアクセスしたり、ウインドウを切り替える必要がなくなり、より迅速かつ効率的にインシデントを解決できるようになり、専門家へのエスカレーションも減らすことができます。自動診断の利用が進むと、Event Intelligenceを利用した自動修復やトリガーなどの用途にも利用できるようになります。

PagerDuty® Automation Actionsは、組織の応答プロセスにおける４つの主要な問題領域を解決するのに役立ちます。

サイロ化された専門知識。** 第一線のレスポンダーは、組織の環境内にある全てのアプリケーションやサービスの遺伝子構成を把握しているわけではありません。 専門家への絶え間ない割り込み。** レスポンダーは、そのアプリケーションやサービスの専門家と思われるエンジニアにエスカレーションを行い、イノベーションを妨げ、インシデント収束を鈍化させています。 繰り返し、手動の診断手順。** インシデント発生時の最初のステップは、大体同じです。インシデントの解決に取り組む以前に、これらの同じ手動ステップを踏んでおく必要があります。 複雑で広大な本番環境。** どのシステムにアクセスし、どのようなアクションを取るべきかを知るには、時間を要することがあります。さらに、全ての対応者が特定の本番システムにアクセスする権限を持っているとは限らず、エスカレーションプロセスを難しく長引かせることがよくあります。

PagerDuty® Automation Actionsは、上記の課題を次のように解決します。

チーム間でオートメーションを委譲する。** 通常専門家が呼び出す自動化された手順を、第一線のレスポンダーに展開する。 より少ないエスカレーションで、より早くインシデントを解決する。** 一般的なリクエストや作業を自動化することで、エスカレーション先を特定する時間を減らし、より多くの時間を修正に費やすことができます。 人手を介した支援・自己回復の自動化を誘発する。** PagerDutyのEvent Orchestrationにより、レスポンダーが呼び出される前に診断アクションを呼び出すことができます。 セキュリティーを考慮した自動化の安全な発動。** レスポンダーは、インシデントの影響を受けるシステムに対して実行する権限を持つアクションのみを表示します。全てのアクションはログに記録されるため、強固なセキュリティー体制を維持することができます。

以上のことを簡単に箇条書きでまとめると、PagerDuty® Automation Actionsはチームを支援します。

応答時間を最大30分短縮、MTTRを最大25％短縮 エスカレーションされるインシデントの量を削減 対応チームに専門知識を共有 レスポンダーが呼び出される前に、人手を介した支援と自己回復の自動化を開始 ファイアウォールやVPCの背後にある安全な自動化を誘発 手作業に代わる自動化されたアクションを導入 事後検証の円滑化、オペレーターの作業軽減のためのインシデント文書化の充実

PagerDutyの自動化ポートフォリオについてもっと知りたい方は、自動化ハブをご覧ください。PagerDuty Automation Actionsについて、また、それがどのようにチームの時間とコストの節約につながるかを知りたい場合は、アカウントマネージャーに連絡するか、今すぐ詳細をご覧ください。

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

スクラムセレモニーとは、スクラムイベントやミーティングの一種で、プロジェクトをよりタイムリーかつ効率的に進めることを目的としたものです。このセレモニーは、制作プロセスの重要なポイントで行うもので、チームメンバー間の組織的なコラボレーションとコミュニケーションを重視し、複雑な開発プロセスやキューを簡素化することを支援します。例えば、デイリースクラムは毎朝行われ、どの項目が完了し、どの項目に取り組んでいるか、そしてどの項目が先に控えているかを確認する儀式です。

スクラムセレモニーには、以下のような５つのスクラムイベントがあります。 スプリントプランニング：スプリントバックログを決定し、チームの期待値を設定するためにスプリントの最初に開催されます。 デイリースタンドアップ／スクラム：毎日（多くは一日の始まりに）行われる15分間のセレモニーで、チーム全体のアイテムの進行状況をスクラムチームメンバー全員に素早く報告します。 スプリント：スプリントは、スクラムチームメンバーが協力してスプリントバックログを完成させるためのイベントと考えられています。 スプリント／イテレーションレビュー：スプリントや特定のマイルストーンの終了時に開催され、完了した作業をレビューして発表します。 レトロスペクティブ：イテレーションの終わりに開催され、イテレーション中に何がうまくいったか、どんな問題が出てきたかを分析します。レトロスペクティブの目的は、継続的な改善を促し、開発を最善の方法で前進させることです。

スクラムやその他のアジャイル手法で非常に重要なのは、チームメンバーや利害関係者全員が制作のライフサイクルについて明確かつ共有した理解を持つことです。スクラムのセレモニーは、物事を整理し、前進させるための接着剤となります。 この記事では、これら５つのスクラムセレモニーについて、どのスクラムチームメンバーが関与するのか、それぞれのミーティングは通常いつ、どれくらいの時間行われるのか、そしてそれぞれのスクラムセレモニーの目的について詳しく見ていきます。

アジャイルメソドロジー＆スクラム

企業やその規模にかかわらず、全ての開発チームの主要な目標の１つは、新しい製品やアップデートを迅速かつ効果的にユーザーに展開することです。定期的かつ確実なアップデートによって製品／サービスの体験を継続的に改善できれば、ユーザーとの信頼関係やロイヤリティーが徐々に構築されます。さらに、幸せな顧客を持つことによる収益性の向上は、利害関係者との良好な関係を維持することにつながります。

今日、テクノロジー企業は、信頼できるプレミアムなユーザー体験を提供するために、アジャイル開発方法論を用いて生産プロセスの改善に役立てています。そして、これらのアジャイル開発手法の中で、スクラムは明らかにNo.1であり、約60％の組織が製品開発にスクラムを活用しています。スクラムは、作業内容、進捗状況、タスクやアイテムの優先順位など、チームの完全な理解に基づくものです。

スクラムの５つのセレモニー

スクラムセレモニー#1：スプリントプランニング

スプリントプランニングは、スプリントの最初に行われるミーティングで、スプリントバックログ（スプリント中にチームが完成させるべき項目の全一覧）を決定します。また、このミーティングでは、スプリントを成功させるために、チーム全体への期待値を設定する必要があります。

スプリントプランニングに参加するのは誰ですか？** スクラムの全役割（開発者、スクラムマスター、プロダクトオーナー） スプリントプランニングはいつ行われますか？** それぞれの新しいスプリントの開始時 スプリントプランニングのミーティングの長さはどれくらいですか？** １～２時間 スプリントプランニングはどのくらいの頻度で行うべきですか？** 全スプリントの前

スクラムセレモニー#2：デイリースクラム

デイリースクラムは、プロダクトバックログで何が起こっているかを全員に知らせるために、最も一般的には午前中に開催される短い毎日のミーティングである。このミーティングはかなり短時間であるべきですが、各メンバーが完了したもの、取り組んでいるもの、障害に遭遇していないかなどを議論する時間を確保する必要があります。

デイリースクラムに参加するのは誰ですか？** 全スクラムロール デイリースクラムはいつ行われますか？** 通常、作業の開始時 デイリースクラムの長さはどれくらいですか？** 15～20分 デイリースクラムはどのくらいの頻度で行うべきですか？** 毎日

スクラムセレモニー#3：スプリント

スプリントは、指定された時間ブロックの間にチーム全体が完了するように設定されたタスク（または仕事の塊）のリストです。これは、スプリントプランニングのセレモニーで示されるものです。

スプリントに参加するのは誰ですか？** 開発者 スプリントはいつ行われますか？** さまざまです スプリントの長さはどれくらいですか？** スプリントプランニングに基づき、各スプリントにはそれぞれブロック化された時間目標があります。スプリントの期間は数日から数週間、数カ月とさまざまですが、スプリントバックログの内容によって異なります スプリントはどのくらいの頻度で行うべきですか？** さまざまです

スクラムセレモニー#4：スプリント／イテレーションレビュー

スプリント／イテレーションレビューは 、スプリントやその他の特定のマイルストーンの完了後に開催されます。このセレモニーの目的は、完成した作品をレビューし、紹介することです。スプリント／イテレーションレビューでは、開発チームは完成した機能やアップデートをチーム全体に向けてデモンストレーションします。他のチームメンバーやステークホルダーからのフィードバックが得られるだけでなく、開発者にとっても自分の頑張りをアピールできるチャンスです。

ここで重要なのは、これはあくまで部分的なレビューであり、完全なレビューは「レトロスペクティブ」で行われるということです。

スプリント／イテレーションレビューに参加するのは誰ですか？** 全てのスクラムロール、ステークホルダー、プロジェクトの他のチームメンバー スプリント／イテレーションレビューはいつ行われますか？** スプリントやマイルストーンが終了したとき スプリント／イテレーションレビューの長さはどれくらいですか？** 最大４時間 スプリント／イテレーションレビューはどのくらいの頻度で行うべきですか？** スプリントが完了したとき

スクラムセレモニー #5： レトロスペクティブ

レビューが製品や完成した仕事に焦点を当てるのに対して、スプリントレトロスペクティブはプロセスに焦点を当てます。何がうまくいったのか、何が問題だったのか、プロセスの問題点を解消し、ツールを追加・調整し、人間関係やコミュニケーションを改善するための計画を立てる場でもあります。

レトロスペクティブに参加するのは誰ですか？** 全スクラムロール レトロスペクティブはいつ行われますか？** 完了したスプリントやその他のマイルストーンの終了時 レトロスペクティブの長さはどれくらいですか？** スプリントの長さ１週間につき最大45分（例：２週間のスプリントの場合、最大1.5時間のレトロスペクティブとなる） レトロスペクティブはどのくらいの頻度で行うべきですか？** スプリントが完了したとき

スクラムセレモニーのメリット

製品がますます複雑化する中、チームメンバー間の組織的なコミュニケーションとコラボレーションはこれまで以上に重要です。スクラムの５つのセレモニーは、チームメンバーが製品／プロジェクトについて共通の理解を持ち、製品ライフサイクルを通じて同期を保つことを支援します。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。