Legacy rendszer korszerűsítése teljes újraírás nélkül

Egy régi rendszer nehezen karbantartható, mégis nélkülözhetetlen lehet a vállalat számára. Árakat, kivételeket és soha teljesen le nem írt munkafolyamatokat őriz. A teljes újraírás tiszta kezdetet ígér, de a hosszú fejlesztés alatt az eredeti rendszer tovább változik. Az új változat mozgó célt követ.

Biztonságosabb egy üzleti képességet egyszerre korszerűsíteni. Egy új elem átvesz egy pontosan kijelölt kérést. A régi út elérhető marad, az irányítás pedig visszaállítható. A felhasználóknak nem kell megvárniuk azt a napot, amikor minden elkészül.

1. 01

   1. Mérje fel a viselkedést

   Folyamatok, hibák, teljesítmény és adattulajdon.

2. 02

   2. Hozzon létre határt

   Facade vagy adapter a régi rendszer elé.

3. 03

   3. Migráljon egy folyamatot

   Értékes, de kezelhető szelettel kezdjen.

4. 04

   4. Hasonlítsa össze az eredményt

   Szerződések, párhuzamos futás és üzleti ciklus.

5. 05

   5. Vezesse ki a régi utat

   Csak bizonyíték, monitoring és rollback próba után.

Először a valódi működést értsük meg

A dokumentáció a szándékot írja le. Az éles rendszer a valóságot mutatja. Beavatkozás előtt fel kell térképezni a használt képernyőket, időzített feladatokat, integrációkat, hibautakat és kézi javításokat. Egy mellékesnek tűnő export lehet az a fájl, amelyre a könyvelés havonta támaszkodik.

Az audit ne enciklopédiát készítsen. A kritikus folyamatok, adattulajdonosok és drága változtatási pontok térképe szükséges. Minden folyamathoz megfigyelhető viselkedés tartozik. Rögzíteni kell a helyes eredményt, a fontos kivételeket és a szolgáltatói kiesés kezelését.

Ez a lista lesz a regressziós tesztek alapja. A viselkedést védjük, nem a régi kódszerkezetet. Ha a régi alkalmazás szokatlanul, de szerződés szerint helyesen számol kedvezményt, az új rendszer üzleti döntés nélkül nem javíthatja ki csendben.

Keressünk átvehető határt

Használható illesztés lehet API-útvonal, képernyő, fájlimport vagy esemény. A régi és új megvalósítás elé tett homlokzat eldönti, hová küldje a kérést. A külső szerződés stabil marad, miközben a belső részek lépésekben cserélődnek.

Az első jelölt ne automatikusan a legnehezebb modul legyen. Jobb pilot az, amelynek egyértelmű tulajdonosa, mérhető eredménye és kevés függősége van. Ezen bizonyítható a telepítés, megfigyelés és visszaállás, mielőtt a működési maghoz nyúlnánk.

A határ azt is megakadályozza, hogy az új kód mindenhol örökölje a régi adatmodellt. Fordító réteg alakíthatja a régi azonosítókat és állapotokat az új domén nyelvére. Az eltávolítás feltételét előre rögzíteni kell.

Minden ténynek egy forrása legyen

A fokozatos átállás legnagyobb kockázata akkor jelenik meg, amikor mindkét rendszer ugyanazt az adatot írhatja. Az eltérés akár egy hétig rejtve maradhat. Minden átállított folyamathoz egy kijelölt nyilvántartó rendszer kell. A másik oldal kaphat olvasási másolatot, de nem birtokolja a döntést.

Az adattulajdon áthelyezése külön lépés. Először a mezőtérképet és az adatminőséget ellenőrizzük. Ezután ismételhető folyamat mozgatja a rekordokat, amely megszakítás után biztonságosan folytatható. Átkapcsoláskor a régi oldali írás leáll vagy az új szerződésen keresztül halad.

Az alkalmazásból végzett kettős írás csábító, de törékeny. Részleges kiesés eltérő állapotokat hagy. Egy megerősített változás és megbízható, ismételhető kézbesítés könnyebben ellenőrizhető. Ehhez is kell késésfigyelés és hibás üzeneteket fogadó hely.

A párhuzamos futás bizonyítékot ad

Számításoknál a régi és új megvalósítás egy ideig ugyanazt a bemenetet dolgozhatja fel. A felhasználó továbbra is a bevált eredményt kapja, a rendszer pedig összeveti a kimeneteket. Az eltéréseket hibára, elfogadott szabályváltozásra vagy rossz történeti adat következményére bontjuk.

Bizonyos műveletek soha nem futhatnak kétszer. Fizetést vagy ügyfélnek küldött emailt nem ismétlünk meg összehasonlításért. Rögzített bemenet, mellékhatás nélküli árnyékfutás vagy éles példákból épített szerződésteszt használható.

Az átkapcsolás feltételét a próba előtt egyeztetjük. Tartalmazhat meghatározott számú megmagyarázatlan eltérés nélküli esetet, válaszidőt és elveszett esemény nélküli működést. Az, hogy az új rész jónak tűnik, nem üzemeltetési feltétel.

A visszaállást az incidens előtt tervezzük

Minden szakasznak kis hibahatása legyen. Egy forgalmi kapcsoló visszaküldheti a kéréseket a régi útra. Az adatbázis-módosítások az átmenet alatt kompatibilisek maradnak, így a régi fogyasztó nem áll le az új séma telepítésekor.

A visszaállás nem mindig egyszerű funkciókapcsoló. Ha az új rendszer olyan rekordokat hozott létre, amelyeket a régi nem olvas, a kikapcsolás elérhetetlenné teheti az elkészült munkát. A terv meghatározza a visszaállási időt, az új adatok kezelését és a döntés jogosultját.

Sikeres szakasz után a régi utat el kell távolítani. Különben a vállalat tartósan két rendszerért fizet. Feltétel lehet a lezárt visszaállási időszak, egyeztetett pénzügyi eredmény és a folyamattulajdonos jóváhagyása.

1. 01

   Teljes újraírás

   Kis terjedelemnél, ismert szabályoknál és rövid együttélésnél indokolt.

2. 02

   Fokozatos csere

   Védi a folyamatos változást, a tisztázatlan működést és az üzletileg szükséges rendszert.

Mikor lehet helyes a teljes újraírás

A fokozatos korszerűsítés nem dogma. Teljes újraírás illhet kis alkalmazáshoz, rövid életű adatokhoz, stabil terjedelemhez és olyan átmenethez, amely alatt a változtatások megállíthatók. A régi platformot kizáró szabályozás is értelmetlenné teheti a hosszú együttélést.

Ekkor is le kell írni a jelenlegi viselkedést, az adatmigrációt és a visszautat. A tiszta repository nem szünteti meg az üzleti kockázatot. Csak megváltoztatja, hogyan találkozik vele a csapat.

Nagy, élő terméknél az üzleti képességenkénti szállítás könnyebben irányítható. A vállalat hamarabb kap eredményt, a következő döntések pedig éles adatokon alapulnak. A nyilvános Slates esettanulmány megmutatja, milyen gondosság kell egy régebbi platform újjáépítéséhez és teszteléséhez. Nem állítja, hogy minden rendszer azonos migrációs mintát követ.

A korszerűsítés irányított változás

Minden technikai szakaszt üzleti eredményhez kell kötni. Rövidítheti a dokumentumfeldolgozást, kivonhat egy nem támogatott adatbázist vagy csökkentheti a kézi javítást. Az eredmény megmutatja, érdemes-e azonos irányban folytatni.

Az új részek modulárisak maradhatnak, majd bizonyíték alapján külön szolgáltatássá válhatnak. A moduláris monolit és a mikroszolgáltatások közötti döntést az üzemeltetési igények vezessék. A megvalósítást szoftverkorszerűsítési szolgáltatásként vállaljuk.

A siker nem az utolsó régi sor törlése. Akkor érkezik el, amikor a vállalat biztonságosan módosít fontos folyamatokat, az üzemeltetés érti a hibákat, és az örökölt kockázat kiadásról kiadásra csökken. A haladást ezért jobb átállított folyamatokban, kevesebb kézi beavatkozásban, gyorsabb helyreállításban és kikapcsolt régi részekben mérni.

Minden szakaszhoz egyértelmű lezárási feltétel kell. Enélkül az ideiglenes homlokzat, adatszinkron és régi út évekig megmarad. A feltétel tegye láthatóvá, mikor bizonyított az új működés, mikor jár le a visszaállási idő és ki hagyja jóvá a régi rész kikapcsolását.

Rövid válasz

Ne azzal kezdje, hogy szép-e a régi kód. Azt a működési folyamatot keresse, amely pénzt, bizalmat vagy szabályváltoztatási lehetőséget visz el. Stabilizáljon először, ha az incidenseket kell megállítani. Refaktorálás illik egy körülhatárolt, ismert viselkedésű problémához. A fokozatos csere élő rendszerhez illik. SaaS átvehet egy szabványos folyamatot. A teljes újraírás inkább kis, stabil terjedelemhez való.

Döntési mátrix a korszerűsítéshez

Egy döntés több választást is összeköthet. Stabilizálhatja a belépést, refaktorálhat egy árszabályt és szakaszosan cserélheti a rendeléseket. A szoftverkorszerűsítés ezért döntési határokkal indul, nem technológiai listával.

Üzleti és műszaki jelzések

Üzleti jelzés az ismételt kézi javítás, a kiesés alatti elveszett értékesítés, a késő zárás vagy egy szabály, amelyet senki sem mer módosítani. Műszaki jelzés a nem támogatott adatbázis, felelős nélküli integráció, gyenge mentés vagy félelmetes telepítés. Mindkét fajta bizonyítékot gyűjtse össze. Egyik nélkül vagy drága technikai rend, vagy üzemeltethetetlen gyors javítás születik.

Függőségek és adatok felmérése

Minden folyamathoz írja le a bemenetet, kimenetet, felelőst, nyilvántartó rendszert, időfüggést és kézi kerülőt. Ellenőrizze a szolgáltatói hozzáférést, licenceket, kötegelt feladatokat, exportokat és felhasználói fiókokat. Személyes vagy pénzügyi adatnál legyen világos, ki módosíthat, hogyan naplózzák a döntést és hiba után hogyan áll vissza az állapot. A biztonsági oldal segít a hozzáférési kérdésekben.

Teljes birtoklási költség és migrációs kockázat

A teljes birtoklási költség nem csak a fejlesztési ár. Számít az üzemeltetés, támogatás, licenc, infrastruktúra, képzés, párhuzamos futás és a vezetői idő a viták rendezésére. Határozza meg a migráció legrosszabb elfogadható hatását, majd azt is, mi észleli ezt az ügyfél előtt. A kalkulátor a lehetséges haszon első kerete, nem ígért megtérülés.

Szerződések és átvételi feltételek

Fejlesztés előtt kérdezze meg, mely kimeneteket kell megőrizni, mely régi kivételek tudatos szabályok és ki hagy jóvá egy változást. Az átvételi feltételekhez mintaadat, hibamérés, jóváhagyó és eltéréskezelés kell. Régi rendszer átvételekor az audit új felismerései módosíthatják a terjedelmet. Az üzleti feltételek leírják az átlátható eljárást.

Szakaszos terv és visszaállítási terv

Az első szakasz egy kis folyamatot adjon egyértelmű eredménnyel. Kiadás előtt készítsen szerződésteszteket, megfigyelést, forgalomirányítást és döntési felelőst. Átkapcsolás után figyelje az eredményt, késést és kézi beavatkozást. A visszaállítási terv megnevezi az időablakot, az új adatok kezelését és a jóváhagyót. A régi folyamat csak ezután kapcsolható ki.

Belső egyetértés

A következő szakasz előtt erősítsen meg négy tulajdonosi döntést:

• A vezetés megerősíti a várt üzleti eredményt, a költségvetési plafont és a döntés szponzorát.
• A folyamatgazda megerősíti a jelenlegi működést, az engedélyezett kivételeket és az átvételi feltételeket.
• Az üzemeltetés megerősíti a kiadás felelősét, a visszaállítási tervet és az incidens felelősségét.
• A pénzügy megerősíti a teljes birtoklási költség feltételezéseit és a szakasz leállítási határát.

Így a szabályvita még a termelési változás előtt láthatóvá válik.

Korlátok és következő lépés

Egy audit sem talál meg minden rejtett szabályt. Párhuzamos futás nem biztonságos fizetésnél vagy ügyfélüzenetnél. A SaaS nem helyettesíti azt a folyamatot, amely az Ön megkülönböztetését adja. Kezdjen egy folyamattal, döntési mátrixszal és megnevezett felelősökkel. További gyakorlati döntéseket talál a Rise blogban.