Blog
ブログ

インシデントを経験した後 のポストモーティム（事後検証。post-mortem またはpostmortem と表記される）に 何をします？ 簡単な質問のように見えるかもしれません。 結局のところ、インシデントの処理の最後のステップとして事後検証を考えるのは簡単です。

しかし、そうではありません。 多くの点でインシデントのポストモーティムで何を検証するかは、ポストモーティムをすることと同じくらい大事なんです。以下、理由を説明し、事後検証が終わったあとに何をするべきか、そのヒントを提供します。

なぜポストモーティムするの？

しかし、この質問の意味を考える前に、より根本的な質問、つまりポストモーティムの機能とは何か、そしてそれには何を含めるべきかを検討する必要があります。

ポストモーティムは基本的に以下の役割を果たします:

インシデントとその原因および関連する兆候、解決策、将来の参考になる影響の記録を提供する。技術的問題を将来理解するためと、事件から生じる法的または行政上の懸念の解決の両方にとって重要になり得る。 事件を引き起こした基本的な技術的問題を分析し解決するための基礎として役立ちます。 インシデント対応プロセスを理解し改善するためのフレームワークを提供します 。

これらの基本的な役割をサポートするために、ポストモーティムにはインシデント、対応、解決の記録が含まれていなければなりません。 また、インシデントの根本原因の分析 、インシデントの範囲とその影響の説明、根本的な問題の解決、対応プロセスの改善、および/または将来のインシデントの影響の最小化のために適切な推奨事項も含める必要があります。

理解したあとに、責めないこと

大事な注意点ですが、ポストモーティムを責任追及の手段にしてはいけませんし、企業や組織のポリシーに点を付ける手段にならないように注意してください。必要ならば、事後検証から責任追及を分離するためにインシデント関連の問題を議論するために別のプロセス（すなわち、部門内での非公式で司会を立てた議論）を設定してください。

一方ポストモーティムでは、インシデントを起こす背景になった可能性のある、または対応中に明らかになった、技術的または組織的問題についての正直な議論が含まれるべきです。 技術や反応プロセスの改善に重点を置くべきであり、個人やチーム、あるいはその仕事の欠陥に置くべきではありません。

ポストモーティムはいつ必要?

すべてのインシデントでポストモーティムをする必要はありません。 軽度の運用上の問題や、よく原因が分かっており簡単な解決策があるインシデント、そしてダウンタイムやデータの消失が起きなかったインシデントには、ポストモーティムが必要ない場合があります。

ポストモーティムが必要な状況の例をいくつか示します。

データや生産性の低下、または顧客のアクセスにつながるインシデント シャットダウン、再ルーティング、以前のソフトウェアバージョンへのロールバック、および/または解決のための長期のアクションが必要だったインシデント 適切な監視やアラートシステムがあったのにうまく検出または処理されなかったインシデント 根本原因が不明、あるいは予想を超えていた、または今後も発生が疑われるインシデント システムの動作に広範囲の影響を及ぼす可能性のある、アプリケーションアーキテクチャや技術の根本を含むように見えるインシデント 回答や解決プロセスに深刻な問題や不備があったインシデント

ポストモーティムは学習を容易にする

ポストモーティムを価値あるものにするにはその書き方を、長期的な問題の分析、解決、防止を担当する人々が読みやすくかつ理解しやすくする必要があります。

これは、例えば、問題やその解決を抱えているチームや部署は、ポストモーティムの記録を読むことを読み、さらに結果として適切な次のステップを決定するために、できるだけ早く議論に参加することを要求されているからです。 どうポストモーティムの資料を流通させて、それらを読んだあとの行動にどう導くかという実際のプロセスは、もちろん、あなたの組織の構造と経営理念に依存します。

ポストモーティムの基本要素

ポストモーティムを書いたり読んだりするときには、次の3つの重要な分野があります。

根本的な原因

ポストモーティムは必ず根本原因の説明を含むべきです。根本的な理由が既に分かっていても、ささいなことであっても。ささいな原因ではない場合は、問題の実際の根本原因を正確に特定し、それを修正する必要があるかどうかを、原因の分析に含める必要があります。 根本原因を正確に特定できない場合は、将来の特定につながる可能性のある情報を含める必要があります。

例えば、インシデントの解決の過程で、その問題が多量のレガシーコードを含むモジュールで生じたことが明らかになったけれども、そのモジュールよりも下の部分にある根本原因を特定できなかったという場合でも、その事実を根本原因の分析に含めることが重要です。インシデントと関連してレガシーコードを特定したという事実の記録は、インシデントの解決だけでなく、後の調査で置き換える必要のあるコードを特定することにおいても価値があります。

対応

ポストモーティムには、対応プロセスの完全な技術的説明が含まれていなければなりません。 また、そのプロセスの相対的に見た成功または失敗の説明と分析も含める必要があります。 これは誰の責任も問うことなく実施されなければなりませんが、対応プロセスまたはそのプロセスの実施中の明らかな失敗や弱点を明確に示すべきです。 これには、対応チームメンバー間の責任分担、対応チーム内の連絡、または対応チームと他のステークホルダーとの間のやり取り、特定の対応プロセスの問題が含まれます。

対応プロセスの失敗は、技術的または組織的なものに及ぶ可能性があります。インシデントの解決中にシステムやアプリケーションが利用できないことを、その影響を受ける部門やユーザーに伝えられなかったというような、簡単なことが含まれます。 2つのチームのメンバーが協調せずに同じタスクを実行してしまったり、誰も必要なタスクを実行しなかったために、結果として解決に時間がかかりすぎた場合は、ポストモーティムの中にはチーム構成やコミュニケーションの潜在的な問題を示す注記を入れておく必要があります。

被害の影響範囲の確認と制御

ポストモーティムには、データの損失、生産性の低下、ユーザーアクセスの中断など、インシデントによって引き起こされた損害の程度を明確かつ正確に記述する必要があります。 この被害を限定あるいは緩和するために取られた措置についての説明と分析を含めることも同様に重要です。 ダメージコントロールは、技術的なインシデント解決とは別のプロセスとして考慮する必要があります。 インシデントの種類、被害の種類、および組織の構造によっては、カスタマーサービスの責任である場合や、ビジネス内の他の部門のアクションアイテムが必要な場合があります。

ダメージコントロールは、似たようなインシデントを将来どう処理すべきかに直接または間接に影響する可能性があるため、ポストモーティムの一部に入れておく必要があります。 例えば停電により航空会社のフライト予約システムが停止した場合、そのダウンタイム中に予約を処理するための代替システムを導入することを優先する必要があるかもしれません。

恥と思わず、金と思え

ポストモーティムを最大限に活用するための鍵は、これがアプリケーション、インフラストラクチャ、および対応プロセスの改善のためのロードマップであることを理解することにあります。 各ポストモーティムは、システムの動作方法とインシデントの処理方法を改善する可能性があります。 ポストモーティムを恥とか何らかの失敗の徴候として扱うのではなく、これは将来の金になる貴重な機会だと考えるべきです。

PageDutyは、業界のベストプラクティスを共有し、ポストモーティムのテンプレートを含む完全に無料のポストモーティムハンドブックを提供します。 あなたのチームが問題にできるだけ簡単に対応できるように、自分のポストモーティムプロセスを正式化するのに役立ちます。 PureDutyプラットフォームの一部であるポストモーティムは、自動化されたタイムライン構築、コラボレーティブな編集、実用的な洞察など、 14日間の無償体験版にサインアップし、ポストモーティムのプロセス全体を合理化します。

2017年2月28日の朝のこと、インターネットが広大な範囲で利用できなくなりました。 Slack 、Quora 、GitHub、Trelloなど、数千人が頼りにしている個々のサイトからサービスに至るまでたくさんのものが利用できなくなりました。たぶん、人為的ミスがインターネットの大部分をダウンさせたこの日を覚えているでしょう。AWSの幅広いコンポーネントが機能しなくなりました。一つの停止でインターネットが無秩序になったのは今回が初めてではありませんが、AWSの規模を考えれば、その影響はいつでもありうると感じられます。

多くの場合、危機の最中に重大な事件に対処する人間の側面を忘れることがあります。例えば人々に連絡する難しさや、個人的な連絡先情報を見つけること、複数のタイムゾーンに主要なスタッフが分散していること、会議から人を引き離すことなど、予期しない出来事のため計画していた作業を中断することなどです。

PagerDutyは、こういう時代に存在する最先端のデジタル運用管理プラットフォームです。私たちは、チームや組織が事態が悪化したときにPagerDutyを使いインシデントを先取りして管理することを支援し、チームがやりたい仕事に集中できるようにします。当社の製品は、予期せぬ事態が発生した場合の行動のプラットフォームとして機能します。私たちは主にエンジニアリングとITチームにフォーカスしてきましたが、チームや人をサポートする他のビジネス分野にとってPagerDutyがどんな意味を持っているかも考えていました。

過去には、エンタープライズシステムや人事部門こそが、AWS停止などの事態が発生したときに必要となる重要な人員の詳細を把握するシステムの責任者でした。人事チームはまた、大事な顧客への影響が発生したときに情報を提供する必要があります。私たちの情報の世界の大部分はクラウドにあり、クラウドベースのサービスが利用できない場合に、私たちが仕事をするために必要な重要な情報もそこにあります。私たちが日常的に利用している人気のあるサービス、社内のメッセージングとVoIPサービスは、すべて利用できなくなる可能性が隠れています。これらのクラウドサービスの大規模な停止またはダウンタイムの間、顧客と従業員に情報を提供し、行動と対応を調整することは困難です。

「 私たちの情報の世界の大部分はクラウドにあり、クラウドベースのサービスが利用できない場合、私たちが仕事をするために必要な重要な情報もそこにあります。」

現代の企業には、通常、人の情報をすべて記録したシステムがいくつもありますが、その詳細を最新の状態に保つインセンティブを人々に持たせていることはめったにありません。 PagerDutyのようなインシデントや危機対応の鍵を握るシステムでは、従業員全員が緊密な接触を維持する気にさせる深いインセンティブと日常のビジネスニーズがあります。そのプラットホームを活用して正確な人の情報を得、応答を調整すればスムースになります。

これは、ビジネス全体で高度に採用されているプラ​​ットフォームをHRチームが使用する絶好の機会であり、私たちを行動の心臓部につなぎとめ、妨げにならないように支援します。私たちが最も避けたいことは、素早い返事と行動を求められている最中に、社内で不要な騒音や官僚的な行動を作り出すことです。

従業員に対する環境的、物理的、またはデジタル的な脅威など、人事部門が責任を持つべき危機のことを考えてください。私たちに必要なのは、状況を管理し、重要な情報にアクセスし、サイロになったりワークフローにまぎれずに、あるいは、チケットによって遅くならずに応対できるようにすることです。いつもそうとは見えないかもしれませんが、HR部門は、さまざまな状況になると、しばしば第一級の対応ができる部門です。ベストプラクティスとアジャイルワークフローを使い重大な事態に対処するには、法律、設備、ベンダー、サイバーセキュリティチームと連絡する必要があります。

当社の顧客の多くは、物理的な在庫やサプライチェーンを持たないビジネスモデルを採用しています。デジタルインフラストラクチャがビジネスの主体であり、顧客の経験に大きな影響を与えます。エンジニアリングから法律およびマーケティングに至るまで、インフラストラクチャと顧客体験の成功に投資しています。リアルタイムの顧客への影響がある場合、そのインフラストラクチャ全体を調整できるプラットフォームを使う方が優れた対応ができます。

“ これらのチームが人々と意思決定とシステムの間に持っているスピード、オーケストレーション、相互運用性からはみんなが恩恵を受けられます。”

テクノロジーに焦点を絞ったビジネスでは、エンジニアリングチームや開発チームが使用するプラットフォームやプロセスから学ぶ必要があります。これらのチームが人々と意思決定とシステムの間に持っているスピード、オーケストレーション、相互運用性からはみんなが恩恵を受けられます。各チームが醸成した文化、つまり最前線に至るまでのカスタマーエクスペリエンスの説明責任を果たせること、チームが対策を組織できると信頼すること、非常に高い協調性から学んだこと、そしてDevOpsチーム、ITチーム、顧客が習熟してきたインシデント対応へのアプローチから、恩恵を受けることができます。ビジネス全体がこれから学ぶことができます。

“ HRの専門家としての私たちの責務は、組織の人々のデータおよびオーケストレーションのインフラストラクチャが、インシデント対応の技術インフラストラクチャおよびオーケストレーションと同じくらい効果的だと保証することです。”

さまざまな機能が共有プラットフォーム上で共同して働ける新しい方法を見つけ出すことは私をワクワクさせます。例えばデータを集めることと機械学習を活用して、あるパターンが出現する前にそれを見つけたり、過去の反省から対策を覚えたり改善したりすることができます。 HRの専門家としての私たちの責務は、組織の人々のデータおよびオーケストレーションのインフラストラクチャが、インシデント対応の技術インフラストラクチャおよびオーケストレーションと同じくらい効果的だと保証することです。私たちは社員が顧客のために構築した経験を彼らから借用していますし、オンコールエンジニアの人生をより良くしていくことで、デジタルビジネスに関わる全員の人生をより良くすることができるはずです。

ウォルマートのようなリテーラー（ 小売業者）の増加に伴い、eコマースとリテーラーの間の戦いが収束しつつあり、Amazonのようなeコマース企業の多くはオフラインでのプレゼンスを確立しています。この2方向の展開をサポートするため、リテーラーとeコマース企業は、優れたオムニチャネルカスタマーエクスペリエンスを提供することを目指しています。

リテールの世界のオムニチャネル

顧客は、店舗内、Webサイト内、モバイルアプリ内、またはソーシャルメディア内の全チャンネルでシームレスな体験ができると期待しています。世界最先端のリテールブランドはトレンドに乗っており、たくさん成功事例があります。以下は、オムニチャネルのリテール体験を提供しているブランドの好例です：

ディズニー：ディズニーランドでの休暇を計画するのは大変です。しかし、ディズニーのWebサイトやモバイルアプリのおかげで、レストランや観光スポットなど、休暇全体をオンラインで計画することができます。また、各アトラクションの待ち時間を知ることもできます。

スターバックス：スターバックスの特典カードを使えば、コーヒー代でキャッシュを使い切ることはありません。モバイルデバイスから簡単に特典カードを取り出して、いつでもカウンターで使えます。

ノードストローム：ノードストロームは、顧客がiPhoneアプリで行う注文を店内のスタッフが補助することで、優れたカスタマーエクスペリエンスを提供しています。各スタッフはアイテムの在庫を確認でき、特定のアイテムが在庫切れの場合、すぐにiPhoneで予約して顧客の家に届けることができます。顧客はオンラインで商品を購入して店頭で持ち帰ることもでき、返品も簡単です。

これらのチャネルでのエクスペリエンスをサポートするためには、深くよく統合されたバックエンドと、一貫したフロントエンドインタフェースが必要です。しかし、これは以前よりもずっと簡単になりました。従来のインフラストラクチャ、ツール利用、そして開発プロセスを放棄して、リテールアプリケーションを構築するための最新のDevOpsアプローチに移行すればよいのです。顧客は絶えず新しい機能や体験を求めており、そのために頻繁になる更新は、安定性を損なうことなくアジャイルさと正確さを最大化する方法で展開する必要があります。これは、デジタルチャネルと物理チャネルをシームレスに統合したエクスペリエンスを構築するために不可欠です。何千もの日常的なやりとりは破綻を生じやすく、また、人気ブランドはサイバー攻撃の目標とされやすいです。何百万人ものユーザーをサポートするためには堅牢なシステムが必要です。システムの可用性とセキュリティを確保する必要があります。これは簡単な仕事ではありません。

いかにしてDevOpsチームがオムニチャンネルリテーラーをサポートするか

インフラストラクチャ層から始めて、アプリケーションスタックまで移動し、オムニチャネルのリテールアプリケーションを構築する際に、DevOpsチームが留意べきことを理解しましょう。

クラウドに移行する

モバイルは、オムニチャンネルのリテールを考える際に最も重要なメディアです。これは、顧客にアプローチする最も個人的かつ強力なチャネルです。どこにいても、お客はあなたの会社とやりとりして、都合のいいときに買うことができます。しかし、ほとんどのリテールアプリは、過去に使われていたクライアントサーバモデルをベースにしていて、現代の最先端の消費者をサポートすることはできません。複数のデバイスやモバイルオペレーティングシステム用のアプリケーションを構築するには、クラウドテクノロジーを活用する必要があります。しかし、いくつかのクラウドツールをあなたのレガシーなスタックに投入するだけでは足りません。AWS EC2などのクラウドサーバでアプリケーションを実行したり、AWS S3などのブロックストレージにデータを格納したり、Sauce Labsなどのクラウドベースのテストプラットフォームを使ったり、Prometheusなどのクラウドネイティブな監視ツールを使ったりする場合は、全システムをクラウドで稼働させるか、少なくともそこへの移行を開始しなければなりません。

マイクロサービスモデルにゆっくりと移行する

マイクロサービスは、単一のモノリシックなアプリケーションを、小規模なクロスファンクショナルチームによって開発・管理される小さなサービスに分解するアプローチです。このタイプの複合型のシステムにより、新しい機能をより早くリリースできます。さらに、あるサービスに障害が発生しても、システム全体をダウンさせることはありません。しかし、マイクロサービスへの移行は、一度に1ステップで行う必要があります。最初のバッチが安定した後に、いくつかの機能を切り分けてください。マイクロサービスアプリは、従来のツールセットを使用する場合に限り、管理が難しくなります。幸いにも、DockerやKubernetesのようなコンテナ技術は、マイクロサービスの管理を容易にしています。

VMからコンテナへの切り替え

クラウドへ移行することが最初にやるべきことです。クラウド内にもう移行していても、アプリをコンテナで実行することが重要です。マイクロサービスモデルに移行すると、サーバインスタンスごとにハードウェアハイパーバイザとOSのオーバーヘッドがアプリのパフォーマンスを低下させます。マイクロサービスアプリケーションを拡張するには、コンテナにコードをパッケージ化する必要があります。コンテナ化すると全く新しいツールセットを使うことになります。たとえば、Kubernetesのようなオーケストレータを活用して、数千のコンテナを管理する必要があります。幸いなことに、コンテナ周辺のツール事情は昨今急速に成熟しました。今日、多くの世界クラスのアプリは、コンテナを使用して確実かつ安全に稼動しています。業界は、クラウドネイティブコンピューティングファウンデーション（CNCF）が認めた標準規格を整理統合しているところです。

分散データストア

インシデント管理でシステムを保護する

現代のマイクロサービスベースのコンテナ駆動型システムでは、多くのパーツがあり、これらのパーツはしばしばフェイルします。DevOpsの呪文の「早く進んで前向きに失敗する」とは、これらの失敗にすばやく反応し対処できる必要があることを意味します。パフォーマンスとセキュリティの両方が、オムチャンネルのリテールアプリの最大の課題です。サイバー犯罪者は多数のユーザーを持つアプリに引き寄せられますが、リテールアプリは名前、住所、クレジットカード情報などの価値のある重要なユーザーデータを数十億単位で持つことが知られています。システム障害やサイバー攻撃から守るには、データポイントを集中管理し、問題に応じて適切な対応者をリアルタイムで把握するインシデント管理システムが必要です。

大規模なDevOpsチームでは、重要な通知が失われる可能性があるため、適切なメッセージが適切な人に届くようにルーティングシステムが必要です。インフラストラクチャの複雑さが増し、大量のデータを処理する必要があるため、機械学習を活用してデータを理解し、重要なポイントに人々が集中できるようにするソリューションが必要です。オムニチャネルリテール向けのインシデント管理ツールは、システム全体にわたる監視、チケット発行およびその他のデータソースを相互に関連付け、集中化することができます。最先端のインシデント管理プラットフォームにより、疑わしいパターンを特定し、インシデントがエスカーレートする前に適切な人材を確保できます。

オムニチャネルのリテールは単純ではないので、完璧なシステムを構築するためには数年以上の時間が必要です。ただし、ここに記載されている方法とツールは、DevOpsチームにオムニチャネル体験を提供するための手がかりを与えることになります。クラウドへの移行、マイクロサービスの活用、コンテナの採用、データストアの分散化、またはインシデントの予見的な管理など、次世代のコンピューティングテクノロジーが今や利用可能です。リテールビジネスに必要なのは、計画を立て直す準備を整えた開発チームだけです。

「フルスタックの可視性」とは？

ツールのベンダーが「フルスタックの可視性を提供します」と宣伝していることがありますが、これが何を意味しているか分かるでしょうか。ツールが違えばどう可視化するかも違います。理由は、可視性がITインフラストラクチャの構成方法に依存するだけでなく、あなたが何が見たいかにもよるためです。極論すればフルスタックの可視性は、ツール、アプリケーション、システム、サービス、および全体的なインフラストラクチャの状態を一覧できるようにすることです。

近代的なインフラ

まず、現代のアプリケーションとサービスをホストするフルスタックインフラストラクチャのタイプを特定してみましょう。以下は、現代のインフラストラクチャに見られる最も一般的なコンポーネント要素です。これらは、仮想デバイスと物理デバイスのミックスとしてオンプレミス、クラウド、またはハイブリッド環境でホストされる場合があります。

現代のインフラストラクチャコンポーネント

アプリケーションとツール オペレーティングシステム ミドルウェア ネットワーク データベース ストレージ Webサーバ 演算装置

これらのインフラストラクチャコンポーネントはすべて、膨大な量の構造化データと非構造化データの両方を生成します。この指数関数的に急増するデータの量と多様性はITOps、DevOps、開発チームに挑戦を突き付けます。つまりシステム、アプリケーション、サービスの可用性を高く維持し、最適なパフォーマンスを発揮させるためにカギとなる情報を収拾し解釈し、実用的な洞察を抽出することを要求します。

以下は、今日の組織がインフラストラクチャとアプリケーションのパフォーマンスを自動化するために採用しているツールの例です。これらのツールのそれぞれは、インフラストラクチャ、アプリケーション、サービス、コードの展開、ビルドなどのステータス、健全性、脆弱性を知らせるデータを生成することができます。

インフラストラクチャ、アプリケーション、自動化ツール

オートメーション／継続的インテグレーション ソースコード管理

構成管理とプロビジョニング リポジトリ管理

ソースコードとリポジトリ管理 プロビジョニング

デプロイ リリース管理

データベース テスト

モニタリング セキュリティ

ビルド クラウドIaaS

マイクロサービスと仮想化

どんな風に可視化できるか

アプリケーションとサービス、システムは、データテーブル、ステータスダッシュボード、パフォーマンスグラフとチャート、ヒートマップ、トレース、システムヘルスメトリック、分析、レポートなど、さまざまな形で可視化できます。フルスタックの可視性は、複数のツールを組み合わせて構成することができます。

監視ツールカテゴリ 人気ベンダー

アプリケーションパフォーマンス監視 New Relic、AppDynamics、Dynatrace

インフラ／クラウド監視 AWS CloudWatch、Microsoft Azure、Google Stackdriver

メトリック Datadog、Librato、Keen IO

ログの監視と分析 Splunk、Elastic、Sumo Logic

既に複数の組織が、上記のさまざまなソリューションを使ってITツールのポートフォリオを構築し、インフラストラクチャ全体で何が起こっているのかを深く調べられるようにしています。

PagerDutyのようなソリューションは、ITポートフォリオ内の全ツールから生成された全イベントとアラートを集中管理して集計し、インシデントへのより適切な対応をリアルタイムで選び出します。

何が起きているのかを示せるツールは世の中にたくさんあって、ほとんどのチームは複数の監視とチケット発行ソリューションに投資しています。ここでもっと重要になるのは、大規模なインシデントがビジネスに影響を及ぼすことを防ぐ、あるいはサービスを復旧するため、専門家に対してよりよく事態を理解するために必要なリソースを提供するソリューションです。

さらにその先へ

PagerDutyでは、真のフルスタック可視性は、インフラストラクチャ、アプリケーション、およびサービスの健全性に関するビューだけではありません。インシデント管理、レスポンスオーケストレーション、システムと運用の両方の効率性の視覚化など、他の重要な部分も含まれているため、チームはSLAを継続的に改善できます。ソフトウェアがビジネスと顧客の経験の中心になるにつれて、ITOps、DevOps、開発者、ITリーダー、エグゼクティブ、ビジネス関係者は、インフラストラクチャ全体で何が起こっているかをよりよく把握する必要があります。

インフラストラクチャの真の健全性を評価する際には、人の役割の重要性を忘れることはできません。ツールは常に仕事をしますが、インシデントはそれらのツールのデータを理解できる人々が解決するのです。PagerDutyのオペレーションコマンドコンソールとインテリジェンスアプリケーションは、多数のベンダーの製品から得た状況の推移を単一のビューにまとめ、どんな重大なインシデントが際立っているか、担当者が取り組んでいるインシデントはどれか、どんなイベントが関連性があるかを包括的に把握できるようにします。そしてインシデントへの技術的、ビジネス的対応の両方を調整します。

PagerDutyを使うと、アプリケーション、サービス、インフラストラクチャの健全性を簡単に視覚化し、インシデント対応ワークフローを1カ所で管理できます。

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

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

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

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

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

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

主な教育内容

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Incident Commander Training: Leading the Response During Major Incidents

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

Incident Commander Training: Leading the Response During Major Incidents

あなたの考えていることをずっと追いかけていて、あなたの計画の実行を助ける、そんな小さな ロボット があったら素晴らしいでしょう。もし、あなたがインシデント監視インフラストラクチャを担当する管理者なら、それは存在します。チャットボットと呼ばれる彼らは、インシデント管理ワークフローを最適化するための鍵です。

ここではチャットボットとChatOpsを使うのが、DevOps手法を採用している組織にとってとても重要な理由について説明します。

チャットボットの定義

「チャットボット」は人によって異なるものを意味します。大まかに定義すると、チャットボットは、人間と「会話」をするプログラムです。チャットボットはずいぶん昔から存在しています。あなたがAOL（注：America Online）がまだインターネットを支配していた時代に育ったなら、例えばSmarterChildというAIMインスタントメッセージングサービスのためのチャットボットを覚えているでしょう。

インシデント管理とインフラストラクチャの監視の分野でいうチャットボットは、もっと狭い意味を持ちます。彼らは人間の言うことを理解し会話をするだけでなく、人の代わりにアラートを監視しインシデントに対応します。

言い換えれば、この意味でのチャットボットは、SlackやHipChatなどのコミュニケーションプラットフォームと統合され、人間の入力に応答してコマンドを処理するプログラムです。コマンド自体は、多くの場合、バックグラウンドで動作するサーバで実行されていますが、管理者が行う必要があるのは、何をするかチャットボットを教えることだけで、残りは事前に定義された手順に基づいて自動的に処理されます。

チャットボットとChatOps

チャットボットは開発業務におけるツール、プラットフォームであり、ChatOpsと呼ばれます。彼らは開発者と運用チームに以下のような利益をもたらします。

コマンドを実行するための便利なインタフェースを提供する

すでにSlack、HipChatや他のコミュニケーションプラットフォームをすでに使っている場合、なぜコマンドを実行するために異なるインタフェースに乗り換えるのでしょうか。チャットボットならばあなたがコマンドを実行する必要はありません。チャットインターフェイスから直接実行させることができるので、ずっと素早く実行できます。

チーム全体を可視化

あなたがチャットボットとの対話を公開していれば、参加するすべての人があなたが実行したコマンドを確認することができます。これは、あなたのチーム全体を可視化し、チームメンバーが同じコマンドや矛盾したコマンドを実行していないことを確認できます。そして同時に、チーム全体が学習する機会も提供します。

リアルタイムなアクションを促進

伝統的に、チームは集まり、計画を立て、別れて、実行します。チャットボットとChatOpsを使うと、コミュニケーションと操作インターフェースが統合されているので、対話と実行が同時に可能です。重要なオペレーションを実行する前、計画を立てるための時間が要らないとは言いませんが、例えばインフラの障害に対応しているときのように時間が最重要である場合、計画とオペレーションが同時に行えるのは大きな利点です。

チャットボットとChatOps、DevOpsチーム

これらの利点は、ほぼすべてのタイプの組織に有用です。組織がDevOpsチームスタイルのワークフローに移行しつつある現在、これは特に重要だといえるでしょう。

それはなぜか。DevOpsチームの2つの原則は、シームレスなコミュニケーションとオペレーションの俊敏性であるためです。ソフトウェアの継続的デリバリー（と透明性と公開性）を求める場合は、チームメンバー間のコミュニケーションギャップを回避する必要があります。また、インシデント対応時に継続的デリバリーのパイプラインを壊さぬよう、迅速かつ容易に行動できる必要があります。

同じ論理は、監視とインシデント管理にも適用されます。監視チームを継続的に活動できるようにしたい場合、リアルタイムでインシデントを特定し解決するため、瞬時に可視化されたコミュニケーションが可能な手段が必要です。素早いアクションと効率的かつ協調的な方法でチームメンバー間に責任を持たせるための方法です。チャットボットはこのすべてを可能にします。そのため、チャットロボットはDevOpsの世界を席捲しているのです。

あらゆるビジネスが デジタルビジネス に進化し、ほんの少しの停止時間でも、これまで以上に収益とブランド価値に深刻な影響を与えるようになり、危機に直面した際の効果的なコミュニケーションの必要性が増してきました。これによりサービスを開発・管理する技術チームにより高いプレッシャーがかかっているということですが、さらにデジタルトランスフォームは、ブランドの評判と顧客体験に責任を持つ他の事業部門にもプレッシャーをかけています。

製品やサービスから顧客が最大の価値を引き出せるようにする責任を負うコミュニケーション、マーケティング、とりわけサポートチームを見てみましょう。プレッシャーによって渉外機能に新しいワークフローとベストプラクティスが必要になっています。PagerDutyで私たちが学んだ実践から、これまでに磨いてきた4つのベストプラクティスを紹介します。

1. みんながオンコール担当

PagerDutyのコミュニケーションチームの一員として、私は技術担当の同僚や他の多くの人と一緒にオンコールの仕事に従事しています。受け取るインシデント通知のほんの一部を見ても、なぜ自動化とインシデント対応プロセスを持つことがスムースな運用に必要なのかを深く理解しています。それが今日のデジタルサービスをうまく稼働させているのです。何かが顧客にインパクトを与えるとき、コミュニケーションチームやサポート、営業、法務、そしてリーダーなど他の部門の関係者は、私たちが顧客と適切なコミュニケーション対応をプロアクティブに取れること、そして時が経つ間に自らのブランドと顧客の約束を守るために正しい対応を効果的にやれるのだということを、知っておく必要があります。

2.サポートと足並みをそろえる

受賞経験のある当社のサポートチームは重大インシデントに遭遇したときには顧客対応の最前線に立ちます。しかしコミュニケーションチームは次のことを理解するために整列して待機しています。

どんなインシデントでなぜそれが起きたのか？ どのくらい多くの顧客がどのくらい長く影響を受けているのか？ インシデント対応はどのくらい進んでいるのか（まだ調査中なのか解決に近づいているのか）？

インシデント対応プロセスの中では、チームは顧客との連絡窓口（注：カスタマーリエゾン）を必要とします。その窓口担当は、アプリやサービスに起きている障害がさらに悪くなりそうな時に外部と最善の方法でコミュニケーションをとれるよう訓練されている人たちです。

私たちのコミュニケーションチームは、今何が起きていてどんな影響があるのかを正確に理解するために、カスタマーリエゾンと一緒に作業をします。PagerDutyの中では、インシデントに関するSlackチャネルの一部に加え、Stakeholder Engagementという機能で情報の更新を自動化しています。我々は各チームからより抜かれた適切な人の間で協業が進むようタイトなラインを作り、顧客やより広い市場との有益なコミュニケーションが作れるように協力しています。

3.プロアクティブになろう

伝統的なチケットやITSMのワークフローを使っている場合、プロアクティブになる機会を失っているかもしれません。顧客は何か悪いことが起きるのをあなたより前に知ります。例えばソーシャルメディアなどの公開の場やニュースで彼らが気づく前にあなたが問題を修復する機会はないでしょう。コミュニケーション対応の観点からは、外向けに出すメッセージをより早く作れるよう行動するべきです。そうすれば不満のツイートや正しい情報を求める記者からの電話に対応できるようになります。インシデント対応コミュニケーションのこの段階では、傷ついた評判を修復する戦略を立てることが大事であり、理想的には事態を正常化するためにリアルタイムに起きていることを共有すべきです。プロアクティブなコミュニケーションを支援するため、我々は発生しうる危機のシナリオを特定してワークフローを作り、さらにこれまでの経験に基づいて、使うべき言葉を中心に、ベストプラクティスを作成しました。もちろん、危機シナリオは独自のものですが、平和な時に基礎を作っておけば、余裕がなくとストレスが高い戦闘中でも、素早く行動できます。

4.ブランドをリシェイプする

インシデントが解決してもコミュニケーションチームの仕事は終わりません。理想的なインシデント管理のライフサイクルの中で、重大インシデントは必ず事後検証を受けるのです。その中では関係者全員が、何が起こったのか、その対応がどう実行されたのか、今後どのように改善できるのかを議論します。これは学習と改善のための時間です。コミュニケーションチームにとしては、組織全体で協力し顧客や広範なコミュニティの信頼を回復する計画を策定し実行する必要があります。つまり当社のブランドが期待に応えられなかった部分を改善する戦略を実行するのだと考えてもらってよいでしょう。企業としての表明も改訂し、健全な判断を使い今後どうするのかを検討しないといけないでしょう。これはまた、あなたががビジネスに携わっている理由と言行一致を確約するための時間でもあります。ビジネス全体での行動が間違いを正すために必要かもしれません。

今日の、”マイクロ秒単位の時間”に支配され、常時オンが当たり前の世界で成功するためには、コミュニケーションチームは他のチームと一緒にデジタルオペレーションのエクセレンスの追及に”レーザーフォーカス”しなければなりません。これは、これまでと違う覚醒を意味するだけでなく、法外に優れた顧客体験を提供することを心の中の統一目標として、各機能部門を横串した新しい作業とコラボレーションのやり方を意味します。

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

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

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年前（注：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が起きた場合でも。

今日の統合されたデジタルエコノミーでは、ほとんどの企業のITインフラストラクチャはもはやサイロ内に留まっていることはできません。統合の圧倒的なメリットは、新しいアイデアやソリューションを急速に発展させられることです。残念なことは、統合と接続性の向上は自分たちの会社とユーザーを、サイバー攻撃、コンピュータウィルス、インフラストラクチャの問題のリスクにさらすことにもなる、ということです。

組織がシステムを保護し、データと顧客を保護するための対策に投資することが不可欠です。組織は、何かが起こる前に明確なインシデント対応計画を策定しておく必要があります。侵害または顧客に影響を与えるインシデントの検出後には、応答チームを率いる人を探し、誰が関与する必要があるかを決めるのに時間をかけるべきではありません。必要なのは、包括的なインシデント対応計画であり、企業のリーダーシップを含む総合的な対応として事前に用意されていなければなりません。

インシデント対応チームはどこまで包括する必要がある？

インシデント対応チームを組織する際は、ITインフラ、開発、品質保証の担当者を含めるべきです。しかし、他にもその代表を含めるべき部門が多数あります。

会社のリーダーシップ

広報

法務

人事

顧客サービス

危機管理

インシデント対応チームは、インシデントに対する組織の対応を監督し指揮する責任を負うべきですが、リスクを軽減しインシデントが発生する前に予防することも義務付けられます。チームのフォーメーションは、まず適切な対応計画の策定に焦点を当てて、インシデントが発生しないように対策を実施する方向に移行する必要があります。インシデントの予防と対応にさまざまな部門が関与すべき理由と、その方法を決定するために各機能を見てみましょう。

会社のリーダーシップ

インシデント対応チームの創設と成功には、最高レベルの企業リーダーの積極的参加が不可欠です。リーダーの積極性は適切なサポートを可能にし、組織のあらゆる側面にわたるチームとの整合性を確保します。リーダーシップの関与は、インシデントのフォローアップにおいても重要です。インシデントに対応する各リーダーとビジネスの調整は、効果的で迅速に対応するために不可欠です。

広報

インシデントのフォローにおいて、広報担当者が企業とユーザーの主要な接点になります。広報活動の準備の中で重要な責務は、包括的な情報開示方針の策定と、他のチームと連携して、特定の種類のインシデントに対して実行可能なシナリオに沿って対策を実施することです。

法務

法務は、契約や企業責任を担当するチームとして、会社のデータと知的財産の完全性を保護するための法的枠組みを開発する重要な役割を担っています。インシデント発生直後の期間に、法務は会社の責任を決定し、開示および通知に関する法的義務が適切に処理されるようにリードします。

人事

人事には、インシデント対応チームの初期開発段階で、社内から来た人であろうと、組織外で雇用された人であろうと、適切な人材が適切に配置されるようにする責任があります。

人事にはさらに他のチームと協力して、機密データへのアクセスを含む従業員向けのポリシーを策定し、従業員にそのポリシーを教え、必要に応じて従わせる責任があります。

顧客サービス

企業の外向きの顔として、顧客サービスチームは、潜在的な脅威を見つけて報告し、ユーザーへ事態の状況を明確に伝えるという重要なポジションにいます。さらに、既存の情報開示方針に精通し、インシデントがいつ誰にエスカレートされるべきかを理解している必要があります。また、渉外担当者は、外部ユーザーとの作業の中で直面する可能性のあるデータセキュリティ要件と潜在的な脅威を熟知している必要があります。

危機管理

最後に、危機管理チームは、コンピュータセキュリティチームと協力して、リスクが発生する前にリスクを特定し軽減するポリシーを開発し実装します。また、他のチームと連携して脆弱性評価法を開発し、実施し、潜在的なインシデントの早期警告システムとして機能する脅威検出指標を設定して監視する必要があります。

強力な防御が効果的な攻撃を可能にする

インシデント対応はIT部門の責任ではありません。ITは、対応チームで重要な役割を果たしますが、組織全体の全チームの協調的な努力こそが、インシデントに対し統一され調整された対応を可能にします。企業がインシデントを処理するための強力な防衛戦略を策定したら、インシデントが発生する前にリスクを特定し、リスクを軽減することに焦点を当てるべきです。

多くのIT組織は、クラウドインフラストラクチャ の活用はやむを得ずやることではなく、IT組織がビジネスニーズに即応するための最も効果的な方法だと悟りました。

しかし、クラウドには、ダウンタイムの最小化、運用コストの削減、社員の燃え尽き症候群防止など、新たな課題があります。企業がプロセスと手順を新しい現実であるクラウドベースのインフラストラクチャに移行するのに合わせて、これらの課題を解決するためにインシデント管理ソリューションを採用する必要があります。これはハイブリッド環境で運用する大企業の場合、つまり従来型のインフラストラクチャとクラウドベースのインフラストラクチャを混在させて、インシデント管理にもハイブリッドなアプローチが必要な場合に特に当てはまります。クラウドに移行するには時間がかかりますが、それは1回で済むものではありません。

組織がこの新しいパラダイムを受け入れてクラウドに移行する理由と、シームレスなクラウド移行のためにインシデント管理をどのように処理しているのかを見てみましょう。

なぜクラウドに移行するのか

組織がクラウドに移行するには多くの経路があります。クラウドネイティブアプリを担当する開発チームを、プライベートクラウドとパブリッククラウドの様々な組み合わせを担当するインフラストラクチャチームへと移行させ、2つのクラウドを相互接続するためのハイブリッドインフラストラクチャを構築する方法など、クラウドに移行するメリットのいくつかを見てみましょう。

インフラストラクチャ管理の削減**：クラウドサービスを活用することで、従業員は、下位レイヤーのコンポーネントをパッチして維持する必要がなくなり、ビジネス価値を提供することに集中することができます。 アジリティ（俊敏性）の向上**：クラウドインフラストラクチャ上でサービスを更新、追加、削除する機能は、企業が新しい機会に対応するスピードを大幅に加速します。 クラウドネイティブアプリ**：アジャイル開発のプラクティスと継続的インテグレーション、継続的デリバリー、マイクロサービスを組み合わせることで、チームはビジネス機能をスピードとスケールをもって提供することができます。 ディザスタリカバリとビジネス継続性**：クラウドインフラストラクチャのビルトインデータレプリケーション機能を活用することで、迅速なリカバリを目的としたセカンダリサイトの構築が可能になります。時間が経つと、これは複数のゾーンや地域に配置した冗長システムに変わります。 常時稼働**：クラウドサービスは、一般的に24時間365日稼働しており、サービスへの移行以外の余分な労力や人員を必要としません。 設備投資の無償**：クラウドサービスはサブスクリプションベースで機能するため、大きな設備投資が不要で、償却費や減価償却費を払う必要はなく、コストを運用予算に移行できます。クラウドサービスプロバイダは、資本投資を必要とする物理的環境を維持します。 市場投入までの時間短縮**：購買手続きが全くなくてもチームは新しいアイデアのテストを数日間で開始することができます。数週間または数カ月のリードタイムを必要とする従来のモデルとは異なる点です。

クラウドへの移行は、企業がより機敏に対応できる利点があるため、規模を問わず多くの組織にとって合理的です。クラウドへの移行は、やるかやらないかではなく、いつやるかという問題になっているのです。結果として、ITチームはこの新しいパラダイム内でアプリケーションを構築、運用、サポートする方法を学ばなければなりません。

クラウド環境でリアルタイムの可視性を得る

クラウドへの移行の前後にインシデント管理プロセスを導入していないと、問題が発生したときに盲点になり、インシデント対応が遅れることがあります。これらの問題は、ビジネスへのリスク、顧客への影響、および移行プロセスの遅延につながる可能性があります。また、ハイブリッドインフラストラクチャを使用したり、パブリッククラウドインフラストラクチャに完全に移行したりする場合に、これらの弱点を未解決のままにしておくと、実際のインシデント対応に支障をきたすようになります。効果的なインシデント対応でハイブリッドクラウド環境を管理することは非常に重要です。そうすればクラウドベースのアプリケーションで動作しているものをリアルタイムに把握し、移行中または移行後に問題が発生した場合に対処できます。

クラウド移行中のインシデント管理の課題

前述したように、クラウドに移行する際には、次のような新たな課題を克服する必要があります。

クラウドインフラストラクチャプロバイダとの統合と監視

クラウドネイティブアプリケーションを組織のアプリケーションポートフォリオに導入することで、複数のクラウドプロバイダー間でインスタンスを動的に追加または削除する場合でも、すべてのインスタンスを表示、レポートできることが不可欠です。現代のクラウドベースのツールからシグナルを引き出すことが重要ですが、従来のツールからシグナルを引き出せることも同様に重要です。組織がハイブリッド環境に存在する可能性が高いからです。すべてのアプリケーションが同時に移行されるわけではないため、これは移行中に大きなリスクになりますが、既存のサービスやアプリケーションを提供するには、オンプレミスとクラウドの両方のコンポーネントが必要です。

解決策：最新と従来のアプリケーションパフォーマンス管理スイートと、すべてのクラウドインフラストラクチャで使用可能なネイティブツールを理解し、統合できるインシデント管理プラットフォームを用意します。

常時オンは常時サポートが必要だという意味です

顧客は常時オンの経験に慣れてくると、自社のサービスは24時間いつでも利用できると期待しますから、問題を報告するために月曜日の朝まで待たずに声を掛けることを躊躇しません。

解決策：24時間365日のサポートを処理するために構築されたインシデント管理プラットフォームに投資し、監視ソリューションが事前に障害を検出したとき、またはクライアントがインシデントを報告したときに、どのチームに通知するかを知ることができます。その後、インシデント対応のライフサイクルを通してそのチームをサポートします。

クラウドの可視性

クラウドベースのプロバイダーから提供されるサービスが増えましたが、アプリケーション、ミドルウェア、インフラストラクチャからのイベントやアラートに必要な可視性を、顧客が影響を受けたり、あなたのプロジェクトが遅れる前に実現できるようにするにはどうしたらよいでしょうか。

解決策：複数の情報源からの情報を受け取れるソリューションに投資し、問題の影響を調査するチームの能力をサポートします。対応者が適切な情報を持って行動し、ビジネスチームやプロジェクトチームのリスクを最小限に抑えることが重要です。これにより、クラウドの移行ライフサイクルが迅速に回り、高品質なアプリケーションの変更が本番環境に導入されるようになります。

分散した労働力

クラウドにはモバイルフレンドリーなプラットフォームがあり、地理的に分散した複数のオフィスを持つ組織がますます増えていますから、単一の統一されたコミュニケーションチャネルを持つことが重要です。

解決策：従来の電話会議を使っているのか、それともSlackやHipChatなどの最新のコラボレーションソリューションを使っているのかどうかは関係ありません。目標は、あなたが話す必要がある人々を見つけられる場所を1つにすることです。SlackやHipChatのようなツールの利点は、会話を離れずにチャットに情報とアクションを持ち込めるようにインシデント管理と監視ソリューションにフックできる点です。

クラウドの移行の一環として、開発チームやビジネスユニットのニーズに合わせて、同じティアでチームをサポートする必要性を検討することが重要です。サポートチームが、開発者が展開しているものの背後にあって必要なすべてのプロセスとツールを持っていない場合、追加されたすべての複雑なレイヤは、信頼性の高い方法で使えないため、ビジネスにとっては無駄になります。

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

残念ながら、これは非常に多くのソフトウェアや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年ウォード・カニンガムが、技術的な複雑さと債務の比較を経験報告で初めて行った。（ウィキペディア）