目次

はじめに

今回、お仕事でレガシーなバッチに変更を加える機会がありました。 ある施策の一環で行った変更なのですが、いったん無事にリリースが終わりひと段落ついたのでこの経験を通して感じたことや反省点をアウトプットしておこうと思います。

状況の説明

今回自分が変更を加えたバッチは以下のような状態でした。

  • 言語はPHP
  • （たぶん）数十年と動いているバッチ
  • dry-runなど知らない！
  • テスト…知らない子ですね？
  • DBの設定や環境ごとの変数の切り替えが整備されてなかった（なので開発環境で動かない）

上記のような状態のため変更後のバッチ自体の動作確認をするには、バッチの全コード自体を変更してdry-runができるようにし、ステージングや本番環境で動作確認をするしかなかったです。 本番環境やステージングで動作確認なんてしたくない（できない事情もある）のでバッチ自体の動作確認はしていませんでした。

リリース後の反省

  1. 動作確認が甘かった
    • ユニットテストを作成して関数レベルでは動作を確認していたが、バッチ自体の動作確認をしていなかった（開発環境でできる状態にしておけばよかった）
      • このことで読み込んでいるファイル間で多重宣言があったりの検知ができてなかった（これが原因でエラー発生）
      • 注入しているインスタンスが似た名前のもので間違っていた（ユニットテストでは正しく注入していたので気づかなかった）
      • 上記に伴って、本来requireしておかなければならないクラスをrequireしてなかった
  2. リリース対応時の自身のスケジュールをしっかり詰めていなかった
    • エラー発生時の切り戻し判断が遅れてしまいほかのバッチの実行に影響が出てしまった

準備しておいてよかった点

  • バッチの手動実行方法や実行結果logの確認方法を事前に確認してまとめていたこと
    • このことでエラー発生時にすぐ原因がわかり再実行ができた
  • 関係するバッチのスケジュールを確認していた
    • 切り戻しの際にどのバッチに影響があるか把握しやすかった
  • 処理対象のＤＢレコードの監視を設定していた
    • redashのアラート機能を使い異常なレコードが作成されないか確認してました
  • バッチ改修時に分かったことをドキュメントに残していた
    • エラー発生時に再実行の可否や冪等性の確認に役立った

おわりに

今回は、もっとこうしておけば、ああしておけばと得るものが多かったです。 バッチの動作確認ができない状況でも、何かあった際にリカバリーをいち早くできるようにしていた次善策を用意していて本当によかったな～と思っています。 今後は、バッチ系のリプレイスをしてもっと安全に変更できるように環境を整えたいなと思いました。