Comment Re:It's a culture issue (Score 2) 66
Excellent point, and a practice I've already seen at my current job (tracking service availability instead of server uptime--in fact, since I started, we've tracked nothing but service availability).
That said, this has led us down the path of constantly increasing availability requirements, for things as (relatively) insignificant as an internal company blog. We're currently doing work between two new data centers, and one of the goals is to provide near 100% availability of all systems. It becomes very easy to sell such an idea to the business at little incremental cost (compared to the cost of building out two DCs in the first place), but the actual work involved in making it happen can be tricky at times. Not to mention the real incremental benefit is questionable at best, at least for a lot of the applications in question (IMHO, and given that many systems aren't tied to money-making endeavors).
Sure, it's theoretically possible to have two DCs, and when you want to do patching, you flip to your secondary site, patch your primary, flip back, and patch the secondary. It's a practice I'd certainly expect to see in an environment like NASDAQ. The business likes it, and the technical minutiae are workable (most of the time), but it is a substantial amount of added complexity (and work... and time) for little added benefit, in a lot of cases.
In short, I agree completely with what you said, but it can have the side effect of increasing the "required" availability numbers to the point where it becomes little different than simply looking at uptime (depending upon the environment).
That said, this has led us down the path of constantly increasing availability requirements, for things as (relatively) insignificant as an internal company blog. We're currently doing work between two new data centers, and one of the goals is to provide near 100% availability of all systems. It becomes very easy to sell such an idea to the business at little incremental cost (compared to the cost of building out two DCs in the first place), but the actual work involved in making it happen can be tricky at times. Not to mention the real incremental benefit is questionable at best, at least for a lot of the applications in question (IMHO, and given that many systems aren't tied to money-making endeavors).
Sure, it's theoretically possible to have two DCs, and when you want to do patching, you flip to your secondary site, patch your primary, flip back, and patch the secondary. It's a practice I'd certainly expect to see in an environment like NASDAQ. The business likes it, and the technical minutiae are workable (most of the time), but it is a substantial amount of added complexity (and work... and time) for little added benefit, in a lot of cases.
In short, I agree completely with what you said, but it can have the side effect of increasing the "required" availability numbers to the point where it becomes little different than simply looking at uptime (depending upon the environment).