Blog
ブログ

インシデント 対応のボトルネック―今お使いのインシデント 対応システムでは少ないかも知れませんが、確かに存在することをご存知でしょう。オンコールのチームやお客様のためにボトルネックは最小限に抑える必要があります。最も重大なボトルネックのいくつか、およびそれらを回避する方法を見てみましょう。

あなたの目標は何ですか?

まず、プロセスのボトルネックを理解する前に、そのプロセスの目標が何かを理解する必要があります。インシデント対応の目標は何でしょうか。

ほとんどのインシデント対応チームにとって目標はおそらく次のようになります。

インシデントの発生を防ぐ**。 インシデントの予防は、問題解決を主な目的とするインシデント管理の手には余る可能性がありますが、予防は計画外の作業を削減するために重要です。 損害を最小限の範囲にとどめる**。実際には、インシデント管理における予防的取り組みの大部分はこの点に焦点に当てられています。インシデントが発生しないようにすることができない場合でも、インシデントが広がらないようにすることができます。 インシデントを迅速に解決する**。全てのインシデントを解決できるわけではなく、全ての修正が根本的な問題を解決するわけではありませんが、迅速なインシデント解決は一番重要です。

各ボトルネックを監視する

上記がインシデント対応の基本的な目標である場合、ボトルネックはそれらの目標を達成することを困難にします。これらの中で最も重要なものは次のとおりです。

優先順位を適切に設定できない

優先順位付けは、インシデント解決とインシデントの影響の封じ込めに利用できる最も重要な手段です。深刻な影響の可能性に基づいて、最も注意が必要なインシデントに焦点を当てることができます。インパクトが比較的少ないインシデントは脇に置いておくこともできますが、それでも多大なチームの時間と注意が取られます。適切な優先順位を設定しなかった場合、重要なインシデントの一部が速やかに処理されない、あるいはまったく処理されないことがあります。

過負荷とアラート疲れ

対応チームがアラートの量に圧倒された場合、どの問題を優先すべきか判断する時間がないため、または真のインシデントをノイズのアラートから見分けることができず、麻痺して全てに対応することができなくなります。これは慢性的なアラート疲れにつながる可能性があります。チームメンバーが無意識にほとんどのアラートを無視する精神状態に陥るため、僅かなインシデントにしか集中できなくなります。

アラートのノイズをフィルタリングするための（典型的には自動化された）システムが絶対必要です。対応不可能なアラートを抑制し、関連するアラートを1つのインシデントにグループ化する必要があります。理想的には、これはルールを介して自動的に行われるべきです。さらに、アラート疲れや報告忘れが致命傷になる可能性があるため、チームメンバー全員にアラートするのではなく、適切なチームやチームメンバーだけにアラートを送るシステムを導入することが重要です。

不十分な準備、訓練、経験

理想的には、全てのインシデント対応チームは、問題を迅速に診断でき、各インシデントを修正するためにどのツールとテクニックを使用すべきかを理解している、高度に熟練した技術者で構成する必要があります。

このような問題を最小限に抑える最良の方法は、インシデント対応者のための正式なトレーニングシステムを用意すること、新しいチームメンバーは可能な限り経験豊富なチームに配属すること、チームに適切なドキュメントを用意することです。一貫性と再現性の高いベストプラクティスを実現するためのドキュメントには、基本的な手順のマニュアルや、索引付きで簡単に検索できる相互参照の効くデータベース（過去のインシデントなど）が含まれている必要があります。

メジャーな新製品のロールアウトに対する不十分な準備

メジャーなアプリケーションのリリースの際―それは全く新しいアプリケーションやサービスかもしれませんがー開発者がいくつかの重大なバグを見逃して大量のアラートが押し寄せる事態に対応チームは備えておくべきでしょうか。結局のところマーフィーの法則はいつでも有効です。それが起こるのは広く使われているプログラムのアップデートや、1つ2つのバグが絡みあったトレースしにくいエラーを発生させる場合です。対応チームが準備できていない場合、時間とリソースの全てが優先順位の高いアラートの暴風に巻き込まれ、関連性のないその他のインシデントを処理するための余裕はほとんどありません。

もちろん、リリース前にA／Bテストやカナリアテストなどでアップデートが適切にテストされていることが理想的です。応答チームが配備作業に加わっていれば、問題がはるかに小さなうちに対処できる機会があります。しかし、限定的な導入から始めるという決定をインシデント対応チームが下すのは不可能であり、十分にテストされていないリリースに対処しなければならない可能性があります。

このような状況では、全ての対応者をオンコール待機にするか、アップデートで起こる全ての問題を処理する特別なチームを指定する必要があります。どのアプローチが最も効果的かは、少なくとも更新の範囲と利用可能な対応チームのリソースによって決まります。しかし、計画はいつでも何度でも必要に応じて変更できますし、計画を立てておけば準備ができていない場合とは大違いになります。

ボトルネックの解消

他にも、時代遅れの障害が発生しやすいインフラや過負荷のインフラから生じるインシデントや、インシデントとは無関係のタスクで対応チームの時間が取られるなど、多くのボトルネックがあります。しかし、私たちが列挙したボトルネックは、インシデント対応チームが時間を消費した理由の多くを占めており、ここで提案した修復アプローチは、それらの大半をなくすのに役立ちます。

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

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

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

データの保存と標準化

過去のインシデント管理データを分析するための第一歩は、情報を収集して解析する標準化された方法を見つけることです。しかしながら、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/ の抄訳です。

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

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

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

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

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

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

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

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

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

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

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

インシデントの定義は、

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

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

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

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

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

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

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

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

DevOpsにとっての利益は？

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

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

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

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

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

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

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

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

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

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

			インシデントを作成する


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


		
		
			モバイルアプリ


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


		
		
			アラートと通知


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


		
		
			インシデントの詳細


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


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


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


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

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

DevOpsのへの移行で、一連のサイロからなる ソフトウェアデリバリーチェーンがなぜ悪いのか理解されるようになりました。 サイロは異なるチーム間のコミュニケーションを複雑にし、デリバリー遅延や手戻り、バグにつながります。

インシデント管理においては、あるベンダー製品の管理データと別のベンダー製品の管理データを分けるというサイロがあります。このサイロは、複数ソースからの監視データの収集と分析を困難にするため、インシデント解決を妨げます。

インシデント管理業務を効率的に流していくために、サイロをどのように分析していますか？

サイロを特定する

インシデント管理での作業の最初のステップは、サイロが最初に存在する理由を理解することです。

理由は簡単です。現代のインフラストラクチャは、多様なハードウェアとソフトウェアで構成されています。ほとんどのコンポーネントには特別な監視が必要です。特定のリズムに従って情報を特定の形式で出力し、特定の方法でデータを収集する必要があります。したがって、インフラストラクチャの各部分に関連する監視情報は、インフラストラクチャの他の部分からのデータと容易に比較できないため、サイロの中に入ってしまいます。

基本的な例として、Windowsを実行する10個のベアメタルサーバと、Linuxを実行する10個のベアメタルサーバで構成されるデータセンターを考えてみましょう。このシナリオでは、Windows用とLinux用の異なる監視ツールを必要とします。ホストが落ちていないかどうかなど、各タイプのオペレーティングシステムに関する監視情報の一部は同じですが、他のデータには違いもあります。そのため、各OS専用のツールでデータを収集する必要があります。したがって、Windows、Linuxそれぞれが専用ツールでデータを監視するエコシステムを備えた明確なサイロになります。

これは単なる例です。モニタリングする2種類のベアメタルサーバだけでなく、各種のハイパーバイザ上で実行される仮想サーバ、各種デスクトップOSを実行するワークステーション、いろいろなモバイル機器やモバイルOS、バージョンなど実際の現場ではさらに複雑になります。

サイロを壊す

シームレスで全体的な監視の可視性を得るために、インフラストラクチャ内の各監視コンテキストを分離するサイロをどのように排除するか。このソリューションには2つの部分があります。

ステップ1：データ収集の集中化

最初のステップは、さまざまなタイプの環境から情報を収集し、その情報を中央の場所に転送できるインシデント管理ソリューションを実装することです。 こうすればエンジニアはインフラストラクチャ全体を1点で監視することができます。 インフラストラクチャのさまざまな部分を監視するために個々のサイロを調べる必要はありません。

集中型のデータ収集には、複数のソースからの監視情報を集約するのに十分な機能を持つインシデント管理ソリューションが必要です。 これは簡単な作業ではありません。 幅広い環境とエンドポイントをサポートするためには、さまざまなタイプの監視システムと統合する必要があります。

ステップ2：データを翻訳する

2番目のステップは見落としやすい点です。インシデント管理チームは、多くの監視ツールのデータを集約し一元管理することに加えて、すべてのデータを一貫したフォーマットに変換する必要があります。

すべてのエンジニアがあらゆるソースからのアラートを解釈して対応できることを保証する唯一の方法は、データ変換だけです。データが共通のフォーマットに翻訳されない場合、エンジニアは特定のタイプの監視システムに必要な特別の知識を持たなければならないか、または特定ベンダーのスキーマを知ってそのシステムから発生したデータを理解する必要があります。このように、中央の場所ですべてのデータを利用できるようにするだけでは、複数のシステムを隔てる大きな障壁が依然として存在するため、サイロを分解することはできないでしょう。

たとえば、ZabbixとNagiosで「エイリアス」という用語の使われ方を見てみましょう。以前の監視システムでは、エイリアスは基本的に各種コンフィギュレーションの略語として機能します。対照的に、Nagiosでは、エイリアスはホストの名前です。この違いを理解しないまま、ZabbixシステムとNagiosシステムの両方のデータが集中ダッシュボードに集約されていたら混乱するでしょう。

効果的なインシデント管理のためには、ベンダーやプラットフォーム固有の用語を単一の言葉に置き換えるソリューションが必要です。 PagerDuty Common Event Formatで有効になっているようなイベントの正規化だけで、レスポンダは複数のソースからのデータを簡単かつ正確に解釈できます。

現代のインフラの複雑さは、サイロを避けることを困難にしています。しかしそれは、監視情報がサイロの中になければならないということを意味するものではありません。さまざまなソースからの監視情報を集約し、オンコールチームの誰でも理解できる言語に変換することで、インシデント管理チームはインフラストラクチャ内に存在するサイロを分解することができます。彼らは、シームレスなコミュニケーションと、機敏なインシデント対応が可能になります。

ビッグデータはもう古い。 今日、データを効果的に活用するための鍵は、ファーストデータです。

大量の監視情報の収集と分析を伴う従来のインシデント管理ではもはや十分ではありません。 また、監視データの収集だけでなく それをリアルタイムで実行する「ファーストモニタリング」が必要とされています。

ここでは、ファーストモニタリングが意味することを検証し、インシデント管理チームがこのアプローチを実装して大きなメリットを実現する方法について説明します。

ファーストデータの定義

ファーストモニタリングの概念を理解するためには、ビッグデータの世界で最も新しいイノベーションの1つであるファーストデータを理解する必要があります。

非常に簡単に言えば、ファーストデータは高速にビッグデータを処理することです。 ビッグデータとは、伝統的に大量の情報を保存して後で分析することを意味しますが、ファーストデータとは、大量の情報をできるだけ速く、理想的にはリアルタイムでデータ分析を実行することを意味します。 その目標は、できるだけ実用的で関連性のあるデータを分析することです。

ソースから分析プラットフォームにデータをストリームするのは、ファーストデータを活用する上で重要な部分です。 これが、Apache Sparkのようなビッグデータツールが近年普及している理由です。 ストリームデータの収集とインメモリ処理をサポートすることにより、Sparkは非ストリーミングやハードディスクによるデータ解析プラットフォームよりもはるかに高速で大量の情報を取り込み、分析できます。

ファーストデータとインシデント管理

インシデント管理はデータ分析とは異なる分野ですが、インシデント管理者はファーストデータへの移行トレンドから多くのことを学ぶことができます。 インフラストラクチャの監視とインシデント管理の世界では、大量の監視とアラートのデータをリアルタイムで分析してレスポンスを向上させることが、これまで以上に重要になっています。

伝統的なインシデント管理から迅速なインシデント管理まで

ファーストデータとファーストモニタリングのつながりは偶然ではありません。多くの点で、インシデント管理の進化はデータ分析の進化を反映しています。

約10年前までは、インフラストラクチャのデータは比較的小さくて済んでいました。ほとんどの組織では、それほど多くのデータを生成しなかったため、ペタバイトクラスのデータを分析する必要はありませんでした。同様に多くの組織は、大規模で多様なインフラストラクチャをサポートできる監視ソリューションを必要としませんでした。代わりに、サーバやワークステーションからなる比較的小さくて複雑ではないネットワークをトラックするためのベーシックな監視システムで済んでいました。

そして、2000年代半ばには、データとインフラストラクチャの両方が大幅に拡大し始めました。すべてをデジタル化することで、組織は大量の情報収集を開始し、ビッグデータを生み出しました。その一方で、モバイルデバイスの普及、仮想化の台頭、さらにますます強くなるコンピューティングパワーの必要性は、インフラストラクチャをはるかに大きく複雑にしました。この新しい状況には大規模なモニタリングが必要でした。

そして、ここ数年の間に、もうひとつの変化が起こっています。情報が絶えず変化している時代には、ほんの数時間の分析の遅れでもデータの価値が損なわれます。同様に、最新ではない情報を監視することに基づいてインシデント管理を実行することにより、管理者はインシデントを迅速に処理して対応することができなくなります。

したがって、ファーストデータとファーストモニタリングには異なるツールセットが必要な場合がありますが、両方の動機と原則は同じです。インシデント管理チームがインフラストラクチャとアプリケーションをできるだけスムーズに稼動させようとファーストモニタリングに専念するのは、データアナリストの仕事とよく似ています。

ファーストモニタリングの促進

情報の収集と迅速な対応は簡単に聞こえるかもしれませんが、実際にはどのようにしてファーストモニタリングを行うことができるでしょうか。主なガイドラインは次のとおりです。

データ収集を一元化する:** 迅速に情報を監視するためには、すべての監視データを中央のインターフェイスに転送する必要があります。これにより、異なるダッシュボードや監視システムを切り替える必要がなくなり、時間と精神的なエネルギーを無駄にするだけでなく、根本原因を理解することが非常に困難になります。 利用可能なすべての情報を収集する:** 伝統的なインシデント管理は、マシンのデータとアラートの収集だけに集中する傾向があります。その情報は、迅速な監視を行うために必要なものの一部を提供しますが、可能な限り迅速にインシデントに対応するためには、可視性と洞察力を可能な限り広げるべきです。たとえば、チケットやサポートコールから人間が生成したデータを収集することを無視してはいけません。これは、PagerDutyのカスタムイベントトランスフォーマーなどの機能を活用して、従来はインシデント管理ワークフローの一部ではないソーシャルメディアチャネルなどのソースからデータを収集することも意味します。 ノイズを最小限に抑える:** 大量のアラートを受け取っても、アクションを必要とするのはそのうちの一部だけです。 したがって、警告の数が最小限になるようにノイズをカットし、対応不要なものを抑止することは絶対に重要です。重複するアラートは自動的に排除されるべきであり、解決が必要な単一の問題に関連する症状をグループ化するのは簡単なはずです。これにより、注意を必要とするアラートの瞬時識別が容易になり、リアルタイムで適切な応答ワークフローが開始されます。 データを解釈しやすくする:** 大量の監視データを収集し、中央の場所に格納することで、そのデータをすぐに価値に変えることができます。 しかし、ダッシュボード上の情報を分析する負荷を軽減するには、さまざまなソースからのデータを一貫した形式に正規化する必要があります。 そうすれば、さまざまなベンダーのすべてのスキーマを暗記する必要はありません。 これを実現するには、さまざまな形で情報を取得し、フィールドを普遍的なものに標準化し、即座に実行可能でわかりやすい洞察を与えるインシデント管理ソリューションが必要です。

これらのプラクティスはすべて、重大な事故の際にインシデント管理者が必要とする手動分析の量を最小限に抑えます。 また、アラート収集とアクションの間隔を最小限に抑え、インシデント管理スタッフがインシデントに素早く反応し、ファーストモニタリングをリアルタイムレスポンスに変えて正常稼働時間を向上させます。

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のような通知を集中管理するソリューションを実装することで、既に導入済みの監視ツールからさらに多くの価値を引き出せます。

メールアラートを改善したいですか？ もう一度考えてみましょう

監視システムは、稼働中のシステムをより効果的に管理するのに役立ちます。しかし、早期に問題を特定するためにチェックとしきい値を設定するのに多くの時間を費やしたとしても、アラート自体にはインシデント対応プロセスと同じくらいの意味しかありません。 PagerDutyがお客様の声を聞いてきた中で発見した最大の課題の1つは、どのお客様もメールアラートに悩まされているということです。 受信トレイがぐちゃぐちゃになって大切なものを見逃してしまいがちだと気づいていながらもなお、多くの監視システムとIT運用チームはメールアラートに依存しています。 メールアラートを改善しようとしていますか？ もう一度考えみてください。それでもまだこのまま使い続けようとお考えのあなたに、メールによるアラートをやめてしまった方がいい理由を5つお教えしましょう。

1. メールアラートは見過ごされやすぎる

「ねえ、友達が私にメールで送った最新の猫のビデオを見ましたか？」

受信トレイを常に見ていても、重大なアラートが他のアラートや仕事関連のメールに紛れてしまうのは日常茶飯事です。 このため、優れたオペレーションチームは、通常、少なくとも2つの通知チャネルを使用します。ひとつは、電話またはSMSメッセージです。 音でアラートを知らせることは間違いなく気づくのに役立ちます。

2. メールで誰かを確実にアサインすることはできません

「えーと、この件誰か対応してる？」

深刻なインシデントへの対応では時間が重要であり、チームの誰が対応に当たることになるのかで混乱している場合ではありません。アラートが複数の人にメールで送信されている場合、チームの誰が最初に応答するかを知る方法はありません。 他の誰かが既にそのメールを見て対応しているのか、自分はそのアラートに対応するのに最も相応しいのか、それとももっと経験豊富な人を待つべきだろうか。 優秀なオペレーションチームは、各インシデントが最適な担当者に自動的に割り当てられるようにします。 インシデント管理ツールとチケットシステムは、オンコールのエンジニアを自動的に割り当て、割り当てたエンジニアのステータスを追跡することにより、このワークフローを実行させます。

PagerDutyではオンコールのスケジュールに従い、すぐに対応に当たる人を決定してインシデントを割り当てます。

3. メールを集約またはバンドルすることはできません。

「これ、止められないのか？」

アラートの嵐が吹き荒れる。スタッフが対応を誤ると、すべての監視システムが毎分何度もアラートを送信します。膨大なアラートは受信トレイをたちまちあふれさせて、事実上使用できなくなります。 PagerDutyでは単一インシデントのアラートは1つに集約し、複数インシデントのアラートは、それぞれの最初の通知の後にまとめて通知します。したがって担当者が受け取るアラートは一度だけです。また、ダッシュボードにより現在進行中のインシデントの数とその出所を簡単に把握することもできます。

4. メールは状況を可視化してくれません

「現在のステータスはどうなってるんだ？」

メールでは、誰がインシデントに対処しているのか、経過時間、最新の状況の把握などは難しいです。この情報はチームだけでなく、経営幹部やその他のビジネス関係者にも重要です。あなたが対応している最中に、状況を知りたい人々に絶えず質問されるのも迷惑です。インシデントをPagerDutyのようなシステムに取り込むことで、管理者だけでなくチーム全員がアクセスできる単一のダッシュボードですべての情報を取得できます。 CEOやCTOがこれで問い合わせを控えてくれるとは限りませんが、少なくとも自分で情報を入手できる方法を伝えることはできます。

5. メールアラートでメトリクスを作成することはできません

「僕ら、うまくやれてる？」

優れたオペレーションチームは、パフォーマンスを継続的に測定、評価、改善するためにメトリクストラッキングを採用しています。全てのメトリクスをメールからトラッキングすることは非常に困難です。インシデントが発生した時刻、最初の人が気付いて応答するまでの時間、チームが解決するまでの時間などをトラッキングすることは、完了予想時刻を管理する上で大切になってきます。このデータを使用して作成したチームのパフォーマンスを示すダッシュボードと週ごとのレポートで、チームや企業内のコミュニケーションを容易にすることができます。

メールアラートの問題は、今まさにあなたが直面している課題かもしれませんが、それはあなただけの問題ではありません。

あなたは解決不可能なチケットを受け取ったことがありますか？Stack Overflowを隅から隅までじっくり読み、時には机に顔を打ち付けながらGoogleで何時間も過ごす。 4時間が過ぎたあたりから問題を解決することはプライドの問題になってきます。生産性は最低！ こんな時こそ、あなたの正気を保つために効果的なインシデント管理プロセスが必要です。

誤解しないでください。他の誰も巻き込まずに解決したいというお気持ちは分かります。うぬぼれだったり羞恥心だったり、はたまた純粋に誰にも迷惑をかけたくなかったり、私もいつもそんな感じですから。 私の場合は問題解決偏愛症のようなものですが、こと自分のプロジェクトの健全さとなると、規定のプロセスに従った方が皆ハッピーになれるようです。

優先順位をつける

いくつかの問題は本物であり、あるものはそうではありません。 すべての問題がミッションクリティカルなわけではないので、チケットがあなたに回ってきたとき、最初のステップはそれがスタックのどこにあるかを決定することです。 あなたとチームメンバーが管理している他のバグやもろもろの要素の中にその場所を見つける必要があります。 詳細なインパクトレポートを作成し、関連するプロジェクトマネージャーたちに相談して決定を導きます。

再現

再現可能なバグは修正可能なバグです。 優先度の高い問題がキューの一番上に達すると、次のステップはそれを再現するステップをコンパイルすることです。 ユーザーが誤ってクラッシュを引き起こしていますか？ たぶんそれはメモリまたはストレージの問題です。 重要なことは、あなたがやろうとしているのは、どうすれば問題を再現できるのかを理解することで、解決法ではないということです。 いったんそれを再現することができれば（または容易に再現できないことを知ると）、修正することができます。

エスカレーション

問題を再現できるようになると、次のステップは適切な専門家を特定することです（ヒント：それはあなたかもしれません）。 問題の性質に応じて、誰の肩を叩くのかを知るのは難しいかもしれませんが、実際にその特定の機能について最後に作業した人に尋ねるのがよいでしょう。 誰に問題をエスカレーションするかにかかわらず、これまでに学習したすべての詳細なレポートを必ず含めてください。 感謝してもらえますよ。

調査

さて、これで問題は少しは見えてきて、あなたの作業リストに入ることになりました。 次のステップは、問題を調査することです。 これは、問題を再現し、ログを収集し、その分野の専門家に質問し、起こり得る問題を特定し、ソリューションをテストします。 何が起こっているのか、なぜ起こっているのかを正確に知るまで繰り返します。

回復

ここまできたら、問題の内容、再現方法、原因を正確に把握していることでしょう。 根本的な原因を特定し、テスト済みで実用的な修正を行っています。 次のステップは修正プログラムを導入することであることは明らかですが、ここで停止することはできません。 問題が解決してすべてが安定したら、問題が修正されたことをすべての関係者に通知する必要があります。 また、ソリューションの詳細を関連する専門家に伝え、必要に応じて、何が起こったのか、どのように解決されたのかを誰もが理解できるように解析しておくことも重要です。

効果的なインシデント管理は、確立されたプロセスと適切なコミュニケーション次第です。 実際の手順はプロジェクトごとに変わる可能性がありますが、問題を最も効果的に軽減するチームは大きなコミュニケーションをとり、必要となる前に計画を立てるものなのです。

「インシデント管理」と聞くと、ITプロフェッショナルがバックエンドシステムを管理していると考えるかもしれません。おそらくカスタマーサポートチームは自分たちとは関係ないと考えていることでしょう。

ですが実際のところ、カスタマーサポートチームもインシデント管理から多くの利益を得ることができるのです。

顧客を幸せにする

ほとんどすべてのIT専門職は、カスタマーサポートに回ってくるようなことがらは一般的に良くないことだと考えているでしょう。私たちは顧客に技術サポートに頼るような経験をさせたくはありません。カスタマーサポートを提供することに直接的なコストが伴うだけでなく、こういった経験をした顧客は将来的に顧客でなくなる可能性が高まるからです。

結論は、顧客を満足させることが重要であるということです。満足した顧客は、あなたの会社との経験を何人かの友人に伝えてくれるかもしれません。怒っている顧客は、自分のTwitterフォロワーに体験をシェアしたり、中には消費者庁に駆け込むようなこともあるかもしれません。

では、カスタマーサポートとインシデント管理はどんな関係があるでしょうか。その性質上、カスタマーサポートは受け身の機能です。通常、顧客は問題に突き当たるとテクニカルサポートに電話を掛け、テクニカルサポート部門は顧客の苦情に対応することになります。インシデント管理も同様に受け身なものですが、予防的な対応も可能です。適切な監視ソリューションを使用することで小さな問題を解決して、チームをより大きな問題の解決に向かわせることができます。これにより、サポートコールが少なくなり、顧客満足度の向上にダイレクトにつながります。

積極的なインシデント管理を通じてサポートコールを削減するという考えは魅力的ですが、インシデント管理計画が適切に実装されている場合にのみ有効です。重大ではなかったり重複している警告は抑止し、より緊急な問題のアラートを発信することで、ソフトウェアはIT担当者の大きな助けになります。しかし、最終的には、インシデント管理プログラムの成功は、問題が発生したときに決定的な行動をとるITスタッフの能力に左右されます。

担当者を呼び出せることの重要性

インシデントが迅速に解決されるようにするためのひとつの方法は、発生する可能性のある問題をITスタッフが常に処理できることを確認することです。組織に24時間対応のITスタッフがいない場合は、呼び出し可能なサポートチームを持つ必要があります。これは全員が常にオンコールでなければならないというわけではありません。輪番制のコール対応スケジュールを組めば、ITチームの誰かが常に起こりうる様々なインシデントに対応可能になります。

時間外の緊急事態に対処するためにコール対応スタッフを用意しておくという考えは新しいものではありません。熟練のIT技術者であれば、たいていは週末や非常識な時間に呼び出された経験が一度や二度はあると思います。

ほとんどのITサービスは時間外の問題に対処するために誰かを呼び出すことを躊躇しないものですが、関係するすべての人がより無理なく日常生活を送れるようにするためには、いくつかのポイントがあります。

オンコールオペレーションのベストプラクティス

まず、時間外のインシデントでITスタッフにアラートを出すのは、インシデント管理ソフトウェアによって起動される自動プロセスでなければなりません。自動アラートを使用することで、IT担当者は問題を可能な限り迅速に認識することができます。自動プロセスをとっていないと、誰かがインシデントを発見してIT部門に電話をかけてくるまで、ITスタッフはその問題を認識できない可能性があります。その頃には、顧客の側でも問題を経験し始めているかもしれません。

これは別のポイントをもたらします。よほど小さな組織でない限り、1人のオンコール担当ではなく、オンコールチームを用意するのが一般的です。ITは複雑な分野であり、チームの誰もが組織全体で使用されているあらゆるテクノロジーの専門家であることを期待するのは非現実的です。オンコールチームを組織しておくことで、インシデントが発生した場合、問題を解決するために相互補完的なスキルセットを持つ人々のグループを確保することができます。これは、オンコール技術者が何らかの問題が発生したときに、解決に必要なスキルを持つ特定の人を探すより好ましい方法です。輪番制のコールスケジュールは、ある人に常に役割を負わせるのではなく、いつでも問題に対処できるチームが存在することを保証します。

業務時間外に待機するのは決して楽しいことではありませんが、24時間体制で顧客にサービスを提供する企業では、ITの専門知識を年中利用できるようにすることが非常に重要です。顧客は企業の最も貴重な資産であり、企業のブランドは顧客に依存しています。インシデント管理ソリューションを活用する積極的なカスタマーサポートチームは、問題が顧客に悪影響を与えるのを防ぐことができ、より高い顧客満足度につながります。

オンコール状態を保つことは難しく、時にそれは受け入れがたい負担となります。しかし、規制業界 （国の規制により 新規参入や事業拡大が制限されている業界）で働く場合、組織に課せられるインシデント管理への要求は日増しに増大しています。この記事では、規制業界におけるソフトウェア関連のインシデント管理の基本原則について説明したいと思います。

インシデント、規制、コンプライアンス

まず、ソフトウェア関連のインシデントが規制業界で何を意味するのかを簡単におさらいしてみましょう。ソフトウェア開発やIT部門の担当に「インシデント」とは何か定義するように尋ねてみると、大概はダウンタイムやアプリケーションの応答時間の問題に言及するかと思います。しかしこれは、もう一方の重要な要素を見落としている場合があります。それはセキュリティー – 侵入、データ盗難、機密データ保護の失敗などです。

規制産業での「インシデント」という用語は、ダウンタイムやセキュリティー上の問題をはるかに超えた意味を持ちます。それは、組織またはプロダクト、またはサービスを規制の準拠外に追いやってしまうことを意味します。

水道会社にとっての問題を例に挙げると、給水中に大腸菌が入り込んでしまった場合がそれにあたります。銀行でいえば顧客の財務データが失われた場合、病院にとっていえば生命維持システムの重大な欠陥があった場合です。規制遵守が危機に瀕している場合、公共の安全や重大なデータ損失、主要サービスの中断などの事故は、ダウンタイムを伴うものほど深刻になるものです。

コンプライアンス – Stakesとは何か

規制業界に属する組織にとって最も根本的な問題の1つは、適用される規制を遵守する必要があるということです。業界およびインシデントの性質によってコンプライアンスの違反が発生する可能性があります。

罰金、手数料、またはその他の民事上または行政上の罰金 インシデントの影響を受ける組織または個人による訴訟またはその他の訴訟 業界内での作業に必要なライセンスまたはその他の証明書の保留または紛失 業界内または一般の人々の目にある評判の喪失 極端な場合には、責任ある個人の刑事告発、有罪判決、懲役刑

言い換えれば、Stakes（危険度）は非常に高くなる可能性があります。インシデント管理の手続きを裁判官に説明する状況に陥るのは、非常に望ましくないものです。

必要性とベストプラクティス

このような厳しい条件の下でインシデントをどのように管理すればよいのでしょうか。最高のインシデント管理は、コンプライアンスに関わる問題になる前にすべての潜在的なインシデントを処理するという予防対策です。それは実際の状況下では必ずしも実現できないため、法的要件と実用的必要性の両方を満たすインシデント対応計画を立てることが重要です。これを行うには、次の要因を考慮する必要があります。

規制要件とガイドライン イン**シデント管理、予防、対応に関しては、規制当局の要求事項に常に従ってください。これらは業界および関連機関によって異なりますが、大抵は正式なインシデント対応計画、ITインシデント対応チーム、インシデント対応手順およびアクションの正式文書が含まれます。 例えば、HIPAA（Health Insurance Portability and Accountability Act ）またはPCIDSS（Payment Card Industry Data Security Standard）の下で運用されている組織には、文書化されたセキュリティレスポンスプランとレスポンスチームが必要です。連邦情報セキュリティ管理法（FISMA) には同様に、連邦機関に対する詳細な事故管理および対応ガイドラインが含まれています。不明点がある場合は組織が対象とする機関と要件を確認し、すべての要件を完全に遵守しているか確認するべきです。 業界ガイドラインとベストプラクティス これらは業界によって異なります。業界全体の専門組織は多くの場合、一連の推奨プラクティスを提供しています。業界に特定のガイドラインがない場合、Common CriteriaおよびCommon Evaluation Methodのドキュメントは、一般的なITセキュリティおよび公衆安全の問題を理解するための有用なフレームワークを提供しています。

一般的な考慮事項

すべての規制産業およびすべての規制の枠組みに適用される基本的な考慮事項がいくつかあります。

識別

障害やその他の誤動作が直接的または間接的にコンプライアンスの問題につながる可能性のある機密システム（アプリケーション、ネットワーク、サービスなど）をすべて特定します。例えば、クライアントの医療記録を含むデータベース、または公益事業のための電力配分を管理するプログラムは、この項目に該当する可能性が高いです。尚、簿記ソフトウェアはこの文脈ではおそらく重要なシステムに該当しません。

プリベンション

インシデント管理の最新トレンドは、システム障害を未然に防ぐことです。つまり、システムの障害だけでなく、障害につながる可能性のある状態についてインシデント対応チームにあらかじめアラートを出す必要があります。セキュリティーに敏感なシステムの場合は侵入を試みる活動やセキュリティーソフトウェア自体のパフォーマンスの低下を示唆する活動である可能性を探る必要があります。公共安全が危機に瀕しているシステムでは、主要メトリックの異常な動作を探る必要があります。言うまでもなく、プリベンションにはデータのフルバックアップ、必要に応じてスタンバイ状態のフルバックアップシステムが含まれます。

問題がコンプライアンスに関わる問題に変わる前に問題を把握するには、インシデント対応チームが完全に同期している必要があります。このような状況では秒単位での対応が重要です。このため、対応担当者を事前に定義してエスカレーションポリシーを明確にし、複数のシステムからのメトリクスへのアクセスを統合して問題を統一的に把握することが不可欠です。

プライオリティ

事実上、既存のインシデント管理のトリアージ（行動順位決定）に別レベルの優先度を追加し、すべてのコンプライアンス関連のインシデントを既存の優先度よりもさらに優先させる必要があります。例えば、簿記システムと在庫システムの両方がクラッシュし、同時に医療記録データベースが天気予報のように不安定になった場合、もし対応できるITスタッフが十分にいなかったとしても、会計担当者と倉庫担当者は緊急チームがデータベースに対応するまで待つ必要があります。また、公共安全に関与している場合は、重大な災害が発生した直後に、重大なシステムを運用する準備ができている必要があります。

これらはとても恐ろしいことのように聞こえるかもしれません。規制当局や裁判官が規制を適切に遵守しなかったと判断した場合、企業が大きなインシデントに対して費やさなければなければならない費用ははるかに高くつく可能性があります。結論として予防的なインシデント管理は、企業にとって自身を守る最高の防衛手段となるはずです。

インシデント対応のプロセスやワークフローを改善するためのリソースを探している場合は、オープンソースのインシデント対応文書と金融サービスソリューションの要約を参照して、PagerDutyがどのように規制対象産業を支援しているか確認してみてください。

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