SLA and Support Model

1) The problem this lesson solves

An SLA sold as “99.95%” can be operationally empty when nobody has defined what is measured, over which window, with which exclusions, what consequence applies, or whether support staffing can actually serve the promise. This lesson binds the commercial promise to operational evidence.

2) Lesson boundary and deliverable

The deliverable is SLA-SLO Support Operating Contract v1. ARC-021 does not own ARC-020 Plan/Entitlement Model or ARC-022 Anti-fork Customization, and it performs no live monitoring, staffing, billing-credit, or contract mutation.

3) Fact: SLI, SLO, and SLA are different

Google SRE describes an SLI as a quantitative service-level measure, an SLO as a target on that measure, and an SLA as an agreement with consequences when objectives are not met. A percentage by itself is therefore not a complete SLA.

4) Fact: prefer indicators relevant to the user

A convenient internal metric is not automatically a user-relevant indicator. If server availability looks healthy while user-facing failures rise, the measurement contract is incomplete and cannot support a commercial success claim.

5) Make the measurement contract explicit

For every tier, record sli_id, sli_definition, measurement_source, and measurement_window. Without those fields, even a precise target is not auditable.

6) Understand SLO before selling SLA

An SLO is an operational target and must fit validated service and dependency capability. A commercial SLA stricter than proven capability does not create reliability; it creates overcommitment.

7) Consequence distinguishes an SLA boundary

Do not automatically call a target an SLA when no consequence is defined. A consequence can be a service credit or another contractual remedy; the exact commercial schedule remains local business design, not a Google SRE mandate.

8) Keep support severity separate from availability

Severity, response target, resolution target, support hours, and escalation path form a distinct operating axis. Good availability evidence does not prove a 24/7 support promise is serviceable.

9) Staffing must cover the promise

If the agreement promises 24/7 critical response while staffing is weekday-only, the state remains HOLD_SUPPORT_UNSTAFFED until real coverage or a revised promise is evidenced.

10) Keep the dependency boundary visible

A customer-facing service cannot safely ignore a critical dependency whose objective constrains the end-to-end promise. Dependency evidence belongs in the decision, not in an invisible footnote.

11) Use exclusions and error budget carefully

exclusion_rule must be explicit and bounded; it must not erase genuine user-facing failure. error_budget_policy is an operating policy and does not replace contractual consequences or staffing evidence.

12) Core Evidence Contract

This lesson uses 20 evidence dimensions, 16 of them critical. The compact table below shows baseline, measurement failure, and support transfer; JSON/CSV retain the complete mapping.

13) Typed states prevent fake success

HOLD_EVIDENCE_MISSING, HOLD_MEASUREMENT_INVALID, HOLD_SUPPORT_UNSTAFFED, HOLD_DEPENDENCY_RISK, REJECT_SLA_OVERCOMMIT, and BLOCKED_CONSEQUENCE_UNDEFINED are valid outputs. Missing evidence must never be guessed into ADMISSIBLE.

14) Approval and review triggers

A service tier becomes admissible only when measurement/support ownership is explicit and review_trigger covers changes to instrumentation, dependency objective, staffing coverage, or commercial consequence.

15) Lab and transfer

The lab uses eight fixtures and 48 assertions. In transfer, client-side SLI instrumentation appears, the dependency improves, overnight staffing disappears, and a financial service credit is added. The learner must recompute from the changed evidence; the baseline is not the oracle.