Finでは、サーバーの状態だけでなく、実際の顧客の活動を使ってSLA遵守を追跡しています。
プラットフォームのコア機能を監視するために「heartbeat metrics」を使用しています。これらの指標は、顧客が製品の主要機能を利用できるかどうかを反映し、製品内の実際の成功率の指標です。
heartbeat metricが低下し、その問題が顧客のコア製品利用能力に影響を与える場合、SLAに影響があるとカウントします。
「heartbeat metric」とは何ですか？
heartbeat metricは、コア機能が動作しているかどうかを示す大量かつリアルタイムの指標です。
例は以下の通りです：
WebまたはMobile Messengerで作成されたメッセージ。
InboxでのTeammateの返信。
顧客へのFinのテキスト応答。
InboxでのTeammateのやり取り。
これらを常に監視しています。期待値を下回った場合、usersから問題の報告がなくてもすぐに調査します。
追跡しているSLA
複数のheartbeat metricsに基づいて遵守状況を判断する2つのSLAを維持しています：
Fin SLA：Finがテキスト応答を生成し、顧客に代わって返信する能力をカバーします。
Intercom SLA：チームのInboxと顧客のMessengerの使いやすさをカバーします。
これらのSLAに対して影響をカウントするのはいつですか？
特定のSLAに対して影響をカウントするのは以下の場合です：
FinまたはCore Platform製品機能の完全な停止がある場合。
Fin、Inbox、Messengerなどのコア機能の使用体験に大幅な劣化がある場合。
アーキテクチャと検出方法のため、計算されたSLA影響は、すべての顧客が同じように影響を受けなくても最悪のシナリオを反映します。
影響の検出方法
heartbeat metricsでは、二値の閾値ではなく異常検知を使用しています。これにより、完全な停止だけでなく微妙な顧客体験の劣化も捉えられ、約束の達成状況がより明確になります。
この検出の一環として、堅牢なインシデント対応プログラムを実施しています。heartbeat metricがアラートを発した場合：
インシデントが開かれ、エンジニアにページが送られます。オンコール体制は24時間365日対応可能で、完全なカバレッジを確保しています。
安定した状態に戻すために、最近のコード変更を自動的にロールバックすることがあります。
初動対応者には自動化による推奨される根本原因が提供されます。
復旧目標
RPO (Recovery Point Objective): 0 – インシデント発生時でも顧客データが失われないように十分な冗長性を持つインフラを設計しています。
RTO (Recovery Time Objective): 8時間 – 可用性に影響する大規模な停止が発生した場合、影響を受けた地域や製品で8時間以内にサービスを完全復旧することを目指します。
計画されたメンテナンス時間帯
最近のシステム再設計により、システム改善中でも顧客の継続的な運用が可能なゼロダウンタイムメンテナンスを実現しています。これが不可能な場合は、SLAに従い、最低24時間前に顧客に通知します。
システムアーキテクチャの最近の変更とその利点については、こちらのブログでご覧いただけます：Evolving Intercoms Database Infrastructure lessons and progress。