En Fin, rastreamos la adherencia al SLA usando la actividad real de los clientes, no solo la salud del servidor.
Usamos “métricas de latido” para monitorear la funcionalidad principal de nuestra plataforma. Estas métricas reflejan si los clientes pueden usar funciones clave de nuestros productos; son una medida de las tasas de éxito en el mundo real dentro de nuestro producto.
Si una métrica de latido cae y el problema afecta la capacidad del cliente para usar nuestro producto principal, lo contamos como un impacto en nuestros SLA.
¿Qué es una ‘métrica de latido’?
Una métrica de latido es un indicador en tiempo real y de alto volumen que muestra si una función principal está funcionando.
Ejemplos incluyen:
Mensajes creados en Web o Mobile Messenger.
Respuestas de compañeros en el Inbox.
Respuestas de texto de Fin a los clientes.
Interacciones de compañeros con el Inbox.
Monitoreamos estos constantemente. Cuando uno cae por debajo de los niveles esperados, investigamos de inmediato, incluso si los users aún no han reportado un problema.
SLA que rastreamos
Mantenemos dos SLA, cuya adherencia se informa mediante nuestras diversas métricas de latido:
Fin SLA: Cubre la capacidad de Fin para generar respuestas de texto y responder a los clientes en tu nombre,
Intercom SLA: Cubre la usabilidad del Inbox para tu equipo y el Messenger para tus clientes.
¿Cuándo contamos el impacto contra estos SLA?
Contamos el impacto contra nuestros SLA específicos cuando:
Hay una interrupción completa de las funcionalidades del producto Fin o Core Platform.
Hay una degradación significativa en la experiencia de usar nuestras funciones principales como Fin, Inbox y Messenger.
Debido a nuestra arquitectura y métodos de detección, el impacto calculado del SLA siempre refleja el peor escenario, incluso si no todos los clientes se ven afectados por igual por un problema dado.
Para los términos completos que rodean nuestros SLA, por favor consulta nuestros términos completos de servicio.
Cómo detectamos el impacto
Con nuestras métricas de latido, usamos detección de anomalías, no umbrales binarios. Esto nos permite captar degradaciones sutiles en la experiencia del cliente, y no solo interrupciones completas, lo que significa que nuestra comprensión de si estamos cumpliendo nuestros compromisos contigo es más clara.
Como parte de esta detección, tenemos un programa robusto de respuesta a incidentes. Si una métrica de latido genera una alerta:
Se abre un incidente y se alerta a los ingenieros. Nuestro proceso de guardia está disponible 24/7 para asegurar cobertura completa.
Podemos revertir automáticamente cambios recientes en el código para volver a un estado estable.
A los primeros respondedores se les proporcionan causas raíz sugeridas mediante automatización.
Objetivos de recuperación
RPO (Recovery Point Objective): 0 – nuestra infraestructura está diseñada con redundancia suficiente para asegurar que no se pierda ningún dato de cliente, incluso cuando ocurren incidentes.
RTO (Recovery Time Objective): 8 horas – en caso de una interrupción mayor que afecte la disponibilidad, nuestro objetivo es restaurar completamente el servicio en 8 horas en las regiones o productos afectados.
Ventanas de mantenimiento planificadas
Nuestra reciente re-arquitectura del sistema permite mantenimiento sin tiempo de inactividad, permitiendo operación continua del cliente incluso durante mejoras del sistema. Si esto no es posible, notificaremos a los clientes con un mínimo de 24 horas de anticipación a cualquier mantenimiento, según nuestros SLA.
Puedes leer más sobre los cambios recientes en la arquitectura de nuestro sistema y los beneficios que aportan en nuestro blog aquí: Lecciones y progreso en la evolución de la infraestructura de base de datos de Intercom.