Zmiana konfiguracji wprowadzona wprost na instalacji produkcyjnej działa, dopóki nie przestanie. Środowisko testowe i tryb wprowadzania zmian są potrzebne od pierwszego miesiąca, nie od momentu pierwszej awarii.
Trzy rodzaje zmian po uruchomieniu
Zmiany trafiające do działającej instalacji różnią się ryzykiem i wymagają innego trybu. Mylenie ich jest przyczyną większości zakłóceń przypisywanych później samemu oprogramowaniu.
| Rodzaj | Przykład | Tryb |
|---|---|---|
| Dane słownikowe | Nowy przewoźnik, nowy rodzaj transportu | Wprost na produkcji, bez ograniczeń |
| Parametry procesu | Długość okna, limit palet, próg zmiany terminu | Po godzinach ruchu, z zapisem poprzedniej wartości |
| Struktura | Nowy magazyn, nowa brama, zmiana ról | Najpierw na środowisku testowym |
| Aktualizacja aplikacji | Nowa wersja systemu | Okno serwisowe, z możliwością wycofania |
Drugi wiersz bywa traktowany jak pierwszy i to najczęstsze źródło kłopotów. Skrócenie okna czasowego w środku dnia przelicza siatkę i unieważnia część dostępnych terminów, więc przewoźnik rezerwujący właśnie w tym momencie dostaje komunikat o niedostępności bez wyraźnego powodu.
Zmiana parametrów bez naruszania rezerwacji
Siatka okien generuje się z parametrów, a rezerwacje wiążą się z konkretnym rekordem, nie z pozycją w kalendarzu. Dzięki temu zmiana długości okna przelicza terminy przyszłe, zostawiając potwierdzone zgłoszenia bez zmian.
Granicą przeliczenia jest horyzont rezerwacji. Jeżeli przewoźnicy rezerwują na trzy tygodnie wprzód, zmiana parametrów dotknie terminów, które ktoś już zaplanował, więc wymaga powiadomienia. Praktyka polega na wprowadzaniu takich zmian z wyprzedzeniem większym niż horyzont, czyli z datą obowiązywania w przyszłości.
Zapis poprzedniej wartości parametru jest ważniejszy niż sama możliwość jego zmiany. Bez niego pytanie, dlaczego zestawienia z dwóch kwartałów się nie zgadzają, nie ma odpowiedzi.
Po co osobne środowisko
Kopia instalacji z danymi zbliżonymi do produkcyjnych pozwala sprawdzić zmianę, zanim dotknie ruchu. Dotyczy to przede wszystkim zmian strukturalnych: dodania magazynu, przebudowy ról, zmiany zakresu uprawnień.
- Sprawdzenie zmiany struktury - czy nowy obiekt nie zaburza istniejących kalendarzy.
- Przygotowanie instrukcji - opis kroków spisywany na środowisku, nie na produkcji.
- Szkolenie - nauka bez ryzyka wprowadzenia wpisu do rejestru, który potem trzeba usuwać.
- Sprawdzenie aktualizacji - uruchomienie nowej wersji przed oknem serwisowym.
Dane osobowe na środowisku testowym wymagają osobnego rozstrzygnięcia. Kopia produkcji zawiera dane kierowców, więc albo podlega tym samym zasadom ochrony, albo przed skopiowaniem przechodzi anonimizację. Obowiązki w tym zakresie porządkuje strona o awizacji a przepisach o ochronie danych.
Aktualizacje i okno serwisowe
Nowa wersja aplikacji wymaga przerwy, której długość zależy od zakresu zmian w bazie. Wyznaczenie jej na porę najmniejszego ruchu jest oczywiste, ale w obiektach pracujących w ruchu ciągłym takiej pory nie ma i trzeba przewidzieć pracę bramy w trybie zastępczym.
Drugim wymogiem jest możliwość wycofania. Kopia bazy wykonana bezpośrednio przed aktualizacją oraz zachowana poprzednia wersja aplikacji pozwalają wrócić do stanu sprzed zmiany w kilkanaście minut. Bez tego decyzja o aktualizacji obarczona jest ryzykiem, które skłania do jej odkładania, a odkładanie prowadzi do przeskoku przez kilka wersji naraz.
Dokładanie obiektów i funkcji
Rozszerzenie na kolejny magazyn przebiega szybciej niż pierwsze wdrożenie, bo słowniki i zasady są już ustalone. Zostaje kartoteka obiektu, siatka okien dopasowana do jego godzin pracy oraz przypisanie użytkowników.
Pułapką bywa kopiowanie parametrów z obiektu istniejącego. Magazyn o innym asortymencie ma inne czasy obsługi, więc siatka przeniesiona wprost daje kolejkę od pierwszego dnia. Parametry trzeba wyznaczyć z pomiaru, tak samo jak przy pierwszym wdrożeniu. Metodę doboru opisuje strona o definiowaniu okien czasowych, a przebieg samego projektu - materiał o wdrożeniu oprogramowania do awizowania dostaw.
Czynności cykliczne
Poza zmianami wprowadzanymi doraźnie pozostaje zestaw czynności wykonywanych regularnie. Żadna nie jest ciągła, wszystkie dają się zaplanować.
Kopie zapasowe z okresowym sprawdzeniem odtworzenia, przegląd kont i wyłączenie tych bez aktywności, korekta siatki po zmianie obsady oraz porządkowanie kartotek przed przypięciem się do nich historii. Do tego archiwizacja zamkniętych wizyt, gdy rejestr urośnie na tyle, że zestawienia zwalniają. Wymagania infrastrukturalne opisuje strona o architekturze oprogramowania YMS, a warstwę raportową - materiał o usługach raportowych SQL Server.
Obserwowanie działającej instalacji
Awaria rzadko zaczyna się od zatrzymania systemu. Wcześniej pojawiają się objawy widoczne w danych: rosnący czas odpowiedzi przy zapisie zgłoszenia, wiadomości zalegające w kolejce wysyłki, przyrost rozmiaru dziennika transakcji. Każdy z nich daje się obserwować, zanim ktoś zgłosi problem.
Zestaw obserwowanych wielkości nie musi być rozbudowany. Dostępność aplikacji, czas najdłuższego zapytania w ciągu godziny, liczba nieudanych logowań i stan kolejki powiadomień pokrywają większość przypadków, w których użytkownik zauważyłby kłopot później niż administrator.
Drugim źródłem sygnałów jest sam rejestr. Nagły spadek liczby zgłoszeń w godzinach zwykle ruchliwych oznacza częściej przerwę w dostępie niż zmianę zachowania przewoźników. Zestawienia kontrolne uruchamiane automatycznie wychwytują to w ciągu godziny.
Warto ustalić, kto jest odbiorcą tych sygnałów. Komunikat trafiający wyłącznie do dziennika serwera zostanie przeczytany wtedy, gdy ktoś zacznie szukać przyczyny już zgłoszonego problemu.
Dokumentacja i przekazanie wiedzy
Konfiguracja wdrożona i nieudokumentowana jest wiedzą jednej osoby. Przy zmianie na stanowisku administratora albo przy rozszerzeniu na kolejny obiekt trzeba ją odtwarzać przez oglądanie ustawień, co zajmuje więcej czasu niż spisanie ich na bieżąco.
Zakres, który realnie się przydaje, jest węższy niż pełna dokumentacja techniczna. Wystarczy zapis decyzji parametrycznych wraz z uzasadnieniem: dlaczego okno trwa czterdzieści minut, skąd wziął się limit palet, dlaczego rampa trzecia nie obsługuje naczep.
Uzasadnienie jest tu ważniejsze niż sama wartość. Parametr bez powodu zostaje zmieniony przy pierwszej okazji przez osobę, która nie wie, że wynikał z pomiaru, a nie z przypadku. Zapis poprzednich wartości pozwala z kolei wyjaśnić rozbieżności między zestawieniami z różnych kwartałów.
Drugą częścią jest instrukcja dla użytkowników, prowadzona osobno dla każdej roli. Operator na bramie potrzebuje opisu czterech czynności, a nie podręcznika obejmującego całą aplikację. Zakres pracy na tym stanowisku opisuje strona o stanowisku ochrony.