Close

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

Incident management in the age of DevOps

Applying principles of open, blameless communication to incident management teams

インシデントへの対応方法を見直さなければ、ソフトウェアの構築、デプロイ、運用方法を再考することはできません。

John Allspaw 氏と Paul Hammond 氏は、2009 年に行われた重要な講演「10+ Deploys Per Day: Dev and Ops Cooperation at Flickr」で、開発者と IT 運用チームが協力することで、リリースの頻度を上げる世界のビジョンを描いています。その後の 10 年間で、このビジョンは DevOps ムーブメントとして具体化されました。

DevOps の本質は、インシデントに対応する新しい方法に依存しています。Allspaw 氏と Hammond 氏の講演でインシデント管理がこれほど注目されたのは驚くべきことではありません。

「重要なことは、失敗は必ず起こるということです」と Hammond 氏は語っています。「失敗が起こることは問題ではなく、いつ起こるのか、が問題なのです」

ITIL のようなフレームワークとは異なり、DevOps チームのベスト プラクティスに関する「公式な」文書はありません。しかし、DevOps の中核をなすのは、組織的なサイロを解体して透明性を高めて、開発者と IT 運用チーム間のオープンなコミュニケーションを促進することで組織にビジネス上の価値をもたらすことであるという点については、一般的に認められています。

透明性、可視性、迅速な学習という同じ文化が、インシデント管理にも及んでいます。

どうしてでしょうか? インシデント管理における優先すべき最も重要なステップは、何がうまくいかなかったのかを理解すること、適切な人材に問題に取り組んでもらうこと、誰も責めない文化を育てることです。

DevOps インシデント管理では、開発者と IT 運用チームとの間でオープンで誰も責めないコミュニケーション文化が求められています。また、IT サービスの信頼性を向上させ、顧客満足度を高め、ビジネス価値を高めるための軽量なプロセスを確立することが必要です。

一方、ITIL では、IT サービス管理における特定のプラクティスを改善するために設計された 26 のプロセス、手順、タスク、チェックリストが規定されています。ITIL は、サービスの品質と一貫性、さらにはシステムの耐障害性の向上に焦点を当てています。

ITIL のメリットの 1 つは、ITSM を改善したい組織が、ゼロから始めるのではなく、テンプレート化されたベスト プラクティスから始めることができる点です。また、ITIL は大企業に適しているという意見もありますが、このフレームワークは柔軟性に富んでいるため、小規模企業でもビジネスに適したプロセスを選択して価値を見出すことができます。

ITIL の欠点は、インシデント対応プロセスの変更を急いでいる場合、正式な変更管理と専門コンサルタントが関与することで、改善が遅れる場合があることが挙げられます。

すぐに開始したいチームにとって、DevOps インシデント管理アプローチは、チームが一体となってすぐにメリットを実現するのに役立ちます。

DevOps インシデント管理プロセス

インシデント管理に対する DevOps のアプローチは、効果的なインシデント管理のための従来の手順と劇的に違うわけではありません。DevOps インシデント管理では、最初からオンコールを含む開発者チームを関与させることと役職ではなく専門知識に基づいて作業を割り当てることを、明示的に重視しています。

1. 検知
DevOps インシデント対応チームは、インシデントが決して起こらないことを期待するのではなく (なぜなら、インシデントは間違いなく発生するので)、準備することに高い価値を置いています。また、システムの脆弱性を特定することにより、潜在的なインシデントへの対応を計画するために協力して取り組んでいます。監視ツール、アラート システム、手順書を用意し、インシデントが発生したときに誰に連絡すればいいのか、次に何をすればいいのかを各メンバーが把握できるようにしています。

2. 対応
DevOps インシデント管理チームは、1 人のオンコール エンジニアがシフト中のすべてのインシデントに対応するのではなく、複数のチーム メンバーを指定してエスカレーションに対応するようにします。指定されたオンコール エンジニアがインシデントを個別に解決できない場合は、ガイドとなる手順書が用意されています。オンコール エンジニアは、問題の影響と深刻度を評価するための適切な担当者を呼び、適切な対応者にエスカレーションできます。

3. 解決
インシデントに対応する際、DevOps のインシデント管理チームは、多くの場合迅速に解決できます。これは、総じて、彼らがアプリケーションやシステム コードに精通しているためです。なぜなら、コードを書いたのは彼らだからです。また、高度な準備と優れたコミュニケーション システムの恩恵を受けて、彼らは協力してインシデントを解決することができ、初めてコードを見るサードパーティの対応チームよりも迅速に解決することができます。

4. 分析
DevOps インシデント管理チームは、誰も責めない事後分析プロセスによってインシデントをクローズします。また、システムの耐障害性を継続的に改善し、将来、インシデントが発生した場合に迅速かつ効率的に解決することを目的として、情報、指標、学習した教訓を共有します。

5. 準備状況
インシデントが解決し、すべての修復手順が完了し、システムが復元すると、DevOps インシデント管理チームは一歩下がって、次のインシデントへの準備状況を評価します。彼らは事後分析プロセスで学んだことを取り入れ、手順書を更新し、監視ツールとアラート システムに必要な調整を行います。また、DevOps の継続的な改善は、技術だけではなく、人やチームにも適用されます。インシデント後、チーム メンバーは次のインシデントにより万全に備えることができます。

効果的な DevOps IM チームのベスト プラクティス

インシデント対応に DevOps アプローチを採用すると、開発チームと IT 運用チーム間のコミュニケーションの向上、インシデント対応と修復の迅速化、より回復力のあるシステムを実現できます。

プロセスとワークフローの自動化
サービス デスク、監視、チケット発行、CMDB/アセット管理、チャット ツールを統合し、IT インシデント アラートとワークフローを合理化して、解決に向けて必要な情報を適切な担当者に通知できるようにします。事前定義されたワークフローを使用して手順書を準備することで、インシデント発生時にすぐに対応できるようになります。

チーム間のコミュニケーション
リアルタイム チャット ツールを使用して、チームのメンバーが組織全体でコミュニケーションできるようにします。インシデントの記録を作成するツールを使用すると、いつでも、誰でも、何が起こったのか、何が起きているのかを素早く把握できます。

誰も責めないアプローチを採用する
インシデントを解決した後、チームで集まり、誰も責めない事後分析セッションを開催して何が起きたかを検証します。責任のなすり合いは避け、全員の仕事に役立つ情報を共有し、より信頼性の高いシステムに貢献することに集中します。

ビジネスの核心を特定し、そこに焦点を当てる
DevOps インシデント対応は、コミュニケーションを向上させる手段であるだけではなく、開発者と運用担当者が連携して真のビジネス価値を実現するための手段です。MTTD (平均検出時間)、MTTR (平均修復時間)、MTBF (平均故障間隔) などの指標を追跡し、チームの改善率を把握します。

オンコール スケジューリングを活用して、開発者とシステム管理者を SRE として配置する
DevOps チームでは、開発者とシステム管理者の境界が曖昧になり始めており、インシデントに対応する担当者が SRE (サイト信頼性エンジニア) になることがよくあります。とは言え、個人的なレベルでは、専門的な知識がアプリケーション コードまたはインフラストラクチャ コードのいずれかに限られる場合が考えられます。インシデントに対応するための専門知識を適切に組み合わせられるようにオンコール スケジュールを設定しましょう