COVID-19 has boosted remote work (WFH – Work From Home) activity to an extent that no one could anticipate 2 years ago. Is it really time to invest in user performance monitoring for remote / WFH users? How should you do it?
- In the EU, in 2019, only 5.4% of workers usually worked from home. The share of workers who worked sometimes from home was only 9% at that time. (source)
- In 2020, nearly 40% of workers started to work remotely as a result of the pandemic (source)
- In the US, the percentage of workers working from home 5 days a week moved from 17% to 44% (source)
Is it due to last? YES
All surveys point in that same direction: according to Gartner 90% of organizations will allow employees to work remotely at least part time (source).
Based on these facts, we all understand how crucial the quality of experience of remote workers is to enable the productivity of almost every organization. This is a major shift for the digital workplace and all the delivery chain has to be upgraded / fine tuned to cope with this new situation, including IT monitoring.
How to deal with digital performance issues related to WFH?
Traditional monitoring does not solve the current issues: it has been built for IT activities mostly taking place from the organization’s private network where the behaviors and troubleshooting are not facing dynamic behaviors and unpredictable service paths.
WFH brings a lot of new issues:
- Home network performance issues
- ISP issues
- Cloud service redirections
- Security issues and the performance costs of new security protections put in place (agents and secured web gateway cloud services – you can read this article for further information about this)
WFH user performance: where can it go wrong?
Well many factors affect user performance when connecting to applications remotely. If you think of all the infrastructure layers between the user and the platform (and the different hosts which together provide the application) as a chain, here are all the places where you can negatively affect user performance:
- Endpoint Device
- Lack of resources (CPU, RAM, Disk outage)
- Agent / application overload
- Home / WiFi network of poor quality
- ISP: Last mile quality of service (between the CPE router and the backbone of that telco)
- DNS performance: response time to resolve hostnames into IP addresses (this may be provided by the ISP or by another 3rd party provider)
- Internet routing:
- Network latency between the ISP and the different hosts used by the application
- Location of the cloud services hosts: depending on your location, the hostnames will be resolved in a different way to attempt to connect users to application nodes which are the closest to them… but this may go wrong.
- Possibly the reachability and processing time of a cloud gateway or Secured Web Gateway as a service (SWGaaS like zScaler or Netskope)
- SaaS application performance itself
How can you monitor WFH user performance?
You need a solution that monitors exactly all of these performance factors, that is to say:
- Resource consumption and system outage / overload source
- Home / Wifi Network (latency, latency variation and packet loss)
- ISP quality to leading cloud services
- DNS response time
- Latency to main resources of each SaaS / application used
- Latency to cloud proxy / SWGaaS if applicable
- SaaS application performance
- Faulty transactions
What’s the best solution to monitor WFH user performance?
There are two main approaches to performance monitoring which are complementary to one another:
- Actively testing the different items: this allows you to understand at anytime whether your SWGaaS is responsive, your SaaS responds to reference transactions in a proper way, etc…
- Passive performance monitoring: this consists in monitoring actual transactions of your users to get visibility of the performance experience 24×7, whatever their location, transaction set etc… this is the preferred approach to troubleshooting cases and attending user complaints at the helpdesk.
We have compared these 2 approaches in more details in this article.
Kadiska’s view is that both should be combined to ensure the best possible coverage of WFH user performance.
