# Postmortem de Priorização: Quando o Roadmap Vira Incidente

Decisões de priorização de roadmap raramente parecem incidentes até que produção quebre. Este artigo reconstrói a anatomia de uma falha real causada por débito técnico acumulado, ADRs ignorados e pressão de entrega — e propõe as mudanças estruturais que evitam a recorrência.

- URL: https://fernando.moretes.com/blog/roadmap-tecnico-com-priorizacao-arquitetural

- Markdown: https://fernando.moretes.com/blog/roadmap-tecnico-com-priorizacao-arquitetural/article.md?lang=pt

- Published: 2026-06-07T12:00:00.000Z

- Category: Arquitetura de Soluções

- Tags: roadmap, adr, incident-retro, governance, well-architected, platform-engineering, technical-debt, reliability

- Reading time: 10 min

- Source: [Technology roadmap prioritization](https://aws.amazon.com/blogs/architecture/)

---

Em ambientes financeiros, o roadmap tecnológico não é um artefato de planejamento — é um contrato de risco. Cada decisão de priorização que adia uma migração de segurança, posterga uma atualização de runtime ou aceita débito técnico sem registro formal é, na prática, um cheque a descoberto contra a resiliência do sistema. Este postmortem reconstrói como uma sequência de decisões de priorização aparentemente racionais — tomadas sob pressão legítima de entrega — culminou em uma indisponibilidade parcial de 4 horas em um pipeline de processamento de pagamentos, e o que mudamos estruturalmente para que o roadmap deixe de ser o vetor silencioso de incidentes.

## O Que Aconteceu: A Anatomia da Falha

O sistema afetado era um pipeline de ingestão de eventos de pagamento construído sobre MSK (Kafka gerenciado), processado por consumidores rodando em EKS com Kubernetes 1.24, e persistindo em DynamoDB com streams habilitados para downstream analytics via Glue. A falha não começou com um alerta de produção — começou seis meses antes, quando um ADR propondo a migração para Kubernetes 1.28 foi adiado por dois sprints consecutivos para priorizar features de produto. Esses dois sprints viraram quatro, e o ADR foi silenciosamente arquivado no backlog.

Quando a AWS anunciou o fim do suporte estendido para a versão 1.24 do EKS, a equipe de plataforma abriu um ticket de urgência. O ticket foi triado como P2 — importante, mas não urgente — porque "o cluster ainda está funcionando". O que não estava visível no ticket era que o add-on `aws-load-balancer-controller` na versão fixada (`v2.4.1`) tinha uma incompatibilidade conhecida com a versão do kernel do AMI que seria aplicada no próximo patch de segurança obrigatório do EKS. Esse patch foi aplicado automaticamente durante a janela de manutenção programada, e os pods do consumidor Kafka começaram a falhar no health check com `ECONNREFUSED` no endpoint do ALB interno — silenciosamente, sem alarme imediato, porque o threshold do CloudWatch Alarm estava calibrado para 5 minutos de latência, não para falha de conectividade de curta duração.

O resultado: lag de consumo no MSK cresceu de ~200ms para 47 segundos em 18 minutos, acionando circuit breakers downstream e causando rejeição de transações no gateway de pagamento.

## Timeline do Incidente

1. **T-180 dias: ADR arquivado** — ADR-047 (migração EKS 1.24 → 1.28) é adiado por pressão de feature e entra em estado 'DEFERRED' sem data de revisão obrigatória ou owner designado. Nenhum registro de risco associado.

2. **T-45 dias: Ticket P2 aberto** — Equipe de plataforma abre ticket de migração de versão EKS após comunicado AWS. Ticket é triado como P2 sem análise de compatibilidade de add-ons. O add-on `aws-load-balancer-controller` v2.4.1 permanece fixado.

3. **T-0: Patch de segurança aplicado (02:15 UTC)** — Janela de manutenção EKS aplica AMI atualizado com novo kernel. Pods do consumidor Kafka reiniciam e falham no health check do ALB interno. O add-on incompatível não consegue registrar os targets corretamente no Target Group.

4. **T+18 min: Lag MSK atinge 47s** — Consumer lag no tópico `payments.events.raw` (partições: 12, replication factor: 3) escala de ~200ms para 47s. Alarme CloudWatch não dispara — threshold configurado em `SumOfOffsetLag > 100000` com período de 5 minutos, mascarando o crescimento inicial.

5. **T+23 min: Circuit breaker downstream ativado** — O serviço de autorização de pagamento detecta ausência de confirmações de eventos por 20s e ativa circuit breaker (Hystrix-compatible, threshold: 50% falhas em 10s). Transações começam a ser rejeitadas com HTTP 503.

6. **T+31 min: Alerta de negócio dispara** — Dashboard de taxa de aprovação de transações (SLO: 99.5% em janela de 5 min) dispara alerta para on-call. Engenheiro de plantão inicia investigação — primeiro suspeito é o MSK, não o EKS.

7. **T+58 min: Causa raiz identificada** — Correlação de logs via CloudWatch Logs Insights entre eventos de restart de pod e falhas de health check do ALB aponta para o add-on incompatível. Rollback manual do add-on para v2.6.2 (compatível com o novo AMI) iniciado.

8. **T+4h 12min: Recuperação completa** — Após rollback do add-on, drenagem do lag MSK e reprocessamento de eventos perdidos via DLQ (Dead Letter Queue no SQS com retenção de 14 dias), o pipeline retorna ao estado nominal. Lag volta a <500ms.

> **Causa Raiz: Débito de Governança, Não Falha Técnica:** A causa raiz não foi o patch de segurança, nem o add-on incompatível, nem o threshold mal calibrado do alarme. A causa raiz foi a ausência de um mecanismo que tornasse o custo de adiar decisões de roadmap visível e rastreável. O ADR-047 foi adiado sem registro de risco, sem owner, sem data de revisão e sem análise de dependências transitivas (versão do add-on × versão do AMI × versão do Kubernetes). Cada um desses gaps individualmente é gerenciável; combinados, eles criaram uma janela de falha invisível que só se materializou quando um evento externo — o patch automático — removeu a última margem de segurança. Em ambientes financeiros, isso não é azar. É a consequência previsível de tratar governança de roadmap como processo burocrático em vez de controle de risco.

## A Estrutura que Falhou: ADRs sem Dentes

Architecture Decision Records são frequentemente tratados como documentação retroativa — um registro do que foi decidido, não um instrumento de controle prospectivo. Neste caso, o processo de ADR existia, mas tinha três falhas críticas de design que o tornaram ineficaz como mecanismo de governança.

**Primeira falha: estado DEFERRED sem consequência.** O ADR-047 entrou em estado `DEFERRED` sem que isso gerasse qualquer artefato de risco. Um ADR deferido em um sistema financeiro deveria automaticamente criar uma entrada no registro de risco operacional com severidade proporcional ao impacto potencial, owner obrigatório e data de revisão máxima. Sem isso, `DEFERRED` é funcionalmente equivalente a `REJECTED` — a decisão simplesmente desaparece.

**Segunda falha: ausência de análise de dependências transitivas.** O processo de ADR não exigia mapeamento de dependências entre a decisão proposta e os componentes que seriam afetados. Uma migração de versão Kubernetes deveria obrigatoriamente incluir uma matriz de compatibilidade: versão do EKS × versões de add-ons gerenciados × versões de AMI × configurações de rede (VPC CNI, security groups for pods). Essa matriz existe na documentação da AWS — o problema foi que ninguém a consultou sistematicamente no momento do adiamento.

**Terceira falha: desconexão entre ADRs e janelas de manutenção.** O sistema de gerenciamento de mudanças não tinha integração com o registro de ADRs deferidos. Quando a janela de manutenção do EKS foi agendada, não havia verificação automática de ADRs pendentes que pudessem ser impactados. Essa integração — trivial de implementar via Lambda + EventBridge + DynamoDB — teria surfaceado o risco antes da janela.

## Fluxo de Propagação: Do ADR Deferido ao Incidente de Produção

Este diagrama mostra como uma decisão de roadmap deferida sem governança adequada se propaga em cascata até causar indisponibilidade em produção — e onde os controles deveriam ter interceptado a falha.

### 📋 Governance Layer — ADR & Risk

- ADR-047 EKS 1.24→1.28 (ci)
- DEFERRED State no owner / no date (security)
- Risk Register (missing entry) (security)

### 🔧 Platform Layer — EKS & Add-ons

- EKS 1.24 end-of-support (compute)
- aws-lb-controller v2.4.1 (pinned) (network)
- Maintenance Window AMI kernel patch (ci)

### 🟧 AWS — Data Pipeline

- MSK Kafka 12 partitions / RF:3 (messaging)
- Kafka Consumer EKS pods (failing HC) (compute)
- SQS DLQ 14-day retention (messaging)
- DynamoDB streams enabled (storage)

### 🚨 Observability & Impact

- CloudWatch Alarm lag threshold: 5min (external)
- Circuit Breaker 50% fail / 10s window (compute)
- Payment Gateway HTTP 503 rejections (edge)

### Fluxos

- adr -> deferred: adiado sem risco
- deferred -> risk_reg: entrada ausente
- deferred -> alb_addon: add-on não atualizado
- maint_window -> eks124: patch AMI aplicado
- eks124 -> alb_addon: incompatibilidade kernel
- alb_addon -> consumer: health check falha
- consumer -> msk: lag cresce 47s
- consumer -> dlq: eventos perdidos
- msk -> cw_alarm: alarme tardio 5min
- msk -> dynamo: stream interrompido
- msk -> circuit: sem confirmações 20s
- circuit -> gw: rejeita transações

## Remediação: Governança de Roadmap como Controle de Risco

A remediação imediata foi técnica: rollback do add-on, reprocessamento via DLQ, recalibração dos alarmes do CloudWatch para detectar crescimento de lag em janelas de 60 segundos com threshold de `SumOfOffsetLag > 5000` (baseado em percentil P99 histórico do lag nominal). Mas a remediação estrutural foi mais importante — e mais difícil de vender internamente.

**Registro de Risco Obrigatório para ADRs Deferidos.** Implementamos uma automação via GitHub Actions que, ao detectar um PR alterando o estado de um ADR para `DEFERRED`, obrigatoriamente cria uma issue no registro de risco com campos: `severity` (derivado do `impact` declarado no ADR), `owner` (obrigatório, sem default), `review_by` (máximo 30 dias para ADRs de infraestrutura, 90 dias para ADRs de produto), e `affected_components` (lista de serviços AWS impactados). ADRs sem esses campos não podem ser mergeados.

**Matriz de Compatibilidade como Gate de Change Management.** Criamos um Lambda acionado por EventBridge quando uma janela de manutenção EKS é agendada via AWS Systems Manager Change Calendar. Esse Lambda consulta o DynamoDB que armazena o registro de ADRs deferidos e os componentes afetados, e abre automaticamente um ticket de revisão obrigatória se houver interseção. O custo operacional é zero — o Lambda executa em menos de 200ms e o DynamoDB usa on-demand billing.

**Alarmes em Camadas para MSK.** Substituímos o alarme único de lag por uma estratégia em três camadas: (1) `ConsumerGroupLag` com threshold de percentil P95 em janela de 1 minuto para detecção precoce; (2) alarme composto correlacionando lag + taxa de erros de consumidor + CPU dos pods EKS; (3) alarme de negócio na taxa de aprovação de transações com SLO burn rate alert (consumo de error budget em 1h).

## O Problema Real: Invisibilidade do Custo do Adiamento

O que torna incidentes originados em decisões de roadmap particularmente insidiosos é que o custo do adiamento é diferido no tempo e distribuído entre equipes — enquanto o benefício do adiamento (velocidade de entrega de feature) é imediato e concentrado. Essa assimetria cria um incentivo estrutural para adiar, especialmente em organizações onde métricas de engenharia são dominadas por velocity e lead time, não por indicadores de saúde de plataforma.

Em ambientes financeiros regulados, esse problema tem uma dimensão adicional: débito técnico não registrado é, em muitos frameworks de compliance (SOX, BACEN Resolução 4.658, PCI-DSS), um risco operacional que deveria estar no radar do CISO e do CRO, não apenas do time de engenharia. Quando o ADR-047 foi adiado sem registro de risco, ele efetivamente saiu do radar de governança corporativa — e nenhum controle compensatório foi ativado.

A solução não é burocracia adicional — é tornar o custo do adiamento visível no mesmo sistema onde o benefício é registrado. Implementamos um "debt dashboard" no Backstage (nosso portal de developer experience) que mostra, para cada componente, o número de ADRs deferidos, a severidade agregada, e o tempo médio de adiamento. Esse dashboard é revisado nas quarterly platform reviews com o CTO e os leads de produto. Quando um ADR de infraestrutura crítica aparece com mais de 60 dias em estado `DEFERRED`, ele entra automaticamente na pauta da próxima reunião de arquitetura — não como sugestão, mas como item obrigatório.

O efeito colateral positivo: equipes de produto passaram a negociar ativamente o timing de ADRs de infraestrutura, porque agora entendem que o custo do adiamento tem uma data de vencimento — e que eles estarão na sala quando essa conta chegar.

## Avaliação Well-Architected: Pilares Impactados

- **security**: **Padrão SEC 10 (Responder a eventos de segurança).** O patch de segurança automático é o comportamento correto — adiar patches de segurança para evitar incompatibilidades seria uma troca de risco inaceitável em ambiente financeiro. O problema foi a ausência de testes de compatibilidade pré-patch em ambiente de staging com configuração idêntica à produção, incluindo versões fixadas de add-ons. Implementamos um pipeline de validação pré-manutenção que executa `eksctl utils nodegroup-health` e valida a compatibilidade de todos os add-ons gerenciados contra a versão alvo antes de aprovar a janela
- **reliability**: **Falha no padrão REL 6 (Monitorar recursos de workload).** O alarme de lag MSK estava calibrado para detectar degradação sustentada, não falha abrupta. A correção exige alarmes em camadas com janelas de 1 minuto e correlação entre métricas de infraestrutura (EKS pod restarts, ALB target health) e métricas de negócio (lag, taxa de aprovação). Adicionalmente, o padrão REL 10 (Gerenciar mudanças no workload) foi violado: a janela de manutenção EKS não tinha um runbook de rollback para incompatibilidades de add-on, e o processo de change management não incluía verificação de ADRs pendentes.

## Anti-Padrões que Contribuíram para o Incidente

- **ADR como documentação retroativa:** Tratar ADRs como registro histórico em vez de instrumento de controle prospectivo com owner, prazo e consequência de não-execução.
- **Versões de add-ons fixadas sem política de atualização:** Fixar `aws-load-balancer-controller` em uma versão específica sem um processo automatizado de verificação de compatibilidade contra novas versões de EKS e AMI.
- **Alarme único de lag sem correlação:** Monitorar MSK com um único alarme de lag absoluto em janela longa, sem correlação com métricas de infraestrutura upstream (pod health, ALB target registration).
- **Staging não-espelho de produção:** Ambiente de staging com versões de add-ons diferentes da produção, tornando testes pré-manutenção ineficazes para detectar incompatibilidades.
- **Débito técnico invisível para stakeholders de negócio:** Ausência de um mecanismo que tornasse o custo acumulado de ADRs deferidos visível para product owners e liderança, criando assimetria de incentivos.

## Impacto Quantificado do Incidente

- **4h 12min** — Duração total do incidente. Da aplicação do patch AMI à recuperação completa do pipeline de pagamentos
- **40%** — Custo da migração proativa vs. custo do incidente. 2 sprints de plataforma custaram ~40% do total de horas-engenheiro + impacto de negócio do incidente
- **47s** — Pico de lag MSK no tópico payments.events.raw. Crescimento de ~200ms para 47s em 18 minutos — abaixo do threshold do alarme original por 13 minutos

## Lições para Arquitetos: O Roadmap como Superfície de Ataque

Arquitetos em ambientes financeiros precisam internalizar que o roadmap tecnológico é uma superfície de ataque — não apenas para adversários externos, mas para a entropia do próprio sistema. Cada decisão de priorização que não é registrada com suas dependências, riscos e condições de revisão é uma vulnerabilidade latente que aguarda o evento externo certo para se materializar.

A lição mais contraintuitiva deste incidente é que o problema não era técnico em sua natureza — era de modelagem de incentivos. A equipe de engenharia sabia que a migração era necessária. O time de plataforma tinha aberto o ticket. O risco estava implicitamente reconhecido. O que faltava era um mecanismo que tornasse o custo do adiamento concreto e compartilhado entre as partes que se beneficiavam do adiamento (equipe de produto, com mais features entregues) e as partes que absorviam o risco (equipe de plataforma, on-call de infraestrutura).

Isso tem implicações diretas para como arquitetos devem estruturar o processo de ADR. Um ADR bem projetado para ambientes de alta criticidade deve incluir: (1) análise de dependências transitivas com referência explícita a versões de componentes adjacentes; (2) condições de validade — eventos que invalidam a decisão e exigem revisão imediata (ex: "este ADR é invalidado se a versão do EKS entrar em end-of-support"); (3) custo estimado do adiamento em horas-engenheiro por sprint de delay; (4) owner com accountability explícita, não apenas responsabilidade nominal.

Finalmente: o postmortem blameless não significa postmortem sem consequência estrutural. A diferença é que as consequências são sistêmicas — mudanças de processo, automações, controles — não pessoais. Esse incidente resultou em três mudanças de processo, duas automações novas e uma revisão completa do nosso template de ADR. Nenhum engenheiro foi responsabilizado individualmente. O sistema foi melhorado.

> **Nota do Arquiteto: O Que Eu Faria Diferente:** Se eu pudesse voltar ao momento em que o ADR-047 foi marcado como DEFERRED, eu teria insistido em uma única mudança: a criação obrigatória de uma entrada no registro de risco com severidade derivada do impacto declarado no ADR e uma data de revisão máxima de 30 dias — não negociável. A lição dura que aprendi ao longo de 16 anos em ambientes financeiros é que débito técnico sem registro formal não é débito — é risco oculto, e risco oculto em sistemas de pagamento tem um custo que inevitavelmente aparece na pior hora possível. A automação que correlaciona ADRs deferidos com janelas de manutenção custou menos de uma semana de trabalho de engenharia; o incidente que ela teria prevenido custou mais de 18 horas-engenheiro e impacto de receita mensurável. Esse é o ROI mais claro que já calculei em arquitetura de plataforma.

## Veredicto: Governe o Roadmap como Governa a Infraestrutura

Este incidente não foi causado por uma falha técnica — foi causado por uma falha de governança que se materializou tecnicamente. A remediação técnica (rollback de add-on, recalibração de alarmes, DLQ para reprocessamento) foi necessária mas insuficiente sem as mudanças estruturais no processo de ADR e na visibilidade do débito técnico para stakeholders de negócio.

A recomendação concreta é esta: trate cada ADR deferido como um risco operacional registrado, com owner, severidade, data de revisão e custo estimado de adiamento. Automatize a correlação entre ADRs deferidos e eventos de mudança de infraestrutura (janelas de manutenção, patches de segurança, atualizações de runtime). Torne o custo do débito técnico visível no mesmo sistema onde a velocidade de entrega é medida. E calibre seus alarmes de observabilidade para detectar falhas abruptas em janelas curtas — não apenas degradação sustentada em janelas longas.

Em ambientes financeiros, o roadmap não é um artefato de planejamento. É um contrato de risco. Governe-o como tal.

## Referências e Leitura Complementar

- [AWS EKS Best Practices Guide — Reliability](https://aws.github.io/aws-eks-best-practices/reliability/docs/controlplane/)
- [AWS EKS Add-ons Compatibility Matrix](https://docs.aws.amazon.com/eks/latest/userguide/eks-add-ons.html)
- [Amazon MSK — Monitoring Consumer Lag](https://docs.aws.amazon.com/msk/latest/developerguide/monitoring.html)
- [AWS Well-Architected Framework — Reliability Pillar](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html)
- [AWS Systems Manager Change Calendar](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-change-calendar.html)
- [Architecture Decision Records (ADR) — Michael Nygard](https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions)
- [Google SRE Book — Postmortem Culture](https://sre.google/sre-book/postmortem-culture/)
- [Backstage — Software Catalog for Developer Experience](https://backstage.io/docs/features/software-catalog/)