Checklist de go-live: o que conferir antes de entrar em produção?

Um checklist de go-live confere cinco frentes antes da virada: a parte técnica (ambiente, desempenho, monitoramento), os dados (migração conciliada), o plano de volta testado, os critérios de go/no-go definidos com antecedência e a equipe (treinada, com superusuários e suporte escalado). Se um item crítico falhar, a decisão é adiar ou entrar com ressalva registrada.

Faça agora: percorra o Checklist de go-live com o seu time técnico e com a área de negócio. Você sai com os itens de prontidão técnica, das pessoas e do negócio em Excel, PDF ou Markdown, com os itens críticos e o plano de volta marcados.

Go-live é o momento em que a entrega passa a operar com usuários e dados reais: um sistema novo, um processo, uma loja, uma linha de produção. A preparação define se a mudança vai ser absorvida pela operação ou se vai gerar falhas, retrabalho e resistência logo depois da virada. O que segue organiza essa preparação em itens que dá para conferir.

O que conferir na parte técnica e nos dados?

Técnica

• Ambiente de produção montado e igual ao de homologação (versões, configurações, integrações).
• Testes de desempenho com o volume esperado no pico, não só com a média.
• Integrações testadas ponta a ponta com os sistemas vizinhos, inclusive o que acontece quando um deles está fora do ar.
• Monitoramento e alertas ativos, com quem recebe o alerta definido.
• Acessos e perfis de usuários criados e testados com contas reais.
• Janela de mudança aprovada e comunicada às áreas afetadas.

Dados

• Regras de migração aprovadas pela área dona dos dados.
• Carga de ensaio feita com volume real, com tempo medido: a janela da virada precisa caber nesse tempo.
• Conciliação definida antes: totais, quantidade de registros e amostras que a área de negócio vai conferir.
• Cópia de segurança dos dados de origem guardada e testada.

O livro de engenharia de confiabilidade do Google (Site Reliability Engineering, 2017) recomenda um checklist de lançamento que cobre arquitetura e dependências, capacidade, modos de falha, dependências externas e plano de implantação passo a passo, com responsável, risco e contingência em cada etapa. Também descreve a prática de liberar mudanças de forma gradual, primeiro para uma parte pequena dos usuários. Em projetos corporativos, a versão disso é o piloto numa área ou unidade antes da virada geral.

Como montar o plano de volta (rollback)?

O plano de volta responde a uma pergunta: se a virada der errado, como a operação volta a funcionar e em quanto tempo? Ele precisa de:

1. Gatilhos objetivos. Exemplos: sistema indisponível por mais de 2 horas no primeiro dia, faturamento parado, erro de cálculo em folha ou nota fiscal.
2. Quem decide e em quanto tempo. Uma pessoa com autoridade, com substituto, e um prazo máximo para a decisão.
3. Ponto de não retorno. Depois de certo momento (por exemplo, o primeiro faturamento no sistema novo), voltar custa mais do que corrigir. Esse ponto deve estar claro para todos.
4. Passos testados. Restaurar a versão anterior e os dados num ensaio, com tempo medido.
5. Comunicação. Quem avisa usuários, clientes e fornecedores, com mensagem pronta.

Quando a volta não é possível, o plano vira de contingência: como operar no modo manual ou degradado enquanto o problema é resolvido. O tema está em como estruturar planos de contingência para projetos críticos.

Quais critérios decidem go ou no-go?

Os critérios são definidos semanas antes e conferidos na reunião de go/no-go, perto da data da virada, com os responsáveis de cada frente. Exemplo ilustrativo para a implantação de um sistema de vendas em lojas:

Neste exemplo, o critério de dados não foi atendido. As saídas possíveis são adiar, entrar com ressalva (os dois itens pendentes conferidos até uma hora definida, com o plano de volta acionável) ou entrar só nas lojas cujos dados estão conciliados. Seja qual for a escolha, ela é registrada em ata, com responsável e prazo para cada ressalva. Critério que vira "atende" na reunião sem evidência é o começo dos problemas do primeiro dia.

Como preparar a equipe e o suporte?

Antes da virada

• Treinamento ligado ao trabalho de cada pessoa. Treinamento genérico ensina a ferramenta; treinamento alinhado ensina o trabalho que cada um vai executar nela. Combine prática com material de consulta (manuais curtos, vídeos, perguntas frequentes). A integração com a capacitação ao longo do projeto está em planos de capacitação durante o projeto.
• Superusuários. Pessoas de cada área com treinamento mais profundo, que serão a primeira referência dos colegas na virada.
• Simulação. Ensaios em ambiente controlado, com os processos do dia a dia, revelam lacunas que a sala de treinamento não mostra. Treine em fases, começando pelas áreas críticas.

Depois da virada

• Suporte reforçado nas primeiras semanas, com canais definidos (central de atendimento, chat, chamados), níveis de atendimento por tipo de problema e especialistas técnicos e funcionais de plantão.
• Monitoramento e feedback. Relatórios de incidentes, dados de uso e reuniões curtas diárias nos primeiros dias mostram onde ajustar processos e reforçar treinamento.
• Critério de saída do suporte reforçado. Por exemplo, chamados abaixo de um volume combinado por uma semana. Depois disso, a operação assume, tema de transição e sustentação pós-projeto.

Para treinar a condução de uma implantação do lado das pessoas, o jogo O Novo Sistema Chegou coloca você para equilibrar adoção, resistência e produtividade na chegada de um sistema novo às lojas.

Faça agora: marque a reunião de go/no-go, copie os critérios do exemplo para a realidade do seu projeto e confira item a item no Checklist de go-live. Você sai com o checklist em Excel ou PDF para anexar à ata da decisão.

Fontes

• Google, Site Reliability Engineering, capítulo Reliable Product Launches at Scale (2017): https://sre.google/sre-book/reliable-product-launches/