Lab 100 — Projeto final: plataforma .NET 8 + AWS + IA
⏱ 44 min·⭐ 330 XP
Noventa e nove laboratórios atrás, a Cadência era uma distribuidora de material de construção com quatro pessoas e um banco de dados que já tinha perdido dados duas vezes. Hoje ela é um marketplace com 900 lojas parceiras no Brasil e 40 em Portugal — a primeira operação internacional da empresa, sob GDPR —, um data lake que nasceu com 41.312 objetos soltos e hoje sustenta um lakehouse governado por coluna, quatro times chamando o Bedrock em produção (atendimento, extração de documento, busca e catálogo), um agente que diagnostica incidente de madrugada sem poder escrever nada, e uma trilha de decisão que nem um administrador total consegue apagar. Cada peça foi construída, testada e documentada — isoladamente, dentro do laboratório que a motivou. Este é o laboratório que pergunta: juntas, essas 99 decisões formam um sistema que alguém pagaria para operar?
O problema, e a empresa que chegou aqui
A pergunta não nasceu de um incidente — nasceu do mesmo lugar que motivou o L60: um cliente enterprise, agora avaliando contratar a Cadência como plataforma de atendimento white-label para toda a rede dele, pediu duas coisas que nenhum dos 99 laboratórios respondia sozinho. Primeiro, uma revisão Well-Architected — não do Bedrock isolado, não do banco isolado, do sistema inteiro que o cliente vai depender. Segundo, prova de que uma falha regional não deixa o atendimento, a busca, o catálogo e a trilha de auditoria inacessíveis ao mesmo tempo — com RTO e RPO medidos do conjunto, não de um componente.
O time de plataforma tentou responder com o que já existia: a revisão do L60 (900 lojas, 59 laboratórios, seis pessoas na plataforma) e o failover do L58 (Aurora Global, RTO de 4h47min e RPO de 2.140 ms, medidos num ensaio real). Nenhum dos dois bastava mais. O L60 revisou a arquitetura que existia naquele momento — antes do RAG do L83, do agente do L87, da trilha imutável do L97, da plataforma multi-time do L98 e da residência de dado do L99. E o RTO do L58 mede quanto tempo o banco leva para voltar — não quanto tempo o atendimento com IA, a busca, o catálogo em lote e a auditoria levam, juntos, para operar de novo na região secundária.
Este laboratório não introduz nenhum serviço novo. Ele faz duas coisas que nenhum dos 99 anteriores fez: aplica os seis pilares do Well-Architected sobre a visão integrada do sistema — aplicação, dados, IA, segurança e observabilidade juntas —, e ensaia um cenário de falha regional medindo o tempo que o sistema inteiro leva para voltar, não a peça mais lenta isolada nem a mais rápida.
NívelEspecialista — capstone da série; depende do L60, L88, L96, L97 e L98
Pré-requisitosL60, L88, L96, L97, L98 e L99 concluídos; os 99 laboratórios anteriores como corpo de decisões já tomadas
Tempo estimadoEstudo 70 min · jogo de guerra de failover 4 h a 6 h na primeira vez
Custo relativoAlto, concentrado num único dia: duplicar capacidade de aplicação, RAG e cota de Bedrock por algumas horas para medir o failover de verdade
Serviçosintegra os 99 anteriores — Well-Architected Tool, Aurora Global, S3 Object Lock, Bedrock (Knowledge Bases, AgentCore, Evaluation), Organizations, Route 53, CloudTrail, Audit Manager
Volume atual900 lojas no Brasil + 40 lojistas em Portugal; 4 times usando Bedrock em produção; lake que nasceu com 41.312 objetos no L62; ≈340 decisões automatizadas de reembolso/mês com trilha imutável
Requisito declaradoa revisão cobre o sistema INTEIRO, não um serviço; o DR mede RTO e RPO do conjunto, com número, não estimativa
Hipótese declarada99 decisões boas isoladamente não somam, por definição, um sistema bem revisado — é essa lacuna, não uma peça quebrada, que este laboratório fecha
Ao final você temuma revisão Well-Architected do sistema integrado com pelo menos um risco alto genuíno (não maquiado), um jogo de guerra de failover regional com RTO e RPO do sistema inteiro medidos, e uma síntese que liga cada uma das 10 bandas ao sistema final
⚠️
O que este laboratório NÃO é
Não é um laboratório de "parabéns, você terminou". Nenhuma das 99 decisões anteriores é refeita aqui — como no L60, esta revisão lê decisão, não aplica infraestrutura nova sobre o que já existe. Não é uma reforma de arquitetura: se um pilar sai com risco alto, ele fica registrado como risco alto, com plano e prazo — não escondido atrás de uma frase otimista só porque é o último laboratório da série. E não é o laboratório que resolve a dívida de sustentabilidade que o L60 encontrou: ela continua sem resposta, e dizer isso é mais honesto do que fingir tê-la resolvido de brinde.
O que você vai conseguir fazer
Cada objetivo abaixo se prova com um artefato real na seção de implantação — nenhum se verifica com a sensação de ter integrado tudo.
- Registrar o sistema da Cadência como UM workload no Well-Architected Tool, cobrindo aplicação, dados, IA, segurança e observabilidade juntos — não um workload por serviço.
- Responder pelo menos uma pergunta de cada um dos seis pilares citando evidência de um laboratório específico entre os 99 anteriores, no padrão do L60.
- Desenhar a visão integrada do sistema com os nós representativos de cada área e a nota dizendo de qual laboratório cada peça veio.
- Ensaiar um cenário de falha regional real, medindo o RTO e o RPO do SISTEMA inteiro — aplicação, banco, RAG, trilha imutável e plataforma multi-time — não só do componente que o L58 já media.
- Explicar por que a região de residência do L99 (eu-central-1) não participa do failover entre us-east-1 e us-west-2, e o que isso prova sobre isolamento por requisito.
- Produzir a tabela de síntese que liga cada uma das 10 bandas do catálogo a uma contribuição concreta e específica no sistema final — não uma menção genérica.
- Identificar, por escrito, pelo menos um risco que sobrevive aos 99 laboratórios sem solução — e justificar por que registrá-lo é mais correto do que escondê-lo.
O que a certificação cobra disto
| Conceito | Certificação | Como aparece aqui | O que dominar |
|---|---|---|---|
| Revisão de sistema integrado vs. de componente | SAP-C02 | os seis pilares aplicados sobre aplicação + dados + IA + segurança + observabilidade juntos | por que revisar cada serviço isoladamente deixa passar risco que só existe na INTERAÇÃO entre eles |
| RTO/RPO de sistema composto | SAP-C02 | o RTO do sistema é o caminho crítico entre componentes dependentes, não a soma nem a média | identificar qual componente domina o tempo total de recuperação, e por que os mais rápidos ainda precisam de teste próprio |
| Isolamento por requisito vs. capacidade de DR | SAP-C02 | eu-central-1 (L99) existe só para residência de dado; não é capacidade de failover para os outros dois | distinguir "região que existe" de "região com capacidade plena de assumir a carga" — a prova adora confundir as duas |
| Well-Architected Tool sobre múltiplos lens/domínios | SAP-C02 | um workload só, com evidência de laboratórios de bandas diferentes citada na mesma resposta | que o workload no WA Tool representa o SISTEMA, e a granularidade da revisão é escolha de quem revisa, não da ferramenta |
| Síntese de decisões distribuídas no tempo | SAP-C02 (cenário) | tabela banda → contribuição, amarrando 99 decisões tomadas em momentos diferentes por autores diferentes | reconhecer, em cenário de prova, quando um sistema tem boas peças e nenhuma visão de conjunto — o antipadrão central deste módulo |
ConceitoRevisão de sistema integrado vs. de componente
CertificaçãoSAP-C02
Como aparece aquios seis pilares aplicados sobre aplicação + dados + IA + segurança + observabilidade juntos
O que dominarpor que revisar cada serviço isoladamente deixa passar risco que só existe na INTERAÇÃO entre eles
ConceitoRTO/RPO de sistema composto
CertificaçãoSAP-C02
Como aparece aquio RTO do sistema é o caminho crítico entre componentes dependentes, não a soma nem a média
O que dominaridentificar qual componente domina o tempo total de recuperação, e por que os mais rápidos ainda precisam de teste próprio
ConceitoIsolamento por requisito vs. capacidade de DR
CertificaçãoSAP-C02
Como aparece aquieu-central-1 (L99) existe só para residência de dado; não é capacidade de failover para os outros dois
O que dominardistinguir "região que existe" de "região com capacidade plena de assumir a carga" — a prova adora confundir as duas
ConceitoWell-Architected Tool sobre múltiplos lens/domínios
CertificaçãoSAP-C02
Como aparece aquium workload só, com evidência de laboratórios de bandas diferentes citada na mesma resposta
O que dominarque o workload no WA Tool representa o SISTEMA, e a granularidade da revisão é escolha de quem revisa, não da ferramenta
ConceitoSíntese de decisões distribuídas no tempo
CertificaçãoSAP-C02 (cenário)
Como aparece aquitabela banda → contribuição, amarrando 99 decisões tomadas em momentos diferentes por autores diferentes
O que dominarreconhecer, em cenário de prova, quando um sistema tem boas peças e nenhuma visão de conjunto — o antipadrão central deste módulo
💡
Onde isto costuma ser cobrado errado
A pergunta clássica de nível profissional descreve um sistema com dezenas de componentes, cada um bem revisado isoladamente, e pergunta o que falta antes de assinar um contrato enterprise. A resposta esperada NÃO é "nada, cada peça já foi revisada" — é revisar o sistema como UM workload, com os seis pilares aplicados à interação entre as peças, e medir RTO/RPO do caminho crítico completo, não do componente mais fácil de medir.
Requisitos, e como cada um muda a revisão e o ensaio
Requisito que não muda uma linha da revisão ou do desenho é intenção, não requisito. A coluna da direita é onde cada um decide o que este laboratório faz — e, como no L60, nenhum requisito aqui cria peça de infraestrutura nova: eles decidem o ESCOPO e o RIGOR da revisão e do ensaio.
| Requisito | Valor declarado | O que ele decide no desenho da revisão |
|---|---|---|
| A revisão cobre o sistema inteiro, não um serviço | obrigatório | um workload só no Well-Architected Tool, com respostas citando aplicação, dados, IA, segurança E observabilidade — não seis revisões separadas |
| RTO/RPO do failover são do sistema, não do componente mais fácil | obrigatório, medido | o ensaio de failover mede o tempo até TODAS as quatro áreas (app, RAG, trilha, plataforma multi-time) operarem na região secundária — não só até o banco promover |
| Nenhum risco genuíno fica maquiado por causa de ser o último laboratório | obrigatório | a tabela de pilares registra risco alto onde ele existe de fato (sustentabilidade, herdado do L60), sem forçar todos os pilares para verde |
| A síntese cita laboratório específico, nunca menção genérica | obrigatório | a tabela banda → contribuição nomeia o laboratório e o artefato real que ele deixou, não "a banda 7 cuidou de dados" |
| Região de residência (L99) não pode virar capacidade de DR por engano | obrigatório, auditado | o diagrama de failover mostra explicitamente que eu-central-1 fica fora do caminho crítico entre us-east-1 e us-west-2 |
| O ensaio de failover não altera decisão automatizada em produção | obrigatório | o jogo de guerra roda contra um ambiente de exercício com dado sintético, nunca contra o reembolso real de um cliente |
RequisitoA revisão cobre o sistema inteiro, não um serviço
Valor declaradoobrigatório
O que ele decide no desenho da revisãoum workload só no Well-Architected Tool, com respostas citando aplicação, dados, IA, segurança E observabilidade — não seis revisões separadas
RequisitoRTO/RPO do failover são do sistema, não do componente mais fácil
Valor declaradoobrigatório, medido
O que ele decide no desenho da revisãoo ensaio de failover mede o tempo até TODAS as quatro áreas (app, RAG, trilha, plataforma multi-time) operarem na região secundária — não só até o banco promover
RequisitoNenhum risco genuíno fica maquiado por causa de ser o último laboratório
Valor declaradoobrigatório
O que ele decide no desenho da revisãoa tabela de pilares registra risco alto onde ele existe de fato (sustentabilidade, herdado do L60), sem forçar todos os pilares para verde
RequisitoA síntese cita laboratório específico, nunca menção genérica
Valor declaradoobrigatório
O que ele decide no desenho da revisãoa tabela banda → contribuição nomeia o laboratório e o artefato real que ele deixou, não "a banda 7 cuidou de dados"
RequisitoRegião de residência (L99) não pode virar capacidade de DR por engano
Valor declaradoobrigatório, auditado
O que ele decide no desenho da revisãoo diagrama de failover mostra explicitamente que eu-central-1 fica fora do caminho crítico entre us-east-1 e us-west-2
RequisitoO ensaio de failover não altera decisão automatizada em produção
Valor declaradoobrigatório
O que ele decide no desenho da revisãoo jogo de guerra roda contra um ambiente de exercício com dado sintético, nunca contra o reembolso real de um cliente
Visão integrada: o sistema que os 99 laboratórios construíram
Os outros 99 laboratórios desenham a mínima e a de produção do mesmo problema. Este é diferente: não existe "mínima" de um sistema que já está no ar há 99 laboratórios. O diagrama abaixo é a visão de conjunto — não as 99 peças, as principais de cada área, com a nota dizendo de qual laboratório cada uma veio.
Quem usa o sistema
Cliente final e lojista parceiro900 lojas no Brasil e 40 em Portugal (L99); é quem sente qualquer degradação do sistema como um todo, não de um serviço isolado
Atendente humano e plantão de operaçãorecebe hipótese do agente diagnóstico (L96) e decide reembolso com base na trilha do L97 — a IA nunca decide sozinha
Aplicação (bandas 1 a 4)VPC
Borda e balanceamentoa mesma decisão do L01: único endereço público, aplicação em sub-rede privada, health check raso no balanceador
Serviços .NET 8 em ECS Fargatemonolito cortado pela fronteira de transação certa desde o L31, com retry e disjuntor do L36 protegendo toda chamada externa
API com cota por clientecota e versão que o ALB sozinho não fazia, decidido no L11, hoje na frente dos quatro times do L98
Dados (banda 7)
Data lake em três camadasnasceu com 41.312 objetos soltos no L62; hoje bronze, prata e ouro alimentam tanto o BI quanto o RAG do L83
Catálogo e qualidade de dadocontrato e quarentena do L70 garantem que o modelo de frete grátis do L71 não treina com dado que mudou de unidade sem avisar
Governança por coluna e por linhapermissão fina do L69 é a mesma fronteira que o L97 reaproveita para decidir quem pode LER a trilha de decisão
ML clássico e IA generativa (bandas 8 e 9)
Modelo de frete grátis, com baseline de regrao L71 provou, com número, que o modelo só valia a pena depois de comparado contra três condições de regra
RAG com citação para atendimentoresolve as ≈216 perguntas/dia sobre política específica da Cadência que o L83 mediu não caberem em conhecimento genérico do modelo
Agente com ferramenta escopada por IAMcada ferramenta do L87 tem teto de voltas e idempotência; nenhuma tem permissão além da ação exata que precisa
Golden set com juiz LLM, viés medidoL88 bloqueia promoção de prompt quando qualquer critério fica abaixo do piso, mesmo com a média parecendo boa
Segurança e governança (bandas 5 e 10)Conta AWS
Menor privilégio derivado do uso realtoda role do sistema, do agente ao pipeline, segue a disciplina que o L41 formalizou: sem `Resource: "*"` sem comentário
Quatro contas de time, cota e chargeback isoladosa mesma árvore de OUs do L43/L56 hoje isola a cota de Bedrock de cada um dos quatro times do L98
Trilha imutável de decisão automatizadaS3 Object Lock em modo Compliance do L97; nem um administrador total apaga um registro de reembolso dentro do prazo
Observabilidade e operação (bandas 6 e 10)
Telemetria correlacionada por trace ido mesmo id que o L51 gravou em log, métrica e span é o que o agente diagnóstico do L96 usa para correlacionar sem adivinhar
Agente que diagnostica, nunca escrevereduziu de mediana de 24 minutos para menos de 2 minutos até a hipótese, sem NENHUMA ferramenta de escrita na policy IAM
- → requisição HTTPS, com a mesma cota por cliente do L11
- → encaminha ao serviço sadio, health check raso
- → roteia para a task com retry e disjuntor do L36
- → grava e lê dado operacional, sem travar o banco de produção
- → contrato de qualidade antes de virar feature de modelo
- → feature validada alimenta o modelo, nunca dado em quarentena
- → pergunta de atendimento sobre política específica da Cadência
- → pedido que precisa de ação, não só resposta
- → toda mudança de prompt passa pelo golden set antes de produção
- → grava decisão ANTES de responder ao cliente, nunca depois
- → concede só a ação que a ferramenta específica precisa
- → menor privilégio herdado por cada conta de time
- → cota de Bedrock isolada por time, sem disputa entre atendimento e catálogo
- → trace id correlaciona log, métrica e span de toda chamada
- → alimenta o agente diagnóstico com o mesmo sinal do plantão humano
- → publica hipótese com evidência, decisão continua humana
- → mesma fronteira de permissão por coluna reaproveitada na auditoria
- Fora da AWS
- Rede e entrega
- Compute
- Armazenamento
- Analytics
- IA e machine learning
- Segurança e identidade
- Gestão e governança
Nenhum nó aqui é novo — cada um representa a peça principal que um laboratório específico deixou, e a nota diz de qual. O que É novo é a ideia de olhar as cinco áreas ao mesmo tempo: é essa visão que os 99 laboratórios, cada um focado no próprio problema, nunca tiveram motivo para desenhar juntos.
- Quem usa nunca vê cinco sistemas — vê um. O cliente final e o lojista parceiro entram por um único domínio. Internamente são cinco áreas distintas com 99 decisões atrás; para quem usa, é um sistema só, e é assim que ele precisa ser revisado.
- A aplicação nunca fala direto com dado bruto. Entre o serviço ECS e o modelo que decide frete grátis existe um contrato de qualidade (L70) que o L71 mediu ser mais barato de manter do que treinar de novo depois de um erro silencioso de unidade.
- A IA generativa tem três guardas que a IA clássica não tinha. RAG cita a fonte (L83), agente só age dentro do escopo IAM de cada ferramenta (L87), e nenhuma mudança de prompt chega à produção sem passar pelo golden set com juiz (L88) — as três nasceram de incidentes reais, não de precaução teórica.
- Toda decisão automatizada grava ANTES de responder. O agente de atendimento escreve na trilha imutável do L97 antes de a resposta sair para o cliente — a mesma ordem que separou o desenho mínimo do de produção naquele laboratório, agora aplicada ao sistema inteiro.
- A governança não é uma camada — está em toda aresta tracejada. IAM de menor privilégio (L41) e isolamento por conta (L43/L98) não aparecem como uma caixa a mais: aparecem em CADA conexão que concede algo. Removê-las quebraria três áreas ao mesmo tempo, não uma.
- A observabilidade fecha o laço sozinha, sem esperar humano acordar. O mesmo trace id que o L51 correlaciona alimenta o agente diagnóstico do L96, que produz hipótese com evidência em menos de 2 minutos — o humano decide a ação, mas não precisa mais reconhecer o padrão do zero, de madrugada.
- Nenhuma área existe sem as outras quatro — é essa a tese deste laboratório. Tire a governança e o agente do L87 vira o incidente que ele mesmo corrigiu; tire a observabilidade e o L96 não existe; tire os dados governados e o RAG do L83 alucina como no dia zero. O sistema só é seguro porque as cinco áreas seguram umas às outras.
Well-Architected: os seis pilares aplicados ao sistema inteiro
O L60 revisou a Cadência depois de 59 laboratórios, como um workload só, e achou um risco alto genuíno: sustentabilidade, sem nenhuma resposta em nenhum dos 59. Esta revisão reaproveita o MESMO workload no Well-Architected Tool — não cria um novo — e responde as perguntas que só fazem sentido depois dos 40 laboratórios que vieram depois: RAG, agentes, trilha imutável, plataforma multi-time, residência de dado. A pergunta que a diretoria fez desta vez foi mais dura que a do L60: "se o sistema inteiro cair numa região, o que sobrevive e o que não sobrevive?"
| Pilar | Situação medida no sistema integrado | Risco | Melhoria | Prioridade |
|---|---|---|---|---|
| Excelência operacional | telemetria correlacionada (L51) alimenta direto o agente que diagnostica incidente (L96), caindo de mediana de 24 min para menos de 2 min até a hipótese | Baixo | nenhuma pendente crítica; monitorar se o padrão de incidente muda o suficiente para exigir recalibrar o agente | Baixa |
| Segurança | menor privilégio (L41) + ferramenta de agente escopada por ação (L87) + trilha imutável em modo Compliance (L97) + defesa contra prompt injection entre inquilinos (L90) | Baixo | nenhuma pendente crítica; a defesa de L90 nunca foi reensaiada depois da expansão para 4 times do L98 | Média |
| Confiabilidade | RTO agora medido no SISTEMA inteiro (ver seção de DR): 4h51min, contra os 4h47min que o L58 media só do banco — a diferença veio de orquestrar as outras três áreas em paralelo | Médio | a dívida do L58 continua aberta: duas regiões de capacidade plena, não três; eu-central-1 (L99) só carrega residência, não é capacidade de DR | Alta, com prazo |
| Otimização de custo | chargeback por time (L98) e FinOps por componente (L59) existem — mas nenhum relatório soma o custo do SISTEMA por cliente atendido de ponta a ponta | Médio | construir um relatório de custo por jornada de cliente, cruzando as quatro contas de time do L98 com o Cost Explorer | Média |
| Eficiência de performance | quatro modos de inferência medidos e escolhidos por carga (L74), recuperação híbrida com reranking (L85) — decisões medidas, não por hábito | Baixo | nenhuma pendente crítica | Baixa |
| Sustentabilidade | a MESMA ausência que o L60 encontrou depois de 59 laboratórios continua depois de 99: nenhuma decisão de região, tipo de instância ou padrão de escala citou critério de sustentabilidade | Alto | nenhuma — este laboratório não inventa uma resposta que os 99 anteriores nunca deram; fica registrado como dívida real, não maquiada | Alta, sem dono ainda |
PilarExcelência operacional
Situação medida no sistema integradotelemetria correlacionada (L51) alimenta direto o agente que diagnostica incidente (L96), caindo de mediana de 24 min para menos de 2 min até a hipótese
RiscoBaixo
Melhorianenhuma pendente crítica; monitorar se o padrão de incidente muda o suficiente para exigir recalibrar o agente
PrioridadeBaixa
PilarSegurança
Situação medida no sistema integradomenor privilégio (L41) + ferramenta de agente escopada por ação (L87) + trilha imutável em modo Compliance (L97) + defesa contra prompt injection entre inquilinos (L90)
RiscoBaixo
Melhorianenhuma pendente crítica; a defesa de L90 nunca foi reensaiada depois da expansão para 4 times do L98
PrioridadeMédia
PilarConfiabilidade
Situação medida no sistema integradoRTO agora medido no SISTEMA inteiro (ver seção de DR): 4h51min, contra os 4h47min que o L58 media só do banco — a diferença veio de orquestrar as outras três áreas em paralelo
RiscoMédio
Melhoriaa dívida do L58 continua aberta: duas regiões de capacidade plena, não três; eu-central-1 (L99) só carrega residência, não é capacidade de DR
PrioridadeAlta, com prazo
PilarOtimização de custo
Situação medida no sistema integradochargeback por time (L98) e FinOps por componente (L59) existem — mas nenhum relatório soma o custo do SISTEMA por cliente atendido de ponta a ponta
RiscoMédio
Melhoriaconstruir um relatório de custo por jornada de cliente, cruzando as quatro contas de time do L98 com o Cost Explorer
PrioridadeMédia
PilarEficiência de performance
Situação medida no sistema integradoquatro modos de inferência medidos e escolhidos por carga (L74), recuperação híbrida com reranking (L85) — decisões medidas, não por hábito
RiscoBaixo
Melhorianenhuma pendente crítica
PrioridadeBaixa
PilarSustentabilidade
Situação medida no sistema integradoa MESMA ausência que o L60 encontrou depois de 59 laboratórios continua depois de 99: nenhuma decisão de região, tipo de instância ou padrão de escala citou critério de sustentabilidade
RiscoAlto
Melhorianenhuma — este laboratório não inventa uma resposta que os 99 anteriores nunca deram; fica registrado como dívida real, não maquiada
PrioridadeAlta, sem dono ainda
🚨
O risco que este laboratório NÃO resolve, de propósito
Um risco alto que sobrevive a 99 laboratórios não é uma falha deste módulo — seria falha DESTE módulo inventar uma resposta de sustentabilidade só para o relatório fechar todo verde. O L60 já registrou isso como prática fundacional ausente; a honestidade aqui é reconhecer que integrar 99 decisões boas não cria, por si só, a 100ª decisão que nunca foi tomada. Um relatório sem nenhum risco alto depois do capstone da série seria o sinal mais forte possível de revisão malfeita.
Ensaiar o Disaster Recovery: a região cai, e o sistema inteiro precisa provar RTO e RPO
O L58 já ensaiou o failover do banco, com RTO e RPO medidos, não estimados. A pergunta que faltava responder é diferente: quando us-east-1 cai, quanto tempo o sistema INTEIRO — aplicação das 4 contas do L98, RAG do L83, trilha do L97 — leva para voltar a operar na região secundária? E o que acontece, nesse meio-tempo, com os 40 lojistas de Portugal cuja residência de dado o L99 isolou numa terceira região?
Região primária — us-east-1 (impactada)Região
Aplicação e API (4 contas de time)os serviços do L98 — atendimento, extração, busca, catálogo — ficam inacessíveis nesta região durante o exercício
Aurora Global — primárioo mesmo cluster que o L58 construiu; o incidente simulado o torna inacessível para escrita nesta região
Knowledge Base do RAGíndice vetorial do L83 hospedado nesta região; sem réplica quente, ficaria indisponível até reindexação do zero
Detecção e decisão de failover
Route 53 — health check regionalmonitora o ALB das 4 contas de time simultaneamente; falha consecutiva em todas dispara o alarme composto
Alarme composto multi-contacruza sinal de saúde das 4 contas do L98 — uma conta isolada cair não dispara o failover regional inteiro
Plantão, acionado pelo mesmo canal do L96recebe o alerta pelo tópico SNS que já pagina incidente de Faturamento; nenhum painel novo para aprender sob pressão
Região secundária — us-west-2 (promovida)Região
Aplicação e API, cutover de DNSmesma imagem por digest do L01, mesma task definition; o que muda é só a região que o Route 53 passa a apontar
Aurora Global — promovido a primárioa mesma promoção manual do L58: 4h47min medidos naquele ensaio, o passo que domina o tempo total aqui também
Knowledge Base — réplica quenteprovisionada continuamente nesta revisão como remediação do risco médio de confiabilidade — cutover de 90s, contra as 3h20min que reindexar do zero mediria
Cota de Bedrock pré-provisionada, 4 contasService Quotas é por conta e por região; sem pré-provisionar aqui, cada um dos 4 times do L98 dependeria de um pedido de aumento sob demanda
Trilha imutável, replicada continuamente
Bucket de trilha — us-east-1S3 Object Lock modo Compliance do L97; a durabilidade do objeto não depende da região estar acessível
Réplica da trilha — us-west-2replicação contínua com Object Lock preservado, medida com 640 ms de defasagem p99 — não espera a promoção do banco
Fora do incidente — eu-central-1Região
Tráfego de residência — 40 lojistas em Portugalo requisito de residência do L99 nunca dependeu de us-east-1; a queda regional simulada não afeta este tráfego em nenhum instante
Quem confirma o número
Auditoria de conformidadelê a trilha pela réplica em us-west-2 durante o próprio incidente, sem esperar nada ser promovido
- → health check falha em sequência nas 4 contas do L98
- → sinal de falha cruzado entre contas alimenta o alarme composto
- → publica no MESMO canal SNS que hoje pagina incidente de Faturamento
- → aciona o runbook de promoção manual do L58
- → promoção assíncrona; RPO medido de 2.140 ms, herdado do L58
- → réplica mantida quente continuamente, não só durante o incidente
- → cada uma das 4 contas do L98 já tem cota própria nesta região
- → DNS aponta para a região promovida após a confirmação
- → replicação contínua, Object Lock preservado do lado destino
- → consulta a trilha sem esperar a promoção do Aurora terminar
- Compute
- Banco de dados
- IA e machine learning
- Rede e entrega
- Gestão e governança
- Conceito de arquitetura
- Armazenamento
- Fora da AWS
Esta topologia não repete a anterior: aqui os nós são regiões, réplicas e o caminho de failover — não os serviços do dia a dia. Percorra os passos: o RTO do sistema é ditado pelo componente MAIS LENTO do caminho crítico, e a região de residência (L99) nunca entra nesse caminho.
- Detecção: 4 contas, um alarme composto, 2min40s. O Route 53 monitora o ALB de cada uma das 4 contas de time do L98; o alarme composto do CloudWatch só dispara quando várias falham juntas — uma conta isolada é incidente local, não falha regional.
- O plantão aciona o MESMO runbook do L58 — sem painel novo. O alerta chega pelo canal que já pagina Faturamento desde o L96. O runbook de promoção do Aurora Global é literalmente o mesmo documento do L58, sem edição para este exercício.
- O banco domina o tempo total: 4h47min, RPO de 2.140 ms. A promoção do Aurora Global é o passo mais lento do caminho crítico inteiro, com o MESMO número que o L58 mediu isoladamente — integrar o sistema não mudou o tempo desta peça, só revelou que ela é o gargalo de tudo.
- O RAG não espera o banco: réplica quente, cutover em 90 segundos. Diferente do banco, a Knowledge Base do L83 foi provisionada como réplica quente NESTA revisão — remediação do risco médio de confiabilidade. Sem essa decisão, reindexar do zero mediria 3h20min, quase tão lento quanto o banco.
- A trilha do L97 nunca dependeu da promoção do banco. Object Lock garante durabilidade independente de região acessível, e a réplica contínua em us-west-2 (640 ms de defasagem) deixa a auditoria ler decisões passadas DURANTE o próprio incidente — RPO da trilha, na prática, próximo de zero.
- A cota do Bedrock não bloqueia os 4 times, porque foi pré-provisionada. Sem isso, cada uma das 4 contas do L98 dependeria de um pedido de aumento de cota sob demanda em us-west-2 — item que a revisão dos seis pilares já tinha marcado como remediação de confiabilidade.
- eu-central-1 nunca entra no caminho crítico. Os 40 lojistas de Portugal continuam servidos pela região de residência do L99 do início ao fim do exercício — a prova de que isolar por REQUISITO (residência) é uma garantia diferente de ter capacidade de DR ali.
⚠️
A cota de Bedrock pré-provisionada em us-west-2 e a réplica quente da Knowledge Base não existiam antes desta revisão — foram a remediação do risco médio de confiabilidade encontrado na seção anterior. Rodar este jogo de guerra ANTES de provisionar as duas teria medido um RTO real bem pior que 4h51min, porque o gargalo deixaria de ser só o banco: seria o banco MAIS a espera por um pedido de aumento de cota que a AWS não garante ser instantâneo.
Implantar, e provar com número
Cinco medições reais, do jogo de guerra de 07/ago/2026. Nenhuma conclusão vem de "o failover pareceu funcionar".
🗺️ Do alarme composto ao sistema inteiro operando na região secundária
1. Health check falha em sequência nas 4 contas de timeRoute 53 monitora o ALB de cada conta do L98; falha isolada não dispara nada — é a falha correlacionada entre contas que aponta para região, não para serviço.
2. Alarme composto confirma em 2min40sO CloudWatch cruza o sinal das 4 contas; esse é o tempo até o plantão ser acionado, medido no próprio exercício de 07/ago/2026.
3. Runbook do L58 promove o Aurora Global4h47min, exatamente o número medido naquele laboratório — a promoção do banco não mudou de comportamento por estar dentro de um sistema maior.
4. Knowledge Base já estava quente: cutover de 90sDiferente do banco, o RAG não espera nada ser promovido — a réplica contínua em us-west-2 só precisa que o DNS aponte para lá.
5. Trilha imutável já estava legível na região secundáriaA auditoria consulta a réplica com Object Lock preservado durante todo o incidente — a defasagem medida de 640ms p99 nunca bloqueou uma leitura.
6. Cota de Bedrock das 4 contas já existia em us-west-2Sem essa pré-provisão, o Catálogo e o Atendimento ficariam bloqueados por SLA de suporte da AWS, não por falta de capacidade técnica.
7. Route 53 conclui o cutover de DNS60 a 90 segundos depois da promoção do banco confirmada — o passo final, não o gargalo.
8. RTO do sistema: 4h51min. RPO do sistema: 2.140 msO RTO total soma detecção (2min40s) + promoção do banco (4h47min) + cutover final (90s) = 4h51min. O RPO é ditado pelo componente MAIS lento a replicar dado transacional — o mesmo Aurora do L58, porque a trilha replica mais rápido (640ms) e não domina.
medir-failover-sistema-inteiro.sh
# medir-failover-sistema-inteiro.sh -- jogo de guerra regional real,
# 07/ago/2026. Consulta os alarmes e os timestamps de promocao das
# quatro pecas do caminho critico, nao so do banco.
# 1) Timestamp do alarme composto disparando
aws cloudwatch describe-alarm-history \
--alarm-name cadencia-falha-regional-composto \
--history-item-type StateUpdate --max-records 1
# StateUpdatedTimestamp: 2026-08-07T03:14:02Z (T+0)
# 2) Timestamp da promocao do Aurora Global concluida (mesmo cluster do L58)
aws rds describe-global-clusters --global-cluster-identifier cadencia-global \
--query 'GlobalClusters[0].GlobalClusterMembers[?IsWriter==`true`].DBClusterArn'
# Promocao confirmada: 2026-08-07T08:01:14Z -- 4h47min02s apos o alarme
# 3) Defasagem de replicacao da trilha imutavel no momento do incidente
aws s3api head-object --bucket cadencia-trilha-decisao-replica-usw2 \
--key decisoes/2026/08/07/registro-mais-recente.json \
--query 'Metadata.timestamp-origem'
# Defasagem medida (p99 da janela do incidente): 640 ms
# 4) Cutover de DNS confirmado, do alarme ao trafego real chegando a us-west-2
aws route53 test-dns-answer --hosted-zone-id Z0123456789ABC \
--record-name api.cadencia.com.br --record-type A
# Resposta aponta para o ALB de us-west-2 as 2026-08-07T08:02:41Z
# RTO do sistema, do alarme ao ultimo componente confirmado:
# 08:02:41Z - 03:14:02Z = 4h48min39s de relogio corrido; o runbook
# registra 4h51min contando os 2min40s de deteccao ANTES do alarme
# consolidado -- o numero que entra no relatorio da revisao.
O número que fecha esta seção: RTO de 4h51min e RPO de 2.140 ms para o SISTEMA inteiro — não apenas para o Aurora Global que o L58 media isoladamente. A diferença de 4 minutos entre o RTO do L58 (4h47min) e o RTO medido aqui não veio de o banco ficar mais lento: veio de somar a detecção multi-conta e o cutover final de DNS, que o ensaio original do L58 não precisava medir porque testava um componente, não um sistema.
As decisões, e o que se perde em cada uma
📋 A Cadência integrou 99 laboratórios de decisão boa e isolada, e precisa provar a um cliente enterprise que o SISTEMA — não cada peça — passa por revisão formal e sobrevive a uma falha regional com número medido, sem reescrever nenhuma das 99 decisões já tomadas.
✓ Um workload só no Well-Architected Tool cobrindo as cinco áreas juntas, mais um jogo de guerra de failover que mede o caminho crítico completo — reaproveitando o runbook do L58, a réplica da trilha do L97 e a cota pré-provisionada das 4 contas do L98.
Nenhuma peça nova de infraestrutura era necessária além de duas remediações pontuais (réplica quente da Knowledge Base, cota pré-provisionada). O ganho inteiro vem de mudar a UNIDADE da revisão — de "cada serviço" para "o sistema" — e de medir o failover pelo componente mais lento do caminho real, não pelo mais fácil de testar isoladamente.
Alt: Revisar cada laboratório separadamente, sem workload único — é literalmente o que a Cadência tinha antes do L60: 99 boas respostas isoladas, e nenhuma resposta sobre a INTERAÇÃO entre elas — o mesmo ponto cego que motivou este laboratório.
Alt: Confiar no RTO do L58 como RTO do sistema — subestima o tempo real: ignora que RAG, trilha e cota de time também precisam estar prontos, e no cenário sem as duas remediações desta revisão, o gargalo real seria pior que o do banco sozinho.
Alt: Forçar todos os seis pilares para risco baixo antes de entregar o relatório — é o antipadrão que o próprio L60 nomeou: zero risco alto depois de 99 laboratórios é sinal de revisão malfeita, não de arquitetura perfeita — e mentir sobre sustentabilidade não a resolve.
Alt: Testar o failover só em ambiente de homologação, nunca em produção espelhada — mede menos do que promete: cota de Bedrock, capacidade de Aurora e latência de replicação em homologação não refletem o volume real das 900 lojas e dos 4 times de produção.
| Decisão | Escolha | Alternativa considerada | Motivo | O que se perde |
|---|---|---|---|---|
| Unidade da revisão | um workload cobrindo o sistema inteiro | um workload por serviço ou por laboratório | revela risco que só existe na interação — como a cota de Bedrock por conta e região, que nenhum laboratório isolado tinha motivo para testar sob falha regional | granularidade fina por componente; compensado citando o laboratório específico em cada resposta |
| O que medir no failover | o caminho crítico completo (detecção + promoção + cutover) | só o RTO do banco, como no L58 | o RTO real que o cliente enterprise sente é o do sistema, não o do componente mais fácil de isolar em teste | um número mais simples de comunicar ("o banco leva 4h47"), ao custo de esconder 4 minutos reais de outras dependências |
| Tratamento do risco de sustentabilidade | manter registrado como alto, sem solução | encerrar a série com todos os pilares em risco baixo | honestidade sobre o que 99 laboratórios genuinamente não resolveram é mais útil ao cliente que um relatório artificialmente verde | um capstone "perfeito" — trocado por um capstone confiável |
DecisãoUnidade da revisão
Escolhaum workload cobrindo o sistema inteiro
Alternativa consideradaum workload por serviço ou por laboratório
Motivorevela risco que só existe na interação — como a cota de Bedrock por conta e região, que nenhum laboratório isolado tinha motivo para testar sob falha regional
O que se perdegranularidade fina por componente; compensado citando o laboratório específico em cada resposta
DecisãoO que medir no failover
Escolhao caminho crítico completo (detecção + promoção + cutover)
Alternativa consideradasó o RTO do banco, como no L58
Motivoo RTO real que o cliente enterprise sente é o do sistema, não o do componente mais fácil de isolar em teste
O que se perdeum número mais simples de comunicar ("o banco leva 4h47"), ao custo de esconder 4 minutos reais de outras dependências
DecisãoTratamento do risco de sustentabilidade
Escolhamanter registrado como alto, sem solução
Alternativa consideradaencerrar a série com todos os pilares em risco baixo
Motivohonestidade sobre o que 99 laboratórios genuinamente não resolveram é mais útil ao cliente que um relatório artificialmente verde
O que se perdeum capstone "perfeito" — trocado por um capstone confiável
Evolução: a maturidade da plataforma, não de uma técnica isolada
Os outros 99 laboratórios mostram a evolução de UMA técnica — do protótipo à escala. Este mostra a evolução da Cadência inteira, nível por nível, cada um citando o que os laboratórios daquela faixa deixaram e qual risco a maturidade seguinte troca por outro — nunca elimina, troca.
🗺️ Da distribuidora de quatro pessoas à plataforma revisada e ensaiada — a maturidade que os 99 laboratórios constroem, nível por nível
Nível 1 — Uma aplicaçãoRisco resolvido: deploy manual e ambiente inexistente. Novo risco: qualquer decisão de arquitetura ainda mora na cabeça de quem escreveu o Terraform.
→
L01 a L10: três camadas em produção, rede privada, segredo rotacionado, backup ensaiado. Uma equipe de quatro pessoas, um banco, uma AZ de risco.Nível 2 — Sistema distribuído com disciplinaRisco resolvido: acoplamento síncrono derrubando tudo junto. Novo risco: superfície de ataque cresce mais rápido que a governança sobre ela.
→
L11 a L40: API com cota, banco pela carga, evento e fila, monolito cortado pela fronteira certa, retry com backoff e jitter.Nível 3 — Governado e operadoRisco resolvido: credencial de longa duração e recurso sem dono. Novo risco: cada domínio (segurança, dados, operação) revisado isoladamente, nunca junto.
→
L41 a L70: menor privilégio, multi-conta com SCP, observabilidade correlacionada, DR do componente crítico ensaiado, dado organizado em lake.Nível 4 — IA com disciplina de engenhariaRisco resolvido: modelo decorativo e resposta plausível sem fonte. Novo risco: cada capacidade de IA testada sozinha, sem medir o custo de somá-las.
→
L71 a L90: baseline de regra antes de ML, RAG com citação, agente com ferramenta escopada, avaliação com golden set e juiz, defesa contra prompt injection.Nível 5 — Solução integrada por domínioRisco resolvido: automação sem trilha auditável e cota disputada entre times. Novo risco: nove sistemas integrados por domínio, ainda sem uma revisão que os trate como um só.
→
L91 a L99: atendimento por voz, IDP com revisão humana, copiloto com permissão por fonte, agente de diagnóstico só-leitura, trilha imutável, plataforma multi-time, residência multi-região.Nível 6 — Sistema revisado e ensaiado como um todoRisco resolvido: revisão fragmentada e RTO subestimado por medir só o componente mais fácil. Novo risco, honesto: sustentabilidade continua sem resposta — maturidade de plataforma não é sinônimo de ausência de dívida.
→
L100 (este laboratório): um workload no Well-Architected Tool cobrindo as cinco áreas, RTO/RPO do sistema inteiro medidos num jogo de guerra real, e a síntese que amarra as 10 bandas.Segurança do sistema inteiro: as costuras que nenhum laboratório revisou
Cada um dos 99 laboratórios tem sua própria seção de segurança, e cada uma está correta dentro do próprio perímetro. O que nenhuma delas podia revisar é a COSTURA: o ponto em que a saída de um laboratório vira a entrada de outro, onde uma credencial atravessa fronteira, onde um bucket escrito por um time é lido por outro. É ali que mora o risco que só existe no sistema montado.
| Costura | O risco que só existe aqui | Como verificar hoje | Correção |
|---|---|---|---|
| O acervo do RAG (L83) é escrito por um pipeline de dados (L62) | Quem tem escrita no lake influencia o que o atendimento responde ao cliente. Nenhum dos dois laboratórios trata o outro como superfície de ataque | Listar quem tem permissão de escrita no bucket do acervo e comparar com quem deveria poder mudar uma política de atendimento | Aprovação explícita para promover documento ao acervo, com o mesmo rigor de uma mudança de código |
| O agente (L87) executa ferramentas contra o banco de pedidos (L07) | O raio de alcance de uma role de ferramenta pode ultrapassar o domínio para o qual ela foi desenhada. O laboratório do banco não sabe que um agente o consulta | Simular a policy de cada ferramenta contra os recursos de todos os laboratórios, não só do próprio | Escopo de recurso amarrado ao cliente da sessão, e revisão de alcance quando uma ferramenta nova nasce |
| A trilha imutável (L97) registra decisões de três origens diferentes | Se uma origem grava com esquema próprio, a consulta cruzada da auditoria falha justamente quando é necessária | Tentar responder "todas as decisões automatizadas sobre o pedido X" em uma consulta só | Esquema comum de trilha, imposto por biblioteca compartilhada |
| A cota do Bedrock é da conta, e quatro times a usam (L98) | Um time consome a cota que outro precisa para responder em tempo real — o incidente das 14h32 | Conferir se cada time tem cota própria e se o onboarding cria isso automaticamente | Isolamento por conta com cota própria, e caminho de onboarding rápido o bastante para ninguém tentar o atalho |
| Dado pessoal atravessa extração (L92), lake (L62) e trilha (L97) | A classificação do dado é feita na origem e não acompanha as cópias. Cada cópia tem retenção e permissão próprias, definidas por times diferentes | Seguir um CNPJ específico por todos os armazenamentos e listar onde ele existe hoje | Classificação que viaja com o dado, e retenção derivada dela — não do hábito de cada armazenamento |
CosturaO acervo do RAG (L83) é escrito por um pipeline de dados (L62)
O risco que só existe aquiQuem tem escrita no lake influencia o que o atendimento responde ao cliente. Nenhum dos dois laboratórios trata o outro como superfície de ataque
Como verificar hojeListar quem tem permissão de escrita no bucket do acervo e comparar com quem deveria poder mudar uma política de atendimento
CorreçãoAprovação explícita para promover documento ao acervo, com o mesmo rigor de uma mudança de código
CosturaO agente (L87) executa ferramentas contra o banco de pedidos (L07)
O risco que só existe aquiO raio de alcance de uma role de ferramenta pode ultrapassar o domínio para o qual ela foi desenhada. O laboratório do banco não sabe que um agente o consulta
Como verificar hojeSimular a policy de cada ferramenta contra os recursos de todos os laboratórios, não só do próprio
CorreçãoEscopo de recurso amarrado ao cliente da sessão, e revisão de alcance quando uma ferramenta nova nasce
CosturaA trilha imutável (L97) registra decisões de três origens diferentes
O risco que só existe aquiSe uma origem grava com esquema próprio, a consulta cruzada da auditoria falha justamente quando é necessária
Como verificar hojeTentar responder "todas as decisões automatizadas sobre o pedido X" em uma consulta só
CorreçãoEsquema comum de trilha, imposto por biblioteca compartilhada
CosturaA cota do Bedrock é da conta, e quatro times a usam (L98)
O risco que só existe aquiUm time consome a cota que outro precisa para responder em tempo real — o incidente das 14h32
Como verificar hojeConferir se cada time tem cota própria e se o onboarding cria isso automaticamente
CorreçãoIsolamento por conta com cota própria, e caminho de onboarding rápido o bastante para ninguém tentar o atalho
CosturaDado pessoal atravessa extração (L92), lake (L62) e trilha (L97)
O risco que só existe aquiA classificação do dado é feita na origem e não acompanha as cópias. Cada cópia tem retenção e permissão próprias, definidas por times diferentes
Como verificar hojeSeguir um CNPJ específico por todos os armazenamentos e listar onde ele existe hoje
CorreçãoClassificação que viaja com o dado, e retenção derivada dela — não do hábito de cada armazenamento
⚠️
A revisão que só cabe aqui
Segurança de sistema não é a soma das seções de segurança dos componentes. Este é o único momento da série em que se pode perguntar "quem, no sistema inteiro, consegue chegar a este dado?" — e a resposta quase nunca é a que qualquer laboratório isolado daria. Reserve o tempo desta revisão antes do ensaio de recuperação: ela costuma achar mais coisa.
Quebrar de propósito: as falhas que atravessam a fronteira dos laboratórios
O ensaio de recuperação testa a perda da região inteira. Estas quatro injeções testam algo diferente e mais frequente: uma peça falhando e o efeito aparecendo em outra, três laboratórios adiante — a classe de incidente que nenhum módulo isolado consegue reproduzir.
| Falha injetada | Onde ela nasce | Onde o sintoma aparece | O que se aprende |
|---|---|---|---|
| Ingestão do acervo parada por 48 horas | O pipeline de dados (L62/L65) | O atendimento (L83) responde com política revogada, com citação e confiança — e a reclamação chega pelo canal de voz (L91), como cliente irritado | A distância entre a causa e o sintoma é de três laboratórios e dois times. Nenhum alarme do pipeline de dados diz "o atendimento está mentindo", e é exatamente essa tradução que falta. O indicador de idade do acervo precisa aparecer no painel de quem responde ao cliente, não só no de quem ingere |
| Job de lote disparado no horário comercial | O enriquecimento do catálogo (L95) | A latência do atendimento em tempo real (L91) estoura o prazo de 2,5 s, e as ligações são abandonadas | É o incidente das 14h32, e ele atravessa quatro laboratórios. O isolamento de cota (L98) é a correção estrutural; a lição de sistema é que recurso compartilhado cria acoplamento invisível entre times que nunca conversaram |
| Reordenador de busca indisponível | A busca de produto (L94) | A conversão cai, o time de marketing investiga campanha por duas semanas, e ninguém olha uma permissão de IAM negada | Degradação silenciosa vira problema de negócio antes de virar problema técnico, e o dono do sintoma não é o dono da causa. Todo caminho que falha aberto precisa de alarme próprio — é a regra que mais se repete nesta série e a mais fácil de esquecer na peça seguinte |
| Trilha de auditoria indisponível | A trilha imutável (L97) | As aprovações de reembolso param, corretamente, e o financeiro reporta "sistema fora do ar" | É o comportamento desejado doendo. O sistema inteiro precisa de uma lista declarada do que falha fechado e do que falha aberto, conhecida por quem atende o chamado — senão alguém vai "consertar" tornando a gravação opcional, e o caso da Roberta volta |
Falha injetadaIngestão do acervo parada por 48 horas
Onde ela nasceO pipeline de dados (L62/L65)
Onde o sintoma apareceO atendimento (L83) responde com política revogada, com citação e confiança — e a reclamação chega pelo canal de voz (L91), como cliente irritado
O que se aprendeA distância entre a causa e o sintoma é de três laboratórios e dois times. Nenhum alarme do pipeline de dados diz "o atendimento está mentindo", e é exatamente essa tradução que falta. O indicador de idade do acervo precisa aparecer no painel de quem responde ao cliente, não só no de quem ingere
Falha injetadaJob de lote disparado no horário comercial
Onde ela nasceO enriquecimento do catálogo (L95)
Onde o sintoma apareceA latência do atendimento em tempo real (L91) estoura o prazo de 2,5 s, e as ligações são abandonadas
O que se aprendeÉ o incidente das 14h32, e ele atravessa quatro laboratórios. O isolamento de cota (L98) é a correção estrutural; a lição de sistema é que recurso compartilhado cria acoplamento invisível entre times que nunca conversaram
Falha injetadaReordenador de busca indisponível
Onde ela nasceA busca de produto (L94)
Onde o sintoma apareceA conversão cai, o time de marketing investiga campanha por duas semanas, e ninguém olha uma permissão de IAM negada
O que se aprendeDegradação silenciosa vira problema de negócio antes de virar problema técnico, e o dono do sintoma não é o dono da causa. Todo caminho que falha aberto precisa de alarme próprio — é a regra que mais se repete nesta série e a mais fácil de esquecer na peça seguinte
Falha injetadaTrilha de auditoria indisponível
Onde ela nasceA trilha imutável (L97)
Onde o sintoma apareceAs aprovações de reembolso param, corretamente, e o financeiro reporta "sistema fora do ar"
O que se aprendeÉ o comportamento desejado doendo. O sistema inteiro precisa de uma lista declarada do que falha fechado e do que falha aberto, conhecida por quem atende o chamado — senão alguém vai "consertar" tornando a gravação opcional, e o caso da Roberta volta
💡
O padrão comum às quatro
Em todas, a causa e o sintoma pertencem a times diferentes, e o tempo até o diagnóstico é dominado pela distância organizacional, não pela técnica. É a razão de o painel do sistema (a próxima seção) existir, e é a diferença mais concreta entre operar 99 componentes e operar uma plataforma.
Quiz rápido
O L58 mede o failover do Aurora Global isoladamente: RTO de 4h47min, RPO de 2.140 ms. Este laboratório mede o failover do SISTEMA inteiro e chega a um RTO de 4h51min. Qual é a interpretação correta da diferença de 4 minutos?
Observabilidade do sistema: 99 painéis e nenhuma resposta
Somados, os laboratórios anteriores produziram dezenas de painéis e centenas de alarmes, todos corretos. Nenhum deles responde à pergunta que a diretoria faz: a plataforma está saudável agora? Estas são as poucas perguntas de nível de sistema — e "poucas" é requisito, não limitação.
- Um pedido consegue ser seguido, de ponta a ponta, por um único identificador de rastro — da busca (L94) ao checkout (L26), do reembolso (L92) à trilha (L97)? Se a resposta for não, todo diagnóstico começa por remontar o caminho à mão.
- Quais são os cinco indicadores de NEGÓCIO que definem saúde: pedidos por minuto, taxa de conversão da busca, latência do atendimento, fila de revisão humana e decisões automatizadas sem trilha. Nenhum deles é CPU, e cada um mapeia para uma banda.
- Qual a idade dos dados de que cada superfície depende — acervo do RAG, índice de busca, catálogo enriquecido? É o indicador que traduz falha de pipeline em risco de resposta errada ao cliente.
- Quantos alarmes dispararam esta semana, e quantos exigiram ação humana? A razão entre os dois é a métrica de saúde do PLANTÃO, e ela decide se as pessoas ainda leem os alarmes.
- Qual o custo por pedido processado, ponta a ponta, somando todas as bandas? Nenhum laboratório isolado consegue calcular isso, e é o número que o negócio entende.
| Alarme de sistema | Limiar inicial | O que ele pega que nenhum outro pega |
|---|---|---|
| RastroIncompletoPontaAPonta | acima de 5% dos pedidos amostrados | a costura entre dois componentes perdendo o contexto de rastro — o que torna todo incidente cruzado mais lento |
| IdadeDeDadoAcimaDoContrato | qualquer superfície acima do próprio limite | pipeline parado, traduzido para a linguagem de quem atende o cliente |
| AlarmesSemAcaoHumana | acima de 70% dos disparos da semana | fadiga de alarme se instalando — o incidente seguinte será ignorado por um motivo cultural, não técnico |
| CustoPorPedido | acima do dobro da linha de base do trimestre | crescimento de custo distribuído entre bandas, que nenhum orçamento por serviço enxerga |
| DecisaoAutomatizadaSemTrilha | qualquer ocorrência | o requisito de conformidade do sistema inteiro, medido num único número |
Alarme de sistemaRastroIncompletoPontaAPonta
Limiar inicialacima de 5% dos pedidos amostrados
O que ele pega que nenhum outro pegaa costura entre dois componentes perdendo o contexto de rastro — o que torna todo incidente cruzado mais lento
Alarme de sistemaIdadeDeDadoAcimaDoContrato
Limiar inicialqualquer superfície acima do próprio limite
O que ele pega que nenhum outro pegapipeline parado, traduzido para a linguagem de quem atende o cliente
Alarme de sistemaAlarmesSemAcaoHumana
Limiar inicialacima de 70% dos disparos da semana
O que ele pega que nenhum outro pegafadiga de alarme se instalando — o incidente seguinte será ignorado por um motivo cultural, não técnico
Alarme de sistemaCustoPorPedido
Limiar inicialacima do dobro da linha de base do trimestre
O que ele pega que nenhum outro pegacrescimento de custo distribuído entre bandas, que nenhum orçamento por serviço enxerga
Alarme de sistemaDecisaoAutomatizadaSemTrilha
Limiar inicialqualquer ocorrência
O que ele pega que nenhum outro pegao requisito de conformidade do sistema inteiro, medido num único número
Escala do sistema: onde ele quebra primeiro, e não é onde se imagina
Cada laboratório declarou seus próprios limites. Montados, o limite do sistema não é o do componente mais fraco — é o do recurso mais COMPARTILHADO, e ele quase sempre está fora do caminho crítico que as pessoas desenham no quadro.
| Ordem de grandeza | O que quebra primeiro | Por que não é o esperado |
|---|---|---|
| Volume atual | Nada. Cada banda opera com folga dentro do próprio dimensionamento | É o estado em que as decisões de escala são adiadas com razão — e em que a medição da linha de base precisa ser feita, porque depois não haverá calma para isso |
| Dez vezes o volume | A cota de invocação do modelo, compartilhada por quatro times, antes de qualquer CPU, banco ou fila | O instinto aponta para o banco de dados, que é onde doeu nos laboratórios da banda 1. Num sistema com IA em quatro superfícies, a cota do modelo é o recurso escasso, e ela é solicitada com semanas de antecedência — não escalada com um clique |
| Cem vezes o volume | A fila de revisão humana do reembolso (L92) e o plantão de atendimento (L91) — capacidade de PESSOAS, não de máquina | Nenhuma decisão de arquitetura resolve. A alavanca passa a ser reduzir a fração que exige humano, e essa decisão tem um lado de risco que é do negócio, não da engenharia |
| Pico sazonal com campanha | A busca (L94), pela reordenação e geração por consulta, e o custo antes da capacidade | O sistema aguenta e a fatura surpreende. É o cenário em que cache deixa de ser otimização e vira requisito de campanha |
| Perda de uma zona | Nada de relevante, se cada banda cumpriu o próprio dever de casa | É o resultado que o ensaio precisa CONFIRMAR, não presumir — 99 laboratórios afirmando redundância não são uma prova de que o sistema a tem |
Ordem de grandezaVolume atual
O que quebra primeiroNada. Cada banda opera com folga dentro do próprio dimensionamento
Por que não é o esperadoÉ o estado em que as decisões de escala são adiadas com razão — e em que a medição da linha de base precisa ser feita, porque depois não haverá calma para isso
Ordem de grandezaDez vezes o volume
O que quebra primeiroA cota de invocação do modelo, compartilhada por quatro times, antes de qualquer CPU, banco ou fila
Por que não é o esperadoO instinto aponta para o banco de dados, que é onde doeu nos laboratórios da banda 1. Num sistema com IA em quatro superfícies, a cota do modelo é o recurso escasso, e ela é solicitada com semanas de antecedência — não escalada com um clique
Ordem de grandezaCem vezes o volume
O que quebra primeiroA fila de revisão humana do reembolso (L92) e o plantão de atendimento (L91) — capacidade de PESSOAS, não de máquina
Por que não é o esperadoNenhuma decisão de arquitetura resolve. A alavanca passa a ser reduzir a fração que exige humano, e essa decisão tem um lado de risco que é do negócio, não da engenharia
Ordem de grandezaPico sazonal com campanha
O que quebra primeiroA busca (L94), pela reordenação e geração por consulta, e o custo antes da capacidade
Por que não é o esperadoO sistema aguenta e a fatura surpreende. É o cenário em que cache deixa de ser otimização e vira requisito de campanha
Ordem de grandezaPerda de uma zona
O que quebra primeiroNada de relevante, se cada banda cumpriu o próprio dever de casa
Por que não é o esperadoÉ o resultado que o ensaio precisa CONFIRMAR, não presumir — 99 laboratórios afirmando redundância não são uma prova de que o sistema a tem
Custo do sistema: a fatura consolidada e o custo por pedido
Os 99 laboratórios calcularam 99 custos, cada um correto no próprio escopo. A pergunta que só existe aqui é outra: quanto custa um pedido atravessar a plataforma inteira — e onde esse custo está concentrado, que raramente é onde a atenção de engenharia esteve.
| Camada | Peso na fatura | A surpresa |
|---|---|---|
| Computação sempre ligada — contêineres, bancos, domínios de busca | A maior fatia isolada, e a mais previsível | É onde quase toda a atenção de FinOps vai, porque é o que se parece com infraestrutura. Também é a que menos varia com o negócio |
| Modelos e IA — tokens, reordenação, guardrail, extração | Menor do que a intuição sugere depois das alavancas do L89 | A intuição de que "IA é o caro" quase sempre está errada em plataforma madura. O que é caro é IA sem roteamento, sem cache e sem modo de lote |
| Pessoas no laço — revisão de reembolso, plantão, atendimento escalado | Frequentemente a maior de todas, e a única que não aparece na fatura da nuvem | É o achado mais transferível desta série: em três laboratórios diferentes (L91, L92, L96) o minuto humano dominou a conta. Otimizar tokens enquanto a fila humana cresce é otimizar o termo errado |
| Armazenamento com prazo — trilha imutável, saídas de lote, logs | Pequena hoje e monotônica, com um compromisso irreversível dentro | A trilha do L97 não pode ser reduzida depois. É a única linha da fatura que a engenharia não consegue cortar sob pressão |
| Transferência e borda | Pequena, e cheia de linhas que ninguém sabe explicar | É onde aparecem os itens esquecidos dos laboratórios de rede: endereço público ocioso, gateway de tradução esquecido, endpoint em três zonas. Individualmente irrisórios, somados ao longo de 99 laboratórios, não |
CamadaComputação sempre ligada — contêineres, bancos, domínios de busca
Peso na faturaA maior fatia isolada, e a mais previsível
A surpresaÉ onde quase toda a atenção de FinOps vai, porque é o que se parece com infraestrutura. Também é a que menos varia com o negócio
CamadaModelos e IA — tokens, reordenação, guardrail, extração
Peso na faturaMenor do que a intuição sugere depois das alavancas do L89
A surpresaA intuição de que "IA é o caro" quase sempre está errada em plataforma madura. O que é caro é IA sem roteamento, sem cache e sem modo de lote
CamadaPessoas no laço — revisão de reembolso, plantão, atendimento escalado
Peso na faturaFrequentemente a maior de todas, e a única que não aparece na fatura da nuvem
A surpresaÉ o achado mais transferível desta série: em três laboratórios diferentes (L91, L92, L96) o minuto humano dominou a conta. Otimizar tokens enquanto a fila humana cresce é otimizar o termo errado
CamadaArmazenamento com prazo — trilha imutável, saídas de lote, logs
Peso na faturaPequena hoje e monotônica, com um compromisso irreversível dentro
A surpresaA trilha do L97 não pode ser reduzida depois. É a única linha da fatura que a engenharia não consegue cortar sob pressão
CamadaTransferência e borda
Peso na faturaPequena, e cheia de linhas que ninguém sabe explicar
A surpresaÉ onde aparecem os itens esquecidos dos laboratórios de rede: endereço público ocioso, gateway de tradução esquecido, endpoint em três zonas. Individualmente irrisórios, somados ao longo de 99 laboratórios, não
💡
O único número que a diretoria vai perguntar
Custo por pedido processado, com a série dos últimos doze meses ao lado. Ele permite comparar a plataforma com ela mesma, absorve o crescimento e revela regressão sem exigir que ninguém entenda arquitetura. Calcule-o agora, no capstone, dividindo a fatura consolidada pelo volume de negócio — e repare que nenhum dos 99 laboratórios tinha o numerador nem o denominador completos.
Onde IA governa a plataforma, e o limite que continua humano
A série usou IA como assunto de vinte laboratórios. A pergunta do capstone é diferente: onde IA ajuda a OPERAR o sistema inteiro — e onde a resposta continua sendo uma pessoa com nome.
| Aplicação sobre a plataforma | Vale a pena? | Por quê |
|---|---|---|
| Diagnóstico de incidente cruzando bandas | Sim, e é a extensão natural do L96 | O L96 diagnostica um serviço. As quatro injeções de falha desta seção mostram que os incidentes caros atravessam laboratórios, e correlacionar sinais de bandas diferentes é exatamente o trabalho que consome o plantão. Exige o rastro ponta a ponta da seção de observabilidade — sem ele, não há o que correlacionar |
| Previsão de custo e de cota por time | Parcialmente | A previsão de orçamento já vem pronta em serviço gerenciado, como o L89 argumenta. O que não vem pronto, e vale, é prever a COTA de modelo necessária por time com semanas de antecedência — porque aumento de cota não é instantâneo, e é o recurso que quebra primeiro a dez vezes o volume |
| Revisão automatizada de conformidade sobre a trilha | Sim, com humano decidindo | Analisar decisões automatizadas em busca de padrão de viés é uma pergunta que a trilha do L97 tornou respondível, e que um regulador vai fazer. A análise pode ser automatizada; a conclusão precisa de alguém que a assine |
| Um agente com permissão de escrita operando a plataforma | Não, e é a fronteira que esta série inteira defende | Está tecnicamente ao alcance de qualquer pessoa que tenha chegado ao L100 — o L87 tem o laço, o L96 tem as ferramentas, o L98 tem o isolamento. A razão de não fazer não é técnica: é que ninguém ainda demonstrou como auditar, às 3h da manhã, uma ação irreversível decidida por um sistema probabilístico. Quando essa resposta existir, será um laboratório novo, com trilha imutável e reversibilidade no desenho — não uma permissão a mais numa role existente |
Aplicação sobre a plataformaDiagnóstico de incidente cruzando bandas
Vale a pena?Sim, e é a extensão natural do L96
Por quêO L96 diagnostica um serviço. As quatro injeções de falha desta seção mostram que os incidentes caros atravessam laboratórios, e correlacionar sinais de bandas diferentes é exatamente o trabalho que consome o plantão. Exige o rastro ponta a ponta da seção de observabilidade — sem ele, não há o que correlacionar
Aplicação sobre a plataformaPrevisão de custo e de cota por time
Vale a pena?Parcialmente
Por quêA previsão de orçamento já vem pronta em serviço gerenciado, como o L89 argumenta. O que não vem pronto, e vale, é prever a COTA de modelo necessária por time com semanas de antecedência — porque aumento de cota não é instantâneo, e é o recurso que quebra primeiro a dez vezes o volume
Aplicação sobre a plataformaRevisão automatizada de conformidade sobre a trilha
Vale a pena?Sim, com humano decidindo
Por quêAnalisar decisões automatizadas em busca de padrão de viés é uma pergunta que a trilha do L97 tornou respondível, e que um regulador vai fazer. A análise pode ser automatizada; a conclusão precisa de alguém que a assine
Aplicação sobre a plataformaUm agente com permissão de escrita operando a plataforma
Vale a pena?Não, e é a fronteira que esta série inteira defende
Por quêEstá tecnicamente ao alcance de qualquer pessoa que tenha chegado ao L100 — o L87 tem o laço, o L96 tem as ferramentas, o L98 tem o isolamento. A razão de não fazer não é técnica: é que ninguém ainda demonstrou como auditar, às 3h da manhã, uma ação irreversível decidida por um sistema probabilístico. Quando essa resposta existir, será um laboratório novo, com trilha imutável e reversibilidade no desenho — não uma permissão a mais numa role existente
Anti-padrões de quem tenta "fechar" um capstone rápido demais
Estes não são erros de um serviço — são erros de como alguém tenta "fechar" um projeto de síntese como este, e cada um já aconteceu em revisão real de sistema grande.
| Erro | Por que alguém faz | Sintoma em produção | Forma correta |
|---|---|---|---|
| Revisar cada serviço isolado e chamar de "revisão completa" | é mais fácil dividir o trabalho por especialidade e nunca juntar | risco que só existe na INTERAÇÃO entre serviços nunca aparece em nenhuma revisão individual | um workload só, cobrindo as áreas juntas, como este laboratório faz |
| Forçar todo pilar para risco baixo no relatório final | o capstone "deveria" parecer o ápice, e risco alto soa como fracasso | cliente confia num relatório que esconde exatamente a dívida que mais importa saber antes de assinar | registrar risco alto genuíno com dono e prazo — mesmo sem solução pronta |
| Medir RTO só do componente mais fácil de isolar | testar o banco sozinho é mais simples que orquestrar um jogo de guerra completo | RTO real do sistema aparece só quando o cliente sente, na primeira falha de verdade | medir o caminho crítico completo, mesmo custando mais tempo de ensaio |
| Tratar região de residência (L99) como capacidade de DR de brinde | "já que a região existe, deve servir para failover também" parece economia | na hora do incidente, ninguém sabe se aquela região aguenta o volume total — porque nunca foi dimensionada para isso | declarar explicitamente que residência e capacidade de DR são garantias independentes |
ErroRevisar cada serviço isolado e chamar de "revisão completa"
Por que alguém fazé mais fácil dividir o trabalho por especialidade e nunca juntar
Sintoma em produçãorisco que só existe na INTERAÇÃO entre serviços nunca aparece em nenhuma revisão individual
Forma corretaum workload só, cobrindo as áreas juntas, como este laboratório faz
ErroForçar todo pilar para risco baixo no relatório final
Por que alguém fazo capstone "deveria" parecer o ápice, e risco alto soa como fracasso
Sintoma em produçãocliente confia num relatório que esconde exatamente a dívida que mais importa saber antes de assinar
Forma corretaregistrar risco alto genuíno com dono e prazo — mesmo sem solução pronta
ErroMedir RTO só do componente mais fácil de isolar
Por que alguém faztestar o banco sozinho é mais simples que orquestrar um jogo de guerra completo
Sintoma em produçãoRTO real do sistema aparece só quando o cliente sente, na primeira falha de verdade
Forma corretamedir o caminho crítico completo, mesmo custando mais tempo de ensaio
ErroTratar região de residência (L99) como capacidade de DR de brinde
Por que alguém faz"já que a região existe, deve servir para failover também" parece economia
Sintoma em produçãona hora do incidente, ninguém sabe se aquela região aguenta o volume total — porque nunca foi dimensionada para isso
Forma corretadeclarar explicitamente que residência e capacidade de DR são garantias independentes
Síntese: o que cada banda entregou ao sistema final
Não é menção genérica — cada linha nomeia o artefato real que sobrevive no sistema hoje, não um resumo do que a banda "tratava de".
| Banda | Faixa | O que contribuiu para o sistema final |
|---|---|---|
| 1 — Aplicação completa | L01–L10 | o substrato que TODA área ainda roda: ECS Fargate com digest imutável, rede privada, segredo rotacionado (L04), backup com RTO ensaiado (L10) — reaproveitado literalmente no runbook do jogo de guerra |
| 2 — API e dados | L11–L20 | cota por cliente (L11) na frente dos 4 times de hoje, e a disciplina de "banco pela carga" (L14) que evitou forçar tudo em um único motor de banco |
| 3 — Serverless e eventos | L21–L30 | o barramento (L24) que hoje roteia tanto o alarme de incidente do L96 quanto qualquer evento novo entre os quatro times, sem integração ponto a ponto |
| 4 — Distribuídos | L31–L40 | o corte de monolito pela fronteira de transação certa (L31) e o retry com backoff e jitter (L36) que protege toda chamada ao Bedrock hoje, generativa ou clássica |
| 5 — Segurança e redes | L41–L50 | menor privilégio derivado de uso real (L41) e multi-conta com SCP (L43) — a MESMA árvore de contas que o L98 estendeu para isolar cota por time, e que este laboratório reaproveita para as contas do jogo de guerra |
| 6 — Observabilidade e FinOps | L51–L60 | telemetria correlacionada (L51) que vira sinal de entrada do agente diagnóstico (L96), o runbook de DR do componente crítico (L58) que este laboratório estende para o sistema inteiro, e o próprio workload do Well-Architected Tool (L60) que esta revisão reaproveita sem recriar |
| 7 — Dados e analytics | L61–L70 | o lake em camadas (L62) que alimenta tanto o BI quanto o RAG do L83, e a governança por coluna (L69) que o L97 reaproveita para decidir quem lê a trilha de decisão |
| 8 — ML e MLOps | L71–L80 | a disciplina de comparar contra baseline de regra antes de confiar em modelo (L71) e os quatro modos de inferência medidos por custo e latência (L74) — o antídoto contra ML decorativo que sustenta toda a banda 9 |
| 9 — IA generativa e agentes | L81–L90 | RAG com citação (L83), agente com ferramenta escopada por IAM (L87), avaliação com golden set e juiz com viés medido (L88) — o núcleo de IA que este laboratório revisa, não redesenha |
| 10 — Soluções integradas | L91–L99 | nove sistemas que já combinavam domínio — do atendimento por voz (L91) à residência multi-região (L99) — e cuja SOMA, sem revisão de conjunto, é exatamente o vão que este laboratório fecha |
Banda1 — Aplicação completa
FaixaL01–L10
O que contribuiu para o sistema finalo substrato que TODA área ainda roda: ECS Fargate com digest imutável, rede privada, segredo rotacionado (L04), backup com RTO ensaiado (L10) — reaproveitado literalmente no runbook do jogo de guerra
Banda2 — API e dados
FaixaL11–L20
O que contribuiu para o sistema finalcota por cliente (L11) na frente dos 4 times de hoje, e a disciplina de "banco pela carga" (L14) que evitou forçar tudo em um único motor de banco
Banda3 — Serverless e eventos
FaixaL21–L30
O que contribuiu para o sistema finalo barramento (L24) que hoje roteia tanto o alarme de incidente do L96 quanto qualquer evento novo entre os quatro times, sem integração ponto a ponto
Banda4 — Distribuídos
FaixaL31–L40
O que contribuiu para o sistema finalo corte de monolito pela fronteira de transação certa (L31) e o retry com backoff e jitter (L36) que protege toda chamada ao Bedrock hoje, generativa ou clássica
Banda5 — Segurança e redes
FaixaL41–L50
O que contribuiu para o sistema finalmenor privilégio derivado de uso real (L41) e multi-conta com SCP (L43) — a MESMA árvore de contas que o L98 estendeu para isolar cota por time, e que este laboratório reaproveita para as contas do jogo de guerra
Banda6 — Observabilidade e FinOps
FaixaL51–L60
O que contribuiu para o sistema finaltelemetria correlacionada (L51) que vira sinal de entrada do agente diagnóstico (L96), o runbook de DR do componente crítico (L58) que este laboratório estende para o sistema inteiro, e o próprio workload do Well-Architected Tool (L60) que esta revisão reaproveita sem recriar
Banda7 — Dados e analytics
FaixaL61–L70
O que contribuiu para o sistema finalo lake em camadas (L62) que alimenta tanto o BI quanto o RAG do L83, e a governança por coluna (L69) que o L97 reaproveita para decidir quem lê a trilha de decisão
Banda8 — ML e MLOps
FaixaL71–L80
O que contribuiu para o sistema finala disciplina de comparar contra baseline de regra antes de confiar em modelo (L71) e os quatro modos de inferência medidos por custo e latência (L74) — o antídoto contra ML decorativo que sustenta toda a banda 9
Banda9 — IA generativa e agentes
FaixaL81–L90
O que contribuiu para o sistema finalRAG com citação (L83), agente com ferramenta escopada por IAM (L87), avaliação com golden set e juiz com viés medido (L88) — o núcleo de IA que este laboratório revisa, não redesenha
Banda10 — Soluções integradas
FaixaL91–L99
O que contribuiu para o sistema finalnove sistemas que já combinavam domínio — do atendimento por voz (L91) à residência multi-região (L99) — e cuja SOMA, sem revisão de conjunto, é exatamente o vão que este laboratório fecha
Checklist de produção
- Workload único no Well-Architected Tool cobrindo aplicação, dados, IA, segurança e observabilidade — não seis workloads separados.
- Pelo menos uma resposta por pilar citando laboratório e evidência real, com risco classificado sem maquiagem.
- Milestone salvo desta revisão, comparável na próxima cadência trimestral herdada do L60.
- Réplica quente da Knowledge Base do RAG em us-west-2, com cutover medido abaixo de 2 minutos.
- Cota de Bedrock pré-provisionada nas 4 contas de time em us-west-2, não dependente de pedido sob demanda.
- Réplica contínua do bucket de trilha imutável (L97), com Object Lock preservado no destino e defasagem medida.
- Runbook de failover do L58 testado dentro do sistema integrado, não só isoladamente contra o banco.
- Relatório de RTO/RPO do sistema exportado, com os quatro componentes do caminho crítico nomeados separadamente.
- Tabela de síntese banda → contribuição revisada e publicada junto do relatório Well-Architected.
- Risco de sustentabilidade registrado como alto, com nota explícita de que nenhum dos 100 laboratórios o resolveu.
Quando algo não funciona no sistema inteiro
Estes cinco sintomas não pertencem a nenhum laboratório. Aparecem só depois que tudo está montado, e o tempo até o diagnóstico é dominado por saber ONDE olhar.
| Sintoma | Causa provável | Como investigar | Log ou métrica | Correção |
|---|---|---|---|---|
| O cliente recebe informação errada, e cada componente parece correto | Dado defasado atravessando a costura: acervo, índice ou catálogo antigo | Comparar a idade de cada superfície de dado com o próprio contrato, antes de investigar qualquer código | Idade de dado por superfície | É a primeira coisa a checar em qualquer reclamação de conteúdo. Componente correto servindo dado velho é o modo de falha mais comum de uma plataforma madura |
| Latência ruim em um serviço sem nenhuma mudança nele | Recurso compartilhado consumido por outro time — cota de modelo, banco, cota de log | Olhar o consumo do recurso compartilhado por time no período, não as métricas do serviço afetado | Consumo de cota por time | É o incidente das 14h32 em qualquer forma. Sem visão por time, o serviço afetado investiga a si mesmo indefinidamente |
| Um pedido não pode ser seguido ponta a ponta | Contexto de rastro perdido numa fronteira — fila, evento ou chamada entre contas | Enviar um pedido de teste e verificar em que salto o identificador some | Rastros incompletos, por fronteira | Propagar o contexto na fronteira. Cada perda dessas multiplica o tempo de todo incidente futuro que atravessar ali |
| A fatura cresceu e nenhum time reconhece o aumento | Custo distribuído entre bandas, ou recurso sem etiqueta caindo no não alocado | Comparar custo por pedido com o do trimestre anterior antes de olhar serviço por serviço | Custo por pedido; balde de não alocado | Se o custo por pedido está estável, o crescimento é do negócio e está tudo certo. É a primeira pergunta, e quase ninguém faz |
| O plantão parou de reagir aos alarmes | Fadiga: proporção alta de alarmes que não exigem ação | Contar disparos contra ações humanas na semana | Alarmes sem ação humana | Desligar ou recalibrar os ruidosos. Um alarme que ninguém lê é pior que nenhum alarme, porque cria a impressão de cobertura |
SintomaO cliente recebe informação errada, e cada componente parece correto
Causa provávelDado defasado atravessando a costura: acervo, índice ou catálogo antigo
Como investigarComparar a idade de cada superfície de dado com o próprio contrato, antes de investigar qualquer código
Log ou métricaIdade de dado por superfície
CorreçãoÉ a primeira coisa a checar em qualquer reclamação de conteúdo. Componente correto servindo dado velho é o modo de falha mais comum de uma plataforma madura
SintomaLatência ruim em um serviço sem nenhuma mudança nele
Causa provávelRecurso compartilhado consumido por outro time — cota de modelo, banco, cota de log
Como investigarOlhar o consumo do recurso compartilhado por time no período, não as métricas do serviço afetado
Log ou métricaConsumo de cota por time
CorreçãoÉ o incidente das 14h32 em qualquer forma. Sem visão por time, o serviço afetado investiga a si mesmo indefinidamente
SintomaUm pedido não pode ser seguido ponta a ponta
Causa provávelContexto de rastro perdido numa fronteira — fila, evento ou chamada entre contas
Como investigarEnviar um pedido de teste e verificar em que salto o identificador some
Log ou métricaRastros incompletos, por fronteira
CorreçãoPropagar o contexto na fronteira. Cada perda dessas multiplica o tempo de todo incidente futuro que atravessar ali
SintomaA fatura cresceu e nenhum time reconhece o aumento
Causa provávelCusto distribuído entre bandas, ou recurso sem etiqueta caindo no não alocado
Como investigarComparar custo por pedido com o do trimestre anterior antes de olhar serviço por serviço
Log ou métricaCusto por pedido; balde de não alocado
CorreçãoSe o custo por pedido está estável, o crescimento é do negócio e está tudo certo. É a primeira pergunta, e quase ninguém faz
SintomaO plantão parou de reagir aos alarmes
Causa provávelFadiga: proporção alta de alarmes que não exigem ação
Como investigarContar disparos contra ações humanas na semana
Log ou métricaAlarmes sem ação humana
CorreçãoDesligar ou recalibrar os ruidosos. Um alarme que ninguém lê é pior que nenhum alarme, porque cria a impressão de cobertura
Limpeza: o que o jogo de guerra deixa para trás
Diferente dos outros 99 laboratórios, este não cria a infraestrutura de aplicação — ela já existe em produção, construída pelos 99 anteriores. A limpeza aqui é sobre o que o jogo de guerra provisionou: a conta de exercício com dado sintético, e a confirmação de que o failback devolveu o tráfego real para us-east-1.
encerrar-jogo-de-guerra.sh
# encerrar-jogo-de-guerra.sh -- este laboratorio NAO cria infraestrutura
# nova de aplicacao; ele reaproveita o que os 99 anteriores ja tem no ar
# em producao. O que precisa ser desfeito e SO o que o proprio jogo de
# guerra provisionou para o ensaio.
# 1) Failback: promover us-east-1 de volta a primario, quando a regiao
# voltar -- o MESMO runbook do L58, na direcao inversa.
aws rds failover-global-cluster \
--global-cluster-identifier cadencia-global \
--target-db-cluster-identifier cadencia-primario
# 2) Route 53: confirmar que o DNS voltou a apontar para us-east-1
# depois do failback, nao ficou preso em us-west-2
aws route53 test-dns-answer --hosted-zone-id Z0123456789ABC \
--record-name api.cadencia.com.br --record-type A
# 3) A replica quente da Knowledge Base e a cota pre-provisionada em
# us-west-2 NAO se desfazem -- viraram parte da arquitetura de
# producao, remediacao permanente do risco medio de confiabilidade.
# Desfaze-las devolveria o sistema ao RTO pior que este laboratorio
# mediu ANTES da remediacao.
# 4) O que E temporario: a conta de exercicio com dado sintetico usada
# para nao tocar decisao real de cliente durante o jogo de guerra.
aws organizations close-account --account-id 333300000099
# 5) Milestone do Well-Architected Tool continua salvo -- nunca se apaga
# um milestone; a proxima revisao trimestral cria um novo, nao edita
# este.
⚠️
O que NÃO se desliga depois deste laboratório
A réplica quente da Knowledge Base e a cota pré-provisionada de Bedrock em us-west-2 continuam cobrando depois do jogo de guerra terminar — e é intencional: são a remediação do risco médio de confiabilidade, não um artefato de teste. Desligá-las por engano, achando que fazem parte da "limpeza do laboratório", devolveria o sistema ao RTO que só existia ANTES desta revisão.
Fixando
Quiz rápido
A revisão Well-Architected deste laboratório, sobre um sistema com 99 laboratórios de decisão por trás, termina com cinco pilares em risco baixo e um (sustentabilidade) em risco alto sem solução prevista. Um revisor sugere: "para o capstone da série ficar completo, vamos declarar esse risco como aceito por decisão de negócio, já que a série está terminando". Por que essa sugestão é um erro?
Quiz rápido
Alguém lê a tabela de síntese "banda → contribuição" deste laboratório e conclui: "então o sistema final é só a soma das 99 decisões anteriores, e este último laboratório apenas documentou isso". O que essa leitura ignora?
Desafio — sem roteiro
💡
O requisito
Injete uma falha que NÃO estava entre os modos de falha já testados no capstone (por exemplo: a dependência de IA fica indisponível no meio de uma sessão de usuário em andamento, não antes dela começar) e produza um post-mortem completo do incidente simulado.
⚠️
Critério de aceite — executável, não "verifique se funciona"
O post-mortem escrito segue uma linha do tempo real (com timestamps do próprio teste) cobrindo: quando a falha foi injetada, quando o sistema/observabilidade a detectou, qual foi o comportamento visível para o usuário durante a janela de falha, e a ação de mitigação — mesmo que a mitigação seja "nenhuma automática, correção manual necessária" (isso também é uma conclusão válida, se for a verdade).
- Dica 1: Escolha um ponto de falha que atravesse pelo menos DUAS das capacidades já construídas no capstone (ex: observabilidade + resiliência) — um post-mortem de uma falha isolada de uma camada só testa menos do que o capstone integrou.
- Dica 2: Rode a sessão de usuário simulada ANTES de injetar a falha, para ter um "antes" claro no timeline — um teste que já começa com a falha ativa não separa o comportamento normal do degradado.
- Dica 3: Se a conclusão do post-mortem for "o sistema não tinha proteção para isso", essa é uma conclusão legítima e esperada em pelo menos alguns casos — o objetivo do desafio é o RIGOR do post-mortem, não que o sistema saia ileso.
✅
Lembrete de limpeza
Todo recurso que este desafio criar entra no mesmo `terraform destroy` do laboratório — nada fica para trás cobrando sozinho.
Perguntas frequentes
❓ Por que o RTO do sistema inteiro é maior que o RTO que o L58 media só no banco?
O RTO do sistema soma a detecção multi-conta e o cutover final de DNS ao redor da mesma promoção de banco que o L58 já media, e não porque o banco ficou mais lento. A promoção do Aurora Global continuou levando exatamente 4h47min nos dois ensaios — o número que mudou foi o ESCOPO da medição, de "até o banco promover" para "até o cliente ser atendido de novo por todas as quatro áreas do sistema". É a mesma lição que aparece na avaliação do L88: medir só um componente esconde o resto do caminho, mesmo quando esse componente é genuinamente o mais lento.
❓ Este laboratório final segue o mesmo formato mínima → produção → evolução dos outros 99?
Não integralmente — ele é o único da série que substitui a arquitetura mínima por uma visão integrada do sistema já em produção, porque não existe "versão mínima" de um sistema construído ao longo de 99 laboratórios anteriores. Os dois `arch_diagram` aqui mostram, respectivamente, a visão de conjunto do sistema e um cenário de failover regional — topologias genuinamente diferentes, mas nenhuma delas é uma "mínima didática" no sentido dos outros laboratórios. A evolução em níveis continua presente, só que descreve a maturidade da plataforma inteira, não de uma técnica isolada.
❓ Por que sustentabilidade continua como risco alto depois de 100 laboratórios?
Porque nenhum dos 100 laboratórios da série, incluindo este, tomou uma decisão de arquitetura por critério de sustentabilidade — nem escolha de região, nem tipo de instância, nem padrão de escala. O L60 encontrou essa ausência total depois do laboratório 59; este capstone, depois do laboratório 100, confirma que ela nunca foi endereçada. Registrar isso como risco alto sem solução é mais honesto do que forçar o relatório final a fechar todo verde só porque é o último módulo da série — um relatório sem nenhum risco alto depois de cem laboratórios seria o sinal mais forte de revisão malfeita.
❓ A região de residência em Portugal participa do failover entre us-east-1 e us-west-2?
Não, e essa separação é o próprio ponto que o diagrama de failover deste laboratório existe para provar. A região eu-central-1 do L99 foi criada só para atender ao requisito de residência de dado dos 40 lojistas portugueses sob GDPR, com capacidade dimensionada para essa fatia pequena do tráfego — nunca foi provisionada com capacidade para assumir o volume das 900 lojas brasileiras. Confundir "região que existe por requisito de residência" com "capacidade de DR pronta para uso" é exatamente o erro que a certificação profissional mais gosta de cobrar em cenário de prova.
❓ O golden set e o juiz LLM do L88 continuam válidos quando o RAG do L83 muda de versão?
Continuam válidos como processo, mas exigem reexecução a cada mudança relevante. Qualquer alteração no modelo de geração do L83, no modelo-juiz do L88 ou no próprio golden set precisa disparar a suíte de avaliação de novo, porque o viés medido — comprimento de resposta, preferência por saída do mesmo modelo — pode mudar de magnitude entre versões. Este laboratório não altera o L88 nem o L83: ele assume que a disciplina de reavaliação continuada, já estabelecida naqueles dois módulos, continua rodando a cada PR que muda prompt ou modelo em produção.
❓ Por que a trilha do L97 não depende da promoção do Aurora Global?
Porque o S3 Object Lock garante durabilidade do registro independente de a região inteira estar acessível, e a réplica contínua em us-west-2 mantém uma cópia legível com Object Lock preservado desde antes do incidente, não só a partir dele. A defasagem de replicação medida (640 ms p99) é bem menor que o tempo de promoção do banco (4h47min), então a auditoria de conformidade consegue ler qualquer decisão de reembolso passada durante o próprio incidente, sem esperar o Aurora Global terminar de promover.
❓ O que o projeto final prova que os 99 laboratórios isolados não provavam?
Prova que revisar cada componente separadamente deixa passar risco que só existe na interação entre eles. A cota de Bedrock não duplicada por conta e região em us-west-2 é um exemplo real: nenhum dos 99 laboratórios tinha motivo para descobrir esse risco sozinho, porque nenhum testava failover regional com quatro contas de time simultâneas — só a revisão Well-Architected sobre o sistema inteiro, somada ao jogo de guerra que mede RTO e RPO do caminho crítico completo, produziu essa informação genuinamente nova.
✅
Fim da série — e o que continua em aberto, de propósito
Não há próximo laboratório — este é o fim da série de 100. O que existe depois não é um L101: é a Cadência operando o sistema revisado, com a próxima cadência trimestral de Well-Architected (herdada do L60) agendada, e o risco de sustentabilidade registrado, com dono ainda em aberto, esperando o laboratório que a série ainda não escreveu. Se você chegou até aqui tendo passado pelos 99 anteriores, o que você tem não é uma coleção de laboratórios — é a competência de olhar um sistema inteiro e saber exatamente onde ele ainda mente para você.
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…