There’s a great little theatrical bit we see in movies and television: someone starts up a complex machine, the machine falters, then the device gets slapped and works perfectly. Executions of this bit have been done to great comedic effect, such as Han Solo’s punching a console on board the Millennium Falcon in The Empire Strikes Back or the Fonz’s mastery of the jukebox and other machines with a single blow in the 70’s sitcom Happy Days.
This sort of thing goes on all the time in real life, too. A big part of our human nature is the (completely wrongheaded) notion that we have absolute control over the things in our lives. But machinery, above all else, breaks. Be it hardware or software, nothing is every perfectly executed, and something will go wrong. Hitting the object in question is just a symptom of our misperception that we can force the universe to do our bidding.
Clearly, this approach is non-optimal.
A better approach, then, is to tell someone who can fix the problem about what’s going on. We call the IT guys when something isn’t working right, tell them what’s wrong, and they fix it.
In many cases, this a straightforward operation: the problem is clear and thus so is the solution. But increasingly the problem is not clear, so solutions are harder to find.
They say the devil is in the details, and that’s certainly true in the modern complexity of IT environments. An app is running slow, the user reports. So where’s the problem? The server? The network? The client machine? Or is it the app itself? With so many layers for data to navigate, it can be very difficult to pin down the actual cause.
Monitoring solutions are one way to narrow this down. If you’re running a network monitoring solution, for instance, you can pretty much rule out (or in) the network as a cause for the slow-down. The same holds for application performance monitoring; keep an eye on the application, and you can see if and where things go awry.
But there is a cautionary to be stated here: monitoring is all well and good, but interpreting the data is even more important. A blinking light signals trouble, but what does that mean?
This is why it’s also critical to frame the discussion in terms of transactions. If you can properly implement business transaction management tools, then you can track transactions as they move through your complex IT environment. Another complimentary approach is end user experience monitoring. What is the end user doing at their end? This can spot user error and even critical design flaws in the application that are holding things back.
We can’t really hit something to make it start working, as much as that would be very satisfying. Understanding is the key to problem solving, and proper monitoring is the key to understanding.