あなたは解決不可能なチケットを受け取ったことがありますか？Stack Overflowを隅から隅までじっくり読み、時には机に顔を打ち付けながらGoogleで何時間も過ごす。 4時間が過ぎたあたりから問題を解決することはプライドの問題になってきます。生産性は最低！ こんな時こそ、あなたの正気を保つために効果的なインシデント管理プロセスが必要です。

誤解しないでください。他の誰も巻き込まずに解決したいというお気持ちは分かります。うぬぼれだったり羞恥心だったり、はたまた純粋に誰にも迷惑をかけたくなかったり、私もいつもそんな感じですから。 私の場合は問題解決偏愛症のようなものですが、こと自分のプロジェクトの健全さとなると、規定のプロセスに従った方が皆ハッピーになれるようです。

優先順位をつける

いくつかの問題は本物であり、あるものはそうではありません。 すべての問題がミッションクリティカルなわけではないので、チケットがあなたに回ってきたとき、最初のステップはそれがスタックのどこにあるかを決定することです。 あなたとチームメンバーが管理している他のバグやもろもろの要素の中にその場所を見つける必要があります。 詳細なインパクトレポートを作成し、関連するプロジェクトマネージャーたちに相談して決定を導きます。

再現

再現可能なバグは修正可能なバグです。 優先度の高い問題がキューの一番上に達すると、次のステップはそれを再現するステップをコンパイルすることです。 ユーザーが誤ってクラッシュを引き起こしていますか？ たぶんそれはメモリまたはストレージの問題です。 重要なことは、あなたがやろうとしているのは、どうすれば問題を再現できるのかを理解することで、解決法ではないということです。 いったんそれを再現することができれば（または容易に再現できないことを知ると）、修正することができます。

エスカレーション

問題を再現できるようになると、次のステップは適切な専門家を特定することです（ヒント：それはあなたかもしれません）。 問題の性質に応じて、誰の肩を叩くのかを知るのは難しいかもしれませんが、実際にその特定の機能について最後に作業した人に尋ねるのがよいでしょう。 誰に問題をエスカレーションするかにかかわらず、これまでに学習したすべての詳細なレポートを必ず含めてください。 感謝してもらえますよ。

調査

さて、これで問題は少しは見えてきて、あなたの作業リストに入ることになりました。 次のステップは、問題を調査することです。 これは、問題を再現し、ログを収集し、その分野の専門家に質問し、起こり得る問題を特定し、ソリューションをテストします。 何が起こっているのか、なぜ起こっているのかを正確に知るまで繰り返します。

回復

ここまできたら、問題の内容、再現方法、原因を正確に把握していることでしょう。 根本的な原因を特定し、テスト済みで実用的な修正を行っています。 次のステップは修正プログラムを導入することであることは明らかですが、ここで停止することはできません。 問題が解決してすべてが安定したら、問題が修正されたことをすべての関係者に通知する必要があります。 また、ソリューションの詳細を関連する専門家に伝え、必要に応じて、何が起こったのか、どのように解決されたのかを誰もが理解できるように解析しておくことも重要です。

効果的なインシデント管理は、確立されたプロセスと適切なコミュニケーション次第です。 実際の手順はプロジェクトごとに変わる可能性がありますが、問題を最も効果的に軽減するチームは大きなコミュニケーションをとり、必要となる前に計画を立てるものなのです。