繁忙期のバッチ設定を年間スケジュールへ組み込んだ――起動時刻と監視時間を事前設定した運用

毎年同じ時期にバッチ処理が長時間化することが分かっているなら、そのたびに担当者が設定を変更する方法だけが選択肢ではありません。

私が携わったプロジェクトでは、例年の実績から繁忙期に該当する月や週を事前に把握していました。その期間に合わせて、バッチの起動スケジュールと監視時間を年間スケジュールに設定していました。

特定の日だけ異なる設定にすることも、スケジュール上で指定できました。繁忙期が終わるたびに設定を戻すのではなく、通常時と繁忙期の条件をあらかじめ登録していたため、変更がなければ翌年も同じスケジュールで動作します。

前回、本番リリース後の通常運用を確認し、運用保守の責任者が障害票の完了を判断していた経験を紹介しました。

今回は、障害対応をきっかけに見直したバッチ運用について、繁忙期の条件をどのように年間スケジュールへ組み込んでいたのかを紹介します。

例年の実績から繁忙期を事前に把握した

繁忙期の時期は、突然分かったわけではありません。

過去の運用実績から、バッチ処理が長時間化しやすい月や週を事前に把握していました。

具体的な月や週は業務によって異なります。この記事で重要なのは、繁忙期を感覚だけで決めたのではなく、例年の実績をもとに対象期間を見ていたことです。

その期間を前提に、通常時とは異なるバッチの起動スケジュールや監視時間が必要かを検討していました。

起動スケジュールと監視時間を年間スケジュールに設定した

保守運用担当者は、繁忙期に合わせてバッチの起動スケジュールと監視時間を変更していました。

変更内容は、その場で一度だけ操作するのではなく、年間スケジュールに設定していました。

通常時の設定と、繁忙期に該当する月や週の設定を、スケジュール上で分けて管理します。また、一時的な対応が必要な場合は、特定の日だけ異なる設定にすることもできました。

※通常時の設定に加え、繁忙期の月・週や特定日だけ異なる起動時刻と監視時間を設定する考え方を示すイメージです。

繁忙期終了後に設定を戻す作業はなかった

繁忙期が終わった後、担当者が設定を手作業で元へ戻していたわけではありません。

通常時と繁忙期の条件を年間スケジュールに設定していたため、登録された日程に従って動作します。

変更がなければ、翌年も同じスケジュールで動作していました。繁忙期の開始時と終了時に、担当者が毎回同じ設定変更を繰り返す運用にはしていませんでした。

一方で、すべての年に同じ状況が続くと保証されるわけではありません。既存の設定を変える必要が生じたときは、変更の必要性と、設定を変えてよいかを確認していました。

変更前に説明・レビュー・承認を行った

バッチの起動時刻や監視時間は、本番運用に関わる設定です。

保守運用担当者だけの判断で変更を確定するのではなく、変更前に責任者へ内容を説明し、承認を得ていました。また、複数人で変更内容をレビューしていました。

確認していたのは、単に設定値が入力できるかどうかではありません。これまでの設定を変えてよいのか、本当に変更が必要なのかを確認したうえで、年間スケジュールに反映していました。

※変更の必要性を確認し、責任者への説明、複数人レビュー、承認を経てスケジュールへ反映する流れを示すイメージです。

年間計画と実行スケジュールは役割が違った

翌年度の対応予定は、年間の計画でも管理していました。

ただし、年間計画と、バッチを実際に動かす年間スケジュールは同じものではありません。

年間計画は、繁忙期に必要な対応を運用上の予定として把握するために使います。一方、実行スケジュールには、バッチの起動時刻や監視時間といった実際の動作条件を設定していました。

毎年「今年も同じ設定でよいか」を確認する定例作業があったわけではありません。既存設定を変更する必要が生じた場合に、変更の必要性と可否を確認する運用でした。

スケジュールへ組み込める作業かを考える

定期的に発生する運用作業でも、すべてを担当者の手作業として残す必要はありません。

実施する時期と設定内容を事前に決められるのであれば、スケジュールへ組み込める可能性があります。特定の日だけ設定を変えられる仕組みであれば、通常時の条件を維持しながら例外日にも対応できます。

ただし、設定を繰り返し適用できることと、変更内容が妥当であることは別です。設定を変える場合は、変更の必要性と可否を確認し、説明・レビュー・承認を経て反映していました。

まとめ

私が携わったプロジェクトでは、例年の実績から繁忙期に該当する月や週を把握し、バッチの起動スケジュールと監視時間を年間スケジュールに設定していました。

一時的な対応が必要な場合は、特定の日だけ異なる設定にすることもできました。通常時と繁忙期の条件を事前に登録していたため、繁忙期が終わるたびに設定を元へ戻す作業はありませんでした。

設定変更は保守運用担当者が行い、変更前に責任者へ説明して承認を得ていました。変更内容は複数人でレビューし、これまでの設定を変えてよいのか、変更が必要なのかを確認していました。

翌年度の対応予定は年間計画で管理し、実際の起動時刻と監視時間は実行スケジュールへ設定していました。毎年同じ確認作業を行うのではなく、変更が必要になったときに既存設定を見直す運用でした。

毎年または特定の時期に繰り返す運用がある場合、手順として残すだけでなく、実行スケジュールへ組み込めるかを検討することも一つの方法です。

次の記事：