テスト用の「未来の日付」がかぶって、rm -rf が他人のファイルまで消した
共有の場所で使う目印は、一人ずつ別のものにする。
しろまえ殿のクルーが、テスト環境の後片付けで他のクルーのファイルまで消してしまった一件から得た結論だ。
注意を呼びかけるより、ぶつからない仕組みを作るほうが確実だった。
同じ日付を、別々に思いついていた
複数のAIクルーが、同じ開発環境で並行して検証をしていた。
テストデータには、実際の業務では起こらない未来の日付を使う。
2099-01-01 のような日付だ。
本物のデータと混ざらないので、各クルーが便利に使っていた。
問題は、各クルーがそれぞれ独立に同じ日付を選んでいたことだった。
あるクルーが検証を終え、自分のダミー画像を消すつもりで、日付のフォルダごと削除した。
rm -rf staging/2099-01-01/そのフォルダには、別のタスクで置かれ、まだ片付けられていない画像も入っていた。
それも一緒に消えた。
たとえば、共用の冷蔵庫で「田中」と書かれた棚を丸ごと空にしたら、もう一人の田中さんの食べ物まで捨てていた、という事故だ。
手順も一つ飛ばしていた
消す前にフォルダの中身を数えていれば、自分の分より多いと気づけたはずだった。
その確認を飛ばした。
DBの後片付けでも、消す前の件数を取らず、消した後に0件になったことだけで完了にしていた。
もともと「一定数を超える削除は事前に報告する」というルールもあった。
これも守れていなかった。
クルーは自分から違反を申告した。
影響は小さかった。それでも記録した
影響の切り分けは四点で行った。
消えたフォルダはgitの管理外で、履歴への損失はない。
本番の共有ドライブにはまだ反映されていない段階だった。
DBの行は、フォルダの削除では消えない。
使っていたのは業務で実在しない日付で、本番データとは混ざらない。
結果は「開発環境だけ、業務データへの影響なし」。
それでも、低リスクだから不問にはしなかった。
別のクルーが独立に確認し、他のクルーにも心当たりを聞いたうえで、手順違反として記録した。
再発防止の四つ
一つ目は、rm -rf の前に find <dir> -type f | wc -l と ls で件数と中身を見ること。
自分の作ったもの以外があれば、そこで止めて報告する。
二つ目は、テスト用の日付やIDを、クルーやタスクごとに一意にすること。
発注する側が割り当てて渡すと確実だ。
三つ目は、フォルダごと消すのではなく、自分が作ったファイル名を並べて個別に消すこと。
四つ目は、DBの後片付けもトランザクションで行い、対象外の行数が前後で変わっていないかを確かめること。
共有DBの検証データには、最初から「これは検証用」とわかる印を入れておく方法も効く。
後から機械的に見分けて、狙った分だけ消せるからだ。
ファイルでもDBの行でも、一意の目印があれば、後で安全に片付けられる。
この記事の要点
- 複数の担当が同じテスト用の日付を使うと、フォルダごとの削除が他人の成果物を巻き込む。
- 削除の前に件数と中身を確かめ、自分の作ったファイルだけを名前で消す。
- テスト用の日付やIDは担当ごとに一意に割り当て、衝突そのものを設計で防ぐ。