Blog
ブログ

2022年1月28日  (更新日:2022年9月12日)

インテリジェントなサービス設計

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

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

サービスについて

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

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

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

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

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

粒度

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

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

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

次に何をするべきか

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

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

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

続きを読む
インシデント&アラート
2022年1月27日  (更新日:2022年9月13日)

インテリジェントアラートグループのタイトルのつけ方

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

引き続き、IAG(Intelligent Alert Grouping)の活用・改善方法について、第3回目をお届けします。最初の投稿では、インテリジェントアラートグループ化機能を紹介しました(こちら)。2回目の投稿では、IAGがどのようにマージを使用してアラートをグループ化するのかを説明しました(こちら)。本日は、IAGのマッチングを向上させるためにアラートタイトルを使う方法について説明します。

アラートタイトルが表示される場所 - 再確認

アラートがプラットフォームでトリガーされると、eメール、テキスト、またはアプリ自体からのプッシュ通知など、いくつかの経路で通知が行われることがあります。どの経路であっても、表示される最小限の情報は、アラート番号、サービス、およびアラートタイトルです。これは、いくつかの注目すべき場所に表示されます。アラートの受信方法によっては、これらの一部または全部が見慣れたものかもしれません。緊急度レベル(例:高)は、連絡方法を決定するために使用されますが、目に見える形で表示されないことに注意してください(ただし、インシデントの詳細には表示されます)。

電話のプッシュ通知とテキスト通知

例えば、iPhoneのロック画面を見てみましょう(同じインシデントについてのテキストメッセージ通知や電話着信)。

これはブログ投稿のために全てのチャンネルにアラートをプッシュしています。ここでは、アラートのタイトル、番号、サービスが表示されていることが分かります。テキストメッセージも似たような感じです。

メール通知

これらは少し違っているように見えます。メールの件名にはあまり詳細が書かれていませんが、メッセージの本文にはアラートの詳細が記載されています。

なぜ、アラートタイトルの表示場所を見直すのですか?

私のような方なら、実際の状況やサービスに関するアラートタイトルや説明文を書いていたときは、人間の脳に最適化させていたのではないでしょうか。証拠は上にも表れています。このアラートタイトルはブログ記事のタイトルのようだし、文頭に「Title」という識別子を強引に含んで、それが表示される場所を強調しています。これは人間のためのもの。読者の皆さんが画像から情報を読み取る際に、私が特定の部分に注目してもらいたくて故意にやりました。

もし、人間以外のために設計するとしたら?例えば、機械学習に適した設計ならどうでしょう?機械学習について知っていることや学んだことを何でも取り込み、それらを活用しようとメッセージを歪め始めるでしょう。

私が皆さんにお伝えしたいのは、このことです。インテリジェントアラートグループの体験を向上させるために機械学習を取り入れる際にも、人間のことを念頭に置く必要があるということです。

アラートタイトルを活用する

人のためにアラートタイトルを構築するとき、忘れてはならないことがあります。

簡潔であること。ご覧の通り、プッシュ通知もテキスト通知も文字数制限が短いです。 OSやウェブブラウザーによって制限が異なります。例えば、Androidの場合、プッシュするタイトルの文字数制限は65文字で、さらに説明文の文字数制限は240文字です。iOSの場合は、タイトルと説明文を合わせて178文字となっています。

明確であること。タイトルが分かりにくくなったり、何も伝わらなかったりするほど簡潔であってはなりません。 タイトル欄を優先するあまり、他の欄をおろそかにしないこと。 ウェブインターフェイスと同様に、PagerDutyモバイルアプリでは、他のインシデント、そのサービス、その説明を含む完全なインシデント情報を利用することができます。最初に表示されるからといって、タイトルフィールドに情報を盛り込みすぎないでください。

これらの詳細については、インシデントレスポンス運用ガイドの「アラート発信の原則」のページをご覧ください。

機械学習では、以下のことに注意しましょう。

識別性と頻度を上手に利用する。 データモデルは(人間と同じようには)読むことができない。 データモデルは意図を推論することができない。

その理由は、機械が「自然言語処理」と呼ばれるものをどのように行っているかを理解するためです。自然言語処理とは、スペルチェックや文法チェッカーが「it's」と「its」を区別して著者に通知したり、オートコレクトがどの単語と活用、どの形式(活用、自然下降)を提案するかを知るためのものです。アラートタイトルに適用される自然言語処理では、タイトルを匿名化し(詳細は後述)、「文トークン化」と「単語トークン化」というプロセスでそれぞれ文と単語に分解し、単語を見出し語化(レンマ化)して、最終結果を頻度の決定と他のアラートとの相関性の検索に使用します。

匿名化から始めると、例えば特定のIPアドレスをxx.xx.xxに置き換えるように、そうでなければあまりにも一意な情報をその情報のパターンに置き換えることが目的です。このテキストは、一意な情報によって本来関連するはずのタイトルが関連しなくなることを防ぎます。関連する可能性のあるコンテキストが完全に削除されるわけではありません。レンマ化とは、活用語や屈折変化をレンマと呼ばれる基本形に単純化する工程のことです。再び例で説明します。{“dogs”, “dog’s”, “dogs’”, “dog”}は全て“dog”にレンマ化され、同様に{“is”, “are”, “be”, “were”}は”be”にレンマ化されます。つまり、“The dog's bones.”と“The dogs' bones.”のような文は、この段階でどちらも{“the”, “dog”, “bone”, “.”}にレンマ化されるのです。

この時点で、インテリジェントアラートグループモデルは、N-gram(N個の単語のグループ)とインシデント言語のパターンに関する知識の両方を使用して、アラートタイトルから情報を抽出し、意味のある相関関係を作成します。前回の記事で紹介した例をもう一度見てみましょう。

最初のパターン memory usage high (> N %) on server $NAME in region $REGION 2つ目のパターン memory usage on host is high (> N %)

既にN %と$NAMEで少し匿名化しましたが、これらのタイトルにあるものをトークン化する練習をしてみましょう。 トークン化、レンマ化された最初のパターン。 {“memory”, “use”, “high”, “(“, “>”, “N”, “%”, “)”, “on”, “server”, “$NAME”, “in”, “region”, “$REGION”} トークン化、レンマ化された第2パターン。 {“memory”, “use”, “on”, “host”, “be”, “high”, “(“, “>”, “N”, “%”, “)”}

パターンが意味することの影響を考えると、2番目のアラートでは、そこに置かれた値によって変化する唯一の用語はNです。もし閾値が現在のメモリー使用量ではなく、一貫したものであれば、Nは全く変化しないか、タイトルに表示される値が1つか2つしかない可能性があります。それに対して、最初のアラートのタイトルには、サーバー名とその地域の一意性がより強くなっています。つまり、用語は1つまたは全く変化しないのではなく、3つの変化する用語があるわけです。言語処理装置に関する限り、2番目のパターンのアラートは1番目のパターンよりも相関関係がある可能性がはるかに高いです。

これからの方向性

アラートのタイトルを作成する際には、人間と機械学習の両方を考慮することが重要です。人間はアラートやインシデントの詳細情報を利用して追加のコンテキストや情報を得ることができますが、インテリジェントアラートグループではタイトルフィールドのみを使用するため、機械学習の最適化を若干意識するとよいでしょう。自然言語処理の基本については、Towards Data Scienceブログの「Introduction to Natural Language Processing for Text」ブログ記事をご覧ください。一般的にアラートやインシデントに含めるべき情報についてのベストプラクティスは、当社のインシデントレスポンス運用ガイドをご覧ください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

続きを読む
インシデント&アラート
2022年1月26日  (更新日:2022年9月12日)

Event Orchestrationの活用でノイズを減らし、次善の策を講じる

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

そこで私たちは、Event Orchestrationを発表し、Event IntelligenceとDigital Operationsをご利用中のお客様に月曜日から提供し始めました。

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

Q: 新機能のEvent Orchestrationについて教えてください。

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

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

Event Orchestrationについて考えるとき、もしお客様がルールを設定する方法をより柔軟にし、より多くの自動化機能を前もって使用できるようにすれば、チームが通知を受ける前に、これらのすぐ解決策が分かるタスクをできるだけ多くカバーすることができるのではないでしょうか。

Q: Event Orchestrationは、Event Rulesとはどう違うのですか?

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

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

Q: Event Orchestrationの利用を検討している人にとって、ハードルの低い利用例を教えてもらえませんか?

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

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

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

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

もっと詳しく知りたいですか?Event Orchestrationの詳細については、ナレッジベースの記事、またはこちらのデモをご覧ください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

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

PagerDutyは、従業員の健康を第一に考えています

PagerDutyは、育児休暇と従業員の健康増進のために、業界をリードするプログラムを導入したことを誇りに思っています。従業員とともに、全てのデュートニアン(訳注:PagerDuty社員をDutonianと呼んでいます)のために健康で幸せな職場を築くことを約束します。

業界をリードする育児休業制度

最新のPagerDuty Inclusion, Diversity, and Equity Annual Reportによると、社員の約30%が親または介護者であることが判明しています。グローバルな育児休暇制度であるBabyDutyを通じて、私たちは手厚い有給休暇を提供しており、多くの場合、最低限必要な条件以上のものを用意しています。例えば

米国**:妊娠中の両親は最大22週間、養父母など妊娠していない両親は最大12週間の有給育児休暇を取得できます。 カナダ**:妊娠中の両親は最大22週間、養父母など妊娠していない両親には12週間の有給育児休暇を取得できます。カナダ雇用保険と連携しています。また、カナダで義務づけられている育児休暇の残りの期間については、無給で休暇を取得できます。

2022年に新たに段階的な職場復帰ポリシーを導入し、初めて育児をする従業員には、再びフルタイムになる前に最大4週間の短時間勤務での復職オプションを提供します。1日の労働時間や1週間の勤務日数を50%から75%相当に減らすことができ、職場復帰をしやすくなります。

さらに、有給育児休暇期間中の基本給以上の給与をカバーするために、制度を拡充しています。この新しい制度の意図は、ボーナスやコミッションの対象となる従業員を経済的に補填することです。

両親や家族をサポートする

子育てには大勢の力が必要なため、従業員のコミュニティーも拡大しています。育児に伴う多くの義務を全うできるように、従業員はCleoとCare.comに会員登録し、特典を利用できます。

Cleoを通じて、健康、育児、およびキャリアのニーズをサポートする専任のスペシャリストが従業員につき、ストレスを軽減しながら育児をできるようになります。 Care.comを使用すると、従業員は認定されたチャイルドケアプロバイダーの幅広いネットワークにアクセスできます。 米国とカナダの従業員は、バックアップケアを利用することもできます。これは、年間5日間の助成されたチャイルドケアの補償範囲です。

「パンデミック(世界的大流行)の時期に親であることは、特に近くに家族がいない場合、大変なことです。今年の初めにシッターが病気で休んだとき、1日だけなら何とかなりましたが、1週間の休みが必要となったとき、大慌てしました。PagerDutyのバックアップケアを試してみることにしました。Care.comは2時間以内に認証済みのシッターを割り当ててくれ、翌朝に到着してからその週の残りをカバーしてもらえました。こんなに簡単だとは信じられませんでした。」-Karen、PagerDutyシニアプログラムマネージャー

充電の時間

COVID-19が大流行した際、社内のウェルビーイング調査を通じて、社員がストレスを感じており、仕事以外の自分の時間を十分に確保できていないことが分かりました。

その結果を受けて即座にDutonian Wellness Daysを設定しました。これは、他の有給休暇や祝日に加え、社員が仕事以外の時間を楽しむための全社的な有給休暇です。全社的な休暇は、PagerDutyにとって新しいものではありません。数年前、私たちは会社の伝統であるHibernationDuty(冬眠当番)を通じて、会社全体が同時に休暇を取ることに大きなメリットがあることを知りました。年末のHibernationDutyでは、社員は1週間の休暇を楽しみ、会社は少人数のカバレッジチームで運営されます。この期間、社員はメールや仕事が溜まっていることを気にすることなく、完全に切り離すことができるのです。

Dutonian Wellness DaysとHibernationDutyの成功により、今年初めて有給の真夏のWellness Weekを提供できることを誇りに思います。私たちは、従業員が十分に休息することで、毎日の「Champion the Customer」が可能になると考えています。

ウェルビーイング施策の導入以来、レジリエンススコア(頻繁に従業員満足度を測定しています)の好感度が25ポイントも上昇しました。これらの結果と従業員からの圧倒的な好意的なフィードバックに基づき、私たちは従業員の健康に投資し、この変化を企業文化の一部として定着させたのです。

従業員の経済的負担を軽減する

従業員にとって報酬は重要であり、個人的なものですが、このような不透明な時代においてはなおさらです。将来の資金計画に関連するプレッシャーを軽減するため、退職金制度を充実させました。

米国では2022年に、従業員の401k退職金制度へのマッチング拠出を1%から2%に引き上げました。現在、PagerDutyは、従業員の在籍中、給与期間ごとに最大2%まで401kプランの拠出金と同額を拠出することになっています。カナダの従業員については、PagerDuty DPSPへの会社からのマッチング拠出を増やしたことをお知らせします。2022年1月1日より、RRSPに拠出された適格利益1ドルにつき、PagerDutyはDPSPに1ドル、最大2%まで拠出します。

さらに、一部のプランでは、米国における免責金額と医療費自己負担額の上限を引き下げました。PPO(Preferred Provider Organization)プランでは、プランや階層に応じて自己負担額の上限が500ドルから1,000ドルの間で引き下げられました。HDHP(High Deductible Health Plan)の控除額は、プランの階層によって300ドルから600ドルの間で減少し、雇用主のHSA(Health Savings Account)拠出は月々最大225ドルとなっています。

PagerDutyは社員を大切にします

私たちは、社員が日々、当社の製品とサービスを向上させるために貢献していることに感謝しています。私たち全員が前進し、新たな課題が発生したときでも、従業員の声に耳を傾け、世界レベルの従業員体験を提供するために努力を続けていきます。

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

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

非インテリジェントなスウォームをコントロールしてインシデント対応を改善しよう

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

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

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

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

どのサービスが影響を受けるか どのサービスにどの程度の影響があるか そのサービスのオーナーは誰か

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

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

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

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

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

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

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

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

スウォームからの移行

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

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

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

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

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

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

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

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

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

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

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

最良の計画は、全てのステークホルダーに定期的に情報を提供することを前提にしています。早めに、そして頻繁にコミュニケーションすることで、状況が改善され、問題が解決されたときに、全員に知らせることができます。

NOCで群れる必要はない

第一線のレスポンダーが総合的な担当をするNOCチームである場合、最新のインシデント対応モデルに移行できます。サービスオーナーシップを明確にしていれば、NOCがインシデントを解決できない場合、複雑な問題をサービスチームにエスカレーションできます。サービスAを担当するチームのオンコール中のレスポンダーを呼び出すことは、組織全体からさまざまな人を集めるよりもはるかに簡単です。

まとめ

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

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

この記事は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年以降に成功を収めることができるのです。

ここで必要なのは、健全な実用性です。賢明なエンジニアリングリーダーは、「ベンダーロックイン」の心配に負けることなく、そこで利用可能な機能に基づいて、自分たちのコードに適したインフラ環境を選択することになるでしょう。このようにして、企業は社内で利用できる限られたスキルを最大限に活用し、クラウドプロバイダー間で複数の同一環境を複製するために貴重なエンジニアリング時間を費やすことなく、イノベーションに専念できるようになるのです。 3. 複雑さを極限まで減らす より革新的な顧客体験への要求は高まる一方です。しかし、その反面、複雑さが増大し続けることはありえません。現代の企業は既に何百万もの依存関係を持つ何千ものデジタルサービスを動かしており、マイクロサービス、コンテナ、サーバーレスアーキテクチャー、オーケストレーションプラットフォームが網の目のように張り巡らされています。

システムの複雑さには「ダンバー数」というものがあり、私たちはそれに急速に近づいています。いくつかのアプローチに対する反発の最初の兆候が現れています。例えば、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日  (更新日:2023年2月23日)    |    インシデント&アラート

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

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月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年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週間のオンコールは燃え尽き症候群につながる可能性がある

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

2021年8月23日  (更新日:2022年3月8日)    |    DevOps

DevOpsのROIを測定する方法

DevOpsは、ソフトウェアの提供とインフラストラクチャの変更のプロセスを自動化および加速しながら、ソフトウェア開発者とIT運用の専門家の間のコラボレーションとコミュニケーションを強調する文化、ムーブメント、実践手法です。 DevOpsプラクティスを実装するには、人、教育、ツール、組織の調整など、いくつかの種類の投資が必要です。しかし、これらの投資から組織が受け取るリターンを判断するのは難しい場合があります。効果測定では何を重視しますか? どうやって投資を価値あるものにしますか?

DevOpsがROIに与える影響

DevOpsのない世界では、ソフトウェアリリースの頻度は低く、以前のリリース以降に開発チームによって構築されたすべての新機能、更新、および変更が含まれています。ビルドされたが次のリリースまで出荷されないコードは、ビジネスには何の価値も生み出しません。コードのユーザーへの配信を加速するということは、ジャストインタイムの製造のようなものであり、完了後すぐに価値を生み出します。そして、今日の継続的なデジタルトランスフォーメーションの世界では、新しい機能をデプロイし、競合他社よりも早く問題を解決する能力が、市場での優位性につながるのです。 DevOpsの主な目標の1つは、ソフトウェアリリースを頻繁に、定期的に、自動化することです。1日に複数回リリースする能力がある場合、個々の本番環境へのプッシュはたいしたことではありません。リリース頻度の低い「ビッグバン」スタイルの体制、つまり全員が臨戦態勢で、土壇場でのトラブルシューティングに追われ、やり遂げるまで深夜も週末も作業する運用チームを必要とするような体制と比較してください。デプロイの失敗によるダウンタイムを解決するために髪を振り乱すのではなく、より幸せで休息の取れた運用チームが次の問題を積極的に解決することの方が、組織にとって明らかにはるかに大きな価値があります。

あなたのチームはあなたの最大の資産です

DevOpsを実装する最良の方法は、解決が必要な問題に権限と責任の両方を集中させることです。最前線のチームは、時間が無駄になっているところ、隠れた非効率性がどこにあるのか、どこに最適化の機会があるのかを知る最適な立場にあります。プロセスに自動化を導入することについての最大の誤解のひとつは、それが必然的にチームから仕事を奪うということです。むしろ、面倒な手作業を自動化に置き換えることで、チームはより価値の高い活動に集中できるようになるのです。 結局のところ、あなたのビジネスをあなたのチームよりよく知っている人たちはいません。人件費にどれだけ投資したかを考えてください。チームの生産性を最大化することは、DevOpsを実装することによるROIの大きな改善点です。重要な問題の解決に時間を費やしてもらうことで、ビジネス全体の成果の量と質が向上し、面倒なエラーが発生しやすいタスクがToDoリストから削除されるため、リスクが排除されます。

ROIをビジネスの目標に結び付ける

では、DevOpsプラクティスを採用するためのビジネスケースを検証するために、ROIの適切な指標をどう選択すればいいでしょうか? これはビジネスにとって大変重要なことです。デジタルトランスフォーメーションが広がるにつれ、新しいビジネスモデルと顧客との新しい対話方法が、あらゆる業界で生み出される価値を根本的に変えています。成功を測定するための鍵は、ユーザーに提供する独自の価値を理解し、それを達成するために指標を結び付けることです。顧客が目標を達成するために費やす時間を最小限に抑える、ユーザーあたりの収益を最大化するなど、DevOpsへの投資を主要なビジネス指標の改善に直接関連付けることができるはずです。

			時は金なり
			鍵は効率化
			柔軟に最適化を
		
	
	
		
			チームがより価値の高い問題に時間を費やすことができれば、あなたのビジネスにより多くの価値をもたらすでしょう。
			ボトルネックを防ぐために、問題に近い現場に権限と責任を持たせましょう。	
			どんなケースでも即通用するというものではありません。ビジネスにとって何が重要かを把握し、そのために最適化を図ってください。
		
	


そして忘れてはいけないのは、何かを測定できるからといって、そうする必要があるとは限らないということです。我々は時にビジネスの目標に関係ない指標に気を取られてしまいがちです。開発者の生産性を測定するためには非常に多くのツールが利用可能であるため、記述されたコードの行数や修正されたバグの数など、実際には重要ではないあらゆる種類のデータを追跡できます。計算や最適化は簡単かもしれませんが、ユーザーのために生み出そうとしている価値とは実際には関係のないことです。

「数えれられることすべてが大事なわけではないし、大事なことすべてが数えられるわけではない。」(ウィリアム・ブルース・キャメロン)

ビジネスへの教訓

DevOpsの変革とは、ITの流れを加速することを目的としたプロセスの変更がすべてです。つまり、ROIを測定する際の最大の課題は、DevOpsが提供するさまざまな種類のメリットを理解し、それらのメリットをビジネス目標に結び付けることができるかどうか、ということなのです。 配信されないソフトウェア在庫の山の削減から、手作業による障害リスクの削減、生産性と従業員の満足度の向上まで、DevOpsプラクティスを実装することの価値はすぐに得られます。今日のデジタル環境で競争力を維持しようとしている企業にとって、DevOpsに移行する余裕があるかどうかという問題は、「DevOpsに移行せず現状のままで安泰なのか?」という問いになってきています。

ROIの決定に使用できるDevOps指標

これらをあなたのビジネス目標に当てはめてください

			指標
			詳細とメリット
		
	
	
		
			1日/週/月あたりの本番環境へのプッシュ数
			本番環境への展開の頻度を増やすことで、ユーザーにビジネス価値を提供する速度を上げ、「倉庫の在庫」コードを減らすことができます。
		
		
			1か月/年あたりのダウンタイムの分数	
			自動化が進むと、アプリケーションのダウンタイムが削減されます。これは、ユーザーの満足度と収益に直接関係します
		
		
			自動テストカバレッジ	
			自動化を広範に使用すればするほど、手動エラーの可能性が少なくなり、移動が速くなります。
		
		
			新入社員がコードを本番環境にデプロイするのに必要な時間	
			新入社員が迅速に対応できるようにするためのフレームワークとプロセスを構築することで、新入社員の生産性が向上し、既存のチームの生産性も向上します。
		
		
			新しいイニシアチブと既存のプロセスの実行に費やされた従業員の時間	
			手動プロセスを自動化することで、チームは既存の問題に対処するのではなく、ボールを前進させることに時間を費やすことができます。
		
		
			従業員の幸せ	
			作業に忙殺されるのではなく貴重な問題に時間を費やしている幸せな労働者は、生産性が高く、長期間にわたって戦力となってくれます。これは、NPS(Net Promoter Score)を介して直接測定することも、トラブルシューティングに追われる夜と週末の数を介して間接的に測定することもできます。
		
	
2021年7月12日  (更新日:2022年3月10日)    |    ニュース&告知

PagerDuty Summit 2021の概要 Part 2

2021年6月に開催されたPagerDuty Summit 2021から、注目セッションのご紹介のパート2です。

パート2では2つのセッションを取り上げます。最初のセッション「The power of PagerDuty in alert noise suppression」(アラートノイズ抑制におけるPagerDutyの力)は、Hudson’s Bay Company社のPlatform Visibility and Command Center Monitoring部門のディレクターであるMarcelo LaRosa氏が登壇しました。このセッションで彼は、測定対象を管理することで生産性と従業員の満足度がどう向上したかを共有しました。 ノイズ抑制に関しては日本の皆さんも興味のあるところだと思います。

さらにご紹介する2番目のセッションは「How PagerDuty & Rundeck Drives Operation Maturity」(PagerDuty&Rundeckが運用の成熟度を高める方法)です。こちらはTrimbleのCloud Engineering and Infrastructure部門のディレクターであるAndrea Valenti氏と、TrimbleのシニアリードDevOpsエンジニアであるAli Soheili氏の講演です。

The power of PagerDuty in alert noise suppression: (アラートノイズ抑制におけるPagerDutyの力)

Hudson’s Bay Company社のMarcelo LaRosa氏 ©PagerDuty

「The power of PagerDuty in alert noise suppression」(アラートノイズ抑制におけるPagerDutyの力)の講演は、Hudson’s Bay Company社のPlatform Visibility and Command Center Monitoring部門ののディレクターであるMarcelo LaRosa氏によって行われました。

最初にLaRosa氏は、「誰もノイズなんか聞きたくない、特にモニタリングでは」と述べました。 彼は、受信する必要のないアラートを処理するためにアクションを実行する必要があり、アクション可能なアラートのみを受け取るようにする必要があると述べました。

最初に行う必要があるのは、PagerDutyでデータを収集することです。分析内で、レポートを選択し、月次データを取得する必要があります。彼は、「少なくとも1年分のデータを取得し、通常の月よりもアラートが多い可能性がある場所を確認すること」を提案しました。次に、その月次データを取得したら、特定のサービスごとに月次統計を分析する必要があります。彼は、高い頻度でアラートを出す上位3つのサービスを確認し、各サービスのCSVレポートをプルダウンして、ピボットテーブルビューを作成することを強く勧めました。

アラートノイズの問題を改善するための手順 ©PagerDuty

そのデータを入手した後に、彼はトップ3のアラートサービスのオーナーとの個別の会議を設定すべきだと強調しました。「サービスオーナーの知識に応じて、アラートをP1 / P2またはP3などとして優先し、警告を設定し、アラートをグループ化するなど、分類法を改善する必要があります」。そして彼が最後に提案したのは「メンテナンス」です。 彼は、改善のための、PagerDutyを使った反復的なモニタリングを確立することを提案しました。彼のチームでは、毎日、毎週、毎月のリズムを確立し、定期的にアラートをチェックしています。そして、ある時点で何かがトップ10に入っているのを見ると、すぐにそのデータの再分析を開始します。

最後に、彼は「継続的改善はまさにそれ自体、継続的に改善すべきである」と私たちに思い出させました。 彼は、こうした説明したプロセスを継続することを強く推奨しました。 「最初の数カ月は大変かもしれませんが、大量のアラートと戦ったあとは簡単になります。こうしたたくさんのレポートを取得する方法はおそらく自動化できます。 自然と会議ができるようになり、意見が出てきます。 その意見が広まり、人々が私たちを求め始めると、何か大きなことをやったんだと感じるようになります」。

How PagerDuty & Rundeck drives operational maturity: (PagerDuty&Rundeckで運用の習熟度を上げる)

このセッションでは、建設をはじめ複数の業種にサービス提供している国際企業で、大規模なDXを遂げているTrimble社のシニアリードDevOpsエンジニアであるAli Soheili氏と、同社のクラウドエンジニアリングおよびインフラストラクチャのディレクターであるAndrea Valenti氏が講演しました。彼らのプラットフォーム 「Trimble Project and Program Management」(Trimble PPM。同社の「Connected constructions Portfolio」の一部)は、PagerDutyとRundeckを使いインシデント対応プロセスを自動化しています。彼らがどうやってインシデント解決までの時間を短縮し、エスカレーションを削減したかを学ぶことができます。

まず、Andrea Valenti氏は同社の重要な目標のひとつとして、CEOのRob Painterの言葉を引用し「私たちがサービスを提供する業界のライフサイクルをつなぐこと」と述べました。PPMは、そのTrimbleにおけるSREの変革の最前線です。彼はPagerDutyとRundeckの導入の経緯を説明しました。特定の部門内だけでなくTrimble全体で、PagerDutyとRundeckの両方を長い間使用してきた経験があります。

TrimbleでのPagerDutyとRundeckの導入と自動化の歴史 ©PagerDuty

また、特に同社の「e-Builder」SaaSアプリケーション群で、すでに数年間PagerDutyを使用していると述べました。Rundeckについてはヨーロッパグループの輸送部門で最初のプロジェクトを開始したときかに使い始めたそうです。PPMでは、エンタープライズレベルでのセキュリティと統合を進めることが彼らにとって最重要なポイントであるため、彼らはさらに2つの製品を活用することを決めました。

Trimbleは、2018年以降、複数のアプリケーションの統合ポートフォリオの運用を開始しました©PagerDuty

2018年からは複数のアプリケーション、e-Builder、ProjectSight、Prolog、Prolianceの統合ポートフォリオの運用を開始しました。その運用は、全グループが独自の方法、独自のツール、独自の解釈とアイデンティティを持っているため、非常に困難でした。そこでSREグループはまず複数のグループでプロビジョニングとデプロイメントについて一貫性のある命名法を決めました。これはまだ継続中ですが、ほぼ確立しています。同時にインシデント管理についても命名法を決めました。以前はイベントがなぜ起きたかをチームごとに別々の見方で調べていました。そのためインシデントの状況を特定すること困難でした。そこで彼らは、イベント管理や各グループがもたらす多様性を消してしまうのではなく、決断をするようになりました。インシデントの概念にフォーカスして、全イベントをPagerDutyに集約することを決めたそうです。

次に、Ali Soheili氏は、SREチームを単一のクラウドチームに変えるべき3つの理由を共有しました。

Rundeckを使いビジネスオペレーションを自動化したことで得られた効果 ©PagerDuty

次に、インシデント管理がどう設定されているかを説明しました。同社ではNew Relicをはじめ複数の監視ソリューションがさまざまな部門で使われていました。Rundeckの利用目的の1つはそのオペレーションの自動化でした。彼らはそれらをセルフサービスとしてRundeckで自動化しました。結果として複数のチームがこれらのセルフサービスジョブを利用できるようになり、時間を大幅に節約できます。例えばあるケースでは、開発チームのオペレーションには5日間のサイクルタイムがありましたが、数分に短縮されました。コスト削減も大事な目的であり、このセルフサービスを使用するメリットの1つです。

次の図はPagerDutyとRundeckを使用して実行した自己修復の例です。

PagerDutyとRundeckを使用して実行した自己修復の2つの例 ©PagerDuty

最後に、Andrea Valenti氏は、RundeckとPagerDutyの利用について学んだことを共有しました。

自動的に修復をする実用的なフレームワークを用意してください。小さくて簡単なものでも、インシデントの優先順位付けで最上位に当たるP1をダウングレードする際に再利用できます。 SME(Subject Matter Experts)のセカンドラインが待機していることを確認してください。 PagerDutyを使用すると、複数の監視ツールからの情報を集約でき、インスタンスを表示する方法を1つに絞ることができます。

すべての画像の著作権はPagerDutyにあります。

PagerDuty Summit 2021のサイトでは詳しい資料と動画を公開していますので、こちらをご覧ください。

2021年7月2日  (更新日:2022年3月10日)    |    ニュース&告知

PagerDuty Summit 2021の概要 Part1

2021年6月に開催されたPagerDuty Summit 2021から、注目セッションの様子をご紹介します。 パート1では、CEOのJennifer Tejadaによる基調講演「DigitalOps Now」と、データサイエンスのシニアディレクターであるMitra Goswamiのセッション「The Power of AIOps」の要約を掲載します。

PagerDuty Summit 2021 基調講演: DigitalOps Now by Jennifer Tejada , CEO of PagerDuty

PagerDutyのCEOであるJennifer Tejadaが、近年のAIOpsのニーズの増大とそれにPagerDutyがどう対応するかを解説 ©PagerDuty

最初の講演「DigitalOps Now」でJenniferは、大手企業がデジタルアクセラレーション、DevOpsトランスフォーメーション、クラウド移行への投資を増やし続けており、75パーセント以上が今後1年半の間にAIOpsに投資すると予想されていると述べました。

ここでゲストとして招待されたNetflixのDelivery Engineering担当ディレクターであるAmy Smidutz氏は自分のチームとNetflixがプラットフォームの信頼性を確保するためにPagerDutyにどう頼ってきたかを共有しました。PagerDutyの機能によりチームとサービスを結びつけることで、インシデントが起きた時に反応するのではなく、予測して計画を立てることができます。

PagerDutyの新しい製品「Service Graph」ではビジネスと技術サービスを担う組織を一望できる ©PagerDuty

続いてJenniferはPagerDutyの新製品である「Service Graph」を紹介しました。これは、フルサービスのオーナーシップを強化するための、ビジネスと技術サービスの関係の全体的なマップです。最も意味のある、または問題のある組織の領域をセグメント化し、これらのプロセスを推進するデータソースを直接リンクして、ビジネスサービスと技術サービスの間に新しい接続を作成します。Jenniferはもう一つ、無駄な時間とエスカレーションを減らし、人の介入を必要とせずに対応を自動化する「Runbook Action」を発表しました。

ここでゲストとして招待されたZoom、Box、Tenable、UiPathの投資家兼取締役でゴールドマン・サックス・グループのKim Hammonds氏は、デジタルトランスフォーメーションがどこまで進んだか、そしてまだどこまで行かなければならないかについて、彼女の考えを共有しました。デジタルトランスフォーメーションを主導するための種を撒くには、第1に稼働時間、可用性、回復力、災害復旧などのすべてが機能する必要があります。そして2番目に重要なのは、世界中の誰もがサイバーセキュリティの脅威に対処しているためのサイバーセキュリティです。3つ目はカスタマーエクスペリエンスです。そして4つ目は何が起こっているかをデータから理解し、データを使って顧客により良いサービスを提供する方法を理解することです。

ゴールドマン・サックス・グループの会長兼CEOであるDavid M. Solomon氏が登壇 ©PagerDuty

ここでさらにスペシャルゲストとして、ゴールドマン・サックス・グループの会長兼CEOであるDavid M. Solomon氏が登壇しました。彼は「PagerDutyのようなツールを使うことで、エンジニアがトラブルシュートに備えて定期的につながっている状況を確実に担保できる」と述べました。彼は、ゴールドマン・サックス・グループが個人を対象にしたビジネスを拡大しているとも述べ、その理由は、「デジタルの世界は個人が白紙の状態で参加することを可能にし、さらに経済的生活を統合するためのツールを提供するからだ」とのことです。彼は、現在定着している消費者金融サービスの世界で巨大なデジタルによる破壊が起きると信じています。彼はまた、消費者がやりたいことは摩擦の少ないデジタルアプリケーションによって、はるかにシームレスな方法で経済的生活を管理することだ、と考えています。

PagerDuty自身のチーフプロダクトオフィサーであるSean Scottが、最新のデジタルオペレーションについて紹介 ©PagerDuty

続いて、PagerDutyのチーフプロダクトオフィサーであるSean Scottが登壇し、組織内で発生する重要で喫緊の作業に現代のデジタルオペレーションが対処している状況を紹介しました。彼は、2019年から2021年の間に重大インシデントが21%増加したことが分かったと述べました。各インシデントの解決には、平均2時間かかり、組織の管理には年間15万ドル以上の費用がかかりました。また、昨年はレスポンダーが以前より不規則に働くことが増え、3分の1以上が24時間体制で問題に対処するために1日2時間余分に働いていることも分かりました。従業員は過労になると仕事を辞める可能性が高くなります。そこで、対策が必要です。

この点での最大のニュースが昨年9月のPagerDutyによるRundeck買収でした。お客様からのフィードバックによると、彼らは労力を減らし、エスカレーションを減らし、運用全体の保守とサポートを民主化する必要がありました。そのため、PagerDutyはそのニーズに投資したのです。RundeckチームとPagerDutyによる自動化が統合されたことで、インシデント解決時間の短縮と開発者の作業の中断を減らせます。お客様の一部はすでにこの価値を理解していると思います。

PagerDutyがRundeckのテクノロジーをマージすることで実現しつつある主なイノベーション ©PagerDuty

6カ月後、彼らのチームは、PagerDutyプラットフォームにこのテクノロジーを統合したことで大きなイノベーションを提供し続けました。

Sean Scottは、Salesforce ServiceCloud用の新しいPagerDutyアプリケーションを提供するSalesforceとの戦略的パートナーシップも発表しました。この新しいパートナーシップにより、最前線のカスタマーサービスエージェントと主要な内部の利害関係者に、Salesforce Service Cloud内で直接に強力なPagerDutyエクスペリエンスを提供します。この機能は、昨年、プロフェッショナルレベルのカスタマーサービスプランナーに新しい価値を追加し、新しいビジネスレベルのカスタマーサービスプランにも統合されます。これは、サポートエンジニアのデスク統合と監視統合に役立つものです。

彼はさらに架空の大手小売業者のビジネスを想定し、PagerDutyの新機能をデモしました。

最後に彼は「PagerDutyはあなたをデジタルの勝者にするパートナーであり、私たちは一緒に完璧な顧客体験を提供することができます」と述べてセッションを結びました。

PagerDuty Summit 2021 基調講演: Power of AIOps

PagerDutyのデータサイエンスのシニアディレクターであるMitra GoswamiがAIOpsの威力について解説 ©PagerDuty

注目のセッション「The Power of AIOps」では、PagerDutyのデータサイエンスのシニアディレクターであるMitra Goswamiが、AIOpsの威力について、その理由と、この分野で最も大きな影響を与える可能性のあるAIの使用例について説明しました。

「AIOpsという言葉は2016年にGartnerが作り出したもので、「ビッグデータと機械学習を組み合わせて、イベント相関、異常検出、因果関係の判断など、IT運用プロセスを自動化するもの」です。この定義は組織によって異なります。Gartner自身は数年後に『AIOpsなしではIT運用の未来はない』と主張しました」。

彼女は次に、PagerDutyがAIOpsをどう強化するかを説明しました。

「この旅を始めたとき、当社はお客様と話し合い、AIOpsの3つの問題点を共有しました。お客様は『まず大事なことはセットアップと開発の容易さだ』と言いました。この点は、PagerDutyは実装が非常に簡単で、すぐに使えます。2番目に大きな問題点は『原因をすばやく発見すること』です。この点についてPagerDutyは新たに3つのソリューションを採用しました。3つ目の問題は、お客様がAIと機械学習のソリューションの信頼度を高めてほしいと考えていることです。(AIという)ブラックボックスで重要な決定を下すことになるので信頼性が高いことを求めています」。

彼女はまた、開発者にとっての3つの問題と、AIOpsソリューションを必要とする理由を共有しました。「最初の問題点は『アラートが殺到すること』です。インシデントが発生すると、開発者は数百または場合によっては数千のアラートを受け取ります。そのため、関連性のある有用な情報を確認することは非常に困難です。2番目は開発者から見て『高レベルの重要なコンテキストが不足している』ことです。十分な時間があるかどうか分からず、狭い部分しか見られない場合、それらはいくつかの重要なコンテキストへの配慮を欠くかもしれません。 3番目は、インシデントを以前の変更に関連付けることができないことです。インシデントの80%が変更イベントによって引き起こされており、現在のすべての情報が右側の同じ場所にないため、インシデントが発生しているときにアクティブな変更と履歴の変更をそれらのインシデントに関連付けることは非常に難しいのです。以上の課題を解決してできるだけ短期間に素因を見つけられるようにするために、AIOpsソリューションが必要です。」

彼女はここでPagerDuty式の「素因分析(RCA)」を共有しました。これは、「勧告、修復、最適化」という3つのアプローチに基づいています。彼女は、「素因の勧告」はこの旅の非常に重要なステップであると述べました。そして目標は、開発者が素因に対処し、できるだけ早くイノベーションに戻ることができるようにすることです。

より高速な素因分析(RCA)により、MTTRが大幅に削減されます ©PagerDuty

彼女は次のように述べています。「効果的な素因分析(RCA)は、開発者の日常生活に直接的な影響を及ぼします。より高速な素因分析により、解決までの時間(MTTR)が短縮され、重大なインシデント解決プロセスの中で起きてほしくない燃え尽き症候群やストレスも回避されます」。

彼女はまた、「RCAをするための3つの方法」についても説明しました。「1つ目はノイズの低減です。PagerDutyのソリューションは、同様のアラートを集約し、関連するインシデントをマージすることに基づいています。そのため、開発者は、何千ものシステムがアラートを開始したときにも波に呑まれることなく、重要で関連性のあることに集中できます。2つ目は、インシデントの分類です。3つ目は変更イベントとインシデントの相関度を示すことです。レスポンダーは潜在的な要因を特定し、無関係な変更を排除できます」。

彼女はまた、Event Intelligenceパッケージとそのデジタル運用計画で利用できる「Intelligent Alert Grouping」機能を紹介しました。チームがシステムの複雑さの増大に合わせて増員できない場合、アラートによる疲労が士気を落とし、何が実行可能かを特定するのを困難にする、という問題に言及しました。この問題を解決するために、PagerDutyのアルゴリズムは、インバウンドのシグナルのパターンとレスポンダーの動作の両方から、アラートをグループ化する方法を学習します。

Incident Alert Groupingは、関連するアラートを単一のインシデントに自動的にグループ化できます ©PagerDuty

彼女が次に言及したのは、新機能の「Incident Outliers」です。これは、レスポンダーが対応に集中している間は、過去の同様のインシデントの経験に関するコンテキストの情報を得る機会が不足することです。解決策は、インシデントをRare、Novel、またはFrequentに自動分類する最適化されたモデルを用意することです。

Incident Outlierは、各インシデントをrare、novel、またはfrequentに分類できる機能です ©PagerDuty

3番目の新機能は、「Change Events & Correlation」です。このソリューションは、お客様の履歴データとアクティブな変更を確認する、最適化されたモデルを提供します。お客様は過去の変更に関するウィンドウを移動することができ、変更をインシデントに関連付けられるようになります。

「Change Events & Correlation」は、お客様がインシデントの原因となる可能性のある変更を特定するのに役立つ機能です ©PagerDuty

最後に、Mitraは、PagerDutyがAIOpsをどう改善しようとしているのかについて言及しました。「PagerDutyの巨大な分析プラットフォームの強みを活用しており、そのアルゴリズムはお客様との信頼関係を構築するために、誤報の50〜60%を即座に削減しています。また、新しい機械学習機能を開発し、お客様と対話できるようにするハイブリッドな方法を導入しています。そうした施策により、多くの力をお客様に還元し、AIOpsソリューションの信頼度を向上させています」。

すべての画像の著作権はPagerDutyにあります。

PagerDuty Summit 2021のサイトでは詳しい資料と動画を公開していますので、こちらをご覧ください。

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

DevOpsを高速化するための6つのステップ

多くの組織がDevOpsの導入を検討しているのは、リリース速度の向上、開発速度の向上、開発者がイノベーションに集中できる時間を確保できることなどが期待されているからです。しかし、DevOpsの採用は万能薬ではありません。その代わり、DevOpsモデルが奨励するコミュニケーション、コラボレーション、批判しない前提での振り返りの考え方は、問題を解決するだけでなく、プロセスを改善してボトルネックを解決し、より無駄のないシステムを構築するのに役立ちます。

DevOpsを実装する組織にとって最大の課題の1つは、ワークフロー内の既存の問題を特定して削除し、より新しく、よりアジャイルな方法論に道を開くことです。ガートナー社は、システムが目標達成に近づくのを妨げる不便さ、挫折、その他の制限要因を意味する制約を取り除き、真の意味でDevOpsの速度を向上させるために組織が取ることができる6つのステップを以下にまとめました。

ステップ1:プロセスを定義する

プロセスを再構築する際には、DevOpsチームは、初期の構想から最終的な顧客価値に至るまでのワークフローをデザインし、プロセスを定義する必要があります。既存のプロセス内のすべてのステップを文書化することにより、プロセス全体に積極的に貢献していない可能性のある制約領域をより簡単に見つけ出し、改善できます。さらに、サイクルタイム、おおよその時間間隔、ハンドオフ、待機状態など、より価値の高い流れを明確に把握できます。これがすべて整理されたら、チームは最大のプロセス制約を簡単に特定し、プロセス全体を改善するための手順を開始し、プロセス文書化の効果を高めることができます。

ステップ2:最大の制約を特定する

典型的なDevOpsのワークフローでは、アイデアから価値へのプロセスを遅らせる段階が常に存在します。体系的な改善を推進するために、チームは進行を妨げている特定のフェーズを特定し、制約の原因を取り除く必要があります。

最大の制約を特定するには、「誰もが常に何を待っているのか」を問います。これを尋ねることで、チームは効率を高めるために特別な注意が必要なことを特定できます。責任追求をしない建設的な環境でこれを行うと、チームメンバーは発言しやすくなります。最大の制約を特定したら、プロジェクトの進行状況を監視して、ブロック要因が正しく特定されていることを確認します。

ステップ3:制約条件下での無駄を取り除く

制約が特定された場合、最も一般的な行動方針は、より多くのリソース(人、お金、新しいシステムなど)を投入することです。ただし、役に立たない可能性があるリソースを追加するのではなく、無駄な可能性のあるリソースを排除することがより効果的です。

ガートナーによると、クライアントが特定した上位3つの無駄の発生源は次のとおりです。

インシデント:** 新しい製品や機能の開発などの付加価値活動を犠牲にして、インシデント管理に貴重な時間が費やされています。このためのベストプラクティスは、チームメンバーを相互訓練してインシデント管理に習熟することです。将来のインシデントを防止する1つの方法は、責任追求をしない事後検証を実施して、インシデントの根本原因を解明し、将来それを防止することです。 待機:** 人、外部組織、その他のリソースを待つことは、常に課題です。これは、多様なスキルと知識を備えた従業員をトレーニングや雇用して、並行して作業できるようにすることで軽減できます。これにより、他の人の対応を待っている間に、プロジェクトの目標や他の割り当てられた仕事を達成することができるようになります。 人のポテンシャル:** データベースの更新であれ、インシデントのエスカレーションであれ、多くのIT専門家は多くの時間をかけて手動で作業しています。組織はできる限り自動化することでより多くの価値を実現し、人々はより価値の高いタスクに集中できるようになります。

ステップ4:制約を無視しない

制約を無視して新たに発生した問題に集中すると、元の問題に対処できなかったため、作業が遅くなり、将来さらに問題が発生します。たとえば、鎖について考えてみましょう。鎖の中の最も弱い環が強化されていない場合、鎖はある時点でその場所で切れてしまいます。

制約を無視することで、チームは次のようなさまざまな課題を経験することになります。

ミスや欠陥の増加 チームの効率と生産性への悪影響 変化率の高い状況での費用のかかるやり直し

ステップ5:容量を追加する

上記の手順は、スループットを少なくとも30%向上させるのに役立ち、問題を評価する能力と時間を利害関係者に与えるので、迅速な解決策を選択するのではなく、最善の解決策を慎重に検討できます。チームは専門サービスの契約であろうと追加のスタッフの採用であろうと、キャパシティを増やすことができる他の方法を見つけるためにこの時間を取るべきです。

ステップ6:次の最大の制約を見つける

リリース速度を向上させることは簡単なことではなく、プロセスを継続的に改善する必要があります。例えば、あるチームが制約を取り除くことに成功したとしても、ワークフローの別の部分で別の制約が取って代わることがあります。時間が経つにつれて、チームは高い開発スピードを達成するために、プロセスとプラクティスを適応させる必要があります。最後に、顧客のニーズを確実に満たすためには、開発サイクルのデューデリジェンスを実施し、必要に応じて改善する必要があります。

ガートナーの完全なレポートをお読みになりたい方は、「制約を削除してDevOpsのリリース速度を向上させる6つのステップ」をご覧ください。

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

2020年9月16日  (更新日:2022年3月10日)    |    DevOps

DevOpsトランスフォーメーションに血を通わせる

チェスをしたことがある人なら誰でも、望む結果に到達する方法が1つではないことを知っています。1手目の後には400の違った指し手があり、2手目の後には19万7742の、3手目の後には1億2000万の可能性があり、これらはすべて望む同じな結果に向かって進んでいます。

「これがDevOpsと何の関係があるの?」。真っ当な質問です。チェスの試合にアプローチする方法が1つではないのと同じように、DevOpsの変革に取り組む方法も1つではありません。

では、どのようにしてビジネス、既存のプロセス、従業員に大きな影響を与えることなく、より速いデプロイメント、安定性の向上、コラボレーションの向上を約束する変革を行うのでしょうか?

PagerDutyでこれに成功した企業は、5つの重要な戦術に従っていることがわかりました。

避けられない変化を認識する

今日の企業は、顧客の期待の高まりに応えるためにデジタルサービスを変革していかなければなりません。変化はしばしば不快なものであり、多くの組織は変革の取り組みに関してチームからの反発を経験し、場合によってはメンバーの離職を経験することもあります。多くの場合、DevOpsの「自分で構築して自分がオーナーになる」というモットーは、現実には一歩踏み込みすぎていることがあります。

しかし、それでいいのです。私たちは、多くの組織で抵抗や従業員の離職が起こるのを見てきました。しかし、このシナリオでは、短期的な苦痛は長期的な利益に値します。

あなたと一緒に変革の旅に出たいと思っている人には、この変革を視覚化するのを手伝ってあげてください。既存のプロセスを解体して置き換えるのではなく、小規模なプロジェクトから始めることで、新しいアイデアをテストし、リスクを評価し、すぐに成果を得て、将来の「新しい標準」の感覚を得ることができます。目標は、オンコールを変化の障壁にするのではなく、学び、成長する機会にするために、考え方を変えることです。成功の種を蒔き、早期に小さな成功を得ることで、たとえ変化が避けられないとしても、少なくともそれがより身近なものになるようにしましょう。

DevOpsはゼロサムゲームではありません。加算的です。その意図は、チームのアウトプットとスキルの質を継続的に向上させることです。

ビジョンへの賛同を得る

トップの賛同なしでは、開発者チームがより多くのオーナーシップを持つようになれないということを強調することが重要です。経営陣と開発チームの両方が、将来の状態と潜在的な利益について相互に理解していることが重要です。

小さく始めて、隠れたところでいくつかの勝利を得ることは、2つの目的に役立ちます。

アジャイルアプローチが達成可能であり、開発者とOpsチームにとっても同様にうまく機能していることを示します。周囲の期待を得ると、この成功を紹介して新しいプロセスを実現する開発者のサポートを得られるため、経営陣へのアピールが容易になります。 この成功の成果が、開発側が得たデプロイ頻度の向上やコード品質の向上なのか、運用側が得た重大インシデントの減少やインフラの回復力の向上なのかに関わらず、それが経営陣の賛同を得るための要素であり、目に見えるものであることが重要です。結果を定量化することで、組織が新しいプロセスを完全に実装した場合に、経営陣はこれらの新しいプロセスがもたらすプラスの影響をよりよく理解することができます。

開発チームの賛同を得ることは、乗り越えなければならない大きな障害のように思えるかもしれませんが、最終的には彼らのサポートが最も貴重な資産となります。ビジョンに取り組むことで、役割と責任を調整し、DevOps への全体的なアプローチを作成することができます。

インセンティブの変化を理解する

PagerDutyを使用することで開発文化がシフトし、より多くの説明責任を果たすことができるということを、私たちは顧客からよく聞かされます。では、これは正確には何を意味しているのでしょうか?

従来のOpsモデルでは、開発者とOpsチームのインセンティブは一般的にずれています。開発者は迅速なコード出荷を望んでいますが、コードが本番になってからの信頼性の可視性は低くなっています。一方、Opsチームは、たとえ出荷が遅くなったとしても、信頼性と完璧に動くコードを望んでいます。

DevOps のアプローチでは、インセンティブが変わります。開発者は出荷するコードのオーナーなので、夜中に本番環境で起きた問題で起こされるのを避けるために、品質に焦点を当てようとする意欲が高まります。多くの開発者は、このような理由からオンコールを恐れています。しかし、私たちが発見したのは、アジャイル DevOps アーキテクチャではコードの品質が大幅に改善されているため、実際に電話が掛かってくることは予想よりもずっと少ないということです。

オンコールであることは、オーナーシップを促進し、インセンティブを調整する戦術であり、リアルタイムの学習を促し、品質の向上とより迅速なイノベーションを促進します。

DevOpsを自分のものにする

チームがDevOpsトランスフォーメーションをナビゲートするのに役立つ情報は、そこら中に豊富にあります。しかし、最終的には、DevOpsの実装方法はチームや組織に固有のものであり、ツールやプロセスだけでは実現できません。

DevOpsの原則は単なるフレームワークですが、そのフレームワークをどのようにチームに適合させるかによって、DevOpsは組織独自のものとなります。チームを変革プロセスに参加させ続けることが、最終的な成功への最も重要なステップです。例えば、新しいプロセスについてチームからのフィードバックを収集し、組織全体からの提案や新しいアイデアを求めてフォーラムを開いておくことは、チームの一体感を構築し、チームが新しい変化を積極的に受け入れようとするモチベーションを高めるのに役立ちます。

このようにして、より多くの成功を収めることで、より多くの支持と採用を得ることができ、文化的な変化は有機的に起こるようになります。多くの先行投資が必要ですが、早い段階での投資は、将来的に配当金として戻ってきます。

指標を理解する

DevOpsの利点について説得力のある議論をするには、証明が必要です。既存のプロセスを測定して定量化し、以下のような質問をして、比較のためのベースラインを作成することを確認してください。

新しいコードを本番環境にデプロイするのにどのくらいの時間がかかるか? デプロイの頻度は? バグのトラブルシューティングにはどのくらいの時間がかかるか? 四半期ごとのダウンタイムはどのくらいか?

これらは単なる測定基準のサンプルであり、あなたの組織で測定するものは全く異なる可能性があります。重要なのは、DevOps モデルの「後」の状態のパフォーマンスを評価できるように、「前」の状態の指標を十分に把握しておくことです。

理想的には、DevOpsアプローチにより指標がより良い結果を示すことが望ましいです。例えば、アップタイムの向上やデプロイ頻度の向上などです。通常、問題を確認する平均時間(MTTA)と解決する平均時間(MTTR)に注目しますが、重要な指標はこれだけではありません。

これらの測定基準を取得することで、改善すべき領域をより明確に把握することができます。経営の第一人者であるピーター・ドラッカーがかつて言ったように、「測定できないものを改善することはできない」のです。 DevOpsには幅広い解釈があり、あなたの組織にとって意味するものは、別の組織にとっては全く異なる意味を持つことがあります。DevOpsへの移行は、リスク、忍耐、コミットメントを伴う重大な変化であり、それが早すぎたり、組織全体の賛同を得ずに行われた場合には、不安な気持ちになることもあります。しかし、思慮深いアプローチでは、開発者がオンコールしている状態でDevOpsの世界に移行する際に生じる懸念や成長の痛みの多くを軽減することができます。

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

アジャイルとスクラムに関する問題

「アジャイル」はソフトウェア開発でよく使われるバズワードで、一部の組織やチームはアジャイルを装っていますが、実際には全く違うことをしています。私はアジャイルコーチとしてのキャリアの中でそれを何度も見てきました。あるリーダーは、アジャイルの価値観を受け入れていると主張していましたが、エンジニアリングチームを細かくマネジメントし、開発者を操って長時間労働させるための方法としてアジャイルを利用していました。その結果、私たちの業界のエンジニアの中には、アジャイルソフトウェア開発を嫌っている人がいます。それは、エンジニアリング以外の人が彼らを操り、ソフトウェア開発をゲーム化するためにアジャイルソフトウェア開発を利用していると感じているからです。

この記事では、エンジニアがアジャイルやスクラムで経験する3つの「問題点」をお話しします。そして、悪質なアクターや誤解が蔓延している「アジャイルのBS」を切り取って、なぜこれらが全く問題ではないのか、その理由をお話しします。

始める前に、「アジャイルBS」を定義しましょう。

アジャイルBS:アジャイルの原則と価値観に沿っていないチーム、プロジェクト、または組織を指すときに「アジャイル」という用語を使うこと。例えば、アジャイルを装ったウォーターフォールや、実際には機能不全のプロセスを「アジャイル」という言葉で呼ぶこと。

この定義を念頭に置くために、チームまたは組織がアジャイルでないことを示す「アジャイルBS」フラグの例をいくつか示します。

エンジニアリングチームのメンバーがソフトウェアのユーザーと話したり、観察したりしていない

ユーザーからエンジニアリングチームへの継続的なフィードバックが行われていない

実用最小限の製品をできるだけ早く出荷して早期のフィードバックを得るよりも、完全なプロジェクト要件を満たすことを優先する

「アジャイルBS」の詳細については、国防総省のアジャイルBS検出ガイドをご覧ください。アジャイルの原則と価値観は、人々がアジャイルについて時々表現する問題、特にこの記事で指摘されている問題を解決するために作成されたのです。

問題1:アジャイルは、マネージャーが悪意を持って使用するための多数のプロセスとツールを提供するが、エンジニアが前向きの影響力を発揮するためのものはほとんどない

マネージャーがデイリースタンドアップを使用してチームメンバーを細かく管理できるのは事実です。また、マネージャーはスクラムチームのスプリントへの取り組みを「保証」と混同し、エンジニアにスプリントの目標を達成するために長時間労働を強要することがあります(問題2を参照)。しかし、これらはアジャイルソフトウェア開発の問題ではなく、マネージメントの問題です。そして、アジャイルソフトウェア開発では悪いマネージメントを克服することはできません。これは、アジャイルの原則と価値観が達成しようとしていることに対して、間違った期待をかけていることになります。

それでは、組織が適切な管理を実施しているとしましょう。どうすればアジャイルを受け入れることができるでしょうか。組織は、あらゆるレベルでアジャイルの原則と価値観を実践する必要があります。これには、リーダーシップによるアジリティへの取り組みが必要であり、アジャイルコーチのサポートを受けながらアジャイル変革の取り組みを通じて達成できます。PagerDutyの場合は、組織の効率を継続的に改善し、チームの可能性を最大限に引き出すシステム、プロセス、文化を構築、拡張するための専用のアジャイルリーダーシップチームがあります。

この「問題」と密接に結びついているのが、アジャイルはプロセスやツールよりも個人や相互作用を大切にしているということです。それは実際には何を意味するのでしょうか。

プロセスよりも人を大切にする。ソフトウェア開発を管理するのは人であってプロセスやツールではない

プロセスとツールに対する万能型のアプローチを求めるのは、ソフトウェア開発にはうまく機能しない

多様性を許さないプロセスや相互作用を妨げるツールに注意する。ガイダンスとガバナンスを考える

プロセスとツールについて考えるとき、アジャイルではないことを示す「アジャイルBS」フラグは次の通りです。

Doneの定義のようなプロセスの考慮事項が、エンジニアリングチームのトップダウンで定義されている

チームがプロセスソリューションを所有していない(例:スクラム対カンバンの選択)

マネージャーは、エンジニアを細かく管理する方法として、デイリースタンドアップとスプリントゴールを使用している

問題2:アジャイルは意図的に「見積もり」と「コミットメント」を混同し、エンジニアを操って時間外労働をさせる

この問題を2つに分けて考えてみます。

アジャイルは意図的に「見積もり」と「コミットメント」を混同している

チームの取り組みについて話し合う場合、言語は特に重要です。「スプリントへの取り組み」というスクラムの概念を説明するために、スクラムアライアンスとアジャイルアライアンスの共同創設者であるマイク・コーン氏からのアドバイスを紹介します。

「チームのコミットメントが保証と見なされないことが重要です。チームのコミットメントは最善を尽くすことです。私はコミットメントに、おおむね80%の時間を費やしてほしいと思っています。それは彼らが真剣に取り組み、時間の大半を占めるものでなければなりません。これは、チームが提供できるという内容をビジネス側が信頼するために必要なことなのです」。

ここで重要なのは、チームのコミットメントが保証と見なされないことです。チームは最善を尽くし、各イテレーションの終わりに達成したものと目標を比較し、それに応じてプロセスを適応させます。

エンジニアを操って長時間労働をさせる

時間外労働はアジャイルであることとは関係がなく、企業文化と関係があります。とはいえ、アジャイルマニフェストの原則は、アジャイルプロセスは持続可能な開発を促進するということです。これは、エンジニアが時間外労働を一切しなくてもいいということでしょうか? もちろんそんなことはありません。

エンジニアリングリーダーは、チームとともに適切な労働時間を設定することが重要です。たとえば、エンジニアリングマネージャーは期待を次のように伝えます。

私は誰もが週に40〜50時間働くことを期待します。これは通常、1日8時間の稼働で、月に1週間はオンコールであるということです。年に2回、私はチームに時間外労働をお願いするかもしれません。ただし、どうしても必要な場合を除いて、これをすることはありません。

マネージャーはチームに定期的に時間外労働を要求しているわけではありません。しかし、彼らはこれが毎年数回起こる可能性があるということを理解します。

持続可能な開発に関連して、チームや組織がアジャイルではないことを示す「アジャイルBS」のフラグは以下の通りです。

エンジニアリングチームがスプリントに取り組む場合、これは保証と同義である

スクラムチームは常にスプリントのコミットメントを守る

エンジニアリングチームは、スプリントのコミットメントを守るために、定期的に時間外労働をする

問題3:「コミットメント」というスクラムの概念は、2週間ごとに特定の量の完成した作業を実行することを意味する。これは、ソフトウェア開発について長期的な意思決定を望むエンジニアにとっては過度に敵対的である

スクラムチームが次のスプリントの計画を開始すると、彼らは顧客にとって最高の優先度を持つと決定された項目を引き出します。チームの長期的な決定は、チームの製品ロードマップで事前に計画されています。しかし、製品のロードマップは双方向です。プロダクトオーナーは、チームが解決すべき次に重要な問題を定義します。エンジニアがロードマップにフィードバックを提供し、チームが取り組むべきより価値のあるものがあると感じた場合は、それをプッシュバックするかどうかはチームのエンジニアにかかっています。

エンジニアが製品ロードマップにフィードバック(またはプッシュバック)するのはなぜでしょうか。

オンコールローテーションを行っているチームの場合、最近オンコールが特に騒がしくて苦痛を伴う場合、次のスプリントで最も価値のある作業は、インフラの改善を優先することです

チームが大量の技術的負債を蓄積している場合、問題が大きくなる前に、ロードマップを調整してそれに焦点を合わせる必要がある場合があります

チームがユーザーや利害関係者からフィードバックを受け取り、それによって提供している価値を向上させることができた場合、ロードマップを適応させてこのフィードバックに優先的に対応することが、最も価値のある仕事になるかもしれません

長期的な決定について考えるとき、チームまたは組織がアジャイルではないことを示す「アジャイルBS」のフラグをは次の通りです。

エンジニアリングチームには、プロダクトオーナーから解決すべき問題ではなく解決策が与えられる

エンジニアリングチームが製品ロードマップにフィードバックを提供する仕組みがない

成功とはなにか

組織が真のアジリティを受け入れれば、

エンジニアは、メトリクス(製品エンゲージメント、収益への影響、予測可能性など)、チームヘルスチェック、チームの回顧などのメカニズムを使用して、組織に前向きの影響を与えることができます。

形式の整ったスクラムとカンバンチームは、持続可能なペースで作業しながら、予測可能な価値を顧客に提供するとの信頼を得ます

エンジニアはフィードバックを提供し、製品ロードマップを調整して、常に最も価値のあるものに取り組むことができます。さらに、HackWeekを定期的に開催することで、組織にとって最も重要だと思うことに取り組むことができるようになります

学びを共有する

組織やチームが「アジャイル」を装っているのに、実際には全く違うことをしていることに気がついたことはありますか? PagerDutyコミュニティでは皆様からのご意見をお待ちしています。

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