Amikor egy weboldal elkészül, a legtöbb ügyfél megkönnyebbül, hiszen úgy érzi, a projekt lezárult. Valójában ilyenkor kezdődik az a szakasz, amely meghatározza, hogy jól szolgálja-e az oldal a vállalkozást öt hónap vagy öt év múlva is, ez pedig a folyamatos fejlesztői háttér, amit sokan félreértenek, mert azt gondolják, ez csak annyit jelent, hogy van kit hívni, ha valami elromlik.
A weboldal-support nem kizárólag hibajavítás: célja a weboldal folyamatos műszaki karbantartása, a működési kockázatok csökkentése, valamint a kisebb üzemeltetési és módosítási igények szervezett kezelése.
Nálunk a folyamatos fejlesztői háttér jellemzően több elemből áll össze. A supportcsomagtól és az adott rendszerhez kialakított szolgáltatási körtől függően a háttértámogatás része lehet a monitorozás, a megelőző karbantartás, a biztonsági frissítések kezelése, a hibák kezelése és a mindennapi kisebb módosítások kezelése, mindezt olyan fejlesztői csapat végezheti, amely ismeri az oldal architektúráját és a mögötte álló döntéseket. A cél nem az, hogy gyorsan eloltsunk egy tüzet, hanem hogy minél kevesebb tűz keletkezzen.
Mit gondolnak az ügyfelek, és mi történik valójában
A legtöbb cégvezető a support fogalmát a hibaelhárítással azonosítja, vagyis azzal, hogy ha egy gomb nem működik vagy egy oldal fehér képernyőt mutat, akkor felhívja a fejlesztőt, aki megjavítja. Ez a kép nem téves, csak nagyon hiányos, mert a munka döntő része sosem jut el eddig a pontig, mert valaki korábban megelőzte a problémát.
Egy weboldal nem egyszer megépített és utána statikus objektum, hanem folyamatosan változó rendszer. A WordPress mag rendszeresen frissül, a pluginok új verziói biztonsági réseket zárnak be, a látogatói szokások pedig hónapról hónapra alakulnak. A böngészők, külső szolgáltatások, API-k és a weboldal által használt komponensek folyamatosan változnak, ezért egy korábban stabil rendszer kompatibilitását hosszú távon is fenn kell tartani. Ha ezt a mozgást senki nem követi, az oldal nem egyik napról a másikra romlik el, hanem lassan, észrevétlenül csúszik ki a kézből.
Amit a látogató sosem vesz észre, de nélküle idővel minden szétesik
A folyamatos háttértámogatás nagy része szándékosan láthatatlan marad, hiszen a cél éppen az, hogy a látogató sose szembesüljön a mögötte zajló munkával. Ide tartozik a rendszeres pluginfrissítés is, amely kontrolláltan, a kompatibilitási és üzleti kockázat mérlegelésével történik, egy fizetési vagy foglalási folyamatot érintő frissítés más elbírálást kap, mint egy vizuális elem apró változása. WordPress-alapú rendszereknél ez többek között a core és a pluginok állapotának követését és szükséges frissítéseinek kezelését jelentheti, egyedi rendszereknél pedig a használt technológiai komponensek, függőségek és integrációk karbantartása kerülhet előtérbe.
Ide tartozik a biztonsági rétegek karbantartása is: a rendszer és a supportcsomag függvényében ide tartozhat a biztonsági beállítások ellenőrzése, a szükséges frissítések kezelése és az azonosított technikai vagy biztonsági kockázatokra történő reagálás is, hogy egy régóta nem frissített komponens ne váljon belépési ponttá egy támadás számára. Egy elhanyagolt weboldal idővel egyre vonzóbb célponttá válik, nem azért, mert rosszabb lett a technológia, hanem mert egyre több ismert, dokumentált sebezhetőség gyűlik fel körülötte, amit senki nem zárt be.
WordPress-alapú rendszereknél ide tartozik a WordPress mag verzióváltásainak követése is. Egy nagyobb magfrissítés, mint amilyen a Gutenberg fejlesztésének egyes szakaszai voltak, alapjaiban változtathatja meg, hogyan viselkedik a szerkesztőfelület vagy egy egyedi fejlesztésű blokk. Ha ezt senki nem követi tudatosan, a probléma pont akkor bukkan fel, amikor a legkevésbé alkalmas rá az időpont.
Mi történik, amikor tényleg elromlik valami
Bármilyen alapos a megelőzés, előfordulhat, hogy egy külső szolgáltatás API-ja hirtelen megváltozik, egy tárhelyszolgáltatónál akad probléma, vagy egy plugin frissítése váratlan mellékhatással jár. A kérdés ilyenkor nem az, elkerülhető lett volna-e minden hiba, hanem az, milyen gyorsan és milyen alapossággal reagál rá valaki, aki már ismeri az oldal teljes architektúráját.
Egy harmadik féltől származó szolgáltatás felületén állítható beállítás néha csak a felszínen tűnik hatásosnak, miközben a tényleges működést a háttérben, kód szinten vezérelt logika határozza meg. Egy fejlesztő, aki nem ismeri a rendszert, gyakran órákat tölt azzal, hogy ezt kiderítse, a csapat viszont, mivel ismeri az architektúrát és a korábbi döntéseket, jóval gyorsabban tudja, hol keresse a valódi vezérlést.
A monitorozás, ami megelőzi a bajt
A folyamatos háttértámogatás egyik legkevésbé látványos, mégis legértékesebb rétege a monitorozás. Az uptime figyelés jelzi, ha az oldal elérhetetlenné válik, a teljesítménymonitorozás pedig azt méri, hogyan alakulnak azok a mutatók, amelyek meghatározzák, milyen élményt kap egy látogató és mennyire elégedett vele a keresőmotor is.
Ez utóbbi különösen fontos, mert a weboldalak teljesítménye nem statikus állapot, hanem folyamatosan mozgó cél. Egy űrlap vagy külső integráció technikailag működőképesnek tűnhet úgy is, hogy a háttérfolyamat valamely eleme hibásan működik. A megfelelő monitorozás és rendszeres ellenőrzés segíthet az ilyen problémák korábbi felismerésében.
Kis kérések, amik nem projektek, mégis időt igényelnek
Van a munkának egy olyan rétege is, amely sem nem hibaelhárítás, sem nem új fejlesztés, hanem az élet apró, folyamatos igazítása. Egy elírás javítása egy termékleírásban, egy új munkatárs fotójának feltöltése, egy szezonális banner cseréje, egy form mező hozzáadása. Ezek külön-külön triviálisnak tűnnek, együtt viszont folyamatos figyelmet igényelnek, és pontosan ezek azok a kérések, amelyek egy rosszul megszervezett support kapcsolatban vagy elvesznek, vagy hetekig várnak megoldásra.
Érdemes ugyanakkor élesen elválasztani, mi fér bele a supportba, és mikor válik egy kérés önálló fejlesztési feladattá. Supportba tipikusan az tartozik, ami a meglévő rendszer logikáján belül marad és nem igényel új tervezést, amint egy kérés új funkciót, komolyabb architekturális döntést vagy több oldalra kiterjedő átalakítást igényel, az már külön fejlesztési feladat, saját scope-pal és időbecsléssel. Hogy egy konkrét feladat a support keretében kezelhető-e, azt az adott supportcsomag szolgáltatási köre, rendelkezésre álló kerete és a kérés komplexitása együtt határozza meg.
Egy jól működő háttértámogatási rendszerben minden kérésnek van egy egyértelmű útja: a beérkező kéréseket rögzítjük, priorizáljuk, és az adott supportmegállapodásban meghatározott folyamat és vállalási feltételek szerint kezeljük. Az ügyfélnek nem kell magának nyomon követnie tucatnyi apró kérést, mert a rendszer ezt helyette teszi.
Mi történik a háttérben egy átlagos hónapban
Az adott supportcsomagtól és rendszertől függően egy hónap során többek között az alábbi feladatok merülhetnek fel:
Monitorozás. A supportcsomagtól és az adott rendszerhez kialakított szolgáltatási körtől függően ide tartozhat az uptime, a teljesítmény és a biztonsági jelzések figyelése.
Frissítések és kockázatok ellenőrzése. WordPress-alapú rendszereknél ez többek között a core és a pluginok állapotának követését és szükséges frissítéseinek kezelését jelentheti, egyedi rendszereknél pedig a használt technológiai komponensek, függőségek és integrációk karbantartása kerülhet előtérbe.
Beérkező kérések kezelése. A kisebb módosítási igények fogadása és priorizálása.
Szükséges korrekciók. Az azonosított kockázatok vagy hibák javítása, a kompatibilitási és üzleti hatás mérlegelésével.
Visszajelzés. Az ügyfél tájékoztatása arról, mi történt a háttérben, és mi vár még megoldásra.
Ez a ciklus az, amit az ügyfél jó esetben soha nem lát, éppen azért, mert jól működik.
Miért nem elég egy sürgősség esetén hívjon típusú szerződés
Sok cég úgy gondolja, elég, ha van egy telefonszám, amit hívhat baj esetén. Ez a modell működik is egy darabig, egészen addig, amíg egy hiba nem olyan pillanatban jelentkezik, amikor éppen senki nem ér rá, vagy amíg ki nem derül, a probléma gyökere egy hónapokkal korábbi, észrevétlenül elmaradt frissítésben rejlik.
A folyamatos háttértámogatás ezzel szemben nem arra épül, hogy legyen kit hívni, hanem arra, hogy minél kevesebbszer kelljen hívni valakit. A hangsúly a megelőzésen van, nem a tűzoltáson, és ez a különbség az, ami hosszú távon jelentősen csökkenti mind a kockázatot, mind a váratlan költségeket.
Egy üzletileg fontos weboldalnál ez már nem technikai kényelmi kérdés, hanem üzletmenet-folytonossági kérdés. Ha egy oldalon keresztül folyik az értékesítés vagy a lead generálás egy része, a rendszer stabilitása ugyanolyan kockázatkezelési tétel, mint bármelyik más kritikus üzleti rendszeré.
Tipikus tévhitek a fejlesztői háttértámogatásról
Az egyik leggyakoribb tévhit, hogy a support csak akkor ér valamit, ha éppen történik valami. Ez olyan, mintha valaki azt gondolná, egy biztosítás csak akkor hasznos, ha be is következik a kár, miközben a legjobb hónap az, amelyikben semmi nem történik, mert minden a helyén van.
A második tévhit, hogy a frissítések elhalasztása kockázatmentes, hiszen az oldal most is működik. A valóságban egy elmaradt biztonsági frissítés ismert sérülékenységet hagyhat nyitva, a verziók tartós elmaradása pedig növelheti a kompatibilitási és biztonsági kockázatot, és egy ponton túl a felzárkózás sokkal nagyobb munkát igényel, mint amennyi a folyamatos karbantartással összesen felmerült volna.
A harmadik tévhit, hogy a support és a fejlesztés két külön világ. A valóságban a legjobb háttértámogatás pontosan azért működik jól, mert ugyanaz a csapat vagy ugyanaz a tudásbázis áll mögötte, amelyik az oldalt eredetileg megépítette, így minden döntés ismerős kontextusban születik, nem egy idegen rendszerben tapogatózva.
A W5labs megközelítése
Nálunk a Support nem utólag csatlakozik a projekthez, hanem a kezdetektől a rendszer negyedik rétege, a Strategy, a Creative és a Development mellett. A W5labs által fejlesztett rendszereknél külön előny, hogy a support mögött ugyanaz a technológiai tudás és projektismeret áll, amely a fejlesztés során felépült. Más fejlesztőtől átvett rendszereknél ezt egy technikai felmérési és megismerési szakasz alapozhatja meg.
Ennek üzletileg is közvetlen haszna van. Egy külsős support-partnernek minden vészhelyzetben előbb meg kell értenie egy idegen rendszert, mielőtt hozzálát a hibaelhárításhoz, ez idő, és időben mérve pénz. A W5labs által fejlesztett rendszereknél ez a lépés jellemzően kiesik, mert ugyanaz a csapat vagy ugyanaz a tudásbázis dolgozik a kérésen, amelyik az oldalt megépítette, más fejlesztőtől átvett rendszereknél pedig a korai technikai megismerés csökkenti ezt az időveszteséget a jövőbeni esetekre.
A gyakorlatban ez rendszeres frissítési ciklusokat jelent, folyamatos biztonsági és teljesítménymonitorozást, amely segít bizonyos problémák és kockázatok korábbi felismerésében, és egy világos csatornát a kisebb kéréseknek, amelyeket priorizálva, visszajelzéssel kísérve kezelünk.
Ez a fajta folyamatos jelenlét segít abban, hogy a weboldal hosszú távon is stabilan, biztonságosan és a változó technológiai környezethez igazodva működhessen, nem azért, mert semmi nem változott körülötte, hanem mert valaki folyamatosan alkalmazkodott helyette a változásokhoz.
A W5labs support szolgáltatásának pontos tartalma és vállalási feltételei az adott weboldal, supportcsomag és megállapodás szerint alakulnak. A célunk minden esetben az, hogy az üzletileg fontos weboldalak mögött kiszámítható fejlesztői és technikai háttér álljon.
