Suporte de Infraestrutura de TI: SLA e Cobertura Real

Um servidor HPE ProLiant em produção apresenta falha num momento crítico. O analista de TI abre o chamado, acessa o portal do fabricante e descobre que a garantia venceu há sete meses. Não há contrato de suporte ativo. O próximo passo é ligar para distribuidores, pesquisar peças, tentar achar um técnico disponível — tudo isso enquanto sistemas de negócio ficam parados.

Essa situação é mais comum do que parece. E o problema raramente é falta de cuidado. É falta de clareza sobre o que estava contratado.

Garantia de fabricante não é suporte especializado

A maioria dos equipamentos sai de fábrica com alguma cobertura padrão. Mas essa cobertura tem limites que não aparecem na embalagem.

A garantia padrão cobre defeitos de fabricação dentro de um prazo. O que ela não cobre: tempo de resposta definido, atendimento fora do horário comercial, diagnóstico remoto, substituição expressa de componentes e suporte para configuração do ambiente. Quando o servidor para às 19h de uma terça-feira, a garantia de fabricante não garante que alguém vai atender até a manhã seguinte.

Um contrato de suporte especializado funciona de forma diferente. Ele define um SLA (Service Level Agreement, ou nível de serviço acordado), com o tempo máximo de resposta e de resolução do problema. Os níveis mais comuns são:

• NBD (Next Business Day): atendimento no próximo dia útil
• 4 horas: técnico ou peça disponível em até 4 horas após abertura do chamado
• 24x7x4: cobertura 24 horas por dia, 7 dias por semana, com resposta em até 4 horas

Para um servidor que sustenta o ERP da empresa, a diferença entre NBD e 4 horas pode significar um dia inteiro de operação paralisada.

Cada camada da infraestrutura tem um impacto diferente

Servidor, storage e switching causam impactos distintos quando falham, e o suporte precisa refletir isso.

Uma falha em um switch de acesso pode isolar um andar inteiro. Já uma falha de storage costuma ser mais grave: dependendo da arquitetura, pode derrubar múltiplos servidores ao mesmo tempo, já que todos dependem do mesmo volume de dados.

Servidores em produção precisam de SLA compatível com o que sustentam. Um servidor que roda apenas tarefas administrativas tolera NBD. Um servidor que processa pedidos em tempo real não tolera.

O que muda quando o equipamento sai de suporte

Fabricantes encerram o suporte oficial de modelos mais antigos, o que é chamado de EOS (End of Support) ou EOL (End of Life). A partir desse ponto, não há mais atualizações de firmware, peças originais ficam escassas e qualquer reposição depende de mercado paralelo, sem garantia de compatibilidade.

Muitas equipes de TI só descobrem que um equipamento está nessa condição quando precisam acionar o suporte. Além de lidar com a falha, precisam justificar por que o ativo estava operando sem cobertura.

Há também um custo que não aparece no orçamento: o tempo da equipe interna gasto tentando resolver sem suporte adequado. Em times enxutos, isso significa deixar outras demandas paradas para improvisar o que poderia ter sido resolvido em horas com o contrato certo.

Como estruturar o suporte antes que o problema apareça

O ponto de partida é saber o que está em campo: equipamentos ativos, datas de garantia, versão de firmware e nível de criticidade de cada ativo. Com esse mapeamento, é possível classificar os ativos por impacto real. O critério não é o custo do equipamento, mas o que paralisa o negócio se ele parar.

Outro ponto que simplifica a gestão é trabalhar com um parceiro que cubra múltiplos fabricantes. Ter contratos separados para HPE, Cisco, Aruba e Dell significa gerenciar quatro fluxos distintos de atendimento, com SLAs e interlocutores diferentes. Um parceiro com capacidade multi-vendor unifica esse controle e ainda conhece o ambiente como um todo, não apenas o equipamento isolado.

Se quiser entender como a infraestrutura desatualizada pode criar riscos além da disponibilidade, vale a leitura sobre infraestrutura de TI defasada e os riscos do crescimento acelerado.

Estruturar o suporte de infraestrutura não é uma decisão técnica. É uma decisão de negócio, e ela precisa ser tomada antes da falha, não durante. Se você quer mapear as lacunas do suporte atual e identificar quais equipamentos estão descobertos, fale com um especialista da Aviti e comece por onde faz mais sentido para a sua operação.