W ramach strategicznego przejęcia amerykańskiego startupu, twórcy zaawansowanej platformy analitycznej, światowy lider technologii reklamowych i Retail Media powierzył MARGO zadanie przejęcia kontroli nad tym krytycznym zasobem danych i jego integracji.
Platforma ta, kluczowa dla sieci handlowych, które monitorują dzięki niej wyniki swoich produktów, opierała się na złożonej i słabo udokumentowanej architekturze legacy, utrzymywanej początkowo przez zespół 40 inżynierów.
MARGO weszło do projektu w krytycznej fazie przejściowej, gdy zespół zmniejszył się już do 20 osób, i zaangażowało elitarną jednostkę inżynierską, aby przeprowadzić inżynierię wsteczną systemu, zagwarantować pełną ciągłość działania usług i pokierować strategią wygaszania aplikacji. Interwencja ta zabezpieczyła własność intelektualną przy drastycznym ograniczeniu zaangażowanych zasobów technicznych (z 40 do 3 inżynierów), zapewniając technologiczny sukces tej wymagającej integracji po fuzji i przejęciu (M&A).
Wyzwania: przejęcie kontroli nad krytycznym zasobem technologicznym w kontekście fuzji i przejęć
Przy przejęciu dług technologiczny przejmowanej spółki często stanowi poważne ryzyko. Po transakcji grupa musiała bezwzględnie odzyskać kontrolę nad docelową platformą: złożonym silnikiem analitycznym, który łączył dane z kampanii reklamowych, masowy web scraping i udostępnianie wyników w dashboardach.
Stawka wykraczała poza samo utrzymanie systemu w ruchu. Chodziło o rozbrojenie technologicznej „czarnej skrzynki”, tak by uniknąć jakiegokolwiek wpływu na biznes naszego klienta:
Ryzyko finansowe i wizerunkowe:
Nie dopuścić do utraty przez sieci handlowe wglądu w ich KPI efektywności.
Ryzyko operacyjne:
Zapewnić zespołom sprzedaży możliwość wspierania klientów rzetelnymi danymi w czasie rzeczywistym.
Ciągły rozwój:
Utrzymać tempo prac nad nowymi strategicznymi funkcjami, o które prosili klienci.
Ryzyko utraty własności intelektualnej (IP):
Przechwycić wiedzę biznesową o systemie utrzymywanym przez odchodzący zespół amerykański.
Cel: misja ratunkowa i strategiczne przekazanie wiedzy
Zadaniem MARGO nie było bezterminowe utrzymywanie starzejącej się infrastruktury, ale pokierowanie prawdziwą operacją ratowania technologii w przełomowym momencie. W tym niepewnym okresie przejściowym misja stała się wyzwaniem z zakresu odporności, opartym na trzech kluczowych filarach.
Przede wszystkim bezwzględnym priorytetem była ciągłość działania: zagwarantowanie „zero przestojów” (Zero Downtime), tak aby przejęcie platformy przebiegło płynnie i bezboleśnie dla sieci handlowych korzystających z niej na co dzień.
Następnie wyzwanie miało charakter ludzki i operacyjny: trzeba było uprzemysłowić niemożliwe – sprawić, by 3-osobowy zespół specjalny ekspertów MARGO przejął obciążenie i złożoność, którymi wcześniej zajmował się początkowy zespół 40 inżynierów.
Wreszcie misja była skierowana ku przyszłości. Nie chodziło tylko o „utrzymanie” systemu, ale o przygotowanie jego inteligentnego wygaszenia. Celem było przekształcenie złożonego i nieudokumentowanego kodu legacy w uporządkowaną bazę wiedzy. Wyodrębniając reguły obliczeń i schematy danych, MARGO umożliwiło wewnętrznym zespołom grupy przejęcie pałeczki i odtworzenie tych strategicznych funkcji we własnych standardach technologicznych, bez utraty know-how.
Podejście: industrializacja, mikrousługi i asynchroniczna zwinność
Aby osiągnąć tak wysoką efektywność, zespół MARGO zastąpił podejście manualne zdecydowaną industrializacją opartą na Google Cloud Platform (GCP) jako fundamencie infrastruktury.
Odporność dzięki orkiestracji (Kubernetes): ponieważ scraping na dużą skalę (co najmniej 2 mln stron internetowych dziennie, obejmujących produkty, kategorie i słowa kluczowe) jest z natury niestabilny, MARGO wykorzystało Kubernetes do izolowania każdego silnika zbierającego dane w efemerycznych kontenerach. W razie awarii scrapera infrastruktura naprawiała się sama, bez udziału człowieka, dzięki czemu niewielki zespół mógł obsługiwać ogromne przepływy danych.
Architektura mikrousług i komunikacja asynchroniczna (GCP Pub/Sub): architektura opierała się na rozdzielonych mikrousługach komunikujących się przez Google Cloud Pub/Sub. Ten model zapewnił wysoką skalowalność, większą odporność i niezależny rozwój usług mimo redukcji zespołu.
FinOps i skalowalność (BigQuery): aby obsłużyć duże wahania wolumenu danych typowe dla etapów migracji, architekturę ukierunkowano na model serverless z wykorzystaniem BigQuery. Zapewniło to użytkownikom Looker Studio stałą wydajność.
Asynchroniczny model zarządzania (Kanban): wobec ograniczeń wynikających z różnicy czasu ze Stanami Zjednoczonymi MARGO wprowadziło ścisłe ramy Kanban, eliminując wąskie gardła po stronie ludzi i zapewniając płynny transfer wiedzy.
Realizacja: 3 etapy wymagającego okresu przejściowego
Interwencja MARGO nie ograniczyła się do zwykłego utrzymania: przebiegała według metodycznego scenariusza, który przekształcił poważne ryzyko w udokumentowany sukces.
Etap 1: zanurzenie w projekcie i mapowanie ryzyk
Od pierwszego dnia wyzwaniem było opanowanie w rekordowym czasie złożonej architektury (Python, SQL, Angular, Django, PostgreSQL). Faza Flash Audit i transferu wiedzy pozwoliła zmapować ryzyka funkcjonalne i zabezpieczyć krytyczne dostępy, budując most wiedzy między odchodzącym zespołem amerykańskim a jednostką kryzysową MARGO.
Etap 2: industrializacja w służbie utrzymania (run)
Po opanowaniu platformy zespół przeszedł do fazy industrializacji. Cel: ustabilizować pipeline’y danych dzięki proaktywnemu monitoringowi i zautomatyzować ponowne uruchamianie przepływów. Stając się gwarantem danych, MARGO zapewniło zespołom sprzedaży wsparcie o wysokiej responsywności, dzięki czemu prośby klientów były obsługiwane bez opóźnień mimo znacznej redukcji pierwotnego zespołu technicznego. To właśnie na tym etapie potwierdzono zdolność do działania na dużą skalę: scraping kilku milionów stron dziennie.
Etap 3: wygaszenie i przekazanie dziedzictwa
Misja zakończyła się bezpieczną fazą wyłączenia systemu, przeprowadzoną wspólnie z zespołami SRE. Kluczowym osiągnięciem tego etapu jest inżynieria wsteczna: zespół MARGO sformalizował wszystkie procesy przetwarzania i reguły biznesowe. Dokumentując każdy KPI i każdy przepływ, zagwarantowaliśmy, że dziedzictwo danych i własność intelektualna startupu zostały w pełni zachowane i są gotowe do ponownej integracji z autorskimi rozwiązaniami naszego klienta.
Rezultaty: bezpieczna integracja i zwielokrotniona efektywność
Zespół MARGO bardzo szybko przejął kontrolę nad złożoną platformą i zapewnił jej stabilność w bardzo trudnym kontekście po przejęciu. Szybka reakcja na incydenty i rygor metodyczny okazały się decydującymi atutami.
Group Engineering Manager
Mierzysz się z podobnymi wyzwaniami? Skontaktuj się z nami!
Ta interwencja pokazuje, że MARGO potrafi działać nie tylko jako dostawca utrzymania operacyjnego, ale jako partner strategiczny w krytycznych fazach integracji technologicznej (Tech M&A).
Łącząc kompetencje chmurowe (GCP/Kubernetes/Pub-Sub), metodykę inżynierii wstecznej i operacyjny pragmatyzm, MARGO pozwoliło temu liderowi Retail Media zabezpieczyć kluczowy zasób biznesowy, a jednocześnie radykalnie zracjonalizować związane z nim koszty operacyjne.
Zamień swoje wyzwania w szanse dzięki innowacyjnym rozwiązaniom szytym na miarę!
Jak MARGO przekształca dług technologiczny w użyteczny zasób dokumentacyjny?
Przy przejęciu (M&A) kod legacy często jest czarną skrzynką. Podejście MARGO wykracza poza zwykłe utrzymanie operacyjne: nasi inżynierowie prowadzą funkcjonalną inżynierię wsteczną. Odszyfrowując i formalizując ukryte w kodzie reguły obliczania KPI przed wycofaniem systemu, przekształcamy przestarzałe oprogramowanie w przejrzystą bazę wiedzy, która pozwala odtworzyć strategiczne funkcje w docelowym stosie technologicznym klienta.
Dlaczego orkiestracja Kubernetes jest kluczowa dla przemysłowego web scrapingu?
Masowy scraping jest narażony na dużą zmienność docelowych serwisów e-commerce. Kubernetes pozwala odseparować od siebie poszczególne silniki zbierające dane. Taka samonaprawiająca się („self-healing”) architektura gwarantuje pełną odporność: procesy, które ulegną awarii, są automatycznie restartowane przez system, dzięki czemu bardzo mały zespół może obsługiwać ogromne przepływy danych przy minimalnym nakładzie ręcznego wsparcia.
Jakie korzyści daje architektura chmurowa „serverless” w fazie transformacji technologicznej?
Podczas migracji wolumeny pobieranych danych mogą gwałtownie i nieprzewidywalnie rosnąć. Przeniesienie obciążeń na technologię serverless, taką jak BigQuery (GCP), zastępuje sztywną infrastrukturę sprzętową elastyczną mocą obliczeniową rozliczaną według zużycia (podejście FinOps). Gwarantuje to użytkownikom końcowym optymalny czas odpowiedzi dashboardów nawet przy intensywnym przetwarzaniu, przy jednoczesnej kontroli kosztów chmury.
