O que é resiliência das aplicações?

As aplicações alimentam praticamente todos os aspectos dos negócios modernos, desde o processamento de transações de clientes e o gerenciamento de cadeias de suprimentos até a colaboração dos funcionários e a análise de dados em tempo real.

Quando essas aplicações falham, o impacto pode ser grave. O downtime, ou seja, períodos em que uma aplicação está indisponível ou não consegue funcionar corretamente, pode resultar em danos à reputação, degradação da experiência do usuário e perdas financeiras significativas.

De fato, 98% das organizações relatam que os custos de downtime excedem USD 100 mil por hora, com um terço delas estimando perdas entre USD 1 milhão e USD 5 milhões.

Ao projetar e implementar aplicações resilientes, as organizações podem evitar e mitigar essas interrupções.

A resiliência das aplicações depende de dois princípios básicos:

• Tolerância a falhas: a capacidade de uma aplicação continuar operando quando parte dela falha.

• Alta disponibilidade: capacidade de um sistema de ser acessível e confiável em quase 100% do tempo. 

Aplicações resilientes ajudam a reduzir as vulnerabilidades em sua arquitetura, melhorar a eficiência operacional e garantir uma experiência de usuário consistente, mesmo em face de interrupções inesperadas.

Para criar e implementar aplicações resilientes, os desenvolvedores e as equipes de TI podem usar várias ferramentas e práticas durante todo o ciclo de vida da aplicação.

Componentes comuns de aplicações resilientes incluem:

• Redundância
• Balanceamento de Carga
• Contenção de falhas
• Observabilidade
• Automação
• Degradação suave
• Escalabilidade

Redundância significa ter versões de backup de sistemas críticos. Se um sistema falha, o backup assume o controle, ajudando a dar continuidade ao seu funcionamento.

Por exemplo, um serviço de processamento de pagamentos provavelmente terá várias cópias do serviço em execução em servidores diferentes. Se um servidor falhar, as cópias em outros servidores poderão assumir automaticamente o controle da carga de trabalho para que os clientes não percebam o problema.

As organizações geralmente criam redundância em áreas importantes:

• Bancos de dados: armazenamento de várias cópias de dados em locais diferentes para que nada seja perdido se um sistema falhar.

• Data centers: hospedagem de aplicações em vários locais físicos para que as operações continuem mesmo que um local fique inoperante.

• Ambientes de nuvem: distribuição de aplicações entre regiões ou provedores, como Amazon Web Services (AWS), Microsoft Azure e IBM® Cloud, para eliminar pontos únicos de falha.

• Conexões de rede: utilização de vários provedores de internet ou de telecomunicações para manter a conectividade durante interrupções.

O balanceamento de carga envolve a distribuição eficiente do tráfego de rede entre vários servidores para otimizar a disponibilidade das aplicações. É fundamental para a resiliência das aplicações, pois permite que os sistemas mantenham o desempenho e a disponibilidade mesmo quando componentes individuais falham ou ficam sobrecarregados.

Por exemplo, se um servidor deixar de responder, o balanceador de carga poderá redirecionar automaticamente o tráfego para outros servidores íntegros, mantendo a aplicação online.

A contenção de falhas é uma prática de design que isola componentes críticos em um sistema distribuído, evitando que problemas localizados se transformem em interrupções em todo o sistema.

A contenção é especialmente importante em arquiteturas de microsserviços, onde uma falha em um serviço pode afetar com rapidez muitas outras dependências se não for devidamente contida.

Malhas de serviço são particularmente úteis para conter erros. Essas camadas de infraestrutura ajudam a gerenciar a comunicação entre microsserviços em aplicações distribuídas, fornecendo:

• Novas tentativas automáticas: quando uma solicitação falha devido a um problema temporário (como uma breve falha na rede), a malha faz novas tentativas automaticamente em vez de desistir de imediato.

• Interrupção do circuito: a malha monitora a integridade do serviço e para temporariamente de enviar solicitações para serviços com problemas, dando tempo para eles se recuperarem enquanto evita falhas em todo o sistema.

• Rastreamento distribuído: a malha rastreia as solicitações à medida que elas se deslocam entre diferentes serviços, ajudando as equipes a identificar lentidões e a determinar exatamente onde os problemas ocorrem.

Juntos, esses recursos ajudam a garantir que as falhas em um serviço não se espalhem para outros. Suponhamos, por exemplo, que um mecanismo de recomendação de produtos falhe em um site de comércio eletrônico. Uma malha de serviço pode detectar essa falha, impedir que as solicitações cheguem ao serviço com defeito e redirecionar o tráfego da maneira adequada. Os usuários podem continuar navegando e comprando sem interrupções.

A observabilidade permite que as equipes monitorem a integridade do sistema em tempo real usando três tipos principais de dados: métricas (indicadores de desempenho, como tempos de resposta), logs (registros de eventos, como erros ou travamentos) e rastreamentos (a jornada completa de uma solicitação por um sistema).

Ao capturar e analisar esses sinais, as equipes podem detectar anomalias, diagnosticar problemas com rapidez e reduzir o downtime. Por exemplo, se um cliente relatar uma página que está carregando lentamente, as ferramentas de observabilidade ajudam os engenheiros a rastrear a solicitação até o serviço que causou o atraso e corrigir o problema antes que ele afete mais usuários.

A automação desempenha um papel crítico na resiliência das aplicações, pois permite que os sistemas respondam a problemas sem a necessidade de intervenção manual.

Por exemplo, as ferramentas de observabilidade detectam problemas, enquanto a redundância fornece recursos de backup. A automação é o que conecta esses recursos, coordenando o processo de recuperação. Uma automação eficaz pode diminuir significativamente o tempo de recuperação, transformando longas horas de resolução manual de problemas em apenas alguns segundos de resposta automatizada.

Veja algumas das principais respostas automatizadas na resiliência das aplicações:

• Failovers com script: sequências predeterminadas de ações que transferem automaticamente operações de um sistema com falha para sistemas de backup identificados por meio de planejamento de redundância. Por exemplo, se o banco de dados principal travar, o sistema mudará automaticamente para um banco de dados de backup e redirecionará todo o tráfego para lá em questão de segundos.

• Reprovisionamento de recursos: provisionamento automático de novas instâncias ou realocação de recursos quando os componentes falham, como a criação de novas máquinas virtuais para substituir as defeituosas, sem que ninguém precise intervir.

• Fluxos de trabalho de autocorreção: coordenação entre alertas de monitoramento e ações de recuperação para restaurar o serviço sem envolvimento humano. Por exemplo, se um aplicativo começar a usar muita memória, o sistema o reiniciará automaticamente antes que os usuários percebam qualquer lentidão.

Ferramentas como o Kubernetes, sistema de código aberto para gerenciar aplicação em contêineres, demonstram como a automação une os componentes de resiliência. O Kubernetes pode detectar falhas por meio de verificações de integridade incorporadas, reagendar cargas de trabalho em nós íntegros e manter a continuidade do serviço por meio de fluxos de trabalho automatizados.

A degradação suave envolve a manutenção da funcionalidade principal e a eliminação de recursos não essenciais durante o estresse. Por exemplo, durante os picos de tráfego da Black Friday, um varejista pode desativar temporariamente as avaliações de clientes e as listas de desejos para permitir que o carrinho de compras e a finalização da compra permaneçam funcionais.

As aplicações escaláveis podem ajustar automaticamente os recursos de acordo com as demandas de carga de trabalho. Esse recurso ajuda a garantir o desempenho e a disponibilidade mesmo com as flutuações do tráfego.

A escalabilidade pode ser alcançada de várias maneiras. Por exemplo, as plataformas baseadas em nuvem oferecem escalabilidade por meio de recursos como balanceadores de carga integrados, ajuste de escala automático e replicação multirregional, ou seja, cópia de dados e serviços em várias localizações geográficas para melhorar o desempenho e a confiabilidade. Esses recursos permitem que os serviços distribuam o tráfego de forma inteligente, mantenham o tempo de atividade e minimizem o tempo de recuperação em resposta a mudanças nas condições.

Por exemplo, uma plataforma de streaming hospedada na nuvem normalmente pode operar em 100 servidores. No entanto, durante um evento global ao vivo, ela pode escalar automaticamente para 10 mil servidores em várias regiões, proporcionando uma reprodução fluida para milhões de espectadores simultâneos.

Como as aplicações de software se tornaram essenciais para as operações e para a vida cotidiana dos consumidores, é fundamental que elas resistam a interrupções inesperadas e permaneçam funcionais em quase todas as condições.

Quatro fatores em particular impulsionam a crescente ênfase na resiliência das aplicações.

• Altas expectativas dos consumidores
• O custo do downtime
• Complexidade arquitetônica
• Pressão regulatória

Os clientes esperam que os serviços digitais sempre funcionem. De acordo com o Google, 53% dos visitantes abandonam uma página em dispositivos móveis se ela demorar mais de três segundos para carregar.

Seja um aplicativo bancário, plataforma de comércio eletrônico ou portal de saúde, o downtime pode desencadear deserções de clientes, reações adversas nas redes sociais e danos duradouros à marca. A disponibilidade de aplicações não é apenas uma métrica técnica, mas um requisito comercial fundamental.

Interrupções de aplicações podem custar caro para organizações de todos os tamanhos. Considere um cenário comum: uma marca de varejo lança um evento de vendas de alto tráfego, mas o serviço de finalização de compra falha devido à demanda adicional. Em poucos minutos, milhares de transações param, os clientes ficam frustrados e a empresa perde receita.

Além da perda de vendas, as interrupções podem desencadear uma cascata de custos secundários, desde despesas de remediação e violações de contratos de nível de serviço (SLA) até penalidades regulatórias, indenizações a clientes e danos de longo prazo à marca.

Incidentes recentes de grande visibilidade mostram o quão significativo pode ser o impacto:

• Transporte: em 2016, a interrupção em um data center levou ao cancelamento de 2 mil voos e gerou um prejuízo de USD 150 milhões para uma grande companhia aérea.

• Comércio eletrônico: durante um evento de pico de vendas em 2018, interrupções técnicas custaram a um varejista online um valor estimado de USD 72 a USD 99 milhões em receita perdida.

• Redes sociais: em 2021, uma interrupção de seis horas no serviço custou a um gigante da internet aproximadamente USD 100 milhões em receita publicitária perdida.
  

As arquiteturas de aplicação modernas possuem muitas partes móveis: microsserviços, ambientes multinuvem, bibliotecas de códigos etc. Embora esses componentes modulares melhorem a escalabilidade, eles também aumentam o número de possíveis pontos de falha.  

Sem projeto e implementação resilientes, até mesmo problemas menores podem escalar. Uma única falha de microsserviço pode se espalhar por dezenas de dependências. Por exemplo, se um serviço de banco de dados que armazena informações de produtos para de funcionar, isso pode interromper outros funcionalidades, como pesquisa, recomendações ou finalização de compra.

Interrupções de rede entre regiões de nuvem também podem fragmentar serviços e causar inconsistências de dados. Diferentemente de uma falha de microsserviço, em que um componente para de funcionar completamente, esses problemas de conectividade criam um cenário de “cérebro dividido”: diferentes partes da aplicação continuam em execução, mas não conseguem se comunicar entre si.

Por exemplo, o sistema de pedidos de um aplicativo de negociação financeira pode ficar desconectado dos dados de preços em tempo real, fazendo com que os usuários vejam cotações incorretas ou tenham negociações malsucedidas.

As interrupções em interfaces de programação de aplicativos (API) também podem interromper funcionalidades críticas. Embora as falhas de microsserviço afetem os componentes internos que a organização controla, as interrupções em APIs envolvem serviços de terceiros de que uma aplicação depende, mas não pode corrigir diretamente. Por exemplo, se o serviço de mapeamento de um aplicativo de entrega ficar fora do ar, os usuários não conseguirão rastrear os motoristas, e estes não conseguirão encontrar as rotas, prejudicando a experiência, mesmo que a aplicação principal permaneça funcionando.

Em determinados setores e locais, os órgãos reguladores estabeleceram requisitos rigorosos para disponibilidade de dados, recursos de recuperação de aplicativos, mitigação de perda de dados e tempo de atividade. Esses requisitos elevam a resiliência das aplicações de uma meta técnica para uma questão de conformidade.

Algumas leis de proteção de dados e de privacidade agora incluem normas de disponibilidade junto com exigências de segurança. Por exemplo, o Regulamento Geral de Proteção de Dados (RGPD) exige que os dados pessoais permaneçam protegidos e acessíveis. No caso de falha do sistema, espera-se que as organizações recuperem os dados perdidos.

Em particular, os setores altamente regulamentados enfrentam algumas das normas mais rigorosas. 

Embora a Lei Sarbanes-Oxley (SOX) não exija explicitamente planos de recuperação de desastres, muitas organizações mantêm sistemas de backup e procedimentos formais de recuperação para ajudar a cumprir e comprovar a conformidade com a lei.

As instituições financeiras também enfrentam regulamentações e recomendações específicas do setor, de órgãos como o Federal Financial Institutions Examination Council (FFIEC), que fornece orientações detalhadas sobre o planejamento de continuidade de negócios e objetivos de tempo de recuperação.

De acordo com a Lei de portabilidade e responsabilidade de planos de saúde (HIPAA), as entidades cobertas devem implementar salvaguardas administrativas, físicas e técnicas para ajudar a garantir a disponibilidade e a integridade das informações de saúde protegidas (ePHI). Embora a HIPAA não exija acesso 24 horas por dia, 7 dias por semana, ela exige que as organizações de saúde mantenham o acesso aos dados do paciente quando necessário para o tratamento.

A regra de segurança da HIPAA exige planos de backup de dados, procedimentos de recuperação de desastres e operações em modo de emergência, o que leva muitas organizações a investir em estratégias avançadas de failover e replicação de dados.

Para permitir que os sistemas possam suportar interrupções do mundo real, as organizações validam a resiliência das aplicações por meio de uma combinação de medição contínua e testes proativos. Essas abordagens permitem que as equipes monitorem o desempenho, identifiquem vulnerabilidades e confirmem se as aplicações podem se recuperar de forma rápida e eficaz.

As equipes de DevOps, em particular, frequentemente integram práticas de resiliência em pipelines de integração/entrega contínua (pipelines de CI/CD). Isso permite que elas automatizem o teste dos procedimentos de failover, validem as alterações de configuração e revertam implementações instáveis para detectar problemas com antecedência e evitar que as interrupções cheguem aos usuários.

As organizações contam com várias métricas-chave para avaliar a resiliência das aplicações. 

As organizações estão cada vez mais recorrendo a testes para ter uma perspectiva mais realista. Quando as métricas fornecem uma base, os testes ajudam as organizações a passar da prontidão teórica para a resiliência comprovada. 

A inteligência artificial (IA) e o aprendizado de máquina (ML) estão remodelando a forma como as organizações abordam a resiliência. Essas tecnologias trazem ferramentas novas e eficientes para evitar o downtime, mas também introduzem desafios singulares.

Um dos maiores desafios é que as cargas de trabalho de IA consomem muitos recursos. Muitos modelos dependem de unidades de processamento gráfico (GPUs), que são caras e difíceis de duplicar entre as regiões da nuvem. Isso torna a redundância (uma parte essencial da resiliência) mais difícil de alcançar.

Os sistemas de IA também podem falhar de maneiras inesperadas. Com o tempo, sua precisão pode se degradar, um problema conhecido como desvio do modelo. Ou eles podem encontrar inputs adversários, ou seja, dados maliciosos projetados para enganar o sistema. Esses tipos de falhas podem ser mais difíceis de prever e conter.

Além disso, quando as funcionalidades de IA ficam lentas ou param de funcionar, um problema comum em ambientes de nuvem devido a restrições de recursos ou latência, o restante da aplicação ainda precisa ter um desempenho confiável, colocando pressão adicional sobre estratégias de degradação suave.

Ao mesmo tempo, a IA tem casos de uso importantes para aumentar a resiliência:

• A análise preditiva de dados prevê falhas futuras analisando padrões e tendências históricas. Isso ajuda as equipes a substituir proativamente o hardware ou ajustar os recursos antes que ocorram problemas, como prever falhas de disco com dias de antecedência com base nas tendências de temperatura e taxa de erros.

• A remediação inteligente utiliza IA para tomar decisões de recuperação mais inteligentes. Enquanto os sistemas automatizados tradicionais podem simplesmente reiniciar um serviço com falha, a remediação impulsionada por IA pode analisar padrões para escolher a estratégia de recuperação ideal, como redirecionar o tráfego para regiões menos carregadas ou escalar recursos com base na demanda prevista.

• A detecção de anomalias permite que a IA identifique irregularidades sutis e em tempo real que o monitoramento baseado em regras pode deixar passar, como combinações incomuns de métricas que sinalizam um problema emergente mesmo quando as métricas individuais parecem normais.

• Os testes orientados por IA permitem que as equipes de DevOps usem a IA para simular cenários de falha mais complexos no início do processo de desenvolvimento de software.

Em resumo, embora a IA introduza nova complexidade, ela também pode permitir uma recuperação mais rápida, um monitoramento mais inteligente e aplicativos mais resilientes em geral, especialmente quando integrada a ambientes nativos da nuvem e pipelines de DevOps.