Egy VPN nélkül lefutott ütemezett feladat jónak látszik

A feladat állapota sikert jelez, a napló befejezett futást mutat, az adatok pedig elavultak vagy hiányoznak. Ez a kombináció általában azt jelenti, hogy az ütemezett feladat a szükséges útvonal nélkül indult el, és valami lejjebb lenyelte a hibát. Az időben induló ütemezés semmit sem mond arról, hogy a hálózat készen állt-e. Ennek a két ténynek a közötti rés az a hely, ahol ez a hiba él.

A beengedés a futáshoz tartozik, nem egy cron-fájl létezéséhez.

A zöld futás nem befejezett feladat

Az ütemező feljegyzi, hogy egy folyamat elindult és később kilépett; fogalma sincs arról, hogy a folyamat elérte-e az erőforrást, amelyért létezik. Egy szkript, amely a sikertelen kapcsolatot üres eredményként kezeli, vagy elkap egy hibát és nullával lép ki, örökké egészségesnek tűnik. A tünet nem piros állapot; ez egy hihető állapot, amely hiányzó munkához tapad.

Nevezze meg, mire van valójában szüksége a futásnak, mielőtt eldönti, hogyan ellenőrizze. Egy biztonsági mentésnek lehet szüksége privát DNS-re és hitelesített végpontra, nem csupán egy alagútfolyamatra.

A kapcsolatot ellenőrizze, ne az interfész nevét

Egy tun0 nevű interfész létezhet a fontos munkamenet nélkül, és egy másik kapcsolat birtokolhatja ezt a nevet. Ellenőrizze azt a konkrét objektumot, amelytől a feladat függ: egy profilidentitást, egy szolgáltatáspéldányt vagy egy kis jóváhagyott műveletet az erőforrás ellen. Tartsa az ellenőrzést időben korlátozottan, és tartsa a hitelesítő adatokat a folyamatargumentumokon és diagnosztikai naplókon kívül.

Határozza meg a kapcsolat nélküli eredményt is. Egy szokásos kihagyás, egy rövid ablakon belüli újrapróbálkozás és egy operátor számára látható elmulasztott határidő három különböző válasz, és egy ismétlődő ütemezés nem választ közöttük.

A kihagyások és a hibák különböző eredmények

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

Egy systemd telepítésben a ExecCondition= futtatja azt az ellenőrzőt a munkaterhelés előtt. A kilépési viselkedése sajátos: a nulla folytatja, az egytől 254-ig terjedő kódok kihagyják a fennmaradó indítási parancsokat anélkül, hogy az egységet meghibásodottként jelölnék meg, a 255 vagy a rendellenes leállás pedig meghiúsítja. Ez három különálló jelet ad, amelyek csak akkor hasznosak, ha az ellenőrző szerződését szándékosan ezekre képezik le. A sikert újradefiniáló beállítások megváltoztathatják a képet, ezért dokumentálja a leképezést.

A kihagyások rögzítése teszi őszintévé a tervezést. Egy kihagyott futás, amely sehol sem jelenik meg, megkülönböztethetetlen egy sikeres futástól, és minden ellenőrzőhiba csendes kihagyásként való kezelése határozatlan ideig elrejti a törött telepítést.

Védje az egész futást, ne csak a kezdetet

Egy készültségi ellenőrzés az indítás előtt figyeli a világot; utána már nem őrködik minden socket felett. Amikor egy közvetlen útvonal soha nem elfogadható ehhez a feladathoz, csatoljon egy jóváhagyott kimenő házirendet, amely folyamatosan érvényesül, és lefedi a DNS-t, az IPv6-ot és az alagút saját átvitelét. A gazdagép globális IPv6-állapotának átkapcsolása nem helyettesíti a feladatra korlátozott házirendet.

Döntse el, hogy egy új esemény átfedhet-e egy még futó feladatot, tartsa ezt a szabályt a munkaterhelés tulajdonosánál, és tegye biztonságossá az újrapróbálkozást az adatművelet számára. Egy feladat leválasztáskor történő leállítása korlátozza a munkát, de semmit sem garantál a tartalék forgalomról.

Fogadja el a munkafolyamatot három esetben: kész útvonal, elérhetetlen útvonal és futás közbeni veszteség. Bármi kevesebb az ütemezést teszteli, nem a feladatot.