ITチームのトラブルシューティング手順
効果的なトラブルシューティングには通常5〜6段階ありますが、それらは相互に関連しており、次のステップの間に明確な境界が存在しないことが多いです。ほとんどのIT(または生活)問題に適用できる一般的な手順は以下の通りです:
ステップ1:問題を理解する。何が壊れているのか理解できなければ、何かを直すことはできません。一般的に、問題は直接影響を受けた人か、他人の代理で報告されたり特定されたりします。
多くの場合、これは第二段階から始めることが多いですが、必ずしもそうとは限りません。
ステップ2:情報収集。通常、情報収集の基礎となる3つの質問があります。
- 何が壊れたの?起きてはいけないことは何なのか、あるいは起きるべきでないことなのか?
- 実際に効果があったのでしょうか?それともIT業界で言うところの「初めての失敗」でしょうか?
- 何が変わったのか?もし以前にうまくいったことがあるなら、何が違うのか特定できますか?
可能な場合は、問題を再現して、実際に一連の出来事を一歩踏みながら、さらなる洞察を得ることができます。
ステップ3:情報の分析:情報を集めたり問題を再構築したりしたら、何が実際に問題を引き起こしているのかを分析し、解明し始めます。
答えは明白かもしれませんし、微妙かもしれませんが、目標は問題を解決するための解決策を考え出し、次のステップとして実行を始めることです。
ステップ4:ソリューションの実装またはテスト:ここはおそらくほとんどの作業が行われる場所、あるいは影響を受ける人が目にする部分の作業です。ソリューションをテストしている間、特にIT分野ではほとんど破ってはいけないルールが一つあります。それは、トラブルシューティング中は一度に一つだけ変更することです。理由は単純です。複数の項目を同時に変更して問題が解決しても、実際に何が問題を解決したのか特定できないかもしれません。
ステップ5:プロセスを文書化する:問題が解決した後、最後のステップであり、正しく行われていないか、あるいは全く行われていない可能性が最も高いのは、あなたが行ったことを記録することです。
- 問題は何だったのでしょうか?
- 症状は何だったのか、あるいはどのように症状が現れたのか?
- 誰が、どのように影響を受けたのか?
- 問題の根本原因を特定するためにどんな情報が必要でしたか?
- どうやって直しましたか?
- 問題が解決したかどうかはどうやって確認しましたか?
これらはすべて答えられるようにしたい質問です。なぜなら、問題が再発したり、同様の問題が起きてこの情報を手元に持っている場合、あなたはゲームの一歩先を行っているため、誰かがすでに集めている情報を追いかける時間を無駄にする必要がないからです。また、監査記録も存在し、これは多くの専門職や規制された業界で特に重要です。しかし、この分野は特にIT分野の多くのトラブルシューティングが失敗する分野です。結局のところ、問題は解決し、ユーザーは満足し、次の問題に移りたいと思うのは自然なことです。次のITトラブルシューターのために、足跡を残す時間を作りましょう。今日は小さな投資ですが、将来的に組織(そしてチームの安心感)に大きなメリットをもたらします。