AMSインシデントのトリアージ
例示ユースケースであり、顧客事例ではありません。
受け付けたチケットを分類し、安全な診断情報を集め、類似インシデントを検索し、エンジニアが対応する前にランブックを提案します。
課題
チケットは不完全な説明で届き、誤ったキューに割り当てられ、誰もログを見る前にたらい回しになる。経験豊富なメンバーが、先月誰かが解決した問題の再診断に一日を費やしている。
現在の進め方
ユーザーがサービスデスクでチケットを起票します。一次対応のアナリストがそれを読み、スクリーンショットや詳細を求め、件名の単語をもとに割り当てます。割り当てられたエンジニアがログを集め、記憶を頼りに過去のチケットを探し、修正方法を考えます。ナレッジは一貫性なく記録されるか、まったく記録されません。
シナリオを見る
ワークフローの例示です。字幕付き。
文字起こし
- チケットは説明不足のまま届き、誤ったキューに入り、たらい回しになります。経験豊富な人が、先月誰かが解決した問題の再診断に一日を費やします。
- トリアージはチケットを分類し、チームが安全と合意した診断情報を収集し、類似インシデントを検索して、ランブックと適切なグループを提案します。
- エンジニアは情報が付加されたチケットを受け取り、修正を判断します。トリアージは準備のみを行い、本番環境には一切手を加えません。
- 測定するのはルーティング精度、解決時間、再発率です。例示ユースケースです。貴社のケースについてご相談ください。
提案するワークフロー
- アプリケーションとインシデントの分類体系に照らしてチケットを分類する
- サポートチームが自動収集しても安全と合意した診断情報を収集する
- 類似の過去インシデントとその解決策を検索する
- 該当するランブックと想定される割り当てグループを提案する
- 情報が付加されたチケットを、修正の判断と実施を行うエンジニアに引き渡す
人が判断を担う箇所
- 修正は人が承認し実施する。トリアージは準備のみを行う
- 診断情報の収集は合意した読み取り専用の範囲に限定する
- ランブックの提案はレビューと修正を経て、ルーティングが時間とともに改善する
プラットフォームの対応付けは、この構想を評価しうる環境を示すものです。実際の実装は、設定、ライセンス、API、データ、権限によって異なります。効果は定性的に記載しており、数値による主張には文書化されたベースラインが必要です。