Como funciona hospedagem de ERP de provedor: etapas para gestores

Resumo

• O ambiente tem camadas, e o banco de dados é a que guarda o que importa, como cadastros, títulos e pagamentos.
• Antes de desenhar, o gestor decide quanto de lançamentos aceita perder e em quanto tempo o sistema precisa voltar.
• A troca acontece numa janela curta, com testes de cobrança, ativação e liberação antes de a equipe voltar a usar.
• A entrega só fecha com uma restauração testada, cronometrada e comparada com o banco original.

Como funciona hospedagem de ERP de provedor: as camadas do ambiente

O ERP roda sobre camadas que dependem umas das outras, do servidor físico ao acesso da equipe. Hospedar bem é saber o que acontece quando cada uma falha e deixar uma proteção pronta para ela.

O ERP é o sistema de gestão do provedor: guarda cadastro, contratos, boletos e notas e, em muitos casos, informa ao servidor de autenticação quem pode navegar. Na hospedagem de ERP de provedor, a Táquion Tech monta e mantém o ambiente em servidor do próprio provedor, no escritório, no POP ou num data center contratado por ele.

Camadas do ambiente que hospeda o ERP do provedor e o que protege cada uma

Camada	O que é	Se falhar	Proteção usual
Servidor e energia	O computador físico, o nobreak e a sala	Tudo para ao mesmo tempo	Segundo servidor, nobreak e sala climatizada
Máquina virtual	Um computador simulado dentro do servidor, que pode mudar de servidor	O sistema para até subir em outro lugar	Cluster que liga a máquina em outro servidor
Aplicação do ERP	O programa do fornecedor, instalado e licenciado	Telas param, mas os dados ficam	Reinstalação guiada pelo fornecedor
Banco de dados	Onde ficam cadastros, títulos e pagamentos	Lançamentos perdidos ou corrompidos	Cópias frequentes, uma delas fora do local
Acesso	Por onde a equipe e as integrações chegam ao sistema	Invasão ou equipe sem acesso	VPN e lista de origens liberadas
Monitoramento	Alertas de disco, memória e serviço	Falha descoberta só quando alguém reclama	Alerta antes de o disco encher

A tabela mostra por que copiar a pasta do programa não basta: a aplicação se reinstala, mas o banco de dados não se recria. Quem já passou por um ataque sabe disso, e o guia sobre o provedor invadido mostra os primeiros passos quando o sistema de gestão é atingido.

Três jeitos de copiar o banco de dados

O jeito de copiar define quanto se perde numa falha. Ambientes bem montados costumam combinar dois deles, de acordo com o banco que o ERP usa [CONFIRMAR com o fornecedor do ERP].

• Cópia completa agendada: o banco inteiro é salvo num arquivo em horários fixos. Simples, mas tudo o que entrou depois da última cópia se perde.
• Cópia contínua do registro de transações: cada alteração é guardada à medida que acontece, e o banco pode voltar a um minuto escolhido.
• Réplica em outro servidor: um segundo banco recebe as alterações quase na hora e assume se o principal parar.

A réplica não substitui a cópia. Se alguém apagar um cadastro por engano ou um vírus embaralhar os dados, a réplica repete o estrago em segundos; só uma cópia guardada à parte devolve o estado anterior.

Quanto aceitar perder e em quanto tempo voltar?

Essas duas perguntas, chamadas em inglês de RPO e RTO, desenham o ambiente inteiro. O RPO é quanto tempo de lançamentos o provedor aceita refazer à mão; o RTO é por quanto tempo ele aguenta sem cobrar, ativar nem liberar clientes.

Um RPO de uma hora pede cópia pelo menos de hora em hora, e um RTO de minutos pede um servidor reserva já ligado. A hospedagem de ERP de provedor exige essas duas respostas por escrito antes de qualquer escolha de local ou de equipamento.

Como funciona cada etapa da hospedagem de ERP de provedor

São cinco etapas, e só a quarta mexe no sistema que a equipe usa. Até lá, todo o trabalho acontece numa cópia, e o servidor antigo segue funcionando normalmente.

1. 1 · Curta

   Levantamento

   Qual ERP e qual banco, tamanho dos dados, integrações com RADIUS, banco e notas, e os dias de cobrança.

2. 2 · Curta

   Desenho do ambiente

   Local, máquina virtual, rotina de cópias, regra de acesso e o que fazer quando o servidor falhar.

3. 3 · A mais longa

   Cópia de teste

   O banco é copiado para o ambiente novo e conferido pela equipe e pelo fornecedor do ERP, sem afetar o uso.

4. 4 · Uma noite

   Troca em janela

   Cópia final, endereço do sistema trocado e testes de cobrança, ativação e autenticação.

5. 5 · Curta

   Restauração e entrega

   Uma cópia é restaurada em ambiente separado, o tempo é medido e a documentação fica com o provedor.

A etapa 3 costuma ser a mais longa porque cada integração precisa responder no ambiente novo antes da noite da troca. O prazo em dias sai depois do levantamento [PREENCHER prazo típico da Táquion Tech].

Montagem e mensalidade de cada tipo de local estão comparadas no guia de quanto custa hospedagem de ERP de provedor. Aqui o assunto é o que acontece dentro de cada etapa.

O que o gestor separa antes do levantamento

O levantamento anda rápido quando estes itens já estão reunidos. Nenhum deles exige conhecimento técnico, só alguém que conheça a rotina do escritório.

Como é a noite da troca de ambiente?

A troca é uma sequência curta de passos, feita num horário em que ninguém usa o sistema. Cada passo tem um teste, e a equipe só volta a trabalhar quando todos passaram.

1. Aviso e bloqueio: a equipe é avisada, e o acesso ao ERP antigo é fechado para ninguém lançar nada durante a troca.
2. Cópia final: o banco é copiado pela última vez e levado ao ambiente novo, que já recebeu a cópia de teste dias antes.
3. Conferência dos números: total de clientes, de títulos em aberto e do último pagamento lançado precisam bater nos dois lados.
4. Troca do endereço: o nome ou o IP que a equipe e as integrações usam passa a apontar para o ambiente novo.
5. Testes de uso: emitir um boleto de teste, abrir uma ordem de serviço e confirmar que um assinante autentica pelo RADIUS.
6. Liberação: com os testes aprovados, a equipe volta a usar o sistema, e o servidor antigo fica desligado, mas intacto.

O servidor antigo intacto é o caminho de volta. Se algo aparecer nos primeiros dias, ele pode ser religado, desde que se saiba quais lançamentos foram feitos no ambiente novo nesse meio-tempo.

Quando um teste falha no meio da janela

A regra é decidida antes da noite: um teste reprovado que não se resolve em tempo combinado leva o endereço de volta ao servidor antigo. A equipe começa o dia seguinte no sistema de sempre, e a troca é remarcada.

O motivo mais comum é uma integração esquecida, como o emissor de notas que só aceita conexão de um endereço cadastrado. Ela entra na lista do levantamento para a próxima tentativa.

Restauração testada: a prova de que a cópia funciona

Restaurar é pegar uma cópia, subir o banco num ambiente separado e conferir se ele está completo. Só esse teste mostra se as cópias servem e quanto tempo o sistema leva para voltar.

Muita cópia nunca é aberta até o dia em que é necessária, e aí se descobre que estava incompleta. O teste da entrega segue um roteiro fixo, repetido depois com a frequência combinada.

• Escolha da cópia: pega-se uma cópia comum da rotina, e não uma feita especialmente para o teste.
• Ambiente separado: o banco sobe longe do sistema em uso, para o teste não afetar a operação.
• Cronômetro: mede-se o tempo do início até o sistema abrir, que é o RTO real do ambiente.
• Comparação: clientes, títulos e o último lançamento da cópia são comparados com o banco original.
• Relatório: tempo, resultado e problemas encontrados ficam registrados para o gestor.

De quanto em quanto tempo repetir o teste?

Depois da entrega, o teste se repete em calendário definido no projeto, e também a cada mudança grande, como versão nova do ERP. A frequência e quem executa ficam por escrito [CONFIRMAR oferta].

A política completa de cópias, com uma guardada fora do local, é tratada no backup de servidores, que costuma andar junto com a hospedagem.

Exemplo: do computador do escritório para uma máquina virtual no POP

Um caso de referência mostra a sequência inteira num provedor regional. Os detalhes são ilustrativos e servem para mostrar a ordem dos acontecimentos.

1. Ponto de partida: o ERP roda num computador comum no escritório, com uma cópia do banco por noite gravada no mesmo disco.
2. Levantamento: aparecem três integrações, o RADIUS, o banco para retorno de boletos e o emissor de notas, e o vencimento cai no dia 10.
3. Desenho: o gestor aceita perder no máximo uma hora de lançamentos. O ERP vai para uma máquina virtual no cluster do POP, com cópia de hora em hora e uma cópia diária no escritório.
4. Cópia de teste: o emissor de notas recusa o novo endereço; o fornecedor libera o cadastro antes da noite da troca.
5. Troca: numa madrugada de domingo, longe do dia 10, os números batem e os três testes passam.
6. Entrega: a restauração da cópia de hora em hora é cronometrada, e o gestor recebe o relatório e as senhas documentadas.

Quem ainda vai montar o cluster encontra o detalhe na virtualização com Proxmox. Se a troca de ERP também está nos planos, o guia de como funciona migração de ERP de provedor mostra por que vale fazer uma mudança de cada vez.

Erros comuns em cada etapa e o sinal de cada um

Cada etapa tem um erro típico, e quase todos deixam um sinal antes de causar prejuízo. A tabela ajuda o gestor a saber o que perguntar em cada momento.

Erros típicos da hospedagem de ERP de provedor, por etapa, e como se percebem

Etapa	Erro	Como se percebe
Levantamento	Esquecer uma integração	Retorno de boletos ou notas falhando no ambiente novo
Desenho	Guardar as cópias no mesmo servidor do ERP	Um único disco com defeito leva sistema e cópias
Cópia de teste	Não avisar o fornecedor do ERP	Licença recusada porque o servidor mudou
Troca em janela	Marcar a noite perto do vencimento	Boletos atrasados e equipe sem sistema no pior dia
Entrega	Nunca restaurar uma cópia	Cópias que parecem existir e não abrem

Outro erro atravessa todas as etapas: deixar a tela do ERP aberta para a internet. O acesso administrativo pode ficar numa rede de gerência isolada, separado do caminho que os assinantes usam.

O que o gestor recebe e o que passa a acompanhar

O gestor recebe o ambiente funcionando e os documentos para não depender de quem o montou. Depois disso, passa a acompanhar poucos números, que mostram se as cópias e o servidor continuam saudáveis.

• Desenho do ambiente: onde o ERP roda, onde ficam as cópias e o que acontece quando cada camada falha.
• Senhas e acessos: guardados em local combinado, sem depender da memória de uma pessoa.
• Relatório da restauração: tempo medido e números conferidos entre a cópia e o banco original.
• Regra de acesso: quem entra por VPN, de quais endereços e como incluir alguém novo.

No dia a dia, três números bastam: data da última cópia bem-sucedida, espaço livre em disco e data do último teste de restauração. Os dois primeiros podem chegar como alerta pela implantação de Zabbix, antes de virarem problema.

O ERP guarda dados pessoais de todos os assinantes, e a lei pede medidas para protegê-los contra acesso indevido e perda [CONFIRMAR na norma]. Acesso fechado e cópia testada fazem parte dessa proteção, e a parte jurídica fica na adequação à LGPD.

Perguntas frequentes

Fontes

1. Disaster recovery (Wikipédia em inglês): definições de RPO e RTO, as duas respostas que desenham o ambiente do ERP
2. Replication (computing) (Wikipédia em inglês): como a réplica do banco funciona e por que ela repete também os erros
3. Lei nº 13.709/2018, Lei Geral de Proteção de Dados (Planalto): dever de proteger os dados dos assinantes guardados no banco do ERP contra acesso indevido e perda