Blog
ブログ

2022年3月28日  (更新日:2022年9月9日)

PagerDutyのピープルファーストのコミュニティーへの取り組み

ピープルファースト(人間第一)は、私たちが日々実践している哲学です。今日は、社員と、そして世界中に広がるコミュニティー作りを通して、私たちが実践している進化した方法をご紹介します。

デュートニアン(訳注:PagerDutyの従業員)にとって2年前は20%だった在宅勤務が、今では75%に達しています。分散型が私たちのニューノーマルです。全新入社員が、ハイブリッド、オフィス内、好きな場所と、自分に最も適した勤務形態を選ぶことができ、働く場所に究極の柔軟さが与えられています。

大切な時間をつくる

デュートニアンの生活を豊かにするために、私たちは社交、コラボレーション、ネットワーク、そして豊かなコミュニティーへの参加をより簡単にできるようにしています。

”Donuts”と”Casual Collisions”の2つは、仮想環境での偶然の出会いや雑談を再現するため取り組みです。Donutsは、Slackのチャンネルにボットを追加し、チャンネル内でランダムにペアリングを行い、ソーシャルチャットを行えます。Casual Collisionsは、このコンセプトを全社的なペアリングに拡大したものです。

PagerDutyは社会的なつながりだけでなく、年2回のHackWeekの伝統を発展させ、現在はバーチャルで行われ、全ての参加者にとって公平な体験となっています。HackWeekは、デュートニアンにとって、普段は会うこともなく、ましてや一緒にプロジェクトに取り組むこともないような会社の人たちと、革新的なアイデアを追求するチャンスなのです。

PagerDutyの価値観でつながる

PagerDutyの目的、ミッション、ビジョン、バリューは、デュートニアンをグローバルに繋ぐものです。私たちは、未来を築き、より公平な世界を描くために、時間と効率でチームに力を与えるために存在しています。この信念は、従業員体験も含め、私たちが行う全てのことに適用されています。

ワークプレイスエクスペリエンスチームのプログラムであるVibeは、デュートニアン同士のつながりを構築・強化し、私たちのブランドやコアバリューとのつながりを感じられるようにするためのものです。Vibeで最も人気のあるイベントの多くは、Social ImpactやEmployee Resource Group(ERG)といったチーム横断的な取り組みで、還元、コラボレーション、ID&Eといった当社の真の価値志向を反映しています。例えば、STEP-temper initiative では、世界中の32チームがチャリティのために1カ月間のフィットネスチャレンジに参加し、素晴らしい非営利団体”Humanity Matters”に合計26,000ドルを集めました。

今年、Vibeは四半期ごとに異なるPagerDutyの価値を、恩返しの要素と結びついた楽しい社会活動の組み合わせによって実現しています。バーチャルコンサート、コンテスト、体験型アクティビティー、そして「Bring Your Child to Work Day」のような家族全員で参加できる機会も用意されています。また、チームから寄せられた快適さや要望をもとに、対面式のイベントも数多く開催する予定です。

また、2カ月に1度のガイド付き瞑想や、Slackでの#WatercoolerWednesdayディスカッションスレッドなど、Vibeが継続的に行っているプログラムも引き続き実施していく予定です。

PagerDutyはコミュニティーを向上させる

PagerDutyのコミュニティーは、デュートニアンを遥かに超えて、私たちの顧客、パートナー、そして私たちが生活し働くコミュニティーを含んでいます。私たちの1%誓約コミットメントの一環として、私たちは従業員の労働時間の1%を地域社会とグローバルコミュニティーの変化を加速させるために提供すると誓約しています。

私たちの社会貢献プログラムは、従業員のスキルや関心を結集してコミュニティーのニーズに応え、信頼とより大きな公平性を構築することを目的としています。 その例として、Volunteer Time Off(VTO)、Technical Pro Bonoプログラム、Givingプログラムの3つがあります。

社員は毎年20時間の有給休暇を取得し、自分の好きな団体や活動に時間やスキルを捧げることができます。子どもの学校でのボランティア、地域の非営利団体への支援、投票関連やメンター活動への参加など、さまざまな活動が行われています。社員はボランティアに参加した時間と影響を記録すると、PagerDutyから資金を得て、自分にとって重要な活動に寄付できます。

私たちは、毎年恒例のカンパニーキックオフ(CKO)で集団ボランティア活動を行い、力強い1年をスタートさせています。今年のCKOでは、デュートニアンは18の仮想プロジェクトをサポートし、公平性を高め、存在感の薄いコミュニティーの機会を拡大し、PagerDutyの非営利顧客とローカルパートナーの影響をさらに拡大させました。例えば、パートナーであり非営利団体であるWeRoboticsがFlying Labs Networkの全メンバーをうまくまとめるために最適なコミュニケーションツールを特定するなど、パートナーが直面している課題に対する解決策のブレインストーミングを支援しました。

通年、ERGや各地域で社会貢献活動を推進する社員のグローバルネットワークであるCommunity Respondersと協力し、社員なら誰でも参加できるドロップインの仮想ボランティア機会を毎月設けています。

PagerDutyの社員は、Technical Pro Bono programを通じ、私たちのプラットフォームの知識を活用して、非営利団体のお客様のデジタルトランスフォーメーションの過程をサポートしています。昨年秋には、異なるチームや地域のPagerDutyの社員が、ワクチンの公平性を高めるために最前線で活動する3つの非営利団体とパートナーシップを結びました。

PagerDutyカスタマーサクセスマネージャーのJon Honariは、Technical Pro Bonoプログラムの経験について、次のように語っています。

「WeRoboticsと一緒に仕事をすることで、PagerDutyは単なるソフトウェア会社ではなく、変化と善のためのファシリテーターであると感じるようになりました。WeRoboticsのチームは、ドローンの助けを借りて予防接種や医療用品を届けることで、世界の最も遠隔地に住む人々が健康を維持できるようにすることを目指しています。PagerDutyが、困っている人々の幸福のために直接インパクトを与えることができるのは素晴らしいことであり、彼らのミッションの一翼を担えたことに感謝しています。

また、従業員には、危機対応活動、PagerDuty.orgパートナー、および自分にとって個人的な原因を支援するための資金提供や企業マッチングキャンペーンに参加する機会もあります。2021年、デュートニアンは412の活動を支援し、デュートニアンの92%が当社のソーシャルインパクトプログラムに参加しました。

詳細は、PagerDutyが近日中に発表する「2021 Impact Report」でお楽しみください。

PagerDutyとPeople-Firstコミュニティーへの参加にご興味がありますか?

私たちは採用中です。PagerDutyでの生活については、採用情報ページと、このピープルファーストシリーズのブログ1と2をご覧ください。PagerDutyの拠点は、リモートでの勤務のほか、アトランタ、リスボン、ロンドン、サンフランシスコ、シドニー、トロントにあります。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

続きを読む
ベストプラクティス
2022年3月17日  (更新日:2022年9月9日)

ウクライナへの支援|企業としての表明

ロシアがウクライナに侵攻してから3週間が経過しましたが、この危機は予測できないほど長く続く可能性があります。人道的危機の規模は驚異的です。この地域における暴力、特に罪のない一般市民を標的にしたエスカレートは悲劇であり、急速に近年最大の人道危機の一つになりつつあります。

私たちは、企業として、私たちの意図を裏付ける行動を優先しています。社員が寄付やボランティアをするためのリソースを提供し、非営利団体と協力して、この地域の救援活動を直接支援したり、サポートしたりする機会を積極的に設けています。

PagerDutyには、グローバルコミュニティーのニーズに応えるための文化や歴史が確立されています。私たちは、ウクライナの人道的支援、救援活動の組織化、避難の調整などを推進する組織が、PagerDutyを無料で利用できるようにし続けます。適切なタイミングで適切な人々に迅速かつ忠実に、そして柔軟にコミュニケーションをとることは、彼らの活動を成功させるために不可欠です。私たちは、新しいユーザーがすぐに製品を使えるようカスタマーサポートを提供します。

PagerDutyは、ロシアの国営企業や、ウクライナのドンバス地方やクリミア地方にある企業とは一切取引していません。より広範な国際ビジネス社会と連帯して、私たちは、私たちが関わっている限られた数のロシアの顧客との全ての作業を停止し、ロシアからの新しいアカウントを受け付けないことにします。当社は、当社のサービスとセキュリティーを積極的に監視し、利用規定に記載されているガイドラインを実施しています。私たちのプラットフォームが不適切に使用されていることを発見した場合、私たちは迅速に対応します。

私たちは、ウクライナで起きている出来事を追い続け、国民、国家、そして主権のために立ち上がる勇敢なウクライナ人を支援する方法を模索し続けます。紛争の平和的かつ公正な終結を願うと同時に、私たちの専門知識とプラットフォームを活用して、私たちが正しいと信じることを支援する方法を積極的に模索していきます。

支援対象組織

国際医療協力隊「ウクライナ基金」。PagerDuty.orgのパートナーは、ウクライナと近隣諸国の医療専門家による一次および緊急医療サービスを提供しています。 UNHCR。ウクライナから逃れてきた難民に、現地で緊急支援を行います。 セーブ・ザ・チルドレン「ウクライナ危機救済基金」。350万人の子どもたちとその家族に、食料、水、衛生キット、心理社会的支援、現金支援などの緊急支援を提供することを目標としています。 Nova Ukraine。ウクライナの非営利団体で、現在、人道的支援を行い、他の地域へ移住しなければならない避難民を支援しています。 Voices for Children。心理学者とともに、危機的状況にあるウクライナの子どもたちを現場で支援します。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

続きを読む
ニュース&告知
2022年3月7日  (更新日:2022年9月9日)

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

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

PagerDuty、AWSPagerDuty、AWSから金融サービスコンピテンシーを取得から金融サービスに関するコンピテンシーを取得

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

続きを読む
ニュース&告知
2022年2月1日  (更新日:2022年9月9日)

チームでRound Robin Schedulingを成功させるためのヒント

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

Round Robin Schedulingの仕組みは?

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

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

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

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

Round Robin Schedulingがない場合Round Robin Schedulingがある場合
全インシデントが1人に割り当てられ、他のメンバーはスケジュールにないため、アイドル状態になるインシデントを公平に割り振り、それぞれが負担を分担する
1人のレスポンダーが複数のアラートを処理しようとするのでMTTAとMTTRが増加する各レスポンダーがアラートに十分な注意を払えるため、MTTAとMTTRは減少する。
レスポンダーが忙殺されると、エスカレーションを余儀なくされる問題発生時にすぐに対応できる別の担当者がいるためエスカレーションの頻度が少ない。

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

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

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

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

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

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

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

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

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

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

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

続きを読む
ベストプラクティス
2022年1月13日  (更新日:2022年9月9日)

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

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

2022年1月11日  (更新日:2022年9月6日)    |    インシデント&アラート

ラウンドロビンスケジューリングによるオンコール責任の均等分配とインシデント対応効率化

PagerDutyは、ラウンドロビンスケジューリングを発表できることをうれしく思います。ラウンドロビンスケジューリングは、チームメンバー間でオンコールシフトの責任を公平に分配することを可能にします。自動的に異なるユーザーまたはエスカレーションレベルのオンコールスケジュールに新しいインシデントを割り当てることで、チームが可能な限り効率的にインシデントを解決することを保証します。また、複数のユーザーで作業負荷のバランスをとることで、燃え尽き症候群のリスクも軽減されます。

同一サービスで発生した複数のインシデントのシームレスな解決

あるサービスでインシデントが発生すると、1人のレスポンダーがアラートを受信し、トリアージを開始します。インシデントが1つだけであれば対処可能です。しかし、アラートの量が多いサービスでは、レスポンダーが複数のインシデントに対応するために複数の方向に引きずられるため、インシデント対応中に混乱が生じる可能性があります。あるサービスで、30分以内に対処しなければならない5つの異なるアラートが同時に発生したとします。1人のオンコールエンジニアがその全てに対応することはできません。そこで、ラウンドロビンスケジューリングが役に立ちます。

ラウンドロビンスケジューリングでは、新しいエスカレーションポリシーを作成するか、既存のエスカレーションポリシーを編集して、”Users are assigned via round robin on the escalation level”(エスカレーションレベルではユーザーはラウンドロビンで割り当てられる)というボックスをチェックすれば、ユーザーは簡単にローテーションを設定することができます。

上記の例のような場合、ラウンドロビンの各担当者は、5つのアラートのうち1つをトリアージするよう割り当てられることになります。これにより、インシデント対応が効率化され、ダウンタイムが短縮され、顧客体験が向上します。

ラウンドロビンスケジューリングなしラウンドロビンスケジューリングあり
全てのインシデントが1人の担当者に割り当てられ、残りのメンバーはスケジュールにないためアイドル状態インシデントをチーム内で公平に割り当て、それぞれが分担する
1人のレスポンダーが複数のアラートを処理しようとするため、MTTAとMTTRが増加する各レスポンダーがアラートに最大の注意を払うことができるため、MTTAとMTTRが減少する
レスポンダーに余裕がなくなると、エスカレーションを余儀なくされる入ってきた問題にすぐに対応できる別のレスポンダーがいるため、エスカレーションの頻度が少ない

さらに、ローテーションの対象者を特定するのも簡単です。ユーザーがエスカレーションポリシーを表示すると、ラウンドロビンのローテーションで誰が次になるかが緑の矢印で示されるので、問題が発生したときに誰がアラートを受けるかがあらかじめ分かるのです。

燃え尽き症候群を減らすために、仕事を分散し、必要に応じてエスカレーションする

大量の依頼を受けるオンコールチームでは、燃え尽き症候群が常に念頭にあります。 一人のチームメイトが複数の問題を同時に処理し、他のチームメイトが待機していることもあります。このようなオンコールシフトは、注意力不足、応答速度の低下、認知能力の低下などを引き起こす可能性があります。たとえオンコールシフトが月に一度しか発生しないとしても、それは離職率を高めるのに十分な圧力となり得ます。

ラウンドロビンスケジューリングは、各新規インシデントが、マネージャーもユーザーも含めて順次割り当てられるようにし、チームが責任のバランスをより良くとれるようにします。これは、エスカレーションの上位レベルにいるディレクターなど、優先順位の高いインシデント中にステップインする必要があるかもしれない人も含めて、オンコールスケジュールにいる全ての人にとって公正かつ予測可能なローテーションを維持するのに役立ちます。

ラウンドロビンスケジューリングを使用する

あなたのチームでオンコールボリュームを管理し、インシデント対応を合理化し、公平に作業負荷を分散する方法をお探しですか。ラウンドロビンスケジューリングは、BusinessとDigital Operationsの全てのプランで利用できるようになりました。現在ご利用中のお客様で、この機能へのアクセスを解除するためのアップグレードをご希望の場合は、PagerDutyアカウントチームまでご連絡ください。まだご利用でない方は、この機能を14日間無料でお試しいただけます。

ラウンドロビンスケジューリングの詳細については、こちらのサポートドキュメントをご覧いただくか、こちらのYouTubeショートムービーをご覧ください。

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

2022年1月10日  (更新日:2022年9月5日)    |    インシデント&アラート

インテリジェントスウォーミング vs 階層型サポート。カスタマーサービスチームがPagerDutyを使い重要な問題をスウォームさせる方法

今日、ほとんどのサポート組織は、何らかの形で従来の階層型サポートモデルを採用しています。これは、エスカレーションと顧客の引き継ぎのプロセスに基づいているものです。このモデルでは、顧客の問題は、サポート階層の複数のレベルを介してエスカレーションされ、3つの階層が一般的なワークフローとなります。

この典型的な3層構造のサポートシステムの例では、Tier 1は入ってくる顧客の問題を受ける最初の防御線であり、一般的なテクニカルサポートを提供します。Tier 1サポートで解決できない問題は、より深い技術的知識とサポートスキルを持つTier 2にエスカレーションされます。このレベルでも解決できない場合は、対象となるアプリケーションの専門家であるTier 3のスペシャリストにエスカレーションされます。

このモデルは、それほど深刻でなく繰り返し発生する問題には有効ですが、今日の常時接続のデジタル世界において、優先度が高く重要なインシデントに対処する場合には、全く適していません。おそらく、今日のカスタマーサービス組織で広く見られるこの従来のサポートモデルの考え方を疑うべき時が来ているのでしょう。

このモデルは、エスカレーションと顧客の引き継ぎのプロセスに基づいているため、以下のようないくつかの欠点があることは驚くことではありません。

解決までの時間、First Reply Timeが長い。** 全チケットが同じトリアージのキューに従うため、最終的に適切な担当者にたどり着くまでは、その問題に対処する能力がないエージェントのもとで時間を浪費することになります。このモデルでは、適切な専門家にたどり着くまでに障壁があり、問題についての重要な文脈や情報が途中で失われることが多く、不必要な遅延が発生します。 長いバックログ項目。** Tier 1レベルで解決できないお客様の問題は、他のサポート層への待ち行列に入ります。このケースは、リアルタイムでアクティブに作業されている状態から、バックログのアイテムになるのです アカウンタビリティーの低下。** 階層化モデルは、エスカレーションと顧客対応のプロセスに基づいています。最前線のスタッフが問題を専門家にエスカレーションすることを求められると、アカウンタビリティーが低下し、インシデントからエンドツーエンドで学ぶ機会も減少します。 顧客にネガティブな体験をさせる。** 複数のサポート担当者に問いを繰り返さなければならなかった経験のある人なら誰でも、このことが顧客満足度にマイナスの影響を与えると理解してるはずです。

これは、サポート組織は階層型サポートモデルを廃止すべきである、と言っているのではありません。階層型サポートは、それほど深刻でない問題や単発の質問に対応するには非常に効果的です。しかし、重要で緊急性の高いインシデントになると、階層型モデル特有の非効率性が、最終的に顧客離れにつながる負の顧客体験をもたらす可能性があります。

IIntelligent Swarming℠は、オーソドックスな階層型サポートに代わるフレームワークを提供します。このフレームワークでは、キュー内の作業よりもリアルタイムの作業、サイロ内の作業よりもコラボレーション、一方的なエスカレーションよりもケースのオーナーシップを優先します。

インテリジェントスウォーミングモデルでは、チケットを受け取ったカスタマーサービス担当者が、その案件を最後まで担当します。サポートに階層はなく、お客様の引き継ぎもありません。チケットの所有者であるエージェントが解決できない場合、そのエージェントは即座に問題の「スウォーム」化を行う専門家チームを引き込みます。このような的を絞ったアプローチはインテリジェントスウォーミングと呼ばれ、適切な人が適切なタイミングで動員され、協調した対応を行います。これは、多くの人が対応策に参加しても、必ずしも問題解決に適した専門家であるとは限らないという、インシデントに対する協調性のないスウォーミングとは対照的なものです。インテリジェントスウォーミングのフレームワークでは、ケースオーナーが専門家チームと情報を共有し、解決に向けて協力し合います。

このモデルには、いくつかの利点があります。

この理論を実践するためには、カスタマーサービス担当者が適切な情報にアクセスし、専門家と協働できるようにする必要があります。つまり、組織全体からリアルタイムのサービス障害データを提供してもらうことです。また、運用チームとの双方向のコミュニケーションを可能にする双方向通信チャネルを確立することも必要です。また、機械学習機能を使って、顧客に影響を与える前にインシデントを特定することも可能です。

PagerDutyでは、サポートエージェントがインシデントの履歴コンテキストを可視化し、テクニカルリソースからの監視データを提供することで、問題の全体像を把握し、正しい解決策を特定できます。エージェントがチケットで助けを必要とする時は、PagerDutyの一連の機能を使って迅速に追加支援を引き出すことで、スウォーミングモデルをさまざまな方法で実現できます。

エージェントは、インシデントにレスポンダーを追加することで(「Add responders」という分かりやすい名前の機能があります)、PagerDutyで迅速にスウォームリクエストを始められます。これにより、組織全体から必要な専門家が直ちにループに入れられ、コラボレーションのための会議ブリッジを設定するオプションも用意されています。追加されたレスポンダーは、緊急性の高い通知ルールで通知され、重要な問題を見逃すことがないようにします。

PagerDutyのエージェントは、レスポンスプレイ(ボタンをクリックするだけでインシデントに対して実行できる定義済みアクションのセット)を利用して、スウォームの開始に関連する定番のワークフローを自動化することもできます。これらの定義済みアクションには、対応者の追加、カンファレンスブリッジの設定、関係者のインシデントへのサブスクライブ、ステータスアップデートの公開などが含まれます。レスポンスプレイは、特定のサービスに結びついたインシデントに対して自動的に実行されたり、PagerDutyを使っている誰もが手動で開始したりでき、実行されるアクションが問題の規模に適していることを確認できます。

最後に、PagerDutyはZendeskなどのチケットツールやSlackなどのChatOpsツールとネイティブに統合されているため、エンジニアリングチームと簡単に双方向のコミュニケーションが可能です。また、エージェントが使っているツールからPagerDutyのインシデントをトリガーできるため、コンテキストスイッチの必要がなく、適切なチームや専門家にすぐに接続して問題を解決できます。PagerDutyをオールインワンの対応オーケストレーションおよびコラボレーションツールとして使用することで、チームは簡単に問題をスウォーミングし、顧客とエージェントの両方にとってよりシンプルで合理的なエクスペリエンスを実現できます。

スウォーミングや階層型プラクティスを使用するかどうかにかかわらず、今日、あらゆる顧客問題をサポートするためのよく知られたアプローチが存在します。適切なスウォーミングの手法を事前に構築しておけば、適切なタイミングで適切な専門知識を自動的に活用できます。また、即時対応が必要でない重要度の低い問題については、階層化されたアプローチを自動化(自動エスカレーションポリシーやオンコール通知など)することです。

デジタルイノベーションとユーザーエクスペリエンスによって定義されるようになるパンデミック後の世界では、カスタマーサービス機能を強化する新しい方法を検討する時期が来ています。

Intelligent Swarming℠は、サービスイノベーションコンソーシアム™のサービスマークです。

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

2022年1月6日  (更新日:2022年8月31日)    |    インテグレーション&ガイド

スクラムセレモニー:初心者のためのガイド

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2022年1月5日  (更新日:2022年8月30日)    |    インシデント&アラート

オンコールの人間模様:オンコール中のストレス、不安、生活を管理するための5つの教訓

DevOpsでは、オンコールプロセスについてよく話しますが、オンコール中の人間的な側面についてはどうでしょうか?例えば、シフト中のストレスや不安に対処する効果的な方法は何でしょうか?オンコール当番中に子供の世話をしなければならないなど、オンコールに専念しづらい生活状況とどのように両立すればよいでしょうか?また、共感的なチームカルチャーは、燃え尽き症候群や離職を防ぐのにどのように役立つのでしょうか? 2021年11月から12月にかけて、PagerDutyの9つのチームのオンコールエンジニアが集まり、オンコールの人間的側面についてディスカッションしました。ここでは、そのセッションで得られた5つの重要なポイントを紹介します。

チーム内の共感が重要である 一日中グラフを眺めていてはいけない ポストモーテムはストレスになり、多くの労力を要する 緊急性の低いアラートは、夜間のノイズを減らす 1週間のオンコールは燃え尽き症候群につながる可能性がある

それぞれの重要なポイントに入る前に、私たちが話を聞いたチームに関連するいくつかの指標を見てみましょう。

2022年1月7日  (更新日:2022年8月30日)    |    ニュース&告知

PagerDutyがどのように全部門の重要な業務に対応できるかをご覧ください

PagerDutyのOperation Cloudは、ITチームからカスタマーサービス、人事、マーケティング、営業など、ビジネス全体にわたる重要な業務で組織を支援します。PagerDutyを使用することで、組織は正確な優先順位付け、効率的な対応、運用上のオーバーヘッドの削減が可能になります。

今回のブログでは、新しい「ビジネス向けソリューションガイド」を使って、IT部門だけでなく、あらゆる部門の重要業務にPagerDutyを活用する事例をご紹介します。

人事部が社員と候補者の体験を向上させる

人事部は、現在働いている人、退職する人、入社を希望する人、全ての人に配慮する責任があります。人事部にとって重要な仕事は、賃金や税金の情報が常に最新であることの確認、従業員の迅速なオフボーディング、候補者の面接プロセスにおける直前の変更の調整など、多岐にわたります。このような重要な作業は、従業員や候補者の経験を確保するための鍵です。このようなワークフローに支障が生じると、優秀な候補者を逃したり、人材が減少したり、あるいはコンプライアンス上の問題が生じたりする可能性があります。

PagerDutyは、人事チームが刻々と変化する組織の状況を把握し、ワークフローが適切な担当者によって迅速に実行されるよう支援します。さらに、これらのワークフローを最適化することで、運用上のオーバーヘッドを削減し、何度も「リマインダー」メールを送信することに別れを告げることができます。

例えば、人事部門がオフボーディングを担当しているとします。オフボーディングのリクエストが来たとき、誰かの受信トレイに埋もれさせるわけにはいきません。オフボーディングのプロセスに遅れが生じると、リスクが高まるからです。そこで、オフボーディングリクエストごとに通知を設定し、すぐに適切な担当者に転送できるようにします。さらに、人事部がオフボーディングを完了した時点で、その社員のアカウントを削除するITチームに通知を再割り当てすることができます。

ITチームは、これが重要な作業であることを理解し、対応します。チケットを送信して、キューに入れられたワークフローで解決されるのを待つよりも、迅速に対応することができるのです。人事チームは、ITチームが作業している間に通知を見ることができ、フォローアップやメール送信の必要なく、プロセスがエンドツーエンドで完了したことを確認できます。これにより、オフボーディングワークフローの継続性が確保され、人事部門にとって価値の低い手作業が削減されます。最も重要なことは、タイムリーに従業員を退職させられないことから生じるリスクを軽減することです。

営業がお客様の取引サイクルを促進する

営業チームは会社の顔であり、収益を上げる重要な原動力です。営業は、対応力があり、有能で、親しみやすいと思われる必要があります。バックエンドでは、セールスエンジンをスムーズに動かすためのプロセスやワークフローが数多く存在します。このチームにとって重要な仕事は、顧客向け(重要な取引や見込み客のメッセージをカスタマーサポートに伝えるなど)、社内向け(月末の見積もり更新を迅速に行うなど)のものがあります。

PagerDutyは、営業チームが散らかった受信トレイを整理し、何が本当に重要なのかを理解し、生産性を維持・向上させることができるよう支援します。これにより、より効果的な営業チーム、より幸せな顧客、そしてより多くの成約を得ることができるのです。

営業担当者は、月末や四半期末になると特別に忙しくなることがよくありますが、これには理由があります。顧客には、購入時期や予算の都合で、特定の時期に特定の製品を購入することがあります。四半期末の残り1日で取引が成立する場合、営業担当者も顧客も、売上処理の遅れを待つことはできません。たった24時間でも遅れると、取引を延期しなければならなくなり、せっかくの機会も失われてしまいます。

このような事態を避けるために、営業担当者はSalesforceやその他の記録システムとPagerDutyの間のインテグレーションを設定することができます。最終的な見積書が承認のために送信されると、承認者がサインオフするまでキューに入れられる必要はありません。また、営業担当者がメールやメッセージで優先度の高い案件であることを伝える必要もありません。その代わり、インテグレーションによって承認者に自動的に通知が送られ、すぐにこのアクションを完了するよう促されるため、案件をクローズに向けて順調に進めることができるのです。

財務チームによる期限内の支払いと受領の確認

財務チームでは、ミスが許されないため、問題を遅滞なく修正する必要があります。全ての取引が正しい時刻に正しい金額で行われることを確認する方法が必要です。財務部門にとって重要な仕事とは、予定した支払いが完了しないこと、処理に失敗したこと、監査統制違反に迅速に対処することなどが考えられます。このような重要な業務を発見できないままにしておくと、会社の収益に大きな影響を与えることになりかねません。

PagerDutyを使用すれば、財務チームは、プロセスに障害が発生したときに、担当チームや担当者に警告するテキスト、電話、eメールによる通知によって、重要な作業への対応の遅れを最小限に抑えることができます。この通知を受け取ったチームは、直ちに状況の改善に着手し、全ての取引が指定された時間内に完了するようにすることができます。

例えば、毎月末の午後9時59分に正確に完了するようスケジュールされた夜間決済があるとします。支払期日から24時間以内に支払いが完了しないと遅延とみなされます。その月の最終日は土曜日です。もしチームが月曜日の朝になるまで支払いの失敗を発見できなかったとしたら、会社には遅延損害金が発生します。

この問題を軽減するために、財務チームは、夜間の支払い処理に通知を設定しました。支払いに失敗した場合、PagerDutyが担当者に電話やメールを送り、担当者はすぐに支払いを再送信し、予定通りに支払いが完了するようにします。

マーケティングはデータを使って正しい方向にピボットする

マーケティングはペースの速い部署です。このチームは、データに基づいた意思決定を行い、営業に適格なリードを提供すると同時に、顧客や見込み客を教育することに努めています。このチームにとって重要な仕事は、競合他社の動向や計画されたキャンペーンの変更を常に把握すること、重要な機会を注視することなどです。

PagerDutyは、マーケティングチームが常に最新の情報を入手し、迅速に対応することで、時間と予算を最大限に活用できるよう支援します。マーケティングチームは、MarketoやHubspotのような頼りにしているツールが使えないときや、企業や競合他社の発表に基づいてピボットするタイミングを理解することができます。

例えば、ある小売企業のマーケティングチームが、年に一度のセールに先駆けて大規模なメールおよびソーシャルメディアキャンペーンを実施する計画をしているとします。この企業は実店舗も持っていますが、売上の大部分と最もエキサイティングなプロモーションのいくつかはオンラインのみで行われます。そのため、お客様に最高の体験をしていただきたいと考えています。

この体験を確実に守るため、マーケティング部門は、オンラインストアでお客様に影響を与える問題が発生した場合に、電話やメールで通知するよう設定しています。この情報をもとに、マーケティング部門はキャンペーンを延期するかどうか、リリース直前に判断することができます。こうして、キャンペーンが開始されると、顧客は購入することができ、マーケティングチームはその投資に対するROIを得ることができるのです。

重要な業務は、全てのビジネスの未来

重要な業務は、IT部門だけのものではありません。顧客、見込み客、従業員体験を守るために、全ての部門が重要な業務に対処する方法を必要としています。

PagerDutyソリューションガイド業務用は、ソリューションガイドをご覧いただくことで、あなたのチームをどのように支援できるかを知ることができます。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

2022年7月18日  (更新日:2022年7月20日)    |    ニュース&告知

PagerDuty Summit 2022 ハイライト Part 2

PagerDuty Summit 2022の注目のセッションを紹介します。Part 2では、次の3つの講演を紹介します。

"Real Talk: PagerDuty’s Product Impact"PagerDutyの製品担当SVPのJonathan Rendeが、Anaplanの米州担当副社長兼カスタマーサクセス責任者のFiona Gillさんに、PagerDutyが彼らの最も重要な指標、チーム、そしてデジタルオペレーション全体に与える影響について、お聞きしました。 "Delivering Value: A two-way street"PagerDutyのチーフカスタマーオフィサーのManjula Talrejaが、LogicMonitorのCEOであるChristina Kosmowskiさんと対談し、企業が顧客と接する際に「価値」をどのように考え、PagerDutyが組織内でどのようにその価値を創造しているのかについて議論しました。 "Leadership in a Digital-First World"DocuSignのCEOであるDan SpringerさんとPagerDutyのCEOであるJennifer Tejadaがデジタルファーストの世界でのリーダーシップはどうあるべきかを対談しました。

2017年12月31日  (更新日:2022年7月14日)    |    インシデント&アラート

運用コマンドコンソールの中でビデオ会議をするには

フェイスツーフェイスで話をする。

プラットフォームになることの大きな点の1つは、ユーザーが、自分とは異なる方向に製品を持っていけることです。 私たちはあなたの好みの電話会議ツールをインシデント対応プロセスに組み込めるようにしました。以前自分のインシデント対応にビデオ会議を追加するんだと冗談を言っていたお客様には、どうやってオペレーションコマンドコンソール に追加するかを教えましたけれど。

私は、インシデントの間に私のブサイクな顔を見たい人がいるなんて思ってなかったんです!

以下は私たちがやった通りのソリューションではありません、オーバービューです。

iframeに埋め込むことのできるビデオ会議ツールを使用します。この例ではAppear.inを使用しています。 サインアップのプロセスがないので。

操作コマンドコンソールを開きます(まだこの機能を試していない場合は営業担当者に相談してください)。インシデントのコンテキストで表示する場合は、これをワークフローの拡張にすることもできます。

コンソール設定に移動し、「カスタムURLモジュール」を追加します。 これはしばらくの間ベータ版であった機能で、顧客はチャット、wikiページ、エーテルパッド、ステータスページをこのように埋め込んでいます。 私のURLはht​tps://appear.in/diligent-quailでした。

以上でおしまいです!

これで自分のチームがオペレーションコマンドコンソールを使ってインシデント対応を調整しているときに、お互いの集中している様子見てほめあうことができます。 次は、Snapchatフィルタを追加する方法を理解する必要があります。

あなたのチームがPagerDutyプラットフォームを拡張した妙だけど素晴らしい方法はいくつあります? [email protected]で電子メールを送って知らせてください!

2017年12月20日  (更新日:2022年7月14日)    |    インシデント&アラート

良いインシデント対応が金融機関への顧客の信頼を増す

「そこには金があるから」。悪名高い銀行強盗Willie Sutton(注:William Francis “Willie” Sutton, Jr. (June 30, 1901 – November 2, 1980))が言ったように、金融機関はセキュリティ犯罪の最大の被害者です。サイバー犯罪者がセンシティブなデータや金融資産を盗もうとする試みを止めるために、金融機関ができることはあまりありません。被害が増えているために金融機関は顧客と規制当局からますます厳しい監視を受けています。

事実、FDIC(Federal Deposit Insurance Corp.、連邦預金保険公社)の審査員は、必要とされるインシデント対応の最小要件ht​tps://w​ww.fdic.gov/regulations/examinations/supervisory/insights/siwin06/article01_incident.htmlを参照 を提示して侵害が判明した場合、規制当局と顧客に通知することを要求します。

しかし多くの金融機関は、進行中の損害に対してクリティカルなインシデント対応をすることにかかりきりになってしまいます。これは時間を浪費するだけでなく、組織の準備が整っていない、あるいは適切なセキュリティ管理策を講じていないという印象を残してしまいます。

インシデント対応計画を立てておく

規制当局は金融機関の規模に関わらず、より広いリスク管理基準でITセキュリティを日常的に監視していることを明らかにしています。そのため、セキュリティ侵害防止対策だけでなく、インシデント対応の有効性についても、金融機関に説明責任を課しています。完全なセキュリティは存在しませんが、金融機関はセキュリティ侵害が発見された場合、ただちに対応できなければなりません。また、迅速な解決と異なる部門間で効率的な緊急連絡の手段を備えていなければなりません。

そのため、金融機関にはIT部門の問題解決の方法から、財務、法務チームが迅速に規制当局とやり取りする方法、必要に応じて顧客と市場に情報提供する方法に至るまでの、対応計画が必要です。ビジネスへのダメージを軽減するには、セキュリティ侵害が発生したときに重要なステークホルダーを関与させるための明確な枠組みが必要です。このようなシステムを導入することで、財務的、法的に重大な影響を及ぼす可能性を見落とさないだけでなく、金融機関とその資産が健全であるという安心感を顧客や株主に与えることができます。

情報共有

そのために、インシデント対応フレームワークは、組織と顧客に対するセキュリティ侵害の影響を緩和するための透明なプロセスでなければなりません。例えばIT組織内の全員がインシデントの影響を評価するための手続きを理解し、適切な専門家を迅速に動員し、基本的なトラブルシューティングや修復を実施できる必要があります。さらに、組織内のステークホルダーは、IT担当者が誰かを正確に把握できるだけでなく、問題解決にかかる時間を顧客に知らせるためにどんな言葉を使うべきかをリアルタイムで理解する必要があります。

このようなベストプラクティスは自然に出来上がるものではありません。ビジネスリーダーとITリーダーはトーンを調整する必要があります。組織が適切なプロセス(定例の研修や実践を含む)を用意していれば、セキュリティ侵害や他の形態のITトラブルに自然に対処できるようになります。金銭的損害の出るセキュリティ侵害よりも唯一悪いこと、そして顧客の信頼を失う最速の方法は、顧客が金融機関そのものではなく、他のソースから問題を知ったときです。そのため、顧客には迅速に問題の発生を知らせる必要があります。

もちろん、サービスに問題があることを顧客に伝えるのは当然として、その問題がいつ解決されるかも正確に伝えられないと、顧客は他の金融機関への乗り換えを検討し始めるかもしれません。チームに適切なプロセスとワークフローが整っているかを常にチェックしましょう。

2019年5月10日  (更新日:2022年7月14日)    |    ベストプラクティス

Dutonianのような影:シャドーイングでオンコール学習

by Max Timchenko

オンコールシャドーイングをする理由

PagerDutyでは、オンコール中のシャドーイングは欠かせません。 新しいエンジニアにとって、シャドーイング期間は問題診断と解決のストレスや責任を一切伴わずに、より親切でスムーズなオンコール開始の準備として役立ちます。

PagerDutyでシャドーイングを設定するとき、「シャドーユーザー」の行動が実際にオンコール中の主任エンジニアに影響を与えないようにしながら、オンコールのプロセスとアクションをできるだけ正確にシミュレートすることが目標です。これにより、シャドーユーザーは安心し、気楽にしていることができ、主オンコール対応者も邪魔されずに行動することができます。

シャドーイングの使い方

最初のステップは、シャドーイング専用のPagerDutyアカウントを設定することです。 このシャドーアカウントに、シャドーイングをしているチーム用のサービスとeメールインテグレーションを追加します。チームが一度に1人のシャドーイングをしているだけであれば、チームごとに1つのサービスで十分です。同じチームに複数の人がシャドーイングしている場合、それでは済まない可能性があります。

このインテグレーションで使うメールアドレスは、プライマリー(メイン)のPagerDutyアカウントにシャドーユーザーへの通知方法として設定します。これは、チームをシャドーイングするためのプライマリーアカウントのオンコールエスカレーションポリシーに追加されます。

この設定の結果、インシデントが発生したときに、通知が主任オンコールユーザーとプライマリーアカウントのシャドーユーザーに送信されます。これにより、シャドーアカウントに同じ情報を持つ別のインシデントが作成されます。シャドーアカウントはシャドーユーザーに通知します。これは別のインシデントになったため、主任オンコールユーザーが対応しているという実際のインシデントのステータスを変更することなく、必要なこと(受任、スヌーズ、コメントの追加など)を実行できます。

この設定の副次的な利点は、一度設定するとプライマリーアカウントの設定をそのままに、シャドーアカウントを使ってシャドーする人の追加や削除、設定が完全にできることです。もう1つの利点は、週末やオンコールの引き継ぎ日などを除外するようにシャドーイングスケジュールを変更できることです。営業時間中にのみシャドーイングを設定することもできます(シャドーユーザーを本物のオンコールのローテーションに追加しないでください)。

「Dutonian」はStar Wars「The Old Republic」に登場するキャラクター。 「シャドーイング」とは初心者が技術習得のために教師役の行いをそっくり真似すること。

シャドーイングを設定する方法

ステップを詳細に見ていきましょう。手順のいずれかが不明な場合は、以下で使用されている設定手順の多くを順を追って解説する設定と対応者トレーニングのウェビナーをご覧ください。

シャドーアカウントを作成する

PagerDutyアカウントをまだお持ちでない場合は、無料トライアルをお申込みいただければこれを含めた設定が試せます。

プレースホルダーにユーザーを作成する

誰もシャドーイングしていない場合、このユーザーはシャドーアカウントのすべてのシャドースケジュールで使用されます。そして誰も呼び出しません。シャドーイングしている人がいると、対応するスケジュールでテキストボックスのユーザーを上書きします。

スケジュールを作成する

次の3つのエンティティ(スケジュール、エスカレーションポリシー、サービス)がチームごとと、同時に行われているシャドーごとに作成されます。これにより、すべてが整理され分離されます。単一のチームに単一のシャドーを設定している場合は、必要なのは1セットだけです。

この例では、架空の 「Labs」チームを使用しています。 テクストボックスのユーザーをスケジュールに追加し、自分のチームに最適なオンコールスケジュールの作成をします。

エスカレーションポリシーを作成する

新しく作成したスケジュールをエスカレーションポリシーに割り当てます。

サービスを作成する

プライマリーアカウントでシャドーユーザーを作成する

プライマリーアカウントに切り替えて、シャドーアカウントのイベントを生成するシャドーユーザーを作成します。シャドーアカウントに複数のシャドーサービスがある場合でも、チームごとに1人のシャドーユーザーしか設定できません。連絡方法に対応するすべてのシャドーサービスにすぐにメールを生成するように通知ルールを設定します。複数のEメールアドレスを設定することで、1人のユーザーがすべてのシャドーサービスに通知できます。対応するすべてのシャドーサービスにすぐにメールを生成するように通知ルールを設定します。

シャドーユーザーをプライマリーアカウントのエスカレーションポリシーに追加する

プライマリーのPagerDutyアカウントで、「Labs」チームのオンコールエスカレーションポリシーをスケジュールしている可能性があります。 誰がオンコール中かに関係なくシャドーユーザーに通知されるように、そのスケジュールと一緒にシャドーユーザーをエスカレーションポリシーに追加します。

重要:Shadow Userをエスカレーションポリシーに直接追加しないでください。追加すると、この人物の行動が実際のインシデント処理を妨げる可能性があります。

設定のテスト

これで設定は完了です。 実際に動作するかをテストできます。プライマリアカウントでチームが使用しているサービスを選択し、手動でインシデントをトリガーします。

インシデントはプライマリーアカウントに表示されます。

インシデントはシャドーアカウントにも表示され、プレースホルダユーザーが呼び出されます。

シャドーインシデントを受任して解決しても、プライマリーアカウントのインシデントには変更が加えられていないことに注意してください。 これで完璧です。

シャドーイング用のユーザーの設定

シャドーしたい人がいるときは、シャドーアカウントに招待してください。通知方法やその他のユーザー情報を通常どおりに設定するようにユーザーに依頼してから、それをシャドースケジュールに上書き設定します。シャドー期間が終了したら、ユーザーを削除します。

スケジュールメモ

PagerDutyでは、シャドーイングのためのサービスとスケジュールを別々に持つことで、シャドーイング時間を変更できます。週に7日、1日24時間などというプライマリーのスケジュールに従うのではなく、週末を除外したり営業時間のみにしたりすることで、シャドーイングの負担を軽減することができます。

「オンコールシフト時間を制限する」には特定の日を除外するのが最も簡単な方法です。営業時間のみのシャドーイングを設定するのはシャドーサービスで簡単にできます(例:「対応者に通知する方法」および「定義されたサポート時間を使用する」)。

注意:シャドーイングプラクティスを設定する際に、シャドーがオンコールローテーションに追加されると、それはプライマリーのオンコールになります。そしてシャドーがエスカレーションポリシーに追加されると、そのアクションはインシデント処理に影響します。

どのようにしてシャドーを私たちの文化に吹き込むか

PagerDutyのシャドーイングプラクティスは誰でも見ることが出来ます。これは、会社の全員にPagerDutyの機能を知ってもらいたいがためです。社内での立場に関係なく、PagerDutyを使用してエンジニアリングチームのシャドーイングに1週間かけて機能と使用方法を理解させることをお勧めします。週単位のオンコールローテーションを実施しているチームの中には、週末と次の担当者に引き継ぐ日を除いた時間をデフォルトのシャドーイングスケジュールとしているところもあります。これですと、週4日、1日24時間の「シャドーイングシフト」が成立します。

チームのほとんどは、シャドーイングを開始したい時期と、オンコールローテーションに参加する準備ができた時期を新しいエンジニアに決定させます。チームの期待するところは、シャドーイングは最初の3カ月のうちに始まり、責任と失敗を非難しないことを共有する文化は、シャドーイングから本番のオンコールへの移行の垣根を低くします。

PagerDutyのシャドーイングの設定方法が理解できたら、この重要なプラクティスを利用してオンコールの経験を改善し、エンジニアの円滑な参加を促進してください。

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

2018年6月15日  (更新日:2022年7月13日)    |    インテグレーション&ガイド

Zenoss 3インテグレーションガイドを追加しました

Zenossは、普及しているオープンソースネットワーク、サーバーおよびアプリケーション監視システムです。あらゆるオープンソース監視システムで利用可能な最高のイベント管理システムの1つを提供します。Zenossのプラグインアーキテクチャにより、誰でも簡単に利用できるようになりました。PagerDutyは、PagerDuty APIを使用してオンコールスケジュール、アラート、インシデント追跡を提供することで、Zenossの機能を拡張します。 このガイドでは、Zenoss 3のインストールをPagerDuty ZenPackにインテグレートする方法について説明します。

詳しくはこちら

2018年3月9日  (更新日:2022年7月11日)    |    インテグレーション&ガイド

BMC Service Deskインテグレーションガイドを追加しました

BMC Remedy Service Deskは、モバイル向けにネイティブで構築された革新的なサービス管理プラットフォームです。美しく直感的なユーザーエクスペリエンスを提供します。BMC Remedyを使用すると、PagerDutyユーザーは、フォームに注意が必要な内容が記入されたときにアラートを受け取ることができます。

詳しくはこちら