取引履歴の保存障害
不手値するほど話したい。この番組は、システム開発25年の株式会社プラムザが、赤坂より開発現場の今と本音をざっくばらんに話していこうという番組になります。
進行は私、鴨志田と、代表の鴨志田と、賑やかし役の辰巳です。よろしくお願いします。
さて今回のタイトルなんですが、前回の過去の障害誤選に引き続き、後編というところで、過去の障害誤選後編、あの時は死ぬかと思ったというタイトルでやらせていただこうと思います。
というところで、早速辰巳さん、お伺いしてもよろしいでしょうか。
はい、4つ目ということですかね、これが。
そうですね、4つ目になりますね。
これはですね、とあるECEに近いけれども、小取引をネット上で行うという企業間でですね、というシステムを開発から弊社で携わっていて、保守になっても結構時間が経つシステムなんですけれども、
障害ってどこから原因が出るかってなかなか難しいところなんですけど、
起こった事象としてはですね、取引の結果が保存されてなかったという状態になりました。
いろんな商品を取り扱うんですけど、一部のカテゴリにおいてですね、最終的にいくらで購入が決定しましたっていうのが保存されてなく、
そのシステムでですね、月間の取引額として本当にもう数百億。
それで売上とか手数料とかいろいろまた別ですけど、商品が流通する金額っていうところで言うと本当にもう数百に達している。
当初数十億、百億ぐらいだったところが本当に指数関数的によく使われているので、それぐらいのボリューム感があった中で、
そのうちの一部が取引の行方が分からないっていう状態になってしまって、履歴としても残ってないからどうしましょうと思ってました。
なんでこれが起きたかっていうとですね、直近回収を行ったんですね。
その影響で、ユーザーというかオペレーター側に近いかもしれないですけど、我々が想定していない操作を行って、そこも我々が考慮漏れだったってところは当然あるんですけど、
そうしたらですね、そのトリガーによって保存がされないような挙動を振る舞いをしてしまいまして、
で、蓋を開けてみたらあれなんかデータ残ってなくないっていうのが来て、ちょっと緊急事態ですっていうことで、日曜の昼間に連絡が来て、
やばいやばいやばいと思ってですね。
でもその前日ぐらいからちょっと数字おかしいかもみたいな話が来ていて、やっぱりやばいですよと。
なんでしょう、ずっと原因調査をしようと思ってもなかなか解決の糸口が見えず、パッチを当てるような形で回収を入れてみてもラチ開かずで、
気がついたら次の日の昼間になっていて。
多分これ島田さんにも相談した記憶がありまして、ちょっとやばいですどうしましょうみたいな。
一回解決したと思ったら直ってなーみたいになって。
最終的に我々としても結論としたら、なんでしょうね、運営の方が結局現場で報酬をするらしいんで、
メモ書きで一応その取引の最終的な金額っていうのはマニュアルですけど紙に控えてる状態だったって、
それ入力してもらうしかないですよねって話になって。
オペレーション上入力してるらしいんですけど、そこの一回目で確実に保存できてなかったってところがあって、
もう一回書き加えてもらって良いでしょうかっていう平山ですよね。
その日の夕方には収束したっていう形になりますね。
元旦のシステム障害
なるほど。ちょっと取引履歴が残ってなかったっていうところでどうするんだろうっていうのを考えながら聞いていたんですが、
最終手元にデータというか書き残しですかねを控えてあったので、同じような形のデータを入れることができたっていうところです。
そうですね。それがなかったら終わってたと思うんですよ、完全にね。
これしまさ仮に残ってなかったらどうするもんなんですか。どうしようもないですよね、これ。
ダメだね。
ダメだね。
オペレーション上、よくも悪くも必ずそこに紙に書き起こすようにしてらっしゃったらしいんですよ。
それが幸いでしたよ。
なんかちょっとあれですね、夏にふさわしい怖い話だなって。
ちょうどしかもう1年前ぐらいなんですよね、時期的に。
本当にその時、夏の暑い日にスーツ着て先方のオフィスに謝りに行ってみたいなこともしましたし、大変でしたね、その時は本当に。
ただめっちゃ怒ってるもんね。
そこから今のところ大きな障害もなく順調に運用できてるので、今後も何も起きないことを祈りつつ引き続きやっていかないとというふうに気が引き締まる思いでございますね。
いやもう怖いなと思って聞いてましたね。
怖いですよ、マジでびっくりしました。
ありがとうございます。では島田さんお願いしてもよろしいでしょうか。
私ですか。
はい。
私のタイトルは言ってなかったっけ、元旦オチっていうのがあって、そういうシステムの何とかオチっていうのは結構あって、それもやつですね。
最近は全然やってないですけど、うちも小さい会社だった時に動画配信とかをやらせていただいたりしてまして、昔は動画が、今AWSだとS3とかあってDRMのデジタル著作権方法みたいな仕組みがちゃんとあって、勝手にデータを持っていかれないっていう、動画を持っていかれないっていう仕組みが簡単に作れるんだけど、
昔はそういうのなくて、普通にですね、ファイルを置いて、そのファイルのフォルダ名をランダムの複雑な形にしとくという風にして、権利を持ってですね、動画買った人はランダムの文字列についているフォルダの中に入っている動画にアクセスするんでダウンロードできるみたいな、そういう仕組みになってたんだよね。
なるほど。
で、当時ね、にちゃんとかにそれを書くやつがいて、ここにアクセスすると撮れるよみたいな感じで書かれちゃうんで、それをですね、定期的にランダム文字列を変更するみたいな、そういう仕組みが入れられたわけですよ。
そういう風になってて、それはそれでうまく動いてたんだけど、年が変わるとフォルダ名が20ゼロイチだったら2002に変わるみたいなね、そういう仕組みが必要になってて、古い動画をどんどん削除していくっていう仕組みになってるんで、3年以上経つと削除するみたいな仕組みがあるんで、
全部こうフォルダ名を新しく作って、古いやつから消していくみたいなバッチがですね、夜中に走るんだけど、それが1月1日になるとうまく動かなくてですね、ほけるんですよ。
なるほど。
そうするとですね、1月1日に苦情がものすごい来ると。先方の社長のところに社長とか会社に苦情がいき、それがそのまま家に来て、アクセスできないってすごいクレーム来てますよって。
正月からですね、こっちもクレーム受けて、当時は自分もフロントに立ってたんで、すぐエンジニアに連絡してアクセスできないって言ってるよって。もうあれだよね、元旦から大変てんやわんや。
それをやって直すんだけど、それテストしにくいんだよね。サーバーの引き続きを変えてさ、テストとかってできないじゃん。なのでまたやらかしたんだよね。
で、さらにもう1回やったんだよね、確かね。3年連続でやりましたよ。
対策の取りようもなかったんですかね、当時は。
そうだね、あったのかもしんないけどね、ローカルのサーバーを立ててやってみるっていうのね。
ただファイルの数が膨大なんで、ローカルで動いたかといって本番サーバーで動くかどうかっていうのはまた分からなくなったりするんだけどね。
まあそういうことがありまして、毎年元旦はビクビクしてるっていうね。それからもうしばらく元旦か、なんかすごい昇半近年だからみたいな。
障害の共通点
結構不安に思ってるのが続いてたけど、最近は分からなくなったけどね。
最近はそこら辺の年が変わる、日付が変わる。日付が変わるあれかもしれないですけど、年が変わるっていうことによる障害みたいなものは根本のシステムから解決されてるみたいなことになってきてるってことなんですかね。
あんまり年によってフォルダ作るとかそういうことやらないかな。
ただやっぱり、例えば注文番号とか会員番号とか発売するときに年を使って作ってると突然動かなくなるとかあり得ない。
例えばないと思うけど、令和でやってると今7年か、それが二桁になると何か不具合を起こすとか、そういうことが起きなくはない。
昭和と平成の切り替わりのタイミングとか結構あれもしんどいですよね。
そうね、そういうのもあるよ。言語とかやばいよね。
だからシステムでは基本的に西暦にしたいです。
そうそうそう。だけど役所とかで書類番号は言語でとみたいな要件があるんだよね。
誰得なんでしょうね。
そうなんだよ。
障害の共通点とかってあるものなんですか。
障害の対策と分析
根本わかっていればその前に対策するよっていうことが大前提だと思うので、基本的に予期しないものだと思うんですが、
何でしょうか、様々なシステムを作ってきた経験としてなんとなく危なそうだなみたいなものとか、そういったことを共有していただけると大変ありがたいんですが、
どうでしょうか。ちょっと無茶振り感が強いですが、辰美さんなんかこういうのとかあります?
そうですね。僕に関して言えることとしては、やっぱり潜在的なものが多いですよね。
潜在的。
起こってからじゃないと気づけない。どうしても、当然その機能の回収したり、新規で開発して納品するとかも、ちゃんとテストは当然しますと。
ましてや回収系だったらそこにフォーカスする、当てると思うんですけど、それ以外の部分でどこまで考慮するかっていう問題は多分テストとかにおいてですね、
どこまで影響範囲が及んでるかっていうのを徹底的に考慮は当然するんですけど、それでもなお抜け漏れが出てきてしまうっていうところがあって、僕の2パターンの障害っていうのは起きてるかなというふうに思います。
さらに思うところとしては、潜在的であるがゆえに、なかなか原因の特定に時間がかかるっていうのもありました。
特定さえできてしまえば、じゃあそれで治るのかっていうのも別問題ですし、やっぱりその対処法と原因ってすごい切り分けて考えればいいんだなっていうふうに思ってます。
ブラムザというかタツミとしては、起きてしまったことをどうするにフォーカスするよりかは、じゃあどうやってそれを直しましょうかっていうところを冷静になって向き合う必要が、システムや全体の共通理念としてあるべきなんじゃないかなっていうのはめちゃめちゃかっこいいこと言いましたけど。
悪いけどだんだん声が小さくなって、自信がないみたいな。
自信は当然障害を起こしたくないですからね。誰も得しないんで。
なるほどね。
お互いクライアントさんと歩み寄って、どうすれば最短で解決できるかっていうのを冷静に話し合える状態がいいなっていうふうに思いますよね。
その後、好きなだけ怒ってもらえれば全然いくらでも謝りますっていう感じですね。
ありがとうございます。
では島田さんいかがでしょうか。
そうですね。とりあえず障害を起きたときに感情的に怒られてもしょうがないというか。
お客さんによっては、昔自分の担当じゃなかったけど障害を起こしてなかなか治らなくて。
こっちも色々とやってたんだけど、お客さんの方がだんだんイライラしてきて、もうそこ行くかみたいな感じで事務所に来ようとしてたことがあって。
それは是非やめて欲しいって言って、やってません。それによって絶対スピードアップしないんだよみたいな。
すごいですね。何をしようとしたんですかね、来たとき。
まあのんびりやってんじゃないかみたいなふうに思ったと思うんだけど、いやそんなわけないから。
まあそうだね。治った後にですね、どうするかみたいなことを考えなきゃいけないですけどね。
あとやっぱり自分の障害を3つ上げたと思うけど、2つループでメールのアドレスが積み重なっちゃって、メールのアドレスが漏えいしちゃったよみたいな話とか。
こういうのはもう経験ですぐわかるので、最近はもうないよね。こういうことはやらないからね。
あとガンダムオチじゃないけど、ゼロ件オチとかっていうのもあって、システム作って開発してるときは全然大丈夫なんだけど、
お客さんのとこ納品して、いざ納品して、じゃあ全部データクリアしますよって言って、ゼロ件にしていざやろうと思うと動かないみたいなね。
落ちちゃうみたいなことがあって、ゼロ件だと動かないっていう、そういうこともあるんだよね。
そういうのも最近はもうわかるので、経験上ね、これやばいなみたいな、ちゃんとゼロ件でテストしておかないとやばいってわかるから、そういう経験は大事ですね。
経験が大事というところで、フラムドは25年システム開発をしてきているので、そこら辺の知見は溜まっているのと、
何よりこの問題解決において先方と話し合いながらすぐに対策打って何とかするっていうところを同じ方向を向いていけると迅速に対応できるんだなという話を聞いていて思いましたというところですかね。
全然まとまってはないですが。
障害が起きるたびに対策も練られたりしますし、経験としても蓄積されていくので、障害が起きるたびにフラムドは強くなっていきますという話ですね。
経験の重要性
筋肉細胞フラムドというところで、本日は終わろうかと思います。
良いでしょうか、全然まとまってないですが。
良いと思います。
本日はいかがでしたでしょうか。楽しんでいただけましたらフォローや評価をお願いします。
また、Xでも最新情報を随時発信していますのでよろしくお願いします。
システム開発に関するご相談がございましたら、公式ホームページからお気軽にお問い合わせください。
それではまた次回お会いしましょう。
ありがとうございました。
