ベロシティの高いチームのためのインシデント管理
DevOps の時代におけるインシデント管理
オープンで誰も責めないコミュニケーションの原則をインシデント管理チームに適用する
インシデントへの対応方法を見直さなければ、ソフトウェアの構築、デプロイ、運用方法を再考することはできません。
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 サービスの信頼性を向上させて顧客満足度を高め、ビジネス価値を高めるための軽量なプロセスを確立する必要があります。DevOps エンジニアは、DevOps の文化とプラクティスの導入をサポートできます。
一方、ITIL では、IT サービス管理における特定のプラクティスを改善するために設計された 26 のプロセス、手順、タスク、チェックリストが規定されています。ITIL は、サービスの品質と一貫性、さらにはシステムの耐障害性の向上に焦点を当てています。
ITIL のメリットの 1 つは、ITSM を改善したい組織が、ゼロから始めるのではなく、テンプレート化されたベスト プラクティスから始めることができる点です。また、ITIL は大企業に適しているという意見もありますが、このフレームワークは柔軟性に富んでいるため、小規模企業でもビジネスに適したプロセスを選択して価値を見出すことができます。
ITIL の欠点は、インシデント対応プロセスの変更を急いでいる場合、正式な変更管理と専門コンサルタントが関与することで、改善が遅れる場合があることが挙げられます。
すぐに開始したいチームにとって、DevOps インシデント管理アプローチは、チームが一体となってすぐにメリットを実現するのに役立ちます。
Opsgenie を使用したオンコール スケジュールの設定
このチュートリアルでは、オンコール スケジュールの設定、オーバーライド ルールの適用、オンコール通知の設定などの方法を学習します。すべて Opsgenie 内で行います。
このチュートリアルを読むインシデント コミュニケーションのベスト プラクティス
インシデント コミュニケーションとは、サービスに何らかの停止またはパフォーマンスの低下が発生していることをユーザーに警告するプロセスです。
この記事を読む