O Ciclo de Vida Real da Engenharia

Sua POC Não é Produção: Um Guia de Sobrevivência para SREs. Por que pular etapas de validação é a maneira mais rápida de criar legado técnico indestrutível.

Se você trabalha com tecnologia há mais de uma semana, já presenciou o crime acontecer: aquela “POC rapidinha” que, magicamente, virou produção crítica na sexta-feira à noite e agora é o legado intocável que ninguém tem coragem de refatorar. A confusão generalizada entre termos como Spike, POC, MVP e Piloto não é somente preciosismo semântico de agilista; é a raiz de muita dívida técnica, arquiteturas Frankenstein e incidentes que acordam a gente de madrugada porque alguém tratou código descartável como solução definitiva.

Entender onde termina a investigação e começa a engenharia é o que separa um profissional sênior de um eterno “apagador de incêndios”. Neste artigo, vou dissecar a anatomia do ciclo de vida de uma solução técnica — da dúvida abstrata até o Golden Path — estabelecendo limites claros para você saber exatamente quando está validando uma hipótese e quando está, de fato, entregando robustez. Vamos organizar a casa e parar de chamar “gambiarrinha temporária” de MVP.

Para quem opera nas trincheiras de SRE e Infraestrutura, respeitar essa hierarquia não é burocracia, é sobrevivência. Diferente do desenvolvimento de aplicações, onde um rollback costuma ser trivial, decisões de arquitetura e plataforma carregam uma inércia brutal: mudar de orquestrador, trocar de banco de dados ou alterar a malha de rede são movimentos caros e, muitas vezes, destrutivos. O uso disciplinado de Spikes e POCs atua como um firewall contra o Hype Driven Development, impedindo que ferramentas imaturas contaminem seu ecossistema só porque têm um marketing agressivo. Mais crítico ainda é o Piloto: em sistemas distribuídos, a entropia de produção é irreplicável em staging. Sem esse rollout controlado, você não está fazendo engenharia de confiabilidade, está somente apostando que o seu “happy path” vai aguentar o caos do mundo real.

POC (Proof of Concept)

• Foco: Viabilidade Técnica.

• Objetivo: Provar que uma ideia ou tecnologia funciona na prática para resolver um problema específico.

• Pergunta: “É tecnicamente possível fazer isso?”

• Entregável: Código funcional (protótipo), mas não necessariamente pronto para produção (qualidade alpha/beta).

Spike

• Foco: Investigação e Redução de Incerteza (Risco).

• Objetivo: Adquirir conhecimento necessário para estimar ou iniciar uma User Story/Feature complexa.

• Pergunta: “Como vamos fazer isso?” ou “Qual abordagem devemos escolher?”

• Entregável: conhecimento, documentação, decisão técnica ou uma estimativa confiável. Código produzido é descartável e secundário.

• Característica Crítica: Time-boxed (tempo fixo para acabar).

Comparativo Técnico

Exemplos no contexto SRE/DevOps

Cenário de POC:
Validar se a migração do Prometheus para VictoriaMetrics reduz o consumo de RAM em 30%, mantendo a mesma retenção. Você sobe a stack, ingere dados reais, mede e apresenta resultados.

Cenário de Spike:
Alocar 4 horas para investigar se a library prom-client do Rust suporta custom registries da forma que sua arquitetura exige, antes de se comprometer a reescrever o exporter. Se não suportar, o Spike termina com a decisão: “Não usar Rust para isso agora”.

Piloto

1. Produção: Ao contrário da POC (ambiente isolado) e do Spike (ambiente de desenvolvimento/local), o Piloto roda no “mundo real” com tráfego/dados reais.

2. Validação de Valor vs. Viabilidade: A POC valida se dá para fazer. O piloto valida se vale a pena manter ou escalar o que foi feito.

3. Ciclo de Vida: O Piloto tem data para morrer ou evoluir. Se aprovado, ele deve ser refatorado para entrar nos padrões (Golden Path). Se reprovado, é descomissionado (rollback).

Se o foco for estritamente validar valor de negócio/produto, pode ser enquadrado como um MVP (Minimum Viable Product) “dirty” (sujo/rápido).

Classificação tecnica

O risco de uma solução “fora dos templates” em produção é ela funcionar bem demais, a migração (“segundo momento”) nunca acontecer, e você criar um Snowflake Server ou um Legacy indocumentado já no dia 1.

Trate como um experimento com Time-to-Live (TTL) definido. Exemplo: “Este piloto roda até dia X. Se não tivermos migrado para o template padrão até lá, ele será desligado, independentemente do sucesso.”

A ordem tecnicamente coerente (do mais barato/abstrato para o mais caro/concreto) é:

Spike > POC > MVP > Piloto > Produto

• Spike vem primeiro: É a fase de pesquisa pura. Você não constrói um protótipo (POC) sem antes investigar qual tecnologia usar ou como a API funciona. O Spike é barato (leitura/docs/testes de 1h).

• POC vem depois: Com o conhecimento do Spike, você investe tempo codando para provar que funciona.

• MVP vs Piloto: O Piloto é a estratégia de lançamento do MVP. Você constrói o MVP e o coloca em modo Piloto (restrito).

É comum pular etapas. Se a tecnologia é conhecida, pula-se o Spike. Se o risco é baixo, pula-se a POC. Mas a ordem lógica permanece.

Cenário 1: Developer (Backend FinTech)

Problema: O atual processador de transações em Python não está suportando o throughput de pico (latência alta). O time quer reescrever o core em Rust.

• 1. Spike (Investigação):

• • Ação: Alocar 2 dias para verificar o ecossistema de crates (libs) do Rust para Kafka e gRPC.

    • Resultado: Confirmação de que rdkafka e tonic são maduros e compatíveis com a infra atual.

• 2. POC (Prova de Conceito):

• • Ação: Criar um consumidor Kafka mínimo em Rust que somente lê a mensagem, deserializa o JSON e printa no stdout.

    • Resultado: Benchmark sintético mostra processamento 20x mais rápido e consumo de RAM 10x menor que o Python. Viabilidade técnica provada.

• 3. MVP (Produto Mínimo):

• • Ação: Desenvolver o microsserviço “Transaction-Ingestor” somente com o “caminho feliz” (sem tratamento complexo de erros ou retries avançados).

    • Resultado: Um binário funcional capaz de processar pagamentos simples.

• 4. Piloto (Validação em Prod):

• • Ação: Deploy do binário em produção rodando em modo Shadow (lê as mensagens do Kafka, mas não commita offset e não responde ao cliente, somente loga o resultado).

    • Resultado: Validação da estabilidade com carga real sem impactar o cliente. Detecção de um memory leak não visto na POC.

• 5. Produto (General Availability):

• • Ação: Correção do leak, implementação de métricas (Prometheus), logs estruturados, CI/CD e switch do tráfego real. Descomissionamento do serviço Python.

Cenário 2: SRE (Observabilidade)

Problema: O cluster ElasticSearch de logs está custando uma fortuna e a ingestão está lenta. O time quer migrar para Grafana Loki usando Object Storage (S3).

• 1. Spike (Investigação):

• • Ação: Estudar a query language (LogQL) para ver se atende aos dashboards complexos atuais e verificar limitações de retenção no S3.

    • Resultado: LogQL é suficiente, mas exige reaprendizado do time. S3 é viável e muito mais barato.

• 2. POC (Prova de Conceito):

• • Ação: Subir uma stack Loki + Promtail via Docker Compose em uma VM isolada. Ingerir 50 GB de logs antigos para testar velocidade de indexação e busca.

    • Resultado: Indexação rápida, busca aceitável para o caso de uso.

• 3. MVP (Produto Mínimo):

• • Ação: Deploy do Loki (modo monolítico simples) no cluster de Staging. Configurar Promtail como DaemonSet.

    • Resultado: Devs conseguem ver logs de Staging no Grafana. Validação da integração com S3.

• 4. Piloto (Rollout Controlado):

• • Ação: Deploy do Loki em Produção, mas coletando logs somente do namespace kube-system e monitoring.

    • Resultado: Validação do consumo de recursos do Promtail nos nós de produção e do custo real de armazenamento no S3, sem arriscar perder logs de aplicação crítica.

• 5. Produto (Padronização):

• • Ação: Habilitar coleta para todos os namespaces, configurar Retention Policies (30 dias hot, 1 ano cold), criar dashboards oficiais e alerta. Desligar o ElasticSearch.

Resumo dos Ganhos (ROI)