Close

インシデント管理改善への道はここから始まります

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

以前は、ほとんどの場合、技術インシデントへの対応を担当するチームは IT でした。チームは多くの場合は、NOCs (Network Operations Centers) に常駐してシステムを監視し、システム停止に対応していました。ベンダーがソフトウェアを構築する場合もありましたが、デプロイと運用は利用者の IT 運用チームの責任でした。現在、クラウド サービスの急増に伴い、ベンダーはソフトウェアを構築してデプロイと運用を行っています。

しかし、インシデント管理は依然としてコア ITSM プラクティスのままです。また、IT は、ガイドラインの開発、予算管理、重大なインシデントの診断、修正、文書化、防止の多大な負担を担ってきた長い歴史があります。

もちろん、技術分野におけるあらゆる場合と同様に、必ずしも過去から未来を予測できるわけではなく、現在、インシデント管理のプラクティスは変化しつつあります。DevOps、SecOps、アーキテクチャの各チームがより大きく関与するようになっています。新しい技術と相互接続された製品によって、インシデントの管理方法が変わりました。これに伴って、理念、プラクティス、チーム構造も変化しています。

では、インシデント管理はどのように変化しているのでしょうか? また、当社の役割、製品、プロセス、チームの将来にとって、その変化はどのような意味を持つのでしょうか?

分散化に向けた動き

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 では、中核的な構成要素を次のように考えています。

オープン性と情報共有

チームが他のチームが何をしているのかを知らずアクセスできないと、コミュニケーション、プロセス、製品の改善に繋がる気づきの機会が失われます。

顧客中心の思考

「顧客にとって本当に最高のものは何か?」といった質問をします。思いついた答えが、現在のプラクティスと整合しないことがあります。最終的に顧客にとってより良い製品を作るコミュニケーション、プロセス、構造的効率の向上を実現して、明確な意図をもって顧客に焦点を当てる必要があります。

定期的な健全性チェック

各チームはどのように作業していますか? 個々のチーム メンバーは物事についてどのように感じていますか? チームは何をうまくやれていますか? チームはいったい何に成功を収めているのですか? Atlassian には、チームの健全性のチェックと新しい働き方の導入に役立つチーム プレイブックがあります。

共感

DevOps が IT の責任を追及して IT 部門が DevOps の緩いアプローチを非難しているようでは、コラボレーションとは言えません。チーム間の共感と繋がりを育むことが、チーム間のコミュニケーション、イノベーション、連携に不可欠です。

権限の付与

チームには、問題を迅速に修正して可能な限り独立して決定を下す権限が与えられるべきです。そのようなチームのメンバーは、チームでの地位や経験に関係なく、質問、提案、懸念があれば発言する権限があると感じるべきです。

若手開発者がコード担当者が先輩であっても会議で手を挙げて課題を指摘できるように感じると、革新的な新しいアイデアを発見してプロセスの改善を実現し、コードにする前にバグを把握できます。