Octocore
OctocorePerformance
Metodologia9 min

Performance Engineering Contínuo: integrando performance no dia a dia

Performance não é projeto pontual. É disciplina contínua integrada ao desenvolvimento. Aprenda a construir uma prática sustentável.

Performance engineering não é algo que você faz uma vez antes do lançamento. É uma disciplina contínua, integrada ao ciclo de desenvolvimento, monitorada constantemente, e melhorada iterativamente.

Performance é maratona, não sprint. Ganhos sustentáveis vêm de práticas consistentes, não de heróicas otimizações pontuais.

O Modelo Tradicional (e seus problemas)

Ciclo problemático

1. Desenvolver features (meses)
2. "Semana de performance" antes do release
3. Descobrir problemas graves
4. Correr para consertar
5. Lançar com dívida
6. Apagar incêndios em produção
7. Repetir

Por que falha

- Problemas descobertos tarde demais
- Arquitetura já solidificada
- Pressão de deadline
- Correções são patches, não soluções
- Time exausto de tanto incêndio

O Modelo Contínuo

Ciclo saudável

Cada commit:
  → Testes de performance automatizados
  → Comparação com baseline
  → Gate de qualidade

Cada deploy:
  → Canary com métricas
  → Comparação A/B
  → Rollback automático se degradar

Constantemente:
  → Monitoramento de SLOs
  → Alertas proativos
  → Profiling em produção
  → Revisão de tendências

Implementando Performance Contínuo

1. Performance no CI/CD

# .github/workflows/perf.yml
name: Performance Pipeline

on: [push, pull_request]

jobs:
  unit-perf:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Benchmark Tests
        run: |
          pytest tests/benchmarks/ \
            --benchmark-json=results.json

      - name: Compare with Baseline
        run: |
          python scripts/compare.py \
            --current results.json \
            --baseline baseline.json \
            --threshold 10

  load-test:
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to Staging
        run: ./deploy-staging.sh

      - name: Load Test
        run: |
          k6 run tests/load.js \
            --out json=load-results.json

      - name: Validate SLOs
        run: |
          python scripts/validate-slos.py \
            --results load-results.json

2. Canary Deployments

# Argo Rollouts
apiVersion: argoproj.io/v1alpha1
kind: Rollout
spec:
  strategy:
    canary:
      steps:
        - setWeight: 5
        - pause: {duration: 10m}
        - analysis:
            templates:
              - templateName: latency-check
        - setWeight: 20
        - pause: {duration: 10m}
        - analysis:
            templates:
              - templateName: error-rate-check
        - setWeight: 50
        - pause: {duration: 10m}
        - setWeight: 100

---
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: latency-check
spec:
  metrics:
    - name: latency-p99
      successCondition: result < 0.2
      provider:
        prometheus:
          query: |
            histogram_quantile(0.99,
              sum(rate(http_request_duration_seconds_bucket{canary="true"}[5m]))
              by (le)
            )

3. SLO Monitoring

# SLO definitions
slos:
  - name: API Availability
    target: 99.9%
    window: 30d
    indicator:
      good: sum(rate(http_requests_total{status=~"2.."}[5m]))
      total: sum(rate(http_requests_total[5m]))

  - name: API Latency
    target: 95%
    window: 30d
    indicator:
      good: |
        sum(rate(http_request_duration_seconds_bucket{le="0.2"}[5m]))
      total: sum(rate(http_requests_total[5m]))

# Alertas baseados em burn rate
alerts:
  - name: SLO Burn Rate High
    expr: |
      (
        slo_error_budget_remaining /
        slo_error_budget_total
      ) < 0.5
    severity: warning

  - name: SLO Burn Rate Critical
    expr: |
      (
        slo_error_budget_remaining /
        slo_error_budget_total
      ) < 0.2
    severity: critical

4. Continuous Profiling

# Profiling em produção com sampling
import pyroscope

pyroscope.configure(
    application_name="my-app",
    server_address="http://pyroscope:4040",

    # 10% dos requests
    sample_rate=0.1,
)

# Profile automático
with pyroscope.tag_wrapper({
    "endpoint": request.path,
    "user_type": user.type
}):
    return handle_request(request)

Práticas do Dia a Dia

Code Review focado em Performance

## PR Review Checklist

### Queries
- [ ] EXPLAIN rodado para queries novas/modificadas
- [ ] Sem N+1 (verificar includes/prefetch)
- [ ] Índices apropriados

### Algoritmos
- [ ] Complexidade O() aceitável
- [ ] Sem loops com I/O

### Recursos
- [ ] Connections/handlers são liberados
- [ ] Buffers têm limite
- [ ] Timeouts configurados

### Testes
- [ ] Benchmark test incluído se crítico
- [ ] Load test atualizado se necessário

Performance Budget

# Orçamento por endpoint
endpoints:
  /api/products:
    latency_p99: 100ms
    throughput_min: 1000rps

  /api/checkout:
    latency_p99: 200ms
    throughput_min: 500rps

  /api/search:
    latency_p99: 150ms
    throughput_min: 2000rps

# Validação automatizada
on_budget_exceed:
  - block_merge: true
  - notify: "#perf-alerts"
  - require_approval: "perf-team"

Weekly Performance Review

## Performance Review - Semana 42

### Métricas vs SLOs
| SLO | Target | Actual | Status |
|-----|--------|--------|--------|
| Availability | 99.9% | 99.95% | ✅ |
| Latency p99 | 200ms | 185ms | ✅ |
| Error Rate | 0.1% | 0.08% | ✅ |

### Tendências
- Latência p99 aumentou 5% vs semana passada
- Throughput estável
- Memory usage trending up (investigar)

### Top Hotspots (via continuous profiling)
1. OrderService.calculateTax - 15% CPU
2. ProductRepository.search - 12% CPU
3. JSON serialization - 8% CPU

### Ações
- [ ] Investigar memory trend
- [ ] Otimizar calculateTax
- [ ] Review de índices para search

### Incidentes
- Nenhum incidente de performance

Ferramentas do Ecossistema

Pipeline

CI/CD:
  - GitHub Actions / GitLab CI
  - Argo CD / Flux

Load Testing:
  - k6
  - Gatling
  - Locust

Canary:
  - Argo Rollouts
  - Flagger
  - Spinnaker

Observabilidade

Metrics:
  - Prometheus
  - Datadog
  - New Relic

Tracing:
  - Jaeger
  - Tempo
  - Zipkin

Profiling:
  - Pyroscope
  - Datadog Continuous Profiler
  - Parca

Dashboards:
  - Grafana
  - Datadog

Análise

SLO Management:
  - Nobl9
  - Datadog SLOs
  - Google SLO Generator

Alerting:
  - Prometheus Alertmanager
  - PagerDuty
  - Opsgenie

Métricas de Sucesso do Programa

Maturidade do Programa:

Level 1 - Ad-hoc:
  - Sem testes de performance
  - Problemas descobertos em produção
  - Reativo

Level 2 - Básico:
  - Testes manuais antes de releases
  - Monitoramento básico
  - Alertas existem

Level 3 - Integrado:
  - Testes automatizados no CI
  - SLOs definidos
  - Canary deployments

Level 4 - Proativo:
  - Continuous profiling
  - Performance budgets
  - Análise de tendências

Level 5 - Otimizado:
  - Cultura de performance em todo time
  - Processo self-service
  - Melhoria contínua mensurável

KPIs do programa

Processo:
  - % de PRs com perf test: > 90%
  - Lead time de fix de perf: < 1 dia
  - Regressions detectadas antes de prod: > 95%

Qualidade:
  - SLO compliance: > 99%
  - Incidentes de perf/mês: < 1
  - Error budget utilizado: < 50%

Eficiência:
  - Custo por request: tendência de queda
  - Throughput por $: tendência de alta
  - Tempo gasto em perf work: < 20%

Conclusão

Performance engineering contínuo transforma performance de:

Problema → Disciplina
Reativo → Proativo
Evento → Processo
Individual → Time inteiro

Para começar:

  1. Semana 1: Adicione métricas básicas
  2. Semana 2: Defina SLOs iniciais
  3. Mês 1: Integre testes no CI
  4. Mês 2: Implemente canary
  5. Mês 3: Continuous profiling
  6. Ongoing: Refine e melhore

O objetivo não é perfeição imediata, mas melhoria contínua mensurável.

Performance engineering contínuo é como higiene: não é evento especial, é prática diária.

continuousDevOpsculturapráticas
Compartilhar:
Read in English

Quer entender os limites da sua plataforma?

Entre em contato para uma avaliação de performance.

Fale Conosco