Defina a prontidão em torno de um resultado do cliente
Comece por resultados, não por rótulos de infraestrutura. Uma página inicial acessível não é suficiente se o visitante não conseguir completar a tarefa que importa. Para cada jornada crítica, declare quem está tentando fazer o quê, o que significa sucesso e qual resultado é inaceitável. Comece com poucas jornadas para que a equipe possa tomar decisões reais.
Classifique cada etapa como essencial, importante ou adiada. Essencial significa que a jornada não termina sem ela; importante pode permitir um contorno por tempo limitado; adiada pode ser omitida, atrasada ou simplificada. Esta é uma decisão de produto informada pela engenharia, não uma hierarquia técnica universal.
Registre um resultado utilizável, como um pedido aceito e confirmação armazenada, em vez de apenas um alvo de resposta de página.
Mapeie dependências e decida o que pode degradar
Para cada caminho crítico, mapeie hospedagem ou entrega, DNS, serviços de aplicação, bancos de dados, autenticação, e-mail, pagamentos, busca, tags, ferramentas de consentimento e APIs externas. Registre o responsável, rota de suporte, limite relevante e efeito sobre o usuário se cada item estiver indisponível. OWASP recomenda visibilidade nas dependências de software; a mesma disciplina de propriedade ajuda nas dependências operacionais.
Uma dependência rígida interrompe a tarefa quando falha. Uma dependência flexível pode estar ausente ou desatualizada enquanto a função principal ainda funciona. A AWS descreve degradação graciosa como manter a função central disponível quando dependências estão com problemas. Defina uma escolha específica de produto: ocultar um widget não essencial, adiar um relatório ou apresentar um fallback honesto. Não invente inventário, preços, estados de pedido ou resultados de pagamento.
Capture propósito, responsável, limite conhecido, fallback, contato para mudanças e data do último teste para cada item.
Transforme uma previsão de tráfego em um experimento de capacidade
Use um cenário, não um número único de tráfego. Declare o evento, padrão de chegada, mix de requisições, proporção de usuários autenticados, geografia, atividade concorrente de checkout ou gravação e período de pico. Inclua um caso alto e as suposições. O Google nota que requisições podem ter custos de recurso muito diferentes, então requisições por segundo isoladamente podem ser um modelo de capacidade pobre.
Teste tráfego sustentado, representativo e ponta a ponta contra uma configuração próxima à produção, com aprovações e salvaguardas. A AWS alerta contra testar apenas componentes, usar um subconjunto de requisições não representativo ou parar em uma pequena margem acima da carga esperada. Documente a primeira restrição ou desaceleração. Testes em produção podem afetar clientes; use um ambiente controlado, a menos que um exercício planejado e com equipe apropriada seja adequado.
Mantenha o cenário, configuração, mix de requisições, duração, restrição observada, mudança de capacidade e responsável por follow-up.
Prepare escolhas de mudança, rollback e recuperação
Antes de uma mudança de alto risco, identifique o artefato ou configuração a restaurar, aprovação necessária, pessoa autorizada e método de validação. Mantenha um runbook curto para pausar um release, reverter um deploy, desabilitar uma feature flag, reduzir uma integração não crítica ou restaurar dados usando um procedimento aprovado. Teste a mecânica antes do evento; um backup ou plano de rollback não exercitado é uma suposição.
Defina objetivos de recuperação a partir do impacto no negócio. Recovery Time Objective (RTO) é o atraso máximo aceitável antes que o serviço seja restaurado. Recovery Point Objective (RPO) é a perda máxima de dados aceitável medida desde o último ponto de recuperação. A AWS alerta contra metas arbitrárias ou irreais e observa que objetivos de dependência afetam o que é alcançável. Trate metas como objetivos de planejamento, não promessas ao cliente.
Verifique um rollback limitado e seguro ou restauração e registre o que foi checado, por quem e qualquer lacuna encontrada.
Atribua propriedade antes que as decisões sejam urgentes
Uma lista de contatos sozinha não é propriedade. Para cada caminho crítico, atribua um dono de negócio pelo resultado aceitável, um dono técnico pela implementação e um dono de decisão autorizado a fazer uma mudança protetiva. Nomeie backups e esclareça quando um provedor, agência, processador de pagamento ou equipe interna possui a próxima ação.
Faça uma revisão curta de prontidão antes do tráfego chegar. Percorra uma falha de dependência: o que permanece disponível, qual alavanca é segura, quem aprova e como o sucesso é verificado. Isso é um ensaio proativo, não um relatório de status ao vivo. Registre ações datadas, responsáveis e prazos.
Pré-autorize ações estreitas e seguras quando apropriado para que a proteção não espere por uma cadeia de aprovação incerta.
Trate caminhos sensíveis a pagamentos e segurança com cuidado extra
A prontidão de checkout deve preservar correção além da disponibilidade. Não contorne autorização, enfraqueça controles de acesso, exponha credenciais ou altere casualmente scripts da página de pagamento. A orientação da PCI SSC aborda autorização, integridade e detecção de adulteração para scripts de página de pagamento e cabeçalhos HTTP com impacto em segurança. Se o site aceita cartões ou usa um iframe de pagamento embutido, faça com que o comerciante, processador, adquirente e consultores qualificados de segurança ou conformidade revisem mudanças materiais.
Mantenha um inventário de scripts de produção, integrações, versões e propriedade de contas, e restrinja quem pode alterá-los. OWASP observa que inventários de dependência e fixação de versões podem reduzir a incerteza sobre o que entra em uma build, enquanto achados automatizados ainda precisam de verificação manual. Essas práticas suportam a prontidão, mas não estabelecem conformidade PCI nem substituem uma avaliação de segurança.
Use apenas um fluxo alternativo aprovado e revisado pelo processador; nunca colete dados de cartão por canais informais.