Quando todos os processos internos são declarados críticos, a organização acaba com alertas constantes, equipas de prevenção difíceis de sustentar e compromissos que ninguém consegue cumprir. O problema não é apenas técnico: a prioridade real de uma indisponibilidade dilui-se e a operação de aplicações, integrações e dados que talvez admitam espera, reprocessamento ou uma alternativa manual torna-se mais dispendiosa.
A decisão útil não consiste em classificar um sistema como «importante». Consiste em acordar que consequência para o negócio é inaceitável, durante quanto tempo e em que condições. A partir daí, alguns processos exigirão um acordo de nível de serviço (SLA); outros funcionarão melhor com uma expectativa operacional, um objetivo interno revisto periodicamente ou simplesmente boas práticas de suporte.
Este enquadramento permite justificar prioridades junto das equipas de produto, negócio e tecnologia sem escolher números por intuição nem transformar cada pedido numa obrigação de disponibilidade permanente.
SLA, objetivo operacional e boa prática: compromissos distintos
Um SLA é um compromisso explícito relativo a um serviço definido. Normalmente, estabelece âmbito, horário, métricas, responsabilidades, exclusões e um mecanismo de revisão ou escalonamento. Não equivale a prometer que nunca haverá incidentes: expressa o nível de funcionamento esperado e a forma como o incumprimento será gerido.
Na operação interna, é conveniente distingui-lo de dois instrumentos mais leves:
- Objetivo de nível de serviço: uma meta mensurável para orientar a operação, como concluir uma sincronização antes de uma hora acordada. Pode ser revisto sem tratar cada desvio como um incumprimento contratual.
- Expectativa operacional: uma norma de trabalho clara, mas menos rígida. Por exemplo, rever uma fila de pedidos em dias úteis ou publicar um relatório no início do dia.
- Boa prática: um procedimento desejável, como monitorizar erros ou documentar uma recuperação manual. É valioso, mas não deve ser apresentado como garantia se não existirem capacidade, cobertura e responsáveis para o sustentar.
A diferença decisiva é a consequência. Se uma interrupção bloqueia receitas, obrigações operacionais críticas ou o atendimento a clientes, e não existe uma alternativa razoável, um SLA costuma justificar-se. Se a equipa puder reagendar a tarefa, usar dados do dia anterior ou concluir o trabalho manualmente, uma expectativa operacional será muitas vezes mais honesta e eficiente.
Não atribua um SLA pela visibilidade de quem o solicita ou pela antiguidade do sistema. Atribua-o pelo dano verificável de não prestar o serviço numa janela concreta.
As cinco perguntas para classificar cada processo
Antes de discutir percentagens de disponibilidade ou tempos de resposta, classifique o processo usando as mesmas perguntas para todas as equipas. A conversa deixa de ser uma negociação abstrata e passa a ser uma avaliação de risco.
- Qual é o impacto se não funcionar? Descreva o efeito em encomendas, operações, conformidade, utilizadores ou decisões. Evite respostas genéricas como «é muito importante». Identifique que ação não pode ser realizada e quem fica bloqueado.
- Qual é a janela real de utilização? Um portal utilizado para efetuar encomendas durante todo o dia não tem a mesma necessidade que uma carga de dados noturna. Defina dias, períodos horários, fechos e picos conhecidos.
- De que depende? Liste aplicações, APIs, fornecedores, credenciais, redes, dados de origem e equipas responsáveis. Um compromisso só pode abranger aquilo que a equipa consegue observar e operar.
- Existe uma alternativa manual ou em modo degradado? Determine se é possível registar informação temporariamente, aceitar encomendas por outro canal, consultar uma cópia anterior ou repetir uma tarefa. Avalie também a capacidade real dessa alternativa, e não apenas a sua existência teórica.
- Que perda de dados ou atraso é tolerável? Distinga indisponibilidade de integridade. Um processo pode aceitar duas horas de atraso, mas não uma transação duplicada, dados incompletos ou a perda de alterações.
Documente as respostas juntamente com um responsável de negócio e um responsável técnico. Se não houver acordo sobre o impacto ou a tolerância, ainda não existe base para definir um nível de serviço; há uma decisão de negócio pendente.
Uma matriz de criticidade útil para aplicações e integrações
Uma matriz simples impede que a classificação dependa de quem apresenta o pedido. Classifique cada dimensão como baixa, média ou alta: impacto, sensibilidade à janela de utilização, ausência de alternativa, risco de dados e complexidade das dependências.
- Criticidade alta: impacto direto e imediato, janela limitada ou contínua, sem alternativa viável e com risco significativo de perda ou inconsistência. Exige SLA, monitorização, escalonamento definido e testes de recuperação.
- Criticidade média: o atraso afeta o trabalho ou decisões relevantes, mas existe um modo degradado ou margem para recuperação. Exige objetivos operacionais mensuráveis, acompanhamento de erros e revisão periódica.
- Criticidade baixa: o processo melhora a eficiência, mas pode esperar, ser reprocessado ou temporariamente substituído. Basta uma expectativa operacional, priorização no backlog e suporte no horário acordado.
A categoria deve aplicar-se ao serviço concreto, e não à aplicação inteira. A mesma plataforma pode incluir um portal transacional crítico, um relatório de consulta adiável e uma exportação mensal. Um único SLA global esconderia estas diferenças e imporia custos desnecessários.
Exemplo de classificação
Um portal de encomendas pode ter criticidade alta se os utilizadores não puderem efetuá-las por outro canal e uma interrupção parar a operação. A sincronização noturna de catálogo pode ser média se puder ser repetida antes da abertura ou se o catálogo anterior permitir operar temporariamente. Um relatório interno de acompanhamento pode ser baixo se for consultado uma vez por dia e os respetivos dados puderem chegar com atraso.
Este exemplo não determina uma categoria universal. Se a sincronização alimentar preços obrigatórios ou se o relatório desencadear uma decisão regulada, a avaliação muda. A classificação depende da consequência e da janela, não do tipo de tecnologia.
O que deve incluir um SLA interno sustentável
Um SLA útil deve ser específico e operacionalizável. Prometer «elevada disponibilidade» ou «atendimento rápido» cria ambiguidade no momento de um incidente. Em contrapartida, um documento breve pode definir com precisão o que é prestado e como é medido.
- Âmbito: processo, interfaces, utilizadores e resultado esperado. Indique os componentes que ficam de fora.
- Horário de serviço: período de operação assumido, calendário aplicável e janelas de manutenção.
- Métricas: disponibilidade do processo, prazo de deteção, tempo de primeira resposta, tempo de reposição ou atraso máximo admissível. Meça resultados, e não apenas a atividade da equipa.
- Responsáveis: responsável de negócio, responsável técnico, equipa que trata o incidente e responsáveis por cada dependência.
- Exclusões: dados de origem não recebidos, indisponibilidades de terceiros, alterações não aprovadas ou utilização acima da capacidade prevista. Não são desculpas: delimitam o controlo real.
- Escalonamento: canal de aviso, severidades, pessoas que decidem medidas de contingência e comunicação aos afetados.
Evite copiar objetivos de fornecedores ou de outros produtos. Um valor só é defensável se responder a uma necessidade de negócio e se a arquitetura, a observabilidade e a capacidade de resposta permitirem cumpri-lo. As práticas de engenharia de fiabilidade popularizadas pela Google distinguem entre indicadores, objetivos e acordos precisamente para evitar que uma aspiração se transforme numa promessa impossível.
Como definir métricas sem escolher números arbitrários
Comece pela necessidade, e não por uma percentagem. Pergunte: «Qual é o último momento em que este resultado tem de estar disponível para evitar o dano identificado?». Essa resposta define um limite operacional. Depois, confronte esse limite com os dados históricos, as dependências e a capacidade de recuperação.
Para a disponibilidade, meça a capacidade de concluir a ação relevante, e não apenas o facto de uma página responder. Numa integração, pode ser mais útil medir a percentagem de execuções concluídas e o atraso dos registos do que o estado de um servidor. Para a recuperação, separe duas decisões:
- Objetivo de tempo de recuperação: quanto pode durar a interrupção antes de restaurar o serviço ou ativar uma alternativa.
- Objetivo de ponto de recuperação: quanta informação pode ser perdida ou ficar pendente de reconciliação após o incidente.
Defina também um orçamento de erro operacional: a margem de incumprimento que pode ser tolerada durante um período antes de dar prioridade à fiabilidade em vez de a novas melhorias. Se a margem se esgotar repetidamente, não basta tornar o SLA mais exigente; é necessário rever o desenho, a dependência externa, a automatização, a capacidade de suporte ou até a necessidade do processo.
Dependências, alterações e sinais para rever o compromisso
O erro mais frequente é assumir um resultado de ponta a ponta quando várias partes não estão sob o mesmo controlo. Se uma API externa, uma equipa de dados ou um fornecedor de comunicações participar no fluxo, documente a dependência e acorde o seu próprio objetivo. Se esse acordo não existir, formule o compromisso de modo condicionado: o que a equipa fará quando receber dados válidos ou quando o terceiro restabelecer o serviço.
Reveja cada classificação quando surgir algum destes sinais:
- O processo começa a ser utilizado em novos horários ou por mais equipas.
- A alternativa manual desaparece ou deixa de ser viável devido ao volume.
- Aumentam os erros repetidos, os reprocessamentos ou as intervenções manuais.
- São acrescentadas integrações, alterações de dados ou novos pontos de falha.
- Um incidente revela que o impacto real foi maior ou menor do que o documentado.
Estabeleça uma revisão periódica e também uma revisão após incidentes relevantes. O resultado não tem de ser tornar o compromisso mais exigente: pode consistir em reduzir o âmbito, criar um modo degradado, melhorar um alerta, separar um serviço crítico de uma tarefa adiável ou reduzir um SLA que já não corresponde à utilização real.
Checklist para tomar e manter a decisão
- Descreva o resultado de negócio que o processo entrega.
- Defina impacto, janela de utilização, alternativa, dependências e tolerância à perda ou ao atraso.
- Classifique o processo pela criticidade, e não a aplicação completa.
- Atribua um SLA apenas aos resultados cujo incumprimento tenha um dano inaceitável.
- Para os restantes, defina um objetivo operacional ou uma expectativa de suporte clara.
- Confirme que as métricas podem ser observadas e que existem responsáveis para atuar.
- Documente exclusões e contingências antes de ocorrer um incidente.
- Reveja o compromisso perante alterações de utilização, dependência ou impacto.
A maturidade não consiste em ter mais SLAs. Consiste em fazer com que cada compromisso reflita uma necessidade real, possa ser medido e tenha uma resposta operacional viável. Essa disciplina protege tanto quem depende do serviço como as equipas que o têm de manter.