Analiza przesunięć i wydajności

1) Cel i wartość

Shift analytics to system pomiarowy, który sprawia, że zarządzanie operacjami 24 × 7 jest przewidywalne: potwierdza pokrycie SLO, identyfikuje wąskie gardła (nocne szczeliny, zatłoczone domeny), zapobiega wypalaniu i poprawia jakość ręczników. W przypadku iGaming ma to bezpośredni wpływ na szybkość wpłat/rozliczeń, terminy KYC/AML i reputację.

2) Taksonomia mierników

2. 1 Zasięg i gotowość

Wskaźnik pokrycia -% godzin przy pełnym składzie (według roli/domeny/regionu).
Gotowość dyżurów - odsetek przesunięć z przypisanym IC/CL i ważnymi kontaktami.
Przekazanie SLA - zgodność z oknem transferowym (10-15 min) i listą kontrolną.

2. 2 Szybkość reakcji i redukcji

MTTA/MTTR (według dni/Swing/Nocne szczeliny, według domeny): mediana, p90.
Detection Lead - opóźnienie między degradacją SLI a pierwszym działaniem.
Czas monitorowania po zwolnieniu - rzeczywisty monitoring wydania.

2. 3 Jakość przesunięcia

Przekazywanie wad - puste pozycje listy kontrolnej.
Info Drift - rozbieżność faktów między var-room, ITSM i kanał statusu.
Działanie Przeniesienie - odsetek zadań, które „migrowały” bez właściciela/ETA.

2. 4 Obciążenie i zmęczenie

Pager Zmęczenie: alert/osoba/tydzień, strony nocne, P1/person/shift.
Gęstość eskalacji: odsetek incydentów, które dotarły do L2/L3 (przeciw naprawom w książce startowej L1).
Idle vs. Busy Ratio: kontra czas oczekiwania na żywo.

2. 5 Wydajność i automatyzacja

Auto-Fix Rate - incydenty rozwiązane przez automatyczne działania/bot.
Runbook Usage -% wpisów zamkniętych zgodnie ze standardowymi scenariuszami.
Pierwsza rozdzielczość kontaktowa (FCR) - Zamknij na poziomie L1 bez eskalacji.
Średni czas między incydentami (MTBI) - stabilność domeny/gniazda.

2. 6 Sprawiedliwość i zrównoważony rozwój

Indeks Fair-Share - równość noclegów/weekendów przez ludzi.
Wymiana SLA - zamienniki potwierdzone ≥ 48 godzin przed zmianą.
Zasięg treningowy - udział przesunięć z gniazdem cieni do wsiadania na pokład.

2. 7 Łącze biznesowe

SLO Impact Score - Jak długo zmiana utrzymywała SLO w kolorze zielonym.
Dochody zagrożone (proxy) - oszacowanie utraconych dochodów z P1/P2 przesunięć.
Partner Latency/Declines - wkład partnerów PSP/KYC w przesunięcie incydentów.

3) Model danych

3. 1 Ziarno wydarzeń

shift_event: start/end, skład, role (IC/CL/L1/L2), region, domeny.
alert_event: sygnał, priorytet, właściciel, zamknięcie, runbook/auto-action.
incident_event: P1-P4, linie czasowe, IC/CL, publikacje o statusie.
handover_check: znaki listy kontrolnej + wady/komentarze.
release_watch: okna obserwacyjne, bramy, auto-rolki.
dziennik pracy: minuty produkcyjne (diagnostyka, poprawki, aktualizacje przecinków, pośmiertnie).
fatigue_signal: częstotliwość stron/nocy, godziny pracy.

3. 2 Schemat (uproszczony)

Клева: 'timestamp', 'tenant', 'region', 'środowisko', 'domena', 'rola', 'dotkliwość'.
Opcje przechowywania: jezioro zdarzeniowe (parkiet/góra lodowa) + preagregaty w DWH/TSDB.
Polityka PII: tylko agregaty i pseudonimy; e-mail/ID są zamaskowane.

4) Gromadzenie danych (ETL)

1. ChatOps/bot: polecenia '/handover ', '/incident', '/runbook '→ magazyn WORM.
2. ITSM: statusy incydentów/biletów, łączące się z pokojami var.
3. Metryki API: SLI/SLO (auth-success, bet → settle p99, error-rate), KRI (kolejka opóźnienia, PSP zmniejsza).
4. Planator zmiany: kalendarze, zamienniki, role, cień.
5. CI/CD: wydania, okna obserwacyjne, auto-rolki.

ETL normalizuje, dodaje 'shift _ slot' (Day/Swing/Night), oblicza mierniki pochodne (MTTA/MTTR, Fair-Share).

5) Deski rozdzielcze

5. 1 Exec (przegląd tygodniowy/miesięczny)

CFR, MTTR, Auto-Fix Rate, SLO Impact, Revenue-at-Risk (proxy).
Mapa przeciążania gniazda i domeny (termiczna).

5. 2 Ops/SRE (każda zmiana/dziennie)

Panel czasu rzeczywistego: otwarte P1-P4, szybkość spalania, kolejki/replikacje, poręcze.
Przekazanie karty stanu listy kontrolnej i wad.
Panel zmęczenia: strony/osoby, noce/osoby (ostatnie 4 tygodnie), ostrzeżenia.

5. 3 Zespół/domena

MTTA/MTTR według domeny, FCR, Runbook Usage, udział eskalacji L2/L3.
Fair-Share i Replacement SLA dla konkretnego zespołu.

6) Wzory i progi

Wskaźnik pokrycia = Watch/168 objęte. Cel ≥ 99%.
Przekazać SLA =% przesunięcia w miejscu zakończenia transferu, a lista kontrolna jest zamknięta ≤ 15 minut (cel ≥ 95%).
Pager Fatigue (wk): p95 alert/person ≤ target; ostrzeżenie na> p90.
Indeks Fair-Share = 1 − (w nocy/ target_nochey). Cel ≥ 0. 8.
Wskaźnik Auto-Fix ≥ 40% dla L1 na kwartał (cel zależy od terminu zapadalności).
Runbook Użycie ≥ 70% dla powtarzających się wpisów (10 najlepszych sygnałów).

karty kontrolne (X-MR, p-wykresy) dla MTTA/MTTR i wad; wpisy wykraczające poza granice kontroli.

7) Metody analityczne

Anomalie: STL/ESD/CUSUM za pomocą alarmu i MTTA/MTTR, oznaczanie odstępstw i przyczyn (zwolnienie, dostawca).
Przewidywanie obciążenia: Prorok/ARIMA przez alert i P1/P2 na gniazdo → Planowanie FTE.
Przypisanie wyniku: model podwyższenia zmian w procesach (na przykład nowy szablon przekazania) → MTTR.
Eksperymenty kontrolne: A/B w procesach wewnętrznych (wersja listy kontrolnej, nowa książka startowa).
Analiza kohort: wydajność nowicjuszy (cień → solo) kontra doświadczony.

8) Integracja

Incydent bot: słupki przesuwają mierniki, przypomina o nieograniczonym przekazaniu, rozpoczyna się retro.
Release-portal: łączy okna uwolnienia z szczytami obciążenia; auto-pauza na czerwonych SLO.
Metryki API: gotowe SLO-view + przykłady (trace_id) dla RCA.
HR/PTO: współczynniki kurczenia → planowanie i analityka fair-share.

9) Politycy i RACI

Ops Analytics Owner (SRE/Platform): model danych, deski rozdzielcze, dokładność metryczna.
Właściciele usług: interpretacja sygnałów domeny, plany poprawy.
Duty Manager: cotygodniowa analiza KPI/KRI, saldo gniazda.
Zgodność/Sec: Zgodność z PII/SoD w telemetrii i sprawozdawczości.
Szkolenie Lead: Plany pokładowe z badań analitycznych.

10) Wzory artefaktów

10. 1 Katalog metryk (YAML)

yaml apiVersion: ops.analytics/v1 kind: MetricCatalog items:
- id: coverage_rate owner: "SRE"
formula: "covered_hours / 168"
slice: ["region","slot","domain"]
target: ">=0.99"
- id: mtta_p50 owner: "Ops"
formula: "median(ack_ts - alert_ts)"
slice: ["slot","severity","domain"]
target: "<=5m (P1)"
- id: handover_defect_rate owner: "Ops"
formula: "defects / handovers"
target: "<=5%"
- id: pager_fatigue_p95 owner: "SRE"
formula: "p95(alerts_per_person_week)"
target: "<=team_threshold"

10. 2 Przykład zapytania (kruszywo SQL)

sql
SELECT slot, domain,
percentile_cont(0.5) WITHIN GROUP (ORDER BY ack_s-emit_s) AS mtta_p50,
percentile_cont(0.9) WITHIN GROUP (ORDER BY ack_s-emit_s) AS mtta_p90,
AVG(auto_fix)::float AS autofix_rate
FROM alerts_fact
WHERE ts BETWEEN:from AND:to AND severity IN ('P1','P2')
GROUP BY slot, domain;

10. 3 Lista kontrolna (sygnały jakości)

Streszczenie SLO/SLI załączone

Otwarte incydenty mają właścicieli/ETA

Planowane prace/wydania są związane

Ryzyko dostawcy jest stałe

Projekty comm gotowe

Kontakty dyżurne są istotne

Aktualizacja listy obserwacyjnej

11) Zarządzanie ryzykiem i poprawą

KRI: DLQ/kolejka-lag wzrost za gniazdo nocne, FCR spadek <cel, Info Drift spike.
Plan poprawy: Cotygodniowy plan operacyjny z właścicielami/ETA na Top 3 Flops.
Zmiany dyscypliny pośmiertnej: retro na wady przekazania i klapki alarmowe.
Proces A/B: sprawdzenie wpływu nowych regulacji na MTTR/Auto-Fix.

12) Przykłady KPI/OKR (kwartał)

KR1: MTTR P1 (mediana)

KR2: Przekazać SLA ≥ 95% w trzech gniazdach.
KR3: Auto-Fix Rate ≥ 45% dla najlepszych 10 reguł sygnalizacji.
KR4: Pager Zmęczenie p95 na 20% (po optymalizacji alarmu).
KR5: Wskaźnik sprawiedliwego udziału ≥ 0. 85 we wszystkich drużynach.

13) Plan działania na rzecz realizacji (6-10 tygodni)

Ned. 1-2: schematy wydarzeń, ETL z bot/ITSM/Metrics API, pierwszy katalog mierników, podstawowe deski rozdzielcze.
Ned. 3-4: karty kontrolne i progi, panel zmęczenia, jakość przekazania, pakiet z wydaniami.
Ned. 5-6: prognozowanie obciążenia (sloty/domeny), analityka sprawiedliwego udziału i wymiany.
Ned. 7-8: auto-porady (które książki startowe zautomatyzować), auto-fix raporty ROI, szablony retro.
Ned. 9-10: eksperymenty w procesach (listy kontrolne A/B), KPI na panelach Exec, zespoły szkoleniowe.

14) Antypattery

Rozważyć „sukces zmiany” tylko przez liczbę biletów zamkniętych (bez kontekstu MTTR/SLO).
Ignoruj wady przekazania („i tak zrozumiałe”).
Metryki nieznormalizowane według natężenia ruchu/sezonowych szczytów.
Personifikacja i „oceny osób” bez uwzględnienia złożoności/warunków wejścia.
Brak uczciwego udziału → wypalenie i zwiększone błędy.
Zero korelacji z wydaniami/eksperymentami → fałszywe wnioski.
Dane bez kontroli WORM i bez polityki PII.

Wynik

Analiza przesunięć i wydajności to system pomiaru produkcji na szczycie ChatOps, ITSM i telemetrii: przezroczysta taksonomia KPI/KRI, prawidłowe modele danych, deski rozdzielcze dla różnych ról, metody statystyczne i powiązanie z efektem SLO/biznesowym. To podejście równoważy obciążenia, przyspiesza reakcję, zmniejsza wypalanie i przewidywalnie poprawia jakość operacji platformy iGaming.