O que pedir ao contratar infraestrutura em um data center?

Contratar infraestrutura em um data center exige mais do que comparar processadores, memória e mensalidades. A decisão precisa esclarecer como sua aplicação será mantida, protegida, monitorada e recuperada em caso de falha.

É necessário ainda contar com uma arquitetura personalizável, já que, por exemplo uma loja virtual, um ERP e uma plataforma SaaS exigem arquiteturas diferentes, mesmo quando utilizam volumes semelhantes de CPU e memória. O que muda é o impacto de uma interrupção, a tolerância à perda de dados, o perfil de acesso e a capacidade da equipe interna de administrar o ambiente.

Antes de contratar, peça uma especificação técnica, o SLA do serviço, a matriz de responsabilidades, a política de backup e recuperação e as condições de migração e saída. Esses documentos permitem avaliar o que está incluído, o que depende de contratação adicional e quais compromissos poderão ser cobrados do fornecedor.

Quais documentos pedir antes de contratar um serviço de um data center?

Solicite documentos que transformem a oferta comercial em compromissos verificáveis. Recursos, limites, responsabilidades, atendimento e recuperação precisam estar descritos por serviço, não apenas em materiais institucionais.

Comece reunindo os requisitos da operação: aplicações, usuários simultâneos, volume e crescimento dos dados, integrações, localização dos usuários e períodos de maior demanda. Registre também quanto tempo cada sistema pode ficar indisponível e quanto dado o negócio aceita perder.

Com esse contexto, solicite:

• Proposta e ficha técnica: recursos, localização, limites de uso e itens opcionais.
• Desenho da arquitetura: componentes, conexões, redundâncias e dependências críticas.
• SLA e política de suporte: indicadores, cobertura, exclusões, escalonamento e compensações.
• Matriz de responsabilidades: atividades do provedor, do cliente e de eventuais terceiros.
• Plano de backup e recuperação: cobertura, retenção, metas e procedimentos de restauração.
• Documentação de segurança e proteção de dados: controles, subcontratados e comunicação de incidentes.
• Condições contratuais: reajustes, permanência, expansão, cancelamento, exportação e eliminação dos dados.

Para controles sensíveis, o fornecedor pode apresentar evidências sob acordo de confidencialidade. A questão é obter comprovação suficiente para avaliar o risco, sem exigir a divulgação pública de detalhes que comprometam a segurança.

Qual modelo de infraestrutura de data center atende sua operação?

Servidor dedicado, cloud server, Data Center Virtual e colocation atendem necessidades distintas. A escolha deve combinar perfil da aplicação, controle necessário, expansão e capacidade de gestão, sem tratar uma modalidade como superior em qualquer cenário.

Um servidor exclusivo não elimina a necessidade de backup ou redundância da aplicação. Da mesma forma, uma instância em nuvem não deve ser considerada automaticamente tolerante a falhas: confirme se a recuperação envolve reinicialização, migração ou outro mecanismo, e qual interrupção pode ocorrer.

Pergunte-se: “Se o componente que executa minha aplicação falhar, o que acontece com o serviço e quem atua para restabelecê-lo?”

Como avaliar capacidade e desempenho de um data center?

Quantidade de vCPU, memória e armazenamento não demonstra, isoladamente, o desempenho da aplicação. Peça características dos recursos, limites sustentados e testes representativos da sua carga de trabalho.

A ficha técnica deve informar modelo e geração dos processadores, núcleos ou vCPUs, memória disponível, capacidade útil de armazenamento e possibilidades de expansão. Em ambientes virtualizados, pergunte como a CPU é alocada e se existem limites, compartilhamento ou condições de uso intensivo.

No armazenamento, confirme:

• Tecnologia utilizada e capacidade efetivamente disponível para os dados.
• IOPS, taxa de transferência e latência, quando relevantes para o projeto.
• Se os valores anunciados são sustentados ou dependem de aceleração temporária.
• Redundância, tolerância a falhas e impacto da reconstrução de discos.
• Possibilidade de ampliar volumes e eventuais interrupções necessárias.

Para um banco de dados, tempo de resposta do armazenamento e consistência sob concorrência podem importar mais do que a capacidade nominal. Para uma aplicação com muitos usuários, avalie o conjunto: aplicação, banco, rede e integrações.

Quando viável, negocie uma prova de conceito com critérios de aceite. Utilize dados representativos, anonimizados ou sintéticos, e registre o desempenho esperado em carga normal e nos picos.

Pergunte-se: “Como este ambiente se comporta durante o pico da minha operação e quais limites podem reduzir seu desempenho?”

Como verificar disponibilidade e SLA de um data center?

Avalie separadamente a infraestrutura física, a arquitetura contratada e o SLA. A classificação Tier não substitui o acordo de nível de serviço nem garante, sozinha, a continuidade da aplicação.

O Uptime Institute caracteriza Tier III pela possibilidade de manutenção concorrente: a topologia permite manutenção sem desligar a operação de TI nas condições previstas. Isso não significa ausência de qualquer falha nem um percentual automático de disponibilidade da sua aplicação.

Também é importante distinguir a certificação dos documentos de projeto, a verificação da instalação construída e a avaliação de sustentabilidade operacional. Peça o comprovante correspondente à unidade que receberá o ambiente e verifique exatamente o que foi avaliado. No SLA, confirme:

• Objeto da medição: energia, rede, máquina virtual, servidor ou outro componente.
• Período e método de cálculo: como a indisponibilidade é detectada e contabilizada.
• Exclusões: manutenções, falhas de aplicações, ações do cliente e dependências externas.
• Procedimento de acionamento: evidências, prazo de solicitação e canal responsável.
• Compensações: forma de crédito e limites previstos no contrato.

Pergunte ainda sobre circuitos elétricos independentes, geradores, reabastecimento, climatização e diversidade de rotas. Em equipamentos com alimentação redundante, confirme se a implantação realmente utiliza circuitos independentes.

Um crédito por descumprimento de SLA não equivale à reparação de todas as perdas do negócio. Por isso, a arquitetura de continuidade deve ser definida pelo impacto da parada, não apenas pela compensação financeira prevista.

O que exigir de conectividade?

Verifique banda, regras de tráfego, rotas e desempenho até seus usuários. A velocidade da porta não é necessariamente a banda garantida, e a proximidade geográfica não comprova a latência de cada conexão.

Uma oferta com porta de 1 Gbps precisa esclarecer se a capacidade é dedicada ou compartilhada, se há franquia, cobrança por excedente ou política de uso aceitável. A palavra “ilimitado” não substitui essas condições.

Peça informações sobre:

• Banda comprometida, capacidade de pico e regras de limitação.
• Operadoras disponíveis e diversidade física dos caminhos de rede.
• Redes privadas, VPNs, interconexões e custos de conexões adicionais.
• Endereços IPv4 e IPv6 incluídos e política para endereços adicionais.
• Proteção DDoS: cobertura, limites, acionamento e comportamento durante a mitigação.
• Visibilidade de consumo, perda de pacotes, latência e variação do atraso.

Faça testes a partir das regiões onde estão usuários, filiais e integrações. Um resultado obtido dentro do próprio data center não representa necessariamente a experiência do cliente final.

Pergunte-se: “Durante uma falha de operadora ou um ataque, como o tráfego é tratado e quais limitações podem afetar minha aplicação?”

Como dividir responsabilidades de segurança e suporte de data center?

Separe segurança física, proteção da infraestrutura e administração dos sistemas. O contrato deve identificar quem monitora, quem decide e quem executa cada ação, inclusive fora do horário comercial.

Na segurança física, peça evidências sobre controle e registro de acesso, autorização de visitantes, vigilância, retenção de imagens e procedimentos emergenciais. No colocation, acrescente as regras para entrada de equipamentos e intervenção física assistida.

Na camada lógica, transforme a expressão “ambiente gerenciado” em uma lista de atividades. Uma matriz pode seguir este formato:

Monitorar não é o mesmo que corrigir. Receber um alerta de disco cheio, por exemplo, não esclarece quem poderá remover arquivos ou ampliar o volume.

A política de suporte deve diferenciar prazo de primeira resposta, início da atuação, restauração e resolução definitiva. Confirme severidades, cobertura em feriados, escalonamento e frequência de atualização durante incidentes críticos.

Se houver SOC gerenciado, peça o inventário dos ativos cobertos, as fontes de registros integradas e as ações previamente autorizadas. Uma equipe pode detectar uma ameaça sem ter autorização para isolar um servidor; essa decisão precisa estar combinada antes do incidente.

O que verificar sobre LGPD e localização dos dados de um data center?

Hospedar dados em data center no Brasil pode atender requisitos de residência e facilitar a governança, mas não produz conformidade automática com a LGPD. Verifique localização, acessos, subcontratados, proteção e obrigações de cada agente de tratamento.

A LGPD, especialmente no artigo 46, exige medidas para proteger dados pessoais. A contratação da infraestrutura é parte desse trabalho, não uma substituição da governança da empresa.

Pergunte onde ficam produção, réplicas, backups e registros de auditoria. Confirme também de quais países equipes e subcontratados podem acessar informações e quais mecanismos são aplicáveis às transferências internacionais, quando houver. A Resolução CD/ANPD nº 19/2024 regulamenta esse tema.

O contrato deve esclarecer instruções de tratamento, confidencialidade, controles administrativos, retenção, devolução ou eliminação dos dados e apoio ao controlador em incidentes e solicitações de titulares.

Combine um prazo de aviso do fornecedor que permita ao cliente avaliar o ocorrido e cumprir suas obrigações. O prazo contratual de comunicação entre fornecedor e cliente não deve ser confundido com o prazo regulatório aplicável ao controlador perante a ANPD e os titulares.

Pergunte-se: “Se ocorrer um incidente envolvendo dados pessoais, quais informações receberei, por qual canal e em quanto tempo?”

Como contratar backup e recuperação de dados?

Disponibilidade, redundância, backup e recuperação de desastres resolvem problemas diferentes. Defina perda de dados tolerável, tempo de retomada e evidências de restauração antes de escolher a política de proteção.

Redundância busca reduzir o impacto de falhas de componentes. Backup mantém cópias para recuperação. Disaster recovery organiza a retomada dos sistemas após eventos que comprometem o ambiente principal.

Uma exclusão acidental ou corrupção pode se propagar para uma réplica. Um snapshot mantido no mesmo ambiente pode não proteger contra a perda desse ambiente. Avalie independência, retenção e capacidade de recuperação, não apenas a existência de cópias.

Dois parâmetros orientam a contratação:

• RPO: objetivo de ponto de recuperação, que representa a perda de dados tolerável em termos de tempo.
• RTO: objetivo de tempo de recuperação, que representa o tempo pretendido para retomar o serviço após uma interrupção.

Como exemplo hipotético, RPO de uma hora significa planejar a recuperação considerando até uma hora de perda de dados; RTO de quatro horas significa planejar a retomada nesse intervalo. São objetivos que precisam ser sustentados por arquitetura, procedimentos e testes, não garantias automáticas de qualquer rotina de backup.

Solicite frequência e retenção das cópias, consistência dos bancos de dados, criptografia, gestão de chaves, isolamento das credenciais e proteção contra exclusão. Se houver imutabilidade, confirme o prazo, as permissões e as condições em que ela funciona.

A CISA recomenda backups críticos offline e criptografados, com testes regulares de disponibilidade e integridade. Na contratação, traduza essa orientação em controles verificáveis e evidências de restauração.

Não basta recuperar arquivos. O teste deve demonstrar que banco de dados, aplicação, autenticação, rede e integrações conseguem voltar a operar. Confirme também capacidade no destino de recuperação, custos de restauração e quem executará cada etapa.

Nenhuma política de backup elimina, sozinha, o risco de ransomware. Isolamento, acessos, monitoramento e validação contínua continuam necessários.

Como planejar migração expansão e saída?

Combine como o ambiente entra em produção, cresce e poderá ser transferido no futuro. Migração, ampliação e encerramento têm impactos técnicos e financeiros que precisam ser conhecidos antes da assinatura.

Na migração, defina inventário, compatibilidade, responsáveis, janela de mudança e critérios de aceite. Registre como serão feitos sincronização dos dados, testes de acesso, validação das integrações e retorno ao ambiente anterior se a mudança falhar.

Para expansão, pergunte quais recursos podem ser ampliados sem interrupção, quais dependem de reinicialização e quais exigem migração ou troca de hardware. Confirme prazo de provisionamento, disponibilidade de capacidade e efeitos sobre licenças e preços. Escalabilidade não significa expansão instantânea e irrestrita.

No encerramento, documente:

• Formatos e mecanismos de exportação de dados, imagens e configurações.
• Prazo de acesso após a solicitação de cancelamento.
• Custos de transferência, apoio técnico e operação simultânea durante a transição.
• Regras de portabilidade ou substituição de endereços IP e dependências de licenças.
• Prazos de retenção e eliminação, incluindo o tratamento das cópias de backup.
• Evidências de eliminação que poderão ser disponibilizadas.

Pergunte-se: “Se precisarmos migrar esta operação no futuro, quais etapas, prazos, dependências e custos teremos?”

Como comparar propostas e custos de data centers?

Compare propostas com o mesmo escopo e pelo custo total da operação. Uma mensalidade menor pode excluir proteção, administração, conectividade ou recuperação que sua aplicação exige.

Antes de comparar preços, marque os requisitos indispensáveis. Uma proposta que não atende à recuperação ou à localização exigida não se torna equivalente apenas porque custa menos.

Use o quadro abaixo como roteiro. Em cada coluna, registre a condição oferecida e a referência do documento que a comprova. “Não informado” é uma pendência; não significa “não se aplica”.

Monte o custo total com mensalidade, implantação, migração, licenças, gerenciamento, proteção, backup, tráfego e serviços adicionais. Para colocation, inclua potência, consumo quando aplicável, conexões e intervenções físicas.

Projete cenários de operação normal, pico e crescimento. Verifique também quanto custam uma restauração completa, uma ampliação e uma saída. O objetivo é entender quanto custa manter a operação dentro dos requisitos do negócio, não apenas quanto custa provisionar o ambiente.

Qual deve ser o próximo passo?

Prepare uma ficha de requisitos e use os mesmos critérios para avaliar arquitetura, contrato e custo. Depois, leve as lacunas para uma conversa técnica, antes de decidir pela configuração ou pela mensalidade.

Comece registrando aplicações, volume de dados, demanda normal e de pico, integrações, localização dos usuários, RPO, RTO e responsabilidades que sua equipe pretende manter. Esse documento permite discutir necessidades concretas, em vez de iniciar a contratação por uma lista isolada de recursos.

Na HostDime Brasil, o portfólio inclui servidores dedicados, cloud, Data Center Virtual, colocation, cloud backup e SOC gerenciado. São alternativas e serviços complementares: a composição deve refletir sua carga de trabalho e o escopo que estiver documentado na proposta.

Use este roteiro para uma primeira revisão interna e identifique os pontos ainda sem resposta. Com essa ficha em mãos, converse com a equipe técnica da HostDime Brasil para avaliar dimensionamento, conectividade, proteção e recuperação junto com o seu time, antes de avançar para uma proposta comercial.

Ao contratar infraestrutura em um data center, o pedido central deve ser: “Quais recursos, controles e responsabilidades permitem operar e recuperar minha aplicação dentro dos limites do negócio?” A resposta precisa estar na arquitetura, no contrato e nos testes.