Arrumar a rede em novembro é tarde

Todo ano a mesma sequência. Em novembro, alguém descobre que a rede não aguenta o pico de acesso — e aí não há mais o que fazer. As medidas que realmente resolvem levam semanas para ficar de pé. As que cabem em um dia são, quase sempre, as mesmas que derrubam tudo na hora errada.

Este texto é sobre a ordem das coisas. Outubro é o mês de mexer, medir e testar. Novembro é o mês de não mexer. Quem inverte essa ordem costuma pagar caro justamente no dia em que a operação não pode parar. E o mais desconfortável é que a conta quase nunca chega por causa do volume de acesso: chega por causa de uma alteração feita na véspera, com a melhor das intenções.

Por que a véspera derruba mais que o pico

Vale descrever o mecanismo na ordem em que ele acontece, porque ele se repete com uma regularidade quase chata. Primeiro, alguém enxerga um risco de última hora: um sistema desatualizado, um equipamento antigo, uma configuração que parece frouxa. Segundo, essa pessoa age bem — atualiza, troca, ajusta. Terceiro, a mudança entra sem teste, porque não sobrou tempo para testar. Quarto, ela funciona no dia seguinte, com pouca gente usando ao mesmo tempo. Quinto, ela quebra no dia do pico, quando todo mundo entra junto.

O passo seguinte é o pior. Na hora da queda, ninguém lembra da mudança. A equipe procura o problema onde ele costuma estar — no link, no servidor, na operadora — e não onde ele foi criado, dias antes, por alguém que talvez nem esteja de plantão. O tempo perdido procurando no lugar errado costuma ser maior que o do conserto.

A cena, do lado de fora, não tem nada de técnico. É a recepção com fila e o sistema de agendamento fora do ar. É o laudo que não abre na tela. É o cartão que não passa, com gente esperando atrás. É o prazo que vencia naquele dia e venceu mesmo assim. Nada disso aparece num gráfico de rede. Aparece na sala.

O que se faz em outubro

Outubro é trabalho técnico, e ele tem uma ordem própria.

Medir o pico do ano passado

Não o pico médio: o pior minuto. Quantos acessos simultâneos, quanto de banda, quanto o servidor subiu, o que ficou perto do limite. Se esse dado não existe, este é o motivo mais concreto para começar a guardá-lo agora — sem histórico, qualquer decisão de investimento vira palpite.

Testar com carga, não com fé

“Deve aguentar” não é um plano. Teste de carga é simular o volume esperado antes de ele acontecer, com o sistema real ligado. Ele quase sempre revela algo que ninguém previu: uma consulta lenta ao banco de dados, um limite de conexões simultâneas, um disco que satura. São coisas que o uso normal esconde, porque o uso normal é folgado.

Olhar o caminho inteiro

O gargalo raramente está onde se procura. Pode estar no link, no servidor, na aplicação, no banco de dados, no meio de pagamento ou na rede interna da loja — inclusive num cabo antigo ou num ponto de rede sem fio disputado por muita gente. Medir só a ponta que você já conhece é medir o lugar errado com precisão.

Ter um segundo caminho de internet — e testá-lo desligando o primeiro

Link redundante é um segundo acesso à internet, de operadora diferente, que assume quando o principal cai. Se nunca foi testado, é decoração. O teste é constrangedor de propósito: desliga-se o principal, em horário combinado e fora do movimento, e observa-se o que acontece. É comum descobrir que a troca demora, que parte dos sistemas não volta sozinha ou que o segundo link nunca esteve ligado de fato.

Restaurar a cópia de segurança

Não conferir se ela existe: restaurar. Num ambiente separado, abrindo o sistema, entrando na tela que a equipe usa todo dia e checando se os dados estão lá e se a data bate. Cópia que nunca foi restaurada é uma promessa. Só a restauração mostra em quanto tempo se volta ao normal.

Combinar quem faz o quê se cair

Uma folha com nomes, telefones e a ordem das ações vale mais que qualquer equipamento no dia em que acontece. Quem liga para a operadora, quem avisa o atendimento, quem decide parar de vender e quem decide voltar. Quase ninguém tem essa folha, e é a parte mais barata de tudo.

O que dá para conferir amanhã de manhã, sem gastar nada

Nem tudo depende de projeto e orçamento. Há verificações que qualquer gestor faz sozinho, com o que já tem em casa:

• Perguntar à equipe qual foi o pior travamento do último ano e o que foi feito na hora. A resposta costuma revelar o gargalo real melhor que qualquer relatório.
• Pedir para alguém abrir o sistema pelo celular, na rede de dados da operadora, fora do escritório. Se ficar lento só de fora, o problema não está na máquina de ninguém.
• Checar se existe um segundo link de internet e de qual operadora ele é. Dois links da mesma operadora, entrando pelo mesmo caminho, caem juntos.
• Pedir a data da última cópia de segurança e a data da última restauração testada. Costumam ser duas datas bem diferentes.
• Perguntar quem tem a senha de administrador dos sistemas críticos. Se a resposta for “só o fulano, que tira férias em novembro”, isso é risco de operação, não de tecnologia.

O que se faz em novembro: quase nada

Esta é a parte impopular. A partir de uma data combinada, congelam-se as mudanças: nada de atualizar sistema, trocar equipamento, mexer em configuração ou “aproveitar para melhorar já que estamos aqui”.

Não é preguiça nem superstição. É a observação repetida de que a maior parte das quedas de pico não vem do volume de acesso. Vem de uma alteração feita na véspera, sem tempo de ser testada e sem ninguém lembrando dela na hora do problema.

Congelar mudanças também muda a conversa interna: deixa de ser “a TI não quer fazer” e passa a ser “isso entra em dezembro, com teste”.

Se uma mudança for mesmo inevitável — uma falha de segurança séria, um equipamento dando sinal de que vai morrer —, ela entra com três coisas escritas: o que muda, como se volta atrás e quem autoriza. Escrever como voltar atrás é o item que mais salva: é ele que permite desfazer em minutos, no meio do problema, sem depender da memória de quem fez.

O dia: quem olha, o que olha e quem decide

No dia, alguém precisa estar olhando os números em tempo real, não a caixa de e-mail. É uma pessoa com a tela aberta e a atribuição clara de olhar — não alguém que vai reparar no problema quando o telefone tocar.

O alerta precisa estar configurado para o que importa: tempo de resposta e erro de transação, não só “o servidor está ligado”. Servidor ligado com sistema lento é o cenário mais comum e o mais invisível. No painel, está tudo bem. Na fila da recepção, está tudo parado.

E a decisão precisa estar tomada antes: a partir de que ponto se aciona o plano, quem tem autoridade para acionar e o que se diz ao cliente enquanto o problema não se resolve. Decidir isso no calor da hora é discutir a regra no meio do jogo.

A ressalva honesta

Nenhuma preparação faz uma operação parar de correr risco. O meio de pagamento é de terceiro, a operadora é de terceiro, e existe o imprevisto que não cabe em plano nenhum.

O que a preparação faz é outra coisa, e é bastante: reduz a chance de a queda acontecer, encurta o tempo até o retorno e tira o improviso do pior dia possível. A diferença entre ficar fora do ar por minutos e ficar fora por uma tarde inteira quase nunca está no equipamento. Está em ter combinado antes.

Se a sua operação depende de poucos dias no ano, a pergunta não é se a rede aguenta. É quando foi a última vez que alguém testou — desligando o link, restaurando a cópia, medindo o pior minuto.

A Ragnatela IoT Solutions trabalha com infraestrutura de TI, nuvem privada e cibersegurança, com atendimento remoto em todo o Brasil. Se você quer chegar em novembro com o teste feito e o plano escrito, converse com a gente ainda em outubro.