V minulém článku jsme řešili, proč dostupnost kritického systému není pouze IT parametr, ale součást návratnosti celé investice do digitalizace a vývoje softwaru. Tentokrát půjdu o úroveň níž: co podle našich zkušeností musí být připravené, aby provoz opravdu fungoval, až přijde první vážný incident.

Profesionální provoz systému se nepozná ve chvíli, kdy všechno funguje.

Pozná se ve chvíli, kdy něco přestane fungovat.

Je dvě ráno. Monitoring hlásí chyby. Část uživatelů nemůže dokončit transakci. Není zatím jasné, jestli problém způsobila aplikace, infrastruktura, cloud nebo některá ze služeb třetích stran.

Právě v tomto okamžiku se ukáže, jestli firma skutečně provoz řídí, nebo se pouze spoléhá na to, že se vždy najde někdo, kdo si s problémem poradí.

Go-live není okamžik, kdy se provozní tým poprvé podívá pod kapotu

V MoroSystems nevnímáme provoz jako službu, která začíná po dokončení vývoje. Připravujeme ho už během vývoje.

„Náš Operations tým se podílí na vývoji systému už od jeho vzniku. Od návrhu a architektury systému, protože již tam se rozhoduje o tom, jestli bude možné výsledný systém provozovat podle našich standardů, potřeb konkrétního klienta a v pozdějších fázích vývoje nebude nutné dělat drastické změny, které by implementaci systému prodražovaly, “ říká Radek Teichmann, CTO v MoroSystems.

Potřebujeme znát jeho architekturu, databáze, integrace na třetí strany, infrastrukturu a způsob nasazování. Musíme vědět, co je kritické pro fungování služby, jaké komponenty potřebujeme zálohovat a jak poznáme, že se některá část systému nechová správně.

Před přechodem do provozního režimu proto připravujeme mimo jiné logování, monitoring a alerting, health-checky, deployment postupy, smoke testy, zálohování, přístupy, provozní dokumentaci a disaster recovery scénáře.

„Naší ambicí je, aby go-live nebyl předáním balíčku přes zeď. Vývojový a provozní tým jsou dvě různé specializace, ale mezi oběma musí existovat kontinuita znalostí, “ doplňuje Jiří Bartoš, Head of Operations v MoroSystems.

Monitoring je k ničemu, když po alertu nikdo neví, co dělat

Nastavením monitoringu naše práce nekončí. Monitoring je jen první krok.

A Jirka pokračuje: „Systém může dokonale měřit CPU, paměť, disk, chybovost aplikace nebo dostupnost napojených služeb. Pokud ale alert pošle e-mail do schránky, kterou si někdo přečte druhý den ráno, problém jsme nevyřešili.„

Proto musí být technická detekce propojená s odpovědností.

Pokud monitoring zachytí relevantní problém, potřebujeme automatickou eskalaci na konkrétního člověka na pohotovosti. Ten musí umět incident vyhodnotit a začít jednat.

A musí k tomu mít nejen technickou odbornost, ale také kontext konkrétního systému.

V našem Operations týmu proto pracujeme s provozními postupy — runbooky. Pro situace, které dokážeme předvídat, popisujeme konkrétní kroky, jak problém ověřit a jak na něj reagovat.

Může jít například o navýšení prostředků, restart dílčí komponenty nebo další předem ověřený zásah.

Důležitá je v tom jedna věc.

Provoz nesmí stát na jednom člověku, který „to má celé v hlavě“.

Pokud chceme službu poskytovat dlouhodobě a například v režimu 24/7, potřebujeme zastupitelnost, rotaci pohotovostí, předávání znalostí a standardizované postupy.

Nejkritičtější proces? Incident management

V MoroSystems považujeme incident management za nejdůležitější část celé provozní služby.

Dává to smysl. Incident je okamžik, kdy software částečně nebo úplně přestává plnit důvod, proč existuje.

Naším cílem je v takové chvíli co nejrychleji obnovit službu.

Proces vypadá v principu jednoduše: monitoring problém detekuje, následuje upozornění provozního inženýra, první investigace a náprava. Pokud incident vyžaduje hlubší znalost aplikace nebo změnu kódu, přechází eskalace na vývojovou podporu.

Po celou dobu zároveň potřebuje zákazník vědět, co se děje.

Jirka to shrnuje následovně: „Zákazník si zde kupuje klidné spaní. Ne proto, že mu slibujeme svět bez incidentů. Ale protože v okamžiku incidentu existuje jasně definovaný tým a proces, který se aktivuje.“

Zákazník nesmí být integračním manažerem a řešitelem výpadku svého vlastního systému

Moderní aplikace se skládají z celé řady komponent. Cloudová infrastruktura, databáze, frameworky, knihovny, platební služby, identity provideři a další externí systémy jsou dnes standard. To současně znamená, že příčina incidentu nemusí být v aplikaci, kterou jsme pro zákazníka vytvořili.

Provozní odpovědnost podle nás ale nemůže vypadat tak, že při prvním podezření řekneme: „Tohle není náš problém.“

Úkolem člověka na pohotovosti je především dostat službu zpět do funkčního stavu. Pokud je k tomu potřeba eskalace na cloud providera, jiného dodavatele nebo vývojový tým, má ji koordinovat.

Zákazník by neměl být člověk, který uprostřed výpadku obvolává několik technologických partnerů a snaží se zjistit, komu incident patří.

53 minut, které ukazují hodnotu přípravy

Dobře je tento princip vidět na jednom skutečném incidentu z našeho provozu.

Šlo o platformu používanou desetitisíci uživatelů. Jedna z jejích klíčových funkcí umožňuje nákup a využívání voucherů.

Jednoho dne začala softwarová komponenta třetí strany chybně pracovat s databázovými spojeními. Spojení se nevracela zpět do poolu a problém postupně způsobil výpadek několika důležitých služeb.

Pro uživatele byl výsledek jednoduchý: při nákupu nebo uplatnění voucheru dostávali chybu a platba nefungovala.

Příčina byla podstatně méně zjevná.

Samotná databáze byla zdravá. Problém byl v chování knihovny, kterou jsme nevyvinuli my ani zákazník.

Automatický monitoring zachytil zvýšené množství chyb a upozornil provozního inženýra na pohotovosti. Ten provedl investigaci, identifikoval zaseknutý connection pool v konkrétní službě a provedl rolling restart.

Od detekce po obnovení služby uplynulo přibližně 53 minut.

„Naplnění SLA naší adekvátní reakcí není sama o sobě pointou tohoto příběhu. Hodnota byla v tom, že existoval člověk, který znal architekturu natolik dobře, aby problém dokázal lokalizovat, převzal odpovědnost za řešení a nemusel nejprve několik hodin zjišťovat, kdo se má incidentem zabývat, “ dodává Bartoš.

Obnovením služby práce nekončí

První cíl incident managementu je jasný: obnovit fungování systému.

Pokud u toho ale skončíme, budeme možná stejný problém řešit za týden znovu.

Proto po workaroundu nebo odstranění incidentu následuje analýza příčiny. Co přesně se stalo? Proč? A co můžeme změnit?

Výsledkem může být oprava kódu, úprava infrastruktury, nový alert nebo rozšíření runbooku.

Právě tady se podle nás musí propojit provoz s dalším rozvojem aplikace.

Incident není jen problém. Je to také informace o chování systému v reálném světě.

Dobrý provoz proto systém nejen udržuje při životě. Postupně ho dělá odolnější.

Záloha, kterou neumíme obnovit, nám klidné spaní nedá

Podobný přístup máme k zálohování.

Nestačí zaškrtnout, že se databáze každý den někam kopíruje. Potřebujeme vědět, která data a komponenty jsou pro obnovu kritické, jak jsou zálohy chráněné a jak bude obnova skutečně probíhat.

Proto sestavujeme disaster recovery plány a ověřujeme funkčnost záloh i alertingu.

Zejména dnes navíc nestačí chránit pouze produkční systém. Chráněné musí být také samotné zálohy, aby je například při bezpečnostním incidentu nebylo možné společně s produkcí jednoduše odstranit.

Stejný princip se propisuje do řízení přístupů, práce s certifikáty, bezpečnostních aktualizací a dalších provozních oblastí.

Bezpečnost pro nás není jednorázová činnost při spuštění aplikace.

Je součástí jejího každodenního života.

Přínosy digitalizace vznikají užíváním digitálního díla. Ne jeho vývojem

Slovo na závěr pro všechny, kteří o digitalizaci a vývoji software přemýšlí.

Software nestačí vyvinout.

Je nutné jej kvalitně a profesionálně provozovat. To znamená zabezpečit, že bude adekvátně nasazován, monitorován, aktualizován, zabezpečen, obnovován a rozvíjen další roky.

Protože skutečná hodnota digitalizace nevzniká během vývoje softwaru.

Vzniká při jeho používání.

A profesionální provoz je disciplína, která má zajistit, aby tuto hodnotu mohl vytvářet co nejspolehlivěji a co nejdéle.

Děkuji že vás problematika návratnosti investic do softwaru zajímá,
Váš Tomáš