Blog
ブログ

by Alex Ware

常時オンの世界では、デジタル運用を管理するための積極的で予防的なアプローチが必要です。PagerDuty は、システムの健全性をひと目で把握できる要約を提供することで、効率の良いリモート修復を支援する最新リリースを発表しました。

PagerDutyはオンコール管理とインシデント対応機能で知られていますが、インシデントのビジネスへの影響を可視化できるなど、他にも機能があります。これらすべてが一体となって、チーム内の効率化を促進し、重要な問題の管理とトラブルシューティングのコストを削減します。また、新たに開発されたブランドメッセージングを用いて、利害関係者にリアルタイムで情報を提供しながら、統一的なビジネス対応をサポートします。

根本原因分析に役立つ関連インシデント

新たに開始された関連インシデント機能により、ユーザーは重要なアプリやサービスをリアルタイムで可視化し、すべてを1カ所で把握することができます。関連インシデントは機械学習を利用しており、他のサービスで現在どのようなインシデントが発生しているかを表示します。この機能は、イベントインテリジェンスを使用して、複数のチームに影響を与えるインシデントのトリアージ時間を短縮するのに役立ちます。また、重複したコミュニケーションを減らし、障害の全体的な範囲を理解し、問題解決のためにお互いに干渉しないようにします。関連インシデントでは以下のことができます。

他のサービスで同時に発生しているインシデントの中で、関連する可能性のあるものを表示する

リアルタイムの機械学習アルゴリズムを適用するイベントインテリジェンスを使用して、サービス全体のアラートと人間の対応行動を解析、ベクトル化、クラスタ化し、関連するインシデントの提案を行う

「いいね」投票をしたり、サービス間でインシデントをマージしたりすることで機械学習を訓練する

Salesforce V2インテグレーション

PagerDuty Summit 2019では、開発チームとカスタマーサービスチームの連携を強化するために、PagerDuty内のインシデントをSalesforce Support CloudのケースにリンクさせるSalesforce Service Cloudとのインテグレーションをリリースしました。Salesforce V2 のインテグレーションにより、Marketing Cloud、Commerce Cloud、Quip などの Salesforce オファリングのサポートが追加されたため、以下のようなことが可能になりました。

顧客の問題、販売機会、その他の活動に関する対応とアクションを組織全体でオーケストレーションする

PagerDuty の更新（Acknowledge、Resolve、Reassign など）があるとすぐに、関連情報を含む Salesforce オブジェクトを作成したり、更新したりする

Salesforce Cloudのインターフェイス内から、インシデントの優先順位を設定したり、レスポンスプレイを実行したり、インシデントを再割り当てしたりする

任意の Salesforce Cloud 標準オブジェクトとのインテグレーション

ビジネスレスポンスブランディング

多くの企業は重要な情報やコミュニケーションのためのブランドガイドラインを持っています。PagerDutyはビジネスブランドガイドラインをリリースしました。これにより、情報を受信した対応者はそれが経営陣からのものであることを知ることができ、ビジネス関係者やエンジニアはクリティカルな事態の間でも企業ガイドラインを遵守することができます。会社のプロセスを遵守し、メッセージングの信頼性を高めるために、ステータス更新メールに会社のロゴを含めることができます。

モバイルステータスダッシュボード

モバイルステータスダッシュボードでは、エグゼクティブや管理職向けのステータスダッシュボードにコンシューマーユーザーエクスペリエンスの状況を組み込み、スマートフォンやiPadからビジネスシステムのステータスを簡単に表示できるようにしました。

モバイルステータスページでは、技術的な知識を持たないビジネスユーザーに重要な障害のステータスを知らせ、すべてのビジネス関係者がアクセスレベルに関係なく、モバイルアプリで主要なビジネスサービスの状態を確認できます。この機能は、ほとんどの iOS および Android デバイスで利用できます。

ライブコールルーティングのためのカスタム呼び出し

ライブコールルーティングは、顧客から掛かってきた電話やボイスメールをオンコールの対応者に転送することで、カスタマーサポートを充実させることができます。この機能を使うと、専用の電話番号（ローカルまたはフリーダイヤル）が提供され、その番号への着信やボイスメールをPagerDutyのオンコール対応者に転送します。

ライブコールルーティングでカスタムメッセージが使えるようになりました。録音されたMP3ファイルを再生し、以下のように発信者をサポートします。

企業とブランディングを一致させる

クリティカルなイベント発生時に追加サポートを提供する

顧客が正しい番号に発信したことを確認する

顧客を適切なリソースに誘導する

API提供の拡張

ビジネスサービス

チームや人などのオブジェクトのタグ付けと検索

中央集中や分散チームのためのイベント管理ルール

当社の API を使用して、ビジネス・テクニカルサービスの階層を自動化し、時代遅れの散在する Wiki への依存をやめ、ビジネス関連情報を必要な場所に置くことで、情報提供を合理化します。

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

ヘルスチェックは、回復力を維持し、システムの継続的な運用を確保するために不可欠です。理想的には、ヘルスチェックはシステム内の問題を可能な限り早期に検出して、システムが自動的に修正するか、サービスオーナーに問題を通知して手動で解決できるようにしなければなりません。

Amazonの主任ソフトウェアエンジニアであるDavid Yanacek氏が述べているように、システムに適切なヘルスチェックを作成することは難しいかもしれません。しかし、適切に行われていれば、ヘルスチェックは効果的にサービスのダウンタイムを減らし、サービスが依存している顧客に与える影響を軽減することができます。

この記事の主な焦点は、PagerDutyのEvent Ingestion Admin（EIA）サービスのために実装されたヘルスチェックになります。EIAはイベントAPIの管理インターフェイスで、ユーザーは様々なイベントタイプの情報や、イベントが当社のシステム内に読み込まれ処理されている間のイベントの状態を見ることができます。今回は、様々なKafkaトピックからイベントを読み込み、それらのイベントをElastiCacheに保存するEIAのConsumerアプリケーションに焦点を当ててみたいと思います。このブログを読んだ後には、Kafkaに依存したシステムのヘルスチェックの書き方や、発生する可能性のある合併症への対処法が見えてくると思います。

何が不健全なのか？

EIAの問題は、Elixirロガーが新しいログを処理できないためにシステムが予期せずクラッシュした後に表面化しました。また、EIA が Kafka からの新しいメッセージの読み込みを停止する可能性が常にあることも知っていましたし、問題がより深刻になるまで気づかないことも知っていました。

このように、EIA のヘルスチェックで解決しなければならない問題が 2 つありました。（1） Kafka Consumerがforwardしていることを確認すること、（2）Elixir ロガープロセスが黙ってクラッシュすることなく動作し続けることです。これらのいずれかが機能しなくなった場合、健全性チェックは失敗し、システムを安定した状態に戻すために必要なアクションが発動されます。

問題が検出されると、問題を修正するのは非常に簡単です。次のコードは、ヘルスチェックのエンドポイントが何をすべきかをシンプルに示しています。

図1: ヘルスチェックエンドポイント

ヘルスチェックの先頭には Consul と呼ばれるネットワークツールがあります。これは、サービスの発見、ヘルスチェック、ロードバランシングなどを提供する役割を担っています。私たちのケースでは、Consul は基本的にConsumerアプリケーションの ナイーブなアプローチ

EIA は多数の Kafka トピックを読み込み、各トピックには 64～100 のパーティションがあります。各トピックのConsumerごとに別のコンテナをスピンアップし、それぞれが独自のヘルスチェックを持ち、ヘルス状態に基づいて個別に再起動することができます。

まず、Elixir GenServer（汎用サーバ）を作成することから始めました。GenServerは、アプリケーション内の他のプロセスと通信しながら、コードを非同期に保存、状態表示、実行できるプロセスです。特に、ヘルスチェックのGenServerは、イベントの現在の状態を更新し、現在の状態に基づいてアプリが健全かどうかを判断する役割を担っています。

これを行うためには、いくつかのステップを踏まなければなりませんでした。イベントが取り込まれて処理されるたびに、GenServerの状態は、イベントが正常に処理された最後の時間を示すタイムスタンプで更新されます。Consulが このアプローチにはいくつかの問題がありました。2つのConsumerが同じ速度でメッセージを読み込んで処理することはありません。例えば、 それに比べて、 一度失敗したら、試してみて、もう一度試してみる

時間ベースのアプローチでは十分ではないことがわかったので、次のアイデアは Kafka のConsumerオフセットを利用することでした。使用するオフセットには、現在の（最新の）オフセットとコミットされたオフセットの 2 種類があります。現在のオフセットはトピックに送信された最後のメッセージを指し、コミットされたオフセットはConsumerによって正常に処理された最後のメッセージを指します。

Consumerアプリが正常に動作しているかどうかを確認するために、forwardしているかどうかを確認したいと考えました。最新のオフセットが移動している（つまり、新しいメッセージを読み込んでいる）ので、コミットされたオフセットも同様に移動している（つまり、新しいメッセージを処理している）ことになります。このソリューションでは、メッセージがいつ入ってきたかどうかは問題ではないので、最初のアプローチからの問題が解決されます。

このソリューションを実装するために、ヘルスチェックのGenServerは、より複雑な情報をステートに保存する必要がありました。以下はステートを抜粋したものです。

ステートには、メタデータ（異なるオフセットを取得するために必要）とパーティション情報という2つの主要なコンポーネントが保存されています。各パーティションには、コミットされたオフセットと最新のオフセット、そしてパーティションの健全性を決定するフラグが格納されています。新しいイベントが入るたびに、GenServer は新しいオフセットで更新されます。ネットワークツールがヘルスチェックのエンドポイントにpingすると、ステートはすべてのパーティションが不健康であるかどうかをチェックするために繰り返されます。もしそうであれば、Consumerコンテナは再起動されます。

プリプロダクション環境でテストを実行した結果、ヘルスチェックは正常に機能していました。これらの変更を本番環境に適用した後、GenServer が本番環境のトラフィックに追いつけず、ヘルスチェックプロセスがクラッシュし続け、アプリケーションが不安定な状態になっていることがすぐに明らかになりました。私たちは変更を元に戻し、振り出しに戻りました。

3度目のチャンス

以前のアプローチでの最大のボトルネックは、EIA が処理しなければならないトラフィックの量でした。幸いなことに、その答は手元のソリューションからそう遠くないものでした。各イベントの後にGenServerの状態を更新する代わりに、ヘルスチェックは10秒ごとに各パーティションを更新してチェックすることができました。これがどのように実現されたのか、ヘルスチェックの主な機能を見てみましょう。

画像3: ヘルスチェックの実装

GenServerが初期化されると、状態のパーティションデータはNULLに設定されます。最初にConsulがヘルスエンドポイントにpingを打つと、GenServerは各パーティションのコミットされたオフセットと最新のオフセットをフェッチしてステートにセットします。それ以降の実行では、Kafka の各パーティションの現在のコミットされたオフセットと最新のオフセットが、ステートに保存された古いオフセットと比較されます。forwardしている場合は、パーティションの健康状態がtrueに更新され、ステートがオフセットで更新されます。各パーティションを見て更新すると、ステートは反復され、トピック全体が健全かどうかをチェックし、適切な値をConsulに返します。

この方法では、EIA が消費するイベントの数は問題にならないので、健康チェックの GenServer は以前よりもかなり少ない作業をすることになります。これは本番に向けてプッシュバックされ、無事に動作しました!

別れの想い

プロセス全体を通して私が得た重要なポイントの1つは、問題に対する答が最初は必ずしも明らかではないということです。システムとその要件によっては、それが正しいものになるまでに何度も反復する余地があります。Kafka を初めて使う人にとって、システムが健全かどうかを判断するためにツールを活用する創造的な方法を考え出すことは、興味深く、最終的には非常にやりがいのあることでした。もしあなたがKafkaに依存したサービスで同じようなことをしようとしているのであれば、私たちが学んだ教訓を共有して、あなたのプロセスがどのように進んだかを聞いて、あなたを助けたいと思います。

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

by Mark Gabbard

インシデント対応プロセスをどのように設定していますか？

PagerDutyのアプローチは、お客様のインフラ、お客様の顧客向けアプリケーション、お客様の製品を総合的に調べることです。これらの項目を「サービス」と表現して、それらを総合した「ビジネスサービス」を構成します。この設定により、チームはサービスをより効率的に管理できるようになり、インシデントが発生したときに、応答者はより迅速にコンテキストを取得できるようになります。

まず、サービスについて説明しましょう。サービスは持続するように構築されており、通常、元々サービスを開発したチームよりも長生きします。言い換えれば、人々は出入りし、チームは常に再編成されるということです。また、サービスを所有するチームの変更は、年に一度だけとか、再編成時にだけに行われるのではありません。特定のプロジェクトでは、わずか数週間で新しいサービスを開始し、古いサービスを継承し、所有権を変更します。

そのため、インシデント対応プラットフォームをチームやサービスに合わせる（さらに悪いのはサービスをまったく提供しない）場合、チームの再編成が発生するたびにインシデント対応のセットアップ全体をやり直す必要があります。さらに、チームの変化に伴い、組織の知識と重要な分析データが失われます。悪夢のようですね。

そのため、PagerDutyはインシデント管理プロセスをサービスに合わせて容易に調整できるようにプラットフォームを構築しました。これにより、チームは時間の経過とともに成長し、変化することができ、サービスの状態とトレンドをより明確に把握できるようになりました。サービスのデリバリーや保守、改善に影響を与えることなく変更を行うことができるため、最終的にはダウンタイムの長期化と顧客への悪影響を軽減できます。

時間の経過に伴うビジネスインパクトやサービスの稼働状態、トレンドの可視性を向上

ほとんどの企業と同じように、インシデントプロセスのセットアップ、運用サポートや構成をチーム単位で行うことができます。つまり、チームベースのアプローチを取ります。これは、ITSM、DevOps、ITOpsのチームが混在し、ビジネスチームと技術チームがビジネスサービスを定義し、他の多くのチームも異なるサービスを持っていることを意味します。

では、チームベースの設定からサービスベースの設定にどのようにして移行するでしょうか。それは、ほとんどの人が考えるよりも簡単です。

最初に、顧客が特定のタスクや成果を実行するためにやり取りする製品やアプリケーションの部分にあたる最上位レベルのビジネスサービスを特定します。たとえば、「ログイン、ショッピングカート、検索」はすべてビジネスサービスです。次に、そのビジネスサービスを支える技術サービスを特定します。各技術サービスは、複数のチームが長期的なメンテナンスに携わっている場合でも、理想的には一度に1つのチームが所有し、開発する必要があります。

ビジネスサービスとそれをサポートする技術サービスを特定すると、さまざまな興味深いことができるようになります。たとえば、チームはビジネス全体で何が起こっているかをリアルタイムで確認できるようになり、単独の問題なのか、より大きな影響を与えているのかをよりよく理解できるようになります。これにより、問題が複数のチームやサービスにまたがる場合に、より適切に連携した対応が可能になります。

イベントが、環境内のサービスから別のサービスにルーティングされても、個々のサービスが環境にどのように反映するか、何が起こっているのかを誰もが簡単に伝えることができます。さらに、対応者はインフラ全体で発生している他のインシデントを把握できます。

例えば、Site Reliabilityエンジニアリングチームに所属していて、サービスが停止したという通知を受信したとします。同時に、データベースチームの別の対応者も同じ通知を受けました。あなたは、複数のサービスに関連するインシデントを表示できるため、それがデータベースの問題であることがわかり、データベースチームが対処することがわかった時点で、あなたによる問題の処理を中止できます。

ビジネスとビジネスニーズに対応

今日のほとんどの企業には、インシデント管理プロセスのためのチームベースの対応セットがあります。初期の段階では対応セットの設定は簡単ですが、成長と拡張に伴い、長期的な管理が実際には困難になります。なぜでしょうか。

このアプローチで生成されたサイロは、対応者に混乱をもたらします。インシデントが発生したときに、協調的で効果的な対応はより困難です。これは、対応者が実際に影響を受けたものを調べるために時間を費やす必要があるためです。何をすべきかを考える前に「サービスAとサービスBのどちらがページに表示されているのか、どの程度の対応が必要か」を考えるべきです。覚えておいてください。ほとんどのチームは少なくとも10の異なるサービスを所有しており、アラートが異なるサービスにルーティングされるようにイベント情報を整理しておくと、何が起こっているのかをよりよく理解するのに役立ちます。

これとは対照的に、技術サービスとビジネスサービスの橋渡しをする、サービス優先のアプローチを採用している組織は、特定のサービスの重要性に関するコンテキストを提供できるため、ビジネスと顧客に明確なインパクトを与えます。また、コミュニケーションのための共通言語を提供し、簡潔で実用的なステータスの変化を知る必要がある人と自動的に情報共有できるようにします（例：サービスAは見積りから現金までのシステムをサポートしているため、インシデントが発生した場合には、SLAがなく必須ではない内部サービスBより高いレベルの対応が必要、などの情報）。

チームベースのセットアップは簡単

前述したように、インシデント管理プロセスの構成と設定にチームベースのアプローチを使用すると、最初は簡単です。ただし、長期的にはマイナスの方がプラスよりも大きくなります。たとえば、チームベースのアプローチでは次のことはできません。

インシデントのビジネスインパクトをリアルタイムで評価する

サービスがアプリケーションの信頼性や安定性に及ぼす影響を分析する

問題の影響範囲を正確に評価する。これは通常、複数のサービスにまたがるので重要

重大なインシデント発生中に通知すべきビジネス関係者を迅速に決定する

加えて、チームベースのアプローチには、チームの変更や再編成に応じて変更を加える柔軟性がありません。さらに、組織の変更がある場合は常にチームとサービスを再構築する必要があります。

最適なアプローチ

インシデント管理プロセスを設定するため、チームベースのアプローチとサービスベースのアプローチのどちらを採用するか決定する前に、「オンコールを設定するのはなぜか」を考えてみましょう。

最も可能性の高い回答は、問題が発生したときに迅速に対応するチームや担当者が必要なため、ということです。また、多くの企業では、チームファーストのアプローチで構成を設定しています。これは、チームがあり、全員がオンコールローテーションに参加していることを確認する必要があり、この方法だと簡単に設定できるからです。

誤解しないでほしいのですが、チームは非常に重要です。しかし、インシデント管理の設定とサービスのセットアップを最初に行うことをお勧めする理由は、それによって次のことが得られるからです。

サービスの健全性を理解し、プロセスを改善するために必要な可視性

ホットスポットを特定するためのトレンドに関する洞察

どのチームがどのサービスをサポートしているかを簡単かつ迅速に確認する能力と、複数のチームを通過して問題のサービスに到達する前にそれらのレイヤーを理解する能力

結局のところ、企業が本当に気にしているのは、ビジネスを遂行できること、そして、迅速に対応する必要がある影響を与えるあらゆることです。そのための最善の方法は、サービスベースのアプローチを使用することです。サービスベースのアプローチを使用すると、何に取り組む必要があるのか、どのように優先順位を付ける必要があるのかを理解できるようになるため、問題のサービスを探すためにいくつものチームのレイヤーを掘り返すことで時間を無駄にすることがなくなります。

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

by Andrew Marshall

PagerDutyの製品管理担当副社長Rachel Obstlerが4月にSlack Frontiersの「Slackによるインシデントの予測、監視、管理」パネルで新しいSlackインテグレーションのベータ版を発表したとき、私たちはこのインテグレーションに関心を持っていただけることを期待していました。

しかし、まだベータ版であるにもかかわらず、すぐにトップレベルのインテグレーション製品になるとは予想していませんでした。そしてこのほど、PagerDutyのSlackインテグレーションが一般公開されました。この記事では、Slack Integrationの主要な機能のいくつかを紹介し、ベータユーザーからのフィードバックを共有します。

どこにいても働ける

現代のOpsやDevOpsチームは、日々ますます多くのツールに依存しています。各ツールにはそれぞれ目的がありますが、必要なコンテキストを取得するためにアプリを切り替えることで、特に複雑なインシデントに対処するときには、素早さと集中力が低下することがあります。PagerDuty for Slackとのインテグレーションでは、PagerDutyインシデントに関するコンテキストの作成、エスカレーション、収集をSlack内から行えます。アプリを切り替える必要がないで、PagerDutyのデスクトップやモバイルインターフェースを使用する場合でも、Slackでリアルタイムオペレーションを管理する場合でも、PagerDutyがこれ1つで利用できます。

Fuzeのインシデント管理マネージャであるCorey Forman氏は、このインテグレーションについて次のように述べています。

「DevOpsチームとエンジニアリングチームがSlackのヘビーユーザであるため、PagerDutyのインテグレーションを各チームチャネルに追加するのは簡単です。アラートを受信し、インシデントを受任し、追加のリソースを通知し、トラブルシューティングの会話を継続する機能は、他にはないこのアドオンの真価です」。

SlackからのResponse Playの実行

Response Playの実行などのPagerDutyのリアルタイム操作機能はSlack内から操作できます。Response Playを実行するPagerDutyの対応チームは、インシデント管理プロセスをSlackアプリの中から素早く簡単に実行できるため、時間を節約し、集中力を維持できます。

ウォールームと他のスラックチャンネルの作成

チームがSlackのようなChatOpsツールに依存するようになった主な理由の1つは、全員が同じページと共通のダイアログスレッドに参加できるように指定されたチャネルを作成できるからです。PagerDutyから新しいウォールーム（または任意のSlackチャンネル）を作成したり、既存のウォールームに参加したりする機能を追加する際には、私達はこれを念頭に置いていました。また、追加のSlackチャンネル対応者をミックスに招待する機能も加えました。チームは、チャネル内のすべてのディスカッションとアクションをキャプチャして、事後レビューに使用できます。

Slack通知に対応

response作業には、豊富なインシデントコンテキストが不可欠です。PagerDuty for Slackでは、関連するインシデント・ファクトとデータ・ポイントをすべてSlack内に表示することで、対応者の武器となります。また、custom incident response playsを実行し、Slack通知から直接対応者を追加することもできます。

WallCraftのAleksey Smirnov氏は「PagerDutyのSlackインテグレーションは、チームに新しいレベルの可視性をもたらします。Slack内でGrafanaアラートを表示できるので、時間を大幅に節約できます」と述べています。

Slackからオンコール情報の表示

最新のオンコールシフトのスケジュールは、インシデント管理計画とインシデント対応に不可欠ですが、スケジュールを覚えていないこともありえます。PagerDuty for Slackのインテグレーションにより、チームはSlackのインターフェースから最新のオンコール情報とタイムラインを表示できます。

「以前は『今夜の当番は誰？』という会話がSlackでよくありました。SlackとPagerDutyのインテグレーションで、誰がオンコールなのかが分かり、Slackを離れずにアラートを知ることができるようになりました」と前出のForman氏は述べています。

Slackからインシデントのトリガー

Slackから直接PagerDutyインシデントをトリガーすることもできます。SlackのようなChatOpsツールは、チーム内やチーム間をリアルタイムでつなぎます。多くの場合、この個人間のやり取りはリアルタイムで問題を特定するのに役立ちます。問題が発生している最中にSlackからインシデントを発生させることができるため、チームはSlackを離れることなく、その時点で規定されたアクションを素早く起動することができます。

組織内の様々なITOpsチームとの接続

現代の企業の多くには、NOCからCentral Ops、DevOpsなどの様々なチームが存在します。PagerDuty for Slackのインテグレーションは、これらの異なる構造のOpsチーム、セキュリティやカスタマーサービスなどの他のチームを共通のインシデント管理フレームワークに接続して、チーム内とチーム間のコミュニケーションを改善します。また、チームはSlackbotを使って、Slackのインテグレーション機能の使用方法を学習できます。

SlackとPagerDuty間のアクセス許可の調整

チームのPagerDuty PermissionのセットをSlackユーザーと同じにすれば、個人とチームが簡単に連携できます。PagerDuty for Slackインテグレーションにより、権限を複製したり再設定する必要はありません。

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

一見すると、機械学習を継続的デリバリー（Continuous Delivery）に適用するのは、ハンマーでピーナッツを割るように聞こえるかもしれません。 つまり、デプロイメントの自動化は実際どれだけ難しいのでしょうか？

調べた結果、それは私たちが考えるよりも複雑です。

新しいデプロイメントをプロダクションに移すと、通常2つの結果になります。

サービスは起動し、すべてがOKだと思う。 サービスは起動せず、何もかもが壊れてる。

現実には、上の2つの点は、組織の95％がデプロイメントの成功を測る方法（上=良い、下=悪い）を表しています。 幸せなPagerDutyのお客様は、2番目のシナリオ（携帯電話にアラートとインシデントの嵐が届く状況）はよくご存じです。 しかし、シナリオ1は、誤解を招く可能性があります。サービスが動いているからといって自動的に健全性、性能、品質がOKだという証拠ではないからです。

手動でデプロイメントのヘルスチェックをする短所

Harness（訳注：Continuous Delivery-as-a-Service プラットフォームのサービス提供会社）で最初の25人の顧客から私たちが学んだ1つは、大部分の組織では一般的に3〜5人のエンジニアがいて、手動で実稼働展開を確認す​​るのに1時間以上かかるということです。例えば当社の顧客のBuild.comは5-6人のチームリーダーがNew RelicとSumo Logicのデータを手動で分析するのに1時間かかっていました。これは通常、複数のコンソール/ブラウザウィンドウを開き、bashスクリプト、アプリケーションパフォーマンス監視、ログ分析ツール間でコンテキストを切り替えることを意味します。

人間の脳は短期記憶を使う際は8-10​​項目しか集中できず、様々なシステムからのすべてのデータが集中していることを考えると、2018年の人間は非常に簡単にミスをします。数十万回の時系列メトリックと、展開後に数百万回のログエントリーがあることを考えれば、 手作業による分析とヘルスチェックは難しい問題です。

AIと機械学習がヘルスチェックを支援するようにする

Harnessでは、ソフトウェアアーチファクトのプロダクションへのデプロイメントを自動化するだけではありません。 AIや機械学習を使ってヘルスチェックを自動化します。 私たちはこのContinuous Verification（継続的検証）と呼んでいます。

主に隠れマルコフモデル、記号集約表現（訳注：Symbolic Aggregate Representation。いわゆるSAX）、k-平均法クラスタリング、およびいくつかのニューラルネットなどの教師なし機械学習アルゴリズムを使用して、APM（アプリケーション性能指標値）とログデータから異常や性能低下の検出を自動化します。

Harnessは、新しいソフトウェアアーチファクトを数秒で展開して、任意のAPMツールまたはLogツールに接続し、パフォーマンス（応答時間/スループット）と品質パースペクティブ（エラー/例外/イベント）から、アプリケーションの動作モデルを自動的に生成できます。

Harnessはこれらのモデルを以前のデプロイメントと比較し、新しい異常や性能低下を即座に示します。 人間が処理や分析をするのに要する時間に比べ、機械学習アルゴリズムでは数秒しかかかりません。

たとえば、以下のスクリーンショットはAppDynamicsのAPMデータをHarnessで検証した結果です。

上記の画像では、Harnessが展開後に2つのビジネストランザクションがパフォーマンス低下を示していることが分かりました。 以下の図では、「Request Login」という1つのトランザクションで、応答時間が31msから165msに増加したことを示しています。 この分析はすべてAI と機械学習で自動化されています。

SplunkからのアプリケーションログについてHarnessが検出したエラー/例外の異常の別の例を次に示します。

赤い点は、デプロイ後からアプリケーションログに入るようになった新しいエラーを示します。 灰色と青色の点は、すべてのデプロイで通常観察されるベースラインのイベントまたはエラー/例外を表します。

ハーネスは、k-平均法クラスタリングといくつかのJacardおよびコサイン距離演算（訳注：ふつう、集合の類似度を示す）を使用して、これらのビジュアルを生成します。 任意の点をクリックすると、イベントのスタックトレースと根本的な原因も表示されます。

AI / 機械学習インテリジェンスによるロールバックの自動化

Harnessは、Continuous Verificationのインテリジェンスを使用して、デプロイメントのロールバックを自動化することもできます。 Harnessは、Dev / DevOpsチームがより速く展開できるようにしながら、新しい異常や性能低下に遭遇するたびにロールバックできるようにするセーフティネットと考えてください。

今後のPagerDutyのHarnessサポートにより、各組織はPagerDutyを通知チャンネルとして、また検証ソースとして使用することができます。 たとえば、Harnessはデプロイの前にPagerDutyに対して、運用中に発生しているアクティブなインシデントがあるかどうかを確認するクエリを送信できます。Dev / DevOpsチームが最後に望むのは、本番環境に展開することです。

まとめると、Harnessは、 継続デリバリー・サービス（ Continuous Delivery as-a-Service ）を提供することで、各組織が本番環境でエンドユーザーへのソフトウェアの展開と配信を自動化することを支援します。私たちは、顧客が何かを壊すことなく迅速に動けるよう支援します。

Steve BurtonはHarness.ioのCI / CD DevOps Evangelistです。 Harnessに入る前は、AppDynamics、Moogsoft、GlassdoorでGeekをやっていました。 彼は2004年にSapientでJava開発者としてキャリアをスタートしました。 テクノロジーで遊んでいないときは、通常はF1を見たり、インターネットで車を研究したりしています。

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

by Adam Keller

想像してみてください。航空会社のデータセンターでチケット発券システムがダウンするような重大なITインシデントが起こりました。舞台裏では、エンジニアが問題の診断と修正を急いでいます。しかし、昨今のシステムは非常に複雑であるため、問題の解決には予想よりも長い時間がかかり、システムがダウンしてから数時間が経過しています。

一方、乗客は長い列を作り、地上係員に怒りをぶつけ、ソーシャルメディアで人々とフラストレーションを共有しています。カスタマーサービス要員には何が起こっているのかわからず、乗客と同様の情報にしか与えられていないにもかかわらず、なんとか状況を説明して全員を落ち着かせようと最善を尽くしています。

ここで、顧客が直面しているのは技術的なインシデント対応で、カスタマーサービス要員、フライトクルー、手荷物係などの内部関係者に情報を提供するなどのビジネス的な対応は存在しないか、あっても行き当たりばったりなので、インシデントの影響を悪化させ、会社のブランドや評判に深刻な損害を与えてしまいます。

そこで我々は、PagerDuty Solution for Business Responseをご用意しました。

ビジネス対応のためのPagerDutyソリューション

この例のように、ビジネスや顧客に影響を与える重大なインシデントが発生した場合、技術面の対応者（つまり、プライマリレスポンダー）だけが行動を起こす必要があるのではありません。会社全体の関係者（エンジニアと非エンジニア）も動員する必要があります。

これらの「二次対応者」は、例えばメディアへの説明ポイントをまとめるなど、ビジネス上の負の影響を軽減するために、最新のインシデント解決の進捗状況を知る必要があります。航空会社の例では、顧客サービスチームとチケット発券業者は、このインシデントがビジネスにどのような影響を与えるかを理解し、ホテルクーポンの提供や乗客の再予約が必要かどうかを決定する必要があります。

PagerDuty Solution for Business Responseは、インシデント対応に当たる技術チームの手をわずらわせることなく、簡潔で実用的なステータス更新を、それを知る必要のある人と自動的に共有することにより、インシデント発生時のビジネス部門と顧客とのコミュニケーションを円滑にします。

「顧客がデジタル製品に24時間年中無休でアクセスできることをますます期待するにつれて、システムダウンの潜在的な悪影響が増大します。インシデント発生中、技術的な対応はビジネス的な対応とうまく統合されないことが多く、このコミュニケーションのギャップは消費者の体験を左右します。PagerDutyのビジネスレスポンスソリューションは、技術とビジネス利害関係者の両方にインシデントを迅速に通知し、問題を修復するための調整されたアクションを実行できるよう構築されました」。

–Rachel Stephens、RedMonkアナリスト

ユーザーは、通知方法をカスタマイズすることもできます。たとえば、PagerDutyのWebサイトのステータスダッシュボードを表示するだけでなく、SMSやメール、PagerDutyモバイルアプリを介してプッシュ通知を受信するように設定できるため、特定のインシデントが発生したことをリアルタイムで知ることができます。

リアルタイム更新のステータスダッシュボード

PagerDutyのステータスダッシュボードには、事前に選択されたビジネスサービスの健全度が表示されるため、従業員はシステムの現在の状態を一目で把握し、過去に起こったことを確認し、メンテナンスやアップグレードなどの今後のサービス変更予定を確認できます。エンジニアは、技術的アクションとビジネスアクションの協調が最も重要なときに両方を調整する洗練されたインシデントレスポンスプレイとフローを設定することもできます。

PagerDutyのビジネス対応ソリューションの利点

Modern Incident Response製品の上に構築されたPagerDuty Solution for Business Responseは、ユーザーにインシデントの状況認識をシームレスかつ自動的に通知するので、技術面の対応者とビジネス関係者／利害関係者の両方がリアルタイムのインシデント情報を使用して対応を調整できます。追加の有料アドオンは必要ありません。利点は次のとおりです。

顧客との関係を積極的に管理することで、企業とブランドに対する顧客の信頼が高まります。関係者と従業員は、顧客から質問される前にインシデントを認識します リアルタイムでインシデントに対応できるようにすることで、ビジネス関係者と対応エンジニアの生産性を向上 顧客に影響を与えるインシデントが発生した場合に、技術的対応とともに、ビジネス対応活動を迅速に開始できる サービスの健全度が一目でわかるライブステータスダッシュボード リアルタイムのターゲットを絞ったステータス更新とビジネス部門自らの関与により、IT部門の負担なしで主要な利害関係者と積極的に関与する機能

Business Responseが実際にどのように機能するか、さらにお知りになりたい方は、次のビデオをご覧ください。

サブスクライバー（情報購読者）の追加、ステータス更新の追加、ステータスダッシュボードでビジネス対応を調整する：https://youtu.be/MaUmLBgLDBE 利害関係者チームや関連対象者向けの特定のビジネスサービスのみを含むカスタムダッシュボードを作成する：https://youtu.be/Ug1s_fsheu4 サブスクリプションの管理と通知ルールの表示：https://youtu.be/XX2aP200wSw ユーザーとチームを追加して、ステータス更新の受信と公開をする：https://youtu.be/C39wNKK_RMw

PagerDuty Solution for Business Responseは、Modern Incident Responseプランのお客様が利用できるようになりました。ステータスのボタンをクリックするだけで準備完了です。この機能にご興味がある場合は担当者に連絡し、詳細についてサポート技術情報をご覧ください。

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

PagerDutyは2019年8月、新しいリリースを発表いたしました。このリリースでは、いつでもどこからでもリアルタイムで安全に作業できるように、新しい製品機能と拡張機能のセットが提供されます。

このリリースでは、デジタルオペレーションを最適に管理するためのより良いプラットフォームを構築するというお客様のニーズに引き続き応えています。機能強化には、モバイルアプリの新しいイノベーションと、メールドメインの制限を追加することによるプラットフォームセキュリティの強化が含まれます。また、分析スコアカード機能をより柔軟にし、Amazon EventBridgeとの新しいパートナーエコシステムのインテグレーションを追加しました。

モバイルプラットフォーム

すべてのインシデントが24時間以内に解決できるわけではないため、ユーザーが24時間以上アラートをスヌーズするオプションを追加し、営業時間外のアラートをより柔軟に管理できるようにしました。長時間スヌーズは現在iOSアプリで利用可能ですが、Androidでも近日中に提供される予定です。

設定についての警告

ユーザーは設定メニューで PagerDutyインスタンスのセットアップを最適化する方法を見つけることができます。警告をタップして、連絡方法と通知ルールを更新します。たとえば、ユーザーがSMSやメールなどの連絡方法を追加するのを忘れた場合、連絡方法の追加を推奨する警告がポップアップ表示されます。

ビジネスサービスのステータス更新

ビジネスレスポンス用PagerDutyソリューションをローンチしました。これは、アドオンのModern Incident Response上に構築されています。この新しいソリューションには、ビジネス関係者に明確で簡潔な情報を提供する新しいステータスダッシュボードが含まれているため、チームはインシデント発生時のリアルタイムのビジネスおよび技術的対応をより適切に連携、調整できます。

ユーザーはインシデントに優先度レベルを割り当て、モバイルアプリから直接ビジネスサービスに関連付けることができます。この新機能により、技術担当者はビジネス系サブスクライバーに通知でき、ステータスダッシュボードの適切な場所に情報が表示されるようになります。

iPadレイアウトの改善

新しいiPad用のレイアウトにより、より大きな画面をより有効に活用し、インシデントをタップして詳細を表示できます。また、分割画面のサポートもあり、PagerDutyアプリをカレンダー、Slackなどの他のアプリと一緒に使用できます。

eメールドメイン制限付きの強化されたプラットフォームセキュリティ

メールドメインが制限されているお客様用に、セキュリティレイヤーを追加しました。これにより、承認されたメールドメインを持つユーザーのみがPagerDutyセッションにアクセスできるようになります。管理者とアカウント所有者は、ユーザーがログイン情報を作成または変更したり、メールアドレスに連絡したりするときに、メールドメイン許可リストにあるドメインのみを使用するように制限することができます。

新しい分析スコアカード検索と購読、購読解除機能

新しい分析スコアカード検索により、ユーザーはチーム名またはカスタムスコアカード名を検索することにより、利用可能なスコアカードのリストから特定のスコアカードをすばやく見つけることができるようになりました。以前は、ユーザーはスコアカードのリストを目で見て必要なものを見つける必要がありました。特に、多くのチーム、多くのスコアカードを購読しているリーダーや大規模な組織のユーザーにとっては、時間がかかるイライラする作業でした。

また、ユーザーはスコアカードのサブスクライブを設定、解除できるようになりました。これにより、チームに所属していない場合でも、チームの運用指標を確認できます。サブスクライブ／サブスクライブ解除機能を追加することにより、ユーザーはUIに表示するスコアカードの中から見たいものだけを表示できるため、カスタマイズされ、すっきりしたユーザーエクスペリエンスを体験できます。たとえば、マネージャーやエグゼクティブのマネージャーは、さまざまなチームグループに参加することなく、関心のあるデータを表示するためにサブスクライブできます。

パートナーエコシステムインテグレーション

Amazon EventBridge

PagerDutyとAmazon EventBridgeとのインテグレーションにより、チームはネイティブAWSサービスをPagerDutyに接続するイベント駆動型のワークフローを簡単に作成できます。Amazon EventBridgeを使用すると、PagerDutyのお客様は、AWSがサポートする幅広いインテグレーションと機能を活用できます。

この8月リリースの新機能にご興味がある場合は、詳細についてのサポート技術情報をご覧ください。

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

by Andrew Marshall

2019年7月のニューヨークでのAWSサミットは、AWSとPagerDutyの両方にとってエキサイティングなものでした。AWSチームは、AWSでSaaSを提供するパートナー企業が、顧客が処理するイベントを簡単に挿入できるようにするAWS CloudWatch Events用のAPIセットであるAmazon EventBridgeを公開しました。PagerDutyは、EventBridgeをローンチパートナーとしてサポートすることで、AWSとの長年のパートナーシップを深化させています。AWSベースのクラウドインフラストラクチャを使用するPagerDutyのお客様は、EventBridgeのアドバンテージを利用して、PagerDutyのリアルタイムオペレーションプラットフォームをさらに活用できます。

AWS Lambdaについて少々

AWSがre：InventでサーバレスサービスAWS Lambdaを2014年に発表したとき、多くの開発者はLambdaの大きな可能性について懐疑的でしたが、Cloud Foundry Foundationの世界的な調査によると、22％の企業がすでにサーバーレステクノロジーを使用していることがわかりました。Lambdaが提供する価値はシンプルです。サーバをプロビジョニングせずにコードを実行できます。チームはほぼすべてのタイプのアプリケーションまたはサービスを自動的に実行でき、Lambdaはどんなコードでも実行しスケーリングします。EventBridgeはAWS Lambdaを使用して、PagerDutyなどのSaaSパートナーと提携することで、さらに多くのことを可能にします。

それで、EventBridgeって何?

EventBridgeはAWSの新しいサービスであり、チームは複雑な設定とインテグレーションに貴重な時間を費やすことなく、ネイティブAWSサービスをPagerDutyなどのサードパーティSaaSソリューションに接続するイベント駆動型ワークフローを作成できます。EventBridgeにより、PagerDutyの顧客はAWSがサポートするインテグレーションと機能のすべてを活用できます。

PagerDutyデータのインバウンドソース

EventBridgeを使用すると、PagerDutyユーザーは PagerDuty Eventsによってトリガーされるイベント駆動型ワークフローを簡単に作成できます。AWSコンソール内のインバウンドデータソースが信頼できるため、チームがデータにアクセスするために複雑なWebhookや他のマニュアル設定手順を使用する必要はありません。セットアップが完了すると、チームはPagerDutyイベントデータを使用して、AWSでイベント駆動型のワークフローをトリガーできます。

「AWS EventBridgeとPagerDutyを組み合わせることで、イベント駆動型のワークフローをリアルタイムで生成できます」とCox AutomotiveのリードソフトウェアエンジニアであるEd Kozlowski氏は述べています。「問題を検出すると、PagerDutyは、AWS Lambda関数をトリガーするアラートを生成してランブックを取得し、PagerDutyに詳細をポストできるため、問題をより迅速に解決し、お客様に最高のエクスペリエンスを提供できます」。

PagerDuty＋EventBridgeをどう使うか

幅広いAWSサービス製品と同様に、PagerDutyとAmazon EventBridgeでできることには制限がありません。とはいえ、顧客が即時のビジネス価値を実感するために実装できる次のような用途があります。

セキュリティ修復　オープンポートを（AWS GuardDutyを介して）検出するとします。これは明らかにセキュリティリスクであり、適切な対応者に警告する必要があります。PagerDutyとEventBridgeを使用すると、SecOpsまたはオンコールチームへのアラートをトリガーするだけでなく、直接オープンポートへのアクションを実行できます。この追加された修復アクションでは、たとえば、AWS Lambda関数を使用して、Amazon Virtual Private Cloudがポートを閉じます。 実行可能なコンプライアンス違反　同様に、AWS Identity and Access Management（IAM）ロールまたはアクセス許可違反がAWS CloudTrailを介してトリガーされたとしましょう。適切なサービスチーム、管理者、またはSecOpsにこの潜在的なセキュリティやコンプライアンスの問題を知らせてほしいが、警告だけでは修復に役立ちません。PagerDutyとEventBridgeを使用すると、このデータを使用してAWS Lambda呼び出しを自動的に行い、アクセスを完全にロックするか、別の構成変更をトリガーして問題に対処できます。

PagerDutyユーザーが活用できるその他のいくつかのユースケースには、次のものがあります。

リソースのデプロイ：サービスリソースをスケーリングまたは起動して、新しい需要に対応します。 エンドポイントの問題：Amazon Personal Health Dashboardを使用して、エンドポイントの問題に対処するための変更を行います。 カスタマーサービス：PagerDutyがインシデントに対処するときに、新しいSalesforce.com Service Cloudケースを自動的に作成するか、既存のケースを更新します。

AWSエコシステム内でPagerDutyのデータとアラートを実行可能にする準備はできていますか？ 詳細については、EventBridgeインテグレーションガイドや、PagerDutyのAWSインテグレーションスイートをご覧ください。

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

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

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

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

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

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

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

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

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

DevOpsの定義

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

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

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

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

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

組織変更

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

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

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

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

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

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

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

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

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

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

6月の新機能リリースでは、チームがどこにいてもリアルタイムで作業できるように設計された新しい一連の機能強化を発表いたしました。移動しながらモバイルデバイスを使っていても、いつものようにデスクにいても、使いやすさを犠牲にすることなく業務の革新を続けていきます。

あなたのやり方で

PagerDutyを使用すると、チームはデスクトップから、もしくはチャットやモバイルを介して、どこからでもリアルタイムの作業を管理できます。

モバイルチームとエスカレーションポリシー

iOSモバイルデバイス用のPagerDutyモバイルチームとエスカレーションポリシーが更新されました（Androidは近日公開予定）。これで、iOSモバイルデバイスで次のすべてを直感的に実行できるようになりました。

チームメンバーとオンコール担当者がすぐ分かる 問題の現状把握と解決を容易にするため、適切な対応者とその連絡先を特定する チームのエスカレーションポリシーの明示

再設計されたモバイルオンコールシフトとスケジュール

モバイルオンコールのシフトとスケジュールの全体を確認し、タップしてスケジュールやエスカレーションポリシーの詳細を表示し、簡単に変更できます。

モバイルビューとインシデント対応者の追加

誰がインシデントに対処しているのかを確認し、アプリから対応者（ユーザーまたはエスカレーションポリシー）を追加して、問題を迅速に解決するために必要な支援を受けることができます。

モバイルビューインシデントステータスの更新

その他の新たな機能は、企業全体のコミュニケーションを自動化して、チームが重要なインシデントについて組織全体で認識を共有するのに役立ちます。iOS向けの最近のリリースに続いて、Androidデバイスを使用する利害関係者も、インシデント購読者を管理し、インシデントのステータスの更新を表示して、関連する解決活動について常に情報を得てデジタルビジネスの健全性を把握できます。

モバイルスワイプジェスチャー

インシデントに対するモバイルスワイプジェスチャーの改善により、Androidでは設定メニューから、iOSではスワイプから表示、タップと確認で、左スワイプや右スワイプのアクションを設定できるようになりました。

モバイル複数選択ワークフロー

Mobile multi-select workflowsで、一度に複数のインシデントをトリアージ、スヌーズ、マージ、受任することができます。これにより、ノイズを削減し、PagerDutyイベントインテリジェンスにフィードバックを提供して、トリアージとスマートな応答を迅速に行えます。

新インテグレーションーCloudability、Demisto、Salesforce（coming soon）

私達はFinOpsやSecOpsなど、さまざまな利用法をツールチェーンで接続する際に、より高い可視性と柔軟性を持つことができるように、新たなインテグレーションへの投資も続けています。さらに、Salesforceとのインテグレーションも間もなく開始されます。そのほか、新しく強化されたインテグレーションには、CloudabilityとDemistoがあります。

PagerDutyとCloudabilityのインテグレーション により、クラウド関連の意思決定と予測、計画、および購買能力の適切でタイムリーな最適化アクションを実行できます。このインテグレーションにより、クラウド使用料請求に異常が検出されたときに、リアルタイムで使用量を最適化することができます。

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

豊富なクラウド請求イベントデータをCloudabilityからPagerDutyにリアルタイムで送信する Cloudabilityインスタンス内の異常を検出する 対応するPagerDutyサービスで新しいインシデントをトリガーする アラートを単一のインシデントに自動的にグループ化する Cloudabilityで検出された異常に対処するようオンコールの担当者に通知する

PagerDutyとDemistoのインテグレーション により、自動化されたデジタル運用管理とセキュリティとITチームにわたる集中的なインシデント監視が可能になります。また、DevSecOpsツールスタック内で機動的なセキュリティ対策を実施するのに役立ちます。

PagerDutyイベントの取り込みと作成、解決を自動化 Demistoインスタンス内のPagerDutyからオンコールスケジュール、連絡方法、通知の詳細にアクセスする 何百ものDemisto製品統合を活用して、部門を超えて対応を調整する ChatOpsを介して対話的に数千のコマンドを実行する 実行スクリプトを作成する。コントロールルームでコマンドを実行したり、スクリプトをプレイブックに関連付けたりする

PagerDutyとSalesforce Salesforce Service Cloudとのインテグレーションはまもなく登場します。内部プロセスがあなたの顧客経験に影響を与えないようにしてください。PagerDutyはSalesforce Service Cloudとのまったく新しいインテグレーションを開始し、カスタマーサービスチームがリアルタイムのサポートを受けられるようにします。双方向のインテグレーションにより、PagerDutyとSalesforceケースの同期が維持され、エージェントは必要に応じて適切なリソースを毎回適切な時期に活用できます。

インシデント対応

より大きなコンテキスト

コンテキスト検索

Contextual Searchでは、チーム、エスカレーションポリシー、ユーザーなどの簡単なタグ付けメタデータをPagerDutyオブジェクトに追加して、対応者とマネージャーが目的のオブジェクトをナビゲートして整理しやすくするとともに、インシデントをすばやく簡単に再アサインできます。タグ付けはコンテキスト検索と連動しているため、インシデントに対応者を追加するときにエスカレーションポリシーをフィルタリングできます。次のスクリーンショットは、PagerDutyオブジェクトのタグ付けの概要を示しています。

Contextual Search APIは現在、特に関心のある利用者への早期アクセス提供となっており、2019年夏に一般利用可能になる予定です。

チームタグの作成と追加

エスカレーションポリシーのタグ

ユーザータグ

タグでオブジェクトを絞り込む

タグを使用してインシデントを再アサイン

モバイルでのエスカレーションポリシーのコンテキストサーチ

Mobile Contextual Searchを使用して、アラートを受信すればいつでもどこでも、タグでエスカレーションポリシーをフィルタリングしたり、検索を使用してインシデントを適切な担当者にすばやく再アサインできるようになりました。

セルフサービスの拡張性

ユーザセッション管理API

User Session Management APIエンドポイントにアクセスしてユーザーセッションを取得、削除できます。これらのエンドポイントは、組織外のユーザーをそのユーザーに関連付けられているすべてのPagerDutyセッションから安全に削除する、ユーザーオフボーディングワークフローの活用に不可欠です。

リアルタイムの可視性

可視化コンソールのパフォーマンスとカスタマイズ

可視化コンソールのパフォーマンスが新たに強化されたことで、エンジニアとビジネス担当者の間で、テクニカルインシデントがデジタルエクスペリエンスにどのような影響を与えるかをリアルタイムで共有することができます。可視化コンソールのすべてのモジュールがライブアップデートされるようになったため、手動でのリロードや自動更新は不要になりました。さらに、コンソールレイアウトの変更は自動的に維持されるようになり、レイアウトの変更を手動で保存する必要がなくなりました。

6月リリースの新機能を使い始めるには、あなたのアカウント担当者に連絡を取り、詳細についてはKnowledge Baseをチェックしてください。

最後に、私たちは定期的に、四半期ごとのPagerDuty Pulse Webinarで、製品、インテグレーション、その他新機能のすべてを紹介しています。今すぐregister todayで登録しましょう。

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

今日のデジタルワールドでは、企業のビジネス関係者や障害対応にあたる技術者は、中断が発生したときにすぐに対応できるように、常にデジタルサービスの健全性を意識する必要があります。それでも過去3年間で、1人のレスポンダーあたりの業務の複雑さは平均3倍に増えているため、チームがデータを理解し、意味のある洞察を得て、デジタルオペレーションを改善することはますます難しくなっています。

そこで今日私たちは、インテリジェントな企業向けに設計した新しい一連の製品の機能を発表します。これらの機能強化によって、各チームが重要な瞬間にデータ、インテリジェンス、そして大規模な自動化を使って、効果的に成果を上げることができます。Spring 2019リリースでは、プラットフォーム全体で新しい改善が行われており、エンタープライズクラスのものでありながらユーザーを念頭に置いて設計されたエクスペリエンスを提供します。

新製品のアップデート

この1年で、私たちは、マシン、チーム、サービスの所有権、そして人間の応答データにわたる、独自のテレメトリの流れに基づいて構築された、いくつかの新しいモジュラー製品をコアプラットフォームの上にリリースしました。 以下に詳述するこれらの新製品は、すでに何千ものチームがよりインテリジェントで効率的な方法でリアルタイム作業を処理するのを助けています。

PagerDuty Event Intelligence

ますます複雑化する運用上の複雑さを管理し、ノイズから信号を抽出し、機械学習主導のコンテキストでトリアージを加速することで、チームの拡張を支援します。

PagerDuty Modern Incident Response

自動対応の動員と利害関係者のコミュニケーションにより、チームは重要なインシデントをより迅速に解決できます。

PagerDuty Visibility

レスポンダーと事業主の両方がデジタルの混乱への共通の状況を受け取ることができます。

PagerDuty Analytics

運用上の投資と成熟度を向上させるための最新の洞察をデジタルビジネスのリーダーに提供します。

Human-Context Enriched Intelligenceの提供へ

Springリリースの一部として、 いくつかの新しい機能でPagerDuty Event Intelligenceを強化しました。 機械学習を使用してノイズを低減するPagerDuty独自のIntelligent Alert Groupingアルゴリズムは、これをさらに効率的に実行するように改善されているため、少ないトレーニングデータでより早く作業を開始できます。 新しいアラートグループ化プレビューにより、サービスのオーナーはインテリジェントアラートグループ化をアクティブにする前に、潜在的なノイズ低減とグループ化動作を理解することができます。

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