O que a confiabilidade significa para sistemas distribuídos, os desafios na construção de sistemas confiáveis e como superar esses desafios usando a Engenharia do Caos.
Todos os aplicativos, independentemente de sua função, complexidade ou linguagem de programação, precisam de sistemas confiáveis para serem executados. Sem sistemas confiáveis, não teríamos a infraestrutura de computação em rede em grande escala que temos hoje. Mas o que realmente significa confiabilidade em termos de tecnologia e sistemas?
Confiabilidade é a capacidade de um sistema permanecer disponível por um período de tempo. Sistemas confiáveis são capazes de atender o tráfego de clientes de forma consistente, sem erros ou interrupções. Embora a tecnologia confiável sempre tenha sido importante – como comprovado pela crescente prática da engenharia de confiabilidade do site (SRE) – ela está se tornando cada vez mais importante para as aplicações modernas.
A razão é que o mundo moderno é executado em sistemas distribuídos. Usamos esses sistemas para gerenciar tudo, desde serviços bancários on-line até telecomunicações e assistência médica. À medida que esses sistemas desempenham papéis cada vez mais importantes na vida cotidiana, as expectativas dos clientes quanto à disponibilidade também estão aumentando. As interrupções não afetam apenas nossa capacidade de gerar receita, elas também afetam a vida de nossos clientes, seja voos atrasados causados por uma falha de computador ou um erro operacional que desativou os principais serviços bancários. De acordo com o Gartner, as empresas perdem em média US$ 336.000 por hora de inatividade e, para empresas que prestam serviços críticos ou estão em setores regulamentados, esses custos são ainda maiores.
A engenharia de sistemas distribuídos confiáveis é um desafio, e mesmo os sistemas mais bem projetados são propensos a falhas inesperadas. Isso se deve a dois fatores principais: aumentar a velocidade de desenvolvimento e aumentar a complexidade do sistema.
DevOps e os métodos ágeis aceleraram rapidamente o ciclo de vida de desenvolvimento de software, permitindo que as organizações inovem e forneçam valor aos clientes mais rápido do que nunca. No entanto, esse aumento de velocidade exige que mudemos a maneira como testamos o software. As práticas tradicionais de garantia de qualidade (QA) não podem mais acompanhar o ritmo e a complexidade do desenvolvimento de software moderno, nem podem testar comportamentos emergentes ou falhas em nível de infraestrutura. Isso resulta em um aumento da taxa de falhas entrando em produção.
A computação em nuvem e as arquiteturas nativas da nuvem, como microsserviços, tornaram nossos aplicativos muito mais dinâmicos e escaláveis, mas também adicionaram uma complexidade significativa aos nossos ambientes. Substituímos monólitos estáticos e de longa duração por contêineres discretos e pouco acoplados. Substituímos os data centers locais provisionados manualmente por plataformas de nuvem automatizadas que gerenciam nossos servidores para nós. Substituímos as implantações manuais por ferramentas de CI/CD que compilam, testam e implantam nossos aplicativos. Nossos ambientes estão maiores do que nunca e estão sendo gerenciados por plataformas automatizadas que orquestram, dimensionam e mantêm nossas cargas de trabalho sem nossa intervenção.
A automação eliminou grande parte da sobrecarga administrativa dos sistemas de gerenciamento, mas resultou em nossos sistemas comportamentos distintos. Esses comportamentos são difíceis de prever, especialmente com medidas de teste tradicionais. As ferramentas automatizadas não são apenas imperfeitas, mas nem sempre entendemos como elas funcionarão em todas as situações. Além disso, muitas de nossas cargas de trabalho são efêmeras: os serviços iniciam e param constantemente com base na demanda ou nos recursos disponíveis. Isso torna ainda mais difícil solucionar problemas, pois um componente com falha pode não existir mais quando os engenheiros detectarem a falha. Combine isso com o fato de que as plataformas de nuvem limitam nossa capacidade de gerenciar e observar a infraestrutura, e a confiabilidade se torna um problema muito maior.
Tudo isso aumenta a complexidade da manutenção de aplicativos e, à medida que a complexidade aumenta, aumenta também o risco de falha. Cada nova ferramenta automatizada, plataforma, serviço de orquestração e dependência adicionada aos nossos ambientes aumenta o risco de uma interrupção, pois uma falha em qualquer componente pode derrubar todo o sistema. Mesmo pequenas alterações nas configurações e nos processos de implantação podem afetar os aplicativos de maneiras inesperadas. No entanto, esperamos que os engenheiros de confiabilidade do site (SREs) mantenham esses sistemas e serviços funcionando com o mínimo de tempo de inatividade.
Exploramos os fatores subjacentes que causam baixa confiabilidade, mas ainda não temos uma imagem clara de como a baixa confiabilidade se manifesta nos sistemas. Como nossos sistemas e aplicativos falham e como abordamos e mitigamos essas falhas?
A confiabilidade do sistema é um tópico amplo que varia dependendo do ambiente e da equipe, mas podemos resumi-lo em categorias distintas. Essas categorias – que chamamos de princípios de confiabilidade – destinam-se a orientar os esforços de engenharia de confiabilidade para que possamos identificar e abordar as falhas com mais eficácia. Isso elimina as suposições da confiabilidade, destacando possíveis falhas e problemas de confiabilidade, fornecendo objetivos claros e ações corretivas e orientando os SREs no processo de abordá-los. Esses princípios incluem falhas de dependência, dimensionamento, autorrecuperação e redundância e recuperação de desastres.
Dependências são componentes de software que fornecem funcionalidade adicional a um aplicativo ou serviço. Eles incluem serviços internos prestados por outras equipes da organização; serviços gerenciados de terceiros (por exemplo, software como serviço ou SaaS); e serviços externos autogerenciados, como aqueles hospedados em plataforma como serviço (PaaS) ou infraestrutura como serviço (IaaS). As dependências criam pontos de falha adicionais que podem causar falhas em nossos próprios serviços, a menos que os projetemos para tolerar falhas de dependência.
As estratégias para mitigar as falhas de dependência incluem:
Escalabilidade é a capacidade de alocar dinamicamente recursos para um serviço em resposta a mudanças na demanda. Os sistemas distribuídos geralmente usam dimensionamento vertical (aumentando a capacidade de um único host) e dimensionamento horizontal (aumentando a capacidade total de um serviço distribuindo-o por vários hosts).
As estratégias para mitigar falhas de dimensionamento incluem:
A autorrecuperação é a capacidade de um serviço detectar e recuperar automaticamente de falhas internas. Os serviços que exigem intervenção humana para se recuperar de incidentes resultam em interrupções mais longas, colocam mais estresse em suas equipes de resposta a incidentes e correm maior risco de falha na recuperação.
As estratégias para mitigar falhas de autorrecuperação incluem:
Redundância é o processo de replicação de dados e serviços para fornecer uma opção de contingência em caso de falha. Ela reduz o risco de uma falha do sistema se tornar uma interrupção, espalhando o risco por várias réplicas. Com os mecanismos de tolerância a falha adequados, os sistemas redundantes podem continuar operando durante uma falha sem interrupções de serviço ou perda de dados.
A recuperação de desastres é a prática de restaurar as operações após um evento disruptivo, como uma grande interrupção ou desastre natural. As equipes que realizam o planejamento de recuperação de desastres (DRP) estão mais bem preparadas para responder a esses eventos e colocar seus serviços online mais rapidamente. A redundância é uma parte essencial do planejamento de recuperação de desastres, pois ajuda as organizações a reduzir seu objetivo de tempo de recuperação (RTO), objetivo de ponto de recuperação (RPO) e tempo médio de recuperação (MTTR).
As estratégias para mitigar falhas de redundância incluem:
Esses princípios fornecem orientação sobre como identificar e evitar falhas, mas mesmo que projetemos nossos sistemas com o maior número possível de mecanismos de resiliência, não saberemos sua eficácia até experimentarmos um incidente ou testá-los proativamente. As formas tradicionais de teste não são abrangentes o suficiente para testar nossos sistemas dinâmicos, complexos e modernos e, portanto, precisamos de uma nova abordagem. Essa abordagem é a Engenharia do Caos.
A Engenharia do Caos é a prática de experimentar intencionalmente um sistema injetando falhas, observando como o sistema responde e usando nossas observações para melhorar a resiliência do sistema. A Engenharia do Caos nos permite simular condições que podem resultar em falhas, como consumo excessivo de recursos, latência de rede e interrupções do sistema, de maneira segura e controlada. Isso ajuda a expor falhas latentes e inesperadas ocultas em nossos sistemas, permitindo implementar correções e validar nossa resiliência antes de implantar na produção.
Com a Engenharia do Caos, podemos aplicar os princípios de confiabilidade acima a cenários do mundo real, como:
A Engenharia do Caos fornece uma abordagem segura e controlada para testes de confiabilidade. Em vez de causar falhas aleatórias e descontroladas, estruturamos nossos testes em torno de experimentos de caos. Esses são experimentos cuidadosamente projetados que testam nossa compreensão de como nossos sistemas funcionam com o objetivo de torná-los mais resilientes.
Um experimento de caos começa com uma hipótese sobre como esperamos que nossos sistemas se comportem sob certas condições. Uma hipótese pode abranger qualquer cenário, mas podemos usar os princípios de confiabilidade listados acima para orientar nossos experimentos iniciais. Podemos fazer perguntas como “O que acontece com meu serviço se…”
Em seguida, determinamos a melhor maneira de testar essa hipótese. Por exemplo, ao testar uma conexão com uma dependência crítica, precisamos de uma forma de simular uma falha na conexão de rede entre nosso serviço e nossa dependência. Tradicionalmente, isso significaria alterar as regras do firewall ou bloquear uma porta em um roteador ou switch. Ferramentas de engenharia do caos como Gremlin simplificam isso fornecendo uma estrutura para injetar falhas em sistemas de maneira controlada, para que possamos testar nossos sistemas sob condições de falha sem causar danos reais.
As ferramentas da Engenharia do Caos nos dão controle total sobre como injetamos a falha, incluindo o tipo de falha, o número de sistemas afetados (chamado raio de alcance), a gravidade da falha (chamada magnitude) e a duração. Ao começar com a Engenharia do Caos, mantenha o raio e a magnitude do alcance baixos para focar o teste de confiabilidade em um único sistema, aplicação ou serviço. À medida que aprendemos mais sobre nossos sistemas e trabalhamos na construção de sua resiliência, podemos expandir gradualmente o escopo de nossos testes aumentando o raio e a magnitude do alcance. Isso nos dá a chance de encontrar e descobrir problemas gradualmente, em vez de testar todo o sistema de uma só vez.
A segurança também é uma parte crítica da Engenharia do Caos. A injeção de falha vem com o risco de causar inadvertidamente uma falha maior do que o pretendido. É por isso que é fundamental ter uma maneira de interromper e reverter rapidamente um experimento. Com o Gremlin, podemos interromper experimentos manualmente ou usar verificações de status automáticas para monitorar continuamente nossos sistemas quanto a falhas e interromper experimentos que crescem fora de controle.
À medida que executamos experimentos e descobrimos novas falhas, devemos acompanhar nossas descobertas e nossas correções. É assim que acompanhamos as melhorias incrementais de confiabilidade ao longo do tempo e vemos como nossos sistemas estão se tornando mais confiáveis como resultado de nossa iniciativa de confiabilidade. Depois de concluir um experimento e corrigir as falhas podemos automatizar nossos experimentos de caos como parte de nosso pipeline de CI/CD para verificar continuamente as regressões.
Com o Gremlin, você pode validar continuamente a confiabilidade de seus sistemas e serviços em relação a essas e outras categorias de falhas. O Gremlin facilita o projeto e a execução de experimentos em seus sistemas, o agendamento de ataques para validação contínua e a integração com sua plataforma de CI/CD. O Gremlin inclui um conjunto completo de Cenários para testar a resiliência a falhas comuns, incluindo falhas de dependência, falhas de dimensionamento automático, falhas de host, interrupções de DNS e evacuação de região. Você pode começar solicitando uma avaliação gratuita interagindo no nosso chatbot.
Confiabilidade é a capacidade de um sistema permanecer disponível por um período de tempo.
Melhorar a confiabilidade em sistemas distribuídos é um desafio por dois motivos principais:
A confiabilidade pode ser categorizada em quatro princípios :
A Engenharia do Caos é a prática de injetar danos medidos em um sistema e observar sua resposta para melhorar sua resiliência.
Antes de executar um experimento de caos, certifique-se de poder interromper e reverter o impacto para evitar consequências não intencionais em seus sistemas.
Automatize experimentos de caos em seu pipeline de CI/CD para validar continuamente sua confiabilidade.
Site Reliability Engineering (SRE) é o resultado da combinação de responsabilidades de operações de TI com desenvolvimento de software. Com o SRE, há uma expectativa inerente de responsabilidade para atender aos objetivos de nível de serviço (SLOs) definidos para o serviço que eles gerenciam e os acordos de nível de serviço (SLAs) que prometemos em nossos contratos.
O que significa observabilidade, como definir objetivos de nível de serviço (SLOs), como a observabilidade ajuda a tornar os sistemas mais confiáveis e como validar sua prática de observabilidade.
Como uma cultura de confiabilidade ajuda as equipes a construir sistemas e processos mais confiáveis.
Somos parceiros Gremlin – Saiba mais sobre como manter a gestão de confiabilidade de seus ambientes e produtos de software.
Nossos squads multidisciplinares também entregam tudo pronto ! Desde desde a concepção, design, arquitetura até a execução dentro do prazo e budget.
O Sizify® por observabilidade e monitoramento ativos, reduz o GAP entre:
a) experiência do usuário durante o uso;
b) gestão de confiabilidade de software e ambientes;
c) exigências de qualidade do produto.
