本記事はアフィリエイト広告を含みます。
VPSでタスクが動かないときは、予定時刻に起動しない、手動実行だけ成功する、成功表示なのに成果物がないの三つに分けます。予約設定、実行環境、保存先の順に調べる場所を絞りましょう。履歴の記録が無効だった場合は、記録がないことだけで未起動と判断せず、試験実行の新しい記録を使います。
この記事は、サイト運営の定期処理を想定した切り分け手順です。特定の障害をABLENET上で再現した記録ではありません。サーバーの操作方法は契約したOSの公式案内に合わせ、まず影響の小さい確認から進めてください。
VPS・起動・処理本体・外部接続を順に確認
最初はVPSの稼働と空き容量、次にタスクの有効・無効、予定時刻とタイムゾーン、実行履歴を見ます。起動していれば処理ログと外部接続へ進みます。手元PCのスリープ対策とVPS内の実行条件は別なので、自分のタスクがどのマシンに登録されているかも確かめてください。
場所／最初に見る記録
- サーバー
-
最初に見る記録：接続可否、稼働状態、保存領域の空き
- 起動設定
-
最初に見る記録：予約時刻、実行履歴、使われたユーザー
- 処理本体
-
最初に見る記録：開始・終了・エラーの記録
- 外部サービス
-
最初に見る記録：応答内容、認証状態、利用上限
手動実行だけ成功する場合は、実行ユーザー、プログラムの絶対パス、引数、開始場所を並べます。予約実行で別のPythonやフォルダーを使っていれば、同じファイルでも結果が変わります。スペースを含むパスの指定や、ユーザーごとの環境変数・保存先にも注目します。
最後の成功と最初の失敗の間に、パスワード変更・OS更新・ファイル移動・認証期限切れがなかったかを読みます。履歴を有効にしていなかった場合は、過去がないことを未起動と断定せず、設定を控えてから試験実行で新しい記録を取ります。変更は一箇所ずつにします。
Windowsの予約処理は前回の実行情報を読む
Windows VPSでタスクスケジューラを使っている場合は、VPS内のPowerShellで前回の実行情報を確認できます。次は、ルートフォルダーに登録したタスク名が DailyCsvJob である場合の例です。
例にある DailyCsvJob は登録名の仮名です。自分のタスク名に置き換えてください。
Get-ScheduledTaskInfo -TaskName 'DailyCsvJob' -TaskPath '\'
このコマンドは登録済みタスクの実行情報を読み取ります。タスクの起動や設定変更をするコマンドではありません。別のフォルダーへ登録した場合は、-TaskPath もその場所に合わせます。Microsoft公式のコマンド説明
前回実行時刻、予定時刻、アプリの開始ログ、出力ファイルの更新時刻を一列に並べます。「履歴では起動、開始ログなし」なら起動対象や権限、「開始後に保存で失敗」なら保存先へ進みます。終了コードが分かった場合も、その数字だけで集計が正しいとは判断しません。
見つかった状態／次に確認する場所
- 予定した時間帯の実行記録がない
-
次に確認する場所：トリガーの日時、実行条件、指定ユーザー
- タスクの実行記録はあるが、開始ログがない
-
次に確認する場所：起動するファイルの場所、引数、作業フォルダー、実行権限
- 終了ログはあるが、欲しい出力がない
-
次に確認する場所：保存先、対象日の入力、エラーを処理して終了していないか
この表は原因を絞るための手順です。タスク側の終了結果だけで、データの集計が正しいとは判断できません。予定した入力から、期待する件数や内容の成果物が作られたかまで確認して、実際の仕事が完了したことを確かめます。
再起動後も動く設定を確認する
再起動後だけ止まるなら、手動で開いたアプリやログオン状態に依存していないかを見ます。タスクの実行アカウントとログオン方式により、画面やネットワーク資源へのアクセス条件が違います。安易に管理者権限を足す前に、必要な資源と権限を特定しましょう。Microsoftのタスク実行権限の説明
再起動後の確認では、起動設定と処理成功を分けます。自動起動していても、必要なネットワークや保存先の準備前に動き出すと失敗します。開始ログと接続エラーの時刻を見て、何を待つ必要があったかを特定してください。
起動直後に失敗する場合は、必要な条件がそろっているかを調べます。待ち時間を増やすだけで済ませず、どの依存先に接続できなかったのかを記録に残すと、次回の確認が楽になります。
ログに開始・終了・失敗を残す
ログは「開始・入力取得・保存・完了」を分け、対象日と件数を添えます。失敗した工程が残れば、取得をやり直すべきか、保存だけ直すべきか判断できます。画面にだけ出て消えるエラーを避け、あとで読める場所へ標準出力やエラーを記録する方法を用意します。
タスクの実行履歴に「成功」と表示されても、目的のファイルが更新されていなければ仕事は完了していません。終了コードと成果物の更新日時・件数を別々に記録します。保存先の権限や外部APIの応答で止まった場合も、どの工程まで進んだかが分かります。
失敗が移行直後から続く場合は、Python移行前の確認で保存先と実行ユーザーを含む移行前提を確認してください。
例えば「日次集計開始、対象日9月14日」「取得完了」「CSV保存失敗、保存先なし」と分かれていれば、データ取得を最初から疑う必要がありません。これは記録形式の例で、実際の障害ログではありません。
ログにAPIキー、パスワード、顧客情報をそのまま含めてはいけません。復旧に必要なのは、多くの場合、処理の種類や応答の概要です。秘密情報を出さずに調べられる形に整えます。
また、ログを無制限に増やすと保存領域を圧迫します。保存期間や容量を決め、必要な記録を残しながら古いものを整理する運用にします。成果物とログの両方で、容量の使い方を把握しておきましょう。
失敗通知と再実行のルールを決める
処理内のエラー通知だけでは、起動しなかった仕事に気づけません。「朝の予定後に完了記録を読む担当」など、完了がないことを見つける仕組みも用意します。再試行の上限、重なったときの扱い、通知先を決め、同じ失敗を無制限に繰り返さないようにします。
一方、エラーのたびに無制限に通知すると、大切な連絡を見落としやすくなります。同じ原因をまとめる、再実行後も失敗した場合に知らせるなど、受け取った人が行動できる頻度へ調整します。
再実行前に、取得・保存・送信のどこまで済んだかを照合します。CSVの再作成とメールや請求の再送は影響が違います。対象日や処理済みIDを使って重複を避け、完了した工程まで繰り返さず、必要な部分だけ復旧できるかを判断しましょう。
修正後は、失敗した条件で復帰を確認する
設定を直したら、元の問題が起きた条件で小さく試してください。再起動後の停止なら再起動まで含め、予約時刻の問題なら予約実行の結果を確認します。
本番への書き込みを止めた試験用処理で、出力先、終了記録、通知を一つずつ確かめてください。復旧した時刻と変更点も残し、次の担当者が同じ切り分けをできるようにします。
ABLENETをこれから検討する場合は、最大10日間のお試しでこの復帰まで確認する方法があります。カード登録は必要で、自動の有料移行はしないという条件です。公式お試し案内
環境を選び直す必要があるなら、同じ処理で試用する
原因の切分け後にVPSの変更を検討する方は、ABLENETの試用条件へ。手動・予約・再起動後の同じ入力を比べ、必要な仕事が続けて動くかを判断できます。
公式サイトで料金・利用条件を確認
利用前にサービス案内へ移動します。最大10日間のお試しはカード登録が必要です。プラン変更で処理の不具合が直る保証はありません。
直したら元の失敗条件で試し、結果と変更点を残します。移行に伴う問題ならPythonの環境・保存先の準備へ、環境を選び直す必要があるなら試用で予約実行と復帰を試す手順へ進めます。原因が不明な段階では、上位プランへの変更を解決策にしないようにします。
