といっても、ストレージそのもののOS不具合ではなく、単なるシェルスクリプトの問題か。
内容があまりにしょうもないですね。
リリース時の考慮不足というけど、若手が何かやらかしたのか。
内容見ると、実行中のシェルスクリプトをアップデートして、再読み込み時に未定義変数を使ってfind -exec rm（かどうかは知らないが、findからの削除をしたらしい）してしまったという。
パラメータチェックがなかったのかな。
ほかにも、findでファイル削除する時はファイルが持つ日時（ctimeやmtime、atimeとかで見えるもの）を見ると思うが、これ自体もしっかり注意しないと想定外の動きをしますから要注意ですね。
◆追記
適当なrhel環境で試してみると、実行中シェルのiノードが変わらないように更新すると、
更新後のファイルを途中から読み込むようですね。
※iノードが変わらないように、なのでcpコマンド等で更新すると変わらない。viやmvは変わる（statコマンドで確認可能）
そもそもスクリプト内の記述を気を付けるのもあるが、
更新対象ファイルが実行される可能性があるなら、実行されないタイミングを見計らうか、
更新タイミングでは実行されないようにしないといけないね。
◆追記２
さらに言うと、シェルスクリプトで以下のような設定をするとスクリプトエラー時に自動的にスクリプトが中断されました（bashでのみ確認）。
・参考
https://xtech.nikkei.com/it/article/COLUMN/20060227/230881/
#!/bin/sh
set -Ceu ★ここ
… スクリプトの続き…
Cは既存ファイルへの＞によるリダイレクトがエラー、eはエラー発生時に中断、uは変数の値がない（unsetやvar=見たくした場合）にコマンド実行エラーを発生させる、です。
リダイレクトは場合によるかもしれませんが、つけていると安心かも。
・京都大学
https://www.iimc.kyoto-u.ac.jp/services/comp/pdf/file_loss_insident_20211228.pdf
・これらを報じる記事
https://pc.watch.impress.co.jp/docs/news/1378005.html