Operacje playbooks

1) Czym jest książka odtwarzania i czym się różni od książki startowej

Runbook jest liniową instrukcją krok po kroku dla typowej operacji/wpisu („zrób jeden, dwa, trzy”).
Playbook jest drzewo decyzji dla scenariuszy z widelcami: różne objawy → różne hipotezy → różne gałęzie działań. Zawiera kryteria wyboru, warunki bramy i gałęzie awaryjne.
Celem odtwarzania jest zmniejszenie MTTA/MTTR oraz poziomu improwizacji w sytuacji niepewności.

2) Gdzie najpierw potrzebne są playbooks

Incydenty: spadek SLO (dostępność/opóźnienie/sukces), niepowodzenie biznesowego SLI (konwersja/sukces płatności).
Zmiany: wydania, migracje, flagi funkcji, konfiguracje (canary/rollback).
Okna konserwacji: aktualizacje bazy danych/brokera, rotacje certyfikatów.
Dostawcy: PSP/KYC/CDN/IDP - degradacja i huśtawka.
Bezpieczeństwo: zagrożony klucz, podejrzana aktywność.
Ops: opóźniona świeżość, dryf obwodu, degradacja rurociągu.

3) Standardy Playbook (minimalny skład)

1. Karta: ID, Wersja/Data, Właściciel (Zespół/Rola), Usługi/Regiony/Najemcy, Powiązane Zasady/Standardy.
2. Warunki przeznaczenia i uruchomienia: które SLO/SLI chronimy, które alerty/wyzwalacze mają zastosowanie.
3. Hipotezy dotyczące objawów: tabela korespondencyjna, jak szybko odciąć błędne hipotezy.
4. Drzewo decyzji: widelce, bramy bezpieczeństwa, kryteria stop/continue.
5. Akcje: krok bloki z poleceń/linków do runbook'i.
6. Komunikaty: szablon aktualizacji (Impakt → Diagnostyka → Deystviya → Sled. aktualizacja), kanały i częstotliwości.
7. Rollback/folback: przezroczysty plan wycofania, limity i flaga degradacji UX.
8. Kryteria wykonania: mierniki, okna czasu obserwacji.
9. Dowody: co zapisać (dzienniki, wykresy, zrzuty ekranu, identyfikator biletu).
10. Historia zmian: changelog, znane ograniczenia.

4) Taksonomia Playbook (przykład katalog)

INC- - incydenty (SLO/SLI, dostawcy, infrastruktura).
REL- - wydania, rolki, konfiguracje/flagi.
MW- - okna konserwacyjne (DB/kolejka/cert/OS).
SEC- - bezpieczeństwo (dostęp, klucze, podejrzane działania).
DATA- - świeżość/jakość/systemy.
PROV- - dostawcy zewnętrzni (PSP/KYC/CDN/Email/SMS).

5) Cykl życia i własność

1. Inicjacja: na podstawie incydentu/symulacji/zmiany.
2. Projekt: autor = właściciel serwisu; przegląd: SRE/security/data (według domeny).
3. Pilot: tablet/gra-day; rejestrowanie czasu przejścia i wad.
4. Publikacja: in repo (Docs-as-Code), wersja, tagi, linki do desek rozdzielczych.
5. Aktualizacja: zgodnie z RCA/CAPA, co najmniej raz na kwartał; Świeżość SLA.
6. Archiwum/wyczerpanie: w przypadku wymiany/utraty znaczenia.

6) Integracja z narzędziami

Alert → Playbook: Each Page rule references to exactly one basic playbook.
ChatOps: '/play start <id> 'otwiera kartę, naprawia dowody, ustawia timery aktualizacji.
CMDB/katalog: usługa posiada listę odpowiednich odtwarzaczy, właścicieli, SLO, desek rozdzielczych.
GitOps: playbooks i runbooks na żywo w Git, mają opinie PR i linters.

7) Mierniki jakości Playbook

Aktywność: ≥ 90% przebiegów prowadzi do konkretnych działań bez nieświadomej eskalacji.
Czas do pierwszej akcji: minuta lub dwie od strony do pierwszego znaczącego kroku.
Zasięg:% Page alerty, które mają powiązany playbook (100% cel).
Świeżość: proporcja playbooków jest świeższa niż 90 dni.
Wskaźnik wad: komentarze do recenzji/symulacji dla 100 odtwarzaczy.
Ponowne użycie: ile razy playbook został faktycznie zastosowany (i do jakich wyników doprowadził).

8) Anty-wzory

„Playbook Encyclopedia” z 20 stron bez drzewa decyzji.
Polecenia bez oczekiwań co do wyniku („execute X” - co powinno się zmienić?).
Nie ma planu wycofania i ograniczeń - ryzyko eskalacji problemu.
Kanały/przedziały komunikacyjne nie są wskazane - wzrost ryzyka PR.
Playbook bez daty właściciela/aktualizacji - nikt nie wierzy w jego znaczenie.
Dziesiątki podobnych odtwarzaczy zamiast jednego parametryzowalnego.

9) Mini-szablon Playbook (pomysł YAML)

yaml id: INC-PAY-001 name: "Payment Success Down"
version: 2. 4 (2025-10-15)
owner: team-payments@sre scope: [prod, region: eu, tenants: all]
goal: "Restore success_ratio ≥ 98% without violating SLA"
triggers:
- alert: slo. burn. payment_success_ratio
- external_status: psp-a partial outage symptoms:
- "5xx growth in payments-api"
- "p95 latency> 400ms on PSP-A"
decision_tree:
- if: "quorum(eu,us) confirms drop AND PSP-A status=partial"
then:
- action: "Reduce PSP-A weight to 30%"
runbook: rb://payments/traffic-shift guardrails: ["success_ratio improving 10m", "p95<300ms"]
- action: "Enable degrade_payments_ux"
runbook: rb://payments/feature-flags
- action: "Status update (30m) by template"
comms: statuspage://payments else:
- action: "Check database/cache/queue"
runbook: rb://payments/diag-stack fallback:
- action: "Failover на PSP-B 70%"
guardrails: ["fraud_rate stable", "chargeback risk noted"]
rollback:
- condition: "PSP-A green 60m"
- steps:
- "Weight of PSP-A 30→70→80 (every 30 m at green SLI)"
evidence:
- "SLI screenshots, p95/5xx graphs, links to logs/trails"
completion:
- "success_ratio ≥98% during 30 m, no burn in 6 h"

10) Gotowe przykłady (fragmenty)

A) Płatności: „Dostawca degraduje się w jednym regionie”

Objawy: zmniejszenie success_ratio kohorty TR, zwiększenie czasu PSP-A.
Rozwiązania: zmniejszyć wagę PSP-A dla TR, włączyć degrade-UX, wzmocnić przekaźniki z budżetu ≤ SLA, przygotować aktualizację klienta.
Kopia zapasowa: Odzyskać wagi przy zielonym SLI 60 minut.

B) DB: „Wzrost p99 i błędy w połączeniu”

Objawy: p99, błędy zresetowania połączenia, zdarzenia związane z oczekiwaniem na wzrost.
Rozwiązania: włączanie skryptów tylko do odczytu, ograniczenie obciążenia zapisu, pula skali/repliki, w razie potrzeby - awaria gorąca.
Kopia zapasowa: parametr rollback, replika-prime.

C) Pamięć podręczna: „Opuszczona stawka” → obciążenie bazy danych

Objawy: wskaźnik pominięcia> 40%, wzrost CPU DB.
Rozwiązania: polityka eksmisji równowagi, zwiększenie pamięci/shading, tymczasowe włączanie odczytu, ograniczenie RPS na gorących klawiszy.
Kopia zapasowa: zwróć politykę, odtworzyć problematyczne odłamki.

D) CDN: „Degradacja zawartości regionalnej”

Objawy: zwiększenie opóźnienia/czasu w jednym kraju, skargi RUM.
Rozwiązania: zmiana mapy routingu/GSLB, obejście problematycznego POP, zmniejszenie TTL, włączenie tarczy pochodzenia.
Komunikaty: aktualizacje stanu z geografią wpływu.

E) KYC: „Nieudane identyfikacje”

Objawy: spadek zatwierdzić szybkość, vendor_error wzrost.
Rozwiązania: przełączyć część ruchu na alternatywnego dostawcę, zmniejszyć dotkliwość zasad (w ramach polityki), zainicjować ręczny przegląd dla VIP.
Zgodność: dziennik wszystkich zmian, Ryzyko/Powiadomienia prawne w razie potrzeby.

11) Komunikaty (szablon aktualizacji)

Impact: EU payment success drop (-3. 1% to SLO, 25 min).
Diagnosis: confirmed by quorum; PSP-A partial outage; p95 = 420ms.
Action: PSP-A weight reduced to 30%, degrade-UX included; next update 18:30 UTC.

12) Lista kontrolna autora Playbook

• Docelowy, właściciele, SLO/SLI i wyzwalacze określone.
• Istnieje tabela "Symptomy" Hipotezy "i drzewo decyzji.
• Wykonalne kroki z oczekiwanymi wynikami i bramy bezpieczeństwa.
• Warunki wycofania/wycofania i zwrotu są wypisane.
• Szablon komunikacji i częstotliwość aktualizacji.
• Linki do desek rozdzielczych/wpisów/wyszukiwań dzienników/ścieżek.
• Wymagana sekcja dowodów i kryteria wykonania.
• Wersja, data, świeżość SLA, historia zmian.

13) Lista kontrolna

• Playbook jest rozgrywany na tablopie/grze-day.
• Kroki są bezpieczne (limity/kanaryjskie/auto-rollback), tajemnice nie są ujawniane.
• Role i eskalacje są jasne; Wskazane są IC/Comms.
• Brak powielania z sąsiednimi książkami odtwarzania; parametry są usuwane.
• Jest jasne, kiedy zatrzymać i przejść do awaryjnego/rollback.
• Dokument jest dostępny od alertu w 1 kliknięciu.

14) Parametryzacja i ponowne wykorzystanie

Przeprowadzanie zmiennych (region, dostawca, progi) w 'values. '.
Ogólne kroki (na przykład „zmniejszyć wagę dostawcy”, „włączyć degradację-UX”) powinny być wydawane w oddzielnych książkach startowych.
Generatory wsparcia z szablonów: 'plb new --type = INC --service = payments'.

15) Plan działania na rzecz realizacji (4-6 tygodni)

1. Spis alertów Page → mapa do każdego podstawowego odtwarzania.
2. Szablony: zatwierdzają strukturę YAML/Markdown, listy kontrolne i lintery.
3. 5 najlepszych scenariuszy (płatności/DB/CDN/KYC/cache) → napisz/zwiń z powrotem do tablopu.
4. Integracja: linki z wpisów, polecenia ChatOps, bot dowodowy.
5. Wiertarka: tygodniowy mini-wiertarka jeden playbook na raz; AAR → uluchsheniya.
6. Świeżość SLA i kwartalne recenzje; raport dotyczący mierników jakości.

16) Sedno sprawy

Playbooks to scenariusze operacyjne z widelcami i balustradami, które przekładają chaos „co robić?” na przewidywalną sekwencję decyzji. Kiedy playbooks są standaryzowane, zintegrowane z wpisami i regularnie szkolone, zespół reaguje szybciej, ryzyko jest kontrolowane, a biznes widzi stabilność i dojrzałość eksploatacji.