Engenharia do Caos - a história, os princípios e a prática

Com o surgimento de microsserviços e arquiteturas distribuídas em nuvem, a web tem se tornado cada vez mais complexa. Todos dependemos desses sistemas mais do que nunca, mas as falhas se tornaram muito mais difíceis de prever.

Essas falhas causam paralisações dispendias para as empresas. As paralisações prejudicam os clientes que tentam fazer compras, transacionar negócios e fazer o trabalho. Mesmo breves paralisações podem impactar o resultado final de uma empresa, de modo que o custo do tempo de inatividade está se tornando um KPI para muitas equipes de engenharia. Por exemplo, em 2017, 98% das organizações disseram que uma única hora de inatividade custaria aos seus negócios mais de US$ 100.000. Uma paralisação pode custar milhões de dólares a uma única empresa. O CEO da British Airways explicou recentemente como uma falha que encalhou dezenas de milhares de passageiros da British Airways (BA) em maio de 2017 custou à empresa 80 milhões de libras (US$ 102,19 milhões).

As empresas precisam de uma solução para este desafio — esperar pela próxima paralisação cara não é uma opção. Para enfrentar o desafio de frente, mais e mais empresas estão se voltando para a Chaos Engineering.

Engenharia do Caos é Medicina Preventiva

A Chaos Engineering é uma abordagem disciplinada para identificar falhas antes que se tornem paralisações. Testando proativamente como um sistema responde sob estresse, você pode identificar e corrigir falhas antes que elas acabem nas notícias.

Chaos Engineering permite que você compare o que você acha que vai acontecer com o que realmente acontece em seus sistemas. Você literalmente “quebra as coisas de propósito” para aprender a construir sistemas mais resistentes.

Uma Breve História da Engenharia do Caos

A Chaos Engineering tornou-se relevante em empresas de internet que eram pioneiras em sistemas distribuídos em larga escala. Esses sistemas eram tão complexos que exigiam uma nova abordagem para testar a falha.

2010

A equipe da Netflix Eng Tools criou o Chaos Monkey. Chaos Monkey foi criado em resposta à mudança da Netflix da infraestrutura física para a infraestrutura em nuvem fornecida pela Amazon Web Services, e a necessidade de ter certeza de que a perda de uma instância da Amazon não afetaria a experiência de streaming da Netflix.

2011

O Exército Símio nasceu. O Exército Símio adicionou modos adicionais de injeção de falha em cima do Chaos Monkey que permitiriam testes de um conjunto mais completo de estados de falha, e assim construir resiliência para aqueles também. “A nuvem é toda sobre redundância e tolerância a falhas. Como nenhum componente único pode garantir 100% de tempo de atividade (e até mesmo o hardware mais caro eventualmente falha), temos que projetar uma arquitetura em nuvem onde componentes individuais podem falhar sem afetar a disponibilidade de todo o sistema”(Netflix, 2011).

2012

A Netflix compartilhou o código fonte do Chaos Monkey no Github,dizendo que “descobriram que a melhor defesa contra grandes falhas inesperadas é falhar com frequência. Ao causar falhas frequentes, forçamos nossos serviços a serem construídos de forma mais resiliente”(Netflix, 2012).

2014

A Netflix decidiu criar um novo papel: o Engenheiro do Caos. Bruce Wong cunhou o termo, e Dan Woods compartilhou com a maior comunidade de engenharia via Twitter. Dan Woods explicou: “Aprendi mais sobre a Engenharia do Caos com Kolton Andrus do que qualquer outro, ele chamou de teste de injeção de falha”.

Em outubro de 2014, enquanto o co-fundador da Gremlin Kolton Andrus estava na Netflix, sua equipe anunciou o Failure Injection Testing (FIT),uma nova ferramenta que se baseou nos conceitos do Exército De Símio, mas deu aos desenvolvedores mais controle granular sobre o “raio de explosão” de sua injeção de falha. As ferramentas do Exército Simian tinham sido tão eficazes que, em alguns casos, criaram paralisações dolorosas, fazendo com que muitos desenvolvedores da Netflix crescessem cautelosos com elas. A FIT deu aos desenvolvedores o controle sobre o escopo de sua falha para que eles pudessem perceber os insights da Chaos Engineering, mas mitigar potenciais desvantagens.

2016

Kolton Andrus e Matthew Fornaciari fundaram a Gremlin, a primeira solução de engenharia de caos gerenciada do mundo. O Gremlin se tornaria disponível publicamente no final de 2017 e lançaria com uma dúzia de vetores de ataque diferentes, um botão de parada incorporado para parar e reverter ataques e segurança abrangente.

2018

Gremlin lança Chaos Conf, a primeira conferência em grande escala dedicada à Engenharia do Caos. Em apenas dois anos, o número de participantes cresceria quase 10x e incluiria especialistas de software, varejo, finanças, entrega e muitas outras indústrias.

2020

A AWS adiciona a Chaos Engineering ao pilar de confiabilidade do AWS Well-Architected Framework (WAF). Ainda este ano, a AWS também anuncia o Fault Injection Simulator (FIS), um serviço totalmente gerenciado para experimentos de caos em serviços AWS.

2021

Gremlin publica o primeiro relatório state of chaos engineering. O relatório mostra como a prática da Engenharia do Caos cresceu entre as organizações, os principais benefícios da Engenharia do Caos, a frequência com que as equipes de alto desempenho executam experimentos de caos e muito mais.

Quais são os Princípios da Engenharia do Caos?

A Engenharia do Caos envolve executar experimentos pensativos e planejados que nos ensinam como nossos sistemas se comportam diante do fracasso.

Esses experimentos seguem três passos:

Você começa formando uma hipótese sobre como um sistema deve se comportar quando algo dá errado.

Então, você projeta o menor experimento possível para testá-lo em seu sistema.

Finalmente, você mede o impacto da falha em cada etapa, procurando sinais de sucesso ou fracasso. Quando o experimento acaba, você tem uma melhor compreensão do comportamento do seu sistema no mundo real.

Quais empresas praticam a Chaos Engineering?

Muitas grandes empresas de tecnologia praticam a Chaos Engineering para entender melhor seus sistemas distribuídos e arquiteturas de microsserviço. A lista inclui Twilio, Netflix, LinkedIn, Facebook, Google, Microsoft, Amazon e muitos outros. A lista está sempre crescendo.

Mas indústrias mais tradicionais, como bancos e finanças, também entraram na Chaos Engineering. Por exemplo, em 2014, o National Australia Bank migrou da infraestrutura física para a Amazon Web Services e usou a Chaos Engineering para reduzir drasticamente a contagem de incidentes.

A Chaos Engineering Slack Community criou um diagrama que rastreia ferramentas conhecidas da Chaos Engineering e engenheiros conhecidos trabalhando na Chaos Engineering.

Por que você quebraria as coisas de propósito?

Pense em uma vacina ou uma vacina contra a gripe, onde você injeta uma pequena quantidade de um corpo estranho potencialmente prejudicial, a fim de construir resistência e prevenir doenças. A Chaos Engineering é uma ferramenta que usamos para construir tal imunidade em nossos sistemas técnicos, injetando danos (como latência, falha de CPU ou buracos negros de rede) a fim de encontrar e mitigar potenciais fraquezas.

Esses experimentos têm o benefício adicional de ajudar as equipes a construir memória muscular na resolução de paralisações, semelhante a uma broca de incêndio (ou trocar um pneu furado, na analogia da Netflix). Ao quebrar coisas de propósito, vemos questões desconhecidas que podem impactar nossos sistemas e clientes.

De acordo com o relatório State of Chaos Engineering de 2021,os resultados mais comuns da Chaos Engineering são aumento da disponibilidade, menor tempo médio de resolução (MTTR), menor tempo médio de detecção (MTTD), menos bugs enviados para o produto e menos paralisações. Equipes que frequentemente executam experimentos de Engenharia do Caos são mais propensas a ter > 99,9% de disponibilidade.

Qual é o papel da Engenharia do Caos em sistemas distribuídos?

Sistemas distribuídos são inerentemente mais complexos do que sistemas monolíticos, por isso é difícil prever todas as maneiras que eles podem falhar. As oito falácias de sistemas distribuídos compartilhadas por Peter Deutsch e outros na Sun Microsystems descrevem falsas suposições que programadores novos para aplicativos distribuídos invariavelmente fazem.

Falácias de Sistemas Distribuídos:

A rede é confiável
Latência é zero
A largura de banda é infinita
A rede está segura
Topologia não muda
Há um administrador
O custo do transporte é zero
A rede é homogênea

Muitas dessas falácias impulsionam o projeto de experimentos da Chaos Engineering, como “ataques de perda de pacotes” e “ataques de latência”. Por exemplo, paralisações de rede podem causar uma série de falhas para aplicativos que afetam severamente os clientes. Os aplicativos podem parar enquanto esperam sem parar por um pacote. Os aplicativos podem consumir permanentemente memória ou outros recursos do sistema Linux. E mesmo depois que uma paralisação da rede tenha passado, os aplicativos podem não tentar novamente operações paralisadas, ou podem tentar novamente de forma muito agressiva. As aplicações podem até exigir uma reinicialização manual. Cada um desses exemplos precisa ser testado e preparado para.

Quais são os benefícios do cliente, dos negócios e dos benefícios técnicos da Chaos Engineering?

Cliente: o aumento da disponibilidade e durabilidade do serviço significa que nenhuma paralisação interrompe seu dia-a-dia.
Negócios: A Chaos Engineering pode ajudar a evitar perdas extremamente grandes nos custos de receita e manutenção, criar engenheiros mais felizes e engajados, melhorar o treinamento de plantão para equipes de engenharia e melhorar o Programa de Gestão de SEV (incidentes) para toda a empresa.
Técnico: os insights dos experimentos de caos podem significar uma redução de incidentes, redução da carga de chamada, maior compreensão dos modos de falha do sistema, melhor design do sistema, tempo médio mais rápido para detecção de SEVs e redução de SEVs repetidos.

Engenharia do Caos para equipes de serviço

Muitas organizações de engenharia, incluindo Netflix e Stitch Fix, têm equipes dedicadas da Chaos Engineering. Essas equipes são muitas vezes pequenas em tamanho, com 2-5 engenheiros. A equipe de Engenharia do Caos é dona e defensora da Chaos Engineering em toda a organização. No entanto, eles não são os únicos engenheiros que fazem a Chaos Engineering no dia-a-dia — eles capacitam equipes em toda a sua organização de engenharia para usar a Chaos Engineering.

Essas equipes de serviço são frequentemente as primeiras a praticar e evangelizar a Chaos Engineering dentro de uma empresa:

Equipe de Tráfego (por exemplo, Nginx, Apache, DNS)
Equipe de Streaming (por exemplo, Kafka)
Equipe de armazenamento (por exemplo, S3)
Equipe de Dados (por exemplo, Hadoop/HDFS)
Equipe de Banco de Dados (por exemplo, MySQL, Amazon RDS, PostgreSQL)

Algumas empresas, como a Remind, estão integrando a Chaos Engineering em seu ciclo normal de lançamento, como outros testes de práticas recomendadas, como uma maneira de garantir que a confiabilidade seja assada em todos os recursos.

Quais experimentos da Chaos Engineering você realiza primeiro?

Argumentamos que você deve realizar seus experimentos na seguinte ordem:

Conhecidos - Coisas que você está ciente e entende
Desconhecidos Conhecidos - Coisas que você está ciente, mas não entende completamente
Desconhecidos Conhecidos - Coisas que você entende, mas não está ciente
Desconhecidos - Coisas que você não está ciente nem compreende completamente

O diagrama abaixo ilustra este conceito:

Para ilustrar isso na prática com exemplos, demonstraremos como selecionar experimentos com base em um banco de dados MySQL fragmentado. Neste exemplo, temos um cluster de 100 hosts MySQL com vários fragmentos por host.

Em uma região, temos um host de banco de dados primário com duas réplicas e usamos replicação semi-sincronização. Também temos uma pseudo primária e duas pseudo réplicas em uma região diferente.

Conhecidos

Sabemos que quando uma réplica for desligada, ela será removida do cluster. Sabemos que uma nova réplica será clonada do principal e adicionada de volta ao cluster.

Conhecidos-Desconhecidos

Sabemos que o clone ocorrerá, pois temos registros que confirmam se ele tem sucesso ou falha, mas não sabemos a média semanal do tempo médio que leva de experimentar uma falha em adicionar um clone de volta ao cluster efetivamente.
Sabemos que receberemos um alerta de que o cluster tem apenas uma réplica após 5 minutos, mas não sabemos se nosso limiar de alerta deve ser ajustado para evitar incidentes de forma mais eficaz.

Desconhecidos

Se desligarmos as duas réplicas para um cluster ao mesmo tempo, não sabemos exatamente o tempo médio durante uma segunda-feira de manhã, levariamos para clonar duas novas réplicas das primárias existentes. Mas sabemos que temos um pseudo primário e duas réplicas que também terão as transações.

Desconhecidos

Não sabemos exatamente o que aconteceria se fecharmos um aglomerado inteiro em nossa região principal, e não sabemos se a pseudo região seria capaz de falhar efetivamente porque ainda não executamos esse cenário.

Criaríamos os seguintes experimentos de caos, trabalhando através deles em ordem:

Conhecidos: desligue uma réplica e meça o tempo necessário para que o desligamento seja detectado, a réplica a ser removida, o clone para dar o pontapé inicial, o clone a ser concluído e o clone a ser adicionado de volta ao cluster. Antes de iniciar este experimento, aumente as réplicas de dois para três. Execute o experimento de desligamento em uma frequência regular, mas procure evitar que o experimento resulte em 0 réplicas a qualquer momento. Informe sobre o tempo total médio para recuperação de uma falha de desligamento de réplicas e quebre isso durante o dia e hora para explicar os horários de pico.
Conhecidos-Desconhecidos: Use os resultados e dados do experimento conhecido para responder a perguntas que atualmente seriam “conhecidas-desconhecidas”. Agora você poderá saber o impacto que a média semanal do tempo médio leva de experimentar uma falha em adicionar um clone de volta ao cluster efetivamente. Você também saberá se 5 minutos é um limite de alerta apropriado para evitar SEVs.
Conhecidos desconhecidos: Aumente o número de réplicas para quatro antes de realizar este experimento. Desligue duas réplicas para um cluster ao mesmo tempo, colete o tempo médio durante uma manhã de segunda-feira ao longo de vários meses para determinar quanto tempo levaria para clonar duas novas réplicas das primárias existentes. Este experimento pode identificar problemas desconhecidos, por exemplo, o principal não pode lidar com a carga de clonagem e backups ao mesmo tempo e você precisa fazer melhor uso das réplicas.
Desconhecidos: O desligamento de um cluster inteiro (principal e duas réplicas) exigiria trabalho de engenharia para tornar isso possível. Esta falha pode ocorrer inesperadamente na natureza, mas você ainda não está pronto para lidar com isso. Priorize o trabalho de engenharia para lidar com esse cenário de falha antes de realizar experimentos de caos.

Como planeja suas primeiras experiências de caos?

Planejando seu primeiro experimento

Uma das perguntas mais poderosas da Chaos Engineering é “O que poderia dar errado?”. Ao fazer essa pergunta sobre nossos serviços e ambientes, podemos rever potenciais fraquezas e discutir os resultados esperados. Semelhante a uma avaliação de risco, isso informa prioridades sobre quais cenários são mais prováveis (ou mais assustadores) e devem ser testados primeiro. Ao sentar-se como uma equipe e branquear seus serviços, dependências (internas e externas) e armazenamentos de dados, você pode formular uma imagem de “O que poderia dar errado?”. Na dúvida, injetar uma falha ou um atraso em cada uma de suas dependências é um ótimo lugar para começar.

Criando uma hipótese

Você tem uma ideia do que pode dar errado. Você escolheu a falha exata para injetar. O que acontece depois? Este é um excelente exercício de pensamento para trabalhar como uma equipe. Ao discutir o cenário, você pode supor sobre o resultado esperado antes de executá-lo ao vivo. Qual será o impacto para os clientes, para o seu serviço ou para suas dependências?

Medindo o Impacto

Para entender como seu sistema se comporta sob estresse, você precisa medir a disponibilidade e durabilidade do seu sistema. É bom ter uma métrica de desempenho chave que se correlaciona com o sucesso do cliente (como pedidos por minuto ou stream starts por segundo). Como regra geral, se você já viu um impacto nessas métricas, você deseja parar o experimento imediatamente. O próximo é medir a falha em si, onde você deseja verificar (ou refutar) sua hipótese. Isso pode ser o impacto na latência, pedidos por segundo ou recursos do sistema. Por fim, você deseja examinar seus painéis e alarmes para efeitos colaterais não intencionais.

Tenha um plano de reversão

Sempre tenha um plano de backup caso as coisas dêem errado, mas aceite que às vezes até mesmo o plano de backup pode falhar. Fale sobre como você vai reverter o impacto. Se você está executando comandos à mão, seja atencioso em não quebrar o ssh ou controlar o acesso do avião às suas instâncias. Um dos aspectos centrais do Gremlin é a segurança. Todos os nossos ataques podem ser revertidos imediatamente, permitindo que você aborte com segurança e retorne ao estado estável se as coisas derem errado.

Vá consertar isso!

Depois de executar seu primeiro experimento, espero que haja um dos dois resultados: ou você verificou que seu sistema é resistente à falha que você introduziu, ou você encontrou um problema que você precisa corrigir. Ambos são bons resultados. Por um lado, você aumentou sua confiança no sistema e seu comportamento, e por outro você encontrou um problema antes que isso causasse uma paralisação.

Divertir-se

Chaos Engineering é uma ferramenta para facilitar seu trabalho. Testando e validando proativamente os modos de falha do seu sistema, você reduzirá sua carga operacional, aumentará sua disponibilidade e dormirá melhor à noite. Gremlin torna seguro e simples começar — envie um e-mail para começarmos hoje!

Quais são outros recursos da Chaos Engineering?

Nós consolidamos uma tonelada de informações úteis aqui no site gremlin. Fornecemos dezenas de tutoriais práticos mostrando como usar a Chaos Engineering com diferentes plataformas, serviços e tecnologias em nuvem, e até mesmo como uma ferramenta para treinar equipes de resposta a incidentes. Nosso blog abrange casos de uso e práticas usando a Chaos Engineering, como preparar-se para migrações em nuvem e executar GameDays. Esses posts podem ajudá-lo a começar com a Chaos Engineering:

Começando com a Engenharia do Caos
4 experimentos de caos para começar
Como executar um dia de jogo
Gremlin’s Gameday: Breaking DynamoDB (Tomamos nosso próprio remédio!)
O que é a Engenharia do Caos? SREs e líderes definem a prática e para onde está indo

Pavlos Ratis criou um repo gitHub chamado “Awesome Chaos Engineering”, que é uma lista com curadoria dos recursos da Chaos Engineering. Você pode encontrar Livros, Ferramentas, Jornais, Blogs, Boletins informativos, Conferências, MeetUps, Fóruns e engenheiros para seguir no Twitter.

Por fim, se você quiser aprender como a Chaos Engineering ajuda a melhorar a confiabilidade geral de seus sistemas, equipes e organização, confira nosso guia de confiabilidade em sistemas distribuídos.

O que são algumas boas apresentações da Conferência de Engenharia do Caos?

Você pode assistir a apresentações do Chaos Conf, o maior evento de Engenharia do Caos do mundo. Você também pode assistir alto-falantes do Failover Conf, que é tema mais em torno da confiabilidade e adaptação às tendências de tecnologia em mudança. Se você não tem certeza por onde começar, confira as seguintes apresentações:

Onde você pode encontrar a comunidade de Engenharia do Caos?

A comunidade de Engenharia do Caos é uma comunidade global de engenheiros. Junte-se a mais de 7.000 engenheiros na comunidade Chaos Engineering Slack em gremlin.com/slack. Você também pode seguir Gremlin no Twitter @gremlininc e no Instagram @thegremlininc.

Conclusão

À medida que os sistemas web se tornaram muito mais complexos com o surgimento de sistemas e microsserviços distribuídos, as falhas no sistema tornaram-se difíceis de prever. Então, para evitar que falhas aconteçam, todos nós precisamos ser proativos em nossos esforços para aprender com o fracasso.

Neste guia, compartilhamos uma breve história da Chaos Engineering e demonstramos como a Chaos Engineering oferece novas informações sobre seus sistemas. Estamos ansiosos para ouvir sobre sua jornada de Engenharia do Caos e incentivá-lo a compartilhar seu progresso com a comunidade de Engenharia do Caos.

Artigo oringal