IT インシデント管理、対応、防止の未来

5 年前を振り返って、IT チームに誰がインシデント管理を担当していたか尋ねてみてください。ほとんど場合、答えは「私たち」でしょう。

そして今、同じ質問をしてみてください。IT だけでなく、DevOps、SecOps、アーキテクチャ チームも答えに出てくることが多いでしょう。多くの組織が「構築した者が運用する」という考え方に徐々にシフトしています。

このアプローチの明白なメリットは、IT チームのプレッシャーを取り除いてコードに最も精通した担当者に責任を移すことによって、応答時間を短縮できることです。これによって、ダウンタイムが最小化されてチームの生産性が最大化されます。また、優れたコードを作成する動機付けとなります (バグを解決するために午前 3 時に起こされた人は、今度は午前 3 時に起こされることがないように、次からはコードをダブル チェック、トリプル チェックするでしょう)。

このアプローチの課題は、組織にはまだ集中化が必要であるということです。リーダーは、レポートやドキュメントにアクセスする必要があります。ビジネス関係者は更新情報を求めています。平均解決時間や平均確認時間などのインシデント指標を確認したいと考えています。明確なインシデントの更新情報、インシデント事後分析レポート、修復作業を期待しています。

分散化への移行が順調に進行している多くの企業にとって、この課題に対する答えは、分散化とチームの自律性によってインシデントを迅速に解決し、情報を一元化してビジネスで常に最新情報を共有できる技術です。

ワークフローを混乱させて予期せぬ結果をもたらす可能性のある他の大きな変更と同様に、多くの組織がほんの最初のステップで分散化に取り組むことは理にかなっています。

多くの組織は、このような変化に文化的に適したチームを特定することから始めて、低リスクのアプリケーションや製品を管理しています。次に、そのチームの特定のアプリケーションまたは製品のインシデント管理をそのチームに移行します。組織はトレーニングを行ってオンコール スケジュールを実装し、時間の経過とともに進捗を追跡して次のように質問します。

• 復旧時間は改善しましたか?
• どのような文化的障壁がありましたか?
• IT チームはどのようなツールを配置する必要がありましたか?
• コミュニケーションにどのようなプロセスが必要でしたか?
• そのチームからより優れたシステム更新情報が提供されていますか?
• インシデントの数は減少しましたか?
• この分散化を他のチームに展開した場合は、この最初のテスト実行から何を削減できますか?

これらのテスト ケースは、企業全体で「構築した者がサポートする」フレームワークを実装するかどうか、実装する場合は、チーム間でどのように効果的に展開するかを決定するための基盤を提供します。

分散化に向けたこの動きに伴って、チーム間のコラボレーションに向けた動きも必要になります。DevOps がインシデント管理に関与している場合は、DevOps が IT インシデント管理プロセス会議に出席する必要があります。IT が引き続きインシデント管理プラクティスのガイドをサポートしている場合は、他のチームによる事後分析レビューに関与する必要があります。

各チームは、インシデント管理の場に独自の強みをもたらします。IT チームはプラクティスや文書化、ガイドラインの順守に長けています。DevOps チームは変更と学習を得意としています。SecOps はセキュリティの観点を提供できます。

チーム全体のコラボレーションを促進するために、このような取り組みが良好に機能している企業では、オープンに情報を共有し、チーム全体の共感を促進し、チーム間の責任の押し付けあいを防止し、インシデント中にチャットを使用してチームのつながりを維持し、全員が発言できるインシデント レビューの優先順位付けを行っています。

ITIL ガイドラインでは、通常、インシデント管理はインシデント防止とは別のプラクティスとみなされます。どちらも ITSM のパズルの重要なピースですが、並行して発生することは多くありません。

このアプローチの問題は、インシデント管理がリアクティブな状態になることです。オンコール対応従業員は即座に解決する必要があり、解決したら次に移ります。唯一の目標は復旧、つまりシステムを復旧して稼働させることです。

しかし、復旧は全体像ではありません。そして、より多くの IT チームがこれを時間の経過とともに実現し、インシデント管理プロセスに防止策を組み込み、平均復旧時間ではなく平均解決時間などの指標を使用してパフォーマンスを判断しています。

多くの場合、このアプローチはインシデント管理と呼ばれて、その目標はプロセスの連携強化です。つまり、チームが 1 つの問題に対応して別の問題に移行するだけでなく、インシデントへの対応、インシデントからの復旧、インシデントからの学習を行い、その教訓を目下の問題と、管理している大規模な製品とサービス システムに適用します。

多くの企業の IT 組織には、インシデント管理専用のプラクティスがあります。IT 組織は、通常、別のチームのための別のプロセスとしてそのプラクティスを扱います。Atlassian ではこれをさらに一歩進めることを提唱して、IT 運用チームと開発者チームがインシデント プラクティスにインシデント管理プラクティスを組み込む混合アプローチを採用しています。これによってインシデント全体の可視性が向上して、インシデントが発生した後、確実に短時間でインシデント分析が行われます。

これは長期的には、インシデントへの迅速な対応よりもインシデントの防止の方が重要であるためです。

インシデント管理におけるチーム間のコラボレーションへの移行に固有の課題の 1 つは、プロセスとドキュメントが他のチームよりも厳密でないチームがあることです。

これは、他のチームが担当製品の管理を担っていても、IT 部門が監視と大きな価値を提供できる要素の 1 つです。なぜなら、しっかりした計画もなく午前 3 時にかすんだ目で重大なインシデントに対応したい人など誰もいないからです。

チームをインシデント管理プロセスに組み込む際に、IT 部門はその計画を決定する主な質問に答える上で役立ちます。次に例を示します。

• インシデント対応とは何ですか?
• あなたが重視する価値は何ですか?
• インシデントが発生した場合は、どのように対応しますか?
• サポートしている重要なシステムに必要な情報はどこにありますか? 複数のシステムにある場合は、その情報をまとめてオンコール エキスパートが簡単にアクセスできるようにするにはどうすればよいですか?
• プロセスとドキュメントは、チームが協同してレビューできますか?

この分散化、コラボレーション、インシデント管理と問題管理への移行には、単に責任を再配分して DevOps 事後分析に IT 担当者をスケジュールすることに留まらない作業が必要です。ここでの成功の鍵は技術にもプロセスにすらもなく、それらの変更をサポートする社内文化の醸成にあります。

多くの企業が省略しようとする部分ですが、移行を成功させるための基盤となります。では、分散型のコラボレーティブかつ将来を見越したインシデント管理をサポートする文化とは、どのようなものでしょうか?

Atlassian では、中核的な構成要素を次のように考えています。