Ako vyzerá dôveryhodné SLA na 99,9 % (a prečo je „100 % dostupnosť“ varovný signál)

Čo robí SLA dôveryhodným#

Dôveryhodné SLA je dostatočne konkrétne na to, aby sa dalo merať, a úprimne hovorí o tom, čo sa môže pokaziť. Presne definuje dostupnosť, stanoví realistický cieľ, napríklad 99,9 % mesačne, vymenuje, čo je vylúčené, garantuje reakčné časy podľa priority a uvádza, čo dostanete späť, keď sa cieľ nesplní. Čokoľvek vágnejšie je marketingová stránka, nie úroveň služby.

Opak sa ľahko rozpozná: „100 % dostupnosť“, „podpora 24/7“ bez reakčných časov, „chyby opravené do 4 hodín“ a ani zmienka o kreditoch. V obchodnej prezentácii to znie dobre, no keď sa niečo pokazí, nikoho to neochráni.

SLA vs. SLO vs. SLI#

SLI (service level indicator) je meranie, SLO (service level objective) je interný cieľ pre toto meranie a SLA (service level agreement) je zmluvný prísľub s dôsledkami. SLO je zvyčajne prísnejšie ako SLA, aby tím zareagoval skôr, než je ohrozená zmluva.

Opýtajte sa dodávateľa na definíciu SLI, ktorá stojí za jeho SLA. Ak je dostupnosť „server odpovedal na ping“, číslo môže zostať zelené, kým vaši používatelia vidia chyby.

Matematika výpadkov: čo ktoré číslo pripúšťa#

Každá ďalšia deviatka zníži povolený výpadok desaťnásobne. Pri 99,9 % máte asi 43 minút za 30-dňový mesiac; pri 99,99 % asi 4 minúty, čo je menej času, než väčšina tímov potrebuje na to, aby si všimla zlé nasadenie, diagnostikovala ho a ručne ho vrátila späť.

Prechod z 99,9 % na 99,99 % nie je zmena v konfigurácii. Zvyčajne znamená redundantnú infraštruktúru naprieč zónami alebo regiónmi, automatický failover, migrácie bez výpadku a rotáciu pohotovostí. Podľa toho to aj naceňte — a opýtajte sa, či biznis v tých 39 minútach navyše naozaj prichádza o peniaze.

Error budget mení cieľ na rozhodovacie pravidlo#

Error budget (rozpočet chybovosti) je miera nespoľahlivosti, ktorú vaše SLO pripúšťa, a hovorí tímu, kedy dodávať a kedy zastaviť a opravovať. Pri SLO 99,9 % a milióne požiadaviek mesačne je rozpočet 1 000 neúspešných požiadaviek. Kým z rozpočtu niečo zostáva, dodávajte funkcie. Keď sa minie, prednosť má práca na spoľahlivosti, kým sa rozpočet neobnoví.

# Príklad definície SLO (v štýle 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

Formát je menej dôležitý ako zvyk. SLI si zapíšte, upozornenia nastavte na rýchlosť míňania rozpočtu namiesto jednotlivých chýb a rozpočet prechádzajte na tom istom stretnutí, na ktorom plánujete funkcie.

Reakčný čas vs. čas vyriešenia#

Reakčný čas je to, ako rýchlo kvalifikovaný inžinier problém potvrdí a začne na ňom pracovať. Čas vyriešenia je to, ako dlho trvá oprava. Prvé má dodávateľ pod kontrolou. Druhé závisí od chyby, od dát a niekedy aj od tretích strán, preto poctivé SLA garantujú reakciu a vyriešenie považujú za best effort s pravidelnými aktualizáciami.

Sľub typu „všetky kritické chyby opravené do 4 hodín“ sa buď nedodrží, alebo sa splní narýchlo zbúchanou záplatou, ktorá spôsobí ďalší incident. Namiesto toho chcete záväzok rýchlo zareagovať, najprv obnoviť službu (rollback, failover, feature flag) a až potom poriadne opraviť príčinu.

Matica priorít od P1 po P4#

Matica priorít priraďuje dopadu na biznis reakčné záväzky, aby sa o naliehavosti nikto nehádal o druhej v noci. Úrovne definujte podľa toho, čo zažívajú používatelia, nie podľa toho, ako veľmi je nahnevaný ten, kto problém nahlásil. Reakčné časy nižšie sú ilustračný príklad; správne hodnoty závisia od vášho plánu a pracovných hodín.

Servisné kredity: čo sa stane, keď sa cieľ nesplní#

Servisné kredity sú čiastočné vrátenie mesačného poplatku, keď dostupnosť klesne pod SLA. Nikdy vám nenahradia stratené tržby a ani na to nie sú určené. Existujú preto, aby mal dodávateľ finančný dôvod cieľ splniť a aby malo jeho nesplnenie zdokumentovaný dôsledok.

Overte si, ako sa kredity uplatňujú. Ak musíte v krátkej lehote podať žiadosť s vlastnými dôkazmi, dodávateľ by mal aspoň zverejňovať namerané údaje, ktoré na to potrebujete.

Výnimky, ktoré má každé poctivé SLA#

Každé poctivé SLA vylučuje výpadky, ktoré dodávateľ nemá pod kontrolou alebo ktoré vopred ohlásil. Nejde o vyhýbanie sa zodpovednosti, ale o to, aby bol zvyšný prísľub merateľný. Podstatné je, aby boli výnimky pomenované a úzke.

• Ohlásená údržba. Plánovaná práca ohlásená vopred (napríklad 48 hodín), ideálne v hodinách s nízkou prevádzkou a s mesačným stropom.
• Poskytovatelia tretích strán. Ak aplikácia beží na cloude, databáze alebo platobnej bráne tretej strany, dostupnosť tejto vrstvy sa riadi vlastným SLA daného poskytovateľa. Dodávateľ nemôže sľúbiť viac ako platforma pod ním.
• Problémy spôsobené klientom. Zmeny urobené mimo dohodnutého procesu, prekročené limity používania alebo prístupové údaje zdieľané a kompromitované na strane klienta.
• Vyššia moc a útoky nad rámec primeranej ochrany. Definované v zmluve, nie používané ako univerzálna výhovorka.

Prečo je „100 % dostupnosť“ varovný signál#

Žiadny systém, ktorý sa nasadzuje, záplatuje a závisí od sietí, nedosiahne 100 % dostupnosť. Dodávateľ, ktorý ju sľubuje, teda buď nemeria, alebo si výpadky zadefinuje preč, alebo počíta s tým, že to nikdy neskontrolujete. Skúsení CTO to čítajú ako znak, že dodávateľ produkčné systémy nikdy vážne neprevádzkoval.

Na čo sa opýtať dodávateľa pred podpisom#

Klaďte otázky, ktoré SLA prinútia byť konkrétnym: ako sa meria dostupnosť, čo je vylúčené, čo znamená každá priorita a čo dostanete, keď cieľ nesplnia. Dobrý dodávateľ odpovie na každú jednou či dvoma vetami a vie ukázať príslušný článok zmluvy.

• [ ]Aké presné SLI stojí za „dostupnosťou“ a meria sa zvonka vašej infraštruktúry?
• [ ]Je cieľ mesačný alebo ročný a za aké kalendárne alebo kĺzavé obdobie?
• [ ]Ktoré komponenty sú pokryté a ktoré preberajú SLA poskytovateľa tretej strany?
• [ ]S akým predstihom ohlasujete údržbu a má mesačný strop?
• [ ]Aké sú reakčné časy podľa priority a v akých hodinách platia?
• [ ]Kto určuje prioritu incidentu a ako môžem eskalovať?
• [ ]Aké servisné kredity platia a ako sa uplatňujú?
• [ ]Dostanem stavovú stránku, správy o incidentoch a mesačný report dostupnosti?
• [ ]Komu patrí kód, cloudové účty a monitoring, ak sa rozídeme?
• [ ]Čo zahŕňa údržba: aktualizácie závislostí, bezpečnostné záplaty, zálohy a testy obnovy?

Dostupnosť je len polovica údržby#

SLA pokrýva dostupnosť a reakciu; kód tým zdravý nezostane. Závislosti starnú, bezpečnostné záplaty sa hromadia a skratky sa sčítavajú. Plán údržby by mal na túto prácu vyhradiť čas, inak sa SLA bude každý mesiac plniť ťažšie.

Plánovaná, pravidelná práca na dlhu je lacnejšia než jej núdzová verzia. Jeden spôsob, ako na to, opisujeme v článku ako splácať technický dlh bez zastavenia vývoja funkcií.

Ako to formulujeme v plánoch Care v Backloo#

Naše plány Care garantujú 99,9 % mesačnú dostupnosť pri systémoch, ktoré hostujeme a prevádzkujeme. To je približne 43 minút výpadku za mesiac, bez údržby ohlásenej 48 hodín vopred. Pod cieľovou hodnotou platia servisné kredity podľa odstupňovanej tabuľky vyššie.

• Reakčné časy, nie časy opravy. Garantujeme reakčné časy podľa priority, najprv obnovíme službu a príčinu potom poriadne opravíme.
• Prevzaté SLA otvorene uvedené. Dostupnosť infraštruktúry tretích strán sa riadi vlastným SLA daného poskytovateľa a zmluva to výslovne uvádza.
• Dve úrovne. Care začína na 490 € mesačne a Care Plus na 1 490 € mesačne; stránka plánov presne uvádza, čo každý z nich zahŕňa.
• Váš GitHub, váš cloud, vaše IP. Odchod je odovzdanie, nie vyjednávanie o rukojemníkoch.

Ako vám môže pomôcť Backloo#

Ak porovnávate dodávateľov, použite checklist vyššie aj na nás. Ak už prevádzkujete produkčnú aplikáciu a chcete písomné SLA so skutočným meraním, pozrite si plány údržby a SLA. Ak samotný systém potrebuje redundanciu skôr, než bude vyšší cieľ dávať zmysel, ide o prácu na backendových systémoch. Najprv máte otázky? Ozvite sa nám.