Dual WAN. Zero przestojów e-Recepty.

Klient i wyzwanie

Przychodnia wielospecjalistyczna w Szczecinie: 6 gabinetów (internista, ortopeda, ginekolog, neurolog, dermatolog, kardiolog), rejestracja stacjonarna i online, system HIS działający na serwerze lokalnym, terminal płatniczy w rejestracji.

Problem był przewidywalny i powtarzalny: łącze światłowodowe od lokalnego ISP padało średnio raz na 11 dni. Każda awaria blokowała:

• •e-Receptę i e-ZLA — lekarze nie mogą wystawić dokumentu bez połączenia z systemem Centrum e-Zdrowia
• •System kolejkowy NFZ — rejestracja online przestaje działać
• •System HIS (synchronizacja danych między gabinetami przez serwer lokalny pozostaje, ale zewnętrzne funkcje odpadają)
• •Terminal płatniczy — tylko gotówka podczas awarii

Kierownik przychodni szacował koszt każdej awarii na 800–1 200 PLN (niedokonane recepty, porzucone wizyty, czas stracony przez personel rejestracji i lekarzy czekających na połączenie). 30 awarii rocznie = 30 000 PLN strat bezpośrednich, nie licząc reputacji.

Rozwiązanie — architektura dual WAN

DSX zaprojektował układ dual WAN na routerze Mikrotik RB4011iGS+5HacQ2HnD-IN:

• WAN1 (primary): dotychczasowe łącze światłowodowe 200/200 Mbps — bez zmian u ISP, bez renegocjacji umowy
• WAN2 (backup): router LTE Cat20 z kartą SIM operatora biznesowego, 5G w lokalizacji, realny throughput 180/50 Mbps
• Failover mechanizm: skrypt Mikrotik monitoruje dostępność 2 niezależnych hostów (8.8.8.8 + 1.1.1.1) co 5 sekund; jeśli oba nie odpowiadają przez 3 kolejne sondy — przełączenie na WAN2
• Failback automatyczny: po powrocie WAN1 do stabilności przez 60 sekund — powrót na światłowód
• Monitoring Zabbix: alerty SMS i e-mail do DSX i kierownika przychodni przy każdym failoverze i degradacji łącza

Decydujące było uniknięcie przerwy podczas wdrożenia — przychodnia pracuje od 8:00, dostępność internetu jest krytyczna od rana. Cała instalacja przeprowadzona w środę po 18:30, przed następnym dniem pracy sieć działała na nowej architekturze.

Harmonogram wdrożenia

1. Audyt sieci (tydzień -1)

   Diagnostyka i projekt

   Sprawdziliśmy istniejące łącze (światłowód 200 Mbps), lokalizację serwerów i urządzeń sieciowych. Zaprojektowaliśmy układ: router Mikrotik RB4011 z failoverem, WAN2 na router LTE z kartą SIM operatora biznesowego (5G w zasięgu 5G+).

2. Tydzień 0 — instalacja

   Wdrożenie bez przerwy w pracy

   Instalacja i konfiguracja poza godzinami pracy przychodni (środa, 18:30–22:15). Równoległe wdrożenie monitoringu Zabbix. Testy failovera: symulowane 5 awarii głównego łącza, każda obsłużona w 6–9 sekund.

3. Tydzień 1–4

   Monitoring i dostrojenie

   Zabbix monitoruje oba łącza co 30 sekund. Progi alertów: latencja > 80 ms na WAN1 lub utrata > 3% pakietów. DSX otrzymuje SMS/e-mail przed faktyczną awarią. Drobna korekta progów po obserwacji ruchu.

4. Miesiąc 2–8

   Produkcja

   3 automatyczne failovery: 2 awarie ISP (jedna nocna, jedna w piątek o 11:00 — podczas rejestracji), 1 degradacja łącza głównego. Żaden z failoverów nie wymagał interwencji człowieka. Personel nie zauważył żadnego.

Wyniki po 8 miesiącach

• 0 wymuszonych przestojów e-Recepty i e-ZLA od dnia wdrożenia
• 3 automatyczne failovery — żaden niezauważony przez lekarzy ani rejestrację
• Uptime mierzony przez Zabbix: 99.98% (3.5h downtime w 8 miesiącach, wszystko w godzinach nocnych 0–4)
• Najdłuższy failover trwał 4h 22min — awaria ISP w sobotę rano, ISP przywrócił do południa, LTE pokrywało bez problemów
• Oszczędność strat: szacowane 25 000 PLN (33 potencjalne awarie × 750 PLN średni koszt)
• Dodatkowy efekt: Zabbix wykrył 4 incydenty degradacji łącza głównego (latencja > 100ms) zanim przerodziły się w awarie — DSX zgłosił ISP z logami, 2 zostały naprawione prewencyjnie

Koszty i ROI

ROI: inwestycja jednorazowa zwróciła się przy pierwszym failoverze (wartość unikniętych strat: ~1 000 PLN). Miesięczny koszt SIM to ubezpieczenie na poziomie <1% potencjalnej straty z każdej awarii.

Czego NIE robiliśmy

Świadomie nie zaproponowaliśmy droższego rozwiązania SD-WAN ani agregacji łącz (load balancing). Centrum medyczne potrzebuje redundancji, nie prędkości — jedno łącze wystarczy do wszystkich aplikacji, drugie musi po prostu wkroczyć gdy pierwsze pada. Prosta architektura = mniej punktów awarii.