ミリシタ3周年の運営ミス雑感

結論:エンジニア目線ではツーストライクくらいまで追い込まれてます。

ミリシタ3周年のバグは何だったのか

直接の原因はおそらく境界値問題のテストケース不足によるリフレッシュ強制明けバグだと思います。なんでそういう設計だったのか、外野からは理解できないところですが…… <と<=を間違えたのかなというのが正直な感想です。

→と書くとJSTとUTC-7の差が……などと言いたくなりますが、普通の実装なら日付依存のコードになります。そして、日本より早く一日が始まるのはほぼ無いですし、このご時世にJST+5(つまりUTC+14)にミリPがいる可能性はほぼゼロでしょう。せいぜいUTC+12です。話を聞くと19時に強制リフレ明けとあったので、UTC+12ではまだ最終日前日であり、バグりそうにないのです。UTC+8以下の場所ではそもそも最終日の判定側が狂って最終日15~24時リフレッシュという方向にできたなら標準時絡みのバグの可能性が高まりますが。

なんでここまで大事になったのか

時間不足

判明したのが実質的に終了日で、バグによって有利になったプロデューサーさんに、バグ時間中のアイテム消費・ポイント積算・ブースト消費を全部ロールバックすること、その点数計算はまだしもアイテム消費の返却はイベント期間中、しかも早ければ早いほど良いし、門限は(おそらく)15時というレベルの緊急事態でした。実際には18時となりましたが、この影響で100位を逃した人が居たかもしれません。(ただ、リフレッシュ時間の意味を考えて適切に回さなかった優秀なプロデューサーさんのほうが有利になるのはイベントの仕様からしても適切であろうとは考えます)

そして、この時間不足で急いでいたことが次の悲劇を起こします。

条件ミス

発生条件を検索してユーザー単位でロールバックするという方針自体は全く間違っていなかったというのは私のスタンスです。しかし、この検索条件が発生条件と一致していなかったのが第二のミスでした。

元来ユーザーからのバグレポートなんて、ふわっとしたやばいことがあること程度しかわかりません。バグレポートの書き方に近づけて出すなんてことはふつうしませんし、普通に「〇〇ができないんだが、訴訟」みたいなレベルになります。簡単に条件を解析できません。なので、最初の仮定が間違っているなんてことはよくあるのですが……

確からしいと考えた仮定が間違っていたということが第二の問題でしたが、これもBigQueryに残っているデータで検算というかデータ検証をすれば十分に防げたと思います。ここもテスト不足でしたね。ユーザー対象漏れは難しいですが、過剰対象は道標の数の増減が指定した9時間ないことを監視すればいいだけなのでできないとは思えないのです。

ユーザー過剰があれば条件が間違っている可能性が高まり、再検証の機運が高まります。ここでBigQueryを札束で殴って全ユーザーのリフレッシュ設定とリフレッシュ休み時間(道標判定)をやっていれば条件ミスは防げたはずです。……が、これをやる時間がなくなるのが時間不足なのです。どうしても限界があるのはしょうがないですね。

今後の対応の中身を検討する

見てわかることと、推定が混ざっています。


不具合DMを受け取っていて、訂正DMも来た人

運営指針→不安にさせてごめんなさい。ポイント減算はしません。別途詫び品を出します。但し過剰なアイテムで走った場合は、そのポイント分は減算します。(これはどう考えるべきかは議論の余地あり。ボーダー当落線の人が居た場合大変可愛そうな結果になるかもしれないので。アイテムの余剰がない場合に仕事走していたよという人には大変不幸な結果かもしれません。この点だけ不満が爆発しそう)

不具合DMを受け取っていて、実際不具合があった人

運営指針→不具合の利用分に関してはDM通りポイントの減算をします。(別に誰も困らない。リフレッシュの意義を考えれば走ったのが無効になっても「休めと行っているのに」で終わります)+(推定)一部の過剰配布の分を配布する可能性があります。

不具合DMを受け取らず、実際は不具合があった人

推定運営指針→不具合利用ですが、こちらの告知ミスのため、ポイントの減算はしません。(以前のバグ利用の適用条項から考えればこの考え方が自然) + (推定) 一部の過剰配布の分を配布する可能性があります。

不具合DMを受け取らず、実際不具合もなかった人

運営指針→このグループに対する詫び品はありません。(次の項目の詫び品がカバーします) + (推定) 一部の過剰配布の分を配布する可能性があります。


上記がイベントの不具合の発生状態による運営指針と思われます。その上で

(スコアタリセマラ等の)不正行為対象者以外

推定運営指針→詫び品の配布を行う(当然ながらランキングが1週間もずれ込むユーザー大迷惑を被ったので、当たり前のムーブだと思います。程度はどうあれ)

(推定)ミリコレの延期

私の読みですが、7月のミリコレは延期だと想定しています。というのも、ミリコレの期間は5~7日間です。7/13(月)スタートの7/19(日)終わりは最長パターンですが、このミリコレ期間を全て潰してログの精査をする覚悟を決めたのだろうと見ています。

プラチナスターツアー~Parade d’amour~のほうが優先度の高いイベントであるのは想像に難くないですし、究極を言えば、8月のミリコレネタを来年に回したりして今月のミリコレを押し込んでしまえば8月の事なぞ誰にもバレません。(ミリコレが1ヶ月延命される事による運営のズレは知りません)

まあ、上記対応が長引きそうなのに、カードの実装アセットを出してしまった運営は3ミス目なのかもしれませんが(笑)

ミリコレは14日から開始します。書き忘れていたけれど、すでに半年以上安定的に動いているコード上で、データだけ実装すれば良いイベントは運営的には品質の良いコードでこれ以上のバグが出ないことが担保されていると言えるので、イベント実行自体は問題なかったのです。

イベントバナーの表示問題が有りそうだなと上の延期で書いていたのですが、そういえばエイプリルフール→Justice OR Voiceの流れのときにイベント中にイベント予告やっていたような記憶がありますし、イベント後とイベント予告・イベント中の状態も出来るということになりそうです。気付けなかった。

まとめ~実装時に気付けば軽い損害が後で見つかるほど大爆死になる良い教材~

プログラマー諸君は当然知っているはずの反面教師としてミリシタが日の目を見ることになるとは私としても思ってなかった次第です。(不具合は先に発見したほうが修正コストが低い)

コロナの影響でデバッガーがまともに動けていないのだろうと思いますが(以前バイトでブラックボックステストをやったときの環境から考えれば、セキュリティレベル的にガチガチにロックされた空間で別にプログラマーでもないなんちゃってデバッガーの数で勝負する世界です)検証量の不足がモロに爆発して保守管理の人が泣いている現状です。ある意味今回ミリコレを止めたのも、開発側の多少の負荷低減のためだろうとは思います。

ただ1月の80連おかわりバグと今回の件を重ね合わせると、どうもミリシタスタッフのDB操作での条件設定はガバガバだなと思います。もっとDB系のまともな人材を入れないとダメそうです。このコロナ下ではそうも言ってられないので、今のDB担当をもっと教育してあげてくださいね?

Comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

Vivaldi