{"id":3012,"date":"2011-04-12T08:15:51","date_gmt":"2011-04-11T22:15:51","guid":{"rendered":"http:\/\/nsrd.info\/blog\/?p=3012"},"modified":"2018-12-11T18:12:04","modified_gmt":"2018-12-11T08:12:04","slug":"technology-is-rarely-the-issue","status":"publish","type":"post","link":"https:\/\/nsrd.info\/blog\/2011\/04\/12\/technology-is-rarely-the-issue\/","title":{"rendered":"Technology is rarely the issue"},"content":{"rendered":"

One of the stories I sometimes hear from companies is that some technology X doesn’t work in their environment because X sucks, or X is broken, or X … well, you get the picture.<\/p>\n

Years ago, when I first got into backup, the the main reasons I had to do recovery were due to system or hardware failures. Hard drive reliability was IMHO much lower, operating systems were frequently less stable, etc. Reliability was about getting to 99% availability, let alone 99.9% or anything grandiose like that.<\/p>\n

These days, hardware\/OS\/app failure is, I’d suggest, one of the least likely reasons for a recovery being conducted in most organisations. Instead, it’s mainly related to soft issues \u2013 user error, audits, compliance checking, etc.<\/p>\n

There’s a point here, and I’m almost ready to make it.<\/p>\n

Back when I first started with backup, I’d have agreed that technology could be firmly blamed for a lot of errors. These days? Rarely \u2013 even when I blame it.<\/p>\n

I periodically go on a rant about just how painful Linux is sometimes, but at the core I also admit that it’s a lack of training and time on my part \u2013 I’ve not made learning the ins and outs of Linux firewalls a field of study in the past, so now that I’m having to construct them by hand for a personal project it’s about as fun as tasering myself in the genitals. Technology is partly<\/em> the problem \u2013 as is always the case with Linux, it’s designed for programmers and developers to manipulate, not for end users, or people like me who have concentrated on other things and just want the damn thing to work<\/em>.<\/p>\n

Ahem, where was I?<\/p>\n

The simple fact is that we often blame technology because it’s easy. It’s like kids picking on the “easy target” at school with bullying; we bully technology and blame it for all our woes and issues because well, it doesn’t really fight back. (Hopefully we’ll get out of this habit before the singularity…)<\/p>\n

As techos though, let’s be honest. The technology is rarely the issue. Or to be more accurate, if there’s an issue, technology is the tip of the iceberg \u2013 the visible tip. And using the iceberg analogy, you know I mean that technology is rarely going to be the majority of the issue.<\/p>\n

The ‘issue’ iceberg in IT looks like this:<\/p>\n

\"The<\/a><\/p>\n

It’s probably best here that I stop and differentiate between issues and problems. A problem to me, is an isolated or an atomic failure \u2013 like, a faulty tape drive, or a failed hard drive. They’re clearly technology related, but they’re not really issues<\/em>. An issue is a deeper, systemic and compound failure. E.g., something like “on any one day, 30% of my backups fail”, or “Performance across all systems is generally 50% worse at end of month”, etc.<\/p>\n

When technology gets blamed in those instances, I’m reminded of someone who say, never has their car serviced, then when it eventually breaks down complains that the car was a lemon. Was it that the car failed the person, or more accurately that the person failed the car?<\/p>\n

As I said, it’s easy to blame the thing that can’t defend itself.<\/p>\n

In environments with ongoing, long-term issues, there reaches a point where you have to sit back and ponder \u2013 is the technology causing the issue, or is the environment causing the technology to have an issue?<\/p>\n

The inevitable and hard truth is that in some cases, it’s the latter, not the former.<\/p>\n

Let’s consider a basic scenario – the “on any given day 30% of our backups fail” scenario. So, does that mean that on any given day 30% of servers crash and reboot during the backup? Or does the backup software agent crash on 30% of servers when a backup is attempted? Maybe, in the most exceptional of circumstances, this may be the case.<\/p>\n

In reality though? In reality we have to start looking at the rest of that iceberg:<\/p>\n

\"Rest<\/a><\/p>\n

High systemic failure rates, if attributed to the deployed technology, should result in a law suit. How often do we see that happening?<\/p>\n

>queue the cicadas<<\/p>\n

That’s right.<\/p>\n

When there are systemic failure rates, a business must, eventually, turn to face the truth that they have to review their:<\/p>\n