„Erre nem is gondoltunk” — miért bukik el a legtöbb IT projekt az első hónapban

Húsz év IT tanácsadói munka után van egy megfigyelésem, ami visszatérő mintaként jelenik meg a projekteknél. Az IT projektek ritkán buknak el technikai okokból — rosszul megírt kódtól, hibás adatbázis-tervezéstől, gyenge szerverhardwertől. Sokkal, de sokkal gyakrabban buknak el azért, mert a megrendelő csak az egyik szeletét rendelte meg — és a teljes képet senki nem rajzolta meg.

A fejlesztők fejlesztenek. Az ügynökségek designolnak és szállítanak. A rendszerintegrátor összeköt. De senki nem ül le és mondja el: „Nézd, az, amit te megrendeltél, ennek van egy másik oldala is, amit ha nem rendezel meg, problémád lesz.” Ez nem rosszindulat — egyszerűen nem a feladatuk.

Mi a Professional IT Services-nél mindig összekötjük a pontokat.

Három eset következik. Mindegyikben elhangzott ugyanaz a mondat: „Erre nem is gondoltunk.”

Az app kész. Most mi lesz?

Néhány évvel ezelőtt keresett meg minket egy SaaS cég. Volt fejlesztőcsapatuk, volt kész backendük, volt egy éve fejlesztett, tesztelt, szép termékük — minden, ami egy prémium SaaS indulásához kell. Ahogy a megbeszélésen elhangzott: „Csak az infrastruktúra hiányzik.”

Ahogy belenéztünk a helyzetbe, kiderült: a fejlesztők dockerizálták az appot, mert így volt a legkönnyebb lokálisan futtatni. Volt egy staging szerver, amit valaki egyszer felállított — nem volt dokumentálva, hogyan. Nem volt Kubernetes cluster, nem volt production deployment terv, nem volt CI/CD pipeline. Nem volt monitorozás, nem volt alerting, nem volt on-call protokoll. Az adatbázis backup a staging szerver egy mappájában volt — az egyetlen, nem redundáns szerveren.

Az első komolyabb marketing kampány napján az alkalmazás leállt. A terhelés szintjét nem tesztelték production-szintű hardveren, az adatbázis nem volt méretezve.

Recovery: három nap. Ebből az első 18 óra tényleges incidens, a maradék a cluster felépítése, a backup stratégia kialakítása, a monitorozás beállítása — az az alap, aminek az éles indulás előtt kellett volna meglennie.

„Erre nem is gondoltunk” — pontosan így hangzott, nem szemrehányásként, hanem meglepett felismerésként.

Egy fejlesztőcsapat feladata remek kódot írni. A Kubernetes cluster tervezése, a disaster recovery stratégia, a production-szintű monitorozás — ez külön szaktudás. A kettő ritkán van egy kézben, és ha nem gondoskodnak külön mindkettőről, abból gondok lehetnek.

Ha felhőalapú infrastruktúrán gondolkodsz, vagy meglévő infrastruktúrádat szeretnéd felülvizsgáltatni, nézd meg a felhő üzemeltetési szolgáltatásunkat.

A weboldal „kész”. A projekt mégsem ért véget.

Egy kiskereskedelmi cég WooCommerce webshopot fejlesztetett ki egy digitális ügynökséggel. Hónapokig tartott a fejlesztés, az eredmény jól nézett ki, mobilra is optimalizálták. Az ügynökség átadta a projektet, lezárta a számlát.

Az oldal mobilon 8–9 másodperc alatt töltött be. A Google Search Console Core Web Vitals riportjában minden piros volt. A WordPress dashboardon 47 aktív plugin volt telepítve — ebből 12 nem volt frissítve az elmúlt hat hónapban, kettőnél ismert biztonsági sebezhetőség szerepelt a CVE-adatbázisban.

Az ügynökség hibát követett el? Nem feltétlenül. Megcsinálta, amit megrendeltek: egy weboldalt. De senki nem mondta el a megrendelőnek, hogy a weboldal indulása nem a projekt vége — hanem a kezdete. Az üzemeltetés, a karbantartás, a biztonsági frissítések, a teljesítménymonitorozás: ezek a weboldal élettartamának minden egyes napján szükségesek.

Ha webshopod van, vagy webshopot tervezel, érdemes előbb mérlegelni a valódi állapotát: 44 kérdés, amivel feltérképezheted, hol veszít bevételt a webshopod.

Az integráció ami „majd megoldódik”

Egy gyártócég ERP rendszerét kellett összekötni egy újonnan bevezetett CRM platformmal. A projektet egy tapasztalt rendszerintegrátor vállalta el. Megcsinálta a feladatát: az adatok átmentek az ERP-ből a CRM-be, és vissza. A tesztkörnyezetben minden rendben működött. Átadás, aláírás, live.

Hat hónappal később az értékesítési vezető reklamált: az ügyféladatok nem egyeznek a két rendszerben. Egy ügyfél státusza az ERP-ben „lezárva”, a CRM-ben „aktív”. Egy rendelés az ERP-ben szerepel, a CRM nem tud róla. Több ezer rekord volt valamilyen szinten inkonzisztens állapotban.

Mi nem volt megtervezve? Nem volt retry logika API hibák esetén. Nem volt conflict resolution stratégia arra az esetre, ha mindkét rendszerben módosítják ugyanazt a rekordot. Nem volt meghatározva, mi a „source of truth” — melyik rendszer a master. Nem volt tesztelve, mi történik, ha az ERP karbantartás miatt négy órán át nem elérhető.

Visszaszinkronizálás: három hét, két fejlesztő, részleges leállással. A cégnek ez háromszorosa volt az eredeti integrációs projekt díjának.

„Erre nem is gondoltunk.” Az integrátor rendeltetésszerűen teljesítette a szerződést. De senki — sem az integrátor, sem az ügyfél IT-vezetője — nem gondolta végig a teljes éles üzemelési forgatókönyvet.

Mi a közös a három esetben?

Mindhárom esetben volt valaki, aki remekül csinálta a saját feladatát. A fejlesztőcsapat jó kódot írt. Az ügynökség szép webshopot szállított. Az integrátor megcsinálta az integrációt.

A probléma nem a szakmai minőségben volt. A probléma az volt, hogy a feladatokat szeletekre osztották — és senki nem gondolkodott a szeletek közötti résekről, és arról, mi van a szeleteken túl.

Húsz év alatt volt részem fejlesztőként, Linux/Oracle DBA-ként, DevOps mérnökként, felhő architekturális tanácsadóként és rendszerüzemeltetőként is dolgozni. Nem azért sorolom fel, hogy imponáló legyen — azért, mert ez az a kombinált látásmód, amitől a „réseket” látom. Egy fejlesztő nem feltétlenül gondol a production Kubernetes clusterre. Egy ügynökség nem feltétlenül gondol az SSL-megújításra három évvel később. Egy integrátor nem feltétlenül gondol a négyórás ERP-kiesési szcenárióra.

Három kérdés, amit érdemes feltenni bármilyen IT projekt előtt

Ha IT projekten gondolkodsz — legyen az app fejlesztés, weboldal, integráció, felhőre költözés —, van három kérdés, amit érdemes az első megbeszélésen feltenni.

1. Ki fogja üzemeltetni ezt, miután az átadás megtörtént?

Ez az egyetlen leggyakrabban kihagyott kérdés. A fejlesztők fejlesztenek, de általában nem üzemeltetnek. Az ügynökségek szállítanak, de általában nem monitoroznak. Valakinek kell — és ideális esetben az illető már a projekt tervezési fázisában jelen van, nem az átadás után kerül képbe.

2. Mi a terv, amikor ez a rendszer leáll?

Nem „ha” — „amikor”. Minden rendszer megáll valamikor: szerverhiba, karbantartás, emberi hiba, kibertámadás. Mi a backup stratégia? Mi a recovery time objective? Van-e disaster recovery terv? Ezeknek az éles indulás előtt kell meglennie a válaszuknak.

3. Hogyan csatlakozik ez a többi rendszerhez — és mi történik, ha az egyik kiesik?

Integrációk, API-k, adatfolyamok. A legstabilabb rendszer is acra eshet egy rosszul tervezett integráción keresztül. Érdemes előre végigmenni a „mi van, ha…” szcenáriókon — a retry logikától a conflict resolution-ig.

Összefoglalás

Az IT projektek nem azért buknak el, mert a fejlesztő rosszul kódolt, az ügynökség rossz dizájnt csinált, vagy az integrátor nem teljesítette a szerződést. Legtöbbször azért, mert valaki nem tudta, mit kell megrendelnie — és senki nem mondta el neki.

A vakfoltok megmutatása az mi feladatunk. Ha IT projektet tervezel, és szeretnéd, hogy valaki végignézze a teljes képet — az infrastruktúrától a biztonságon át az üzemeltetésig —, nézd meg a rendszerüzemeltetési és automatizálási szolgáltatásainkat, vagy vedd fel velünk a kapcsolatot.