DevOps a infrastruktura

Navrhujeme a provozujeme infrastrukturu, na které běží e-shopy, a to bez Kubernetes clusteru, jehož správa by vyžadovala dedikovaného seniorního SRE.

Typické výchozí situace

• E-shop běží na jednom VPS a při každé slevové akci nebo startu kampaně dojde k výpadku
• Deploy trvá 40 minut, selhává bez chybového hlášení, nebo jej dokáže provést jediný člověk
• Příčinu pomalého checkoutu z minulého týdne nelze dohledat, protože chybí logy i metriky
• Compliance požadavky (PCI, GDPR audit trail) vyžadují doložitelné odpovědi
• Zakladatel nebo CTO plní roli on-call inženýra, včetně nočních zásahů během špiček typu Black Friday

Co děláme

• Cloud a edge infrastruktura. Cloudflare, AWS, GCP, Hetzner nebo bare metal; stack vybíráme podle workloadu.
• CI/CD pipeline na GitHub Actions nebo GitLab CI, s reprodukovatelnými buildy, vratnými deployi a secrets, které neleží v repu.
• Observabilita: logy, metriky a traces přes Grafanu, OpenTelemetry, Sentry nebo Cloudflare Logpush. Na otázku „co se stalo minulé úterý ve 14:32“ byste měli umět odpovědět do minuty.
• Výkon a náklady. Edge caching, image CDN, autoscaling vyladěný na špičky kampaní a cost review, které často zaplatí celou spolupráci.
• Incident response: runbooky, alerting bez falešných poplachů a post-mortem proces, který z nočního incidentu udělá opravu nasazenou následující týden.
• Bezpečnostní základ. Správa secrets, dependency scanning, image signing, network policies a rutinní patche, které odstraňují známé zranitelnosti dřív, než je někdo zneužije.

Výchozí volbou je u nás nejjednodušší infrastruktura, která splní požadavky.

Incidenty, které jsme řešili

Vzorek z produkčních systémů, které jsme v minulých letech provozovali:

• Grafy paměti zůstávaly ploché, zatímco aplikaci unikala paměť: agent pro metriky totiž sledoval procesního manažera, a ne aplikaci, kterou spouštěl. Diagnóza vedla přes rozbor stromu procesů a čtení zdrojového kódu agenta; opravou byl malý init wrapper, který navíc zajistil korektní ukončování procesů.
• Opakované výpadky do „maintenance mode“, za kterými ve skutečnosti byla cache vrstva, které docházela transientní paměť. Zhoršoval to automaticky aktualizovaný „stable“ tag image, který bez vědomí provozovatele měnil nasazený software. Připnuté verze, přepracované VCL a hit rate se ze 4 % dostal na standardní hodnoty.
• CI agenty ukončoval OOM killer uprostřed jobu, což bez jakéhokoli hlášení zablokovalo stavový automat indexerů e-shopu a zastavilo aktualizace skladu. Selhání jsme na stagingu záměrně zreprodukovali a vrstvu plánovaných úloh přestavěli s izolací po skupinách a samoopravnými resety.
• Frontendová cache celé jedné země se nedala invalidovat kvůli překlepu v jediném slově namespace v seznamu purge hostů. Okamžitou nápravu zajistily ruční cache bany, trvalou pak oprava konfigurace.
• Klientské prostředí někdo omylem smazal a logické zálohy neexistovaly. Vrátili jsme ho ze snapshotů hypervizoru přes vynucené InnoDB recovery, napříč skokem o hlavní verzi MySQL.

Společný princip: alerty nastavujeme na byznysové invarianty, třeba „každá objednávka je do 15 minut v ERP“, nejen na error rate. Několik z incidentů výše zachytila přesně taková sonda dřív, než dopad zaznamenal první zákazník.

Jak spolupráce obvykle začíná

Velká část této práce přichází uvnitř jiné zakázky: audit dosleduje úzké hrdlo až k hostingu, nebo stavba potřebuje deploy pipeline dřív, než jde cokoli nasadit. U samostatné infrastrukturní práce začínáme krátkou revizí toho, co kde běží, kolik to stojí a co pod zátěží selže jako první; doporučené změny pak dostanete písemně s pevnou cenou. Průběžný provoz běží jako měsíční paušál se jmenovitě určenými hodinami, za podmínek popsaných na Jak pracujeme.