The CIA Triad & Availability
The leg everyone neglects until production goes down at 3am.
Overview
Availability without measurement is a wish. Availability with measurement but without targets is data collection. Availability with targets, measurement, and accountability is engineering. Answer the five questions below with the precision of someone who has had to defend an availability posture to a customer.
Read before you answer
The CIA triad — Confidentiality, Integrity, Availability — is the foundational model of information security, but availability is consistently the least systematically managed of the three. Confidentiality has encryption and access controls; integrity has checksums, signatures, and audit logs; availability has... an on-call rotation and a Slack channel. This asymmetry is a governance failure, not a technical one. Availability is measurable, plannable, and improvable — but only if you treat it as an engineering discipline with defined targets, measurement methodology, and accountability rather than as an operational hope.
The industry standard vocabulary for availability targets is the SLA/SLO/SLI hierarchy. An SLI (Service Level Indicator) is the actual metric being measured — request success rate, latency at the 99th percentile, error rate, uptime percentage. An SLO (Service Level Objective) is the internal target for that indicator — "99.9% of requests complete successfully over a rolling 30-day window." An SLA (Service Level Agreement) is the contractual commitment to customers, typically set conservatively below the SLO to provide an operational buffer. A 99.9% SLO means 43.8 minutes of acceptable downtime per month; a 99.99% SLO means 4.38 minutes. These numbers have real cost implications: moving from three nines to four nines typically requires architectural changes (redundancy, failover, health checks, automated recovery) that a single-server deployment cannot provide regardless of how well it is tuned.
The cost of downtime is almost always underestimated because direct revenue loss is only one component. Full cost accounting includes: direct revenue loss during the outage, support cost handling incoming tickets, engineer time for incident response and post-mortem, cost of remediation and architectural changes following the incident, damage to customer trust and churn probability, and regulatory or SLA penalty exposure. For a SaaS product, even a single hour of unplanned downtime can cost multiples of what a redundant architecture would have cost to build. The practical governance implication is that availability investment decisions should be made against a realistic cost-of-downtime model — not against an abstract preference for simplicity.