Jak vypadá důvěryhodné SLA na 99,9 % (a proč je „100% dostupnost“ varovný signál)

Co dělá SLA důvěryhodným#

Důvěryhodné SLA je dost konkrétní na to, aby se dalo měřit, a upřímné v tom, co se může pokazit. Přesně definuje dostupnost, stanoví realistický cíl, například 99,9 % za měsíc, vyjmenuje, co je vyloučené, garantuje reakční doby podle priority a říká, co dostanete zpět, když se cíl nesplní. Cokoli vágnějšího je marketingová stránka, ne úroveň služby.

Opak se pozná snadno: „100% dostupnost“, „podpora 24/7“ bez reakčních dob, „chyby opravené do 4 hodin“ a ani zmínka o kreditech. V obchodní prezentaci to zní dobře, ale jakmile se něco rozbije, nikoho to neochrání.

SLA vs. SLO vs. SLI#

SLI (service level indicator, ukazatel úrovně služby) je měření, SLO (service level objective, cíl úrovně služby) je interní cíl pro toto měření a SLA (service level agreement, smlouva o úrovni služeb) je smluvní slib s důsledky. SLO bývá přísnější než SLA, aby tým zareagoval dřív, než je smlouva v ohrožení.

Zeptejte se dodavatele na definici SLI, která stojí za jeho SLA. Pokud dostupnost znamená „server odpověděl na ping“, číslo může zůstat zelené, zatímco vaši uživatelé vidí chyby.

Výpočet výpadků: co které číslo připouští#

Každá další devítka snižuje povolený výpadek desetkrát. Při 99,9 % máte zhruba 43 minut za 30denní měsíc; při 99,99 % asi 4 minuty, což je méně času, než většina týmů potřebuje, aby si všimla špatného nasazení, diagnostikovala ho a ručně ho vrátila zpět.

Přechod z 99,9 % na 99,99 % není změna konfigurace. Obvykle znamená redundantní infrastrukturu napříč zónami nebo regiony, automatický failover, migrace bez výpadku a rotaci pohotovostí. Podle toho ho naceňte — a zeptejte se, jestli byznys v těch 39 minutách navíc skutečně přichází o peníze.

Error budget mění cíl v rozhodovací pravidlo#

Error budget (rozpočet chyb) je množství nespolehlivosti, které vaše SLO připouští, a říká týmu, kdy dodávat a kdy se zastavit a opravovat. Při SLO 99,9 % a milionu požadavků měsíčně je rozpočet 1 000 neúspěšných požadavků. Dokud z rozpočtu něco zbývá, dodávejte funkce. Když dojde, má práce na spolehlivosti přednost, dokud se rozpočet neobnoví.

# Příklad definice SLO (ve stylu OpenSLO)
apiVersion: openslo/v1
kind: SLO
metadata:
  name: api-availability
spec:
  service: web-api
  description: Requests served without a 5xx error
  budgetingMethod: Occurrences
  timeWindow:
    - duration: 30d
      isRolling: true
  indicator:
    spec:
      ratioMetric:
        good:
          metricSource:
            spec:
              query: sum(rate(http_requests_total{code!~"5.."}[5m]))
        total:
          metricSource:
            spec:
              query: sum(rate(http_requests_total[5m]))
  objectives:
    - displayName: Internal target (stricter than the 99.9% SLA)
      target: 0.9995

Na formátu záleží méně než na zvyku. SLI si sepište, upozornění posílejte podle rychlosti čerpání rozpočtu (burn rate), ne na jednotlivé chyby, a rozpočet procházejte na stejné schůzce, na které plánujete funkce.

Reakční doba vs. doba vyřešení#

Reakční doba udává, jak rychle kvalifikovaný inženýr problém potvrdí a začne na něm pracovat. Doba vyřešení udává, jak dlouho trvá ho opravit. Dodavatel má pod kontrolou to první. To druhé závisí na chybě, na datech a někdy i na třetích stranách, takže poctivá SLA garantují reakci a vyřešení berou jako best effort s pravidelnými aktualizacemi.

Slib typu „všechny kritické chyby opravené do 4 hodin“ buď nebude dodržen, nebo bude splněn uspěchanou záplatou, která způsobí další incident. Místo toho chcete závazek rychle reagovat, nejdřív obnovit službu (rollback, failover, feature flag) a příčinu pak opravit pořádně.

Matice priorit od P1 po P4#

Matice priorit převádí dopad na byznys na reakční závazky, takže se ve 2 ráno nikdo nehádá o naléhavosti. Úrovně definujte podle toho, co zažívají uživatelé, ne podle toho, jak moc je rozladěný ten, kdo problém hlásí. Reakční doby níže jsou ilustrativní příklad; správné hodnoty závisí na vašem tarifu a pracovní době.

Servisní kredity: co se stane, když se cíl nesplní#

Servisní kredity jsou částečné vrácení měsíčního poplatku, když dostupnost klesne pod SLA. Nikdy nepokryjí vaše ušlé tržby a ani to není jejich účel. Existují proto, aby měl dodavatel finanční důvod cíl splnit a aby nesplnění mělo zdokumentovaný důsledek.

Zkontrolujte, jak se kredity uplatňují. Pokud musíte v krátké lhůtě podat žádost s vlastními důkazy, měl by dodavatel aspoň zveřejňovat data z měření, která k tomu potřebujete.

Výjimky, které má každé poctivé SLA#

Každé poctivé SLA vylučuje výpadky, které dodavatel nemůže ovlivnit nebo které předem ohlásil. Nejde o vyhýbání se odpovědnosti, ale o to, aby byl zbývající slib měřitelný. Důležité je, aby byly výjimky vyjmenované a úzké.

• Ohlášená údržba. Plánované práce ohlášené předem (například 48 hodin dopředu), ideálně v hodinách s nízkým provozem a s měsíčním stropem.
• Poskytovatelé třetích stran. Pokud aplikace běží u cloudového, databázového nebo platebního poskytovatele, dostupnost této vrstvy přebírá SLA daného poskytovatele. Dodavatel nemůže slíbit víc než platforma, na které stojí.
• Problémy způsobené klientem. Změny provedené mimo dohodnutý proces, překročené limity využití nebo přístupové údaje sdílené a kompromitované na straně klienta.
• Vyšší moc a útoky nad rámec rozumné ochrany. Definované ve smlouvě, ne používané jako paušální výmluva.

Proč je „100% dostupnost“ varovný signál#

Žádný systém, který se nasazuje, záplatuje a závisí na sítích, nedosáhne 100% dostupnosti. Dodavatel, který ji slibuje, tedy buď neměří, nebo si výpadek nadefinoval tak, aby se nepočítal, anebo spoléhá na to, že to nikdy nezkontrolujete. Zkušení CTO to čtou jako znamení, že dodavatel nikdy vážně neprovozoval produkční systémy.

Na co se zeptat dodavatele, než podepíšete#

Ptejte se tak, aby se SLA muselo stát konkrétním: jak se dostupnost měří, co je vyloučené, co znamená která priorita a co dostanete, když cíl nesplní. Dobrý dodavatel odpoví na každou otázku jednou nebo dvěma větami a ukáže na příslušný článek smlouvy.

• [ ]Jaké přesné SLI stojí za „dostupností“ a měří se zvenku vaší infrastruktury?
• [ ]Je cíl měsíční, nebo roční, a v jakém kalendářním či klouzavém období?
• [ ]Které komponenty jsou pokryté a které přebírají SLA poskytovatele třetí strany?
• [ ]S jakým předstihem ohlašujete údržbu a má měsíční strop?
• [ ]Jaké jsou reakční doby podle priority a v jakých hodinách platí?
• [ ]Kdo rozhoduje o prioritě incidentu a jak můžu eskalovat?
• [ ]Jaké servisní kredity platí a jak se uplatňují?
• [ ]Dostanu stavovou stránku, zprávy o incidentech a měsíční report dostupnosti?
• [ ]Komu patří kód, cloudové účty a monitoring, pokud se rozejdeme?
• [ ]Co zahrnuje údržba: aktualizace závislostí, bezpečnostní záplaty, zálohy a testy obnovy?

Dostupnost je jen polovina údržby#

SLA pokrývá dostupnost a reakci; o zdraví kódu se nepostará. Závislosti stárnou, bezpečnostní záplaty se hromadí a zkratky se sčítají. Plán údržby by na tuto práci měl vyčlenit čas, jinak se SLA bude každý měsíc plnit hůř.

Plánovaná pravidelná práce na dluhu je levnější než její havarijní verze. Jeden ze způsobů popisujeme v článku jak splácet technický dluh, aniž byste zastavili vývoj funkcí.

Jak to formulujeme v plánech Care v Backloo#

Naše plány Care garantují měsíční dostupnost 99,9 % u systémů, které hostujeme a provozujeme. To je zhruba 43 minut výpadku měsíčně, bez údržby ohlášené 48 hodin předem. Pod cílovou hodnotou platí servisní kredity podle odstupňované tabulky výše.

• Reakční doby, ne doby opravy. Garantujeme reakční doby podle priority, nejdřív obnovíme službu a příčiny pak opravíme pořádně.
• Převzatá SLA otevřeně uvedená. Dostupnost infrastruktury třetích stran se řídí SLA daného poskytovatele a smlouva to výslovně říká.
• Dvě úrovně. Care začíná na 490 € měsíčně a Care Plus na 1 490 € měsíčně; stránka plánů přesně uvádí, co která zahrnuje.
• Váš GitHub, váš cloud, vaše IP. Odchod je předání, ne vyjednávání o rukojmích.

Jak vám Backloo může pomoct#

Pokud porovnáváte dodavatele, použijte checklist výše i na nás. Pokud už provozujete produkční aplikaci a chcete písemné SLA, za kterým stojí skutečné měření, podívejte se na plány údržby a SLA. Pokud systém potřebuje redundanci dřív, než dává vyšší cíl smysl, jde o práci na backendových systémech. Máte nejdřív otázky? Ozvěte se.