Um pipeline de implantação sem falhas traz satisfação.
O build passou. O artefato foi produzido. A infraestrutura o aceitou. As verificações de saúde estão positivas. A nova versão está em execução.
Nada disso prova que o sistema está pronto para produção.
A implantação prova que o software chegou a um ambiente.
A prontidão para produção pergunta se o sistema consegue operar, ser observado, falhar com segurança, se recuperar, receber suporte e continuar tendo responsáveis depois da liberação.
Esse é um padrão muito mais amplo.
Implantar, liberar e operar são estados diferentes
Times frequentemente condensam três eventos em um só:
Implantar
↓
Liberar
↓
Operar
Uma implantação leva código a um ambiente.
Uma liberação disponibiliza uma capacidade aos usuários.
A operação começa quando a organização assume a responsabilidade pelas consequências.
As feature flags tornam essa distinção evidente. O código pode estar implantado há dias antes de ser liberado. Um serviço pode ser liberado com sucesso e ainda assim falhar operacionalmente horas depois, quando o tráfego muda, uma dependência fica lenta, uma credencial expira ou uma tarefa em segundo plano acumula memória.
A prontidão para produção precisa, portanto, considerar mais do que o evento de implantação.
A prontidão começa pela responsabilidade
Um sistema sem responsáveis claros não está pronto para produção.
A responsabilidade responde a perguntas como:
- Quem responde quando ele falha?
- Quem entende as dependências críticas?
- Quem pode reverter uma implantação?
- Quem é responsável pelo guia operacional?
- Quem recebe os alertas?
- Quem decide se um funcionamento degradado é aceitável?
- Quem se comunica durante incidentes?
Responsabilidade não é o mesmo que acesso ao repositório.
Um time pode ter escrito o código, mas não ter permissão para reiniciar recursos de produção. Outro pode ser responsável pela infraestrutura sem entender o comportamento da aplicação. Um fornecedor pode oferecer uma dependência cuja semântica de falha ninguém mapeou.
A prontidão torna essas fronteiras explícitas antes de um incidente.
A observabilidade deve responder a perguntas operacionais
Logs não são observabilidade apenas porque existem.
Um sistema pronto para produção deve tornar os comportamentos importantes visíveis.
O time consegue identificar:
- se os usuários estão conseguindo realizar suas tarefas;
- qual dependência está falhando;
- se a latência está aumentando;
- se a pressão sobre a memória está se acumulando;
- se uma fila está crescendo;
- se uma tarefa em segundo plano parou;
- se a taxa de erros está concentrada em um cliente ou é global;
- se uma nova versão mudou o comportamento?
As orientações de lançamento do Google SRE incluem monitoramento, capacidade, transferência para recursos alternativos, dependências externas, planejamento da liberação, segurança, backup e recuperação porque a confiabilidade depende do sistema ao redor do código.
A observabilidade deve ser projetada a partir das perguntas sobre falhas, não daquilo que o framework registra por padrão.
Verificações de saúde precisam de significado
Um processo que retorna HTTP 200 ainda pode ser inútil.
Um modelo significativo de saúde distingue níveis como:
- o processo está ativo;
- o processo consegue atender a requisições;
- as dependências críticas estão acessíveis;
- a aplicação consegue executar uma operação importante de ponta a ponta.
Esses sinais têm finalidades diferentes.
Uma verificação de atividade, ou liveness probe, não deveria reiniciar um serviço porque uma dependência remota está temporariamente lenta. Uma verificação de prontidão, ou readiness probe, pode precisar retirar uma instância do tráfego se ela não consegue responder corretamente. Uma verificação sintética pode precisar testar um fluxo crítico para o cliente através de vários componentes.
Estar pronto para produção significa entender o que cada sinal indica e o que a automação faz com ele.
O comportamento em falhas faz parte do produto
Sistemas não precisam apenas de um caminho de sucesso.
Precisam de um comportamento projetado para falhas.
As perguntas incluem:
- O que acontece quando o provedor de e-mail retorna erros?
- O que acontece quando o provedor de identidade está indisponível?
- O que acontece quando uma migração de banco de dados é concluída parcialmente?
- O que acontece quando uma mensagem de fila é processada duas vezes?
- O que acontece quando um fornecedor excede o tempo de resposta após aceitar uma requisição?
- O que acontece quando um token de API expira durante a madrugada?
- O que acontece quando o uso de memória cresce durante doze horas?
Essas são perguntas de arquitetura e produto porque as falhas mudam os resultados para o usuário.
Tempos limite, novas tentativas, idempotência, disjuntores, filas de mensagens não processadas e caminhos alternativos são mecanismos.
A decisão de produto é o que o usuário e o negócio devem experimentar quando as dependências não estão saudáveis.
Planejar capacidade não é só para grandes sistemas
Todo sistema em produção tem limites de capacidade.
A pergunta é se o time os conhece antes que os usuários os descubram.
A capacidade pode ser limitada por:
- CPU;
- memória;
- conexões com o banco de dados;
- limites de requisições de fornecedores;
- vazão de filas;
- armazenamento;
- rede;
- limites de licenciamento;
- concorrência;
- janelas de processamento de sistemas posteriores.
Um serviço pode operar normalmente com tráfego médio e falhar durante um processamento em lote previsível porque o consumo de memória é cumulativo.
A prontidão para produção deve conectar a carga esperada aos limites conhecidos e ao monitoramento.
O checklist histórico de lançamento do Google inclui explicitamente estimativas de tráfego, testes de carga, capacidade, crescimento e impacto sobre dependências. Os detalhes variam por organização, mas o princípio continua relevante.
Configuração e segredos são dependências de produção
Muitos incidentes não vêm do código da aplicação.
Eles vêm de:
- certificados expirados;
- variáveis de ambiente ausentes;
- strings de conexão incorretas;
- segredos desatualizados;
- feature flags incompatíveis;
- divergências entre ambientes;
- configurações alteradas sem histórico de versões.
Um sistema pronto para produção precisa de configuração controlada.
Isso inclui saber quais configurações são obrigatórias, quais podem mudar durante a execução, como os segredos são rotacionados, o que acontece quando essa rotação falha e como as mudanças de configuração são auditadas.
Uma aplicação que pode ser implantada, mas tem configuração frágil, não está operacionalmente pronta.
Mudanças de dados precisam de caminhos de recuperação
É fácil discutir a reversão de uma aplicação quando o código não mantém estado.
Mudanças de banco de dados tornam a reversão mais difícil.
Uma revisão de prontidão para produção deve perguntar:
- A migração é compatível com versões anteriores?
- As versões antiga e nova podem funcionar durante a liberação gradual?
- O que acontece se a migração parar no meio?
- Ela pode ser retomada?
- Mudanças destrutivas são adiadas até haver confiança?
- Como os dados são validados?
- A restauração dos backups foi testada?
Um binário pode ser revertido em segundos, enquanto o esquema que ele alterou não pode.
O planejamento da liberação precisa tratar os dados como parte da implantação gradual.
Backup não é recuperação
Um backup existe.
Isso não prova que a recuperação funciona.
A prontidão para produção exige confiança de que a organização consegue restaurar o que importa dentro de objetivos aceitáveis de tempo e perda de dados.
Uma revisão prática pergunta:
- O que é copiado?
- Com que frequência?
- Onde?
- Quem consegue restaurar?
- Quanto tempo leva a restauração?
- Quais dados se perdem entre backups?
- A restauração foi testada?
O mesmo princípio se aplica à reversão de versões, à recuperação de desastres e aos procedimentos de incidentes.
Capacidades que existem apenas no papel podem não existir quando forem necessárias.
Dependências precisam de semântica explícita de falha
Aplicações modernas dependem de serviços externos para identidade, comunicação, pagamentos, análise, IA, armazenamento e outras funções.
Cada dependência adiciona um contrato operacional.
Uma revisão de prontidão deve tornar esse contrato visível:
| Pergunta | Por que importa |
|---|---|
| Qual tempo limite se aplica? | Evitar recursos bloqueados |
| O que é repetido em uma nova tentativa? | Evitar efeitos colaterais duplicados |
| Qual limite de requisições existe? | Evitar falhas em cascata |
| O que acontece durante a indisponibilidade? | Definir a experiência do usuário |
| Existe um caminho alternativo? | Determinar a estratégia de degradação |
| Como a saúde da dependência é observada? | Diagnosticar incidentes |
| Quem aciona o fornecedor? | Reduzir o atraso na resposta |
Do ponto de vista do usuário, as dependências externas não estão fora do sistema.
Se são necessárias para a capacidade, suas falhas fazem parte do projeto operacional do produto.
Guias operacionais devem registrar decisões, não formalidades
Um guia operacional útil ajuda alguém a agir sob pressão.
Ele deve responder:
- O que este alerta significa?
- Qual é o impacto provável?
- Quais painéis ajudam?
- Quais causas comuns existem?
- Quais ações são seguras?
- Quando devemos reverter a versão?
- Quem precisa participar?
- O que não deve ser feito?
Um guia que diz “investigue os logs” acrescenta pouco.
A documentação operacional é valiosa quando reduz o tempo de decisão em condições anormais.
A aceitação operacional é um critério de liberação
Muitas organizações têm uma definição de concluído para o desenvolvimento, mas nenhuma aceitação operacional explícita.
Um processo de liberação mais sólido pergunta se a capacidade está concluída para produção.
Isso pode incluir:
- código concluído;
- testes aprovados;
- questões de segurança revisadas;
- migração ensaiada;
- painéis disponíveis;
- alertas significativos;
- reversão testada;
- responsabilidades atribuídas;
- guia operacional escrito;
- suporte informado;
- dependências críticas compreendidas;
- métricas pós-liberação definidas.
A lista exata deve ser proporcional ao risco. Uma pequena funcionalidade interna não precisa da mesma formalidade de um fluxo de pagamentos.
O princípio é que a responsabilidade operacional faz parte da conclusão.
Production Done é um padrão de engenharia
A NILLKAI usa a ideia de Production Done para descrever essa condição mais ampla de conclusão.
O ponto importante não é o nome.
É a recusa em equiparar “implantado” a “concluído”.
O software gera valor em operação, e a operação cria novas obrigações.
Um time responsável pelos resultados precisa saber como o sistema se comporta depois que o pipeline de implantação deixou de ser o centro das atenções.
A implantação é apenas o começo
Prontidão para produção é confiança em todo o ciclo de operação.
O sistema consegue atender à carga esperada?
O time consegue observar comportamentos relevantes?
As falhas podem ser contidas?
Os dados podem ser recuperados?
Uma versão pode ser revertida?
As dependências podem degradar com segurança?
Alguém consegue responder às duas da manhã sem reconstruir o sistema a partir do código-fonte?
Essas perguntas tornam a prontidão mais cara do que a implantação.
Também tornam menos provável que a implantação se transforme em um incidente.
A liberação não está concluída quando o artefato chega à produção.
Ela está concluída quando a organização está preparada para assumir o que acontecerá depois.
Referências
- Google. Launch Coordination Checklist. Site Reliability Engineering. https://sre.google/sre-book/launch-checklist/
- Google. Reliable Product Launches at Scale. Site Reliability Engineering. https://sre.google/sre-book/reliable-product-launches/
- Google. Creating a Production Launch Plan. https://sre.google/resources/practices-and-processes/production-launch-planning/
- Microsoft. Reliability design principles. Azure Well-Architected Framework. https://learn.microsoft.com/en-us/azure/well-architected/reliability/principles