Blog
ブログ

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日)

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

続きを読む
DevOps
2017年12月28日  (更新日:2022年3月10日)

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

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

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

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

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

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

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

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

素敵なJavaScriptはある?

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

同期 vs. 非同期

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

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

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

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

判定

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

引き継ぎ

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

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

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

続きを読む
インシデント&アラート
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社のサイトで公開されているものを日本語訳したものです。原文はこちらです。

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

インシデント管理のメトリックでタブを常時オンにする

およそ1年前(注:2016年)、Citiで起きた技術的な問題が原因で数十万枚のカードとATMが同時に使えなくなりました。その結果、Citiが新しく立ち上げたCostco Anywhereカードは、「苦情の洪水」(flood of complaints)を受けました。 インターネットの世界で言えばこれに相当するフレーズは「タイヤ火災」(”tire fire” 、https://en.wikipedia.org/wiki/Tire_fire)です。 Tire fireに発展するインシデントには、通常、リーダーシップからユーザー、サポートデスクまで、組織内の全員が関与します。PRやマーケティングはアラートを出し、外とのコミュニケーションに対処し、技術チームは状況把握に努めます。 これは、SLA(Service Level Agreement)などに則る事後検証を外部向けに書面で用意することを意味します。これらは、しばしば「根本原因」の分析として書かれ、インシデントに関係する人、プロセス、技術を批判し、修正することに焦点を当てています。 技術リーダーは、このような状況では責めを負う以上のことはできません。もちろん、チームは可能な限り早くトリアージをし、サービスを正常に戻すことができます。しかし、インシデントの原因、効果の有効性、および影響を測定する過程では、目標を「根本的原因」にのみ合わせるべきではありません。 「ポイントアンドシュートアプローチ」では、責任を追求し予算を要求します。「ポートフォリオアプローチ」は、現在の投資がどのような結果を返したか、再配分がその結果をどのように変えうるかを示しています。これは、組織の他のメンバーがDevOps、サポート、サービスにどの割合で投資するべきかを理解するのに役立ちます。

経営側と話をつける

たとえば、ServiceNow、PagerDuty、Slackなどの内部ツールは、スピードとカバーの広さへの投資であり、インフラストラクチャ全体の問題を迅速に解決するのに役立ちます。それらをさらに補強するには、開発用ツール、オンコールスタッフの増員、モバイルやアプリ内でユーザーに警告するためのシステムとの緊密な統合が必要になるでしょう。これらの投資は、インシデント後に計画なしに提示されるべきではありません。むしろ、インシデント管理とインシデント解決の指標は、インシデント解決の結果を改善するために、現在インフラがどう設定されているのか、人やプロセス、ツールをどこに追加すべきかを示すものでなければなりません。

また、インシデントは必ずDevOpsやTechOps、サポート、サービス部門と経営側との対話を強制するため、明確な「ビジネス現場で通じる」言葉で話せる必要があります。 以下はインシデントについて情報を交換するための非常に基本的なフレームワークの例です。

優先度2

社内のインシデント通知(変更管理チケットなど)は、(PagerDutyとSlackを使用して)オンコール担当者に直ちに送信されること。SLAでは、アカウントオーナーとの同日中の管理連絡を求めます。

SLAが合意した目標内で実際にに解決された優先度3のインシデントの割合(過去の割合) 該当する期間内の優先度3のインシデントの割合(パーセンテージ)

優先度1

内部でのインシデント通知(カート機能のダウンなど)は、オンコール担当者、管理チーム、サポートにすぐに送信される。SLAは、この通知から1時間以内にインシデント責任者との管理連絡を求めます。

SLAが合意した目標内で現実に解決された優先度1のインシデントの割合(過去の割合) 該当する期間内の優先度1のインシデントの割合(パーセンテージ)

このテンプレートは、インシデント対応担当者やビジネス関係者向けに内部だけで使うこともできますし、顧客や見込み客向け、つまり外向けに使うこともできます。技術的な知識がなくても、経営側はインシデント履歴と解決にかかった時間を理解できます。このデータは、テクニカルチームが保守できる資産であり、インシデント解決とDevOpsプロセスを直接結びつけるものです。

上記は経営レベルで適切な会話をするのに役立ちますが、内部の事後検証は開発チームやサービスチームにとってより内省的です。 質問:これらのプロセスは正しいですか? インフラストラクチャは十分な弾力性を備えていますか? そうでない場合は、自分たちが知っているることと、変えられることをどう計ればよいでしょう? チームの成果を判断する際に考慮すべき基準の例を次に示します。

インシデントのインパクトと緊急性に基づいて優先順位を設定したか

ログ処理後に優先度が変更されたチケットの数 苦情やエスカレーションのために作成された追加チケットの数 各優先度のチケットに割り当てられた担当者の数と層(ティア)

顧客とユーザーが何が起こっているのか、そしてインシデントが解決されることを期待できるかを理解するよう、コミュニケーションをうまく行えるかどうか

顧客が最新情報を求めるためにサービスデスクに連絡したインシデントの割合

顧客はインシデントを処理する方法に満足しているかどうか

インシデント終息後の調査でユーザーの満足度の割合 年間顧客満足度調査で調べたインシデント解決による満足度の向上

繰り返されるインシデントを認識し、将来の悪影響を減らすために公開の場(フォーラム)で問題を説明したかどうか

フォーラムに公開されたサービスデスクに記録された問題の数 フォーラムにリダイレクトされたチケットの数 フォーラムにより生成されたチケットの数

インシデント解決への投資とツールを効率的に活用したかどうか

メール/フォーラム/アプリケーション経由で記録されたインシデントの割合 セルフサービスツールで検出され解決されたインシデントの割合 インシデント解決の平均コスト(優先度別) ツールへの投資後にインシデントを解決するためにかかった平均時間 ツールへの投資後のインシデント数の減少率

専門チームのために分析が最大の意味を持つようにするには、はるかに多くの基準がありますが、これらの基準は不可避な質問に答えるための出発点となります。モダンなチケット発行、監視、インシデント解決、コラボレーション、顧客満足度測定ツールを使用してください。多くのツールには分析機能が組み込まれています。

先に書いたPagerDutyとSlackは、インシデント解決とコラボレーションの標準ツールです。ServiceNowとAtlassianスイートは、インシデント管理と資産管理の連携に最適です。何よりも、インシデントを効果的に解決しその後の発生を防ぐには、ツールだけではなく、効果的かつ統合された、セルフサービス型でツールを使えるようにする明確なプロセスが必要です。

ツール、プロセス、人の効果を評価する際に、「Other」、「Misc」、あるいは他のざっくりと包括するようなカテゴリーを使わないでください。そんなカテゴリーを使うのは全ての基準に罠を仕掛けるようなものです。また、まずテンプレートを使ってみるのが良い場合もありますが、テンプレートからコピーするだけではなく自分たちで改良すれば、チームのレポート機能をさらに強化します。さもなければ、次の点についてチームの感覚で検討を始めてください。

課金モジュールのエラーがあなたのサービスでは優先度1または2に分類されていますか? 顧客は優先度1になるでしょうか? 全部が優先度1である顧客はいますか?

無理はしないでください。あなたもチームの一員なのです。 自分のチームがインシデントをどう扱うか(タイムライン、人員、ツールの使用法など)という質問にフォーカスし、それに基づいて優先順位を付けてください。インシデント解決ツールの基本的なカテゴリーとプロセス、ビジネス改善のための投資を継続できるかを示す指標が分かっていれば健康を維持できます。Tire fireが起きた場合でも。

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

2020年春のローンチ:新しいデジタル時代の新機能

進行中のパンデミックとその結果としての景気後退は、市場の状況を劇的に変化させました。その結果、エンジニアチームは、完全リモート環境に突然移行することによる影響を軽減するために、財務リスクを最小限に抑え、コストを削減する必要性をますます感じることになりました。

一部の人にとっては、ビジネスの継続性を維持するための苦労がありました。つまり、皆が自宅で仕事をしているときもビジネスの物理コンポーネントは実行し続けています。他の人にとっては、社内外の顧客に対するデジタルサービスへの依存度を強調することが課題の中心となっています。最近の調査で判明したように、すべての組織や部門が同じように影響を受けるわけではありません。

このような環境では、会社の種類に関係なく、ビジネス目標はコストを削減し、収益を保護し、デジタルトランスフォーメーションを加速するという3つのニーズに集約されます。困難なように思われるかもしれませんが、楽観的な見方があります。適切なテクノロジーソリューションを導入することで、組織は予算を拡大し、プロセスをより効率的にし、シームレスなデジタル体験で顧客を満足させることができます。

PagerDutyは、お客様の課題解決を支援するために、対応チームの効率を向上させ、デジタルファーストの世界でお客様との関係を保護できるようにする最新のリリースを発表しました。

積極的なインシデント対応

デジタルサービスへの信じられないほどのアクセスに直面している場合でも、それがまもなく予定されている場合でも、あらゆる組織が積極的にインシデント対応することが重要であると考えています。積極的になるとは、技術スタッフとビジネススタッフの両方にデジタルサービスを活用するためのツールを提供し、問題が発生しても無知の状態から始まらないようにすることです。デジタルの世界では、秒単位の時間が重要であり、重要な個人がその場でインフラや対応手順について学習することはできません。今こそ行動の時です。そのため、デジタルの準備が非常に重要です。

積極的なインシデント対応に関する新機能とアップデートされた機能により、すべてのチームにデジタルサービスとその依存関係、ハイパーケアを提供し、収益に影響する危機になる前に問題を回避するために必要な運用指標を提供します。

サービスプロファイルを使用すると、エンジニアリングマネージャーと対応者はランブック、抑制されたアラート、過去のインシデント、通信チャネルなど、サービスに関する関連情報を整理、検索することができます。

サービスダッシュボードは、運用メトリックとKPIを分析して、組織間の調整を行い、より良いビジネス成果を実現します。

サービスの依存関係(アーリーアクセス可能)は、ユーザーがPagerDutyのサービス間の関係を理解し、問題をより迅速に特定、トリアージ、修正し、チーム全体でより効果的にコラボレーションするのに役立ちます。

可視性コンソール(アーリーアクセス可能)は、サービスパフォーマンスのリアルタイムの統合ビューを提供し、UIが一新された高度なフィルタリングとカスタマイズ可能なレイアウトが含まれるようになりました。このツールは、チームがインシデント対応に積極的なアプローチを取り、ハイパーケアの瞬間に顧客のニーズを満たすのに必要なコンテキストを提供します。

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

チームがまだハンドブックを調べて問題への対応方法を決定している、または手動で過去のインシデントを調べて何が関連しているのかを確認していては、時間やリソースを最大限に活用できません。チームの効率を改善して収益を保護する最も簡単な方法の1つは、価値の低いアクティビティや労力を自動化して削減し、貴重なリソースを他の場所に再展開できるようにすることです。

インテリジェントな対応と自動化のための最新のソリューションは、何が最も重要であるかに焦点を当てたリアルタイム情報を提供します。また、作業の重複を減らし、マシンが手動タスクを自動化できるようにすることで、対応者の負担を軽減します。自動化でより少ないリソースでより多くのことを実行できるようになり、ビジネスの回復力が向上し、収益が保護されます。

イベントインテリジェンスの一部であるモバイルインテリジェントトリアージは、チームによる作業の重複を防ぎます。機械学習は、問題とコラボレーションの履歴レコードを利用し、関連するインシデントをマージすることで、誰が責任を持ち、問題に取り組んでいるかをより正確に特定できるようにします。

インシデントの再開**(アーリーアクセス可能)は、対応者の柔軟性が向上し、インシデントの重複が減少し、問題が予期せずに再発したときに、より迅速な再動員が可能になります。

Rundeck、Ayehu、Pliant、Amazon EventBridgeとのインテグレーションは、ワークフローマニュアル自動化し、レスポンスプレイの一部として対応チーム内のコミュニケーションを改善することができます。

リアルタイムビジネスオーケストレーション

今日、テクノロジーチームは、デジタルサービスに対する顧客の需要の劇的な増加だけでなく、完全に分散されたチーム間でのインシデントコミュニケーションの管理にも取り組んでいます。一方、顧客は依然として完璧な体験を期待しています。インシデントが発生した場合、ビジネス面での対応と技術的な対応を緊密に統合することが重要であると考えています。これは、既存の技術プロセスの自然な拡張である必要があり、手動のプロセスを伴うことや、追加のツールをセットアップをしなくてもいいことが必要です。

当社の最新の機能強化は、サイロを分解し、すべてのチームに適切なレベルの情報を提供することで、重要な瞬間に作業とコミュニケーションをより効率的に行えるようにし、最終的にはより良い顧客体験につながります。

モバイルステータスダッシュボードは、ビジネスの利害関係者に、ビジネスサービスに関する情報更新への外出先でのアクセスを提供します。

ステータス更新ブランディングはブランド化された通知により、通知受信者のエンゲージメントと信頼を高めます。

Salesforceとのインテグレーションにより、チームはワークフローをカスタマイズして適切なリソースを適切なタイミングで動員できるようになるため、デジタルサービスのカスタマーサポートにおけるクラス最高の統一フロントが実現します。標準のSalesforceオブジェクトと統合して、PagerDutyで対応するアクションをトリガーします。

オンコールスケジューリングタイムライン(制限付きアクセス)および* ハンドオフ通知の拡張機能*により、オンコールシフトとチームメンバーが担当するサービスの可視性が向上し、競合、ワークロード、シフトのオーバーライドを管理する簡単な方法がユーザーに提供されます。

Microsoft Teamsとのインテグレーションにより、対応者はチーム内の重要なインシデントの詳細を表示できます。また、新しいインシデントを受任、解決、トリガーするだけでなく、インシデントのメモをすべて1つのインターフェイスから追加できます。

新しいインテグレーションとAPI

詳細が重要であることはわかっており、小さな改善や拡張されたインテグレーションでも、停止に迅速に対応し、最高のパフォーマンスで運用するチームの能力にすべての違いをもたらすことができます。そのため、私たちはSalesforce、Microsoft Teams、Jiraなどのツールとの統合を強化し、テクノロジースタック全体の可視性を最大化して、すでに知っているツールやお気に入りのツールから作業できるようにするために懸命に取り組んできました。さらに、ビジネスサービスとレスポンスプレイAPIにより、主要なデータと機能にアクセスできます。

最新のリリースの詳細については、このリンクをご覧ください。

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

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

インシデント管理が全従業員のやる気をアップ!

失敗への恐れは開発チーム や運用チーム のメンバーにとって大きな壁となります。この恐怖は耐えがたいもので、社内の士気を大幅に下げ、従業員の生産性と進歩も傷つける可能性があります。

適切なインシデント管理とモニタリングを実施するだけで、アラートを管理して分析機能を提供する以上の効果が得られます。つまり開発の失敗を軽減し、アプリの作り方や投入方法を変えられるようにすることもできるのです。効果的なインシデント管理ソリューションを導入して、開発チームの士気を高め、最高の仕事ができるようにするいくつかの方法を見てみましょう。

インシデント対応中のストレスレベルを下げます

ストレスの軽減は正しいデータを得ることから始まります。正しいデータを持っていない場合は、どこを見て解決すべきかが分かりません。インシデント管理では、適切なコンテキストで全ての適切なアラートを集中管理し、関連する監視ツールのデータを浮かび上がらせることでさらに深く分析を掘り下げることができます。これはインシデントのトラブルシューティング時にチームがよりうまく動き、問題をより速く解決するのに役立ちます。全てのツールのデータをインシデント管理ソリューションに統合することで、チームの誰が何を担当しているかを全員が把握できます。さらに、問題を素早く修復するために必要なデータ(ランブック、グラフなど)も備えています。より速い解決は常にチームをよりハッピーにします。

( 注:ランブックは、運用時に実施する一連の操作について、手順を明確に示した操作指示書のこと)

新機能でインシデントの発生が予測可能になります

インシデント管理プロセスがうまく機能している場合、何が原因で繰り返しダウンタイムが発生するのか、またどのインフラストラクチャやアプリケーションが障害の影響を受けやすいのかが分かります。これにより、新しい機能を追加する際の信頼性が向上します。QAチームは、例えば、注意を必要とするアプリの特定のエリアをチェックするテストを書くことができます。また、経験から問題の原因が分かるため、新しい機能を拒否することさえできます。チームが新しい機能のフィードバックを提供するには、システムの機能と定期的に起こる問題についての深い理解が必要です。このような理解はインシデント管理プラットフォームを使うことでしか得られません。この予測可能性は、チームが「システムを信頼する」ことを助け、あらゆるステップで次に何を期待できるかが分かるようになります。この心の安らぎは従業員の士気と自信を高めます。

全チームが優れたユーザーエクスペリエンスを 提供できるようにします

伝統的に開発チームは、アプリケーションのコードを書きあげて、「壁の向こうの運用チームに投げ込めば」、自分たちの仕事は終わるものと思っていました。同様に、運用チームは、提出されたコードの品質を保証することは自分たちの仕事ではなく、開発から来るものをデプロイすればよいと思っていました。インシデント管理が機能すれば、開発チームと運用チームが統一されたプラットフォームで連携して、チーム間で可視性と一貫性のある単一の真実に向き合えるようになります。彼らは、どれがコードに起因する問題か、そしてどれがインフラストラクチャに起因する問題かを認識できます。

つまり稼働時間は、いくつのサーバが稼働しているか、アプリケーションのどれくらいが正常に稼働しているかによって決まるのではなく、エンドユーザーの経験によって評価されているのだということです。稼働時間に関するこの現実的な見方は、チームの目標とプロセスを、ユーザーの期待を超えるアプリケーションを提供するというより広いビジネス目標へと向かわせます。幸せな顧客がチームを幸せにするのです。チームの仕事のおかげでエンドユーザーが喜んでいることを見せる以上に、従業員の士気を高める良い方法がありますか?

パイプライン全体を加速します

ゲームを変えるようなアプリケーションを構築したい場合は、スピードが不可欠です。インシデント管理は、インシデントが発生したときに、開発チームと運用チーム(ヘルプデスク、サポート、ビジネス関係者など)間の明確なコミュニケーションを可能にします。コミュニケーションのボトルネックが解消されば、チームメンバーは繰り返し起きる問題をより短い時間で解決できるようになり、顧客の幸せを保つためのアプリケーションの開発にもっと多くの時間をかけられるようになります。アプリの開発に使える時間が増えることは、品質向上と市場投入までの時間短縮をもたらします。市場への投入がより迅速になり、チームが1日あたりに出来ることが増えれば、彼らは自分たちの能力が上がったと感じ、より深く取り組むようになり、自分の仕事に情熱を感じるようになります。

オーナー感覚を作り出します

インシデント管理は、インシデント対応のさ中にチームメンバーがより責任を持ち、インシデント対応の手順を確立して、より上位の人たちに頼ることなく重要な意思決定を行えるようにします。決定する能力を持つことは簡単なように思えるかもしれませんが、組織のプロセスの中でチームメンバーがより強い影響力と自信を持つようになるまでは、長い道のりがあります。上位のチームメンバーからの許可を待たないようにすれば、お役所仕事を減らせます。チームのメンバーは、顧客の体験を24時間確実にサポートするために、オンコールを担う責任を全うしています。あらゆるレベルのチームメンバーが意思決定に関与できるようにすると、無茶苦茶なカオスや冗長な作業に費やす時間を短縮し、貴重な時間を無駄にせず、実際の開発に多くの時間を割けるようになります。

効果的なインシデント管理ソリューションは、失敗への恐れを減らし、予期せぬ事態をチームが自信を持って管理できるようにし、結果として従業員の士気を向上させます。チームメンバーが獲得できた信頼感は、パイプライン全体で革新と標準化を推し進め、従業員の士気、生産性、成功を大幅に向上させます。

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

2019年春リリースの概要:The Intelligent Enterprise

今日のデジタルワールドでは、企業のビジネス関係者や障害対応にあたる技術者は、中断が発生したときにすぐに対応できるように、常にデジタルサービスの健全性を意識する必要があります。それでも過去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アルゴリズムは、これをさらに効率的に実行するように改善されているため、少ないトレーニングデータでより早く作業を開始できます。 新しいアラートグループ化プレビューにより、サービスのオーナーはインテリジェントアラートグループ化をアクティブにする前に、潜在的なノイズ低減とグループ化動作を理解することができます。

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

クリティカルなアプリとインフラを継続稼動させる

「インシデントのライフサイクル管理? ある事件から次の事件まで生き伸びさせることができれば、 良い一日。悪い日は何もかもパニックさ」

残念ながら、これは非常に多くのソフトウェアやIT企業のインシデントライフサイクル管理の現実ですが、必ずそうなるものではありません。本来は、本物のプロアクティブなインシデントライフサイクル管理により、インシデント対応チームが慢性疾患やパニックモードに陥るのを防ぐことができるのです。

インシデントライフサイクル管理は、インシデントを分類、応答、解決、および文書化するためのフレームワークであり、サービス損失を最小化し、良く組織化されたフォローアップをもたらします。重要なサービスを維持するには、エンドツーエンドのインシデント解決フレームワークが不可欠です。

顧客中心のインシデント管理を

最新のインシデント管理システムは、英国政府のセントラル・コンピューティング・アンド・テレコミュニケーションエージェンシーによって1980年代に最初に開発されたITIL(注1)モデルに基づいています。ITILモデルは、厳密に技術仕様に従って主要システムを維持するのではなく、クライアントや顧客にサービスを提供することを中心にしています。これは、ユーザーサービスのメンテナンスが非常に重要な外部向けのアプリケーションでのインシデント対応の理想的なモデルになります。インシデント・ライフサイクル管理フレームワークを設定する際に留意すべきITILモデルの最も重要な点は次のとおりです。

初期対応

これは、着信アラートが記録され、分類され、適切なチームにルーティングされるフェーズです。多くの点で、これはインシデント管理ライフサイクルの中で最も重要な部分です。なぜなら、問題を検出し、ノイズ(対応不可能なアラート)をフィルタリングし、優先順位を設定し、各アラートをどこにルーティングするかを決定するからです。

プロセスのこの部分を適切に管理できないと、重要なアラートが見落とされたり、あまりにも低い優先度で処理されたり、誤った担当者にルーティングされたり、レスポンスチームの作業負荷が不均衡になったりする可能性があります。

レベル1レスポンス

アラートが分類されると、アラートはレベル1対応チームに送信されます。レベル1のチームが最初の対応者です。彼らの仕事は、典型的には特定の時間枠内で、顧客満足度を満たすように解決することです。レベル1のチームは、事件を調査し、基本的な問題が何であるかを把握し、可能な限り、既知の修正または推奨された修正を適用します。

レベル1のサポートは、インシデントの特にエスカレーションに関するステータスも監視します。レベル1のサポートのもう1つの重要な責務は、影響を受ける顧客とのコミュニケーションを維持し、契約や組織ポリシーによって設定された間隔で状態の更新情報を提供することです。これにより、たとえインシデントがより高いレベルのサポートに引き継がれたとしても、一貫した通信チャネルを維持することが可能になります。

レベル2レスポンス

インシデントがレベル1サポートの診断と迅速な解決能力を超えている場合、より多くのリソースと経験を持つレベル2のサポートチームに引き継がれます。

レベル2のチームは、製造業者、ベンダーなどからの専門的な助言を受けることもできます。レベル2サポートの基本的な目標は、レベル1と同じ状況に戻す、つまり顧客またはクライアントへのサービスをできるだけ迅速に復元することです。

解決後のレポート作成とレビュー

正式なITILモデルでは、解決後のプロセスはインシデントのクローズと評価、およびインシデント管理レポートの2つに分けられます。多くの組織、特に小規模の組織では、それらを1つのプロセスにまとめるほうが便利かもしれません。

解決後のまとめの重要な要素は、解決策(またはその不足)の検証、記録、評価、およびインシデントの詳細報告(通常、事後検証報告による)です。インシデントの事後検証報告は、将来のインシデントへの対応(うまくいけば防止)のために簡単にアクセスできる情報源として機能するように、対応チームやマネージャーが利用できる、インデックスが付いて検索可能な情報として蓄積されなければなりません。

その他の重要な問題

上記の要素に加えて、ITILモデルには、現実的なインシデント・ライフサイクル管理システムで活躍する2つの要点があります。

重大インシデントのハンドリング

重大インシデントは通常、基本インフラストラクチャや主要なサービスの運用、あるいはセキュリティに直接的かつ深刻な脅威を与えるものです。目的は、できるだけ早くシステムを稼働させることですが、初期応答の優先順位とレベルははるかに高くなります。重大インシデント、例えばハードウェアインフラストラクチャの重要コンポーネントが故障した場合などには、レベル2となり、専門サポートチーム、サードパーティのサポートに直接渡すことがあります。

各組織は重大インシデントを構成する要件について独自の基準を作れますが、優先順位と対応のレベルがはるかに高い独自のカテゴリーに設定することが肝要です。

応急策

ITILモデルのインシデント管理の最優先事項の1つは顧客サービスを可能な限り迅速に維持、復元することであるため、初期の対策には応急策(ロールバックなど)が含まれる可能性があります。これはすべてのレベルで当てはまります。その理由は単純です。顧客サービスを今復元するとすぐに問題を解決でき、運用チームや開発チームは根本的な問題を解決するために必要なだけ時間を取ることができるからです。

インシデントレポートシステムと運用、開発アップデートのスケジューリングの両方で、すべての応急策をログに記録して識別することが重要です。また、応急策を取ったことで技術的負債(注2)が発生し、そのコストは負債を解消するまで大きくかつ長くなります。つまり、インシデント対応に適用した応急の回避策は、できるだけ早くシステム設計基準に準拠したソリューションで置き換える必要があります。多くの点で、回避策がより永続的なソリューションに置き換えられるまで、インシデントは完全には解決されません。

インシデント対応チームが日常的にサバイバルモードで運用を続ける必要はありません。インシデントへの準備ができていなくても顧客に対して大きな影響がない場合は、そうすることで混乱と不安が生じます。

組織のニーズに合わせたインシデント・ライフサイクル管理フレームワークにより、重要なアプリケーションやインフラストラクチャーを最小限のサービス中断やストレスなしに管理できます。インシデントライフサイクルのベストプラクティスを実装することが信頼性の鍵であり、信頼性そのものは長期的な成功を左右する不可欠なサービスです。

※注1:ITILはITサービスマネジメントを実現するため、ITサービスの品質向上、中長期的なコストの削減などを目的として実在する企業、サプライヤ、コンサルタントなどからITサービスに関する実際の運営方式やノウハウを収集し、書籍化したもの。欧米社会においてITILは既にITサービスマネジメントの業界標準として広く認知されており、社会的な地位を確立している。(ウィキペディア)

※注2:技術的負債(英:Technical debt)とは、行き当たりばったりなソフトウェアアーキテクチャと、余裕のないソフトウェア開発が引き起こす結果のことを指す新しい比喩である。「設計上の負債(design debt)」とも言う。1992年ウォード・カニンガムが、技術的な複雑さと債務の比較を経験報告で初めて行った。(ウィキペディア)

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

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

IcingaはNagiosからフォークしたオープンソースのシステム、ネットワーク監視ソフトです。このガイドではPerlベースのプラグインを使用して、IcingaのインストールとPagerDutyへのインテグレーションを解説します。

詳しくはこちら