Zaplanowane zadanie, które działało bez VPN, wygląda dobrze

Status zadania mówi o sukcesie, dziennik pokazuje ukończone uruchomienie, a dane są nieaktualne lub ich brak. Ta kombinacja zwykle oznacza, że zaplanowane zadanie zaczęło się bez ścieżki, której potrzebowało, a coś niżej połknęło błąd. Harmonogram, który uruchamia się na czas, nie mówi nic o tym, czy sieć była gotowa. Właśnie w luce między tymi dwoma faktami żyje ten błąd.

Dopuszczenie należy do uruchomienia, a nie do istnienia pliku cron.

Zielone uruchomienie to nie ukończone zadanie

Planista odnotowuje, że proces się rozpoczął i później zakończył; nie ma pojęcia, czy ten proces dotarł do zasobu, dla którego istnieje. Skrypt, który traktuje nieudane połączenie jako pusty wynik albo przechwytuje błąd i kończy z zerem, będzie wyglądał zdrowo wiecznie. Objawem nie jest czerwony status; to wiarygodny status przypięty do brakującej pracy.

Nazwij, czego uruchomienie naprawdę potrzebuje, zanim zdecydujesz, jak je sprawdzić. Kopia zapasowa może potrzebować prywatnego DNS i uwierzytelnionego punktu końcowego, a nie tylko procesu tunelu.

Sprawdzaj połączenie, a nie nazwę interfejsu

Interfejs o nazwie tun0 może istnieć bez sesji, która ma znaczenie, a inne połączenie może posiadać tę nazwę. Sprawdź konkretny obiekt, od którego zależy zadanie: jedną tożsamość profilu, jedną instancję usługi albo niewielką zatwierdzoną operację wobec zasobu. Utrzymuj sprawdzenie ograniczone w czasie i trzymaj poświadczenia poza argumentami procesu i dziennikami diagnostycznymi.

Zdefiniuj także wynik rozłączenia. Zwykłe pominięcie, ponowna próba w krótkim oknie i widoczny dla operatora przekroczony termin to trzy różne odpowiedzi, a powtarzający się harmonogram nie wybiera między nimi.

Pominięcia i błędy to różne wyniki

[Service]
Type=oneshot
User=worker
ExecCondition=/usr/local/libexec/check-office-path
ExecStart=/usr/local/bin/private-task

W wdrożeniu systemd ExecCondition= uruchamia ten sprawdzian przed obciążeniem roboczym. Jego zachowanie przy wyjściu jest szczególne: zero kontynuuje, kody od jednego do 254 pomijają pozostałe polecenia startu bez oznaczania jednostki jako nieudanej, a 255 lub nieprawidłowe zakończenie powoduje jej niepowodzenie. Daje to trzy odrębne sygnały, użyteczne tylko wtedy, gdy kontrakt sprawdzianu jest świadomie na nie odwzorowany. Ustawienia przedefiniowujące sukces mogą zmienić obraz, więc udokumentuj odwzorowanie.

To rejestrowanie pominięć czyni projekt uczciwym. Pominięte uruchomienie, które nigdzie się nie pojawia, jest nieodróżnialne od uruchomienia, które się powiodło, a traktowanie każdego błędu sprawdzianu jako cichego pominięcia bez końca ukrywa zepsute wdrożenie.

Chroń całe uruchomienie, nie tylko początek

Sprawdzenie gotowości obserwuje świat przed startem; nie pilnuje potem każdego gniazda. Gdy bezpośrednia ścieżka nigdy nie jest dopuszczalna dla tego zadania, dołącz zatwierdzoną politykę wyjścia, która jest egzekwowana stale i obejmuje DNS, IPv6 oraz własny transport tunelu. Przełączanie globalnego stanu IPv6 hosta nie zastępuje polityki ograniczonej do zadania.

Zdecyduj, czy nowe zdarzenie może nakładać się na wciąż działające zadanie, trzymaj tę regułę u właściciela obciążenia roboczego i uczyń ponowną próbę bezpieczną dla operacji na danych. Zatrzymanie zadania przy rozłączeniu ogranicza pracę, ale niczego nie gwarantuje w kwestii ruchu zapasowego.

Zaakceptuj przepływ pracy w trzech przypadkach: gotowa ścieżka, niedostępna ścieżka i utrata w trakcie działania. Cokolwiek mniej testuje harmonogram, a nie zadanie.