Modernizacja systemów legacy, prowadzona bez wyłączania systemu z produkcji
Modernizacja systemów, których zmiana jest zbyt ryzykowna, a zamrożenie – zbyt kosztowne dla biznesu: inżynieria wsteczna, dekompozycja monolitu i przywracanie platform do sprawności, realizowane podczas pracy systemu. Systemy core banking i finansowe, platformy treści FMCG oraz ekosystemy e-commerce w retailu. Przejmujemy i stabilizujemy systemy produkcyjne tam, gdzie inne podejścia zawiodły – w tym w ramach publicznie opisanego ratowania platformy CMS o dużym ruchu dla Royal Canin.
Sygnały, że system kwalifikuje się do modernizacji
Nie każdy stary system wymaga tej samej interwencji, a część tego, co wydaje się nie do naprawienia, da się naprawić łatwiej, niż się wydaje. Oto objawy, które warto sprawdzić w pierwszej kolejności.
ZESPÓŁ
Osoby, które go zbudowały, odeszły. Nie ma dokumentacji, nie został nikt, kto pamięta, dlaczego system działa tak, a nie inaczej, a zapis podjętych decyzji odszedł razem z nimi.
HISTORIA
Próbowano przepisać system od nowa i po cichu z tego zrezygnowano. Budżet na zmianę platformy został wydany, część nowego rozwiązania wciąż działa równolegle, a nikt nie chce proponować tego samego po raz drugi.
RYZYKO
Wydania są zamrożone lub prawie zamrożone. Każda zmiana niesie ryzyko dla produkcji, każda wymaga akceptacji, a najbezpieczniejszą opcją w każdym kwartale jest nierobienie niczego.
KOSZTY
Koszty utrzymania rosną, a tempo dostarczania spada. Małe funkcje powstają miesiącami, a większość wysiłku idzie w to, by nie zepsuć tego, co już działa.
WIEDZA
Jedna lub dwie osoby mają cały system w głowie. W zwykłym tygodniu to wąskie gardło, a przy pierwszym przeglądzie regulacyjnym, który zapyta, kto mógłby go obsługiwać po ich odejściu – poważne zastrzeżenie.
PLAN
Na stole leży pełna wymiana systemu i wszyscy są zaniepokojeni. Platforma nie zniesie przestoju, którego wymagałaby wymiana, a ostatnia wycena była powodem, dla którego projekt utknął.
Rozpoznanie dwóch lub trzech z tych sygnałów to punkt wyjścia do oceny. Poniżej przedstawiamy kolejność, w jakiej się nimi zajmujemy – dobraną tak, by wyeliminować ryzyko, zanim zaczniemy zmieniać cokolwiek w strukturze.
Etapy, przez które przechodzimy, by ograniczyć ryzyko
Każdy etap eliminuje konkretne ryzyko, a nie tylko posuwa projekt do przodu. Są ułożone tak, by nie zmieniać niczego w strukturze, dopóki nie znikną czynniki, które czyniłyby to niebezpiecznym. Dowiedz się więcej podczas rozmowy z naszymi inżynierami.
1
Mapowanie (tylko odczyt)
Rzeczywiste działanie, zależności i przepływy danych – odczytane z kodu i zaobserwowane na produkcji, zamiast opierania się na starych diagramach. Obejmuje to również sposób, w jaki dziś zatwierdzane są zmiany, i to, kto ma dostęp do czego, bo oba te czynniki ograniczają wszystko, co nastąpi później. wyeliminowane ryzyko – zgadywanie, co się zepsuje.
2
Udowodnienie bezpieczeństwa
Testy charakteryzacyjne utrwalają obecne zachowanie systemu, zanim cokolwiek zostanie zrefaktoryzowane – zaczynając od najpoważniejszych ryzyk. Testy służą jednocześnie jako dowód, że zachowanie się nie zmieniło, czego wymaga komitet ds. wydań lub audytor. wyeliminowane ryzyko – zmiany, co do których można mieć tylko nadzieję, a nie pewność.
3
Podział na części
Wzorzec strangler, jedna funkcjonalność na raz – stary i nowy system działają równolegle, dopóki każdy fragment nie zostanie sprawdzony. Ruch jest przenoszony osobno dla każdej funkcjonalności, więc system działa i obsługuje sprzedaż przez cały czas trwania migracji. wyeliminowane ryzyko – jeden moment, w którym wszystko musi zadziałać naraz.
4
Przekazanie odpowiedzialności
Dokumentacja, runbooki i zespół, który ponownie rozumie system – utrzymywany przez nas długofalowo lub przekazany. Spisane w formie, która przetrwa audyt lub zmianę dostawcy, a nie tylko spotkanie przekazujące. wyeliminowane ryzyko – wiedza, która odchodzi wraz z końcem współpracy.
Każdy z powyższych etapów opiera się na określonym zestawie technik. Żadna z nich nie jest egzotyczna. Stosujemy je świadomie i we właściwej kolejności.
Inżynieria wsteczna
Analiza kodu, mapowanie zależności i przepływów danych oraz odtwarzanie zachowania systemu tam, gdzie brakuje dokumentacji.
Testy charakterystyki
Testy, które utrwalają obecne zachowanie przed refaktoryzacją, dzięki czemu modernizacja nie zmienia po cichu tego, na czym opiera się biznes. Te same testy służą jako dowód, że zachowanie się nie zmieniło.
Migracja według wzorca strangler
Stopniowa wymiana, z ruchem przekierowywanym osobno dla każdej funkcjonalności w miarę weryfikacji kolejnych części. Typowe podejście tam, gdzie platforma nie może sobie pozwolić na okno serwisowe.
Dekompozycja monolitu
Granice wyznaczane zgodnie z Domain-Driven Design, wydzielanie usług, warstwy antykorupcyjne i staranne projektowanie kontraktów.
Migracja danych
Ewolucja schematów, strategie podwójnego zapisu i uzupełniania danych (backfill), ciągłe uzgadnianie danych i przełączenia z minimalnym przestojem – z dowodami uzgodnień przechowywanymi na potrzeby audytu.
Przywracanie systemów do sprawności
Stabilizacja awaryjnych lub nieutrzymywanych platform, w tym systemów przejmowanych od poprzedniego dostawcy w trakcie trwającego incydentu.
Redukcja długu technicznego
Ukierunkowane naprawy priorytetyzowane według ryzyka biznesowego i częstotliwości zmian – zaczynając od elementów, które blokują wydania.
Planowanie migracji
Kolejność prac, strategia wycofania zmian, planowanie ciągłości działania oraz okna zmian dopasowane do cykli akceptacji wydań.
Umów się na bezpłatną konsultację z naszymi ekspertami i CTO
Porozmawiajmy o Twoich obecnych wyzwaniach i sprawdźmy, w czym możemy pomóc.
Sprawdzone na produkcji
- 0+
- globalnych środowisk obsługiwanych na produkcji
- 0%
- dostępności względem uzgodnionych SLO
- 0%
- niższe koszty chmury po przeglądzie FinOps
Systemy modernizowane i obsługiwane dla klientów z branży bankowej, FMCG i retail od 2008 roku
Jak zorganizowana jest współpraca – od pojedynczego audytu po pełną odpowiedzialność
Większość prac modernizacyjnych zaczyna się od jednego projektu czy usługi. Pozostałe szczeble są dostępne, gdy są potrzebne – nie trzeba się na nie decydować z góry.
Masz pytania dotyczące modernizacji systemów legacy?
Porozmawiajmy o planie modernizacji systemu, którego nie można wyłączyć, ale też nie można zostawić w obecnym stanie.
Rozmowa o systemie, który trudno zmienić, i o realistycznej, stopniowej ścieżce dalszego rozwoju.
