Drobna zmiana w systemie, który pracuje
Kartoteka klientów ma dostać nowe, obowiązkowe pole: opiekuna handlowego. Dla osoby, która o to prosi, to drobiazg. Klientów jest jednak kilka tysięcy i żaden z nich opiekuna jeszcze nie ma. W tej samej chwili ktoś wystawia fakturę, ktoś inny poprawia dane klienta, a nocą działają zadania, które coś przeliczają.
Gdyby wymaganie włączyć od razu, system albo odmówiłby zmiany, albo każdy, kto otworzy starego klienta, dostałby błąd przy zapisie.
Najprostsze wyjście to przerwa serwisowa. W sobotę wieczorem wyłącza się system i wprowadza zmiany, w niedzielę się je sprawdza, a w poniedziałek wszyscy wracają do pracy. Firma przez ten czas stoi, a im więcej osób i procesów zależy od systemu, tym trudniej znaleźć chwilę, w której nikt go nie potrzebuje. Jeśli w niedzielę coś pójdzie nie tak, w poniedziałek rano jest awaria albo pośpieszne łatanie.
Da się inaczej. Zmianę dzieli się na małe kroki, a każdy z nich da się sprawdzić i, dopóki to możliwe, cofnąć.
Taki porządek opłaca się wtedy, gdy na systemie codziennie pracuje kilka osób albo działa on także w nocy, jak sklep internetowy. Przy małej stronie firmowej zwykle wystarczy krótka przerwa, zapowiedziana z wyprzedzeniem, i kopia zrobiona tuż przed zmianą.
Krok 1. Próba na kopii
Zanim zmiana dotknie prawdziwych danych, przechodzi próbę na kopii. Wersja testowa dostaje kopię danych z systemu, na którym pracuje firma.
Na kopii widać, ile wpisów zmiana obejmie, ile to potrwa i które wpisy sprawią kłopot. Gdy wartość nie może się powtarzać (np. NIP), wyjdą powtórzenia. Przy tekście zamienianym na datę będą to wartości, których nie da się przeliczyć. Przy polu obowiązkowym będzie to liczba pustych wpisów. Osoba, która zatwierdza zmianę, decyduje wtedy na podstawie prawdziwych danych. Nie musi zakładać, że „u nas wszystkie wpisy są poprawne”.
Po próbie kopię się sprząta. Skąd brać dane do takiej próby i w którą stronę mogą płynąć, piszemy w artykule Testy na prawdziwych klientach. Dobrze, gdy wykonawca ma na to stałą procedurę. Próba nie zależy wtedy od tego, czy ktoś o niej pamiętał.
Krok 2. Dodanie pola bez wymagań
Na prawdziwym systemie najpierw dodaje się pole, ale puste i jeszcze nieobowiązkowe. Istniejące dane i codzienna praca działają dokładnie tak jak wcześniej. Aplikacja może od tej chwili zapisywać nowe pole, więc nowi klienci od razu dostają opiekuna.
Krok 3. Uzupełnienie starych wpisów
Teraz istniejący klienci dostają wartość, domyślną albo wyliczoną według reguły, którą ustala osoba zamawiająca zmianę. Dzieje się to w tle, w czasie normalnej pracy.
Kusi, żeby zrobić to jednym ruchem. Przy dużej kartotece takie polecenie potrafi jednak na kilka minut zatrzymać zapisy innym osobom. Każdy, kto chce wtedy coś zapisać, czeka i ma wrażenie, że system się zawiesił. Dlatego dane uzupełnia się porcjami. Każda porcja jest krótka, a po każdej zapisuje się, gdzie praca stanęła. Jeśli coś przerwie uzupełnianie, rusza ono dalej od tego miejsca.
Uzupełnianie nie może też nadpisać pracy człowieka. Jeśli ktoś zmienił wpis w trakcie, uzupełnianie wraca do tego wpisu później.
Krok 4. Odczekanie
Włączenie wymagania zamyka prostą drogę powrotu, więc z tym krokiem warto poczekać. Przez pewien czas nowe pole działa na prawdziwej pracy firmy, a nic jeszcze nie jest wymagane ani usunięte. Jeśli wyjdzie problem, nowe pole można po prostu wycofać, a dotychczasowe dane zostają nietknięte.
Ten etap łatwo pominąć, bo wszystko już działa i kusi, żeby zamknąć sprawę od razu.
Krok 5. Włączenie wymagania
Dopiero teraz, gdy wszystkie wpisy mają wartość, a zmiana trochę już popracowała, pole staje się obowiązkowe. Od tej chwili każdy nowy i każdy poprawiany klient musi mieć opiekuna. Powrót wymaga już nowej, świadomej zmiany w przeciwną stronę, z własną próbą i zatwierdzeniem.
Ten sam porządek działa przy innych zmianach. Gdy tekst w polu ma się stać datą, obok starego pola powstaje nowe, wartości są przeliczane, a stare pole znika na samym końcu. Zanim zniknie, ktoś musi zdecydować, co z danymi, które w nim były. Można je usunąć albo zachować w archiwum. Bywa też, że lepiej wstrzymać zmianę, bo dane okazały się ważniejsze, niż się wydawało.
Przełączenie nowej wersji aplikacji
Przestój zwykle widać w chwili przełączenia na nową wersję. Stara wersja obsługuje użytkowników, dopóki nowa nie jest gotowa i sprawdzona, a użytkownicy trafiają do nowej dopiero wtedy, gdy ona już odpowiada. Nocne przeliczenia i inne zadania w tle wstrzymuje się na czas przełączenia i czeka, aż skończą to, co zaczęły, żeby nie działały częściowo na starej, a częściowo na nowej wersji.
Każda wersja aplikacji ma własną nazwę, a kilka ostatnich zostaje na serwerze. Powrót do poprzedniej to wskazanie wcześniejszej wersji i ponowne uruchomienie, bez budowania czegokolwiek od nowa. Dane są trzymane osobno od aplikacji, więc wymiana wersji ich nie dotyka.
Przydaje się też hamulec. Jeśli jakaś operacja nagle chce usunąć wyraźnie więcej danych niż zwykle, powinna się zatrzymać i poczekać na człowieka.
Kopia zapasowa, która naprawdę działa
Na końcu zostaje kopia zapasowa. Kopia, z której nikt nigdy nie próbował odtworzyć danych, może po prostu nie działać, a firma dowie się o tym w najgorszym możliwym momencie.
Dobra kopia trafia poza serwer, najlepiej do serwerowni w innym mieście, żeby awaria serwera albo całego budynku z serwerami jej nie zabrała. Jest szyfrowana. Historia kopii obejmuje wiele dni, a uprawnienia są ustawione tak, że nawet ktoś, kto przejmie serwer, nie skasuje starszych wersji. Do tego ktoś regularnie odtwarza kopię w osobnym miejscu i porównuje wynik z działającym systemem.
Kopia, która przestała się robić, też powinna od razu wywołać alarm. Jak ustawić takie powiadomienia, opisujemy w artykule Strona padła w nocy, a firma dowiaduje się od klienta.