A Netflix deu ao mundo dois lindos presentes: uma plataforma de streaming de mídia para o público em geral e um macaco maravilhoso para a comunidade tecnológica. Já foi dito o suficiente sobre a parte de streaming de mídia, então vamos brincar (ou trabalhar) com o macaco agora. Quando a Netflix divulgou ao mundo sobre o Chaos Monkey, a comunidade tecnológica parou um minuto para se levantar e aplaudir. Desde então, tem sido um padrão desencadear o caos intencional apenas para ver quão robustas são realmente as nossas pilhas de tecnologia.

Para quem conhece Chaos Monkey por nomes diferentes, tudo começou quando a Netflix desenvolveu uma ferramenta que intencionalmente causa estragos em seus sistemas e observa onde estão os impactos. Uma infraestrutura resiliente não deve deixar os clientes serem afetados, por isso o Chaos Monkey expõe os pontos fracos. O termo engenharia do caos tornou-se mais prevalente, incentivando muitas organizações a usá-lo para eliminar bugs que normalmente não eram encontrados há décadas.

Isso nos leva à questão principal: por que você deveria considerar a engenharia do caos em um ambiente Azure? A nuvem é um produto complexo e brilhantemente construído. Uma empresa típica utiliza vários produtos Azure para as suas aplicações e serviços. Esses serviços estão todos vagamente conectados entre si, mas são muito dependentes. Uma interrupção ou degradação do desempenho em um serviço pode ser transferida para outros serviços mais rapidamente do que o esperado. As falhas na zona de disponibilidade também são um grande fator a considerar ao tentar tornar a sua infraestrutura resiliente. Mas, novamente, por que a engenharia do caos especificamente em um ambiente Azure?

Os serviços em nuvem hospedam diferentes processos em diferentes serviços divididos em pacotes. A chance de uma falha passar despercebida é maior em uma plataforma em nuvem do que em uma configuração local, porque você tem dados, processos e aplicativos em silos. O Azure é o nosso exemplo hoje, mas o cenário de engenharia caótica vale para todos os outros provedores de serviços de nuvem pública.

• A VM foi reiniciada?
• Os bancos de dados estão conectados à VM corretamente?
• Os bancos de dados dependem da VM com alta latência?
• Algum cliente foi afetado porque a VM foi desligada?
• Por quanto tempo os clientes foram afetados?

Essas são as perguntas que surgem nos primeiros 10 segundos após imaginar a situação. Mas, na realidade, quando este cenário acontece na produção, sai fumo também de uma quantidade substancial de outros serviços dependentes. Infalível? Não.

E se houver caos, mas você não sabe disso? Você não quer estar em uma posição em que haja perda de dados ou algo esteja quebrado, mas ninguém sabe disso até que um cliente irritado envia um e-mail de duas páginas ameaçando passar para seu concorrente. Em termos do exemplo acima, a VM está funcionando perfeitamente, mas e se mysqldb.exe não tiver iniciado mesmo após reiniciar a VM?

Por mais que pareça assustador (e emocionante), a engenharia do caos prepara você para o pior. Equipes em todo o mundo implantam macacos do caos pelo menos em seus ambientes de teste (se se sentirem corajosos no dia, também em seus ambientes de produção) para ver os elos mais fracos e implantar contramedidas. Se você se sentir pronto para iniciar o caos (engenharia), vá imediatamente para o Azure Chaos Studio, onde verá instruções sobre como usar a própria ferramenta do Azure para testar a engenharia do caos.

Como o Site24x7 se encaixa aqui?

1. Quando a VM é desligada :
   1. Site24x7 envia um alerta de inatividade para o sysadmin .
   2. A automação de TI entra em ação e tenta reiniciar a VM .
   3. A integração de monitorização da Rede Virtual Azure envia um alerta de inatividade informando que há muitos pings falhados para o VM.
   4. O Site24x7 envia alertas informando que seus bancos de dados estão enfrentando degradação de desempenho por meio do Banco de Dados do Azure para integração MySQL ou da integração de monitoramento de banco de dados MySQL .
2. Depois que a VM for reiniciada :
   1. O Site24x7 envia uma notificação de que a VM está online novamente.
   2. Site24x7 envia um alerta de que o serviço mysqldb.exe está inativo .