Finでは、サーバーの状態だけでなく、実際の顧客の活動を使ってSLA遵守を追跡しています。
プラットフォームのコア機能を監視するために「heartbeat metrics」を使用しています。これらの指標は、顧客が製品の主要機能を利用できるかどうかを反映し、製品内での実際の成功率の指標です。
heartbeat metricが低下し、その問題が顧客のコア製品利用能力に影響を与える場合、SLAに影響があるとカウントします。
「heartbeat metric」とは何ですか？
heartbeat metricは、コア機能が動作しているかどうかを示す大量かつリアルタイムの指標です。
例は以下の通りです：
WebまたはMobile Messengerで作成されたメッセージ。
InboxでのTeammateの返信。
顧客へのFinのテキスト応答。
InboxでのTeammateのやり取り。
これらを常に監視しています。1つが期待値を下回った場合、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。