--- schema_version: "1" id: 86222537ddde50d19302b078de49848522141d0dc46090755081cf557834ad94 title: Gerenciamento de incidente – Padrões collection: architect version: current locale: pt-br portal_url: https://docs.salesforce.com/architect/current/pt-br/well-architected/guides/operational-excellence-incident-patterns.md canonical_url: https://architect.salesforce.com/docs/architect/pt-br/well-architected/guide/operational-excellence-incident-patterns.html source_site: architect.salesforce.com content_type: documentation content_hash: ed5869d95bcf2c95c91ba664a868310e22b3d95c2476fe9d5fd1c0e4cee26d1f products: - Estrutura bem arquitetada - Architect Site Content Repo --- # Gerenciamento de incidente – Padrões Saiba mais sobre a [excelência operacional](/docs/architect/pt-br/well-architected/guide/operational-excellence.html) bem arquitetada → [Gerenciamento de incidentes](/docs/architect/pt-br/well-architected/guide/operational-excellence.html#incident-management) ## Detecção e alerta de incidentes **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Plataforma \| Monitoramento | ✅ A arquitetura de alerta inclui o encaminhamento de incidentes críticos de classificação de gravidade (produção indisponível, corrupção de dados, compromisso de segurança) para a chamada da página imediatamente | | Plataforma \| Monitoramento | ✅ Incidentes de alta gravidade (desempenho reduzido, interrupção parcial) geram notificações imediatas para investigação imediata de horário comercial | | Plataforma \| Monitoramento | ✅ Avisos (limites se aproximando, desvio de configuração) agregados em resumo diário para remediação proativa | | Plataforma \| Monitoramento | ✅ O aprimoramento de alerta inclui o contexto de diagnóstico: contagem de usuários afetados, percentis de taxa de erro, implantações recentes, alertas relacionados e links diretos do painel | | Plataforma \| Monitoramento | ✅ O contexto do alerta reduz o tempo médio para confirmar fornecendo avaliação de situação imediata sem coletar informações básicas por meio de consultas separadas | | Plataforma \| Monitoramento | ✅ O agrupamento de alertas evita tempestades de alerta consolidando centenas de alertas relacionados de um único problema subjacente em uma notificação com estatísticas agregadas | | Plataforma \| Monitoramento | ✅ Alertas agrupados mostram a contagem, a taxa e as transações afetadas revelando o padrão de problema sem sobrecarregar os respondentes | | Plataforma \| Monitoramento | ✅ A supressão de alerta impede que condições de transição conhecida gerem alertas durante janelas de manutenção esperadas ou períodos de remediação automática | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Plataforma \| Monitoramento | ⚡️ A falha de integração gera 100 mil alertas individuais em 5 minutos de telefone de chamada, cada alerta idêntico, exceto carimbo de data e hora | | Plataforma \| Monitoramento | Alertas carecem de contexto sobre escopo, alterações recentes ou padrões de problema; o engenheiro na chamada deve coletar informações básicas manualmente | | Plataforma \| Monitoramento | ⚡️ Todos os alertas são roteados pelo mesmo canal, independentemente da gravidade; interrupções críticas de produção competem com pequenos avisos | | Plataforma \| Monitoramento | Alertas são disparados durante janelas de manutenção agendadas gerando falsos positivos que erodem a Trust no sistema de monitoramento | | Plataforma \| Monitoramento | ⚡️ O agrupamento de alertas não existe; cada falha de transação aciona um alerta separado criando tempestades de alerta durante incidentes | | Plataforma \| Monitoramento | Alertas não fornecem links para painéis relevantes; os respondentes passam tempo encontrando ferramentas de monitoramento durante a resposta ao incidente | ## Rotação na chamada e manual de execução **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Plataforma \| Operações | ✅ A rotação na chamada é semanal ou de duas semanas equilibrando a distribuição de carga em relação à preservação de contexto | | Plataforma \| Operações | ✅ Os manuais são documentados para cada tipo de alerta, permitindo que os engenheiros na chamada respondam de modo eficaz sem conhecimento profundo do domínio | | Plataforma \| Operações | ✅ Os manuais incluem descrição do problema, etapas de diagnóstico, procedimentos de remediação, critérios de escalação e links relacionados da documentação | | Plataforma \| Operações | ✅ Os manuais são documentos ativos no controle de versão que evoluem por meio de itens de ação pós-morte | | Plataforma \| Operações | ✅ Os procedimentos de transferência incluem breves reuniões durante as transições de rotação transferindo o contexto, incluindo problemas ativos, alterações recentes, riscos conhecidos e manutenção futura | | Plataforma \| Operações | ✅ Notas escritas de transferência complementam a transferência verbal para evitar a perda de informações durante as transições de rotação | | Plataforma \| Operações | ✅ Frequência da página, contagem de incidentes após as horas e taxa de falsos positivos são medidos para identificar a carga de chamada insustentável que requer remediação arquitetônica | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Plataforma \| Operações | ⚡️ Os manuais não existem; os engenheiros on-call dependem do Knowledge tribal e frequentes escalas para especialistas em assunto | | Plataforma \| Operações | Os manuais são armazenados em documentos pessoais, em vez de no controle de versão compartilhado, em que os membros da equipe podem acessá-los e atualizá-los | | Plataforma \| Operações | Transições de rotação na chamada acontecem sem reuniões de transferência; o engenheiro recebido não tem contexto sobre problemas ativos e alterações recentes | | Plataforma \| Operações | ⚡️ Alta carga na chamada continua indefinidamente por meio de heroísmo operacional, em vez de promover melhorias arquitetônicas | | Plataforma \| Operações | Métricas na chamada (frequência da página, incidentes após as horas, falsos positivos) não são rastreadas; os padrões de carga permanecem invisíveis | | Plataforma \| Operações | Os manuais são criados uma vez durante a implementação inicial e nunca são atualizados à medida que o sistema evolui ou novos modos de falha aparecem | ## Caminho de escalação **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Plataforma \| Operações | ✅ Caminhos de escalação técnica definem quais especialistas no assunto tratam de domínios de problema específicos | | Plataforma \| Operações | ✅ Os caminhos de escalação de gerenciamento definem quais gerentes recebem notificações para incidentes que excedem os limites de gravidade ou duração | | Plataforma \| Operações | ✅ Documento de caminhos de escalação do fornecedor O Salesforce oferece suporte a critérios de gravidade e procedimentos de criação de caso | | Plataforma \| Operações | ✅ Caminhos de escalação executiva definem quais executivos recebem notificações sobre incidentes essenciais para os negócios | | Plataforma \| Operações | ✅ Os critérios de escalação são explícitos e objetivos: níveis de gravidade, limites de tempo, contagens de usuários afetadas, avaliações de impacto comercial | | Plataforma \| Operações | ✅ Os caminhos de escalação são documentados em manuais e acessíveis durante incidentes sem pesquisar informações de contato | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Plataforma \| Operações | Os caminhos de escalação não são documentados; os engenheiros na chamada desperdiçam tempo pesquisando contatos adequados durante incidentes | | Plataforma \| Operações | ⚡️ Os critérios de escalação são vazios ("escalar se parecer ruim"; os respondentes não têm orientação clara sobre quando escalar | | Plataforma \| Operações | A notificação de gerenciamento acontece tarde demais porque os limites de gravidade não estão definidos; os executivos aprendem sobre incidentes com os usuários | | Plataforma \| Operações | ⚡️ Os procedimentos de escalação de suporte do Salesforce não são documentados; as equipes atrasam a abertura de casos de suporte perdendo um tempo de resposta valioso | | Plataforma \| Operações | ⚡️ Os contatos de especialistas no assunto estão desatualizados; as escalações chegam às pessoas erradas ou falham durante as alterações de rotação | ## Processo de revisão pós-incidente **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Plataforma \| Operações | ✅ Revisões pós-incidente sem culpa são realizadas dentro de cinco dias úteis após eventos operacionais significativos | | Plataforma \| Operações | ✅ A cultura impecável foca melhorias do sistema em vez de culpa individual, criando segurança psicológica para avaliação honesta | | Plataforma \| Operações | ✅ Linha do tempo inclui sequência detalhada das condições iniciais por meio do primeiro sinal, detecção, confirmação, investigação, resposta, recuperação e validação | | Plataforma \| Operações | ✅ Carimbo de data e hora da linha do tempo de cada evento habilitando a análise de duração das fases de detecção, resposta e recuperação | | Plataforma \| Operações | ✅ A causa raiz identifica a falha técnica ou condição que causou diretamente o incidente, diferenciada dos fatores relevantes | | Plataforma \| Operações | ✅ A análise de fatores contribuintes revela condições organizacionais, de processo ou de arquitetura que habilitaram ou amplificaram o impacto do incidente | | Plataforma \| Operações | ✅ A análise de detecção avalia como o incidente foi detectado e se a detecção poderia ter sido mais rápida | | Plataforma \| Operações | ✅ A avaliação da resposta identifica o que foi bem durante a resposta e o que foi mais lento ou mais difícil do que o necessário | | Plataforma \| Operações | ✅ Itens de ação são específicos, atribuídos e com prazo definido para evitar recorrência ou melhorar a resposta futura | | Plataforma \| Operações | ✅ Itens de ação evitam melhorias vagas ("melhorar o monitoramento") em favor de tarefas concretas ("adicionar alerta para taxa de erro de API superior a 5% na janela de 10 minutos") | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Plataforma \| Operações | ⚡️ A discussão pós-incidente conclui que "o trabalho em lote teve um erro, corrigimos" sem nenhuma documentação ou melhorias sistemáticas | | Plataforma \| Operações | As análises pós-incidente focam a falha individual, em vez de melhorias do sistema, destruindo a segurança psicológica | | Plataforma \| Operações | ⚡️ A linha do tempo não tem carimbos de data e hora que impedem a análise de duração; a equipe não consegue identificar se a detecção ou a resposta foi lenta | | Plataforma \| Operações | ⚡️ A análise de causa raiz não diferencia a causa técnica imediata de fatores organizacionais ou de processo | | Plataforma \| Operações | A análise de detecção foi ignorada; as lacunas de monitoramento que permitiam aos usuários relatar o incidente primeiro não foram identificadas | | Plataforma \| Operações | Itens de ação são vazios sem proprietários ou prazos; as melhorias são discutidas, mas nunca implementadas | | Plataforma \| Operações | As análises pós-incidente não são realizadas dentro de cinco dias úteis; o contexto é perdido e a urgência para melhorias desaparece | ## Documentação e aprendizado pós-incidente **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Plataforma \| Gerenciamento de Knowledge | ✅ As análises pós-incidente são documentadas e compartilhadas amplamente além dos responsores de incidentes imediatos para aprendizado organizacional | | Plataforma \| Gerenciamento de Knowledge | ✅ Revisões pós-incidente são armazenadas em wiki compartilhada ou base de Knowledge com marcação que permite a análise de padrões em vários incidentes | | Plataforma \| Gerenciamento de Knowledge | ✅ A conclusão do item de ação é rastreada em revisões subsequentes, impedindo que retrospectivas se tornem discussões repetitivas sem acompanhamento | | Plataforma \| Gerenciamento de Knowledge | ✅ As taxas de conclusão do item de ação são medidas como um indicador de saúde operacional que revela se as melhorias são implementadas ou apenas discutidas | | Plataforma \| Operações | ✅ Os padrões de incidente são analisados em vários incidentes revelando problemas sistêmicos que exigem investimento arquitetônico | | Plataforma \| Operações | ✅ Os manuais são atualizados com base em aprendizado pós-incidente, garantindo que os procedimentos reflitam a experiência real de resposta a incidentes | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Plataforma \| Gerenciamento de Knowledge | ⚡️ As análises pós-incidente não são documentadas; os aprendizados permanecem com os responsores do incidente, em vez de se espalharem pela organização | | Plataforma \| Gerenciamento de Knowledge | As análises pós-incidente são armazenadas em documentos pessoais, em vez de uma base de Knowledge compartilhada, onde os membros da equipe podem aprender com a história | | Plataforma \| Gerenciamento de Knowledge | Itens de ação são definidos, mas nunca rastreados; a taxa de conclusão é desconhecida e as melhorias não são implementadas | | Plataforma \| Gerenciamento de Knowledge | Taxas de conclusão de item de ação baixas persistem sem reconhecimento de que os retrospectivas são ineficazes sem acompanhamento | | Plataforma \| Operações | Padrões de incidente não são analisados em vários incidentes; problemas do sistema permanecem ocultos porque cada incidente é tratado isoladamente | | Plataforma \| Operações | Os manuais não são atualizados após incidentes; os procedimentos ficam desatualizados conforme o sistema evolui e novos modos de falha aparecem | ## Métricas e monitoramento de incidentes **Padrões** | Onde procurar | Qual é a boa aparência | | --- | --- | | Plataforma \| Operações | ✅ O tempo médio para detectar (MTTD) é rastreado para medir a duração da ocorrência do incidente até a detecção | | Plataforma \| Operações | ✅ O tempo médio para confirmar (MTTA) é rastreado para medir a duração da detecção até a confirmação do engenheiro na chamada | | Plataforma \| Operações | ✅ O tempo médio para restaurar (MTTR) é rastreado para medir a duração da detecção até a restauração do serviço | | Plataforma \| Operações | ✅ A frequência do incidente é rastreada com a análise de tendência mensal que revela se a estabilidade está melhorando ou diminuindo | | Plataforma \| Operações | ✅ A taxa de falha da alteração é rastreada medindo a porcentagem de implantações que causam incidentes de produção que exigem remediação | | Plataforma \| Operações | ✅ A taxa de falha de alteração é mantida consistentemente baixa, uma pequena fração de todas as implantações | | Plataforma \| Operações | ✅ Métricas de incidente são compartilhadas com equipes de desenvolvimento durante o planejamento de sprint informando a priorização de pendências e melhorias arquitetônicas | **Anti-Padrões** | Onde procurar | Qual é a aparência ruim | | --- | --- | | Plataforma \| Operações | As métricas de incidente não são rastreadas; a equipe não tem visibilidade de se os tempos de resposta estão melhorando ou diminuindo | | Plataforma \| Operações | ⚡️ MTTD, MTTA e MTTR não são medidos; as equipes não podem identificar se a detecção ou a resposta é o gargalos | | Plataforma \| Operações | A taxa de falha de alteração não é rastreada; a equipe não sabe se os portões de qualidade são eficazes | | Plataforma \| Operações | As tendências de frequência de incidentes não são revisadas mensalmente; a degradação da estabilidade não é detectada até que ocorra um incidente importante | | Plataforma \| Operações | Métricas de incidente permanecem na equipe de operações sem compartilhamento com as equipes de desenvolvimento; problemas arquitetônicos não são resolvidos | | Plataforma \| Operações | As métricas são rastreadas, mas nunca usadas para informar decisões; a medição sem ação desperdiça esforço e não fornece valor |