서비스 수준 목표와 오류 예산

Reliability cannot be improved if it is not measured. SaaS teams use a vocabulary of three terms: SLI, SLO, and SLA.

Together they turn 'the system should be up' into precise, trackable targets.

An SLI is a measured value describing service quality, such as:

• Request success rate
• Latency (95th percentile response time)
• Availability (uptime percentage)

SLIs are the raw signals you collect.

An SLO is the target you set for an SLI, for example: '99.9% of requests succeed over 30 days.'

SLOs are internal goals that guide engineering decisions.

An SLA is a contractual promise to customers, often with financial penalties if missed. SLAs are usually looser than internal SLOs.

If your SLA is 99.9%, your internal SLO might be 99.95% to give yourself a safety margin.

Availability is often expressed in nines. More nines means less allowed downtime:

• 99% = ~3.65 days/year
• 99.9% = ~8.76 hours/year
• 99.99% = ~52 minutes/year

Availability is uptime divided by total time. Here is a small calculation of allowed downtime for a target.

The error budget is the allowed amount of unreliability: 100% minus your SLO. A 99.9% SLO gives a 0.1% error budget.

This budget is something you can spend on risk, deployments, and experiments.

Error budgets balance two forces:

• Velocity — ship features fast, accept some risk
• Stability — slow down, protect reliability

If the budget is healthy, ship boldly. If it is exhausted, freeze risky changes and focus on hardening.

SLOs should reflect what users actually care about. Chasing 100% is wasteful and impossible.

Set SLOs slightly above the level where users start to notice and complain. Over-engineering reliability beyond that wastes money.

Instead of alerting on every blip, mature teams alert on burn rate — how fast the error budget is being consumed.

A fast burn (budget gone in hours) pages immediately; a slow burn (budget trends over days) creates a ticket. This reduces alert fatigue.

SLOs are reviewed regularly. If you consistently beat them, tighten them or invest budget in faster shipping. If you miss them, prioritize reliability work.

This data-driven loop keeps reliability decisions objective rather than emotional.

You learned to define and manage reliability:

• SLI measures, SLO targets, SLA promises
• Nines map to concrete downtime budgets
• Error budgets and burn-rate alerts balance velocity against stability

These turn reliability into a measurable, negotiable resource.