Resumo
- A garantia anual de 99,9% de disponibilidade da TECNOWEB Colombia permite cerca de 8 horas e 46 minutos de inatividade, mas seus termos concedem à equipe técnica até 48 horas após a notificação para resolver um incidente elegível e não publicam um método de medição, cronograma de crédito de serviço ou objetivo de recuperação por produto.
- A empresa afirma que possui seus servidores, usa gabinetes exclusivos, consoles remotos e controle remoto de energia, e envia cópias incrementais para um data center externo, mas não nomeia publicamente as instalações de produção ou backup, identifica suas jurisdições ou mostra quanta capacidade permanece utilizável após uma falha de host, energia, refrigeração ou rede.
- O AS64114 e os blocos de endereço registrados na Colômbia são evidências públicas ativas de uma pegada de rede real, enquanto dois upstreams observados e várias presenças em exchanges são apenas conexões lógicas; eles não estabelecem que os racks da TECNOWEB Colombia tenham duas saídas físicas independentes, dois caminhos de energia independentes ou um destino de migração testado.
Oito horas de tolerância, seguidas por um relógio de 48 horas
A aritmética por trás de 99,9% é simples o suficiente para caber em uma fatura. Em um ano de 365 dias, os 0,1% faltantes equivalem a 525,6 minutos: 8 horas, 45 minutos e 36 segundos. Essa é a tolerância anual total de interrupção se cada minuto indisponível for contado. Para uma empresa cujo site, checkout, aplicativo ou caixa postal está hospedado no serviço, a questão importante não é se três noves soam reconfortantes. É quando o relógio começa, o que o pára, quais falhas contam e o que acontece quando a tolerância é excedida.
A página inicial da TECNOWEB na Colômbia anuncia 99,9% de disponibilidade, ativação imediata, suporte 24 horas em espanhol, backups automáticos e hospedagem em data centers de "primeiro nível". Os atuais termos de serviço são mais consequentes. Eles afirmam que a TECNOWEB Colombia SAS garante 99,9% de disponibilidade anual para serviços de hospedagem. Para um incidente fora dos casos de força maior, a equipe técnica fornecerá uma solução no prazo máximo de 48 horas a partir da notificação.
O mesmo documento exclui ou limita a responsabilidade por interrupções atribuídas a distribuidoras de energia elétrica, desastres naturais, links nacionais ou internacionais fornecidos por terceiros, hardware ou software de terceiros e credenciais mal manuseadas.
Essas declarações podem coexistir contratualmente, mas deixam uma ampla lacuna operacional. Uma janela de resolução de 48 horas é mais de cinco vezes toda a tolerância anual de interrupção. "Solução" pode cobrir um reparo, uma solução alternativa, uma cópia restaurada ou outra resposta; os termos não a definem. Eles também não dizem se a disponibilidade é medida em um servidor, uma porta de aplicativo, um painel de controle, um domínio do cliente ou na borda da rede da TECNOWEB.
Não há fórmula pública para manutenção planejada, degradação parcial, perda de pacotes ou um cliente que só consegue acessar um servidor por meio de uma rota com falha. Também não há uma tabela de crédito de serviço publicada que converta a falta de disponibilidade em compensação.
Isso não é evidência de que a TECNOWEB causou uma interrupção de 48 horas ou que sua restauração normal leva esse tempo. É evidência de que o contrato público e o número de marketing respondem a perguntas diferentes. O número de marketing descreve um resultado. A cláusula descreve o tempo máximo permitido para ação após um cliente relatar um problema.
Uma avaliação séria de continuidade precisa da ponte operacional entre eles: monitoramento que detecta um incidente antes de um ticket, níveis de gravidade nomeados, intervalos de reconhecimento e atualização, uma meta de restauração, uma meta de recuperação de dados e um registro de se o resultado foi alcançado.
A página de VPS da TECNOWEB também invoca "Tier III". A explicação do Uptime Institute sobre as classificações de Tier define o Tier III como mantido simultaneamente, com componentes e caminhos de distribuição redundantes que permitem manutenção planejada sem interromper as operações de TI. A página pública da TECNOWEB não nomeia uma instalação, vincula um certificado ou informa qual sala e carga a designação cobre. Portanto, a leitura prudente é uma declaração do fornecedor sobre o ambiente de hospedagem, não uma prova com escopo independente de que cada produto, rack e dependência herda características de Tier III.
A promessa se torna significativa apenas em um limite. Se um evento de energia derrubar um host e uma máquina virtual for reiniciada em outro lugar em minutos, o ano pode permanecer dentro de 99,9%. Se o host saudável não tiver RAM, armazenamento ou capacidade licenciada, a migração para. Se o servidor sobreviver, mas ambos os upstreams visíveis compartilharem uma entrada de edifício, o tráfego ainda será interrompido. Se existir um backup, mas não puder ser restaurado rapidamente, a proteção de dados não restaura a disponibilidade. As dez seções restantes seguem essa corrente, do contrato ao rack e de volta ao cliente.
O catálogo é mais amplo que uma única pilha de hospedagem
A TECNOWEB Colombia não está vendendo uma máquina uniforme única. Seu catálogo atual abrange ambientes compartilhados, máquinas virtuais, servidores físicos, contas de revenda, e-mail gerenciado, suítes de produtividade de terceiros, registro de domínio e serviços de segurança. Cada produto move o limite operacional e muda o que um cliente pode razoavelmente esperar que a TECNOWEB controle.
A página de hospedagem Linux comercializa cPanel, LiteSpeed e armazenamento NVMe. Ela atribui cotas finitas de armazenamento e caixa postal a quatro planos e distingue backups semanais nas ofertas menores de backups diários nas maiores. A oferta WordPress adiciona uma camada de aplicativo otimizada, cache e uma interface de gerenciamento WordPress. A hospedagem Windows muda o cliente para Plesk, IIS e suporte a aplicativos orientados à Microsoft, enquanto o serviço Java adiciona dependências de Tomcat e runtime Java. Estes não são apenas rótulos diferentes.
Eles envolvem diferentes planos de controle, ciclos de patch, dependências de licença, perfis de memória e procedimentos de recuperação.
Os planos de revenda estendem a consequência de uma falha de infraestrutura para os clientes de outra empresa. A TECNOWEB comercializa WHM, contas white-label, domínios nominalmente ilimitados, clientes e transferência, e níveis finitos de armazenamento de 20 GB a 100 GB. Um revendedor pode se apresentar como o provedor imediato, mesmo que o reparo físico, hipervisor, armazenamento e caminho upstream permaneçam fora de seu controle. Um nó compartilhado com falha pode, portanto, atingir usuários finais que nunca ouviram falar da TECNOWEB.
O catálogo de VPS usa KVM no Proxmox e vende planos que variam de duas vCPUs, 2 GB de RAM, 40 GB de SSD e 1 TB de transferência a quatro vCPUs, 8 GB de RAM, 300 GB de SSD e 10 TB de transferência. Os clientes recebem acesso root, um console de navegador, snapshots e controles de firewall no nível do hipervisor. A página de servidores dedicados promete hardware exclusivo, descreve entrega rápida para configurações populares e recomenda um disco adicional para backup.
Um cliente dedicado evita vizinhos barulhentos no nível do convidado, mas ainda compartilha energia da instalação, refrigeração, links upstream, mão remota e possivelmente um switch de topo de rack.
O e-mail introduz mais dois limites. O Email Empresas é apresentado como um serviço Open-Xchange com 25 GB de armazenamento de e-mail e 5 GB de armazenamento de arquivos por conta, recursos de colaboração e disponibilidade de 99,9%. A página mais antiga Email Pymes anuncia 5 GB por conta e faz afirmações mais amplas sobre backup, redundância e disponibilidade de rede. A TECNOWEB também revende Google Workspace e Microsoft 365. Nesses produtos, a TECNOWEB pode controlar venda, integração, cobrança e suporte de primeira linha, mas a infraestrutura global de aplicativos e armazenamento pertence ao provedor da plataforma upstream.
Essa variedade é importante porque "TECNOWEB está fora do ar" pode descrever vários incidentes distintos. Um nó web compartilhado pode falhar enquanto o e-mail hospedado no Google continua. O portal do cliente pode ficar indisponível enquanto um VPS existente continua servindo tráfego. Um erro de renovação de domínio pode remover um site funcional da internet pública sem qualquer falha de servidor. Um revendedor pode perder o acesso administrativo enquanto os sites downstream permanecem online.
Um compromisso de serviço útil precisa identificar o produto e o ponto que está sendo medido; uma porcentagem em toda a marca não pode, por si só, descrever todos esses estados.
Um contrato colombiano fica dentro de um limite operacional regional
A contraparte legal é visível. Uma página de diretório de empresas colombiana baseada em dados RUES lista TECNOWEB COLOMBIA S A S como ativa, fornece NIT 901182036, coloca-a em Bogotá e classifica suas atividades como processamento de dados, hospedagem e trabalhos relacionados, além de consultoria de TI e administração de instalações de computação. A página de pagamento da Colômbia da TECNOWEB mostra a superfície comercial local em pesos colombianos e canais de pagamento locais. Os termos de serviço escolhem a lei colombiana e os tribunais em Bogotá.
Isso não significa que todo servidor, funcionário, licença ou recurso de rede pertença à empresa colombiana. O material "sobre" da própria marca diz que ela fornece serviços relacionados à hospedagem desde 2002, enquanto a listagem comercial pública identifica a atual SAS colombiana. O histórico da marca e a idade de uma entidade legal não são a mesma coisa. O site também oferece vitrines específicas por país em toda a região. Um comprador precisa saber qual empresa fatura o serviço, qual empresa opera o equipamento, qual empresa detém o recurso de rede e qual entidade é responsável quando o serviço cruza uma fronteira.
O limite regional é especialmente claro nos registros de números da internet. O cadastro eleitoral de 2025 da LACNIC lista TECNOWEB COLOMBIA SAS entre as organizações colombianas. No entanto, o registro LACNIC para AS64114 identifica o registrante do sistema autônomo como TECNOWEB PERU SAC e o registra como ativo. A entrada de entidade LACNIC separada para TECNOWEB COLOMBIA SAS fornece um endereço administrativo em Bogotá e conecta a organização colombiana a registros de recursos numéricos.
Essas entradas estabelecem identidades formais; elas não estabelecem uma empresa controladora, participação acionária ou acordo de serviço interno. Seria um exagero converter uma marca compartilhada, um contato técnico ou um sistema autônomo comum em uma relação corporativa legalmente comprovada. O que a evidência mostra é interdependência operacional: o espaço de endereço colombiano pode ser originado por meio de um sistema autônomo registrado para uma empresa peruana, e o contato técnico pode administrar recursos em vários rótulos de país.
A empresa colombiana voltada ao cliente pode, portanto, depender de capacidades de grupo ou parceiros que não são descritas no contrato de varejo.
Essa distinção é importante na recuperação. Suponha que o endereço de um cliente colombiano permaneça registrado para a TECNOWEB Colombia enquanto as mudanças de rota são feitas sob AS64114. A equipe autorizada a alterar o roteamento pode trabalhar para outra entidade regional ou uma função de operações compartilhada. Suponha que o rack de produção esteja em uma instalação contratada por uma empresa irmã. O vendedor colombiano pode coordenar o suporte, mas não controlar o acesso ao prédio ou o despacho da operadora. Nenhum desses arranjos é inerentemente fraco; empresas de hospedagem regionais geralmente compartilham infraestrutura.
O risco vem da opacidade sobre autoridade e escalonamento quando os minutos são importantes.
Uma programação robusta do cliente nomearia a entidade contratante, operador de infraestrutura, operador de instalação, operador de rede e subcontratados materiais. Também diria qual parte pode autorizar uma mudança de rota, mover uma máquina virtual, recuperar uma cópia externa, substituir um disco e comunicar um incidente. As páginas públicas nomeiam produtos e uma contraparte colombiana. Elas não publicam essa matriz de responsabilidades.
A empresa descreve seus racks sem nomear o prédio
A página da empresa TECNOWEB fornece descrições de primeira parte incomumente concretas. Ela diz que a empresa possui, em vez de alugar, todos os seus equipamentos e servidores; usa sistemas dual Intel Xeon com 128 GB a 256 GB de RAM, SSDs empresariais e RAID 1 ou RAID 10; equipa servidores com placas de rede ópticas de 10 Gbps; abriga-os em gabinetes exclusivos; e anexa dispositivos remotos de console e gerenciamento de energia. Também afirma ter três camadas de firewall, monitoramento 24 horas, DNS no Chile, Estados Unidos, França e Inglaterra, e cópias incrementais diárias enviadas para um data center externo.
Essas são declarações úteis sobre um projeto operacional pretendido. Elas descrevem o controle no nível do servidor e do gabinete: hardware próprio, acesso físico restrito, administração fora da banda e a capacidade de religar a energia remotamente. Elas também revelam dependências. Um console remoto funciona apenas enquanto sua rede de gerenciamento e serviço de autenticação estiverem acessíveis. Uma unidade de energia remota pode reiniciar um servidor travado, mas não pode reparar uma fonte de alimentação com falha, substituir um disco ou restaurar um switch morto.
RAID pode tolerar falhas de disco especificadas; não é uma cópia protegida contra exclusão, corrupção, incêndio ou uma falha do controlador de armazenamento.
O substantivo que falta é a instalação. A página repetidamente diz "o Data Center" ou "um Data Center externo" sem nomear nenhum deles. Ela não fornece endereço, operador da instalação, identificador da sala, número de certificação, topologia de energia, topologia de refrigeração, design de supressão de incêndio, exposição a inundações, entradas de operadora ou jurisdição do site de backup.
A página de VPS chama o ambiente de Tier III, e a página de dedicados fala de servidores na Colômbia e uma variedade de opções de data center, mas nenhuma fornece um registro específico da instalação que vincule essas descrições aos planos colombianos disponíveis na data da pesquisa.
O endereço de Bogotá no registro de entidade da LACNIC é uma evidência administrativa, não uma coordenada de data center. Um detentor de recurso de rede pode ser registrado em um escritório enquanto seus servidores operam em outra cidade ou país. Da mesma forma, vendas em todo o país para Bogotá, Medellín, Cali e outras cidades descrevem um mercado, não a localização dos racks. A hospedagem chega a um cliente colombiano pela internet; não precisa de um servidor na cidade do cliente.
Uma observação no nível do endereço torna a questão da localização mais nítida sem resolvê-la. A página do IPinfo para 179.61.15.3, um endereço dentro de um bloco registrado para TECNOWEB Colombia, coloca esse endereço em Tampa, Flórida, e o rotula como infraestrutura de hospedagem. A página em si é um produto de geolocalização observacional, não um contrato de instalação. Um IP pode ser movido, anunciado remotamente, localizado imprecisamente ou usado para apenas um serviço. Ele não pode provar onde residem a frota de hospedagem compartilhada, hosts VPS, servidores dedicados ou cópias de backup.
A conclusão correta não é "os servidores estão em Tampa". É que rótulos de país no registro de endereço, vitrines de site e bancos de dados de geolocalização respondem a perguntas diferentes. A localização do titular legal, mercado do cliente, origem da rota e localização física do rack podem divergir. A evidência que resolveria a questão é direta: um cronograma atual de instalações nomeando os prédios de produção e backup, seus operadores e países; uma alocação de produto para site; um certificado ou escopo de auditoria onde reivindicado; e confirmação de que os dados do cliente são armazenados ou replicados apenas nos locais declarados.
Até que essa evidência esteja disponível, a superfície física pode ser descrita, mas não mapeada com precisão. Existem servidores, gabinetes, interfaces de rede, dispositivos de controle remoto e sistemas de backup de acordo com a empresa. Existe espaço de endereço ativo e roteamento. Existe um escritório e contrato colombiano. Não há uma cadeia publicamente verificável ligando um plano colombiano específico a um rack nomeado em uma instalação nomeada.
Cotas vendidas não revelam capacidade instalada ou sobrevivente
As páginas de hospedagem são ricas em cotas de clientes e quase silenciosas sobre a planta total. Isso é normal na hospedagem de varejo, mas torna a análise de capacidade fácil de errar. Um plano de 50 GB não é evidência de que um provedor instalou apenas 50 GB, e 1 TB de transferência não é uma porta de 1 Tbps. Os números descrevem o que um cliente pode consumir sob um produto, não quanto servidor, armazenamento, rede ou energia o provedor instalou.
Os planos Linux publicam 10 GB, 30 GB, 50 GB e 80 GB de armazenamento NVMe, com diferentes cotas de caixa postal, banco de dados, domínio e backup. A página de revenda publica 20 GB, 30 GB, 50 GB e 100 GB enquanto usa "ilimitado" para domínios, clientes e transferência. Ilimitado não pode significar fisicamente infinito; é uma promessa comercial limitada por hardware compartilhado, regras de uso aceitável e a capacidade do provedor de controlar a contenção.
As páginas não divulgam o número de contas por servidor, oversubscription de armazenamento, limites de CPU, limites de memória, limites de E/S ou a capacidade de nó sobressalente reservada para evacuar um host com falha.
A página de VPS é mais explícita no limite do convidado. Seus quatro planos mostram alocações de vCPU, RAM, SSD e transferência e afirmam que os recursos são dedicados sem overselling. Mesmo que cada alocação de convidado listada seja aplicada, a folga física permanece desconhecida. Quatro convidados de 8 GB podem caber em muitos hosts diferentes; um cluster com um nó sobressalente se comporta de maneira diferente de um único servidor totalmente comprometido.
O isolamento KVM não divulga o número de hosts, a política de posicionamento, o design de armazenamento compartilhado, a capacidade de migração ao vivo, a disponibilidade de licenças ou quantos convidados podem reiniciar após a falha do maior host.
A faixa de memória do servidor de 128 GB a 256 GB e a reivindicação de placa de rede de 10 Gbps da página da empresa são sinais de componentes instalados, mas não há contagem de servidores ou inventário específico de data. Uma interface de rede classificada em 10 Gbps não é evidência de 10 Gbps de trânsito pago, backplane de switching, throughput sustentado ou largura de banda utilizável durante uma falha upstream. RAID 1 e RAID 10 descrevem o layout do disco, não o armazenamento disponível após reserva, snapshots e backups.
A promessa da página de servidores dedicados de entrega em apenas quatro horas para configurações populares sugere algum inventário ou acesso rápido de provisionamento, mas não identifica quantas unidades estão disponíveis, onde são mantidas ou o que acontece durante uma escassez regional de hardware.
A capacidade de e-mail é igualmente segmentada. Email Empresas atribui 30 GB por conta entre e-mail e arquivos; Email Pymes atribui 5 GB. As ofertas do Google Workspace e Microsoft 365 expõem cotas de licença e caixa postal fornecidas por seus proprietários de plataforma. A TECNOWEB pode vender mais contas sem adicionar um servidor ao seu próprio rack quando o fornecedor upstream carrega a carga de trabalho. Por outro lado, um serviço Open-Xchange operado em infraestrutura controlada ou contratada pela TECNOWEB pode depender diretamente de seu cluster de armazenamento e e-mail. O catálogo não publica a divisão.
A capacidade, portanto, precisa de pelo menos seis rótulos. A capacidade de projeto é o que uma arquitetura pretende. A capacidade instalada está fisicamente presente. A capacidade energizada pode ser ligada. A capacidade operacional foi comissionada e é utilizável. A capacidade vendida ou reservada já está comprometida. A capacidade utilizável é o que resta após despesas gerais e reserva. A capacidade utilizável em estado de falha é a porção que sobrevive ao host, caminho de energia, sistema de armazenamento ou saída de rede relevante com falha.
As evidências públicas suportam direitos individuais de produtos e algumas descrições de componentes. Elas não divulgam o total de computação instalada, armazenamento total instalado, trânsito pago, utilização atual, capacidade vendida, folga de recuperação reservada ou capacidade utilizável em estado de falha. Nenhuma estimativa responsável do número de clientes ou tamanho da frota pode ser derivada dos planos. Um comprador deve pedir evidências na escala de sua carga de trabalho: o posicionamento do host ou cluster, a política de reserva atual, a suposição de maior falha e a capacidade disponível após essa falha.
Uma classificação de hardware em destaque é importante apenas quando conectada a esses estados.
AS64114 mostra acessibilidade, não um par de rotas de fibra independentes
A TECNOWEB tem mais evidências de rede do que muitas marcas de hospedagem pequenas. Os registros LACNIC conectam recursos colombianos à empresa, e os coletores de rotas públicas veem o AS64114 originando um conjunto de prefixos de vários países. Essa é uma evidência sólida de uma rede lógica ativa. Não é um mapa da fibra entre um rack colombiano e o resto da internet.
A consulta LACNIC para 45.191.2.0/24 retorna a alocação circundante 45.191.0.0/22 e um handle de registrante para TECNOWEB Colombia. O registro 179.61.15.0/24 identifica um bloco realocado ativo associado ao mesmo handle de entidade colombiana. Esses são registros de recursos numéricos. Eles estabelecem espaço de endereço delegado e responsabilidade administrativa, não o prédio onde cada endereço é usado.
A visualização AS64114 do BGP.tools observou 15 prefixos IPv4 e 33 IPv6 originados, incluindo 45.191.2.0/24 e 179.61.15.0/24 sob rótulos colombianos. Também observou dois upstreams, AS29802 da Hivelocity e AS36236 da NetActuate, e várias presenças em internet exchanges. A visualização AS64114 do IPinfo também listou esses dois upstreams e milhares de domínios hospedados em centenas de endereços observados. A concordância entre dois serviços de observação fortalece o caso de que o AS64114 está ativo e multi-homed no nível do sistema autônomo na data da pesquisa.
Isso não estabelece independência de rota para um serviço colombiano específico. Um sistema autônomo pode anunciar diferentes prefixos de diferentes continentes. Os dois upstreams podem estar presentes em um site, sites separados, exchanges remotos ou uma mistura. Ambos podem entrar em um prédio pelo mesmo duto, depender da mesma operadora metropolitana ou terminar no mesmo roteador e alimentação elétrica. A participação em exchange na Europa ou por meio de conexões virtuais não diz nada por si só sobre o caminho usado por 45.191.2.0/24 de um cliente colombiano.
A distinção é visível na página 45.191.2.0/24 do IPinfo. Ela rotula o recurso como Colômbia, mas explica explicitamente que o país mostrado é onde o detentor do recurso está legalmente sediado e pode não ser onde os endereços são usados. Esse aviso deve governar todo o mapa. O sinal de Tampa para 179.61.15.3 é relevante porque sugere que pelo menos algum espaço registrado na Colômbia pode ser atendido nos Estados Unidos. Ele não pode localizar todo o /24 ou o resto dos produtos da TECNOWEB.
A contagem de domínios hospedados também é um sinal de mercado, não um censo de clientes. Muitos domínios podem compartilhar um cliente, um endereço pode hospedar centenas de domínios e um domínio pode estar inativo ou com proxy. A contagem sugere que a rede carrega atividade de hospedagem pública material. Ela não pode estabelecer receita, contas ativas, usuários colombianos, ocupação de rack ou quantas pessoas seriam afetadas por uma falha.
O teste de falha deve operar no nível do prefixo e da instalação. Para cada prefixo de produção, um comprador deve perguntar quais roteadores o originam, em quais prédios, por meio de quais operadoras contratadas e entradas físicas. Deve perguntar se o segundo upstream permanece acessível após remover o primeiro roteador, primeiro cross-connect, primeira sala de meet-me, primeiro duto e primeiro provedor metropolitano. Também deve perguntar se o tráfego de saída e entrada falha, como a segurança de rota é mantida e quanta largura de banda permanece no caminho sobrevivente.
O BGP público pode verificar se uma rota é vista. Um traceroute pode revelar um caminho observado em um momento. Nenhum pode provar separação subterrânea. A evidência ausente é um diagrama de rota física atual, cartas de operadora identificando infraestrutura comum, entradas de prédio diversas, separação de roteador e energia, e um teste no qual o caminho primário é removido sob carga. Sem isso, "dois upstreams" é uma hipótese de resiliência útil, não um caminho de recuperação demonstrado.
A linguagem de backup muda conforme o produto muda
Os backups são onde as descrições públicas da TECNOWEB se tornam mais instrutivas. Elas não formam uma promessa universal. Elas formam várias promessas específicas do produto que podem proteger contra diferentes falhas e carregam diferentes responsabilidades do cliente.
Os termos de serviço fornecem a cautela controladora. Cópias automáticas existem apenas para planos que as incluem expressamente. VPS não gerenciados, servidores dedicados e planos de e-mail básicos podem não incluir backup automático. Mesmo quando o backup está incluído, os termos o chamam de complementar e dizem aos clientes para manter cópias independentes. A empresa se isenta de responsabilidade por perda de dados decorrente de software, hardware ou fabricantes de terceiros. Essa linguagem faz uma distinção clara entre um serviço de hospedagem e o próprio plano de continuidade do cliente.
A página da empresa faz a afirmação de infraestrutura mais ampla: backup incremental diário por meio de um sistema comercial para um data center externo em outro local físico. A página de revenda adiciona detalhes, dizendo que cópias diárias, semanais e mensais de contas de revenda são transferidas diariamente para um data center externo. A página Linux estreita a frequência por plano, com cópias semanais nos dois planos menores e cópias diárias nos dois planos maiores.
Essas declarações podem ser todas verdadeiras se descreverem produtos ou níveis de retenção diferentes, mas as páginas públicas não nomeiam o site externo, seu país, operador, distância, isolamento de armazenamento, criptografia, retenção ou desempenho de restauração.
A página de VPS diz que snapshots manuais estão incluídos, snapshots automatizados podem ser agendados e backup externo tem um custo adicional. Um snapshot armazenado no mesmo sistema de armazenamento ou na mesma instalação é valioso para reverter um erro de configuração; pode não sobreviver à perda da matriz de armazenamento, credenciais, conta ou prédio. Uma cópia externa pode sobreviver ao site, mas ainda ser inutilizável se a rede de backup, chaves de criptografia, catálogo ou host de restauração compartilhar a mesma falha. A página não publica esses limites.
A página de servidores dedicados recomenda comprar um disco adicional e fazer com que os técnicos o configurem para cópias. Um segundo disco pode proteger contra falha do disco primário. Se estiver dentro do mesmo chassi, não protege contra falha do controlador, danos elétricos, roubo, incêndio ou uma ação destrutiva que atinja ambos os dispositivos. É, portanto, um componente de recuperação local, não uma prova de recuperação de desastre no nível do site.
O e-mail adiciona outra inconsistência no escopo. A página mais recente de e-mail empresarial anuncia 99,9% de disponibilidade em uma plataforma Open-Xchange. A página mais antiga para PME usa frases mais fortes sobre perda zero de dados, backup e 100% de disponibilidade de rede. Os termos de serviço, no entanto, dizem que o e-mail básico pode não ter backup automático, a menos que seja expressamente declarado. Um cliente deve confiar no pedido e no cronograma do produto que identifica seu plano real, não combinar a frase mais forte de cada página de marketing.
Um compromisso de backup útil tem quatro números e três limites. Os números são frequência de backup, retenção, objetivo de ponto de recuperação e objetivo de tempo de recuperação. Os limites são a falha de produção que ele foi projetado para sobreviver, as credenciais administrativas ou conta que o separam da produção e a jurisdição física na qual a cópia reside. O material público da TECNOWEB dá fragmentos — diário, semanal, mensal, incremental, externo — mas não a combinação completa para cada produto.
O caminho de recuperação também precisa de capacidade. Restaurar um VPS de 300 GB requer armazenamento limpo e computação para executá-lo. Reconstruir um servidor dedicado requer hardware compatível, licenças e pessoal. Mover contas compartilhadas requer nós sobressalentes, mudanças de DNS e acesso ao painel de controle. Uma cópia pode estar intacta enquanto o serviço permanece indisponível porque o destino está cheio ou a rede está inativa. O armazenamento de backup instalado e a capacidade de recuperação utilizável não são a mesma coisa.
A evidência necessária para fechar essa lacuna é prática: um cronograma de backup específico do produto, região de backup nomeada, prova de credenciais separadas, resultados recentes de teste de restauração, velocidade de restauração medida e confirmação de que a computação de destino está reservada. O teste mais importante começa com uma instância de produção destruída e termina quando um cliente pode usar o aplicativo e verificar os dados — não quando um trabalho de backup relata sucesso.
O painel de controle e a central de suporte também são infraestrutura
Para muitos clientes, o painel de controle de varejo é a única infraestrutura visível. Ele provisiona um serviço, expõe cobrança, abre tickets, altera DNS, cria caixas postais, reinicia uma máquina virtual e apresenta controles de backup. Quando falha, o servidor subjacente pode ainda estar em execução, mas a capacidade do cliente de diagnosticar ou recuperar pode desaparecer.
A TECNOWEB opera um portal de suporte público que aceita tickets e permite que um usuário verifique o status do ticket. Suas páginas prometem assistência 24 horas, enquanto os termos dizem que o suporte está disponível através do portal do cliente. O material público não informa se existe um caminho telefônico de emergência separado quando o portal ou sistema de autenticação do cliente está indisponível, ou se a interface de suporte está hospedada fora do ambiente de produção que suporta. Essa é uma pergunta de modo comum: uma página de status e sistema de tickets são mais úteis quando sobrevivem ao incidente.
Diferentes serviços adicionam diferentes superfícies administrativas. Clientes Linux dependem de cPanel; clientes de revenda usam WHM; clientes Windows usam Plesk; clientes VPS usam controles baseados em Proxmox e noVNC; clientes WordPress usam um kit de ferramentas de aplicativo. Uma falha no plano de controle pode bloquear redefinições de senha, snapshots, reinstalações, alterações de firewall e migrações sem tornar todos os aplicativos hospedados inacessíveis. Os relatórios de disponibilidade devem distinguir tráfego do cliente de acesso administrativo.
A cadeia de dependências vai além da hospedagem. A página de domínios da TECNOWEB vende serviços de registro e DNS, enquanto os termos descrevem a empresa como intermediária perante os registros. Um servidor válido pode desaparecer do uso comum se um domínio expirar, a delegação mudar ou o DNS autoritativo falhar. Os certificados SSL adicionam autoridades de certificação e automação de renovação. O SiteLock adiciona um serviço de segurança externo. A oferta DMARC é apresentada em torno da Valimail, e os certificados BIMI dependem de ecossistemas de verificação de marca e certificado.
Nenhuma dessas dependências é reparada pela substituição de um disco de servidor com falha.
As ofertas do Google e da Microsoft tornam a divisão de responsabilidades ainda mais clara. A TECNOWEB pode ajudar a configurar, transferir e apoiar uma assinatura, mas não pode restaurar independentemente um serviço global do Gmail, Exchange Online, Teams ou OneDrive. Por outro lado, uma interrupção no próprio portal da TECNOWEB não deve necessariamente derrubar essas plataformas upstream. Um cliente que compra "um provedor, um suporte" precisa de um caminho de escalonamento que sobreviva aos limites entre vendedor, operador de plataforma, registro, autoridade de certificação e operadora de rede.
O trabalho humano é o plano de controle final. Um ciclo de energia remoto é rápido; diagnosticar um sistema de arquivos corrompido, controlador RAID com falha ou conta comprometida não é. Uma substituição física requer um técnico com acesso, peça compatível e autoridade para agir. Uma mudança de rota requer pessoal de rede. Uma restauração requer alguém que entenda a carga de trabalho e possa validá-la. Um rótulo 24 horas diz quando um canal está aberto, não quantas pessoas qualificadas estão disponíveis, como os incidentes são priorizados ou quanto tempo uma peça leva para chegar ao rack.
A cláusula de 48 horas torna esses detalhes operacionais centrais. Os compradores devem perguntar sobre definições de gravidade, metas de reconhecimento, contatos de escalonamento, intervalos de atualização, disponibilidade de mão remota, política de peças de reposição e um canal alternativo fora do portal normal. Eles também devem perguntar se o monitoramento abre incidentes automaticamente. Uma garantia medida apenas após a notificação do cliente pode perder minutos ou horas preciosos antes do relógio formal do provedor começar.
Uma falha pode atingir empresas que nunca compraram um servidor
As pessoas afetadas por uma falha de hospedagem são mais amplas do que a lista de contas. Um cliente de hospedagem compartilhada pode ser um pequeno varejista cujo checkout e e-mail comercial usam o mesmo domínio. Um VPS pode executar um sistema de planejamento de recursos empresariais, banco de dados, serviço de reservas ou interface de aplicativo. Um servidor dedicado pode carregar várias unidades de negócios. Um revendedor pode colocar dezenas de organizações downstream em uma única alocação. Uma agência pode gerenciar sites para clientes que não têm relacionamento direto com o provedor de infraestrutura.
O catálogo da TECNOWEB tem como alvo explícito indivíduos, pequenas e médias empresas, grandes empresas, comércio eletrônico, bancos de dados, aplicativos empresariais e revendedores. Sua página inicial afirma mais de 10.000 clientes colombianos e mais de 20.000 domínios gerenciados. Esses são números de marketing de primeira parte sem uma definição de cliente datada ou auditoria anexada. A contagem de domínios observada pelo IPinfo diz respeito a domínios vistos em endereços AS64114, não a todos os clientes, todos os produtos ou todos os domínios sob gestão. Os dois números medem coisas diferentes e não devem ser forçados a concordar.
O mecanismo de impacto também muda por camada. A perda de um servidor compartilhado afeta as contas colocadas nele, não necessariamente a frota. A perda de um sistema de armazenamento pode afetar vários hosts. A perda de um switch de topo de rack pode isolar um gabinete. A perda de energia ou refrigeração da instalação pode afetar a sala. A perda de uma rota upstream comum pode afetar servidores de outra forma saudáveis. A perda de DNS pode fazer muitos aplicativos separados parecerem inativos. A perda do portal de suporte pode atrasar a recuperação em todos os produtos.
Os clientes carregam parte desse impacto. Um proprietário de VPS não gerenciado controla o sistema operacional e o aplicativo. Um revendedor controla a comunicação downstream. Um titular de domínio deve manter os dados de registro e renovação. Uma empresa deve decidir se mantém uma cópia independente e um serviço secundário. Os termos da TECNOWEB tornam vários desses deveres explícitos. Mas a responsabilidade do cliente não remove a obrigação do provedor de tornar seus próprios limites inteligíveis.
Nenhuma evidência pública suporta um número preciso de usuários que seriam afetados por uma falha de rack, prefixo ou instalação. Contagens de domínio não são usuários; clientes anunciados não são cargas de trabalho simultâneas; espaço de endereço não é ocupação. A avaliação correta é qualitativa: a superfície do serviço é ampla, os revendedores amplificam as dependências e as pequenas empresas podem concentrar web, e-mail, DNS e suporte com uma única marca. Essa concentração pode transformar uma falha técnica local em uma interrupção comercial, mesmo quando o provedor subjacente é modesto em tamanho.
A localidade dos dados não pode ser inferida de uma vitrine colombiana
O contrato de serviço é colombiano, mas o caminho físico e legal dos dados do cliente permanece incompletamente descrito. A política de privacidade da TECNOWEB diz que as informações pessoais fornecidas pelos usuários são processadas confidencialmente, usadas para melhorar os serviços e não divulgadas a terceiros sem consentimento, exceto quando exigido por autoridade. Ela não identifica países de hospedagem, países de backup, operadores de infraestrutura, subprocessadores, períodos de retenção para conteúdo hospedado ou os locais usados por cada produto.
A Lei 1581 de 2012 da Colômbia rege o processamento de dados pessoais e aborda transferências para terceiros países. A presença da lei colombiana não impõe uma conclusão aqui sobre qualquer carga de trabalho específica do cliente. Ela torna a localização e a alocação de papéis comercialmente importantes para clientes que armazenam dados pessoais. Eles precisam saber se a TECNOWEB atua como processadora, se outra empresa regional ou provedora de plataforma participa e onde as cópias de produção e backup são tratadas.
O catálogo de produtos já mostra que uma resposta não pode cobrir todos os serviços. Google Workspace e Microsoft 365 usam suas respectivas plataformas globais. O e-mail Open-Xchange introduz outro limite de plataforma. O registro de domínio envolve registros e registradores. Os produtos de segurança envolvem seus fornecedores. A hospedagem compartilhada, VPS e servidores dedicados operados pela TECNOWEB podem seguir um padrão de localização diferente. Os termos referem-se a links nacionais e internacionais e a fabricantes externos, enquanto a página da empresa coloca DNS em quatro países e backup em uma instalação externa não nomeada.
Nada disso prova uma transferência ilegal ou uma falha de proteção. Isso prova que um rótulo colombiano é evidência insuficiente de residência de dados. O registro LACNIC identifica um detentor de recurso; a geolocalização de IP é probabilística; uma moeda de faturamento identifica um mercado; um contrato identifica a lei aplicada. Apenas um cronograma de serviço, registro de arquitetura e lista de subprocessadores podem identificar onde o conteúdo, metadados, logs e cópias de um cliente realmente vão.
Um comprador com requisitos de localidade deve perguntar sobre países de produção e backup, o operador legal em cada lugar, termos de transferência transfronteiriça, propriedade de criptografia, jurisdições de acesso e comportamento de exclusão após cancelamento. Deve perguntar se o pessoal de suporte em outros países pode acessar dados ou consoles e se uma migração muda o local. Essas respostas devem ser específicas do produto e incorporadas ao contrato. Uma garantia verbal de que o serviço é "para a Colômbia" não é o mesmo que um compromisso de residência.
O caminho de recuperação deve ser testado desde a perda de energia até o uso do cliente
Um teste de resiliência útil começa com uma falha específica. Imagine que o caminho de energia que atende um gabinete de produção seja perdido. A energia armazenada deve carregar a carga enquanto um gerador ou caminho alternativo se torna disponível. A refrigeração deve continuar. O console remoto e o gerenciador de energia devem permanecer acessíveis. Se um servidor falhar, o hardware saudável precisa de RAM, CPU, armazenamento, rede e licenças suficientes para aceitar sua carga de trabalho. Se o armazenamento for danificado, uma cópia limpa deve estar disponível fora do domínio com falha.
Se a rota primária for perdida, um caminho fisicamente independente deve carregar o prefixo. Se o painel de controle estiver indisponível, a equipe precisa de outra maneira de agir. O serviço é restaurado apenas quando o cliente pode usá-lo e verificar seus dados.
O material público da TECNOWEB suporta partes dessa sequência: servidores próprios, RAID, interfaces de 10 Gbps, gabinetes exclusivos, controles remotos, monitoramento, dois upstreams observados, alegações de cópia externa, snapshots, suporte por ticket e uma porcentagem de disponibilidade contratual. Ele não publica um teste completo de ponta a ponta que remova um caminho de energia, host, serviço de armazenamento ou upstream e demonstre a recuperação do cliente sob carga representativa.
O primeiro pedido deve ser, portanto, um cronograma de instalações nomeado. Ele deve identificar o prédio de produção e o prédio de backup, seus operadores, países e certificações aplicáveis. Ele deve mostrar quais produtos estão colocados em cada site. Se "Tier III" fizer parte da venda, o cliente deve receber o certificado atual, o escopo exato avaliado e a confirmação de que seu rack, energia e caminhos de refrigeração estão dentro dele.
O segundo pedido deve reconciliar a capacidade. Para hospedagem compartilhada e VPS, os compradores precisam de arquitetura de host e cluster, regras de posicionamento, recursos comprometidos, política de oversubscription e capacidade sobressalente após a falha do maior host ou armazenamento. Clientes dedicados precisam de inventário, compromissos de peças de reposição e uma opção de migração. As evidências de rede devem identificar a capacidade paga e a largura de banda disponível após a remoção de um upstream. Nenhum desses valores deve ser inferido de uma classificação NIC ou cota de transferência de varejo.
O terceiro pedido deve mapear dependências de modo comum. Um diagrama físico deve mostrar entradas de utilidades, energia ininterrupta, geração, refrigeração, alimentações de gabinete, roteadores, entradas de operadora e caminhos externos. Para diversidade de rede, os nomes das operadoras não são suficientes: os caminhos, entradas, salas de meet-me, roteadores e alimentações de energia precisam de separação. Para backup, "externo" deve ser substituído por um país, instalação, limite de credencial, cronograma de retenção e resultado de restauração medido.
O quarto pedido deve transformar o número 99,9% em um compromisso de serviço completo. Ele deve definir o ponto de medição, intervalo, exclusões, tratamento de manutenção, início do incidente, gravidade, reconhecimento, metas de atualização e restauração, créditos de serviço e direitos de rescisão. Ele deve esclarecer se a linguagem de 48 horas é um compromisso de resolução externa, o que significa restauração temporária e como um limite anual perdido é remediado.
O quinto pedido deve testar pessoas e comunicação. Os clientes devem ver um caminho de escalonamento fora do horário comercial que não depende apenas do portal comum, uma política de peças de reposição, cobertura de mão remota e um canal de status hospedado fora dos sistemas afetados. Um exercício deve incluir TECNOWEB, o operador da instalação, provedores de rede e o cliente. Ele deve terminar com validação de aplicativo e dados, não apenas um alarme de infraestrutura verde.
O registro público suporta uma empresa colombiana de hospedagem em operação, um catálogo de serviços atual, recursos numéricos ativos e uma rede lógica com mais de um upstream observado. Ele não suporta uma localização exata de rack, rotas de fibra colombianas independentes, totais de frota, capacidade sobressalente atual, uma jurisdição de backup nomeada ou um tempo de recuperação medido. É por isso que o fato mais forte na oferta da TECNOWEB também é a melhor pergunta de abertura: 99,9% pode ser calculado ao segundo, enquanto o sistema físico que deve entregá-lo ainda é descrito sem um nome.