こんなお話をTwitterでも観測していました。
要するに、「「１年間ログインしていなかった人についてデータを消す」という仕様が誤爆して、頻繁にログインしている人も含めて片っ端からデータが消えた」というなかなかハードコアな事態が発生したらしいのですね。
で、今改めて確認させて頂いたところ、
shinzaki / しんざき
RT @KgPravda: 公式に問い合わせたら、「不具合が見つかりませんでした」とお言葉を頂戴した。やっぱり不具合なんて無かったのか、心配して損しちゃった。 at 09/25 00:13
どうもデータ復旧はなされていない、ないし部分的にしか為されていないようです。「どう見ても誤処理で多数のユーザーのデータを消しておきながら、不具合は発見されていないと運営が主張」という、なかなか大変にロックンロールな状況であるように思います。それでもゲームへの愛を失わないユーザーの皆さまには敬服致します。
「1年以上ログインしていないユーザーについてデータ削除」という仕様がそこまで一般的なものかはわかりませんが、もし私がこの処理をDBの方から作りこむとしたら、多分こんな風に考えると思います。
1.定時監視を人力でやるとか考えたくないので、当然バッチ処理で作ろう。バッチ処理はcronかなにかでメンテナンス時間中に動くようにしとこうかな
2.仕組みとしては、アカウントのデータに最終ログイン日時のデータを持っておいて(ないしそれ以外のセッションデータから最終ログイン日時を計算出来るようにしておいて)、最終ログイン日時が現在の日付から1年以上前であるアカウントをselectして、当該のアカウントについてデータ削除のスクリプトを走らせるようにしておけばいいかな。
例えばこんな感じ。
begin
for cur in(
select 顧客ID
from 顧客テーブル
where 最終ログイン日時 <= (現在日時 - 1年)
)loop
(取得した顧客IDについての削除処理)
end loop;
end;
インデントが動作してない点については勘弁してください。
3.ただ、万一の誤削除が怖いから、いくつか対策しておこう。
・データについては論理削除フラグを用意しておいて、バッチ処理の時点では論理削除のフラグだけ立てるようにしておく
・その後、週次ないし月次の定期メンテナンスなどで、論理削除のフラグが立ったデータについてのみ物理削除をする形で負荷軽減する
・当然のことながらデータのリカバリ対策はしておこう。フラッシュバックリカバリが使えるDBならそれでいいけど、そうでなかったら日次でdumpデータとって、ログと合わせて特定時点までのデータ巻き戻しが出来るようになっていれば安心だな。多少の巻き戻りは勘弁してもらおう
4.当たり前だけど、バッチ処理を作った時点でちゃんとテストデータを作って動作テストしよう。あと、初回のバッチ動作の時は一応立ち会って、データ削除が問題なく動作するか確認しようかな
上記の思考自体は多分割と一般的なものだと思うんですが、今回のケースでも同様の実装方針だったかどうかはわかりません。
ただ、「誤って全データを削除、しかも戻せない」というケース自体は、2,3,4の全てにおいて何かしらトチらないと発生しない筈です。
２について：アカウントIDの抽出条件の不備によって本来対象ではないアカウントが対象になる、ないし削除処理の不備によって抽出したアカウント以外のデータについても削除してしまう
3について：データのバックアップに不備がある、ログをとっていない、論理削除ではなくいきなり物理削除しているなどの理由でリカバリ出来ない(バッチなどで多分トランザクションはバッチ完了時点でcommitされている筈)
4について：テストをいい加減なテストデータでしかしていない、ないしテスト自体をしていない
多分これらのいずれか、恐らく複数のケースには当てはまっているのではないかと。開発チームのrockっぷりが伺えます。ろけんろーーる。
ということから、恐らく初代サムライスピリッツのような不退転一撃即死、武士道とは死ぬことと見つけたり的な運営方針をとられているのではないかと推測します。漢らしいですよね。shinzaki / しんざき
RT @KgPravda: メールによれば、「愛との約束」は、長く日本に滞在している中国人技術者とその後輩の２名が、平日の夜と休みの時間を切り詰めて開発したゲームだった。「侍の芯を探求したい」という文面を読むと、侍之城という作品は、日本に対する彼の「侍」の答えだったという事に、… at 09/25 00:11
愛との約束の今後のご発展を深く祈念致します。
今日書きたいことはそれくらい。
