DevOps pragmático: o que importa em times pequenos

"DevOps" virou uma palavra de múltiplos significados, na maioria das vezes associada a grandes empresas com times dedicados de SREs, ferramentas complexas e processos elaborados. Para quem trabalha em times pequenos — 2 a 10 pessoas — grande parte dessa conversa não tem aplicação prática imediata.

Este artigo é sobre o subconjunto de DevOps que realmente importa para quem não tem uma equipe inteira dedicada a operações, mas precisa de sistemas confiáveis, deploys frequentes e noites de sono tranquilas.

O princípio central: automatize o que dói

Antes de qualquer ferramenta ou processo, é importante entender o princípio que guia as boas decisões de DevOps em times pequenos: automatize o que dói, não o que é elegante.

Toda equipe tem pontos de fricção — coisas que são manuais, demoradas e propensas a erro. Em times pequenos, esses pontos costumam ser:

• Deploy em produção (quem faz? como? quando?)
• Configuração de ambientes (o famoso "na minha máquina funciona")
• Rollback quando algo dá errado
• Notificações de erro (quando você descobre que algo quebrou)
• Backup de banco de dados

Se você não tem nada automatizado hoje, comece pelos dois últimos. Backup e alertas de erro são o mínimo essencial — o resto você vai construindo conforme sente as dores.

O básico que todo time pequeno precisa

1. Controle de versão bem utilizado

Parece óbvio, mas muitos times ainda não têm uma disciplina clara de branches, commits e pull requests. Um fluxo mínimo que funciona:

• main (ou master): só código que está em produção ou pronto para ir
• develop (ou staging): integração de features antes de ir para produção
• Feature branches: cada funcionalidade nova em um branch separado

Pull requests não são burocracia — são a única forma de ter uma segunda leitura no código antes de ir para produção. Em times de uma pessoa, até PR para si mesmo ajuda a mudar a perspectiva e pegar erros.

2. CI/CD: o que funciona para times pequenos

Continuous Integration/Continuous Delivery soa assustador, mas na essência é simples: cada push de código dispara uma série de verificações automáticas, e se tudo passar, o deploy acontece sem intervenção manual.

Para times pequenos, o GitHub Actions é a escolha óbvia. É gratuito para repositórios públicos e generoso para privados, tem uma biblioteca enorme de actions prontos e se integra naturalmente com o fluxo de trabalho do GitHub.

Um pipeline mínimo útil para um projeto Node.js/React:

name: CI/CD
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '18'
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npm run test

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Deploy para produção
        run: |
          # seu comando de deploy aqui

O importante é que o deploy só acontece se os testes passam, e só no branch main. Isso elimina a classe inteira de problemas causados por deploy manual.

3. Infraestrutura como código (o mínimo)

Você não precisa do Terraform para ter algum nível de infraestrutura como código. Comece com o que você tem:

Docker + docker-compose: Para desenvolvimento local, um docker-compose.yml que sobe banco de dados, serviços de mensageria e qualquer dependência elimina o problema do "na minha máquina funciona". Todos os devs sobem o mesmo ambiente com um comando.

Scripts de setup documentados: Se não for usar Docker, documente os passos de setup em um Makefile ou em scripts de shell. make setup, make dev, make test. Faz diferença quando alguém novo entra no projeto ou quando você volta para um projeto após meses.

Variáveis de ambiente versionadas: Versione um arquivo .env.example com todas as variáveis necessárias (sem valores reais). Isso documenta o que você precisa configurar e reduz o tempo de onboarding de dias para horas.

4. Monitoramento: saber quando algo quebrou

O pior cenário de operações é um usuário descobrir o bug antes de você. Para evitar isso:

Sentry (ou similar) para erros de aplicação: O Sentry captura exceções não tratadas, erros de JavaScript, falhas de API e te notifica em tempo real. A versão gratuita é suficiente para a maioria dos times pequenos. Configurar o Sentry leva menos de 30 minutos e economiza horas de debugging.

Uptime monitoring: Use uma ferramenta gratuita como UptimeRobot para monitorar se seus endpoints principais estão respondendo. Se o site cair, você recebe um alerta por e-mail ou Slack antes do usuário perceber. A versão gratuita monitora até 50 URLs a cada 5 minutos.

Logs centralizados: Em produção, logs no console de um servidor específico não escalam. Mesmo para times pequenos, usar um serviço de logging como Papertrail (gratuito até certo volume) ou a própria suíte da AWS (CloudWatch) facilita muito investigar problemas.

5. AWS: o suficiente para começar

Para hospedagem, a AWS tem uma curva de aprendizado, mas oferece o equilíbrio certo entre poder e custo para a maioria dos projetos. O que você precisa entender no início:

• EC2: instâncias de servidor. Para apps Node.js/Python, uma instância t3.micro ou t3.small cobre a maioria dos casos de uso iniciais.
• RDS: banco de dados gerenciado (PostgreSQL). Não gerencie seu próprio banco em produção se puder evitar — o RDS cuida de backups, replicação e patches.
• S3: armazenamento de arquivos. Para uploads de usuários, assets estáticos, backups.
• CloudFront: CDN. Coloque seu front-end estático atrás do CloudFront e elimine a maioria dos problemas de performance.

O AWS Free Tier é generoso o suficiente para rodar um produto em fase inicial sem custo. Depois que você tem usuários reais, os custos são proporcionais ao uso.

O que evitar no início

Kubernetes: Poderoso, mas é sobrecarga para times pequenos. Você não precisa dele para a maioria dos projetos até ter dezenas de microsserviços ou centenas de instâncias.

Microserviços prematuros: Começar com um monólito bem estruturado é mais fácil de operar, debugar e entender. Migre para microsserviços quando a justificativa for técnica, não ideológica.

Complexidade de pipeline prematura: Um pipeline CI/CD com 15 stages pode parecer impressionante, mas adiciona tempo de execução e complexidade de manutenção. Comece simples.

Infraestrutura gerenciada própria: Se um serviço gerenciado existe (banco de dados, cache, filas), prefira ele à versão self-hosted. O custo operacional de manter sua própria instância do Redis raramente vale a economia em nuvem.

Métricas que importam

Para times pequenos, três métricas de operações são suficientes para começar:

1. Uptime: percentual do tempo em que seu serviço está disponível. Alvo mínimo: 99,5%.
2. Tempo de deploy: quanto tempo leva do merge no main até o código em produção. Alvo: menos de 10 minutos.
3. MTTR (Mean Time to Recovery): tempo médio para resolver um incidente. Monitore, mas sem um número alvo fixo no início — apenas acompanhe se está melhorando.

Conclusão: começe com o suficiente

DevOps em times pequenos é sobre remover fricção das coisas que você faz frequentemente. Deploy frequente e confiável. Ambiente de desenvolvimento reproduzível. Alertas quando algo quebra. Rollback quando precisa.

Você não precisa de uma equipe de SREs para ter operações saudáveis. Precisa de automação nos lugares certos e disciplina para não aumentar a complexidade antes de precisar.

O resto você aprende conforme sente as dores. Esse é o DevOps pragmático.

Alexandre Yamamoto tem 25+ anos de experiência em TI e lidera operações de infraestrutura na Satochi Yamamoto Tecnologia da Informação.