Bug Shooting Challengeに行ってきました!

Bug Shooting Challengeとは,

BugShootingChallenge

Bug Shooting Challenge
株式会社mixiが主催するインターンで,実際にCREで行われている業務の一つである不具合調査を,実際に手を動かしながらコンテスト形式で体験していきます.今回はその第1回目でした!
 

CREとは,

Customer Reliability Engineeringの略です.CREはカスタマーの信頼性を向上させることを目的としていて,業務の一つとして不具合調査があります.
基本的にサービスを開発をするときは,テストを動かしてみて今まで動いていた機能が動かなくなった部分がないか,想定通りに実装できているかを確認したり,コードレビューを行ってセキュリティ的に問題がないか,可読性が保たれているかなどをエンジニア同士で指摘しあったり,ステージング環境のような本番環境になるべく近い環境を用意し問題なく動作するかを検証します.できるだけ不具合が起きないようサービスが世の中に出るまでに確認を怠らないのですが,それでもバグは存在します.実際にバグが見つかった時点で調査に入る訳ですが,そうすると今まで開発を行っていたエンジニアが作業を中断してバグ修正に入らなければならなくなり,開発を進めることができなくなります.そこで,バグに関する調査はCREを引き受けることで,開発を進めるエンジニアが作業を中断することなくスムーズに開発を行うことができます.
 
今回は,擬似的なアプリケーションが用意されており,そのアプリケーションに対するクライアントからの不具合に関する報告を受け,実際に手元にある擬似的に用意したサービスの開発環境(DBは本番に繋いである)と膨大な量のリクエストやアプリケーションのログ(詳しくは覚えてないけどG単位のログだった)を元にバグの調査を行いました.
 
 
 

インターン午前

技術説明

Bug Shooting Challengeで使用する技術の説明を聞きました.
2部構成になっていて,1部はWebアプリケーションが動いている環境についての説明,2部はログ解析を行う環境についての説明でした.
1部は,今回のWebアプリケーションは使用言語はRubyで,MVCフレームワークであるRuby on Railsを元に開発されていました.言語やフレームワークに関する説明はほとんど飛ばして,Dockerに関する説明を聞きました.他のVMと比べ,Dockerがどのような環境で動いているかとか.
2部は,がっつりとログ解析の環境についての説明で,最初に簡単な講義があって,後はワークショップ形式で進んでいきました.
 

お昼休憩

みんなで釜飯を食べました.
 

インターン午後

環境構築

擬似的に用意したWebアプリケーションの環境構築を行なっていきました.gitからソースコードをcloneし,docker-composeコマンドでビルドやコンテナの立ち上げを行なって,後はDBのデータを取ってきたりごにょごにょして完成.
ちなみにWebアプリケーションの構成としては,Docker上で,Railsで書かれているアプリケーションのコンテナと,DBのコンテナ,キャッシュのコンテナが動くっていうよくあるような構成でした.よくキャッシュ用途で使われるコンテナが2台あったのが気になったけど,今回はそのうち1台しか使用していないのかなって感じでした.
 

競技開始

調査してほしい内容と調査してほしいクライアントの情報が送られて来るので,それを元にどこで不具合が起きているのかを調査します.
一応今回はコンテスト形式で,実際に不具合を調査して,該当箇所を修正してプルリクを出す,修正できなくても原因を書いてプルリクを出し,そのプルリクの内容により優勝チームが決まりました.
私は普段Webアプリケーションの機能開発をRailsやReact,Redux等を用いて行っているのですが,主要なDBがグラフDBやElasticsearchであるためSQLはほとんど触れることがない状態でした.チームを組んでいたもう一人の方が,ログ解析が得意なようだったのでとりあえずログ解析はお任せし,Railsのコードを読み不具合が起きそうな箇所がないか調査していきました.後から聞いた話ですが,得意な技術が被らないようにうまくチーム分けが組まれていたようですね.
 
問題の内容とコードは,公開禁止らしいので割愛.
 
私たちのチームの進み具合としては,
1問目は原因までは特定できたのですが,私がデバッグに戸惑ってしまい修正まではできずに終了.
2問目は,なんとなく不具合になりそうな場所は当てをつけれたのですが,結局どこが原因だったのかはわからずに終了.こちらは解説直前に不具合の原因に気づいたので,原因だけでも回答したかった.
3問目は原因を特定し,修正後プルリクを出すところまで完了.プルリクに原因を書いていたのですが,ちょっと的が外れた回答をしてしまった.
といった感じでした.
 
問題を解いてみた感想としては,時間内にうまく解けなかったのが悔しかったです.後から解説を聞いたらそうだよなあって納得するものも多く,全く歯が立たないレベルの問題はではなかったです.制限時間が1問につき1時間程度だったのですが,もうちょっと早く解けたらなって思いました.あとプルリクに関してはちょっと雑に書きすぎたなと反省です.4行程度の文でさらっとまとめた感じになっていたので,何を検証して,どのような結果が出たのか.またその不具合に対しどう対処をしたのかをもっと具体的に,例えばコードの解説を含んだり写真で示したりしながら,プルリクを書けたら理解しやすいプルリクになるかなと思います.
全体的としては,難易度も丁度解けるか解けないかの瀬戸際くらいで,本当に面白かったです.
 
 

懇親会

 

懇親会の食事

懇親会の食事
料理が豪華でした.寿司とかピザが出るのかなあと思ったらバイキング形式で,ラザニアやカルパッチョから見た目が可愛いスイーツまで!どの料理もすごく美味しかったです.

懇親会では,社員の方から実際に動いているサービスの運用に関するお話を聞いたり,一緒に参加した学生の方と就活のお話したりで楽しかったです.同じテーブルで話していた就活生の方達が,全員某大手企業の選考途中だったのは驚きでした.
あと,懇親会の中で聞いたお話の中でも,実際にコードにあるバグにより不正なデータが混入した時には,不正なデータに対し処理をする必要がありその後処理が大変と聞ききました.大規模なサービスを運営されているエンジニアの方たちのお話だからこそ,すごくリアルな話だなって思いながら聞いていました.ログも1日で数T溜まるとかで,想像がつかない世界でした.
 
 
 
 

まとめ

 
今回出題された問題には,実際にあったバグを元に作られた問題もあり,現実味があり,ログを元に調査するという機会はあまりなかったのでいい経験になりました.また参加したいなと思ったくらい面白かったのですが,2度は参加できないようです,残念.

ブログ始めました

はじめまして.

 

Webだったり,サーバ関係に興味があって以前から今までに身につけた知識をどこかで書き留めておきたいなあって思いがあって始めてみました!

 

簡単な自己紹介としては,

インフラ,サーバサイドのエンジニア

関西在住の大学生

です.

 

よく使用するフレームワーク,言語,ライブラリとかは,

RailsRuby),React(JavaScript),Html5CSS

使用したことある環境,ツールは

AWS,Docker,CircleCI,Capistrano,Webpack,

 

ぱっと思いつくのはここらあたり.

 

誤字脱字があった記事には指摘してもらえると嬉しいです.