Bei Fin verfolgen wir die SLA-Einhaltung anhand realer Kundenaktivitäten – nicht nur anhand der Servergesundheit.
Wir verwenden „Heartbeat-Metriken“, um die Kernfunktionalität unserer Plattform zu überwachen. Diese Metriken zeigen, ob Kunden wichtige Funktionen unserer Produkte nutzen können – sie messen die Erfolgsraten in der Praxis innerhalb unseres Produkts.
Fällt eine Heartbeat-Metrik ab und beeinträchtigt das Problem die Fähigkeit der Kunden, unser Kernprodukt zu nutzen, werten wir dies als Einfluss auf unsere SLAs.
Was ist eine „Heartbeat-Metrik“?
Eine Heartbeat-Metrik ist ein Echtzeit-Indikator mit hohem Volumen, der anzeigt, ob eine Kernfunktion funktioniert.
Beispiele sind:
Nachrichten, die im Web- oder Mobile Messenger erstellt wurden.
Teammate-Antworten im Inbox.
Fin Textantworten an Kunden.
Teammate-Interaktionen mit dem Inbox.
Wir überwachen diese ständig. Wenn eine unter die erwarteten Werte fällt, untersuchen wir sofort – auch wenn users noch kein Problem gemeldet haben.
SLAs, die wir verfolgen
Wir pflegen zwei SLAs, deren Einhaltung durch unsere verschiedenen Heartbeat-Metriken informiert wird:
Fin SLA: Deckt Fins Fähigkeit ab, Textantworten zu generieren und im Namen der Kunden zu antworten,
Intercom SLA: Deckt die Nutzbarkeit des Inbox für Ihr Team und des Messenger für Ihre Kunden ab.
Wann werten wir Auswirkungen auf diese SLAs?
Wir werten Auswirkungen auf unsere spezifischen SLAs aus, wenn:
Es einen vollständigen Ausfall der Fin- oder Core Platform-Produktfunktionen gibt.
Es eine erhebliche Verschlechterung der Nutzungserfahrung unserer Kernfunktionen wie Fin, Inbox und Messenger gibt.
Aufgrund unserer Architektur und Erkennungsmethoden spiegelt unsere berechnete SLA-Auswirkung immer das Worst-Case-Szenario wider, auch wenn nicht alle Kunden gleichermaßen von einem Problem betroffen sind.
Für vollständige Bedingungen zu unseren SLAs verweisen wir auf unsere vollständigen Nutzungsbedingungen.
Wie wir Auswirkungen erkennen
Mit unseren Heartbeat-Metriken verwenden wir Anomalieerkennung, keine binären Schwellenwerte. So können wir subtile Verschlechterungen der Kundenerfahrung erfassen, nicht nur vollständige Ausfälle, was unser Verständnis darüber, ob wir unsere Verpflichtungen Ihnen gegenüber erfüllen, klarer macht.
Als Teil dieser Erkennung haben wir ein robustes Incident-Response-Programm. Wenn eine Heartbeat-Metrik einen Alarm auslöst:
Ein Vorfall wird eröffnet und Ingenieure werden benachrichtigt. Unser Bereitschaftsdienst ist rund um die Uhr verfügbar, um volle Abdeckung zu gewährleisten.
Wir können automatisch kürzliche Codeänderungen zurückrollen, um einen stabilen Zustand wiederherzustellen.
Ersthelfern werden über Automatisierung vorgeschlagene Ursachen bereitgestellt.
Wiederherstellungsziele
RPO (Recovery Point Objective): 0 – Unsere Infrastruktur ist mit ausreichender Redundanz ausgelegt, um sicherzustellen, dass keine Kundendaten verloren gehen, selbst wenn Vorfälle auftreten.
RTO (Recovery Time Objective): 8 Stunden – Im Falle eines größeren Ausfalls, der die Verfügbarkeit beeinträchtigt, streben wir an, den Service in den betroffenen Regionen oder Produkten innerhalb von 8 Stunden vollständig wiederherzustellen.
Geplante Wartungsfenster
Unsere kürzliche Systemarchitektur ermöglicht wartungsfreie Zeitfenster, sodass Kundenbetrieb auch während Systemverbesserungen kontinuierlich möglich ist. Wenn dies nicht möglich ist, benachrichtigen wir Kunden mindestens 24 Stunden vor jeder Wartung gemäß unseren SLAs.
Sie können mehr über die jüngsten Änderungen an unserer Systemarchitektur und deren Vorteile in unserem Blog hier lesen: Evolving Intercoms Database Infrastructure lessons and progress.