Web API は HTTP ステータスコードを使用して効果的にエラーを通知しますが、バッチジョブでは、実行環境がエラーを認識するために異なるアプローチが必要です。当初、著者は、false または status: 500 オブジェクトを返すことでエラーを通知することを意図した既存の Lambda 関数を見つけました。しかし、Lambda の観点からは、これらのアクションは正常な呼び出しとして扱われ、CloudWatch にエラーが記録されるのを妨げました。その結果、設定された CloudWatch アラームはトリガーされず、Slack 通知も送信されませんでした。著者は、Web API で一般的な 500 ステータスコードを返すという馴染みのあるパターンが、バッチジョブには適用できないことに気づきました。代わりに、バッチジョブでは、実行環境が問題を検出するために、呼び出し全体が失敗する必要があります。これを解決するために、エラー処理は例外をスローするようにリファクタリングされ、Lambda の呼び出しが実際に失敗するようになりました。この失敗は CloudWatch Errors メトリックに正しく反映され、アラームがトリガーされ、通知が送信されるようになりました。この経験は、エラー処理がアプリケーションコード自体を超えて拡張されることを浮き彫りにしました。外部の監視およびアラートシステムによってエラーが観測可能であることを保証する必要があります。したがって、エラー処理を検討する際には、エラーが内部的にどのように管理されるかだけでなく、外部システムがどのように障害を認識するようになるかについても尋ねる必要があります。これにより、バッチプロセスに対して監視およびアラートメカニズムが意図したとおりに機能することが保証されます。