機能リリース後のカオス！荒れたSentryのアラート通知をどう立て直したか

はじめに

こんにちは、業務委託でサーバーサイドエンジニアとしてスマートバンクにジョインしているakshimoといいます！

ソフトウェア開発は「作って終わり」という訳にはいかず、その後の運用も重要かと思います。その中でもエラーの監視とその通知システムは不可欠です。この記事では、私たちのチームのエラー監視にて起こった問題とその対策、そして普段行っている運用業務の流れについて書きたいと思います！

前提・課題

リリースに伴いエラーが多発

私たちのチームでは、機能改善の一環としてある外部サービスを新しいものに移行するプロジェクトを進めていました。しかし、移行後に予期しない問題が多数発生してしまいました…

具体的には以下のような問題が発生していました。

1. 外部サービスの各エンドポイントでのタイムアウト
2. サプライズ的な想定外の仕様
3. 実装の不備によるバグ

これらのエラーには放置するとユーザー体験を大きく損なうものもありました。また、検知や対応は開発者に大きな負担となってしまいました…

Slackのエラー通知が荒れてしまう

エラーの検出と通知にはSentryを使用し、Slackチャンネルに通知するよう設定していました。しかし、エラーの増加に伴い、Slackチャンネルは次のような問題に直面していました。

1. 通知の氾濫：1日に多くのエラー通知が流れ、重要な情報を見逃す危険性が高まっていた
2. 通知の分散：Sentry通知以外にも、バッチ処理からのアラートなどがあり対応すべき通知が分散していた
3. 他チームへの影響：関係のないチームにまで通知が届き、迷惑をかけていた

この状況は、チームのモチベーションを低下させ、エラー対応の効率を下げていました。

Sentryの設定

問題の解決のため、まずはSentryの設定を見直し、以下の改善を行いました。

通知先変更

まず、Slackに自分たち専用のOpsチャンネルを作成し、自分たちが対応すべきSentryのエラーはそのチャンネルに通知先を変更するようにしました。

Sentryでは、このように通知ルールの設定をすることができます。これにより、「特定の条件を満たす場合に指定のSlackチャンネルに通知」といった設定が可能になります。

私たちの場合、Sentryのtransactionという項目にエラーが発生したControllerのアクションの名前が設定されており、その名前空間に特定の文字列を含む場合に、専用のチャンネルに通知するように設定しました。

リアク字チャンネラー

上記により、Sentryの通知は自分たちのOpsチャネルに通知することができました！ しかし、まだ以下のような通知が各チャネルに散らばってしまっていました。

• バッチ処理のアラート
• Slack上での各種依頼事項
• Sentryの通知設定で取りこぼしたもの

これらは、Slackのリアク字チャンネラーアプリを使って拾うようにしています！

専用の絵文字を登録しておいて、チームで対応すべき運用課題があったら、そのメッセージに登録した絵文字でリアクションをします。

そうすると、自動でOpsチャネルにメッセージを転送してくれます。

• 対応すべき運用課題が一つのチャネルに集約される
• リアクションをつけているので、他チームの人が「このチームが対応してくれるんだな」というのがわかる
• 転送されたメッセージのスレッドに作業内容などを書き込むことで、誰がどんな対応をしているのか状況がわかる

といったメリットがあり、Opsチャンネルを見れば「対応必要なものがあるか？」「誰がどのように対応中か？」がすぐにわかるようになりました！

朝会の流れ

通知を整理し運用課題をチームにアサインしても、実際に対応しなければ意味がありません！ 私たちのチームでは毎日朝会を実施しており、その中で起きたエラーについても話し合う場を設けています。

朝会の流れ

朝会は以下のような流れで進めています。

1. 各自やったことと今日やることの共有
2. 共有・相談・報告など
3. 〜ここまではエンジニア以外も一緒にやる〜
4. Sentryにて誰にもアサインされていないエラー一覧を確認し必要なものはチームにアサイン
5. チームにアサイン済みのエラーの対応

エラー対応

エラー対応は主に以下のように行っています

1. 不要なエラー通知の調整
   　・重要度の低いエラーはwarningレベルに変更
   　・不要な通知の削除
2. Sentryでのエラーイベント管理
   　・解決したエラーをResolve
   　・対応不要なエラーをArchive
3. チーム内での対応
   　・対応が必要なエラーをバックログアイテム化
   　・チームメンバーへのアサイン

特に移行直後は不要なエラー通知も多く発生していたため、それらは大体1日以内にwarningレベルに変更したり、通知自体を削除したりしました。また、朝会内で必ず解決済みのエラーをResolveし、対応不要なものをArchiveするようにしています。

このようにすぐに対応することにより、チームにアサインされたままの未対応エラーをなくし、結果的にチームの負担を軽減しています。

さらに、Sentryにはエラーイベントに対しコメントを残す機能があるため、対応内容は必ずそこに記録するようにしています！同じエラーが発生した場合でもスムーズに対応できるようにしています。

最後に

以上、私たちのチームで取り組んでいるエラー対応についての紹介でした！ 正直、こういったエラー対応や運用保守的な業務はあまり好きではない人も多いと思います。でも、このように試行錯誤しながらトライして改善を続けていけば、良い循環で回っていくと思います。

この記事が皆さんの開発の一助になれば幸いです！

スマートバンクでは、サーバーサイドエンジニアを募集しています！

smartbank.co.jp

また、開発について話を聞いてみたい方はぜひカジュアル面談もお待ちしています！

smartbank.co.jp