図で技術的に何が起きたかを解説 スマホゲーム『偽りのアリス』の不具合報告がやたら丁寧と話題に「BtoBみたいな報告で草」「なんだこの説明量は」

なるほど(わかってない)
テクノロジー
225
偽りのアリス 公式アカウント @itsuwari_alice
今回のサーバー障害に関する詳細情報をご報告致します。 ユーザーの皆様には大変ご迷惑をお掛け致しました事 改めてお詫び申し上げます。 今後とも偽りのアリスを何卒宜しくお願い致します。 #イツアリ pic.twitter.com/0KSXAEA0Ab
拡大
拡大
拡大
拡大
偽りのアリス 公式アカウント @itsuwari_alice

ビジュアルアーツ teamAecaが手掛けるスマートフォンゲーム「偽りのアリス」公式アカウントです。 ゲーム情報や運営からのお知らせをツイートします。たまに中の人。 #イツアリ

https://t.co/COYzvRNiYd
🐻せるなさん🐻配達屋の画集で感激 @neige_soukuu
すごい!めちゃくちゃわかりやすい、サーバー障害の一部始終。 twitter.com/itsuwari_alice…
木綿豆腐 @momendofu_ps
なんだこの不具合復旧の説明量は、やべえ

わかった人

越前 @echzn
ほー、書き込みと読み込みでDBを分けるって実装なのね。いまいちどういう効果があるのかわからんけど、やっぱり今回みたいな障害発生に備えてなのかしら。
夜音 @shure16x
なるほどな、書き込み用DBと読み込み用DBを別のサーバーにすることで、冗長構成も取れるし、尚且つ負担が減らせるということか…考えてる
_ @ariaribababa
こえーちょーこえー。すんでのとこで一歩間違ったらライトもリードも不整合データ発生やんけー。
ゆーの @uno_sgame464
@itsuwari_alice ここまで詳しい障害説明はじめてだわ。Writeまで壊れてたらえらいことだったね。 ともかく復旧してよかったですわ。説明乙です。
春日 @haruhi603
@itsuwari_alice @hoshinotakayuki 内外ネットが落ちて、DBリンクが切れ途中データの整合性がとれなくなって動けなくなった? 外部リンクはわかるとして、内部リンクまで同時に落ちるってのは痛すぎ、せめて冗長化しといて欲しい >o<!

わからくてもまあ許せるよね

聖 璧悟@フォロー出来ない男 @seitamago09102
ここまで説明するとか凄いけど、一般人にはわかんねぇw twitter.com/itsuwari_alice…
♠︎のあ♤ @Noa_0225_0301
@itsuwari_alice あーね。なるほど。運営サンありがとうございます。機械音痴の私には全くわかりません。 とりあえず楽しいので大丈夫です(??)
ハッソウ @JHakgf
うん、分からん。 まぁ、復旧したので良し。 twitter.com/itsuwari_alice…
ねね@春休み @nene__ita
ごく分かりやすく図になってるのに分からん 復旧作業お疲れ様です
@1112345678999
よくわからんけどクソ大変だったんだろうなってことは分かった

ユーザーが欲しいのはベタ謝りよりも説明?

言離 猫助@FGO @nekosuke4264
これまでのアプリゲームには無い新しい障害報告書…ガチ謝罪感好き twitter.com/itsuwari_alice…
\(^o^)/ @KL2128
詳細まで報告してくれる運営とか珍しすぎるw 神かよ... twitter.com/itsuwari_alice…
アマクラ @roz_zor
ちゃんと報告しててエラい!
紅坂柚月🦌みせる @micelle9
こういうこと書くの珍しい。
紅坂柚月🦌みせる @micelle9
普通はプライドとか手間とかで書かないよね。
残りを読む(3)

コメント

メラミ @merameramix 2019年12月19日
これはアレじゃない?店員に在庫聞いた時に一応見に行くフリでもした方が客が納得しやすいってのと同じで、障害内容が理解できなくても見える形にする事で納得されやすいみたいな
@onpu_original 2019年12月19日
これもしかして社内用とかで作った資料をほとんどそのまま流用したのでは…w
トモマサ🔞 @Mattyan_shida 2019年12月19日
中途半端で更に燃料投下になりかねないような謝罪文を公表するよりも、障害が起きた原因や復旧までのプロセス等をできるだけ分かりやすく説明したほうがユーザーからしたら「よくわからんけどヨシ!」ってなるのかも
フルバ @furubakou1 2019年12月19日
ごめん、さっぱりわからないどころか見た瞬間に理解する努力を拒否した!
Yeme @yer_meme 2019年12月19日
ネットワーク障害が発端でリードレプリカ破損したんスね。分かりやすいっス。滞在としてネットワーク障害でもリードレプリカが破損しない、ないしは自動復旧するようにすれば対策としても完璧っスね。SE同士でもなかなかスっとは出てこない良い説明っス。
とらくろ @trakron 2019年12月19日
たぶんこれを見た「こういうのに詳しい層のプレイヤーあるいは外野」が説明してくれる…的な期待もこもっているのでは
trycatch777 @trycatch777 2019年12月19日
良い説明だと思います。内容も濃すぎなくて。 ここでは大抵の処理はデータ更新より参照の方が圧倒的に多いので、Read専用のデータベースがWrite用1台に対して2台ずつ用意されてる。Write用のデータベースにデータが更新されるタイミングでReadの方にも同じ更新が行われる仕組みになってるけど、そこはネットワーク経由なので、その「Readへの書き込み処理」の最中にネットワーク障害が起こったため、Read用とWrite用の間が不整合が起こってしまったってことでしょう。
okwae @okwae858 2019年12月19日
不思議の国の情報を格納するサーバ見てみたい
骨格 @black_nasbee 2019年12月19日
ユーザー「詫び石は?」
あーる @xxxk_ac 2019年12月19日
現在進行形で不具合ガン無視してる剣盾の画像リプに草
もくざい @mokuzai_tig 2019年12月19日
元ソシャゲ運営だけど、めんどくさいお問い合わせしてくる人には、これくらい詳しく説明してた… どんだけカスタマーサポートとエンジニアが消耗したか…
おろろ @fYe39CoQsPrbZVK 2019年12月19日
一枚目わけわからんなこれ。こんな壊れ方せんやろ
海◆eoxyl9RE @umi_eoxyl9RE 2019年12月19日
読み込み用は生きていて書き込みが死んでると、これまでの冒険の記録は出てくるが、新たに冒険を始められない感じかな
いぬ @tada_suzu 2019年12月19日
このくらいわかりやすい図を書けるようになりたい。
denev @_denev_ 2019年12月19日
ソースコードまで公開したドラゴンボール
saku @sakuuuuuuune 2019年12月19日
偽りのアリスは、障害を偽らないという高度なギャグ
野獣後輩 @yaju5123 2019年12月19日
fYe39CoQsPrbZVK パラメータ設定か何かミスって参照先にエラー起こしたとかそっち系ですかねコレ
しゅう @SetPM 2019年12月19日
実際、紙芝居みたいに絵作って軽く進捗説明な方が納得してくれること多いから楽だよ。資料作る手間ってテンプレ一枚作った後に軽い説明文追加とアイコンの配置変えくらいだし。
Metallis(PIU筐体買取中) @c7R1S0tU 2019年12月19日
艦これ恒例のメンテ延長もシーケンス図のどこでトラブってますってやってくれりゃいいのに
緋蓮@雑多 @hiyokurenri688 2019年12月19日
ちゃんとトラブルの原因分かってます、その上で治しました、って説明してくれるのは安心する。
セバスチャン小林(裏) @Dongpo_Jushi_x 2019年12月19日
でも下手にキッチリ説明されるとたまに「えっ、そこ、冗長化してないの…?」ってかえって心配になる場合もあるなあ。byインフラ屋
†ヒロセジロウ† ✏️ @denjiro13 2019年12月19日
何か問題が発生したのなら、ただ謝るのではなくちゃんと説明する。理解してもらえなくてもいいから、とにかくすべてを説明することの重要性
金目の煮付 @kinmenitsuke 2019年12月19日
原因が書かれて(描かれて)ないけどね。
ポッカ @pokka80 2019年12月20日
ホストOSが落ちたのか?スイッチングハブに障害が起きたのか?分からん
ZIMBA @zimba_dqx 2019年12月20日
エンジニア目線だから面倒臭い問い合わせする人には説明したほうが信頼されるか。
愛媛人と大阪人のハーフ @TmtRj 2019年12月20日
面倒くさい奴に絡まれる前にさっさと報告しただけなんじゃね?復旧してくれればあってもなくてもいいや。
Earwax @Earwax97409510 2019年12月20日
クラウドでネットワーク障害から復旧に15分、って未だかつて経験無いなあ。CloudWatch(AWSなら)のメールで一杯になりそうだ。恐ろしや
Earwax @Earwax97409510 2019年12月20日
yer_meme 自動復旧はしたっぽくないですか?時刻からして。目検にしてはノータイム過ぎるかと
ジョエーウ @joejoeu 2019年12月20日
絵図を時系列でならべて説明というのは『ビデオ判定」みたいなもんで、疑惑を素早く収めるのに効果が高いんでしょうな。ドライブレコーダーもビデオ判定の一種だし、時代。
RAIYA@提督 @RAIYASB 2019年12月20日
SEやNEからしたらすっごく参考になる説明で草 Earwax97409510 自動復旧したのはクラウド側だと思います
ぼんぼ (唐揚げに大根おろし&ポン酢醤油) @tm_bonvo 2019年12月20日
fYe39CoQsPrbZVK そりゃ物理的には相互に繋がってるわけでなく、ネットワーク機器を通して繋がってるので、肝心なネットワーク機器が壊れたら終わりですよ
coilcoils @coilcoils 2019年12月20日
「鏡の国」も準備しとけ
新米のれいじポーター @layzy_glp 2019年12月20日
仮想ネットワーク死んだらDBのレプリケーション切れたって話かな?
gx9900 @GX9900GUMDAMX 2019年12月20日
説明したはいいけど、3日ぐらい進展しなかったら逆効果になりそう。説明でなんとかなるのは順調に治せるとわかってる時ぐらいか。
カムイさん @kamui10 2019年12月20日
さすが俺らのイツアリ!
野獣後輩 @yaju5123 2019年12月20日
coilcoils 鏡の国はDR用サーバーだった……?
な.ん.ば. @namba_1301 2019年12月20日
客を一番怒らせるのは、嘘つかれることなんだな。全部正直に話して怒る人は少ない
ゲーム用垢 @z1g6309 2019年12月20日
なるほどリードとライト用のDBを分けるのか。 このゲームは即時他人にデータの変更を反映させなくても問題ないような作りだからできることだな。
いるーか @iruka12go 2019年12月20日
「アリス」「不思議の国」というファンタジー感溢れるワードに、「データベース」「API」という現代のIT用語が並んでいるのがなんとも面白い。Read用DBのリビルドが上手くいって良かった。
いるーか @iruka12go 2019年12月20日
ReadとWriteでDBの機能を分けているのは、処理の頻度(Readの方が多い)や、速度(Writeの方が遅い)を考慮して設計したからだろう。DBが複数個存在することで、今回のようにDB間で不整合が生じるデメリットもあるけれど、ある時点でのバックアップとその後の差分データからDBは復旧できる、と。なるほどなあ。
ZIMBA @zimba_dqx 2019年12月20日
怒る原因とか面倒臭い奴が絡んでくる原因は、対外的な理由に嘘と信じていると思えば。
まんまるまるまいん @manmarumarumain 2019年12月20日
このゲームちょっとやってみようかなと思うくらいにはいい対応だと思った
たるたる @heporap 2019年12月20日
trakron trycatch777 図の方が理解しやすい人、文章の方が理解しやすい人、文章を朗読する(してもらう)と理解しやすい人などがいます。 https://togetter.com/li/1444497 ちなみに私は図の方が理解しやすいです。
らない @lanai_spr2 2019年12月20日
onpu_original むしろ下請けの開発が提出した内部資料を運営が利用者に丸投げしたのでは
たるたる @heporap 2019年12月20日
ソースコード開示は「運営が悪い」「開発が悪い」みたいな責任問題に発展したからじゃなかったっけ? ガチャの確率操作をしてる、してない、とかで。
yuki🌾㊗️5さい🎉⚔ @yuki_obana 2019年12月20日
言い方がダメ。もっと取引先に言うみたいに言って!の結果♪(´・ω・`)
おろろ @fYe39CoQsPrbZVK 2019年12月20日
yaju5123 多分レプリケーション壊れたか壊したかして認証系のトークンが更新できなくて全部入れなくなったとかやろな。クラウドの機器障害なら他の会社でも起きとるはずやしニュースにも出るやろし、15分じゃ原因すらわからんわ。
JIT_MIRUMIRU @JIT_MIRUMIRU 2019年12月20日
ちゃんと説明しようとする誠実さもさることながら、『図にしてみましたので、皆様にはお分かりいただけるかと(にっこり)』とやられたら、プライドの高いパソコンの大先生たちは「ぼくちんわからん」とは言えないだろうね。
ゲーム用垢 @z1g6309 2019年12月20日
原因を言ってないと言ってる人がいるけどネトゲ運営からすれば原因はクラウドベンダーがネットワーク障害やらかしたで終わる話なんだよなぁ。ネットワーク障害の説明責任があるのはクラウドベンダーだよね。
fai into VR @faifx 2019年12月20日
本音「クラウドベンダーがすべて悪い!」と言いたいのを我慢して、復旧の手順はこんな感じで、ここに時間が掛かっていたんですよ と言わざるを得ない運営に同情する
ポテチ @h4UoKS4uiga53r4 2019年12月20日
誰も原因なんて聞いてないぞ。早く補償の石よこせって言ってるだけで
きなこユキ @daizu_hiitakona 2019年12月20日
最早ホップがなんでも褒めてくれるやつに
【わちゃっとピンボールDLよろしく勇気!】ねねっとテックダイナー @nenet_techdiner 2019年12月20日
可視化って意味ではソース晒されるより僕はわかりやすいと思ったw
団扇仙人 @uchiwamaster 2019年12月20日
「ちゃんと説明しろよ(説明とかいいから詫びよこせ)」「わかりました。ちゃんと説明します」「お,おう…」
Off Black @OffBlack1 2019年12月20日
write側が無事だったから復旧も早かったんやなとは思うが、家に帰ってまでシステムリカバリ構成図など見とうないわ
ウッドロウ雷鳥🖖♌ @CHICKEN_TODO 2019年12月21日
ここまで構成を公開して大丈夫なのか逆に不安・・・(´・ω・`)
JIT_MIRUMIRU @JIT_MIRUMIRU 2019年12月21日
CHICKEN_TODO 公開したところで何のセキュリティリスクにもならない内容。
トケイネコ @tokei1974kuro 2019年12月23日
ちょっと前に理系の卒論発表は分かりにくいってまとめがあったけど、この報告みたいにわかりやすさより正確さを重視しなければいけないって考える学生が多いんじゃないかな。
akkr @akkr333 2019年12月25日
trycatch777 あーなるほど。Read1台とWrite1台に分けようが、単純にReadもWriteもやる2台を用意しようが大して変わらなくない?と思ったが、ReadとWriteで負荷と故障リスクが大きく違う場合に、それぞれ割り振る台数を変えることでリスクに釣り合うリソースを割り当てられるのか。
ゴロニャーゴ @nukopoint 2019年12月25日
faifx まあ、クラウドベンダーに任せるにしても自前でインフラ組むにしても、ある程度障害は出るからね。正直に話して理解してもらうのが一番。
ゴロニャーゴ @nukopoint 2019年12月25日
CHICKEN_TODO このシステムならではの要素は「Write系とRead系に分けている」とか「1DBに対してRead2台」くらいだから大丈夫でしょう。
S.O. @so_rei 2019年12月25日
たぶん9割ぐらいの一般人は理解出来ないと思うぞ。
降霜 @kousou666sub 2019年12月26日
これだけスマホげー乱立する現状、[多少のゲーム内容の優劣]より[運営への信頼や顧客への態度]を優先する人は多いだろうしなぁ。顧客にしてみても続けるなら年単位、万円単位での付き合いになるわけだし。
ログインして広告を非表示にする
ログインして広告を非表示にする