roduction Readiness Checklists and Reliability Fundamentals for FDE Solutions

A solution that works in a demo is not the same as a solution that survives real users, real load, and real failures. Demo code gets a reset button; production doesn't. This tutorial walks through what it actually means to be "production-ready," then introduces the concepts that let you measure reliability — SLIs, SLOs, and error budgets — instead of just hoping things hold up.

Table of Contents

• Production Readiness
  • The Readiness Checklist
  • Readiness as a Scorecard
• Reliability Fundamentals
  • SLI, SLO, and SLA
  • Error Budgets
  • Computing an SLO

Production Readiness

Production readiness is the state a solution has to reach before you'd be comfortable trusting it with real users and real data: stable, observable, secure, recoverable, and supportable.

Why bother with a formal review? Because the first time most people learn a system "wasn't ready" is during an outage. A demo handles one user and gets wiped when it breaks. Production has no reset button. If you run through a readiness review before launch, those surprises surface as checklist items you can work through calmly instead of as a fire at 2 a.m.

The Readiness Checklist

Whether it's an internal tool or a SaaS feature, the same five areas keep coming back:

A fast way to get a feel for where you stand: go down the checklist and mark each item true, false, or "don't know." Treat every "don't know" as a false. If you can't observe a thing, you can't claim it works.

Readiness as a Scorecard

readiness = {
    "reliability": {"load_testing_done": False, "graceful_shutdown": True},
    "observability": {"logging": True, "metrics": False, "health_check": True},
    "security": {"secrets_in_vault": True, "access_controlled": False},
    "recoverability": {"backups_running": True, "restore_tested": False},
    "supportability": {"runbook": True, "owner_assigned": True},
}

def score(area):
    items = readiness[area]
    passed = sum(items.values())
    return f"{area}: {passed}/{len(items)}"

for area in readiness:
    print(score(area))

This walks each area and prints how many checks pass. The code is deliberately dumb — there's no magic in it, and there shouldn't be. Its value is that you now have a written, shareable list anyone can read to see exactly what's blocking launch.

Reliability Fundamentals

Reliability is the practice of keeping a system doing its job — answering requests, processing jobs, returning correct results — even as users, load, and time conspire against it. It's not a single feature you bolt on; it's a set of measurable goals plus the design choices that let you reach them.

The reason the vocabulary matters: "make it reliable" is a wish, but "meet a 99.9% availability target this quarter" is a spec. The fundamentals give you the words and the math to turn one into the other.

SLI, SLO, and SLA

These three get mixed up all the time, but they're deceptively simple:

• SLI (Service Level Indicator) — the number you actually measure, like "99.4% of requests succeed."
• SLO (Service Level Objective) — the target you set, like "at least 99.9% of requests succeed."
• SLA (Service Level Agreement) — the contract you make with a customer, usually with a penalty for missing it.

SLI:    what we measure     ->  % of requests that return success
SLO:    what we aim for     ->  >= 99.9% per month
SLA:    what we promise     ->  >= 99.9% or the customer gets a credit

One habit pays off constantly: set your SLO stricter than your SLA. Aim for 99.95% internally and you've got a buffer before you breach a 99.9% contract. Aim at the SLA exactly and one bad day puts you in penalty territory.

Error Budgets

An error budget is the unreliability your SLO allows. If your SLO is 99.9%, you get 0.1% of a month — about 43 minutes — to be down.

This sounds restrictive, but it's actually liberating. You don't have to be perfect; you just can't spend more than the budget. You spend it on incidents, and you can also spend it deliberately — on a risky release, an experiment, a big refactor. Run out of budget and you stop shipping risky changes until it refills. That's how you turn "reliability vs. speed" from a philosophical argument into straightforward accounting.

Computing an SLO

MONTH_MINUTES = 30 * 24 * 60  # 43,200

def availability(ok_minutes, total_minutes=MONTH_MINUTES):
    return ok_minutes / total_minutes * 100

def error_budget_remaining(ok_minutes, target=99.9):
    actual = availability(ok_minutes)
    return actual - target

# 30 days of serving, with 25 minutes of downtime across the month
print(f"{availability(MONTH_MINUTES - 25):.3f}%")   # 99.942%
print(f"budget left: {error_budget_remaining(MONTH_MINUTES - 25):.3f}%")

The math is boring on purpose. Twenty-five minutes down in a month still lands you at 99.94%, comfortably inside a 99.9% target — and that's exactly the point of a budget: it tells you when to panic. A 30-minute outage eats most of a 99.9% target's budget; against a 99.5% target it's nothing worth waking anyone over.

Best Practice: keep your SLOs in a plain file or dashboard anyone can read, and review them monthly. An SLO nobody ever looks at is just a nice sentence.