Observabilidade e monitoramento – Padrões
Saiba mais sobre a excelência operacional bem-construída → Observatibilidade e monitoramento
Padrões
| Onde procurar | Qual é a boa aparência |
|---|---|
| Plataforma | Monitoramento de evento | ✅ O Monitoramento de evento é projetado para a arquitetura inicial capturando IDs de correlação que rastreiam solicitações por meio de cadeias de processamento assíncronas e integrações externas |
| Plataforma | Monitoramento de evento | ✅ A infraestrutura de capacidade de observação é incluída no sprint inicial, em vez de ser adaptada posteriormente após os incidentes de produção serem impossíveis de diagnosticar |
| Plataforma | Integração | ✅ Os pontos de verificação de integração são colocados deliberadamente para habilitar o rastreamento de solicitações entre os limites do sistema |
| Plataforma | Eventos de plataforma | ✅ As cargas úteis de evento de plataforma são estruturadas para visibilidade operacional com marcadores de transação e contexto |
| Plataforma | Registro personalizado | ✅ A estrutura de registro personalizado captura eventos separados com informações contextuais completas, incluindo identidade do usuário, carimbo de data e hora, duração e resultado |
| Plataforma | Métricas | ✅ As métricas agregam medidas numéricas ao longo do tempo revelando tendências, incluindo taxas de consumo de API, distribuições de tempo de CPU do Apex e taxas de sucesso de trabalho em lote |
| Plataforma | Rastreamento distribuído | ✅ Rastreia conexões de chamadas de API síncronas a cadeias de processamento assíncronas, eventos de plataforma a execuções do assinante e solicitações de integração a respostas do sistema externo |
| Plataforma | Capacidade de observação | ✅ A capacidade de observação permite que os operadores respondam a perguntas arbitrárias sobre o comportamento do sistema sem implantar uma nova instrumentação para cada investigação |
Anti-Padrões
| Onde procurar | Qual é a aparência ruim |
|---|---|
| Plataforma | Monitoramento de evento | ⚡️ Solução iniciada sem registro personalizado, exigindo refatoramento importante seis meses depois quando os incidentes de produção se revelarem impossíveis de diagnosticar com registros de plataforma apenas |
| Plataforma | Monitoramento de evento | ⚡️ A capacidade de observação é adaptada à solução existente que requer alterações de instrumentação que afetam a maioria dos componentes e arriscam bugs durante o trabalho de melhoria operacional |
| Plataforma | Integração | ⚡️ Há falhas de integração, mas os caminhos de solicitação não podem ser rastreados entre os limites do sistema sem telemetria abrangente |
| Plataforma | Eventos de plataforma | As cargas úteis de evento de plataforma não têm contexto operacional, o que torna a investigação de incidentes dependente de pesquisar vários sistemas |
| Plataforma | Registro personalizado | ⚡️ Os registros capturam contexto insuficiente; as investigações exigem a reprodução de problemas para coletar informações adicionais |
| Plataforma | Capacidade de observação | Painéis predefinidos não podem responder perguntas inesperadas sobre o comportamento do sistema emergente na produção |
Padrões
| Onde procurar | Qual é a boa aparência |
|---|---|
| Plataforma | Monitoramento de evento | ✅ O Monitoramento de evento está habilitado para ambientes de produção que capturam o uso da API, a atividade de login, a execução do Apex, consultas SOQL, páginas do Visualforce, páginas do Lightning e execuções de relatórios |
| Plataforma | Monitoramento de evento | ✅ Arquivos de registro de evento exportam a cada hora para a plataforma de registro centralizada, permitindo a análise histórica além da retenção nativa da plataforma |
| Plataforma | Monitoramento de evento | ✅ Agregação de log externo permite correlação com a telemetria corporativa de outros sistemas para rastreamento de transação de ponta a ponta |
| Plataforma | Monitoramento de evento | ✅ Arquivos de registro de evento são retidos para atender aos requisitos regulatórios para relatórios de conformidade e análise de tendência de longo prazo |
| Plataforma | Proactive Monitoring | ✅ Os limites Proactive Monitoring são ajustados deliberadamente com base no intervalo de operação normal específico da organização, em vez de aceitar padrões |
| Plataforma | Proactive Monitoring | ✅ Alertas Proactive Monitoring detectam picos de limite de API, falhas do Apex simultâneas, abordagens de limite de linha SOQL e contenção de bloqueio de linha antes de incidentes visíveis ao usuário |
| Plataforma | Proactive Monitoring | ✅ Limites ajustados geram sinais acionáveis em que as equipes Trust e agem para criar ciclos virtuosos de melhoria contínua |
| Plataforma | Centro de escala | ✅ As linhas de base do Centro de escala são estabelecidas durante a estabilização da solução e revisitadas após cada versão principal |
| Plataforma | Centro de escala | ✅ O Centro de escala revela quais operações consomem mais recursos, quais transações se aproximam dos limites de tempo limite e onde o investimento na otimização gera maior impacto |
| Plataforma | Centro de escala | ✅ Aumento do tempo de transação em relação à investigação de prompt de linha de base revelando padrões de consulta N+1 inadvertidos introduzidos na última implementação |
| Plataforma | Trilha de auditoria de configuração | ✅ A Trilha de auditoria de configuração rastreia alterações de configuração, incluindo modificações de permissão, implantações de metadados e atualizações de configuração de segurança com retenção de até 180 dias |
| Plataforma | Trilha de auditoria de configuração | ✅ As entradas da Trilha de auditoria de configuração são exportadas para retenção além de 180 dias quando requisitos de conformidade ou contratuais exigem janelas históricas mais longas |
| Plataforma | Shield | ✅ A Trilha de auditoria de campo é habilitada seletivamente para campos contendo dados confidenciais, dados regulamentados que exigem histórico de alterações ou dados críticos de negócios |
| Plataforma | Shield | ✅ A Trilha de auditoria de campo fornece retenção de até 10 anos para campos em que a compreensão de valores históricos ajuda operações e relatórios de conformidade |
| Plataforma | Verificação de integridade | ✅ As análises da Verificação de integridade são agendadas trimestralmente com as descobertas remediadas com base na priorização de risco para o ambiente |
| Plataforma | Verificação de integridade | ✅ As descobertas da Verificação de integridade recebem revisão deliberada em vez de aceitação passiva; controles compensatórios ou diferentes tolerâncias de risco são documentados |
Anti-Padrões
| Onde procurar | Qual é a aparência ruim |
|---|---|
| Plataforma | Monitoramento de evento | O Monitoramento de evento está habilitado, mas os registros nunca são exportados, limitando as investigações à janela de retenção nativa e impedindo a análise de tendências históricas |
| Plataforma | Monitoramento de evento | ⚡️ Arquivos de log de evento permanecem no armazenamento de plataforma; a agregação externa não é implementada, impedindo o planejamento de capacidade de longo prazo |
| Plataforma | Proactive Monitoring | O Proactive Monitoring usa limites padrão que são muito sensíveis ou muito lentos, gerando alertas ruidosos que as equipes aprendem a ignorar |
| Plataforma | Proactive Monitoring | O ruído do alerta destrói o Trust no sistema de monitoramento; as equipes param de responder a sinais válidos |
| Plataforma | Centro de escala | ⚡️ O Centro de escala está habilitado, mas nunca revisado proativamente; o desempenho diminui lentamente até os usuários reclamarem após meses de degradação incremental |
| Plataforma | Centro de escala | Métricas de desempenho não têm contexto de linha de base; não está claro se os tempos de transação de três segundos são típicos, melhoram ou degradem |
| Plataforma | Trilha de auditoria de configuração | A Trilha de auditoria de configuração não é exportada; limitações de retenção impedem investigações de segurança ou validação de conformidade após 180 dias |
| Plataforma | Shield | A Trilha de auditoria de campo está habilitada para todos os campos em vez de de forma seletiva, criando custos de armazenamento sem o valor de conformidade correspondente |
| Plataforma | Verificação de integridade | As descobertas da Verificação de integridade nunca são revisadas; a configuração de segurança se desvia das recomendações de linha de base sem aceitação deliberada |
Padrões
| Onde procurar | Qual é a boa aparência |
|---|---|
| Plataforma | Fluxos de usuário | ✅ Fluxos de usuário críticos são definidos com base no impacto dos negócios e monitorados de ponta a ponta para taxas de sucesso, tempo de conclusão, pontos de abandono e taxas de erro |
| Plataforma | Fluxos de usuário | ✅ Fluxos críticos incluem atividades geradoras de receita (envio de pedido, execução de contrato, fechamento de oportunidade), atividades de alto volume (login, pesquisa, criação de registro) e atividades exigidas por conformidade (captura de consentimento, cumprimento dos direitos de sujeito de dados) |
| Plataforma | Fluxos de usuário | ✅ Os fluxos são instrumentados com marcadores de transação indicando início, conclusão, abandono e falha em cada etapa significativa |
| Plataforma | Fluxos de usuário | ✅ Fluxo de envio de pedidos instrumentado com eventos de plataforma em cada estágio (validação de carrinho, verificação de inventário, processamento de pagamento, acionador de cumprimento) mostrando taxa de sucesso por estágio |
| Plataforma | Fluxos de usuário | ✅ O monitoramento em nível de fluxo revela problemas invisíveis no monitoramento em nível de componente, pois falhas podem ocorrer em qualquer ponto de transição |
| Plataforma | Fluxos de usuário | ✅ Alertas são disparados quando as taxas de sucesso do fluxo ficam abaixo dos limites aceitáveis ou a duração excede as metas de latência |
| Plataforma | Integração | ✅ O monitoramento de integridade detecta falhas do sistema externo, problemas de rede, problemas de autenticação e abordagens de limite de taxa antes de ser encadeado em falhas voltadas para o usuário |
| Plataforma | Integração | ✅ Alertas de monitoramento de taxa de sucesso quando estiver abaixo de 99% para integrações síncronas críticas |
| Plataforma | Integração | ✅ Alertas de monitoramento de distribuição de erros quando novos tipos de erro aparecem que não existiam na linha de base |
| Plataforma | Integração | ✅ Monitoramento de percentil de latência (p95) alerta quando exceder 3 segundos para chamadas síncronas voltadas para o usuário |
| Plataforma | Integração | ✅ Alertas de monitoramento de taxa de transferência quando acima de 80% do limite de taxa ou limite de SLA conhecido |
| Plataforma | Integração | ✅ Alertas de monitoramento de estado do disjuntor quando qualquer circuito é aberto indicando degradação do sistema externo |
| Plataforma | Integração | ✅ Alertas de monitoramento de taxa de nova tentativa quando a taxa de nova tentativa sustentada excede 5% indicando problemas de confiabilidade |
| Plataforma | Integração | ✅ Roteamentos de telemetria de integração para plataformas de monitoramento centralizadas que permitem correlação entre limites do sistema |
Anti-Padrões
| Onde procurar | Qual é a aparência ruim |
|---|---|
| Plataforma | Fluxos de usuário | Os componentes são monitorados de modo independente mostrando a operação saudável, enquanto 12% dos usuários abandonam fluxos críticos sem visibilidade do porquê |
| Plataforma | Fluxos de usuário | ⚡️ Os painéis de integridade do componente aparecem em verde enquanto os usuários não podem concluir fluxos de trabalho críticos revelando falha na arquitetura de monitoramento |
| Plataforma | Fluxos de usuário | A jornada do usuário que afeta várias classes do Apex, fluxos, eventos de plataforma e integrações externas não tem visibilidade de ponta a ponta |
| Plataforma | Fluxos de usuário | ⚡️ Jornadas de negócios críticas não têm instrumentação; as taxas de sucesso e os pontos de abandono são desconhecidos |
| Plataforma | Integração | ⚡️ As falhas de integração são detectadas apenas depois de se encaixar em falhas voltadas para o usuário, em vez de proativamente |
| Plataforma | Integração | A telemetria de integração permanece isolada em sistemas individuais, impedindo correlação e análise de causa raiz entre limites |
| Plataforma | Integração | ⚡️ Monitorar alertas sobre sintomas a jusante após o dano ser feito em vez de revelar causas-raiz com antecedência |
Padrões
| Onde procurar | Qual é a boa aparência |
|---|---|
| Plataforma | SLIs | ✅ Os SLIs de disponibilidade medem a porcentagem de tempo em que os fluxos críticos são executados com sucesso do ponto de vista do usuário (recebendo o resultado esperado, não apenas 200 códigos de status) |
| Plataforma | SLIs | ✅ SLIs de latência medem o tempo para concluir operações em p50 (mediana), p90 (90o percentil excluindo desvios), p95 (95o percentil excluindo piores desvios) e p99 (99o percentil mostrando a experiência de pior caso) |
| Plataforma | SLIs | ✅ Os destinos de latência variam de acordo com a criticalidade da operação e a expectativa do usuário (500ms de pesquisa parece instantâneo, a mesma latência para digitação de entrada parece lenta) |
| Plataforma | SLIs | ✅ SLIs de taxa de transferência medem o volume de operações bem-sucedidas por unidade de tempo revelando a utilização de capacidade e tendências de crescimento |
| Plataforma | SLIs | ✅ A taxa de transferência combinada com a latência revela se o sistema mantém o desempenho sob aumento da carga ou se diminui conforme o volume aumenta |
| Plataforma | SLIs | ✅ Os SLIs de taxa de erro distinguem entre tipos de erro (erros do usuário, como falhas de validação, versus erros do sistema, como exceções de limite do regulador) |
| Plataforma | SLOs | ✅ Objetivos de nível de serviço são estabelecidos definindo limites de SLI aceitáveis com base nos requisitos de negócios antes de selecionar padrões de arquitetura |
| Plataforma | SLOs | ✅ O requisito de negócios “Os representantes de vendas devem ver atualizações de oportunidade dentro de 5 segundos” conduz o SLO “A página de detalhes da oportunidade é carregada dentro de 3 segundos no p95”, que conduz decisões de arquitetura |
| Plataforma | SLOs | ✅ SLOs emergem de requisitos de negócios e conduzem decisões de arquitetura em vez de serem definidos com base no que o sistema atinge no momento |
Anti-Padrões
| Onde procurar | Qual é a aparência ruim |
|---|---|
| Plataforma | SLIs | A disponibilidade é medida da perspectiva técnica (200 códigos de status) em vez da perspectiva do usuário (recebendo o resultado esperado) |
| Plataforma | SLIs | A latência é medida apenas na mediana sem entender a experiência do usuário de pior caso nos percentis p95 ou p99 |
| Plataforma | SLIs | ⚡️ Os SLIs de taxa de erro não distinguem erros do usuário e erros do sistema, mascarando diferentes problemas que exigem soluções diferentes |
| Plataforma | SLOs | ⚡️ A arquitetura é criada primeiro, então o SLO é definido como “tudo o que alcançamos no momento”, levando à aceitação de carregamentos de página de 12 segundos, pois o design do sistema nunca considerou os requisitos do usuário |
| Plataforma | SLOs | SLOs são orientados por arquitetura, em vez de por negócios, definindo metas com base no que o sistema realiza, em vez do que os usuários precisam |
Padrões
| Onde procurar | Qual é a boa aparência |
|---|---|
| Plataforma | Alertas | ✅ A classificação de gravidade encaminha incidentes críticos (produção indisponível, risco de corrupção de dados, compromisso de segurança) para os engenheiros na chamada imediatamente |
| Plataforma | Alertas | ✅ Incidentes de alta gravidade (desempenho reduzido, interrupções parciais) geram notificações para investigação imediata dentro do horário comercial |
| Plataforma | Alertas | ✅ Avisos (limites se aproximando, desvio de configuração) geram notificações digitais diárias para remediação proativa |
| Plataforma | Alertas | ✅ O contexto do alerta inclui contagem de usuários afetados, mensagens de erro, rastreamentos de pilha, implantações recentes, alertas relacionados e links para painéis relevantes |
| Plataforma | Alertas | ✅ O contexto avançado reduz o tempo médio para confirmar habilitando avaliação e investigação de gravidade imediatas sem coletar informações básicas |
| Plataforma | Alertas | ✅ O agrupamento de alertas evita tempestades de alerta em que centenas de alertas relacionados são disparados para um único problema subjacente |
| Plataforma | Alertas | ✅ A falha de integração aciona um alerta agrupado por ponto de extremidade de integração mostrando 156 solicitações com falha nos últimos cinco minutos com gráfico de latência, distribuição de erros e link do painel |
| Plataforma | Alertas | ✅ 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 |
| Plataforma | Alertas | ✅ Os alertas são suprimidos durante a manutenção agendada, durante os primeiros minutos após a implementação enquanto o cache está quente e durante breves falhas temporárias em que a lógica de nova tentativa é bem-sucedida |
Anti-Padrões
| Onde procurar | Qual é a aparência ruim |
|---|---|
| Plataforma | Alertas | ⚡️ Todos os alertas são roteados para o mesmo canal sem classificação de gravidade; incidentes críticos não são diferenciados de avisos de rotina |
| Plataforma | Alertas | Alertas carecem de contexto de diagnóstico; os engenheiros na chamada devem coletar informações básicas por meio de consultas separadas antes de avaliar a gravidade |
| Plataforma | Alertas | A falha de integração gera 156 alertas individuais em 5 minutos, sobrecarregando o telefone do engenheiro na chamada, cada alerta idêntico, exceto o carimbo de data e hora |
| Plataforma | Alertas | Tempestades de alerta impedem os respondentes de distinguir um único problema subjacente de centenas de sintomas relacionados |
| Plataforma | Alertas | Alertas são disparados durante janelas de manutenção conhecidas e condições temporárias gerando ruído que erode a Trust no monitoramento |
| Plataforma | Alertas | ⚡️ A fadiga de alerta de falsos positivos ruidosos faz com que as equipes ignorem notificações, reduzindo a eficácia da resposta |