Melhores Práticas de Solução de Problemas de Produção
Um resumo condensado das 25 melhores práticas mais importantes extraídas de todas as páginas desta seção. Runbooks armazenados ao lado do código, não na busca do Slack.
//
Busque em todas as páginas da documentação
Um resumo condensado das 25 melhores práticas mais importantes extraídas de todas as páginas desta seção. Runbooks armazenados ao lado do código, não na busca do Slack.
Comandante de Incidente Único: Um IC nomeado decide a severidade, contenção e rollback - threads paralelas do Slack sem IC desperdiçam os primeiros 15 minutos.
Contenção antes da RCA: Pause o rollout da loja, ative kill switches e inicie o rollback de OTA em T+0 - a análise da causa raiz é executada em paralelo, não primeiro.
Severidade por impacto no usuário: SEV1/SEV2 vinculados ao caminho de receita e % de usuários afetados - não volume de alertas ou ansiedade executiva.
Marque cada sinal com identidade de release: version+build nativo, updateId de OTA, channel e runtimeVersion - veja Melhores Práticas de Observabilidade.
Canais de comunicação separados: Canal de incidente de engenharia vs. canal de comunicação curado - macros de suporte devem corresponder à redação da página de status.
Checklist dos Primeiros 15 Minutos: IC, confirmação do escopo, alavancas de contenção, links do dashboard, scribe designado - Noções Básicas de Incidentes Móveis.
Agrupe antes de ler pilhas: Ordene o Sentry por impressão digital e dist - os 3 principais clusters geralmente explicam >90% do pico.
Bisecte OTA vs. nativo: Falhas em um dist → OTA; todos os dist em um release → binário nativo; todos os releases → backend.
Pilhas simbolizadas são obrigatórias: Frames Hermes não simbolizados bloqueiam o triagem - source maps em cada build de produção EAS.
Registre o último ID de grupo OTA conhecido como bom: Cada ticket de publicação de produção armazena a âncora de rollback - Melhores Práticas de Atualizações OTA.
Tempo de rollback de OTA inferior a 15 minutos: Decisão para o head do canal verificado - pratique trimestralmente no canal de preview.
Verifique o rollback de três maneiras: eas channel:view, Updates.updateId do dispositivo, migração de dist do Sentry ao longo de 60 minutos.
OTA não pode corrigir falhas nativas: SIGABRT e módulos nativos ausentes precisam de eas build - não gaste a janela de rollback em alavanca JS.
Flags de recursos antes do rollback do bundle: Erros de lógica isolados - kill switch primeiro; defeitos em todo o bundle - reversão de canal.
Pause o rollout faseado/gradual cedo: A contenção do rollout da loja leva minutos - Lançamento e Rollback Faseados.
Disciplina na sala de guerra de build: Leia primeiro a fase do log EAS - credenciais, prebuild, compilação, assinatura - uma hipótese por reconstrução.
Lembretes de calendário de credenciais: Certificado de distribuição da Apple e expiração da chave de upload do Play causam SEV2 na semana de lançamento - proprietário nomeado é necessário.
Deslistamento da loja é SEV1: Jurídico e executivo na primeira hora - engenharia é proprietária do cronograma técnico, não de e-mail de política externa.
Comunicações executivas usam intervalos: ETA de envio de binário é de propriedade da engenharia; duração da revisão da loja é um intervalo - nunca prometa revisão até as 17h.
Scribe captura linha do tempo UTC: Decisões com timestamps superam a memória pós-incidente - captura no mesmo dia antes que a equipe se disperse.
Post-mortem em até 5 dias úteis: SEV1/SEV2 exigem RCA de várias camadas - JS, nativo, OTA, backend, loja - Modelo de Post-Mortem.
Itens de ação com verificação: Proprietário, data de vencimento e métrica comprovando a correção - máximo de 5-7 itens ou a propriedade se dilui.
Atualize runbooks no repositório após incidentes: Anexe às páginas de solução de problemas e docs/incidents/ - não um cemitério de Google Docs.
Defina gatilhos de rollback antes do lançamento: Sem falhas -2% abs, pagamento -1% abs - alinhe com SLOs para Aplicativos Móveis.
Runbooks ao lado do código em controle de versão: site/reactnative/troubleshooting/ e docs/ota-rollback-card.md viajam com branches - pins do Slack apodrecem.
Noções Básicas de Incidentes Móveis para IC e os primeiros 15 minutos. Se houver pico de falhas: Triagem de Pico de Falhas. Se OTA ruim confirmado: Rollback de Emergência OTA.
O Runbook de Rollback documenta a mecânica e os gatilhos do OTA. As páginas de solução de problemas adicionam comando de incidente, bisect sob pressão, salas de guerra de loja/build e post-mortems - a camada humana em torno dos comandos.
Sim - execute exercícios de rollback de OTA e triagem de falhas em preview antes da confiança de produção. Falhas de preview são SEV3; falhas de produção são SEV2+.
Sentry com release + dist, rastreamento de sessão, source maps e log de início de sessão de updateId - triagem mínima viável por Sentry para React Native.
O plantão móvel é responsável pela contenção de falhas/OTA. Operações da loja se juntam para pausa faseada, bloqueadores de envio, deslistamento e prazos de política - Resposta a Incidentes da Loja.
Versões da Stack: Esta página foi escrita para React 19.2.3, React Native 0.86.0 e Expo SDK 57 (
expo~57.0.4).
Revisado por Chris St. John·Última atualização: 16 de jul. de 2026