Finding value through problem localisation

As the tech ecosystem continues to swell and digital solutions become a beacon of productivity and profitability for companies across industries, development speed and agility are becoming differentiators —  even for small companies on the outskirts of the ever-expanding tech fog. 

Here's how problem localisation can minimise your change failure rate, boost your deployment frequency, and create a stable and usable environment across your tech stack.

What is "Problem Localisation?"

Tech infrastructure is sprawling. Many of us have a smorgasbord of legacy apps, cloud apps, and hybrid apps. And we're often running those apps across WAN deployments, on virtual desktops, and directly on a mix of devices. So, when something fails, you don't just need to figure out a fix; you need to figure out where the failure even happened. Was it the app itself? Was it the virtual desktop? Is it the network? Or was it an integrated legacy system?

Problem localisation is how you localise the true source of a problem in your tech ecosystem. This problem is important for nearly every company. If you're a SaaS company deploying products, you need to understand where failures originated quickly. Your reputation is on the line. For companies, downtime quickly becomes a cash drain. Your automated synthetic monitoring tool can quickly remediate issues, but it can also help you find them.

Here's how:

Finding Problems Using Checkpoints, Geographic Monitoring, and Access Methods

For the purposes of this post, we're going to show you how to solve your "problem localisation" problem using 2 Steps in three steps. But you could also leverage these tips with other solutions.

Step 1: Set Up Checkpoints

The first step we recommend is to cut your synthetic journey into logical chunks. We call these checkpoints. As an example, a basic application may have checkpoints such as: "Application Startup," "Login," "2FA," and "Run Report." Each of these checkpoints represents a specific app step, and together they should form the basic flow of the app. You don't have to make a checkpoint for every app pathway at once. Once you checkpoint the core pathways, you can solve the less-used pathways ad-hoc until you get used to the process.

Next, you want to run a 2 Steps instance on each of these checkpoints. Since 2 Steps is no-code, you can quickly deploy it across each. But you may need to set aside time and budget if you're working with a Selenium-based solution. It's also important to note that 2 Steps works in every environment (seriously!). So, you don't have to worry about running it across multiple environments if your app has a non-standard flow. If you use Selenium-based solutions, you're likely locked into your core app.

When a problem happens, you can check each checkpoint (2 Steps provides a video replay) to figure out exactly where the hiccup occurred. You can then route that problem to the applicable team responsible for that part of the journey. For example, a glitch in "Login" may require the Active Directory team to take action.

Step 2: Use Geographic Placements

After you create a robust pipeline of synthetic monitoring instances across each checkpoint, you should deploy copies of that instance as close to your front end as possible. Next, you need to place instances at regional sites. This should give you an idea of whether network issues are causing specific app problems. If your front end and regional sites fail, it's almost certainly an application issue. But if your front end runs smoothly and a regional site fails, it's probably a network issue.

Remember, today's tech surface is vast. Apps can encounter issues with third-party components, APIs, networks, firewalls, cloud sites, databases, and virtual desktops. Ruling out network issues allows you to hyper-focus on things such as core app coding, APIs, and databases.

Step 3: Use Different Access Points

Companies are rapidly deploying virtual desktop technology (e.g., Citrix, VMWare Horizon, Azure VD, other DaaS, etc.) to tackle remote work issues. But this creates another failure point. And it can make failures murky if you don't run unique synthetic monitoring journeys across each access point. For example, you run a 2 Steps instance on your base app, and you can run another on your app in a VD environment. If both fail, it's the app. If the VD environment app fails but the core app runs smoothly, it's probably the VD environment. Once you understand this, you can shoot a ticket to the right people.

Important: Remember to create an additional checkpoint in the VD environment for logging in and out of the VD.

2 Steps + Problem Localisation: A Recipe for Faster Launches, Fixes, and Results

As we all continue to pile new fail points into our tech environment, creating a robust, automated monitoring ecosystem is a necessity. It's not enough to know that your app is failing. You need to know why. And to know why, you need to understand which ecosystem (e.g., APIs, firewalls, core code, VDs, etc.) is having issues. Problem localisation is the key to smart problem-solving and a better customer experience.

To learn more about 2 Steps and how we can help you solve your application performance monitoring issues, contact us.