Desafios

DevOps Mínimo Viável: O que Toda Startup Precisa Antes de Ir para Produção

Por Marc Molas·20 de fevereiro de 2024·10 min de leitura

Você não precisa de Kubernetes. Provavelmente não precisa de microsserviços. Definitivamente não precisa de uma equipe de SRE dedicada nesse momento. Mas precisa de uma base de DevOps. Sem ela, cada deploy é uma roleta russa e cada incidente em produção vira um incêndio para apagar às 3 da manhã.

Já vi startups com produto sólido e tração real perderem semanas por não terem um pipeline de CI/CD decente. E vi outras gastarem meses montando infraestrutura de empresa grande quando tinham 3 engenheiros e 0 clientes pagantes. Ambos os extremos são erros. O que você precisa é do DevOps Mínimo Viável.

O checklist do DevOps Mínimo Viável

Estes são os 8 elementos que toda startup precisa antes de colocar um produto nas mãos de usuários reais. Não é negociável. Se falta algum, você está acumulando dívida operacional que vai explodir na sua cara no pior momento possível.

1. Controle de versão com estratégia de branching

Isso parece óbvio, mas a quantidade de startups que trabalham diretamente na main sem estratégia de branching é surpreendente.

Você tem duas opções razoáveis:

Trunk-based development. Branches curtas (horas, não dias), merge frequente na main, feature flags para código não terminado. Ideal para equipes pequenas que fazem deploy várias vezes ao dia.
Git Flow simplificado. Branches de feature, uma branch de develop, releases a partir da main. Mais estrutura, útil quando precisa de staging environments claros.

Para a maioria das startups em fase inicial, trunk-based com feature flags é a opção certa. Menos overhead, menos conflitos de merge, ciclos mais rápidos.

2. Pipeline de CI: lint, test, build em cada PR

Cada pull request deve passar por um pipeline automatizado antes que alguém a revise. Mínimo:

Linting. ESLint, Pylint, o que corresponder ao seu stack. Isso não é estética — é prevenção de bugs.
Testes automatizados. Unit tests como mínimo. Integration tests se os tiver. O pipeline falha se algum teste falhar. Sem exceções.
Build. Se sua aplicação compila, compile no CI. Um PR que quebra o build não é mergeado. Ponto.

Isso dá uma rede de segurança básica. Não perfeita, mas infinitamente melhor que "funciona na minha máquina."

3. Pipeline de CD: deploy automatizado para staging e produção

Se está fazendo deploys manuais — SSH no servidor, git pull, npm run build, rezar — está vivendo perigosamente. Um pipeline de CD básico faz isto:

Merge na develop = deploy automático para staging.
Merge na main (ou tag de release) = deploy automático para produção.
Rollback acessível. Um botão ou um comando para voltar à versão anterior em menos de 5 minutos.

O deploy deve ser um evento entediante. Se toda vez que faz deploy para produção a equipe inteira prende a respiração, você tem um problema de processo, não de produto.

4. Monitoramento básico: uptime, erros, tempos de resposta

Você não precisa de dashboards com 47 métricas. Precisa saber três coisas o tempo todo:

Sua aplicação está online? Monitoramento de uptime. Se cai, você descobre em minutos, não quando um usuário tuíta.
Existem erros? Taxa de erros 5xx, exceções não capturadas. Ferramentas como Sentry são perfeitas para isso.
Está rápida? Tempos de resposta dos seus endpoints críticos. Se sua API passa de 200ms para 2 segundos, você quer saber antes que seus usuários percebam.

As opções: Datadog se tem orçamento, New Relic com seu tier gratuito, ou até CloudWatch se está na AWS. O importante não é a ferramenta — é que o monitoramento exista e que os alertas cheguem onde alguém os veja.

5. Logging centralizado e pesquisável

console.log em produção não é logging. Logs dispersos em 3 servidores diferentes não são úteis quando tem um incidente às 11 da noite.

Você precisa de logs centralizados em um lugar onde possa buscar. As opções:

ELK Stack (Elasticsearch, Logstash, Kibana). Poderoso, mas exige manutenção se hospedar você mesmo.
CloudWatch Logs se está na AWS. Fácil de configurar, pesquisável, integrado.
Papertrail ou Logtail. Simples, baratos, suficientes para startups em fase inicial.

A regra de ouro: se um usuário reporta um erro, você deveria conseguir encontrar o log correspondente em menos de 5 minutos.

6. Backup e recovery: backups de banco de dados com restore testado

Ter backups não conta se nunca testou restaurá-los. Isto é o mínimo:

Backups automáticos diários do seu banco de dados. Se usa RDS ou Cloud SQL, isso já vem incluso.
Retenção mínima de 7 dias. Idealmente 30.
Restore testado. Pelo menos uma vez por trimestre, restaure um backup em um ambiente de teste e verifique que os dados estão lá. Se nunca testou seu restore, você não tem backups — tem uma ilusão de segurança.

7. Paridade de ambientes: staging espelha produção

Seu ambiente de staging deve ser o mais parecido possível com produção. Mesma versão do banco de dados, mesma configuração de servidor, mesmas variáveis de ambiente (com valores diferentes, obviamente).

Se algo funciona em staging mas falha em produção, seu staging não serve. Os problemas mais comuns:

Versões diferentes de dependências. Staging com Node 18, produção com Node 16. Use Docker ou pelo menos .nvmrc para fixar versões.
Banco de dados diferente. Staging com SQLite, produção com PostgreSQL. Não. Use o mesmo banco em ambos os ambientes.
Dados de teste irreais. Seu staging tem 10 registros. Sua produção tem 100.000. Problemas de desempenho não aparecem com 10 registros.

8. Gestão de segredos: zero credenciais hardcoded

Se existe uma API key, senha de banco de dados ou token de acesso no seu código fonte, você tem um problema de segurança que é questão de tempo para explodir.

O mínimo:

Variáveis de ambiente para todos os segredos. Nunca no código, nunca no repositório.
.env no .gitignore. Sempre. Sem exceções.
Rotação de segredos. Se um segredo vaza, você deveria conseguir rotacioná-lo em minutos, não em horas.

Ferramentas como AWS Secrets Manager, HashiCorp Vault ou até o gerenciador de segredos do GitHub Actions são suficientes para começar.

O que você NÃO precisa (ainda)

Tão importante quanto o que precisa é o que não precisa. Estas são as armadilhas de over-engineering mais comuns:

Kubernetes. A menos que tenha uma equipe de mais de 10 engenheiros e necessidades reais de orquestração de containers, Kubernetes é complexidade que não agrega valor. Um simples ECS, Railway ou Fly.io é mais que suficiente.
Service mesh. Istio, Linkerd... soluções para problemas que você não tem com 3 microsserviços (que provavelmente deveriam ser um monolito).
Dashboards de métricas customizados. Grafana com 15 painéis não faz você mais rápido. Alertas básicos sim.
Multi-region failover. Se sua startup tem 500 usuários, não precisa de redundância geográfica. Precisa de um bom uptime em uma região.

A regra: se não consegue explicar em uma frase por que precisa de uma ferramenta ou prática, provavelmente não precisa.

Quando subir de nível

O DevOps Mínimo Viável não é o destino — é o ponto de partida. Você deveria começar a investir em infraestrutura mais robusta quando:

Tem clientes pagantes. Agora existem SLAs implícitos. O downtime custa dinheiro real.
Sua equipe ultrapassa 5 engenheiros. Mais gente = mais necessidade de automação, melhores ambientes de desenvolvimento, pipelines mais sofisticados.
Tem requisitos regulatórios. Se lida com dados de saúde, financeiros ou pessoais com requisitos de conformidade, sua infraestrutura precisa refletir isso.

Ferramentas por orçamento

Orçamento zero (free tier): GitHub Actions para CI/CD, Vercel ou Railway para hosting, Sentry free para erros, UptimeRobot para monitoramento de uptime. Isso cobre surpreendentemente bem até seus primeiros milhares de usuários.

Orçamento médio (200-500 euros/mês): AWS com Terraform para infraestrutura como código, GitHub Actions ou CircleCI para CI/CD, Datadog ou New Relic para monitoramento, ELK managed ou CloudWatch para logs.

Orçamento enterprise (1.000+ euros/mês): Serviços managed da AWS ou GCP, ECS ou EKS para containers, Datadog full suite, PagerDuty para gestão de incidentes, Terraform Cloud para gestão de estado.

O perfil que você precisa

Montar tudo isso não requer uma equipe de DevOps. Requer um engenheiro senior que já fez isso antes. Alguém que sabe a diferença entre o necessário e o aspiracional, que consegue configurar um pipeline de CI/CD em um dia — não em um sprint — e que entende que a infraestrutura deve servir ao produto, não o contrário.

Na Conectia, temos engenheiros seniores de DevOps e infraestrutura que montaram exatamente esse tipo de fundação para startups. Sem over-engineering, sem soluções enterprise para problemas de startup. O stack certo para sua fase atual, configurado para escalar quando precisar.

Cada engenheiro passa pelo nosso processo de vetting técnico liderado por CTOs. Avaliamos experiência real em produção, não certificações. E estão disponíveis em 72 horas.

O DevOps Mínimo Viável não é glamoroso. Você não vai escrever um post no LinkedIn se gabando do seu pipeline de CI. Mas é a diferença entre uma startup que pode iterar com confiança e uma que tem medo de fazer deploy na sexta-feira.

Precisa de um engenheiro DevOps senior que monte as bases sem over-engineering? Fale com um CTO — infraestrutura certa para sua fase, pronta em dias.