O que inclui um contrato SLA de IT eficaz

Quando um servidor deixa de responder, uma ligação remota falha ou há suspeita de ransomware, não basta saber que existe suporte. A questão operacional é outra: quem assume o incidente, em quanto tempo, com que prioridade e até à reposição de que serviço? É precisamente aqui que a pergunta o que inclui contrato SLA deixa de ser administrativa e passa a ser uma decisão de continuidade de negócio.

Um SLA - Service Level Agreement, ou acordo de nível de serviço - transforma expectativas em compromissos mensuráveis. Não é uma frase comercial sobre “suporte rápido”. É o documento que define o nível de serviço contratado, os limites da responsabilidade do prestador e os mecanismos para acompanhar se o serviço está, ou não, a cumprir.

Para uma empresa que depende de aplicações, conectividade, postos de trabalho, sistemas de backup e infraestrutura híbrida, um SLA mal definido cria uma falsa sensação de proteção. Quando ocorre um incidente crítico, surgem as interpretações: o suporte estava incluído? O tempo conta a partir da abertura do pedido ou do diagnóstico? O fornecedor resolve ou limita-se a encaminhar para o fabricante? Um contrato claro elimina grande parte desta fricção.

O que inclui um contrato SLA de IT

Em primeiro lugar, o contrato deve identificar os serviços e ativos abrangidos. Pode incluir a monitorização de servidores, firewalls, switches, redes Wi-Fi, Microsoft 365, postos de trabalho, armazenamento, cópias de segurança, cloud pública ou privada e ferramentas de cibersegurança. Não basta escrever “suporte informático”. É necessário saber quais os equipamentos, aplicações, localizações e utilizadores incluídos.

Em segundo lugar, deve definir o horário de cobertura. Um serviço 8x5, em horário útil, responde a uma realidade diferente de uma operação 24x7. Uma empresa industrial, uma unidade de saúde ou uma organização com equipas internacionais pode precisar de acompanhamento permanente para os serviços críticos, mantendo cobertura em horário laboral para pedidos correntes. Esta distinção tem impacto direto no custo e no risco aceite.

O SLA deve também estabelecer os canais de contacto e de escalonamento. Portal de suporte, e-mail, telefone de emergência e contacto direto com o gestor de conta não são equivalentes. Em incidentes graves, ter acesso a uma equipa que conhece o ambiente tecnológico reduz o tempo perdido a repetir informação e a explicar dependências entre sistemas.

Tempos de resposta não são tempos de resolução

Este é um dos pontos mais mal interpretados nos contratos de suporte. O tempo de resposta mede o período entre o registo válido do incidente e o início do tratamento pela equipa técnica. O tempo de resolução, por sua vez, mede o prazo para restaurar o serviço, aplicar uma solução definitiva ou disponibilizar uma alternativa operacional.

Um SLA pode comprometer uma primeira resposta em 30 minutos para uma ocorrência crítica, mas isso não significa que o serviço esteja recuperado nesse período. A recuperação pode depender de diagnóstico, substituição de hardware, intervenção de terceiros, reposição de dados ou validação da aplicação pelo cliente. Por isso, um contrato bem construído deve distinguir claramente resposta, atualização, mitigação e resolução.

Para evitar ambiguidades, as métricas devem indicar:

• tempo máximo para acusar e assumir o incidente;
• cadência de atualizações enquanto o incidente está aberto;
• objetivo de reposição ou mitigação por nível de prioridade;
• tempo de resolução quando for contratualmente aplicável;
• disponibilidade mensal do serviço, quando existe operação gerida;
• consequências, créditos de serviço ou plano de correção num caso de incumprimento.

Os créditos de serviço podem ser relevantes, mas não devem ser o centro da decisão. Uma compensação financeira não recupera vendas perdidas, reputação ou produtividade. O valor real do SLA está na capacidade de reduzir a duração e o impacto de uma interrupção.

Prioridades e classificação de incidentes

A prioridade deve resultar do impacto no negócio e da urgência, não apenas da tecnologia afetada. Um alerta num servidor não crítico pode ser uma prioridade baixa. A indisponibilidade do ERP, do e-mail corporativo, da ligação à internet principal ou de uma plataforma de faturação poderá ser crítica, mesmo que a causa técnica pareça simples.

É habitual trabalhar com quatro níveis. Uma prioridade P1 corresponde a paragem total ou risco elevado para a operação, segurança ou dados. A P2 aplica-se a degradação grave com impacto relevante. A P3 cobre falhas com solução alternativa disponível, e a P4 reúne pedidos de serviço, dúvidas e alterações planeadas.

O contrato deve apresentar exemplos adaptados ao ambiente do cliente. Caso contrário, cada incidente torna-se uma negociação sobre prioridade. E, em segurança, esta definição deve prever eventos específicos, como deteção de malware, comprometimento de credenciais privilegiadas, indisponibilidade causada por ataque DDoS ou falha da plataforma de backup.

Cobertura técnica, responsabilidades e fronteiras

Um SLA eficaz não promete que tudo será resolvido por uma única equipa em qualquer circunstância. Define, com rigor, quem faz o quê. Esta clareza é especialmente necessária em ambientes com vários fabricantes, fornecedores de internet, aplicações de negócio, cloud e equipas internas.

O prestador pode assumir a monitorização, o diagnóstico, a gestão de patches, a administração de backups, a resposta inicial a incidentes e a coordenação técnica com terceiros. O cliente pode ser responsável por manter contactos autorizados, aprovar alterações, garantir acesso físico a instalações, renovar licenças ou validar a recuperação de aplicações de negócio.

Também importa clarificar se o fornecedor apenas abre um pedido junto do fabricante ou se acompanha o processo até à resolução. Para o responsável de TI, a diferença é substancial. Ter cinco fornecedores a apontar responsabilidades uns aos outros aumenta o tempo de indisponibilidade. Um parceiro que assume a gestão transversal da stack reduz a fragmentação e mantém um ponto de responsabilidade operacional.

Na ITPOINT, a abordagem é assumir esta responsabilidade desde a arquitetura e implementação até à operação contínua, sempre com o âmbito e os limites contratuais identificados. Não vendemos tecnologia como um elemento isolado. Operamos infraestrutura com objetivos concretos de disponibilidade, segurança e controlo.

Exclusões: o que fica fora do SLA

As exclusões não são uma letra pequena dispensável. São uma proteção para ambas as partes, desde que sejam razoáveis e transparentes. Um contrato deve indicar, por exemplo, se projetos de migração, desenvolvimento aplicacional, substituição de equipamentos fora de garantia, deslocações ao local, formação, recuperação forense ou alterações de grande dimensão estão incluídos na mensalidade ou são faturados à parte.

Também devem estar previstas situações fora do controlo do prestador: falhas generalizadas de operadores, indisponibilidades de serviços cloud de terceiros, acesso insuficiente aos sistemas, incumprimento de requisitos técnicos acordados ou intervenções não autorizadas no ambiente. Isto não elimina a obrigação de acompanhar o incidente, mas enquadra a responsabilidade e as métricas aplicáveis.

É aqui que muitas organizações cometem um erro: comparam apenas o valor mensal de dois contratos. O custo total de propriedade depende da cobertura efetiva, das exclusões, da maturidade da operação e da capacidade de o fornecedor agir quando há pressão. Um preço baixo com horas de suporte limitadas e múltiplas excepções pode tornar-se caro no primeiro incidente sério.

Disponibilidade, RTO e RPO para serviços críticos

Nos serviços geridos, o SLA pode incluir uma meta de disponibilidade, normalmente expressa em percentagem mensal. Mas uma disponibilidade de 99,9% não diz tudo por si só. É necessário perceber quais as componentes abrangidas, como se calcula a indisponibilidade, se as manutenções planeadas são excluídas e que dependências externas existem.

Para backup e disaster recovery, o SLA deve estar alinhado com RTO e RPO. O RTO define o tempo máximo aceitável para recuperar um serviço. O RPO define a perda máxima de dados aceitável, medida no tempo. Uma cópia de segurança diária pode ser suficiente para um serviço secundário, mas é inadequada para uma base de dados transacional que não pode perder um dia de registos.

Estas métricas exigem testes. Um backup concluído não é sinónimo de recuperação garantida. O contrato deve prever validações periódicas, testes de restauro e relatórios que confirmem se os objetivos de recuperação continuam realistas à medida que a infraestrutura e as aplicações evoluem.

Governance ativa e reporting de serviço

O SLA não termina quando o ticket é encerrado. Um serviço maduro inclui governance ativa: análise periódica de incidentes, tendências, tempos de resposta, vulnerabilidades, capacidade, estado dos backups e ações de melhoria. Este acompanhamento permite corrigir causas recorrentes antes de se transformarem em indisponibilidade.

Os relatórios devem ser úteis para decisões técnicas e financeiras. Um CIO precisa de saber se o serviço cumpriu os níveis acordados, mas também quais os riscos que permanecem abertos. Um diretor financeiro precisa de prever custos e perceber se a operação está a reduzir paragens, trabalho reativo e investimento não planeado.

Vale a pena exigir reuniões de serviço com uma frequência adequada ao ambiente. Para uma infraestrutura crítica, uma revisão mensal pode ser necessária. Para um âmbito mais simples, uma revisão trimestral pode bastar. O essencial é haver responsáveis nomeados, indicadores verificáveis e decisões registadas.

Como avaliar uma proposta de SLA

Antes de assinar, peça cenários concretos. O que acontece se o firewall falhar às 02h00? Quem atua se um utilizador reportar um possível phishing? Como é feita a escalada para Dell, HPE, Microsoft, Fortinet ou outro fabricante? Que ativos são monitorizados? Quais os tempos para P1 e P2? Há limite de pedidos ou horas incluídas? Quem aprova alterações com impacto na produção?

Se a proposta responder a estas perguntas com linguagem vaga, ainda não é um SLA operacional. Um bom contrato traduz necessidades de negócio em procedimentos executáveis, métricas auditáveis e responsabilidades sem zonas cinzentas.

O SLA certo não é o que promete uma resposta impossível a tudo. É o que permite saber, antes do incidente, quem assume o comando, que resultado é esperado e como a empresa volta a operar com o menor impacto possível.