Uma abordagem multidimensional proativa para evitar falhas operacionais, Parte 3: Operações e resiliência de processos

Na parte 3, exploramos como desenvolver aplicações mais resilientes e a necessidade de se testar e dividir processos operacionais e run books. Alguns processos são necessários para capturar métricas de baseline e condições de limite. Para detectar desvios e anomalias, se faz necessário logs de eventos, métricas, rastreamento, monitoração e alertas. Automação de testes e rollback devem fazer parte de pipelines do processo de integração e implantação contínuas (CI/CD). Para mantermos o controle e integridade da rede, das aplicações, e de sistemas, se faz necessária automação.

Para atendermos os requisitos de RPO (Objetivo de ponto de recuperação) e RTO (Objetivo do tempo de recuperação) de sistemas distribuídos, necessitamos de automação para implementar processos de failover em todas as camadas. Vamos explorar como a resiliência operacional de sistemas distribuídos precisa ser endereçada antes que seja colocada em produção e, uma vez em produção, e durante falhas operacionais.

Padrão 1: Padronizar e automatizar a configuração de contas AWS

Crie processos e automação para adicionar novos usuários e fornecer acesso à contas AWS de acordo acordo com sua função e unidade de negócios, conforme definido pela organização. O acesso federado às contas e organizações da AWS simplifica o gerenciamento de custos, a implementação de segurança e provê visibilidade. Definir uma estratégia ideal para organizar suas contas AWS de forma adequada pode reduzir impactos relacionados com falhas segurança e acesso indevido.

1. Ter mecanismos de auditoria implementados. O AWS CloudTrail monitora conformidade, melhorando a postura de segurança e auditando todos os registros de atividade em contas AWS.
2. Pratique o modelo de segurança de privilégio mínimo ao configurar o acesso aos logs de auditoria do CloudTrail, de rede, e de aplicações. Siga as práticas recomendadas sobre políticas de controle de serviço e IAM Boundaries para ajudar a garantir que suas contas da AWS permaneçam dentro das políticas de controle de acesso de sua organização.
3. Explore AWS Budgets, AWS Cost Anomaly Detection, e AWS Cost Explorerpara implementar técnicas de optimização de custos. Utilize também os recursos do AWS Compute Optimizer e Instance Scheduler on AWS para otimizar o tipo de instâncias utilizadas, e desligá-las automaticamente fora do horário de expediente. O guia básico de Gerencimento de Custos AWS apresenta várias ténias de optimizações de custos.
4. Use o AWS CloudFormation para detectar mudanças no ambiente e executar ações corretivas para manter os recursos em conformidade, conforme demonstrado na Figura 1.

Padrão 4: Mantenha seu código em um repositório com controle de versões, independentemente do GitOps

As solicitações de merge e as alterações de configuração devem seguir o mesmo processo utilizado em código de aplicações. Assim como acontece com o o código de aplicações, gerencie a infraestrutura como código (IaC) submetendo o código ao repositório, enviando solicitações pull, escaneando o código em busca de vulnerabilidades, alertando e enviando notificações, executando testes de validação e implantação, e implementando um processo adequado de aprovação.
Você pode auditar alterações na infraestrutura, definir padrões reutilizáveis, e aderir aos objetivos de RTO de seu sistema distribuído criando seu próprio IaC (Figura 4). O IaC é crucial para resiliência operacional.

Padrão 5: Infraestrutura imutável

Um pipeline de implantação imutável inicia um conjunto de novas instâncias que possuem uma nova versão de aplicações. Você pode personalizar a imutabilidade em diferentes níveis de granularidade, dependendo de qual parte da infraestrutura está sendo reconstruída para novas versões das aplicações, como demonstrado na Figura 5. Quanto mais componentes de infraestrutura imutáveis forem reconstruídos, mais caras serão as implantações, tanto no tempo de implantação quanto em custos operacionais reais. A infraestrutura imutável também é mais fácil de reverter, se necessário.

Padrão 6: Teste desde o início, e com frequência

Em uma abordagem de teste shift-left, comece os testes em seus estágios iniciais de desenvolvimento, conforme demonstrado na Figura 6. Essa prática pode revelar defeitos que podem ser resolvidos de maneira mais econômica e em menos tempo se comparados com os testes pós-desenvolvimento.

O teste contínuo é uma parte essencial do CI/CD. Os pipelines de CI/CD devem implementar vários níveis de teste para reduzir a probabilidade de defeitos serem introduzidos em produção. Os testes podem incluir: unidade, funcional, regressão, carga e caos.

O teste contínuo requer testar e exceder as condições de limite existentes, atualizando os casos de teste quando os limites forem alterados. Os casos de teste devem testar a idempotência dos sistemas distribuídos. O teste de caos (chaos testing) beneficia os processos de resposta à incidentes em sistemas distribuídos que possuem vários pontos de integração. Ao testar nossos mecanismos de escalonamento automático e failover, o teste de caos melhora o desempenho e a resiliência das aplicações.

O AWS Fault Injection Simulator (AWS FIS) é um serviço para testes de caos. Um modelo de experimento padrão contém ações que param e iniciam instâncias, juntamente com a lista de instâncias a serem testadas. Além disso, você pode especificar as condições de parada e verificar se elas acionam os alarmes desejados do Amazon CloudWatch, conforme demonstrado na Figura 7.

Padrão 7: Fornecendo visibilidade operacional

Em produção, a visibilidade operacional em várias dimensões é necessária, em especial, para sistemas distribuídos (Figura 8). Para identificar gargalos e falhas de desempenho, AWS X-Ray e bibliotecas de código aberto podem ser usadas para para rastreamento distribuído.
Envie logs de aplicações, infraestrutura, e segurança para CloudWatch. Quando as métricas violarem os limites de alarme estabelecidos, configure os alarmes correspondentes para enviarem uma notificação utilizando Amazon Simple Notification Service, ou integre com seu sistema de gerenciamento de incidentes.
Serviços de monitoramento, como Amazon GuardDuty, são usados para analisar diferentes fontes de dados, como o AWS CloudTrail, DNS, VPC Flow Logs, e logs de de auditoria de Amazon Elastic Kubernetes Service para detectar problemas de segurança. Verifique o seu AWS Health Dashboard para identificar eventos de manutenção, fim de vida útil, ou de nível de serviço que possam afetar seu ambiente AWS. Siga as recomendações do AWS Trusted Advisor para garantir que suas contas sigam todas as práticas recomendadas.

A Figura 9 explora vários componentes de aplicações e infraestrutura que se integram aos componentes de log e monitoramento da AWS para melhor detecção e resolução de problemas, que fornecem visibilidade operacional.

Ter um plano de gerenciamento de resposta a incidentes é um mecanismo importante para fornecer visibilidade operacional. Entretanto, para uma execução bem-sucedida, todas as partes envolvidas devem conhecer o modelo de responsabilidade compartilhada da AWS, simulações de falhas previsíveis e imprevisíveis, documentação dos KPIs dos sistemas distribuídos, e desenvolvimento contínuo de processos. A Figura 10 demonstra os recursos necessários para um plano de gerenciamento de resposta a incidentes ideal.

Conclusão

Na Parte 3, discutimos como estabelecer um processo contínuo de melhorias de processos testando-os e dividindo-os em partes. Para que possamos entender as métricas de baseline, os contratos de serviços, e condições de limite de um sistema, precisamos capturar os seus RNFs. Recursos operacionais são necessários para identificar desvios e anomalias, que é onde entram os alertas, registros de log e rastreamento distribuído. Processos devem ser definidos para automatizar testes frequentes em pipelines de CI/CD, detectar problemas de rede e implantar um conjunto de infraestrutura redundante em outras regiões com base nos requisitos de RTOs e RPOs. Uma ativação automática de failover depende de métricas e alarmes, e utilizando metodologias de teste de caos, podemos simular ativações de failover.

Prepare-se para o pior e aprenda com aperfeiçoá-lo. A manutenção de resiliência é uma tarefa contínua.

Quer aprender mais?

• Melhores práticas para desenvolvimento de aplicações em núvem utilizando o AWS CDK
• Estratégias de múltiplos ramificações em CodePipeline com uma architecrtura baseada em eventos

Este artigo foi traduzido do Blog da AWS em Inglês.

Sobre os autores

Piyali Kamra é uma experiente arquiteta empresarial e tecnóloga com mais de 21 anos de experiência prática na criação e execução de projetos de TI corporativos de grande escala internacional. Ela acredita que construir sistemas corporativos de grande escala não é uma ciência exata, mas sim uma arte, onde nem sempre é possível escolher a melhor tecnologia que vem à mente, mas ferramentas e tecnologias devem ser cuidadosamente selecionadas com base na cultura, pontos fortes, fracos e riscos do time, além de ter uma visão futurista de como você deve moldar produtos que resistam à prova do tempo.

Aish Gopalan é uma Arquiteta de Soluções Sênior na AWS baseado na bela cidade de Atlanta, Geórgia. Como colaboradora individual, ela ocupou vários cargos, desde Arquiteta de Soluções, Arquiteta de Aplicativos, Líder de Entrega de Transformação em Nuvem e Desenvolvedora em sua jornada de software de mais de 16 anos. Sempre animada, ela pratica Crossfit e acredita em viver o momento.

Isael Pimentel é um Gerente Técnico de Contas sênior na AWS com mais de 15 anos de experiência no desenvolvimento e gerenciamento de infraestruturas complexas e possui várias certificações, incluindo AWS Solution Architect, AWS Network Specialty, AWS Security Speciality, MSCA e CCNA.

Aditi Sharma é uma Gerente Técnica de Contas na AWS e iniciou sua jornada como engenheira de suporte de nuvem na equipe de bancos de dados RDS. Desde então, ela ocupou várias funções na AWS antes de passar para a função atual. Antes de ingressar na AWS, ela trabalhava como engenheira de desenvolvimento de software no setor bancário. Aditi possui mestrado em Sistemas de Informação Gerencial e Bacharelado em Engenharia de Ciência da Computação e também Certified Scrum Master, Product Owner e AWS Associate Solutions Architect.

Tradutor

Renato Fichmann é um Arquiteto de Soluções Sênior na AWS, com mais de 20 anos de experência em TI, sendo a maior parte dela em funções relacionadas com serviços gerenciados de TI (ITSM), com foco nos processos de resiliência, governança, e disponibilidade de sistemas. Além das certificações ITIL e TOGAF, Renato é certificado AWS Professional Solutions Architect.