システムのエラーハンドリングで何を考えていた？停止・通知・再実行の実務経験

システムでエラーが発生したとき、私が担当した環境では、すべての処理を同じように止めていたわけではありません。

JP1/AJSを使っていた環境では、ジョブネット側で、エラーになった処理や後続を止めたり、ログを出したり、エラーメールを送ったりする構成がありました。

その後は原因を確認し、必要な修正をして再実行していました。私の経験では、失敗したジョブだけを単独で実行して終わるより、失敗したジョブから後続まで流し直すことの方が多かったです。

この記事では、エラー時にどこまで処理を止めていたのか、ログや通知で何を残していたのか、修正後にどのように処理を流し直していたのかを、実務経験から紹介します。

エラーが起きてもすべての処理を止めるわけではなかった

エラーになった処理を止め、その後続も止めることがありました。

一方、その処理自体はエラーとして終了させても、別の処理はそのまま進める構成もありました。

どこまで止めるかを考えるときに見ていたのは、データの整合性に影響するか、後続処理が成立するかという点です。

処理を続けてもデータの整合性に問題がないのか、後続処理に必要なものが揃っているのかによって、扱いは変わっていました。

データの一部でエラーが発生したとき、そのデータだけを切り離し、正常なデータは処理を続ける構成もありました。

ただし、後続処理で全データが必要な場合は同じようにはできませんでした。

一部のデータを外した状態では後続処理が成立しない場合、処理を作り直す可能性もありました。

私が担当した環境では、エラー時の通知にメールとエラーログを使っていました。

緊急性が高いものでは、電話で連絡することもありました。

すべてのエラーを電話で連絡していたわけではありません。

エラーログでは、次のような情報を残していました。

中でも、エラー内容はその後のリカバリー方法に影響するため、特に必要な情報だと考えていました。

対象データを特定できる情報も、出せるのであれば残したい情報でした。

エラー原因を確認して必要な修正をした後は、処理を再実行していました。

失敗したジョブを起点に後続処理を流し直すことが多かったのですが、再実行する範囲は固定ではありませんでした。

処理内容やその時点の状態によっては、ジョブネットや一連の処理を最初から流し直すこともありました。

また、修正後すぐに実行するのではなく、翌営業日に再び実行時間になるまで待つ処理もありました。

現在の日立製作所「JP1/Automatic Job Management System 3 導入ガイド（Version 13）」にも、実行が終了したジョブネットやジョブを再実行する操作が用意されています。

これは現在の製品仕様についての補足です。私が実際にどこから再実行していたかは、当時担当した環境での運用経験として書いています。

実装で大変だったものの一つが、複数の処理のエラーハンドリングを一つのフローへまとめる部分です。

処理ごとに発生するエラーの条件が違うだけでなく、データの中身によってエラー後の動きを変える必要があるものもありました。

例えば、内容によっては電話で連絡する必要があるものもあれば、メールだけでよいもの、そのまま処理を続けても問題ないものもありました。

こうした条件の違いがあるため、単に共通のエラー処理を一つ作れば終わり、というわけではありませんでした。

このエラーハンドリング実装を含む仕事内容全体については、アプリSEの仕事内容とは？設計・実装・テスト・管理まで実務経験から紹介で紹介しています。

エラーハンドリングで印象に残っているのが、エラーを処理する側でもエラーが発生した経験です。

私が担当した環境では、エラー処理の中でDBを使用しているものがありました。

そのときは、エラー処理自体も正常に動かず、そこでさらにエラーになりました。

原因を確認すると、エラー処理が使っていたDB自体が停止していたことが分かりました。