---
schema_version: "1"
id: 9310fe279a8e4a709eabfe36849873ec66c408831abbf932ffde8a9a665a8731
title: Melhoria contínua – Padrões
collection: architect
version: current
locale: pt-br
portal_url: https://docs.salesforce.com/architect/current/pt-br/well-architected/guides/operational-excellence-continuous-improvement-patterns.md
canonical_url: https://architect.salesforce.com/docs/architect/pt-br/well-architected/guide/operational-excellence-continuous-improvement-patterns.html
source_site: architect.salesforce.com
content_type: documentation
content_hash: 9886dc2836a658f98363ff488bb3c4c96b9e39eea70ec1f51067bc7925a8678a
products:
  - Estrutura bem arquitetada
  - Architect Site Content Repo
---
# Melhoria contínua – Padrões

Saiba mais sobre a [excelência operacional](/docs/architect/pt-br/well-architected/guide/operational-excellence.html) bem-construída → [Melhoria contínua](/docs/architect/pt-br/well-architected/guide/operational-excellence.html#continuous-improvement)

## Métricas operacionais e DORA

**Padrões**

| Onde procurar | Qual é a boa aparência |
| --- | --- |
| Plataforma \| DORA | ✅ A frequência da implantação é rastreada; as equipes com movimento mais rápido são implementadas sob demanda, geralmente várias vezes por dia |
| Plataforma \| DORA | ✅ O tempo de processamento para alterações é medido do compromisso de código à implementação de produção; o tempo de processamento subdia indica entrega de alto desempenho e o tempo de processamento subhorário indica capacidade excepcional |
| Plataforma \| DORA | ✅ A taxa de falha de alteração é rastreada como a porcentagem de implantações que causam incidentes de produção que exigem remediação e mantida consistentemente baixa |
| Plataforma \| DORA | ✅ O tempo de recuperação da implementação com falha é medido; a recuperação em menos de uma hora indica a maturidade da entrega |
| Plataforma \| DORA | ✅ A taxa de retrabalho da implantação é rastreada como a proporção de implantações não planejadas resultantes de incidentes de produção |
| Plataforma \| DORA | ✅ As métricas são organizadas em fatores de taxa de transferência (tempo de processamento, frequência da implementação, tempo de recuperação da implementação com falha) e instabilidade (taxa de falha de alteração, taxa de retrabalho) |
| Plataforma \| Métricas | ✅ As métricas DORA são medidas continuamente e trazem tendências ao longo do tempo, com a trajetória de melhoria ponderada mais do que os valores absolutos |
| Plataforma \| Painéis | ✅ As métricas são rastreadas em painéis operacionais visíveis para toda a organização, criando transparência sobre o desempenho operacional |

**Anti-Padrões**

| Onde procurar | Qual é a aparência ruim |
| --- | --- |
| Plataforma \| DORA | ⚡️ A baixa frequência de implantação reflete as equipes que evitam a dor da implantação, criando um ciclo vicioso em que uma implantação infrequente torna cada implantação mais arriscada |
| Plataforma \| DORA | ⚡️ Longos tempos de processamento refletem sobrecarga excessiva do processo, automação insuficiente ou disfunção organizacional |
| Plataforma \| DORA | ⚡️ Uma alta taxa de falha de alteração reflete testes insuficientes, validação de implementação inadequada ou alterações apressadas sem verificações de qualidade adequadas |
| Plataforma \| DORA | ⚡️ Longos tempos de recuperação refletem validação de implementação insuficiente, falta de reversão automatizada ou propriedade não clara de incidentes de produção |
| Plataforma \| DORA | ⚡️ Uma alta taxa de retrabalho mostra incidentes de produção gerando rotineiramente implantações de emergência, sinalizando lacunas em testes pré-produção, validação de versão ou gerenciamento de mudanças |
| Plataforma \| Métricas | As métricas são capturadas como instantâneos de ponto no tempo, em vez de traçar tendências ao longo do tempo, ocultando se o desempenho operacional está melhorando ou diminuindo |

## Retrospectivas e revisões

**Padrões**

| Onde procurar | Qual é a boa aparência |
| --- | --- |
| Plataforma \| Processo | ✅ Retrospectivas de sprint ocorrem regularmente (todos os sprints ou mensalmente) criando um ritmo para reflexão em vez de esperar por crises |
| Plataforma \| Processo | ✅ Os retrospectivas usam formatos estruturados (Iniciar/Parar/Continuar, Mal-entendido/Feliz, Linha do tempo) que incentivam a participação e resultados acionáveis |
| Plataforma \| Processo | ✅ Os facilitadores são alternados para evitar que qualquer pessoa domine a discussão |
| Plataforma \| Processo | ✅ Percepções retrospectivas são convertidas em itens de ação concretos com proprietários e datas de conclusão, produzindo um pequeno número de melhorias por sessão |
| Plataforma \| Processo | ✅ A conclusão do item de ação é rastreada entre retrospectivas, mantendo as equipes responsáveis pelo acompanhamento |
| Plataforma \| Operações | ✅ As análises operacionais avaliam a integridade operacional agregada trimestralmente ou mensalmente, examinando dados de tendência e comparando com os objetivos |
| Plataforma \| Operações | ✅ Revisões operacionais engajam a liderança para proteger recursos para trabalho de melhoria operacional que compete com o desenvolvimento de recursos |
| Plataforma \| Operações | ✅ As análises incluem métricas operacionais: disponibilidade em relação à meta por jornada, tendências de latência por percentil, contagens de incidentes por gravidade com tempo médio para detectar e resolver, frequência e taxa de sucesso da implementação e carga operacional, como páginas na chamada e horas de trabalho |

**Anti-Padrões**

| Onde procurar | Qual é a aparência ruim |
| --- | --- |
| Plataforma \| Processo | ⚡️ Os retrospectivos esperam por crises em vez de ocorrer em um ritmo regular |
| Plataforma \| Processo | ⚡️ As retrospectivas geram discussão longa, mas sem ação, desperdiçando tempo e gerando cinismo |
| Plataforma \| Processo | Os itens de ação são definidos sem proprietários ou datas de conclusão, portanto, as melhorias são discutidas, mas nunca implementadas |
| Plataforma \| Processo | ⚡️ A conclusão do item de ação nunca é rastreada entre retrospectivas, deixando o acompanhamento desconhecido |
| Plataforma \| Operações | ⚡️ As operações são tratadas como trabalho em segundo plano invisível recebendo atenção apenas durante as crises, sem revisão operacional regular |
| Plataforma \| Operações | ⚡️ As análises operacionais não têm engajamento de liderança, portanto, o trabalho de melhoria perde para o desenvolvimento de recursos quando os recursos são alocados |

## Revisão de prontidão operacional

**Padrões**

| Onde procurar | Qual é a boa aparência |
| --- | --- |
| Plataforma \| Operações | ✅ Revisões de prontidão operacional avaliam se novos recursos ou sistemas atendem aos requisitos operacionais antes do lançamento da produção |
| Plataforma \| Operações | ✅ As revisões são realizadas antes do lançamento da produção de novas soluções, principais recursos ou alterações arquitetônicas com implicações operacionais |
| Plataforma \| Operações | ✅ O momento da revisão é equilibrado para que a implementação seja concluída o suficiente para avaliar sem preocupações operacionais chegando tarde demais para serem tratadas |
| Plataforma \| Monitoramento | ✅ A revisão confirma que as métricas suficientes estão instrumentadas, existem alertas para cenários de falha e os painéis mostram o status de saúde |
| Plataforma \| Documentação | ✅ A revisão confirma que os manuais existem para operações comuns, a arquitetura está documentada para os respondentes e os procedimentos de escalação estão claros |
| Plataforma \| Implantação | ✅ A revisão confirma que a implementação é executada com confiança, existe um procedimento de reversão e a implementação foi validada no preparo |
| Plataforma \| Desempenho | ✅ A revisão confirma que as metas de desempenho são validadas sob carga realista, há espaço para crescimento e os riscos de limite do regulador são avaliados |
| Plataforma \| Segurança | ✅ A revisão confirma que as revisões de segurança estão concluídas, os requisitos de auditoria são atendidos e o controle de acesso corresponde aos requisitos |
| Plataforma \| Dependências | ✅ A revisão confirma que as dependências externas foram identificadas, os parceiros de integração têm acordos de nível de serviço e o comportamento de fallback existe para falhas de dependência |
| Plataforma \| Governança | ✅ O lançamento da produção está marcado na conclusão da revisão, tornando as preocupações operacionais requisitos de implantação mais adequados do que o melhor esforço |

**Anti-Padrões**

| Onde procurar | Qual é a aparência ruim |
| --- | --- |
| Plataforma \| Governança | ⚡️ Novos recursos são lançados para produção sem uma avaliação de prontidão operacional, acumulando débito operacional que torna a excelência operacional futura cada vez mais difícil |
| Plataforma \| Operações | ⚡️ A revisão é realizada tarde demais, portanto, preocupações operacionais parecem bloqueadores de implementação e criam pressão para ignorar correções |
| Plataforma \| Governança | ⚡️ A prontidão operacional é tratada como um requisito de melhor esforço, em vez de um requisito de implantação |

## Loops de feedback e cultura de aprendizado

**Padrões**

| Onde procurar | Qual é a boa aparência |
| --- | --- |
| Plataforma \| Cultura | ✅ Segurança psicológica permite a discussão honesta de problemas, erros e quase erros sem medo de punição |
| Plataforma \| Cultura | ✅ A segurança psicológica é criada por meio de trabalhos pós-mortems inocentes, comemorando a descoberta de problemas e a vulnerabilidade de modelagem de liderança discutindo seus próprios erros |
| Plataforma \| Métricas | ✅ A medição torna o estado operacional visível por meio de métricas operacionais, tendências de incidentes, indicadores DORA e pontuações de satisfação do usuário, permitindo a priorização objetiva do trabalho de melhoria |
| Plataforma \| Operações | ✅ A capacidade de engenharia é reservada intencionalmente para melhoria operacional, redução de débito técnico e investimento em ferramentas e automação |
| Plataforma \| Operações | ✅ Os loops de feedback conectam a experiência operacional a decisões de design, de modo que os incidentes conduzem a melhorias arquitetônicas, o monitoramento conduz a otimização e as falhas de implementação conduzem a melhorias na cobertura de teste |

**Anti-Padrões**

| Onde procurar | Qual é a aparência ruim |
| --- | --- |
| Plataforma \| Cultura | ⚡️ Equipes sem segurança psicológica ocultam problemas até serem catastróficos, impedindo intervenção precoce |
| Plataforma \| Operações | ⚡️ As equipes gastam toda a capacidade em recursos sem tempo para melhoria operacional, acumulando débito técnico e operacional que, por fim, força a resposta à crise |
| Plataforma \| Operações | ⚡️ A experiência operacional não é alimentada novamente no design, portanto, as mesmas fraquezas se repetem e as operações são gradualmente reduzidas em vez de melhorar |
