Analityka operacyjna
1) Co to jest analityka operacyjna i dlaczego jest ona potrzebna
Operational Analytics (Ops Analytics) to system montażu sygnałów z obserwowalności (mierniki/dzienniki/szlaki), ITSM (incydenty/problemy/zmiany), CI/CD (wersje/konfiguracje), dostawców (PSP/KYC/CDN/Cloud), FSP inOps (koszty) i business SLS I (sukces płatności, rejestracja), przekształcone w pojedyncze okna i deski rozdzielcze do podejmowania decyzji.
Cele:- zmniejszyć MTTD/MTTR poprzez wczesne wykrywanie i prawidłowe przypisywanie przyczyn;
- utrzymywanie pod kontrolą SLO i budżetów na błędy;
- Link zmiany → impact (releases/configs → SLI/SLO/reklamacje/koszty)
- dać samoobsługowe analizy zespołom i kierownictwu.
2) Źródła i kanoniczna warstwa danych
Telemetria: mierniki (SLI/zasoby), dzienniki (sampling/PII edition), ścieżki (trace_id/span_id, znaczniki wydania).
Moduły ITSM/Incydent: SEV, T0/Detected/Ack/Declared/Mitigated/Recovered znaczniki czasowe, RCA/CAPA.
CI/CD & Config: wersje, commits, canarics/blue-green, stan flagi, konfiguracje docelowe.
Dostawcy: statusy/SLA, opóźnienia, kody błędów, wagi trasy.
FinOps: koszt według tagów/kont/najemców, $/unit (1k operas.) .
• Ops: świeżość okna, błędy DQ, rodowód.
Kluczową zasadą jest pojedyncza korelacja poprzez identyfikatory: 'service', 'region', 'lokator', 'release _ id',' change _ id', 'incident _ id',' provider ',' trace _ id'.
3) Jednolity model danych (uproszczone ramy)
dim_service(service_id, owner, tier, slo_targets…)
dim_time(ts, date, hour, tz)
dim_region(region_id, country, cloud)
dim_provider(provider_id, type, sla)
fact_sli(ts, service_id, region_id, tenant, metric, value, target, window)
fact_incident(incident_id, service_id, sev, t0, t_detected, t_ack, t_declared, t_mitigated, t_recovered, root_cause, trigger_id, burn_minutes)
fact_change(change_id, type(code config infra), service_id, region_id, started_at, finished_at, canary_pct, outcome(ok rollback), annotations)
fact_cost(ts, service_id, region_id, tenant, cost_total, cost_per_1k)
fact_provider(ts, provider_id, region_id, metric(latency error status), value)
fact_dq(ts, dataset, freshness_min, dq_errors)4) SLI/SLO i wskaźniki biznesowe
Мибне,-SLI: 'payment _ success _ ratio', 'signup _ completion', 'deposit _ latency'.
Теz-SLI: 'dostępność', 'http _ p95', 'error _ rate', 'queue _ depth'.
Warstwa SLO: cele + szybkość spalania (krótkie/długie okno), automatyczne adnotacje naruszeń.
Normalizacja: wskaźniki na 1k udanych operacji/użytkowników/ruchu.
5) Korelacje i przypisywanie przyczyn
Wersje/konfiguracyjneSLI/SLO: adnotacje na wykresach; raporty o przyczynach i skutkach (odsetek incydentów związanych ze zmianą; Incydenty zmiany MTTR).
Podmioty świadczące usługi SLI: wagi tras w stosunku do opóźnień/błędów, wkład każdego dostawcy w miss SLO.
Pojemność/zasoby • opóźnienie - przegrzanie basenu → wzrost p95 → wpływ konwersji.
6) Anomalie i prognozowanie
Wykrywanie anomalii: sezonowość + progi percentylowe + funkcje wyszukiwania zmian (przed/po zwolnieniu).
Prognoza: tygodniowe/sezonowe schematy obciążeń, prognoza budżetu błędów spalonych, prognoza kosztów ($/jednostka).
Gardrails: alerty tylko wtedy, gdy źródła kworum (syntetyczne + RUM + business SLI).
7) Prezentacje i deski rozdzielcze (odniesienie)
1. Executive 28d: SEV mix, mediana MTTR/MTTD, SLO adherence, $/unit, top reasons.
2. SRE Ops: SLI/SLO + szybkość spalania, burza strony, aktywny%, zmiana wskaźnika awarii.
3. Zmień wpływ: zwalnia/konfiguruje SLI/SLO/reklamacje, rolki i ich efekt.
4. Dostawcy: linie statusu PSP/KYC/CDN, wpływ na SLI biznesowe, czas odpowiedzi.
5. FinOps: koszt za 1k txn, kłody/wyjście, anomalie kosztowe, zalecenia (pobieranie próbek, przechowywanie).
6. • Ops: świeżość okna, błędy DQ, SLA rurociągu, sukces zasypki.
8) Jakość danych i zarządzanie nimi
Umowy dotyczące zdarzeń: jasne schematy dotyczące incydentów/zwolnień/SLIs (obowiązkowe pola, jednolite strefy czasowe).
Kontrolery DQ: kompletność, wyjątkowość klawiszy, spójność linii czasowej (t0 ≤ wykryte ≤ ack...).
Rodowód: deska rozdzielcza do źródła (identyfikowalna).
PII/tajemnice: edycja/maskowanie według zasad; WORM dla dowodów.
Świeżość SLA: Operacje prezentują ≤ 5 min opóźnienia.
9) Metryki dojrzałości analizy operacyjnej
Zasięg:% usług krytycznych w sklepach i tablicach SLO (cel ≥ 95%).
Świeżość: udział widżetów o świeżości ≤ 5 minut (cel ≥ 95%).
Aktywność:% przejście od deski rozdzielczej do akcji (playbook/SOP/bilet) ≥ 90%.
Zasięg wykrywania: ≥ 85% incydentów wykrywanych jest przez automatyzację.
Wskaźnik przypisania: odsetek incydentów z potwierdzoną przyczyną i spustem ≥ 90%.
Zmiana wpływu: udział incydentów związanych ze zmianami (kontrolowanie trendu).
Jakość danych: Błędy DQ/tydzień → QoQ
10) Proces: od danych do działania
1. Kolekcja → czyszczenie → normalizacja obudowy wyświetlacza → (ETL/ELT, warstwa funkcji dla ML).
2. Matrix Detection/Forecast → Eskalacja (IC/P1/P2/Comms).
3. Akcja: playbook/SOP, brama, flaga funkcji, przełącznik dostawcy.
4. Dowody i AAR/RCA: linia czasu, wykresy, linki do wydań/dzienników/utworów.
5. CAPA i rozwiązania produktowe: priorytetyzacja przez minuty spalania i $ impact.
11) Przykłady zapytań (pomysł)
11. 1 Wpływ uwolnień na SLO (24h)
sql
SELECT r. change_id,
COUNT(i. incident_id) AS incidents,
SUM(i. burn_minutes) AS burn_total_min,
AVG(CASE WHEN i.root_cause='code' THEN 1 ELSE 0 END) AS code_ratio
FROM fact_change r
LEFT JOIN fact_incident i
ON i.trigger_id = r. change_id
WHERE r. started_at >= NOW() - INTERVAL '24 hours'
GROUP BY 1
ORDER BY burn_total_min DESC;11. 2 Udział problemów ze strony dostawców w podziale na regiony
sql
SELECT region_id, provider_id,
SUM(CASE WHEN root_cause='provider' THEN 1 ELSE 0 END) AS prov_inc,
COUNT() AS all_inc,
100. 0SUM(CASE WHEN root_cause='provider' THEN 1 ELSE 0 END)/COUNT() AS pct
FROM fact_incident
WHERE t0 >= DATE_TRUNC('month', NOW())
GROUP BY 1,2
ORDER BY pct DESC;11. 3 Koszt na 1k udanych płatności
sql
SELECT date(ts) d,
SUM(cost_total)/NULLIF(SUM(success_payments)/1000. 0,0) AS cost_per_1k
FROM fact_cost c
JOIN biz_payments b USING (ts, service_id, region_id, tenant)
GROUP BY d ORDER BY d DESC;12) Wzory artefaktów
12. 1 Schemat zdarzeń incydentalnych (JSON, fragment)
json
{
"incident_id": "2025-11-01-042",
"service": "payments-api",
"region": "eu",
"sev": "SEV-1",
"t0": "2025-11-01T12:04:00Z",
"detected": "2025-11-01T12:07:00Z",
"ack": "2025-11-01T12:09:00Z",
"declared": "2025-11-01T12:11:00Z",
"mitigated": "2025-11-01T12:24:00Z",
"recovered": "2025-11-01T12:48:00Z",
"root_cause": "provider",
"trigger_id": "chg-7842",
"burn_minutes": 18
}12. 2 Katalog metryk (YAML, fragment)
yaml metric: biz. payment_success_ratio owner: team-payments type: sli target: 99. 5 windows: ["5m","1h","6h","28d"]
tags: [tier0, region:eu]
pii: false12. 3 Karta sprawozdania wykonawczego (sekcje)
1) SEV mix and MTTR/MTTD trends
2) SLO adherence and burn-out risks
3) Change Impact (CFR)
4) Providers: Degradation and switchover
5) FinOps: $/unit, log anomalies/egress
6) CAPAs: Status and Deadlines13) Narzędzia i wzory architektoniczne
Data Lake + DWH: warstwa „surowa” do telemetrii, prezentacja rozwiązań.
Przetwarzanie strumieniowe: szybkość SLI/spalania w czasie zbliżonym do rzeczywistego, funkcje online dla anomalii.
Funkcja Sklep: ponowne wykorzystanie funkcji (kanarka, sezonowość, sygnały dostawcy).
Warstwa semantyczna/sklep metryczny: jednolite definicje metryczne (SLO, MTTR...).
Kontrola dostępu: RBAC/ABAC, bezpieczeństwo na poziomie wiersza dla najemców/regionów.
Katalog/Lineage: wyszukiwanie, opisy, zależności, właściciele.
14) Listy kontrolne
14. 1 Uruchomienie analityki operacyjnej
- Zatwierdzone słowniki SLI/SLO, SEV, powody, rodzaje zmian.
- Schematy wydarzeń i jednolite strefy czasowe.
- Złącza telemetryczne, ITSM, CI/CD, dostawcy, rozliczenia.
- Prezentacje: SLI/SLO, Incydenty, Zmiany, Dostawcy, FinOps.
- Dostępne są deski kontrolne/SRE/Change/Providers.
- Alerty kworum i tłumienie są konfigurowane w oknach konserwacji.
14. 2 Tygodniowy przegląd operacyjny
- Trendy SEV, MTTR/MTTD, SLO brakuje, spalić minuty.
- Zmiana wpływu i CFR, status zwrotu.
- Incydenty i czas reakcji dostawcy.
- FinOps: $/unit, log anomalies/egress.
- Status CAPA, przestępstwa, priorytety.
15) Anty-wzory
„Ściana wykresów” bez działania.
Różne definicje mierników dla poleceń (brak warstwy semantycznej).
Brak adnotacji o zwolnieniu/oknie - słabe przypisywanie przyczyn.
Orientacja średnia zamiast p95/p99.
Nie ma normalizacji dla głośności - duże usługi „wydają się gorsze”.
PII w dziennikach/sklepach, zaburzenia retencji.
Dane „stagnuje” (> 5-10 min dla widżetów w czasie rzeczywistym).
16) Plan działania na rzecz realizacji (4-8 tygodni)
1. Ned. 1: porozumienia w sprawie słownika metryk, programów imprez, id-korelacji; Połączenie SLI/SLO i ITSM.
2. Ned. 2: Incydenty/Zmiany/Dostawcy prezentuje, adnotacje wydania; Deski rozdzielcze Executive & SRE.
3. Ned. 3: warstwa FinOps ($/jednostka), więzadło z SLI; wykrywanie anomalii za pomocą kworum.
4. Ned. 4: samoobsługa (warstwa semantyczna/sklep metryczny), katalog i rodowód.
5. Ned. 5-6: prognoza obciążenia/kosztów, raporty dla dostawców, prezentacja CAPA.
6. Ned. 7-8: zasięg ≥ 95% Tier-0/1, świeżość SLA ≤ 5 min, regularne opinie Ops.
17) Sedno sprawy
Analityka operacyjna to maszyna do podejmowania decyzji: jednolite definicje mierników, świeże sklepy, prawidłowe przypisywanie przyczyn oraz bezpośrednie przejścia do odtwarzaczy i SOP. W takim systemie zespół szybko wykrywa i wyjaśnia odchylenia, dokładnie ocenia wpływ zwolnień i dostawców, zarządza kosztami i systematycznie zmniejsza ryzyko - a użytkownicy otrzymują stabilną usługę.