Inżynieria niezawodności

1) Czym jest SRE i dlaczego jest ona potrzebna

Site Reliability Engineering (SRE) to dyscyplina na styku rozwoju i działania, która zamienia niezawodność w wymierny atrybut produktu. SRE łączy mierniki doświadczenia użytkownika (SLIs), cele jakości (SLO), budżety błędów, automatyzację i zarządzane zmiany, aby zapewnić wartość szybciej bez utraty odporności.

Kluczowe cele to przewidywalny UX, szybkie zwolnienia, minimalny czas przestoju i kontrolowany koszt własności.

2) Zasady SRE

Niezawodność jako cecha. Priorytetowo traktuje się limity określone przez SLO i cele biznesowe.
Budżet błędu kontroluje tempo zmian. Jeśli budżet zostanie spalony, nacisk zostanie położony na stabilność.
Automatyzacja> operacje ręczne. Każde powtarzalne zadanie to skrypt/operator/rurociąg.
Wymierność. Tylko to, co jest mierzone (SLI/SLO) można poprawić.
Tylko kultura. Pośmiertnie bez oskarżeń, skupić się na przyczynach systemowych.
Zmiana w lewo. Jakość, bezpieczeństwo, testy i obserwowalność są częścią cyklu rozwoju.

3) Organizacja i role

Zespół platformy SRE: wspólne narzędzia, polityki, rurociągi, GitOps, katalogi serwisowe.
Wbudowane SRE: Praca obok zespołu produktów, wspólne cele SLO.
Dyżur: obroty, ograniczenia obciążenia, kompensacja, szkolenia.
RACI: właściciel usług, właściciel SLO, IC w incydentach, Comms Lead, Scribe.

4) SLI/SLO i budżet błędów (link produktu)

SLI: dostępność, opóźnienia, sukces działalności gospodarczej, adekwatność danych.
SLO: gole dla okien 28-30 dni + wyjątki.
Budżet błędu = 1 − SLO. Politycy: uwolnienia, eksperymenty, kanarki i cechy są regulowane przez rzeczywistą szybkość spalania.
Projektowanie według kohorty: regiony, dostawcy, segmenty VIP - poszczególne SLO, aby nie stracić anomalii.

5) Domyślna obserwowalność

Wskaźniki: sukces/błąd, percentyle p50/p95/p99, nasycenie (CPU/mem/IO/conn).
Dzienniki: ustrukturyzowane, z korelacją żądań/wydań/flag.
Śledzenie: końcowa mapa opóźnień i błędów, gorące ścieżki.
Syntetyka + RUM: zewnętrzne próbki i rzeczywista telemetria klienta.
Deski rozdzielcze SLO: budżet spalania, adnotacje wydania, kanarka, dostawcy.

6) Zarządzanie zmianą i uwolnieniem

Rurociąg CI/CD: zespoły deterministyczne, podpis artefakt, skany bezpieczeństwa, testy kontraktowe.
Strategie progresywne: kanaryjski/niebiesko-zielony/cień; posiadają flagi z cyklem życia.
Jakość bramy: policy-as-code, SLO-guardrails, auto-rollback pod degradacją.
GitOps: konfiguracje/polityki jako kod, promocja środowiska, audyt.

7) Incydenty i zwłoki

Deklaracja na poziomach SEV/P, IC jest przydzielana natychmiast, freeze uwalniania z SEV-1 +.
Alerty spalania: krótkie i długie okna, kworum według regionu i typu próbki.
Playbooks: kickbacks, degradations, provider failure over, limits/retrays.
RCA i CAPA: fakt, przyczynowość, wymierne działania, punkty kontroli (D + 14/D + 30).
Katalog wiedzy: ponowne użycie szablonów i lekcji.

8) Badanie niezawodności

Testy kontraktowe i umowy konsumenckie na mikroprocesory.
Profile obciążenia według prawdziwych wzorów, p99 test/GC pauza/ogony kolejki.
Przypadki chaosu/odporności: wyłączanie zależności, sieci, opóźnienia; dni gry i ćwiczenia DR.
Migracje bazy danych: rozszerzyć → migrate → kontrakt, odwracalność, testy kompatybilności dwóch wersji.

9) Zarządzanie zdolnościami i kosztami (FinOp)

Pojemność Jednostki i zagłówek na ścieżkach krytycznych.
HPA/VPA/KEDA według mierników użytkownika i opóźnień w kolejce.
Wielu dostawców: kwoty, SLO/latency routing, auto-feiler.
Unit-economics: $/1k żądania, $/udana transakcja; optymalizacja buforów, kłód, wyjścia.

10) Bezpieczeństwo w ramach niezawodności

SAST/DAST/SCA, wyszukiwanie tajemnic, SBOM, podpis obrazu.
minimalne uprawnienia w zakresie MTLS i polityki dostępu (OPA/ABAC).
Rotacja klucza/certyfikatu, monitorowanie terminów, scenariusze testów wygaśnięcia.
Incydenty związane z bezpieczeństwem - pojedyncze playbooks, kryminalistyka, powiadomienia regulatora.

11) Kultura i procesy

Opinie SLO: tygodniowo/miesięcznie, priorytetyzacja zadłużenia nad fioletowymi funkcjami.
Szkolenia i symulacje: szkolenia dyżurne, próby incydentów, dni chaosu.
Jednolite normy: listy kontrolne gotowości do produkcji, komunikacja SLA, format pośmiertny.
Wskaźniki zmęczenia alarmowego: hałas ≤ próg docelowy, regularne dostrajanie.

12) Wskaźniki zapadalności funkcji SRE

Wskaźniki DORA: wskaźnik wyczerpania, czas realizacji, MTTR, wskaźnik awarii zmian.
Wykonanie SLO: udział usług w zielonej strefie, tendencja spalania.
Higiena alarmu:% działań strony, mediana alarmu/zmiany, fałszywa szybkość.
RCA/CAPA: realizacja na czas, udział powodów systemu (nieosobowych), szybkość ponownego otwarcia.
Koszt: punkt $/SLO, żądania $/1k, wydajność autoskalowa.

13) Lista kontrolna „Gotowość serwisowa do produkcji”

• Zdefiniowano SLI/SLO, właściciela SLO i okno obserwacyjne.
• Deski rozdzielcze i alerty spalania są dostrojone, istnieje syntetyka zewnętrzna.
• Rurociąg: podpisy/skany, testy kontraktowe/integracyjne, kanaryjskie/flagi, auto-rollback.
• Migracje DB są odwracalne, profile obciążeń obejmują szczyty.
• Odtwarzacze incydentów i kontakty dostawców; strona statusu.
• Potwierdzenie pojemności zagłówka; Skontrolowane kwoty HPA/KEDA i dostawcy.
• Konfiguracje i polityki - w Git, środa promocja, audyt włączony.
• Bezpieczeństwo: tajemnice poza kodem, mTLS/rotacja, czas TLS pod kontrolą.

14) Anty-wzory

«99. 999% lub nic" - nieosiągalne cele → wieczne czerwone oparzenia.
Wydania bez kanarów i flagi funkcyjne → duże eksplozje.
Jeden punkt monitorowania → fałszywe alarmy i pominięcia.
Ręczne zmiany konfiguracji w produkcie → dryfowanie i bezgłośność.
Post śmiertelne bez CAPA → powtarzające się incydenty.
SRE jako „strażacy” bez prawa do zmiany architektury → dług nie jest zamknięty.

15) Plan realizacji SRE (przykład na 3-6 miesięcy)

1. miesiąc 1: inwentaryzacja usług i ścieżek krytycznych; projekty SLI/SLO; podstawowe deski rozdzielcze i wpisy o szybkości spalania; uruchom dyżur.
2. Miesiąc 2: kanarki/flagi funkcyjne, auto-kickbacks; Konfiguracje GitOps; katalog playbook incydentu; strona statusu.
3. Miesiąc 3: testy kontraktowe, profile obciążenia, migracje baz danych zgodnie z programem rozszerzenia/umowy; pierwsze dni gry.
4. Miesiąc 4-6: trasy dla wielu dostawców, ćwiczenia DR, optymalizacja kosztów, wskaźniki dojrzałości, KPI dla zespołów.

16) Sedno sprawy

SRE to system operacyjny rozwoju: przejrzyste cele jakościowe (SLO), kontrolowana szybkość zmian (budżet błędów), automatyzacja i dyscyplina incydentów, testy odporności i świadome koszty. Dzięki temu podejściu, wydania stają się rutynowe, a niezawodność staje się przewagą konkurencyjną.