再発インシデントから改善バックログへ
例示ユースケースであり、顧客事例ではありません。
繰り返すインシデントを推定原因ごとにまとめ、チケットのコストと比べて修正規模を見積もり、オーナーが改善バックログで修正の優先順位を決められるようにします。
課題
同じインシデントが毎月戻ってくる。失敗するインターフェース、決算期にタイムアウトするレポート、リリースのたびにずれる設定。それぞれは個別に解決され、誰もそのパターンに責任を持たず、サポート予算は同じ問題に何度も支払われている。
現在の進め方
インシデントは症状が消えた時点で個別にクローズされます。月次レポートはカテゴリごとにチケットを数えます。根本原因分析は重大インシデントに限って行われます。改善要望は新規プロジェクトの要望と競合してほとんど予定に入らず、繰り返しの作業はサポートキューに残り続けます。
シナリオを見る
簡単な概要
ワークフローの例示です。字幕付き。
文字起こし
- 同じインシデントが毎月戻ってきます。それぞれ個別に解決され、誰もそのパターンに責任を持たず、サポート予算は同じ問題に再び支払われます。
- 解決済みインシデントを可能性の高い原因ごとに分類します。各グループの修正に必要な作業を見積もり、再発によって生じるチケット数と対応工数に照らして比較します。
- オーナーが改善バックログに入れる修正を承認します。変更はリリースの確認を経て、インシデントデータが問題の再発の有無を示します。
- 測定するのは再発率と再発インシデントに費やすサポート工数です。例示ユースケースです。貴社のケースについてご相談ください。
詳細なシナリオ
例示シナリオ。 架空のサポートエンジニアが、毎月再発するインシデントを、オーナーが優先順位を付け、リリース確認を経る改善へと変えます。 1:08
文字起こし
- Samは、開く前からそのチケットに見覚えがあります。同じ症状が戻ってきて、同じ調査もまた繰り返されます。
- 一件ずつ見れば、インシデントは解決済みでした。まとめて見ると、オーナーを置くべき再発の問題がうかがえます。
- インシデントを想定される原因ごとにまとめ、パターンを検証して、修正にかかる工数と、再発が生むサポート作業を比較します。
- 修正を改善バックログに入れるか、ほかの優先事項と比べてどこに位置づけるかは、オーナーが決めます。
- 承認された変更は、リリースと回帰テストの確認を経て進みます。提案された改善は、本番環境を変更する許可ではありません。
- リリース後は、問題が再発するかどうか、どれだけのサポート工数を消費しているかを追跡します。御社のチームが次に調べるべき繰り返しの問題は何でしょうか？
- [エンドカード] 御社のチームが次に調べるべき繰り返しの問題は何ですか？ 再発インシデントについて相談する. qxorbit.ai/ja/contact
- 例示ユースケースであり、顧客事例ではありません。
提案するワークフロー
- インシデント分類体系、解決記録、影響を受けたコンポーネントを用いて、解決済みインシデントを可能性の高い根本原因ごとに分類する
- 再発している各グループについて修正を見積もる。必要な変更、影響する環境、リリースと回帰テストの工数
- 修正を再発コストと比較する。月あたりのチケット数、エンジニアの工数、オーナーが説明する業務への影響
- 順位付けした候補をアプリケーションオーナーに提示し、オーナーが改善バックログに入れるものを決める
- 承認された修正を回帰テストの確認を伴うリリースプロセスで提供し、リリース後の再発を監視する
人が判断を担う箇所
- 分類と見積もりは提案である。何をどの順番で修正するかはオーナーが決める
- 計画された改善は合意したリリースと回帰テストのプロセスに従う。緊急の変更には合意した緊急承認が必要
- 改善項目をクローズするかどうかを決める前に、合意した観察期間に照らして再発データを確認する
プラットフォームの対応付けは、この構想を評価しうる環境を示すものです。実際の実装は、設定、ライセンス、API、データ、権限によって異なります。効果は定性的に記載しており、数値による主張には文書化されたベースラインが必要です。