This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
6 Best Practices to Remember for WFH Troubleshooting
With imperfect visibility into network connectivity and application access, diagnosing and troubleshooting problems reported by work-from-home (WFH) employees can present a real challenge for IT. This can lead to false assumptions, and those can make the situation worse.
To get control of the WFH environment, follow these six steps when diagnosing and resolving a problem.
1. Take care to identify the problem
If a WFH user reports a problem, the description might be as vague as “it doesn’t work right.” Spend time interviewing the user, and add context to the problem description from your dialogue. Review the problem symptoms and see if they’ve been reported previously. These records can be good to have when trying to diagnose “ghost” issues — i.e., a user reports the problem then informs you it has disappeared.
2. Determine your approach
If you can, use the OSI model as a reference to pinpoint where the problem exists — computer, physical connection, LAN or WAN, operating system, application control, or application. You have two choices when you start the problem analysis: a top-down approach that starts with the application or a bottom-up approach that starts at the physical layer. Ensure that you document what actions you take so that others don’t duplicate your efforts. Document and justify your assumptions. Add any information collected to your knowledge base for future use. The problem may indicate a complex architectural design issue, like a bandwidth bottleneck, that will show up with all the video conferences now taking place.
Assume WFH configurations and Wi-Fi traffic is not consistent. Advise the WFH user to have a hard-wired, not wireless, connection to the router. Other questions to ask include: How many applications are you running simultaneously? Are any family members also using the Wi-Fi? How old is the router? In other words, investigate the WFH environment before assuming a problem is an IT issue.
3. Assess how big the problem is
Is this a one-off problem, or is it pervasive, occurring with multiple users? Understanding the scope can help reduce the problem footprint and the mean time to repair.
- Are all users, apps, and locations affected?
- Is it one-time or recurring issue?
- If it is an application issue, what is the delivery path?
- Is the problem due to an ISP or other provider problem?
- Is the WFH user watching sporting events or breaking news that has video streaming or activity?
4. Plan your investigation
Document your assumptions of what could be wrong. Create a priority short list to eliminate the most likely causes.
- Top-down approach: Review the application monitoring, network, server, and browser timings from your locations. Latency timings can be broken down in steps to locate the longest latency. Providing latency information can help a cloud app provider identify a problem.
- Bottom-up approach: Start by identifying the application delivery path on the networks from the user to the app. Look at the LAN, WAN, and vendor components of the delivery path to determine if the issue is in your IT infrastructure, the WAN/Internet, cloud provider, or the WFH location.
5. Document problem resolution
Note differences in the process and the time it takes to perform each step as compared to your expectations. The resolution time to fix them is important so the next time the problem resolution is faster using fewer resources.
Recurring issues may signal a bigger problem. Unhelpful WFH users may be another problem because they cannot monitor applications delivered over the WAN. Continuous centralized monitoring helps identify ghost issues.
6. Follow up and look for ways to mitigate future occurrences
Investigate ways to mitigate an issue in the future. If your monitoring tools don’t provide key information, investigate complementary or replacement solutions that can give you greater visibility. A problem post-mortem and documenting your findings expands your knowledge base and saves important infrastructure information.
It is very likely that the business scrambled to implement WFH users. There should be policies and education that relate to WFH users' behavior, use of their own resources, competing resource impact, and what an effective WFH hardware and software configuration should like. Without guidance from IT, WFH users will create their own inconsistent solutions that will be hard to troubleshoot.