人数半減の中で総開発量UPを実現させた秘訣 by エイチームコマーステック Advent Calendar 2023

7記事目は、エイチームコマーステックフロントエンドエンジニアの大沢（@kazzzzzz）が担当します！

今回は、エラー監視に注力し運用を見直したことでさまざまな良いことがあったので、事例共有として記事にさせていただいております！エラー監視がうまく運用できていないと感じる方は特に見ていただきたいと思っております！

エラー監視に注力した理由

エラー監視に注視し始めた頃、体制変更により私たちのエンジニアチームは半分の人数となりました。人数が減った分、エラー監視に注力することで、結果的に開発に割ける工数が増えると考えたためです。

エラーが発生した場合に迅速に対応すれば傷も浅く済みますし、ビジネスへの悪影響を最小限抑えるためのセーフティーネットとして存在するだけでもエンジニアの負担を下げることもできる考えました。

Sentryとは？

以降、Sentryというツールに関する記載が多いので軽くどういうものかをご紹介しておきます。

Sentryはソフトウェアのエラー監視ツールで、発生したエラーをWebのダッシュボード一覧化したり、詳細ページでエラーメッセージ、スタックトレースなどをエラーごとに確認することができます。

他にも、個別エラーを無視設定や解決済みとすることで一覧から非表示にできたり、Slackなどのツールと連携することで新規エラーを通知させることもできます。

これまでの運用と課題

エラー管理にSentry、エラー通知にSlackを使っています。

具体的な運用としては、

毎日の朝会で担当領域（フロントエンド・バックエンド）ごとに集まり、過去1日間のエラーを確認する
気になるエラーがあれば調査
都度Slackで気になるエラー通知があれば確認

です。

上記運用をする中でエラー通知数が多かったので、すべてを見るのではなく比較的発生回数が多いエラーに絞ってみることが多かったです。

Sentryに表示されているエラーの中で問題になりそうなエラーはないか？という視点で確認しておりました。非常に多くのエラーの中から問題になりそうなものを抽出する作業となっていたため抜け漏れが発生しました。また新規のエラーが発生しても原因不明のものですと次のアクションを明確に決めることができず、放置してしまうこともよくありました。

やったこと

Sentryで一覧に表示されるエラーは常に0件にすることをエンジニアチームの目標としました。

「Sentryにエラーが表示されている状態＝システム異常」と定義づけできれば、システム異常か否かが非常にわかりやすくなります。その結果対応が必要なエラーを見逃してしまうといったような、システム異常か否かの判断ミスを防ぐことができると考えました。

この状態を目指すために下記のアクションを実施しました

毎日エラーをエンジニア全員で見る

まずは全員がエラーを認知することで、異変を見逃さずに検知できるようにしました。

それだけではなくすべてのエラーを確認することにしました。すべて見るのは大変ですが、大変だからこそ早くエラー一覧を少なくしたいという心理が働くと考えました。

放置しない運用

朝会でのエラーチェック時に、エラーの対処もしくは調査が必要な場合はその場でアサインを振り、対応不要の場合は無視設定を行うようにしました。

アサインを振ることで宙にも浮かなくなり、責任の所在が不明のエラーがなくなりました。

ぶつかった課題と解決策

上記のやったことを遂行しましたが、思うようにいかない部分が出てきました。

それらの課題と解決策を説明します。

やむを得ないエラーの取り扱い

お客さんのブラウザ拡張機能やボットなどのエラーは、通知されたところで基本的には対処のしようがありません。結局そのようなエラーが多く発生してしまい、エラーの確認作業を阻害してしまうということが起きてしまいました。

Sentryの設定にてブラウザ拡張機能や外部スクリプトのエラーを除去するような機能を有効にしたり、古すぎるブラウザは通知が来ないような設定をしました。

誤ったグルーピングがされたエラー

Sentryが意図しないエラーのグルーピングを行なってしまうことがありました。

例えば、同様のエラーにもかかわらず別々のエラーとしてグルーピングされなかったり、逆に別々のエラーなのに同様のエラーと判定されることがありました。前者のように別々のエラーとされてしまうと、一覧に表示されるエラーが必要以上に多くなってしまい確認の工数が多くかかりますし、逆に別の原因のエラーが同一エラーとグルーピングされてしまうと、リリースにより1つの原因をつぶしても解決済みにできないという課題がありました。

そこで、実装側でもエラーハンドリングの仕方を見直し、例えばGraphQLのクエリーごとにエラーがグルーピングされる様子するなどの対応をすることで、同じ原因のエラーが複数回通知されてしまうこと、違う原因のエラーが同様のグルーピングをされることを減らせました。

結果

エラー通知の信頼性が上がったことで、エラー通知に気づいてから修正が行われるまでのサイクルが早まりました。また、エンジニア全員がエラーについて把握できている状態が作れているため、例えば〇〇さんがいないからこのエラーは放置するといったこともなくなりました。

そして、想定外のことでしたが、エラー通知の確認作業に重点を置いたはずが、結果的に時間短縮になりました。
エラー通知の絶対数が徐々に減っていったため、確認すべき対象が減ったためです。

次回カレンダーは、

要件定義から設計で完全を目指さない！諦める勇気を持とう！

です！

もしご興味がありましたら次回記事もご購読いただければと思います！

よろしくお願い致します！