SLA de software: o que exigir do fornecedor

O contrato de sustentação promete "atendimento em até quatro horas". Numa sexta-feira à noite, o sistema de faturamento para. Alguém abre um chamado, recebe em minutos uma resposta automática com número de protocolo, e o sistema volta na segunda-feira. Tecnicamente, o SLA foi cumprido. Na prática, a empresa ficou sem faturar um fim de semana inteiro.

Esse descompasso é mais comum do que parece, e quase nunca é má-fé. É um SLA escrito para medir o que é fácil de medir, e não o que importa para a sua operação. A seguir, como ler um acordo de nível de serviço com olho de quem depende do sistema, o que exigir e como verificar se ele está sendo cumprido de verdade.

SLA, SLO e o que realmente está sendo prometido

Três siglas aparecem nessa conversa, e vale separar:

• SLI (indicador de nível de serviço): o que é medido. Proporção de requisições bem-sucedidas, tempo de resposta de uma tela, tempo até o primeiro atendimento de um chamado.
• SLO (objetivo de nível de serviço): a meta interna para esse indicador. É o que a equipe técnica persegue no dia a dia.
• SLA (acordo de nível de serviço): o compromisso contratual, com consequências definidas quando não é cumprido.

Um bom fornecedor trabalha com objetivos internos mais rigorosos do que o SLA contratado, justamente para ter margem antes de descumprir o acordo. Se o fornecedor não sabe dizer quais indicadores acompanha internamente, o SLA provavelmente só existe no papel.

A pergunta mais importante ao ler qualquer SLA é: o que exatamente está sendo prometido, medido por quem e como? Promessas vagas ("alta disponibilidade", "atendimento prioritário", "melhores esforços") não são compromissos verificáveis.

Disponibilidade: como é medida e o que fica de fora

Disponibilidade parece simples: o sistema estava no ar ou não. Na prática, cada palavra dessa frase precisa de definição.

O que conta como "no ar"? Se o servidor responde, mas o login falha, o sistema está disponível? Se a tela abre, mas a emissão de nota fiscal não funciona? Uma medição honesta usa as funções críticas do negócio, não apenas o fato de uma página carregar.

Quem mede e de onde? A medição deve vir de uma verificação externa, que simula o acesso de um usuário, e não apenas dos painéis internos do fornecedor. Se a infraestrutura inteira cair, o monitoramento interno cai junto.

Qual é a janela? Disponibilidade medida no mês inteiro, 24 horas por dia, é diferente de disponibilidade medida só no horário comercial. Nenhuma das duas está errada, mas precisam refletir quando a sua operação realmente usa o sistema.

O que fica de fora? Todo SLA tem exclusões, e é nelas que a promessa costuma encolher:

• Manutenções programadas. Razoável, desde que tenham aviso prévio, janela definida e limite de frequência. Sem limite, qualquer parada vira "manutenção".
• Falhas de terceiros. Provedor de nuvem, gateway de pagamento, serviço da Receita. Faz sentido excluir o que foge do controle do fornecedor, mas não o que ele poderia ter mitigado com redundância ou fila de reprocessamento.
• Mudanças solicitadas pelo cliente. Justo, desde que a mudança tenha sido feita a pedido e com os riscos comunicados.

Desconfie de números de disponibilidade muito altos sem arquitetura que os sustente. Um sistema rodando num único servidor, sem réplica e sem plano de recuperação, não tem como entregar uma promessa ambiciosa, por mais que o contrato diga que sim.

Severidade definida pelo impacto no negócio

O coração de um SLA de sustentação é a classificação de severidade, e ela precisa ser definida em termos do seu negócio, não em termos técnicos.

Uma estrutura comum, com quatro níveis:

• Crítica: operação parada ou sem alternativa. Faturamento, vendas, produção ou atendimento impedidos para todos ou para uma unidade inteira. Risco de segurança ou de vazamento de dados também entra aqui.
• Alta: função importante comprometida, mas com contorno possível, ainda que trabalhoso. Um relatório gerencial fora do ar em dia de fechamento, uma integração parada com reprocessamento manual possível.
• Média: falha que incomoda, sem impacto relevante na operação. Um filtro que não funciona, um campo exibido errado.
• Baixa: dúvidas, ajustes cosméticos, pedidos de melhoria.

O trabalho de verdade é listar, antes de assinar, quais situações do seu negócio se encaixam em cada nível. "Nota fiscal não emite" é crítica. "Relatório de comissão atrasado" talvez seja alta no fechamento e média no resto do mês. Sem essa lista, cada incidente começa com uma discussão sobre a severidade, justamente quando ninguém tem tempo para isso.

Defina também quem pode classificar e reclassificar. O normal é o cliente abrir com a severidade que percebe, e as duas partes ajustarem com base em critérios escritos.

Tempo de resposta não é tempo de solução

Aqui mora a maior parte dos SLAs que parecem bons e não são.

• Tempo de resposta é o tempo até alguém qualificado começar a trabalhar no problema. Resposta automática com número de protocolo não conta.
• Tempo de contorno é o tempo até a operação voltar a funcionar, mesmo que de forma provisória: um rollback, um processamento manual assistido, a desativação de uma função problemática.
• Tempo de solução definitiva é o tempo até a causa ser corrigida de forma permanente.

Para incidentes críticos, o número que importa para a sua operação é o tempo de contorno. Um SLA que só promete tempo de resposta está prometendo que alguém vai olhar, não que o problema vai ser resolvido.

Solução definitiva raramente tem prazo contratual rígido, e isso é compreensível, porque a causa de alguns problemas exige investigação. Mas é razoável exigir um plano de correção comunicado dentro de um prazo e uma análise pós-incidente escrita para toda ocorrência crítica: o que aconteceu, qual foi a causa, o que foi feito e o que muda para não acontecer de novo. Análise sem busca de culpados, focada em causa e prevenção.

Atenção também ao horário de cobertura. Se a sua operação roda aos sábados, ou de madrugada, e o SLA só vale em horário comercial, o relógio de um incidente de sexta à noite só começa a contar na segunda de manhã.

Monitoramento, plantão e comunicação de incidente

Um fornecedor que só age quando você abre chamado está terceirizando para você a detecção dos problemas. O esperado de uma sustentação séria é que ele saiba do incidente antes do seu cliente, e de preferência antes de você.

Pergunte como isso funciona na prática:

• O que é monitorado? Só infraestrutura ou também as funções críticas do negócio, como emissão de pedidos e integrações? O que isso exige do sistema está em observabilidade: logs, métricas e traces.
• Quem recebe o alerta fora do horário? Existe escala de plantão com nomes, ou é "a equipe"?
• Qual o canal de comunicação durante o incidente? Um canal oficial, com atualizações em intervalos definidos, evita que o seu gestor fique ligando para saber se alguém está olhando.
• Quem do seu lado precisa ser avisado? O SLA deve prever uma lista de contatos para comunicação de incidentes, atualizada.

Incidentes que envolvem dados pessoais trazem uma camada a mais: a LGPD (Lei 13.709/2018) exige que o controlador comunique à ANPD e aos titulares incidentes de segurança que possam acarretar risco ou dano relevante. O fornecedor precisa avisar você rápido o suficiente para que isso seja possível, e o contrato deve dizer isso explicitamente.

Relatórios e revisão periódica

SLA sem relatório é promessa sem prova. Exija um relatório periódico com, pelo menos:

• disponibilidade medida no período, com a metodologia usada;
• incidentes por severidade, com tempos de resposta, contorno e solução;
• chamados abertos e encerrados, e os que estão parados há mais tempo;
• análises pós-incidente das ocorrências críticas;
• ações preventivas realizadas: atualizações de segurança, melhorias de desempenho, ajustes de alerta.

Mais importante que o relatório é a reunião de revisão. Números mostram o que aconteceu; a conversa decide o que muda. Um padrão saudável é revisar os incidentes recorrentes e decidir se vale corrigir a causa com trabalho evolutivo, assunto que tratamos em manutenção evolutiva de software.

SLA e continuidade são coisas diferentes

Um SLA cobre a rotina de incidentes. Ele não substitui um plano para o dia em que tudo dá errado ao mesmo tempo: ransomware, perda do ambiente, exclusão acidental do banco de dados.

Para isso, o contrato deve mencionar explicitamente os objetivos de recuperação, ou seja, quanto dado a empresa aceita perder e quanto tempo aguenta ficar parada, e como os backups são testados. O tema tem texto próprio: plano de recuperação de desastres para sistemas.

Perguntas para fazer antes de assinar

• Como a disponibilidade é medida, de onde e sobre quais funções?
• Quais são as exclusões, e quais limites valem para manutenção programada?
• Quais situações do meu negócio se encaixam em cada severidade?
• O SLA promete tempo de resposta, de contorno ou de solução?
• Qual é o horário de cobertura para cada severidade?
• Quem está de plantão fora do horário, e como o alerta chega a essa pessoa?
• Qual é o canal oficial e a frequência de atualização durante um incidente crítico?
• Existe análise pós-incidente escrita para ocorrências críticas?
• Qual relatório vou receber e com que periodicidade?
• O que acontece quando o SLA é descumprido, e o que acontece quando é descumprido repetidamente?
• Em caso de incidente com dados pessoais, em quanto tempo sou avisado?
• Se eu encerrar o contrato, como recebo código, acessos, documentação e dados?

A última pergunta costuma ser esquecida e é das mais importantes. Ela conecta o SLA ao processo de escolha do fornecedor, discutido em como escolher uma software house.

Como saber se o SLA está funcionando

Depois de alguns ciclos de relatório, olhe para além do cumprimento formal:

• Quem descobre os incidentes primeiro: o fornecedor ou a sua equipe?
• Os mesmos problemas continuam voltando?
• Houve discussão sobre severidade em incidentes recentes?
• As análises pós-incidente geraram mudanças concretas?

Um SLA sempre cumprido com a operação sofrendo é sinal de que os indicadores estão medindo a coisa errada.

Sustentação com compromisso verificável

Na Pervian Tech, sustentação faz parte do nosso trabalho de cloud e DevOps: monitoramento das funções que importam para o seu negócio, severidade definida junto com você, plantão com responsáveis nomeados e relatórios que mostram o que aconteceu e o que mudou.

Cada operação tem criticidade e horário próprios, então o acordo é desenhado sob medida e o investimento é definido sob consulta, depois de um diagnóstico inicial gratuito do sistema e do que a sua operação exige dele. Se o seu SLA atual não protege o que realmente importa, fale com a gente.