Etsy, známý internetový obchod, který spojuje prodávající a kupující, přistupuje k monitorování svých aplikací a serverů velmi systematicky. Jejich monitoring sleduje širokou škálu metrik – od počtu přihlášení uživatelů a chyb při přihlášení až po dolarové hodnoty transakcí provedených přes webové stránky. Toto monitorování však neslouží pouze k detekci problémů, ale také k identifikaci příčin těchto problémů.

V roce 2010 Mike Brittain, tehdy hlavní softwarový inženýr v Etsy, ukázal příklad grafu chyb PHP. "Něco se určitě stalo, ale co to bylo?" říká. Tento graf ukazuje náhlý vzestup chyb, ale není snadné určit příčinu tohoto vzestupu. Může jít o selhání serveru nebo třetí strany, ale může to být také důsledek změn v aplikaci. V Etsy nasazují změny kódu a konfigurace více než 25krát denně. K tomu, aby mohli okamžitě identifikovat, zda jsou tyto změny důsledkem úpravy aplikace nebo externího problému, používají sledování času každé jednotlivé změny, která je nasazena na jejich produkční servery.

Tato metoda je pro tým Etsy nezbytná, protože umožňuje okamžitě provázat nasazení s problémy, které mohou nastat. Je to velký rozdíl oproti běžným systémům monitorování, které pouze detekují změny, ale neumožňují zjistit jejich skutečnou příčinu. Tento přístup zahrnuje i zobrazení vertikálních čar, které označují časy nasazení. Tým v Etsy tak může snadno zjistit, že problémy, které se objevily po nasazení, jsou důsledkem konkrétní změny.

Další zásadní součástí tohoto přístupu je automatizované testování, které Etsy provádí před a po každém nasazení. Automatické testy ověřují, že klíčové funkce aplikace stále fungují, jak mají. Kombinace těchto testů, neustálého monitorování a manuálního testování je pro tým Etsy klíčová pro udržení vysoké úrovně kvality a stabilitě aplikace, i když se na jejich platformě neustále provádí změny.

Spotify, známý hudební streamingový servis, přistupuje k podobným technologiím, i když s jinými specifiky, která odpovídají jejich infrastruktura a specifickým potřebám. Spotify začalo používat Docker v roce 2013, aby se vypořádalo s problémy správy velkého počtu serverů a služeb. Rohan Singh, inženýr infrastruktury ve Spotify, vysvětluje, že jejich platforma se skládá z mnoha malých služeb, z nichž každá má specifickou funkci. Zatímco některé služby jsou poměrně jednoduché, jiné mohou mít širší spektrum úkolů a mohou být méně efektivní.

Docker zde pomáhá standardizovat a zjednodušit infrastrukturu. Díky této technologii mohou vývojáři vytvářet opakovatelné kontejnery, které fungují stejně v testovacím, vývojovém i produkčním prostředí. To usnadňuje nasazování nových verzí aplikací, a především zjednodušuje proces obnovy v případě selhání. Pokud nasazení selže, není nutné znovu konfigurovat celý stroj – stačí znovu spustit kontejner a problém je vyřešen. To výrazně zvyšuje stabilitu a snižuje riziko výpadků.

Dále Spotify vyvinulo nástroj Helios pro orchestraci Docker kontejnerů. Tento nástroj automatizuje proces nasazování služeb na širokou škálu serverů a zajišťuje, že všechny služby běží hladce. Tímto způsobem Spotify řeší složité problémy spojené s nasazováním mnoha různých služeb na velkém množství serverů.

Zásadní součástí přístupu Spotify k monitorování a nasazování aplikací je důraz na automatizaci a snadnou správu infrastruktury. To umožňuje rychlou reakci na problémy a zajištění, že služby běží efektivně i při velkém objemu uživatelů a dat. Spotify také využívá monitoring pro detekci anomálií a okamžitou analýzu, což je klíčové pro zajištění spolehlivosti služby.

Tento přístup, kombinující rychlé nasazování, monitoring a automatizované testování, nejen zvyšuje kvalitu softwaru, ale také výrazně snižuje čas potřebný k identifikaci a řešení problémů. Důležité je také mít na paměti, že automatizace je klíčem k udržení vysoké efektivity v prostředí s velkým množstvím nasazení a neustálými změnami.

Jak funguje DevOps filtrace chyb a co je třeba otestovat?

Model automatizace v DevOps prostředí, jak si ho představuji, má šest vrstev, přičemž horní tři slouží pro testování v rámci vývojového prostředí, a to: testování jednotek, testování integrace a end-to-end testování. Spodní tři vrstvy se zaměřují na informace, které jsou zachyceny v produkčním prostředí a mohou být použity k detekci chyb a určení kvality produktu: upozornění, monitorování a logování. Představme si tyto vrstvy jako různé filtry pro chyby. Testování jednotek a logování mají jemně tkanou síť, která zachytí ty nejmenší chyby. Testování integrace a monitorování mají širší síť, která zachytí širší spektrum problémů. End-to-end testování a upozornění mají nejširší síť, která zachytí pouze ty největší problémy.

Představme si chyby, které procházejí tímto filtrem, jako motýly v různých fázích jejich života. Testy jednotek zachytí vajíčka — tedy chyby, které se ještě nevyvinuly v nic závažného. Testy integrace zachytí housenky, které mohou vzniknout z vylíhnutého vajíčka v prostředí integrace, nebo mohou pocházet z třetí strany. End-to-end testování zachytí dospělé motýly. Horní vrstvy filtru nejsou uzavřeny. I kdybychom měli 100% pokrytí testy jednotek, stále bychom nemohli zabránit tomu, aby všechny chyby dospěly až do nižších vrstev filtru.

Jak postupujeme přes testování integrace, end-to-end testování a produkční prostředí, měníme infrastrukturu a systémy, se kterými interagujeme. Chyby se mohou objevit v těchto vrstvách z nečekaných zdrojů, které přesahují naše vlastní aplikace, což je důvod, proč se filtry ve spodních vrstvách rozšiřují. Jakmile se dostaneme do produkce, filtr funguje jako blokový filtr: strany jsou uzavřeny a vrchní vrstva zachytí největší problémy, přičemž spodní vrstva zachytí ty nejmenší. V této fázi již nejsou žádné nové problémy mezi vrstvami, protože se pouze prohlubujeme v detailních informacích o produkční aplikaci.

DevOps filtr pomáhá vést diskuzi o širší strategii testování. Testy, které implementuje váš vývojový tým, a data, která jsou shromažďována v produkčním prostředí, tvoří síť v tomto filtru. Pokud má váš tým špatné pokrytí, síť bude mít mezery. Kde je síť neúplná, existují příležitosti pro chyby, které mohou proklouznout a stát se větším problémem. Chybějící pokrytí v testech jednotek znamená více housenek v integrační vrstvě a tak dál. Více mezer znamená, že v softwaru mohou být skryté další chyby.

V některých případech může být strategickým rozhodnutím zachytit chybu později v procesu. Možná některá integrační služba nemůže být vystavena samostatně, nebo test jednotek je těžké izolovat, a proto je přidán do pozdějšího testovacího balíčku. Tyto strategické rozhodnutí stojí za to diskutovat, aby nedošlo k nedorozumění. Síť může mít také mezery, když se vývojový tým rozhodne, že neúspěch testu nebrání vydání. Možná je vhodné vydat produkt do produkce i s chybami, které jsou detekovány pomocí upozornění, monitorování nebo logování. Součástí DevOps je zvažování, kde je nejvhodnější zmírnit riziko a přidat pouze nezbytnou automatizaci.

Pokud by model filtrování chyb byl příliš složitý na to, aby se nakreslil na tabuli, výchozím bodem pro diskuzi o strategii testování v DevOps může být jednoduchý model přesýpacích hodin: Upozornění, monitorování a logování jsou jakýmsi zrcadlem původní pyramidy testování. To je rychlý způsob, jak rozšířit tradiční diskuzi o testování do oblasti DevOps. Zahrnuje vaše testovací strategie typy informací, které mohou operace poskytnout?

Dalším důležitým bodem v oblasti automatizace je, že tyto konverzace a modely se vztahují nejen na funkční, ale i na nefunkční testování aplikace. Můžete automatizovat aspekty bezpečnosti, výkonu, použitelnosti apod. stejnými zpětnovazebními mechanismy – využíváním automatizace testování ve vývoji a sbíráním metrik v produkci.

Jedním z klíčových aspektů, které by měly být brány v úvahu při vývoji DevOps testovací strategie, je vyvážení mezi explorativním a automatizovaným testováním. Explorativní testování je zásadní pro odhalení funkcionality softwaru, která byla implementována, ale není přímo uvedena v požadavcích. V DevOps prostředí může být těžké obhajovat explorativní testování, zvláště když je kladen důraz na rychlost dodání. Explorativní testování se často posouvá na okraj vývojového procesu. Může probíhat v místním vývojovém prostředí před sloučením kódu do hlavního repozitáře nebo po vydání, když uživatelé interagují s aplikací. Příležitosti pro exploraci jsou v automatizovaných pipelinech omezené. Jak tedy tester určí svou strategii pro explorativní testování a jak detailní by mělo být?

Důležitým nástrojem pro vyvážení testovacího přístupu je kyvadlo. Představte si kyvadlo v klidu. Prostor, ve kterém se kyvadlo může houpat, je naším přístupem k testování. Na levém vrcholu kyvadla jsme příliš detailní, na pravém vrcholu jsme příliš povrchní. Kyvadlo se zpočátku pohybuje od povrchního testování směrem k hlubší analýze, jak se náš pohled na projekt prohlubuje. Klíčovou dovedností je umění identifikovat okamžik, kdy jsme příliš hluboko nebo příliš povrchní, abychom mohli přizpůsobit svůj přístup.

Pokud v průběhu testování nenacházíte mnoho chyb, ale vaši zákazníci hlásí mnoho problémů v produkci, vaše testování může být příliš povrchní. Naopak, pokud naleznete mnoho chyb, ale mnoho z nich není opraveno nebo vaši zákazníci nehlásí žádné problémy, vaše testování může být příliš hluboké. Tento indikátor je však závislý na povaze aplikace a požadavcích, které na ni kladete.

Jak komunikovat s lékařem v zahraničí?
Jak si udělat prostor pro sebe a rodinu ve zrychleném životě?
Jak si užít plavbu po Nilu a na co si dát pozor