Hostingové horory: Proč záleží, kde běží vaše appka

Infrastruktura je neviditelná -- dokud se nerozbije. A pak je to jediné, co vidíte. A vaši zákazníci taky.
Za léta vývoje webových a mobilních aplikací jsme narazili na hostingová řešení, která by nás překvapila, kdyby nás po těch letech ještě něco překvapovalo. Od serverů, které fyzicky zmizely, po hostingy, které zmizely finančně. Tady je pár příběhů, které nás naučily, že infrastruktura opravdu není místo, kde se šetří.
- ✗Aplikace na notebooku vývojáře
- ✗Sdílený hosting za 50 Kč bez garantovaných zdrojů
- ✗Produkční databáze na free tier cloudové služby
- ✗FTP deploy bez verzování a rollbacku
- ✗Zálohy na stejném serveru jako produkce
- ✗Žádný monitoring — o výpadku se dozvíte od zákazníků
- ✓Spolehlivý hosting s garantovanou dostupností (SLA)
- ✓Automatické denní zálohy na odděleném úložišti
- ✓Deployment pipeline s rollback možností
- ✓Monitoring dostupnosti a alerting
- ✓Izolované prostředí (VPS nebo kontejnery)
- ✓Staging prostředí pro testování před nasazením
Notebook pod stolem
Tohle je příběh, kterému byste nevěřili, kdyby nebyl pravdivý. Převzali jsme projekt od malé agentury -- interní firemní systém pro správu zakázek. Fungoval spolehlivě. Až jednoho dne v srpnu přestal.
Začali jsme pátrat. DNS ukazovalo na IP adresu, která neodpovídala žádnému známému hosting provideru. Po sérii telefonátů jsme zjistili pravdu: aplikace běžela na starém notebooku vývojáře. Na jeho pracovním stole. V kanceláři.
Vývojář odjel na dovolenou do Chorvatska. Při odchodu z kanceláře zavadil o napájecí kabel. Notebook se vybil. Aplikace spadla. A protože vývojář byl jediný, kdo o tom serveru věděl (a měl heslo), nikdo ji nemohl restartovat.
Dva týdny bez interního systému, protože někdo chtěl ušetřit za hosting. Měsíční náklady na skutečný server by byly zlomek toho, co ta dvoutýdenní odstávka stála na ztracené produktivitě.
Chcete to nejlepší? Notebook nebyl ani zálohovaný. Kdyby se rozbil pevný disk místo vybití baterie, data by byla pryč navždy.
"Neomezený hosting" za padesát korun
Klient spustil e-shop. Vybral hosting, protože byl nejlevnější -- padesát korun měsíčně s příslibem "neomezeného prostoru a přenosu". Znělo to skvěle. Měsíc šlo všechno hladce.
Pak spustil marketingovou kampaň. Reklamy na sociálních sítích, newsletter, slevová akce. Traffic stoupl na sto současných uživatelů. A web spadl.
Kontaktoval hosting. Odpověď: "Váš tarif je optimalizovaný pro menší projekty. Pro vyšší zátěž doporučujeme přejít na business tarif." Business tarif: tisíc korun měsíčně. Pořád levný. Přešel na něj. Při dvou stech uživatelích spadl znovu.
"Neomezený" se ukázal být omezenější, než klient čekal. V podmínkách služby, které nikdo nečte, stálo: sdílený hosting, maximálně 10% CPU jednoho jádra, 256 MB RAM na účet, 20 současných databázových spojení. Pro statické stránky adekvátní. Pro e-shop s dynamickým obsahem, vyhledáváním a košíkem naprosto nedostatečné.
Klient přišel za námi v pátek večer s tím, že mu nejede e-shop uprostřed kampaně. Migraci na slušný VPS jsme řešili přes víkend. Kampaň mezitím běžela dál a posílala lidi na nefunkční web. Peníze za reklamu šly do ztracena.
Hosting, který zkrachoval přes noc
Malý český hosting provider. Nízké ceny, příjemná podpora, funkční služby. Klient u nich hostoval web i databázi tři roky bez problémů.
Jednoho rána web přestal fungovat. Telefonní číslo hosting providera neexistovalo. Web providera byl offline. E-maily se vracely. Po dvou dnech pátrání jsme zjistili, že firma ukončila činnost. Ze dne na den. Bez upozornění zákazníků. Servery vypnuté.
Klientova data? Na těch vypnutých serverech. Zálohy? Klient je měl. Poslední záloha byla stará čtyři měsíce. Čtyři měsíce dat -- objednávek, zákaznických účtů, změn v obsahu -- pryč.
Obnovili jsme web ze zálohy na novém hostingu za den. Ale ty čtyři měsíce dat nikdo nevrátí. A klient se naučil dvě lekce naráz: dělat zálohy pravidelně a nespoléhat na jednoho malého providera bez jakýchkoli garancí.
Jeden za všechny, všichni za jednoho (v tom špatném smyslu)
Sdílený hosting. Desítky webů na jednom serveru. Efektivní, levné, a většinou v pořádku. Většinou.
Klient měl na sdíleném hostingu firemní web. Nic velkého, nic náročného. Jednoho dne mu Google Chrome začal zobrazovat varování: "Tato stránka může poškodit váš počítač." Web byl na blacklistu.
Příčina? Úplně jiný web na stejném serveru měl bezpečnostní díru ve WordPressu. Útočníci přes ni získali přístup na server a infikovali všechny weby na něm. Včetně klientova naprosto nevinného webu.
Odstranění malwaru, skenování, podání žádosti o review u Googlu, čekání na stažení varování -- celý proces trval dva týdny. Dva týdny, kdy každý návštěvník webu viděl červenou stránku s varováním. Kolik potenciálních zákazníků to odradilo, se dá jen odhadovat.
Klient neudělal nic špatně. Jeho web byl čistý, aktualizovaný, zabezpečený. Ale sdílel server s někým, kdo zabezpečený nebyl.
FTP a nic jiného
Aplikace nasazená přes FTP. Vývojář nahraje soubory, přepíše produkci, hotovo. Žádné staging prostředí. Žádné testování před nasazením. Žádný rollback. Žádná verzovací kontrola na serveru.
Jednoho dne vývojář nahrál špatnou verzi. S chybou, která rozbila platební proces. Zjistilo se to po šesti hodinách, protože nikdo nemonitoroval produkci. A protože neexistoval rollback, musel vývojář chybu opravit, otestovat lokálně (snad) a znovu nahrát přes FTP.
Celkem: šest hodin nefunkčních plateb a dalších pět hodin na opravu a nasazení. Jedenáct hodin, kdy e-shop nemohl zpracovat ani jednu objednávku.
S moderním deployment pipeline by rollback na předchozí verzi trval minuty. Ale FTP deployment žádný rollback neumožňuje. Jakmile přepíšete soubory, předchozí verze neexistuje.
Databáze s expirační lhůtou
Startup, který chtěl ušetřit na všem. Produkční databáze na free tier cloudové služby. Free tier, který měl podmínku: po třiceti dnech neaktivity se databáze automaticky smaže.
"Neaktivita" v tomto případě neznamenala žádné uživatele. Znamenala žádné připojení z administračního panelu poskytovatele. Aplikace se k databázi připojovala normálně a zápisy probíhaly. Ale poskytovatel vyhodnotil účet jako neaktivní na základě jiného kritéria.
Po třiceti dnech přišel e-mail s upozorněním. Spadl do spamu. Po dalších sedmi dnech: databáze smazána. Produkční data, uživatelské účty, historie transakcí -- všechno.
Zálohy? Na tom samém free tier. Smazané společně s databází.
Nastavte si automatické denní zálohy na oddělené úložiště a pravidelně (alespoň jednou za měsíc) testujte obnovu ze zálohy. Záloha, kterou jste nikdy nezkusili obnovit, není záloha -- je to naděje. Navíc si nastavte základní monitoring (např. UptimeRobot zdarma), abyste o výpadku věděli dřív než vaši zákazníci.
Poučení: Infrastruktura není místo pro úspory
Všechny tyhle příběhy spojuje jedna věc: snaha ušetřit na infrastruktuře. A ve všech případech ta "úspora" nakonec stála mnohonásobně víc, než by stálo slušné řešení od začátku.
Co by měl mít každý projekt na minimu:
Spolehlivý hosting s garantovanou dostupností a podporou. Ne nejlevnější, ne nejdražší. Přiměřený velikosti a náročnosti projektu.
Automatické zálohy na jiném místě, než běží produkce. Denně. Testované. Protože záloha, kterou jste nikdy nezkusili obnovit, není záloha -- je to naděje.
Deployment pipeline s rollback možností. Nemusí to být nic složitého. Git, staging prostředí a automatizovaný deploy zvládne i jednoduché řešení.
Monitoring. Alespoň základní -- vím, že web běží, vím, že odpovídá. Protože zjistit o výpadku z e-mailu zákazníka po šesti hodinách není monitoring.
A izolace. Váš projekt by měl běžet ve svém prostředí, kde ho nemůže ovlivnit bezpečnostní díra sousedního webu.
Infrastruktura je základ, na kterém stojí všechno ostatní. Bez stabilního základu je jedno, jak krásný je design nebo jak chytrý je kód. Když server neběží, neběží nic.


