APRENDER. PRATICAR. EVOLUIR.Capacidade no estado de falha
Num desenho fictício, três zonas suportam 180 operações por segundo cada. Em operação normal existem 540, mas perder uma zona deixa 360. Se o requisito é manter 400 sem provisionar recursos, faltam 40 operações por segundo. A disponibilidade de uma maioria ou de vários servidores não resolve essa diferença. O orçamento deve considerar a capacidade que fica utilizável no modo de falha definido, incluindo dependências comuns. Um plano que espera criar recursos durante o incidente acrescenta pressupostos sobre tempo, quota e controlo. Regista esses pressupostos e o modo degradado aceite, em vez de apresentar a soma normal como capacidade de recuperação.
O atraso compete com novas chegadas
O modelo original desta aula usa taxas constantes e custo uniforme. Com 4200 itens pendentes, entrada de 250 por segundo e capacidade de 320, restam 70 por segundo para recuperar atraso. O tempo calculado é 4200 dividido por 70, ou sessenta segundos. Dividir por 320 pressuporia que deixavam de entrar pedidos. Se entrada e capacidade forem iguais, o backlog positivo não desaparece; se a entrada for maior, cresce. Estes resultados são aritmética do modelo, não medições de desempenho. Variação de custo, latência, concorrência e limites do destino podem alterar o comportamento de uma aplicação real.
Tentativas adicionais consomem margem
Acrescenta quarenta tentativas por segundo com o mesmo custo unitário ao exemplo anterior. A margem passa de setenta para trinta, e o tempo idealizado sobe para 140 segundos. A tentativa pode ser necessária, mas consome recursos antes de produzir resultado útil. Define erros elegíveis, limite de tempo, número máximo e backoff com jitter no contrato real. Um erro persistente de autorização precisa de corrigir permissões, não de repetir mais depressa. Também distingue tentativas já feitas por bibliotecas das realizadas pela aplicação. O laboratório só calcula o efeito de uma taxa adicional; não implementa um cliente, um scheduler de jitter ou uma política de retry completa.
Fila menor não prova conclusão válida
Uma API assíncrona pode confirmar a entrada na fila antes de o consumidor produzir o efeito. Reporta aceite e concluído como marcos separados. Observa idade dos itens, prazo de negócio, classe, erros e destino das exceções. A remoção de itens faz diminuir o backlog sem demonstrar execução correta. Num fluxo fictício de fundos, uma instrução expirada pode exigir investigação ou decisão autorizada; a fórmula de capacidade não define se deve ser descartada, compensada ou ainda executada. O modelo também não conserva uma fila individual por prazo. Cabe ao exercício de decisão identificar estes requisitos adicionais e atribuir a sua validação.
População e cronologia do indicador
O laboratório compara cem operações lógicas com 120 tentativas. Se 96 tentativas bem-sucedidas correspondem a 96 operações distintas, o sucesso lógico é 96%, enquanto o sucesso por tentativa é 80%. Ambos os números podem ser úteis, mas respondem a perguntas diferentes. Define a população antes do incidente e mantém identificadores para reconciliar efeitos. Na cronologia, um exemplo sem sobreposição soma quinze segundos de deteção, 25 de decisão, quarenta de reconexão e vinte de validação: cem segundos até ao marco final. Não reportes apenas a etapa mais curta ou a eleição se o consumidor ainda não conclui a operação acordada.
Oficina: compromisso perante o cut-off
Organiza quarenta e cinco minutos com papéis de APS, negócio e gestor técnico. Nos primeiros quinze, calcula a capacidade residual e o tempo de escoamento para as taxas fornecidas. Introduz depois quarenta retries por segundo e um conjunto de itens expirados. Usa quinze minutos para rever a estimativa e decidir que perguntas faltam responder antes de prometer recuperação. Nos quinze finais, comunica em inglês o estado, a estimativa condicionada, os itens sem resultado confirmado e a próxima atualização. A aceitação exige ensaios representativos e reconciliação funcional. O sucesso das 32 verificações locais não demonstra carga real, perda de zona ou revisão independente.
net_capacity = capacity - arrivals - extra_attempt_load
recovery_seconds = backlog / net_capacity # only when positive
# Constant rates and equal unit cost are exercise assumptions.
# No finite drainage time for positive backlog when net_capacity <= 0.4200 itens, entrada 250/s e capacidade 320/s: sessenta segundos no modelo. Com mais 40 tentativas/s de custo igual, a estimativa passa a 140 segundos.
Armadilhas comuns
Dividir pela capacidade bruta; ignorar retries; contar tentativas como operações; confundir aceite com concluído; eliminar itens para melhorar o gráfico; apresentar o modelo como benchmark.
Tópicos relacionados: Domínios de falha e capacidade residual · Quorum e isolamento de escritores · Substituição, identidade e aceitação
A recuperação precisa de capacidade útil e efeitos válidos. Uma estimativa deve conservar as premissas, a população medida e os critérios do consumidor.
Referência: Use static stability · DR HA 2026-09; Pacemaker 3.0, etcd 3.6, PostgreSQL 18 and selected Kubernetes/AWS behavior