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

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

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

優先順位をつける

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

再現

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

エスカレーション

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

調査

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

回復

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

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

脅威の影響範囲は狂ったようなペースで拡大しています。毎日新しい脆弱性が露わになり、ITOps担当者が管理するサーバ、アプリケーション、およびエンドポイントの量は絶えず増加しています。最近の世界的なランサムウェア攻撃の脅威が数千ドルを加害者に稼がせていることで分かるように、これらの脅威はさらに強力になり頻発するようになっています。専門家は、犯罪者がしばしばデータ破壊の試みを隠す偽装をしていると考えています。

組織がより機敏になるようバイモーダルITOps（2つの流儀のITOps）の手法を採用するにつれて、インシデントを回避し、セキュリティを強化することはかなりの難題を引き起こす可能性があります。新しい課題には、コンテナとパブリッククラウドリソースを活用することと、これらの別々のデータドメイン間でセキュリティインシデントを管理すること、そして重要なリソースにアクセスできる新たな擬似管理ユーザーの集団を運用することが含まれます。ますます拡大するITOpsの要求に対して全層に渡る可視性とインシデント解決を可能にするには、SecOpsへの多面的な戦略が必要です。実際、SecOpsインシデント管理は、実用的で見やすい真に安全な環境を構築するために必要な組み合わせだという考えに私は傾いています。

フェーズ1：脅威を止める

まず第一に、SecOpsスタックの複雑さを軽減することが、SecOpsポリシーを実施するのに役立ちます。簡単に言えば、攻撃を阻止し、ITOpsチームに修復する必要があることを通知します。単純さは、セキュリティアラートやインシデントのノイズを削減し、本当に重要なシグナルに集中できるようにするためにに重要です。SecOpsのプラクティスでは、チームが組み込みのストップウォッチを活用して、可能な限り迅速に対応し、脅威がSLAや重要なデータに損害を与える前にそれを停止することを保証します。過酷な状況の好例は、ネットワークとシステムがゼロデイ攻撃やランサムウェアにさらされている場合です。このような場合、重要なのは、大規模な脅威への暴露を防止し、インシデント管理システムにアラートを発行するという戦略を構築することです。CryptolockerやCryptowallのような暗号化されたランサムウェアの場合、そのランサムウェアが脅威をもたらすのを防ぐツール（ソフォスのインフォグラフィックスの第2段階を参照）を利用して、ハンドシェイクを防ぎ、暗号の感染を回避することが目標です。

ファイアウォール、エンドポイント、第三者のセキュリティ監視ツール、およびその他の関連するデータソースを、中央のインシデント管理ソリューションにパイプすることができます。このように、SecOpsとITOpsには、優先度の高い問題の効果的な調査と修復に必要なデータとワークフローが即座に通知され、装備されます。効果的なセキュリティツールを使用することは、セキュリティインシデントの管理の成功に不可欠です。

フェーズ2：インシデント管理と修復

問題を検出して通知する能力だけでなく、事態の収れんや将来の予防策を十分に考えておくことは、ベストプラクティス、エンドツーエンドのセキュリティインシデントライフサイクル管理と同様に重要です。また、このフルスタックの可視性を実現するには、すべてのセキュリティシステムを集中的なインシデント管理ソリューションに統合して集約したいと思うでしょう。例えば、SNMPトラップ／クエリを活用して監視プラットフォームに情報を集約するようにファイアウォールやネットワークデバイスを構成します。さらにsyslogサーバーを統合し、すべてのセキュリティインシデントをこれらのソースに送信するようにします。

ファイアウォールとネットワークのsyslogを設定するときに、Info、Debugアラートと、Warning、Criticalアラートの間のしきい値を設定することで、かなりの時間を節約し、アラート疲れを軽減できます。ベンダーによって、しきい値が異ながす。 ただし、SNMPではOID（注：オブジェクトID）をフィルタリングしてInfo、Debugアラートを無視しWarning、Criticalアラートを許可することで、重要度の高いアラートのみをインシデント管理システムへ送信させるようにできます。

syslogを使用すると、より詳細なログ条件を設定できますが、ここで重要な点は、ノイズを抑えて特定の条件に合う場合にのみ通知させることです。これらのイベントを監視システムに集約できれば、実行可能な情報でアラートを強化したうえでチームに送信して脅威を修復するフレームワークを構築できます。

syslogは、いくつかの理由で価値あるものになります。監視システムに流入するセキュリティとネットワークデータに関する詳細な情報を取得するだけでなく、侵入検知と防御と脅威情報の収集も容易にすることができます。syslogを監視システムに直接つなぐのではなく、syslogデータをAlienVaultやLogRhythmなどのサードパーティの侵入解析システムに送信して侵入を容易に見つけられるようにしたり、ログデータを豊かにしたり、即応性の高いアラートを作成したりすることもできます。その後、PagerDutyなどのインシデント管理システムにアラートを送信して、関連のある症状をグループ化し、根本的な原因を理解し、適切なエキスパートにエスカレートし、適切なコンテキストで是正し、今後のセキュリティインシデント対応を改善するための分析や反省を実施できます。

結論**：セキュリティツールを活用して脅威を実際に阻止する

ベースラインモニタリング**：ベースラインのモニタリングおよびアラートポリシーを確立する

エンリッチメント**：サードパーティのツールを活用してデータと脅威情報を強化にする

インシデント管理**：フルスタックの可視性を最大化し、問題の優先順位付け、ルーティング、エスカレーションを保証します。ワークフローと分析で解決までの時間を短縮できます

最後に付け加えると、ハイブリッドクラウドやパブリッククラウドのリソースを使っている組織でも、同じフレームワークを実装できます。ただし可視化とアラート分析を強化するには、さまざまなサードパーティのツールを活用する必要があります。たとえば、Amazonクラウドを利用する際にはAWS Cloud Watchを活用して、あるいはMicrosoft Cloudを活用する際にはAzure Alertsを活用することで、パブリッククラウドサーバーの監視とアラートを使い、類似のしきい値の設定とノイズ削減が可能になります。さらに幸いなことに、Evident.ioやThreat Stackなどのサードパーティのツールもあり、アジャイル、パブリック、ハイブリッド、またはバイモーダルのITOps戦略を持つ誰もが、クラウドインフラストラクチャ全体にわたってセキュリティに焦点を当てた分析を簡単に実行できます。

SecOpsチームに合う完全なインシデント管理プロセスを設計する際に活用するツールやシステムは、シンプルさ、可視性、ノイズリダクション、実行可能性といった基本的な部分がその成功に最も重要な要素になります。ITOpsとSecOpsのチームはビジネス上に求められるものでは非常に似通った立場にいます。そこでは、2つのチームが絶え間なく増大するデバイス、サービス、およびその他のエンドポイントのリストに安全かつ効率的にアクセスする能力とビジネス上の要求がしばしば競合します。

セキュリティインシデント対応のベストプラクティスの詳細をさらに知りたければ、我々が社内で使っているPagerDutyのオープンソースドキュメントを参照してください。実行可能なチェックリストと、攻撃方法を遮断する方法、レスポンスチームを組織する方法、侵入されたデータを処理する方法などの情報を得ることができます。これらのリソースが、効果的なインシデント管理を備えたSecOpsを最適化するための強固なフレームワークを構築する上での最初の出発点になることを願っています。

インシデント管理は、現代のITOpsチームの成功に最重要です。しかし、ビジネスを成長させるようにインシデント管理をスケールさせることは、成長の痛みを引き起こす可能性があります。監視が必要なデバイス、アプリケーション、システムの規模が拡大するにつれて、ノイズも増え、オンコールスタッフの管理の複雑さも増えます。チームのエンジニアの数が増えるにつれて、効率的で負荷が公平に分散されるような人員配置や、新しい通知方法の実装、時間外の運用計画を立てるのが困難になります。また、ITのハイブリッドモデルとバイモーダルなIT環境を志向する動きは、インシデント管理を複雑にする可能性があります。それにもかかわらず、いくつか実証された技術を試してみると、インシデント管理を計画的で組織的かつ効果的な方法で拡張することができます。

変化するITOps環境に被害を与えない

スケーリングが深刻な問題になる例を参考にまずこの問題の重要性を理解しよう

あなたは会社が新しい事業を買ったのを知りました。そこで、あなたは新たなインシデント管理プロセスを始めることになります。あなたのOpsチームは、すでに担当していることに加えて、新しいIT環境を引き継がなければなりません。まずあなたは、新しいスタックに同じツールと方法を適用することができる完璧なシナリオがないかを考えます。

しかし、現実は完璧ではありません。新しい会社は、以前と違う技術スタックと異なるインシデント管理の監視ツールと方法論を活用するかもしれません。このシナリオは非常に困難ですが、ITチームの成長や、よりアジャイルでバイモーダルなITOps構造の採用など、あらゆる成長シナリオと非常によく似ています。あなたがどんなスケールのシナリオに直面するにせよ、監視、インシデント管理、およびチームの拡大に取り組んでいる組織のためには下記が参考になります。

スケールの主な領域を特定する

新しいハードウェア、ソフトウェア、またはサービスを実装していますか？ あなたの将来のITOps環境には新たな複雑さがありますか？ あなたのエンジニアリングチームは育っていますか？ コードエラーを報告する必要があるアプリケーションを継承しましたか？ いずれの場合でも、ITOpsチームが業務を拡大することを余儀なくされている分野を特定する必要があります。

監視ツール

監視ツールが確実にスタック全体をカバーできるようにすることは、スケーリングの成功に最も重要です。この変更を採用するには、現在のスタックの外に複数の、または全く新しい監視システムを実装する必要があるかもしれません。これらのシステムの目的は、フルスタックの可視性を得ることであり、多くの場合、異種システムや新しいシステムを適切に監視するために、さまざまな監視ツールを実装する必要があります。しかし、組織化されたスケールを本当にサポートするには、このデータすべてを正規化し、重複を排除し、相関を取り、実行可能な洞察を得る方法が必要です。各監視ツールによって生成された全イベントを、単一のハブに集中させる必要があります。このハブからはイベントがトリアージされ、オンコールエンジニアにルーティングされるようにできます。

ノイズ減少

監視を実施するのは、効果的なインシデント解決のためにデータを理解することが目標です。監視ツール全体のルーティング動作を調整し、適切なしきい値を設定することは、新しいツールを実装した後にチームがアラート疲れを経験しないで済むようにするための次の大きなステップです。データを集約し、共通のインシデント管理システム内のページングからの対応不能なアラートを抑制またはフィルタリングすることは、ノイズを削減し、スタック全体のインシデントの可視性を高めるために重要です。

事故管理

包括的なインシデント管理プラットフォームは、すべてのツールのデータを統合し、スケールを拡大しながら成長するのに役立ちます。これは、すべての異種監視アラートを1つの共通システムに統合するだけでなく、リソース管理に関する混乱を防ぎ、エンジニアリングチームの成長をサポートします。さらに、より組織的なコラボレーションだけでなく、よりアカウンタビリティを促進するのに役立ちます。ボーナスとして、インシデント分析を活用して、上司にITOpsチームがどれだけうまく稼働停止を管理し解決するかを示すことができます。

スケールと複雑さは去っていません

ITOpsの世界は急速に進化していますが、1つの点は明らかです。ITチームは、業務拡大に全力を傾けるように指示されています。ITOps環境は、よりハイブリッドでアジャイルなアーキテクチャとフレームワークへと移行しています。ユーザーは、さまざまなデバイス間でデータへの高速で信頼性の高いアクセスを絶えず要求しています。その結果、ITOpsチームはスケーリングの計画を立てる必要があります。ダウンタイムの損害が大きくなるにつれて、インシデント管理が必要になっているのです。

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

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

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

ファーストデータの定義

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2020年7月初め、多くの地域で、サービスプロバイダーのルータの設定ミスによる大規模なインシデントが発生しました。これにより、サービスの障害が連鎖的に発生し、いくつかの有名なSaaSに広範囲の停止と混乱を引き起こしました。

障害が発生したとき、我々PagerDutyのチームはすぐにイベントやインシデントの世界的な急増に気付きました。いくつかの組織内でアラートやインシデントが増加することは珍しくありませんが、今回のケースでは、複数の地域で多数発生していました。これは懸念材料でした。

インシデントの量が異常に増加した場合には、問題に対処するために総力を挙げて対処できるように、予防措置としてメジャーインシデント対応を積極的に展開しています。対応者にタイムリーに通知を行うために、PagerDutyのモバイルアプリを使用して、必要な関係者がどこにいようとも、即座に連絡を取るようにしています。

この特定の問題は、私たち全員がリモートで仕事をしている時に起きたので、私たちはSlackとZoomを使って対応を調整しました。PagerDutyとSlackとのインテグレーションを利用して、インシデント責任者、エキスパート、利害関係者、記録係からなる完全にリモートのチームを編成し、サンフランシスコ、トロント、アトランタで協力して大規模なインシデント対応を3分以内に完了させました。

当社のインシデント責任者が対応を調整し、カスタマーサポートが内部と外部の情報更新を管理し、専門分野のエキスパートが取るべき必要な手順を議論し、記録係が対応の進捗状況とコミュニケーションを文書化しました。

幸いなことに、当社のシステムがインシデントトラフィックの急激な増加に対応できることを迅速に判断し、問題を沈静化することができました。

リモートインシデント対応の重要性

完全に遠隔地での作業環境でのこのような大規模なインシデントは、場所に関係なく、インシデントを迅速に受任し、チームとして対応することの重要性を浮き彫りにしました。PagerDutyでは、分散化した作業と対応の文化は、初日から私たちのプロセスに組み込まれています。実際、当社のインシデント対応ドキュメントを見てみると、対処中に対応者の物理的な接近を必要とするプロトコルは1つも見当たりません。PagerDutyプラットフォームを使えば、どこにいても、インシデントに瞬時に対応し、作業することができます。

また、SlackやZoomのようなコラボレーションツールを利用して、インシデント発生時にリアルタイムでコミュニケーションを取ることもできます。今回のケースでは、PagerDutyとSlackのインテグレーションが、インシデントの状況と関係者への情報更新のための中心的なハブとなりました。Slackで当社のチームメンバーは主要な利害関係者に通知し、役割を割り当て、仮想的な場所に集まり、インシデントに真正面から取り組むことができました。

さらに、インシデントが解決したあとにも、Slackは事後検証のプロセスに役立つため、将来の対応プロセスにも貢献します。記録係はSlackインテグレーションを使用して、対応中に発生したすべてのことを文書化して記録します。誰が対応したのか、誰が対応しなかったのか、なぜエスカレーションしたのかなど、起きたことをすべて見ることができるので便利です。これにより、インシデントの全体像を把握して理解することができ、将来インシデントが発生した場合でも、より迅速に対応して解決するためのプロセスを改善することができるようになります。

私たちの分散型エンジニアリングの文化は、PagerDutyが何があってもお客様のために常にオンになっていることを保証することを可能にしています。PagerDuty をコラボレーションツールや明確に定義されたプラクティスと共に真実の単一ソースとして使用することで、事実上どこからでもインシデントに効果的に対応することができます。多くの場合、オフィス内のオーケストレーションから仮想的な対応に移行することは困難だと思うでしょうが、PagerDuty を使用することで、ほとんどの場合、通常通りの業務を行うことができます。

チームがどのように PagerDuty を使ってリモートインシデントレスポンスを行うかについては、分散型コミュニケーションに関するこのブログを参照してください。

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

顧客は、価値観 を共有していると 感じる企業に忠実です。予期せぬ出来事が企業を襲ったとき、結果として生じた激動がブランドを危険にさらします。航空会社の災難や、テクノロジーシステムを巻き込んだ性能に関するインシデントなど、これらの瞬間は、顧客にサービスする能力を低下させることで、顧客体験に影響を与えます。顧客にブランドへのアクセスを提供するデジタルチャネルが増えている状況で、今日の現実は、世界中がポリシーや行動を監視する中で企業は事業を展開しているということです。

このシフトの影響から、CEOのオフィスにブランドが置かれるようになり、インシデント対応の中で企業のコミュニケーションを重視させる一因になりました。しかし、このチャレンジは企業のコミュニケーションのように、テクノロジー、製品、セキュリティなどのインシデント対応の共通部分にフォーカスする傾向があります。しかし、実際に問題となるのは、全ての側面がインシデント・オペレーションに書記から統合されていた場合、予期しない事態が発生したら、それらがどうに連携して最も効果的な戦略になりうるかです。

最近のForbesの記事で私たちは、危機の最中、特にインシデントのニュアンスが見落とされたときに、組織がブランドを保護するために使える3つのコミュニケーションのヒントを紹介しました。このような状況でストーリーラインをコントロールすることは、企業のコミュニケーションの責任です。彼らの役割は、オペレーションと顧客との関わり方を変えられるコミュニケーション計画を準備し実行することです。企業のコミュニケーションがインシデント対応業務に合わせて準備されている場合、次の点に対応できるメリットがあります。

出血を遅らせる

重大インシデントでは、技術とセキュリティの関係者だけが含まれる古典的な対応チームが組織されることがよくあります。 専門家が問題を特定して解決する間に、企業のコミュニケーションチームは待機させられ、対応作業に遅れをとります。 その一方で、デジタルチャネルを横断して世論が醸成され、形成されています。 レポーターは複数のストーリーを公開し、コミュニティ、ユーザー、パートナーはソーシャルチャネルを通じて意見を共有しています。インシデントの進展に合わせて企業のコミュニケーションチームを早期に巻き込むことで、危機に瀕しているブランドの出血を遅らせる機会が得られます。

ブランドの再構築

ポストモーティム（事後検証）のフェーズでは、重大インシデントに巻き込まれたビジネス全体の関係者が集まり、何が起こったのか、どのように対応業務が実行されたのか、何が改善できるのかを議論します。事態が終息すると、企業のコミュニケーションチームは、顧客やコミュニティの信頼を回復するために組織の舞台裏で働きます。彼らは企業側のメッセージを次にどこへ届けるかを決定し、PRの機会として何をすべきか、あるいは何をしないべきかを決定するために良い判断を下します。危機後に各ブランドは顧客の評判を素早く回復するためにどれだけのケアと行動を取ったかを顧客に迅速に伝えます。時には、整合性が取れない行動に直面したり、次の関連イベントが発生したりして、バックファイアを食らうことがあります。

デジタル時代には、企業の運営方法やコミュニケーションの役割に対する期待が急速に高まっています。新しい技術が登場し、デジタルチャネルが増加する現在、重大インシデントへ対応するための運用の初期段階でコミュニケーションを統合しておくことが、お客様のブランドが世間から否定されず称賛されるという差を生み出します。

2018年はPagerDutyにとって極めて重要な一年でした。 過去6ヶ月間にわたり、私たちは多くのPagerDutyの新機能の開発を加速し、デジタルオペレーション管理プラットフォームとモバイルアプリケーションのさまざまなアップデートと拡張をリリースしました。

これらの機能により、各組織は、レスポンス体制の編成と継続的な開発と配信をさらに最適化できます。開発者、運用チーム、DevOpsの実践者、および管理者が、コンテキストの洞察とインタラクティブなアプリケーションを通じて、カスタマーエクスペリエンスのあらゆる側面を視覚化できるようになります。

(訳注：下記の新機能の機能名は英文が正式名称です。和文の名称はDigitalStackが仮に訳したもので、正式ではありません。)

新機能のリリース

イベントインテリジェンスのリリース

最新の製品であるイベントインテリジェンス（Event Intelligence）は、デジタルシグナルと人間の対応行動の両方を組み込み、機械と人間のテレメトリーを組み合わせて、デジタルオペレーションを最適化します。自動適応学習アルゴリズムは、ノイズを削減し、チームがイノベーションと生産性向上に容易に集中できるようにします。 統合されたイベントインテリジェンスとインシデント対応により、誰もが同じ情報に接し、問題をより迅速に解決するために必要なコンテキストが確保されます。 ルーティングとワークフローの自動化、インテリジェントなアラート相関分析、ノイズ抑制、類似インシデントの憑依、API、およびプログラマビリティが連携して、レスポンダーが必要とする正確なマシンと人間のコンテキスト情報を提供します。

イベントルール（Event Rules) 、PagerDutyのルーティングとワークフローの自動化機能は、200以上のツールから大量のイベントデータをプログラムで管理するのに役立ちます。 イベントデータ、問題の重大度、サポート時間などに基づいて、ルーティング、抑制、通知、およびその他の動作をインテリジェントに自動化できます。

インテリジェントアラートグルーピング（Intelligent Alert Grouping）により、重要なコンテキストを集中しながらノイズを削減し、適応的機械学習とルールベースのアプローチによって、複雑なシステムにわたる関連する着信アラートを自動的にグループ化して１つのインシデントすることで、トリアージをスピードアップします。

類似インシデント（Similar Incidents)は 、トリアージを改善するのに役立つように、インシデント内に過去の関連のある問題を自動的に埋め込んで表示します。過去に類似の問題を処理していたエキスパートや過去のその問題の発生頻度を把握したり、過去のインシデントから得たより迅速に問題を解決するのに役立つ修復手順を含めて、状況に応じた洞察を得ることができます。

継続的な強化

今年の年初に、モダンインシデントレスポンス（Modern Incident Response）機能をリリースしました。私たちは、顧客からのフィードバックを取り入れながら、この製品を引き続き改良し続けています。

モダンインシデントレスポンス（Modern Incident Response）機能 の更新

既にPagerDutyのレスポンスプレイ機能を使用し、複数のチームのレスポンスをモバイル化し、ワンクリックでインシデントに関するアップデートを送れるようステークホルダーを登録している方もいらっしゃると思います。今夏からはさらに レスポンスブリッジ（Response Bridge）をレスポンスプレイにつなぎ合わせて、レスポンダーがシームレスにコラボレーションできるようになりました。この機能によって問題の最下部までレスポンダーが下りていけるようになり、ビジネスの重要なサービスをすばやく元に戻せるようになります。

ライブコールルーティングの機能拡張（Live Call Routing enhancements）。 電話番号をダイヤルしてオンコール通話相手にすぐにアクセスできるほか、重要なアプリやサービスに関連付けられたオンコールスケジュールとエスカレーションポリシーでオンコールをルーティングすることができます。

あるコールが次のレスポンダーにエスカレートする前に鳴動時間をカスタマイズする

自動受付の文言をカスタマイズする

コール内容を文章に転記する

この柔軟性は、さまざまなチームの対応プロセスに対応し、チーム全体および組織全体の学習を促進します。

レスポンスのモバイル化中の全エスカレーションのインシデントタイムライン項目化。 インシデントレスポンスに携わっているのが誰かを知ることは、インシデントレスポンスを加速するうえで重要であり、適切な人材を重要な問題の解決に専念させ、他者が開発に戻れるようにします。 PagerDutyのインシデントのタイムラインは、レスポンスプレイ、カスタムインシデントアクション、チャットの会話など、豊富なインシデント関連アクティビティをキャプチャします。 現在では、レスポンスのモバイル化中に発生するすべてのエスカレーション関連アクティビティもインシデントのタイムラインに記載されており、定期的な問題や新たな問題に直面した場合に貴チームが信頼する貴重な事後検証（ポストモーティム）にその内容を簡単に含めることができます。

クリティカルインシデント関連の活動をどのようにあなたの事後検証に含めることができるかについて詳しくはここでご覧ください。

インテグレーションとAPI

PagerDuty開発プラットフォームは柔軟なAPIと拡張性ツールを提供しており、どんなチームもPagerDutyと簡単に統合して拡張することができます。 私たちはすでに280以上のビルトインのインテグレーションとエクステンションをカバーしており、さらに追加しています！

最新の PagerDuty とServiceNowの公認インテグレーションは、ITチームが重要なサービス管理およびセキュリティインシデントの問題にリアルタイムで対処するのに役立ちます。 チームは脅威を緩和し、根本原因の特定とサービス修復を加速する力を得られます。 この統合により、チームは解決までの平均時間を短縮し、デジタルでの障害がビジネスへ及ぼす影響を軽減できます。

サービス群とチームの同期

ServiceNowプラットフォーム全体にわたるリアルタイム応答

自動化されたエンタープライズワイドなモバイル化

セキュリティインシデントレスポンスの迅速化

PagerDuty + Microsoft AzureとVisual Studio Team Services（VSTS)は、もうひとつの新しいインテグレーションです。ソフトウェア開発のライフサイクル全体を通して、チームに運用上の健全性の洞察とイベントインテリジェンスを提供することに私たちも大きく期待しています。各チームは、PagerDutyとMicrosoftを使用して、アプリケーションのコーディング、所有、および管理を効率的に行うことができるため、顧客に影響を与える問題を先取りしてより高品質なアプリケーションやサービスを迅速に提供できます。 その他の利点は次のとおりです。

PagerDutyインシデントとMicrosoft Azure Metric AlertsとMicrosoft Visual Studio Team Services Work Itemsとの自動同期

新しいMicrosoft Azure Metric Alertsフォーマットのサポート

インシデントレスポンスとサービス提供の迅速化

改善されたコンテキストによる開発サイクル時間の短縮

各サービスとAzureインフラストラクチャ全体の可視性の向上

V2 webhooks。 インシデントベースのWebフックを使用すると、インシデントが発生したときに外のWebhook URLにWebhookメッセージを送信できます。 Webhook受信者は、ID、イベント、作成日時、インシデント、ウェブフック、およびログエントリなどの複数のメッセージ要素を含む、メッセージ配列のペイロードを受信できます。

あるアカウントに拡張機能を追加するためのAPI 。 APIを介してサービスに拡張機能（webhookなど）を追加できます。

モバイル

アップデート： iOSのUniversal Linksのサポート （訳注：Universal LinksはiOS 9以降で導入されています）。レスポンダーが時間を節約できれば収益とカスタマーエクスペリエンスにポジティブなインパクトを与えられるため、調和のとれたモバイルエクスペリエンスが、レスポンダーにとってとても重要です。そのため、私たちはiOSのUniversal Linksのサポートを実装しました。 iOS Safari、Mail、Messagesからタップされた、インシデント、エスカレーションポリシー、ユーザーへのリンクは、PagerDuty Appでシームレスに開けます。

モバイルアプリについて多くのご意見をいただきました。人々はどこにいてもモバイルデバイスからアクセスできて、エスカレートできるようにすることが大好きなので、次の機能を追加することでアプリをさらに便利にすることに決めました。

iOS 1Passwordインテグレーション 。

インシデントの中の詳細、メモ、電話番号とURLをクリック可能に。

インシデント優先度（Incident Priority）のサポート （詳細、インシデントリスト、ソートなどを含みます）。

インシデントタイムラインのレスポンダリクエストとメモのiOSの電話番号とURLをタップ可能に。

PagerDutyモバイルアプリでのライブアップデート対応。この詳細については、 エンジニアリングのブログをご覧ください。

これらは2018年のこれまでに用意した全アップデートです！ しかし、今年はまだ終わっていませんし、後半に発表する予定も増えています。製品や機能の最新かつ最大限の情報を知るためにチューニングはそのままにブログをチェックしてください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

クラウドの可視性

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

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

分散した労働力

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

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

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

オンコールエンジニア は インシデント 管理 で重要な役割を果たします。 彼らは、インシデントをクリティカルな状態から管理された状態に変える役割を果たし、迅速に解決します。

スタートアップには誰がコールを受けるべきかについてあまり多くの選択肢がないかもしれませんが、組織が成長し、インシデント管理がより複雑になり、関係者が増えるにつれて、構造化されたプロセスを用意しておくことがオンコールエンジニアにとって重要になります。スタートアップ企業であれ大企業であれ、オンコールエンジニアを成功させるための明確なプロセスを用意しておくことで大きな利益を得られます。 ここにいくつかのガイドラインを示します。

最初の対応が重要

インシデント発生の最初の数分間で、オンコールエンジニアはインシデントの重大度とサービスへの影響を把握する必要があります。それに基づいて、影響を受ける下流のサービスと、誰がそのインシデントを解決する必要があるのか​​、そしてその人たちを迅速に実戦に投入する方法を判断する必要があります。これには、何かが壊れたときに根本原因を特定し、作業の優先順位を決定できるように、システムがどのように機能しているかを実践的に知っておく必要があります。オンコールエンジニアのローテーションは自動的にスケジュールされます。こうすれば負荷が分散され、チームは公平性と説明責任のために最適化され、誰もがインシデントを処理でき、接触を失うことはありません。大規模なチームでは、最初の対応を開始できる専門のインシデント管理者がいることがあります。いずれの場合も、オンコールエンジニアの主な目標は、インシデントのトラブルシューティングや解決ができない場合でも、インシデントを解決するために必要なリソースを取り込むことです。

2次オンコールエンジニアを用意しておく

2次（そしておそらく3次も）のオンコールエンジニアをバックアップとして持つべきです。 そうして、第1レベルの対応者が寝過ごして午前3時の電話連絡に気づかなくても、何も谷間に落ちないようにします。これはまた、チーム内の役割のローテーションのスケジュールが必要だということです。1次担当のエンジニアからの応答がない場合、インシデント通知がバックアップエンジニアにエスカレートされるように、自動化されたルールを設定します。

オンコールエンジニアが必要なトレーニングを

受けていることを確認する

インシデント発生時には多くの問題が発生するため、オンコールのエンジニアはプロトコルを遵守し事態の推移に遅れず考えることができる必要があります。 彼または彼女は、さまざまな部門間のステークホルダー（顧客サポート、マーケティング、PRなど）が連絡を取り合う適切な方法も理解しておく必要もあります。そうすれば修復状況を外部に伝達できます。インシデントが発生した場合に従うべきチェックリストまたはフローチャートをオンコールエンジニアに渡しておくと便利です。

ダウンタイムの1分ごとに何千ドルもの損失が発生する可能性があるため、オンコールエンジニアができるだけ早くインシデント対応をする必要があります。そのための手順は次のとおりです。

インシデントの特定とログ作成

まず、インシデントを特定または検出してログを作成します。ロギングは、問題の根本的な原因を迅速に突き止めるのに役立ち、解決後のインシデントの包括的な事後検証の進め方を示してくれます。インシデントに迅速に対応することが重要なので、特定とロギングは迅速かつ体系的に行ってさっさと次のステップに進む必要があります。

カテゴリを分けて優先順位を付ける

チームが遭遇する可能性がある問題はその種類が膨大なため、混乱を避けるためにインシデントを分類することが重要です。影響を受けるユーザーの数、影響を受けるサービスに関する問題の「爆発の半径」、潜在的な収益への影響などに注意してください。インシデントの優先順位を設定することで、オンコールエンジニアは、インシデントが残りのチームの時間とリソースを必要としているかどうかを連絡することができます。可能であれば、チーム全体の時間を節約するために、あまり複雑ではないマイナーなインシデントにはエンジニアだけで対応できるようにしておくとよいでしょう。オンコールエンジニアが重要なことに集中できるようにするため、行動不可能なアラートは抑制する必要があります。

正しい人に通知する

PagerDutyのようなプラットフォームやそれに内蔵されたChatOpsやコラボレーションは、関係する人材を採用し、その人たちを適切なタイミングで適切な場所に集めるためのベストプラクティスです。特に、特定のChatOpsチャンネル/会議室、ビデオ通話と会議での共有、コンテキスト内の問題の修正機能を使うと、解決のスピードとビジネスの影響レベルに大きな違いが生じます。チームメンバーとコミュニケーションしている間は、自分と他の人の時間を節約するために、事件の説明を簡潔かつ理解しやすくすることも重要です。チームはアラートが多すぎて注意をそらすことがあるので、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つのインシデントにグループ化する必要があります。理想的には、これはルールを介して自動的に行われるべきです。さらに、アラート疲れや報告忘れが致命傷になる可能性があるため、チームメンバー全員にアラートするのではなく、適切なチームやチームメンバーだけにアラートを送るシステムを導入することが重要です。

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

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

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

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

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

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

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

ボトルネックの解消

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

インシデント管理は、アプリケーションをサポートする大事な要素です。アプリケーションの仕事をするとき、私たちはプロダクション（本番バージョン）のリリースに大部分の時間を費やします。これには、ロードマップについての打ち合わせ、ニーズと要望の特定、私たちのストーリーと機能の構築が含まれます。その後、多くのサイクルが開発、テスト、QA（品質検証）に費やされます。エンジニアリングチームは環境を準備しながら作業します。その後、アプリがローンチを迎え、チームは次のアプリに移ります。アプリを本格的に提供するのは運営チームの責任です。これがアプリとのやりとりの終わりである場合、開発チームは、改善に関する貴重なフィードバックを多く未解決または未発見のまま残しています。 そこで、インシデント管理プロセスが、アプリケーションを改善し、最終的にお客様にとってより良いエクスペリエンスを提供する鍵を握ることになるのです。

1. 必要に応じて迅速にエスカレーションし、解決までの時間を短縮する

明確かつ十分に利用されるインシデント管理プロセスがあると、アプリケーションサポートは組織文化の自然な一部となります。インシデントは、ベストプラクティスを反映した方法に沿ってより迅速に、より一貫して解決されます。明文化されていなかったり不規則だったりするインシデント管理は、解決と絶え間ない消火作業で試行を繰り返すことにつながる可能性があります。

2. クロストレーニングを奨励する

「夜中に誰かを起こしてそれを修正させる」という原則に従って、インシデント管理プロセスは、開発チーム内とチーム間の両方でクロストレーニングを奨励します。 これには、コードの可読性の重要性を強調し、コメントすることで、運用文書と構成管理を最新の状態に保つことを奨励するという副次的な利点があります。

3. 信頼と透明性の文化を築く

開発チームのすべての人は、バックアップとプライマリの両方でエスカレーションのローテーションに参加する必要があります。これはコミュニケーションとチームの友情を深めます。また、透明性を奨励することで、オンコールに出る開発者はすでにアプリケーションの一般的な感覚を持っているはずであるため、解決までの時間が短縮されます。 チームがマイクロサービスのパラダイムに従っており、各アプリケーションに1つのサービスを含む場合、これはさらに強化されます。

4. ジュニアスタッフの成長の道を提供する

私たちは、私たちが前進するために急いで来た場所を振り返ることをしばしば忘れています。 チームはまた、思考や意見の多様性から恩恵を受けます。インシデント管理プロセスでは、エスカレーションパスのすべてのレベルをアプリケーションに公開することで、これを促進できます。インシデントを解決することは、ジュニアメンバーにより多くのチームのことを理解させるのに役立ちます。特定のインシデント解決について貴重な知識を得る一方で、アプリケーショントポロジの包括的な設計にも触れる機会が持てます。才能ある人を募集し維持することは、組織にとって重要です。第1層のインシデント対応から開発およびエンジニアリングチームまでの可視的なパスを提供することは、貴重な採用ツールになります。

5. より良い全体プロセスを作成する

継続的なインテグレーションと継続的な配信技術を組み合わせることで、以前の月次または四半期の導入よりも迅速に展開されます。 これはインシデントを促進し、量と頻度を減らします。 これの成果は、はるかに短い時間枠でバグを修正でき、繰り返しの一時的な修正の必要性を大幅に削減できることです。 これにより、エンジニアリングチームとオペレーションチームの技術的負債の蓄積も少なくなり、実践的に役立つ修正の道が開かれます。

6. 定量的フィードバックを生成する

追跡される各インシデントは、多くのもののカプセル化です。 これには、修理のための複数の人の時間、解決を記した文書、おそらくバグレポートの提出が含まれます。また、アプリケーションを操作する際に苦労する点の評価も明らかにするに違いありません。これにより、アプリケーションのロードマップを知らせることができ、実装可能な高価値、低エフォートな機能拡張に関する会話を促進することができます。

7. 内部ツールを開発する

チームが一定のサイズに達すると、職務の差別化が行われます。 これは組織の自然な進歩であり、規模を拡大する方法です。 以前はうまく機能していたアプリケーションを操作するツールは、組織の成長を維持するために不可欠になっています。 インシデント管理プロセスは、このニーズだけでなく、これらのツールを作成するときに開始する場所を明示することもできます。

アプリケーションのインシデント管理は、多くの場合、顧客サポートと成功にとっては重視されないものですが、顧客はアプリケーションの一部のみを見ています。 彼らが経験するのは、アプリケーションのレイヤーを通る狭いパスだけです。 もっと目に見えるくらいアプリケーションの復元力が高く、インシデントが迅速に解決されるほど、すばやくアプリケーションを使用することができます。

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