Harmonogram jest miejscem, w którym gromadzą się zadania dopisywane latami. Po pewnym czasie nikt nie wie, co się uruchamia i po co.
Rozłożenie w czasie
Wszystkie zadania ustawione na pełną godzinę uruchamiają się razem i obciążają serwer skokowo. Rozsunięcie o kilka minut usuwa problem bez żadnych kosztów.
Przy układaniu planu liczy się też kolejność. Zadanie liczące raport z danych, które dopiero mają zostać wczytane, wykona się poprawnie i da zły wynik. Jeśli jedno zadanie zależy od drugiego, bezpieczniej połączyć je w jeden przebieg niż liczyć na odstęp w harmonogramie, który kiedyś okaże się za krótki.
Warto też sprawdzić, jaki czas ma serwer i czy zmiana czasu z zimowego na letni nie powoduje pominięcia albo podwójnego uruchomienia zadania nocnego.
Zabezpieczenie przed nakładaniem
Zadanie uruchamiane co pięć minut, a trwające siedem, po godzinie działa w kilkunastu kopiach naraz. Blokada uruchomienia równoległego jest obowiązkowa.
Blokada musi się zwalniać także po awarii. Znacznik zostawiony przez przerwany przebieg zatrzymuje wszystkie kolejne uruchomienia i wygląda dokładnie tak samo jak zadanie usunięte z harmonogramu. Dlatego blokada powinna mieć termin ważności albo sprawdzać, czy proces, który ją założył, nadal działa.
Kontrola wykonania
Zapis czasu rozpoczęcia i zakończenia. Bez tego zadanie, które przestało się uruchamiać, pozostaje niezauważone przez miesiące.
Najskuteczniejsza kontrola działa odwrotnie niż powiadomienie o błędzie: sprawdza brak sygnału. Jeśli zadanie miało się zgłosić do rana i tego nie zrobiło, ktoś powinien się o tym dowiedzieć. Awaria polegająca na tym, że nic się nie uruchomiło, nie wyśle przecież żadnego komunikatu o błędzie.
Powiadomienie o błędzie
Nie o każdym uruchomieniu — tylko o nieudanym. Wiadomość po każdym poprawnym przebiegu przestaje być czytana w tydzień.
Skrypt musi przy tym rzeczywiście zgłaszać niepowodzenie kodem wyjścia, a nie kończyć się spokojnie po wypisaniu komunikatu. Harmonogram widzi wyłącznie kod, nie treść. Zasady doboru kanału i progów opisuje tekst o powiadomieniach z serwera.
Czas trwania
Warto zapisywać. Zadanie wydłużające się z miesiąca na miesiąc zapowiada problem, który wyjdzie sam, gdy przekroczy okno serwisowe.
Typowa przyczyna to zapytanie przeszukujące całą tabelę, która rośnie. Dopóki danych jest mało, nikt tego nie zauważa. Dlatego zadania nocne przetwarzające historię warto od początku ograniczać do okresu, który naprawdę jest potrzebny.
Przegląd harmonogramu
Raz na rok: co się uruchamia, po co, kto jest odbiorcą wyniku. Zadania bez odbiorcy można wyłączyć.
Zamiast usuwać od razu, warto wyłączyć i odczekać kwartał. Jeśli nikt nie zauważy braku, zadanie było zbędne. Do przeglądu potrzebny jest spis narzędzi, o którym mówi tekst o dokumentacji i ewidencji skryptów — bez niego pozostaje odtwarzanie stanu z samych wpisów w harmonogramie.
