こちらの記事は、「Luup Developers Advent Calendar 2024」の13日目の記事です。
こんにちは。Luup Serverチームの原です。
LUUPでは、土日祝日にユーザー体験を損なわせないことを目的として、バックエンドのシステムで発生したインシデントを迅速に復旧する取り組みを行っております（以降はオンコールと呼びます）。
この記事では、実際のオンコール対応の進め方について、Waroomを中心としたアーキテクチャに触れながら紹介していきます。
オンコール対応のためのシステムアーキテクチャ
オンコール概要図
オンコール観点でのLUUPのバックエンドのシステム概要は上図の通りになります。
オンコール対応時の社内コミュニケーションツールはSlackに完結しており、Slackを中心にオンコールのシステムを構築しています。弊社では、バックエンドで発生したインシデントをWaroomで管理しており、インシデントページの作成や、Slackと連動してポストモーテムを半自動的に作成・記録しています。
Waroomのインシデントページ
バックエンドの各サーバーのメトリクス監視は画像中央部のDatadogとGoogle Cloudで行っており、異常値を観測するとSlackとWaroomに通知が飛ぶようにしています。
画像左部はLUUPの車両とユーザーアプリとバックエンドの接続を簡易的に示しており、車両とサーバーの間にはSORACOM Beamを挟んで施錠と解錠のメッセージを仲介させています。
オンコール対応の流れ
不具合の検知
Google CloudやDatadogのアラート発火によりSlackの専用チャンネルにメッセージが投稿されるので、オンコール対応者はその通知を受けて調査と復旧対応を始めます。また、社内のメンバーやカスタマーサポートチームから、Slackの不具合報告の専用チャンネル上で連絡を受けることもあり、こちらも同様に調査対応を行います。
不具合対応の起票
一部のGoogle Cloud、DatadogのアラートはWaroomが自動的に起票できるようにしてます。それ以外のアラートや、カスタマーサポートチームからの報告は自動で起票ができないのでWaroomから手動起票します。
また、Waroomでインシデントを起票すると、Waroomのインシデントページと連動したSlackのチャンネルが作成され、チャンネル内でのコミュニケーション内容をAIがサマライズしてくれます(便利！)。そのため、担当者は原因調査と復旧作業に集中できます。
暫定対応
不具合内容を基に、DatadogのメトリクスやGoogle CloudのCloud Loggingを確認して原因を特定していきます。影響範囲が施錠などの車両との通信に及ぶ場合は、SORACOM Beamのステータスまでチェックすることになります。
原因が判明したら、暫定対応を優先して進めていきますが、プロダクトの運用に大きく関わりそうな場合はPdMを交えて判断することになります。
根本的な原因への即時対応が難しい場合もあり、その時はhotfixを適用し、翌営業日に恒久対応を進めます。
ポストモーテムの作成
不具合を暫定的に解消できた段階で、Waroomのポストモーテムにこれまでの経緯を含めた不具合の詳細を纏めていきます。ただ、これまでのやり取りはWaroomに自動的にサマライズされているので、作業負担はそこまで大きくないです。
Waroomに記録されたポストモーテムは、後の類似した不具合対応や運用改善のナレッジとして活用されます。
最後に
バックエンドのオンコール対応について紹介しました。Slackのチャンネルにアラートや不具合報告の通知を集約しており、対応者はその通知を受けとって対応を始めることができるようになりました。また、Waroomを取り入れることで、インシデントに伴うポストモーテムの作成を半自動化できるようになりました。
オンコール体制の参考になりましたら幸いです。
Discussion