Blog
ブログ

2018年5月1日  (更新日:2022年3月10日)

JIRAクラウドエクステンションガイドを追加しました

JIRAソフトウェアは、組織内のチームコラボレーションを有効にするプロジェクト管理ツールです。 このガイドでは、PagerDutyインシデントからJIRAのイシューを作成できるように、JIRAエクステンションを設定するプロセスについて説明します。

詳しくはこちら

続きを読む
インテグレーション&ガイド
2018年2月23日  (更新日:2022年3月10日)

JIRAサーバエクステンションガイドを追加しました

JIRA Software は、組織内のチーム間のコラボレーションを可能にするプロジェクト管理ツールです。 このガイドは、JIRA サーバで使用する場合のインテグレーションについて述べてい説明します。JIRA Cloudとのインテグレーションは、JIRA Cloud Extension Guideをご覧ください。

詳しくはこちら

続きを読む
インテグレーション&ガイド
2018年7月4日  (更新日:2022年3月10日)

Dead Man’s Snitchインテグレーションガイドを追加しました

Dead Man’s Snitchは、バックアップまたはバッチ処理のようなスケジュールされたタスクが実行されない、または失敗した時に通知する、簡単に構成可能な監視ツールです。 Dead Man’s SnitchとPagerDutyの統合は簡単に実現できます。

詳しくはこちら

続きを読む
インテグレーション&ガイド
2018年7月18日  (更新日:2022年3月10日)

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

IPSentryは、世界中の何千もの情報システム専門家、システム管理者、ITソリューションプロバイダが使用するWindowsベースのネットワーク監視ソフトウェアパッケージです。インターネットとイントラネットのサーバー、ルーター、モデム、データベース、サービス、イベントログなどを1日24時間連続して監視する強力なネットワーク管理ツールで、ネットワークとデバイスが適切に機能していることを保証します。問題が検出された場合は、できるだけ早く原因を知るために、さまざまなアラート、通知、およびアクションをトリガーすることができます。

詳しくはこちら

続きを読む
インテグレーション&ガイド
2020年7月20日  (更新日:2022年3月10日)

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

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

頑張らずに賢く働く

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

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

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

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

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

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

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

インシデントの再開

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

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

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

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

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

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

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

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

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

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

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

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

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

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

続きを読む
ベストプラクティス
2020年6月23日  (更新日:2022年3月10日)

PagerDutyとMicrosoft Teamsを使ったリアルタイムChatOps

7500万人以上のアクティブユーザーがいるMicrosoft Teamsは、多くのグローバルビジネスに欠かせない存在であると言っても過言ではありません。さらに、MicrosoftのCEO Satya Nadella氏は最近、Microsoftが5月1日に2億人の会議参加者を記録したことを明らかにしました。Microsoft Teamsの爆発的な成長は、最近のリモートワークの急増と関連していますが、それ以前にも多くの企業は長い間、世界中の人々をつなぐためにTeamsを利用してきました。

ご存知でない方もいらっしゃるかもしれませんが、Microsoft Teamsはコラボレーションハブであり、従業員はチャット、ビデオ会議を介した接続、SharePoint、Word、PowerPoint、Excelなどの一般的なMicrosoftツールを介したコラボレーションをすべてリアルタイムで行うことができます。これらのMicrosoftツールを使用してコラボレーションする機能は、PagerDutyのユーザーがChatOpsを駆動するためにTeamsを使用する主な理由の1つです。

PagerDutyのユーザーは、会社全体でリアルタイムのオペレーションを推進するために、Microsoft Teamsとのインテグレーションを使用することができます。チームが PagerDuty のデジタルオペレーションのためのプラットフォームと Microsoft Teams のコラボレーションハブを組み合わせると、強力な ChatOps 機能を備えた真のリアルタイムオペレーションを可能にするテクノロジースタックになります。

どこにいても仕事ができる

多くのPagerDutyユーザーにとって、Microsoft Teamsは我々のプラットフォームの第3のインターフェイスとなり、ユーザーはデスクトップやモバイルのインターフェイスと同じようにリアルタイムの操作を行うことができるようになります。

PagerDutyのインテグレーションにより、Microsoft Teamsのインターフェイスから重要なインシデントの詳細を表示することができますが、それはほんの始まりに過ぎません。ユーザーはTeams内で重要なインシデントアクションを実行することもできます。これには、インシデントの受任と解決、メモの追加、さらにはTeams内で直接新しいインシデントをトリガーすることも含まれます。また、サービスをTeamsのチャンネルに直接接続して、全員が同期してつながりを保つこともできます。

PagerDutyとMicrosoft TeamsでHybridOpsを強化する

今日の組織は、エンジニアリング、DevOps、IT運用、カスタマーサービス、マーケティングなど、様々な機能を持つチームで構成されています。PagerDutyユーザーがMicrosoft Teamsインテグレーションを使用している場合、日常業務の間も、何か問題が発生したときも、共有データを使用することでチームが連携して作業を続けることができます。あなたがどのようなチームにいても、PagerDutyは、それぞれの担当者とチャネルを正しいインシデント解決プロセスとワークフローに接続することができます。ユーザーは、運用モデルや機能に関係なく、共通のメトリクスを使用して、業務を段階的かつ継続的に改善することができます。

Microsoft Teamsでデータと人をつなぐ

分散化したチームでは、各個人がどこにいても重要なドキュメントにアクセスする必要がありますが、Microsoft Teamsでは、リモートオフィスを含むどこにいてもコラボレーションが可能です。Microsoft Teamsでは、Word文書やPowerPoint、Excelファイルへのアクセス、共有、編集が可能です。これにビデオ会議やチャット機能を組み合わせることで、Teamsのユーザーは自分に最適な方法でコラボレーションを行うことができます。

TeamsのワンストップコラボレーションプラットフォームをPagerDutyに接続すると、最適なデータセットとインシデントコンテキストを使用して、リアルタイムでインシデントに対応できるようになります。

Teamsからのインシデント受任、解決、メモ

PagerDutyのお客様の中で、すでにTeamsを利用している方と話をした結果、ユーザーがアプリ間の切り替えをしないようにすることが、私たちが提供できる最も求められている機能の1つであることは明らかでした。私たちは、このような「今いる場所で仕事をする」機能を新しいインテグレーションで実現しました。

インシデントが発生したとき、対応者はほとんどの場合、何かの最中です。その「何か」とは、ほとんどの場合チームメンバーとMicrosoft Teamsによるコミュニケーションです。PagerDuty for Teams とのインテグレーションにより、ユーザーは PagerDuty で何もしなくても、Teams UI から直接インシデントを受任したり、解決したりすることができます。すべてが同期されます。また、Teams からその場でメモを追加して、全員が最新の情報を入手できるようにすることもできます。

簡単設定でフレキシブル

PagerDuty for Microsoft Teams を使い始めるのは簡単で、Microsoft Teams 用の PagerDuty アプリは、Microsoft Teams マーケットプレイスのアプリストアからインストールできます。一度インストールしてしまえば、PagerDuty サービスを Teams のチャンネルに簡単に接続することができ、各ユーザーとチームのつながりを維持することができます。

一度接続すると、PagerDutyの設定ページにはPagerDutyとTeamsの接続が表示され、ニーズの変化に合わせて簡単に接続したり外したりすることができます。さらに、アプリのコマンドを使って簡単に Teams チャネルにサービスを接続できます。

PagerDuty for Microsoft Teamsを使い始める準備はできていますか? Microsoft ストアで探してください。また、インテグレーションについての詳細はこちらをご覧ください。

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

続きを読む
インテグレーション&ガイド
2018年4月25日  (更新日:2022年3月10日)    |    DevOps

HybridOpsとは?

CentralOpsとDevOpsの融合であるHybridOpsがエンタープライズの世界で盛り上がっています。昔から大企業には、 重大インシデント対応の中心的役割を果たすオペレーションセンター(サービスオペレーションセンター、テクニカルオペレーションセンター、ネットワークオペレーションセンター。略称SOC、TOC、 NOC )がありました。

これは長年にわたり実行可能なアプローチでしたが、DevOpsにより従来のCentralOpsモードのオペレーションが、開発と運用の両方のスキルを持つ開発者の新しい波と相反し始めました。さらに、CentralOpsとDevOpsを融合する必要があることを認識する企業が増えてきており、デジタルトランスフォーメーションを成功させるための仕組みを整えることがますます重要になっています。

協調戦略の重要性

HybridOpsに移行する際の課題の1つは、IT運用における最も重要な資産=人のインパクトを評価することです。

最近まで、IT Operations(ITOps)の監視対象は、常にサーバやアプリケーション、サービスに集中してきました。欠落していたのは、ITOpsのアラートが及ぼすオンコール担当者とその家族に対する影響を評価する能力でした。

たとえば、新しいサービスのデプロイや既存サービスのアップデートのために、オンコール担当者が夜間に何度も起こされた場合、担当者の欠員やバーンアウトのリスクが高くなります。現在、企業はデジタルトランスフォーメーション(HybridOpsへの移行など)を成功させるために必要とするリソースのわずか19%しか持っていないことを考慮すると、従業員の減少は大きな問題です。

さらに、うまく調整された移行戦略がなければ、サイロ化の可能性は非常に高まります。たとえば、NOC、SOC、TOCの集中管理に不満を感じているDevOpsチームは、 AWS EC2とDatadogを導入し、インフラストラクチャの管理と監視を独自にすることができます 。しかし、このアプローチの欠点は、いくつかの点で明らかです。

企業環境では、そのチームがサポートしているインフラストラクチャの問題が非常に目立つようになります。

大規模なインシデントが発生した場合、 経営幹部チームなどのビジネス関係者は、通常、復旧に関する最新情報をNOCに問い合わせます。上記のようなサイロ化した組織では、インフラストラクチャはNOCには見えず、NOCは関連するアップデートを提供できないため、解決までの時間が遅くなる可能性があります。

HybridOpsをうまく実装し、サイロ化を排除し、NOCチームとDevOpsチームの間で負荷を分担する合理的なシステムを採用する組織と比べてみましょう。このシナリオでは、NOCはアラートを適切なDevOpsチームにルーティングし、チームは得意とするインシデントの処理ができます。NOCは、インシデントが複数のチームにまたがってカスケード接続されているかどうかを把握し、ビジネス関係者への情報を更新し、DevOpsチームはインシデントの修復にエネルギーを集中することができます。 結果として、アラート、インシデント、インシデント解決の流れが劇的に改善されます。

オペレーションヘルスマネージメントサービス

いかなるITOpsオペレーションモデルも、それを選択して実装するのは、特に企業環境においては恐ろしく複雑なことです。問題の深さを理解し、必要な機能を開発したベンダーが提供するツールと監視ソリューションを利用しなければ、デジタルトランスフォーメーションのリスクははるかに大きくなります。

PagerDutyのオペレーションヘルスマネージメントサービスは、ITOpsの人々の健康と福利に関する監視を提供する業界初のサービスです。ビジネスリーダーとテクニカルリーダーは、人々の健康を重視した運用インフラストラクチャと改善のための具体的な推奨事項を深く理解しています。このサービスを使用して、これらの推奨事項を実装した企業は真のHybridOpsを達成することにより、従業員の幸福度、定着率が高まり、デジタルサービスのスムーズな提供が可能になります。

本記事は米国PagerDuty社のサイトで公開されているインテグレーションガイドをそのまま日本語に翻訳したものです。日本語環境での動作を保証するわけではありません。原文はこちらを参照してください。

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

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

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

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

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

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

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

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

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

以上でおしまいです!

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

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

2017年12月28日  (更新日:2022年3月10日)    |    インシデント&アラート

Twitterはコールセンターをなくす

インシデント管理における外部メディアの重要性

インシデント管理について偏狭な考え方に陥るのは簡単です。私たちは何カ月も問題を警告するシステムの設計と構築を行い、我々がキャッチできなかった問題を発見するために顧客サポートのチャネルも構築しました。この考え方は間違っていませんが、このアプローチではなく、TwitterやFacebookなどのSNSで問題を報告するユーザーが増えています。

新たな道を歩むソーシャルメディア

ソーシャルメディアは、企業がカジュアルな雰囲気でユーザーと直接つながる素晴らしい手段として、より密接な双方向コミュニケーションの扉を開いています。ソーシャルメディアは個人が企業とコミュニケーションをとるだけでなく、より効果的な方法でユーザーサポートを得ることもできます。

一般的に、ユーザーが電話やサポートチケットなどの伝統的なルートでサポートを得ることができない場合、ツイートで不満を述べるとすぐに答えがが得られることがあります。SNSは苦情を訴える手段だけではありません。多くのユーザーは、ソーシャルメディアを企業とのコミュニケーションに使用するのが好きです。

私も何度かツイートしたことがあります。

彼らのサイトは500のエラーを発生させている?

素敵なJavaScriptはある?

開発者として私が気づいていないかもしれない問題を指摘していただければ幸いです。「何かを見つけたら話す」です。

同期 vs. 非同期

ソーシャルメディアによるサポートの「報告」の側面は強力ですが、他にもより大きな利点があります。ソーシャルメディア(特にTwitter)は、「リアルタイム」を感じさせるからです。

たとえば、電子メールは非同期通信メディアであり、顧客サポートの手順では受けた質問はキューに追加されます。そこに緊急感はありません。一方、Twitterにはより同期的なフローがあります。電話やライブチャットのようなリアルタイムのサポートチャネルではありませんが、回答する時間が公に記録されているため、電子メールよりも緊急性があります。フィードバックは直接的かつ個別的なもので、あなたの問題を他と同様に重要なものと感じさせます。

干し草の山から針を探し出す

それでは、インシデント管理以外の質問に埋もれることなく、うまくやるにはどうすればいいのでしょうか。この問題の解決策はサポートチャネルと同じで、判定と引き継ぎです。

判定

ソーシャルメディアは顧客サービスのためだけに使用されるわけではないため、ユーザーサポート以外の書き込みで混雑することもあります。バグレポートをそれ以外から物理的に隔離することが重要です。単純にバグを非バグから隔離するだけでなく、レポート間の共通点を特定することも重要です。これによりパターンを検出し、問題が手に負えなくなりそうならばその前にエスカレーションすることもできます。たとえばコマンドコンソールは、ツイートなどのデータソースをインフラストラクチャ内の特定のイベントに関連付けたり、影響の範囲を視覚化したりすることができます。こうして、ソーシャルメディアへの反応からデプロイの失敗や停止が顧客に影響をもたらしたかどうかや、影響の程度を理解することができます。

引き継ぎ

問題が特定され、グループの他の部分から隔離されたら、適切な人やチームを割り当てる必要があります。これは、既存のヘルプデスクアプリケーションにレポートを転送するだけでなく、専用のソーシャルメディアサポートアプリケーションを使用して、多種多様な方法で実行できます。

ソーシャルメディアプラットフォームは、マーケティング部門だけが利用するものではなく、インフラストラクチャ内の問題に関するリアルタイムの情報を得る優れた方法であり、今日のデジタル世界では完全な可視性を提供するために不可欠なデータソースです。これらのプラットフォームに従来のサポートチャネルと同じレベルのプロセスと労力をかけることで、問題がより深刻なものになった後ではなく、最初のレポートが到着してすぐのインシデント対応が可能になります。

コールセンターが不要というわけではありませんが、顧客満足度をを確保するためには、ソーシャルメディアを介して入手可能な豊富な顧客データを積極的に活用しなくてはなりません。監視とインシデント管理戦略の重要な要素として、ソーシャルメディアはユーザーエクスペリエンスの質をより深く把握し、顧客のロイヤリティを向上させるための重要な要素です。

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

「インシデントコマンダー」に求められるトップスキルとは―養成のプロセスを考える

組織は、オンコール の負担を下げつつ顧客に高いレベルのサービスを提供するために多くのインシデント対応の司令官( 「インシデントコマンダー」)を必要とします。多くの人は上級の技術者(シニアテクニカルリード)だけがその役を担えると思っているので、インシデントコマンダーになりたがりません。しかし、実際には「ソフトスキル」のほうが重要であり、この記事で説明されているような明確なプロセスで、チームは障害対応を主導し調整を成功させる人員を養成できます。*

私はエンジニアではなく、PagerDutyのスクラムマスター(チームのまとめ役)です。私は最近インシデントコマンダーになりました。インシデントコマンダーとして働くには上級の技術者である必要はないということを最初に学びました。*

インシデントコマンダーには誰でもなれる

効果的なインシデント対応には、インシデントコマンダーが意思決定者として機能し、明確に調整をする必要があります。ユニークなスキルが求められる厳しい職務です。インシデントはいつでも発生するので、オンコールの負荷を軽減し、燃え尽きるのを回避するのに十分な数のインシデントコマンダーが必要です。したがって、インシデントコマンダーを養成するプロセスを開発することが重要です。

インシデントコマンダーにとって、組織のサービスが相互にどのようにやり取りしているかという知識は重要ですが、インシデント対応をリードするために高度な技術を備えている必要はありません。インシデントコマンダーは、技術的な回復や調査作業自体は自分では行わず、キーになるソフトスキルを駆使してインシデント対応をコーディネートするのに注力することが重要です。インシデントコマンダーは、ベストな対策を決めるために、今明らかになっている症状と対策案を積極的に聞き取る必要があります。自分が選ぶアプローチには技術的な知識によるバイアスをかけないようにしなければなりません。

インシデントコマンダーには職位や技術的な専門知識に関係なく、誰でもなれます。PagerDutyのインシデント対応マニュアルは、独自のプロセスを形式化するための素晴らしい出発点ですが、座学だけでは新しいインシデントコマンダーを完璧には訓練できません。適切な訓練には実践的な練習が必要です。PagerDutyでは、主要なインシデント対応を導く上で、ほとんどのジュニアチームのメンバーでも快適にサポートできるトレーニングプログラムを開発しました。

主な教育内容

プロセス**:インシデント対応プロセスは、発生した問題を迅速に解決し、SLAの範囲内でシステムを継続稼働させるのに役立ちます。これは明確な役割とコミュニケーションルールを持つ構造化されたプロセスです。優れたインシデントコマンダーは、プロセスに精通しており、混沌とした状況も整理できます。

指示伝達**:インシデントコマンダーは、指示伝達に慣れていなければなりません。タスクを委せるのがあなたの責任なので、職位に関係なく、何をすべきかを相手に伝えることを恐れてはなりません。

時間管理**:インシデント対応中は、時間設定が重要です。タスクを委任するときには、指示を更新するためにいつチェックするかを相手に伝えます。変化する情報に追随したいなら、オンコール中であっても全員への定期的な指示更新のリズムを維持し続けるべきです。

聴取**:体制と方向性は重要ですが、エキスパートのフィードバックに耳を傾け即断即決で計画を変更することも必要です。オンコールに携わる全員からも情報と提案受けられるようにします。あらゆる提案を聞いて、あなたが最終決定をします。

これらを明文化し、プロセス、指示伝達、時間管理、 および聴取をどのように実践するかを正確に話しましょう

当社のインシデントコマンダーは、インシデント対応に関心のある全従業員に対して、営業時間中、常に問い合わせを受け付けています。訓練開始を決めたインシデントコマンダーのタマゴたちはその間に質問をし、プロセスについて学べます。これは、たくさんのインシデントコマンダーが必要な理由を説明する機会であり、みんなが試しにやってみて学ぶのを助ける機会です。

インシデント対応の準備のためにスタッフを訓練する方法を知りたい場合は、次の無料のウェビナーに登録してください。

Introduction to Being an Incident Commander インシデントコマンダーの紹介(英語)

Introduction to Being an Incident Responder インシデントレスポンダの概要(英語)

私たちは就業時間内にプロセスをキックスタートした後、インシデントコマンダーのシャドウスケジュールに訓練生を送り込みます。インシデントコマンダーのやることをシャドウすることで、訓練生は実際にオンコールをしているような気分を味わえます。また、インシデントコマンダーが呼び出されるたびに、一緒に起こされたり自分の仕事を中断されたりします。訓練生はシャドーイングの間にインシデントのコールに加わります。研修生は、「沈黙の観察者」のままにしておいて、最後まで質問をさせずにおくことが重要です。インシデントコマンダーは、事が終わってから訓練生の質問に答える時間を取って、彼らの学習を助け、満足度を高め、コミュニティにサポートされていると感じられるよう計らいます。

研修生がいくつかのコールを聞いた後は、進行中のインシデントのタイムラインを文書化して、スクライブ(記録者) として手伝うように勧めます。より長いインシデントでは、頻繁な引き継ぎが効果的な対応を維持し、燃え尽きを避けるために大きな違いを生むことがわかっています。記録者として参加することはインシデントコマンダー候補がその準備が整う前に手助けを始めるには非常に良い方法です。このようにインシデント対応に取り組むことで、訓練生はプロセスにさらに精通し、自信を高めるのに役立ちます。

いくつかのインシデントコールを聞いて手助けをした後、訓練生には勇気を出してメインスケジュールに入るように促します。彼らは、バックアップインシデントコマンダーのサポートでコールをリードする、リバースシャドウをすることができます。バックアップが対応の全過程で役に立つということを訓練生に理解させてください。新たなインシデントコマンダーにコールを担当させることが重要で、そうすれば彼らは信頼を得られ、さらに自信を深められます。ヒントやリマインダー、励ましなどを添えて個人としてメッセージを送ってください。

新しいインシデントコマンダーが最初のインシデント対応をうまくリードした後は祝ってあげてください。効果的なインシデント対応を導くことは、お客様のビジネスの成功と顧客の幸福に直接影響し、チームの士気を維持するうえでも重要です。互いをサポートし合うインシデント対応者のコミュニティを作ることで、より多くのインシデントコマンダーを育てることができ、オンコールの負荷を減らせるようになります。

オンデマンドのウェブセミナーを使い、インシデントコマンドとインシデントレスポンダのトレーニングを開始してください。

インシデント・コマンダー・トレーニング:主要インシデント時の対応

Incident Commander Training: Leading the Response During Major Incidents

インシデントレスポンダトレーニング:重大インシデント時の成功のベストプラクティス

Incident Commander Training: Leading the Response During Major Incidents

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

セキュリティスタックに入れておくべき6つの必須ツール

最新のセキュリティ監視:どのツールをスタックに入れておくべきか*

クラウドネイティブまたはコンテナ化されたアプリケーションを管理する際には、セキュリティ監視に関するアプローチを完全に変える必要があります。このような複雑な環境では、従来のツールを使ってセキュリティインシデントを迅速にトラブルシュートし解決するのは無理だからです。

これを念頭においてみると、クラウドベースまたはコンテナ化された環境で効果的なセキュリティ監視を行うのに役立つツールがいくつかあります。

コンテナ監視ツール

イメージスキャンツール:コンテナイメージはDockerのセキュリティの中心です。誰でもアクセスできる公開されたイメージはシステムに脆弱性をもたらす可能性があり、使用する全コンテナイメージを検証することが不可欠です。Docker Hubは、基本的なイメージスキャン機能を提供します。プロセスをより詳細に制御するには、ファイアウォールの背後でも機能するDock(Docker Trusted Registry)を選択することができます。さらに、QuayやGitLab Container Registryのような多くのサードパーティのイメージスキャナがあります。どのイメージスキャニングツールを選択するにしても、スタック内で許可されているイメージの種類を厳重に守ることが重要です。できるだけ公式のリポジトリを選択し、未確認のイメージを使用する必要がある場合は、常に完全にスキャンされていることを確認してください。

エンドツーエンドのコンテナ監視ツール:これらのツールはイメージをスキャンするだけでなく、カーネル、ネットワーク、オーケストレーションツール、アクセスコントロールなど、Dockerスタックのすべてのレイヤーを保護します。Twistlockのようなツールは、全面的にコンテナセキュリティツールと統合し、コンテナの監視を1カ所でできるように​​します。

クラウド監視ツール

Threatstack、Signal Sciences、Evident.ioなどのツールは、Webアプリケーションやクラウド環境全体で侵入検知とセキュリティ監視を強化するソリューションです。これらのツールは、パブリッククラウド環境の急速な変化に対応し、可視性を提供すると同時にコンプライアンス要件を満たすのを助けてくれるのでリスクを軽減するのに役立ちます。

オープンソースの監視ツール

オープンソースの監視ツールは、あらゆる監視スイートの大事な要素です。それらの機能は、クラウドネイティブアプリケーション用に専用に設計されており、活気にあふれた開発者コミュニティが持続しています。

Calicoはコンテナのネットワークセキュリティツールです。ネットワーク全体に1つのファイアウォールを提供するのではなく、Calicoは各インスタンスを1つのファイアウォールで保護します。このようにして、1つのサービスやポッドが侵害された場合でも、他のサービスやポッドは安全に保たれます。Calicoでは、ポリシーを使用してネットワークセキュリティを定義できます。サービスにアクセスするだけで、タスクを完了できるようになり、そのアクセスを取り消すことができます。

ELKスタック(ELKスタックとはElasticsearch社のElasticsearch(解析) + Logstash(収集) + Kibana(可視化)の3つの製品の総称)は、ログ解析ソリューションとして説明の必要はありません。スタックのデータベースコンポーネントであるElasticsearchは、ログデータの分散ストレージと分析を提供します。シャード(注)用の自動フェイルオーバーとクエリの並列処理により、ELKスタックは規模に合わせて構築されます。使用量を増やすと、ELKスタックを維持するのが難しくなるかもしれませんが、ベンダーがスタックのメンテナンスを担当してあなたが自システムのロギングに集中できるように、ELK用のマネージドサービスを選ぶことができます。

(注:DBのインデックスは、単一ノードのハードウェア制限を超える大量のデータを格納しなければならない場合があります。その問題を解決するために、Elasticsearchは、複数の部分にインデックスを分割でき、これをシャードと呼んでます。)

Prometheusは今日最もホットなオープンソースの監視ツールの1つです。これは主にKubernetesとの深い統合によるものです。これは、ポッド、サービス、コンテナ、ノードなどのKubernetesコンポーネントを自動的に検出します。アラートと通知の基本的な管理を行うアラートマネージャが含まれています。高度なアラート管理とレスポンスオーケストレーションのために、PagerDutyのようなプラットフォームと統合されています。

ログ分析ツール

ELKスタックを独自に管理するのは面倒な作業です。特に、ノードの限界に達するとシャーディングがスムーズに行われるようにするのは手間がかかります。この場合、SplunkやSumo Logicのようなクラウドベースのログ解析ソリューションが必要かもしれません。これらのソリューションは、機械学習を活用してログデータから予測に役立つ洞察を収集します。また、他の監視ツールとの統合も容易です。

インシデント管理ツール

スタックが複雑であると、すべてのコンポーネントに関するレポートデータが常に流れ込んできます。これは圧倒的な量になり、ノイズの中の重要なアラートを見落とす原因となります。PagerDutyのようなインシデント管理ソリューションで、他のすべてのセキュリティ監視ツールを補完することが不可欠です。

PagerDutyは、様々な監視ツールと統合し、すべてのメトリックを1カ所に統合します。パワフルな自動化ルールを適用して誤検知を減らし、適切な人に注意が必要なイベントが通知されるようにします。インシデントの最中は、適切な人物を即座にスタックの状況に関与させる必要があります。これがPagerDutyによって実現されます。

ChatOpsツール

火消しに注力している状況では、他の人と協力する必要があります。これまでは電子メールやチケット管理システムを使っていたでしょうが、今日ではSlack、HipChat、Flockなどのコミュニケーションツールがチームコラボレーションを促進します。また、チャットボットがマシンが生成したデータをチャットインターフェースで伝えます。PagerDutyとSlackなどとの統合により、ChatOpsインターフェイスとインシデント管理ソリューション全体でアクションを同期させ、インシデントをより迅速に共同作業し解決することができます。

クラウドネイティブのアプリケーションを保護する際には、DevSecOpsとインシデントのライフサイクルに関する最良のアプローチを採用してください。多くのツールはユニークな機能を提供しますが、選択したツールが他のツールともうまく機能することを確認してください。問題を検出する際に最大の馬力を発揮できるだけでなく、最も重要なときに指先で適切なデータを取得できるようになります。

2020年6月16日  (更新日:2022年3月10日)    |    インテグレーション&ガイド

Jira ServerとJira Data Centerとのインテグレーションでリモートワーク

このブログを読んでいる人の多くは、自宅、どこかのリモートオフィス、家族の家、あるいはZoomの背景が本物ならば宇宙船ミレニアム・ファルコンのコックピットから読んでいるかもしれません。私たちは皆、上手に「今いる場所で仕事する」方法を学ぼうとしていますが、それには毎日使うツールスタックを最適化することも含まれます。Atlassian の Jira Server と Data Center 製品を利用している PagerDuty ユーザーのために、我々はユーザーがリアルタイムで仕事をし「今の場所で仕事をする」ことができるように、いくつかの変更を行いました。

Jira Server と Jira Data Center との強化されたインテグレーション機能を一般公開します。このインテグレーションには、ユーザーが PagerDuty サイドバーを使用して Jira の課題からインシデント対応を調整できるようにする機能が含まれています。また、複雑なワークフローを持つチーム間の同期とコラボレーションを推進し、PagerDuty と Jira Server と Data Center 間でユーザーとアカウントをマッピングすることができます。最も人気のある PagerDuty 統合の1つとして、ユーザーの皆様からのフィードバックに基づいて開発された新機能です。

もちろん、これらの機能を表示しないようにしたい場合は、非表示にすることもできます。

高度なワークフロールールを使用してJira でより多くのことを自動化する

デジタルビジネスを成功させるためには、デジタルサービスが完璧に稼働していなければなりません。PagerDuty のリアルタイムオペレーションプラットフォームは、主要なワークフローを自動化することで、ダウンタイムの削減を実現します。PagerDuty は、これらの高度なワークフローを Jira とのインテグレーションに追加しました。Jira ServerとData Centerのお客様は、複雑なワークフローを動かす高度なルール設定を Jira インターフェイスから使用できるようになりました。Jira ユーザーは、ビジネスを実行するために必要な正確なワークフローを使って、リアルタイムのオペレーションを推進することができます。

双方向ユーザーマッピング

フィードバックに基づいて、ユーザーマッピングも追加したので、Jira と PagerDuty のアカウントをリンクして、チームメンバーがどのようにインシデントに対応したかを完全に把握することができるようになりました。ユーザーマッピングでは、PagerDuty のきめ細かいパーミッションを PagerDuty アプリで使用することができます。また、すべての変更が毎回リアルタイムで行われるように、フォールバックユーザーとのミスコミュニケーションを防ぐことができます。

マルチアカウントサポート

チームが成長し、高度に分散化するにつれ、Jira ユーザーを個別のアカウントに対応させることが現実的な問題となります。チームと対応者が全員同じページにいて、漏れがないようにするために、複数の Jira インスタンスを PagerDuty にマップする機能を追加しました。また、複数の PagerDuty アカウントを Jira にマッピングすることもできます。最新のインテグレーションにより、あなたのエンタープライズビジネスは生産性を妨げることなく、グローバルに拡大する準備ができています。

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

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

インシデント管理データで技術的負債を測る

技術的負債(technical debt)が借金のようなものだったら、手作業でチェックインしない限り、それを追跡するのは難しいでしょう。 多くの人にとっては自分の当座預金口座に資金がなくなったことを知る唯一の方法は、口座の残高を確認することです。さらに悪くなると、小切手が返されたり、デビットカードが拒否されます。

しかし、技術的負債の測定はもっと自動化できます。 これは、お客様の銀行口座とは違って、ITインフラストラクチャの場合はそれを専用のツールで継続的に監視でき、重要なヘルスメトリックについて通知を受けることができるからです。 次に、監視データを使い技術的負債についての情報を得ることができます。 つまり、データセンターで問題が発生したときに手動で監査する必要はありません。 問題があることを知るのに、サーバーがダウンするまで待つ必要はありません。 インシデント管理ツールは、その情報を提供します。 エクステンションを使えば手作業で面倒なことを測定することなく、技術的負債を取り込む方法も提供しています。

インシデント管理は、技術的負債を追跡して修正するのに役立ちます。追加の投資は必要ありません。

技術的負債の定義

まず、技術的負債の意味を説明しましょう。 技術的負債とは、長期的には非効率性やその他の問題を引き起こすような、ソフトウェアコードやアーキテクチャの不完全性を指します。 たとえ欠陥自体が小さいとしても、その効果が継続的に繰り返されるため、時間の経過とともに多くの利子が生じることがあります。

例えば、モジュラーアプローチを採用しておらず、同じ機能の複数のバージョンをコードに含むようなプログラムは、より優れたプログラムよりも実行に数ミリ秒余計にかかることがあります。 一度だけそれを実行するなら、大きな問題にはなりません。 しかし、それがサーバーの側で1日に数千回実行されるWebアプリケーションであれば、パフォーマンスが低下したり、CPU時間が浪費されたりするという負債があっという間に積み上がります。

技術的負債には多くの潜在的な原因(訳注:クリックすると英語版のWikiに飛びます)があります。 場合によっては、例えば何かを迅速に導入しなければならず、ベストプラクティスに従う時間がない場合は、負債がコストに見合う価値があると判断(少なくともその時点で)して、技術的負債を意図的に負うことがあります。管理者の中で最も優れた人でも将来の技術的負債を避けることは難しいです。 将来を見通せない限りは(例えば、あなたがアップグレードする余裕がないために今日も使用している10年前のスイッチが、最新のファイアウォールツールではうまく機能しないということは過去の時点では分からなかったはずです)。 その場合、技術的負債は、不完全な世界での生活で起きることまったく同じ経緯をたどります。

技術的負債を追跡する

技術的負債には多くの源がありますが、それをインシデント管理を使用して測定するというアプローチは、問題の原因を問わず問題の追跡を容易にします。繰り返しますが、時間のかかる手動のシステム監査で非効率性を検索する代わりに、インシデント管理データを技術的な負債の程度を評価し、それを評価するためのプロキシとして活用できます。

やり方を理解するために、PagerDutyが追跡するさまざまな種類のインシデント管理データの例と、それらのデータが技術的負債について明らかにできることをいくつか見てみましょう。

まず、ツールが生成するアラートの生の数を取得します。これは非常に基本的な指標であり、さまざまな要因によって影響を受ける可能性があります。しかし、インシデント管理の報告システムが適切に構成されており、インフラストラクチャに大きな変更を加えなくてよいと仮定すると、技術的負債の規模とツールが報告するインシデントの数との間に相関が見られる可能性があります。負債が増えるとパフォーマンスが低下し、応答時間やリソースレベルが特定のしきい値に達するとアラートがトリガーされるためです。したがってアラートの発生率が月ごとに減っていれば、コードがより効率的になったので技術的負債が減っている可能性があります。

平均解決時間(MTTR)は、技術的負債を見るためのインシデント管理の指標です。MTTRが悪い一般的な原因の1つは、コードがあまりにも複雑すぎることです。例えば、上の例を再利用するために、急いで書かれたコードには冗長な機能が含まれているため、管理者にはすぐに理解するのが難しいでしょう。これは、事件に対応するためにコードを読み込んで変更する必要がある場合に、解決時間が長くなることを意味します。

技術的負債の源を見つける

インシデント管理データは、技術的な負債に関する一般的な傾向を追跡するのに役立つだけでなく、問題の原因をゼロにするのにも便利です。

たとえば、特定のプログラムに関連するインシデントのMTTRが平均MTTRよりも高い場合、問題のプログラムが技術的な負債を生成している可能性があります。同様に、あるタイプのオペレーティングシステムを実行しているサーバーが不均衡なアラート数の大部分を占めている場合、おそらくコードまたは構成上の欠陥があります。それはあなたが対処できる技術的な負債です。

インシデント管理データを使って技術的負債を特定し、対処するのはとてもクールで、ほとんど追加作業を必要としません。あなたは既にPagerDutyのような操作と報告を集中化するハブ(うまく設定すればですが)を備えた監視システムを備えています。これらのリソースを活用して技術的負債を見つけて修正するには、追加のツールや投資を必要としません。既存のソフトウェアを使用して、コードや操作をより効率的にすることができます。

2019年1月24日  (更新日:2022年3月10日)    |    インテグレーション&ガイド

リアル(タイム)になりつつあるSecOps

AWS Security HubとPagerDutyがリアルタイムオペレーションを強化

クラウドに移行する企業は、強力なセキュリティ体制を維持し、コンプライアンス要件を満たすことができるようにする必要があります。コンプライアンスを確実にすることに加えて、企業はまた、異なるインターフェースおよびプラットフォームにわたって大量のイベントデータを生成する複数のセキュリティツールを結びつけるという課題に直面しています。この課題に対処するために、AWS re:Invent 2018で AWS Security Hubに新しいセキュリティサービスが発表されました。

AWS Security Hubとは?

Security Hubは、 Amazon GuardDuty 、Amazon Macie、Amazon InspectorなどのAWSセキュリティサービスからのイベントデータを1画面に表示します。さらに、Security Hubを使うと、AWSは多数のサードパーティ製セキュリティツールをプラグインして、好みのファイアウォールまたはエンドポイントソリューションを引き続き使用し、AWSネイティブサービスと一緒に表示するために、Security Hubにイベントデータを送信できるようにします。

AWSセキュリティハブ+PagerDuty

また、Security Hubはコンプライアンスチェックを実行し、潜在的な問題を防ぐためチームが迅速に行動できるようにカスタムアクションを作成するのに役立ちます。Security Hub内での対応および修復プロセスの一環としてPagerDutyとのインテグレーションを使用すると、各組織はCloudWatchイベントを介したGuardDuty検索ルールをPagerDutyに送信するカスタムアクションをすばやく設定できます。

Security Hub設定内でカスタムアクションを設定するのは非常に簡単です。これにより、チームはAWSまたはサードパーティのセキュリティツールから特定されたセキュリティ問題を選択し、すぐにPagerDuty内にインシデントを作成して適切な開発チームとセキュリティチームに通知し、彼らは共同で調査と対応に当たれます。

Security Hubとの新しいインテグレーションに伴い、当社もre:Invent 2018でいくつかの新しい AWS Integrationsを発表しました。

もっと知りたいですか? 14日間の無料トライアルを提供しています。組織にPagerDutyを採用する準備はできましたか? それならば AWSマーケットプレースでも購入できます。(訳注:Digital StacksでPagerDutyを契約するメリットについてもご覧ください)

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

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

OverOps統合ガイドを追加しました。

OverOpsを使用すると、開発中にコードブレークがいつ、なぜ発生したのかを知ることができます。プロダクションJVMでの、完全なアプリケーションコールスタック、ソースコード、キャッチ/キャッチされなかった例外、ログに記録されたエラーやワーニングを参照できます。

詳しくはこちら

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

PagerDuty + Atlassian:モダンインシデント対応を前進させる新しいエクステンション

「常時稼働・即時対応」の顧客の要求と期待の高まりに応えるため、デジタルオペレーションは人々の仕事の仕方を変えつつあります。 また、最も興味深いマクロなトレンドの1つは、IT運用チームと開発チームだけでなく、ビジネス全体がどのように顧客への対応力をレベルアップさせるよう注力しているかを見ています。 良いにつけ悪いにつけインシデント対応は、時間の制約のある中での組織全体の取り組み(カスタマーサポート、エグゼクティブ、コミュニケーション/マーケティング、セールスなどを含む)で効果的な対応を策定するための非常に良い例になります。重大インシデントはビジネス上の問題であり、製品上の問題ではありません。 現代のインシデント対応には、優れたコミュニケーションとコラボレーションが不可欠です。

Atlassianはこの現実解を与えてくれます。 当社が既に用意しているJIRA、HipChat、およびStatusPageとの深い統合に加えて、 PagerDutyのStride向けエクステンションの一般向けの提供開始をここに発表します。 Strideは完全なチームコミュニケーションソリューションで、何かPagerDutyでのインシデントが発生したときにチーム全体の可視性を向上させるのに最適です。 しかし、最も重要なことは、Strideが、重大インシデントのような危機の時に組織を調整するのに役立つということです。 特に、効果的なインシデント対応を推進するために、Incident Commanders、Deputies、Scribesの優れた機能を提供します。 (Incident Commandに精通していない場合は、 https://response.pagerduty.com/を参照してください )。

Incident CommandのStride機能をご紹介します。

PagerDutyのStrideサイドバーの使い方

PagerDutyはChatOps(GitHubの商標です)の初めに関連していることを誇りに思っていますが、ChatOpsの悪い応用例の1つは、対応中のインシデントの詳細を理解させるために新しいレスポンダーにチャットログ全体を読み上げるよう強制することです。それに対してStrideのサイドバーは、インシデントに関して関連性が一番高い情報のスナップショットを提示しておく場を提供します。インシデントに関連する冗長な会話はルームで行われ、一方でサイドバーのアクティブなインシデントの表示には、インパクト、イベント、重要な決定事項、および実行されたアクションの要約が含まれます。

このタイプの情報はまさにScribeがキャプチャし続ける必要があるものであり、リアルタイムでキャッチアップするためにも、後でタイムラインを編集するためにも最適です。 共通の基礎情報はコミュニケーションの重要な概念であり、インシデント対応にとって特に重要です。インシデント・コマンダーは、共通の基礎情報を維持するために、これらの種類の要約を定期的に(音声でのコールでは口頭で)行うように訓練されています。 スピードを上げるために人々に「チャットログを読め」と強制しないでください! (興味があれば、ExomiteのDan Slimmon氏はVelocity Santa Clara 2016で素晴らしい話をしています。ご覧ください。)

Stride Decisions

効果的なインシデント対応の重要な原則の1つは、すべての意思決定権限がインシデント・コマンダーに与えられることです。 これは、リスクの高い決定が顧客の影響を緩和するために必須な重大インシデントでは特に重要です。 トレーニングで使用する1つの例を示しましょう。ダウンタイムが発生すると同時に全Webサーバーを再起動するのは一般的ではありませんが、既に他の方法ですべての顧客が影響を受けている場合は、再起動が正しい選択かもしれません。

Stride Desicionsは、そのハード・ディシジョンをレスポンスが記述されているときにインラインで簡単に記録できます。 この種の意思決定ポイントの記載は、あなたの対応チームの共通の基礎情報を更新する素晴らしい方法です。 ただ覚えておいてください:あなたは決定を下す権限を持っていますが、あなたは常にあなたの Subject Matter Experts(SMEs)の専門知識を活用すべきです。 あなたは自分の意思決定について承認する必要はありませんが、実行する前に「何か強い反対意見」を求めておくのは、事後の偏った見方を防ぐために常に良い考え方です。

Stride Action

インシデントコマンドが有効な間に、統制のとれた状態を保つのが難しいことがあります。 決定が下されると、いろいろな行動がしばしば続きます。Stride Actionsは、さまざまな調査や実験を追跡し、それによって幅広い顧客への影響を理解し、それが顕在化するまえに緩和する方法を知るために最適です。

この種の機敏を要するアクションについては、次の3つを強く推奨します。

Assign them(担当に割り当てる)、つまり個人名( “Dave Cliffe”)または機能( “Network on-call”)で指定すること。 Time-box them(締め切りを示す)、担当者はより多くの情報を得る余裕がどのくらいあるかを知ることができます(これは緊急性を意識させるためにも役立ちます)。 Receive acknowledgement (誰かが受任したという通知を受け取る)、インシデント・コマンダーは彼らがタスクを理解していることを知っています。

事後検証をないがしろにしないこと

混乱が収まり、顧客への影響が少なくなったとき、インシデント・コマンダーがすべき最後の1つは、事後検証をさせることです。 すべてのインシデントは、学習の機会であることを覚えておいてください。 システムの技術的側面だけでなく、チームのコミュニケーションの仕方を理解することで、今後の対応がさらにうまくいくようになります。だからインシデント対応プロセスを定期的に確認してください。 PagerDutyとJIRAの統合は、レスポンスチームが特定したアクション項目をフォローアップするための素晴らしい方法を提供します。

モダンなインシデント対応には、反復と学習を通じて向上する正確で自動化された共同のレスポンスを可能にしながら、分散型のオーナーシップを取り入れる新しいアプローチが必要です。 PagerDuty StrideエクステンションをJIRAとStatusPageの統合と連携させることで、PagerDutyとAtlassianは効果的なオペレーションのための優れたプラットフォームを提供します。 ぜひ試してみて、あなたの考えをお聞かせください!

その他のリソース:

Strideスタートガイド モダンインシデント対応トレーニング インシデント対応のベストプラクティス

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

2017年12月19日  (更新日:2022年3月10日)    |    インシデント&アラート

余計なアラートを抑制しよう!

インシデント管理におけるノイズ回避

抑制( 注:Suppression )。シソーラスによると、この単語は削除、排除、消滅などの用語と同義語です。

しかし、インシデント管理の文脈の中では、抑制とは全く異なることを意味します。永遠にデータを削除することではありません。そうではなく、騒音を軽減して管理者が適切なタイミングで適切なアラートに注目できるようにする方法として機能します。

ここでは、抑制がインシデント管理を合理化する様子をご紹介します。

抑制が重要な理由

インシデント管理に抑制が役立つのはなぜでしょう。簡単に言えば、現代のインフラストラクチャは大量のアラートを生成するので、管理者は全てのアラートをレビューできないのです。試してみればすぐにアラート疲れすることに気づきます。つまり、アラートの量に圧倒されて燃え尽きてしまい、本当に重要なアラートを無視するようになってしまいます。また、アラートに注意を払うのをやめるとインシデント管理プロセス全体が壊れてしまいます。

アラート抑制はこの問題を回避する方法です。管理者は、特定の種類のアラートを抑制することで、対処可能で優先度の高いアラートを重視するようにできます。また、ダッシュボードに表示されるアラートの総数を減らすことができるので、アラート疲れを防ぐのに役立ちます。

例えば、ワークステーション群が更新プログラムのインストール後に1週間に1回再起動するようになってしまったケースを考えてみましょう。ワークステーションが再起動後にオフラインになってまた復帰するまでの間に一連のアラートが生成されます。管理者が見ているインシデントダッシュボードにこれらを追加すると、ダッシュボードが役に立たなくなってしまうでしょう。それらのアラートは特にアクションを必要としないルーチンの手続き型イベントが起きたことを示すものだからです。この役に立たないノイズを管理者のダッシュボードに表示させないようにするには、管理者はインシデント管理ソフトウェアの設定で、ワークステーションの再起動に関連するアラートを抑制することができます。

抑制はゼロか100かという問題ではありません

アラート抑制を理解するうえで大事なのは、アラートを抑制するというのはゼロか100かを選ぶのではないということです。つまり、管理者のオプションは、特定のタイプのすべてのアラートを有効にするか、またはすべてのアラートを永久に抑制するか、ということではありません。

そうではなく、抑制にはもっと繊細なアプローチをとることができます。特定の期間内に繰り返し発生しない限り、特定の種類のアラートが抑制されるように設定できます。あるアラートを特定の時間帯に発生した場合だけ報告するように設定したり、他の時間帯には抑制するように設定したりすることもできます。同様に、管理者は特定の種類のデバイスで発生した特定の種類のアラートは抑制したいが、他の種類のアラートは抑制したくないという場合があります。

こういう柔軟性はアラートの有効性を最大限に引き出すために重要です。幅広く雑な抑制ポリシーを適用するのではなく適切に調整すれば、インシデント管理システムに不要なノイズを出さず、重要なイベントを最大限に可視化することができます。

上記の例では、繊細な抑制が役に立ちます。私が指摘したように、管理者は普通、ワークステーションがソフトウェア更新後、深夜に再起動したときに出すアラートは受信したくありません。しかし、インシデント管理ソフトウェアが同じ期間に複数回再起動するワークステーションを検出した場合は、管理者が知りたい問題(ソフトウェアの欠陥など)が発生している可能性があります。この状況では、再起動が反復される場合だけセンターのダッシュボードに表示されるインシデントが生成されるように設定すれば、インシデント管理の効果を最適化できます。

抑制はデータの損失を意味しません

インシデント管理の文脈でいう抑制は、抑制されたアラートが永遠に消えることを意味するものではないことを強調しておきます。逆に、抑制されたアラートはまだ発生しますし、それらに関連するデータは保存する必要があります。抑制されたアラートとされていないアラートとの唯一の違いは、前者はインシデント管理システムの優先順位の高いダッシュボードには送信されないということです。

これは管理者が必要に応じて抑制されたアラートを見てインシデントを把握できることを意味します。これにより、アラートのしきい値を調整するのに役立ちます。さらに、抑制されたアラートを過去のインシデント管理データとして見ることで、インフラストラクチャの効率性やシステムの健全性のトレンドに関する多くの貴重な情報を明らかにできます。

抑制されたアラートを活用することで管理者がインシデントの特定と対応に役立てることもできますし、優先順位の高いインシデントを解決するために活用したいダッシュボードを、対処不可能な情報で混乱させることもなくなります。さらに、インフラストラクチャを完全に把握できるように、アラートが適切な状況下でのみ抑制されるようにして、常に報告が続けられるよう微調整することもできます。

2018年8月21日  (更新日:2022年3月10日)    |    ニュース&告知

ノイズを減らすPagerDutyのイベントインテリジェンス機能

私たちがお手伝いしているあらゆる業界と運用モデルで、お客様から、データの海の中から行動に結び付けられるシグナルを見つけるのに苦労しているとよく言われます。 システムとサービスチームは毎年より複雑化し続けていますが、従業員数は同じ速度で増えたり減ったりすることはありません。

これは、テレメトリー(遠隔診断)を実施する組織の量が、もはや既存の方法では管理できなくなったことを意味します。多くの企業は、1日に数千、場合によっては数百万のイベントを処理します。 重大インシデントが発生した場合、レスポンダーは重複したアラートを飛ばすのを防ぐために電話を切る必要があると各組織からよく聞かれます。 これは迷惑で気の毒なことです。特に利害が極端に高い場合は悪化し、実際の問題をすばやく特定することも不可能になります。 また、ビジネスにとっては、解決に時間がかかり、リスクも増大します。

イベント管理からイベントインテリジェンスまで

ノイズを減らすことは、常にPagerDutyの使命の一部となっていて、当社のプラットフォームは、オンコールスケジューリングやエスカレーションを自動化する効果的なコラボレーションとインシデント対応を支援し、サービスを介してこれを達成した報告と洞察力、すべて自分の運命を所有するチームに権限を与える方法で解決できました。

しかし、我々は現在、全ツールとインフラからのシグナルの急増を処理できるスーパーパワーを各チームに与えられるように、新しい製品に注力しています。

イベントインテリジェンスは、すべてのツールからのシグナルを収集し、ノイズを抑制し、実行可能なアラートを相関させ、レスポンダーにその情報を取得させるなど、イベント管理の世界で共通なたくさんの問題に取り組んでいます。 しかし、それはシステムと人間のデータを融合させてノイズを減らし、反応を集中させ、チームに力を与えることによって、新しいユニークな方法で解決を図ります。

インテリジェントアラートグルーピングは簡単な洞察から生まれました。システムからのリッチなデータでできることはたくさんありますが、レスポンダーがデータを処理することも(もしかしたら他のことより)重要です。 インフラがスケールし更新され、チームは予測しなかったやり方でユーザーと対話する新しいサービスを開始するので、従来のコマンドと制御のアプローチでは追いつけません。

しかし、チーム上のユーザーがオペレーション上の問題をどうにやり取りし、その行動から時間をかけて学習するかを知ることで、当社のサービスは、あなたのシステムが成長して変化しても、アラートを効果的に相関させ、ノイズをカットして時間とコストを大幅に節約し、より高いレベル・よりインパクトのある作業にフォーカスできるようにします。

“使えます” –Andrew Percher, Macy’s (訳注:イベントインテリジェンスについての感想)_

アラートがアクション可能なインシデントに関連付けられれば次はレスポンスです。 Similar Incidents機能は、現在のインシデントに関連するインシデント群に対するこれまでのあるアカウントのレスポンス履歴を調べ、データサイエンスを駆使してレスポンダーの指先に正確なコンテキストを届けます。 レスポンダーは、インシデントが日常的に起こっているのか・隠れていた危険なものであるのかを簡単に知ることができ、過去のインシデントのメモやその他のトリアージを助けるメタデータを見られます。 レスポンダーは、集約して表示された過去の運用上の問題のパターンを確認することで、より自信を持ち、より効果的に動けるようになり、最も重要なときに貴重な時間を節約できます。

“Similar incidents の機能は、チームに追加でレスポンダーを配属したようなものです。”-Corey Burke、Dialpad___

その裏で、 Advanced Event Automationはシグナルのフィルタリング、強化、優先順位付けを行い、人々に不必要なアラートを行わないようにします。また、通過するシグナルには 、runbooksや回復のための情報などのすべての適切なコンテキストが含まれます。

我々は昨年のPagerDuty Summitでこれらの機能の多くを紹介し、何百もの早期アクセス顧客から大きなフィードバックを受けました。 彼らは、イベントインテリジェンスが手作業によるトリアージプロセスに取って代わり、レスポンダーの生活の質を向上させ、構成とメンテナンスにかかっていた数え切れない時間を省いたと語っています。 また、これらの機能を使った顧客を調査したところ、シグナルがフィルタリングされ、抑止され、インテリジェントに相関されるため、全体の98%のノイズが削減されています。

今すぐ試してみてください

イベントインテリジェンスをすべてのお客様に提供できます。 まず、PagerDutyの担当者に連絡するか、無料トライアルにサインアップしてください。

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

<  123456789101112  >