Na Fin, monitoramos a adesão ao SLA usando a atividade real dos clientes - não apenas a saúde do servidor.
Usamos “métricas de heartbeat” para monitorar a funcionalidade principal da nossa plataforma. Essas métricas refletem se os clientes podem usar os recursos principais dos nossos produtos - são uma medida das taxas de sucesso no mundo real dentro do nosso produto.
Se uma métrica de heartbeat cair, e o problema afetar a capacidade do cliente de usar nosso produto principal, contamos isso como impacto nos nossos SLAs.
O que é uma ‘métrica de heartbeat’?
Uma métrica de heartbeat é um indicador em tempo real e de alto volume que mostra se um recurso principal está funcionando.
Exemplos incluem:
Mensagens criadas no Web ou Mobile Messenger.
Respostas de colegas na Inbox.
Respostas de texto da Fin para os clientes.
Interações de colegas com a Inbox.
Monitoramos isso constantemente. Quando um indicador cai abaixo dos níveis esperados, investigamos imediatamente - mesmo que os users ainda não tenham reportado um problema.
SLAs que monitoramos
Mantemos dois SLAs, cuja adesão é informada por nossas várias métricas de heartbeat:
Fin SLA: Cobre a capacidade da Fin de gerar respostas de texto e responder aos clientes em seu nome,
Intercom SLA: Cobre a usabilidade da Inbox para sua equipe e do Messenger para seus clientes.
Quando contamos impacto contra esses SLAs?
Contamos impacto contra nossos SLAs específicos quando:
Há uma interrupção completa das funcionalidades do produto Fin ou Core Platform.
Há uma degradação significativa na experiência de uso dos nossos recursos principais, como Fin, Inbox e Messenger.
Devido à nossa arquitetura e métodos de detecção, o impacto calculado do SLA sempre reflete o pior cenário, mesmo que nem todos os clientes sejam igualmente afetados por um dado problema.
Para os termos completos relacionados aos nossos SLAs, consulte nossos termos de serviço completos.
Como detectamos impacto
Com nossas métricas de heartbeat, usamos detecção de anomalias, não limites binários. Isso nos permite capturar degradações sutis na experiência do cliente, e não apenas interrupções completas, tornando nosso entendimento sobre o cumprimento dos compromissos mais claro.
Como parte dessa detecção, temos um programa robusto de resposta a incidentes. Se uma métrica de heartbeat disparar um alerta:
Um incidente é aberto e os engenheiros são acionados. Nosso processo de plantão está disponível 24/7 para garantir cobertura total.
Podemos reverter automaticamente mudanças recentes no código para voltar a um estado estável.
Os primeiros respondentes recebem causas raiz sugeridas via automação.
Objetivos de recuperação
RPO (Recovery Point Objective): 0 – nossa infraestrutura é projetada com redundância suficiente para garantir que nenhum dado do cliente seja perdido, mesmo quando ocorrem incidentes.
RTO (Recovery Time Objective): 8 horas – no caso de uma grande interrupção que afete a disponibilidade, nosso objetivo é restaurar totalmente o serviço dentro de 8 horas nas regiões ou produtos impactados.
Janelas de manutenção planejadas
Nossa recente reestruturação do sistema permite manutenção sem tempo de inatividade, permitindo operação contínua dos clientes mesmo durante melhorias do sistema. Se isso não for possível, notificaremos os clientes com no mínimo 24 horas de antecedência sobre qualquer manutenção, conforme nossos SLAs.
Você pode ler mais sobre as recentes mudanças na arquitetura do nosso sistema e os benefícios que elas trazem em nosso blog aqui: Evolução da infraestrutura de banco de dados da Intercom: lições e progresso.