Miért érdekes egy rövid karbantartási ablak?
A Cloudflare státuszoldalán megjelent Workers platform konfigurációs karbantartás első ránézésre nem drámai: egy órás ablak, ezen belül legfeljebb néhány percig nem lehet konfigurációt módosítani vagy új Workers/Pages deployt indítani. Üzemeltetési szempontból viszont jó példa arra, hogy a modern webes működés nem csak a saját kódunktól függ.
A legtöbb KKV nem saját adatközpontból szolgálja ki a weboldalát. Ez jó. A CDN, a felhő, a menedzselt adatbázis, a tranzakciós email szolgáltató és a fizetési API rengeteg terhet vesz le a vállalkozásról. De ettől a rendszer nem lesz karbantartásmentes. Inkább több szolgáltatói határ jön létre, ahol látni kell, mi történik.
Hol szokott elcsúszni a webes működés?
A külső függőségek általában nem teljes leállásként fájnak. Gyakoribb, hogy nem megy ki egy deploy, nem frissül egy cache, nem érkezik meg egy tranzakciós email, egy API lassabban válaszol, vagy a DNS módosítás nem ott terjed, ahol várnánk. A látogató ebből csak annyit lát, hogy valami nem működik.
- Kampány indul, de a landing page módosítása nem deployolható.
- Űrlap működik, de az értesítő email nem érkezik meg.
- A fizetés sikeres, de a visszaigazolási folyamat késik.
- A cache régi tartalmat mutat, miközben az adminban már új szöveg van.
- A szolgáltató státuszoldala jelzi a hibát, de senki nem figyeli.
Ezek nem mindig katasztrófák, de rossz időpontban üzleti kárt okoznak. Egy hirdetési kampány első órája, egy pályázati határidő, egy esemény jegyértékesítése vagy egy szezonális akció nem várja meg, amíg mindenki ráér utánanézni.
Mit jelent erre felkészülni?
A felkészülés nem azt jelenti, hogy mindent saját szerverre kell visszahozni. A jó irány inkább az, hogy a külső szolgáltatásokat tudatosan választjuk, dokumentáljuk és monitorozzuk. Tudni kell, melyik szolgáltató mire kell, hogyan látszik a hibája, és mi az elfogadható kerülőút.
Deployment rend
Élesítés előtt érdemes nézni a szolgáltatói státuszt, és kritikus kampány előtt nem utolsó pillanatban módosítani.
Függőségi térkép
DNS, CDN, email, adatbázis, fizetés és API-k: legyen világos, melyik üzleti funkció melyiktől függ.
Riasztás és kommunikáció
Ha hiba van, gyorsan derüljön ki, és legyen kész válasz az ügyfelek vagy belső csapat felé.
A szolgáltatófüggőség nem csak technikai kérdés. Ha egy webalkalmazás bevételt vagy ügyfélkiszolgálást érint, akkor a karbantartási ablak, a státuszoldal és a monitoring ugyanúgy üzleti információ, mint egy készletjelentés vagy kampányriport.
Érdemes előre eldönteni azt is, milyen eseményről kit kell értesíteni. Más reakció kell egy fejlesztői deploy-csúszásnál, más egy fizetési hiba esetén, és megint más, ha az ügyfelek nem kapnak visszaigazoló emailt. A jó üzemeltetésben nem csak technikai riasztás van, hanem üzletileg érthető priorizálás is.
Mit adunk hozzá üzemeltetésben és fejlesztésben?
Az 1data fejlesztési és üzemeltetési munkában nem csak a saját kódot nézzük. A webes működéshez tartozó cloud, DNS, CDN, email és API függőségeket is figyelembe vesszük. Ez segít abban, hogy egy hiba ne találgatás legyen, hanem gyorsan behatárolható esemény.
Ez különösen fontos egyedi webalkalmazásoknál, admin felületeknél, leadgyűjtő oldalaknál és olyan rendszereknél, ahol a webes folyamat több szolgáltatón keresztül teljesül. A jó architektúra nem attól jó, hogy nincs benne külső szolgáltató, hanem attól, hogy a függőségek láthatók és kezelhetők.
Egy kisebb cégnek ez nem feltétlenül bonyolult dokumentációt jelent. Elég lehet egy karbantartott lista arról, hol van a domain, ki kezeli a DNS-t, melyik szolgáltató küldi az emaileket, honnan megy a deploy, és milyen státuszoldalakat kell figyelni. Ez a lista incidensnél órákat spórolhat.
