※この記事は、2022 Speee Advent Calendar3日目の記事です。
昨日の記事はこちら
https://tech.speee.jp/entry/infinite-environments-with-cloudfronttech.speee.jp
リフォームのマッチングプラットフォーム「ヌリカエ」の開発チームメンバーの竹井です。
今回は、ヌリカエで恒常的に発生していたが対応されずに残ってしまっていたアラートの改善に着手したお話をさせて頂ければと思います!
そもそもアラート改善の「アラート」とは?
そもそもアラート改善の「アラート」とは、エラーなどが出た際にSentryからSlackチャンネルに投稿しているものです。
ヌリカエチームではSlackにアラートチャンネルと言うものを用意しており、もしも予期せぬエラーが発生したりするとアラートチャンネルにエラー内容が投稿されるようになっています。
こんな感じです。
それぞれ様々なエラーをキャッチしては、チャンネルに自動で投稿されるようになっています。
ここに投稿されるものを「アラート」と表現しています。
アラート改善とは?
今回紹介するアラート改善についてですが、先程のキャプチャを撮影した2022年7月1日で、この日のアラートは 93件ほど発生しています 。
つまり、1日で約100件のアラートが発生しているんですね。
流石にこれら1つ1つを発生したタイミングでチェックしていると開発を進めることができなくなってしまいます。
ですので、このアラートを減らそう! と動きだしたのが「アラート改善」です。
そもそもなぜこうなった……?
なぜこうなってしまったのかは、そもそもヌリカエチームのアラートの中には以前からシカトして良いアラートと、対応しないといけないアラートの2つがありました。
例えばシカトして良いアラートというのは「バリデーションチェックに失敗した」などです。エラーメッセージを添えてユーザ側にエラー内容を返してはいますが、これもアラートとしてSlackに飛ばしていました。
これは特にエンジニアが対応せずとも良いアラートです。
他にもたまに誤操作で起きてしまうエラーや、不正なURLにアクセスされた際に出るエラーなど、ユーザ側の操作ミスによって発生していて適切にエラー内容をユーザに渡しているのであれば、特に対応せずシカトでOKなアラートと言えます。
エラーはエラーだけれど、アラートではないでしょう。みたいな。
逆に対応しないといけないアラートは、CV時にエラーが発生してしまう、などです。
つまりユーザにサービスを提供できない状態にあるものです。
こちらは意図しないバグなどがあり、本番環境でアラートが鳴ると即座に対応をしないといけないものになります。
が、入社してすぐの頃はまだこの勘どころもなく、シカトして良いアラートかどうかの指標はだいたい 過去からヌリカエに所属しているエンジニアがアラートに反応するかどうか でした。
一度「これは流石に良くない! 改善しよう!」という声が上がりアラート改善のタスクを行いました。
しかし、全てのアラートを解決することが出来ずアラート自体は少なくなりましたが、シカトして良いアラートは一部残ったままになっていました。
──割れ窓理論。
たった1枚の割れた窓ガラスをそのままにしていると、割れた窓ガラスが増えても誰も関心を持たなくなる。
そんな感じで「シカトして良いアラートはシカトで良いんやぁ〜」と思ってしまった結果、シカトしても良いアラートがジワジワと増え続け、1日100アラートが常となってしまいました。
これにメスを入れたのが、2022年版ヌリカエアラート改善。です。
改善するにあたり目標としたこと
まず、今回の改善で目指した理想状態としては「チームの皆がアラート発生したらヤバイ!と思えるようになっていて、アラートに対してその場で対応優先度を決定し、長期的にも修正を行っていける体制にする」と設定しました。
この理想状態に対する定量目標としては「1日に出るアラートを3つ以下にすること」と設定しました。
何故3つは許可しているかと言うと、改善をしている間にも新しい機能のリリースは継続的に行うため新しいアラートが発生する可能性があると考えたことと、頻度の低いアラートの場合、どうしても原因調査が困難で、再度アラートが出たときに対応をした方が改善しやすいものがあると考えたためです。
つまり、新しいアラートや頻度の低いアラートなどが発生したときに、即座に調査が行え、適宜Issueを切って優先度を付けられる状態を理想としました。
改善として行ったこと
改善として行ったこととしては、ざっくりと
- 過去一ヶ月以内に発生したアラートを一覧する
- パッと見てわかるものに関しては、シカトして良いアラートと、修正が必要になるアラートに分ける
- パッと見てわからないものに関しては調査を入れ、だいたいどの辺りのコードが問題っぽいのかを備考程度に記載しておく (まだ深い調査はしない)
- それぞれざっくりと工数感を把握する
- 優先度順に並べる
- 優先度順にガリガリ改善していく!!
これらを行いました。
過去一ヶ月以内に発生したアラートを一覧する
過去一ヶ月以内に発生したアラートの一覧は、Sentryのissue一覧をcsv形式でexportする - Qiitaを参考にさせて頂きました。
対象期間を過去一ヶ月に指定して取得。
一瞬で終わりました。
パッと見てわかるものに関しては、シカトして良いアラートと、修正が必要になるアラートに分ける
シカトして良いアラートと修正が必要だろうアラートの判別は、基本的に今までの経験を駆使して行いました。
入社してすぐの頃はまだこの勘どころもなく、シカトして良いアラートかどうかの指標はだいたい 過去からヌリカエに所属しているエンジニアがアラートに反応するかどうか でした。
とある通り、私はヌリカエの開発に入ってそろそろ3年目なのでこの
過去からヌリカエに所属しているエンジニア
になっているんです。そうなんです。私はいつも出ているアラートと、比較的珍しいアラートと、原因もわかっているアラートだけれどリソース的に修正が行えないアラートと、完全に未知のアラートがわかるんです。
ですのでシカトして良いアラートだけを一旦抜き出して、一応Sentryの詳細も確認しつつも対応が不要なものに関しては、修正を行う or Sentryのアラートをignoreする判断をパッと行いました。
パッと見てわからないものに関しては調査を入れ、だいたいどの辺りのコードが問題っぽいのかを備考程度に記載しておく (まだ深い調査はしない)
パッと見でわからないものの簡単な調査に関しては、まぁそのままですね。
1日100件近いアラートが出ていることもあり、見落としているものもあるのです。
Sentryから見えるコードの部分と、少し他のソースも見つつだいたいの修正箇所の当たりを付けます。
それぞれざっくりと工数感を把握する
だいたいの当たりがついたら、それを元にざっくりと工数感を出します。
ここでは「だいたいの当たりをつける」でOKです。
深く調査をするくらいであればもうそのまま対応しちゃった方がコンテキストスイッチも発生しなくって良いです。
むしろ期間を定めて行わず、順番に1日1件目標! みたいな形で改善する形でも良いのかなと思っています。
弊社ではそれぞれ開発を行う前に見積もりを行い「その見積もりを元に本当に今行うべきなのか」を決定しているためざっくりと見てざっくりと見積もります。
一旦ざっくりの工数感でこれの対応を行って良いか、事業の売上を上げるための開発にフォーカスすべきかの判断を行います。
優先度順に並べる
ざっくりと見積りを行えたら、後は優先度順に並べます。
自分は最初軽いタスクから始めて、サクサク順調!調子に乗ってきたぜ〜!ってなってきたところで重いタスクも勢いで片付けるようなことをよくやるのですが、今回は「軽いタスク」よりも「発生件数」順に倒すプランにしました。
発生件数が多いものがなくなる = アラートチャンネルの数が目に見えて減る → 「気持ち良い〜! 改善できてる〜!」みたいな感じで良い意味で調子に乗れたら良いな。という戦法です。我ながら単純スね。
優先度順にガリガリ改善していく!!
あとはやるだけ!!
ということで、それぞれ順番に片付けていって……。
結果
結果、2022年7月22日に始めたプロジェクトでしたが、2022年8月20日に完了しました!!
その後、発生頻度の低いアラートや、新しいアラートなどにも対応をし続け……。
9月末くらいになると、アラートがだいたい1件とかになっています。
素晴しい……。
ちゃんと改善目標を達成でき、現在ではアラートが発生すると (ほぼ) 即座に対応することができています!
まだ全てのアラートに対して即対応!!とまではなっていなくって、特に開発に集中していたりMTGしていると見逃してしまうこともあるのですが……。
元々行おうと思っていた「チームの皆がアラート発生したらヤバイ!と思えるようになっていて、アラートに対してその場で対応優先度を決定し、長期的にも修正を行っていける体制にする」に近付けることはできました!
まだ足りていない箇所についても、まずは自分から動きアクションを起こしていくことで、皆のアラートチャンネルへの関心を上げていければなと思っています。
まとめ
アラート改善、行って良かったです。
やっぱりアラートが発生していない状態は気持ちが良いですし、新しいメンバーが入ってきてもアラート = ヤバイヤツという認識でOKになるためアラートによる空気読みも必要なくなります。
また、途中で出した割れ窓理論じゃないですが、やっぱり見て見ぬ振りされている箇所があるプロダクトはドンドン改善アクションへの関心が薄れていってしまうのかなと思います。
今回はアラート問題への対応でしたが、歴史あるコードになると他にも様々な負債が貯まっていたりします。
これらに対抗していく気持ちを忘れないようにしていきたいですね。
最後に
Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！
こちらのFormよりカジュアル面談も気軽にお申し込みいただけます！
Speeeでは様々なポジションで募集中なので「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！
