Godzina bez zasięgu: co robi Twoja operacja, gdy znika łączność
Autor navichain team
Kierowca wjeżdża do tunelu drogowego, na podziemny dok załadunkowy, na pokład samochodowy promu, albo po prostu w dolinę, gdzie jeden słaby maszt obsługuje trzy wioski, i przez pięć minut albo czterdzieści telefon nie ma zasięgu. To nie jest awaria systemu ani rzadki przypadek brzegowy — to normalna część prowadzenia pojazdów po prawdziwym terenie, a każda firma obsługująca więcej niż kilka tras spotka się z tym rutynowo. Ciekawe pytanie nie brzmi, czy to się zdarza. Brzmi, co robi wtedy aplikacja na uchwycie w kabinie i ekran dyspozytora w biurze — i czy ktokolwiek dalej w łańcuchu potrafi odróżnić „tu nic się nie wydarzyło” od „coś się wydarzyło, tylko jeszcze o tym nie wiemy”.
Trzy różne problemy pod jedną nazwą
„Offline” brzmi jak jeden stan, ale aplikacja kierowcy traci trzy odrębne rzeczy, gdy znika sygnał, i te rzeczy nie zachowują się tak samo, gdy sygnał wraca.
Pierwsza to stan, który był już lokalny — dzisiejsza lista przystanków, trasa, manifest ładunku aktualnie na pokładzie. Nic z tego nie wymaga aktywnego połączenia, żeby było przydatne; wymaga tego, żeby zostało pobrane zanim pojazd wjechał w martwą strefę, a to pytanie o to, kiedy aplikacja ostatnio się zsynchronizowała, nie o to, co robi offline. Kierowca sprawdzający kolejny przystanek w tunelu czyta dane, które dotarły godzinę wcześniej, i nie potrzebuje od sieci absolutnie niczego więcej.
Druga to czynność, którą trzeba zapisać w chwili, gdy się dzieje, niezależnie od tego, czy sieć akurat współpracuje. Dostawa zostaje odrzucona przy drzwiach. Paleta przyjeżdża uszkodzona. Przystanek zamyka się, bo odbiorca podpisał odbiór. To fakty ze znacznikiem czasu, a ten znacznik to teraz, w martwej strefie — nie wtedy, gdy wrócą kreski zasięgu. Aplikacja, która nie potrafi zapisać faktu, dopóki nie może też o nim zadzwonić, każe kierowcy albo czekać na poboczu, albo zaufać własnej pamięci co do wersji, którą wpisze później — a „zrobię to, jak złapię zasięg” to dokładnie sposób, w jaki zapis operacyjny zamienia się w rekonstrukcję z pamięci.
Trzecia to żywy strumień danych, który nie ma odpowiedzi wstecznej — przede wszystkim to, gdzie pojazd znajduje się w tej chwili. Pozycja to nie fakt, który można w uczciwy sposób nadrobić później: jeśli ciężarówka spędza osiemnaście minut w tunelu, nie ma prawdziwej odpowiedzi na pytanie „gdzie była w dziewiątej minucie” poza „gdzieś w tunelu, między dwoma punktami po obu jego stronach”. Właściwe zachowanie to nie fabrykowanie ciągłości. To pokazanie ostatniej znanej pozycji ze znacznikiem czasu i pozwolenie temu, kto patrzy, wyciągnąć oczywisty wniosek — zamiast po cichu interpolować prostą linię przez litą skałę i przedstawiać to jako dane.
Zapis i jego dowód rzadko zgadzają się, kto ma iść pierwszy
Większość zdarzeń operacyjnych to nie pojedynczy zapis — to zapis plus coś, co go potwierdza: dostawa plus podpis, odmowa plus zdjęcie, przegląd plus fotografie usterki. W martwej strefie zwykle da się zapisać lokalnie i tanio tylko jedno z tych dwóch (sam zapis, który jest mały), podczas gdy drugie — zwłaszcza zdjęcie — jest na tyle duże, że „po prostu ponów wysyłkę” oznacza realne czekanie, a nie chwilę.
Te dwa zdarzenia nie chcą tej samej kolejności. Zapis dostawy, który istnieje bez zdjęcia w tle, to małe ryzyko, do odzyskania, jeśli kiedykolwiek zostanie zakwestionowany. Kierowca utknięty przy drzwiach, bo aplikacja odmawia oznaczenia przystanku jako zakończonego, dopóki obraz nie skończy się wysyłać przy jednej kresce zasięgu, to problem większy i bardziej natychmiastowy — przystanek utyka, kierowca albo czeka, albo omija aplikację, a omijanie aplikacji to sposób, w jaki papierowy proces po cichu odrasta wewnątrz cyfrowego. Zapis więc nie powinien czekać, aż dotrze jego dowód; ale dowodu też nie należy traktować jak opcjonalnego ładunku, który spokojnie można zgubić. Musi sam, w tle, próbować dalej, aż dotrze albo naprawdę przepadnie — a jeśli przepadnie, ktoś musi to zobaczyć, zamiast żeby to zniknęło bez śladu.
Ta kolejność nie jest jednak uniwersalna, i to jest część warta zauważenia: dla niektórych zdarzeń priorytet się odwraca. Zgłoszenie nieudanej dostawy jest dla biura prawdopodobnie bardziej przydatne bez żadnego zdjęcia niż niezłożone w chwili, gdy się wydarza, bo nieudany przystanek zmienia to, jak wygląda reszta dnia — ponowna próba, telefon do klienta, przeplanowanie trasy — a to musi dotrzeć do dyspozytora wcześniej niż zdjęcia, jeśli trzeba wybierać. To, co idzie pierwsze, nie powinno być technicznym domyślnym ustawieniem wybranym przez przypadek, zależnie od tego, które wywołanie akurat najłatwiej odpalić pierwsze w kodzie. To decyzja o tym, którego braku bardziej by zabrakło, podjęta świadomie, raz, dla każdego rodzaju zapisu.
Ponowna próba to nie automatycznie powtórzenie
Niewygodny przypadek to ten, w którym nikt tak naprawdę nie wie, co się stało: aplikacja wysłała żądanie, połączenie padło w trakcie, i z samego telefonu nie da się stwierdzić, czy serwer je odebrał i nie zdążył odpowiedzieć, czy w ogóle go nie zobaczył. Ślepe ponawianie jest w porządku dla czegoś idempotentnego. Nie jest w porządku dla czynności, która za każdym wywołaniem tworzy nowy zapis — drugi wpis „dostarczono” po niejednoznacznym przekroczeniu czasu może zostać odczytany przez wszystko dalej w łańcuchu jako druga próba dostawy, a nie potwierdzenie pierwszej. Uczciwy system musi rozróżniać: „na pewno się nie udało, bezpiecznie ponowić” to inny stan niż „nie wiemy” — a ten drugi zasługuje na większą ostrożność: człowieka potwierdzającego, zanim pójdzie ponownie, zamiast cichej ponownej próby, która może na papierze podwoić prawdziwe zdarzenie.
Znane martwe strefy traktuj jako znane, nie jako incydenty
Większość tego da się opanować dzięki przewidywaniu, nie sprytowi. Jeśli trasa co tydzień przechodzi przez ten sam tunel albo tę samą trzywioskową martwą strefę, ta przerwa w łączności to nie nowina — to znana cecha trasy, a traktowanie dziesięciominutowej ciszy na tym odcinku jak alarmu zamiast czegoś oczekiwanego uczy dyspozytora gonić kierowców za czymś, co wcale nie jest błędem. Nawyk, który warto wyrobić, to znajomość własnych martwych stref na tyle dobrze, by odróżnić „cicho, bo tunel” od „cicho, bo naprawdę coś jest nie tak” — a to ocena, którą wciąż musi wykonać człowiek, ale może ją dobrze wykonać tylko wtedy, gdy system przed nim uczciwie mówi, co w tej chwili wie, a czego nie.
Gdzie stoi navichain
Aplikacja kierowcy zapisuje status przystanku, podpis, zdjęcia i powód nieudanej dostawy na miejscu, a dzisiejsze przystanki, nawigacja i manifest ładunku dla każdego przystanku są już w telefonie, zanim dzień się zacznie — kierowca sprawdzający kolejną dostawę czyta plan, który już tam był, a nie taki, który czeka na aktywne pobranie. Strona platformy opisuje resztę tego, co działa obok tego mechanizmu: codzienne przeglądy techniczne, które od razu otwierają usterkę, gdy coś zawiedzie, oraz dane towarów niebezpiecznych ograniczone dokładnie do przystanku, przy którym stoi kierowca — tak, by informacja ważna przy drzwiach nie zależała od tego, co akurat robi zasięg, gdy drzwi się otwierają.