Os testes de carga tradicionais responderam primeiro. Experimentos de injeção de falhas e latência revelaram a segunda, uma forma de falha controlada frequentemente descrita como engenharia do caos. Ao introduzir atrasos controlados e interrupções ocasionais, verificamos que os prazos realmente paravam de funcionar, as filas não cresciam sem limites e os substitutos se comportavam conforme o esperado.
Lições que levaram adiante
Este incidente mudou permanentemente a forma como penso sobre os tempos limite.
Um tempo limite é uma decisão sobre valor. Depois de um certo ponto, esperar mais não melhora a experiência do usuário. Aumenta a quantidade de trabalho desperdiçado que um sistema executa depois que o usuário já saiu.
Um tempo limite também é uma decisão sobre contenção. Sem esperas limitadas, as falhas parciais transformam-se em falhas de todo o sistema através do esgotamento dos recursos: threads bloqueados, swimming pools saturados, filas crescentes e latência em cascata.
Se há uma conclusão desta história, é esta: definir intervalos de tempo deliberadamente e vinculá-los aos orçamentos. Comece pelo comportamento do usuário. Meça a latência em p99, não apenas as médias. Torne os tempos limite observáveis e decida explicitamente o que acontece quando eles disparam. Isole a capacidade para que uma única dependência lenta não possa esgotar o sistema.
A espera ilimitada não é neutra. Tem um custo actual de confiabilidade. Se você não limitar a espera deliberadamente, isso acabará limitando seu sistema a você.
Este artigo foi publicado como parte da Foundry Knowledgeable Contributor Community.
Quer participar?