Trojice pojmů Day 0, Day 1, Day 2 se poměrně stabilně zabydlela ve slovníku IT profesionálů. Původně pocházejí ze světa DevOps a cloud-native, ale velmi dobře se hodí i pro „tradiční“ adminy, kteří spravují dedikované servery, VPS nebo menší firemní infrastrukturu. Pomáhají pojmenovat tři klíčové fáze života každé služby: od nápadu přes nasazení až po nekonečnou operativu.
V praxi se běžně děje, že se mnozí z nás rádi zamilují do Day 0 – plánování a vymýšlení. Hodně energie dokážeme dát i do Day 1 – hledání nástrojů, jak systém elegantně a automatizovaně nasadit. Z dlouhodobého hlediska ale rozhoduje hlavně Day 2. To je ta nejdelší a nejdůležitější část – každodenní provoz.
Day 0 – Design, plánování, rozhodování
Day 0 je všechno, co se děje ještě předtím, než vůbec existuje server, kontejner nebo první deployment. Je to fáze, kdy se definují cíle projektu, přemýšlí se nad architekturou a rozhoduje se, jaké technologie a řešení se použijí. Na papíře (nebo v Notionu, Confluence apod.) vzniká obraz toho, co chceme postavit, pro koho to bude a jaká jsou očekávání na výkon, dostupnost nebo bezpečnost.
Tady se rodí odpovědi na otázky typu: jakou aplikaci vlastně stavím, kolik uživatelů má zvládnout, co se stane při výpadku, kde budou uložena data a jak je budu zálohovat. A stejně důležité: jaké máme limity – časové, finanční, technologické.
Day 0 je oblíbený i proto, že je plný možností a ještě relativně málo problémů. Ale právě tady se rozhoduje, jestli bude celý další život aplikace zvládnutelný, nebo vás za pár měsíců čeká systém, který se sice nějak rozběhl, ale těžko se udržuje a všechno v něm bolí.
Day 0 mohou být nekonečné týmové debaty. Od jednoduchého serveru až po stavbu raketoplánu.
Day 1 – Nasazení a první spuštění
Day 1 je den, kdy přecházíte z teorie do praxe. Berete věci, které jste vymysleli v Day 0, a měníte je v běžící systém. V praxi to znamená připravovat infrastrukturu, instalovat služby, nastavovat sítě, databáze, DNS, zabezpečení a nakonec samotnou aplikaci.
Je to fáze, kterou si mnozí užívají – něco nového se rozbíhá, běží první testy, najednou je vidět výsledek. Přicházejí na řadu skripty, CI/CD pipeline, Infrastructure as Code, kontejnery, možná Kubernetes, automatizované deploymenty. Hodně energie jde do toho, aby nasazení bylo co nejčistší, opakovatelné a „na klik“.
Day 1 často přitahuje i love of tools – člověk zkouší nové deploy nástroje, nové orchestrace, nové způsoby, jak si ulehčit život. A je to super. Jenže právě tady se dá snadno zapomenout na to, že nasazením mise nekončí. Ve skutečnosti jí teprve začíná další, mnohem delší kapitola.
Day 2 – Nekonečná operativa
Day 2 začíná ve chvíli, kdy aplikace běží v produkci a používají ji reální lidé. Všechno je nasazené, DNS směřuje, první requesty chodí. A od tohoto momentu se váš život mění na variaci filmu Na Hromnice o den více.
Každý den se totiž probouzíte do velmi podobného scénáře: je potřeba zkontrolovat monitoring, vyřešit alerty, podívat se, proč jedna služba z ničeho nic spotřebovala víc RAM, proč se databáze chová divně, jestli se podařily zálohy, jestli se obnovil certifikát, proč uživatelům z nějaké geolokace najednou všechno běží pomaleji… A když to vyřešíte, zítra přijdou nové zprávy, nové tickety, nové bugy a nové nápady, které je potřeba nasadit.
Day 2 je nekonečná operativa. Do této fáze patří monitoring a alertování, pravidelné aktualizace a záplaty, plánované odstávky, incident management, zálohování a testování obnovy, škálování podle potřeby, ale i komunikace se zákazníky nebo interním byznysem. Z technického hlediska je to série opakujících se cyklů: pozoruji (co se děje), vyhodnocuji (jestli je to problém), rozhoduji (co s tím) a konám (změna konfigurace, navýšení kapacity, oprava bugů, rollback verze…). A tak pořád dokola.
Právě tady se rozhoduje o skutečné kvalitě služby. Pokud Day 2 zanedbáte, i ten nejhezčí návrh a nejčistší nasazení se časem rozpadnou pod tlakem reality: víc uživatelů, víc dat, víc závislostí, víc aktualizací.
Proč myslet na Day 2 už od Day 0?
Klíčová myšlenka je jednoduchá: Day 2 nezačíná až po nasazení, ale už při plánování. Když v Day 0 řešíte architekturu, vyplatí se zároveň položit otázky typu: jak budeme systém monitorovat; kde budeme logovat; jak rychle dokážeme obnovit data; kdo má na starosti incidenty; jak bude vypadat škálování; co uděláme, když se zátěž zdvojnásobí.
A v Day 1, při nasazování, se vyplatí rovnou zavést alespoň základní prvky Day 2: nastavit monitoring hned od začátku; mít připravené zálohy a otestovanou obnovu; mít v týmu dohody, kdo co řeší při problémech; mít zdokumentovaný postup, jak se systém nasazuje a jak se dá vrátit zpět. To všechno výrazně snižuje stres ve chvíli, kdy se něco pokazí – a ono se vždycky dříve nebo později něco pokazí.
Firmy a týmy, které Day 2 ignorují, to většinou poznají velmi rychle: po pár měsících se plácají v manuálních zásazích, systém je plný „dočasných řešení“, která tam jsou už rok, a každý větší incident znamená noční směny a improvizaci. Naopak ti, kteří s Day 2 počítali od začátku, sice mají pořád co dělat, ale jejich Na Hromnice o den více je o dost klidnější film.
TIP: Websupport má za sebou dlouhé roky zkušeností se správou serverů – od malých projektů až po náročná produkční řešení. Známe typické problémy, nečekané výzvy i to, co všechno obnáší spolehlivý provoz. Proto se se stejnou péčí a důsledností postaráme i o váš server. Zajistíme jeho rychlost, bezpečnost, dostupnost i pravidelnou údržbu, abyste se vy mohli soustředit na svůj byznys a ne na technickou operativu.
Shrnutí
Day 0 vám dává vizi a směr. Day 1 vám dává první viditelný výsledek – běžící službu. Ale až Day 2 z toho dělá dlouhodobou hodnotu, kterou mohou vaši klienti spolehlivě používat.
A až se příště budete dívat na Na Hromnice o den více, možná si vzpomenete, že Bill Murray v tom filmu vlastně nezažívá nic jiného než klasický Day 2: každý den stejné problémy, ale s každým opakováním se to dá zvládnout o kousek lépe. Pokud dnes navrhujete nový systém, zkuste si u každého rozhodnutí položit otázku: Jak se mi tohle bude spravovat za rok v Day 2? Často zjistíte, že mírné zjednodušení architektury, trochu víc automatizace nebo lepší monitoring jsou investice, které se vám vrátí při prvním větším problému.