Sazonalidade de carga: como preparar a TI para picos de black friday, fechamento e safra

Por que a sazonalidade derruba uma TI que funciona o ano inteiro

Existe um paradoxo conhecido de quem administra infraestrutura: o ambiente que passou onze meses estável, sem um único chamado crítico, é exatamente o que cai na sexta-feira da Black Friday, no dia do fechamento contábil ou no primeiro carregamento da safra. Não é azar nem coincidência. É que o dimensionamento da TI, na maioria das empresas, foi feito para a média — e a média é uma medida que esconde justamente o momento em que o negócio mais depende do sistema.

Quando o volume transacional triplica em poucas horas, cada componente da cadeia revela seu gargalo real. O banco de dados que respondia em 40 ms começa a acumular locks; o pool de conexões da aplicação satura; o link de internet, que parecia folgado a 30% de uso, chega a 95% e passa a descartar pacotes; o storage atinge o limite de IOPS e a latência de disco sobe de 2 ms para 80 ms. Nenhum desses elementos "quebrou" no sentido tradicional. Todos continuam funcionando — apenas devagar demais para serem úteis. E lentidão, do ponto de vista do usuário e do cliente final, é indistinguível de indisponibilidade.

O agravante é que picos sazonais concentram receita. Um varejista pode faturar em quatro dias de Black Friday o equivalente a um mês normal. Uma indústria de alimentos vive da janela de safra, que não espera. Um escritório contábil tem prazos legais que não se movem. O custo de uma hora parada nesses períodos não é proporcional ao custo de uma hora parada em uma terça-feira de março — é várias ordens de grandeza maior, e inclui multa, perda de contrato e dano de reputação.

Mapear os picos antes de dimensionar qualquer coisa

O primeiro erro de quem se prepara para sazonalidade é comprar capacidade sem saber do que precisa. Antes de qualquer investimento, é preciso responder a três perguntas com dados, não com percepção: quando o pico acontece, qual a sua amplitude e qual recurso satura primeiro.

Isso exige histórico. Um monitoramento que guarda apenas sete dias de métricas é inútil para planejamento sazonal — o ciclo que interessa tem doze meses. O ideal é manter, no mínimo, treze meses de séries temporais de CPU, memória, IOPS, latência de disco, throughput de rede, sessões concorrentes, tempo de resposta da aplicação e fila de mensagens. Com esse histórico, o pico do ano anterior deixa de ser lembrança e vira baseline mensurável.

Um roteiro prático de mapeamento:

1. Levantar o calendário de negócio com as áreas, não com a TI. Comercial, financeiro, logística e operação sabem de datas que não estão em lugar nenhum do datacenter: campanha promocional, virada de exercício fiscal, entrega de obrigação acessória, início de colheita, inventário anual.
2. Cruzar o calendário com as séries históricas. Sobrepor as datas às métricas revela a amplitude real. "Dobra o acesso" quase nunca é verdade — costuma ser 4x em imagens, 1,3x em banco e 8x em uma fila específica.
3. Identificar o recurso limitante de cada rota crítica. Em checkout costuma ser banco; em emissão fiscal, o serviço externo da SEFAZ; em fechamento contábil, IOPS de disco e memória de relatório; em safra, conectividade de campo e sincronização de dados.
4. Definir o headroom-alvo. A regra prática de mercado é operar o pico projetado com no máximo 70% de utilização dos recursos críticos, deixando 30% de margem para o inesperado.
5. Projetar o crescimento sobre o pico anterior, não sobre a média atual. Se o negócio cresceu 25% no ano, o pico deste ano tende a ser o pico anterior mais 25% — e não a média de hoje mais 25%.

Capacidade não se planeja pela média de uso. Planeja-se pelo percentil 95 do período crítico, com margem de folga — porque é nesse percentil que o negócio ganha ou perde o ano.

Planejamento de capacidade: dimensionar para o pico sem pagar pelo vale

Uma vez conhecida a amplitude do pico, surge a questão econômica: comprar infraestrutura para o dia mais movimentado do ano significa deixar recurso ocioso nos outros 360. Foi exatamente esse dilema que a computação elástica veio resolver, e é aqui que a arquitetura escolhida faz diferença de dezenas de milhares de reais.

Na prática, a resposta madura é híbrida. A carga de base — o volume estável que existe todo dia — fica em recurso reservado, contratado por período longo, com custo unitário mais baixo. A carga variável do pico é atendida por recurso elástico, provisionado dias antes e devolvido depois. Esse modelo evita tanto o desperdício de superdimensionar permanentemente quanto o risco de depender exclusivamente de escalonamento automático em um momento em que não há tempo para ajustar parâmetros.

Os principais eixos de dimensionamento a revisar antes de cada temporada:

• Computação: vCPU e memória por serviço, com atenção ao limite de conexões do banco — aumentar aplicação sem aumentar o pool do banco só transfere a fila de lugar.
• Armazenamento: IOPS provisionados e latência garantida. Em fechamento contábil e geração de relatórios, disco costuma ser o gargalo antes da CPU.
• Rede: banda de saída, link redundante de operadora distinta e, no caso de e-commerce, CDN para descolar tráfego estático da origem.
• Licenciamento: muitos ERPs e bancos licenciam por core ou por usuário nomeado. Escalar sem checar licença gera problema jurídico no pior momento possível.
• Backup e janela de retenção: volume maior de transação significa backup maior e janela mais longa. Se a janela invadir o horário produtivo, o backup vira concorrente da operação.
• Serviços de terceiros: gateway de pagamento, ERP em nuvem, transportadora e órgão fiscal têm limites de requisição. Vale confirmar o teto contratado antes de bater nele.

Vale registrar um ponto frequentemente ignorado: escalar horizontalmente só funciona se a aplicação for preparada para isso. Sistemas que guardam sessão em memória local, gravam arquivo em disco do próprio servidor ou dependem de job agendado singleton não ganham nada com uma segunda instância — ganham inconsistência. Descobrir isso no dia do pico é caro. Descobrir em setembro é apenas trabalho.

Escalonamento na prática: da nuvem elástica ao legado que não escala

Nem todo ambiente é elástico, e fingir que é gera falsa segurança. Um ERP monolítico rodando em servidor físico com banco local não escala horizontalmente por decreto. Para esses casos, o caminho é escalonamento vertical planejado — aumentar CPU, memória e IOPS da máquina antes da temporada — combinado com otimização, que costuma render mais que hardware: revisar índices de banco, reescrever consultas que fazem varredura completa de tabela, arquivar dados históricos que inflam tabelas quentes e mover relatórios pesados para réplica de leitura.

Para ambientes já virtualizados ou em nuvem, algumas medidas têm alto retorno e baixo risco:

• Congelar mudanças a partir de uma data definida — tipicamente duas a três semanas antes do pico. Nada de atualização de versão, migração ou troca de firmware dentro da janela crítica.
• Testar a carga antes, com volume real. Teste de carga simulando o pico projetado mais 30% é a única forma de saber onde o sistema quebra sem descobrir ao vivo.
• Pré-aquecer caches e réplicas, já que cache frio no primeiro minuto de campanha derruba a origem exatamente quando ela está mais exposta.
• Definir degradação graciosa: decidir de antemão o que pode ser desligado para preservar o essencial — recomendação personalizada, relatório em tempo real, integração não crítica. Melhor um site funcionando sem "quem viu também viu" do que um site fora do ar.
• Validar o rollback. Todo plano precisa de caminho de volta testado, não apenas documentado.

Igualmente importante é revisar a resiliência, não só a capacidade. Pico de carga aumenta a probabilidade de falha de componente simplesmente porque tudo está trabalhando no limite térmico e de throughput. Fonte redundante, RAID em estado íntegro, nobreak com bateria testada sob carga, link secundário com failover validado e backup restaurado — restaurado, não apenas concluído — deixam de ser boas práticas e passam a ser pré-requisito.

Plantão, runbook e comunicação: o lado humano do pico

Infraestrutura dimensionada sem plantão organizado ainda falha. O período de pico exige um modelo de operação diferente do cotidiano, com papéis explícitos e canais definidos antes do primeiro incidente.

Um plantão sazonal bem montado tem escala nominal com nomes, horários e contatos alternativos; um responsável técnico de decisão por turno, com autoridade para acionar rollback ou degradação sem esperar aprovação em cadeia; janela de resposta acordada e comunicada às áreas de negócio; e um canal único de incidente, para que a informação não se fragmente entre grupos de mensagem, telefone e e-mail.

O runbook é o outro pilar. Ele não é documentação de arquitetura — é um conjunto de procedimentos executáveis sob pressão, escritos para quem está com sono às três da manhã. Deve conter, para cada cenário previsto, o sintoma observável, o comando ou passo exato de diagnóstico, a ação corretiva, o critério de escalonamento e o texto de comunicação ao negócio. Cenários mínimos: banco lento, fila acumulada, link caído, serviço externo indisponível, storage cheio, certificado expirado e falha de autenticação em massa.

Durante o pico, a métrica que importa não é apenas o uptime — é o tempo entre o problema começar e alguém com autoridade estar tomando decisão sobre ele.

Por fim, o pós-pico é parte do processo e quase sempre é o passo abandonado. Nas duas semanas seguintes, cabe reduzir a capacidade elástica contratada para não carregar custo desnecessário, revisar o que efetivamente saturou contra o que se previu que saturaria, registrar os incidentes com causa raiz e atualizar o runbook com o que se aprendeu. Esse registro é o insumo do planejamento do ano seguinte — e é o que transforma sazonalidade de sobressalto anual em rotina previsível.

Como a Duk conduz temporadas críticas de TI

A Duk Informática & Cloud acompanha ciclos sazonais de infraestrutura há mais de 18 anos, em mais de 550 empresas atendidas de varejo, indústria, serviços financeiros e agronegócio. Essa base dá algo que nenhum dimensionamento teórico oferece: histórico comparativo de como diferentes setores realmente se comportam sob pico, e onde cada arquitetura costuma quebrar primeiro.

O trabalho começa pelo mapeamento — calendário de negócio cruzado com métricas históricas de monitoramento — e avança para o plano de capacidade, com dimensionamento de computação, storage, rede e licenciamento, além da revisão de resiliência e de backup com teste de restauração. Na temporada, entram o congelamento de mudanças, o plantão estendido com SLA acordado e o runbook específico do cliente. Como Microsoft Gold Partner, a Duk também trata o lado de identidade, Microsoft 365 e cargas em nuvem, que costumam ser esquecidos no planejamento e aparecem como gargalo de autenticação ou de licença no pior momento.

Se a sua empresa tem uma data no calendário em que a TI não pode falhar — Black Friday, fechamento, safra, campanha ou prazo regulatório —, o momento de preparar é agora, com folga para testar. Fale com a Duk e monte o plano de capacidade e plantão da sua próxima temporada crítica.