Provozujeme internetové aplikace bezpečně a dlouhodobě udržitelně
Vyvinutím a spuštěním internetové služby práce nekončí, ani zdaleka. Kromě nezbytných úprav a rozvoje jsou s vlastnictvím a provozováním takové služby spojené další náklady, práce a zodpovědnost. V článku nabízíme takový „checklist“ dlouhodobě udržitelného a bezpečného provozování internetových služeb.
V praxi se znovu a znovu setkáváme se zákazníky, kteří nechápou dvě hlavní věci nezbytné k provozování internetových aplikací bezpečně a dlouhodobě udržitelně:
- vyvarování se vendor locku, a to jak u sw, tak případně u hw
- že smlouvy, smluvní garance a pokuty nic neřeší (když přijdu o data teď, nezajímá mě až tak moc, jestli vysoudím náhradu škody za 3 roky)
Několik našich klientů např. poslalo svůj web do pekel tím, že si koupili web s líbivým CMS od nějaké české firmy a neuvědomili si, jak je ta firma za pár let začne, třeba i neúmyslně a nechtěně, omezovat a jak bude případně pracné se této závislosti zbavit a migrovat na jiné řešení.
Je dobré si proto uvědomit některé základní principy, kterými je třeba se řídit, pokud chceme, aby naše webová prezentace či aplikace byla dlouhodobě funkční, co nejvíc dostupná a bezpečně provozovaná.
Software a data
Právní vztah ke zdrojovým kódům aplikace
Licence, pod kterou vám autor umožní dílo užívat, by měla zejména umožňovat zásahy do díla vámi nebo jinou stranou, a také by měla umožňovat dílo šířit dále. Mnoho uzavřených licencí např. neumožňuje vytvořit více než dvě kopie – hlavní provozní a zálohu.Taková licence je příliš svazující.
Obecně se doporučuje přijmout dílo pod licencí GPL, BSD, MIT nebo některými z licencí Creative Commons (BY nebo BY-SA).
Umístění zdrojových kódů aplikace
Zdrojové kódy byste měli mít k dispozici v jakýkoliv okamžik. Bez ohledu na to, zda máte zdrojové kódy na svém serveru, na githubu nebo na serveru autora aplikace, měli byste mít vlastní zálohu (včetně historie).
Dostupnost vývojářů pro danou platformu
Ověřte si, že vždy dokážete sehnat vývojáře, který se orientuje v platformě, na které je váš systém postaven. Ověřte to zadáním reálné zakázky malého rozsahu, kterou zadáte jiné společnosti, než kdo je autorem.
Zálohování
Mějte vždy alespoň dvě zálohy dat svého systému. Pokud to okolnosti umožňují, zálohujte nejen uživatelské soubory a databáze, ale i celou aplikaci včetně logů a celý server (servery) včetně logů.
Zálohování databáze provádějte z repliky, minimalizujete tím výpadek (downtime) a zrychlíte samotné zálohování. Sekundární zálohu dělejte z primární zálohy; pokud je primární záloha vytvářena metodou push, sekundární dělejte metodou pull. Přístup k sekundární záloze by měla mít jiná osoba, než kdo má přístup k primární záloze.
Zálohujte tak často, jak je to potřeba. Pokud máte málo dat, která jsou ale velmi variabilní, zálohujte třeba každou hodinu.
Plán pro případ katastrofy
Napište si plán disaster recovery. Naplánujte výpadek služby a zkuste disaster recovery podle tohoto plánu provést.
Počítejte s tím, že obnova dat ze záloh trvá dlouho. Možná zjistíte, že budete potřebovat do infrastruktury zahrnout hot-standby servery, do kterých pak jen dohrajete poslední změny.
Zkuste provést disaster recovery v neděli, ve svátek, na Silvestra nebo o Velikonocích.
Hardware a lidé
Výkon a zátěž
Používejte pro své webové služby proxy servery a balancery. Umožní vám to rychleji reagovat na nenadálé požadavky. DNS failover trvá o řád déle.
Dohled
Monitorujte chod serverů ze dvou nezávislých míst. Kromě vlastního stavu běží/neběží sbírejte i performance data, umožní vám to minimalizovat náklady na infrastrukturu, nebo maximalizovat propustnost
Veďte si přehled problémů, které se s vaším systémem řešily (issue track). Můžete-li, dejte možnost vstupovat do tohoto trackeru vašim klientům.
How To…
Napište si návod k instalaci celého vašeho systému. Návod v pravidelných intervalech testujte a aktualizujte.
Hardware
Vyhněte se investicím do hardware, pokud pro vlastní hardware nemáte opravdu dobré důvody. Většina poskytovatelů IT služeb zároveň hardware prodává a hlavní motivací je pro ně provize z prodeje. Správnou konfigurací lze často snížit náročnost na hardware, v mnohých případech o více než polovinu.
Když už z nějakého důvodu musíte koupit hardware, ověřte si reálnou objednávkou dostupnost náhradních dílů. Často se vyplatí mít více obyčejných serverů než jeden super dokonalý, na který ovšem nikdo nemá náhradní díly skladem.
Příklad za všechny: v jedné firmě koupili server HP-Compaq za ranec peněz. Jelikož byl velmi drahý, byla investice počítaná na pět let. Po konci záruky odešel harddisk v poli. Tuzemské zastoupení bylo schopné dodat nový harddisk stejného typu za cca 10 000 CZK a v termínu 6 týdnů. Kdyby server byl obyčejný, jednak by bylo politicky možné ho po 2–3 letech vyměnit celý, a jednak by náhradní díl byl k dispozici do druhého dne.
Lidé
Důvěřujte lidem, kteří mají přístup do vašeho systému. Paranoidní přístupové systémy jsou extrémně drahé. Nemůžete-li z nějakého důvodu lidem důvěřovat, vyměňte je.
Ideální stav je lidem umožnit prakticky vše, aby je omezení přístupu nebrzdilo v práci, avšak zároveň užívání přístupů logovat, aby nebylo obtížné případného pachatele škody dohledat.
Pokud někomu nedůvěřujete, musíte mu sebrat všechny přístupy do systému a naráz. Často jich bývá mnoho a na různých místech. Je dobré mít aktuální seznam k dispozici, případně mít skript, který to řeší.
Logy
Při sběru logů kombinujte centrální a lokální ukládání. Centrální ukládání umožňuje rychlejší analýzu, lokální zajišťuje uložení dat i v případě potíží se sítí a pod.
Horizontální škálování
Naučte se rozumět horizontálnímu škálování a využívat jej. Údržba malého serveru vždy zabere méně času než údržba velkého serveru. Můžete také škálovat podle přihlášených uživatelů. Budete-li mít výpadek jednoho serveru, je velký rozdíl, jestli vám budou telefonovat všichni klienti, nebo jen každý desátý. Stejně tak v případě, že dojde k poškození souborového systému – je velký rozdíl, jestli oprava proběhne za 10 minut nebo za 100 minut. Navíc můžete (díky proxy) uživateli poslat přátelskou chybovou hlášku, ideálně s odhadem, za jak dlouho se má pokusit o přístup znovu.
Shrnutí
V článku jsme si představili některé základní body, které by měl mít každý provozovatel internetové služby rozmyšlené a podchycené. Zamyslete se nad tím, jestli vaše služba nemá někde slabé místo – především zda má funkční zálohování a disaster recovery scénář, které pomohou vyřešit většinu problémů. Je samosebou důležité katastrofám předcházet, ale spoléhat se na to, že se jim podaří předejít vždy, je čirá bláhovost.
Autor vám přeje, abyste ty katastrofické scénáře nemuseli nikdy použít!
Školení: Návrh a používání MySQL databáze

Naučte se používat jednu z nejrozšířenějších databází. Dozvíte se vše potřebné od návrhu až po samotné využití MySQL v projektech.
Školení pro všechny, kteří se chtějí naučit efektivně pracovat s MySQL nebo se v práci s touto databází zlepšit.
Přihláška a podrobné informace
Přehled názorů
Tento text je již více než dva měsíce starý. Chcete-li na něj reagovat v diskusi, pravděpodobně vám již nikdo neodpoví. Pro řešení aktuálních problémů doporučujeme využít naše diskusní fórum.