Infraestrutura: engenharia do caos
A engenharia do caos é um método: formular uma hipótese mensurável sobre o estado estável, injetar uma falha específica, observar e parar se a hipótese não se sustentar. O curso aplica esse método a uma aplicação Rails num único servidor. Ele trata a observabilidade como pré-requisito e conduz no papel um experimento que rastreia a verificação de saúde /up. Também levanta as falhas que este sistema pode ter e os limites do raio de impacto com um contêiner só. No fim, propõe uma ordem de pré-condições e um desafio de avaliação de experimentos.
O que você vai aprender
- ✓Os quatro passos: hipótese, injeção, observação e parada
- ✓Por que a medição do estado estável vem antes de qualquer injeção
- ✓Como conduzir um experimento de caos lendo código e configuração
- ✓Quais falhas se aplicam a uma aplicação Rails num único servidor
- ✓Os controles do raio de impacto e por que um contêiner só não os usa
- ✓A ordem das pré-condições: restauração, observabilidade, raciocínio, staging e produção
Engenharia do caos não é quebrar coisas
O nome não ajuda. Engenharia do caos não é matar processos ao acaso para ver o que acontece. É um método com um formato específico, e é o formato que o torna útil em vez de imprudente.
Ler a aula completa grátis →Currículo
7 aulasEngenharia do caos não é quebrar coisas
A engenharia do caos segue quatro passos, começa por uma hipótese mensurável e descobre falhas que os testes não especificaram.
Você não faz isto às cegas
Observar o estado estável é o pré-requisito, e os logs disponíveis precisam virar um número de estado estável.
O experimento que dá para rodar no papel
Rastrear a verificação /up mostra que ela devolve 200 com o Postgres inacessível, e o kamal-proxy continua roteando.
As falhas que valem injetar aqui
A lista de falhas vem desta arquitetura: banco inacessível, disco cheio, job travado, memória esgotada e deploy pela metade.
Raio de impacto
Fração do tráfego, escopo, tempo e aborto limitam o raio de impacto, e com um contêiner só resta o staging.
O que fazer antes de tudo isso
Primeiro vem a restauração testada, depois observabilidade, experimentos raciocinados, staging e produção se houver redundância.
Juntando tudo
Uma revisão do curso e um desafio de implementar evaluate_experiment, em que a verificação de aborto tem precedência.