What to do when an issue is reported
The success of pinning down an issue is in the mindset of the investigator. An investigator should be prepared to start with the right essence of data and use the right blend of tools and control the entire troubleshooting process. A professional approach at the start gives confidence to users and stakeholders expecting the resolution. This avoids beating around the bush in stakeholder meetings and also avoids the situation where stakeholders start suggesting troubleshooting tips and tricks.
Gather Information
Use the following to gather information:
- Gather information about the application causing the issue.
- Gather information about the current configuration of the application.
- Gather information about all dependencies with the application.
- Gather information about the teams directly related with the application.
- What changed recently?
- Understand the issue.
- How the issue differs from normal behavior?
- When did the issue first occur?
- What are the monitoring tools used in the environment in scope?
- What logs are best suited to help the investigation? Correlate with the monitoring tools identified above.
- Do not start with ULS logs. Understand the problem area and start with the right genre of logs.
Most Important
Try to reduce the scope with numerous attributes.
- Environments: Cloud, On-Premise, Acceptance and so on
- Users: Global, limited, partner, external, application specific permission level and so on
- Type of Clients: Browser version, office application version, web services, webdav, custom tool, sandbox solution, Infopath, SharePoint Designer and so on
- Other attributes: operating system used, SharePoint CU, SharePoint security update and so on
Note: Keep an exhaustive list of attributes in various categories.
Reproduce the issue
Use the following to reproduce the issue:
- Reproduce the issue in another representative environment.
- This is the key to get deep into the investigation. Imagine the trouble we get into when an investigator must wait for log files every time the issue is reproduced in the environment in scope.
- But there are situations where reproducing the issue in another environment takes a back seat, and focusing on the environment in scope to find more information leads to the root cause.
- Decision to reproduce the issue in another environment or use the environment in scope is based on the issue identified and is not in scope of this document.
Comments
Join the conversation! Your thoughts help the community grow.