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 je pomalý, selhává bez chybového hlášení, nebo jej dokáže provést jediný člověk, který zná ten skript
• Příčinu pomalého checkoutu z minulého týdne nelze dohledat, protože chybí logy i metriky
• Požadavky na compliance (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 revize nákladů: za co ve skutečnosti platíte.
• Incident response: runbooky, alerting bez falešných poplachů a post-mortemy, které se sepíšou a promítnou do oprav.
• Bezpečnostní základ. Správa secrets, dependency scanning, image signing, network policies a rutinní patche, které odstraňují známé zranitelnosti dříve, než je někdo zneužije.

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

Příklady incidentů

Vzorek z deseti let inženýrské práce v e-commerce, na kterých tato praxe stojí, anonymizovaně:

• 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 a přepracované VCL vrátily hit rate ze 4 % 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. Obnovili jsme ho ze snapshotů hypervizoru přes vynucené InnoDB recovery, přes skok 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. Sonda sledující tento invariant zachytí tuto třídu poruch ve chvíli, kdy error rate pořád vypadá normálně.

Jak spolupráce obvykle začíná

Velká část této práce je součástí jiné zakázky: audit vystopuje úzké hrdlo až k hostingu, nebo stavba potřebuje deploy pipeline dříve, než lze 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 s pevně stanovenými hodinami, za podmínek popsaných na Jak pracujeme.