第⑫回では、公式TXTを将来の学習・検証用データとして扱うために、確認できた通常データだけを受け入れる仕様をまとめました。
前回の記事：公式データをそのまま学習に使わない理由｜開発日記⑫
ただし、研究で確認できたことが、そのまま本番runtimeへ反映されるわけではありません。ボートレースAIでは開発中のコードにも改善を加えていますが、レース前の予想を保存する環境では、更新を急がないことも大切な作業です。
今回は、source側で確認できた改善と、本番runtimeへの反映を別に扱っている理由を書いてみます。
開発用の確認と、本番で動かすことは別です
改善したコードは、まず開発側で内容を確認します。テストを通り、受入確認ができたとしても、それだけで本番runtimeへ反映してよいとは限りません。
本番では、予想を出す時刻、対象レース、保存済みの計画、起動済みのAgentなどが関わります。途中で実行環境だけを差し替えると、何の版で判断した予想なのかが不明確になる可能性があります。
そのため、現在は次の2つを分けています。
| 状態 | 意味 |
|---|---|
| source受入済み | 開発側で内容を確認できた状態 |
| 本番runtimeへ未反映 | 正式な反映手順・時刻・監査がまだそろっていない状態 |
source側で確認できたことは前進ですが、本番反映の完了とは書きません。
ACTIVE運用中は、当日の差し替えをしない
現在は正式ForwardをACTIVEで運用しています。
当日のレース計画や起動準備が始まったあとにruntimeを入れ替えると、計画を作った時点と実行した時点で版が変わるおそれがあります。予想そのものが正しくても、記録のつながりが切れてしまいます。
そのため、当日のrun直前に更新することはしません。反映するなら、当日planやAgentが動いていない時間帯を選び、実行中のprocess、lock、一時ファイルなどが残っていないことを確認してから進めます。
反映前には、内容だけでなく一致も確認する
本番runtimeへ反映する際には、単にファイルをコピーするだけでは不十分です。
確認する項目には、次のようなものがあります。
- sourceとruntimeの対象ファイルが一致していること
- manifestとSHA-256で、反映する版を確認できること
- バックアップと切り戻し経路が用意されていること
- DBや実行環境が正常であること
- 反映してよい時刻であること
- 作業前後の監査記録が残ること
こうした確認がそろって初めて、反映を判断できます。どれか1つでも不足していれば、反映しないという判断になります。
NO-GOは失敗ではなく、安全に止まれた記録
以前のpreflightでは、当日の計画作成後にruntimeを差し替えると版の整合性を確認できないため、NO-GO と判断しました。
ここで大切なのは、無理に反映しなかったことです。変更を見送った結果、当日の正式運用を別の版で動かしてしまうことを避けられました。
開発では、実行できた回数だけでなく、条件がそろわないときに止まれた回数も大切だと考えています。
今回のまとめ
本番に反映する改善は、内容が正しいだけでは足りません。
- source側で確認済みであること
- runtimeとmanifest、SHA-256の対応を確認できること
- 当日の正式runに影響しない時刻であること
- バックアップ・監査・切り戻しの準備があること
- 明確な承認を得ていること
現在、source側で受け入れた改善はありますが、本番runtimeへの正式反映はまだ完了していません。今後も、反映できる状態がそろったときだけ実施し、完了したことと準備中であることを混同しないように記録していきます。
コメント