本記事は、モジュール「Troubleshooting Best Practices」の覚え書き、気づきの整理です。
実績のあるトラブルシューティングプロセスを使用して、組織の問題を特定し、解決するという話
salesforce に限った話ではなく、ITシステム全般に活用できる内容。
Identify the Problem
- Salesforce内で問題を記録および追跡するための公式チャネルを作成するのが第一歩。一元化する。窓口も１つが望ましい？
- 単純な送信フォームは問題の記録に役立つ。
が、ユーザーや利害関係者が進捗状況を追跡するために必要な透明性を提供しない。 - 問題に関する情報を事前に収集することは、トラブルシューティングプロセス全体で最も重要なステップの1つ。salesforce でも変わらず。
Replicate the Problem and Research Solutions
- sandbox で代理ログイン機能で事象再現を試みる。(salesforce っぽいところ
- オンプレでも代理ログインの仕組みは作る(パスワードを固定文字列)し、動作確認環境は用意する。ただ、事前にその仕組みがサービスとして提供されているかどうかの違い。salesforce はボタンポチポチで事足りる。
- 調査：類似事例があるか確認：Knowledge base(まずはここ)、Trust(ダウンタイムだったかどうか)、Trailblazer Community Groups(誰かが報告しているかも、アドバイスくれるかも)
Develop a Hypothesis and Test It
- トラブルシューティングで、ソリューションの最後の手順を文書化することだけはよろしくない。すべてのテストの各ステップを文書化する。
- 利点：備忘録、作業の重複防止、解決したときドキュメントの役割
- 解決策を行動に移し、解決した問題が再び起こらないようにすることが重要。
Implement and Share the Solution
- 実装を計画しないこと＝失敗を計画すること
- ここでいう実装(Implement)は本番環境への反映と思われる。
- 計画には以下が含まれる
- 実施期間、実施するアクション、ユーザが期待する変更点、予想されるダウンタイム、影響を受けるユーザ
- 作成した公式チャネルで計画を発表する。
- 文書化して同じプロセスを行わないようにする。つまり、時間の削減。ナレッジ化。
ところどころで salesforce 特有の言葉が出てきたが、だいたいはsalesforce に限らずすべてのITシステムにおいて活用できる内容であった。というか、これができている組織ってどんだけあるのか知りたいところｗ
クイズの選択肢に"リーダーシップ"が必ずと言っていいほど出てきたな・・・（しかし、すべて不正解の選択肢
