Como escolher e implementar SLAs e playbooks de suporte contínuo

O primeiro critério é a capacidade de assumir a operação depois da implantação. Um fornecedor adequado precisa compreender o fluxo de negócio, a arquitetura, as integrações, os pontos de falha e os limites de responsabilidade entre sua equipe e a equipe contratada.

Peça evidências do processo de transição. O fornecedor deve explicar como coleta acessos, valida diagramas, revisa logs, testa alertas, documenta procedimentos e confirma que outra pessoa consegue executar o atendimento. Se a operação depende de um único especialista, o risco permanece mesmo com um SLA formalizado.

Também verifique como os chamados são classificados. Um bom modelo diferencia incidente crítico, incidente relevante, solicitação de serviço, evento de segurança e problema recorrente. Cada categoria precisa ter prazo, canal, responsável, critérios de escalonamento e forma de encerramento próprios.

Pergunte quais métricas aparecem no relatório mensal. MTTA mede o tempo médio até o reconhecimento ou início do atendimento, enquanto MTTR costuma representar o tempo médio até a recuperação ou resolução, conforme a definição contratual. Sem uma definição precisa, dois lados podem apresentar números diferentes para o mesmo incidente.

A documentação técnica é outro ponto decisivo. O fornecedor deve entregar ou manter uma base com inventário, contatos, dependências, variáveis de ambiente, procedimentos de rollback, evidências de testes e histórico de mudanças. Para integrações, consulte também o guia para escolher um parceiro de integrações e APIs para automações em PMEs.

Por fim, avalie a postura diante de falhas. Um fornecedor maduro não promete que incidentes nunca ocorrerão. Ele mostra como detecta, contém, comunica, recupera e aprende com cada ocorrência, incluindo análise de causa raiz quando o problema pode voltar a acontecer.

Disponibilidade, MTTA e MTTR são métricas úteis, mas não devem aparecer isoladas. A disponibilidade mede o tempo em que um serviço esteve operacional em determinado período. Uma meta de 99,9% ao mês, por exemplo, permite aproximadamente 43 minutos de indisponibilidade nesse intervalo, antes de considerar a forma de medição e as exclusões contratuais.

Defina claramente o que entra no cálculo. Manutenções programadas, indisponibilidade de terceiros, falhas causadas por alterações não autorizadas e incidentes de força maior podem ter tratamento específico, mas essas exceções precisam ser visíveis e auditáveis.

Para automações, acompanhe métricas de negócio e de execução. Taxa de sucesso dos fluxos, quantidade de itens em fila, idade do item mais antigo, falhas por integração, tempo de processamento e volume de intervenções manuais mostram problemas que a disponibilidade do servidor não revela.

Para infraestrutura, inclua uso de CPU, memória, armazenamento, certificados, backups, reinicializações, erros de aplicação e disponibilidade dos serviços essenciais. O monitoramento deve gerar alertas acionáveis, com limiares ajustados ao comportamento do ambiente, e não uma sucessão de notificações que a equipe aprende a ignorar.

A referência Alerting on SLOs, do Google SRE explica como relacionar objetivos de nível de serviço a alertas e orçamento de erro. A ideia é útil para decidir quando uma equipe deve priorizar estabilidade em vez de novas mudanças.

Inclua ainda métricas de qualidade operacional: percentual de chamados resolvidos dentro do SLA, reincidência, quantidade de incidentes sem causa identificada, cobertura de runbooks, mudanças que causaram falhas e percentual de alertas testados. A Trait consolida esses indicadores em painéis operacionais no Metabase, permitindo discutir tendência e não apenas o incidente mais recente.

O contrato também deve prever a periodicidade dos relatórios, os participantes da reunião de revisão, o formato das evidências e o processo para alterar metas. Um SLA precisa acompanhar a maturidade do ambiente, o crescimento do volume e a evolução da criticidade.

O preço de um contrato de suporte não deve ser calculado apenas pelo número de servidores. O esforço depende da quantidade de automações, criticidade dos processos, volume de integrações, necessidade de cobertura fora do horário comercial, nível de monitoramento, complexidade dos acessos e maturidade da documentação.

Uma PME com poucos servidores, mas com uma automação que processa pedidos a cada minuto, pode exigir mais cuidado que um ambiente maior com cargas previsíveis. O custo também aumenta quando o fornecedor precisa reconstruir a arquitetura, corrigir alertas, criar runbooks e organizar acessos antes de iniciar a operação recorrente.

Separe no orçamento a fase de preparação do serviço mensal. Diagnóstico, documentação, criação de playbooks, testes e ajustes iniciais são atividades de implantação do suporte. Misturá-las a uma mensalidade baixa costuma gerar escopo indefinido e discussões sobre o que está ou não incluído.

Na análise de valor, compare o custo do contrato com horas de retrabalho, vendas interrompidas, multas, atraso de conciliação, perda de dados e dependência de profissionais-chave. O retorno pode aparecer não apenas na disponibilidade, mas também na redução de intervenções manuais e na capacidade de a equipe interna trabalhar em projetos estratégicos.

Erros frequentes incluem contratar atendimento 24 horas sem definir quais eventos justificam acionamento, aceitar uma meta de disponibilidade sem método de medição, manter credenciais compartilhadas e criar runbooks que nunca são testados. Outro problema comum é medir apenas chamados encerrados, ignorando incidentes detectados pelo monitoramento.

Antes de assinar, solicite uma proposta com premissas, limites, horários, quantidade de ativos, horas ou franquias quando aplicável, atividades fora de escopo, tratamento de terceiros, reajustes e condições de saída. Para avaliar também a base técnica do parceiro, use o checklist para escolher um parceiro de infraestrutura em nuvem para PMEs.