Contente
- Preparando-se para a Falha
- Os próximos passos
- Sem erros, sem estresse - seu guia passo a passo para criar software que muda vidas sem destruir sua vida
- Aprendendo e melhorando através de exercícios
Fonte: pressureUA / iStockphoto
Leve embora:
Os sistemas modernos devem ser capazes de lidar com o caos, a fim de evitar o tempo de inatividade. É por isso que é mais importante do que nunca testar exaustivamente os sistemas e garantir sua resiliência.
Apesar de nossos maiores esforços para evitá-los, os incidentes de TI são uma parte inevitável do trabalho - e tentar ficar à frente do tempo de inatividade com impacto nos negócios está ficando cada vez mais complicado. Hoje, os sistemas são fortemente acoplados e cada vez mais complexos, e com mais partes móveis, surgem mais oportunidades para que as coisas dêem errado.
Essa é uma das razões pelas quais mais e mais organizações estão recorrendo aos microsserviços para aumentar a disponibilidade de serviços e melhorar a resiliência a falhas. Mas, embora essas sejam ótimas premissas para quebrar aplicativos monolíticos, elas também podem potencialmente aumentar o risco de falha - a menos que sejam projetadas expressamente com a resiliência em mente.
Preparando-se para a Falha
Dada a natureza inerentemente caótica dos sistemas distribuídos, os serviços devem ser desenvolvidos não apenas para antecipar falhas, mas também para se recuperar automaticamente em caso de falha. Isso significa instigar falhas regularmente para garantir que seus sistemas possam lidar com o caos sem interromper o serviço aos clientes finais. E para conseguir isso, você precisa simular o tráfego semelhante à produção em ambientes de teste.
Obviamente, é uma boa ideia testar a resiliência antes que as alterações cheguem à produção. Se você não fizer isso, não poderá verificar se seus serviços podem suportar cargas médias e de pico. De fato, a aposta mais segura é garantir que seu produto possa lidar com o dobro do valor máximo sem ter que aumentar.
Quando se trata de teste de resiliência, as ferramentas certas não devem se preocupar muito com a forma como as solicitações são tratadas, apenas com o impacto correto no final. Lembre-se de que, sob certas condições, o serviço de entrada pode falhar em entregar uma solicitação ao restante do sistema, mas não reportar a falha. Não arrisque problemas voando sob o radar do monitoramento, certificando-se de que a validação de ponta a ponta está, de fato, ocorrendo. (Para saber mais, consulte Falhas técnicas: podemos viver com eles?)
Os próximos passos
Depois de entender como os serviços se comportam sob carga, é hora de começar a apresentar os eventos de falha. Como em todos os testes de software, é melhor ter ferramentas automatizadas que permitam reproduzir cenários de maneira fácil e rápida, para que você possa coordenar eventos complexos que afetam diferentes tecnologias de infraestrutura. E além da capacidade de verificar correções e alterações nos serviços, isso permite executar cenários de falha aleatória em qualquer ambiente e em um cronograma.
Eventos de falha significativos dependem amplamente do layout de seus serviços e você pode formulá-los fazendo perguntas específicas relevantes para você. Por exemplo, qual é o impacto para as pessoas que usam o front-end quando um banco de dados fica inacessível por um determinado período de tempo? Esses usuários ainda podem navegar na interface da web? Eles ainda podem emitir atualizações para suas informações e essas atualizações serão processadas corretamente quando o banco de dados se tornar acessível novamente?
Se você executar vários microsserviços, poderá perguntar se haverá uma interrupção global se algum serviço individual falhar. Ou se você possui um mecanismo de enfileiramento para armazenar em buffer a comunicação entre serviços, o que acontece quando o serviço (ou serviços) ao consumidor para de funcionar? Os usuários ainda poderão trabalhar com seu aplicativo? E, dada uma carga média, quanto tempo você tem antes das filas transbordarem e começar a perder s?
Sem erros, sem estresse - seu guia passo a passo para criar software que muda vidas sem destruir sua vida
Você não pode melhorar suas habilidades de programação quando ninguém se importa com a qualidade do software.
Depois de definir algumas perguntas importantes sobre sua infraestrutura, você poderá começar a listar maneiras diferentes de simular essas falhas. Pode ser o suficiente para parar um serviço específico ou um servidor de banco de dados. Você pode bloquear o encadeamento principal de um serviço para simular um bloqueio, enquanto o contêiner ainda está responsivo e em execução. Você pode decidir introduzir regras na sua rede para bloquear o tráfego entre serviços específicos. Em ambientes Linux, você pode usar ferramentas como 'tc' para emular situações de rede como pacotes de alta latência, descartados, corrompidos ou duplicados. (Pode ser importante envolver os usuários nos testes. Leia mais em 4 razões pelas quais os usuários finais precisam participar dos testes antes do UAT.)
Aprendendo e melhorando através de exercícios
Um dos aspectos mais valiosos da criação de cenários de falha é que eles podem expor todas as formas possíveis de falha do sistema, abrindo caminho para a lógica de autocorreção. Sua equipe seguirá as etapas para recuperar serviços manualmente - a propósito, uma ótima simulação para confirmar que eles são capazes de fazer isso nos SLAs. A automação desse processo de recuperação pode ser trabalhada, mas, enquanto isso, você pode ficar tranquilo sabendo que sua equipe passou pelo processo de obter os serviços de volta aos trilhos. Ao tornar os cenários de falha aleatórios e regulares e não divulgar todos os detalhes da execução, você também pode incluir descobertas e diagnósticos no drill - que é, afinal, uma parte crítica dos SLAs.
No fundo, a engenharia do caos toma a complexidade do sistema como um dado, testa-o simulando condições novas e malucas e observa como o sistema responde. Essa é a equipe de engenharia de dados que precisa reprojetar e reconfigurar o sistema para obter maior resiliência. Existem muitas oportunidades para aprender coisas novas e úteis. Por exemplo, você pode encontrar instâncias em que os serviços não estão recebendo atualizações quando os serviços downstream foram alterados ou áreas em que o monitoramento está faltando completamente. Não faltam maneiras interessantes de tornar seu produto mais resistente e robusto!