本番移行後、月次バッチまで重点監視した理由――監視エラーと処理失敗を分けて判断する

本番移行が完了しても、すぐに通常の運用・保守体制へ引き渡せるとは限りません。

私が携わったプロジェクトでは、本番移行後もログ監視ツールを使った重点監視を続けていました。定時バッチの前後や昼間の通常業務中にログを確認し、月次の重要バッチが正常に処理されるまでを重点確認の期間としていました。

その月次バッチで、監視時間を超過したことによるエラーが出たこともあります。しかし、バッチ処理自体はその後正常に終了しました。

そこで、監視エラーだけを見て処理失敗とは判断せず、エラー内容と処理件数を確認しました。その結果、移行時に滞留したデータをまとめて処理したことによる、一時的な処理量の増加だと判断しました。

前回は、本番移行を止めにくい条件の中で、続行判断、切り戻し、完了承認の役割を分けた経験を紹介しました。

今回は、本番移行後にどのようなタイミングでログを確認し、監視エラーと処理失敗をどう分け、何をもって通常運用へ引き渡したのかを紹介します。

移行完了後も重点監視を続けた

本番移行の作業が終わり、移行結果の確認と完了承認を受けても、重点確認はそこで終わりではありませんでした。

移行直後には日常的な画面操作だけでなく、決まった時刻に動く処理や、月に一度動く重要な処理もあります。移行当日だけでは、それらが新しい環境で正常に動くかを確認できません。

そのため、ログ監視ツールを使った重点監視を、本番移行後も続けていました。

重点監視の終了を単純な日数では決めず、月次の重要バッチが正常に処理されることを、通常の運用・保守体制へ引き渡す条件としていました。

※本番移行後、通常業務と定時バッチを確認し、月次の重要バッチが正常終了してから通常運用へ引き渡す流れを示すイメージです。

定時バッチの前後と通常業務中にログを確認した

重点監視では、常に同じ頻度でログを見るのではなく、処理が動くタイミングを意識していました。

確認していたのは、定時バッチの実行前後と、昼間の通常業務中です。

定時バッチの前後では、処理の開始や終了に伴うエラーが出ていないかを確認します。通常業務中は、利用者がシステムを使っている時間帯にエラーログが出ていないかを確認していました。

監視期間だけでなく、どのタイミングで確認するかも決めておくことで、移行後に初めて動く処理や、実際の利用によって表面化する問題を確認しやすくしていました。

エラーログを検知したら担当部署へ連絡した

ログ監視ツールでエラーログを検知した場合は、担当部署へ連絡していました。

担当部署では、エラー内容を確認し、一次調査と判断を行いました。

ここで重要なのは、監視ツールがエラーを示した時点で、すぐに移行失敗や処理失敗と決めつけないことです。

エラーログは調査を始めるきっかけです。その後の一次調査で、何が起きているのかを確認する必要がありました。

エラー内容と移行前後のデータから判断した

一次調査では、エラーログの内容と、移行前後のデータ内容を確認していました。

ログに記録されたエラーの種類や発生状況だけでなく、移行前後のデータに違いがあるかを確認し、移行に起因する問題か、通常運用中に起きた問題かを判断していました。

ただし、すべての問題を同じ手順だけで切り分けていたわけではありません。実際には、検知したエラーの内容に応じて、担当部署が必要な情報を確認していました。

月次バッチで監視時間を超過した

月次の重要バッチは、正常終了することが多くありました。

一方で、監視時間を超過したことによるエラーが出たこともあります。

このとき、監視上はエラーになっていましたが、バッチ処理自体はその後正常に終了しました。監視エラーが出たことと、バッチ処理が失敗したことは同じではありませんでした。

移行のために通常処理が止まっていた期間には、処理待ちのデータが滞留します。移行後のバッチでは、その滞留分を含む多くのデータを処理する必要がありました。

その結果、通常より処理時間が長くなり、監視時間を超過していました。

処理件数を比較して一時的な増加と判断した

監視時間を超過したからといって、すぐに監視時間の設定を変更したわけではありません。

実際に処理したデータ件数と、現行環境でのデータ処理数を比較しました。

比較した結果、移行時に滞留したデータを処理したことによる、一時的なデータ処理量の差だと判断しました。

バッチ処理自体も正常に終了していたため、監視時間の設定はそのままにしました。

もし恒常的に処理量が増え、通常運用でも同じ監視エラーが続くのであれば、別の判断が必要です。しかし今回確認できたのは、移行時のデータ滞留に伴う一時的な増加でした。

※監視時間超過を検知した後、バッチの終了状態と処理件数を確認し、一時的な処理量増加と判断して監視設定を維持する流れを示すイメージです。

月次バッチの正常終了後に通常運用へ引き渡した

重点監視は、月次の重要バッチが正常に処理されるまで続けました。

日々の通常業務や定時バッチだけでは、月次にしか動かない重要処理の確認はできません。

月次バッチが正常に処理されたことを確認した後、重点監視を終え、通常の運用・保守体制へ引き渡していました。

この経験では、移行後の監視期間を「何日間」と一律に決めるのではなく、そのシステムで重要な業務サイクルが一巡したかどうかで判断していました。

まとめ

本番移行後は、ログ監視ツールを使い、定時バッチの前後と昼間の通常業務中にログを確認していました。

月次の重要バッチでは、監視時間超過によるエラーが出たことがあります。しかし、バッチ処理自体はその後正常終了しました。

処理件数と現行環境でのデータ処理数を比較した結果、移行時に滞留したデータによる一時的な処理量の増加だと判断しました。そのため、監視時間の設定は変更しませんでした。

監視ツールがエラーを示しても、それだけで処理失敗とは判断できません。エラー内容、実際の処理結果、処理したデータ件数を確認し、一時的な事象か継続する問題かを分ける必要がありました。

月次の重要バッチが正常に処理されたことを確認した後、通常の運用・保守体制へ引き渡しました。移行後の重点監視は、日数だけでなく、重要な業務処理が正常に一巡したかを基準にしていました。

次の記事：