DevOps a infraštruktúra

Navrhujeme a prevádzkujeme infraštruktúru, na ktorej bežia e-shopy, a to bez Kubernetes clusteru, ktorého prevádzka by vyžadovala senior SRE na plný úväzok.

Kedy je táto služba vhodná

• E-shop beží na jednom VPS a pri každej akcii alebo spustení kampane dôjde k výpadku
• Deploy je pomalý, zlyháva bez chybového hlásenia alebo ho vie spustiť len jediný člen tímu, ktorý pozná ten skript
• Nikto nevie zistiť, prečo bola pokladňa minulý štvrtok pomalá, lebo neexistujú logy ani metriky
• Požiadavky na compliance (PCI, GDPR audit trail) si zrazu žiadajú zdokumentované odpovede
• Zakladateľ alebo CTO je de facto on-call inžinier a každý Black Friday trávi v pohotovosti

Čo robíme

• Cloudová a edge infraštruktúra. Cloudflare, AWS, GCP, Hetzner alebo bare metal; stack vyberáme podľa workloadu.
• CI/CD pipeline na GitHub Actions alebo GitLab CI, s reprodukovateľnými buildmi, reverzibilnými deploymi a secrets, ktoré nie sú v repe.
• Observabilita: logy, metriky a traces cez Grafanu, OpenTelemetry, Sentry alebo Cloudflare Logpush. Na otázku „čo sa stalo o 14:32 minulý utorok“ by ste mali vedieť odpovedať do minúty.
• Výkon a náklady. Edge caching, image CDN, autoscaling vyladený na špičky kampaní a revízia nákladov: za čo v skutočnosti platíte.
• Incident response: runbooky, alerting bez falošných poplachov a post-mortemy, ktoré sa spíšu a premietnu do opráv.
• Bezpečnostný základ. Správa secrets, dependency scanning, image signing, network policies a pravidelné patche, ktoré držia známe zraniteľnosti mimo vášho e-shopu.

Východiskom je pre nás vždy najjednoduchšia infraštruktúra, s akou sa dajú požiadavky splniť.

Príklady incidentov

Vzorka z desiatich rokov inžinierskej práce v e-commerce, na ktorých táto prax stojí, anonymizovane:

• Dashboardy pamäte zostávali ploché, zatiaľ čo aplikácii unikala pamäť, pretože agent na metriky sledoval process manager namiesto aplikácie, ktorú spúšťal. Diagnostikované forenznou analýzou stromu procesov a čítaním zdrojového kódu agenta; opravené malým init wrapperom, vďaka ktorému sú odvtedy čisté aj shutdowny.
• Opakované výpadky do „maintenance mode“, za ktorými v skutočnosti bola cache vrstva, ktorej dochádzala transient pamäť; situáciu zhoršoval „stable“ image tag, ktorý sa sám aktualizoval a bez upozornenia menil nasadený softvér. Pripli sme verzie, prepracovali VCL a hit rate stúpol zo 4 % na zdravé hodnoty.
• CI agentov ukončoval OOM killer uprostred úlohy, čo bez chybového hlásenia zablokovalo stavový automat indexerov e-shopu a zastavilo aktualizácie zásob. Zlyhanie sme najprv zámerne zreprodukovali na stagingu a potom prestavali vrstvu plánovaných úloh s izoláciou po skupinách a self-healing resetmi.
• Frontendová cache celej jednej krajiny sa nedala invalidovať kvôli preklepu v jednom slove namespace v zozname purge hostov. Naživo opravené ručnými cache banmi, natrvalo potom v konfigurácii.
• Klientske prostredie niekto omylom zmazal a logické zálohy neexistovali. Vrátili sme ho zo snapshotov hypervízora cez vynútené InnoDB recovery, a to naprieč skokom o hlavnú verziu MySQL.

Zásada, ktorá za tým stojí: alerty na biznisové invarianty, napríklad „každá objednávka je do 15 minút v ERP“, nielen na chybovosť. Sonda sledujúca tento invariant zachytí túto triedu porúch vo chvíli, keď chybovosť stále vyzerá normálne.

Ako zákazka zvyčajne začína

Veľká časť tejto práce je súčasťou inej zákazky: audit, ktorý vystopuje úzke hrdlo až k hostingu, alebo projekt, ktorý potrebuje deploy pipeline skôr, než sa dá čokoľvek dodať. Pri samostatnej infraštruktúrnej práci začíname krátkou revíziou toho, čo kde beží, koľko to stojí a čo pod záťažou zlyhá ako prvé, a odporúčané zmeny dáme písomne s fixnou cenou. Priebežná prevádzka beží ako mesačný paušál s pevne stanovenými hodinami, za podmienok opísaných na stránke Ako pracujeme.