Modernizacja i skalowanie systemów

Zmiana, która kiedyś zajmowała dwa dni, zajmuje dwa tygodnie, bo skutek dotknięcia jednego fragmentu przestał być przewidywalny. Wdrożenia stały się wydarzeniem: planowane wieczorem, z udziałem kilku osób. Dwóch programistów rozumie krytyczny komponent i tylko oni się do niego zbliżają. Rachunek za infrastrukturę urósł szybciej niż użycie i nikt nie potrafi wskazać przyczyny. Żadne z tego nie jest awarią. Razem oznacza to, że biznes porusza się w tempie swojego najstarszego systemu.

Zespoły zwykle wskazują komponent, przy którym pracuje się najgorzej, a to rzadko ten sam, który faktycznie Cię ogranicza. Moduł, którego nikt nie lubi, potrafi być zupełnie wystarczający przy obecnym obciążeniu, podczas gdy prawdziwy sufit siedzi w puli połączeń do bazy albo w nocnym zadaniu, którego czas wykonania po cichu rośnie razem z danymi.

Dlatego pierwszym krokiem jest test obciążeniowy dociskający system, aż coś ustąpi, plus analiza zapytań i śledzenie żądań przy realnym ruchu. Wynikiem jest konkretne ograniczenie i konkretna liczba. To zmienia rozmowę z „system jest stary” na „obsługujemy mniej więcej taką współbieżność, a granica jest tutaj”. To już da się zaplanować i wpisać w budżet.

Rozliczenia, powiadomienia, raportowanie, generowanie dokumentów, przetwarzanie plików: te obszary mają zwykle niewielki styk z resztą systemu, bo zawsze były w pewnym stopniu osobne w sposobie myślenia firmy. Wyjęcie jednego z nich to zamknięty kawałek pracy o sprawdzalnym efekcie. Cięcie w poprzek granicy, która nie istnieje (oddzielanie „części frontendowej” domeny od „części backendowej”), daje dwa komponenty, które muszą stale ze sobą rozmawiać, a wywołania funkcji zamieniają się w wywołania sieciowe, które mogą zawieść.

Pierwsze wydzielenie warto wybierać pod niskie ryzyko, a nie pod duże znaczenie. Jego zadaniem jest sprawdzić podejście, ustalić wzorce pracy i dać zespołowi pewność na czymś, co nie położy firmy, jeśli pójdzie źle.

Jedna baza obsługująca odczyty i zapisy, gdy dominuje ruch odczytowy. Jeden proces przetwarzający kolejkę, która czasem gwałtownie rośnie. Jeden serwer trzymający wgrane pliki na lokalnym dysku, co jest zarazem powodem, dla którego nie da się go zduplikować. Jedno synchroniczne wywołanie zewnętrznego API wewnątrz żądania, na które czeka użytkownik.

Każdy z tych przypadków ma dobrze znane rozwiązanie i żaden nie wymaga przepisania systemu. Wymagają wiedzy, który z nich ograniczy Cię pierwszy. Dlatego pomiar wyprzedza plan.

Brzmi to mało efektownie i właśnie to odróżnia modernizację, która się kończy, od tej, którą się anuluje. Długie programy bez takiego punktu pośrodku po cichu kumulują ryzyko i stają się niemożliwe do zatrzymania czy przekierowania. Gdy kontekst biznesowy się zmieni (a przy długim programie zmieni się na pewno), chcesz być w punkcie, w którym przerwanie jest opcją, a nie katastrofą.

To oznacza też, że korzyści pojawiają się stopniowo. Wdrażanie robi się łatwiejsze, zanim całość dobiegnie końca. Czasy odpowiedzi poprawiają się po pierwszej rundzie prac wydajnościowych, a nie na finiszu. To ma znaczenie, bo utrzymanie poparcia dla takiej pracy zależy od tego, czy ludzie widzą jej efekt przed ostatnim krokiem.

Jest jeszcze jeden powód, żeby trzymać się etapów: modernizacja prowadzona równolegle do rozwoju produktu zawsze konkuruje o tych samych ludzi. Praca podzielona na zamknięte kawałki daje się wstrzymać na kwartał, gdy pojawi się pilny temat biznesowy, i podjąć później bez zaczynania od nowa. Przebudowa prowadzona jako jeden wielki krok takiej możliwości nie daje. Albo trwa, albo przepada razem z włożonym w nią czasem.