Category
ベストプラクティス

2022年8月12日  (更新日:2022年8月12日)

今こそ、その先へ。Arrayの進化

Words Like Freedom

There are words like Freedom フリーダムなんて言葉がある

Sweet and wonderful to say 口にすると甘く素敵な響き

On my heartstrings freedom sings 琴線に触れる自由の歌の数々

All day every day. 毎日毎日耳にする。

There are words like Liberty リバティなんて言葉がある

That almost make me cry 聞けば泣きそうになる

If you had known what I know 僕のことを知っていれば

You would know why. なぜだか分かるよね

Langston Hughes

(訳注:Freedomは束縛からの自由、Libertyは行動する自由) 初日、4年前 2018年2月15日(木)、今年最初のタウンホールで、私は同じブラックデュートニアン(PagerDuty社員)のAdam Booneと共に立ち、Langston Hughesの詩「Words like Freedom」から上記の言葉を全社に読み上げました。その日、私たちはPagerDutyで初めてのブラック&ラテン系従業員リソースグループ(ERG)であるArrayを紹介しました。今思えば、入社してまだ2カ月目、このステージでマイクを握らされ、私たちの声を聞いてもらう機会を与えられたのですから、緊張しました。アメリカでキャリアを積んできた黒人女性として、マイクを渡され、心から発言することを許されたときほど嬉しいことはないでしょう。これこそ、私が言うところの「リバティ」です。この場に至るまで、何の障壁もなく、日時を指定されたので、ただ来て、始めたのです。この時、PagerDutyではこういう仕事ができるんだと思いました。

PagerDutyのおかげで、インクルージョン、ダイバーシティー、エクイティーに関して、私たち全員が果たすべき役割を理解することができました。私の経験を通じて、Arrayの旅について、そして私たちが1カ月のお祝いを超えて、私たちの周りの人々(ブラック、ラテン、そして味方)を育てるための継続的なプログラミングに移行していることをお話ししましょう。この物語の一部では、私が働いている職場で、帰属意識と公平性のある場をつくるためにERGというプラットフォームをどのように利用したかを紹介しています。

振り返り

私が初めてPagerDutyに来たとき、多くの有色人種がそうであるように、ここに「私たち」が何人いるか数えてみたんです。幸いなことに、私が前にいた場所よりも多かったので、言うまでもなく、私は興奮しました。他の黒人やラテン系のデュートニアンに出会い、一緒にランチを食べたり、会議室でERGの名前、ミッション、ビジョンについてブレストしたりして、すぐにここPagerDutyでのコミュニティー意識を持ったことを覚えています。

Arrayのミッションは、ブラック&ラテンアメリカの生きた経験への共感と理解を育む、継続的な学びのコミュニティーを可能にすることです。

ビジョン:PagerDutyの多様で包括的なグローバル職場環境を育成・賞賛することで、黒人・ラテン系従業員の活躍の場を均等にし、多様な顧客層を代表する人材を継続的に獲得すること。

私は、"これは、私の祖先が公民権運動を計画していたときに経験したことなの?"と考えました。可能性はありますね。PagerDutyでの時間を振り返ってみると、最も長く在籍しているArrayリーダーとして、Arrayは私とPagerDutyに多くのものを与えてくれました。私たちは、どのような不快な会話が交わされる可能性があるかを共に学び、私たちに直接影響を与える難しい社会問題を解決するために、黒人とラテン系の従業員に自分のスペースを持つことを許可し、味方のために黒人とラテン系の経験を知ってもらうための学習機会を作りました。

私たちは先の長いゲームに参加しています

昨年、未来の働き方を研究する中で、カリフォルニア大学バークレー校のOthering & Belonging Instituteのディレクター、John Powell から”universal belonging”(普遍的貴族意識)という言葉を学びました。普遍的帰属意識とは、人々の間にある一体感や感覚のことです。意見、人種、信条、階級、宗教の違いに関係なく、人々を結びつける感覚です。多くのArrayのメンバーが去っていきましたが、私はArrayの中で過ごした時間と経験によって、私たちがどのようにこれからの仕事を生き抜いていくのか、そして、分散した世界の中で分離された私たちが帰属の場を作るにはどのような仕事が必要なのかを理解できました。パンデミックや危機は自己満足している時ではないことを、私はArrayの進化を通して学びました。

PagerDutyの価値観である”Bring Your Self”、”Take the Lead”、”Run Together”によって、Arrayは成長し、一体感がより重要視されるようになりました。長年にわたり、私たちはPagerDutyでこの一体感を作り出し、他の人たちを連れてくることを許可され、特権を与えられてきました。

私たちは、人種についていつ話すべきか、いつ話すことができるか、また、私たちが誰であるかを認めあえるかについて、暦上の月に左右されるわけにはいきません。実際、歴史を祝う日や月があっても、過去を消し去ることはできませんし、現在そして将来にわたって私たちが直面する問題を解決することはできません。この4年間、私はArrayのリーダーシップ、会員数、プログラムへの参加、イベントへの参加などの成長を目の当たりにしてきましたが、それは私たちが取ってきたゆっくりと進む行動によるものでした。そして、2022年。Arrayのメンバーは90人を超え、Arrayの中に「Array-Black」と「Array-Latine」というサブグループを作り、それぞれのディアスポラに対してユニークな体験を提供できるようにしています。私たちは、「黒人歴史月間」「ヒスパニック・ヘリテージ月間」の枠を超え、つながりや成長、コミュニティ形成を促進する継続的なプログラムを通じて、つながりや変化をもたらすことを目標としています。また、昨年は初めて”Inclusion Survey”のデータの報告を受け、会員のニーズに対応したプログラムやイベントを実施するための参考としました。 会員数が増え、データが蓄積されたことで、他の優れたチームと同じように、私たちも進化と拡大を遂げることができるようになりました。私たちは、黒人やラテン系の人材が職場でより良い未来を実現できるよう、周囲に影響を与えることで歴史を刻んでいきたいと考えています。元の状態に戻るよりも、より公平に私たち全員のためになるニューノーマルに到達できるのでしょうか?

変革にはリーダーシップが必要

真の変革には、アカウンタビリティと、それを実行しようとする真のリーダーが必要です。ArrayがERGになった直後、CEOのJennifer Tejadaは、アレイのリーダーとじっくりと話をしたいと言ってきました。その姿は、今でも鮮明に覚えています。彼女は部屋に入ってきて、座って、"私に何ができるのか "と言ったのです。それがきっかけで、あとは歴史に残ることになりました。それ以来、ArrayはCEOとつながり、関係を築き、Alec Gallimore、Elena Gomez、Bonita Stewartといった黒人とラテン系のボードメンバーにアクセスできるようになり、Arrayメンバーとシニアリーダーによる初のERG主催のメンターシッププログラムを始めるためのスポンサーとなり、ビジネスと社員体験というレンズを通してメンバーが直面しているさまざまな課題にどう取り組むかを意識させることができるようになったのです。Jennの魅力は、Arrayのことに関して答えを知っているふりをすることなく、四半期ごとのアップデートミーティングでは時間をかけて話を聞き、解決策を見つけるサポートを惜しまないことです。

未来への展望-コミュニティーの構築

パンデミックの "ジュニアイヤー "だと聞いています。私が高校生の頃を思い出すと、3年生といえば、高校卒業後の進路について真剣に考える年でした。ある意味、今日のアレイは、私たちの将来について真剣に考え、帰属意識を持てるようなポケベルデューティのコミュニティーの強さを構築しているのです。私は、リーダーたちがアイデアを持ち寄り、それを実現することで、コミュニティ内での定着率とエンゲージメントを高めることにコミットしていることに、とても興奮しています。このような継続的なつながりがあれば、誰もが毎日仕事に打ち込み、お互いのため、お客様のためにベストを尽くすことができるようになると信じています。今年、私たちは以下のような形で、継続的なコミュニティづくりを推進しています。

不快な会話につなげる-。私たちは、会話には力があると信じているからこそ、「Spill the Tea」の対話を続けています。このようなメンバー同士の親密な会話は、自分自身を表現し、今一番気になっていることについて本音で語り合うための安全な場となります。毎月1回開催し、組織横断的にメンバー同士が気軽にぶつかり合える場を設けています。 アライメンバーとリーダーをつなぐ-。このプログラムは、シニア・リーダーシップ・チーム(SLT)のメンバーが、黒人と茶色のデュトニアンのキャリアを発展させるための指導を行い、同時に、職場内外の黒人と茶色のコミュニティをサポートするためのアライシップのベストプラクティスを学ぶために企画されたもので、2年目に突入しています。また、職場の内外で黒人や褐色人種のコミュニティを支援するためのアライシップのベストプラクティスを学ぶこともできます。

このプログラムは、私に「ドリームビッグ!」という自信を与えてくれました。 私は素晴らしい指導者に恵まれました。彼は、私に自分の考えを話す時間を十分に与えてくれました。彼は私の話に耳を傾けるだけでなく、聞き、自分の個人的な話をすることで私と弱さを共有し、何でも可能であることを教えてくれたのです。 —2021 Array mentee, Meley Bekele アレイメンバー同士をつなぐ -。 会員数の増加に伴い、「Reach One, Teach One(ROTO)」シリーズを開始します。このシリーズでは、会員を対象としたアンケートの結果をもとに、行動を起こしていきたいと考えています。会員の皆さんは、キャリアの節目や決断をどのように乗り越えたらよいかを話し合う場を求めていました。このような会話を始めるには、自分のコミュニティ内で行うのが一番良い場合もあります。私たちは、隔月でこのセッションを開催しています。 トピックを1つ選び、視点、アドバイス、洞察を共有します(一部のトピックは会員のリクエストに応じます)。 プロセスに関する実用的なヒントを提供します。 前に進むための意識を高めるために、本音で語り合い、厳しい質問をする安全な空間を作る。

より大きな目的へとつながる- 私たちは、先人たちの犠牲なくして、このような機会を得ることはできなかったと認識しています。今年も、ID&Eチームとソーシャルインパクトチームとのパートナーシップを維持し、社員とコミュニティのために時間を割くことを徹底していきます。2月と9月・10月には、黒人系・ラテン系企業の声を意図的に増幅させ、それぞれのヘリテージを祝いました。今後も、大小さまざまな取り組みを通じて恩返しをし、あらゆる面で周囲の人々を高めていけるよう、努力を続けていきます。過去および現在のパートナーシップは以下の通りです。 デイズ・フォー・チェンジ コード・テンダーロイン MLKミドルスクール(サンフランシスコ ウィメンズ・ビルディング(サンフランシスコ ニュー・ジョージア・プロジェクト アトランタミッション コベナントハウス・オブ・ジョージア エンパワー アトランタ・コミュニティ・フード・バンク

未来に希望を持ち続けること

なぜなら、変化とは最終目的地ではなく、正義であるからです。年々、私たちは意識と認識を高め、プログラミングを繰り返し、一度に一人ずつに影響を与えることを学ぶ意欲を持つようになることが、私の望みです。アレイは、私たちが誰であるか、どのように他者に影響を与えるか、そして人々を第一に考えたときにどのような変化が起こりうるのか、その見本となるにはどうしたらよいか、私たち全員が学ぶべきことがあると教えてくれました。真の自由と解放は、すべての人が意志を持ち、ひとつの人間として学ぶことを許されているときにのみ訪れるのです。アレイは、その学びのプロセスを支援できると思います。私は、過去と現在のArrayのメンバーが、長年にわたり、個人的、職業的な経験や物語を私と共有してくれたことに、永遠に感謝します。そのような体験談や経験が受け入れられ、今日のArrayのコミュニティーの核となっているのです。

What Makes Array

No two stories the same

A mix of melanin we call by name

A space for an unfiltered tone

A community I can call home.

Filled with pride and emotion

I don’t feel like a token

Always there on a day like today

Moving us forward, this is Array

—Phylicia Jones

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

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

カスタマーサービス・オプス - 新機能リリース

ここ数年、ストリーミング、ショッピング、仕事、ヘルスケアなど、私たちの世界はますますデジタル化しています。顧客は、これらのデジタル体験がシームレスであることを望んでいます。これは、すべての企業にとっても重要な優先事項となっています。なぜなら、企業の売上やブランドの評判は、お客様の満足度に左右されるからです。

このようなシームレスなデジタル体験を保証するために、テクノロジーチームは信頼性、ユーザー体験、新機能の構築に倍旧の努力を払ってきました。しかし、デジタルの世界は完璧ではありません。問題が発生した場合でも、顧客を安心させ、維持するために、企業はこれまで以上にカスタマーサービスチームを必要としています。

PagerDuty for Customer Serviceは、カスタマーサービスチームがプロアクティブになり、ケースに費やす時間を短縮し、SLAを達成し、比類のないレベルのカスタマーサービスを提供できるよう支援します。

昨年秋、Salesforce Service Cloud 用の PagerDuty アプリケーションを発表しました。これにより、ユーザーは Salesforce Service Cloud で直接作業することができ、コンテキストスイッチの必要性が減りました。これにより、カスタマーサービスチームは、迅速かつ効率的に、そして部門を越えて仕事をすることができるようになりました。今回、カスタマーサービスユーザーのために、さらに多くの機能を発表できることを嬉しく思います。これらの新機能により、チームは顧客に影響を与える問題の影響範囲を把握し、より迅速に対応できるようになります。

インシデントサブスクリプション

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

ダッシュボードトグル

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

PagerDutyのインシデントタイトルをSalesforceのデータでカスタマイズする

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

PD WebでリンクされたSF案件の可視化

インシデントが顧客に与える影響範囲や、問題によって影響を受ける顧客の数を気にしたことがありますか? もう悩むことはありません。PD Web、モバイル、電子メールのいずれでも、PD for Customer Serviceはインシデントに関連するケースをリンクしてレポートします(逆もまた然り)。なぜでしょうか?カスタマーサービス担当者は、受け取ったケースの数に基づいて、特定のインシデントの緊急性を正当化することができるからです。また、インシデント対応では、障害に対してどれだけの顧客が不満を抱いているかを確認することができます。結局のところ、顧客はデジタル資産の健全性を示す重要な信号なのです。

これらの新機能により、サポートチームとレスポンスチームの間のサイロを継続的に解消し、あらゆるインシデントに迅速かつ容易に対応するための方法を、カスタマーサービスチームに提供しています。これにより、カスタマーサービス担当者は、ケースを最初から最後まで自分で管理できるようになります。

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

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

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

PagerDuty、新たなフィランソロピー・パートナーとともに不公平を是正し、気候変動への対応に取り組む

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

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

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

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

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

未来のワールドリーダーへの投資

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

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

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

-Catherine Mongella, Executive Director, Earth Guardians

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

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

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

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

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

– Chisato Fukuda Calvert, Interim Director, OpenAQ

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

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

-Gloria Walton, CEO of The Solutions Project

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

支援・奨励

パートナーであるアース・ガーディアンズが示しているように、若者主導の気候変動運動は、フィランソロピーにこの緊急事態に対応するよう働きかけています。パートナーから得た洞察と学習は、制度的差別に対処するアプローチを進化させるために、私たちの戦略に反映され続けます。私たちは、これらの優れた団体を支援できることを光栄に思うとともに、すべての人間と地球の健康を守るためのこの取り組みに参加されることをお勧めします。

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

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

ラウンドロビンスケジューリングを成功させるためのポイント

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

Round Robin Schedulingの仕組みは?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まだお客様でない方は、以下の方法でお試しできます。現在ご利用中のお客様で、この機能へのアクセスを解除するためのアップグレードをご希望の場合は、PagerDutyアカウントチームまでご連絡ください。まだお客様でない方は、以下の方法でお試しいただけます。この機能を14日間無料でお試しいただけます。

Round Robin Schedulingの詳細については、こちらのサポートドキュメントをご覧いただくか、こちらのYouTubeショートムービーをご覧ください。

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

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

イベントオーケストレーションの活用でノイズを減らし、次善の策を講じる

お客様からは、管理しきれないほどの大量のノイズや複雑性に対処しているため、根本的な原因を突き止め、迅速に解決することが難しいという声をよく聞きます。ノイズの選別、イベントの処理、コンテキストの収集に費やす労力は、多くの時間を浪費することになります。

そこで私たちは、イベント・オーケストレーションを発表し、月曜日にイベント・インテリジェンスとデジタル・オペレーションをご利用のお客様に一般提供を開始しました。

PagerDutyのイベントオーケストレーション担当シニアプロダクトマネージャーであるFrank Emeryに、この機能を構築した理由と、お客様の行動やフィードバックがどのように開発の方向性を決定したのか、その背景を詳しく聞いてみました。

Q: 新機能のイベントオーケストレーションについて教えてください。

A: PagerDutyのプラットフォーム全体で見ると、20%のインシデントが5分以内に解決されています。解決が難しい大きなインシデントを5分以内に解決できることはありません。このことからわかるのは、インシデント対応には、診断テストの実行やサーバーの再起動など、必要ではあるが手作業に近いプロセスが存在し、それがチームの時間を奪い、生産性や集中力を低下させていることです。このようなケースでは、的確な自動化によってインシデントレスポンス時の手順を短縮することが可能です。場合によっては、インシデントを担当から外すこともできるかもしれません。これらのユースケースを、解決時間が15分や30分のインシデントの原因となる反復タスクに拡大すると、時間の節約、生産性、集中力の向上の可能性はさらに高まります。

それは、「インシデントが発生したときにチームが常に行っている手作業や繰り返しの作業に費やす時間を削減するために、お客様が当社のプラットフォームを利用できるようにするにはどうすればよいか」ということです。自動化を構築することで、レスポンダーが処理しやすいイベントの数を減らし、実際に彼らの専門知識が必要なインシデントに時間を割くことができるようにするには、どうすればよいでしょうか。

イベントオーケストレーションについて考えるとき、もしお客様がルールを設定する方法をより柔軟にし、より多くの自動化機能を前もって使用できるようにすれば、チームが通知を受ける前に、これらのよく理解されているタスクをできるだけ多くカバーすることができるのではないでしょうか。

Q: イベントオーケストレーションは、イベントルールとどのように違うのですか?

A: 私たちが効果的に行ったのは、Event Rulesを利用して、イベントの取り込みパイプラインに直接設置する意思決定エンジンを構築したことです。イベント・オーケストレーションでは、複雑なロジックで構築された新しい条件言語を使用して、条件に基づいて次善のアクションを大規模に起動することができます。ある例では抑制、ある例ではルーティング、あるチームではリアルタイムに取り込まれる自動診断や自動修復などの自動アクションを起動したいと思うかもしれません。

オーケストレーションで特定の状況を処理するように設定すると、マシンはロジックを使用して特定の状況を識別し、その状況に基づいて対処方法を決定します。これにより、誰かが通知を受ける前に、意思決定エンジンがこれらのタスクのいくつかを処理する道が開かれ、そもそも人間が必要な場合には、インシデント対応プロセスを実際に補強し始めることができます。

Q: イベントオーケストレーションの利用を検討されている方にとって、ハードルの低い利用例とはどのようなものでしょうか?

A:お客様のことを考えると、まず2つの使い方のどちらかをされることが多いでしょう。

1つ目は、ノイズリダクションです。ノイズは非常に一般的な問題で、スタックを監視するために接続されるすべてのツールや、それらがどのようにアラートを送信するかを考えれば、驚くことではありません。私たちは、重複排除や抑制といった他の機能や、インテリジェント・アラート・グルーピングといったMLオプションも用意していますが、お客様の中には、より正確な情報を得たいと考えている方もいらっしゃいます。ノイズリダクションのためにイベントオーケストレーションを使用すると、ユーザーは正確なルール条件を利用して、非常に多くのターゲット状況を設定し、チームのためにノイズを偏向、統合、抑制して、重要な信号のみを通過させることができます。

2つ目は自動化です。自動化がどこまで高度になるかは、運用の成熟度によって異なります。インシデントレスポンスの初期段階を自動化できる可能性は非常に高く、その手順の多くは実際には非常に反復的なものです。

最もノイズの多いサービスについて考えてみてください。そのサービスのインシデントのうち、同じ初期診断手順を必要とするものがどれだけあるか考えてみてください。エンジニアからよく聞く話ですが、障害が発生すると必ず電話がかかってきて、問題解決のために誰かが何かを始める前に、毎回このような手順を踏まなければならないそうです。通常、これらのステップはスクリプトを実行したり、正しいコンテキストを見つけるために情報を収集したりするものです。診断の自動化は、多くのシナリオで必要とされるこれらのよく知られた反復タスクの自動化を開始するには、このシナリオでは最適な低空飛行の果実と言えます。

もっと詳しく知りたいですか?イベントオーケストレーションの詳細については、ナレッジベースの記事、またはこちらのデモをご覧ください。

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

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

インシデントレスポンスの向上には、(非インテリジェントな)スウォームをコントロールすることが必要です。

事件が起こる。物事がうまくいかない。システムが故障する。時には、予期しない劇的な方法で失敗し、重大な事故が発生することもあります。PagerDutyは、インシデントとインシデントを非常に明確に区別しています。あなたの組織でもそのような区別をしているかもしれません。

インシデントが重大かどうかの判断は、影響を受けるサービスの数、顧客への影響、インシデントの期間など、多くの要因、または特定の要因の組み合わせによって決まります。

これらの要素には、少なくともベースラインの遠隔測定と、技術エコシステムを構成するサービス間の関係性の把握が必要です。このベースラインがなければ、インシデントのトリアージにおいて、実際の影響やどこから手をつければよいかを知ることは困難です。

重要なデータがない場合、どうなるのでしょうか?次のようなデータがないと、インシデントに対応するのが難しくなります。

どのサービスが影響を受けるのか? どのサービスにどの程度の影響があるのか? そのサービスの所有者は誰ですか?

このようなデータがない場合、インシデント対応にスウォームアプローチを選択する組織もあります。

スワーミングとインテリジェントスワーミングの比較

スワーミングとは、組織内の全員に問題が発生したことを知らせ、問題解決に貢献できる可能性の有無にかかわらず、全員が参加できる大規模なウォー・ルームや電話会議を開くインシデント対応のアプローチです。インシデントの影響を軽減するためには、適切な人材を適切なタイミングで動員することが極めて重要です。スウォーミングは、適切な人が適切な時間に適切な場所にいることとは正反対で、全員がずっと参加することです。

インテリジェントスワーミングという言葉は、今月初めにお話しした、特にVIP向けの接客対応ワークフローを指す言葉として使われています。これはやや異なるアプローチで、最初にケースを拾ったチームメンバーが解決まで見届けることを指定し、問題解決を支援するために組織内のリソースを引き込む能力を持つものである。一般的なレスポンススウォームと関連しますが、インテリジェントスウォームの焦点は通常、単一の顧客であり、その体験を中心に据えることです。

一般的なテクニカルインシデント対応のためのスウォームは、建物の火災報知器のように、全員が厳戒態勢で、対応することが期待されています。基本的には、何らかの知識を持つ可能性のある人すべてにアラートが送信され、インシデントに参加するよう求められ、その後、誰がトリアージと修復を行えるかを見極める手間のかかるプロセスが開始されます。

組織はしばしば、自社のサービスやエコシステムについて十分な情報を持っていなかったり、利害関係者に情報を提供するための強力なコミュニケーション手段を持ち合わせていないために、群れをなしてしまうことがあります。何かが起こったとき、何が問題なのか、どこで起こっているのか、誰がどうすれば解決できるのか、誰もわからない。だから、自分が何か重要な知識を持っているかもしれないと、誰もが動員される。このため、スウォーミングは非常にコストがかかる。仕事は中断され、タスクやミーティングは頓挫し、リソースは有効でない場所に取り残されることになります。何百人もの人が、実際に対処できるのはほんの一握りである事故への対応のために動員されるかもしれない。むしろ、支障なく仕事を続け、適切なアップデートを受け取ることができるかもしれないのだ。

スウォーミングアップも大変です。多くの応答者がいる大規模な通報は、騒がしくて混乱することがあります。スウォーミングは、明確な調整や責任の所在が不明確なため、インシデントの復旧プロセスを遅らせることになります。中央の組織や意思決定権がない中で、あらゆる方向から情報が入ってきます。チームは、他のサービスへの影響を十分に理解しないまま、自分たちのサービスを復旧させようとするかもしれません。 スウォーミングアップは、私たちがインシデントコマンドを明示的に実践している理由の一つです。混乱を減らし、事態を悪化させることなく、できるだけ早くインシデントを解決するためです。

スワーミングは、自分たちのシステムが影響を受けていると判断された時点で人員を投入するのではなく、最初の警告からインシデントコールに必要な人員を常に配置できるとチームが考えているため、安心感があります。オンコール体制を改善することで、復旧に人員を割けないのではないかという不安を取り除くことができます。オンコールのローテーションを明確にし、責任分担を決めておくことは、いつオールコール・ページが来るかわからないと心配するよりも、対応者のストレスが軽減されるのです。応答者は、特定の日や時間帯にオンコール・シフトがあることを知っていれば、前もって計画を立てることができます。群発シナリオでは、必要な人材が不在になる可能性があります - 彼らは24時間365日オンコールで対応できるわけではありません。

スウォームからの移行

スウォーミングからプロセスを改善するには、サービスとそれを所有するチームについてのチームの考え方を変える必要があります。PagerDutyでは、この実践を「フルサービスオーナーシップ」と呼んでおり、これについてはOpsガイドで詳しく説明しています。連携したインシデント対応という文脈では、サービスの所有権はいくつかのことを意味します。

1つのチームが、本番環境でのパフォーマンスを含め、そのサービスに対する全責任を持っている。 そのチームには、そのサービスに関する問題が通知されるための文書化されたプロセスがあります。一般に、これはオンコールスケジュールである。 そのサービスが消費する依存関係が文書化されている。

あなたの組織には、現在、明確な所有者がいないサービスがあるかもしれません。それらは、もはや積極的な開発や注意を払う必要のない成熟したプロジェクトやレガシー・プロジェクトかもしれません。ベンダーと共同で保守している商用オフザシェルフ(COTS)製品、SaaSソリューション、あるいは組織の変更で孤立した内部サービスかもしれません。サービスが本番環境の中にある場合は、ベンダーのアップデートを受信するためにチームの電子メールエイリアスを登録するだけでも、サービスを監視するチームを作る必要があります。あなたの環境で稼働しているすべてのサービスには、明確に責任を負うチームが必要です。これらのサービスは、インシデントに巻き込まれたり、セキュリティ更新などの作業を必要としたりする可能性がまだあります。組織によっては、レガシーエンジニアリングチームやプラットフォームエンジニアリングチームが、これらのサービスの責任者になっている場合もあります。

サービスを1つのチームに割り当てることで、環境内で誰が何を所有するのかに関する混乱を減らすことができます。チームは、自分が所有するサービスについて新しいメンバーを教育し、最も影響力のあるサービスのSLOに管理することができる。サービスディレクトリを作成し、誰に通知すべきかを記載したチームの所有権構造を補完することで、組織内の全員に、問題が発生したときに相談できるリソースを提供することができます。PagerDutyでは、チームとエスカレーションポリシーをサービスに添付することで、これを実現しています。

エスカレーションポリシーは、サービス上のインシデントに対応するために、誰が利用可能であることが期待されるかのガイドラインを設定します。この場合の対応者は、影響を受けるサービスに精通し、問題のトリアージと修正を行うための適切なアクセス権を持つ人物であるべきです。

明確な依存関係モデルは、サービス間の関係を確立し、対応者、サポート、利害関係者が、あるサービスでの事故が環境内の他のサービスにどのような影響を与えるかについて明確に把握できるようにします。PagerDutyはさらに一歩進んで、ビジネスサービスを提供し、技術サービスを互いにリンクさせるだけでなく、それらが貢献する顧客向け機能にもリンクさせます。すべての技術サービスとビジネスサービスは、サービスグラフに表示され、そのサービスのために現在オンコールしているチームメンバーへの便利なリンクも表示されます。

このインフラデータ(特に依存関係モデル)を構築することは、あるサービスに対して最新の状態に保たれていない場合、多くの労力を要することになります。しかし、バックエンドのサービスに対するインシデントの影響を完全に把握することは、その問題が発生しているサービスを消費している他のサービスが分からなければ不可能です。

カスタマー・サポート・チームも、この作業から利益を得ることができます。インテリジェント・スワーミングは、サポート・チームがこれらの情報をすべて手元に置いておけるかどうかにかかっています。顧客が解決策を必要とするとき、チームはすべての正しい情報を見つけ、適切な人材を動員することができなければなりません。

インシデントコミュニケーションの改善

インシデントレスポンスは、観客を楽しませるスポーツではありません。チェックやプロセスの実行を待ち、エラーメッセージを追跡し、再起動を待つ時間が長くなることがあります。この作業が行われている間は、あまり変化がありません。しかし、これらの作業が進行している間でも、修復に直接関与していない人々は、何が起こっているのかを知りたがります。強力なインシデント・コミュニケーション・プランがないことも、チームがスウォーミングに頼る理由の一つです。もし誰かが何が起こっているのか知りたければ、解決にどんなに時間がかかっても、通話に参加して聞くしかないのです。

重要なインシデントのための強力なコミュニケーション・プランをあらかじめ決めておくことは、内部ユーザーが何が起こっているのかを常に把握できるようにすることと、外部ユーザーに情報を提供することの2つの機能を備えています。インシデント対応ガイドでは、インシデント発生時のコミュニケーションについて、「顧客リエゾン」と「社内リエゾン」という2つの役割を明記しています。この2つのグループには、それぞれ異なるアップデートを行うことが予想されます。組織によっては、インシデントについて公表する内容を検討したり、特定の表現を使用したりする必要があります。そのため、テンプレートを作成し、特定のチームメンバーをコミュニケーション担当として任命することで、この作業を容易にします。社内向けには、他のチームが自分たちのサービスに影響があるかどうかを判断できるように、より詳細な情報を提供することになるでしょう。

最良の計画は、すべての利害関係者に定期的に情報を提供することに基づいています。早めに、そして頻繁にコミュニケーションをとることで、状況が改善され、問題が解決されたときに、全員に知らせることができます。

NOCで群れる必要はない

第一線の対応者が汎用的なNOCチームである場合、最新のインシデント対応モデルに移行することが可能です。明示的なサービス所有権は、NOCがインシデントを解決できない場合、複雑な問題をサービス・チームにエスカレーションできることを意味します。サービスAを所有するチームのオンコール対応者を呼び出すことは、組織全体からさまざまな人を集めるよりもはるかに簡単です。

概要

対応方法を近代化することで、組織の時間とリソースを節約することができます。SAPのようなPagerDutyの顧客は、必要なときに必要な応答者だけを動員し、最も効果的な対応を提供することに集中できるという利点を享受しています。

もし、あなたのチームが解決までの時間を短縮し、大規模なスウォームコールの必要性を制限する方法をお探しなら、当社のインシデントレスポンス運用ガイドのリソースをご覧ください。フルサービスオーナーシップを実現するために必要なことは何でしょうか?当社のビデオをご覧になり、コミュニティ・フォーラムで同じ考えを持つ人々と話し合ってみてください。

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

続きを読む
ベストプラクティス
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年8月10日  (更新日:2022年6月14日)     |    ベストプラクティス

成長の機会を与えてくれたPagerDutyでのインターンシップ

私の名前はJoshua Carnide、Waterloo大学でソフトウェアエンジニアリングを学ぶ4年生です。この記事で、私がPagerDutyのトロント事務所でのインターンシップで得た素晴らしい経験と、それが成功のためにどうに役立ったかをお伝えしたいと思います。

私はPagerDutyのAndroidとiOSアプリケーションの維持と改善を担当するモバイルチームのメンバーでした。このチームの目的は、移動中にユーザーがPagerDutyプラットフォームとシームレスにやり取りできる機能を提供することです。小さなチームだったけど急速に成長していたチームでした。2018年1月に参加したとき、このチームにはわずか5人しかいませんでした。 3ヵ月後、2人のエンジニアリングインターン(私を含む)、製品管理のインターン、5人の常勤デベロッパー、アジャイルコーチ、製品オーナー、エンジニアリングマネージャーの計11人に増えました。 私はここでの4カ月間に想像していた以上に多くのことを学び、信じられない才能を持つ多くの人と出会い、エンジニアとして大きく成長できました。

PagerDutyの人々:多様性と包括性

PagerDutyの人々は驚くべき人ばかりでした。 彼ら自分の製品と彼らが行う仕事について心からの情熱を持っています。ユーザーに最高の経験をしっかりと提供し続けて、その合間に楽しい時間を過ごすために働いています。

PagerDutyは、多様性と包括性を強く信じる個人のコミュニティでもあります。他者との違いを受け入れる環境であり、あなたが本来のあなた自身であることができる場所です。例えばInternational Women’s Dayの日、同社のトロントオフィスでは、SalesforceやProcter&Gambleなどの4人の地元の女性のプロフェッショナルを招いたディスカッションパネルを開催しました。私にとって他のジェンダー指向と比較した女性のキャリアパスについて深く知ることができ、さまざまな職業の女性が直面している現代の課題を知ることができる貴重な機会でした。

PagerDutyにいた時、私はインターンだと思ったことはありません。いつもフルタイムの従業員の一人のように感じました。 インターンシップの最初の1週間に、カリフォルニア州ナパバレーで開催された会社のキックオフ( Company Kick Off :CKO)イベントに参加する特権を得ました! CKOは、シドニー、ロンドン、シアトル、トロント、サンフランシスコのオフィスなど遠隔地の従業員が一緒に来て、PagerDutyの成功を祝い、新年に向けての重要な優先事項に認識を合わせる機会でした。このイベントには多くのソーシャルな機能があり、さまざまなチームや世界各地の人々と出会う機会がありました。サンフランシスコのオフィスで働いているモバイルチームのメンバーにも会いました。会社のさまざまな従業員の背景や経験について学ぶことは本当にクールでした。PagerDutyの一人ひとりがユニークで特別なものをその場に持ち寄っていたのです。

CKOの中のあるソーシャルイベントに参加したモバイルチームと私。 (私は左の後ろの列にいます。)

メンターシップ

インターンシップの初めのうち私は人に助けを求めることを躊躇しました。他の開発者を邪魔(bugging)したくなかったからです。しかし、そのうちにすぐ、彼らが人を助けるのが大好きで助けを求められるのも大歓迎なんだということに気づきました。そして問題を解決するためにペアリングすることがどれほど有益であるかも分かりました。

以前のインターンシップでは、私はAndroidの開発だけを行っていました。 だから私が初めてiOSのタスクを割り当てられたときには、iOSアプリケーションで作業したことがなかったし、Swiftプログラミング言語の経験がないので、随分緊張しました。 タスクはモバイルアプリのライブアップデートに関連するものでした。リアルタイムでコンテンツを動的に更新する新しいアプリの機能です。 この機能の基盤はすでにアプリに入っていて、あまりにも多くのコードを必要ではなかったし、かなり簡単な作業でしたが、どこから始めるべきかはわかりませんでした。

私が助けを求めたときに受けたサポートには驚きました。私はチームのフルタイムの上級iOSエンジニアとペアを組んで一緒にソリューションを作りました。途中で、Swiftの複雑さとiOSフレームワークの基本についても立ち止まり議論しました。その中でPagerDutyアプリについてのベストプラクティスと共通のパラダイムとデザインの決定などの話もしました、

加えて、私は途中で多くの有益な指導をいただきました。私たちのモバイルアプリケーションは、学習曲線が急に上を向く強力なライブラリやテクノロジーを利用しています。それでも私のチームメンバーは、私に手を差し伸べるためには喜んで自分の手を止めてくれました。 時間がをかけてなぜ何かがそのようになったかという理由を説明してくれましたし、何かを改善したり最適化したりできるかどうかを議論することには常にオープンでした。

さらに、私はインターンだったので、何をどうすべきかを決定する際に主導権を持つ(”call the shot”な)ポジションにあるとは思っていなかったのですが、間違いでした。 1か月以上経った後、私はフルタイムのAndroidエンジニアと共同で、テストのしやすさとスケーラビリティを向上させるためにAndroidアプリケーションをどう再構築すべきかという提案書を作りました。チームとして、私たちはどのアーキテクチャを使うかを決めましたが、私たちのアプリケーションにどう適用するのかは決まっていませんでした。 私は私たちのアプリにアーキテクチャを統合する方法の技術的な詳細を書き上げる責任がありました。それは重い責任でしたが、そのチャレンジを進んで引き受けました。他の開発者からの徹底的な見直しを受けてから、この提案は最終的に承認され、現在は私たちのアプリの標準として機能しています。

提案を完全に実行するプロセスには長い時間がかかります。 しかし、我々は、新しいアーキテクチャの基礎とそれで実装されるすべての新機能を定めました。 PagerDutyのAndroidアプリの未来に革命を起こすために私が大きな役割を果たしたと分かるのは素晴らしいことです。

小さなチームで大きなインパクトを

相対的に言えば、モバイルチームはPagerDutyの他のチームと比較してまだ小さいです。 小規模なチームとしては自律的にやれることがたくさんありました。たとえば、私たちのアプリで使用すべきコードアーキテクチャーに至るまで、プルリクエストの形式のような単純なものを理解することは、私たちの責任でした。 私たちは、アプリケーションのリリース時期や頻度を自分たちで決めました。チームはこのプロセスを非常に大事にしています。まずPagerDutyの従業員に新しいバージョンのアプリケーションを配布して、そののちに最高品質のアプリがユーザーに提供されるようにします。 チームの上級エンジニアと数回ペアを組んで、モバイルアプリをユーザーにリリースしました。 この経験から、多数のユーザーにアプリを出荷するプロセスについての洞察が得られました。すべてを円滑に進めるためにリリースを監視する方法を学びました。

成長の機会

PagerDutyには、パイプラインにたくさんのクールなプロジェクトがあり、どれもオフリミットはありません。 私が最初にPagerDutyに入社したとき、私はiOS開発やバックエンド開発をしたいという希望を出しました。 私は両方の仕事をする機会を与えられただけでなく、すぐにユーザーに出荷される重要なプロジェクトに取り組ませていただきました。

新しいことを学べたもう1つの非常に便利な機会は、モバイル・チームの週1回の共同作業セッションでした。そこではチームメンバーが個人的な開発にとって価値のあるものに取り組みます。 何か新しいことを探求し、疑問があるときはいつでもチームの上級開発者のサポートを受けるのは本当に便利なチャンスでした。私はこの時間を使って技術的知識を広げました。Swiftについてより深く学び、さらにiOSフレームワークについて学ぶために小さなiOSアプリケーションを開発しました。

私はアジャイル手法についても学びました。これは私のワークフローを実際に改善しました。 モバイルチームに参加したとき、彼らはScrum Agileメソドロジーを採用していました。 基本的に、これは、チームがスプリントと呼ばれる固定された時間単位で作業を完了するよう計画することを意味しました。私たちのチームにとっては、各スプリントは2週間の長さでした。 各スプリントの終わりに、私たちのチームは一緒になって( れとろすぺくてぃと呼びます)スプリントについて議論しました。何がうまくいったのか、あまりうまくいかなかったのか、プロセスを改善するためにどんな行動が可能だったかを議論したのです。

これらの実践の中で、ボトルネックを特定して修正する方法と、他の開発者と効果的に連携する方法を学習しました。私が最初に会社に入社した時と比べると、自分が高品質の仕事を完成させようとしている間にスループットが大幅に増加したことにはっきりと気づきました。 もう一つのことも気が付きました。つまりPagerDutyが真剣に取り組んでいることは、皆の意見が重要であることと、レトロスペクティブは、各チームメンバーがチーム全体としてどのように改善でき、皆の提案が考慮されたかにというフィードバックを提供する機会であったことです。

未来に

全体的に見て私のPagerDutyでのインターンは最高の経験でした。 インターンシップが終わり、学校に戻ることは辛かったです。幸運にも多くの素晴らしい人と出会って、これからも続くたくさんの関係を築けたと感じています。 私は、自分がインターンシップの過程で獲得したスキルセットが、将来のエンジニアリングの取り組みに役立つと確信しています。 PagerDutyとモバイルチームと過ごした期間は、私にとって決して忘れられない経験です。

PagerDutyで働くことに興味がある場合は、キャリアページ(訳注:米国PagerDutyサイトの応募ページにリンクしてあります)に応募することを検討してください 。

本記事は米国PagerDuty社のサイトで公開されているものを日本語訳したものです。原文はこちらです。

2017年9月1日  (更新日:2022年6月13日)     |    ベストプラクティス

PagerDutyのスケジュール設定をしてみました

ConfigurationからScheduleを選択します。

「New On-Call Schedule」で新しいスケジュールを追加できます。

まず、 「Time zone」を日本に設定して、Layerを追加していきます。

レイヤーを順番に設定していきます。

レイヤー1では、1人の担当者が日中の時間帯に交互に担当するよう設定してみました。

レイヤー2では、それ以外の時間帯を2名で設定してみました。

最終的なスケジュールは、以下になりました。

簡単なUI操作だけで、柔軟なスケジュール設定ができますね。

また、スケジュールのOverride機能を使うと例外的なスケジュールも組み込むことができるので、非常に便利です。

2018年3月7日  (更新日:2022年5月19日)     |    ベストプラクティス

いかにして優秀なエンジニアになるか パート1:レバレッジの向上

PagerDutyで私達は個人としてもチームとしても日々勉強に励んでいます。具体的には、事後分析、コードレビュー、過去の見直し、SlackやJIRAでの議論、ヘルスチェック調査などです。さらに、インタレストグループに参加したり、スプリントレビュー、テクニカルトーク、ブログを読いんだり書いたりする機会もあります。

エンジニアとして、私たちは非効率なコードをリファクタリングし、技術的な欠陥に対処し、ワークフローを改善しようともしています。このように多くの仕事をしている(これとは別のスクラムチームでやっている製品やインフラストラクチャの仕事もある)ので時間をどのように管理するかが重要です。たとえば、どのプロジェクトが他のプロジェクトより優先されるべきか、その理由は何か? 目標に向かってより効果的に進めるため、私たちは何をすべきか?

これらの質問に答えるには、当面の仕事のレバレッジを評価する必要があります。Edmond Lauの効果的なエンジニアによるとレバレッジとは「投下された時間当たりの生成された価値またはインパクト」というシンプルな方程式で定義されています。

言い換えれば、ハードに働くことは効果的に働くことと同義ではありません。それは仕事が生産的なのか、ただ忙しくしているのかの違いです。それを知るための別の方法は、エンジニアリングのROIです。私たちが取り組むべき仕事は無限にありますが、私たちの時間とリソースは限られています。効果的であるということは、最小の努力で最大の価値を生むものに取り組むことを意味します。「結果の80%は20%の労力から生まれる」―Pareto Principleとも呼ばれる80-20のルールが当てはまります。

どうすればレバレッジを高めることができるか

元IntelのCEOであるAndrew Groveは著書「High Output Management」で、レバレッジの総量―時間単位で生産する価値―を高めるためには、3つの方法しかないとしています。

一定の活動を完了するのにかかる時間を短縮する 特定の活動のアウトプットを増加させる レバレッジがより高い活動に移行する

日中は、会議、メールのチェック、Confluence/コメント/ブログの読み書き、Githu/Confluenceへのフィードバック、Slackディスカッションへの参加、デザインスプリントなど、さまざまな活動が行われています。しかし、あなたが何をしているのかに関わらず、あなたのレバレッジを向上させるために次のことを自問してみましょう。

どうすればこの活動を短時間で完了できるか どうすればこの活動によって生み出される価値を高められるか より高い価値を生み出せるものが他にあるか

以下にいくつかの例を示します。

ミーティング

会議をより効果的にするために、以下の質問について考えてみてください。

この会議に1時間かける必要があるか。30分で済ませられないか。それとも15分内のほうがいいか 会議の目的を全員が理解しているか。出席者は何か準備する必要があるか。彼らは事前に何かを読んでおくべきか この会議は必要なのか。Slackやメールですませられないか

電子メールとSlackのチェック

メールとSlackの設定は個人ごとに異なります。メールのチェックと返信に価値があることは否定できません(Slackのメッセージを読み、アップデートし、コラボレーションすることも同じ)。だが、これらはどんな点でそのリターンを低下させているのか。言い換えれば、これはいつから私たちの生産性の阻害要因になったのでしょうか。

1日を通して絶えず割り込みがかかる中で、この競り人の速さでコードを書けるマインドセットを持つことは難しいかもしれません。たとえば、私はコミュニケーションツール(メール、Slack、JIRAなど)で頻繁にチャットをしながら、Command + Tabでアプリケーション間を行き来したり、Chromeののタブからタブへとスイッチしたり、そしてコードを書いたりと、落ち着かない働き方をしています。しかし、私は正面を向いてロックインし、レーザーのように集中できる割り込みなしのコーディング時間―私が言うところのディープワークを、1日に少なくとも2〜3時間取れるようにしています。

Deep Workの著者であるCal Newportは、それを次のように定義しています。

「途切れのない十分な集中力で行われる専門的な活動は、認知能力を限界まで押し上げる。その努力は新しい価値を創造し、スキルを向上させる。それは簡単には真似できない」

私はまた、心理学者Mihaly Csikszentmihalyiによって造られたflowと呼ばれるコンセプトを聞いたことがあります。flowを経験した人々は、flowのことを「何の努力もせずに、時間の感覚や自己の存在、自分の問題も忘れるほど集中できる状態」と表現しています。

ディープワークをしている時、私はSlackのスヌーズ機能を使用しています。これで設定した時間は通知が抑制されます。その後、きりのいいところで何も起こっていないことを確認するため定期的にSlackをチェックします。

エンジニアは最大限仕事を頑張って、効果的な結果を果たしていると私は信じており、人には1日に少なくとも1時間か2時間は仕事に集中し、より生産的であるかを確認するよう勧めています。この時間を通常の集中していないコーディング時間と混同しないでください。理想的には、私たちは一日中コードを書くべきですが、散漫で集中していないコーディングと中断のないコーディングとは違います。私がディープワークと言う時は、途切れることのないコーディングを指します。

あなたが作業している現在のJIRAチケット

Jiraチケットがすでにプロダクトオーナーによって優先順位付けされており、ストーリータイムとスプリント計画プロセスを経ていると仮定すれば、それをもう一度見て、そのレバレッジを高めることができるかどうか考えましょう。次の3つの質問でそれをチェックしてみましょう。

どうすればこの活動を短時間で完了できるか 既存のライブラリを利用できるか。エンジニアにとって最初からスクラッチでコードを書くことが魅力的であることは私も知っています。 どうすればこの活動によって生み出される価値を高められるか より高い価値を生み出せるものが他にあるか

現在の目標やリリースのためもっと重要な作業が必要なのか。このような状況ではMVP (最小限の実行可能な製品)を考える―初期のフィードバックを収集しようとしているときに、最初からこのファンシーな最適化が本当に必要なのだろうか。リリース可能な最小スライスは何か。リリースにおける80-20とは何か。しないでいいのは何か。どのようにして価値を下げることなく範囲を縮小できるのか。

忙しい仕事に巻き込まれるのはよくあると思います。しかし、私は正しい質問を自分に問うことを覚えました。そうすれば効果的に仕事をして生産性を高めることができるでしょう。

次回は優先順位付けの方法についてより詳しく説明します。お楽しみに。

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

2018年5月28日  (更新日:2022年5月19日)     |    ベストプラクティス

DNSmetrics:複数のDNSプロバイダから統一したメトリックを集める

マネージドDNSプロバイダーからメトリックを収集して変換するためのツールをオープンソース化して皆様とシェアできたことを喜びに思います。私たちは現在DNSmetricsを使用して、SREチームの監視、警告システムに標準形式のデータ提供を行なっておりますが、この方式が皆さんのお役にも立てると信じております。

DNSの主な役割

PagerDutyでは、サービスの信頼性と可用性を重視しております。可用性は私たちの内部インフラの設計に重要であるだけでなく、私たちが所有していないインフラにも同じ要件を適用する必要があります。 PagerDutyは外部のプロバイダーをいくつかの不可欠なインフラコンポーネントに活用しています。本日はこれらの1つについて説明します。

ドメインネームシステムは、pagerduty.comのようなドメイン名を、APIやWebアプリケーションが要求する数字のネットワークアドレスに翻訳します。アドレスは変わる可能性があるため、ほとんどのシステム(とほとんどの人)は数字ではなく名前を使用します。そのため、私たちのドメインの DNSが利用できない場合、多数のお客様は私たちのサービスに到達できなくなるので、DNSを使用可能にして正しく構成することが重要です。

DNSプロバイダはこれを理解し、高可用性システムのグローバルネットワークを維持しています。しかし、DNSの性質上、大規模なシステムは間違いなくDoS攻撃の影響を受けやすくなります。実際、有名なマネージドDNSプロバイダの大部分は、過去数年間に少なくとも1つの大きなサービスの混乱を経験しています(例:1、2、3、4)。PagerDutyは過去に単一のプロバイダを使用していましたが、我々はもはや十分に頑強であるとは言えません。現在ではアクティブ―アクティブ構成(各プロバイダーが運用トラフィックの半分ずつを担当する)で、DNSニーズに対して2つのプロバイダーを使用しています。

DNSメトリックを何のため構築し、どのように役立つのでしょうか

両方のDNSプロバイダに監視と警告を設定するのは難しいことでした。各プロバイダは、管理インタフェースでオーバービューとレポートを提供していますが、公開されているメトリックの選択、異なるインタフェース内の同じデータの場所、平均とレポートに使用される時間間隔など、レポートはプロバイダによって異なります。プロバイダやゾーン全体でDNSの状態のスナップショットを得るために多くの努力とさまざまな表示画面が必要で、我々はアラート機能のために自らのツールを使用したいと考えました(いずれのプロバイダーも当社の総トラフィックの一定割合以上を取得していないことを追跡します)。

私たちにはもっと良い解決策が必要でしたが、利用可能なものはなかったので、構築することにしました。これは、APIを使用して両方のDNSプロバイダに接続し、関心のある指標を引き出すサービスです。これらのメトリックは、同じ名前空間とユニットに正規化され、標準的な統計形式で発行され、任意の時系列モニタリングシステムに取り込まれます。

2つの異なる管理インターフェイスとそれぞれの複数の画面ではなく、すべてのプロバイダとゾーンを集約したDNSの正常性の概要を示す単一のダッシュボードが作成されました。

さらに、時系列のメトリックを1か所に配置したので、時系列クエリ(我々の場合はDataDogモニタ)の豊かな表現力を適用して、すべてのプロバイダでDNSの柔軟なアラートをプロバイダごと、ゾーンごとに設定できます。

マネージドDNSプロバイダを監視することは、PagerDutyのSREチームだけの問題ではありません。そのため、オープンソースのDNSメトリクスを採用することにしました。現時点では、使用しているプロバイダのみをサポートしていますが、他のプロバイダにカバレッジを拡張するには、一般的に使用されているメトリックを公開するREST APIがあれば簡単です。 DNSメトリックを試してみるのは、Dockerコンテナを実行するのと同じくらい簡単です。スピンを加えて環境内の場所を探すこともできるかもしれません。

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

2018年4月3日  (更新日:2022年5月19日)     |    ベストプラクティス

チームの健全性に関する驚くべき3つの発見

800人のITプロフェッショナルの調査結果から驚くべき発見

PagerDutyで、私たちは芳しくない業務の健全性につながる否定的な結果を認識しています。 今日の常時接続のデジタル世界では、絶え間なく高まる顧客の要求のために企業はプレッシャーにさらされていて、ITサービス担当者はデジタルサービスを健全かつ継続的に運営するために努力していますーしばしば個人の健康と生活が脅かされるほどに。仕事の呼び出しに応答するため、真夜中に携帯電話が鳴る音に起こされたり、人生の重要なマイルストーン(子供の初めての学校演劇のような)を逃したことなど想像してみてください。燃え尽きてすぐにワークライフバランスのいい仕事が欲しいと考えたことがあるでしょうか?

それでも、私たちは、米国、英国、オーストラリアの800人以上のITプロフェッショナルを対象に実施した最近の調査による3つの発見に驚いています それは、

家族生活はITマネージャーの想像以上に荒れている 認知度の欠如はITOpsの職業病となっている ビジネスにかかるコストは、労働力の喪失だけでなく苦労している従業員の生産性低下にも及ぶ

ということでした。

PagerDutyが依頼した調査レポートでは、常時接続のデジタルサービスを管理する責任が家庭生活に影響を与えているとの回答が94%となっています。さらに、半数以上(51.3%)が、デジタルサービスの中断や停電に対処するために、1週間に10回以上睡眠や個人的な生活の中断を経験したと指摘しています。

コンスタントに起こる呼び出しがオンコール担当者の健康や個人生活に悪影響を及ぼしているという統計にもかかわらず、調査回答者の約4分の3(72%)が、彼らのマネージャーはt担当者が厳しいオンコール時間を過ごしていることをを全然知っていないという結果になりました。それに対して、 調査のITマネージャーの58.9%は、彼らのチームが厳しいオンコール時間を過ごしていることをほとんど知らなかったと答えています。

悪い業務管理はデジタルトランスフォーメーションを妨げる可能性がある

IT管​​理者と企業全体は懸念すべきです。なぜか?

Forresterによると、多くの企業ではクリティカルな役割を担うタレントの不足がデジタルトランスフォーメーションを妨げることにつながっています。このようなタレントの欠如は、悪い業務管理と結びついた場合に、最終的に損益に悪影響を及ぼし、従業員の離職率や売上に直接悪影響を与えます。

健全なITエコシステムを維持するためにオンコール担当者はいつでも準備を整えていることを要求されます。その結果、燃え尽きたり、離職したりする不幸な従業員が生まれる可能性があります。しかし、ITOpsの始まり以来、運用上の管理は、人ではなくサーバやアプリケーションに集中しており、それはしばしばビジネスに損害を与えるものでした。

しかし、サーバやアプリだけでなく、人の面から業務の健全性を見ると、なぜIT管理者はオンコール担当者の健康状態をより詳細に把握する必要があるのかが分かるようになります。一部の回答者(23.1%)は、仕事と生活のバランスがとれない結果、新しい仕事に移る可能性が高いと答えています。さらに、組織が業務の健全性を改善するための対策を講じないと、残る人の生産性も低下する可能性が高くなります。 事実、94.5%の回答者は、継続的な中断が作業生産性にも影響を及ぼすと回答しました。

データの利用によりチームの健康を変える

いま指摘したように、良い人材を失うことは、組織がデジタルサービスをどれだけうまく提供できるかに悪影響を及ぼします。では、従業員の健康と幸福をどのように改善できるでしょうか。

それを知っているかどうかに関係なく、あなたはすでに現在の操作の健康状態を把握するためのデータを持っています。そのデータのロックを解除するだけで、改善すべき点を判断することができます。

PagerDutyは、この課題を認識してOperations Health Serviceを開発しました。これは機械学習、データサイエンス、専門サービス、1万を超える組織のピアベンチマークデータを組み合わせて、IT管理者が社員の健康状態を見て自社のデジタルオペレーションを評価できるようにするものです。

今日からPagerDutyがいかに組織のデジタルオペレーションをに人間的にすることができるかを学び、業務の健全性を向上させてください。

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

2019年4月18日  (更新日:2022年4月29日)     |    ベストプラクティス

Postmortem(事後検証) パート3:事後検証ミーティングを最大限に活用する

「Postmortem Guide」を発表したとき、私は責任を問わない事後検証を行うことの価値と、継続的改善の文化を確立する方法について書きました。このシリーズの最後である事後検証の本記事では、効果的な事後検証ミーティングを開催する方法について説明します。*

私が参加した最後の事後検証ミーティングでは、システムで何が起きたのか、どのように対応したのか、問題が二度と起こらないようにするためにどのような改善を加えるべきかを話し合いました。PagerDutyには責任を問わないという文化があるので、誰かを名指しで非難したり、感情を傷つけたりはしませんでした。しかし、継続的な改善をという点において、この会議時間を最も効果的に活用しているのかどうか疑問に思いました。

インシデントを最適に分析する方法については、多くの記事が書かれています。「事後分析をする」というと、とかく分析のプロセスと結果として得られるドキュメントの形式に焦点が当たる傾向があります。多くの場合、このプロセスは、分析の結果について話し合うための事後検証ミーティングで終わります。私たちは最近、なぜ事後検証が重要なのか、そしてどのように実践するべきかについての詳細な情報をコミュニティに提供するため、総合的なPostmortem Guideを始めました。しかし、このガイドのために研究を行っているとき、私は事後検証ミーティングそのものについてはほとんど書かれていないことに気づきました。

分析を実行し、事後検証のドキュメントを完成させることは、インシデントから学ぶための重要な最初のステップです。結果を議論するために会議をフォローアップすることで、チームは分析からさらに多くの価値を引き出すことができます。事後検証ミーティングの目的は、インシデントの原因に対する理解を深め、実際に行動を起こせるようにアクション項目に賛同を得ることです。

一緒に、そしてクールに

何が起こったのかについてのライブ会話をするために(物理的またはバーチャルに)部屋に集まると、分析は新しい方向に進み、すべての人にとって学習ポイントが深まります。 最も重要なのは、議論することで、同じ問題が再発するのを防ぐのに必要なアクションの優先順位にチームの賛同を得ることです。

これは、「言うは易く行うは難し」です。 事後分析をみんなで読むだけでは、この会議から最大の価値を引き出すことができません。感情が高まり会議の進行が困難になることもあります。チームが責任を問わない事後検証を実行するために最善を尽くしたとしても、彼らが犯したした失敗について議論するとき、人々はどうしても防御的になるでしょう。

私は元スクラムマスターとして、事後検証ミーティングと振り返り(retrospective)の類似点に気づきました。振り返りミーティングでは、チームは最後の反復がどのように行われたか、またどのように改善したいかを検討します。同様に、事後検証は過去のインシデントの考察とそこから学びを得るために行われます。チームが奮闘していると、ふりかえりミーティングは個人間の摩擦と感情的な反応を引き起こします。事後検証も恐れや怒りといった感情を伴うことがあります。

進行役を担う

PagerDutyでの事後検証ミーティングとふりかえりの運営方法には大きな違いが1つあります。ふりかえりはチームのアジャイルコーチによって進行されますが、事後検証ミーティングは通常Incident CommanderまたはPostmortem Ownerが主導します。

これら2つの会議の類似点を考慮すると、事後検証ミーティングも熟練した進行役の参加が重要であることに気付きました。会議における進行役の役割は、他の参加者とは異なります。彼らは彼ら自身の考えを表明するのではなく、議論を軌道に乗せ続け、メンバーに発言するよう促します。対応者が会議の進行役をやると、グループ全体の一体感を保ちながら彼らの経験やアイデアを共有することは困難であると学びました。

指名された進行役は、グループが会議の2つの主たる目標に集中するのを手助けします。

インシデントにつながった原因についての理解を深めること 事後検証で明らかになったアクション項目への同意を得ること

チームが議論をしている間、進行役は全員が快適で誰か1人がミーティングを支配しないよう、グループダイナミクスに注意します。進行役がこれをどの程度きちんと実行しているか注目しましょう。

インシデントの原因を探る

進行役が直面する議論を妨げる2つの大きな課題があります。

システム障害の責任を個人に負わせてしまう傾向がある 分析が深く掘り下げられていない

進行役は非難が起こりそうな時に会話の方向を変えることで、チームが責めを避けるようにすることができます。事後検証の目標は、どのような体系的要因がインシデントを引き起こしたのかを理解し、この種の失敗が再発するのを防ぐ方法を見つけることです。誰がミスを犯したのかではなく、ミスがどのように起きたかに焦点を絞るようにします。

進行役は、分析を妨げ、責任追及を暗示する「誰」や「なぜ」という質問を避け、代わりに「何」や「どのように」という言葉を使って「あなたは何が起こっていたと思いましたか」や「必要な支援をどうのように受けましたか」というような質問をしてください。

特定の対応者を抽象化した人間に置き換えることにより、ある行動についての責任追求を避けます。誰でも同じミスを犯した可能性があることをチームに思い出させてください。「何がその行動をとらせたのか」と尋ねることにより、誰か1人を責めるのではなく、グループ内の誰もがシステム障害の原因についての率直な意見を述べることができるようになります。

たとえあなたが責任追及を極力避けるという文化を持っていたとしても、インシデントにつながった多くの条件を深く理解するのは難しかったりします。進行役の役目は、グループに考えさせるために適切な質問をすることです。単純に「はい」または「いいえ」で答えることができる質問ではなく、常に自由回答形式の質問をしてください。会話の初心者は事後検証ガイドの分析用の質問を参照してください。

メンバーの賛同を得る

製品管理者や技術管理者など作業の優先度を決定するチームリーダーに、事後検証ミーティングへの参加を奨励するために、カスタマーエクスペリエンスに対する脅威と技術投資へのニーズについての見識が上がることを説明します。事後検証ミーティングは、行われるか、あるいは行われない作業に関する困難な決定と、それらの選択の予想される影響について話し合う機会です。

下手なチームダイナミクスは全員の積極的参加を妨げる可能性があります。進行役はこれらのパターンに注目してグループを導きます。1人が会議を支配している場合は、その人が言っていることを繰り返し(例:「◯◯ですね。それは分かりました」)、続けて「別の観点があれば聞きたいのですが」と他の人が話すのを促します。

誰かが人の発言を遮っていたら「初めの人の言ったことが聞こえませんでした」または「ちょっと待って。マリーさんの意見を最後まで聞かせて 」と言いましょう。

反対に、意見を話す人がいないときには「他に何か検討することがあるでしょうか?」と尋ねれば参加を促せます。

これらの会話のトリックにより、進行役は全員を参加させることができます。そして最も重要なのは、アクションプランへの合意に向かって会話を進めることです。たとえ最善の行動方針について意見の相違があったとしても、みんなが聞いたことがあると思えば、グループをアクションプランに参加させることができます。

成功のために進行役を配する

チームの議論をフォローして、あなたの事後検証分析を最大限に活用してください。ライブで会話をすることは、全員の学習を深め、新たな洞察につながる可能性があります。ただし、単にその会議をスケジュールして文書を一緒に読むだけでは不十分です。事後検証ミーティングを成功させるためには、熟練した進行役の助けを借りてください。

その他の円滑化のヒントと効果的な事後検証の実行方法については、「 Postmortem Guide」を参照してください。PagerDutyのフォーラムでは事後検証ミーティングからどのようにして最大の価値を得るかについてご意見を募集しています。

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

2017年12月7日  (更新日:2022年3月11日)     |    ベストプラクティス

カスタマーサポートチームがインシデント管理をどのように活用できるか

「インシデント管理」と聞くと、ITプロフェッショナルがバックエンドシステムを管理していると考えるかもしれません。おそらくカスタマーサポートチームは自分たちとは関係ないと考えていることでしょう。

ですが実際のところ、カスタマーサポートチームもインシデント管理から多くの利益を得ることができるのです。

顧客を幸せにする

ほとんどすべてのIT専門職は、カスタマーサポートに回ってくるようなことがらは一般的に良くないことだと考えているでしょう。私たちは顧客に技術サポートに頼るような経験をさせたくはありません。カスタマーサポートを提供することに直接的なコストが伴うだけでなく、こういった経験をした顧客は将来的に顧客でなくなる可能性が高まるからです。

結論は、顧客を満足させることが重要であるということです。満足した顧客は、あなたの会社との経験を何人かの友人に伝えてくれるかもしれません。怒っている顧客は、自分のTwitterフォロワーに体験をシェアしたり、中には消費者庁に駆け込むようなこともあるかもしれません。

では、カスタマーサポートとインシデント管理はどんな関係があるでしょうか。その性質上、カスタマーサポートは受け身の機能です。通常、顧客は問題に突き当たるとテクニカルサポートに電話を掛け、テクニカルサポート部門は顧客の苦情に対応することになります。インシデント管理も同様に受け身なものですが、予防的な対応も可能です。適切な監視ソリューションを使用することで小さな問題を解決して、チームをより大きな問題の解決に向かわせることができます。これにより、サポートコールが少なくなり、顧客満足度の向上にダイレクトにつながります。

積極的なインシデント管理を通じてサポートコールを削減するという考えは魅力的ですが、インシデント管理計画が適切に実装されている場合にのみ有効です。重大ではなかったり重複している警告は抑止し、より緊急な問題のアラートを発信することで、ソフトウェアはIT担当者の大きな助けになります。しかし、最終的には、インシデント管理プログラムの成功は、問題が発生したときに決定的な行動をとるITスタッフの能力に左右されます。

担当者を呼び出せることの重要性

インシデントが迅速に解決されるようにするためのひとつの方法は、発生する可能性のある問題をITスタッフが常に処理できることを確認することです。組織に24時間対応のITスタッフがいない場合は、呼び出し可能なサポートチームを持つ必要があります。これは全員が常にオンコールでなければならないというわけではありません。輪番制のコール対応スケジュールを組めば、ITチームの誰かが常に起こりうる様々なインシデントに対応可能になります。

時間外の緊急事態に対処するためにコール対応スタッフを用意しておくという考えは新しいものではありません。熟練のIT技術者であれば、たいていは週末や非常識な時間に呼び出された経験が一度や二度はあると思います。

ほとんどのITサービスは時間外の問題に対処するために誰かを呼び出すことを躊躇しないものですが、関係するすべての人がより無理なく日常生活を送れるようにするためには、いくつかのポイントがあります。

オンコールオペレーションのベストプラクティス

まず、時間外のインシデントでITスタッフにアラートを出すのは、インシデント管理ソフトウェアによって起動される自動プロセスでなければなりません。自動アラートを使用することで、IT担当者は問題を可能な限り迅速に認識することができます。自動プロセスをとっていないと、誰かがインシデントを発見してIT部門に電話をかけてくるまで、ITスタッフはその問題を認識できない可能性があります。その頃には、顧客の側でも問題を経験し始めているかもしれません。

これは別のポイントをもたらします。よほど小さな組織でない限り、1人のオンコール担当ではなく、オンコールチームを用意するのが一般的です。ITは複雑な分野であり、チームの誰もが組織全体で使用されているあらゆるテクノロジーの専門家であることを期待するのは非現実的です。オンコールチームを組織しておくことで、インシデントが発生した場合、問題を解決するために相互補完的なスキルセットを持つ人々のグループを確保することができます。これは、オンコール技術者が何らかの問題が発生したときに、解決に必要なスキルを持つ特定の人を探すより好ましい方法です。輪番制のコールスケジュールは、ある人に常に役割を負わせるのではなく、いつでも問題に対処できるチームが存在することを保証します。

業務時間外に待機するのは決して楽しいことではありませんが、24時間体制で顧客にサービスを提供する企業では、ITの専門知識を年中利用できるようにすることが非常に重要です。顧客は企業の最も貴重な資産であり、企業のブランドは顧客に依存しています。インシデント管理ソリューションを活用する積極的なカスタマーサポートチームは、問題が顧客に悪影響を与えるのを防ぐことができ、より高い顧客満足度につながります。

2018年2月28日  (更新日:2022年3月11日)     |    ベストプラクティス

セキュリティインシデント対応者としての生活

小さな目でスパイして

「誰がリンクをクリックしたかを追跡する機能を構築したい」

そのメールをセールスチームに送ったとき、私は気味の悪いストーカーと思われたようだ。なぜクリックされた地球上のすべてのリンクを追跡したいのだろうか? 私は私についての厄介な噂を払拭するために、どんな状況だったのか知る必要があると判断した。そして、セールスチームのメンバーが警戒してセキュリティチームに報告したため、実際にフィッシング攻撃という脅威が検出された。

私の考えを説明するフォローアップメッセージを書いたとき、私はカーテンを剥がして「セキュリティのしくみ」を明らかにすれば会社全体が利益を得ることができると気づいた。拡大と混乱の期は熟した。セキュリティインシデント対応者のニーズを理解すれば、PagerDutyを使用して顧客が新しい問題を解決する助けになれると。

セキュリティインシデント対応の仕組み

セキュリティチームには、ビジネスに対するサイバーセキュリティリスクを軽減し、顧客の信頼を向上させるという2つの主な目的がある。私たちが毎日直面している本当のリスクは、攻撃者がいつでも任意のコンピュータ上でマルウェアを実行できることだ。セキュリティインシデント対応チームは、私たちが直面している脅威の影響を理解し軽減するプロセスを経験している。ここでPagerDutyで行う高度な手順は、 NISTのサイバーセキュリティフレームワークに基づいており、以下のようなセキュリティインシデント対応計画からなっている。

検出

封じ込め

対応

回復

さて、PagerDutyセキュリティチームがこのような脅威にどのように対応しているかを見てみよう。

急ぎの質問としては、

悪質なマルウェアが含まれているか?

悪質なマルウェアはどこででも発現したか?

この2つの質問に答えることで、攻撃の最初の影響を理解し、被害を封じ込めることができる。

最初の質問への答えは、同僚からの攻撃のレポートを受け取ったときにすぐに分かった。私たちの手元にはリンクが付いた電子メールがあり、リンク先がマルウェアかどうかを確認することができた。そのような場合、安全のため隔離されたコンピュータの中の仮想マシンを使用してリンクをたどって疑わしいファイルを検査する。こうすれば、リンクが何か悪質なものをダウンロードした場合は、直ちに仮想マシンを止めることができるため、マルウェアは損害を与えられない。

この方法を使用すると、リンクがマルウェアをインストールしたことが検出された場合、そのリンクをブロックして、オフィスネットワーク上の誰もそれをダウンロードできないようにできる。しかし、ブロックを設置する前に誰かがすでにダウンロードしていたらどうだろうか?

これは2番目の質問につながる。悪質なマルウェアはどこででも発現したか? この質問に答えるには、誰かがマルウェアをダウンロードしたかどうかを調べる必要がある。誰がリンクをクリックしたのか? マルウェアをダウンロードした人が複数いる場合は、すぐにネットワークからコンピュータを切り離して、マルウェアが他のシステムと通信できないようにする必要がある。マルウェアはネットワーク上の他のコンピュータを攻撃し、コンピュータからデータを盗み、インターネット経由で攻撃者に送信する可能性がある。これらの行動は、それぞれ「lateral movement」(横への動き)と「exfiltration」(抽出)と呼ばれる。

感染したコンピュータをネットワークから切り離した後、マルウェアが実行可能だったかどうかを確認する。必ず、問題に対応する前に、まず攻撃をカットすること。できるだけ早く感染が広がらないようにする。ひょっとするとあなたは幸運かもしれない。マルウェアはWindowsやMacでのみ実行可能で、それ以外のOSにダウンロードしても実行されないならば、あなたが影響を受けることはない。

では次に、3人のユーザーがリンクをクリックし、悪意のあるソフトウェアが彼らのコンピュータで実行できることが判明したシナリオを見てみよう。これは本当に危険な状況だ。3台のコンピュータがネットワークから切断される前に、マルウェアが実行中に何をしたのか理解する必要がある。インターネット越しにデータを抽出したのだろうか? 横への動きを使って別のコンピュータを攻撃することができたのだろうか? パスワードを盗もうとキーロガーをインストールしたのだろうか? これらの質問に対する答えは、私たちがどのように対応し、攻撃から回復するために何をすべきかを決定する。

残念ながら、現在のところ誰かがリンクをクリックしてマルウェアをダウンロードしたかどうかを即座に特定できる技術はない。私はいつも誰もクリックしていないことを願っているが、それが望めなくともせめてどのシステムも影響を受けていなければ、夜はよく眠れるだろう――だから私は誰がリンクをクリックしたかを追跡したいのだ。

セキュリティのためのPagerDuty

インシデント対応チームがセキュリティイベントが検出されたときに迅速に対応することがいかに重要であるかをご理解いただけただろうか。リスクを減らすことが私たちが仕事をして給料を稼ぐ理由だ。あなたのためにできる私の挑戦は、以下の質問に答えること――セキュリティインシデント対応者は、PagerDutyを使用して対応にかかる時間をどのように短縮できるか? 彼らは横への動きを介して広がる前に感染を封じ込めることができた場合、どのくらいのリスクを排除することができるのか? どのくらいのコストを節約できるのか?

セキュリティのためにPagerDutyを! 以下のセキュリティに関するリソースを確認しよう。

セキュリティの混乱:SecOpsとインシデント管理によるITセキュリティの改革

セキュ開発者:PagerDutyを安全に保つ

シグナルサイエンスはセキュリティ上の異常に素早く対処し、PagerDutyで顧客データを安全に保つ

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

2017年12月30日  (更新日:2022年3月11日)     |    ベストプラクティス

3年間で3倍になったPagerDuty:エンジニアリング組織のスケーリング

3年前、私は 新興スタートアップだったPagerDutyにエンジニアリングマネージャーとして参加しました。 当社は2013年にシリーズAの資金を受けて超成長モードにあり、あらゆる分野で積極採用を進めていましたが、エンジニアリングチームは当時30人以下でした。急成長企業が直面している構造的課題の解決に、私は大きな魅力を感じました。エンジニアリングが100人のDutonian(注:Star Wars: The Old Republicに登場する)の群に増えつつある今、これまでの変化を振り返り、今後に反映させようと思います。

組織構造の進化は魅力的なプロセスです。それはたくさんの間違い、行き止まり、車輪の再発明みたいなことでいっぱいです。うまくいけば、エンジニアリング組織をカバーする文献はたくさんあります。その多くは、賛否両論の抽象的なリストみたいなもので沸騰しています。また企業が採用したプロセスを自画自賛するようなブログ記事も投稿されています。私は別のアプローチをとって、エンジニアリングチームが構造を進化させる試みを繰り返し、それに伴って起こった誤解や学びのすべてを包括して、そこから歴史的な教訓を得たいと思います。

注:イベントや詳細の一部は、ストーリーを分かりやすくするため省略しています。このブログをブックマークしておくと、新しいコンテンツを見ることができます。

昔はサイロ化した組織でした

2014年初頭のPagerDutyは次のように見えました。

エンジニアリング組織は、サンフランシスコ(SF)とトロントのオフィスに分かれていました。

運用チームは、インフラストラクチャの自動化、セキュリティ、およびパーシステンス(SFのみ)を担当しました。

WebアプリケーションチームはPagerDutyの顧客に

見えるの部分を担当し(SFのみ)、主にRuby on RailsとMySQLで

開発をしていました。

バックエンドサービスグループは、信頼性の高いデータ収集と通知配信を担当し(SFとトロントにチームが分割配置されていました)、主にScalaとCassandraで開発をしていました。

DevOpsには部分的な遵守事項しか明文化されていませんでした:

運用チームは、インフラストラクチャ監視アラートのオンコールを担当し、他のチームは導入したコードのオンコールを担当していました。

エンジニアリングが非常に短期間に少人数からいくつかの分散したチームへと成長する中で、製品開発プロセスは未成熟なままでした。スタンドアップとスプリントを使い表面的には敏捷に動いているように見えていたにもかかわらず、基本的にウォーターフォールモデルを使っていました。リーダーシップは、作業すべきプロジェクトを定義し、個々のエンジニアをそれらのプロジェクトに割り当て、目標とする納期を定義しました。予想通り予定はあまり守れずプロジェクトのスプレッドシートは壊滅的な状態になりついには使われなくなりました。

事態はうまく進むように見えませんでした。プロダクトマネージャーは、開発中に発生する可能性のある疑問を予期して詰め込んだ長い機能設計仕様書を作って新しいプロジェクトを開始しました。プロダクトとエンジニアリングは実際には開発中にはあまりやりとりをしないのに、です。この仕様では、Webアプリケーションとバックエンドサービスチームに提示され、ユーザーチームとバックエンドの側面を個別に担当しました。新しいインフラストラクチャのリクエストは、数週間前に運用チームに提出する必要がありました。

こうした努力の数々をすべて一貫した機能リリースに統合することは悪夢でした。我々は不完全なインフラしかなかったり(またはまったくインフラが用意されていなかったり)、バグ、機能ギャップ(各チームが、きっと他のチームがそれをやっていると思いこんでたのです)、エンジニアと製品の両方のオーナーシップやエンパワーメント、日数不足、組織のサイロ化や不整合がありました。期限通りに出したいという欲が、リスクテイクを減らすことにつながりました。私たちは実装においてより慎重になり、製品の仕様を調整することに嫌気しました。

この部門の構造と開発プロセスの組み合わせは、その年のエンジニアリング内の他のすべての議論の最前線にサイロの話題を押し上げました。 おーい僕らはサイロに落ちているんじゃないの?と。

Webアプリケーションvsバックエンドサービス 2つのグループの間 には緊張がありました。 どちらも他のグループが取り組んでいたことをちゃんと理解しておらず、不満でした。

Ruby vs Scala 上記と似ていますが、特定の言語を中心に多くの「自転車置き場」(注:本当に必要か、どこに作るべきかをきちんと検討せずに作られたものを指す)やアイデンティティを構築していました。

オペレーションvs開発チーム。両方とも開発チームがすべてのサーバープロビジョニングのボトルネックとなっていることに不満を抱いていました。オペレーションは迫りくる締め切りに大きなプレッシャーを経験していました。

サンフランシスコvsトロント。 地理的に2つの場所に分かれたエンジニアの間で、同じ場所にあるエンジニアはまとまり、はっきりとした「彼らと私たち」の雰囲気が生まれました。 両陣営は何かと相手に不満を募らせました。

責任の集合を厳密に定義すればチーム間の機能的な連携に多くの余地を残すことはありませんでした。 私たちは、「ワーキンググループ」という概念を試してみたこともあります。小規模で一時的で多様なチームが責任範囲と日程が明確な横断的なプロジェクトに取り組むことを目的として、既存のチームからメンバーを編成しました。こうした取り組みは、プライマリチームを不安定化させて混乱を招いてしまったので、実験は中止されました。

でもみんなで協力してより高い整合性と予測可能性を顧客に提供することが一番大事なことでした。みんながサイロ化に悩んでいたので、解決しなければならなかったのです。私たちはなんとかやり遂げました。

マトリックス化した組織に

2015年の初めには、物事の状態への不満やアジャイル・メソドロジへの関心の高まりが重大になり、部門別に同様が生じました。特定の製品の方向性に合わせていくつかの新しいチームが結成されました。彼らはScrumプロセスに従い、Webアプリケーションとバックエンドサービスチームのエンジニア、製品所有者、Scrumマスター、UXデザイナーで構成されていました。

前年度の製品進捗状況が理想的ではなかったことを考え、新しいチームは製品提供のために最適化されていました。新しい機能の導入に100%時間を費やすことができるように、メンテナンス作業はバックエンドサービスチームに委任されました。これらはKanbanの方法論を採用し、「ベースチーム」として知られるようになり、プロダクト内のすべてのオンコールの責任を含め、すべてのサービスのオーナーシップを取りました。さらに、製品チームに供給された基本チームは、製品作業の増加に伴い、エンジニアが一方から他方に移行しました。

これらは明らかに大きな変化でした。個々のエンジニアへのチームシャッフルの影響を最小限に抑えるため(また、リモートレポートを処理することをやめるため)、レポート関係には触れませんでした。これはもちろん、皆さんの人生を驚異的に複雑にしました。なぜなら、マトリックス型の組織という二重のレポート構造を持っていたからです!多くのエンジニアは、直属のスーパーバイザーに割り当てられていないチームに所属し、マネージャーは、「人事マネージャー」(人員を管理。他のチームに所属する人も含みます)と「機能マネージャー」になりました(チームを管理。一部のエンジニアは別の人にも報告をしていました)。

良かった点は、古いサイロがほとんど壊されたことです。それが復活することはありませんでした。バックエンドサービスエンジニアと緊密に連携するWebアプリケーションエンジニアは、互いの違いを認識しながら、共通の目標に向かって進むことができました。もっとも、ほとんどのチームは地理的にも分散していたため、2つのオフィスを統合するのを不思議に思っていましたが。

悪いニュースは、新たな問題が発生したことでした。

テクニカルメンテナンスに関係するチームを結集することは非常に困難でした。ベースチームは、長期のロードマップを形成し、すべてのプロダクションサービスの運用上のオーナーシップをとる羽目になりました。

フィーダーモデルが各チームの結束に非常に大きな影響を与えました。チームの構成を何度も変えていくことは、士気にはあまり良いことではないことが分かりました。

二重のレポート構造はとても非効率でした。直接のレポートでは日常的な活動が見えず、人事マネージャーと機能マネージャー間ではコミュニケーションのオーバヘッドが起き、責任に関して混乱がありました。

私たちは、敏捷性よりもむしろアジャイルプロセスを採用しました。Scrumは、過剰な仕様、統合、製品のオーナーの関与を確かに助けました。しかし、ソフトウェア配信に対する当社のアプローチは変わらず、機能リリースは依然として価値があるかどうか怪しいという大きな問題があるものでした。

より多くのチームがオペレーションの人々に多くの負荷をかけました。インフラストラクチャの要求が頻繁になり、新しいサービスごとにオンコールの責任が追加されるため、このアプローチは拡張されませんでした。

すべてのことを考慮すると、私たちはまだ1年前よりずっと良い形になっています。

しかし、まだまだ道のりはまだまだありました。

アジャイル組織

新しい組織体系で1年間生活した後、私たちはかなりの数の学習を蓄積しました。 アジャイルはうまくいっていましたが、十分な作業はしていませんでした。DevOpsはうまくいっていましたが、十分に機能していなかったので、マトリックス管理はそれほど良くありませんでした。

2016年の早い段階で、我々は再び再編した。 「垂直」製品スクラムチームは現在、製品の特定の部分を担当していました。 「水平」チームは、製品やインフラストラクチャの問題を横断する責任があり、ベストプラクティスを設定し、他のチームが速やかに動くことを可能にしました。 プロダクトデリバリーチームは、ロードマップ、要件定義、実装、デプロイメント、運用中のコードとインフラストラクチャ(!)の保守を所有していました。 私たちは真の開発者を採用しました.Ops「あなたはそれをコードします、あなたはそれを所有しています」アプローチ。

これは以前の懸念をどのように解決しましたか?

メンテナンスチームはこれ以上ありません。各チームは製品やインフラストラクチャの一部を所有し、迅速に移行し、革新する権限を与えられました。

フィーダーチームはこれ以上ありません。特定のチームに対して人員が開かれました。

もう二重報告はありません!組織として、遠隔のエンジニアの採用と管理をより快適にしました。物理的な距離がもはや障害ではなくなったので、私たちはマネージャーを点線関係のないチームに割り当てることができました。

私たちは物事を終わらせることに集中しています。 GSD(Get Sh * t Done)のマントラは、チームが実用的で生産的で機敏なデリバリーマシンに成長するために、過剰仕様化とオーバーエンジニアリングのイントロスペクトと遺産を捨てるようにチームに挑戦し、私たちの集団意識に浸透しています。

セルフサービスで成長が可能。オペレーションチームは、あらゆる種類のインフラストラクチャニーズに対応できるように、魅力的なChatOpsツールを提供するなど、製品配信チームに力を与えるために多くの作業を行いました。これはDevOpsを徹底的に採用し、インフラストラクチャのアラートをOpsから、実際のホスト(問題をより速く解決できる人)を持つ関連チームに移動するための鍵でした。

GSDの主題はもう少し詳しく調べる価値があります。練習を通して、私たちは、チームの自律性、発明よりも革新的なアイデア、そして実現する解決策ではなく解決するための問題をビジネスにもたらします。顧客にとって何がベストかを知っているという考えを放棄するのは容易ではありません。実行可能な最小限の製品を提供し、開発サイクル中に即座にフィードバックを取り込み、それを組み込むことに重点を置いたのが、レーザーの焦点でした。迅速に反復し、価値を最大化し、金めっきを最小限に抑え、数ヶ月から数日または数週間の間にプロトタイプを顧客の手に渡す時間を短縮することができました。言い換えれば、「アジャイルプロセスに従う」組織から実際のアジャイル組織に変化しました。

製品納品チームの数が増えるにつれて、興味深い現象が発生しました。いわゆる「部族」(Spotifyのチームモデルに対するハットチップ)、つまり共通の機能や共通の使命でチームのグループが出現しました。これらの取り決めにより、共有された所有権、知識の共有、ロードマップの共有(個々のチームのバックログとは別)、共有されたビジョンなどの利点がもたらされました。部族組織は私たちがまだ実験しているものです。部族との習得についての今後の更新についてお楽しみください。

私たちはこの構造で16ヶ月稼働しています。確かにチームと関連するオーナーシップラインは、会社が急速に成長し続けるにつれて進化します。同時に、正しいことがどのように見えるかを知るために、間違ったことを十分に行ったことは明らかです。

学んだ教訓

私が早期に決定したいくつかの決定と、組織が耐え忍んだ厄介な中間的な状態のいくつかに戻って考えると、私は頭の中で自分自身を叩きつけ、 明らかに優れた終わりの状態。 もちろん、現実は決して簡単ではありません。その決定は当時の国家、優先順位、国民、そして私たちの課題の関数でした。 あなたは自分の挑戦のいくつかを認識しているかもしれません。その場合、あなたは私たちの経験から何かを取り除くことができると願っています。

私がそれを何度もやり直さなければならない場合、これは私が私と一緒に持ってくる学習です。

チーム間の依存関係を最小限に抑えます**。 依存関係は、ブロック、バグ、誤解、悪い気持ちにつながります。 チームが他の人たちを待つことなく提供できるようにすると、生産性が大幅に向上します。

チーム構成の変更を最小限に抑えます**。 ビジネスの現実は、時折、リソースをある場所から別の場所に移す必要があることを指示しています。 チームの士気と生産性に重大な影響を与える可能性があるため、人を動かす前に長く考えてください。

チームの所有権と責任を過度に処罰しないでください**。 ここでの柔軟性は、長期的な勝利につながります。 チームに自分の問題を解決させるよう促し、前の2つの点で問題が少なくなります。

継続的な学習と実験を恐れないでください**。 これはコード、プロセス、組織といったすべてに適用されます。 同じことを何度も何度もやり続けると、1つは良くなりません。

アジャイルプロセスは素晴らしいです。アジャイル・カルチャーが優れています。スタンドアップとスプリントレビューは、自分自身で大きな価値をもたらすわけではありません。実行可能な最小限の製品、迅速なフィードバックループ、およびコラボレーションに焦点を当てることは、文化的な変化を必要としますが、提供される顧客価値を最大化します。

コードの運用上の所有権はチームと一緒に存続する必要があります。システムの信頼性、コード品質、および組織のスケーラビリティのバランスをとるための最良の方法です。

クロスファンクショナル、フルスタックのチームが製品の配送に最適です。これは、上記の依存性の最小化ポイントと非常によく似ています。各チームは、外部の専門家やプロジェクトのハンドオーバーを必要とせずに、要件の収集から展開に移行できる必要があります。スペシャリストチームには場所がありますが、以前に議論された「水平」チームの領域ではより多くのものがあります。

どのような環境でも動作できるジェネラリストを雇う。チームメイトは、技術と技術の方向性が変わるにつれて、特定のツール、フレームワーク、スタックにアイデンティティーの感覚を付けてはなりません。成長の著しい環境で成功するために最適な人材は、仕事に適したツールを学習して使用することに重点を置いています。したがって、学習と成長の機会を提供する準備ができていること。

あなたがそれを助けることができるならば、行列での管理を避けてください。 二重報告が解決するように見えるかもしれない問題に対処する他の方法があるかどうかを検討してください。

分散チームを受け入れる。 離れたメンバーと緊密なチームを構築することには課題はありませんが、そのメリットは多くあります。 Martin Fowler氏は、「チームを遠隔地にすることで、チームにもたらすことのできる人の範囲を広げることができます。 遠隔地のチームは、同一のチームが同じ場所にいる場合に比べて生産性が低いかもしれませんが、あなたが形成できる最高の共同チームよりも生産性が高いかもしれません。 、より強固なチーム全体を構築することができます。

組織が成長し成熟するにつれて、減速し、石灰化し、より保守的になる傾向があります。 継続的な改善を実践し、プラクティスを進化させることで、我々は負に陥らないようにし、時間をかけてより機敏で、実用的で、生産的に成長することができました。

3年間(そして多くの)の学習の成果がここにあります!

2019年4月11日  (更新日:2022年3月11日)     |    ベストプラクティス

Postmortem(事後検証) パート2:学習する文化を取り入れる方法

事後検証(ポストモーテム)シリーズのパート2では、リーダーシップを発揮することから文化面での変化を起こすことまで、継続的な学習の文化を確立する方法を掘り下げます。*

文化は私たちが物事を一つにする方法です。それは一貫した形で目標を満たす幸せで健康的なチームを作るための秘密のソースです。組織の中で定義し、育て、変革するのは最も難しいことです。真の文化的変化には、ポリシーを作って伝えること以上のことが必要です。コラボレーション、永続性、そして実験が必要です。

PagerDutyの私たちはアジャイルの方法論とDevOpsプラクティスの大ファンです。私たちは、ソフトウェア開発から文化の変化まで、継続的な改善の原則を適用しました。反復的な評価とコラボレーションを通じて、文化を正しい方向にシフトさせることができます。

これは別のコアなDevOpsプラクティスである事後検証に思い至らせます。事後検証の成功は単なるプロセスにかかっているのではなく、誠実さ、学び、説明責任の文化に基づいています。企業文化の変革には経営陣の参加が必要ですが、自分の役割に関係なく文化の変革を先導することができます。

身近なところから始めよう

あなたの会社のプロセスの全面的な見直しに着手する前に、どこから始めるのかを把握することは重要です。インシデント後の報告には事後検証プロセスを使用していますか? あなたが従うステップは何ですか? 誰が関与していますか? 失敗についての会話は通常どのように行われますか? あなたのチームがこれらの議論をすれば、関係者の責任を問わない事後検証を実施する文化への移行を始められると思います。

多くの企業は、重大インシデントの後に、何が起こったのかを検討する会議を開くでしょう。これらの議論の過程で少数の個人がインシデントに対する責任を負わされるのを見ることになるかもしれません。一般的に、全員がもう少し詳しく知る前に、将来問題を避けるための計画を立ててしまいます。さらに重要なことに、少数の人々があなたが避けたいと思う、かなり不愉快な気分で立ち去ります。

あなたのチームに迅速な監査ができるように事後検証の実施のためのステップバイステップガイドを見てください。現在していることや、現在何をしているけれど微調整する必要があるかもしれないこと、そしてしていないことは何でしょう?

責任を問わないことをリーダーに求める

事後検証を組織にまったく新しいやり方として紹介するにせよ、既存のプロセスを改善するために動いているにせよ、文化の変革は難しいものです。伝統的には変革より管理が優先されると思います、しかしボトムアップでの変革は通常もっと成功をもたらすものです。 あなたの役割が何であれ、新しいプロセスを導入するための最初のステップは、経営陣からの承認を得ることです。

変革について思慮深い推論を用いリーダーに近づくことが、その変革が持つはずの重要性と影響を強化するのを助けます。 そのための対話で重要な点は次のとおりです。

責任追及がどれほど有害であるかを明確にし、定量化し、そして責任追及のビジネス上の価値を説明する。

問題を「引き起こした」ことを理由に個人を罰する慣習は、問題が発生したときに人々が責任追及されることを恐れて発言しなくなるように仕向けます。結果としてインシデントを認識して解決するまでの平均時間が長くなり、最終的にはインシデントの影響が大きくなり、深刻な影響を受ける可能性があります。問題が発生したらできるだけ早く解決できるように、リーダーは人々に発言を求めてください。

組織は責任追及される恐れを排除し、共同学習および反復的な設計の改善を促すことによって、システムの回復力を急速に向上させ、イノベーションのスピードを上げることができます。

さらに、バカみたいに聞こえるかもしれませんが、新しい事後検証プロセスを売りこむときに、管理側のせいにしないことを忘れないでください。リーダーがチームに加わっていることを確認してください。インシデント後に誤って責任追及を示唆した場合には、彼らがそのフィードバックを受け取るのを納得するというリーダーシップの確約を得ることが重要です。

ゴールは、継続的改善の文化を作るためにリーダーに確実に参加してもらうことです。

Pro tip___:責任追及をしないという概念を会社の価値にマップできるかどうかを確認してください。例えばPagerDutyの文化的価値観の1つは、特に中断と継続的な改善を受け入れ、常に学習に集中することです。このような責任を問わない事後検証の概念は、これらの価値を支えることに直接対応できます。

チームを指導する

これでリーダーシップが完成しました。組織で大きな文化の変革を遂げることができました。次のステップはあなたのチームの個々のコントリビューターの参加を確保することです。彼らがまだ、インシデントの責任を追及されることを恐れているかもしれないことに留意してください。その恐れは、ポリシーだけでは消えないでしょう。インシデント対応後にどんな方法でも誰も罰せられることはない、という経営陣からのコミットメントを得ていることを必ず共有してください。責任をもっと意識して、責任が認められたらお互いに声をかけて協力することで、同僚との信頼関係を築きましょう。

(グループ内での心理的安全性の重要性について読んでください。)

変革を繰り返す

文化の変革は一晩では起こりません。実験を成功させた結果を新しいプラクティスと共有し、次にそれらのプラクティスをチーム間でゆっくりと拡張するなど、小規模から始めて新しいプラクティスを組織に繰り返し導入します。

始め方:

チームを1人選び、完璧な事後検証の実験を始めましょう。** 始めるには、「事後検証記録の書き方」ガイドを使用してヒントを共有してください。スキルを磨き、他の人に教えます。

小さなインシデントから始めましょう。** 小さなインシデントのビジネスへの影響は小さいため、インシデントの原因として個人をスケープゴートにする圧力は少なくなります。

責任追及する人を批判しないでください**。上記で推奨されているように、個人に責任を負わせがちな人を探してください。必ず声をかけて、チームがこのインシデントに対して新しい、責任追及のないアプローチを使用することを決定したことを伝えてください。

覚えておいてください:責任追及のない事後検証へのグループの信頼を築くために最初は単純なものから始めてください。チームにとって最適なものを試し、次のラウンドで繰り返します。

共有することはケアすること

組織のためでも、単一のチームのためであっても、文化的シフトを促すには大きなエネルギーを必要とします。試みられ、テストされ、そして最終的に採用される前に、それが「難しい」という単なる認識のために、変革は時に強く非難されることがあります。

インシデントレポートを共有することは、最初は直感に反するように思われるかもしれません。成功というより失敗のストーリーを共有するように思えますからね。でもそれとは全く反対に、チームは失敗から学んでシステムを改善し、失敗の発生率を減らせます。

インシデントを個人的な失敗としてではなく、具体的な改善をもたらす学習機会として再考することです。それは士気を高め、ひいては従業員の定着率と生産性を高めます。

批判しないことがアカウンタビリティを育てる

自由に情報を共有し、透明性を促すことで、説明責任を養う環境を支えられます。事後検証のあとに起きることは、システムの健全性にとって重要です。事後検証の行動項目が網羅されたと思われた時点でSLAを設定することは、チームがタスクを迅速に割り当て、優先順位を付けるのに役立ちます。また、許可を待たずにチームが行動に移れるようにします。

Pro-tip*:このSLAをすべてのエンジニアリング部門に伝達し、将来の参考にするために必ず文書化してください。

PagerDutyでは、Sev-1インシデントの再発防止に必要な優先順位の高いアクションアイテム(行動項目)は、インシデントから15日以内に完了することを期待しています。Sev-2インシデントから得たアクションアイテムは30日以内に対処されるべきです。

カルチャーのチャンピオンになる

あなたの会社の文化を良い方向に変えることは、実現が最も難しい仕事のひとつです。信じられないほど微妙で、高レベルの共感を必要とし、そして感情的に疲れることです。継続的に学習する、責任を問わない文化を促進することは、より幸せなチームとより良いソフトウェアにつながるので、組織にとって最も重要でやりがいのある作業でもあります。

評価、コラボレーション、コミュニケーション、そして実証という具体的なステップを適用すれば組織を正しい方向に変えることができます。

現在の事後検証プロセスの状況を知ることから始めましょう

リーダーとチームの了承を得て、責任を問わない事後検証を試しましょう

1チームまたは小規模なインシデントで試してみてください

実証結果を共有して、変化を広めてください

責任を問わない事後検証を採用する方法の詳細については、包括的な「Postmortem Guide」をご覧ください。あなたがどのようにして文化の変化にアプローチし、誠実さを広めているかをお聞きしたいです。当社のフォーラムにアクセスしてコミュニティと情報共有してください

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

2020年7月20日  (更新日:2022年3月10日)     |    ベストプラクティス

インテリジェント対応と自動化で、少ない労力で多くのことを行う

良くも悪くも、私たちの社会はは効率化に取りつかれています。オンラインバンキングやEコマースアプリからスマートIoTデバイスに至るまで、私たちの生活の隅々にその痕跡があります。しかし、私たちは個人生活のほぼすべての面で自動化を使用しているにもかかわらず、PagerDutyとDimensional Researchが実施した共同研究では、90%の企業が問題解決のための自動化をほとんど、あるいは全く行っていないことがわかりました。なぜでしょうか。私たちは簡単なことをより簡単にするため、私たちの生活の中で毎日自動化を利用しているのに、なぜ仕事でもそれを利用していないのでしょうか。

頑張らずに賢く働く

社内では「技術の達人」と呼ばれているにもかかわらず、仕事を終わらせるために面倒な手動のプロセスに頼っているIT担当者の多さに驚くことでしょう。

多くのITチームは、時間やリソースを最大限に活用できていません。その代わりに、問題への対応方法を決定するためにハンドブックに目を通したり、過去のインシデントを手作業で調べて関連性があるかどうかを確認したりしています。しかし、チームの効率を向上させ、収益を守るための最も簡単な方法の1つは、インテリジェントな対応と自動化であり、繰り返し可能な手順を自動化することで、貴重なリソースを他の場所に再配分することができます。

2020年春に発表された最新の機能強化では、インテリジェント対応と自動化に3つの方法でアプローチしています。(1)人とプロセスの調整、(2)対応チームが必要なときに適切なコンテキストと情報を提供する、(3)使いやすい自動化機能を提供することで、問題を迅速に診断して解決できるようにする。これがどのように機能するかを詳しく見てみましょう。

新機能の詳細 インテリジェントトリアージ

PagerDutyイベントインテリジェンスの一部として、モバイルで利用できるようになったインテリジェントトリアージは、チーム作業の重複を防ぐことができます。これにより、複数のチームに影響を与えるインシデントについて、何が本当の原因となっているかを判別するために、Related Insidents機能を使用することができます。Related Insidentsは、イベントインテリジェンスの機械学習機能をノイズ削減の域を超えて拡張し、サービス全体にわたってリアルタイムのコンテキストに基づいた洞察を対応者に提供します。

目下のインシデントに関連している可能性のある他のサービスで同時発生しているインシデントを調査することで、対応者は影響の幅と範囲をより深く理解し、重複したコミュニケーションを回避し、問題解決のためにチームがお互いを邪魔しないようにすることができます。インテリジェントトリアージは、機械学習を利用して以下のことを可能にします。

ビジネス全体で今現在何が起こっているかを見る 問題がローカルなものなのか、他に影響を与えるものなのかを理解する 適切なチームメイトを募り、協力して問題を解決する MTTRの改善

インシデントの再開

時には、インシデントが実際には解決されていないにもかかわらず、対応中に誤ってインシデントをクローズしてしまうことがあります。あるいは、インシデントが終了したと思って大規模なインシデントを解決済みにしたにもかかわらず、その後すぐにモニタリングやカスタマーサポートなどの他のチャネルを通じて、同じ原因に起因する進行中の症状に気づくこともあります。

大丈夫です、間違いは起こります。私たちは皆人間です。だからこそ、PagerDuty は新しいアラートをトリガーすることなく、応答者がインシデントを再開することができる新機能(アーリーアクセス可能)をリリースしました。このシンプルでありながら重要なアクションは、対応者の柔軟性を高め、インシデントの重複を減らし、重大なインシデントの症状が再発していることが判明した場合に、対応チームの再動員をより速く、より簡単にします。また、ServiceNowのような隣接するツールを同時再開することができます。

ランブックオートメーションのインテグレーション

もう1つの方法は、運用上の「ランブック」で取得した手動または部分的に自動化された手順をすべて自動化して、自動化されたインテリジェントなインシデント対応プロセスに接続することです。Amazon EventBridgeとの既存のインテグレーションに加え、ランブック自動化のために新しくリリースされたRundeck、Ayehu、およびPliantとのインテグレーションは、Amazon EventBridgeとの既存のインテグレーションに加えて、手動のITレスポンスプレイワークフローを自動化し、対応チーム内のコミュニケーションと解決スピードを向上させることができます。

Rundeck 統合のランブック自動化機能を使ったインシデント対応の例を見てみましょう。

「Eコマースビジネスのピーク時にサーバがダウンして、顧客がチェックアウトしたり、カートの中の商品を購入したりすることができなくなりました。PagerDutyはインシデントが発生したことを適切な人に警告しました」

さて、どうしますか。どのようにして対応者がインシデントを診断し、解決するための迅速な行動を取ることができるでしょうか。もし彼らが同僚や他のチームにエスカレーションしなければならない場合、あなたは時間をロスすることになります。wikiを閲覧したり、マニュアルのランブックを調べたりする場合も時間の無駄になります。

そうではなく、対応者が行動を起こすために必要な自動化されたオペレーション手順に安全にセルフサービスでアクセスできるようにしましょう。Rundeckによるランブックの自動化により、対応者の誰もが専門家と同じように診断や修理の手順を安全に実行できるようになり、インシデント時間をより短くし、より少ないエスカレーションで済むようになります。

RundeckとPagerDutyのインテグレーションにより、以下のことが可能になります。

PagerDutyのインシデントの開始時に自動的にRundeckジョブをトリガーする。例えば、最初の対応者がPagerDutyにログインする前に診断を開始したり、修理アクションを試したりする PagerDutyのWebやモバイルUIでカスタムアクションを使って、インシデント発生時にRundeckジョブをトリガーする Rundeckジョブが自動的にPagerDutyのインシデントノート/タイムラインを更新する Rundeckジョブが失敗した場合にPagerDutyインシデントをトリガーする

このシナリオでは、ランブックの自動化を利用することで、Eコマースビジネスはリソースをより効率的に展開し、MTTRを改善し、停止の結果として失われる収益を保護することができます。

インテリジェントな対応と自動化を実現

これらの新機能は作業の重複を減らし、機械による手作業の自動化を可能にすることで対応者の負担を軽減します。PagerDutyはチームに少ない労力でより多くのことを行う能力を与えることで、企業の回復力を向上させ、顧客との関係性と獲得した収益を保護することを支援します。

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

<  123  >