Noční incident v produkci: stabilizace monolitu a koordinace týmu
Noční pagerový signál „PROD: vše červené“ mě vytrhl ze spánku. Příjezd do místnosti pro řešení incidentů: SRE mantry — stabilizovat, analyzovat, post mortem. Tým si rozdělil role: koordinace, komunikace, databáze, monitorování metrik a logů. Cíl — najít kořen problému pod vrstvami legacy kódu.
Stakeholderům přišlo první hlášení: „Služba není dostupná. Tým pracuje. Aktualizace za 15 minut“. Monitorování ukázalo všechny metriky v červené, kromě jediné zelené tečky. Logy plné chyb timeout při volání monolitu, přezdívaného „drak“.
Diagnostika: od front zpráv k databázi
Metrika front zpráv rostla exponenciálně, konzumenti padali kvůli timeoutům. Příčina — pomalé dotazy k DB. Příklad problematického dotazu:
SELECT * FROM users WHERE some_condition ORDER BY created_at LIMIT 1000;
-- Bez indexu na some_condition a created_at, na 10M+ řádcích — katastrofa.DBA odhalil chybějící indexy a N+1 problémy v nové službě. Legacy architekt potvrdil: monolit drží globální stav, není navržen pro paralelizaci bez refaktoringu.
Návrh urgentní migrace na Kubernetes zamítli: v krizi by to přidalo složitost, neřeší kořen problému.
Bezpečnostní inkvizice a kompromis
Žádost o dočasný přístup pro omezení provozu a rollback funkce zablokovala security. Threat model vyžaduje schválení rizik. Kompromis: hodinový přístup s logováním a reportem.
Akce:
- Omezení provozu rate limitingem.
- Rollback nové funkce přes feature flag.
- Monitorování obnovy: červené → růžové → šedé → stabilní.
Stakeholderové aktualizováni: „Stabilizováno. Analýza pokračuje. Aktualizace za 30 minut“.
Lokalizace a lekce z incidentu
Incident lokalizován: front ucpaný, DB zatížená neoptimalizovanými dotazy z nové služby. Monolit stabilní na řetězu, ale potřebuje systémový přístup.
Zásah OKR manažera: plány zdvojnásobit releasy, „vše přepsat“ a Kubernetes. Riziko: soustředění na velké projekty místo inkrementálních vylepšení.
Co je důležité:
- Kořen problému v neoptimalizovaných dotazech a frontech, ne v monolitu samotném.
- Role v incidentním týmu jsou klíčové: koordinace, komunikace, expertiza.
- Bezpečnostní kompromisy možné s dočasnými opatřeními a auditem.
- Vyhnout se unáhleným migracím v krizi; soustředit se na stabilizaci.
- Post mortem ukáže roadmap: indexy, feature flag, postupný refaktoring.
Celkový objem práce týmu — 2 hodiny do stabilizace. Pokračování: post mortem a plán.
— Editorial Team
Zatím žádné komentáře.