Un-Excuse-ing Upgrades

When we talk about upgrades here at SolarWinds, we spend a lot of time discussing the beneficial features, performance, and capabilities you can gain. That’s not by accident. The honest-to-goodness truth is, the most compelling reason to upgrade ANYTHING—from our phone to our game console to our monitoring software—is because we’ll be able to do something both new and useful to us. Therefore, when a particular upgrade doesn’t contain anything of apparent use, we often tend to skip it.

This logic is flawed in two fatal ways:

First, the more versions we skip, the harder it is to upgrade when we DO want an awesome new feature. This sets up a negative-feedback loop where the level of effort appears greater than the perceived benefit, so we skip yet another version, making the subsequent updates even more time-consuming and thus harder to justify.

Second, evaluating upgrades by “what’s in it for me” ignores an incredibly important reason software vendors produce updates: bug fixes and security updates.

My colleague, Mike Driskell () , compares it to getting a service notice on our car. We might not be great about oil changes, but we realize the value of taking the car to the dealer so the airbag doesn’t spontaneously explode in our face as we drive down the freeway. Driskell points out how—with hundreds of thousands of lines of code—there are a lot of little airbags in the software we use. Any time a vendor puts out a patch, update, or upgrade, it’s not only to make OUR experience better, it’s to make it safer, too.

I also want to address the myth of how upgrades are “expensive” in terms of time and effort. An old saying says, “If you think education is expensive, try ignorance.” In the past, I’ve adapted it to point out how, if you think implementing a monitoring solution is expensive, just wait until you see how much an un-monitored outage costs you. Taking it one step further, if you think it’s a lot of work to upgrade, wait until you try to restore a system which crashed due to un-patched issues.

The last point I’ll make here uses history as its backdrop. Most of us have been in IT long enough that phrases like “Blaster virus,” “Heartbleed worm,” and “SQL Slammer” all bring chills—if not painful memories of long hours worked in a haze of panic and stress. In those cases, as in so many others throughout the years, patched and up-to-date systems were far less susceptible to attack. Even in cases where additional updates were needed, it was far easier because the distance between the version our system was at—and the update(s) we needed to apply—was so small.

So, take a look at both your systems and your schedule and see if there’s a way to make patches, updates, and upgrades part of your normal routine.

  • Great article, and not just a 'nice opinion', but really important advice.

  • At the start of every quarter I block out time for likely updates. Microsoft infrastructure is monthly, I tend to plan for quarterly updates for Orion, and some stuff I might go slightly longer or shorter depending on the cadence of developer releases. I consider an operational project. Can it get bumped? Yes, any project can depending on the needs of the business. But I put it down in the plan. I might also drop what I am doing and run something immediately. The point is that we all get busy, and if we don't give the care and maintenance of our systems some priority, its bound to get lost in the noise. If I don't need that planned time to run an update, there is always something waiting to get done.