はじめに

こちらはバイセルテクノロジーズ Advent Calendar 2024の 2日目の記事です。前日の記事は早瀬さんの「3年間に及ぶ新規プロダクト開発の技術選定の振り返り」でした。

こんにちは！株式会社BuySell Technologiesのテクノロジー戦略本部開発2部で、バックエンド領域でテックリードをしている藤澤です。前日の記事でも紹介されましたが、この度3年の開発期間を経てEXSというEC出品管理システムがリリースを迎えました。プロジェクトの立ち上げから携わらせて頂いたシステムがなんとかリリースを迎えることができ、チーム一同感無量でした。

既存のシステムからの切り替えということもあり、必須要件が多く開発ボリュームが大きいシステムであるため、リリース直後はユーザーから多くの問い合わせや、システムアラートが発生することが予想されました。また、リリース時の開発チーム全体の人数は12名いましたが、権限の問題もあり機動的に対応できるのは正社員の5名だけでした。チームではそれらを考慮した仕組みや体制を整えた上で、リリース後の監視対応に取り組みました。

結果として、問い合わせやアラート件数は徐々に落ち着き、チームは次のアップデートのためのエンハンス開発に着手できるようになりました。また、ユーザーから問い合わせ対応のスピード感やホスピタリティについて良い評価を得ることができました。

今回は、私たちがリリースに向けて「システム監視」と「ユーザーサポート」をどのように準備し乗り越えたかを紹介します。

はじめに
システム監視概要
ユーザーサポート概要
- 問い合わせワークフロー
- 問い合わせ対応フロー
チームとしての監視体制
チームで大事にしていた心構え
- 事業を止めないこと
- ユーザーからの信頼を得ること
成果について
まとめ

システム監視概要

EXSでの全体的なシステム監視は、下図のような構成となっています。各種監視対象から異常が検知された場合、Slackチャンネルに通知され、Opsgenieを通じて開発メンバーに連絡されます。

アプリケーションエラー監視
- ランタイムエラーやデータ不整合などによるアプリケーションのエラーと、外部連携先のエラーレスポンス
インフラ監視
- リソースの使用率や特定のレスポンスコードの発生頻度など

アプリケーションエラー監視

sentry-goやsentry/nextjsを利用し、BE/FEともにアプリケーションが正常に動作していないことを検知して、Sentryに通知できるようにしています。また、Sentryから各種インテグレーションを通じて、SlackとOpsgenieに通知が連携されるようアラートルールを組んでいます。

Slackに通知されたアラートは下記のように通知され、その通知のスレッド内で開発メンバーは異常の確認と対応を進めることになります。

インフラ監視

インフラはGoogle Cloudを利用しており、Google Cloud Monitoringで各種リソースの逼迫状況を監視しており、メトリクスが設定したボーダーを超えたら検知できるように、アラートポリシーを設定しています。

通知チャネルとして、SlackとWebhook(Opsgenie)を設定することで、アプリケーションエラーと同じく通知を連携しています。

例として、以下のようなアラートポリシーを設定しています。

コンテナのメモリ使用率が○%を超えたら通知
1分間に500となったリクエストの数が○回以上発生したら通知

システム監視の対応フロー

システム監視は下図のような対応フローをとっています。 Opsgenieでアラートに迅速に気付き、通知の投稿のスレッド内で、影響調査や対応方針検討まで完了させています。「何が起きているのか」をなるべく早く特定した上で、事業影響があるかどうかを判断しユーザーとの連携を密にとって対応方針を決めます。また、事業影響がある場合は、その他の作業を止めて修正を実施することとしています。

ユーザーサポート概要

現在EXSの主なユーザーは社内の事業部にいます。既存のシステムからの切り替えということもあり、システムの利用方法や、不具合などについて多くの問い合わせがあることが予測されました。ユーザーと密にコミュニーションをとりながら迅速に問い合わせ対応を実施するために、「問い合わせチャンネル」と「問い合わせ調査チャンネル」をSlackに作成し、Slackのワークフローを利用してユーザーサポートを行うことにしました。

問い合わせワークフロー

下図のように「問い合わせチャンネル」にワークフローボタンを設定しています。

ワークフローを起動すると、下図のような入力欄が表示され、そこにユーザーは問い合わせ内容の詳細情報を入力することができます。

入力後内容を送信すると、「問い合わせチャンネル」投稿が作成され開発メンバーに即時に通知されます。

開発メンバーは、問い合わせ内容の情報に加えて、投稿のスレッド内でユーザーとやり取りしながら問い合わせの解決を目指します。

また、開発チーム内でより詳細な調査と検討が必要な内容が発生した場合は、「 [Tech専用] 調査チャンネルにスレッドを立てる」のボタンから「問い合わせ調査チャンネル」にスレッドを作成し、その中で専門的な内容での調査検討ログを残すこともできます。

問い合わせ対応フロー

問い合わせ発生からの対応は下図のようなフローをとっていました。

ユーザーとのやり取りは「問い合わせチャンネル」、開発チーム内での調査などは「問い合わせ調査チャンネル」を利用します。開発メンバーはユーザーからのヒアリングや優先度判定、修正対応までをそれぞれのチャネルで対応し、最終報告をして問い合わせ完了させます。 Slackという普段のコミュニケーションツールで問い合わせ対応をしたことで、リリース直後の大量の問い合わせを少人数で機動的かつ迅速に対応していくことができました。

チームとしての監視体制

リリース直後は以下のような監視体制を敷いていました。 Opsgenieのオンコール担当者も含めて、アラート通知や問い合わせが発生したらとにかく早い者勝ちで対応開始します。ほぼチーム内全員で状況を確認までを実施し、対応者を決めたらその後は対応者に任せます。対応者以外は、タスクを進めつつ次のアラート通知や問い合わせに備えます。

この体制は、リソース効率的には無駄がある体制ではありましたが、１つ１つを確実に対応完了させていくことができました。また、リリース後一定期間を経過して、アラートも問い合わせも発生頻度が落ち着いてきたことを受け、現在は以下のような監視体制に移行しています。

日替わりで担当者を配置して、担当者が全てのアラート通知や問い合わせを対応しています。それ以外のメンバーはエンハンス開発を進めることができており、チームが開発生産性を取り戻すことができています。

チームで大事にしていた心構え

事業を止めないこと

私たちが開発したシステムは事業部が利用する基幹システムであるということを念頭に、チームとして事業影響を最小限にする監視体制を敷くということを強く意識していました。不具合が発生した場合は、全てにおいて最優先に対応し、その対応もまずは状況把握からの事業影響判定を迅速に行うことをルールとしています。例えば、アプリケーションエラーが発生した場合は、以下のような観点で影響度合いを洗い出しています。

重要なデータの不整合がないか
機能が正常に動いているか

EXSはEC出品管理システムなので、商品の在庫数が最も重要なデータとして位置付けています。何か起きたらまずは在庫数に不整合が起きる可能性があるかどうかを最優先に確認しています。

また、EXSでは毎日非常に多くの商品を出品 ~ 受注する業務を担っています。2についてはエラーによって、「業務フローのなかで、できなくなってしまったことはないか」「回避方法はあるか」の観点で影響度を判断しています。

ユーザーからの信頼を得ること

事業を支えるシステムの開発チームとして、ユーザーからの信頼を得ることも非常に大事にしています。その上で、対応時はエラーや問い合わせに対する「最初のリアクション」をできる限り速くすることを心がけています。

具体的には、問い合わせワークフローが立った時には、その投稿に対して何らかの返答を素早く返すといった心構えを全員が持つようにしています。別の最優先事項の対応をしている場合でも、チーム歴が浅く対応できるか不安なメンバーであっても、「確認します」と即座にいうことで、まずは問い合わせに対して「見ている」安心感をもってもらうという狙いもあります。（もちろん状況によって他のメンバーがヘルプにすぐに入るので実際の対応も即時で進めます）

成果について

これまで説明した方針によって、私たちは無事リリースを乗り切ることができました。ここでは、具体的な成果について紹介したいと思います。

アラート

以下はリリース後からこれまでの、アラート発生件数の週次の推移です。リリース直後は多くのアラートが発生しましたが、2週間ほど集中して対応をした結果数が減少し落ち着きを取り戻しました。また、チームの地道な努力の結果、その後のアラート数の推移も減少トレンドを続けています。

問い合わせ

以下はリリース後からこれまでの、問い合わせ件数と、1次対応までの反応時間を週次での平均で推移を示しています。問い合わせ件数はアラートと同じく減少トレンドを続けています。また、反応時間については概ね30分以内、早い場合は5分以内での平均となっており、これまでの全期間の平均としては、17分14秒でした。諸々の対応が差し迫っていた場合など、Slackのリアクションで反応を代替することもあり、今回はそれらを集計に反映できませんでしたので体感としてはもっと短時間に反応ができていたと思います。