Jak przeprowadziliśmy proces migracji marki Reserved do chmury

W ciągu ostatnich lat wiele zmieniło się w podejściu do architektury systemów technologicznych. Przejście do chmury przestało być „pieśnią przyszłości”, a stało się rzeczywistością dla wielu firm – szacuje się, że na początku 2021 r. z takich rozwiązań skorzystało już niemal 2/3 polskich przedsiębiorstw.

Za rozwiązaniami chmurowymi przemawia wiele zalet, wśród których na wyróżnienie zasługuje przede wszystkim możliwość rezygnacji z własnej infrastruktury IT i poświęcania zasobów na jej utrzymanie. W zespole IT już pod marką Silky Coders świetnie opanowaliśmy clouda przeprowadzając do niego kolejny, tym razem flagowy brand LPP. O kulisach migracji wykonanej dla Reserved dowiecie się z poniższego artykułu.

Agata Mielewczyk. IT Project Manager, z LPP związana od ponad 6 lat, od prawie 3,5 zasila szeregi zespołu IT. W Silky Coders prowadzi kluczowe projekty takie jak roll-out RFID oraz rozwój w obszarze magazynów e-commerce.

Michał Kocieniewski. Od 10 lat związany z wytwarzaniem oprogramowania. Pracował jako programista w różnych technologiach, później samodzielnie prowadził zespół. Oprócz studiów informatycznych skończył zarządzanie projektami IT oraz MBA. Większość kariery zawodowej spędził w branży edukacyjnej. Obecnie pracuje jako DevOps Team Leader w firmie Silky Coders w zespole odpowiedzialnym za rozwój infrastruktury produkcyjnej e-commerce.

---

Jako spółka Silky Coders mamy stosunkowo krótką historię, ale równocześnie interesujący background. W odpowiedzi na rosnące w ogromnym tempie potrzeby biznesowe oraz postępujący nieustannie rozwój narzędzi cyfrowych, w kwietniu 2021 r. zarząd LPP podjął decyzję o wydzieleniu ponad 400-osobowej ekipy specjalistów ds. IT i stworzeniu zupełnie nowej spółki – wspomnianej Silky Coders.

Działając obecnie jako odrębny software house wspieramy rozwój m.in. kanałów sprzedaży online oraz offline i usprawniamy procesy logistyki oraz customer care marek Reserved, Cropp, House, Mohito i Sinsay należących do naszej spółki-matki. Można rzec, że ułatwiamy pracę niemal 22 tys. osobom zatrudnionym przez LPP oraz umożliwiamy wygodne zakupy milionom klientów w krajach Europy, Azji i Afryki, dostarczając spółce rozwiązania „skrojone na miarę”.

Jednym z najważniejszych obszarów, które realizujemy dla LPP, jest sfinalizowanie planu przeniesienia wszystkich brandów w całości do chmury.

Po co w ogóle nam chmura?

Ogromna dynamika rozwoju biznesu LPP w obszarze e-commerce spowodowała, że infrastruktura informatyczna przestała nadążać za zwiększonym ruchem na stronach www. Było to wynikiem nie tylko rosnącej popularności marek przed 2020 r., ale też skutkiem pandemii, kiedy to zakupy przeniosły się na kilka miesięcy właściwie wyłącznie do kanału online. Ponieważ duży ruch dawał się we znaki głównie podczas okresów wyprzedażowych (czyli czerwiec i grudzień), a także wszelkiego rodzaju akcji sprzedażowych jak chociażby Black Friday (listopad) czy też back to school (końcówka sierpnia), mieliśmy świadomość, że migracji nie możemy odkładać na później.

Dalszy ruch mógł bowiem jedynie rosnąć i pogłębiać kolejne wyzwania. W przypadku flagowego brandu LPP, jakim jest Reserved, stawało się to wręcz niecierpiącą zwłoki koniecznością.

Odpowiedzią na te wyzwania było wdrożenie rozwiązania skalowalnego, które elastycznie dopasowywać możemy do aktualnego zapotrzebowania biznesu LPP – naturalnym wyborem była więc chmura.

Reserved w obłokach

Umiejętności zarządzania projektami migracji zdobyliśmy przy okazji przeniesienia do chmury innych brandów LPP, tj. Mohito, Cropp i Sinsay, które jeszcze jako dział IT gdańskiej spółki odzieżowej przeprowadziliśmy w 2019 i 2020 r. To doświadczenie zaprocentowało i mogliśmy je z powodzeniem wykorzystać przy kolejnych pracach na drodze do chmury.

Mimo że analogiczne projekty przeprowadzaliśmy już kilka razy, planując tym razem migrację Reserved byliśmy świadomi szeregu wyzwań, stojących za tak znaczącym (i wymagającym odpowiednich zasobów) projektem. Warto pamiętać też, że ruch w internecie ciągle rośnie, a to rodzi za sobą kolejne wyzwania związane z wydajnością.

Naszym głównym celem była migracja usług Reserved i sklepu www na nową infrastrukturę, ale w planach mieliśmy też migrację usług powiązanych (np. procesy backoffice czy aplikacje zależne, np. Store Vision). Kluczowe było dla nas utrzymanie wydajności serwisu.

Intensywny okres przygotowań

Najważniejszy zatem był etap jak najlepszego przygotowania się do wdrożenia projektu. Nie chodzi tutaj jedynie o development funkcjonalności w odpowiednim momencie, ale również o samą migrację. Zrobiliśmy to poprzez zaangażowanie wszystkich zespołów (posiadających zróżnicowane kompetencje), przeprowadzenie odpowiedniej analizy ryzyk i zabezpieczenie się przed nimi. Musieliśmy zyskać pewność, że zaadresowaliśmy wszystkie obszary i przewidzieliśmy wszystkie scenariusze oraz że posiadamy plan na wypadek niespodziewanych sytuacji.

Ważnym aspektem organizacyjnym była decyzja o przydzieleniu do tej migracji dedykowanego kierownika projektu. Uprzednio odpowiedzialność za koordynację przejścia danego brandu do chmury spoczywała głównie na zespole DevOps. Teraz postanowiliśmy odseparować administrację projektową od działań operacyjnych dotyczących samej migracji w sensie technicznym. Ten krok pozwolił odciążyć zespół i zadbać o lepszą komunikację z pozostałymi interesariuszami projektu.

W celu jeszcze lepszego zabezpieczenia się przed teoretycznymi ryzykami, sposoby realizacji kluczowych kroków migracji zweryfikowaliśmy wcześniej na testowej infrastrukturze. Możliwych dróg realizacji projektu było kilka, ale dzięki testom byliśmy gotowi na użycie każdej z nich w momencie migracji.

Rekordowy time-to-market

Jednym z kluczowych wyzwań – jak się to często w branży IT zdarza – był czas. Podczas realizacji projektu musieliśmy dopasować się do kalendarza biznesowego LPP – zdążyć z realizacją całości w okresie zmniejszonego ruchu pomiędzy wyprzedażami letnimi a jesiennym sezonem back to school.

Decyzja o migracji Reserved została podjęta w maju, a musieliśmy zdążyć przed końcem sierpnia, więc mieliśmy cztery miesiące. Wszystkie prace należało zaplanować z chirurgiczną precyzją i odpowiednio w czasie realizować.

Zaczęliśmy od spisania wszystkich tasków potrzebnych do migracji i podzieliliśmy je według metody priorytetyzacji zadań MoSCoW. Wiedzieliśmy, że nie wszystkie zadania uda nam się ukończyć w zakładanym czasie, ale też nie wszystkie były do migracji niezbędne.

Niezwykle istotne było osiągnięcie odpowiedniej wydajności poszczególnych elementów systemu i skrócenie czasu trwania procesów (na przykład Przetwarzania Nocnego). Chcieliśmy mieć pewność, że wszystkie usługi będą pracować w określonych ramach czasowych tak, żeby nie zakłócać dostępu do platformy www klientom Reserved.

Koordynacja prac różnych zespołów

W toku prac przeanalizowaliśmy wszystkie procesy, na które migracja miała mieć wpływ i skontaktowaliśmy się z zespołami odpowiedzialnymi za każdy z nich. Mimo że największy ciężar prac spoczywał na zespole DevOps, to projekt nie mógłby zostać zrealizowany tak sprawnie, gdyby nie wkład pozostałych zespołów, m.in. developerów, administratorów, zespołu QA, RMS, BI czy osób z biznesu (sales), które wspierały nas w testowaniu i monitorowaniu prawidłowego funkcjonowania całej platformy sprzedażowej.

Dwa razy w tygodniu spotykaliśmy się na statusy ze wszystkimi zespołami zaangażowanymi w projekt – dzięki temu na bieżąco monitorowaliśmy postęp prac, odpowiadaliśmy na pojawiające się pytania i interweniowaliśmy, jeśli pojawiła się taka potrzeba.

Ponieważ uczestnicy projektu nie zajmowali się jedynie zadaniami związanymi z migracją Reserved do GCP, dużym wyzwaniem było skoordynowanie wszystkich prac, żeby zakończyć je na czas. Niezbędna była zatem priorytetyzacja. Oprócz samego developmentu musieliśmy przeprowadzić też szereg prac analitycznych, które w efekcie pozwoliły nam na optymalizację zapytań na bazach, co finalnie przełożyło się na przyspieszenie ich działania.

Tuż przed przepięciem dopilnowaliśmy, aby docelowe rozwiązanie zostało jak najdokładniej przetestowane, co pozwoliło uniknąć poważnych problemów w trakcie samego przepięcia. Prowadziliśmy bardzo szczegółową dokumentację projektu, co pozwoliło nam bez problemu zapanować nad wszystkimi pracami, które działy się równolegle w różnych obszarach.

Oferty pracy z

Ready, set… go!

Tuż przed wyznaczonym terminem migracji spotkaliśmy się na ostatni status, na którym wszyscy członkowie zespołu potwierdzili, że są gotowi do jej rozpoczęcia. Sama migracja została zaplanowana na godziny nocne – dzięki temu nie miała aż tak dużego wpływu na możliwość dokonywania zakupów przez klientów Reserved (ruch na stronie www jest oczywiście znacznie mniejszy od godzin późnowieczornych do porannych).

Plan samej nocnej migracji składał się z ponad 70 punktów, a poszczególne etapy były rozpisane co do minuty. Odpowiedzialności za nie były przypisane imiennie.

To przygotowanie do wdrożenia podzieliliśmy na trzy główne etapy:

1. „Przed” – oprócz przygotowania całej potrzebnej infrastruktury oraz testów, ten etap obejmował również zapewnienie odpowiednich dostępów, określenie zespołu „głównego” do przepięcia, a także osób wspierających, backupowych, weryfikację IP, portów i połączeń, odpowiednie przygotowanie baz, a także komunikację do wszystkich zespołów, na które migracja będzie miała wpływ.
2. „W trakcie” – na tym etapie przepinaliśmy oczywiście całość serwisu z fizycznych serwerów do chmury. Bardzo ważna była komunikacja pomiędzy poszczególnymi osobami odpowiedzialnymi za kolejne etapy. Na bieżąco monitorowany był stan baz danych. Zmienialiśmy odpowiednie konfiguracje, co od razu na bieżąco testowaliśmy. Na sam koniec włączyliśmy docelową komunikację.
3. „Po” – po zakończeniu migracji upewniliśmy się, że całość komunikacji przebiegła poprawnie. Musieliśmy również uporać się z kilkoma małymi błędami, które wyszły w trakcie procesu, ale nie były one krytyczne.

Ta (czwarta już) migracja brandu LPP do chmury przebiegła nadzwyczaj sprawnie dzięki – między innymi – poszerzeniu zespołu projektowego oraz świetnemu przygotowaniu, a strona www była z powrotem dostępna dla klientów Reserved nawet przed zaplanowaną godziną!

Co zmieniła chmura? Najważniejsze wnioski i korzyści

Przeniesienie brandów do chmury pozwala być dużo bardziej skalowalnym i skuteczniej nadążać za biznesem. Zapewnia większą elastyczność w zarządzaniu potrzebnymi zasobami, ponieważ daje prawie natychmiastowy dostęp do zasobów Data Center Google’a. W standardowej serwerowni byłoby to niemożliwe.

Na nowym rozwiązaniu zyskujemy nie tylko my (unikanie konieczności inwestowania milionów złotych na nowy sprzęt wykorzystywany jedynie przez kilka dni w roku), ale również klienci, którzy mają dzięki niemu jeszcze większą wygodę w korzystaniu ze sklepów online marek LPP.

Wśród wniosków, jakie będziemy wykorzystywać przy dalszych projektach (nie tylko tych związanych z cloudami) nasuwa się jeden kluczowy – bardzo ważne jest skrupulatne przygotowanie się do migracji (a właściwie do każdego wdrożenia).

Migracja Reserved do chmury nie była pierwszą, który realizowaliśmy, ale w przypadku tak złożonego i krytycznego biznesowo projektu zawsze musimy liczyć się z tym, że zmaterializują się jakieś nieznane ryzyka. To, co ważne w takich sytuacjach, to mieć „przygotowany” cross-kompetencyjny, zaangażowany i doświadczony zespół specjalistów, który wszelkie problemy będzie w stanie rozwiązać w możliwie krótkim czasie, aby nie ucierpiała na tym ciągłość biznesu. W przypadku tego projektu z dumą możemy powiedzieć, że nasz zespół spisał się na medal!

Co dalej? Plany Silky Coders na 2022 r.

Na początku przyszłego roku planujemy pracę nad migracją do chmury ostatniego brandu LPP – House. Będzie to historyczny moment zamknięcia pewnego ważnego rozdziału w historii Silky Coders. Nie oznacza on całkowitej rezygnacji z rozwiązań on-premise, ale odciążenie ich z bardzo istotnego elementu biznesu naszej spółki-matki – e-commerce’u.

Nie będzie to jednak ostatnie słowo firmy w kontekście prac związanych z rozwiązaniami chmurowymi. Mamy apetyt ma rozwiązanie multicloud, więc przed nami kolejne migracje. Chcemy zrealizować ten projekt, by nie być zależnym od jednego dostawcy usług, a tym samym zwiększać dostępność platformy sprzedażowej dla klientów LPP. Z takim modelem oczywiście wiążą się nowe wyzwania związane z architekturą systemów. Przed nami więc wciąż sporo nauki i wychodzenia naprzeciw wymaganiom LPP, której biznes nadal dynamicznie się rozwija.