Blog
ブログ

本日は国際女性デーということで、オーストラリアの技術職の女性たちにスポットライトを当て、特にDevOpsのキャリアに焦点を当てる、待望の機会となっています。

昨年６月、LinkedInはDevOpsエンジニアを最も需要の高い職種第10位に挙げ、最近の求人レポートでは情報通信技術（ICT）分野の職種が業界で最も高給であることが判明しました。

エンジニアリングに限らず、さまざまな職務におけるDevOpsエキスパートの需要は、飛躍的に高まっています。プラットフォームやアプリケーションが記録的なスピードで出現し、進化していく中で、これらの職務は、女性が国内外で大きな成功を収めるのを目にすることができます。

テック業界は、自動化の進展に伴い、今後数年間で他のどの業界よりも急速に成長すると思われます。技術系、非技術系を問わず、金融サービス、小売、教育などの分野でキャリアの機会が増え続けており、COVID-19はこれをさらに加速させるものです。しかし悲しいことに、Australian Computer Societyの最近の統計によると、オーストラリアの技術系労働者に占める女性の割合はわずか29％に過ぎません。

オーストラリアでは、科学、技術、工学、数学（STEM）のあらゆる段階で、才能のある女性が失われています。また、調査によると、女子は６歳でSTEMから離れることが分かっています。これは主に、目に見える女性のロールモデルがいないことや、STEMの専門家が何をするのかが理解されていないことが一因となっています。

しかし、2022年現在では、イノベーションの機会が最前線にあり、キャリアパスについて女性の意識を高める余地が大いにあります。

これを受けて、PagerDuty APJは、技術分野の女性に焦点を当てた地域プログラムを立ち上げました。これはWomen in Technologyの地域支部から始まり、PagerDutyの広範なプログラムであるSisterDutyの一部を形成しています。さらに、四半期に一度、メンターと若いメンティーがペアを組み、知識やアドバイスを共有するメンターシップミートアップを開催しています。

外部からは、STEM分野の若い女性を支援するTech Girls Movement Foundationとパートナーシップを結び、毎年開催されるNext Tech Girl Superheroコンテストでメンターや審査員として協力することにしています。

女性だからといってチャンスは限られていませんし、むしろ増える一方だと思います。女性リーダーは異なるスタイルのマネジメントを組織にもたらしますが、私はこのカルチャー、共感、成功に焦点を当てたスタイルにチームがよく反応すると思います。

技術やDevOpsのキャリアを考える女性を鼓舞するために、私は３つのアドバイスをしています。

じっくりと正しい道を探ってください。テック業界は、女性にとって素晴らしい機会を与えてくれます。時間をかけて探索し、充実感と感動を与えてくれる道を探してください。 選択肢を研究してください。オーストラリア国内のテック業界は、多くのエキサイティングなスタートアップ企業で活況を呈しています。よく調べて、選択肢を検討しましょう。リスクをとることを恐れないでください。この業界に入れば、可能性は無限に広がります。 あなたの声を届けましょう。この業界に多様な視点を持ち込むことは、非常に歓迎されるでしょう。現状を打破し、新鮮なアイデアと思考をもたらすことを恐れないでください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

本日、PagerDutyはCatalyticの買収により、自動化能力を新たな規模と範囲に拡大することを発表いたします。Catalyticの技術と優秀なチームによって、私たちはあらゆるワークフロー、あらゆる従業員に広く適用できる企業全体のノーコードワークフローを管理し、プロセス自動化の提供を加速させます。私たちの能力を組み合わせることで、フロントオフィスとバックオフィスの両方のワークフローに対応できる統一プラットフォームを企業に提供し、DevOps、技術、カスタマーサービスチームだけでなく、法務、財務、人事、営業、その他の職種にまで私たちの影響を拡大できます。

この新機能により、企業全体の反復作業を自動化できます。例えば、ビジネスオペレーションにおける従業員、顧客、パートナーのオンボーディング、収益チームにおける販売とパイプラインのレポート、契約、合意、雇用、購買などのあらゆるタイプの共同コンテンツレビュープロセスを含められます。実際、技術的な知識やコーディングを一切必要としない直感的なインターフェイスを使用して、既存のあらゆる反復的なワークフローを迅速に実装できます。

PagerDutyが重要な業務の管理にフォーカスする上で、自動化は常に最前線にあります。世界がより予測不可能になるにつれ、デジタルオペレーションの複雑さと企業のビジネススピードは加速し続けています。勝ち組になるには、自動化によってチームを強化し、より多くの時間をイノベーションに費やせるようにする必要があります。繰り返しのタスクで人に負担をかけることはスケーラブルではなく、最もスキルの高い、限られたリソースである従業員に余計な負担をかける結果になります。

一番大事なデジタルサービスが利用できない場合、ビジネスへの影響は驚くほど大きくなります。そのため、当初は、高いスキル（と報酬）を持つ開発者や技術チームのために、大規模なインシデント対応を自動化することに焦点を当てました。PagerDutyは、自動化されたインシデント対応とインシデント発生時の自動リアクションのパイオニアです。その後、ノイズや誤報を減らすためのイベント管理の自動化に着目し、イベントインテリジェンスでマシンタイムにロジックを注入しています。2020年10月には、Rundeckの買収を完了し、これを急速にプラットフォーム上に統合しました。これにより、ランブック、自動診断、自動修復によるタスクの自動化でレスポンダーを強化し、問題解決にかかる時間を大幅に短縮するとともに、そのための力を第一レスポンダーの手に委ね、開発者や高度なスキルを持つチームの中断やエスカレーションを完全に省くことができるようになりました。

Catalyticの機能と熟練した自動化チームが加わったことで、私たちは、ビジネスに不可欠なデジタルサービスだけでなく、企業全体のあらゆるビジネスワークフローに範囲を広げています。冗長なタスクやプロセスを排除し、可能な限り人手をかけずにビジネス全体のサービスレベルを満たし、それを超えることを保証します。

現在、PagerDutyは企業全体のあらゆる反復的なオペレーション業務に取り組んでおり、ビジネス全体のプロセスの自動化と、あらゆる状況に対応できる従業員への稼働能力の提供に注力しています。

私たちは、企業全体に機能を拡大できることに、この上ない喜びを感じています。ビジネスが顧客中心になり、デジタルサービスがビジネスのあらゆる側面を強化するにつれ、PagerDutyデジタルオペレーションプラットフォームは、全ての従業員の反復作業をサポートし、タスクや不要な中断を取り除き、最も重要なことに集中できるよう拡張していきます。私たちは、以前のRundeckと同様に、Catalyticの機能を迅速に組み込み、PagerDuty上に統一された体験を短期間で提供する予定です。

企業はPagerDutyに最も重要なサービスを任せることで、信頼を深めてきました。私たちは、その信頼に基づき、将来にわたってお客様の組織全体の業務プロセスをサポートできることを嬉しく思っています。

セーフハーバー条項

この発表には、PagerDutyの信念と仮定、およびこの発表日時点でPagerDutyが利用可能な情報に基づく「将来予想に関する記述」が含まれています。将来予想に関する記述には、「買収が完了すると予想される時期（完了する場合）」、買収によって期待される利益、CatalyticをPagerDutyの事業にうまく統合する能力、買収がPagerDutyの製品とサービスに与える影響、およびCatalyticの製品とサービスの能力に関する記述が含まれますが、これだけに限られるものではありません。既知および未知のリスク、不確実性、およびその他の要因が多数存在するため、PagerDutyの実際の結果、パフォーマンス、または業績が、将来に関する記述で表明または暗示されたものと大幅に異なる可能性があります。これには、合併した事業、技術、人員、および運営を完了し統合する際に遭遇する困難、買収に関するコスト、買収および結果として得られる製品およびサービスの市場受容、製品およびサービスのイノベーションを含む事業に対する重要な投資からPagerDutyが価値を実現できないこと、一般市場、政治、経済およびビジネスの状況、などがあります。

PagerDutyの業績に影響を与える可能性のある要因に関する追加情報は、米国証券取引委員会に提出されている2021年10月31日に終了した四半期のフォーム10-Qによる同社四半期報告書およびPagerDutyが米国証券取引委員会に提出したその他の書類に記載されています。法律で義務付けられている場合を除き、PagerDutyは、新しい情報、将来の出来事、その他の結果に関わらず、将来予想に関する記述を更新または修正する意図や義務、または実際の結果が将来予想に関する記述で予測されたものと大きく異なる理由を更新する意図を持ちません。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

テクノロジー企業での業務は、ソフトウェア開発の仕事だけではありません。PagerDutyのようにソフトウェアを事業としている企業では、あらゆる職務がテクノロジーに関わります。PagerDutyの多様性イニシアティブは、CAPインターンシッププログラムから取締役会まで、組織のあらゆるレベルに及んでいます。 女性史月間と国際女性デーの今年は、昨年に引き続き、女性に焦点をあてたプログラムを充実させたいと考えています。2021年のイベントを見逃した方は、 録画をご覧いただけます。今年のウェビナーでは、ゲストスピーカーにDevOps InstituteのチーフアンバサダーであるHelen Bealを迎え、その後PagerDutyとユーザーコミュニティーの幹部がパネルディスカッションを行います。3月23日のイベントについての詳細と参加申し込みはこちらから。

ウェビナーに加え、パネルディスカッションも開催し、当社のソーシャルメディアアカウントでライブストリーミング配信します。私たちは、女性経営者が何に刺激を受け、どう組織を運営しているかを話すのが大好きです。今年はパネルを拡大し、PagerDuty、お客様、そして私たちのコミュニティーで技術専門職として活躍する女性の話をもっと聞きたいと思いました。これらのディスカッションはTwitterアカウントでフォローできますし、質問をしたい場合はTwitchでも視聴できます。ライブを見逃した方もご安心ください。TwitchやYouTubeアカウントで録画したものを見ることができます。

今週はPagerDutyの最高ダイバーシティー責任者であるRoshan Kindredから話を聞きます。Roshanは昨年夏にPagerDutyに入社し、公平性と帰属意識に対する情熱を持ち続けています。私たちはRoshanと、DE&I、キャリア成長、そして女性が技術キャリアで自分自身を主張する方法について話をします。3月7日（月）2pm EST / 11am PSTにご参加ください。

火曜日は、PagerDutyチームのJess Ritterと、H&R BlockのBrittany Woodsと一緒にSREについてお話します。JessはSREデリバリーチームで、私たちの製品をお客様に届けるために必要なものを全開発チームが持てるよう保証しています。BrittanyはH&R BlockでServer Automationのマネージャーをしています。彼女は昨年、ポッドキャストのエピソードにも参加しています。このパネルは、3月8日（火）2pm EST / 11am PSTに開催されます。

水曜日は、人々がテクノロジーから最も連想する仕事であるソフトウェア開発に取り組む人たちに話を聞きます。パネルディスカッションでは、PagerDuty RundeckチームのJulianna Green、Event OrchestrationsチームのNeha Wadhwa、モバイル開発チームのSanthoshi Shakar、そしてApp FoundationsチームのHannele Kormanoが登壇予定です。このパネルは3月9日（水）2pm EST / 11am PSTに開催されます。

木曜日のパネルは、セキュリティーとコンプライアンスに焦点を当てます。セキュリティーエンジニアIIのNeha Guptaをはじめ、ScaleSecのシニアクラウドセキュリティーコンサルタントのSarah Gori、Elasticのセキュリティーエンジニアリング生産性担当シニアQAエンジニアのTanisha L. Turnerが参加する予定です。セキュリティーパネルは3月10日（木）2pm EST / 11am PSTに実施します!

最後に、金曜日は、プロダクトチームとプロダクトマーケティングチームの女性を特集します。PagerDutyのプロダクトマネージャーとプロダクトマーケティングマネージャーは、さまざまな技術的経験を持ち合わせています。プロダクトマネージメントチームからはJulianna NasserとMya Kingが、プロダクトマーケティングからはVivian Chanが参加します。3月11日（金）3pm EST / 12pm PSTにご参加ください（このパネルは、スケジュールの都合で他のパネルより１時間遅く開催されます）。 私たちのパネルは、PagerDutyで女性が担っている全ての役割を網羅しているわけではありませんが、2022年の国際女性デーを記念して、これらのストーリーを皆さんと共有できることを誇りに思っています。もし、あなたがこれらの役割のいずれかに自分自身を重ねているのであれば、boards.greenhouseから応募して参加してください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

AIOpsは、機械学習と人を組み合わせ、IT運用で技術的成果を実現するものです。この能力への期待が新たな競合を市場に送り込み続けています。AIOpsは、あらゆる主要なイベント管理プレーヤーにとって、メッセージングの中核となるコンポーネントとなっています。多くの企業が自社製品のブランドを変更し、AIOpsの機能を特に強調するようになりました。新興のイベント管理プレーヤーも登場し、AIOps市場に場を確保しようと試みています。ほぼ全ての観測可能なAPMベンダーが同じことを行い、自分たちが今、AIOpsツールとして選ばれていると主張しています。

AIOpsとは何か？

しかし、一歩下がってほんの少し現実を見てみましょう。AIOpsはツールではなく、一連の機能です。したがって、製品セットとしてのAIOpsを定義することは困難です。これは、自分のツールがDevOpsのツールとして選ばれていると主張するのと同じようなものです。業界をリードするアナリストでさえ、AIOpsの中核となるアプローチは何か、AIOpsの特定のヒューリスティックは何かについて、同様に意見の相違があります。このような意見の相違はあるものの、私たち実務家は、大多数のAIOpsソリューションを２つの中核的な陣営に分類して考えることができます。

オプションその１：アプリケーション監視

アプリケーション監視ツールは、最初の陣営を所有しています。この監視中心のアプローチは、メトリクス、KPI、ログなどを活用し、機械学習と傾向分析を使用して予測を行い、より早くスマートなアラートを出せるようにすることを目的としています。良い点は、全てを監視することで、根本的な原因に近づける可能性があることです。一方、デメリットは、監視を複製することになるか、これらのツールセットを活用するために現在のツールセットの大部分を削除して交換しなければならないことです。さらに、ネットワーク、ストレージ、アプリケーション、パフォーマンスモニタリングなど、全てを１つのツールで監視することは、特に「十分な」監視ツールを置き換える場合、コストがかかる可能性があります。

オプションその２：イベント管理

2つ目のアプローチは、イベント管理です。このソリューションのグループは、異なるモニタリングを統合することでドメインにとらわれない視点を維持し、単一の管理画面の結果に焦点を当てた集中型NOCの能力タイプに行き着くことになります。このアプローチでは、全ての異種情報を一元化することで、理想的にはより良い意思決定を行うことができると期待されています。しかし、ルールを更新するために一元化された場所を持つ必要があるため、能力のボトルネックになってしまう可能性があります。さらに、多くのベンダーがピーク時の使用量、１日の平均使用量、ノード数、イベントソース数などのデータに基づいて異なる料金指標を設定しているため、ソリューションのサイズ設定が難しい場合があります。

どちらのアプローチも抜け落ちているのは、「完璧な」根本原因を突き止めることができても、「さあ、どうする？」がないことです。どのように問題を解決するのか？これらのソリューションを使用するチームは、実際の銃撃戦に役立つ重要な質問をまだ残していることになります。どのサービスが影響を受けているのか？そのサービスの所有者は誰か？誰がそのサービスのために待機しているのか？どのような診断が必要なのか？どのような自動化が可能か？

これらの答えが見つからないと、サービスを復旧させるのに苦労することになります。

より良いAIOpsソリューション

PagerDutyは、ほとんどのAIOpsソリューションが無視しているリアルタイムの作業の問題を解決するために、この課題に取り組んでいます。私たちは、ノイズを減らし、根本原因を特定するためのコンテキストを作成し、労力を削減しサービスを回復するための自動化を促進します。PagerDutyを利用することで、チームはフルサービスのオーナーシップアプローチを活用し、ビルダーやイノベーターが競合他社よりも早くソリューションを市場に投入し、顧客のために価値を繰り返し提供できるよう支援します。PagerDutyは、お客様が既にお持ちのツール、チーム、機能を活用し、デジタルトランスフォーメーションに向けた幅広い戦略的優位性の構築をサポートしながら、戦術的な運用を迅速に実現するお手伝いをします。

自動化ファーストアプローチ

私たちの自動化ファーストのアプローチは、私たちのランブックオーケストレーションプラットフォームであるRundeckを第一レスポンダーとして活用することで、あなたのチームの働き方を変えることができます。Rundeckを使うことで、チームを動員することなく問題を解決できることがたくさんあります。この自動解決はMTTRを大幅に改善しますが、それと同じくらい重要なのは、各分野の専門家が本業に集中できるようにすることです。自動化が問題を即座に解決できない場合は、自動診断により、影響を受けるサービスと顧客への影響とSLAへの影響を第一レスポンダーが理解できるようにコンテキストを作成できます。そうすることで、ログ、スクリプト、手順から情報を収集し、自動化対応を推進するための指針とすることができます。これにより、全体の監査証跡が作成され、事後検証やITSM問題管理を改善し、将来、同様な問題が発生するのを避けられます。

私たちのプラットフォームは、大規模な組織や複数のチームがセルフサービスで管理できるように、API設定機能を活用しています。そのため、ルールの更新や設定の管理を中央のチームに依存するのではなく、管理者はリポジトリーやTerraformなどのツールを活用し、チームが必要とする更新を迅速に入手できるようにすることができます。中央のチームの力だけに頼って渋滞を起こすことを避けられます。

自動化を優先したデータ駆動型のセルフサービスアプローチにより、チームと機械学習が一体となって問題を解決し、根本原因を見つけるだけでなく、AIOpsの真の約束を実現できると信じています。このドメインにとらわれないアプローチでは、適切なタイミングで適切な情報を適切な担当者に提供することに集中できます。アクションを実用的なインテリジェンスに置き換えることで、ノイズやアラート疲れを減らし、第一レスポンダーが問題を解決できるようにし、労力を削減し、ビルダーやイノベーターがインシデントを追いかけるだけでなく、新機能を提供できるように変えられるのです。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

PagerDutyがAWS 金融サービスコンピテンシーパートナーとして承認されたことを発表でき、うれしく思います。私たちは、世界的展開を拡大し、金融サービス企業のクラウド移行とデジタルアクセラレーションの道のりを加速する支援を行うことを楽しみにしています。これにより、金融サービス企業のデジタル業務をさらに合理化・自動化するとともに、リスク低減やコンプライアンス要件管理の支援が可能になります。

AWSは、クラウドネイティブかハイブリッドクラウドインフラを運用しているかを問わず、多くの金融サービス機関にとって信頼できるクラウドプロバイダーです。信頼されるパートナーになることは、並大抵のことではありません。PagerDutyは、金融サービス業界におけるAWSの専門性を実証し、金融サービスソリューションの監査に合格するなど、多くの要件を満たしました。

今回、PagerDutyとAWSの連携により、より多くの金融サービス機関がクラウドスケールを最大限に活用し、自動化、DevOps、サービスオーナーシップ、コミュニケーションの合理化を通じてデジタル運用管理のレベルアップを図ることができます。

変化はすぐそこにあった

デジタルトランスフォーメーションは、企業規模に関係なく、全ての業界と地域に広がっており、新しい顧客体験の提供、迅速なイノベーションの実現、クラウドの規模と機敏性の活用に道を開くのに役立っています。また、新たなクラウドネイティブの組織が消費者の求めているサービスをクラウドによって迅速に提供しやすくなりました。

特に金融業界は、消費者の要求がますます高まっており、変化の時期を迎えていました。新たな既存企業の参入により、全ての組織が競争力を維持するために、より迅速なイノベーションへと駆り立てられました。2020年のリモート化も相まって、デジタルトランスフォーメーションにとってこれほど良いタイミングはありませんでした。

移行から近代化へ

一枚岩として運営されている既存の金融機関にとって、近代化への道はハードルが高いものです。これらの企業は、生き残るためだけでなく、成功するために変化する必要がありました。

クラウドへの移行は、テクノロジーだけでなく、オペレーション、そして最も重要なのは、その全てを可能にする人材です。金融サービス企業の働き方に大きな組織的変化をもたらすには、人材、ツール、プロセスにわたって整合性をとる必要があります。

金融サービス企業は、クラウドへの移行を始めるにあたり、さらなる課題に直面することになりました。規制の厳しい市場でリスクを軽減・低減し、コンプライアンス要件を満たすことが、クラウド導入の複雑さに拍車をかけています。つまり、コンプライアンスと規制要件を満たすために、ガードレールとコントロールが既に組み込まれた安全なツールを選択する必要があると同時に、顧客のために迅速にイノベーションを起こすために、クラウドの拡張性と機敏性を最大限に活用する必要があるのです。

PagerDutyとAWS

金融サービスが停止すると、何百万人もの人々や何十億ドルもの収益に影響を与えます。クラウドでは数百のサービスが全て相互接続・相互依存しているため、障害発生がより複雑になる可能性があります。一刻を争う事態となった場合、インシデント対応を合理化・自動化し、人材、ツール、プロセスの連携を支援するデジタルオペレーションプラットフォームが必要となります。

PagerDuty Operations Cloud ™は、現代のデジタルビジネスにおける緊急かつミッションクリティカルな業務のあらゆる側面を管理します。AWS上に構築されたスケーラブルで安全かつ柔軟なプラットフォームで、企業、人材、テクノロジーを統合し、顧客、従業員、ビジネスの評判に影響が及ぶ前に、これらのビジネスにおける緊急かつ時間的制約のある作業を特定、エスカレーション、自動化、解決します。

業界をリードする当社のAWS統合ソリューションは、あらゆる規模の企業がクラウドの力を活用し、サイロ化した集中型アプローチから、複数の分散型チームとハイブリッドインフラへの移行を進め、安全かつ大規模に、より迅速なデジタル変革を推進できるようにするものです。

PagerDutyとAWSを使用すると、金融サービス組織は、次のことができます。

企業全体とハイブリッドクラウドインフラのインシデント対応を合理化・自動化し、顧客価値を提供します。 PagerDutyとAmazon GuardDutyおよびAWS Security Hubの統合により、AWSインフラに影響を与える可能性のあるセキュリティー問題の脅威対応プロセスを自動化し、適切な担当者に直ちに通知されるようにします。 マイクロサービスアーキテクチャーへの移行に伴い、技術サービスとビジネスサービスの完全な可視性と明確なオーナーシップを全員が確保できるようにします。

PagerDutyと業界をリードするAWSとの統合により、金融サービス企業は人材、ツール、プロセスを連携させ、クラウド移行とエンタープライズ近代化の動きを加速させることができます。金融サービス企業は、モノリスを解体し、マイクロサービスアーキテクチャーに移行することで、クラウドの規模と機敏性を得られるようになります。この結果、より迅速なイノベーションと顧客の満足度を高めることができます。

詳しくは、最近のウェビナーやre: Inventでのプレゼンテーションをご覧ください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

ここ数年、ストリーミング、ショッピング、仕事、ヘルスケアなど、私たちの世界はますますデジタル化しています。顧客はこれらのデジタル体験がシームレスであることを望んでいます。これはあらゆる企業にとって重要な優先事項となっています。なぜなら、企業の売り上げやブランドの評判は顧客満足度に左右されるからです。 このようなシームレスなデジタル体験を保証するために、テクノロジーチームは信頼性、ユーザー体験、新機能の構築に過去と比べ倍以上の努力を払ってきました。しかし、デジタルの世界は完璧ではありません。問題が発生した場合でも、顧客を安心させ、維持するために、企業はこれまで以上にカスタマーサービス（CS）チームを必要としています。 PagerDuty for Customer Serviceは、カスタマーサービスチームがプロアクティブになり、ケースに費やす時間を短縮し、SLAを達成し、比類のないレベルのカスタマーサービスを提供できるよう支援します。 昨秋当社は、Salesforce Service Cloud用の PagerDutyアプリケーションを発表しました。これにより、ユーザーは Salesforce Service Cloudで直接作業でき、コンテキストを切り替える必要性が減りました。これにより、カスタマーサービスチームは、迅速かつ効率的に、そして部門を越えて仕事ができるようになりました。今回、カスタマーサービスエージェントのユーザーのために、さらに多くの機能を発表できることを嬉しく思います。これらの新機能により、チームは顧客に影響を与える問題の影響範囲を把握し、より迅速に対応できるようになります。

Incident Subscription Incident Subscriptionにより、CSエージェントは、リアルタイムのサービスステータスコンソールを介して、SFDC内で直接インシデントを閲覧（サブスクライブ）できるようになりました。シングルクリックで、エージェントはインシデントの進捗と解決に関するリアルタイムのアップデートを受け取ることができます（以前のように、チケットとインシデントを手動で「リンク」させる設定は必要はありません）。一度サブスクライブすれば、エージェントは自分のキューにある他の顧客チケットを処理することができ、影響を受けた顧客とのループを閉じるときにPagerDutyが再エンゲージするのを知ることができます。

ダッシュボードトグル この新機能により、カスタマーサービスエージェントは、自分たちに特化・関連したStatus Dashboardを持てるようになります。顧客向けサービスに特化したビジネスサービスのStatus Dashboardを作成できるため、バックエンド全体のシステムヘルスと顧客に直接関連するシステムヘルスを分けて表示することができます。これにより、CSはよりシンプルになります。

PagerDutyのインシデントタイトルをSalesforceのデータでカスタマイズする エージェントはさらに、Salesforceのケースから得た重要な情報に基づいてチームがPagerDutyのインシデントをカスタマイズできるよう、強力に支援できます。このデータにより、顧客と問題と緊急性を特定し、複数のケースをPagerDutyのインシデントにリンクさせることが容易になります。エージェントは、ケースをドリルダウンしたり、ツール間でコンテキストを切り替えたり、ケースの進行に関するリアルタイムの更新を確認したりすることなく、どのインシデントに関連するのかを一目で確認し、できるだけ多くの詳細を提供することができます。

PD WebでリンクされたSF案件の可視化 インシデントが顧客に与える影響範囲や、問題によって影響を受ける顧客の数を気にしたことがありますか？ もう悩むことはありません。PD Web、モバイル、電子メールのいずれでも、PD for Customer Serviceはインシデントに関連するケースをリンクしてレポートします（逆もまた然り）。なぜでしょうか？カスタマーサービスエージェントは、受け取ったケースの数に基づいて、特定のインシデントの緊急性を正当化できるからです。また、インシデント対応では、障害に対してどれだけの顧客が不満を抱いているかを確認できます。結局のところ、顧客はデジタル資産の健全性を示す重要な信号なのです。 これらの新機能により、サポートチームとレスポンスチームの間のサイロを継続的に解消し、あらゆるインシデントに迅速かつ容易に対応するための方法を、カスタマーサービスチームに提供していきます。これにより、カスタマーサービスエージェントは、ケースを最初から最後まで自分で管理できるようになります。

PagerDuty Customer Service Opsについて詳しくはこちら。さらに、営業に連絡するか、14日間の無料トライアルに申し込むと、すぐに始められます。

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

PagerDutyは２年前にPagerDuty.org Fundを立ち上げ、タイムクリティカルヘルスの分野で資金調達し、より早く人々に届けることで命を救う手助けをするという使命を担いました。それ以来、世界はCOVID-19のパンデミックによる広範囲な影響と、人種的不公平に対する報いを受けました。このパンデミックの長期的な遺恨は、公衆衛生システムにおける構造的な不公平をさらに悪化させることです。これを受けて、PagerDutyは2021年、世界中の最も疎外されたコミュニティーへのワクチン配布に注力する団体のために100万ドルの資金、製品、技術サポートを調達しました。

私たちの世界、私たちが目指すもの

制度的差別と闘うために、私たちは健康格差に取り組む活動を、構造的人種差別の影響を受ける別の分野、すなわち気候変動と環境汚染の影響にも広げています。異常気象が私たちの日常生活や幸福に影響を及ぼすようになり、気候変動が私たちのコミュニティーの健康にもたらす害が明らかになってきました。これらの変化は私たち全員に影響を与えますが、最も被害を受けるのは、最も貧しい人々なのです。特に、パンデミックへの対応で見られた健康上の不公平は、人種、階級、性別による不平等が根強く、多くのグループが環境災害や気候変動の影響に対してより脆弱であることを映し出すものであります。有色人種、低所得者層、先住民族が、水質汚染や大気汚染、有害物質による被害を不当に受けていることを示す研究は増え続けています。レッドライン（訳注：経済面での人種差別）は50年以上前に禁止されましたが、その影響は今日も有色人種社会を苦しめています。歴史的にレッドラインのある地域は、レッドラインのない地域よりも気温が高く、木や緑地が少ないのです。さらに、これらの人々は、気候変動から最も深刻な被害を受ける可能性が高く、熱波、洪水、山火事、その他の異常気象の影響に備え、再起する能力が最も低いのです。

この不公平の中心にある根本的な原因である有色人種コミュニティーへの投資不足に取り組むためには、全ての人々、特に汚染と気候変動の影響を不当に、そして制度的に受けている人々の有意義な関与を中心とした環境正義のビジョンに焦点を当てる必要があります。この限られた機会に、私たちはより公平な未来を再構築しなければなりません。私たちは、環境危機の影響にレッドラインを引かない、社会的に公正なアプローチを必要としているのです。最も疎外された人々が環境災害や気候変動の影響、さらには新たな健康上の脅威から確実に保護されるようにするには、協力的かつ体系的なアプローチが必要です。

気候変動に関するフィランソロピーの分野を調査したところ、別の不公平があることが分かりました。気候変動に焦点を当てた資金提供者からの資金のうち、環境正義に取り組むBIPOC（訳注：黒人・先住民・有色人種）主導の団体に向けられたのはわずか1.3％でした。この不均衡から、Donors of Color NetworkはClimate Funders Justice Pledgeを作成し、全米最大の気候変動資金提供者に、より透明性を高め、気候変動資金の少なくとも30％をBIPOC主導の第一線のグループに展開することを公的に約束するよう求めました。

未来の世界的指導者への投資

公平性を高めるという目標のもと、私たちは全ての資金提供の取り組みにおいて、多様な指導者や有色人種のコミュニティーに力を与える組織への支援を意図的に行ってきました。PagerDuty.orgは、女性やBIPOCの指導者がいる組織への投資の歴史を踏まえ、環境と気候の正義に向けて活動する４つの組織に、合計25万ドルの無制限資金を投入します。これらの組織は全てBIPOCのエグゼクティブディレクターが率い、国内、地域、および国際的なコミュニティー主導の運動の一部を担っています。より公正な未来を擁護するためにオープンソーステクノロジーを使用している組織もあります。これらのパートナーは以下の通りです。

Earth Guardiansは世界中の環境、気候、社会正義の運動において力を発揮する指導者となるべく青少年を育成し、力を与えています。６大陸で数千人の若者が活動しており、Earth Guardiansは彼らの声とコミュニティーへの影響を増幅させるためのプラットフォーム、リソース、そしてつながりを持つ機会を提供しています。音楽、アート、文化を通じて、あるいは気候変動ストライキや集会を組織して、Earth Guardiansのユースリーダーは再生可能な未来を想像するよう、他の人々を鼓舞しているのです。

「組織は転換期を迎えました。1992年の設立以来、40歳以下のBIPOC女性が先導を務めるのは初めてのことです。PagerDuty.orgはEarth Guardianの転換期と活動を公的に支援してくださり、感謝しています。この寄付により、私たちはアート、ストーリーテリング、組織化、法的措置を使って力強い変化を生み出すために、若者のエンパワーメントを直接支援することができ、同時に私たちがグローバルコミュニティーとして直面している重要な問題に対するインパクトのある解決策を鼓舞していきます。」

-Catherine Mongella, Executive Director, Earth Guardians

Earth Hackのインクルージョンについてのビジョンは、世代間や多国間のつながりが生まれ、学生たちが環境活動の一形態としてハッカソンに参加するグローバルコミュニティーです。これまでのハッカソンでは、都市部のヒートアイランドなど不公平な問題の解決に取り組んできました。歴史的な差別的慣習であるレッドラインに起因する有色人種のコミュニティーに不釣り合いな影響を与える問題です。ハッカソンのイノベーション能力を活用し、オープンソースプロジェクトライブラリーは、何千人もの大学生が批判的思考に取り組み、潜在的な解決策を得るための出発点として役立っているのです。

「Earth Hacksは、PagerDuty.org Fundの寛大なご支援により、ハッカソンを環境活動の一形態として活用する私たちの活動を支援できることに感謝しています。この助成金により、例年よりも多くの学生を支援し、小さくても意味のある環境ソリューションの組み合わせを推進し、環境技術分野における正義に焦点を当てた文化の変化を促進し続けることができます。」

-Sanjana Paul, Co-Founder and Executive Director, Earth Hacks

OpenAQは、個人とコミュニティーをオープンデータでつなぎ、科学を発展させ、政策に影響を与え、大気汚染と戦う力を人々に与えることを使命とする非営利団体です。OpenAQ Platformは、世界最大のオープンソース大気質データプラットフォームであり、世界135カ国からの160億のデータポイントを集約・調和し、毎月1500万件のデータリクエストに対応しています。OpenAQ Platformは、よりきれいな空気のための世界的、地域的、ローカルなアクションを支える基盤として機能しています。また、多様なステークホルダーを集め、よりクリーンな空気のための公平なソリューションを触媒として、データ設計と行動計画を共同で開発しています。

「OpenAQは、PageDuty.orgの助成金を受けられることに感激しています。このパートナーシップによる支援は、きれいな空気を実現するためにデータへのアクセスがもはや障害とならない世界というOpenAQのビジョンをよりよく実現するために役立ちます。私たちは、大気質の低下に最も影響を受ける人々が大気質のデータにアクセスしやすくし、よりきれいな空気のための解決策をともに検討しようとオープンデータの力を利用する大気質の支持者を団結させることができるでしょう。」

– Chisato Fukuda Calvert, Interim Director, OpenAQ

The Solutions Project（TSP）は、全米の黒人、先住民、移民、女性、有色人種が主導する組織が生み出した気候正義の解決策に資金を提供し増幅する公的財団です。2021年、TSPは127の草の根団体に1000万ドルを助成し、助成対象に100万ドルのコミュニケーション能力開発を提供しました。これにより、石油生産の段階的廃止からパイプラインの阻止、風力タービンや電気自動車製造の開発、コミュニティーの太陽光発電や水システムの構築まで、目覚ましい成果を生み出しました。

「この運動は、多数の問題に同時に取り組む気候正義の解決策を現場で作り出している草の根組織とさらに協力するよう、フィランソロピーに求めているのです。TSPは、誰もが手頃な価格の住宅、環境に優しい良い仕事、資源への公平なアクセスを持つ世界を思い描いています。私たちがここに到達する唯一の方法は、最前線のコミュニティーと連帯して動くことです。PagerDutyのような業界のリーダーが、気候正義へのこの道を認識してくれることをうれしく思います。」

-Gloria Walton, CEO of The Solutions Project

COVID-19の大流行がもたらしたポジティブな結果のひとつは、資金提供パートナーに資金提供のスピードと柔軟性を高めるよう促したことです。PagerDuty.orgはこの点で確立された前例に倣い、私たちの助成金を使途不指定の資金として構成し、これらの組織が適切と考えるようにそのミッションを推進できるようにしています。また、PagerDutyの従業員、具体的には従業員リソースグループのリーダー、ソーシャルインパクトアンバサダーカウンシル、そして最も熱心な環境保護活動家たちが、私たちの選考プロセスに意見を述べ、私たちの決定に役立つ多くの多様な視点を提供してくれたことに感謝しています。

支援・奨励

パートナーの１団体であるEarth Guardiansが示しているように、若者主導の気候変動運動は、フィランソロピーにこの緊急事態に対応するよう働きかけています。パートナーから得た洞察と学習は、制度的差別に対処するアプローチを進化させるために、私たちの戦略に反映され続けます。私たちは、これらの優れた団体を支援できることを光栄に思うとともに、全ての人間と地球の健康を守るためのこの取り組みに参加される仲間が増えることを願っています。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

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

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

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

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

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

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

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

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

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

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

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

CollabOpsの実践

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

Rundeckアクションの仕組み

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

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

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

Round Robin Schedulingについてお聞きになったことや、自分のチームに合っているかどうか検討されたことがあるかもしれません。このオンコールスケジューリングの方法を考えるとき、Round Robin Schedulingがどう使われ、どんなチームに最適なのか理解することが大事です。さらに、避けたい落とし穴だけでなく、採用すべきベストプラクティスもあります。このブログでは、PagerDutyのRound Robin Schedulingについて知っておくべきこと、そしてどのように始めるべきかを紹介します。

Round Robin Schedulingの仕組みは？

Round Robin Schedulingは、チーム全体のオンコール責任を分散させる方法です。これにより、より柔軟なローテーションが可能になり、複数のレスポンダーが同じシフトにオンコールで対応することができるようになります。新しいインシデントを異なるユーザーに公平に割り当てることで、チームが燃え尽きるリスクをできるだけ少なくし、効率的にインシデントを解決できます。

多くの組織では、スプレッドシートを使い、たくさんの手間をかけてこのプロセスを始めています。ある人がインシデントに対応するたびに、マネージャーはスケジュールを移動し、別のインシデントが発生したら次の人の出番を知らせなければなりません。これでは、その場しのぎの対応になり、チームは常にすぐオンラインに移れることを期待されているような気がしてしまいます。Round Robin Schedulingは、それをサポートするツールがなければ、恩恵というより重荷になるかもしれません。そこで、PagerDutyの出番です。

PagerDutyのRound Robin Schedulingを使うと、あなたのチームは燃え尽きを減らすために、必要に応じて作業を分配しながら、同じサービス上で発生した複数のインシデントをシームレスに解決できるようになります。あなたがオンコール中であり、同時に発生した２つ以上のインシデントを担当すると想像してみてください。すぐに無理と思ってしまうのは目に見えています。Round Robinなら、複数のインシデントに必要な人数を投入し、お客様への影響を確実に軽減できます。

以下は、働き方の比較です。

しかし、Round Robin Schedulingは、あらゆるチームに適しているのでしょうか？必ずしもそうではありません。このメソッドが例外的にうまく機能するチームのタイプが２つあります。

Round Robin Schedulingで最も得をするのは誰？

オンコールの方法を作ったり、変更したりするのは難しいことです。ある特定のオンコールメソッドを使うには、チームの目標やインシデントボリュームを考慮に入れ、最適だという理由を基に決める必要があります。多くの場合、Round Robin Schedulingから一番恩恵を受けるチームがいくつかあります。

カスタマーサポートやヘルプデスクのチーム。 時間帯や週末、祝日をまたいで常に電話がかかってくるようなチームでは、１人のオンコール担当者では、殺到する電話に対応しきれない場合があります。むしろ、Round Robin Schedulingは、予定外のチームメイトにタグを付ける必要がなく、あらかじめ決められた人々がリクエストを処理し、チーム全体に均等に作業負荷を分散することができます。

中央ITチームまたはNOC。 カスタマーサポートやヘルプデスクと同様に、これらのチームは24時間体制で人員を配置し、大量のリクエストを受けることがよくあります。複数のサービスをサポートする中央のITチームやNOCでは、インシデントの量が１人のオンコールエンジニアの能力を簡単に越えてしまうことがあります。さまざまなインシデントに最初に対応するチームにとって、レスポンダーを増やせることは、適切な特定課題の専門家（SME）を迅速に投入することを可能にし、お客様への影響を軽減できます。

Round Robin Schedulingのコツとベストプラクティス

Round Robin Schedulingのコツをつかむには、少し時間がかかることがあります。任意のオンコール変更と同様にすぐには完璧にはできないでしょう。人々は、オーバーライドしたり拒否したりする権利を持っています。克服すべき課題があるでしょう。しかし、ここでは移行を容易にするために使えるヒントがいくつかあります。

毎週末、全員をオンコールにするのはやめる。** 毎週末や夕方にチーム全員を待機させるのは理にかなっているように思えるかもしれません。結局のところ、仕事をより多くの人で分担すれば、１人当たりの負担は当然軽くなります。しかし、これでは、常にオンコール状態であるかのように感じられてしまうかもしれません。それよりもオンコールのシフトを快適にこなすために必要な最低限の人数を考え、その人数でシフトを組むようにしましょう。他の人が息抜きできるような休憩時間を確保するのです。 チームメイトが休みを取る場合、その人たちが呼び出されないと分かっていてもローテーションから完全に外しておくこと。** 典型的なオンコールシフトがどのようなものかはご存じのはずです。あなたのチームが十分大きく、処理すべきインシデントの量も少ないと、ローテーションの最後にいる人が電話を受ける可能性は極めて低くなるかもしれません。それでも、休暇中の人はローテーションから外しておくことが重要です。仕事を離れている間、心からくつろぐことができるようにするだけの目的であっても。 動き回れ！** チームによっては、これは奇妙に映るかもしれませんが、オンコールのため、一日中デスクに座ってスクリーンを見ている必要はない、ということです。問題が発生したときに、その問題を解決するために利用できるようにすればよいのです。また、PagerDutyモバイルアプリを使えば、多くのインシデントを外出先で解決できます。 チームを訓練する。** 複数の人がオンコールで対応するからといって、新しいチームメイトへの教育を怠ってはいけません。ラウンドロビン型のオンコールローテーションでは、一貫した顧客体験を確保できるだけの、同じようなスキルセットと専門知識レベルを全員が持っている必要があります。毎週オンコールのレビューを行うことで、知識のギャップを明らかにし、チームメンバー間の情報共有を促すことができます。 チームと確認し合おう。** ラウンドロビンは燃え尽き症候群を減らすのに役立ちますが、万能薬や特効薬ではありません。特に、チームメンバーが複数のオンコールローテーションに参加していて、現在のローテーションに加えて他の問題にも取り組んでいる場合は、チーム内でチャットをして、誰も負担を感じていないことを確認し、必要に応じてローテーションを調整する必要があります。

あなたのチームでも試してみませんか？

Round Robin Schedulingは、通常、全ビジネスプランとデジタルオペレーションプランで利用可能です。現在ご利用中のお客様で、この機能へのアクセスを解除するためのアップグレードをご希望の場合は、PagerDutyアカウントチームまでご連絡ください。まだお客様でない方は、この機能を14日間無料でお試しいただけます。

Round Robin Schedulingの詳細については、こちらのサポートドキュメントをご覧いただくか、こちらのYouTubeショートムービーをご覧ください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

PagerDutyプラットフォームの新しいアップデートとエンハンスメントを新たに発表できてうれしいです。製品チームからの最近の更新は、オンコール管理、イベントインテリジェンス、およびモバイル製品、PagerDutyコミュニティー＆アドボカシーイベントが含まれています。新しい機能により、ユーザーや顧客はインシデントの迅速な解決、以下のようなことを行うことができます。

強力なEvent Intelligenceにより、システム全体のノイズを制御し、手動イベント処理の量を削減します。 Rundeckの最近のリリースでオートメーションのセキュリティーが向上しました。 オンコール管理機能の向上により、レスポンダーの燃え尽き症候群を軽減し、レスポンダーが常に重要なインシデントに迅速かつ効果的に対処できるようにします。 PagerDutyのモバイルアプリの最新アップデートにより、重要なコンテキストの表示と重要なインシデントレスポンス機能へのアクセスが可能になりました。 PagerDuty App for ServiceNowの製品デモと、2021年からのイベントインテリジェンスの機能をウェビナー＆イベントからご覧いただけます。 PagerDutyとRundeck、Laceworkを連携させる方法についてTwitch Stream上で仲間から学びましょう。

新機能のデザインパートナーとしての参加も歓迎します。また、数々のソリューションガイドを通じて、組織内のさまざまなチームがPagerDutyオペレーションクラウドをどのように受け入れ活用できるかを知っていただけることを願っています。

ソリューションガイド PagerDutyは、IT部門以外の部署でも利用できることをご存知でしょうか？　そうなのです！　マーケティング、営業、財務、人事などのチームが重要なビジネス機能を処理するのにPagerDutyが役立ちます。ソリューションガイドをチェックしてみてください。

Event Intelligence Event Intelligence（EI）は、企業がダウンタイムを削減し、顧客体験を実現するために役立つ、機械学習を活用したソリューションです。最新のEI機能は、ノイズを減らし、根本原因を突き止め、手動プロセスを自動化してインシデントの発生を減らし、迅速な解決を可能にする実用的なインサイトをチームに提供します。

Event Orchestration Event Orchestrationにより、チームはノイズを減らし、手動によるイベント処理を削減し、業務効率の向上と労力の軽減を図ることができます。Event Orchestrationのデシジョンエンジンは、カスタムロジックを作成し、イベントの条件に基づいて、適切なチームへのイベントのルーティングを大規模に強化、変更、制御することを可能にします。

ネストされたイベントルールを機械学習とターゲット自動化と組み合わせて、診断および修復アクション（システムヘルス統計情報の取得、自己修復の実装、導入の自動ロールバックとサーバーの再起動を含む）をトリガーします。

Event Orchestrationのデモをご覧ください。

オンコール管理

チームの健康、幸福、そして全体的なウェルビーイングは、全ての組織の成功の鍵です。私たちのオンコール管理機能は、組織の最も貴重な資産である人を守るために役立っています。

ラウンドロビンスケジューリング ラウンドロビンスケジューリングは、複数のチームメンバー間でオンコールシフトの責任を公平に分配することができます。この機能は、チーム内の異なるユーザーに新しいインシデントを自動的に割り当てることで、燃え尽きるリスクを抑えながら、可能な限り効率的にインシデントを解決できるようにするものです。

デモをご覧ください。 詳しくはナレッジベースで デモを見る ブログを読む：ラウンドロビンスケジューリングによるオンコール責任の均等分配とインシデント対応効率化

オートメーション Rundeck 3.4.7、3.4.8、3.4.9、および3.4.10リリース Rundeck EnterpriseとRundeck Communityの最新のRundeck機能と拡張をチェックしてください。

HashiCorp Vault Pluginは、より多くのログを記録し、パスワードが保存されている場所とは異なる名前空間への認証をサポートし、セキュリティーを強化。 Spring Securityのバージョンを5.1.11から5.2へ変更し、セキュリティーを強化。 Rundeck Enterprise と Rundeck Community の両方で log4j を 2.17.0に更新し、最近のlog4jの脆弱性に対処。 Rundeck Enterpriseのパスワードリセット機能で、アカウント上で直接パスワードをリセットする代わりに、リセットリンク付きのメールを送信することでローカルユーザーのパスワードをリセットできるようにした。

これらのアップデート、およびその他のコア製品のアップデートとバグ修正の詳細については、3.4.7, 3.4.8, 3.4.9, 3.4.10 のリリースノートでご確認ください。

インシデント対応 モバイルインシデント詳細リフレッシュ 新しく改良されたモバイルのインシデント詳細画面では、インシデント対応プロセス中のお気に入りの機能全てに、一カ所から簡単にアクセスできるようになりました。新しいカルーセルで、プレーの実行、優先度やメモの追加、ステータスアップデートの投稿など、さまざまなことが可能です。

詳しくはナレッジベースで最新のモバイルリリースノートをご覧ください。

製品廃止のお知らせ 2022年3月31日** - ウェブフックV2は、現在一般公開されているウェブフックV3に置き換わります。

ウェビナー＆イベント 以下のウェビナーやイベントに参加し、PagerDutyの最近の製品アップデートと、それがどのようにお客様に利益をもたらすかについて、より詳しく学んでください。

PagerDutyでノイズを減らし、イベントルーティングを管理する方法** - PagerDutyのシニアプロダクトマネージャーであるFrank Emeryが、PagerDuty Event Orchestrationで管理しきれないレベルのノイズと複雑さに対処する方法を説明します。 オンデマンドでウェビナーを見る Event Intelligenceの最新情報 - 2021年まとめ** - Vivian Chan、Frank Emery、Vera Chanによる製品デモとQ&Aで、Event Intelligenceの最新のアップデートをオンデマンドで入手できます。 オンデマンドでウェビナーを見る Event Intelligence101 with PagerDuty University** - Hannah Lodiseが、Event Intelligence機能がいかにチームのシステムノイズを減らし、問題のトラブルシューティングを迅速に行い、手作業を排除して早期解決を可能にするかを詳細に説明します。 オンデマンドでウェビナーを見る ServiceNowとPagerDutyの統合によるメジャーインシデント管理のレスポンスタイム改善** - ServiceNow統合の製品デモとLaura ChassagneとVera ChanによるQ&Aで、CMDBデータの活用、可視性とコンテキストの向上、インシデントレスポンス、さらに自動診断と自己回復によるインシデント解決時間の短縮について詳しく学びましょう。 オンデマンドでウェビナーを見る PagerDuty Pulse Q3** - 最新の製品デモをQ3 PagerDuty Pulseでプレーリストにまとめてオンデマンドでご覧いただけます。今すぐQ3 PagerDuty Pulseをご覧ください。

PagerDuty Community Twitch Stream 私たちのTwitchチャンネル、PagerDuty Twitch StreamとPagerDuty Community Twitch Streamに参加して、私たちのエバンジェリストが率いる最新のストリームをご覧ください。

登録すると、ライブのお知らせや過去の録音を見ることができます。 見逃した回がありますか？最近のTwitch配信やYouTube動画をご覧ください。 2022年1月14日 Scott McAllister & Mandi Walls - PD Garage (Custom Change Transformer for Change Events) 2021年11月16日 Mandi Walls & Rob Jahn (Dynatrace) - Partner Integration – Dynatrace with PagerDuty and Rundeck 2021年11月11日 Nov 11, 2021 with Mandi Walls & Jeff Fry (Lacework) – Integrate PagerDuty & Lacework

もし、チームでこれらの機能拡張を活用できそうだったら、ぜひアカウントマネージャーに連絡して、14日間の無料トライアルに申し込んでください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

共著者：PagerDutyデータサイエンティストVI、Chris Bonnell氏

EIアーキテクチャーシリーズの第４回目、「Intelligent Alert Grouping（インテリジェントアラートグルーピング）」についてご紹介します。前回は、インシデントのマージを使用してIntelligent Alert Grouping をトレーニングする方法（こちら）と、デフォルト マッチングを改善するためにアラートのタイトルを設定する方法について説明しました。今回は、サービスデザインがIntelligent Alert GroupingやPagerDutyアプリの使用感にどのような影響を与えるかについて説明します。

サービスについて

サービスを設計したり、再設計したりする前に、組織で機能するサービスの定義を持つことが重要です。この定義は、理解できるほどは具体的である必要がありますが、複数のチームがサービスとは何かを抽象的には同じように理解できるように広いものである必要があります。PagerDutyでは、次のような定義を使っています。

サービスとは、チームによって完全に所有される、価値を提供する機能の個別部分である。

担当チームは、サービスを構築し維持するチームであり、あらゆるインシデントに対応することも含まれるため、把握しておくことが重要です。サービスとオーナーシップについての概説は、サービスの定義に関する完全なサービスオーナーシップ運用ガイドを参照してください。

サービスやその所有者について考えるだけでなく、サービス名にも気を配る必要があります。Service Directoryに目を通すと、追加の制度的知識がなくても、それぞれのサービスが何であるか簡単に理解できるようになるはずです。簡単に言うと、「Payment Service」という名前のサービスがあったり、あらゆるトランザクションサービスがギリシャ神話の神々にちなんで名付けられているという社内文書を知っているか参照して、どのギリシャ神が支払いを処理するサービスに相当するかを調べるかの違いです。この点については、Full Service Ownership Ops Guideの「Naming Services」のセクションで詳しく説明しています。

PagerDutyアプリでは、サービスはビジネスサービスとは区別されます。ここまでは、全てサービスに関連する話です。また、ビジネスサービスとの混同を防ぐため、弊社のドキュメントでは技術サービスと表記している場合があります。ビジネスサービスは、技術サービスや他のビジネスサービスの集合体であり、通常、ビジネスロジックおよび／またはステークホルダーに従います。Intelligent Alert Groupingは技術サービスのみを利用し、ビジネスサービスは利用しないため、この記事でサービスと書いた場合、技術サービスのみを指します。

粒度

サービスをどう分けるか、そのバランスを考えてもすぐには分かりませんし、万能の解決策もありません。基本的には、粒度の高いものと低いもののバランスを取り、時には置き換えすることになります。例えば、PagerDutyのアプリケーションでは、１つの監視ツールで、その構成機能を全部別のサービスに分解しています。一方、より広範で粒度の低いサービスの使い方としては、iOSとAndroidの開発を別々のチームが担当している場合でも、あらゆるモバイルアプリケーションを１つのサービスとして提供することが挙げられます。後者の例では、サービスの構成方法について単一の推奨事項が存在しない理由は、組織にモバイルチームが１つしかないとか、モバイルチームがないとか、異なる基準で分割されたモバイルチームがあるためだとよく分かります。

では、どうすればよいのでしょうか。私たちは、サービス定義のナビゲートに役立ついくつかのアドバイスを抽き出せます。まず始めに、オーナーシップについて説明します。PagerDutyアプリケーションでサービスを定義する主な理由の１つは、インシデント対応のためです。つまり、サービスの問題に対処できるのは誰かを知ることは、サービスを所有しているのは誰かを知ることなので、組織内で誰がサービスを所有しているかによって、PagerDutyでサービスをどのように定義するかを決めることができます。これは、完全なサービスオーナーシップモデルではないものの、望ましいエスカレーションパスが分かっているサービス構造が既にある場合、その知識を活用できる点で重要です。この場合、Intelligent Alert Groupingがインシデントをグループ化すると、サービスが希望するエスカレーションパスに関連付けられるだけにしても、このコンテキストではそれが重要であり、達成する最終結果になるのです。

また、現在のプロジェクトを見直して、どれが事実上機能単位になっているかを確認し、それらをPagerDutyで１サービスとして定義する必要があります。こうすることで、エスカレーションパスが同じプロジェクトは正しくグループ化される一方で、エスカレーションパスの関係で複数のプロジェクトが単一のサービスとして定義され、可視性が損なわれるというシナリオを防ぐことができるはずです。もう少し踏み込んで、常にインシデントが同時に発生している２つ以上のサービスがある場合、それらを１つのサービスに集約する必要があるかもしれません。具体的な例として、メトリクス、ハートビート、ログなどの個別のコンポーネントを持つモニタリングマイクロサービスがあるとします。これらがそれぞれPagerDutyサービスを持っている場合、ほとんどの場合、インシデントがこれら全サービスに同時にまたがることになるので、モニタリングマイクロサービス自体として１つのサービスにまとめる必要があります。一方、同じ人が働いているからと言って、別々のプロジェクトが１つのサービスとして定義されている場合、そのサービスは十分に粒度が揃っていない可能性があります。このシナリオでは、PagerDutyアプリに関する限り、サービス内のエンティティーは全て１つの「もの」であるため、どのエンティティーが他のエンティティーよりも注意を払う必要があるかを判断するのが難しくなります。

次に何をするべきか

既存のサービス、あるいはこれから作成されるであろうサービスを見て、それらをチェックすることから始めましょう。

エスカレーションパス 名称 機能単位

そして、PagerDutyアプリケーションでサービスを定義する際の指針として使用します。Intelligent Alert Groupingは、関連するサービスの下にアラートをグループ化することで、そこからの作業を行います。サービスをゼロから設計したり、サービスの定義を見直したりする場合は、「フルサービス オーナーシップ運用ガイド」で、レスポンスの命名とオーナーシップに関するベストプラクティスを参照し、「（技術）サービス」と「ビジネスサービス」に関するドキュメントもご覧ください。次回は、このシリーズの最終回で、これまで取り上げた内容を全て再録する予定です。ei-architecture-seriesタグを使うと、このシリーズの記事をご覧いただけます。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。