Modelo de maturidade de confiabilidade

Estabelecer uma base sólida para resiliência em operações e infraestrutura de carga de trabalho, em vez de gastar tempo em tarefas de otimização.

O nível 1 do modelo de maturidade foi projetado para ajudar as equipes de carga de trabalho a criar uma base forte para a confiabilidade do sistema. O foco é na inicialização, que é o processo de configurar os fundamentos para futuras decisões de confiabilidade. Esse estágio envolve principalmente a implementação funcional com extensões secundárias às práticas atuais.

Esse estágio inclui a pesquisa, a obtenção de insights e a criação de um inventário de seus sistemas. Ele também usa recursos internos de confiabilidade no Azure, como habilitar a redundância de zona para melhorias imediatas.

Ao estabelecer esses conceitos básicos, você pode preparar sua equipe para avançar nos níveis do modelo de maturidade de confiabilidade para aprimorar progressivamente a resiliência e o desempenho do sistema.

Principais estratégias

✓ Avaliar oportunidades para descarregar a responsabilidade operacional

Essa estratégia é, essencialmente, um abordagem criar versus comprar ou depender. A decisão depende de quanta responsabilidade é gerenciável nesta fase, enquanto ainda dá suporte ao desenvolvimento futuro. Você quer usar recursos que sejam relevantes para a carga de trabalho, mas deve sempre explorar oportunidades para transferir sua manutenção. Aqui estão alguns casos de uso clássicos em que talvez você queira aplicar essa abordagem.

• Descarregre as responsabilidades para a plataforma de nuvem escolhendo soluções paaS (plataforma como serviço). Eles fornecem soluções prontas para necessidades comuns de resiliência, como replicação, failover e repositórios de backup. Quando você usa essa abordagem, o provedor de nuvem lida com melhorias de hospedagem, manutenção e resiliência.

  Por exemplo, o provedor de nuvem replica dados em vários nós de computação e distribui as réplicas entre zonas de disponibilidade. Se você criar sua própria solução em máquinas virtuais (VMs), precisará gerenciar esses aspectos por conta própria, o que pode ser demorado e complexo.

• Delegar responsabilidades operacionais que não têm ligação direta com os objetivos comerciais da carga de trabalho. Algumas operações especializadas, como gerenciamento de banco de dados e segurança, podem afetar potencialmente a confiabilidade da carga de trabalho. Explore a possibilidade de ter equipes experientes, tecnologia ou ambas lidar com essas tarefas.

  Por exemplo, se sua equipe não tiver experiência no banco de dados, use serviços gerenciados para ajudar a transferir a responsabilidade para o provedor. Essa abordagem pode ser útil quando você começa porque permite que sua equipe se concentre na funcionalidade da carga de trabalho. Muitas empresas têm serviços compartilhados e gerenciados centralmente. Se as equipes de plataforma estiverem disponíveis, use-as para lidar com essas operações. No entanto, essa abordagem pode adicionar dependências e complexidade organizacional.

  Como alternativa, se sua equipe tiver a experiência certa, você poderá tomar uma decisão explícita de usar suas habilidades e selecionar serviços que não incluem recursos de gerenciamento.

• Descarregar responsabilidades para fornecedores que não são da Microsoft. Escolha produtos fora da prateleira como ponto de partida. Crie soluções personalizadas somente quando elas contribuem para o valor comercial da carga de trabalho.

Risco: Se a opção comprar ou depender atender parcialmente aos seus requisitos, talvez seja necessário implementar extensões personalizadas. Esse método pode resultar em uma situação de "bloqueio de personalização", em que as atualizações e a modernização se tornam impraticáveis. Examine regularmente seus requisitos e compare-os com os recursos da solução. Desenvolva uma estratégia de saída para quando houver um desvio significativo entre os dois.

O cenário oposto também é um risco. Embora a opção de compra ou de confiança possa parecer mais simples no início, ela pode exigir a reavaliação e o redesenho posteriormente se as limitações do serviço paaS, solução de fornecedor ou recursos de propriedade da plataforma não atenderem à granularidade ou nível de autonomia necessários para a carga de trabalho.

✓ Identificar os fluxos críticos do usuário e do sistema

Dividir a carga de trabalho em fluxos é crucial neste estágio. Concentre-se nos fluxos do usuário e do sistema . Os fluxos de usuário determinam as interações do usuário e os fluxos do sistema determinam a comunicação entre componentes de carga de trabalho que não estão diretamente associados às tarefas do usuário.

Por exemplo, em um aplicativo de comércio eletrônico, os clientes executam atividades de front-end, como navegação e pedidos. Enquanto isso, as transações de back-end e os processos disparados pelo sistema atendem às solicitações do usuário e lidam com outras tarefas. Esses fluxos distintos fazem parte do mesmo sistema, mas envolvem componentes diferentes e servem a diferentes finalidades.

Comece a criar um catálogo de fluxos nesta fase. Observe as interações do usuário e a comunicação de componentes. Listar e categorizar fluxos, definir seus pontos de início e de término e observar dependências. Documente resultados e exceções usando diagramas para maior clareza. Esse catálogo pode servir como uma ferramenta importante para a conversa inicial com os stakeholders de negócios para identificar os aspectos mais importantes de sua perspectiva. Essa conversa pode informar o primeiro nível de priorização.

Classifique um fluxo como crítico avaliando o risco e o impacto nas atividades de negócios primárias. Se você espera uma interrupção, a degradação gradual concentra-se na manutenção desses fluxos críticos. No exemplo de comércio eletrônico, os fluxos críticos incluem pesquisas de produtos, adição de itens ao carrinho e check-out porque essas tarefas são essenciais para os negócios. Outros processos, como atualizar dados do produto e manter imagens de produtos, não são tão críticos. Verifique se os fluxos críticos permanecem operacionais durante uma interrupção para evitar a perda de receita, permitindo que os usuários continuem procurando produtos e adicionando itens ao carrinho.

Para obter mais informações, consulte Azure Well-Architected Framework: otimizar o design da carga de trabalho usando fluxos.

✓ Selecione o modelo de design, os recursos e as funcionalidades corretas

Você deve aplicar essa estratégia nos seguintes níveis:

• Arquitetura: O design da carga de trabalho deve considerar as expectativas de confiabilidade em várias camadas de infraestrutura. Suas decisões iniciais podem ser a escolha entre a contêinerização ou o PaaS para hospedar o aplicativo. Ou você pode considerar modelos de rede como hub and spoke ou uma única rede virtual.

  Você também deve definir limites que criam segmentação com base na funcionalidade. Por exemplo, em vez de hospedar tudo em uma VM com um disco virtual de zona única, considere dividir a computação e o armazenamento de dados e usar serviços dedicados.

  Cuidado

  Em cenários de migração, adotar uma abordagem lift-and-shift sem examinar novas oportunidades pode resultar na perda de benefícios e em ineficiências. É importante pesquisar a modernização antecipadamente para evitar ficar preso a configurações difíceis de mudar e aproveitar melhores opções e melhorias.

• Serviços do Azure: Use árvores de decisão para ajudá-lo a selecionar os serviços certos para seu design. Escolha componentes que atendam às suas necessidades atuais, mas permaneçam flexíveis para que você possa alternar de serviço à medida que sua carga de trabalho evolui e requer mais recursos.

• SKUs ou camadas nos serviços do Azure: Examine os recursos de cada SKU e entenda as garantias de disponibilidade da plataforma. Avalie os contratos de nível de serviço para entender a cobertura fornecida em torno do percentil publicado.

• Recursos que dão suporte à confiabilidade: Escolha serviços nativos de nuvem para aprimorar a disponibilidade por meio de configurações simples sem alterar o código. É importante entender as opções e selecionar configurações intencionalmente, como aumentar a redundância de zona ou replicar dados para uma região secundária.

✓ Implantar com um nível de redundância básico

Em cada parte da solução, evite pontos únicos de falha, como instâncias únicas. Em vez disso, crie várias instâncias para redundância. Os serviços do Azure geralmente lidam com redundância para você, especialmente com serviços de PaaS, que geralmente incluem redundância local por padrão e opções para atualização. De preferência, use a redundância de zona para espalhar essas instâncias em vários datacenters do Azure. Se você não fizer isso, pelo menos certifique-se de redundância local, mas esse método vem com maior risco. Em níveis futuros, você avalia se seus requisitos de confiabilidade podem ser atendidos estendendo a solução com componentes com redundância geográfica.

Prós e contras: uma contrapartida significativa é o aumento do custo da redundância. Além disso, a comunicação entre zonas pode introduzir latência. Para aplicativos herdados que exigem latência mínima, a redundância pode prejudicar o desempenho.

Risco: Se um aplicativo não for projetado para um ambiente de várias instâncias, ele poderá ter dificuldades com várias instâncias ativas, o que pode levar a dados inconsistentes. Além disso, se um aplicativo for criado para uma configuração local que tenha baixa latência, o uso de zonas de disponibilidade poderá interromper seu desempenho.

✓ Habilitar métricas, logs e rastreamentos para monitorar fluxos

Escolha ferramentas nativas da plataforma, como o Azure Monitor, para garantir a visibilidade de métricas, logs e rastreamentos. Use recursos internos para definir alertas para possíveis problemas. Você deve ter alertas básicos para enviar notificações e receber alertas. Aproveite os recursos da plataforma do Azure que indicam alterações no status de integridade dos serviços, como:

• Integridade do Serviço do Azure para verificar o status de integridade no nível da plataforma.

• Azure Resource Health para verificar o status de integridade no nível do recurso.

Configure grupos de ações do Azure Monitor para a infraestrutura e o aplicativo.

Prós e contras: à medida que você coleta mais logs, é necessário gerenciar o volume crescente, o que afeta os custos relacionados ao armazenamento desses logs. Use políticas de retenção para gerenciar o volume. Use o Azure Monitor para definir um limite diário em um workspace. Para obter mais informações, consulte As recomendações de configuração para confiabilidade.

Comece a criar observabilidade nas seguintes camadas.

Infraestrutura

Comece habilitando logs de diagnóstico e certificando-se de coletar métricas nativas de componentes da plataforma para análise. Colete informações sobre o uso de recursos, como CPU, memória, entrada/saída e atividade de rede.

Aplicação

Colete métricas em nível de aplicativo, como consumo de memória ou latência de solicitação, e registre atividades do aplicativo. Faça operações de log em um thread ou processo separado do thread principal do aplicativo. Essa abordagem não faz o logging desacelerar as tarefas principais do aplicativo.

Além disso, verifique os testes de disponibilidade básicos no Application Insights.

Dados

Para monitorar bancos de dados em um nível básico, colete as principais métricas que os recursos do banco de dados emitem. Semelhante aos componentes de infraestrutura, acompanhe o uso de recursos no contexto de armazenamentos de dados, como métricas de rede. Coletar dados sobre como as conexões são agrupadas é importante para melhorar a eficiência em estágios posteriores.

Para confiabilidade, é importante acompanhar as métricas de conexão, como monitorar conexões ativas e com falha. Por exemplo, no Azure Cosmos DB, um código de status 429 é retornado quando o número de solicitações excede as unidades de solicitação alocadas e as conexões começam a falhar.

✓ Comece a criar um guia estratégico de mitigação de falhas

As falhas variam de falhas intermitentes a um pouco prolongadas e interrupções catastróficas.

No Nível 1, concentre-se em falhas de plataforma. Mesmo que eles estejam fora do seu controle, você ainda deve ter estratégias para lidar com eles. Por exemplo, resolva interrupções zonais usando zonas de disponibilidade. Antecipe falhas transitórias no nível da plataforma e manipule-as em sua carga de trabalho.

O processo de tratamento dessas falhas varia de acordo com a complexidade. Comece a documentar possíveis falhas no nível da plataforma, seus riscos associados e estratégias de mitigação. Este exercício é principalmente teórico e amadurece com automação em níveis posteriores.

Você deve documentar falhas, incluindo fatores como suas estratégias de probabilidade, impacto e mitigação. Use uma escala de criticidade que se alinhe às metas da carga de trabalho. Sua escala pode incluir:

• Alta. Uma interrupção completa do sistema que resulta em uma perda financeira significativa e uma queda na confiança do usuário.

• Média. Uma interrupção temporária que afeta parte da carga de trabalho e causa inconveniência do usuário.

• Baixa. Um pequeno problema de software que afeta um recurso não essencial do aplicativo e causa uma interrupção mínima para os usuários.

Este é um modelo de exemplo:

No Nível 1, não se esforce pela completude porque sempre há casos de falha imprevistos. Se você enfrentar interrupções inesperadas, documente as causas e ações de mitigação no manual. Trate esse ativo como um documento vivo que você atualiza ao longo do tempo.

✓ Adicionar mecanismos para se recuperar de falhas transitórias

Em um ambiente de nuvem, falhas transitórias são comuns. Eles indicam problemas de curto prazo que as novas tentativas geralmente podem resolver em segundos.

Use SDKs internos e configurações para lidar com essas falhas para manter o sistema ativo. As configurações internas geralmente são a configuração padrão, portanto, talvez seja necessário testar para validar a implementação. Além disso, implemente padrões projetados para lidar com falhas transitórias em sua arquitetura. Para obter mais informações, consulte padrões de design de arquitetura que dão suporte à confiabilidade.

Problemas resistentes podem indicar uma falha que não é transitória ou o início de uma interrupção. Esse cenário requer mais do que apenas corrigir problemas localizados dentro do aplicativo. Envolve examinar os fluxos críticos de usuário e do sistema e adicionar técnicas de autopreservação e esforços de recuperação. Esses métodos são práticas maduras que o Nível 2 descreve.

✓ Executar testes básicos

Integre testes básicos de confiabilidade nos estágios iniciais do ciclo de vida de desenvolvimento de software. Procure oportunidades para fazer testes, começando com testes de unidade para validar a funcionalidade e as configurações.

Além disso, desenvolva casos de teste simples para os problemas que você identifica no guia estratégico de mitigação de risco. Concentre-se em maior impacto, redução de mitigações de esforço. Por exemplo, simule interrupções de rede ou problemas de conectividade intermitente para ver como sua lógica de repetição resolve as interrupções.

Risco: O teste geralmente introduz atrito no ciclo de desenvolvimento. Para atenuar esse risco, torne o teste de confiabilidade rastreável junto com as tarefas de desenvolvimento.

O desenvolvimento de funcionalidades é a prioridade, e os testes podem introduzir fricção no ciclo de desenvolvimento. É mais fácil iniciar o teste antes que o desenvolvimento de funcionalidades seja concluído. Projetar aspectos não funcionais do aplicativo no início permite estendê-los à medida que você adiciona funcionalidades funcionais, em vez de criar uma lista de problemas a serem resolvidos posteriormente. Embora essa abordagem exija mais esforço inicialmente, ela é gerenciável e impede problemas maiores posteriormente.

Assegure-se de que o sistema permaneça funcional e estável incorporando capacidades de autopreservação e tenha um plano de recuperação básico para gerenciar falhas.

Falhas na nuvem são inevitáveis. Suas estratégias de resiliência devem se esforçar para manter o sistema funcional em todas as condições. O Nível 1 apresenta métodos para lidar com falhas transitórias. O nível 2 concentra-se na incorporação de estratégias de autopreservação para prevenir, detectar e recuperar-se de falhas mais duradouras. Se não for resolvido, esses problemas poderão se transformar em interrupções completas.

Os fluxos críticos que você identifica no Nível 1 têm prioridade. Eles exigem maior resiliência e esforços de recuperação para todos os componentes, incluindo aplicativos, serviços e bancos de dados. Espere ajustar seus tamanhos de provisionamento iniciais, contagens de instâncias e políticas de escala automática para reduzir os riscos de confiabilidade.

Nesse nível, seja intencional sobre suas práticas de monitoramento e teste. Use técnicas avançadas de monitoramento que se alinhem às necessidades técnicas e estejam no escopo das equipes de desenvolvimento. Expanda o guia estratégico simples para abranger os componentes arquitetônicos que você desenvolve e possui, como o código do aplicativo.

Principais estratégias

✓ Avaliar o estado atual de resiliência para proteger contra falhas

• O nível de redundância é bom o suficiente para suportar falhas? Defina uma estratégia de redundância que especifica o número de recursos redundantes a serem mantidos. Determine onde colocar esses recursos, localmente, entre zonas ou em locais geograficamente distribuídos. Avalie as configurações da plataforma de nuvem e selecione um nível que atenda às necessidades de negócios e às compensações aceitáveis.

• Os componentes da carga de trabalho são isolados o suficiente para conter suas falhas? Padrões como o padrão Bulkhead ajudam a criar resiliência e isolamento de falhas. O padrão Bulkhead particiona um sistema em componentes isolados, conhecidos como bulkheads, para evitar que falhas sejam em cascata para outras partes do sistema.

• Os componentes no caminho crítico se comunicam de forma assíncrona? Caso contrário, use métodos de comunicação, como filas. Essa abordagem mantém o sistema operacional mesmo se um componente downstream falhar. Ele também impede que o sistema insira um estado indeterminado. Explore as opções do Azure, incluindo o Azure Service Bus para filas e o Azure Event Hubs para fluxos de eventos.

  Dilema: A comunicação assíncrona pode ajudar a evitar falhas em cascata desassociando processos. No entanto, ele adiciona latência no caminho de comunicação, o que pode representar um problema para componentes críticos. Avalie o impacto no desempenho antes de fazer alterações no padrão de design.

• As operações foram projetadas para consistência? Ativos como segredos do aplicativo e certificados podem expirar e exigir atualização regular. Inconsistências em atualizações de rotina podem resultar em problemas de confiabilidade.

  Idealmente, identifique e elimine tarefas contínuas operadas por humanos porque elas são propensas a erros e podem causar inconsistências que representam riscos de confiabilidade. Descarregre o máximo de tarefas operacionais possível para o provedor de nuvem. Por exemplo, use identidades gerenciadas que a ID do Microsoft Entra fornece e certificados TLS (Transport Layer Security) gerenciados pelo Azure Front Door.

  O monitoramento é necessário para medidas proativas, como acompanhar a expiração do certificado e receber notificações. O aplicativo deve registrar eventos importantes, como um certificado TLS próximo à expiração. Usar vários métodos para verificar possíveis falhas ajuda a garantir que as ações necessárias sejam tomadas.

✓ Adicionar funcionalidades técnicas em seu sistema de monitoramento

No Nível 1, você reuniu dados de monitoramento dos componentes da carga de trabalho, com foco na infraestrutura. A análise básica é concluída e os alertas básicos são definidos. Essa configuração é essencial para entender o desempenho da linha de base dos componentes da carga de trabalho e identificar o comportamento anômalo.

O Nível 2 leva o monitoramento mais adiante, adicionando recursos avançados de observabilidade aos recursos de carga de trabalho e adotando uma abordagem mais estruturada para analisar dados de monitoramento. Aproveite as ferramentas de análise fornecidas pelo serviço de nuvem. Por exemplo, as ferramentas de insights do Azure Monitor, como insights de VM e insights de rede, fornecem visualizações sobre a integridade e o desempenho nas dependências.

Planeje os recursos de observabilidade nas camadas a seguir.

Aplicação

• Responder à investigação de status de saúde. Permitir que o aplicativo responda às solicitações de checagem de saúde das sondas. O aplicativo deve ter endpoints dedicados para verificações de saúde que fornecem informações de status, como healthy ou unhealthy, no mínimo. Essa abordagem permite que os sistemas de monitoramento avaliem se o aplicativo está funcionando corretamente e podem lidar com solicitações ou se há problemas que precisam ser resolvidos.

  Os serviços de balanceamento de carga do Azure, como Azure Front Door, Gerenciador de Tráfego do Azure, Gateway de Aplicativo do Azure e Azure Load Balancer, oferecem suporte a investigações de integridade. As investigações de integridade enviam solicitações de verificação de integridade para os aplicativos.

• Avance para o registro em log semântico. Inclua informações estruturadas sobre eventos e ações no aplicativo. Com o registro em log estruturado, os dados de log são registrados em um formato consistente usando um esquema bem definido. Esse esquema facilita a criação de automação, pesquisa e análise em estágios posteriores. Inclua campos específicos, como carimbos de data/hora e códigos de erro, para ajudar a identificar e solucionar problemas rapidamente.

• Implementar o rastreamento distribuído. Quando uma solicitação flui por diferentes componentes do sistema, é importante capturar dados de rastreamento entre limites. Esses dados são úteis para obter insights sobre o comportamento do aplicativo e identificar gargalos de desempenho, erros e problemas de latência. O Azure Monitor dá suporte à coleta de dados baseada em OpenTelemetry com o Application Insights.

Dados

• Acompanhe a duração da consulta, as consultas com falha e outras métricas relevantes. Consultas de execução longa podem indicar restrições de recursos e, possivelmente, uma necessidade de ajustar o design do esquema.

  Neste estágio, seu banco de dados está operando há algum tempo. Preste atenção à taxa de crescimento de dados, especialmente em tabelas que crescem inesperadamente rapidamente. Essas informações são cruciais para planejar futuras necessidades de armazenamento e resolver problemas de desempenho antecipadamente.

• Monitore o status da replicação de banco de dados usando as ferramentas e o painel que o sistema de gerenciamento de banco de dados fornece. Por exemplo, se você usar o Azure Cosmos DB, utilize o recurso de insights do Azure Cosmos DB. Para o Banco de Dados SQL do Azure ou a Instância Gerenciada de SQL do Azure, considere usar o observador de banco de dados para obter detalhes de diagnóstico sobre seus bancos de dados.

  À medida que o banco de dados aumenta, os problemas de esquema podem se tornar mais aparentes, o que afeta o desempenho. Para otimizar a eficiência da consulta, considere adicionar índices ou modificar o esquema porque essas alterações podem afetar a confiabilidade.

Operações

O nível 1 concentra-se nas camadas anteriores. No Nível 2, você começa a criar operações em torno do sistema de monitoramento.

• Mantenha os logs tempo o suficiente para adquirir informações valiosas. Do ponto de vista da confiabilidade, configure a duração da retenção para que você possa coletar dados suficientes para detectar padrões de falha, solucionar problemas e executar a análise de causa raiz.

• Monitore os processos de backup e recuperação. Verifique se os backups são armazenados com êxito em locais como planejado e se os dados da carga de trabalho são recuperados dentro de um período razoável. Monitorar esses processos é importante para definir linhas de base para suas métricas de RPO (objetivo de ponto de recuperação) em níveis posteriores.

✓ Estender seu guia estratégico de mitigação de falhas

O nível 1 concentra-se nas falhas de plataforma esperadas. No Nível 2, você aborda pontos de falha em componentes e operações dentro de sua própria carga de trabalho. Conforme o código é executado na plataforma, os pontos de interação entre a plataforma e o aplicativo aumentam. Espere falhas de bugs em seu código, implantações malsucedidas e erros humanos. Reduza esses problemas usando táticas de autopreservação ou recuperação.

Estenda seu guia estratégico de mitigação de falhas para incluir bugs e problemas de implantação. A tabela a seguir baseia-se no modelo do Nível 1:

Este exercício pode se tornar avassalador se você tentar considerar todas as falhas possíveis. Para facilitar, concentre-se nos componentes que fazem parte dos fluxos críticos do usuário. Este documento vivo continua a crescer à medida que a carga de trabalho amadurece.

✓ Desenvolver um plano de recuperação básico

O guia estratégico de mitigação de falhas é a base para a criação de um plano de recuperação básico. As estratégias de mitigação podem incluir implementação de padrão de design, ajustes de configuração de plataforma, gerenciamento de incidentes de site ao vivo, testes automatizados e equipe de treinamento para detectar problemas durante revisões de código.

Comece com uma estratégia de degradação normal, que inclui correções temporárias quando partes do sistema não funcionam corretamente. O objetivo é continuar atendendo aos usuários, apesar das falhas desabilitando partes não funcionais e ajustando a experiência do usuário. Por exemplo, se um banco de dados estiver inativo, o aplicativo poderá desabilitar o recurso afetado e informar aos clientes que o serviço está temporariamente indisponível usando códigos de status HTTP.

Para que a degradação gradual funcione, isole os componentes do sistema para que apenas as partes afetadas enfrentem problemas enquanto o restante dos componentes continue funcionando. Use o padrão Bulkhead para alcançar o isolamento de falha.

Aproveite essa oportunidade para revisitar as opções de design que podem atrasar a recuperação. Por exemplo, apontar registros DNS (Sistema de Nomes de Domínio) diretamente para seu aplicativo no Serviço de Aplicativo do Azure pode causar atrasos durante a recuperação devido à propagação de DNS. Use um serviço dedicado como o Azure Front Door como o ponto de entrada para uma reconfiguração mais fácil durante as etapas de recuperação.

Espere que esse plano básico evolua para um plano de recuperação de desastre completo em níveis mais maduros.

✓ Criar planos de teste

Crie planos de teste simulando interrupções e problemas identificados no guia estratégico de mitigação de risco. Complemente essas mitigações com casos de teste simples para garantir que funcionem conforme o esperado e sejam viáveis. Verifique se esses recursos operam corretamente e realize testes de degradação para ver como o sistema é executado quando componentes específicos falham. Mantenha o resultado simples, garantindo que o teste falhe ou passe.

Use ferramentas de teste como estruturas de simulação para injetar falhas em solicitações HTTP, que ajudam você a testar políticas de repetição de forma mais explícita. O Azure Chaos Studio fornece um conjunto de testes abrangente para simular interrupções de componentes e outros problemas, o que o torna um serviço valioso a ser explorado. Você pode adotar gradualmente o Chaos Studio à medida que se familiariza com seus recursos.

✓ Avaliar o impacto das operações de dimensionamento na confiabilidade

Para lidar com picos de carga, os componentes críticos devem ser capazes de escalar horizontalmente ou verticalmente com eficiência. Aproveite os recursos de dimensionamento automático que o Azure fornece. Esses recursos ajustam os limites de capacidade de um serviço com base em configurações predefinidas. Esse ajuste permite que você escale o serviço para mais ou para menos conforme necessário.

• Identifique possíveis gargalos e entenda os riscos que eles podem representar. Por exemplo, a alta taxa de transferência não deve fazer com que o fluxo seja interrompido.

• Entenda os padrões de carga. Padrões de uso estático podem tornar os gargalos menos críticos, mas as alterações na dinâmica de uso e consumo podem piorar os riscos.

  Observação

  Pode haver componentes que não podem ser dimensionados, como bancos de dados monolíticos e aplicativos herdados. Monitore proativamente a curva de carga para permitir a rearquitetura, se necessário.

• Decida sobre limites de dimensionamento razoáveis com base nos requisitos de desempenho e confiabilidade. Para questões de desempenho, aumentar gradualmente é mais comum. No entanto, as preocupações de confiabilidade para fluxos críticos podem exigir um dimensionamento mais rápido para evitar interrupções. Em ambos os casos, evite o dimensionamento infinito.

Risco: Quando você lida com problemas relacionados ao desempenho, o dimensionamento pode ser uma estratégia de mitigação útil. No entanto, o dimensionamento é uma correção temporária e não uma solução. Investigue e resolva o problema subjacente, como um vazamento de memória ou um processo descontrolado. Caso contrário, você corre o risco de aplicar a mesma mitigação novamente em outro ponto de inflexão e pagar por recursos que você não precisa. Ao abordar a causa raiz, você pode garantir a estabilidade e a eficiência de custo a longo prazo.

Definir objetivos e metas de confiabilidade para responsabilizar a equipe nos procedimentos de recuperação.

Em níveis iniciais, suas equipes se concentram em ganhos fáceis e recursos básicos. Eles começam com pequenas melhorias, resolvendo problemas simples para criar uma base forte, ao mesmo tempo em que dependem principalmente dos recursos de confiabilidade do Azure. À medida que suas equipes crescem, elas lidam com desafios mais técnicos relacionados aos seus próprios ativos e processos.

No Nível 3, suas equipes devem integrar insights de negócios e habilidades técnicas para o planejamento de recuperação. Eles definem objetivos e planejam processos de recuperação usando monitoramento avançado. Essa abordagem ajuda os SREs (engenheiros de confiabilidade do site) a atender rapidamente às metas de confiabilidade.

Principais estratégias

✓ Formalizar recursos de confiabilidade como objetivos

Os objetivos de confiabilidade ajudam a definir a responsabilidade das equipes de carga de trabalho. É importante ter uma conversa colaborativa com os stakeholders empresariais para discutir os tempos e custos de recuperação e fazer compromissos que se alinhem às metas de negócios. Reúna os stakeholders e conduza essa discussão como um workshop. Considere os seguintes pontos para a agenda do workshop:

• Explicar as métricas por trás dos objetivos. Comece explicando as principais métricas usadas para definir objetivos como objetivos de nível de serviço, RTOs (objetivos de tempo de recuperação) e RPOs (objetivos de ponto de recuperação). Mostrar como essas métricas se alinham com as metas de negócios. Concentre-se nos fluxos críticos do usuário. Por exemplo, em um aplicativo de comércio eletrônico, o RTO para atualizar as preferências de email é menos importante do que a finalização de compras pelos usuários.

• Comunique os prós e contras. Os stakeholders geralmente esperam mais do que o que pode ser alcançado. Explicar como a expansão do escopo afeta o orçamento, os requisitos operacionais e o desempenho.

• Propor metas objetivas. Com base na experiência da arquitetura e no design da carga de trabalho, recomende metas como 99,9% de disponibilidade, com RPO e RTO definidos em quatro horas. Facilite uma discussão para que os stakeholders forneçam comentários e façam ajustes. Certifique-se de que os stakeholders corporativos e técnicos evitem expectativas irreais. Abordar discussões com uma mentalidade colaborativa.

• Chegar a um consenso ou decisão. Busque um consenso, mas se isso não for possível, faça com que um tomador de decisão finalize as metas para garantir o progresso.

✓ Monitorar proativamente usando seu modelo de saúde

No Nível 1, os dados de monitoramento são coletados de componentes de carga de trabalho, incluindo serviços de plataforma e aplicativos. A análise básica e os alertas são definidos para estabelecer o desempenho da linha de base e identificar anomalias. No Nível 2, o foco muda para obter dados de observabilidade de componentes de carga de trabalho, como o código do aplicativo.

O Nível 3 aprimora o monitoramento adicionando o contexto de negócios a fluxos críticos e definindo estados íntegros, não íntegros e degradados por meio da modelagem de integridade. Um acordo com as partes interessadas é necessário para determinar compromissos aceitáveis para a experiência do usuário e deve ser usado como entrada para definir os estados de saúde.

A modelagem de saúde requer maturidade operacional e experiência em ferramentas de monitoramento. Sua equipe analisa dados brutos, níveis de desempenho e logs para criar métricas e limites personalizados que definem o estado de integridade do fluxo. Eles devem entender como esses valores se relacionam com a integridade geral do sistema. Comunique definições e limites claros aos stakeholders.

Visualize o modelo de saúde nos painéis para ajudar os SREs a identificar rapidamente os problemas, concentrando-se em fluxos não saudáveis ou degradados.

O modelo de integridade define o status do aplicativo e os fluxos críticos. Verde indica que todos os fluxos críticos estão operando conforme o esperado. Vermelho indica uma falha. Além disso, amarelo mostra tendências aos problemas. A iteração por meio de versões de modelo de integridade garante a confiabilidade e a precisão, mas requer um esforço significativo para aplicativos grandes.

Uma alteração no estado de saúde deve ser configurada como alertas. No entanto, para manter os alertas intencionais, a criticidade do componente deve ser levada em consideração.

Para obter mais informações, consulte Well-Architected Framework: Modelagem de saúde.

✓ Definir alertas acionáveis

Para melhorar a eficiência de resposta, defina alertas claramente e forneça informações suficientes para uma ação rápida. Nomes e descrições de alerta detalhados podem ajudar a economizar tempo e esforço durante a solução de problemas. Configure cuidadosamente a severidade, o nome e a descrição, com especial atenção aos níveis de gravidade. Nem todo evento é uma emergência. Avalie cuidadosamente os níveis de gravidade e estabeleça critérios para cada nível, como se um pico de CPU de 80% para 90% se qualifica como uma emergência. Defina os limites apropriados para garantir que os alertas sejam efetivamente definidos.

O gerenciamento efetivo de alertas garante que os alertas notifiquem as pessoas certas no momento certo. Alertas frequentes e disruptivos indicam a necessidade de ajuste e podem se tornar contraproducentes quando são ignorados. Reduza as notificações desnecessárias definindo os limites apropriados para filtrar alarmes falsos. Identificar oportunidades em que a automação pode disparar procedimentos operacionais.

Crie uma única página de destino que tenha as informações necessárias para resolver problemas de alertas com eficiência. Essa abordagem economiza tempo em comparação ao logon no portal do Azure e à pesquisa de métricas. Se os recursos internos do Azure Monitor não atenderem totalmente às suas necessidades, considere o desenvolvimento de um painel personalizado.

✓ Conduzir análise de modos de falha

Nos níveis anteriores, você criou um guia estratégico de mitigação de falhas simples para componentes individuais. Nesse nível, evolua esse guia estratégico para um exercício formal de FMA (análise de modo de falha). A finalidade deste exercício é identificar proativamente possíveis modos de falha.

O FMA exige que você identifique possíveis pontos de falha em sua carga de trabalho e planeje ações de mitigação, como recuperação automática ou recuperação de desastre (DR). Para começar, monitore o aumento das taxas de erros e detecte os impactos nos fluxos críticos. Use experiências passadas e dados de teste para identificar possíveis falhas e avaliar seu raio de explosão. Priorize os principais problemas, como uma interrupção em toda a região.

É importante classificar ações como preventivas ou reativas. Ações preventivas identificam riscos antes de causarem uma interrupção, o que reduz sua probabilidade ou gravidade. Ações reativas resolvem problemas para atenuar um estado de integridade degradado ou uma interrupção.

No aplicativo de exemplo de comércio eletrônico, a equipe de carga de trabalho deseja fazer a FMA para se preparar para um grande evento. Um dos principais fluxos do usuário é adicionar itens ao carrinho. Os componentes que fazem parte do fluxo são o front-end, CartAPI, ProductCatalogAPI, UserProfileAPI, PricingAPI, Azure Cosmos DB e Hubs de Eventos do Azure.

A FMA é complexa e pode ser demorada, portanto, crie sua análise progressivamente ao longo do tempo. Esse processo é iterativo e continua evoluindo em estágios posteriores.

Para mais informações, consulte RE:03 Recomendações para a execução do FMA.

✓ Preparar um plano de DR

No Nível 2, você criou um plano de recuperação focado em controles técnicos para restaurar a funcionalidade do sistema. No entanto, um desastre requer uma abordagem mais ampla devido à perda catastrófica ou à falha. Os planos de recuperação de desastre são baseados em processo. Elas abrangem comunicação, etapas de recuperação detalhadas e potencialmente incluem artefatos técnicos como scripts.

Primeiro, identifique os tipos de desastres para os quais planejar, como interrupções de região, falhas em todo o Azure, interrupções na infraestrutura, corrupção de banco de dados e ataques de ransomware. Em seguida, desenvolva estratégias de recuperação para cada cenário e verifique se os mecanismos estão em vigor para restaurar as operações. Os requisitos de negócios, RTOs e RPOs devem orientar os planos de DR. RtOs e RPOs baixos exigem processos automatizados explícitos, enquanto RTOs e RPOs mais altos permitem métodos de recuperação mais simples e análise manual.

A DR inclui principalmente as seguintes ações:

• Notifique as partes responsáveis. É importante ter clareza sobre quem envolver e quando. Verifique se sua equipe usa os processos corretos, tem as permissões certas e entende suas funções na recuperação. Algumas responsabilidades, como o CEO se reportando ao mercado ou lidando com requisitos regulatórios, devem ser identificadas antecipadamente.

  O ideal é que você tenha funções de recuperação e comunicação separadas e atribua pessoas diferentes a cada função. Inicialmente, a pessoa de operações de TI que descobre o problema pode lidar com ambas as funções. Mas à medida que a situação aumenta, a equipe sênior pode lidar com a recuperação técnica enquanto um empresário gerencia as comunicações.

• Tome decisões de negócios. Durante um desastre, os níveis de estresse podem ser altos, o que torna a tomada de decisões clara essencial. Um plano de DR bem estruturado requer discussões contínuas entre a equipe técnica e os stakeholders de negócios para definir opções de decisão preliminares. Por exemplo, considere se os recursos de carga de trabalho devem ser executados em uma região do Azure, com backups em outra região, ou se os ativos IaC devem ser preparados com antecedência para criar novos recursos ou restaurar de um backup durante um failover.

  As ações tomadas de acordo com os planos de DR podem ser destrutivas ou ter efeitos colaterais significativos. É essencial entender as opções, pesar seus prós e contras e determinar o momento certo para aplicá-las. Por exemplo, avalie se a recuperação para uma região diferente é necessária se espera-se que a região primária esteja operacional dentro de um período aceitável.

• Restaurar operações do sistema. Durante um desastre, o foco deve ser restaurar operações e não identificar a causa. Para a recuperação técnica, especialmente no failover de região, decida antecipadamente sobre abordagens como ativo-ativo, ativo-passivo, espera fria ou espera quente.

  Prepare etapas de recuperação específicas com base na abordagem escolhida. Comece com uma lista concreta de etapas para restaurar as operações. À medida que o processo amadurece, procure definir o plano de recuperação de desastre como um script com interação manual mínima. Use o controle de versão e armazene o script com segurança para facilitar o acesso. Essa abordagem requer mais esforço inicial, mas minimiza o estresse durante um incidente real.

  Para obter mais informações, consulte Implantar em modo ativo-passivo para DR.

• Realize a análise pós-incidente. Identifique a causa do incidente e encontre maneiras de impedi-lo no futuro. Faça alterações para melhorar os processos de recuperação. Este exercício também pode descobrir novas estratégias. Por exemplo, se o sistema mudou para o ambiente secundário, determine se o ambiente primário ainda é necessário e qual deve ser o processo de failback.

Um plano de recuperação de desastre é um documento dinâmico que se adapta às mudanças em sua carga de trabalho. Atualize seu plano de recuperação de desastre à medida que novos componentes e riscos surgirem. Refinar o plano com base nos insights obtidos de simulações ou desastres reais, coletando informações realistas de operadores de DR.

Controlar riscos que decorrem de alterações técnicas e operacionais e priorizar o gerenciamento de incidentes.

Nos níveis anteriores, sua equipe de desenvolvimento se concentra na criação de funcionalidades e na operacionalização do sistema. No Nível 4, o foco muda para manter o sistema confiável na produção. O gerenciamento de incidentes torna-se tão importante quanto garantir que todas as alterações introduzidas sejam completamente testadas e implantadas com segurança para evitar tornar o sistema instável.

Esse processo requer melhorias nos controles operacionais, como investir em equipes dedicadas para gerenciar incidentes de confiabilidade. Ele também requer controles técnicos para aprimorar a confiabilidade do sistema além dos componentes críticos reforçados nos níveis anteriores. À medida que o sistema continua a ser executado em produção, o crescimento de dados pode exigir redesenhos, como particionamento, para garantir acesso e manutenção confiáveis.

Principais estratégias

✓ Gerenciamento de alterações confiável

Os maiores riscos de confiabilidade ocorrem durante as alterações, como atualizações de software, ajustes de configuração ou modificações de processo. Esses eventos são críticos do ponto de vista da confiabilidade. A meta é minimizar a probabilidade de problemas, interrupções, tempo de inatividade ou perda de dados. Cada tipo de alteração requer atividades específicas para gerenciar seus riscos exclusivos efetivamente.

No Nível 4, a confiabilidade se cruza com as práticas de implantação seguras descritas na Excelência Operacional, na manutenção de um ambiente estável ao gerenciar alterações. O gerenciamento de alterações confiável é um requisito para alcançar a estabilidade da carga de trabalho. Considere os seguintes aspectos principais:

• Reagir às atualizações da plataforma. Os serviços do Azure têm mecanismos diferentes para atualizar os serviços.

  • Familiarize-se com os processos de manutenção e atualize as políticas de cada serviço que você usa. Entenda se o serviço dá suporte a atualizações automáticas ou manuais e ao período de tempo para atualizações manuais.

  • Para serviços que têm atualizações planejadas, gerencie essas atualizações efetivamente agendando-as durante tempos de baixo impacto. Evite atualizações automáticas e adie-as até depois de avaliar o risco. Alguns serviços permitem controlar o tempo, enquanto outros serviços fornecem um período de carência. Por exemplo, com o AKS (Serviço de Kubernetes do Azure), você tem 90 dias para aceitar antes que a atualização se torne automática. Teste atualizações em um cluster de não produção que espelha sua configuração de produção para evitar regressões.

    Aplique atualizações gradualmente. Mesmo que o teste mostre que a atualização é segura, aplicá-la a todas as instâncias simultaneamente pode ser arriscada. Em vez disso, atualize algumas ocorrências de cada vez e espere entre cada conjunto.

  • Verifique regularmente se há notificações sobre atualizações, que podem estar disponíveis em logs de atividades ou em outros canais específicos do serviço.

  • Monitore alterações repentinas ou graduais após a aplicação de uma atualização. Idealmente, seu modelo de saúde deve notificar você sobre essas alterações.

• Teste completo com automação. Integre mais testes ao pipeline de compilação e implantação ao distribuir as alterações. Procure oportunidades para converter processos manuais em partes automatizadas de seus pipelines.

  Faça testes abrangentes usando uma combinação de diferentes tipos de testes em vários estágios para confirmar se as alterações funcionam conforme o esperado e não afetam outras partes do aplicativo. Por exemplo, testes positivos podem verificar se o sistema opera conforme o esperado. Ele deve validar que não há erros e que o tráfego flui corretamente.

  Quando você planeja atualizações, identifique os portões de teste e os tipos de testes a serem aplicados. A maioria dos testes deve ocorrer em estágios de pré-implantação, mas os smoke tests também devem ser executados em cada ambiente, quando o atualizar.

• Siga as práticas de implantação seguras. Use topologias de implantação que incluem janelas de validação e práticas de implantação seguras. Implemente padrões de implantação seguros, como implantações canário e azul-verde, para aumentar a flexibilidade e a confiabilidade.

  Por exemplo, em implantações canário, um pequeno subconjunto de usuários recebe a nova versão primeiro. Esse processo permite o monitoramento e a validação antes da implantação em toda a base de usuários. Técnicas como sinalizadores de recursos e lançamentos discretos facilitam o teste em produção antes de liberar alterações para todos os usuários.

• Atualize seu plano de DR. Atualize regularmente seu plano de recuperação de desastre para mantê-lo relevante e eficaz. Evite instruções desatualizadas. Essa abordagem garante que o plano reflita o estado atual do sistema implantado na produção e confiado pelos usuários. Incorpore lições aprendidas com exercícios e incidentes reais.

Para obter mais informações, consulte o Nível de Excelência Operacional 4

✓ Invista em uma equipe dedicada para lidar com incidentes

Inicialmente, a equipe de desenvolvimento pode estar envolvida durante incidentes. No Nível 4, invista em SRE (engenharia de confiabilidade do site) para gerenciamento de incidentes. As SREs são especializadas em problemas de produção e são especialistas em eficiência, gerenciamento de alterações, monitoramento, resposta a emergências e gerenciamento de capacidade. Uma equipe de SRE proficiente pode reduzir significativamente a dependência da equipe de engenharia.

Forneça às SREs as ferramentas, as informações e o conhecimento necessários para lidar com incidentes de forma independente. Essa preparação reduz a dependência da equipe de engenharia. As SREs devem ser treinadas nos livros de estratégias e no modelo de saúde da carga de trabalho desenvolvido nos níveis anteriores para reconhecer rapidamente padrões comuns e iniciar o processo de mitigação.

A equipe de engenharia deve ter tempo para refletir sobre problemas recorrentes e desenvolver estratégias de longo prazo, em vez de abordá-los individualmente a cada vez.

✓ Automatizar processos de autorrecuperação

Nos níveis anteriores, as estratégias de autorrecuperação são projetadas usando padrões de redundância e design. Agora que sua equipe tem experiência com o uso do mundo real, você pode integrar a automação para atenuar padrões comuns de falha e reduzir a dependência da equipe de engenharia.

Dilema: A automação pode levar tempo e ser dispendiosa para configurar. Concentre-se em automatizar as tarefas mais impactantes primeiro, como tarefas que ocorrem com frequência ou que provavelmente causarão interrupções.

Configure ações com base em gatilhos e automatize respostas ao longo do tempo para criar um guia estratégico automatizado para SREs. Uma abordagem é aprimorar o guia estratégico com scripts que implementam etapas de mitigação. Explore as opções nativas do Azure, como usar grupos de ações do Azure Monitor, para configurar gatilhos que iniciam automaticamente várias tarefas.

✓ Estender a resiliência a tarefas em segundo plano

A maioria das cargas de trabalho inclui componentes que não dão suporte diretamente aos fluxos de usuário, mas desempenham um papel crítico no fluxo de trabalho geral de um aplicativo. Por exemplo, em um sistema de comércio eletrônico, quando um usuário faz um pedido, o sistema adiciona uma mensagem a uma fila. Essa ação aciona vários processos em segundo plano, como confirmação de e-mail, finalização de cobrança de cartão de crédito e notificação ao armazém para preparação de envio. Essas tarefas operam separadamente das funções que atendem às solicitações do usuário no site, o que reduz a carga e melhora a confiabilidade. Os sistemas também dependem de tarefas em segundo plano para limpeza de dados, manutenção regular e backups.

Depois de avaliar e melhorar os fluxos de usuário primários, considere as tarefas em segundo plano. Use as técnicas e a infraestrutura que já estão em vigor e adicione melhorias para tarefas em segundo plano.

• Aplique o ponto de verificação. Ponto de verificação é uma técnica para salvar o estado de um processo ou tarefa em pontos específicos. O ponto de verificação é especialmente útil para tarefas de execução longa ou processos que podem ser interrompidos devido a problemas inesperados, como falhas de rede ou falhas no sistema. Quando o processo é reiniciado, ele pode retomar a partir do último ponto de verificação salvo, o que minimiza o impacto das interrupções.

• Mantenha os processos idempotentes. Verifique a idempotência em processos em segundo plano para que, se uma tarefa falhar, outra instância possa pegá-la e continuar o processamento sem problemas.

• Verifique a consistência. Impedir que o sistema entre em um estado inconsistente caso uma tarefa em segundo plano seja interrompida durante o processamento. Tanto o ponto de verificação quanto a idempotência no nível da tarefa são técnicas para permitir maior consistência em operações de tarefas em segundo plano. Execute cada tarefa como uma transação atômica. Para uma tarefa que abrange vários armazenamentos de dados ou serviços, use idempotência em nível de tarefa ou transações compensatórias para garantir que ela seja concluída.

• Integre tarefas em segundo plano ao sistema de monitoramento e às práticas de teste. Detectar falhas e evitar interrupções despercebidas que podem resultar em consequências funcionais e não funcionais. Seu sistema de monitoramento deve capturar dados desses componentes, definir alertas para interrupções e usar gatilhos para repetir ou retomar o processo automaticamente. Trate esses ativos como parte da carga de trabalho e realize testes automatizados da mesma maneira que você faz para componentes críticos.

O Azure fornece vários serviços e recursos para trabalhos em segundo plano, como o Azure Functions e o Serviço de Aplicativo do Azure WebJobs. Examine suas práticas recomendadas e limites ao implementar fluxos que se concentram na confiabilidade.

Se mantenha resiliente à medida que a arquitetura da carga de trabalho evolui, o que permite que o sistema resista a riscos novos e imprevistos.

No Nível 5, o foco de melhorar a confiabilidade da sua solução se afasta da implementação de controles técnicos. Sua infraestrutura, aplicações e operações devem ser confiáveis o suficiente para serem resilientes a interrupções e recuperarem dentro dos tempos de recuperação definidos.

Use os dados e as metas futuras de negócios para reconhecer que, se sua empresa precisar ir mais longe, as alterações de arquitetura poderão ser necessárias. À medida que sua carga de trabalho evolui e novos recursos são adicionados, procure minimizar interrupções relacionadas a esses recursos, reduzindo ainda mais as interrupções para os recursos existentes.

Principais estratégias

✓ Usar insights de confiabilidade para orientar a evolução da arquitetura

Nesse nível, tome decisões em colaboração com os stakeholders empresariais. Considere os seguintes fatores:

• Analise métricas que indicam quantas vezes seu sistema ultrapassa os limites de confiabilidade em um período de tempo e se isso é aceitável. Por exemplo, sofrer cinco interrupções principais em um ano pode desencadear uma reavaliação do design do sistema e das práticas operacionais.

• Avalie a criticidade para os negócios do sistema. Por exemplo, um serviço que oferece suporte a fluxos de trabalho críticos pode exigir reformulação para implantações de tempo de inatividade zero e failover instantâneo, mesmo que aumente o custo ou a complexidade. Por outro lado, um serviço de uso reduzido pode se beneficiar de objetivos de nível de serviço mais relaxados.

• Avalie como as alterações em outros pilares afetam a confiabilidade. Por exemplo, o aumento de medidas de segurança podem exigir mitigações de confiabilidade para saltos de segurança adicionais, o que poderia introduzir possíveis pontos de falha.

• Avalie os custos operacionais de manutenção da confiabilidade. Se esses custos excederem as restrições orçamentárias, considere as alterações arquitetônicas para otimizar e controlar os gastos.

Para ajudar os stakeholders, engenheiros e gerentes de produto a tomar decisões informadas, considere visualizar os pontos de dados anteriores, juntamente com insights extras. Essa abordagem fornece uma visão completa da confiabilidade.

✓ Executar testes controlados na produção

Nesse nível, considere experimentos controlados em produção somente se a carga de trabalho exigir as garantias de resiliência mais altas. Essas práticas de teste são conhecidas como engenharia do caos. Os testes validam que o sistema pode se recuperar normalmente e continuar funcionando em condições adversas.

Considere os seguintes casos de uso:

• Análise de fluxo de dependência: Um caso de uso comum é testar aplicativos projetados como microsserviços. Você pode desativar instâncias aleatórias de microsserviços para garantir que as falhas não ocorram em cascata ou interrompam a experiência do usuário. Você pode estender essa abordagem aos fluxos do sistema desabilitando componentes específicos para analisar como os sistemas downstream reagem. O objetivo é identificar o acoplamento apertado ou dependências ocultas e testar como os planos de redundância do sistema são executados.

• Teste de degradação normal: Avalie como o sistema é executado com funcionalidade reduzida durante a falha. Por exemplo, você pode ocultar recursos não críticos se um mecanismo de recomendação falhar.

• Simulação de falha de terceiros: Desabilite ou trave chamadas para APIs externas para ver como seu sistema opera e se os mecanismos de fallback ou repetições são implementados corretamente.

A engenharia do caos é um padrão-ouro para testar a resiliência. No entanto, reserve essa prática para sistemas maduros e equipes responsáveis por cargas de trabalho. Verifique se as proteções estão em vigor para limitar o raio de explosão e evitar o impacto do usuário.

• Prepare-se executando dias de simulação. Comece em ambientes de não produção que simulam condições reais usando configurações de menor risco com transações sintéticas. Essa abordagem ajuda a identificar lacunas de processo, caminhos de erro humanos e falhas arquitetônicas.

  Quando o teste de não produção para de produzir insights valiosos, talvez seja hora de migrar para a produção se você estiver confiante. Certifique-se de listar todas as preocupações, avaliar a resiliência e resolver quaisquer problemas antes da transição.

• Limite o escopo dos experimentos. Por exemplo, você pode desligar apenas uma instância. Defina claramente a finalidade do teste. Entenda o que você está testando e por quê.

Esses testes devem seguir contratos de nível de serviço operando dentro de limites predefinidos e orçamentos de erro. Selecione os quadros de tempo apropriados para esses experimentos. Normalmente, executá-los durante um dia de trabalho garante que a equipe esteja totalmente equipada e tenha amplos recursos para responder a quaisquer incidentes que possam ocorrer.

✓ Realizar exercícios de recuperação de desastre

A engenharia do Chaos testa a resiliência dos controles técnicos. As simulações de recuperação de desastres (DR) avaliam a resiliência de controles de processo. O objetivo dos exercícios de recuperação de desastre é validar a eficácia de procedimentos, coordenação e ações humanas quando seu sistema se recupera de grandes falhas ou desastres.

Para cargas de trabalho regulatórias, os requisitos de conformidade podem ditar a frequência de simulações de DR para garantir a documentação do esforço. Para outras cargas de trabalho, é recomendável realizar esses exercícios regularmente. Um intervalo de seis meses oferece uma boa oportunidade para capturar alterações na carga de trabalho e atualizar os procedimentos de recuperação de desastre adequadamente.

Simulações de recuperação de desastres devem ser mais do que exercícios de rotina. Quando realizados corretamente, os exercícios de recuperação de desastre (DR) ajudam a treinar novos membros da equipe e a identificar lacunas nas ferramentas, na comunicação e em outras tarefas relacionadas aos exercícios. Eles também podem destacar novas perspectivas que, de outra forma, podem ser negligenciadas.

Considere os seguintes métodos principais para realizar exercícios de DR, cada um variando em risco e praticidade:

• Totalmente simulado: Esses exercícios são totalmente baseados em quadro branco e incluem orientações passo a passo sem afetar nenhum sistema. Eles são adequados para treinamento e validação inicial. No entanto, eles não fornecem insights sobre incidentes reais.

• Simulações reais em ambientes de não produção: essas simulações permitem validar automação, scripts e processos sem nenhum risco para os negócios.

• Exercícios reais na produção: Esses treinamentos fornecem o mais alto nível de confiança e realismo. Realize essas simulações somente depois de testar os dois métodos anteriores. Estratégias completas de planejamento e reversão são essenciais para minimizar o risco. Não prossiga se houver alguma chance de causar interrupções.

Independentemente do tipo de simulação de DR, defina claramente os cenários de recuperação de carga de trabalho. Faça exercícios como se fossem incidentes reais. Essa abordagem garante que a equipe siga listas de verificação bem compreendidas. Documente e classifique as descobertas para impulsionar o aprimoramento contínuo. Sua preparação para DR pode incluir os seguintes processos:

• Entenda os sistemas de gerenciamento de incidentes e verifique se a equipe é treinada em caminhos de escalonamento.

• Listar ferramentas de comunicação para atualizações de colaboração e status, incluindo alternativas caso os sistemas primários sejam afetados.

• Forneça materiais de qualificação em cenários de teste relevantes para a carga de trabalho.

• Acompanhe as discrepâncias para capturar problemas encontrados durante a implementação.

Prós e contras: essas simulações normalmente não são disruptivas, mas levam tempo. Para maximizar sua eficácia, concentre-se nos principais aspectos e evite tarefas desnecessárias. Certifique-se de alocar tempo para essa prática na sua lista de pendências.

Ao criar planos de DR ou realizar simulações de DR, especificamente nas primeiras simulações, considere incluir conhecimento especializado. A contribuição deles em design multirregional, estratégias de failover e failback, e serviços ou ferramentas pode ser inestimável. Se sua organização tiver uma equipe do Cloud Center of Excellence, inclua-as no processo de planejamento.

✓ Avaliar seu modelo de dados e segmento, se necessário

Os dados são dinâmicos e em constante evolução. Ao contrário de outros componentes em sua arquitetura, os dados normalmente crescem à medida que os usuários interagem com seu sistema. Monitorar padrões de dados ao longo do tempo e avaliar seu impacto em outras partes da arquitetura é essencial. Nesse nível, considere técnicas que simplificam o gerenciamento de dados e melhoram o desempenho para melhorar a confiabilidade geral. O particionamento é uma estratégia fundamental para alcançar esses resultados.

Explore técnicas como particionamento quente e frio, que divide os dados com base nos padrões de acesso e os armazena separadamente. Use critérios como frequência de acesso ou relevância para decidir o que particionar.

O particionamento a frio pode ser combinado com fragmentação, que é um processo que divide um banco de dados grande em unidades menores chamadas fragmentos. Cada fragmento contém uma parte dos dados e, juntos, formam o conjunto de dados completo. Essa abordagem permite o gerenciamento de dados independente.

Dilema: O balanceamento de fragmentos requer processos operacionais para avaliar e confirmar sua distribuição. Essa abordagem ajuda a evitar partições quentes nas quais uma partição é superutilizada. No entanto, também requer esforço e recursos contínuos para manter o equilíbrio.

Ao escolher uma técnica de particionamento, considere os seguintes benefícios de confiabilidade:

• Desempenho aprimorado: Distribuindo solicitações em várias partições, você pode reduzir a carga em repositórios individuais. Quando implementado efetivamente, a fragmentação permite que um sistema processe milhões de solicitações de gravação por dia. Essa estratégia melhora o desempenho e minimiza a latência.

  O particionamento pode simplificar o dimensionamento horizontal. Por exemplo, a fragmentação pode dividir usuários ou clientes em buckets de tamanho aproximadamente igual.

• Gerenciamento de dados aprimorado: O particionamento a frio permite que diferentes níveis de gerenciamento de dados sejam aplicados a cada camada de armazenamento. Por exemplo, mover dados de arquivamento para um repositório separado ajuda a evitar lentidão em operações e backups. Da mesma forma, nem todos os dados de log precisam ser armazenados em um banco de dados relacional. Ele pode ser armazenado em outro armazenamento de dados enquanto os dados de carga de trabalho ativos permanecem relacionais.

• Políticas de confiabilidade personalizadas: políticas de confiabilidade diferentes podem ser aplicadas para ajudar a garantir que cada partição tenha o nível certo de resiliência e impeça que qualquer repositório se torne um gargalo. Partições quentes podem ser totalmente redundantes, incluindo redundância de zona e redundância geográfica, enquanto partições frias dependem de backups. Um benefício de confiabilidade adicional é que você pode reduzir o raio de explosão de alguns tipos de falhas. Por exemplo, se uma falha afetar um fragmento, poderá não afetar os outros fragmentos.

Dilema: Pode ser difícil manter ou modificar partições devido às interdependências fortes entre partições de dados diferentes. Essas alterações podem afetar a capacidade de verificar a consistência e a integridade dos dados, especialmente quando comparadas a um único armazenamento de dados. À medida que o número de partições aumenta, a necessidade de processos robustos para manter a integridade dos dados torna-se mais crucial. Sem essas medidas, a confiabilidade pode ser comprometida.