トラブルシューティングの準備
こんにちは、シニアソフトウェアエンジニアのリドルです。
こんにちは、ミドルソフトウェアエンジニアのひびのです。
このポッドキャストは、2人でIT業界の様々な話やキャリア、困ったことについて話して、IT業界のリアルを届けようという趣旨の番組になっております。
今回のテーマが、メガベンチャーの職場の雰囲気を実際にやってみよう。
イエーイ。実際にやってみましょう。
はい。普段の感じでね、喋ればいいですよね。
はい。メガベンチャー、僕らはそうですよね。株式会社ミクシンに所属していて、おそらく多くの場面でメガベンチャーのくくりで語られることが多いであろう会社ですよね。
そうですね。その認識でおります。
どういうシチュエーションからやりますか?
まずはあれじゃないですか、トラブルシューティング。
いきなり一番エンジニアが燃えるやつやってきましたね。
はい。
じゃあ、僕が対応するエンジニア。
私はとりあえず、たぶんメンバーをやるんで。
はい。じゃあ、てことは僕がですね、インシデントコマンダーやります。
はい。じゃあ、僕が生涯見つけますね。
PagerDuty鳴らしてもいいですよ。
PagerDuty鳴らします。そしてPagerDutyの内容としては、どうしようかな。
ウェブサイトのトップページが落ちてます。白い画面でエンジンXの500って返ってきます。
やばいじゃん。
やばい。やばいですよ。じゃあ、僕がまず最初にPagerDutyの、たぶんBotがスラックに何か投稿してくれるのかな。
はい。
目をつけます。スラック上で。アイズ。
とりあえず…
うわ。スマホに来たわ、通知が。PagerDutyアラート、PagerDutyアラート。来ましたね。
なんだなんだ。
アメリカの番号からやってくるやつ。
とりあえずウェブフロントが落ちてますかね。500。
ウェブフロントが500番エラー。そして、じゃあ、インシデントコマンダーとしてスラックを開いていたということで僕が気づきます。
じゃあ、どうしようかな。
とりあえずGoogleMeets開きますか。で、Meetsに集まりますか。
はい。じゃあGoogleMeets開きましょう。GoogleMeetsのURLをスラックに投稿。
はい。じゃあちょっとPDMに連絡しておきます。
はい。ありがとうございます。
で、裏でPDMにすいません。サイトが今こういう状態で、ユーザー影響がこんな感じで、サービスにみんなアクセスできません。ウェブの人は。
うんうん。
至急調査してます。
はい。ありがとうございます。
よろしくお願いします。
ありがとうございます。
障害の解析と対応
今Meetsで話してます。
あとここであれですね。部署によってはSNSでお知らせを出すとか、
あとはアプリ内のお知らせ通知を出すかみたいな判断もPDMに投げておくとスムーズかもしれないですね。
そうですね。
うんうん。じゃあ、はい。エンジニア2人集まりました。ここで何をするかっていうと、まずどういう事象が実際に起こってるかウェブサイト開きますか。
そうですね。
うん。確かにブラウザで真っ白な画面になってNGX500が出てる。これはやばいですね。
ちょっとNGXのログ見ますか。
はい。
ログ見たら、確かに500って返されますね。
うんうんうん。
裏側のアプリケーションサーバー500返してるっぽいんで、アプリのログを見ましょうか。
はい。お願いします。
まあ、なんかユーザーのAPIでゲット券やらせて500返してますね。
それはまずい。500を返してる、今見ていただいてるログはいわゆるあれかな。フロントエンド、ウェブフロントエンドをホスティングしてるサーバーかな。
いや、バックエンドの方のAPIでゲットをV1のユーザーのAPIを選ぶ感じですね。
はい、なるほど。じゃあそれがウェブフロントエンドから呼ばれてが、APIが500を返してるからそのままウェブサイトを表示できなくなっているという事象ですね。
だからフロント的にそれでいいのか。
フロント的にはまずい。それは…いや、ちょっと待って。
たぶんその場合エンジンXは500を返さなそうではあるが、一旦その手で進めましょう。
待って、このエンジンXはどこにいる設定なんだっけ。ウェブフロントの手前にいるエンジンXか。
はい、僕はその認識でした。
OKです。分かりました。じゃあ、500返さない。
はいはい。リドルさん、ゲット券APIの修正をお願いします。
ちょっと待って、まず事象が分からないのでちょっと待つかね。
はいはい。
これはだからログインしているユーザーの時に起こるかな。実はログインしていないユーザーは問題ないんじゃないか。
なるほど、いいところに気づきましたね。そうですね。さっきユーザー系のゲットAPIとおっしゃいました。
ちょっとログアウトしたユーザーで試してみてもらえますか。
はい。たぶんここで僕がサクッと見られるなら僕がやるか、あるいはちょっとログアウトしているユーザーの用意が時間がかかるとかだったらQAさんにお願いするかみたいな選択肢が発生しますよね。
そうですね。コマーターなんで本当は手を起こさない方がいいんですけど。
はい。じゃあサクッと見られそうなんで僕見ます。確かにログアウトしている状態だとエラーは返ってきません。
OKです。じゃあ一応PDMに一歩入れとくか。テコテコテコテコ。
そうですね。PDMが各スペースホルダーとやり取りしたり、あとはお知らせの内容を作ってくれているかもしれないので、より詳細な情報を伝えることは大切ですね。
そうですね。じゃあ引き続きユーザーのやつ見ますけど、これなんか全員で起こっているのかな。
特にロケーションとかユーザーの種類とか関係なく、なんか一律ユーザー系のGET系のAPIがもう500に変わっちゃってるな。
おーなるほど。それはUSB自体ですね。
これなんかいつからなんだろうな。障害発生時刻はなんか13時からエラーレートが爆伸びしてますね。
やりましたっけ13時。
13時。あ、もしかしたらエンジニアの誰々さんがデプロイしたタイミングと重なるかもしれないですね。
じゃあそれだ。サブウンを見に行こう。
そうですね。リリースプルリクのサブウンを見る。
だいたいこういう時はログにコミットログついてるから、コミットIDついてるから、コミットID見て、じゃあこのコミットIDをGitHubで検索しますか。
あ、このプルリクかな。いくぞー。このプルリクは内容的にはなんかリファクタリングなのかな。
はいはいはい。
だからリバートしても問題ないさそうだから、一回リバートしますか。影響。
はい。よろしくお願いします。
いいですか。確認します?PDMとかに。大丈夫ですか。
いや大丈夫でしょう。ここはインシデントコマンダーとして解決できそうということなので、修正お願いします。自分からPDMに再度伝えておきます。
はい。じゃあリバートします。
はい。よろしくお願いします。
はい。デプロイ終わりました。
ありがとうございます。じゃあ動作確認します。
お、ユーザーログインした状態でも問題なくトップページを開ける。よし解決しました。
じゃあさっき障害報告があったチャンネルに収束宣言をします。宣言しました。
じゃあ一旦ここは解散とします。
そして明日のこの時間に今回の対応に関わった人はポストモーテムのミーティングを入れておきます。
障害対応の重要性
それまでに障害対応の記録のドキュメントを共有するので皆さん記載お願いします。以上。
はい。ありがとうございます。
ありがとうございます。
いやーこんなに綺麗に解決したら素晴らしいですね。
いやこんなに綺麗に解決することなかなかないですよね。
そうですね。そんなね、まあすぐに見つからないですよね。
うーん。いやリバートするだけで治るなら一番いい。
まあ細かくねリリースしててプルリクマージ単位でデプロイしてるんだったらまあなんか全然あるかなと思いますけど。
うーん。
まあでも場合によってはデータベースが変な感じになってしまって戻さないといけないとか。
ありますね。
いろいろあったりするんでCS対応とか。
まあでもこれなんか別にメガベンチャー関係なく普通の自社開発企業でトラブル起こったらまあまあこんな感じなのかなっていうイメージですかね。
ありますね。Cって言うならあれですよね。
これまでえっとそれこそスタートアップとかそういう開発の現場にも関わってきたんですけど、まずPagerDutyがしっかり用意されてて、
あのーなんかインシデントに誰かしら気づく仕組みがあるっていうのはだいぶメガベンチャーっぽいですね。
あーまあまあでもある程度の規模の差別だとあることが前提になってると思いますけどね、さすがに。
うーん、まあそうですね。今2025年だし、あのーそうだと思いたいですね。
うーん。
そうだな、まあそれで言うと意外となんかQAさんがしっかりいるっていう環境も、あのーなんというか実はあんまりないんじゃないかなと思ってて。
特にメガベンチャーそれこそ今の会社に入ってQAさんがしっかり見てくれてるってだいぶ安心して開発ができるなっていうのは驚いた記憶がありますね。
うん、まあまあ確かにそれはそうですね。
うーん。
あんまりいないとこも多いでしょうし。
前職のSIRと比べるとこう障害発生の時って絶対その相手先の企業への連絡が必要なんですよね。
おーそうなんですね。
相手先、あーそれはあのいわゆるそのシステムを使ってる顧客っていうことですかね。
うーん。
そうそうそう。
確かに。
何だったらなんか問題が起きた時ってまず判断を仰がないといけない可能性もあるって結構そこで時間かかったりするんですよ。
うんうんうん。
規模がでかいサービスであるほど実際に作業している現場の人が直接お客さんと話すことはなくて、一回課長を経由して課長からお客さんに話してみたいな感じで伝言ゲームになるんですよね。
そうなるとだいぶ時間かかりそうですね。リバートすれば治る問題だったとしても。
そうそうそう。
そういう意味では本当になんか現場の判断でその一旦こういう対応をしておこうは全然メガベンチャーではよくある障害対応ですもんね。
そうですね。この辺のスピード感の違いみたいなものを何かね感じていただけるといいんじゃないかなとは思います。
開発現場の経験
確かに。なんか個人的になんですけど、サーバーエンジニアが一人前になる過程で自分で起こしてしまった障害を自分で治すっていうイベントあるのかなと思ってて。
なんか今の話聞いてたらもしかしたらSIRだとそういう経験ってあんまり実はしにくい?
あーそうですね。特にアプリケーション開発になると自分で作ってないこともありますし。
なのに障害は自分のところに回ってくるというか。対応に追われるのは自分だったりとか。
あとそんなにすぐに治せないですよね。例えば外注してたりとかする場合って、作って1年後にそのバグ見つかった場合とかって、もうまた新しく契約結ばないとそもそも治せないとか。
うーん、怖いなー。かつ1年前に作ったシステムって書いた本人も絶対もう覚えてないですもんね。
そうそうそう。なのでバグの特定だけ有識者で先にやっちゃって、で治すのは別の対応とか。急ぎだったら早くやるかもしれないですけど。
まあなんかいろいろあるからもうちょっと大変ですね。
なるほどなー。
なんかその問題に対して、なんというかもちろんインシデントが起こしてしまいました。その問題に対して一定数の人数で取り掛かれるっていう安心感はありそうだと思いつつも、
自分のケツを自分で拭くという経験はもしかしたらメガベンチャー、ITベンチャーならではと。
そうですね。なんかすぐ人にね簡単に迷惑かけられるっていうね。
あまり良くないですね。そういう問題が仮に起こったとしたらその後のポストモーテムでしっかり振り返られて再発防止策が講じられるものだと。一般的にはそういうものですもんね。
そうですね。こんな感じでですね、今ちょっとだいぶ即興でやったんですけど、割と雰囲気としてはなってるかなと思うので、皆さん他にもですね、このシーン見たいんだけどというものがあれば是非コメントとかで教えてください。考えます。
そうですね。これいろんなシチュエーションで展開できる話ですね。
そうそう。我々どういう視点でお見せすれば皆さん喜んでもらえるのかちょっと分からなくなっちゃうんで、是非教えてください。
教えていただきたい。
はい。ということで、このポッドキャストはハッシュタグUITで皆様からのコメントや感想を募集しております。またGoogleフォームのリンクからでもですね、募集しておりますのでよろしくお願いします。ありがとうございました。
ありがとうございました。
