Firmy działające w kilku lokalizacjach jednocześnie polegają na tym, że dane — stany magazynowe, zamówienia, kartoteki klientów — są spójne między oddziałami. Utrata synchronizacji prowadzi do rozbieżności, które trudno później uzgodnić.

Objaw

Dane w jednym oddziale przestają odzwierciedlać zmiany wprowadzone w drugim — stan magazynowy pokazuje różne liczby w zależności od lokalizacji, albo zamówienia widoczne w jednym miejscu nie pojawiają się w drugim.

Co sprawdzamy w pierwszej kolejności

Stan połączenia sieciowego lub internetowego między oddziałami.
Logi mechanizmu synchronizacji wskazujące moment, w którym proces się zatrzymał.
Konfigurację usługi odpowiedzialnej za wymianę danych między lokalizacjami.
Zakres rozbieżności — jak długo dane nie były synchronizowane.

Co robimy

Diagnoza lokalizuje moment i przyczynę przerwania synchronizacji. Po naprawie połączenia lub konfiguracji wykonywana jest ręczna synchronizacja zaległych danych, a rozbieżności między oddziałami są uzgadniane z udziałem osób odpowiedzialnych za dany zakres danych.

Ile to trwa

Diagnoza i naprawa mieszczą się z reguły w standardowym czasie do 3 dni, w zależności od zakresu rozbieżności do uzgodnienia.

Warunki

Diagnoza komputera stacjonarnego door-to-door kosztuje 200 zł i wlicza się w cenę naprawy. Dojazd na terenie Warszawy i okolic jest bezpłatny, a naprawa objęta jest gwarancją do 12 miesięcy.

Warianty problemu — różne typy utraty synchronizacji

Nie każda utrata synchronizacji wygląda tak samo. Sposób, w jaki dane przestają być spójne między lokalizacjami, zależy od architektury systemu i od tego, na jakim etapie wymiana danych się zatrzymała. Poniżej opisane są warianty, z którymi spotykamy się najczęściej.

Synchronizacja zatrzymała się całkowicie

Usługa odpowiedzialna za wymianę danych między oddziałami przestała działać — na przykład po aktualizacji systemu operacyjnego, restarcie serwera lub wygaśnięciu certyfikatu połączenia VPN (wirtualnej sieci prywatnej łączącej lokalizacje przez internet). W logach widać konkretny moment zatrzymania, a dane po obu stronach rozjeżdżają się od tej chwili. Jest to wariant stosunkowo prosty do naprawy, ponieważ wiadomo, od kiedy trzeba uzgodnić zmiany.

Synchronizacja działa, ale z opóźnieniem

Dane docierają między oddziałami, lecz z kilkugodzinnym lub kilkudniowym opóźnieniem zamiast w ciągu kilku sekund czy minut. Przyczyna leży zwykle w przeciążonym łączu internetowym, w zbyt dużej kolejce dokumentów oczekujących na przesłanie albo w harmonogramie synchronizacji ustawionym na zbyt rzadkie interwały. Pracownicy widzą nieaktualne stany magazynowe i mogą sprzedać towar, którego fizycznie już nie ma.

Synchronizacja powoduje konflikty

Ten sam rekord — na przykład kartoteka klienta lub pozycja zamówienia — został zmodyfikowany w dwóch oddziałach w podobnym czasie. System nie wie, która wersja jest właściwa, i albo nadpisuje jedną z nich bez ostrzeżenia, albo zgłasza błąd konfliktu, który blokuje dalszą wymianę. Rozwiązanie wymaga ustalenia reguł pierwszeństwa (która lokalizacja „wygrywa" w przypadku kolizji) i ręcznego rozstrzygnięcia zaległych sporów w danych.

Synchronizacja częściowa — brakuje wybranych typów dokumentów

Zamówienia przesyłają się prawidłowo, ale stany magazynowe już nie — albo odwrotnie. Powodem jest najczęściej zmiana konfiguracji po stronie systemu ERP (planowania zasobów przedsiębiorstwa) lub selektywne wyłączenie jednego z kanałów wymiany danych. Ten wariant bywa trudny do zauważenia, bo część danych nadal wygląda na aktualną.

Najczęstsze przyczyny w kontekście systemów ERP

Systemy używane w firmach wielooddziałowych — takie jak InsERT nexo, Comarch ERP Optima, WAPRO Mag, Sage Symfonia czy enova365 — mają własne mechanizmy synchronizacji między bazami danych. Przyczyny awarii bywają specyficzne dla konkretnego rozwiązania, ale kilka schematów powtarza się niezależnie od producenta.

Aktualizacja programu w jednym oddziale bez równoczesnej aktualizacji w pozostałych. Różnica wersji bazy danych powoduje, że mechanizm wymiany nie rozpoznaje nowych pól lub struktur tabel.
Wygaśnięcie licencji na moduł synchronizacji lub na serwer SQL — wymiana danych zatrzymuje się bez wyraźnego komunikatu w interfejsie użytkownika, a informacja o błędzie pojawia się dopiero w logu usługi.
Zmiana adresu IP serwera w jednym z oddziałów (na przykład po wymianie routera lub zmianie dostawcy internetu) bez zaktualizowania konfiguracji po stronie pozostałych lokalizacji.
Przepełnienie dysku na serwerze bazy danych — baza nie jest w stanie zapisać przychodzących zmian, a synchronizacja zatrzymuje się z błędem zapisu.
Zapora sieciowa (firewall) blokująca port używany przez mechanizm replikacji — zdarza się po aktualizacji oprogramowania zabezpieczającego lub po wdrożeniu nowych reguł przez administratora sieci.

Każdą z tych przyczyn weryfikujemy podczas wizyty serwisanta, sprawdzając konfigurację zarówno po stronie serwera, jak i stacji roboczych korzystających z systemu.

Błędy przy próbie samodzielnej naprawy

Gdy synchronizacja przestaje działać, osoby zarządzające systemem informatycznym w firmie próbują niekiedy rozwiązać problem samodzielnie. Część tych prób jest uzasadniona, ale kilka typowych działań regularnie pogarsza sytuację.

Ręczne kopiowanie bazy danych z jednego oddziału do drugiego

Zastąpienie bazy w oddziale B kopią bazy z oddziału A wydaje się prostym rozwiązaniem — skoro dane się rozjechały, wystarczy wziąć „tę nowszą". Problem polega na tym, że obie bazy mogły zawierać unikalne, prawidłowe zmiany. Nadpisanie jednej z nich powoduje trwałą utratę dokumentów wystawionych w tym oddziale od momentu utraty synchronizacji. Przywrócenie tych dokumentów jest potem znacznie trudniejsze niż uzgodnienie rozbieżności.

Wymuszenie pełnej resynchronizacji bez analizy zakresu rozbieżności

Niektóre systemy ERP mają opcję „pełnej synchronizacji od zera". Uruchomienie jej na dużej bazie (tysiące dokumentów) może trwać wiele godzin, w tym czasie system jest niedostępny dla użytkowników, a w przypadku przerwania — na przykład przez utratę łączności w połowie procesu — stan danych może być gorszy niż przed próbą. Tego typu operację warto przeprowadzać dopiero po ustaleniu przyczyny i upewnieniu się, że łącze jest stabilne.

Restart serwera SQL bez sprawdzenia, czy trwa transakcja

Gwałtowne zatrzymanie usługi serwera bazy danych w trakcie trwającej operacji zapisu może doprowadzić do uszkodzenia pliku bazy. Odzyskanie spójności wymaga wówczas naprawy bazy z kopii zapasowej — o ile kopia jest aktualna. Przed restartem serwera należy zawsze sprawdzić w monitorze aktywności, czy nie trwają otwarte transakcje.

Zmiana konfiguracji synchronizacji „na próbę"

Modyfikowanie parametrów wymiany danych metodą prób i błędów, bez dokumentowania wprowadzonych zmian, prowadzi do sytuacji, w której nawet po wizycie serwisanta trudno ustalić, jaka była pierwotna konfiguracja. Każdą zmianę parametrów — adresów, portów, interwałów, nazw baz — warto zapisywać z datą i opisem.

Kiedy to nie jest problem z synchronizacją

Nie każda rozbieżność danych między oddziałami oznacza awarię mechanizmu wymiany. Kilka sytuacji daje podobne objawy, ale ma zupełnie inną przyczynę.

Błąd po stronie użytkownika — pracownik wystawił dokument w niewłaściwej bazie (wybrał oddział A zamiast B) i dane pozornie „nie dotarły" do właściwej lokalizacji, bo nigdy nie zostały tam wprowadzone. Synchronizacja działa prawidłowo, a problem leży w procedurze pracy.

Opóźnienie wynikające z ustawionego harmonogramu — jeśli synchronizacja jest skonfigurowana na uruchamianie co godzinę lub co kilka godzin, rozbieżność w danych między oddziałami w ciągu tego interwału jest normalna. Problem pojawia się dopiero, gdy opóźnienie przekracza skonfigurowany harmonogram.

Filtrowanie widoku w aplikacji — niektóre systemy ERP pozwalają ograniczyć widoczność dokumentów do wybranego magazynu lub oddziału. Pracownik, który nie widzi danych z innej lokalizacji, może nie mieć ustawionego odpowiedniego filtra, a synchronizacja działa poprawnie.

Uszkodzenie lokalnego indeksu bazy — dane są fizycznie obecne w bazie, ale wyszukiwanie ich nie zwraca, ponieważ indeks (struktura przyspieszająca wyszukiwanie rekordów) wymaga przebudowy. Przeindeksowanie bazy rozwiązuje problem bez ingerencji w mechanizm wymiany danych.

Dodatkowe pytania klientów

Czy podczas naprawy firma musi wstrzymać pracę we wszystkich oddziałach?

Nie zawsze. W wielu przypadkach diagnostykę i naprawę konfiguracji można przeprowadzić na serwerze odpowiedzialnym za synchronizację, podczas gdy oddziały pracują normalnie na swoich lokalnych bazach. Przerwa jest potrzebna dopiero na etapie uzgadniania rozbieżności — i dotyczy zwykle tylko tych modułów, w których dane się rozjechały (na przykład magazynu), a nie całego systemu.

Ile danych można stracić, jeśli synchronizacja nie działała przez kilka dni?

Utrata danych w sensie ich całkowitego zniknięcia zdarza się rzadko — zazwyczaj dane istnieją po obu stronach, tylko nie zostały przesłane. Ryzyko rośnie, gdy ktoś w tym czasie ręcznie nadpisał bazę lub gdy zapełnił się dysk i serwer przestał zapisywać nowe transakcje. Dlatego pierwszym krokiem po wykryciu problemu jest wykonanie kopii zapasowej obu baz w ich aktualnym stanie — zanim podejmie się jakiekolwiek działania naprawcze.

Czy da się zabezpieczyć firmę przed powtórzeniem takiej awarii?

Tak, i sprowadza się to do kilku elementów: monitoringu usługi synchronizacji (powiadomienie e-mail lub SMS, gdy wymiana danych nie nastąpi w oczekiwanym czasie), regularnych kopii zapasowych obu baz oraz dokumentacji konfiguracji sieciowej i parametrów synchronizacji. Konfigurujemy takie rozwiązania podczas wizyty serwisanta — po naprawie, gdy mechanizm wymiany danych znów działa prawidłowo.

Czy serwisant musi odwiedzić wszystkie oddziały?

Nie zawsze. Jeśli oddziały są połączone przez VPN lub łączą się ze wspólnym serwerem w chmurze, diagnostykę i naprawę po stronie serwera można przeprowadzić z jednej lokalizacji. Wizyta w pozostałych oddziałach jest potrzebna tylko wtedy, gdy problem leży po stronie lokalnej infrastruktury sieciowej lub lokalnej instalacji oprogramowania. Dojeżdżamy do każdej z lokalizacji na terenie Warszawy i okolic.

Co, jeśli firma używa kilku różnych systemów, które powinny wymieniać dane?

Synchronizacja między różnymi programami — na przykład systemem magazynowym i osobnym systemem księgowym — opiera się zazwyczaj na mechanizmie eksportu i importu plików lub na interfejsie API (programistycznym łączu do wymiany danych między aplikacjami). Diagnostyka takiego scenariusza jest bardziej złożona, ponieważ trzeba sprawdzić poprawność formatu przesyłanych danych po obu stronach. Obsługujemy takie przypadki — w tym integracje między systemami InsERT, Comarch, WAPRO, a także połączenia z platformami sprzedażowymi.

Jak wygląda wizyta serwisanta przy tego typu awarii

Serwisant dojeżdża do lokalizacji, w której znajduje się serwer lub główna stacja robocza odpowiedzialna za synchronizację. Diagnoza obejmuje analizę logów usługi wymiany danych, sprawdzenie połączenia sieciowego między oddziałami oraz weryfikację konfiguracji po stronie systemu ERP i serwera bazy danych. Jeśli przyczyną jest awaria sprzętowa — na przykład uszkodzony dysk serwera lub niesprawna karta sieciowa — naprawa lub wymiana podzespołu następuje podczas tej samej wizyty, o ile część jest dostępna. Do naprawy wykorzystywane są wyłącznie nowe części, a na wykonaną usługę przysługuje gwarancja do 12 miesięcy.

Po przywróceniu mechanizmu synchronizacji przeprowadzane jest uzgodnienie zaległych danych. Serwisant wskazuje zakres dokumentów, które wymagają ręcznej weryfikacji, i omawia z osobą odpowiedzialną, która wersja danych jest właściwa w przypadku konfliktów. Na zakończenie konfigurowany jest monitoring, który pozwoli wykryć podobną awarię zanim rozbieżności narosną do trudnego do opanowania poziomu.

Utrata synchronizacji między oddziałami to problem, którego konsekwencje rosną z każdą godziną zwłoki — im dłużej bazy działają niezależnie, tym więcej dokumentów wymaga późniejszego uzgodnienia. Zgłoszenie awarii pod numerem 22 378 48 09 pozwala rozpocząć diagnostykę tego samego dnia, zanim rozbieżności zdążą się pogłębić.

22 378 48 09

Utrata synchronizacji danych między oddziałami firmy