Category
DevOps

2022年9月28日  (更新日:2022年11月22日)

新着情報 モバイル、PagerDuty® Process AutomationソフトウェアとPagerDuty® Runbook Automation、その他の更新情報

PagerDuty Operation Cloudの新しいアップデートと機能強化を発表することができ、とても嬉しく思います。製品チームによる最近の開発とアプリのアップデートには、Incident Responce、PagerDuty® Process Automation、Community & Advocacy Eventsのアップデートが含まれています。私たちは、お客様がクラウド運用を最適化し、他のチームにエスカレーションされる問題を減らすために、あらゆる場所を自動化できるよう、引き続き支援します。今すぐ使い始めて学んでください。

PagerDutyモバイルアプリのインシデントレスポンスに関するアップデートにより、外出先からMaintenance Windowsを操作してをメンテナンスウィンドウを作成、更新、削除できるようになりました。 PagerDuty® Process AutomationとRundeck Community(https://www.pagerduty.com/blog/whats-new-product-update-2022-09-29/#Process-Automation)のアップデートを最新の[4.6.0リリースで実現。 V1/V2 Webhooks EOL (End-Of-Life), Event Rulesの廃止とEvent Orchestrationへの移行の勧めなどの製品に関する告知。 今後のイベントに登録し、最近のポッドキャストやTwitchストリームを閲覧し、コミュニティチームや製品チームのメンバーと一緒に新製品やソフトウェア業界のリーディングプラクティスを学ぶことができます。

PagerDutyモバイルアプリ

New! PagerDutyモバイルアプリでメンテナンスウィンドウを作成・管理

PagerDutyモバイルアプリのメンテナンスウィンドウ機能は一般的に利用可能です(2022年9月15日現在)。メンテナンスウィンドウは、レスポンダーがメンテナンスモードの間、そのすべての統合を含むサービスを一時的に無効化するのに役立ちます。サービスがメンテナンス・ウィンドウに入ると、すべてのサービス統合が事実上「オフ」になり、新しいインシデントが発生しないようになります。現在、デスクやオフィスから離れているユーザーは、PagerDutyモバイルアプリを通じてメンテナンスウィンドウを作成、更新、削除する柔軟性を持っています。

(上記特集:アクティブメンテナンス Windows on Mobile)

(上記特集 モバイルでのメンテナンスウィンドウ メンテナンスウィンドウの作成とスケジューリング)

モバイルメンテナンスウィンドウの詳細はナレッジベース記事でご確認ください iOSまたはAndroidからアップデートをダウンロードし、お試しください。 ブログを読む

PagerDuty® Process Automatio

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

このリリースでは、PagerDuty® Process Automation(旧Rundeck Enterprise)、PagerDuty® Runbook Automation、Rundeck Communityの新機能や強化された機能をご確認ください。

AWS Athenaの新しいクエリジョブステッププラグインです。この新しいAWS Athenaジョブステッププラグインは、ユーザーがAWS Athenaを使用してS3内のデータに対してSQLクエリをジョブとして実行できるようにします。

Amazon ECS ノードソースプラグインの機能強化。** ユーザーは、特定のリージョン内の複数のクラスタと統合できるようになり、より大規模な環境でのECSタスクの管理が容易になりました。

セキュリティおよびコンプライアンスに関する重要なアップデートが多数含まれています。** およびバグフィックス

詳しくはこちら

このリリースのTwitchストリームレビューを見る 2022年9月6日、Ogre Salmon Bullhorn Release (4.6.0)に関するリリースノート全文を読む

製品廃止のお知らせ

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

V1/V2 Webhooks EOL

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

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

v3 Webhooks への移行の詳細と手順については、こちらの移行ガイドをご参照ください。

その他のご質問は、[email protected] までご連絡ください。

重要な日程

V2 Webhooks -** V2 Webhook 拡張は、2022年10月にサポートが終了します。

必要なパーミッション

管理者ま* たはアカウント所有者* は、アカウント全体を移行できます。 チームマネージャー** は、割り当てられたチームのウェブフックのみを移行できます。

ご不明な点がございましたら、PagerDutyの担当者またはサポートチーム([email protected])までご連絡ください。

イベントルールの廃止とEvent Orchestrationへの移行

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

マイグレーションについて詳しくはナレッジベースをご覧ください

  • イベントオーケストレーションの詳細 担当者に連絡する

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

ウェビナー&イベント

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

ウェビナー

クラウド対応。PagerDutyとAWSでクラウドでのモダナイゼーションを加速させる

PagerDutyの業界をリードするAWSインテグレーションは、AWSとPagerDutyを使用している企業がインシデントレスポンスを自動化し、クラウド導入を加速させ、ダウンタイムと顧客への影響を最小限に抑えるためにどのように構築されているかをInga WeizmanとMandy Wallsが説明します。また、PagerDutyがどのように組織を支援するかを説明します。

サービスオーナーシップにより、ダウンタイムと顧客への影響を軽減し、チームが継続的な改善とイノベーションを推進できるようにします。 エンタープライズグレードのAWS統合のセットでオペレーションを近代化し、最適化する PagerDutyのRunbook AutomationとAWSプラグインの最新セット、および自動診断で稼働を容易にするプレビルドジョブでインシデント対応を自動化します。

今すぐ登録

PagerDutyのAWS向け自動診断機能でインシデント対応の効率化を実現

PagerDutyのGreg Chase、Sebastian Joseph、John Kieferが、PagerDuty Automated Diagnostics for AWSがどのようにAWS環境における問題の迅速なトリアージを支援するのかについて説明します。ご覧ください。

ファーストレスポンダーがシニアエンジニアのようにAWSの問題を診断する方法 PagerDutyで利用可能なAWSサービス用の組み込み診断の利用方法 シニアエンジニアがファーストレスポンダー向けに新しい診断を作成する方法 上記をすべて実行するためのデモ

今すぐ登録

カスタマーサービス業務。Zendeskによるプロアクティブアプローチ

PagerDuty for Customer Service OperationsとZendeskの組み合わせにより、カスタマーサービスチームがどのように問題を迅速に解決し、顧客に影響を与えるインシデントに先手を打つことができるかを、Kat GainesとCarrie Lacinaが説明します。詳細はこちらをご覧ください。

機械学習を活用して、問題を知る前に、次に何をすべきかという情報を顧客に伝え、VIP顧客向けに差別化された対応を提供する方法 ZendeskでPagerDuty Automation Actionsを使用して、顧客の問題を検証し、自動化によって重要な情報を取得し、ケースを迅速に診断して解決する利点について PagerDutyとZendeskのお客様が、ビジネスに影響を与える前に問題を解決することで、ロイヤルティを高め、CSATを向上させ、顧客SLAを超過する方法

今すぐ登録

10月に開催されるイベントのお申し込みはこちらから

PagerDuty Community Twitch Stream

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

登録すると、ライブのお知らせや過去の録音を見ることができます。 私たちの放送を見逃しましたか?今後予定されている、または最近のTwitchストリーム(PagerDuty GarageとTerraform Time)、またはYouTubeビデオをご覧ください。 PagerDutyプロセスオートメーションとRundeckオープンソースリリースノート4.6.0。Mandi Walls、Forrest Evans、Jake Cohen と共に (2022年9月13日) PagerDutyとArize。Arize AIのMandi Walls氏とJack Zhu氏によるML Observabilityのための統合(2022年8月11日開催) Twitchのストリームスケジュールを見て、9月に毎週開催されるストリームに参加してください。

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

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

続きを読む
DevOps
2022年9月28日  (更新日:2022年11月22日)

PagerDutyモバイルアプリでメンテナンスウィンドウを作成・管理するMaintenace Windowsを提供

緊急かつ重要なデジタルインシデントにリアルタイムで対応するためには、オンコール対応者がどこからでもアクションを起こせるようにする必要があります。

しかし、オンコール対応者がアラートに圧倒されると、本当のアラートと偽のアラートの違いを見分けることができないため、ただ「無視」してしまうことがよくあります。例えば、メンテナンスまたはアップグレードによるサービスのダウンがあった場合、このイベントは複数のインシデントを引き起こす可能性があり、レスポンダーは実際のインシデントに関係しない偽のアラートを受け取る可能性があることを意味します。しかし、あるサービスがクリティカルなインシデントを引き起こし、レスポンダーが問題に飛び込み、迅速に問題を解決する必要がある場合もあります。

オンコールチームは、より直感的で柔軟なソリューションが必要です。モバイルデバイスでサービスを無効にしたり、インシデントアラートを一時停止したりすることができるため、中断することなくインシデント解決という重要なことに集中できます。

私たちは、効果的なインシデント管理は、中断を最小限に抑えながら、チームがより効率的に仕事をするのに役立つと信じています。そのため、PagerDutyモバイルアプリを通じて”Maintenance Widows”の一般提供を発表できることをうれしく思っています。

Maintaance Windows を使うと、レスポンダーは、メンテナンスモードの間、すべての統合を含むサービスを一時的に無効にすることができます。サービスがメンテナンスウィンドウにあるとき、サービスの全統合は事実上「スイッチオフ」になり、新しいインシデントが発生しないようにします。

メンテナンスウィンドウの作成、更新、削除がどこからでも簡単に行えます

モバイルアプリでメンテナンスウィンドウを作成するには、いくつかの簡単なステップを踏むだけです。

ハンバーガーメニューから「サービス一覧」を選び、ご希望のサービスを選択します。 設定をタップし、"create maintenance menu "をタップします。 このメンテナンスが行われる理由を説明するために、Descriptionを入力します。 メンテナンスの開始日と終了日(および時間)をスケジュールします。 メンテナンスウィンドウが終了すると、サービスはメンテナンスモードを終了し、新しいインシデントを再びトリガーすることができます。

設定から "end maintenance window"をタップすると、既存のメンテナンスウィンドウを削除できます。

複数のサービスのメンテナンスウィンドウを表示

PagerDutyのモバイルアプリでの操作では、一度につのサービスに対してメンテナンスウィンドウを作成できます。複数のサービスをカバーするメンテナンスウィンドウを作成したいユーザーは、ウェブアプリケーションから行えます。 複数のサービスをカバーするメンテナンスウィンドウのオプションの更新や削除は、モバイルアプリから行えます。

PagerDuty Mobileに追加されたこの最新機能は、オンコールチームが時間やワークライフバランスを犠牲にすることなく、インシデントを管理し対応することを可能にします。私たちは、チームがより良いサービスを提供し続けるために信頼できる情報を提供することで、PagerDutyのモバイル体験を継続して改善しています。

PagerDuty MobileとMaintenance Windowsについては、ナレッジベースの記事で詳しく説明されています。または、以下のQRコードからダウンロードし、お試しください。

iOS

Android

PagerDutyのインシデントレスポンスとモバイルアプリとの連携についてもっと知りたいですか?14日間の無料トライアルに参加し、PagerDutyがいかにチームを迅速かつ効率的に強化し、オペレーションクラウド全体のイノベーションを推進できるかを体験してください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

続きを読む
DevOps
2022年8月31日  (更新日:2022年11月15日)

新着情報 PagerDuty® Process Automation Software & PagerDuty® Runbook Automation, Integrations, and More!

PagerDutyオペレーションクラウドの新しいアップデートと機能強化を発表することに興奮しています。製品チームによる最近の開発およびアプリのアップデートには、PagerDuty®プロセスオートメーション、パートナー統合およびアプリエコシステム、コミュニティ&アドボカシーイベントのアップデートが含まれています。私たちは、お客様がクラウド運用を最適化し、他のチームにエスカレーションされる問題の量を減らすために、あらゆる場所を自動化できるよう支援し続けています。今すぐ始めましょう。

最近リリースされたPagerDuty + Sumo Logic Job Step PluginとPagerDuty + AWS ECS Node Executor Pluginの詳細、およびPagerDuty® Process AutomationとRundeck Communityのアップグレード、バグ修正、パッケージ更新を最新の4.5.0 Releaseでキャッチアップすることができます。 PagerDuty App for Jira Cloudのサイドバーの更新、PagerDuty App for Jira Data Center Recertification、PagerDuty App for BMC Helix/Remedy を管理するKTSLへのサポート移行を含む、最新のパートナー統合とアプリエコシステムの更新をお楽しみ下さい。 イベントルールの廃止、イベントオーケストレーションへの移行、V1/V2 Webhooksの廃止など、製品廃止情報を常に把握してください。 今後のイベントに登録し、最近のポッドキャストやTwitchストリームを閲覧し、コミュニティチームや製品チームのメンバーと一緒に新製品やソフトウェア業界の最先端のプラクティスを学べます。

PagerDuty® Process Automation

PagerDuty® Process AutomationソフトウェアとPagerDuty® Runbook Automation 4.5.0

最新のPagerDuty® Process Automation Version 4.5.0には、以下の内容が含まれています。

Sumo Logic Job Step Pluginをリリースしました。Sumo Logicインスタンスと連携することで、インシデント診断のためのログ取得などの運用タスクを自動化できるようになりました。 AWS ECS Node Executor Puglin ユーザーは、単一のジョブステップまたはコマンドタブから、複数のECSコンテナにコマンドを実行できるようになりました。これにより、インシデント発生時にコンテナを再展開する前にタイムクリティカルな診断を取得するなどのタスクを容易に実行できるようになりました。

ハイライトをご覧いただき、プラグインなどの追加アップデートや修正についてご確認ください。

アップグレード、修正、パッケージの更新は、Rundeckオープンソース製品にもあります。それらの詳細や、GitHub で公開されているプルリクエストを見ることができます。

2022年8月10日のNessie Orchid Tower Release (4.5.0)についての詳細はこちら。

パートナーインテグレーションとアプリエコシステム

PagerDuty App for Jira Jira Data Center:マーケットプレイスアプリを1年間正式に再認定

既にPagerDutyをJira Data Centerと統合し、重要なサービスリクエストに取り組み、Jira Serverの課題とPagerDutyのインシデント間を双方向同期してインシデント解決を加速している方に朗報です。私たちはまた、Jira Data Center用のPagerDutyアプリを1年間正式に再認定し、AtlassianマーケットプレイスにおけるData Center Approved Statusを維持しました。

アプリの詳細はknowledge baseでご確認ください。

PagerDutyアプリ for Jira Cloud。Jira CloudのサイドバーにPagerDutyを表示する新オプションを今年9月に提供開始

Jira Cloudの新規顧客には、全Jira プロジェクトでPagerDutyがデフォルトでサイドバーに表示されません。 既存のJira Cloudプロジェクト管理者は、プロジェクトごとに Jiraサイドバー上の PagerDuty を非表示または表示する機能があります。

(上図:Jira CloudでPagerDutyのサイドバーがdisabledにされています)

(上図:PagerDutyのサイドバーをJira Cloudでenabledにできます)

ご不明な点がございましたら、PagerDutyアカウントチームまたはカスタマーサポート([email protected])までご連絡ください。

BMC Helix用PagerDutyアプリ/Remedy:パートナーKTSL社への所有権移管について

PagerDutyは、BMC HelixとRemedyのインテグレーションの所有権を、サービスマネジメントと統合の専門家であるBMC Eliteパートナー、KTSLに移管しました。今後、KTSLがこのインテグレーションをビルドし、サポートします。

製品廃止のお知らせ

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

Event Rulesの廃止とEvent Orchestrationへの移行

PagerDuty は、2023年1月31日にEvent RulesをEOL (End-of-Life)=停止することを決定しました。私たちは、お客様のために最も堅牢で信頼性の高いイベントドリブンのエンリッチメントとオートメーション体験の構築にリソースを捧げることを確実にするために、この決定を下しました。Event Orchestrationは、Event Rulesの次の進化形として年初にリリースされ、現在では、ユーザーがルールの量を圧縮し、ノイズ除去を改善し、よく理解されている手作業をより効果的に自動化するための最良の方法となっています。

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

(上図:PagerDuty Event Orchestration)

マイグレーションについて詳しくはknowledge baseをご覧ください Event Orchestrationの詳細 アカウントマネージャーへのお問い合わせ

V1/V2 Webhooks

現在、PagerDuty 環境で V1/V2 webhook 拡張を使用している場合、機能を維持するために V3 webhook サブスクリプションに移行する必要があります。

移行ガイドに従ってください。

重要な日程

V1 Webhooks** - V1 Webhook 拡張は、2021 年 11 月 13 日からサポート対象外(新機能やバグフィックスがない)となり、2022 年 10 月に機能停止となります。 V2 Webhooks** - V2 Webhook 拡張は、2022年10月にサポートが終了し、2023年3月に動作しなくなります。

必要なパーミッション

Admins* またはAccount Owners* は、アカウント全体を移行することができます。 Team Manager** は、割り当てられたチームのウェブフックのみを移行できます。

ウェブフックとは何ですか? ウェブフック(webhook)を使うと、PagerDutyアカウントで重要なイベントが発生したとき、例えばインシデントがトリガー、エスカレート、または解決したときに、HTTPコールバックを受け取ることができます。イベントに関する詳細は、Slackや独自のカスタムPagerDuty ウェブフックプロセッサーなど、指定したURLに送信されます。

ご質問がある場合は、PagerDutyの担当者またはサポートチーム([email protected])にご連絡ください。

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

続きを読む
DevOps
2022年8月10日  (更新日:2022年11月8日)

5つの簡単なステップで根本を探る(原因分析)

PagerDutyでインシデントを割り当てられたとき、最初にすべきことは何でしょうか?すぐに「受任!(Acknowledge)」と思った方は間違っていませんが、その後は、できるだけ早く、痛みを伴わずに問題を解決することが大切です。解決への第一歩は、最初にインシデントの原因を調査し、簡単に修正策を講じられるようにすることです。 PagerDutyのプラットフォームでは、Root Cause Analysis(根本原因分析)*は、レスポンダーであるあなたにできるだけ多くのコンテキストと実用的なインテリジェンスを提供することを目的とした一連の機能を指します。過去に発生したインシデントや関連するインシデント、インシデントの発生頻度に関する情報を表示することで、レスポンダーは根本原因を特定するために必要な状況認識を素早く得ることができ、迅速なトリアージと、そして最終的には早期解決につながるツールを手にすることができます。また、過去のデータに基づき、発生源と思われる場所がハイライト表示され、状況を把握しやすくなります。 ここでは、インシデントの詳細ページで、潜在的な根本原因を調査するのに役立つ5つの場所を紹介します。

  1. Outlier Incident

インシデントを最初に開くとき、[Outlier Incident]分類ラベルを探します。このラベルはインシデント名の直下にあり、"Frequent", "Rare", "Anomaly "のいずれかの分類ラベルが表示されます。この分類ラベルに基づいて、このインシデントが以前に発生したことがあるかどうか、また過去の経験に基づいてどう対応すべきかをすぐに判断することができます。ラベルにカーソルを合わせると、それぞれの定義が表示されます。

  1. Past Incidents

サービス上でインシデントが発生した頻度を決定したら、ページのさらに下にある[Past Incidents]タブに移動します。ヒートマップが表示され、このオープンインシデントのような過去のインシデントが過去6カ月間にいつ発生したかが示されます。色のパターンを探す(色が濃いほどインシデントが集中している)か、ヒートマップの色にカーソルを合わせると、関連するインシデントの詳細が表示されます。その下には、オープンインシデントのような過去のインシデント上位5件(もしあれば)の詳細と、それらがいつ発生したか、誰が最後にインシデントを変更したかについての情報が表示されます。注:その人は、インシデントに際して何をしたか尋ねたり、それに関するメモを見たい場合、素晴らしいリソースになります。過去のインシデントの詳細ページを開くには、ハイパーリンクされたタイトルをクリックします。

  1. Related Incidents

もう一つの簡単な情報源は、[Related Incidents]タブです。ここでは、同じサービス上の類似のインシデントしか表示されない過去のインシデントとは異なり、全サービスからあなたの問題に関連する可能性のある進行中のインシデントがあるかどうかを確認できます。ビジネス全体のインシデントの範囲(これは孤立したものか、より大きな問題の一部か)を理解することは、影響を理解し、問題を解決するために協力する必要がある人を迅速に特定するのに役立ちます。

  1. Probable Origins

インシデントの詳細ページにある[Probable Origins]ウィジェットを使用して、トリアージ作業を素早く始められます。このウィジェットは、インシデントが現在のオープンインシデントの類似イベントの直前に発生したか、または直後に発生したかなどの履歴データに基づいて、発生源の可能性のパーセンテージを計算します。

  1. Change Correlation

最後に、インシデントの原因となった可能性のあるインフラやコードの変更に気付いている場合、解決を大幅に加速できます。インシデントの詳細ページの[Recent Changes]に表示される[Change Correlation]は、時刻、関連サービス、PagerDutyの機械学習に基づいて、インシデントに最も関連する最近の変更イベントを3つ表示します。最近の変更イベントには、プラットフォームがイベントを表面化させた理由が表示されるため、潜在的な原因を簡単に絞り込めます。

ナレッジチェック! 正しいでしょうか、間違いでしょうか?: [Past Incident]タブには同じサービスのResolved Incidentsが表示され、[Related Incidents]には他のサービスのOpen Incidentsだけが表示されます(ページ下部の回答を参照)。

いかがでしたでしょうか?これら5つの、コンテキストをすばやく取得し、トリアージ作業を開始するために調べられる場所を忘れないでください。

インシデントを迅速に解決し、ダウンタイムをさらに短縮するには、この一連のRoot Cause Analysys機能をNoise ReductionとEvent Orchestrationの機能と組み合わせるとよいでしょう。再確認が必要な場合は、PagerDuty UniversityのEvent Intelligenceコースを受講し、Event Intelligence認定を取得して、ハードワークではなく、スマートな作業ができることを証明してください。

次のステップのためのリソース:

Event Intelligenceコースは、PagerDuty University eLearning Portalでご覧いただけます。

Noise Reduction Event Orchestration Root Cause Analysis

Event Intelligence Certification Exam(認定試験)の情報は、このページの "Specialty Product Certification" でご覧いただけます。この新シリーズの発売を記念して、30日間、試験への登録を無料にしますので、今すぐご登録ください。

*脚注:このカテゴリーの機能を「Root Cause Analysis」と呼んでいますが、PagerDutyは根本原因を予測したり特定したりするものではありません。むしろ、PagerDutyの機能は、インシデントに関連するコンテキストを作成し、より迅速な解決を促進するためのものです。また、業界では、真の「root cause」が1つであることを示すような用語ではなく、「probable」cause または「 proximate」causeという用語を採用する方向に変化していることも注目に値します。

ナレッジチェックの回答:誤りです。過去のインシデントは同じサービス上で解決された過去のインシデントのみを表示するという記述は正しいのですが、関連インシデントは全サービス(現在のインシデントが起きているサービスを含む)上で未解決の、または最近解決した他のアクティブなインシデントを調べ、現在のインシデントに関連しているインシデントがあるかどうかを確認します。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

続きを読む
DevOps
2022年8月9日  (更新日:2022年11月8日)

PagerDuty、2022年のGigaOm RadarでAIOpsソリューションのリーダーとしてデビュー

毎年、Radarリポートには驚きに満ち溢れています。私たちと共に、多大な利益を得ている何千ものお客様にとっては驚きではないでしょうが、PagerDutyは2022年のGigaOm Radar for AIOps Solutionsでリーダーに選ばれたことを大変喜んでいます。

GigaOmは、Radarのベンダーを評価するために広範な基準を使用しています。リポートによると 「今年は、既存のツールを置き換える必要があるAIOpsソリューションと、大きな混乱なしにITツールボックスに追加できるソリューションを区別しています」とのこと。これは、PagerDutyがLeaderに位置付けられ、Tool DisplacementでOutstanding と評価された鍵の一つです。

Time to ValueとTCOは、かねてよりPagerdutyのビジネスバリューの特徴です。お客様はPagerDutyを信頼して、既存のシステムを取り替えることなく、迅速にその価値を最大化することができます。 私たちのSaaSプラットフォームは、シンプルなセットアップ、素早い統合、使いやすいイベントルーティングとエンリッチメントを提供し、これらは全て「導入の容易さ」の優れたスコアにとって重要な要素となっています。

650以上の統合機能を持つPagerDutyは、データ消費、システム統合、クラウド監視の分野で「Exceptional」と評価されました。このような幅広い機能により、実務担当者は事実上カスタマイズの必要なく、迅速な価値創造を実現することができます。UI、Terraform、APIプロバイダーにより、専門家はモニタリング、CI/CD、DevOps、セキュリティー、BizOpsなどの全てのデータソースを活用し、新しいチームメンバーでも迅速に問題を解決するために必要なåコンテキストを作成することができます。 当社のEvent Orchestrationは、シンプルかつ強力なルーティング、エンリッチメント、問題への自動応答を可能にします。膨大で複雑なルールベースからシンプルなノードベースのグラフルーティングに移行することで、SREとDevOpsチームは、コンテキストを作成し、診断を提供し、必要に応じて自動的に問題を解決するためにイベントを使用する方法を正確にコントロールすることができます。シンプルなグラフィカルインターフェイスは、簡単な実験的方法を提供し、基盤となる Terraformプロバイダーはセルフサービス機能を可能にし、中心チームから負担を取り除くことができます。この総合的なセルフサービス機能は、「Manageability」で「Outstanding」と評価されました。

GigaOm は、AIOps に対する自動化優先のアプローチの優位性を認識しました。Rundeck と Catalytic の買収により、当社のプラットフォームは、ビルトインのAutomation Actionsと柔軟なワークフローという形で、プラットフォーム全体に包括的な自動化の統合を提供することができるようになりました。人とマシンのワークロードのバランスをとることは、生産性を維持し、燃え尽き症候群を防ぐために重要です。インシデント解決の最初のレスポンダーとして自動化を活用することで、労力を軽減し、解決までの時間を短縮することができます。レスポンダーが必要ない場合、一般的な問題の兆候を特定し、自動修正により機械の速さで処理することができます。自動修復はごく一部のよく知られた修正に対応できますが、多くの場合、自動化はインシデント対応と調査の中心であるレスポンダーを補強する、第二の手の役割を果たします。 Radarはまだ1年目ですが、ここ数年のEvent Intelligenceの成功に基づき、お客様のために機能を拡張し、新たなビジネス成果を提供することに全力を注いでいます。今年は、お客様のために200億件以上のイベントを処理する予定です。SaaSプラットフォームとしての長年のデータを活用し、お客様がどのようにノイズを減らし、問題を解決しているかを理解することで、機械学習、自動化、分析を拡大し、チームは生産の維持とよりよいソリューションの提供に集中できるようになりました。

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

続きを読む
DevOps
2022年10月24日  (更新日:2022年10月28日)

NOCプロセスの二日酔いになる3つの可能性

NOC(ネットワークオペレーションセンター)のプロセスは、何十年もの間、定石とされてきました。しかし、これらのプロセスの一部は、そろそろ進化する時期に来ています。デジタルトランスフォーメーションとクラウド時代の到来により、DevOpsが台頭し、それに伴いサービスオーナーシップも台頭してきました。サービスオーナーシップとは、開発者が自分たちが提供するソフトウェアをライフサイクルのあらゆる段階でサポートする責任を負うことを意味します。これにより、開発チームは顧客やビジネス、そして提供する価値により近い存在となります。

また、従来のNOCのインシデント処理方法からの脱却も必要です。しかし、組織がサービスオーナーシップに移行するにつれ、古いNOCのプロセスがいくつか残っています。ここでは、3つの一般的なNOCプロセスの残存物と、それらを交換または更新する方法について説明します。

プロセスの二日酔い。L1レスポンダーが問題を解決できない

かつてNOCは、技術的な問題の司令塔であった。NOCは脳のように機能し、関連する付属機器に信号を送ります。ネットワークに問題がある?ネットワークへのルート。セキュリティの問題?セキュリティーの問題?NOCの中心的な役割は、問題を解決するために適切なSMEを関与させることでした。これは、誰が何を担当しているかを把握するために、スプレッドシート(時には物理的な連絡帳も!)を掘り起こすことを意味します。

すべてがオンプレミスで対面式だった時代には、これは理にかなっていました。サービスも少なく、インシデントも部署ごとにきちんと分けることができました。もしデータベースに問題があれば、データベースのオンコールレスポンダーを呼び出すことができます。その担当者(おそらくオフィスにいるか、直接対応できるほど近くにいる人)は、データセンターに行き、調べることができました。

しかし、リモートワークやクラウドの時代には、世界中に散らばる数十、数百のチームによって数百、数千のサービスが管理されており、名簿方式はもはや用済みになっています。どのチームがどのサービスを担当しているのか、正確なスプレッドシートを維持することは不可能に近いのです。また、組織が変われば、記録はすぐに古くなります。サービスはチーム間で移動することができます。チーム間の移動や、退職・入社に伴い、チームも変化する。L1レスポンダーは、効率的かつタイムリーに適切な担当者を特定するために、大変な努力をしなければならないのです。

組織は、適切な担当者を見つけるためのこうした手作業のステップを排除し、あらゆる問題に飛び込んで対応できる中小企業に直接インシデントを転送する方法を必要としているのです。これは、さまざまな方法で実現できます。一部の組織では、DevOpsサービス所有権モデルが正しい道筋となります。コードを書く人は、インシデント発生時にサービスに対応し、修正するよう割り当てられます。アラートは、サービスをサポートする開発チームのオンコール担当者に直接送られ、そこからSMEが対応します。

他の組織では、L1レスポンダーが防御の第一線として機能した後に、分散したオンカルのチームにエスカレーションしてサービスを提供するというハイブリッドアプローチが理にかなっている場合もあります。L1レスポンダーは、問題を他のチームに接続するルーティングセンターであってはなりません。その代わりに、インシデントを自ら解決する権限を与える必要があります。L1レスポンダーに、トラブルシューティングとインシデントの選択的解決の両方の能力を与えることで、より効果的にL1レスポンダーをセットアップすることができます。自動化とランブックのようなリソースにアクセスすることで、L1レスポンダーは診断と修復のプロセスを加速させることができます。L1 レスポンダーに自動化を導入することで、組織は不必要なエスカレーションを回避し、L1 が問題を迅速に解決できるようになります。

プロセスの二日酔い。重大インシデントが発生しない、または発生が遅すぎる

時は金なり」という言葉を聞いたことがあります。そして、NOCがインシデントに確実に対応するための主要な方法であったとき、NOCはさらなる責任を負っていました。NOCは、リソースが適切に管理されていることを確認する必要がありました。つまり、問題に対応するために不必要な人員を配置しないことだ。NOCは、重大なインシデントを早く呼び出したり、微細な問題で人々を中断させたりすると、しばしば非難を浴びます。このような混乱は、中小企業を技術革新のための仕事から遠ざけてしまうことになります。そのため、NOCの対応者は、より大きな問題が起きていることが明らかな場合にのみ、重大インシデントを呼び出すことが極めて重要だったのです。

しかし、今は「時は金なり」ではなく、「稼働時間は金なり」なのです。大規模な事故が発生した場合のコストは、追加で人員を投入する場合のコストよりも大きくなります。例えば、オンラインショップでショッピングカートの機能がダウンしたとします。お客様が商品をカートに入れられない分、何十万ドルもの損失を被ることになります。さらに、ここ数年で、顧客の期待は高まっています。お客様は、アプリ、ツール、プラットフォーム、ストリーミングサービスなどが中断することなく機能することを期待しています。そして、そうでない場合は、顧客の信頼を損なうことになります。実際、PWCによると、3人に1人の顧客が、気に入っていたブランドで1度でも悪い経験をしたら、そのブランドとの取引をやめると回答しています。

組織は、顧客への影響を軽減するために、重大なインシデントをより早く連絡する必要があります。確かに、これは、不必要に誰かを起こすことを意味するかもしれません。しかし、サービスのオーナーシップがあれば、その可能性ははるかに低くなります。サービスを担当する中小企業は、L1レスポンダーよりも、いつ重大インシデントを呼び出すべきかをよりよく理解しています。そのため、誤報が少なくなります。

プロセスの二日酔い。出入りの激しい戦争部屋

NOCは、しばしば大規模なインシデントのコミュニケーションハブとして機能します。これは、問題解決に取り組む対応者が作業を継続するのに役立ちます。多くの企業がすべてを(そしてすべての人を)オンプレミスで管理していた時代には、ウォー・ルームがありました。人々はそこに集まり、NOCコーディネーターは皆に最新情報を提供しました。現在では、チームやシステムが分散しているため、物理的なウォー・ルームは過去のものとなっています。多くの企業は、ビデオ会議ブリッジやチャットチャンネルを備えた仮想のウォー・ルームの代わりに、インシデント発生中もオープンにしています。

他のステークホルダーは、このウォー・ルームを物理的な部屋と同じように扱い、好きなように立ち寄りたいかもしれません。しかし、この仮想世界では、これらの利害関係者がインシデント対応者に質問をすることになります。これでは解決は遅れます。出入りの激しいバーチャルワールームを持つ企業では、ミスコミュニケーションやフラストレーションがより多く発生する可能性があります。対応者は中断されることにフラストレーションを感じ、利害関係者はコミュニケーションの欠如にフラストレーションを感じるのです。

これを軽減する方法の1つは、ウォー・ルームを参加者以外には閉鎖することです。もし誰かがインシデント対応チームの一員でないなら、対応チームの仮想ウォー・ルームにアクセスする必要はないでしょう。その代わりに必要なのは、内部の連絡役です。これは、インシデント対応チームから指名されたコミュニケーターである。

社内コミュニケーション・リエゾンは、インシデント情報を集約し、関連するステークホルダーに伝達します。これを容易にするために、コミュニケーション担当者は、ステータスアップデートの通知テンプレートを使用することができます。このテンプレートは、特定の対象者に向けたコミュニケーションの作り方を規定するものです。これにより、利害関係者は意思決定に必要なすべての情報を受け取ることができます。また、対応担当者は、最新情報を共有するために、目の前の事故の作業を中断する必要はありません。

二日酔いは楽しくないが、必ず終わる

NOCは、多くの組織でインシデントを管理するために試行錯誤されている方法です。しかし、このデジタルトランスフォーメーションの時代に移行すると、NOCの方法は時代遅れになります。シームレスなコミュニケーションと迅速な対応は、お客様の信頼を維持するための鍵です。今後、チームはSMEを直ちに巻き込み、重大なインシデントを早急に連絡することになるでしょう。また、インシデント発生中は主要なステークホルダーとコミュニケーションをとり、境界線を設定することになるでしょう。

そして多くの場合、チームはこの移行をサポートするためのデジタルオペレーションプラットフォームを必要としています。PagerDutyは、重大インシデントのベストプラクティスを組織に導入し、重要インシデントを迅速に解決し、将来の発生を防止することを可能にします。14日間無料でお試しいただけます。

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

続きを読む
DevOps
2022年9月22日  (更新日:2022年10月18日)     |    DevOps

PagerDutyモバイルアプリでメンテナンスウィンドウを作成・管理

緊急かつ重要なデジタルインシデントにリアルタイムで対応するためには、オンコール対応者がどこからでもアクションを起こせるようにする必要があります。

しかし、オンコール対応者がアラートに圧倒されると、本当のアラートと偽のアラートの違いを見分けることができないため、ただ「無視」してしまうことがよくあります。例えば、メンテナンスまたはアップグレードによるサービスのダウンがあった場合、このイベントは複数のインシデントを引き起こす可能性があり、レスポンダーは実際のインシデントに関係しない偽のアラートを受け取る可能性があることを意味します。しかし、あるサービスがクリティカルなインシデントを引き起こし、レスポンダーが問題に飛び込み、迅速に問題を解決する必要がある場合もあります。

オンコールチームは、より直感的で柔軟なソリューションが必要です。モバイルデバイスでサービスを無効にしたり、インシデントアラートを一時停止したりすることができるため、中断することなくインシデント解決という重要なことに集中できます。

私たちは、効果的なインシデント管理は、中断を最小限に抑えながら、チームがより効率的に仕事をするのに役立つと信じています。そのため、PagerDutyモバイルアプリを通じてMaintenance Widows の一般提供を発表できることを嬉しく思っています。

メンテナンス ウィンド ウを使用すると、レスポンダーは、メンテナンス モードの間、すべての統合を含むサービスを一時的に無効にすることができます。サービスがメンテナンス・ウィンドウにあるとき、サービスのすべての統合は事実上「スイッチオフ」になり、新しいインシデントが発生しないようにします。

メンテナンスウィンドウの作成、更新、削除がどこからでも簡単に行えます。

モバイルアプリでメンテナンスウィンドウを作成するには、いくつかの簡単なステップを踏むだけです。

ハンバーガーメニューから「サービス一覧」を選び、ご希望のサービスを選択します。 設定をタップし、"メンテナンスメニューの作成 "をタップします。 このメンテナンスが行われる理由を説明するために、説明を入力します。 メンテナンスの開始日と終了日(および時間)をスケジュールします。 メンテナンスウィンドウが終了すると、サービスはメンテナンスモードを終了し、新しいインシデントを再びトリガーすることができます。

設定から "メンテナンスウィンドウの終了 "をタップすると、既存のメンテナンスウィンドウを削除することができます。

複数のサービスのメンテナンス窓口。

PagerDutyのモバイル体験では、一度に1つのサービスに対してメンテナンスウィンドウを作成することができます。複数のサービスをカバーするメンテナンスウィンドウを作成したいユーザーは、ウェブアプリケーションから行うことができます。 複数のサービスをカバーするメンテナンスウィンドウのオプションの更新や削除は、モバイルアプリから行うことができます。

PagerDuty Mobileに追加されたこの最新機能は、オンコールチームが時間やワークライフバランスを犠牲にすることなく、インシデントを管理し対応することを可能にします。我々は、チームがより良いサービスを提供し続けるために信頼できる情報を提供することで、PagerDutyモバイル体験を向上させ続けています。

PagerDuty MobileとMaintenance Windowsについては、ナレッジベースの記事で詳しく説明されています。または、以下のQRコードからダウンロードし、お試しください。

iOS

Android

PagerDutyのインシデントレスポンスとモバイルアプリとの連携についてもっと知りたいですか?14日間の無料トライアルに参加し、PagerDutyがいかにチームを迅速かつ効率的に強化し、オペレーションクラウド全体のイノベーションを推進できるかを体験してください。

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

2022年8月2日  (更新日:2022年10月13日)     |    DevOps

Slack on Webhooks V3の専用インシデントチャンネルの改善 - アーリーアクセス

本日、Dedicated Incident Slack Channelの改良版のアーリーアクセスを開始することができました。この改良は以下の通りです。

全てのインシデントの詳細、履歴、およびアップデートを表示する 全てのインシデントアクションを実行する 全レスポンダーをチャンネルに追加する ズームコンファレンス専用ブリッジの掲載または作成

この機能を利用するためには、Slack on WebHooks V3にアップグレードし、PagerDutyサポートにアーリーアクセスをリクエストする必要があります。 正しいバージョンでアーリーアクセスができたら、専用のインシデントチャンネルを作成する方法が2つあります。

  1. Slackにて

Slackのインシデント通知から、「View | Create Channel」を使用して、デフォルトのネーミングスキーマで新しいインシデント専用チャンネルを作成します。チャンネルがすでに存在する場合は、チャンネルのハッシュタグが付いたメッセージが投稿されます。

  1. PagerDuty Web 経由

Incident Pageで、「Set the Channel」でチャンネルを設定する。アーリーアクセス中は、「BETA」タグが表示されます。

その後、ユーザーは既存のチャンネルを選択するか、新しいSlackチャンネルを作成することができます。

新しいチャネルを作成する場合、ユーザーはデフォルトの名前を受け入れるか、新しい名前を割り当てることができます。チャンネルは公開にも非公開にも設定できます。

注:PagerDutyアカウントに複数のSlackワークスペースが接続されている場合、ユーザーはチャンネル接続に必要なワークスペースを選択することができます。

作成すると、PagerDutyのウェブのUIとSlackではこのように表示されます。

この新機能を活用していただくことを期待するとともに、ご意見をお待ちしています。

次はどうする?

この機能は、Slack on Webhooks V3をご利用の全てのお客様に対して、来月には公開する予定です。

また、チャンネル作成の効率化・自動化により、この機能の充実を図っています。

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

2022年7月12日  (更新日:2022年10月13日)     |    DevOps

これまで以上に強力に。PagerDutyのモバイルアプリを刷新し、インシデント対応のさらなる向上を目指す

2020年は、私たちの働き方に革命をもたらしました。多くの人が一夜にして、フルタイムのオフィスワークから100%リモートワークへと移行しました。そして今、再びオフィスでの仕事が視野に入ってきたため、企業はフレキシブルな働き方を継続する方法を考えています。しかし、これには課題が増え、この働き方に合ったツールが必要とされています。

PagerDutyのモバイルアプリケーションは、App StoreやGoogle Playで星4.8の評価を得ており、高い認知度を誇っています。私たちは、適切な人にすぐに連絡することがいかに重要かを理解しています。だからこそ、レスポンダーがいつでもどこでも重要な仕事を解決できるように、iOSとAndroidに多大な投資を行ってきました。

このブログ記事では、最も必要な情報を見つけるための新しいナビゲーションインターフェース、過去および現在のインシデントを通じたインシデントインテリジェンスの向上、自動診断の起動と修正アクションを実行するための自動化の活用など、最もエキサイティングな改善点をいくつかご紹介します。

必要な情報を簡単に見つけられる

レスポンダーは、自分がいつオンコールになるのか、どのようなサービスのためにオンコールになるのかを知る必要があります。万が一、呼び出しを受けた場合、自分が担当する技術サービスがどのように機能しているかを確認できることが極めて重要です。そして最も重要なことは、これらの情報をモバイルアプリから一目で確認できることです。複数の画面を参照したり、アプリの奥深くに埋もれた情報を探したりする必要はありません。

新しいPagerDutyモバイルホーム画面エクスペリエンスでは、レスポンダーが必要とする最も重要な情報が容易に利用可能です。このデザイン変更により、オープンインシデント、オンコールシフト、影響を受けるテクニカルサービスを中心に表示し、アプリ内のナビゲーションに必要なタップ数を減らすことができます。

デザイン変更されたホーム画面は、現在、早期アクセス可能です。試してみたい方は、この早期アクセスフォームに必要事項を記入し、「新しいモバイルホーム体験」の選択をすると、案内が送られてきます。

フレキシブルに働くということは、最も重要な瞬間に、クリティカルインシデントの状況を自由に把握できることを意味します。インシデントが発生したら、できるだけ早く対応し、影響を軽減するための最善の方法を決定する必要があります。

その方法の1つが、新しいモバイルインシデント詳細画面です。この画面では、視覚的に分かりやすく、最も重要な機能全てにアクセスできるため、インシデント対応に迅速に取り組むことができます。インシデントで作業している他のレスポンダーのメモ、変更イベント、過去のインシデント、最新のアラートなど、インシデントに関する最も重要な情報をすぐに利用することができます。

また、更新版のモバイルインシデント詳細画面にある新しいカルーセルでは、プレーの実行、優先度やメモの追加、ステータスアップデートの投稿などを行うことができます。

過去または現在におけるクリティカルインシデントのコンテキストを獲得する

インシデントが発生したとき、最大のハードルの1つは、「以前にもあったか」という質問に答えることです。もしあれば、以前に動作したプレーを実行したり、自動化シーケンスを実行することで簡単に解決できるかもしれません。しかし、そのような過去の状況を見つけることはしばしば困難であり、それは誰にも許されない無駄な時間です。

PagerDutyモバイルアプリのPast Incidents(過去のインシデント)機能では、現在アクティブなインシデントと同じサービス上で発生した、類似したメタデータを持つインシデントが表示されます。この追加コンテキストにより、正確なトリアージが容易になり、解決までの時間が短縮されます。例えば、自分やチームの誰かが過去に同様のインシデントに巻き込まれたことがあるかどうかを確認し、詳細を調べてどのような改善策が取られたかを知ることができます。 Change Events(変更イベント)。システム内の変更は、しばしばインシデントの影の犯人です。特に、多くの組織が1日に何十回、何百回も新しいコードを出荷している場合、どの変更がインシデントを引き起こしたかを正確に特定するのは難しいため、見過ごされがちです。しかし、「Gartner社の推定によると、全てのパフォーマンスインシデントの約85%は追跡可能」です。変更イベントにより、お客様の環境に影響を与える変更を確認し、潜在的な根本原因を特定することができます。変更イベントは、モバイルアプリの2つのエリア(新しいモバイルインシデントの詳細画面と、サービスの詳細画面)で簡単に確認できます。目的のインシデントをタップして変更イベントにスクロールするか、サービスディレクトリーに移動してサービスを選択し、最大2つの変更イベントを表示できます。表示されるイベントの詳細には、日時、概要、サービス、タイプ、リンク、ソースが含まれます。 インシデント対応におけるもう1つの重要な情報は、問題の影響範囲を理解することです。この情報を得るための1つの方法は、Service Dependencies(サービス依存関係)を理解することです。大規模で顧客向けのビジネスサービスが、技術的なサービスインシデントによって問題が発生している場合、問題の範囲をよりよく理解するために、より速く、より文脈的なインテリジェンスで対応する必要があります。モバイルアプリのサービス依存関係画面では、どのサービスが影響を受けるかを表示して、範囲をよりよく理解することができます。サービス依存関係は、サービスディレクトリーの各サービスのプロファイル内に表示されます。

自動化を活用した迅速な対応

テクノロジー環境がより複雑になるにつれ、人々の時間と認知資源を節約することがこれまで以上に重要になっています。これは、人間ではなく、機械が最初の防衛線として機能することを意味します。

反復的な手作業やよく理解されている事象を自動化することで、対応者の不必要な労力を軽減し、本業に集中できるようにし、最も必要とされている事象にのみ注意を向けるようにできます。これを実現する1つの方法が、指先のタップで実行できる自動化です。

PagerDuty Automation Actionsは、PagerDutyモバイルで一般的に利用できるようになり、いつでもどこからでも自動診断と修復アクションを実行できるようになりました。繰り返し行われる診断と修復のステップを自動化することで、手動で行っていた作業を代替し、生産性を向上させることができます。スクリプトを実行するだけでなく、過去に実行したスクリプトや出力レポートをモバイルアプリから直接表示することができます。これらはリアルタイムで更新されるため、見落としがありません。

PagerDutyモバイルアプリケーションに追加されたこれらの最新機能は、時間、品質、顧客体験を犠牲にすることなく、レスポンダーが思い通りに作業できるよう支援します。フレキシブルな働き方は今後も続きます。PagerDutyの強力なモバイルアプリケーションは、あなたがそれを最大限に活用できるよう支援することを約束します。PagerDutyのモバイルアプリケーションをまだお試しでない方は、今がチャンスです。QRコードを使って、どちらかをダウンロードしてください。

iOS

Android

重要:モバイル体験の安全性を確保するために

PagerDutyモバイルに多くの新しい素晴らしい機能が追加されました。モバイルアプリが革新的で安全であり続け、ユーザー体験を向上させるために、新しい最小システム要件を導入します。2022年6月27日より、PagerDutyモバイルアプリの将来のバージョンでは、Android 9.0かiOS 14.0以降が必要となります。モバイルアプリのアップデートを継続的に受信するために、お使いのデバイスが最新に保たれていることをご確認ください。

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

2022年1月31日  (更新日:2022年9月14日)     |    DevOps

最新情報:Event Intelligence、オンコール管理、オートメーション、モバイルなど

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

2022年2月24日  (更新日:2022年9月12日)     |    DevOps

アクショナブルインテリジェンスに「アクション」を入れる

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

AIOpsとは何か?

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

オプションその1:アプリケーション監視

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

オプションその2:イベント管理

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

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

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

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

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

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

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

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

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

2022年3月30日  (更新日:2022年9月9日)     |    DevOps

最新情報:オンコール管理、インシデント対応、Event Intelligence、プロセス自動化など

PagerDutyのデジタルオペレーションプラットフォームの新しいアップデートと機能拡張を発表できてうれしいです。製品チームからの最近の更新は、オンコール管理、インシデント対応、プロセス自動化、PagerDutyコミュニティー&アドボカシーイベントが含まれます。新しい機能により、ユーザーや顧客はインシデントの迅速な解決や以下のようなことを行うことができます。

既存のオンコール管理スケジューリング機能のビジュアルを改善しました。 アーリーアクセスプログラムに参加して、最新の自動インシデント対応機能をお試しください。 PagerDuty® Process Automationのリブランディング、PagerDuty® Runbook AutomationのGAリリース、PagerDuty® Process Automation On-Prem 4.0のリリースについて詳しく説明します。 CollabOps統合内で直接PagerDuty® Automationアクションを実行できるようになります。 Event Intelligenceと機械学習で不要なノイズを削減します。 最新のパートナーエコシステムの発表についてお読みください。 コミュニティーチームと製品チームのメンバーが新製品やソフトウェア業界のリーディングプラクティスを紹介しています。今後のイベントへの登録や、最近のポッドキャストやTwitchストリームをどうぞ。

オンコール管理 スケジュール一覧のUI刷新

スケジュール一覧ページのUIが新しくなります。この新しいビジュアルにより、必要な情報を簡単かつ迅速に見つけることができ、より柔軟な対応が可能になります。その他の変更点は以下の通りです。

検索機能の強化 全スケジュールとチームスケジュールの切り替え 詳細度に合わせた情報の折りたたみと拡大 時間帯の表示により容易にスケジュール比較 オンコール対応者をシフト時間と共に効率的に表示 アカウントへのアーリーアクセス展開が進行中です。

インシデント対応

ステータスアップデートの通知テンプレート

ステータスアップデートの通知テンプレートがアーリーアクセス可能になりました。この機能により、インシデント対応中の社内コミュニケーションに必要なコンテンツとコンテキストを追加できます。これらの新しい柔軟なテンプレートにより、チームはコミュニケーションにロゴを追加したり、会社の標準に従ってテキストをフォーマットしたりすることができます。このアーリーアクセスプログラムへの参加をご希望の方は、こちらのフォームにご記入ください。

サービスパフォーマンスレポート

PagerDuty Labs Insightsから新しいサービスパフォーマンスレポートが利用できるようになりました。このレポートでは、さまざまなサービスが時間とともにどのようにインシデントの影響を受けているか、マクロトレンドと具体的な詳細について掘り下げることができます。サービスごとのインシデントを時系列で表示する折れ線グラフや、指定した日付範囲に基づく指標を表示するサービス一覧表をご活用ください。このレポートは、今後数カ月間にアップデート展開される4つのレポートの第1弾で、新しいインタラクティブな可視化、直感的なドリルダウン機能、より多くのフィルターオプションなどのUI改良が施されています。今後ともご期待ください。

詳しくはこちら

プロセス自動化

PagerDuty® Process Automationは、お客様がビジネスの全てを自動化し、一貫性を高め、解決時間を短縮できるよう支援します。お客様は、ビジネスシステム全体のITおよび業務手続きを自動化する権限を与えられます。自動化されたプロセスは、指定されたスケジュールに従って実行され、発生したイベントによって自動的に起動し、ステークホルダーはボタンをクリックするだけで安全に実行することができます。

PagerDuty® Process Automationの3つの最新製品に触れる前に、PagerDutyの自動化製品ラインの公式リブランディングについての詳細もご覧ください。Rundeck®やPagerDuty® Process Automation、そして各製品の詳細については、こちらをご覧ください。

PagerDuty® Automation Actions

PagerDuty® Automation Actionsは、PagerDutyのお客様が、インシデントの影響を受けたサービスに対して、ボタンをクリックするだけで、サービスの自動診断と修復を実行できるようにするアドオンです。

PagerDuty® Runbook Automation

これまで「Rundeck Cloud」として発表していた当社のランブック自動化クラウドサービスは、「PagerDuty® Runbook Automation」として、一般提供を開始しました。これは、自動化されたITワークフローを組織内のより多くの人に安全に委ねることで、企業のクラウド運用を加速させるためのSaaS型サービスです。

PagerDuty® Runbook Automationの概要をご覧ください。 PagerDuty® Runbook Automationを使用して、定期的なタスクを自動化する方法をご紹介します。 PagerDuty® Runbook Automationの使用例と利点について、ブログで詳しくご紹介しています。

PagerDuty® Process Automation On-Prem Version 4.0

これまで「Rundeck Enterprise」として知られていた、プロセス自動化の幅広いユースケースをサポートするセルフマネージドソフトウェアは、「PagerDuty® Process Automation On-Prem」という名称に変更されました。

最新の4.0では、以下のような内容が盛り込まれています。

Process Runner。Process Runner(Enterprise Runnerとして発表)は、HTTPS経由でクラスターのエンドポイントにコールバックしてタスクリストを取得するため、ゾーン間のSSHトンネルが不要になります。ファイアウォールの背後に配置され、ノードに安全に接続し、ネットワークゾーン内で自動化タスクを実行するため、最新のゼロトラストセキュリティーモデルに適合しています。 強化されたセキュリティー機能。User Class Management(ユーザークラス管理)、Enhanced Webhook Security(強化されたウェブフックセキュリティー)、User Manager Password Complexity and Password Reset by Email(ユーザーマネージャーのパスワードの複雑性とメールによるパスワードリセット)、Failed Login Rate Limiting(ログイン失敗率の制限)などの機能により、自動化ソリューションに強化されたセキュリティーを提供します。 プラグインの拡張。新しい拡張プラグインは次の通りです。AWS Systems Manager、Azure Active Directory Single SignOn、PagerDuty User Management Job Steps、およびThycotic Key Storage Pluginです。 Enterprise更新とCore Product更新の詳細はこちら 詳しくはリリースノートをご覧ください。

Process RunnerとPagerDuty® Process Automationを使って、多くの顧客のシングルテナントを管理する方法をご覧ください。 詳しくはリリースノートをご覧ください。

Automation + CollabOps

Automated ActionsとSlack用PagerDutyアプリ

Automation ActionsがPagerDuty CollabOpsと統合され、レスポンダーがSlackから直接自動診断と修復を実行できるようになりました。レスポンダーは、インシデントのコンテキストで実行可能な自動化されたアクションを表示し、起動し、自動化されたジョブからの実行状況と出力を確認することができます。このように、レスポンダーはコンテキストを変更することなく、通常業務で使用しているUIで作業を継続することができます。

ナレッジベースへ ブログを読む

Event Intelligence

インシデント通知の自動停止

2月28日より提供されているAuto-Pause Incident Notifications(インシデント通知の自動停止)は、機械学習を応用して、従来から自動解決していた一過性のアラートを検出し、一時停止することができます。ボタンをクリックするだけで、不要なノイズを除去することができます。さらに、APIを活用することで、特定のサービスに対してどれだけの一過性アラートが発生しているかという基本的な統計情報を把握することができます。

詳しくはこちら

パートナーエコシステム

AWS 金融サービスコンピテンシーパートナー

PagerDutyはAWS 金融サービスコンピテンシーパートナープログラムに認定されました。このコンピテンシーにより、PagerDutyは金融サービス組織にとって信頼できるクラウドプロバイダーとしてAWSのウェブサイトに掲載されています。このコンピテンシーは、PagerDutyとAWSがともに、より多くの金融サービス組織がクラウドスケールをフル活用できるよう支援できることを示します。自動化、DevOps、Service Ownershipプロセス、コミュニケーションの合理化を通じて、デジタル運用管理をレベルアップしていきます。

詳しくはこちら

製品廃止のお知らせ

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

Impact Metrics - 2022年2月をもって、Impact Metricsの機能としてのサンセットが完了しました。

V1ウェブフック

サポート終了日 2021年11月13日** V1ウェブフックのサポートを終了しました。この日以降、V1ウェブフックの機能リクエストやバグ修正の受付は行っておりません。 終息日 2022年10月** V1ウェブフックの使用終了日が2022年3月から2022年10月に延期され、現在一般提供されているV3ウェブフックに置き換わります。この日付以降、お客様はV1ウェブフックを使用したり、新規に作成したりすることができなくなります。さらに、V1ウェブフックを使用しているアプリのインテグレーションは機能しなくなるため、開発者は早急にV3ウェブフックを使用するようにアプリを更新することをお勧めします。ただし、V1ウェブフックをベースに構築されたSlack V1は既に非推奨となり、ご利用いただけなくなります。詳しくは、こちらのサポート記事をご覧ください。

V2ウェブフック

サポート終了日 2022年10月** V2ウェブフックのサポートは終了し、2022年10月以降、V2ウェブフックに関する機能リクエストやバグ修正の受付は終了します。 終息日 2023年3月** 2023年3月以降、お客様は新しいV2ウェブフックを作成したり、使用したりすることができなくなります。さらに、V2ウェブフックを使用しているアプリのインテグレーションは機能しなくなるため、開発者はできるだけ早くV3ウェブフックを使用するようにアプリを更新することをお勧めします。ただし、V2ウェブフックをベースに構築されているSlack V2インテグレーションは、2023年1月までの期間限定で利用可能です。Slack V2 Next Generation(V3ウェブフックをベースに構築)をお使いのお客様には影響ありません。 V3ウェブフックへの移行手順の詳細については、こちらのサポート記事をご参照ください。

ウェビナー&イベント

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

クラウドと大規模化するITプロセスの自動化を実現する新製品をリリース** PagerDutyの最新ランブック自動化クラウドサービス、異種環境間のITプロセスを自動化する新機能、そしてRundeck by PagerDutyの将来についてご紹介します。 オンデマンドでウェビナーを見る インシデントレスポンス(AIR)の自動化。手動から自動化への道のり** AIRとは何か、AIRが解決する問題とは何か、機械がどのように人間の認知的負担を軽減するのか、手動から予防への道のりはどのようなものか、そしてPagerDuty AIRのパワーを紹介する10分間のデモをお楽しみください。オンデマンドでウェビナーを見る PagerDutyとSalesforceで顧客とカスタマーサービスチームをインシデント対応の中心に** PagerDutyのデベロッパーアドボケイトであるKat GainesとSalesforceのプロダクトマネジメントシニアディレクターであるNoopur Bakshiから学びましょう。また、PagerDutyとSalesforceがどのように重要なカスタマーサービスチームが顧客対応をしているか、顧客フィードバックをレスポンス時間の改善に使うメリット、そして顧客フィードバック、カスタマーサービス組織、バックエンドエンジニアリングチーム間のコミュニケーションとコラボレーションの壁を取り払い、顧客に影響のある混乱を解決しているかをご紹介します。ウェビナーはオンデマンドでご覧いただけます。

今後開催されるイベントのお申し込みはこちら

PagerDuty Community Twitch Stream

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

登録すると、ライブのお知らせや過去の録音を見ることができます。 放送を見逃しましたか?最近のTwitch配信やYouTube動画をご覧ください。 2022年2月10日 Mandi Walls、Frank Emeryと共に - イベントルールをネストしたイベントオーケストレーションに隠された数学と楽しさ 2021年12月15日 Mandi WallsとJason Flintと - 施設と危機対応のためのPagerDuty

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

2022年3月7日  (更新日:2022年9月9日)     |    DevOps

DevOps活動に女性の参加を呼びかける

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

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

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

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

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

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

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

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

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

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

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

2022年1月13日  (更新日:2022年9月9日)     |    DevOps

2022年に組織のデジタル革新を加速させる3つの方法

クラウドや関連技術への支出が急増した2年間を経て、2022年は企業のITおよびデジタルリーダーにとって正念場となります。テクノロジーへの投資は、大規模なハイブリッド勤務への急速な移行を促進し、ニューノーマルのデジタルファーストモデルを採用するビジネスを支援しました。しかし、新しい働き方を支えるための単なる投資だけでなく、リーダーは組織が革新を続けることを保証する必要があります。

これは非常に重要なことです。マッキンゼーの調査によると、リーマンショック後でもイノベーションを重視する組織は、市場平均より30パーセント以上も業績を向上させたことが分かっています。デジタルサービスの競争環境では、立ち止まるという選択肢はないのです。では、どうすればデジタル革新を加速させ、2022年に成功することができるのでしょうか。

重要なのは、開発者の生産性を具体的に向上させ、複雑さを軽減するようなイノベーション関連の投資を選ぶことです。そして、そのためには、3つの明確な攻め手があります。先進的な企業は、開発者の支援に焦点を当て、インフラについて実用的であり、「複雑さ」について現実的です。これらの分野を探ってみましょう。

  1. 開発者の生産性向上への投資 開発者は、デジタル革新の原動力となる存在です。しかし、手作業による設定や管理が必要な扱いにくいツールを使っていることがよくあります。大手企業は、開発者の生産性向上に投資することで、この問題に取り組んでおり、多くの場合、「開発者ツール」チームを新設しています。このチームの取り組みには、開発者をラップトップからGitLab/GitHubなどのクラウドベースのDevOpsやCI/CDプラットフォーム、GitHub ActionsやCodespacesなどの機能へと移行させることが含まれています。なぜでしょうか?それは、アプリケーションのアーキテクチャーが複雑化し、計算能力に対する要求が大きくなりすぎて、現在のやり方を続けることが難しくなったからです。

開発者にとってよくある問題は、「自分のラップトップでは動くが、本番では動かない」というものです。新しいクラウドベースの開発者環境は、この問題を解決します。本番環境と同じ規模の複雑なシステムをクラウド上で実現し、開発者の増強されたノートパソコンと同等かそれ以上のパフォーマンスとパワーを提供します。さらに、クラウドベースの環境は、継続的インテグレーションだけでなく、未だに悩ましい問題である継続的デリバリーへの道筋を容易にするのに役立ちます。

重要なことは、開発者の生産性に投資すれば、収益も向上するということです。調査によると、開発者の生産性が高い企業は、生産性の低い企業に比べて最大で5倍もの収益増加を達成しています。

  1. 「インフラ」の過剰設計を避ける 調査によると、現在92%の企業がマルチクラウド戦略を取っていることが分かっています。しかし、多くの場合、これは競争上の優位性につながっておらず、より良いイノベーションに寄与していません。IDCによると、79%の企業がマルチクラウドのメリットを実現するのに苦労しており、作業負荷がサイロ内に留まっているといいます。

これは、企業がマルチクラウドに取り組む際に間違った理由に基づいてベンダーを選択する場合に起こります。「ロックイン」を回避しようとするあまり、最善の機能を選んでいません。将来はハイブリッドクラウドが主流になる、マルチクラウドではないと認識している企業こそが、2022年以降に成功を収めることができるのです。

ここで必要なのは、健全な実用性です。賢明なエンジニアリングリーダーは、「ベンダーロックイン」の心配に負けることなく、そこで利用可能な機能に基づいて、自分たちのコードに適したインフラ環境を選択することになるでしょう。このようにして、企業は社内で利用できる限られたスキルを最大限に活用し、クラウドプロバイダー間で複数の同一環境を複製するために貴重なエンジニアリング時間を費やすことなく、イノベーションに専念できるようになるのです。

  1. 複雑さを極限まで減らす より革新的な顧客体験への要求は高まる一方です。しかし、その反面、複雑さが増大し続けることはありえません。現代の企業は既に何百万もの依存関係を持つ何千ものデジタルサービスを動かしており、マイクロサービス、コンテナ、サーバーレスアーキテクチャー、オーケストレーションプラットフォームが網の目のように張り巡らされています。

システムの複雑さには「ダンバー数」というものがあり、私たちはそれに急速に近づいています。いくつかのアプローチに対する反発の最初の兆候が現れています。例えば、Kubernetesは、ビジネス価値を提供するために多くの表面積を必要とします。また、CSPが提供するマネージドサービスを採用する企業も増えています。これらのサービスは、自社で設計することなく、最初から拡張性、信頼性、冗長性を提供します。

複雑さに対抗するためには、他に2つの重要な要素があります。1つ目に、リアルタイムの依存関係管理に投資して、エンジニアがデジタルシステムの関連性を明確に把握できるようにすることです。2つ目は、タスクを実行する必要がある人から「内側の複雑性を隠す」ために、自動化に投資することです。これにより、チームはデジタルインシデントをリアルタイムで監視、管理、是正することができます。PagerDutyの調査によると、技術系リーダーの73%が、複雑さとデジタルサービスに対する圧力の高まりに対処するため、自動化に投資している、または投資する予定であると回答しています。

イノベーションの強化 2022年にデジタル革新を成功裏に加速するために、組織は開発者の時間を解放し、単に「明かりを灯し続ける」のではなく、彼らがベストを尽くし、イノベーションを起こすことができるようにしなければなりません。リーダーを目指す企業にとって、この3つの領域は成功のための青写真となります。

DevOpsのサポートからクラウド戦略、自動化まで、PagerDutyがどのようにデジタルイノベーションの加速を支援できるかを知るには、https://www.pagerduty.com/ をご覧ください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

2022年1月12日  (更新日:2022年9月6日)     |    DevOps

PagerDutyが最新のG2 Grid for AIOps PlatformsでLeaderに選出される

PagerDutyでは、お客様を最優先にすることを約束します - これは会社のコアバリューです。私たちの製品は素晴らしい価値を提供し、優れたサービスを提供し、そして私たちとビジネスをすることをシンプルにする必要があります。

2022年冬のG2 Grid for AIOps Platforms Relationship Indexは、これらの価値を紹介し、PagerDutyをAIOps分野のリーディングプレーヤーとして取り上げています。

AIOpsの展望が進化し続ける中、PagerDutyは、よりインテリジェントで自動化されたオペレーションを実現するために、お客様の成功を促進することに力を入れています。ドメインにとらわれないアプローチで、戦略的な投資に基づいて構築することで、「壊して取り替える」という考え方ではなく、組織が観察可能性やその他の監視ツールで成し遂げてきた成功をさらに後押ししています。PagerDutyは、組織内に既にある戦略遂行能力を基に構築することに重点を置いており、ワークフローと連携して大きな価値を提供するために、再調整やわずかな改善点を探すことはしません。

私たちの顧客は、数秒という短い時間で適切な情報を適切な人に届けるためのサービスとしてPagerDutyを信頼しています。AIOps機能の加速は、この約束の実現を加速させ続けてきました。

昨年のレポート以降、AIOpsの領域で導入した新機能は以下のとおりです。

自動化とオーケストレーションのためのRundeckの機能を追加し、チームが安全にセルフサービスオペレーションを実行可能に コンテキストと状況認識のため、数少ないシステムからの変更イベントを、事実上あらゆる構成または展開ツールに統合 過去のインシデントと変更イベントのビューを統合し、モバイル機能を拡張 イベントのスループットを40倍に向上 イベントオーケストレーションの導入により、ルール管理を簡素化し、複雑なネスト化されたロジックを比較的容易に作成可能に イベントやインシデントがサービスに与える影響を理解しやすくするため、グラフィカルなサービスマッピングを開始 考えられる原因(Probable Cause)を示唆し、問題解決の出発点としてチームを特定のサービスに誘導し、MTTRを短縮

PagerDutyは、AIOpsの約束を実現するために、Actionable Intelligenceの推進に注力しています。PagerDutyのAIOpsソリューションにより、チームは数年にわたる実装を待つ必要はなく、PagerDutyは今すぐペインポイントの解決を応援することができます。

私たちのソリューションは、データサイエンティストを必要とせず、簡単に始められ、価値創造までの時間が短いため、チームがより良い、データ主導の意思決定を行えるよう支援します。** サービス、レスポンダー、インシデント、監視などに関する深い洞察を提供することで、チームはプラットフォームの専門家でなくても、より良い運用上の意思決定ができるようになります。私たちが独自のデータセットを使って開発したMLとデータサイエンスのアルゴリズムは、ノイズの低減、根本原因の迅速な分析、自動化を可能にし、チームはすぐにでもその恩恵を受けることができます。 プラットフォームを誰でも使いやすくし、分散チームやハイブリッド運用モデルに合わせた分散構成で、セルフサービスオペレーションを実現します。** PagerDutyのAIOpsは、中央のITチームには診断と自動修復を実行するための簡単なボタンを、開発チームには根本原因のトラブルシューティングを行うための合理的な方法を提供し、600以上のインテグレーションパートナーによってあらゆる技術スタックにシームレスに適合します。 インシデント対応のライフサイクルを通じて、自動化された次善の策を提案します。** イベントオーケストレーションでは、より少ないルールでよりスマートにネストされたルールを提供することで手動処理を削減し、インシデントの詳細と同時に考えられる原因や関連する変更を表示し、Rundeckを活用してエスカレーションの回数を減らし、インシデント解決を自動化します。

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

2018年4月25日  (更新日:2022年6月10日)     |    DevOps

DevOpsのメインストリーム化

PagerDutyで、私たちはDevOpsコミュニティとITプロフェッショナルが成功するために、どのように支えることができるかを考えて多くの時間を費やしています。私たちは、DevOpsの実践の進化のやり方と理由、実務家に価値を提供する方法、PagerDutyに高い信頼を寄せているコミュニティにどのように役立つのかについて、特に興味を持っています。

このことを念頭に、私たちは最近業界リーダーを対象としたWebセミナーを開催し、最新の実践とDevOpsの将来に関する予測を共有するよう求めました。 APMだけでなく、アプリケーションやセキュリティ監視の世界の視点を取り入れ、デジタル運用管理についての洞察を得ました。このグループには次の人たちが参加しています。

Ilad Rabinovich氏、Datadogの技術コミュニティ担当ディレクター Chris Gervais氏、Threat StackのエンジニアリングVP John Rakowski氏、AppDynamicsのプロダクトマーケティングディレクター Arager Chakrabarti氏、PagerDutyのエンジニアリングディレクター

私たちは、「DevOpsがやがて主流になるか?」とか、「エンタープライズ企業がDevOpsのプラクティスを採用することはできますか?」など、DevOpsの将来に関する多数の質問を検討しました。パネリストは多くのことをシェアしてくれたので、その中から、私たちは以下のハイライトを得られました。

DevOpsはやがてメインストリーム化するのか?

各スピーカーは、DevOpsがやがてメインストリーム化するのかということに関して考えを述べました。

DatadogのIlan Rabinovich氏は、ツールの普及、関連カンファレンス、マーケティング活動の環境全体を上げて、この産業はDevOps用語でいう「ピーク使用量」を達成したとコメントしました。 彼はさらに、誰もが同じ方法でDevOpsの言葉を使用しているわけではなく、真のDevOpsは “CAMS” definition:に定義されれいるような、文化、自動化、定量化、共有などによって証明されると指摘しました。

Threat StackのChris Gervais氏は、普及が遅れたとしてもDevOpsという言葉は確実に主流になると認めました。彼は、多くの組織や特定の種類の企業にとって、DevOpsはその活動のファブリックに組み込まれていることを提示しました。特に、SaaS製品を作っていスタートアップとファームには、DevOpsを一種の基盤となる固有の機能として活用しており、DevOpsのアプローチはまったく新しいものではなく、そうした企業の創業物語の一部になっています。 infrastructure as codeの考えに沿い、素早く進歩したい企業はコミュニティと同じくDevOpsツールの有用性を取り入れています。最近のTechCrunch の記事ではDevOpsは廃れたと宣言されたが、今やメインストリーム化しているはずだ、という冗談も口にしました。

AppDynamicsのJohn Rakowski氏は、DevOpsのメインストリーム化を「はいといいえ」という提案の一種とみなしています。同氏は、他のパネリストと意見を交わすことなく、DevOpsについて聞き取ること無しでは何処へも行けないと同意し、2016年までにDevOpsが主流戦略になるという2015年のGartnerの予測について言及しました。現実はあまり緊密に連携していなくても、Rakowski氏はメインストリーム化できると信じていましたが、 DevOpsの定義に関する継続的な闘争と議論は、特にさまざまな業界や組織にわたって残っています。彼は、エンタープライズ企業のDevOpsとスタートアップ企業のDevOps、DevOpsのメリットを得るために別々のチームを作成している企業などの有意義な違いを見分けました。

Arup Chakrabarti氏は、DevOpsは中小企業にとって「まさにそのままの存在です」と述べています。既存の企業にとって、DevOpsは標準ではありませんが、多くの企業は進化してあります。彼は、遅くて煩わしいことで知られている銀行や通信事業者の中には、DevOpsをポケットに入れて素晴らしい仕事をしていると指摘しました。しかし、彼は、DevOpsコミュニティが企業内でメインストリーム化できるためにはもっと多くの作業を行う必要があることを示唆しています。

エンタープライズ組織はDevOpsプラクティスを採用できますか?

エンタープライズ企業でDevOpsを採用するという問題で、Rabinovich氏は、採用とは技術よりも文化や組織の整合性のことだと感じています。 エンタープライズ企業では、ビジネスユニットやプロジェクトに割り当てられた別個のITチームが行動目標や営業目的などの共有によって内紛調整を対処できるサイロを作成することができます。

Rabinovich氏は「DevOpsの成功した組織は、まず文化と共有に取り組んだ後、ツールやメトリックを使って旅を加速しました。」とコメントしました。彼は市場にはテクノロジー製品を攻撃するために、ツールや、イベントや他のソリューションを販売していますが、文化と共有はメインストリームをもっと集中すべきエリアだと感じています。 DevOpsツールを購入することも一つのことですが、チームが共同の文化を構築していないと、データを共有できても進歩がほとんどなしで、学習も難しくなるとIlanは示唆しています。彼の見解では、CAMSモデルを活用し、共通の目標を特定するために共同作業をすることは、組織の成功への鍵となる道筋です。これは、アライメントと効率性を高め、追加リソースの確保につながる成功を追跡して共有する方法を生み出すからです。

Threat StackのGervaisは、エンタープライズの採用の聴衆からの、DevOpsは上から下、それとも下から上へ押し上げられているのか という質問に対応しました。.Gervaisは、これはただのCIOが DevOpsで “ready set go” というようなケースではなく、その代わりにmiddel outプロセスだと言えます。つまり、DevOpsはITチームの一部だけではなく、何人かの同好の一人一人がビジネス上の問題に集中するときに成長します。ビジネス上の問題に取り組まれる時、チームはDevOpsモデルの実験やテストを行い、従来のエンタープライズプロジェクト計画から外れる可能性のあるメトリクスを確立することでメリットを得られます。 Gervaisは、DevOpsが伝統的なIT組織やPMO組織に由来する場合、本質的に開始能力に制限があることを示唆しています。

Rakowskiの観点から見ると、エンタープライズ企業全体でDevOpsを実装することは、  

「DevOpsの採用はエンタープライズ企業全体でどのように進んでいますか?」などの質問を見て究極の問題とみなされています。ソフトウェアは顧客インタラクションと従業員の生産性を高めルための中心部であり、アプリケーションはビジネス成果を上げるようにします。そのように、技術がビジネスパフォーマンスの第一ドライバーとなっているため、より速いリリースが必須であるという現実があります。 DevOpsを実装しているRakowski州は、エンタープライズにとっての選択肢ではなく、ユーザーにサービスを提供し、ビジネスに価値をもたらすためにITが果たさなければならないことである。

PagerDutyのChakrabartiは、DevOpsの採用は、彼が考えるエンタープライズ企業が直面する最大の課題の3つ:文化、共有、アライメントによって推進されていることを示しています。 Opsチームは安定性に集中し、開発チームはイノベーションと変化に焦点を当てているため、根本的に不安定であり、異種のグループが組織内でサイロを作成します。結果として、彼は、サイトの信頼性と革新のバランスをとるビジネスの成功に焦点を当てた共通の目標を通じて、整合性を確立する強い必要性を認識しています。

マーケット上の雑音を除いて、パネリストはDevOpsがメインストリームかし、2017年以降にエンタープライズに移行していることに同意しているようです。 共有や文化の変革など、採用を推進する重要な要素は、DevOpsイニシアチブの基本要素であり、アライメントは成功と同じ傾向にあります。

このブログシリーズの次回の記事では、「中央オペレーションチームがアプリケーションコードベースに近づくのか」、「セキュリティがDevOpsの運用モデルの一部になるのか」など、さらに重要な質問について検討します。

その間、BrightStudioのデベロッパーズウェブセミナーの2017年の予測と傾向全体をチェックしてください!

本記事は米国PagerDuty社のサイトで公開されているブログをそのまま日本語に翻訳したものです。原文はこちらを参照してください。

2019年8月26日  (更新日:2022年5月19日)     |    DevOps

DevOpsは買えません

DevOpsへの移行は、どこから始めればよいのかわからない多くの組織にとって、大変な作業になる可能性があります。私は最近、どんなソリューションが市場に出回っているかを知るために、いくつかのDevOpsの評価を読んでみました。それはDevOpsを完全に採用している組織から、まだ始めたばかりの組織までありました。評価の中には真の価値をもたらし、文化や方法論に関する記事にリンクしているものもあれば、DevOpsのすべての夢を実現するためのツールを提供してくれるというものもありました。

DevOpsの過程では、ユーザーがサービスを継続的にデリバリーし、自動化し、サービスを監視することを可能にするソフトウェアとしてのツールは不可欠です。ただし、DevOpsは製品ではなく、ツールだけではDevOpsの価値を十分に理解するために必要なプロセスを得ることができません。DevOpsでは人が最も重要です。人がいなければ、DevOpsを完全に実現するために必要な考え方や文化を構築することはできません。

DevOpsで勝つのではなく、チャンピオンになる

私は最近PagerDutyのCEOであるジェニファー・テハーダと勝者とチャンピオンの違いについて話をしました。彼女は勝利の素晴らしさを語りました。トロフィーやタイトル、もしそれが宝くじなら数百万ドルが手に入ると。しかし、大きな絵で見ると、勝利は短期的なゴールに過ぎません。対照的に、チャンピオンになるには、長期的な成功や成果に焦点を当てることが必要です。この会話で、DevOpsを採用している組織に同じ原則をどのように適用できるかについて考えさせられました。

DevOpsツール関連の私のお気に入りの1つは、XebiaLabs社のDevOpsツール周期表です。

表に示されているように、DevOpsカテゴリーには多数のツールがあります。しかし、ツールを購入することによって組織が「DevOpsに変貌する」という話を見たり聞いたりすることが多すぎます。先に述べたように、ツールはDevOpsへの過程の重要な部分ですが、ツールだけではDevOps環境は構築されません。DevOpsチームを適切に機能させるためのすべての要素(コラボレーション、自動化、オーナーシップ、サイロの解体、プロセスの定義、継続的改善、継続的デリバリー)を考慮する必要があります。

ツールの購入を決断することは正しい方向への大きな一歩ですが、もっとも重要なのは、決定の背後にある「なぜ」、つまり最終目標を定義することです。そのために、もう一度チャンピオンの考え方を検討しましょう。

たとえば、オリンピックの水泳金メダリスト、マイケル・フェルプス選手を見てください。フェルプスは史上最も称賛されたオリンピック選手であり、彼は39の世界記録を保持しています。フェルプスは1、2勝するどころか、20勝でも止まりませんでした。彼はチャンピオンになることを目指しました。これはすべて、コミットメント、実践、そして目的とする最終状態に集中することによって成されました。

DevOpsの定義

DevOpsには何百もの定義がありますが、ほとんどの人はDevOpsレポートで概説されている次の基本原則に同意することができます。

「DevOpsは、チームがより効率的に作業し、優れたソフトウェアをより迅速に提供できるように、文化とプロセスを構築することを目的とした一連の原則です」。

文化やプロセスはクレジットカードで変更することはできません。ツールを使用すると、組織はより優れたコラボレーション、自動化、継続的デリバリーを実現できます。しかし、正しい考え方と選択がなければ、ツールの全機能が達成されない可能性があります。

例としてSlackを取り上げましょう。新しい会社に転職した私の元同僚は会議に出席していました。彼は、Slackのチャンネルを作ってコラボレーションすることが、チームをDevOpsに変えるために素晴らしいと言うのを聞きました。Slackが彼らのすべてのコミュニケーション問題を解決するだろうと彼のマネージャーは確信しました。しかし、Slackを採用してから6か月後でも、マネージャを含めチームの大半がまだSkypeを使用していました。Slackは、製品をより早く市場に投入するために使用されるツールというよりは、ビールの醸造について話すための場所になったのです。問題はSlackではありませんでした。それはチームと組織の参加の不在、そして製品の全機能に関する知識の欠如でした。

ツールとベストプラクティスをチームと短期、長期の目標の達成にいかに機能させるかが、DevOpsチャンピオンとしての我々が話すべきことです。たとえば、チームや組織の全体の目標は何ですか? 目標が特定されたら、主要なステークホルダーからどのようにして賛同を得るのでしょうか。合意が成された後、どのようにしてソリューションを実装しますか?

組織変更

変化は多くの組織や個人にとって困難であり、意味のある変化は一晩では起こりません。人と組織がどのように変化を成し遂げるかを理解することは重要です。

Kotter 8-Step Process for Leading Changeが提唱するのは、最初のステップで変化の必要性を明確にし、すぐに行うべき理由を考え、小さなことから始め、勝とうとする前に内部にいるチャンピオンを見つけて育てるということです(この場合の変化はツールの購入)。

組織内の人々が問題を認識していない、またはより良い運営方法が存在することを認識していない場合、チームメンバーの賛同と新しいアイデアを採用し行動を起こすように動機付けることは困難です。もしかすると現在のプロセスが十分であるため、人々は現在の状態に完全に満足しているかもしれません。または、少なくとも現在の状態が既知である可能性があります。しかしながら、チーム全体がうまく機能し、より早く、より機敏な方法で彼らの共通の目標を達成するためには、最初に新しいメカニズムを導入しなければなりません。

DevOpsチャンピオンになる方法

DevOpsの世界でチャンピオンになることは、勝利を超えて進むことを意味します。それは、チームと組織構造と文化を深く掘り下げて、ツールの範囲を超えた問題を特定し、他の人と協力して、明確な結果につながる必要な変化を受け入れることを意味します。つまり、最初に戻って最終の目標を定義する必要があります。以下はあなたが始めるように頼むことができる簡単な質問です。

あなたのコアバリューは何ですか? なぜあなたはもっとアジャイルな会社やチームになろうとしているのですか? あなたのチームや組織はどんな障害に直面していますか? ツールやプロセスは何を達成するのでしょうか? 人々はどのようにしてコミュニケーションやコラボレーションをしていますか? サイロはありますか? それはなぜですか? あなたはどのように顧客を擁護していますか? 従業員は権限を与えられていますか?

最終状態を定義したら、志を同じくする他の人をチャンピオンチームの一員にし、達成しようとしていることを見失なわないようにしましょう。1つのチームやテスト環境から始めるなど、変化を始めるときはスモールスタートを忘れずに。小さく始めて勝利を築くことによって、内部のチャンピオンは彼ら自身をクリエイトし​​始めるでしょう。

覚えておいてください。企業は熱心にDevOpsを売ろうとしています。しかし、結局のところ、DevOpsは製品ではありません。それは、自動化、コラボレーション、人、そしてプロセスの方法論と考え方なのです。

*この記事のオリジナル版は、opensource.comで以前に公開されたものです。

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

2017年12月26日  (更新日:2022年5月19日)     |    DevOps

現代のインフラストラクチャに真のフルスタック可視性を

「フルスタックの可視性」とは?

ツールのベンダーが「フルスタックの可視性を提供します」と宣伝していることがありますが、これが何を意味しているか分かるでしょうか。ツールが違えばどう可視化するかも違います。理由は、可視性がITインフラストラクチャの構成方法に依存するだけでなく、あなたが何が見たいかにもよるためです。極論すればフルスタックの可視性は、ツール、アプリケーション、システム、サービス、および全体的なインフラストラクチャの状態を一覧できるようにすることです。

近代的なインフラ

まず、現代のアプリケーションとサービスをホストするフルスタックインフラストラクチャのタイプを特定してみましょう。以下は、現代のインフラストラクチャに見られる最も一般的なコンポーネント要素です。これらは、仮想デバイスと物理デバイスのミックスとしてオンプレミス、クラウド、またはハイブリッド環境でホストされる場合があります。

現代のインフラストラクチャコンポーネント

アプリケーションとツール オペレーティングシステム ミドルウェア ネットワーク データベース ストレージ Webサーバ 演算装置

これらのインフラストラクチャコンポーネントはすべて、膨大な量の構造化データと非構造化データの両方を生成します。この指数関数的に急増するデータの量と多様性はITOps、DevOps、開発チームに挑戦を突き付けます。つまりシステム、アプリケーション、サービスの可用性を高く維持し、最適なパフォーマンスを発揮させるためにカギとなる情報を収拾し解釈し、実用的な洞察を抽出することを要求します。

以下は、今日の組織がインフラストラクチャとアプリケーションのパフォーマンスを自動化するために採用しているツールの例です。これらのツールのそれぞれは、インフラストラクチャ、アプリケーション、サービス、コードの展開、ビルドなどのステータス、健全性、脆弱性を知らせるデータを生成することができます。

インフラストラクチャ、アプリケーション、自動化ツール

オートメーション/継続的インテグレーション ソースコード管理

構成管理とプロビジョニング リポジトリ管理

ソースコードとリポジトリ管理 プロビジョニング

デプロイ リリース管理

データベース テスト

モニタリング セキュリティ

ビルド クラウドIaaS

マイクロサービスと仮想化

どんな風に可視化できるか

アプリケーションとサービス、システムは、データテーブル、ステータスダッシュボード、パフォーマンスグラフとチャート、ヒートマップ、トレース、システムヘルスメトリック、分析、レポートなど、さまざまな形で可視化できます。フルスタックの可視性は、複数のツールを組み合わせて構成することができます。

監視ツールカテゴリ 人気ベンダー

アプリケーションパフォーマンス監視 New Relic、AppDynamics、Dynatrace

インフラ/クラウド監視 AWS CloudWatch、Microsoft Azure、Google Stackdriver

メトリック Datadog、Librato、Keen IO

ログの監視と分析 Splunk、Elastic、Sumo Logic

既に複数の組織が、上記のさまざまなソリューションを使ってITツールのポートフォリオを構築し、インフラストラクチャ全体で何が起こっているのかを深く調べられるようにしています。

PagerDutyのようなソリューションは、ITポートフォリオ内の全ツールから生成された全イベントとアラートを集中管理して集計し、インシデントへのより適切な対応をリアルタイムで選び出します。

何が起きているのかを示せるツールは世の中にたくさんあって、ほとんどのチームは複数の監視とチケット発行ソリューションに投資しています。ここでもっと重要になるのは、大規模なインシデントがビジネスに影響を及ぼすことを防ぐ、あるいはサービスを復旧するため、専門家に対してよりよく事態を理解するために必要なリソースを提供するソリューションです。

さらにその先へ

PagerDutyでは、真のフルスタック可視性は、インフラストラクチャ、アプリケーション、およびサービスの健全性に関するビューだけではありません。インシデント管理、レスポンスオーケストレーション、システムと運用の両方の効率性の視覚化など、他の重要な部分も含まれているため、チームはSLAを継続的に改善できます。ソフトウェアがビジネスと顧客の経験の中心になるにつれて、ITOps、DevOps、開発者、ITリーダー、エグゼクティブ、ビジネス関係者は、インフラストラクチャ全体で何が起こっているかをよりよく把握する必要があります。

インフラストラクチャの真の健全性を評価する際には、人の役割の重要性を忘れることはできません。ツールは常に仕事をしますが、インシデントはそれらのツールのデータを理解できる人々が解決するのです。PagerDutyのオペレーションコマンドコンソールとインテリジェンスアプリケーションは、多数のベンダーの製品から得た状況の推移を単一のビューにまとめ、どんな重大なインシデントが際立っているか、担当者が取り組んでいるインシデントはどれか、どんなイベントが関連性があるかを包括的に把握できるようにします。そしてインシデントへの技術的、ビジネス的対応の両方を調整します。

PagerDutyを使うと、アプリケーション、サービス、インフラストラクチャの健全性を簡単に視覚化し、インシデント対応ワークフローを1カ所で管理できます。

<  12  >