提案中のユースケース - インシデント管理
連絡先
| PMM | PM |
|---|---|
| @supadhyaya | @abellucci |
市場の視点
インシデント管理
ダウンタイムは高くつきます。さらに、製品が利用できなかったり信頼性に欠けたりするたびに顧客の信頼が失われるため、ダウンタイムのコストは複利的に増加します。組織は 24x7 で利用可能な耐障害性のあるアプリケーションを構築するだけでなく、効率的で信頼できるインシデント対応能力を備える必要があります。
ダウンタイムは高くつくため、インシデント管理を担当するチームには大きなプレッシャーがかかります。チームがインシデント対応のための適切なツールを持っていないと、彼らの仕事は不必要にストレスフルになり、燃え尽き症候群が発生します。これが雪だるま式にさらに多くの障害を引き起こし、ビジネス上の悪い結果につながります。
インシデント管理は、DevOps ツールボックスにおける重要なツールです。適切なインシデント管理ツールは、インシデント対応者への通知、コミュニケーションと調整の合理化、問題の診断支援、修復の促進、そして組織全体の学習と改善に役立ちます。
ペルソナ
ユーザーペルソナ
バイヤーペルソナ
バイヤーは、エンジニアリング、インフラ、運用、または信頼性チームの上級マネージャーまたはディレクターです。彼らは通常、企業の構成に応じて 10〜100 人を率いています。
業界アナリストリソース
インシデント管理は、アナリストの観点ではしばしば「インシデント対応(Incident Response)」と呼ばれます。場合によっては ITSM(IT Service Management) の下に分類されます。
- Gartner
- Forrester
- 451
市場要件
アラートソースの統合
あらゆるアラートソースと統合し、IT サービスの中断や障害に関するアラートを取り込めること。アラートは HTTP 形式またはメール形式で受信できます。多くのツールは独自の機能を提供しています。
- 一般的な機能
- HTTP 経由での統合
- メール経由での統合
- 一般的な監視ツールとの独自統合
- 統合のクレデンシャル表示
- 認証トークンのリセット機能
- 価値: すべてのソースからのアラートを集約することで、何か問題が起きたときに対応チームが確認するツールが 1 つに集約され、時間を節約できます。
アラートのトリアージ
すべての受信アラートをリストに集約してトリアージを合理化します。各アラートには、ペイロードとアラートに対して取られた措置の監査証跡を表示する詳細ページがあります。アラートのステータスを変更して状態と進捗を示したり、アラートを担当者に割り当てて所有を明確化したりできます。
- 一般的な機能
- 高レベルの詳細を表示するアラートのリスト
- アラートペイロード
- メトリクスとログへのリンク
- ステータスの変更機能
- アラートの割り当て機能
- アラートに対して取られた措置を示す監査証跡
- 価値: 監視ツールから問題が発生したという通知が届きます。サービス障害や中断に関する詳細を提供し、対応者の調査開始を支援します。
インシデント対応
すべてのインシデントをリストに集約してトリアージを合理化します。また、それらは Issue リストや Issue ボードにも表示され、異なるチームの独自のワークフローに適合します。インシデントは手動で作成することも、アラートから自動的に作成することもできます。アラートからインシデントが作成されると、すべてのアラートの詳細が含まれます。インシデントは対応とコラボレーションを調整します。
- 一般的な機能
- 元アラートへのリンク
- アラートペイロード
- 説明
- タイムライン
- ディスカッション
- 割り当て機能
- 重要度の設定機能
- Slack 統合
- 価値: コラボレーションのための SSOT を提供し、ステークホルダーとのコミュニケーションを行い、調査結果を収集することで対応ワークフローを調整します。
オンコールスケジュール管理
オンコール対応のためのスケジュールを設定します。管理者はスケジュールを作成し、対応者をスケジュールに追加するための柔軟なオプションを持っています。スケジュールは、アラート発生時に誰がオンコールであるかを特定するためにエスカレーションポリシーで使用されます。対応者は、好みのページング方法でページングポリシーを設定できます。
- 一般的な機能
- ローテーション
- エスカレーションポリシー
- スケジュールのオーバーライド
- 個人のページングポリシー
- 価値: 重要なアラートとインシデントが適切な時に適切な人に届くという安心感を対応チームに提供します。非常にストレスの多い仕事であるオンコールの責任を分散・ローテーションするのに役立ちます。
インシデント後のレビュー
非難のない環境で、消火活動中に何が起こったのかをレビューします。インシデントのタイムラインを順を追って確認し、学び、改善すべき点、調査すべき事項を注釈として記録します。継続的な改善のためのアクションアイテムを作成します。
- 一般的な機能
- インシデントにリンクしたインシデント後レビューの作成
- インシデントタイムラインへの注釈付け機能
- アクションアイテムの作成
- 価値: 継続的改善とドキュメンテーションに焦点を当てた非難のない文化の構築を支援するためのインシデント後レビューを促進します。
GitLab ソリューション
GitLab がどのように市場要件を満たすか
| 市場要件 | 現在の GitLab の提供内容 | デモ |
|---|---|---|
| アラートソースの統合 | 顧客がアラートを送信できる HTTP エンドポイントを作成する機能を提供しています。AlertManager からのアラートを受信する独自の Prometheus 統合も提供しています。 | TBD |
| アラートのトリアージ | ユーザーは、列のソート機能でアラートリストをトリアージし、最も重要なアラートに絞り込むことができます。アラートをクリックすると、ペイロードの表示、ステータスの変更、担当者への割り当てができるアラート詳細ページに移動します。アラートに対して取られたすべての措置は、アラートの監査証跡にシステムノートとして表示されます。 | TBD |
| インシデント対応 | ユーザーはインシデントを手動で作成することも、プロジェクトを設定して GitLab で作成されたすべてのアラートに対して自動的にインシデントを作成することもできます。インシデントには、アラートの詳細、編集可能な説明、コメントが含まれており、消火活動中にユーザーが協力できます。ユーザーはインシデントを外部向けのステータスページに昇格させ、外部のステークホルダーとコミュニケーションを取ることができます。 | TBD |
| オンコールスケジュール管理 | オンコールスケジュール管理 MVC は 13.10 でのリリースを予定しています。MVC により、ユーザーは複数のローテーションを含む単一のスケジュールをプロジェクト内に作成できるようになります。そのプロジェクトに受信されるすべてのアラートは、スケジュール内のオンコール対応者にメールで送信されます。 | TBD |
| インシデント後のレビュー | ユーザーは Issue を作成し、それをクローズされたインシデントにリンクして、インシデント後のレビューを実行できます。アクションアイテムは追加の Issue として作成できます。 | TBD |
トップ 3 の差別化要因と主要機能
| 差別化要因 | 価値 | プルーフポイント |
|---|---|---|
| 開発プラットフォームと統合されたオンコールスケジュール管理 | 開発者が自分の書いたコードに対してオンコール対応する形に容易に移行できる | TBD |
| 修正をデプロイするのと同じプラットフォームでアラートとインシデントをトリアージ | 解決までの時間を短縮。インシデントとパッチおよびアフターアクションアイテムを容易に関連付け | TBD |
競合比較
| 競合 | 市場ポジション | 強み | 弱み |
|---|---|---|---|
| PagerDuty | スタンドアロンのインシデント管理ツール。エンタープライズ市場に深く根付いている。市場が特定のツール 1 つに依存する形から、インシデント管理を含むワークフローツールへとシフトしているため、彼らが地位を失い始めているのが見え始めている。 | 適切な波に乗って市場に参入。ツールに深く根付いた大規模な顧客基盤があり、インシデント管理プラットフォームを切り替えさせるのは困難。堅牢な機能セット。クラウドベースの HA ソリューション。 | 非常に高価とみなされている。他に何もしないスタンドアロンツール。すべてのものと統合する必要がある。カスタマーサービス/サクセスが貧弱という評判がある。 |
| Opsgenie | Atlassian 製品スイートの一部 - 2018 年に買収。PagerDuty より市場シェアは小さく、GitLab の顧客が使用しているのを聞くことは稀。「より進歩的」とみなされている。インシデント管理企業がワークフローツールの提供物となった一例。 | 直感的なインターフェースを持つ非常に柔軟なツール。強いブランド。 | TBD |
| ServiceNow | エンタープライズ市場に深く根付いた巨大なワークフローツール。過去数年にわたり、すぐに使えるインシデント管理ワークフローを徐々に開発している。従来の ITSM/ITL ワークフローを可能にする方向に傾いている。 | ユーザーがすべてをカスタマイズするオプションを提供する非常に柔軟なツール。ビジネスの他の部分でも使用されている可能性が高いため、オンコールチームに容易に拡張できる。 | 多くの設定を必要とする。インシデント管理だけのために購入する人はいない。インシデント管理に特化した経験と機能が不足している。 |
| Splunk On-call | 2018 年の VictorOps の買収によって設立。2020 年末に Splunk On-call にリブランド。Splunk Observability スイートを構成する 3 つのうちの 1 つ。市場シェアは小さい。 | VictorOps と Splunk は非常に強いブランドとフォロワーを持っている。 | Splunk は Splunk on-call から投資を引き上げ、担当チームを縮小した。ユーザーは Splunk On-call のためだけに Splunk を購入することはない。Splunk 自体が非常に高価。ツールは柔軟性に欠け、大規模なチームでの使用が困難。 |
| Xmatters | |||
| DataDog Incident Management | 2020 年に導入された DataDog の可観測性プラットフォームへの比較的新しい追加機能。 | 監視とインシデント対応がすべて 1 つの統合アプリケーション内に収められているという利点がある。DataDog は監視分野の市場リーダーであり、拡大するための既存の大規模な顧客基盤を持っている。 | 比較的新しい。オンコールスケジュール管理がないため、それを使用するためにはインシデント管理ツールも別途必要となる。DataDog 専用。 |
イネーブルメントとトレーニング
ユースケース
この表は、採用が推奨されるユースケース、製品ドキュメントへのリンク、各ユースケースに対応するサブスクリプション層、製品分析メトリクスを示しています。
| ユースケース | 説明 | ドキュメントへのリンク | 適用可能なサブスクリプション層 | メトリクス |
|---|---|---|---|---|
| SRE チーム | これは、進歩的な企業の 10〜30 人のチームです。インシデントへのオンコール対応に加え、彼らの会社が提供するクラウドネイティブサービスのインフラのアーキテクチャと保守に関与しています。彼らはアジャイルで効果的です。継続的な改善にコミットしており、定期的なプラクティスにインシデント後のレビューを組み込んでいます。彼らは組織全体で DevOps を伝道しています。可能な限りワークフローを自動化しようとしています。このタイプのチームは、最も多くの機能リクエストを送信し、私たち(GitLab)により革新的になるよう真に推進する存在となるでしょう。 | Ultimate | TBD | |
| 開発チーム | このチームは 10〜500 人の規模になります。これは、ソフトウェアの開発を担当するエンジニアのチームです。彼らは、組織が DevOps トランスフォーメーションを進める中で、最近オンコール対応するよう求められるようになりました。彼ら自身がインシデントを解決することは稀で、運用チームメンバーとともに消火活動に参加するためにページされることが多いでしょう。より進歩的な組織では、貢献するコードベースの領域に基づいてエンジニアをページする方法を見つけているでしょう。これらのチームでは、多くの単一障害点(つまり、多くのドメイン知識を持つシニアチームメンバー)を見つけることが一般的です。 | Premium、Ultimate | TBD | |
| サポートチーム | このチームは通常 5〜20 人で、はるかに大きなサポート部門に属しています。サポートチームは顧客から報告された障害に対して対応的であり、消火活動中に企業と顧客の間の連絡役となります。彼らはステークホルダーとのコミュニケーションを担当します。これらのチームは伝統的な企業でも進歩的な企業でも見られます。サポートチームは「最低限十分」なソリューションで満足することになります。 | Premium、Ultimate | TBD |
ディスカバリー質問
質問 - 現在、インシデント管理にはどのようなツールを使用していますか?
回答: 「自社製です。独自のソリューションを構築・保守しています。」
回答とフォローアップ質問: すごい!作成と保守に多くの作業が必要そうですね。あなたのシステムについて教えてください。
注意して聞くべきこと: 保守に時間がかかり信頼性に欠ける、本物のツールを購入する余裕がなかった。
-または-
回答: 「PagerDuty/Opsgenie/ServiceNow を使用しています。」
回答とフォローアップ質問: そのツールを使用した経験について教えてください。
注意して聞くべきこと: 高価である、無料または最安層を使用している、カスタマーサポートが貧弱、機能 X が欠けている。
リソース
方向性
将来のビジョンと計画については、インシデント管理カテゴリの方向性ページをご覧ください。
