O sistema caiu de novo? As causas mais comuns e como evitar a próxima parada

Quando o sistema cai, a empresa para junto. Ninguém fatura, o estoque não anda, a equipe fica olhando para a tela e o cliente espera. O custo vai além da hora parada, porque depois vêm o retrabalho, a entrega atrasada e a conversa difícil com quem ficou sem atendimento.

A boa notícia é que a maioria das paradas avisa antes. O disco enche aos poucos, o certificado tem data para vencer, a memória sobe dia após dia. O problema costuma ser que ninguém estava olhando.

As causas que mais aparecem

Disco cheio

Log que ninguém limpa, cópia de backup guardada no próprio servidor, arquivo temporário esquecido e o próprio banco crescendo. Quando o disco enche, o banco para de gravar e o sistema para junto. É uma das quedas mais comuns e uma das mais fáceis de evitar, porque o disco leva semanas para encher. Já vimos uma transação esquecida aberta por mais de dois dias encher o log do banco, e uma integração gerar 55 GB de arquivos em três dias.

Certificado vencido

O certificado que protege o acesso pelo navegador tem data de validade. Quando ele vence, o navegador bloqueia a entrada e as integrações que dependem dele param de conversar com o sistema. O mesmo vale para o certificado digital usado na emissão de nota fiscal. Vencido, a nota não sai. Nos dois casos, a data é conhecida com meses de antecedência. Num cliente, quatro certificados de nota fiscal vencidos geravam mais de mil erros. Em outro, a renovação automática nunca tinha funcionado, e ninguém sabia.

Memória que vai acabando

Tem aplicação que perde um pouco de memória a cada dia até travar. Reiniciar resolve até a próxima vez, e a próxima vez costuma cair num dia de fechamento. O sinal aparece no gráfico de memória semanas antes.

Caso real. Num cliente, o sistema era reiniciado todo dia às 5h da manhã, por rotina. Olhando os registros, vimos que o servidor tinha derrubado a aplicação às 4h57 por falta de memória. O reinício das 5h escondia a queda.

Atualização sem teste e sem plano de volta

Atualizar o sistema operacional, o banco ou o próprio sistema no meio do expediente, sem testar antes e sem saber como desfazer, é pedir para parar. Atualização precisa acontecer, com janela combinada, teste e um caminho de volta. Já vimos um módulo atualizado com o sistema em uso estourar a memória da aplicação e deixar todo mundo 14 minutos parado. Os sinais tinham aparecido dias antes, mas os erros iam para um lugar que ninguém lia.

Serviço que não volta sozinho

Depois de uma queda de energia ou de uma manutenção do provedor de nuvem, o servidor liga, mas o sistema não sobe sozinho. Ele fica fora do ar até alguém perceber e iniciar na mão, às vezes só na segunda-feira.

A nuvem também falha

A nuvem reduz muito o risco de hardware, mas não zera. O que salva é ter alguém olhando e saber subir o ambiente de novo.

Caso real. Num domingo de manhã, uma manutenção programada do provedor de nuvem travou o servidor de um cliente, e a recuperação automática do próprio provedor também falhou. A máquina não aceitava mais nenhum comando. A equipe copiou os discos e subiu um servidor novo, sem perda de dados.

Conta da nuvem suspensa

Cartão vencido ou boleto esquecido, e o provedor suspende a conta. As máquinas param e, no dia seguinte, o backup começa a falhar. Num caso que atendemos, o único aviso era uma faixa no painel do provedor, que ninguém da empresa abria.

Tudo num lugar só

Um servidor com banco, aplicação e arquivos, um link de internet, uma pessoa que sabe a senha. Qualquer uma dessas peças falha e a empresa para. No servidor local entram também energia, no-break, ar-condicionado e disco envelhecendo sem ninguém ver.

O que separa uma parada de um susto

• Alerta antes do usuário perceber. Disco passando de 80%, certificado vencendo em 30 dias, memória crescendo, serviço parado. Cada um desses sinais avisa alguém a tempo de agir.
• Mudança com método. Teste antes, janela fora do expediente e plano de volta escrito.
• Serviço configurado para voltar sozinho, e testado, porque configuração que nunca foi testada pode falhar justo no dia.
• Acesso e documentação em ordem. Como reiniciar, quem chamar e onde estão as senhas, guardadas num cofre e ao alcance de mais de uma pessoa.
• Backup testado, porque às vezes a única saída é restaurar. Escrevemos sobre isso em como saber se o backup da empresa funciona.

Se caiu, o que fazer

1. Volte o sistema primeiro e investigue depois, mas guarde os registros do que aconteceu antes de reiniciar tudo.
2. Avise os usuários com uma previsão, mesmo que aproximada. Silêncio gera mais chamado.
3. Depois de resolver, responda três perguntas. O que falhou, por que ninguém foi avisado antes e o que muda para não repetir.

Como a Cloud Labs trabalha nisso

O monitoramento acompanha servidor, banco e aplicação 24 horas por dia e avisa quando algo sai do normal, antes de virar parada. Em horário comercial, incidente crítico tem resposta em até 3 horas. À noite, no fim de semana e no feriado, tem atendimento emergencial e programado, conforme contrato. Mudança no ambiente é planejada, testada antes e feita fora do horário comercial.