Prevádzka a podpora: čo sa deje s aplikáciou po tom, ako ju spustíte

Aplikácia, ktorú nevidíte, nie je nasadená — je opustená. Rozdiel medzi tými dvoma stavmi nie je v kóde, ale v tom, či sa o probléme dozviete vy, alebo zákazník.

Projekt sa odovzdá, faktúra sa vystaví a tým to pre väčšinu dodávateľov končí. Aplikácia pritom žije ďalej: rastie jej databáza, menia sa závislosti, vypršia certifikáty a niekto raz urobí zmenu, ktorá niečo pokazí. Prevádzka je to, čo rozhoduje, či sa to rieši v pokoji alebo v panike.

Monitoring je o otázke, nie o grafoch

Zmyslom monitoringu nie je mať peknú nástenku. Je to vedieť odpovedať na jednu otázku: funguje to teraz pre používateľa?

Na to stačia prekvapivo jednoduché veci, ktoré sa však musia sledovať naozaj:

• Chybovosť a rýchlosť na kľúčových miestach. A nie priemer — ten schová aj to, že desatine ľudí sa stránka načítava osem sekúnd. Zaujíma nás, ako je na tom tá najpomalšia časť návštev.
• Beží ešte to, čo má? Nielen webserver, ale aj fronty a naplánované úlohy. Spadnutý worker sa navonok neprejaví hneď — prejaví sa o deň neskôr tým, že nikomu neodišiel e-mail.
• Dochádza niečo? Miesto na disku, pripojenia do databázy, platnosť certifikátu. Toto sú výpadky, ktoré sa dajú vidieť týždne dopredu.

A platí jedno pravidlo: alert, na ktorý sa nedá reagovať, treba zmazať. Tri upozornenia denne, ktoré nikto nerieši, spoľahlivo naučia tím ignorovať aj to štvrté, ktoré bolo dôležité.

Záloha, ktorá nebola obnovená, nie je záloha

Toto je najčastejšia tichá diera v prevádzke. Zálohy bežia, v logu je „OK", a v deň, keď sú potrebné, sa zistí, že sa roky zálohovala prázdna databáza alebo že obnova trvá dvanásť hodín.

Preto k zálohovaniu patrí pravidelná skúšobná obnova — nie kontrola, že súbor existuje, ale reálne obnovenie do oddeleného prostredia a overenie, že dáta v ňom dávajú zmysel. Zároveň treba mať povedané dve čísla: koľko dát si môžeme dovoliť stratiť a ako dlho smie trvať návrat do prevádzky. Z nich vyplýva, ako často sa zálohuje a čo to stojí.

Dostupnosť: čo sa dá sľúbiť a čo nie

Dohodnutá dostupnosť je užitočná vec, ale len vtedy, keď sa k nej povie zvyšok. Samotné percento nehovorí nič, kým nie je jasné, čo sa počíta ako výpadok, v akom čase sa meria a čo sa stane, keď sa nedodrží.

Rovnako dôležité je, čo nemôže sľúbiť nikto: dostupnosť služieb tretích strán. Keď vypadne platobná brána alebo API dopravcu, aplikácia to má prežiť so zrozumiteľnou hláškou — ale nemôže za to ručiť.

Preto sa s klientmi bavíme o dohodnutej dostupnosti a reakčných časoch podľa závažnosti, nie o jednom čísle do zmluvy.

Nasadzovanie zmien je súčasť prevádzky

Väčšina výpadkov nevzniká z ničoho nič. Vzniká pri zmene. Preto sa prevádzka a spôsob nasadzovania nedajú oddeliť:

• Nasadzuje sa automaticky a rovnako zakaždým, nie ručne a nie podľa toho, kto má službu.
• Zmeny databázy musia byť spätne kompatibilné, inak sa nedá vrátiť späť bez straty dát.
• Návrat na predchádzajúcu verziu musí byť vyskúšaný, nie len popísaný. Rollback, ktorý sa prvýkrát skúša počas incidentu, obvykle nefunguje.

Čo robíme my

Aplikácie nasadzujeme v kontajneroch, takže bežia rovnako u nás, u vás alebo u iného poskytovateľa — a prípadné sťahovanie je nasadenie, nie prepisovanie. K prevádzke patrí monitoring s alertmi, zálohovanie s overenou obnovou, dohodnutá dostupnosť a reakčné časy, a zmeny nasadzované automatizovane.

Prevádzkovať vieme aj riešenie, ktoré sme nestavali — vtedy sa začína auditom, aby sme vedeli, čo preberáme. Ak vás zaujíma, čo by to znamenalo pre vašu aplikáciu, ozvite sa.