VPNなしで実行された定期ジョブは問題なく見える
ステータスは成功と言い、データは欠けている。各実行を正確な接続に条件づけ、スケジュールを信頼するのではなくスキップを別に記録する。
ジョブのステータスは成功と言い、ログは完了した実行を示し、データは古いか存在しない。この組み合わせは通常、定期ジョブが必要な経路なしに開始され、下流の何かが失敗を飲み込んだことを意味する。時間どおりに起動するスケジュールは、ネットワークが準備できていたかについては何も語らない。この二つの事実の間の隙間こそが、この失敗の住む場所である。
受け入れは実行に属し、cronファイルの存在には属さない。
緑の実行は完了したジョブではない
スケジューラはプロセスが開始し後に終了したことを記録するが、そのプロセスが存在理由であるリソースに到達したかは分からない。失敗した接続を空の結果として扱う、あるいはエラーを捕まえてゼロで終了するスクリプトは、永遠に健全に見える。症状は赤いステータスではなく、欠けた作業に付いたもっともらしいステータスである。
どう検査するかを決める前に、実行が実際に何を必要とするかを名指しする。バックアップにはプライベートDNSと認証済みエンドポイントが必要かもしれず、単なるトンネルプロセスでは足りない。
接続を検査し、インターフェース名を検査しない
tun0という名前のインターフェースは、重要なセッションなしに存在しうるし、別の接続がその名前を持つこともある。ジョブが依存する具体的な対象を検査する:一つのプロファイル同一性、一つのサービスインスタンス、あるいはリソースに対する小さな承認済み操作である。検査は時間で区切り、資格情報はプロセス引数や診断ログの外に置く。
切断時の結果も定義する。通常のスキップ、短い窓内での再試行、運用者に見える期限の見逃しは三つの異なる答えであり、繰り返しスケジュールはそのどれも選ばない。
スキップと失敗は別の結果である
[Service] Type=oneshot User=worker ExecCondition=/usr/local/libexec/check-office-path ExecStart=/usr/local/bin/private-task
systemdの配備では、ExecCondition= がワークロードの前にそのチェッカーを実行する。その終了時の振る舞いは特有である:ゼロは続行し、一から254のコードはユニットを失敗と記録せずに残りの起動コマンドをスキップし、255または異常終了は失敗させる。これにより三つの異なる信号が得られ、チェッカーの契約が意図的にそれらへ対応づけられている場合にのみ役立つ。成功を再定義する設定は状況を変えうるので、対応づけを文書化する。
スキップを記録することこそが設計を誠実にする。どこにも現れないスキップされた実行は成功した実行と区別できず、すべてのチェッカーエラーを静かなスキップとして扱うことは壊れた配備をいつまでも隠す。
実行全体を守り、開始だけを守らない
準備検査は起動前に世界を観察するが、その後にすべてのソケットを監視するわけではない。この作業に直接経路が決して許されないなら、DNS、IPv6、トンネル自身の輸送を継続的にカバーして強制する承認済みの出口ポリシーを付ける。ホストのグローバルIPv6状態を切り替えることは、作業に限定したポリシーの代わりにならない。
新しいイベントが実行中のジョブと重なってよいかを決め、その規則をワークロードの所有者の下に置き、データ操作にとって再試行を安全にする。切断時にタスクを止めることは作業を制限するが、フォールバック通信について何も保証しない。
三つの場合でワークフローを受け入れる:準備された経路、利用できない経路、実行途中の喪失である。それ未満はスケジュールを試すのであって、ジョブを試すのではない。