Chez Fin, nous suivons le respect des SLA en utilisant l'activité réelle des clients - pas seulement la santé des serveurs.
Nous utilisons des « métriques de heartbeat » pour surveiller la fonctionnalité principale de notre plateforme. Ces métriques reflètent si les clients peuvent utiliser les fonctionnalités clés de nos produits - elles mesurent les taux de réussite réels dans notre produit.
Si une métrique de heartbeat chute, et que le problème affecte la capacité des clients à utiliser notre produit principal, nous le comptons comme impactant nos SLA.
Qu'est-ce qu'une « métrique de heartbeat » ?
Une métrique de heartbeat est un indicateur en temps réel à fort volume indiquant si une fonctionnalité principale fonctionne.
Exemples incluent :
Messages créés dans Web ou Mobile Messenger.
Réponses des coéquipiers dans l'Inbox.
Réponses textuelles Fin aux clients.
Interactions des coéquipiers avec l'Inbox.
Nous surveillons ces indicateurs en permanence. Lorsqu'un d'eux descend en dessous des niveaux attendus, nous enquêtons immédiatement - même si les users n'ont pas encore signalé de problème.
SLA que nous suivons
Nous maintenons deux SLA, dont le respect est informé par nos différentes métriques de heartbeat :
SLA Fin : Couvre la capacité de Fin à générer des réponses textuelles et à répondre aux clients en votre nom,
SLA Intercom : Couvre l'utilisabilité de l'Inbox pour votre équipe et du Messenger pour vos clients.
Quand comptons-nous un impact contre ces SLA ?
Nous comptons un impact contre nos SLA spécifiques lorsque :
Il y a une panne complète des fonctionnalités des produits Fin ou Core Platform.
Il y a une dégradation significative de l'expérience d'utilisation de nos fonctionnalités principales telles que Fin, Inbox et Messenger.
En raison de notre architecture et de nos méthodes de détection, l'impact SLA calculé reflète toujours le pire scénario, même si tous les clients ne sont pas également affectés par un problème donné.
Pour les conditions complètes entourant nos SLA, veuillez consulter nos conditions générales de service.
Comment nous détectons l'impact
Avec nos métriques de heartbeat, nous utilisons la détection d'anomalies, pas des seuils binaires. Cela nous permet de détecter des dégradations subtiles de l'expérience client, et pas seulement des pannes complètes, ce qui rend notre compréhension de notre respect de nos engagements envers vous plus claire.
Dans le cadre de cette détection, nous avons un programme robuste de réponse aux incidents en place. Si une métrique de heartbeat déclenche une alerte :
Un incident est ouvert et les ingénieurs sont alertés. Notre processus d'astreinte est disponible 24h/24 et 7j/7 pour assurer une couverture complète.
Nous pouvons automatiquement annuler les modifications récentes du code pour revenir à un état stable.
Les premiers intervenants reçoivent des causes racines suggérées via l'automatisation.
Objectifs de récupération
RPO (Recovery Point Objective) : 0 – notre infrastructure est conçue avec une redondance suffisante pour garantir qu'aucune donnée client n'est perdue, même en cas d'incidents.
RTO (Recovery Time Objective) : 8 heures – en cas de panne majeure affectant la disponibilité, nous visons à restaurer complètement le service dans les 8 heures dans les régions ou produits impactés.
Fenêtres de maintenance planifiées
Notre récente réarchitecture système permet une maintenance sans interruption, assurant une opération continue des clients même pendant les améliorations du système. Si cela n'est pas possible, nous informerons les clients au moins 24 heures à l'avance de toute maintenance, conformément à nos SLA.
Vous pouvez en savoir plus sur les récents changements de notre architecture système et les avantages qu'ils apportent sur notre blog ici : Évolution de l'infrastructure de base de données d'Intercom : leçons et progrès.