Category
インシデント＆アラート

ITOpsチームはインシデント管理を集中化できますか？ ITOps部門で仕事をしている人なら、その質問に対する最初の答えは、はっきり「いいえ」かもしれません。

結局のところ、ITOpsはあまりにも幅広く多様なことに責任を抱えているため、インシデント管理に関してはすべてを一つの傘の下に置くことはほとんど無理と思われるかもしれません。サーバの管理、デスクトップPCのプロビジョニングからヘルプデスクのサポートまで―業者の選定や管理には言及していませんが、ITOpsチームはすべてそれを行います。

これは、ITOpsを組織の他のほとんどの部門と大きく違うものにします。プログラミング部門の場合は、コードリポジトリを使って開発プロセスとバグ管理プロセスを集中管理できます。 営業部門なら、Salesforceのような集中型プラットフォームを使用して、製品と顧客の連絡先を管理できます。でもITOps部門ではそうはいきません。非常に多くの異なるタスクをカバーしているからです。

ここでは、ITOpsの集中インシデント管理が単なる夢物語だとは限らないことをお伝えします。確かにITOpsは非常に多くの多様なジョブを処理しているため、1つであらゆる組織の問題を監視して対応できるプラットフォームはありませんが、インフラストラクチャ全体のインシデントを管理は一元化できます。

どうやって？　その答えは、ITOpsワークフローのさまざまな要素を統合できるインシデント管理ツールを使うことです。

監視サービスを最大限に活用する

ITOps自体が集中化されていない場合でも、ITOpsチームがインシデント管理を集中化する方法について基本を説明しましょう。

あなたが中小企業のITOpsのプロフェッショナルであれば、3つの主要なインフラを把握しておく必要があります。1つ目は、ローカルファイル共有をホストしたり、いくつかのWebサイトを提供するために使用する社内サーバです。 2つ目はデータをバックアップしているパブリッククラウドです。 3つ目はローカルのワークステーションで、常に稼働状態にして、オンプレミスとクラウドのサーバに接続している必要があります。

このインフラの各部分のインシデント管理を計画するのは難しいことです。一部の監視システムは、ベアメタルサーバ、クラウドインフラストラクチャ、そしてPCを等しく良好にサポートできると主張しているものがあります。しかし、もしそうなら、おそらくどの分野にも特化した機能を持っていないのでしょう。そういうシステムは、特定の種類のインフラ向けに設計された高度な機能を持たずに、一般的な監視機能だけを提供しているのです。

ですから、単一の監視システムでカバーしようとするのではなく、各インフラの特質に合わせて調整された監視サービスを複数組み合わせて使う方がよいでしょう。クラウドの場合は、AWS CloudWatchなどのクラウドセントリックの監視システムを使えば最大の効果を引き出せます。 SolarWindsは、オンプレミスのデバイスやローカルネットワークに便利です。 Splunkのようなものを使えば、多くのデバイスが吐き出しているすべてのログデータを分析することもできます。

すべてを統べるたった1つのインシデント管理ツール

ここで紹介した各監視プラットフォームには、アラートまたは通知システムが付属していますが、通知は必要十分なほどロバストではない可能性があります。たとえ十分ロバストであっても、ITOpsチームは、いくつかの異なるプラットフォームからアラートを（しかも異なるフォーマットでいろいろな種類のコンテンツを）一度に受け取りたいとは思いません。そんな状況では、適切なアラートが適切な人に適時届いているかどうかを確認するのはまず無理です。

同じく重要なことに、通知をチームにどのように配信するかを集中管理することもできます。たとえば、監視サービスの中には、SMSアラートをそのサービスだけでは出せないものがあります。通知を必要な形式に変換できる集中管理型のインシデント管理プラットフォームとこれらのサービスを連携させれば、必要に応じて管理者の電話に通知を転送できます。

最後に、集中管理されたインシデント管理ソリューションを使うと、冗長なアラートを回避できます。ネットワークが過負荷になると、ネットワークスイッチを監視しているサービスからの通知だけでなく、サーバ上の監視スタックまで通知を出し始める可能性があります。

同じ問題に起因する複数のアラートを受信すると、チーム間で混乱が起こり、対応にかかる時間が長くなります。これとは対照的に、集中管理されたインシデント管理では、監視システムごとではなく、インシデントごとに通知を受け取ります。したがって、ノイズは少なく、何が起きているのかはすぐに分かります。

通常、ITOpsワークフローにもう1つのツールを追加すると、余分なだけに見えるかもしれません。多くの状況ではそうかもしれませんが、インシデント管理の場合、PagerDutyのような通知を集中管理するソリューションを実装することで、既に導入済みの監視ツールからさらに多くの価値を引き出せます。

Internet of Things （IoT） は、世界中の企業や人々の生活に普遍になりつつあります。それは目新しいものとして始まりましたが、最近ではもっと革新的でミッションクリティカルに使われるケースが出てきています。利用できるIoTデバイスが多様になり、生成されるデータも膨大になっているなか、さまざまなセキュリティ上の脆弱性が露わになり、IoTデバイスを製造する企業は多数の課題に直面していますが、ここでもインシデント解決プラットフォームが役立ちます。今日IoTシステムを構築している場合、または今後IoTシステムを構築する予定がある場合は、ベストプラクティスのインシデント解決ソリューションに投資して、IoTシステムを確実にレジリアント( 弾力性に富み) かつ安全にすることが不可欠です。

IoTシステムには統合が必要

IoTシステムには本質的な複雑さがあるため、エンドツーエンドの監視と統合が不可欠です。非常に多くのデバイスが存在し、すべてがインターネットに接続され、家庭にデータを戻してくるので、使われるのを待つだけの大量のデータがあることになります。ユーザーがIoTデバイスを使うと、使用時間と頻度、使われている機能など、詳細な使用パターンにあなた（注：サービス提供側）はアクセスできます。

監視、ロギング、およびITSM（ITサービス管理）ツールとの統合は、IoTに大きな違いをもたらし、IoTデバイスの開発者が一息つくことができます。PagerDutyのようなソリューションは、すべてを集中管理されたダッシュボードで管理し、ルールを定義してイベント管理の手順やワークフローをカスタマイズできるようにしてカオスを防ぎます。

PagerDuty APIバージョン2.0を使うとまさしくこれが可能になります。このAPIを使用すると、アプリの通知とアラート管理がよりシームレスでカスタマイズ可能になります。あなたのアプリにPagerDutyを埋め込めるだけでなく、PagerDutyにあなたのアプリを埋め込むこともできます。PagerDutyの機能は、必要なデータを表示するためにあなたが独自のダッシュボードを埋め込むことでさらに拡張できます。Custom Event Transformer（カスタムイベントトランスフォーマー）があればJavaScriptを使い、通常のデータを価値がある、そして正規化されたインシデントに変換し、PagerDutyとのカスタム統合が実現できます。

PagerDuty APIによるさまざまなIoTの統合例

PagerDutyのAPIがIoTの革新に影響を与えた事例はたくさんあります。

Resinio

Resin.ioは、IoTのクライアント、サーバ、およびデバイスプラットフォームであり、PagerDutyを使用してIoTインシデント管理を処理します。Resin.ioのようなソリューションは、DevOpsの原則と利点をIoTの世界にもたらします。Resin.ioの他の利点には、Linuxカーネルの採用も含まれており、おかげでIoTデバイス用に独自のソフトを使う必要がなくなります。これにより、開発がより身近なものになります。

Temboo

さらに、Tembooはセンサーモジュールを使った駐車場管理にPagerDutyを使っています。IoTセンサーは警報をトリガーすることができ、駐車スペースが利用可能かどうかを知るためにセンサーデータを使えるようにします。TembooとPagerDutyは、高齢者の介助にセンサーを利用することもできます。センサーを老人の生活エリアに設置すれば、手助けを求めている時に家族が通知を受けることができます。

AlertSite

別のツールで、SmartBearのAlertSiteは、IoTの品質チェックとAPIテストに役立ちます。これらのテストは手動で行う必要はなく、AlertSiteが実行を自動化します。本質的には、それは統合された複合型の監視プラットフォームであり、テスト場所から直接迅速なアラートを送信する機能や、エンドユーザーの動作をエミュレートするアラート機能も含まれています。PagerDutyはAlertSiteと統合することで実現される、最先端のエンドツーエンドのインシデント解決機能により監視機能を強化します。

起こる前に不正を防止

倫理的なハッカーは、インターネットに接続されているデバイスが、さまざまな手段で悪用されることを明らかにしました。例えばユーザーにトラブルをもたらすために機能を悪用したり、デバイスを使ってDDoS攻撃をかけるといった手口を繰り返し明らかにしてきました。インシデント管理は、IoTチームにデバイスに潜在する誤用、悪用の可能性を警告するための重要な保護層であり、特に異常に動作が起きた場合は、調整された応答をトリガーします。

インシデント管理は、それをすること自体が目標と見なされるべきものではありません。IoTが存在するためのより安全な環境を作り出すことは非常に重要です。IoTは、これまで決してできなかったような方法で人々の生活を改善することを目指しています。デバイスがそのような重要な役割を果たしている場合、インシデントの防止と修復はこれまで以上に重要になります。PagerDuty API V2.0は、IoTセントリックな未来のためにPagerDutyプラットフォームを準備するものであり、エンドユーザーと開発者のエクスペリエンスをより快適で、拡張性があり、信頼できるものにする無限の可能性をもたらします。

オフィス に戻って、一晩中サーバ がダウンしていたことを知った経験がありますか。また、その時にアラート通知を受ける方法がなかったのですか。 だとすれば、モバイルインシデント管理が必要です。 ほぼすべての人のポケットにスマートデバイスを持つ現代社会で、インシデントが発生したときにスマートデバイスを活用せずに自分が無力だと思い込むのは残念です。

モバイルインシデント管理の重要性 計画外のインシデントはいつでも襲ってきますが、その時、モバイル端末はインシデント管理の重要なギャップを埋めます。 多くのインシデントは、チームメンバーがオフィスにいないときに発生します。 チームメンバーが眠っているときにも起きます。 インシデントは、こちらの都合を待ってはくれません。

そのため、モバイルインシデント管理が絶対に重要です。 モバイルインシデント管理では、あらゆるデバイスから、外出先でインシデントを解決する方法を提供します。 アラート、統計、要約、タイムライン、ログなどの概要を表示します。 誰がオンコール待機かを知ることができ、オンコールのチームメンバーは、選択したデバイスを介してリアルタイムで通知を受け取ります。 その他にも、チームの割り当て、どこからでもコミュニケーションやコラボレーションを行う機能、他のアプリと簡単に統合できる機能など、便利な機能があります。

モバイルアドバンテージ 一見すると、モバイルインシデント管理は「モバイル用のアプリならありますよ」と言いたがるトレンドに沿っただけのものに見えます。しかしモバイルインシデント管理の利点は無視することはできません。

インシデント管理アプリケーションをスマートフォンまたはタブレットにインストールすることは、デバイスにすべての機能が統合されていることを意味します。 PCと比較して、スマートフォンはより便利な通信手段です。単独でデータを持てますし、電話をかけたり、電子メールを送信したり、テレビ電話をかけたり、緊急サービスに知らせることができます。ラップトップやデスクトップをいつも持ち歩いていなくても、おそらく電話ならいつもお手元に置いてるはずです（またはベッドサイドに）。インスタントメッセージアプリ、作業ファイルなども内蔵しているでしょう。これは、それを4時間いつでも問題を通知するのに理想的なデバイスにします。さらに、インシデント管理アプリケーションはすべての電話連絡先と統合されるため、適切な連絡先情報で適切な人物に自動的に連絡してインシデントを解決しやすくしてくれます。また、アプリのダッシュボードやサマリーに重要なインシデントがあるかどうかを素早く判断して把握することもできます。この方法で、後回しにするインシデントを再割り当てまたはスヌーズすることができます。

インシデント管理アプリケーションを持ち歩けば、問題を見逃すことはありません。あなたがいない間に何が起きるかを心配せずに机を離れることができます。モバイルインシデント管理は、インシデント管理の強力な自動化と、いつでもどこでもあなたに届くフェールセーフを提供します。

DevOpsにとっての利益は？

DevOpsを実践する場合、チームがモバイルインシデント管理アプリケーションを使用することは、多くの利点があります。応答が必要なリアルタイムの問題についての情報を得られることは非常に強力です。常に準備を整え、問題を迅速に解決することができます。これにより、イノベーションとコラボレーションにより多くの時間を費やすことができます。モバイルインシデント管理では、Dev、QA、およびOperationsのすべての人をインシデント管理に確実に同列に関与させていることを確認します。

このコラボレーションは強力なものとなり、インシデントをより効率的に解決するのに役立ちます。チーム全体が常にインシデントを追跡する能力を持っていることで士気が高まります。これにより、多くのプレッシャーが軽減され仕事に集中できます。そして、誰もが開発中のコードについてコールを受けられるようにしておくことは、開発者がより良いコードを生産することを可能にします。これにより、開発プロセスのスピードアップと品質が大幅に向上します。

オンコールエンジニアのベストフレンド オンコールエンジニアは、救急サービスの一次対応チームのようなものです。モバイルインシデント管理は、仕事をずっと簡単にします。リアルタイムにインシデントに適切なアクションをとるためのソリューションを提供します。タイムライン、ログ、対応者の割り当てなど、インシデントを解決するために必要な機能をすべて備えています。モバイルインシデント管理アプリケーションを使用すると、オンコールのエンジニアはインシデントの重要度を迅速に分類して、優先順位や影響を受けるサービス、外部向けの対応を把握し、モバイルデバイスからエスカレート、共同作業、解決、またはスヌーズを直接行うことができます。これにより、誰も時間を無駄にすることがなくなり、オンコールのエンジニアは必要な時に、そして必要なときに対応できる人を募ったり、インシデントを再割り当てすることができます。インシデントがはるかに迅速に解決されるため、不要なエスカレーションが最小限に抑えられます。

PagerDutyのモバイルインシデント管理アプリケーション（iOSまたはAndroid対応）は、集中ダッシュボード、重要な統計情報、インシデントの再割り当て、連絡先の統合、インシデントタイムラインなどのすべての機能を提供します。ユーザーごとのアクセス許可と細かいカスタムアクセス制御は、どのデバイスでも可能です。それはインシデント管理のワークフローをより合理化します。どこにいてもモバイルデバイスから迅速かつ簡単にインシデント管理ができるようにします。インシデント管理プロセスの中では絶対不可欠なものです。

※このコンテンツはwww.pagerduty.com/blog/の抄訳です。

モバイルでのインシデント管理

モバイルでのインシデント管理。 どんなときも。 どこでも。

すべてのデバイスで、卓越したユーザーエクスペリエンスを備えたインシデント管理ライフサイクルを実現します。 PagerDuty Mobileアプリケーションを使用すると、アラートを視覚化し、外出先でアラートを確認、解決、再割り当てすることができます。 モバイルアプリ、メール、SMS、電話などのマルチチャネル通信オプションを使用すると、アラートやインシデントの更新を見逃すことがありません。

“ iOSアプリが本当に好きです。 オフィス外にいる間にすべてのインシデントを認知し、エスカレートし、解決する能力は本当に素晴らしいです。 “

モバイルインシデント管理の詳細をご覧ください

			インシデントを作成する


			モバイルアプリから直接新しいインシデントを簡単に作成できます。


		
		
			モバイルアプリ


			iOSとAndroidの携帯電話、タブレット、スマートウォッチでインシデントを管理します。


		
		
			アラートと通知


			アラート音をカスタマイズして、無制限のプッシュ通知アラートを受信することができます。また、割り当てられたインシデントについて承認、エスカレート、解決されたことを知ることができます。


		
		
			インシデントの詳細


			インシデントの詳細、インシデント履歴、オンコールスケジュールを表示します。 オープンしているインシデントに対して、認識、解決、再割り当てすることができます。


		
		
			スケジューリング
			自分またはチームのオンコールスケジュールとブックされたオーバーライドを表示します。


		
		
			インシデントをスヌーズする


			すぐに解決する必要のないアラートをスヌーズします。

PagerDutyのインシデント解決プラットフォームは、ノイズを削減し、インシデントをより迅速に解決するのに役立ちます。

アラート 。それはいとも簡単に積み上がります 。一瞬で目にするアラートはほんの一握り。でも数時間、場合によっては数分後に、積みあがった山を見ることになります。 どのようにそれらを管理すれば、担当者がお手上げにならないようになるんでしょうか？

これらは非常に重要な質問です。 アラート管理システムにノイズが溢れていて、対応チームが慢性の疲労状態にある場合は、初動に対応するITアラート管理システムを持っていないも同然です。 過剰なノイズとアラート疲れは、アラート管理システムの有効性を完全に低下させます。

フィルタリングの適用：インシデントにアラートをまとめる

多くの点で、アラート管理システムの合理化の鍵は、関連するアラートをインシデントに統合し、インシデントの優先順位を決定するための迅速かつ正確な方法にあります。緊急度別にインシデントを並べ替えることで、ほとんどのノイズを自動でフィルタすることができ、すぐに注意が必要なものとしばらく様子を見ることができるものを、合理的に推量することができます。すべてのアラートがインシデント化や対応を必要とするわけではありません。対応不要なアラートを抑制すると、ノイズがさらに削減され、重要なことに集中できます。

ソート（優先度順に並べ替える）プロセスの一部を自動化する（例えば、ソースとキーワードで並べ替える）ことはおそらく可能ですが、一部の（多分相当な量の）ソートプロセスでは、ディスパッチャの役割を果たしているレスポンスチームの誰かが介在する必要があります。ただし、どのような方法を使用しても、基本となる基準は変わりません。

優先順付けのスキームのほとんどは、ITILが定めているインシデントの優先順位付けガイドラインなどに準拠しています。インシデントの優先順位は、インパクトと緊急性という2つの密接に関連する要因に基づいて付けられます。この記事では、これらの要因とその相互作用について詳しく見ていきます。

インシデントのインパクトを判断する

インパクトは、インシデントの影響範囲（部門、ユーザー、または主要サービスがどれだけ影響を受けるか）に基づきます。 影響判定プロセスの少なくともいくつかの要素を自動化するのは比較的簡単です。 たとえば、ほぼ同時に特定のサービスが利用できないことを示す多数のレポートが出てくれば、影響の大きいインシデントになる可能性があります。一方、単一のユーザーからの問題のレポートは、類似のレポートが他になければ、 影響の少ないインシデントだということを示します。 多くのIT部門にとって、インシデントの影響を判断するためのガイドラインは、次のようになります。

高インパクト

重要なシステムがダウンしている。 1つ以上の部門が影響を受ける。 相当数のスタッフがその機能を実行できない。 そのインシデントが多数の顧客に影響を与える。 そのインシデントが、財務上の大きな損失や組織の評判への損害になる可能性がある。 組織の機能と影響を受ける他のシステムに応じて変わるその他の基準もあります。例えば公衆の安全上の脅威、人命の喪失、または重大な財産の被害などが含まれる可能性があります。

中程度のインパクト

一部のスタッフまたは顧客は影響を受ける。 失われたサービスはどれも重要ではない。 財務上の損失や組織の評判への損害は起きる可能性があるが、範囲は限られている。 人命、公共安全、身体的財産への脅威がない。

低インパクト

少数のユーザーしか影響を受けない。 重要なサービスは関与しておらず、財務上の損失や評判の低下の可能性はほとんどない。

インシデントの緊急度

インシデントのインパクトとその緊急性を厳密に区別することは必ずしも容易ではありませんが、ほとんどの場合、このコンテキストで言う「緊急性」とは、「問題がシステムにどれだけ早く影響を及ぼし始めるか」ということだと定義できます。 給与計算システムの故障は、例えば、影響が大きい可能性がありますが、給与の支払い周期の始めに発生した場合は、毎日使う顧客関係データベースの損失よりも緊急性が低い可能性があります。

緊急度高

日々の操作に不可欠なサービスが利用できない。 インシデントのインパクトの範囲が急速に拡大しているか、または迅速なアクションによってその範囲を制限できる可能性がある。 時間に敏感な仕事や顧客の行動に影響がある。 そのインシデントが、高位の個人または組織（上級管理職または主要なクライアント）に影響を与える。

緊急度低

影響を受けるサービスはオプションであり、まれにしか使用されない。 インシデントの影響は拡大しないように見える。 重要な作業や時間に敏感な作業は影響を受けない。

注意してほしいのは、インパクトと緊急度の両方について、一般的には各カテゴリの1つの基準に当てはまればそのカテゴリになると思ってよいということです（基準のすべてまたは大多数を満たす必要はありません）。インシデントは、それが条件を満たす最も高いカテゴリに配置する必要があります。

優先度=インパクト+緊急度

以上のように考えれば、優先順位をインパクトと緊急性の両方の合算で評価すべきだと分かりやすくなったはずです。アラート管理とインシデントのディスパッチプロセスには関係なく、優先順位を決定するための基準に従ってルーティングする必要があり、結果としてアラートノイズを大幅に減らすことができ、低インパクト、低緊急度のイベントは自然に優先順位リストの下端に並ぶと思います。これにより、インシデント対応チームは、非常に注意を払う必要がある、高インパクトで高優先度のインシデントに集中することができます。

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

火事が発生する前に適切なツール を用意することが重要です。適切なツール がないと、大規模な停止を認識し、整理し、解決することがはるかに難しくなります。事前にベストプラクティスが確立されていれば、困難なインシデントをよりスムーズに処理できます。

以下は、障害発生に備えたプランを網羅したリストではありませんが、問題の調整と準備のための組織の能力を大幅に向上させます。

1. 内部コミュニケーション

内部のコミュニケーションは通常電子メールで行われます。これは、いくつかの理由で問題があります。電子メールは1対1のメディアです。つまり、送信者と受信者だけが読み取り可能であり、迅速なステータス情報が必要な場合は解析が困難です。SlackやHipChatなどのコラボレーション環境は、情報を伝達するために外部ホストを利用します。これらは、全員への公開チャンネル、登録者のみに公開されるチャンネル、あるトピックについてのチャンネルなどを提供します。クリティカルレベルでは、ステータスの更新（または問題が既に分かっており、作業中であることを伝えるメッセージ）を、主要なスタッフ（サポート、リーダー）にほぼリアルタイムで提供することができます。

2. アプリケーションのパフォーマンスとインフラストラクチャの監視

本来、チームは顧客より先にアプリケーションに問題があることを知るべきです。アプリケーションやインフラストラクチャの監視技術は、修正や更新が必要なときに役立つかどうかの情報を提供します（New RelicやAWS CloudWatchなどがこれにあたる）。また、PagerDutyなどのソリューションを使い、アプリケーションのパフォーマンスとインフラストラクチャのパフォーマンスを監視することも重要です。問題が発生した場合は、全サービスの正常度データを単一のビューに統合し、緊急行動が必要な場合はオンコール担当者に通知します。アプリケーションとインフラストラクチャの両方が可視化されていれば、問題解決ははるかに簡単です。

3. ステータスの更新

パフォーマンス上の問題が発生した場合、サポートチームに更新要求が殺到します。この流入を緩和するための主な方法は、Twitter、ステータスページなどを利用すること、またはPagerDutyのような製品を使うことです。これらは、主要インフラストラクチャとは別のインフラ上で稼働し、サイト全体が停止しても動き続けることが必要です。Twitter上では、ユーザーがピントゥイートと最近の返信を簡単に探すことができます。ユーザーはstatusapp.comで「黄色」または「赤」のステータスを確認することもできます。statuspage.ioのような読みやすいステータスページは、ダウンタイム中に情報を顧客に伝えるための重要なコンポーネントです。ユーザーはトラブルの際の情報が正確で更新が適切に行われている場合、そのページに信頼を置きます。そうすれば、彼らはあなたのビジネスにもっと信頼を寄せるでしょう。また、トラブル対応の最中にも情報の更新と各主要サブコンポーネントのステータスを知らせる必要があります。これらの更新は、完全な可視性を担保するために数分ごとに行われるべきです。最後に、PagerDutyのステークホルダーエンゲージメントのような機能により、インシデント担当者は、任意の優先通知チャネル（電話、SMS、電子メール、またはプッシュ通知）を介して、事前定義されたビジネス関係者のグループに到達するステータス更新を簡単に送信できます。ステークホルダーは、インシデント状況の更新を購読して、顧客に影響を与える問題についてリアルタイムの情報を得ることもできます。

4. チケットソリューション

ZenDeskのようなチケットソリューションは、停電を管理するために絶対に重要です。重大な停止は破壊的であり、信用を失うことにつながります。チケット管理システムは、アプリケーションモニターが見逃した間欠的に起こる問題を特定するのに役立ちます。また、サポート要求に対して情報を公開します。問題のエスカレーションのワークフローは、特に大きなサポートチームにおいて、個々の判断に頼るよりも迅速な問題解決を導きます。あらかじめ用意されたメッセージは、システム停止中にメッセージの一貫性と正確性を維持するのに役立ちます。また、「related to」タグを使うと、問題が解決された後で簡単に報告することができます。

5. プロシージャのトラッキング

適切な手順を講じることで、組織はアプリケーションから発生する可能性のある問題を予測できます。これらのシナリオは、事前に文書化する必要があります。トラブル対応、障害緩和、修復に関する情報は、チームのために文書化されるべきです。この文書には、誰が何をすべきかという職務チェックリスト、緊急連絡先電話番号とオンコール担当者の名前も入れておきましょう。もし可能ならば、模擬停電の訓練が、実際の停電が発生した際の対応に役立ちます。その後、訓練終了後、事後検証チームと一緒に検討し手順を改善してください。別のトラブルが発生した際、プロセスに追加できる情報があれば追加します。上記の他の項目と同様に、ローカルのインフラが利用できなくなる可能性があるため、これらのプロシージャを外部にホストされたリポジトリに格納するか、PagerDutyなどのソリューションで自動化することをお勧めします。

これらは一連のリストの最初のいくつかに過ぎません。トラブル時に有効だったことを記録しておくのは、事前に理解して準備するために費やされた時間と同じくらい貴重です。社内外のステークホルダーとのコミュニケーションはIT業界だけでなく、あらゆる業界にとって重要です。

典型的な技術者はたった1つの質問ですべての課題に対峙します：「私は自分でこの ソリューションを構築できるだろうか？」と。そしてこの質問は重要な考察が得られるので十分考えるに値します。 では私たちは作るべきですか？買うべきですか？ インシデント管理ソリューションの評価は今この問題を招いているようです。 しかし、今インシデント管理プラットフォームを作るべきか、あるいは購入するべきかは、どう分かるのでしょうか？

なぜビルドするの？

独自のソリューションを構築したいという願望が、商用ソリューションの調達権限があなたにないという単純な理由によることもあります。 例えばエンタープライズのITにはツールの予算があっても、DevOpsチームがそれを必要としていたりします。 オープンソースプロジェクトを基にソリューションを構築する方が、商用ソリューションを購入するのに必要な長い駆け引きをするより簡単に思えるかもしれません。 しかし、これは組織的な問題であって、技術的な問題ではありません。 そしてカスタムビルドのソリューションは短命になることがよくあります。

でも独自のソリューションを構築する理由は他にもあります。

現実のまたは既に必要が見えている固有の要件がある

セキュリティとプライバシーに関する懸念がある

コスト

これらは、インシデント管理ソリューションの構築を検討する正当な理由ですが、どれも精査する必要があります。

あなたの要件は本当にユニークですか？ これが当てはまるかどうかを特定する方法は、競合他社と彼らが使っているものを見て、さらに類似の組織と比較して要件を調査することです。同時に、独自の要件があっても、なぜそれがユニークであるのか疑問に思うかもしれません。それって本当に必要なの？と。

セキュリティに関しては、商業的なインシデント管理を使わないようにさせるようなセキュリティとプライバシー上の懸念は何ですか？データが暴露される可能性がありますか？ほとんどの場合、アプリケーションのデータはアラートの中に含める必要はありませんが、そうなっている場合は、検討する必要があります。一般的なセキュリティに懸念があるのなら、ベンダーは自らが常にセキュリティの脅威に敏感であろうと努めていることを知っておいてください。多くの場合彼らはあなたの社内の運用チームよりもセキュリティの面ではるかに優れた能力を持っています。

そして、コストの問題があります。 独自のソリューションを構築する上で最もコストのかかる側面は簡単には数字にならないため、コストの計算は難しいのです。インシデント管理サービスの月額料金と、フルタイムの開発者による一回きりの開発のコストを計算するのは簡単です。しかし、継続的なメンテナンス、機能の変更、および大きな一回切りの開発のコストを予期することは困難です。このソリューションを構築していない場合に、開発者は何をしているんでしょうか？また、開発中に複数のプロジェクトやバックログを脇に置いてしまうコストはいくらですか？構築した人が退社した場合に別の問題が発生します。残されたコードベースを理解するためにまたコストがかかります。組織のインフラストラクチャのミッションクリティカルな部分に関連している場合、知識を持つ人が組織を離れることは望ましくありません。

インテグレー？

インシデント管理ソリューションの構築には、1つに大きな弱点があります。成功したインシデント管理プラットフォームには、ソース（アプリケーションとインフラストラクチャなど）とディストリビューション（コラボレーションツールなど）への統合に関する膨大なライブラリが用意されています。これらの統合を実現するためには開発者は新しいAPIに対して習得し、構築する必要があり、かなりの時間がかかります。独自のインシデント管理プラットフォームを構築する組織は、いろいろなユースケースをサポートする必要がなく、重要な統合を行うだけで済みます。

しかし、これらのシステムのAPIが変更されると、あなたは盲目になる可能性があります。新しい機能を使えず、プラットフォームを完全に壊す可能性があります。オープンソースプロジェクトは、統合の中での変化に、あるいは新しいものを作リ出すために素早く対応することはありません。何か不具合が生じた場合も、開発者はもう別の何かを抱えています。もちろん、インシデント管理システムと統合する必要のあるツールの選択は、チームの規模の拡大とそのニーズの変化に伴って変化する可能性があります。

ビルドする時期

オープンソースプロジェクトを基盤とするカスタムインシデント管理プラットフォームが有用なシナリオがあります。それは特定の目的のためのビルドが必要という、とてもニッチなシナリオです。一般的に、このようなソリューションが必要な組織は、グローバルでの商業的インシデント管理を行っており、ニッチなシナリオのためにインシデント管理プラットフォームのAPIに統合していることさえあります。

もう1つの目的は、アプリケーションまたはインフラストラクチャのサポートとは異なるコンテキストで使用されるアラートのためです。おそらくそのアラートはコラボレーションや製品管理に使用されています。このような場合は、自社で作った他のユースケース向けの責任の低いシステムと、商用およびミッションクリティカルなインシデント管理システムとそのユースケースを分けたほうが有用な場合があります。アプリケーションの使用方法から学ぶことについては同じことが、すでに多くのカスタマイズを行っているチームにも当てはまります。例えば、新しい機能がローンチされたときに、その機能が使用されたらアラートを受け取るということができます。また、新しいインフラストラクチャが配備されたときに、パフォーマンスを示す特定のKPIにヒットしたときにアラートを表示させるように設定することもできます。

もう1つの理由は、内外へのデータ漏えいの懸念がある場合です。例えば、是正措置が個人を識別できる情報を、内部のティア1のサポートに、その人たちには見る権限がないのに晒してしまうアラートです。これは問題であり、特に規制産業では問題となる可能性があります。 ほとんどの場合あなたはプラットフォームでの役割と見られる内容を変更できるため、これは問題にはなりません。一般的に言って、あなたはそれを常に試すようにするべきです。避けられない場合もまれにはあるでしょう。

あなたの輝く時間が来る

熟練した技術者は、自分の興味の範囲を超えて、いつビルドや購入をするのが適切かを判断し問題を解決できるようになります。このソリューションは早速作り始めるべきで、立ち止っていてはいけません。これはカスタムソリューションに伴う長期的なサポートであり、リスクです。ソリューションの作成だけでなく、実行する必要もあります。インシデント管理システムにインシデント管理システムをインストールしているんですか？他の何かの稼働時間を心配することはストレスであり、インシデント管理がダウンすると、何も見えなくなります。

コードベースとインフラストラクチャへのカスタムニッチの統合を理由に、独自のインシデント管理ソリューションを構築することが正当化されることがあります。あるいは、商用インシデント管理と連動する非ミッションクリティカルなユースケースがある場合は、独自のインシデント管理を構築する価値があります。しかし、一般的に商用ソリューションの総所有コスト（TCO）は低く、規模の拡大に合わせてニーズに対応し、特定の専門家が退職したときにツールやプロセスが破壊されないようにし、キュリティとプライバシーに関する懸念にもより良いカバレッジとソリューションを提供します。

ビルドや購入を決定するときは、機会費用に重点を置くことをお勧めします。これはあまり知られていない費用ですが、これを考えると普通はかなり早く答えがはっきりします。

インシデント 管理の主な目的は、インフラストラクチャ に影響を与える問題を特定し解決することですが、インシデント管理業務はそこで停止するべきではありません。

お客様のチケットに反応するだけではなく、アラートシステムが生成する豊富なデータを活用すれば、問題を事前に検出しインフラストラクチャをより弾力的に運用するための洞察を得られます。

ここでは、データの収集と分析の方法、情報を扱う際に探すべき点など、過去のインシデント管理データを扱うための戦略の概要を説明します。

データの保存と標準化

過去のインシデント管理データを分析するための第一歩は、情報を収集して解析する標準化された方法を見つけることです。しかしながら、Screen-Shot-2017-12-14-at-11履歴ログの量と形式がさまざまな監視システムによって大きく異なるため、困難な場合があります。

いくつかの監視システムは、事後に調べることができる記録をまったく残しません。たとえば、Pingdomはリアルタイムモニタリングのための優れたツールですが、昨日のことではなく、今起きていることを伝えるように設計されているので、独自の履歴データをあまり提供しません。

他の監視システムは、限られた期間だけデータを保管したり、扱いにくい形式で保管したりします。たとえば、Snortのデータを分析するにはパケットダンプを調べなければならない場合があります。金曜の夜にWiresharkにハマるのが好きでない限り、やっかいな仕事です。

さらに、多くの監視システムを設置している場合は、違う場所にバラバラにデータをダンプする可能性があります。いくつかのツールはローカルマシン上の/var/logにログを書き出します。ローカルマシンのログは見逃しやすく、メンテナンススクリプトで削除されることもあります。あるいは、一定ではない期間ログをクラウドに保存したりします。これは、すべての履歴データを一度に分析するには理想的とは言えません。

これらの理由から、インシデント管理データを最大限に活用するには、次の2つのことを確実に行う必要があります。

アラートとログを中央の収集ポイントに送信します。モニタリングシステムや ローカルストレージがそれをサポートしていれば、必要に応じてアラートやログを保存できます。 収集ポイントのデータを標準フォーマットに変換し実用的な洞察を抽出します。

これにはLogstash、Splunk、Papertrailなどのツールが役立ちます。 これらは、サイロ化された場所からデータを収集し、中央のストレージポイントに転送できます。

PagerDutyは以上のソースや他のソースからデータをインポートし、標準化されたフォーマットに変換してパターンや傾向を可視化し、データの集中化と相互関連付けを行い、根本的な原因などを特定することができます。

データの表示と分析

データを表示する最も簡単な方法は、Webベースのインターフェースを使用する方法です。ログから特定のイベントを検索したり、インシデントの現在のステータスを監視したりするために使用できる洗練された検索機能が求められます。

Webインターフェースは、小さな傾向の発見、特定タイプのインシデント履歴のトレースから、全体状況の理解まで可能にしてくれます。アラートの表やリストは、システム全体の傾向を理解するのに役立ちません。 PagerDutyがレポートに含めるようなインシデント管理データに基づく可視化は大規模な情報の解釈に役立ちます。

特にプログラムでデータを分析する場合は、必要に応じてログデータをエクスポートできるAPIが重要です。 PagerDutyのAPIを使用すると、必要な形式でログデータを簡単に収集しエクスポートできます（Events API v2では、そのデータをすべて共通の形式に自動的に正規化します）。

何を探すか

データ分析をしたら、次に何を探すべきでしょうか。 監視しているインフラストラクチャのタイプによって異なりますが、一般的に注意すべき点は次のとおりです。

インシデントが発生している頻度。この数が時間の経過とともに変化する場合は、その理由を知りたいでしょう 平均認識時間（MTTA）と平均解決時間（MTTR）。これらの時間を把握することで、チームがインシデント管理をどの程度効果的に処理しているかを知ることができます。 チームの誰が最も多くのアラートを処理しているか。これはメンバーの評価基準になるだけでなく、アラートが適切に配分されているかどうか、そして最適な人に届けられているかどうかの判断基準になります。たとえば、1人の管理者が応分の分担以上のアラートを受け取っているときは調整する必要があります どの監視システムが最も多くのアラートを生成しているか。上記のように、さまざまな監視システムからのアラートを1つのログ記録場所に統合すれば、最も多くの情報を提供しているシステムを特定することができます。システムのパフォーマンスが低下しているかどうか、またはノイズが多すぎるかどうかを確認し、必要に応じてしきい値を調整できます。

これらのヒントに従えば、悲惨な歴史を繰り返すことはありません。

それがインシデント管理がいかに実を結ぶかです。 インシデント対応は治療行為ですが、過去のインシデント管理データを含むフィードバックループを継続的に作成すれば、インシデントの予防も可能になります。

Chef、Puppet、Ansibleのような構成管理ツールの大きな利点は、データセンターを「スクリプト化された」インフラストラクチャに変えることです。人生の時間を無駄にするサーバのプロビジョニングや設定を手動で行う代わりに、構成ツールで自動化することができます。

ただし、これらのツールはインシデント管理を自動化するようには設計されていません。他のIT業務がスクリプト化されているときにインシデント管理だけを手動で処理する理由はありません。インシデント管理もスクリプト化されたルーに統合すべきです。インシデント管理のためのスクリプト化されたインフラストラクチャアプローチを採用することで、監視とアラート管理だけでなく、残りの操作も拡張できます。

問題

まず、インシデント管理に対するスクリプト化されたインフラストラクチャアプローチが非常に重要である理由について説明します。

まだ手動でインシデント管理、自分を責めないでください。あなたは悪い管理者ではなく状況の犠牲者です。最近まで自動化されたインシデント管理ソリューションは、Chefのようなインフラストラクチャ管理ツールを容易に利用できませんでした。

インシデント管理の要件も、今日のように常に複雑ではありませんでした。10年前のデータセンターには、たいていの場合、数十台のオンプレミスサーバがあり、手動でインシデント管理を処理できました。

しかし今日、インフラストラクチャは、拡張性と迅速な製品革新の要求から、ますます複雑なものになっています。オンプレミスのベアメタルサーバがあり、ローカル仮想サーバがあります。クラウドサーバ、コンテナ、モバイルデバイスもあります。IoT革命が本格化した今、まもなく冷蔵庫と電子レンジとパーキングメーターを追加する必要があるかもしれません。

これらすべてのデバイスでインシデント管理を効果的に実行したい場合は、可能な限り反復的な手作業を排除する必要があります。これを実現するには、急増するデータセンターインフラストラクチャの構成を自動化するのと同じ方法で、自動化およびスクリプト化が可能な次世代インシデント管理ソリューションが必要です。

ソリューション

スクリプト化されたインフラストラクチャの時代にインシデント管理を効果的に処理するためには、

適切な人にアラートを自動的にルーティングする。適切な人に問題を通知するのに手作業が入れば、プロセスは壊れてしまいます。

インシデントを自動的にエスカレーションします。ここでもまた、人々が行動を取ることを忘れ、特に巨大なインフラストラクチャを持っている場合は、人間が手作業で問題を再割り当てするのを待つことはできません。ChefとPuppetがサーバーを自動的に構成するのに十分なほどスマートなのと同じように、あなたのソフトウェアはあなたのために十分にスマートである必要があります。

スケーラブルにアラートの動作を管理します。インフラストラクチャスクリプトツール便利な理由の1つは、既存のリソースを最も効率使用することに優れているからです。彼らは、クラウド内のどこに仮想サーバを配置すべきかを知っています。同じように、インシデント管理ツールは、アラートを適切なサービスやチームに自動的にグループ化し、無駄なアラートは抑制してルーティングすることができるため、ノイズが減り応答時間が短縮されます。

ChatOpsと統合することで、インシデント管理作業から通信プロセスを切り離すことなく、チームがインシデント対応に協力できるようになります。さらに、チャットボックスを通じて、ChatOpsは特定のレスポンスタスクを自動化するのに役立ちます。

すべての監視ニーズをサポートします。AWS Cloudwatch、Nagios、Pingdomなど、複数の監視ツールを利用している可能性があります。インシデント管理をスケーラブルかつ自動化するために、これらのツールは手動による介入なしで連携する必要があります。すべてのソースからのアラートを自動処理するインシデント管理戦略で、あるアラートだけを除外するのは、他のすべてのインフラストラクチャをPuppetで構成しながら1つだけ手動でプロビジョニングするのと同様に問題があります。イベントを自動化されたワークフローに変えることができるソリューションで、すべてのツールを集中管理することが重要です。

100％の稼働。私はオンプレミスの通知だけに頼ることが悪い考えであることを思い出すために、この点を常に念頭に置いています。私はNagiosを愛していました。しかし、今日、アラートを届けるためにローカルで稼働するNagiosのようなツールだけに頼っていると、インフラストラクチャに問題があった場合、インシデント管理システム自体がダウンするリスクがあります。Nagiosを使用するのは良いことですが、残りの監視システムからのアラートを、インフラストラクチャの問題の影響を受けない集中型のクラウドベースのインシデント管理ソリューションに供給する必要があります。

レガシーなアラートと監視システムだけで作業していた場合、上の要求リストはファンタジーのように見えるかもしれませんが、そうではありません。スクリプティングされたインフラストラクチャがデータセンターを自動化するのと同じくらい効果的に、すべてのイベントに対して迅速なレスポンスワークフローを自動化するインシデント管理ソフトウェアがここにあります。あなたの仕事をはるかに生産的で効果的なものにするために、今はそれを活用する時です。

※このコンテンツは www.pagerduty.com/blog/ の抄訳です。

近年、1年で最も忙しいショッピングデー「ブラック フライデー」(注）にシステム障害が多発しています。

有名ブランドのWebサイトの停止やシステムトラブルの記事を目した管理者は、他人事とは思えないでしょう。大規模な小売業者でもスムーズにインフラストラクチャーを稼動させるのに苦労しているというのに、中小企業はどうすれば障害を防止できるでしょうか。

幸いにも、手はあります。適切なインシデント管理手順に従うことで、小規模のチームでも必然的に起こる業務の中断による影響を最小限に抑えることができます。

ここでは小売業者のニーズに焦点を当てて解決法を紹介します。

（注；ブラックフライデー（英語: Black Friday）とは、小売店などで大規模な安売りが実施される11月の第4金曜日のことである。 アメリカ合衆国では感謝祭（11月の第4木曜日）の翌日にあたり、正式の休暇日ではないが休暇になることが多い。当日は感謝祭プレゼントの売れ残り一掃セール日にもなっている。買い物客が殺到して小売店が繁盛することで知られ、特にアメリカの小売業界では1年で最も売り上げを見込める日とされている。また、年末商戦の幕開けを告げるイベントでもある。 ）

小売業者の優先順位の定義

小売業者の効果的な監視とインシデント管理を行うために、管理者はまず、インフラストラクチャの可用性と稼働時間に関して小売業者の最も重要な要件が何であるかを理解しなければなりません。

実店舗とオンラインショップの両方を備えた最新の小売業者にとっては、以下を確実に行うことが不可欠です。

顧客がアクセスするWebサイトを常に正常に稼動させる。** 顧客が接触するサイトがパブリックなインターネット上にあり、DDoS攻撃など悪意のあるトラフィックスパイクからクラッシュする可能性や不正侵入の脅威があるからです。Webサイトは販売促進のために実店舗のみの小売業者にも不可欠です。顧客は通常、オンラインで購入するか店舗に足を運ぶかにかかわらず、購入を計画するためにWebサイトを使用します。

バックエンドシステムの稼動を維持する**。在庫の追跡やトランザクション履歴の保存などのタスクを処理するバックエンドサーバも、ビジネスオペレーションにとって不可欠です。一般にバックエンドサーバはプライベートネットワーク上で実行できるため、パブリックサイトよりも攻撃者から保護しやすいですが、一方で別の脆弱性も持っています。非常に機密性の高い情報が保管されていたりするので、効果的なモニタリングが不可欠です。

POSシステムの安定稼働を確保する**。小売業者はPOS端末がクラッシュした場合、販売を続けられなくなります。POSシステムを稼働させ続けるには、ローカルネットワーク接続から物理的なセキュリティ、さらに電源供給まで、複雑な変数の組み合わせを効果的に管理する必要があります。

IoT資産を保護する**。小売業もIoTを活用してワークフローをパーソナライズし、自動化することでデバイスとセンサーの安定稼働と接続性を保証し、業務を強化します。高度に自動化されたIoTデバイスベースのビジネスオペレーションへの移行は、システム監視の分野でも新たな課題となります。

これらは、取引完了を確実にするための小売業者の第一の要件です。ここでは、監視とインシデント管理を使用して重要な課題に対処する方法について説明します。

システムダウンの防止

小売業のシステムインフラの重要な部分を円滑に運用するためのガイドラインを紹介します。

インフラストラクチャ全体の可視性を最大化する**。非常に多くの要素があるため、小売業者は特に複雑で多様なITインフラを持つ傾向があります。それはWebサイトだけでなく、バックエンドシステムや各種専用デバイス、センサーなども含みます。このようなインフラストラクチャを把握するために、全面的な可視化が必要です。監視情報はそれを理解する唯一の方法であるため、1カ所に集中させる必要があります。

柔軟な監視ソリューションを導入する**。多様なインフラストラクチャには、多様な監視ツールが必要です。小売業者は、インフラストラクチャのさまざまな部分にすべて監視エージェントをインストールし、収集した監視情報を中央の管理プラットフォームへ転送し、正規化する必要があります。

リアルタイムに対応する**。小売業者にとっては、販売サイトやPOSシステムの数時間（またはわずか数分）のダウンタイムが非常にコストの高い影響を与えます。ダウンタイムの直接的な結果として失われた売上に加えて、企業も評判にも損害を与えます。したがって、影響は数カ月続く可能性があります。これらのリスクを軽減するために、インシデント管理システムとワークフローが鋭い洞察を基にしたリアルタイム応答を可能にし、サービスができるだけ迅速に復元されるようにする必要があります。

効果的コミュニケーションを図る**。小売業におけるインシデント管理の課題のひとつは、企業のインフラストラクチャが、特に店舗や倉庫の大規模なネットワークを持つ小売業者にとって、非常に大きく広く分散する傾向があることです。インフラストラクチャの稼動を維持する管理者も分散しがちです。この課題に取り組むには、シームレスなコミュニケーションツールを提供するインシデント管理システムが必要で、ChatOpsなどの共同作業ワークフローを活用すべきです。そうすれば、広範囲に広がった大規模な管理者チームでも、問題を解決するときに効果的にコミュニケートできます。

ダウンタイムをもたらす脅威を完全に排除することは決してできないと言っても過言ではありません。しかし、最新技術による監視とインシデント管理のソリューションは、小売業者が大規模なサービス障害の話題の提供者にならないために重要な役割を果たします。

2018年、サーバインフラストラクチャはハイブリッド化されているでしょう。 インシデント管理ソリューションもハイブリッド環境への対応が必要です。オンプレミスサーバのみを管理する場合、仮想ネットワークやマイクロサービスが混在していない場合は、インシデント管理は簡単です。しかし、そんな時代はもう終わりました。

今日、ほぼすべてのインフラストラクチャは、ある意味でハイブリッドなのです。 オンプレミスのサーバとデバイスは、パブリックまたはプライベートクラウドとシームレスに稼働します。ネットワークは物理層から抽象化されています。ストレージはスケールアウトされ、多くのサーバに分散しています。複数のデータセンターに分散配置されているかもしれません。

この環境で管理者がすべきことは何でしょうか。簡単なのは、ハイブリッド対応のインシデント管理ソリューションを採用することです。では、今日のハイブリッドインフラストラクチャのインシデント管理を最適化するためのヒントをお教えしましょう。

ハイブリッド環境におけるインシデント管理の課題

ハイブリッド環境におけるインシデント管理に特徴的な課題を説明しましょう。

インシデント管理チームは、インフラストラクチャ全体に物理的にアクセスするとは限りません**。インフラストラクチャが複数のデータセンターにまたがる場合や、クラウドを含む場合、管理者がアラートを発呼するデバイスと同じ場所にいない可能性があります。 すべてのインフラストラクチャを完全に制御することはできません**。パブリックまたはプライベートクラウドは、他の誰かのサーバ上にホストされている可能性があります。 物理デバイスは抽象化されています**。その結果、アラートがソフトウェアの問題、ハードウェアの問題、またはその両方によって引き起こされているかどうかを判断するのが難しくなります。たとえば、仮想サーバ上のファイルシステムの問題に関するアラートの原因には、ホスト上のディスクのハードウェア障害、ゲスト上のソフトウェアファイルシステムのエラー、またはその組み合わせなどがありえます。 インフラストラクチャは変化します**。新しいデバイスが追加または削除されたり、ストレージが拡張されたり、コンテナがスピンアップやスイングしたりするなど、絶えずスケーリングされています。

ハイブリッド環境の課題を解決する

ハイブリッドインフラストラクチャインシデント管理戦略を計画する際に考慮すべきいくつかの提案を示しましょう。

原因に応じてアラートをルーティングできるインテリジェントなインシデント管理プラットフォーム（PagerDutyなど）を採用します。そうすれば、あるデータセンターで生成されたアラートは、別の場所のチームではなく、そのデータセンターを管理している管理者に確実に届きます。 柔軟な監視とアラート設定を提供し、既存の環境と容易に統合できるインシデント管理プラットフォームを導入します。これにより、インフラストラクチャのさまざまな部分にさまざまなツールを統合できるようになり、その特定の部分に最も適したツールが決まることになります。パブリッククラウドサーバでは、AWS CloudWatchを使用することができ、Nagiosはオンプレミスサーバを処理できます。SnortまたはOSSECはネットワークイベントを監視できます。PagerDutyを例にとると、既存のハイブリッドインフラストラクチャと統合できる150以上のインテグレーションがすぐに利用できます。 すべてのアラートをセントラルハブに送信します。複数の監視プラットフォームを使用している場合は、アラートをグループまたはクラスタで一緒に表示する必要があります。さもなければ、管理が困難になり、関連する問題の間のリンクを導き出すことが不可能になります。PagerDutyのようなプラットフォームは、ハイブリッド環境全体からさまざまなアラートを受信して正規化する集中ハブを提供しこれを解決します。 インシデント管理ソリューションが拡張できることを確認します。インフラストラクチャのサイズは一定ではないため、アラートの変化する量を受信して格納できるプラットフォームが必要です。 ベンダー依存は推奨できません。特定のオペレーティングシステムやベンダー製品のみをサポートするインシデント管理ソリューションは、ハイブリッドインフラストラクチャでは機能しません。ハイブリッド環境は、通常、さまざまなハードウェアとソフトウェアのコンポーネントで構成され、部品をすばやく交換できるのが利点です。 PagerDutyのようなソリューションは、ベンダー固有の監視ソフトウェアと統合し、柔軟なインシデント管理インターフェイスを使用してアラートを変換できるためハイブリッド環境でも便利に使えます。

以上の課題のいくつかは、まだハイブリッド化していない組織にとって今のところまだ重要ではないように思えるかもしれません。しかし、明確な傾向はハイブリッド環境にに向かっています。 インフラストラクチャを監視する能力に影響を与えることなく、インシデント管理ソリューションを早期に準備すれば、ハイブリッド環境に完全に移行できるようになります。

注）インシデントとアラート

インシデントの定義は、

「システムの運用を通して提供されるサービスの中断、サービス品質の低下、 またはその可能性がある出来事」、つまり、「ディスクの使用率があらかじめ決めたしきい値を上回った」などの、システム利用者には影響がなくても、サービスの品質が落ちる可能性がある出来事もインシデントとなります。

アラートとは監視システムが、そのシステムの監視対象のある定量情報（メトリック）があらかじめ設定されたしきい値と超えた場合に管理者に送る通知を指します。ある1つのアラートまたは複数のアラートの組み合わせが1つのインシデントの予兆または症状として発生します。

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

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

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

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

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

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

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

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

素敵なJavaScriptはある？

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

同期 vs. 非同期

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

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

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

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

判定

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

引き継ぎ

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

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

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