Role zespołu infrastruktury
1) Cały obraz: dlaczego specjalizować
Przewidywalność i szybkość: jasne właściciele zmniejszają „szare obszary”.
Niezawodność i bezpieczeństwo: dystrybucja odpowiedzialności według domen (K8s, sieci, DB, bezpieczeństwo).
Ekonomia: FinOps oddziela wartość od konsumpcji i zarządza „ceną dziewięciu”.
Deweloper Experience: platforma jako produkt - samoobsługa, szablony, katalogi.
2) Kluczowe role i obowiązki
3) Granice odpowiedzialności (granice własności)
Platforma posiada poziom usług platformy L3-L7 (K8s, siatka, obserwowalność), ale nie logikę biznesową.
SRE jest właścicielem procesu niezawodności (SLO/incydenty/pośmiertne), a nie metryki każdego konkretnego zespołu produktów.
Wydanie/Dostawa posiada mechanikę obliczeń, ale odpowiedzialność za „to, co” jest rozłożone jest z poleceniami funkcji.
DBRE jest właścicielem klastrów/zasad dotyczących danych, a schemat/migracje są własnością zespołu produktów (zgodnie ze standardami DBRE).
SecOps jest właścicielem zasad i kontroli, a implementacja jest współdzielona z właścicielami domeny.
4) Modele operacyjne
1. Scentralizowana platforma - szybki start, ryzyko wąskiego gardła.
2. Platforma jako produkt (PaaP) - szablony samoobsługowe, katalogi, „rynek wewnętrzny” usług.
3. Federacja/gildie - eksperci są osadzani w domenach produktów (rozdział/osadzony SRE/DBRE).
4. Macierz - strategiczne standardy centrum + wykonanie w domenach.
Zalecenie: łączyć PaaP dla podstawowych potrzeb i osadzone dla domen krytycznych.
5) Interfejsy i OLA (umowy wewnętrzne)
Katalog usług: co jest dostępne „jako usługa” (K8s obszar nazw, klaster baz danych, kolejka, deska rozdzielcza SLO, profil alarmowy).
OLA (umowa o poziomie operacyjnym): daty reakcji, areny odpowiedzialności, punkty eskalacji.
Karty SLO usług platformowych: dostępność, opóźnienie API, czas wdrożenia z szablonu.
yaml service: "Kubernetes Namespace Provisioning"
owner: "Platform"
request_channel: "Service Catalog"
targets:
response_time: "≤ 15 min"
delivery_time: "≤ 1 hour (without manual approvals)"
scope:
includes: "quota, RBAC, secrets integration"
excludes: "business configs, database migrations"
escalation: "#plat-ops-oncall"6) RACI: kto robi co
Legenda: R - performs, A - replies, C - consulting, I - poinformowany.
7) KPI i wskaźniki wydajności według roli
Platforma: czas realizacji usług,% samoobsługi, DevEx NPS.
SRE: MTTR/MTTD, wykonanie SLO, pokrycie playbook, udział auto-mitigate.
CloudOps/NetOps: uptime obwodu, changey runtime, incydenty konfiguracyjne.
DBRE: RPO/RTO, sukces odzysku, opóźnienie replikacji p95.
Zwolnienie: procent wydań kanaryjskich, szybkość wałków, czas środowisk.
Obserwacja: kompletność sygnałów, czas reakcji żądań/desek rozdzielczych, wskaźnik antyhałasu.
SecOps: czas zamknięcia dla krytycznych CZ, incydentów bezpieczeństwa MTTD/MTTR, tajnego zasięgu menedżera.
FinOps: koszt za usługę/RPS, oszczędności prawowitych, prognoza dokładności.
8) Wejście na pokład i DevEx
Pakiet początkowy: szablony Terraform/Helm, rurociągi CI/CD, listy kontrolne „Hello, Service”.
Portal dokujący: standardy, przykłady, deski rozdzielcze „na żywo”, przyciski samoobsługowe.
Warsztaty/godziny pracy: według roli (SRE 101, SecOps 101, DBRE 101).
Polityka eskalacji: kto dzwonić w nocy i kiedy bilet wystarczy.
9) Granice własności i dostępu do danych
Ubezpieczenie IAM: właściciele ról, dostęp do życia, dostęp JIT (just-in-time).
Sekrety: scentralizowany tajny menedżer, rotacja, zakaz tajemnic W/repo.
Własność danych: produkt jest właścicielem schematu/danych domeny; DBRE jest właścicielem „statku” (klastry i zasady).
10) Procesy: incydenty, zmiany, wydania
Incydenty: IC/war-room/postmortem (patrz Incydenty i playbooks SRE).
Zarządzanie zmianą: oparty na ryzyku, szybki pas dla niskiego ryzyka, CAB tylko dla wysokiego ryzyka.
Wydania: progresywna dostawa, zamrażanie zasad podczas spalania błędów budżetowych.
11) Listy kontrolne według roli (wyciskanie)
Platforma
- Katalog usług i SLA dla każdej usługi platformy
- Szablony zasad IaC + (OPA/Conftest)
SRE
- Karty SLO górnych ścieżek, alerty spalania, playbooks
- Miesięczne błędne sprawozdanie budżetowe
DBRE
- Wiertarki DR, test odzysku, RPO/RTO podpisane
- Polityka w zakresie migracji i indeksowania
SecOps
- Triage luk i okien patch
- Kontrole DLP/PII, dostęp do audytu
Zwolnienie
- Domyślne kroki kanaryjskie, auto-rollback
- Flag funkcji i kill-switch
Obserwowalność
- Mierniki/standardy etykiet, deski rozdzielcze budżetu
- Anty-hałas (kworum, multi-window), widżety SLO
FinOps
- Obciążenie zwrotne/showback, rekomendacje dotyczące praw
- „Koszt na 9”, prognozowanie
12) Wzorce antyorganizacyjne
„DevOps to człowiek”: przeciążenie „generalistów”, brak właścicieli domen.
„Platforma = biuro biletów”: wszystkie poprzez bilety ręczne, bez samoobsługi.
„SRE = strażacy na służbie”: bez SLO i autorytetu.
„Security as stopcock”: późniejsze włączenie, zamiast „guardrails by design”.
„Obserwowalność = piękne wykresy”: bez aktywnych wpisów i SLO.
„FinOps tylko o raporcie”: bez zaleceń i auto-prawowitości.
13) Wzory artefaktów
Szablon karty serwisowej platformy
yaml service: "Managed PostgreSQL"
owner: "DBRE"
plan: "S, M, L"
slo:
availability: "99. 95 %/quarter"
rpo: "≤ 5 min"
rto: "≤ 15 min"
interfaces:
request: "Service Catalog → Postgres"
incidents: "#dbre-oncall"
changes: "Change Policy L2"
security:
secrets: "Vault"
access: "JIT/RBAC"
finops:
pricing: "по vCPU/GB/IOPS"
limits: "quota per tenant"Mini RACI dla wydań
yaml release:
strategy: canary
R: Release/Delivery
A: Product Owner
C: SRE, SecOps
I: Platform14) Plan realizacji (4 iteracje)
1. Standaryzacja (2-3 tygodnie): mapa ról, katalog usług, RACI, OLAs, kanały eskalacji.
2. DevEx (3-4 tygodnie): katalog serwisowy, szablony CI/CD, moduły Terraform, podstawowe tablice SLO/deski rozdzielcze.
3. Niezawodność i bezpieczeństwo (4-6 tygodni): odtwarzacze incydentów, wiertarki DR, WAF/DLP, tajny menedżer.
4. FinOps i optymalizacja (ciągła): obciążenie zwrotne, sprawiedliwość, „koszt na 9”, automatyczne zasady.
15) Mini-FAQ
Gdzie przechowywać SRE - na platformie lub w produktach?
Hybrid: strategiczny SRE w platformie, osadzony-SRE w krytycznych domenach.
Kto jest właścicielem usług SLO?
Zespoły produktów. SRE zapewnia metodologię, oprzyrządowanie i kontrolę procesu.
Jak uniknąć „shadow IT”?
Katalog usług, wyraźne OLAs, szybka samoobsługa i przejrzyste ceny (showback/chargeback).
Razem
Silną funkcją infrastruktury są wyraźne role + podejście produktowe do platformy + porozumienia w sprawie interfejsów i mierników. Przechwycić RACI i OLAs, dać samoobsługę i standardy, zmierzyć wydajność z KPI każdej roli, i regularnie poprawić DevEx, SLO, i koszty. Zmniejszy to ryzyko operacyjne, przyspieszy uwolnienia i sprawi, że infrastruktura będzie przewidywalna.