PITR, RPO, RTO, SLI, SLO i SLA: słownik recovery

PITR

PITR to point-in-time recovery.

Najprościej:

odtworzenie danych do konkretnego punktu w czasie

Nie "do ostatniego backupu".

Nie "do najnowszego dostępnego stanu".

Tylko do wybranego momentu.

Przykład:

odtwórz bazę do 2025-01-14 10:42:15

W PostgreSQL zwykle oznacza to połączenie backupu bazowego i zapisów WAL.

Backup bazowy daje punkt startowy.

WAL pozwala odtworzyć kolejne zmiany aż do wybranego momentu.

To jest mocne, bo błąd nie zawsze jest wykryty od razu.

Jeżeli błędny job skasował dane o 10:43, a monitoring zapalił się o 11:20, ostatni backup z 10:00 może być za stary, a stan z 11:20 jest już popsuty.

PITR daje trzecią opcję:

wracamy tuż przed błędnym zapisem

RPO

RPO to recovery point objective.

Odpowiada na pytanie:

ile danych możemy stracić?

Jeżeli RPO wynosi 15 minut, organizacja akceptuje ryzyko, że po awarii zabraknie ostatnich 15 minut zapisów.

To nie znaczy, że zawsze tyle stracimy.

To znaczy, że system jest projektowany pod taki limit.

RPO wymusza konkretne decyzje:

jak często robimy backup
czy archiwizujemy WAL albo binlog
gdzie trzymamy kopie
jak szybko wykrywamy przerwę w replikacji
czy testujemy odtworzenie, a nie tylko tworzenie backupu

Backup raz dziennie i RPO 5 minut to fantazja.

Można tak napisać w dokumencie, ale system tego nie spełnia.

RTO

RTO to recovery time objective.

Odpowiada na pytanie:

jak długo możemy wracać do działania?

Jeżeli RTO wynosi godzinę, plan recovery musi zmieścić się w godzinie od decyzji albo od początku incydentu, zależnie od tego, jak organizacja to definiuje.

Tu często pojawia się literówka TRO.

W praktyce prawie zawsze chodzi o RTO.

RTO obejmuje więcej niż samo odtworzenie danych.

Trzeba policzyć:

czas wykrycia
czas decyzji
czas uruchomienia procedury
czas odtworzenia
czas walidacji
czas przepięcia ruchu
czas komunikacji

Jeżeli baza odtwarza się 20 minut, ale zespół przez 40 minut szuka osoby z uprawnieniami, realne RTO nie wynosi 20 minut.

Wynosi co najmniej godzinę.

SLI i SLO

Zanim dojdziemy do SLO, trzeba nazwać SLI.

SLI to service level indicator.

To konkretna miara działania usługi.

Przykład:

procent poprawnych odpowiedzi
p99 latency
procent udanych zapisów
czas od błędu do wykrycia

SLI musi dać się policzyć.

Nie jest nastrojem zespołu ani ogólnym zdaniem "system działa wolno".

Jeżeli podczas recovery mówimy, że "checkout wrócił", SLI powinno pokazać, co to znaczy.

czy odpowiada
czy zapisuje zamówienia
czy mieści się w latency
czy nie zwraca błędów

SLO to service level objective.

To cel techniczny ustawiony na podstawie SLI.

Inaczej:

SLI mierzy
SLO mówi, jaki wynik uznajemy za dobry

Przykład:

99.9% poprawnych odpowiedzi w miesiącu
p99 latency poniżej 300 ms
99.95% dostępności endpointu checkout

SLO pomaga podjąć decyzję podczas incydentu.

Jeżeli błąd dotyczy małej funkcji, która nie wpływa na główne SLO, rollback może być mniej pilny.

Jeżeli błąd niszczy ścieżkę zakupową, każde kilka minut pali error budget.

SLO nie mówi, jak zrobić recovery.

Mówi, dlaczego recovery jest pilne i jaki wpływ naprawdę mierzymy.

Error budget

Error budget to różnica między idealnym działaniem a zaakceptowanym SLO.

Jeżeli SLO mówi o 99.9% poprawnych odpowiedzi, to system może mieć 0.1% błędów w danym oknie.

To jest budżet błędów.

Podczas incydentu error budget pokazuje, jak szybko zużywamy margines.

Nie mówi, jak odtworzyć bazę.

Pomaga zdecydować, czy problem trzeba ciąć natychmiast, czy można spokojnie dokończyć diagnozę.

SLA

SLA to service level agreement.

To już nie tylko cel techniczny.

To zobowiązanie wobec klienta, działu biznesowego albo innej strony umowy.

SLA może mieć konsekwencje finansowe, formalne albo reputacyjne.

Najczęstsza pomyłka wygląda tak:

SLO mamy dla siebie
SLA obiecaliśmy komuś

Jeżeli SLO jest ostrzejsze niż SLA, zespół ma bufor.

Jeżeli SLA jest ostrzejsze niż realne SLO, organizacja sprzedaje obietnicę, której system nie dowozi.

Jak to połączyć

Te pojęcia tworzą prostą mapę.

PITR: do którego momentu umiemy odtworzyć dane
RPO: ile danych możemy stracić
RTO: jak długo możemy wracać
SLI: jak mierzymy działanie usługi
SLO: jaki poziom działania chcemy utrzymać
SLA: co obiecaliśmy na zewnątrz

Warto znać jeszcze dwa skróty, bo często pojawiają się po incydencie.

MTTD to mean time to detect, czyli średni czas do wykrycia problemu.

MTTR to mean time to recover albo mean time to restore, zależnie od organizacji. W praktyce chodzi o średni czas powrotu do działania.

Nie są tak precyzyjne jak konkretne RTO dla danej usługi, ale pomagają zobaczyć, czy zespół szybciej wykrywa i zamyka incydenty.

Podczas awarii nie trzeba prowadzić akademickiej dyskusji.

Wystarczy zadać pięć pytań:

co jest popsute
od kiedy jest popsute
ile danych możemy stracić
ile czasu mamy na powrót
czy złamaliśmy obietnicę wobec użytkowników

Dopiero po tym warto wybierać mechanizm.

Bo rollback kodu, restore backupu i PITR rozwiązują różne problemy.