Rendszerátépítés futás közben

futasAdott egy rendszer 1-2 ezer vásárlóval. A rendszer lassú, nehézkes, rugalmatlan és olyan biztonsági lyukak tátonganak rajta amin egy elefánt is átférne. Valamit tenni kell, de egy futó rendszer átépítése nem egy könnyű hadművelet. A megrendelőnek azt mondtam, hogy kb olyan mintha beülnénk egy Zsiguliba, elindulnánk Pestre és menet közben átépítenénk az autót egy Audivá. Ja igen, megállni nem lehet és amint kicseréltünk egy alkatrészt máris használni akarjuk.

Reinkarnációs módszer

Első megközelítésben azt gondoltam, hogy a legegyszerűbb az lenne, hogy építek a 0-ról egy új rendszert, szépen átpumpálnám bele a meglévő adatbázisban lévő szükséges és használható adatokat és voálá minden szuper.

Habár ez a módszer roppant rokonszenvesnek látszik jó néhány kérdést és problémát felvet. Egyrészt az új rendszer kifejlesztése időigényes és a fejlesztés alatt nem látszik belőle semmi. A régi rendszerben folyamatosan kell hibákat javítani, esetleg új funkciókat beépíteni, ami időt vesz el az új rendszer kifejlesztésétől.

Mi van ha az adatok átköltöztetése mégsem sikeres? Vagy bekapcsoláskor kiderül, hogy egyes funkciók nem, vagy nem úgy működnek ahogy szeretnénk? Visszakapcsolhatunk éppen a régi rendszerre de egy ilyen ide-oda kapcsolás esetén szinte biztos, hogy el fogunk szenvedni valamiféle adatvesztést. Elvesznek megrendelések, elégedetlen ügyfelek, egyik sem jó indítás egy új rendszerhez.

A béka módszer

A másik módszer amit egy alaprendszer lecserélésekor használhatunk valami olyasmi mint amit a békák csinálnak. Először egy kis golyóként ücsörögnek egy fűszálhoz tapadva, aztán növesztenek egy farkat és elkezdenek úszni. Aztán úszás közben kinő a lábuk és kijönnek a szárazra. Kicsit programozósabbra véve a folyamatot úgy cseréljük le az alaprendszert, hogy bizonyos alkotóelemeit cseréljük le, míg szép fokozatosan végül mindent lekapcsolunk ami a régi rendszerhez tartozott és mindent újra cserélünk.

Persze ennek a megközelítésnek is vannak problematikus elemei. Ha módosítunk az adatbázis felépítésén – márpedig valószínűleg erőteljesen módosítani fogunk – akkor lesznek olyan elemek amelyek átmeneti jelleggel kerülnek beépítésre. Például egy normalizálatlan táblában a stringként tárolt csoport nevek mellé ideiglenesen feleszünk egy csoport azonosítót. Egy ideig együtt futnak, majd idővel a stringet kivesszük a táblából. Igaz lesz ez az ideiglenes jelleg bizonyos funkciókra is. Ez pedig várhatóan elég sok plusz munkával fog járni. Ezzel szemben a rendszer átállítása fokozatos, bármilyen fennakadás elvileg kis fájdalommal korrigálható.

Ebben az esetben minden új funkciót az új rendszerben valósíthatunk meg, azaz ugyanazt az adathalmazt két külön alkalmazással piszkálunk és a usereket a két alkalmazás között folyamatosan ide-oda dobáljuk.

Konklúzió

Így vagy úgy egy komplett alaprendszer csere sehogy sem egy egyszerű vagy gyors mutatvány. Főleg ha a kiindulási állapot eléggé zagyva, nem használ semmiféle réteget, nincsenek jól elhatárolható modulok hanem minden össze van hányva. A probléma nem egyedi. Sok webes alapú vállalkozás gyorsabban növekszik mint ahogy eredetileg azt elképzelték volna. Változnak a körülmények az igények és a rendszer ami egy ideig jól futott szűkössé válik. Ha a rendszer nem elég rugalmas, dokumentálatlan vagy rosszul tervezett akkor bizony cserélni kell.

Te hogyan csinálnád?

5 thoughts on “Rendszerátépítés futás közben

  1. Ha nem szorítana anyagi kényszer, akkor nem vállalnám el. Inkább készítenék két tervet: az egyik az új rendszerről szólna, a másik pedig a régi rendszer adatainak átmigrálásáról, mindeközben minimális állásidővel.
    Persze ha muszáj elvállalni a fokozatos csere módszerével, akkor igen vastagon fogna a ceruzám, hiszen ez a munkamennyiség többszöröse annak, mint amit az első pontban vázoltam – ráadásul minden felelősséget előre az ügyfélre hárítanék, mert bármikor adódhat előre nem látható probléma, amiről a fejlesztő egyszerűen nem tehet.

  2. Ilyenkor mindig az a kérdésem, hogy hova tűnt az aki a rendszert kifejlesztette?

    Mondjuk én az első megoldást, a teljesen új rendszer + migrációt választanám. Persze a migrálás egy scripttel történne és arra kis időre le lehet állítani a rendszert. Tesztelésnél pedig természetesen ezt a scriptet is tesztelni kell.

  3. A fokozatosság elve jó, de úgy átírni egy részmodult (illetve nevezd aminek szeretnéd, ha már azt írtad, hogy a jelenlegi rendszer egy spagettikód), hogy vajon jól fog-e működni az új részre való áttéréskor jó kis szerencsejáték.

    Én biztos, hogy funkcionális, integrációs és unitteszteket készítenék minden lényeges részhez, és ennek birtokában nyugodtabb szívvel állítanám át a rendszert az új részmodulra. Ha tudom, hogy itt bemegy A ott meg B-nek kell kijönnie, s az új kódom is ezt csinálja, akkor nagy gondok nem lehetnek.

    Tény, hogy ez nagyon sok idő, és azt a legritkább esetben szeretik megfizetni a megrendelők.

  4. Kösz hogy leírtad, sokan találkozunk ilyen dolgokkal és tényleg nehéz a döntés.

    Nem kis csapás lesz kisimítani a kódot. Az írásodból nem érzem azt, hogy tényleges sebesség növekedés okozna az átépítés. Ez a módszer, szerintem még csak csavar egyet az amúgy is zavarós kódon.

    Szerintem ezzel többet fogsz szívni, mintha megírod 0-ról (az adatbázis újragondolva), és az adatokat átpumpálod bele.

    Milyen módszert használsz majd a betöltési idő csökkentésére?

  5. Pingback: WebMánia » Rendszerátépítés futás közben 2. lépés

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöljük.