Problemy z architekturą IT zaczynają się wcześniej, niż myślisz

‍‍Czy wiesz, kiedy najczęściej zaczynają się problemy z architekturą IT? Nie wtedy, kiedy firma już nie wyrabia. Wszystko zaczyna się chwilę wcześniej, kiedy systemy teoretycznie działają, ale nagle pojawiają się sygnały, że robi się gęsto. Zamówienia przechodzą, ale wolniej. Integracje działają, ale coraz częściej coś trzeba zrobić jednak ręcznie. Magazyn przesyła dane, ale co jakiś czas coś się przycina. To są momenty, które zwykle są bagatelizowane. Do czasu. Bo później zaczynają dziać się rzeczy, których już nie da się zignorować. Opóźnienia w eksporcie danych, blokujące się procesy, skoki obciążenia, spowolnione API. I nagle okazuje się, że to nie jest kwestia jednego błędu, tylko problem całej architektury, która została rozciągnięta do granic możliwości. Dlatego w tym odcinku skupimy się na praktyce. Jak rozpoznać, że system zaczyna pracować już na limitach? Jakie sygnały poprzedzają poważne problemy? Kiedy jest najlepszy moment na reakcję? Jakie działania faktycznie poprawiają sytuację, zanim będzie za późno? I warto zostać do końca, bo dopiero wtedy zobaczysz, jak to wszystko składa się w całość. Kanał IT i Biznes prowadzi firma Innovation. Rozwiązania technologiczne dopasowane do Twojego biznesu, ze wsparciem zewnętrznego dyrektora IT. Zapraszam, Grzegorz Tabor.
‍

Pierwsze sygnały przeciążenia systemów w produkcji, logistyce i dystrybucji

W firmach produkcyjnych, logistycznych i dystrybucyjnych, problemy ze skalowaniem prawie nigdy nie zaczynają się od dużej awarii. One pojawiają się dużo, dużo wcześniej, w takich drobnych, codziennych sytuacjach, które na początku wyglądają niegroźnie, ale są sygnałem, że systemy powoli tracą zapas. W produkcji bardzo często pierwszym sygnałem jest wydłużające się planowanie materiałów, zasobów. Proces, który wcześniej liczył się kilka minut, nagle potrzebuje 20-20 paru. Rośnie liczba operacji, zmienia się struktura BOM-ów, dochodzą nowe komponenty i system, który wcześniej działał płynnie, zaczyna pracować z obciążeniem. To jeszcze nie awaria, ale to już jest żółta lampka. W magazynach sytuacja wygląda podobnie. System WMS działa, ale nierówno. Jednego dnia pobranie zlecenia trwa ułamek sekundy, a drugiego już cztery. Skanery raz reagują natychmiast, a raz mają chwilową zawieszkę. Najczęściej dzieje się to wtedy, gdy firma z większą liczbą lokalizacji integruje kolejne marketplacy albo kiedy wolumen SKU zaczyna rosnąć szybciej niż zakładano. Dystrybucja ma swój charakterystyczny sygnał – opóźniające się stany magazynowe, a konkretniej aktualizacja. Kiedyś aktualizowały się co 5 minut, teraz co najmniej co 20 albo co godzinę. Zaczynają pojawiać się podwójne rezerwacje, produkty widmo, spóźnione wysyłki. Na pierwszy rzut oka drobiazg.

Gdy system przestaje dowozić: raporty, integracje i ręczne obejścia

W rzeczywistości jasna informacja, że architektura jest zwyczajnie zła. Kolejny sygnał pojawia się przy raportach. Raport jakościowy czy produkcyjny, który generował się kilka sekund, nagle potrzebuje co najmniej kilkunastu minut. Niby da się poczekać, ale to jest jasna informacja, że logika i dane przestały mieścić się w dotychczasowych ramach, na których bazie ten system był budowany czy wdrażany. Do tego dochodzą integracje ERPA, które zaczynają już zgłaszać time-outy albo wykonywać swoje zadania z coraz większym opóźnieniem. Czasem widać, że rezerwacje przechodzą coraz później. Kartoteki przetwarzają się w kolejce, która trwa bez końca, a synchronizacja stanu zwyczajnie nie nadąża za operacją. I to jest bardzo jasny sygnał, że system centralny nie jest w stanie już obsłużyć takiej ilości operacji w wymaganym czasie. Najbardziej niebezpieczny sygnał to ten, którego firmy często ignorują. Pojawia się ręczne obejście. Ktoś z magazynu coś popchnie do przodu, planista coś przeliczy w Excelu, ktoś z administracji restartuje jakiś proces, żeby po prostu już działało wszystko sprawniej. To ciche potwierdzenie, że system nie jest w stanie przeprowadzić procesu od początku do końca w sposób powtarzalny, jeśli się tego nie zatrzyma, to za chwilę ręczne obejścia staną się codziennością.

API zwalnia w piku - moment, w którym systemy pracują na granicy

No i jest jeszcze API, które w godzinach szczytu zaczyna działać skokowo. Rano odpowiedzi są szybkie, wszystkie systemy integrują się błyskawicznie, a w piku logistycznym potrafią rosnąć co najmniej do kilkudziesięciu sekund. To szczególnie dobrze widać w firmach, które współpracują z marketplace'ami, integratorami logistycznymi albo po prostu dużymi partnerami B2B. Wszystkie te sytuacje wydają się drobne, ale razem układają się w bardzo wyraźny obraz. To jest moment, w którym firma powinna zatrzymać się i powiedzieć OK, coś się kończy, coś trzeba przemyśleć, architektura już nie daje komfortowego marginesu i zwyczajnie nasze systemy nie działają szybko. Kiedy firma zaczyna widzieć, że systemy pracują na granicy, ważne jest, żeby nie reagować impulsywnie, tylko zatrzymać się i zrobić kilka bardzo konkretnych kroków.

Jak zdiagnozować wąskie gardło zamiast leczyć objawy

Te pierwsze dni nie mają na celu naprawienia systemu od razu, ale przede wszystkim dobrą diagnozę, czyli zrozumienie, gdzie naprawdę znajduje się wąskie gardło. Przejdziemy sobie przez to krok po kroku, tak jak na co dzień robimy to u klientów. Pierwsza rzecz, nie dotykamy samych systemów stricte już na dzień dobry, bo większość błędów systemowych to często tak naprawdę błędy procesowe, które dopiero potem odbijają się od użytej technologii. Zaczynamy od operacji. W praktyce wygląda to tak. Wsiadasz z magazynem, z planowaniem produkcji, z logistyką, z ludźmi od integracji i zadajesz jedno proste pytanie. W którym momencie dnia przestajecie ufać systemom? Jeśli dobrze przeprowadzisz ten proces, to masz mapę operacyjną tego, gdzie problem jest widoczny dla ludzi, a nie gdzie myślisz, że jest. Dopiero potem patrzymy na technologię i na tym etapie szukamy odpowiedzi na pytanie, w której warstwie jest wąskie gardło. Czyli innymi słowy, to co operacyjnie wygląda jak system zwalnia, technicznie bardzo często jest problemem jednej konkretnej warstwy używanych przez ciebie systemów, czy też technologii. Może to być infrastruktura, czyli wszystko to, co działa pod aplikacją, ale ma bezpośredni wpływ na jej wydajność. Mówimy tu m.in. o dostępie do bazy danych, o limitach połączeń, o różnych blokadach, o czasach odpowiedzi z tej bazy danych, skali wielkości samej bazy i tym, jak szybko da się z niej realnie odczytywać i zapisywać dane, o przeróżnych ograniczeniach sieciowych, opóźnieniach pomiędzy systemami na poziomie VPN-u na przykład, na poziomie przeróżnych firewalli, połączeniach między lokalizacjami czy różnymi centrami danych. I tu pojawia się ważna obserwacja. Bardzo często problem przypisywany aplikacji wcale nie leży w kodzie, tylko w tym zapleczu, które po prostu przestaje nadążać za tym, jak system jest używany wraz z tym, jak firma się rozwijała. Drugi obszar to architektura rozwiązania i sam kod, czyli moment, w którym warto zadać sobie pytanie, czy system jako całość nie stał się po prostu zbyt ciężki na obecny sposób jego użycia. W praktyce sprawdzamy m.in. czy te same operacje nie są liczone wielokrotnie w różnych miejscach systemu, czy kluczowe procesy nie są zbyt mocno ze sobą splecione i przez to wzajemnie się nie blokują, czy kolejne tzw. customizacje, czyli rozszerzenia systemów, szczególnie w systemach ERP, nie dokładają logiki, która działała przy mniejszej skali, ale przy większym wolumenie zaczyna realnie ciążyć na wydajności. I to często nie jest kwestia złego kodu, tylko samej architektury, która nigdy nie była projektowana pod dzisiejszą skalę biznesu. Trzeci obszar to ilość danych. Temat pozornie najprostszy, a jednocześnie najczęściej pomijany. W pewnym momencie system zaczyna zwalniać dlatego, że musi jednocześnie pracować na zbyt duże ilości danych operacyjnych i historycznych. Objawy są bardzo charakterystyczne. Raporty liczą się coraz dłużej, wyszukiwania i zestawienia zaczynają nie iść, operacje, które kiedyś były niemal natychmiastowe, robią się ciężkie, bo ciągną za sobą całą historię firmy. 

Trzy warstwy, w których najczęściej leży problem

Jeżeli nie rozdzielisz tych trzech warstw, infrastruktury, architektury i danych, bardzo łatwo zacząć leczyć objawy zamiast przyczyny. A na tym etapie chodzi wyłącznie o jedno. Ustalić, gdzie faktycznie jest wąskie gardło, czyli co faktycznie jest winne tym wszystkim obciążeniom. Gdy mamy zdiagnozowaną realną przyczynę, pojawia się kluczowe pytanie decyzyjne. Czy obecna architektura może jeszcze chwilę tak działać, czy właśnie zbliżamy się do granic jej możliwości? Bo mogą być tak naprawdę dwa scenariusze. Pierwszy, udało się te sygnały wychwycić odpowiednio wcześnie, jest spokojniejszy okres, nie ma dużych skoków wolumenów, nie ma szczytu sezonu, zamówienia są przewidywalne. W takiej sytuacji architektura, mimo, że już wysyła ostrzeżenia, może jeszcze pracować parę tygodni, czy nawet miesięcy, czy czasem nawet lat, bez ryzyka, że coś dużego się wysypie. Ale może być też zupełnie odwrotnie. Za chwilę wchodzicie w sezon. Nasza zamówienie rośnie, produkcja się zagęszcza, rusza kampania sprzedażowa, jedna, druga, trzecia, dołącza kolejny marketplace, albo otwiera się nowy magazyn. Jeśli architektura już teraz łapie zadyszkę, to trzeba podjąć doraźną decyzję, która ochroni firmę przed tym, co może wydarzyć się za dwa, trzy, czy nawet cztery tygodnie. Te działania na tym etapie nigdy nie powinny być wielką przebudową, ani żadnym projektem rewolucyjnym. To są drobne decyzje, które potrafią odciążyć systemy na tyle, żeby dana operacja mogła działać stabilnie. I tu bardzo ważna rzecz. Te decyzje nigdy nie są uniwersalne, niestety, bo systemy nie psują się w ten sam sposób. Dlatego od strony technicznej zawsze wracamy do tych trzech obszarów, o których przed chwilą powiedziałem. Jeżeli problem jest po stronie infrastruktury, często wystarczy zdjąć ograniczenia, które realnie go duszą. Poprawić dostęp do bazy danych, uporządkować, ustabilizować połączenia między systemami, zlikwidować wąskie gardła sieciowe. Jeśli źródłem problemu jest architektura rozwiązania, to znaczy, że system robi za dużo rzeczy na raz, albo w zbyt wielu miejscach robi to samo. I wtedy zamiast dokładać kolejne moduły czy integracje, sensowną decyzją bywa wydzielenie jednego krytycznego procesu, odciążenie systemu centralnego o ten właśnie proces, skrócenie ścieżki dla operacji, które muszą działać szybko i przewidywalnie. A jeśli problemem jest ilość danych, to żadna optymalizacja kodu nie pomoże w długim terminie. Tu rozwiązania są bardziej porządkowe. Oddzielenie danych bieżących od historycznych, archiwizacja, a czasem druga baza danych, podraportowanie czy historia. Najważniejsze jest jednak to, że każdy przypadek wygląda naprawdę zupełnie inaczej. Dlatego gdy pojawiają się pierwsze drobne problemy, warto je zgłaszać i drążyć wspólnie z IT, nawet jeśli na początku monitoringu nic nie widać, z naszej strony wszystko wygląda w porządku. I w tym miejscu warto doprecyzować jedno. Skalowanie to nie jest dokładanie kolejnych systemów ani technologii. W firmach produkcyjnych i logistycznych problemy bardzo rzadko biorą się z tego, że czegoś brakuje. One częściej biorą się z tego, że systemy są ze sobą zbyt ciasno powiązane i zaczynają się wzajemnie blokować. Dlatego skalowanie w praktyce polega na rozdzielaniu procesów, które nie muszą działać synchronicznie, zdejmowaniu systemów centralnych operacji, które nie są krytyczne w danym momencie i budowaniu takiego przepływu danych, który pozwala rosnąć bez reakcji łańcuchowych. Celem jest architektura, która nie jest krucha, która przy większym wolumenie nie zatrzymuje całej operacji. I dopiero, gdy firma ma taką architekturę, może spokojnie wejść w sezon, zwiększyć sprzedaż, otworzyć nowy magazyn bez stresu czy dodać kolejny kanał bez obaw, że wzrost sam w sobie stanie się problemem.

Skalowanie architektury to decyzje, nie checklisty

W skalowaniu architektury nie ma jednego przepisu, jednej checklisty, która działa wszędzie i zawsze. Każda firma ma inną specyfikę operacji, inną kolejność procesów, inny sposób pracy magazynu, inne integracje czy inną sezonowość. Dlatego zawsze trzeba zacząć od tego, co działa dobrze, czego nie ruszać, co już dziś jest na granicy i co za chwilę zacznie powodować problemy. Dopiero wtedy można podjąć właściwą decyzję, co odciążyć, co uporządkować, a co wynieść poza system centralny. Jeżeli widzisz, że wasza architektura zaczyna być na styk albo wiesz, że nadchodzi moment, w którym obciążenia rosną, to warto spojrzeć na to szerzej, zanim zrobi to za was operacyjna rzeczywistość. Jeśli chcesz porozmawiać o tym, jak przygotować architekturę pod wzrost, odezwij się. Chętnie pokażę, jak robimy to w praktyce w firmach produkcyjnych, logistycznych czy dystrybucyjnych. Tymczasem kończąc, serdecznie dzięki za dzisiejszy odcinek i do zobaczenia w następnym. Cześć.

‍

‍

‍

‍