Era pouco depois das 2 a.m. quando meu telefone tocou. Na linha estava o líder de manutenção de um cliente 3PL, com a voz rouca: eles tinham acabado de concluir uma atualização do WCS, e agora os transportadores estavam mortos, dois transelevadores congelados no meio do corredor, e as tarefas de saída se acumulavam na tela. Uma vintena de pessoas estava em volta das correias sem nada para fazer, e duas ondas de caminhões estavam previstas antes do amanhecer. Perder uma e os pontos SLA das docas do cliente iam por água abaixo.
Eles tinham optado por uma atualização com parada total: desligar tudo, trocar tudo de uma vez, resolver logo. Acontece que a nova versão do WCS tinha uma incompatibilidade de handshake com os drivers PLC antigos, uma pequena diferença de versão que nunca apareceu no ambiente de testes porque o volume de dados era pequeno demais. Em produção, as comunicações explodiram imediatamente. Eles reverteram e apagaram incêndios até de manhã. Os caminhões fizeram fila, as penalidades caíram.
Depois daquela noite, virei regra para cada cliente: atualizações de WCS em produção sempre são progressivas. Nada mais de viradas de uma vez só. O que segue é o playbook completo.
Os números explicam por que ninguém ousa parar a linha. Os cálculos da indústria colocam o custo do tempo de inatividade não planejado em aproximadamente $10,000 por hora para um armazém de 750,000 pés quadrados. E os armazéns americanos são velhos: dados da CBRE mostram que edifícios com mais de dez anos representam 89% do estoque de armazéns nos EUA, com idade média de 34 anos. Edifícios velhos rodam sistemas velhos, e atualizações de WCS são inevitáveis. A única pergunta é se você as faz sem parar o negócio.
A noite anterior: snapshots e backups são a verdadeira atualização
O primeiro passo de uma atualização progressiva não é a atualização. É construir para si mesmo uma saída.
Três coisas acontecem na noite anterior. Primeiro, tire um snapshot completo do WCS: configuração do sistema, regras de agendamento de tarefas, mapeamentos de interfaces, versões dos programas PLC, tudo. Um WCS fica no meio de tudo, falando para cima com o WMS e o ERP e para baixo com os PLCs, transportadores e transelevadores. Uma incompatibilidade de versão em qualquer ponto dessa cadeia e a atualização produz fantasmas. O snapshot é a foto de família do seu sistema antes da cirurgia; quando algo quebra, você compara contra ela.
Segundo, um backup completo do banco de dados com um ponto de restauração definido. Só o backup não basta. Restaure-o uma vez no ambiente de testes e prove que funciona. Já vi tragédias demais onde o backup existia e a restauração não. Meio dia de exercícios de restauração pode salvar sua operação.
Terceiro, prepare dois pacotes: a atualização e o rollback. O pacote de rollback não é o instalador antigo. É um plano completo de reversão incluindo a lógica reversa de migração de dados. Se a nova versão muda o esquema do banco de dados, o rollback tem que devolver tanto o esquema quanto os dados ao estado pré-atualização. A maioria das equipes esquece isso na primeira vez.
Mais uma coisa: envie o plano de atualização ao gerente de operações do armazém com antecedência e explique a ele o que o negócio vai sentir em cada etapa. O plano técnico mais elegante do mundo não vai salvá-lo se as operações não souberem o que você está fazendo. Seu telefone vai tocar sem parar a noite inteira.
Noite da atualização: primeiro o standby, depois migre o tráfego aos poucos
Minhas noites de atualização seguem o mesmo cronograma toda vez.
Por volta das 10 p.m., quando o volume cai, atualize o standby. A maioria das instalações de WCS roda em ativo-standby. Leve o nó de standby à nova versão e faça um smoke test: uma tarefa real de entrada, uma de saída, uma contagem cíclica. Observe a cadeia inteira, despacho de tarefas, resposta dos equipamentos, callbacks de confirmação. Isso não toca em nenhum tráfego de produção, então os erros saem baratos.
Por volta das 11, com o smoke test verde, desvie uma fatia do tráfego. Escolha uma linha de transportadores não crítica ou um único corredor e direcione suas tarefas para o novo WCS. Mantenha a janela de observação em pelo menos uma onda completa de saída. Uma onda exercita o ciclo completo de liberação de pedidos, alocação de tarefas, execução dos equipamentos e tratamento de exceções. Uma onda limpa significa que os fundamentos da nova versão são sólidos. A versão antiga continua carregando o grosso do negócio; a nova é só um piloto.
Depois da meia-noite, expanda nó por nó. Termine um nó, mantenha um período de observação, confirme que as taxas de sucesso das tarefas e os tempos de resposta dos equipamentos não se degradaram, depois passe para o próximo. Nunca atualize vários nós em paralelo para economizar tempo. Se a nova versão tiver uma mina terrestre, as atualizações em paralelo a enterram sob cada nó de uma vez, e não há volta.
Na madrugada, quando o volume atinge o fundo, toque o núcleo por último: o núcleo de agendamento, o nó primário do banco de dados. Antes da troca, verifique mais uma vez se o pacote de rollback está pronto e se a pessoa que decide está na sala.
A noite inteira, alguém vigia o painel de monitoramento. Três números: tarefas em atraso, status de comunicação dos equipamentos, taxa de tarefas de exceção. No momento em que qualquer um deles der errado, pare. Diagnostique primeiro, depois decida se continua ou reverte.
Trace a linha de rollback antes de começar
Equipes demais tratam o rollback como improvisação depois de uma atualização fracassada. Não é. O rollback faz parte do plano de atualização, escrito antes de começar.
Quantifique os gatilhos e faça todos assinarem. Por exemplo: a taxa de tarefas de exceção sobe para várias vezes a linha de base normal, o atraso excede a capacidade de processamento de uma onda, ou um dispositivo crítico perde a comunicação além dos minutos acordados. Atingiu qualquer um deles e você reverte, sem reunião, sem debate. A frase mais perigosa em uma atualização é "vamos observar mais dez minutos". Dez minutos depois o problema é maior.
Nomeie exatamente uma pessoa para decidir o rollback. Normalmente o líder de manutenção ou o gerente do turno da noite de plantão. Quando ele diz para reverter, você reverte. Discuta isso no post-mortem, não às 3 a.m.
Ensine o rollback de ponta a ponta no ambiente de testes pelo menos uma vez, e cronometre. Esse número define sua janela de manutenção: tempo de atualização mais observação mais tempo de rollback mais margem. A maioria das equipes dimensiona a janela só para a atualização e não deixa nada para o rollback. Quando as coisas dão errado, elas ficam travadas.
Uma coisa que as pessoas esquecem: a reconciliação de dados após o rollback. As tarefas e os movimentos de estoque criados enquanto a nova versão rodava têm que voltar limpos para a versão antiga, ou a versão antiga tem que recolhê-los. Um WCS é um sistema em tempo real. Uma lacuna de dados dói mais que o tempo de inatividade.
Então, sempre que um cliente pergunta como atualizar um WCS, minha resposta é a mesma: primeiro snapshots e backups, primeiro o standby, migre o tráfego aos poucos, e trace a linha de rollback com antecedência.
O plano de rollback se resume a cinco verificações, marcadas antes da noite da atualização: uma pessoa que decide, no local; gatilhos quantificados escritos no plano; pacotes de rollback e atualização preparados e testados juntos; um ensaio cronometrado em testes; etapas de reconciliação de dados documentadas. Marque as cinco e você pode realmente dormir naquela noite.
Ninguém lembra de uma atualização bem-sucedida. Mas um rollback limpo, o armazém inteiro lembra disso.
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
