In search of the unknown

I’ve talked at length about the importance of business process monitoring alongside of system monitoring, but in discussions I found that sometimes an overview and simple examples are not enough to convince people about the benefits of this approach. Business owners think they don’t need to know anything about the operational performance of their systems as long as they have their numbers, and engineers often don’t feel they need invest time into understanding the business they are supporting in detail, finding examples shown too “common sense.”

One question we ask our engineers during an interview at work, is to describe the process of how they would go about troubleshooting a hypothetical issue, given only the minimum information. We often hear from our clients things like, “our website is slow” and “something’s wrong with registration” with no additional information, and in order to figure out the potential issue we need to review the whole system at a glance. For large applications, with a myriad of moving and interweaving components, this is not an easy task. But if you are monitoring all of those components, in a lot of cases, the task can be simplified.

So let’s examine a real problem. A large e-commerce company called and said that they are seeing less money coming in from web transactions. They have a pretty complex system with a lot of different revenue generation points, so this observation shed very little light on the root cause of the problem. Luckily, both systems and business processes were being monitored with Circonus, so the data was available to review.

As any engineer knows — step one of troubleshooting the problem is to confirm the problem, so looking at the revenue trends seemed like a good starting point.

The graph clearly shows that, starting around April 30th, the trend looked abnormal in comparison to the previous few weeks. So it seemed like there was an actual problem, and potentially, the issue could lie in payment processor itself or somewhere in the system, preventing certain users from making a purchase. So let’s overlay the traffic trends, collected from Google Analytics, against revenue graph and see if there are any common trends.

Even though the traffic showed a clear drop at the same time as revenue, the ratio remained the same, allowing us to exclude payment processor and other application logic from the equation (for now).

Note: This is the first potential breaking point in the process. It is very tempting to look at the ratios, attribute revenue decrease to traffic decrease, and stop the investigation. 99% of the time, unfortunately, nothing “just” happens, so on we go.

Now for the next step — what would be a logical cause for a drop in overall traffic to the site? Response time is probably the first thought that should come to mind. So let’s look at what the HTTP checks collected.

Load times didn’t seem to be deviating from the norm, but the HTTP response metric doesn’t provide full visibility into the load times for a dynamic application, so let’s check the health of the database and CPU usage on the server(s), to validate that the underlying platform is not the bottleneck. There are numerous metrics to monitor database and system health that should be, and in this case, are collected, but when researching the root cause of the elusive problem, diving deep into a specific component can waste time early in the process.

Both of the metrics appear well within norm, so at first glance, it seems like the problem is not a systems issue.

Note: This is the second point of the investigation where the process can break down. A lot of technical folks will either report that there is no confirmation to the problem reported; the reported problem is just an anomaly because the system monitors don’t exhibit any issues. This is exactly why understanding of the business by the technology team is vital.

With that said, what would be the next logical process to validate? It is not uncommon for an e-commerce site to see a drop in purchases if they either stop promoting or if their marketing campaign is ineffective: traffic to the site slows down, subsequently decreasing the number of transactions. This company, in particular, sends out tens of millions of emails a day which bring in new users, and subsequently, new conversions. So let’s take a look at the email deliverability and bounce rates collected from the company’s MTAs.

Bingo! The bounce rates sky rocketed at the same time as the drop in traffic and revenue stream occurred. Upon closer investigation, it appeared that one of the major ESPs accidentally blocked the delivery domain, and the emails did not go through to the recipients. The issue was resolved (after some discussions with the ESP) and the trends returned back to the expected level.

Keep in mind, if email deliverability was not the issue — there are multiple other metrics that were on a list to be verified, both system (operational and development alike) and business. The amazing part of all of this is that I was able to view the whole system at a glance in just one graph. Granted, stacking everything on one graph is probably not the most optimal every day approach, but it is very useful in a certain cases when the direct overlay correlation is needed. For everything else — a real-time dashboard that displays all the vital points of the business at any given moment is a must-have for anyone responsible for business and/or system health.

Everyone responsible for the success of a business, regardless of the role, needs an ability to see the status of the whole business at a glance at any given point. System engineers don’t need to know all the ins and out of marketing, but they should be aware of the overall organizational goals, and should be able to spot irregularities in the business trends. Similarly, CEOs don’t need to know how systems work in the background, but should be able to correlate high email bounce rates (if it’s critical to the business) to a decrease in purchases.

The point of all of this is that everything should be monitored, and to suggest some tools and methods that can enable users in all roles — within any organization — to ensure the success of the business. Get ’em, learn ’em, use ‘em! You will thank me later.