Assessment técnico em engenharia: como mapear riscos e gargalos antes que virem incidentes

Introdução

Incidentes graves raramente surgem sem sinais anteriores.

Um banco de dados que começa a apresentar aumento gradual de latência, um cluster Kubernetes com requests incompatíveis com o consumo real, aplicações sem readinessProbe, filas crescendo silenciosamente, workloads críticos executando em um único nó ou contas de serviço com permissões excessivas são exemplos de situações que podem permanecer invisíveis durante meses.

Até que alguma mudança de tráfego, deploy ou falha de infraestrutura transforme aquela fragilidade em indisponibilidade.

É justamente nesse ponto que entra o assessment técnico de engenharia.

Um assessment técnico é uma análise estruturada de arquitetura, infraestrutura, aplicações, segurança, observabilidade, capacidade, custos e práticas operacionais. Seu objetivo não é apenas identificar erros existentes, mas principalmente encontrar condições que podem evoluir para incidentes.

Em ambientes modernos compostos por Kubernetes, AWS, microsserviços, bancos distribuídos, pipelines CI/CD e dezenas de integrações, analisar somente se "o sistema está funcionando" é insuficiente.

A pergunta correta é:

O sistema continuará funcionando quando houver aumento de carga, perda de infraestrutura, deploy defeituoso ou falha de dependência?

Um assessment bem executado responde essa pergunta antes que a produção responda da pior maneira possível.

O que é um assessment técnico

Um technical assessment é uma avaliação sistemática do estado técnico de uma plataforma ou sistema.

Ele analisa não apenas componentes isolados, mas principalmente como eles se relacionam.

Um assessment pode envolver:

• arquitetura;
• infraestrutura;
• Kubernetes;
• Cloud;
• aplicações;
• bancos de dados;
• mensageria;
• CI/CD;
• segurança;
• observabilidade;
• escalabilidade;
• confiabilidade;
• custos;
• processos operacionais.

O resultado normalmente é um mapa de riscos contendo:

Estado atual → Evidência → Risco → Impacto → Prioridade → Recomendação

Por exemplo:

Workload:
payment-api

Estado atual:
2 réplicas executando no mesmo worker node

Risco:
falha do node derruba todas as réplicas

Impacto:
indisponibilidade completa da API

Recomendação:
topologySpreadConstraints + PodDisruptionBudget

Prioridade:
Alta

O assessment não deve ser confundido com auditoria formal.

Uma auditoria normalmente verifica aderência a requisitos ou normas.

Já o assessment de engenharia busca responder perguntas como:

• Onde estão nossos Single Points of Failure?
• O cluster suporta aumento de tráfego?
• O banco possui capacidade suficiente?
• Quanto tempo demoramos para detectar uma falha?
• Um deploy pode derrubar o ambiente?
• Temos recursos superdimensionados?
• Temos workloads sem limites?
• Existem permissões excessivas?
• Conseguimos recuperar o ambiente após uma falha?

Principais conceitos

Risco

Risco representa a combinação entre:

Probabilidade de falha × Impacto da falha

Uma maneira simples de classificar riscos é utilizar:

Um problema de baixa probabilidade, mas com impacto catastrófico, também merece atenção.

Um exemplo clássico é banco de produção sem backup validado.

Talvez nunca seja necessário restaurá-lo.

Mas, quando for necessário, descobrir que o backup não funciona pode ser fatal.

Gargalo

Gargalo é um recurso ou componente que limita a capacidade do sistema.

Pode existir em diferentes camadas:

Aplicação
    ↓
CPU
    ↓
Memória
    ↓
Network
    ↓
Banco de dados
    ↓
Storage
    ↓
Dependência externa

Um erro comum é assumir que alta latência significa falta de CPU.

Na prática, a causa pode estar em:

• conexões de banco saturadas;
• consultas SQL lentas;
• DNS;
• garbage collection;
• pool HTTP;
• lock distribuído;
• IOPS;
• filas acumuladas;
• chamadas externas.

O assessment deve observar o sistema inteiro

Um assessment técnico eficiente analisa diferentes dimensões simultaneamente.

Arquitetura

Perguntas importantes:

• Existem Single Points of Failure?
• As dependências são síncronas ou assíncronas?
• Existe isolamento entre serviços?
• Existe retry?
• Retry possui limite?
• Existe timeout?
• Existe circuit breaker?
• Uma falha de serviço pode gerar efeito cascata?

Considere:

API
 ↓
Service A
 ↓
Service B
 ↓
Service C
 ↓
Banco

Se todos os serviços utilizarem timeouts de 30 segundos e múltiplos retries, uma falha no banco poderá bloquear centenas de threads simultaneamente.

O resultado pode ser um retry storm.

Uma arquitetura mais resiliente pode utilizar:

API
 ↓
Service
 ↓
Queue
 ↓
Worker
 ↓
Database

A fila absorve picos e reduz acoplamento temporal entre sistemas.

Arquitetura e funcionamento de um assessment

Um assessment pode ser organizado no seguinte fluxo:

Inventário
    ↓
Arquitetura
    ↓
Infraestrutura
    ↓
Aplicações
    ↓
Capacidade
    ↓
Observabilidade
    ↓
Segurança
    ↓
FinOps
    ↓
Riscos
    ↓
Plano de ação

O primeiro passo é entender o ambiente.

Não faz sentido avaliar Kubernetes sem entender:

• quais aplicações são críticas;
• quais dependências existem;
• qual banco é utilizado;
• qual volume de tráfego existe;
• quais serviços podem ficar indisponíveis.

Depois disso, a análise passa para evidências técnicas.

Exemplos:

kubectl get nodes -o wide
kubectl get pods -A -o wide
kubectl get deployments -A
kubectl get statefulsets -A
kubectl get hpa -A
kubectl get pdb -A
kubectl get networkpolicy -A

O objetivo é montar um mapa real do ambiente.

Exemplo do dia a dia

Considere uma empresa SaaS executando dezenas de microsserviços em Amazon EKS.

A arquitetura possui:

Internet
   ↓
ALB
   ↓
Ingress Controller
   ↓
Kubernetes
   ↓
APIs
   ↓
RabbitMQ
   ↓
Workers
   ↓
PostgreSQL

Durante um assessment são encontrados os seguintes pontos:

API crítica:
2 réplicas

Nodes:
3

PodDisruptionBudget:
não configurado

Topology Spread:
não configurado

CPU Request:
100m

CPU real:
700m

HPA:
não configurado

A aplicação funciona normalmente.

Porém existe um problema.

As duas réplicas podem ser agendadas no mesmo node.

Se esse node falhar:

Node
 ├── API Pod 1
 └── API Pod 2

a aplicação fica indisponível.

O assessment identifica o risco antes do incidente.

A correção seria distribuir as réplicas.

Exemplo YAML: distribuição de pods

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-api
  namespace: production
spec:
  replicas: 3

  selector:
    matchLabels:
      app: payment-api

  template:
    metadata:
      labels:
        app: payment-api

    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: payment-api

      containers:
        - name: api
          image: company/payment-api:2.4.1

          ports:
            - containerPort: 8080

          resources:
            requests:
              cpu: 300m
              memory: 512Mi
            limits:
              cpu: "1"
              memory: 1Gi

          readinessProbe:
            httpGet:
              path: /health/ready
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10

          livenessProbe:
            httpGet:
              path: /health/live
              port: 8080
            initialDelaySeconds: 20
            periodSeconds: 20

A configuração utiliza topologySpreadConstraints para tentar distribuir os pods entre diferentes nodes.

O parâmetro:

topologyKey: kubernetes.io/hostname

indica que a distribuição deve considerar hosts diferentes.

Já:

whenUnsatisfiable: DoNotSchedule

impede que o scheduler coloque pods adicionais caso a regra não possa ser respeitada.

Em produção, essa decisão deve ser avaliada cuidadosamente.

Em clusters pequenos, uma regra muito rígida pode deixar pods em estado Pending.

PodDisruptionBudget

Outro risco comum encontrado durante assessments é a ausência de PodDisruptionBudget (PDB).

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: payment-api
  namespace: production
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: payment-api

Esse PDB determina que pelo menos duas réplicas devem permanecer disponíveis durante interrupções voluntárias.

Por exemplo:

Node drain
Upgrade do cluster
Karpenter consolidation
Atualização de nodegroup

Sem PDB, múltiplos pods de uma aplicação crítica podem ser removidos simultaneamente.

O PDB, entretanto, não protege contra falhas inesperadas de node.

Ele controla apenas disrupções voluntárias.

Assessment de recursos Kubernetes

Um dos pontos mais importantes em clusters Kubernetes é comparar:

requests
limits
uso real
capacidade dos nodes

Considere:

resources:
  requests:
    cpu: 2
    memory: 4Gi

  limits:
    cpu: 4
    memory: 8Gi

Mas a aplicação utiliza:

CPU média: 180m
Memória média: 600Mi

O cluster estará reservando muito mais capacidade do que realmente precisa.

O scheduler trabalha principalmente baseado em requests.

Portanto:

requests superdimensionados
        ↓
menos pods por node
        ↓
mais nodes
        ↓
mais custo

Esse é um dos problemas mais comuns encontrados durante assessments FinOps.

Assessment de capacidade

Uma plataforma deve ser analisada considerando três números:

Uso médio
Uso de pico
Capacidade máxima

Exemplo:

Node Pool

Capacidade CPU:
64 vCPU

Requests:
52 vCPU

Uso real:
22 vCPU

À primeira vista existe muita capacidade ociosa.

Entretanto o scheduler considera os 52 vCPU de requests.

Isso significa que novos pods poderão ficar Pending mesmo que o uso real seja muito menor.

Um assessment deve identificar essas distorções.

Horizontal Pod Autoscaler

Outro ponto importante é verificar se aplicações conseguem reagir ao aumento de carga.

Exemplo:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: payment-api
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: payment-api

  minReplicas: 3
  maxReplicas: 20

  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 65

  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
        - type: Percent
          value: 100
          periodSeconds: 60

    scaleDown:
      stabilizationWindowSeconds: 300

Esse HPA escala a aplicação quando a utilização de CPU em relação aos requests aumenta.

É importante entender essa relação.

Se o request estiver incorreto:

CPU real: 600m
CPU request: 2000m

o HPA poderá interpretar:

600 / 2000 = 30%

e não escalar.

Portanto o assessment deve analisar HPA e requests conjuntamente.

Exemplo em ambiente de produção

Considere uma plataforma contendo:

AWS
 └── EKS
      ├── APIs
      ├── Workers
      ├── Redis
      ├── RabbitMQ
      ├── PostgreSQL
      ├── Prometheus
      ├── Grafana
      └── Loki

O assessment identifica:

1. Nodes distribuídos apenas em uma AZ
2. APIs sem PDB
3. Workers sem autoscaling
4. RabbitMQ sem monitoramento de fila
5. Banco próximo de 90% do storage
6. NetworkPolicy inexistente
7. ServiceAccounts compartilhadas
8. Logs sem retenção definida
9. Requests superdimensionados
10. Alertas baseados apenas em CPU

Nenhum desses pontos necessariamente causa incidente naquele momento.

Porém todos representam riscos acumulados.

O maior valor do assessment está justamente nisso:

detectar problemas enquanto eles ainda são baratos de resolver

Avaliação de banco de dados

Um assessment também deve analisar banco.

No PostgreSQL, alguns pontos importantes incluem:

SELECT
    datname,
    numbackends
FROM pg_stat_database;

Para identificar queries lentas, quando pg_stat_statements estiver disponível:

SELECT
    query,
    calls,
    mean_exec_time,
    total_exec_time
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 20;

Outros pontos devem ser avaliados:

• número de conexões;
• locks;
• índices;
• queries lentas;
• crescimento de tabelas;
• WAL;
• replicação;
• backup;
• restore;
• IOPS;
• storage.

Um ambiente pode estar saudável em CPU e mesmo assim sofrer gargalo de banco.

Mensageria

Sistemas assíncronos precisam de métricas específicas.

Para RabbitMQ, por exemplo:

messages_ready
messages_unacknowledged
consumer count
publish rate
ack rate
queue depth

Considere:

Publish rate:
1.000 mensagens/s

Consume rate:
800 mensagens/s

O sistema está acumulando:

200 mensagens/s

Após uma hora:

720.000 mensagens

Mesmo sem erro aparente, existe um gargalo estrutural.

O assessment deve identificar essa diferença antes que a fila cresça até comprometer memória, disco ou SLA.

Observabilidade

Um assessment técnico não pode analisar somente infraestrutura.

Também deve analisar se o time consegue enxergar problemas.

Uma arquitetura moderna costuma possuir:

Métricas → Prometheus
Logs → Loki
Traces → OpenTelemetry
Dashboards → Grafana
Alertas → Alertmanager

Os quatro pilares fundamentais são:

Métricas

Exemplos:

CPU
Memória
Latência
Throughput
Error rate
Queue depth
Database connections

Logs

Devem permitir responder:

O que aconteceu?
Quando aconteceu?
Qual serviço causou?
Qual usuário/request foi afetado?

Traces

Distributed tracing permite acompanhar:

API Gateway
   ↓
Service A
   ↓
Service B
   ↓
Database

Sem tracing, investigar latência entre microsserviços pode ser extremamente difícil.

Alertas

Alertas devem representar impacto.

Evite:

CPU > 70%

Prefira sinais relacionados ao serviço:

p95 latency > 800ms
error rate > 5%
queue backlog > threshold
pods unavailable > threshold

Golden Signals

Uma estratégia eficiente durante assessments é verificar os Golden Signals utilizados pelo SRE:

Latency
Traffic
Errors
Saturation

Por exemplo:

Latency:
p95 HTTP

Traffic:
requests/s

Errors:
5xx rate

Saturation:
CPU, memory, connections, queues

Esses sinais ajudam a identificar se o sistema está próximo de seus limites.

Segurança

Assessment de infraestrutura também precisa avaliar segurança.

RBAC

Verifique permissões excessivas.

kubectl get clusterrolebindings
kubectl get rolebindings -A

Procure permissões como:

cluster-admin

atribuídas desnecessariamente.

ServiceAccounts

Cada workload deve utilizar sua própria identidade.

Evite:

default ServiceAccount

para aplicações de produção.

Em AWS EKS, prefira mecanismos de identidade de workloads como EKS Pod Identity ou IRSA, conforme a arquitetura adotada.

Secrets

Nunca armazene credenciais diretamente em manifests versionados.

Evite:

env:
  - name: DB_PASSWORD
    value: super-secret-password

Prefira integração com serviços como:

AWS Secrets Manager
HashiCorp Vault
External Secrets Operator

NetworkPolicy

Sem NetworkPolicy, normalmente qualquer pod pode se comunicar com qualquer outro pod dentro do cluster, dependendo do CNI utilizado.

Uma política básica poderia ser:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-database
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: database

  policyTypes:
    - Ingress

  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: payment-api

      ports:
        - protocol: TCP
          port: 5432

Essa regra permite que pods payment-api acessem os pods selecionados como database na porta 5432.

Em produção, normalmente utiliza-se uma abordagem de:

default deny
+
allow explícito

Esse modelo reduz movimento lateral em caso de comprometimento.

CI/CD durante um assessment

Pipelines também podem introduzir riscos.

Alguns pontos a verificar:

Deploy automático em produção?
Existe aprovação?
Existe rollback?
Existe scan de imagem?
Existe scan de dependências?
Secrets aparecem no pipeline?
Existe versionamento de imagem?

Evite:

image: company/api:latest

Prefira:

image: company/api:2.4.1

ou melhor ainda, imagens referenciadas por digest quando a imutabilidade for requisito.

Troubleshooting durante o assessment

Alguns comandos ajudam a identificar problemas rapidamente.

Pods

kubectl get pods -A -o wide

Identifique:

CrashLoopBackOff
Pending
OOMKilled
Evicted

Descrição do pod

kubectl describe pod <pod> -n <namespace>

Procure por:

FailedScheduling
FailedMount
OOMKilled
Unhealthy
BackOff

Eventos

kubectl get events -A \
  --sort-by=.metadata.creationTimestamp

Isso ajuda a identificar:

falhas de scheduling
problemas de volumes
problemas de imagens
falhas de probes

Recursos

kubectl top nodes
kubectl top pods -A

Esses dados devem ser comparados com:

kubectl describe node <node>

para analisar requests e limits agregados.

Sinais de risco comuns

Durante um assessment, alguns padrões aparecem frequentemente.

Pods críticos com apenas uma réplica

replicas: 1

Pode ser aceitável em desenvolvimento.

Em produção pode representar Single Point of Failure.

Ausência de readinessProbe

Sem readiness, Kubernetes pode enviar tráfego para aplicações que ainda não estão prontas.

Ausência de limits

Uma aplicação com memory leak pode consumir memória do node inteiro.

Limits muito baixos

Podem gerar:

OOMKilled
CPU throttling

Requests muito altos

Geram desperdício de capacidade.

HPA sem capacidade de node

Escalar pods sem capacidade de infraestrutura resolve pouco.

Por isso:

HPA
+
Node Autoscaling

precisam ser avaliados juntos.

Desenvolvimento x produção

Configurações aceitáveis em desenvolvimento podem ser perigosas em produção.

Desenvolvimento

Pode ser aceitável:

1 réplica
sem PDB
autoscaling desabilitado
cluster pequeno
logs com baixa retenção

O objetivo pode ser reduzir custos.

Produção

Normalmente deve existir:

múltiplas réplicas
distribuição entre nodes/AZs
PDB
autoscaling
monitoramento
backup
security policies
resource requests
capacity planning

Produção precisa considerar falha como evento esperado.

Custos e FinOps

Um assessment moderno também deve avaliar eficiência financeira.

Existem três categorias comuns de desperdício:

recursos ociosos
recursos superdimensionados
recursos esquecidos

No Kubernetes:

CPU Request total:
100 vCPU

CPU média utilizada:
32 vCPU

Isso pode indicar oportunidade de rightsizing.

Mas reduzir requests sem análise pode causar problemas.

Idealmente deve-se analisar:

p50
p95
p99
picos históricos

antes de alterar configuração.

Spot versus On-Demand

Workloads tolerantes a interrupção podem utilizar Spot Instances.

Por exemplo:

CI/CD runners
workers assíncronos
jobs
processamento batch

Já workloads mais sensíveis podem exigir combinação entre:

On-Demand
+
Spot

Um assessment deve analisar tolerância à interrupção antes de recomendar Spot.

O que evitar

Um assessment perde valor quando vira apenas uma lista genérica.

Evite recomendações como:

"melhorar observabilidade"

Prefira:

Problema:
não existe alerta de backlog no RabbitMQ

Risco:
fila pode crescer silenciosamente

Recomendação:
alertar quando messages_ready ultrapassar limite definido por 10 minutos

Outro erro é aplicar checklist sem entender contexto.

Por exemplo:

"todo serviço deve ter 3 réplicas"

Isso não é necessariamente verdade.

Um serviço batch que executa uma vez por dia pode não precisar de múltiplas réplicas.

Assessment precisa considerar criticidade e arquitetura.

Como priorizar riscos

Uma maneira prática é utilizar:

Severidade = Probabilidade × Impacto

Exemplo:

Também é útil considerar:

esforço de correção

Algumas mudanças de alto impacto podem exigir pouco esforço.

Exemplo de matriz de assessment

Categoria: Kubernetes

Item:
Topology Spread

Estado:
Não configurado

Risco:
Réplicas críticas podem executar no mesmo node

Impacto:
Indisponibilidade durante falha de node

Prioridade:
Alta

Recomendação:
Adicionar topologySpreadConstraints

Outro exemplo:

Categoria: Database

Item:
Storage

Estado:
85% utilizado

Crescimento:
4% ao mês

Risco:
Storage exhaustion

Estimativa:
aproximadamente 4 meses

Prioridade:
Crítica

Recomendação:
expandir storage e revisar retenção

Esse formato transforma observações técnicas em ações concretas.

Quando utilizar um assessment

Assessments são especialmente úteis em situações como:

• crescimento acelerado da plataforma;
• aumento recorrente de incidentes;
• migração para Kubernetes;
• migração Cloud;
• mudança de arquitetura;
• preparação para Black Friday ou grandes eventos;
• redução de custos;
• preparação para auditoria;
• aquisição ou integração de empresas;
• ambiente legado sem documentação;
• entrada de nova equipe de Platform Engineering;
• preparação para SRE.

Também é recomendável realizar assessments periodicamente.

Por exemplo:

trimestral
semestral
antes de grandes eventos
após mudanças arquiteturais relevantes

Quando não utilizar

Nem todo problema precisa de assessment completo.

Se a arquitetura for pequena:

1 aplicação
1 banco
1 servidor

uma revisão técnica simples pode ser suficiente.

Também não faz sentido iniciar um assessment de dezenas de dimensões quando existe um problema conhecido e urgente.

Se o banco está com 99% de disco:

primeiro estabilize
depois faça o assessment

Assessment não substitui resposta a incidentes.

Um assessment eficiente deve gerar ações

O documento final deve responder:

O que está errado?
Por que isso importa?
Qual o risco?
Qual evidência comprova?
Como corrigir?
Qual prioridade?

Um exemplo:

Risco:
pods críticos podem executar no mesmo node

Evidência:
3 pods encontrados no worker ip-10-0-4-21

Impacto:
falha do node causa indisponibilidade completa

Correção:
topologySpreadConstraints

Prioridade:
alta

Esforço:
baixo

Isso permite transformar avaliação técnica em backlog de engenharia.

Resumo prático

Um assessment técnico eficiente percorre um fluxo semelhante a:

Inventário
   ↓
Arquitetura
   ↓
Infraestrutura
   ↓
Capacidade
   ↓
Aplicações
   ↓
Banco
   ↓
Mensageria
   ↓
Observabilidade
   ↓
Segurança
   ↓
FinOps
   ↓
Matriz de riscos
   ↓
Plano de ação

Os principais pontos a avaliar são:

• Single Points of Failure;
• distribuição de workloads;
• capacidade de CPU e memória;
• requests e limits;
• escalabilidade;
• filas e processamento assíncrono;
• banco de dados;
• backups;
• observabilidade;
• segurança;
• identidade;
• rede;
• CI/CD;
• recuperação de desastre;
• eficiência de custos.

O objetivo não é encontrar o maior número possível de problemas.

É identificar os problemas que podem gerar maior impacto ao negócio.

Conclusão

Assessment técnico não deve ser tratado como uma fotografia estática da infraestrutura.

Ele é uma ferramenta de engenharia de confiabilidade.

Uma arquitetura pode estar operando normalmente e ainda possuir dezenas de riscos ocultos.

O trabalho do assessment é transformar esses riscos em evidências técnicas antes que sejam descobertos durante um incidente.

Em ambientes modernos com Kubernetes, Cloud, microsserviços e infraestrutura dinâmica, a complexidade cresce rapidamente. Quanto maior o número de componentes, mais difícil se torna compreender todas as interações possíveis entre aplicações, infraestrutura e dependências.

Por isso, times maduros de SRE, DevOps e Platform Engineering não trabalham apenas reagindo a incidentes.

Eles procuram constantemente sinais de fragilidade.

A evolução natural é sair de:

incidente
   ↓
investigação
   ↓
correção

para:

assessment
   ↓
identificação de risco
   ↓
priorização
   ↓
correção preventiva
   ↓
redução de incidentes

Essa mudança representa uma das principais diferenças entre uma operação puramente reativa e uma engenharia de plataforma orientada a confiabilidade.

O melhor incidente continua sendo aquele que nunca aconteceu.