"High availability" gets used loosely enough in vendor material that it's genuinely lost some of its meaning everything gets described as highly available, the same way everything gets described as enterprise-grade. The actual concept is precise and worth reclaiming: high availability means designing infrastructure so that the failure of any single component doesn't take down the service that component supports. Not "usually doesn't." Doesn't by design, verified, not assumed.
My real position here: most infrastructure that's described internally as "highly available" hasn't actually been designed to a specific availability target. It's been assembled from components that each individually sound redundant, without anyone calculating what the combined system's actual availability comes out to, or verifying that the redundancy genuinely functions the way everyone assumes it does.
Start With an Actual Availability Target, Not a Vague Aspiration
"We want high availability" isn't a design requirement it's a feeling. A genuine design requirement looks like "this system needs 99.95% availability," which translates to a specific, calculable amount of acceptable downtime per year roughly 4.4 hours at that particular target, for context. Different systems genuinely warrant different targets. A customer-facing transaction system generating revenue every minute of uptime deserves a meaningfully higher target than an internal reporting tool that can tolerate real, occasional downtime without materially hurting the business.
