A sua loja online foi abaixo: plano de continuidade para saber o que fazer

Todas as lojas vão abaixo alguma vez. O servidor fica sem disco, uma atualização automática do alojamento muda a versão de PHP, um módulo falha depois de uma alteração, o domínio expira ou um ataque deixa o site inutilizável. O que distingue uma falha de uma hora de uma de um dia não costuma ser a gravidade do problema, mas sim o grau de preparação da equipa: se sabia como dar por isso, a quem ligar e o que fazer.

Um plano de continuidade não tem de ser um documento de cem páginas. Para uma loja online bastam uma ou duas folhas que respondam a algumas perguntas antes de serem precisas.

1. Como fica a saber

A pior forma de ficar a saber é por um cliente, e a segunda pior é no dia seguinte. Precisa, pelo menos, de:

• Uma monitorização externa que peça a página inicial e alguma página-chave de poucos em poucos minutos a partir de fora do seu servidor, e avise se não responder ou responder com erro. Tem de estar fora: se o servidor for abaixo, um vigilante dentro dele vai abaixo com ele.
• Avisos de erros a partir de dentro da loja, para as falhas que não deitam abaixo a página inicial mas partem alguma coisa: o checkout, o regresso de um gateway, uma página concreta.
• Avisos de expiração do domínio e do certificado SSL. São falhas totalmente evitáveis.

E decida quem recebe os avisos. Um aviso que chega a uma caixa de correio que ninguém lê à noite não serve de nada.

2. Que tipo de falha é

Os primeiros minutos servem para classificar, porque cada tipo tem o seu responsável:

• Nada responde (nem a loja nem outros sites do mesmo servidor): servidor, rede ou DNS. É com o alojamento ou com o fornecedor do domínio.
• Responde com erro 500 ou ecrã em branco: quase sempre uma falha de PHP na loja. Uma alteração recente, um módulo, a versão de PHP, o disco cheio ou a base de dados.
• Erro de base de dados: o servidor de base de dados está em baixo, saturado ou as credenciais mudaram.
• Funciona mas algo está mal: não se consegue pagar, não se adicionam produtos ao carrinho, a loja mostra conteúdo estranho. Pode ser uma falha de um módulo ou, no pior dos casos, uma intrusão.
• Funciona mas muito lenta: picos de tráfego, bots, uma tarefa pesada ou falta de recursos.

3. A quem liga

Escreva uma lista com nome, forma de contacto e horário para:

• O alojamento: número de cliente, como abrir um pedido urgente e o que cobre o seu suporte.
• O fornecedor do domínio e do DNS, se não for o mesmo do alojamento.
• Quem mantém a loja: o seu programador ou a empresa que lhe dá suporte.
• Os gateways de pagamento, caso o problema esteja neles ou precise de rever pagamentos.
• Quem decide dentro da sua equipa: se se restaura uma cópia, se a loja fica em manutenção, o que se comunica.

Guarde esta lista fora da loja e do correio do domínio. Se o servidor for abaixo e o seu correio estiver nele, não a poderá consultar.

4. Acessos e cópias, verificados antes

Em plena falha não é altura de descobrir que ninguém tem a palavra-passe do painel do alojamento ou que a última cópia é de há um mês. Verifique antecipadamente:

• Que as pessoas que têm de agir têm acesso ao painel do alojamento, ao FTP ou SSH, à base de dados e ao back-office.
• Que existem cópias de ficheiros e de base de dados recentes, guardadas fora do servidor da loja.
• Que alguém já restaurou uma cópia alguma vez e sabe quanto tempo demora. Uma cópia que nunca foi testada é uma esperança, não um plano.
• O que acontece às encomendas recebidas entre a última cópia e a falha se for preciso restaurar: onde consultá-las (gateway, e-mails de confirmação, ERP) e como recuperá-las.

5. O que faz enquanto se resolve

Manutenção com aviso

Se a loja responde mas falha, muitas vezes é melhor colocá-la em manutenção com uma mensagem clara do que deixar que os clientes encontrem erros ou, pior, que paguem e a encomenda não seja criada.

Pagamentos

Reveja no gateway os pagamentos do período afetado e compare-os com as encomendas. Os pagamentos sem encomenda têm de ser tratados um a um: criar a encomenda ou devolver o dinheiro.

Comunicação

• Aos clientes: uma mensagem breve nas redes ou no próprio aviso de manutenção, sem prometer horas que não pode cumprir.
• Aos clientes com encomendas em curso, se a falha afetar envios ou prazos.
• À equipa de apoio ao cliente, com o que responder se ligarem.

Se houver indícios de que entraram na loja e de que dados pessoais podem ter sido afetados, a situação muda: é preciso avaliar as obrigações de notificação do RGPD com quem o aconselha em proteção de dados, e não restaurar uma cópia sem antes fechar a via de entrada.

6. Depois: o que registar

Quando a loja volta, o trabalho não terminou. Registe:

• Quando começou, quando deu por isso e quando foi resolvida. A diferença entre as duas primeiras horas mede a sua monitorização.
• O que a causou e o que foi feito.
• O que faltou: um acesso, uma cópia, um telefone.
• O que muda para que não se repita: uma atualização pendente, mais disco, um módulo a retirar, uma monitorização a acrescentar.

Muitas falhas repetem-se porque ninguém regista a causa. E muitas evitam-se com o de sempre: loja, PHP e módulos em dia, testados numa cópia antes de os mudar em produção.

Como resolver no PrestaShop

O RKR Sentinel vigia a loja a partir de dentro e avisa-o por Telegram de erros de PHP, exceções, erros fatais, memória esgotada, tempos esgotados e respostas 500, com a mensagem, o ficheiro e a linha, o URL e as versões; também captura os erros de JavaScript do checkout e vigia os pagamentos que não acabam em encomenda ou cujo montante não bate certo. Agrupa as repetições para não lhe encher o telemóvel e mascara cartões, IBAN, tokens e palavras-passe antes de enviar o que quer que seja. Lembre-se de que precisa que a loja responda: para as falhas completas do servidor, combine-o com uma monitorização externa. E se procura um alojamento pensado para PrestaShop, o Hosting plan profesional da Rekire é a nossa proposta para lojas que querem deixar de se preocupar com o servidor.