W trzecim kwartale tego roku zakończyliśmy migrację działu handlowego na laptopy z procesorami ARM. Plan był prosty: dłuższy czas pracy na baterii, natychmiastowe wybudzanie z trybu uśpienia i niższa temperatura obudowy podczas ciągłej pracy w terenie. Pierwsze testy wypadły obiecująco. Przeznaczyliśmy budżet, przeszkoliliśmy zespół IT i wymieniliśmy łącznie 47 urządzeń. Efekt końcowy to 85% sukcesu, ale pozostałe 15% wdrożeń musieliśmy wycofać. Powód nie leżał w samych procesorach ani w systemie operacyjnym. Problemem okazały się dwa elementy infrastruktury, które uznaliśmy za stabilne: klienci VPN oraz sterowniki drukarek sieciowych.
VPN oparty na starych bibliotekach szyfrujących nie obsłużył nowej architektury
Nasze środowisko VPN działało na dedykowanych bramach z protokołem IPSec i uwierzytelnianiem dwuskładnikowym. Klienci instalowani na laptopach z x86 działali bez zarzutu od ponad trzech lat. Na ARM-ie uruchomiliśmy natywną wersję tego samego oprogramowania, dostarczoną przez producenta. Połączenia nawiązywały się poprawnie, ale już po kilku minutach transfer spadał do poziomu uniemożliwiającego pracę z bazą danych CRM i współdzielonymi arkuszami kalkulacyjnymi. Analiza ruchu wykazała, że problem leży w implementacji algorytmu szyfrowania AES-GCM, który na ARM wykorzystywał instrukcje kryptograficzne, ale sterownik bramy VPN nie potrafił poprawnie negocjować ramek MTU. Skutek: pakietowość wzrosła o 40%, a opóźnienie przekroczyło 300 ms przy obciążeniu większym niż dwa równoległe strumienie.
Próbowaliśmy trzech rozwiązań. Pierwsze – aktualizacja firmware bram VPN – wyeliminowała błędy negocjacji, ale wymagała restartu całego klastra w godzinach pracy, co odrzuciliśmy. Drugie – przejście na protokół WireGuard – dało poprawę przepustowości, ale zderzyło się z polityką bezpieczeństwa, która wymaga rejestracji każdego urządzenia w systemie NAC. Trzecie – uruchomienie tuneli SSL przez przeglądarkę – sprawdziło się w przypadku aplikacji webowych, ale nie dla klienta SQL i zdalnego pulpitu. Ostatecznie utrzymaliśmy ARM-y dla 80% użytkowników, którzy korzystają głównie z przeglądarki i lekkich narzędzi. Pozostałe 15% wdrożeń to handlowcy pracujący z rozbudowanymi raportami i połączeniami bezpośrednimi do hurtowni danych. W ich przypadku wróciliśmy do x86, a koszt zwrotu sprzętu i ponownej konfiguracji pochłonął równowartość dwóch tygodni pracy trzech administratorów.
Sterowniki drukarek sieciowych – różnica między emulacją a natywnym kodem
Druga przeszkoda okazała się bardziej podstępna. Dział handlowy drukuje codziennie zamówienia, faktury protokolarne oraz karty katalogowe. Wszystkie urządzenia w biurze to modele sieciowe z językami opisu stron PCL6 i PostScript. Na x86 sterowniki dostarczane przez producenta działają w trybie jądra. Na ARM producent zaoferował jedynie sterowniki oparte na emulacji, które przekazują zadania przez warstwę tłumaczącą. Dla dokumentów jednostronicowych różnica jest niezauważalna. Przy zestawieniach 50–100 stron emulacja wydłużała przetwarzanie z 4 do 18 sekund na stronę. Do tego doszły problemy z buforowaniem – przy równoczesnym wysyłaniu pięciu zadań kolejka drukarki blokowała się, wymagając ręcznego resetowania.
Sytuację pogarszał fakt, że nie wszystkie drukarki wspierały uniwersalny sterownik PCL6 w wersji ARM. Modele starsze niż trzy lata nie otrzymały aktualizacji. Modele nowsze wymagały oddzielnej konfiguracji portu i protokołu, co nie było udokumentowane w skróconej instrukcji. Po trzech tygodniach testów wypracowaliśmy dwa warianty postępowania:
- Dla drukarek z gamy produkcyjnej (rok produkcji 2024–2025) wdrożyliśmy sterowniki AirPrint oraz Mopria, które na ARM działają natywnie i nie wymagają emulacji.
- Dla urządzeń starszych lub niestandardowych (np. drukarki etykiet i fiskalne) pozostawiliśmy stacje mostkujące – komputer x86, który przyjmuje zadania i przekazuje je dalej jako przetworzony strumień.
Pierwsze rozwiązanie zadziałało dla 12 użytkowników. Drugie – dla kolejnych ośmiu. Pozostałe siedem osób, które stanowiły owe 15% wycofanych wdrożeń, to handlowcy pracujący zdalnie z własnymi drukarkami biurowymi podłączonymi przez USB lub starsze interfejsy sieciowe. W ich przypadku mostkowanie nie miało sensu logistycznego, a emulacja uniemożliwiała płynną pracę. Zwróciliśmy im laptopy x86, mimo że ARM oferował lepszą mobilność. Decyzja była trudna, ale mierzalna – liczyliśmy czas oczekiwania na wydruk i liczbę interwencji helpdesku.
Co wynieśliśmy z tego wdrożenia i jak planujemy dalej
Migracja na ARM nie jest błędem, ale wymaga weryfikacji całego łańcucha zależności, nie tylko samego systemu operacyjnego. VPN i sterowniki to dwa obszary, które w testach jednostkowych często pomijamy, koncentrując się na aplikacjach biurowych i przeglądarce. Tymczasem to właśnie warstwa sieciowa i peryferia decydują o codziennym komforcie użytkownika. W naszym przypadku 15% wycofanych urządzeń to nie porażka, lecz koszt zdobycia wiedzy, którą teraz stosujemy w kolejnych etapach – przy migracji działu księgowości oraz logistyki. Dla każdego nowego pionu przygotowujemy oddzielny audyt kompatybilności infrastruktury sieciowej i urządzeń peryferyjnych, zanim zakupimy sprzęt.
Zmieniliśmy również procedurę testową. Obecnie każdy model ARM przechodzi pięciodniowy sprawdzian w środowisku produkcyjnym z ograniczoną grupą użytkowników, którzy reprezentują różne profile pracy – od lekkiego przeglądania po intensywne drukowanie i tunele VPN. Dodatkowo utworzyliśmy wewnętrzną bazę znanych problemów ze sterownikami, aktualizowaną na bieżąco przez dział wsparcia. Dla VPN uruchomiliśmy równoległy klastr testowy z protokołem IPsec w nowszej wersji, która ma certyfikat zgodności z ARM. Jeśli testy wypadną pomyślnie, rozważymy ponowne zaproponowanie ARM handlowcom z grupy 15%, ale na zasadzie dobrowolnej wymiany, nie przymusowej migracji.
Podsumowując: ARM w laptopach biznesowych to przyszłość, ale nie dla każdego i nie od razu. Kluczowe jest zrozumienie, że procesor to tylko jeden element układanki. Infrastruktura sieciowa, polityka bezpieczeństwa i starsze urządzenia peryferyjne potrafią zniweczyć korzyści wydajnościowe. Nasza rekomendacja dla firm planujących podobny krok: wykonajcie inwentaryzację wszystkich drukarek, bram VPN oraz protokołów szyfrowania, zanim podpiszecie zamówienie. Testujcie na rzeczywistych danych, nie na syntetycznych benchmarkach. I zawsze miejcie plan odwrotu – nawet jeśli oznacza to 15% wycofanych urządzeń. W biznesie lepiej cofnąć się o krok, niż utknąć w martwym punkcie na miesiące.
