Modelo de Maturidade de Fiabilidade

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

O nível 1 do modelo de maturidade foi projetado para ajudar as equipes de carga de trabalho a construir uma base sólida para a confiabilidade do sistema. O foco está no bootstrapping, que é o processo de estabelecer as bases para decisões futuras de confiabilidade. Esta etapa envolve principalmente a implementação funcional com pequenas extensões às práticas atuais.

Esta etapa inclui pesquisar, obter insights e criar um inventário de seus sistemas. Ele também usa recursos de confiabilidade internos no Azure, como habilitar redundância de zona para melhorias imediatas.

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

Estratégias-chave

✓ Avaliar oportunidades de descarga de responsabilidade operacional

Esta estratégia é fundamentalmente uma abordagem de construção versus uma abordagem de compra ou confiança . A decisão depende de quanta responsabilidade é gerível nesta fase, ao mesmo tempo que apoia o desenvolvimento futuro. Você deseja usar recursos que são relevantes para a carga de trabalho, mas deve sempre explorar oportunidades para delegar ou aliviar a manutenção desses recursos. Aqui estão alguns casos de uso clássicos em que você pode querer aplicar essa abordagem.

• Transfira responsabilidades para a plataforma de nuvem escolhendo soluções de plataforma como serviço (PaaS). Eles fornecem soluções prontas para necessidades comuns de resiliência, como replicação, failover e armazenamentos de backup. Quando você adota 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 aspetos por conta própria, o que pode ser demorado e complexo.

• Delegar responsabilidades para operações que não estão diretamente ligadas aos objetivos empresariais do fluxo de trabalho. Algumas operações especializadas, como gerenciamento e segurança de banco de dados, podem potencialmente afetar a confiabilidade de sua carga de trabalho. Explore a possibilidade de ter equipes experientes, tecnologia ou ambas para lidar com essas tarefas.

  Por exemplo, se sua equipe não tiver experiência em 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, pois permite que sua equipe se concentre na funcionalidade da carga de trabalho. Muitas empresas partilharam serviços geridos centralmente. Se as equipes da 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ê pode tomar uma decisão explícita de usar suas habilidades e selecionar serviços que não incluam recursos de gerenciamento.

• Transferir responsabilidades para fornecedores que não são da Microsoft. Escolha produtos prontos a usar como ponto de partida. Crie soluções personalizadas apenas quando elas contribuírem para o valor comercial da sua carga de trabalho.

Risco: Se a opção comprar ou confiar 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", onde atualizações e modernização se tornam impraticáveis. Analise regularmente seus requisitos e compare-os com os recursos da solução. Desenvolver 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 confiança possa parecer mais simples no início, ela pode exigir uma reavaliação e redesenho posterior se as limitações do serviço PaaS, da solução do fornecedor ou dos recursos de propriedade da plataforma não atenderem à granularidade ou ao nível de autonomia necessários para a carga de trabalho.

✓ Identificar os fluxos críticos de usuários e sistemas

Nesta fase, é crucial dividir a carga de trabalho em fluxos. Foco 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 os componentes da 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 realizam atividades de front-end, como navegação e pedidos. Enquanto isso, as transações de back-end e os processos acionados pelo sistema atendem às solicitações dos usuários e lidam com outras tarefas. Esses fluxos distintos fazem parte do mesmo sistema, mas envolvem componentes diferentes e servem finalidades diferentes.

Comece a construir um catálogo de fluxos nesta etapa. Observe as interações do usuário e a comunicação dos componentes. Liste e categorize fluxos, defina seus pontos de início e fim e observe as dependências. Documente resultados e exceções usando diagramas para maior clareza. Este catálogo pode servir como uma ferramenta importante para a conversa inicial com as partes interessadas do negócio para identificar os aspetos mais importantes a partir de sua perspetiva. Esta conversa pode informar o primeiro nível de priorização.

Classifique um fluxo como crítico, avaliando o risco e o impacto nas principais atividades de negócios. Se espera uma interrupção, a degradação suave foca em manter esses fluxos críticos. No exemplo do e-commerce, os fluxos críticos incluem pesquisas de produtos, adição de itens ao carrinho e checkout, porque essas tarefas são essenciais para os negócios. Outros processos, como a atualização de dados de produtos e a manutenção de imagens de produtos, não são tão críticos. Certifique-se de que os fluxos críticos permaneçam operacionais durante uma interrupção para evitar perda de receita, permitindo que os usuários continuem pesquisando 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 certas

Deve aplicar esta estratégia aos seguintes níveis:

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

  Você também deve definir limites que criem 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 computação e armazenamento de dados e usar serviços dedicados.

  Atenção

  Em cenários de migração, adotar uma abordagem de elevação e mudança sem analisar novas oportunidades pode levar à perda de benefícios e ineficiências. É importante pesquisar a modernização cedo 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 o seu design. Escolha componentes que atendam às suas necessidades atuais, mas que permaneçam flexíveis para que você possa mudar de serviço à medida que sua carga de trabalho evolui e requer mais recursos.

• SKUs ou camadas nos serviços do Azure: Analise 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.

• Características que suportam a fiabilidade: Escolha serviços nativos da nuvem para melhorar a disponibilidade através de configurações simples sem alterar o código. É importante entender as opções e selecionar intencionalmente as configurações, como aumentar a redundância de zona ou replicar dados para uma região secundária.

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

Dentro de cada parte da sua 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 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 distribuir essas instâncias em vários datacenters do Azure. Se não o fizer, pelo menos garanta redundância local, mas este método apresenta um risco mais elevado. 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.

Compromisso: Um compromisso significativo é 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 degradar 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 com baixa latência, o uso de zonas de disponibilidade poderá interromper seu desempenho.

✓ Habilite 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. Utilize funcionalidades incorporadas para definir alertas para potenciais problemas. Você deve ter alertas básicos para enviar notificações e receber alertas. Aproveite os recursos da plataforma Azure que indicam alterações no status de integridade dos serviços, como:

• Azure Service Health para verificar o estado de saúde ao nível da plataforma.

• Azure Resource Health para verificar o estado de funcionamento ao nível do recurso.

Configure os grupos de ação do Azure Monitor para a infraestrutura e o aplicativo.

Compensação: À medida que você coleta mais logs, precisa 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 espaço de trabalho. Para obter mais informações, consulte Recomendações de configuração para confiabilidade.

Comece a construir observabilidade nas camadas a seguir.

Infraestrutura

Comece habilitando os logs de diagnóstico e certificando-se de que você reúna métricas nativas dos componentes da plataforma para análise. Reúna informações sobre o uso de recursos, como CPU, memória, entrada/saída e atividade de rede.

Aplicação

Colete métricas no nível do aplicativo, como consumo de memória ou latência de solicitação, e registre atividades do aplicativo. Faça operações de registo em uma thread ou processo separado da thread principal da aplicação. Essa abordagem não faz com que o registro em log diminua a velocidade das tarefas principais do aplicativo.

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

Dados

Para monitorar bancos de dados em um nível básico, colete métricas-chave que os recursos do banco de dados emitem. Semelhante aos componentes de infraestrutura, rastreie o uso de recursos no contexto de armazenamentos de dados, como métricas de rede. A recolha de dados sobre a forma como as ligações são agrupadas é importante para melhorar a eficiência em fases posteriores.

Para obter confiabilidade, é importante rastrear as métricas de conexão, como o monitoramento de 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 construir um manual de mitigação de falhas

As falhas variam de falhas intermitentes a falhas transitórias ligeiramente prolongadas e interrupções catastróficas.

No Nível 1, concentre-se em falhas de plataforma. Mesmo que eles estejam além 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 ao nível da plataforma e lide com elas na 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 é essencialmente teórico e amadurece com a automatização a níveis posteriores.

Você deve documentar as falhas, incluindo fatores como sua probabilidade, impacto e estratégias de mitigação. Use uma escala de criticidade que esteja alinhada com os objetivos da sua carga de trabalho. Sua escala pode incluir:

• Alta Uma interrupção completa do sistema que resulta em perdas financeiras significativas e um declínio na confiança do usuário.

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

• Baixo Um pequeno problema de software que afeta um recurso não essencial do aplicativo e causa tempo de inatividade mínimo para os usuários.

Aqui está um modelo de exemplo:

No Nível 1, não se esforce pela perfeição, pois sempre podem ocorrer casos de falhas imprevistas. Se ocorrer interrupções inesperadas, documente as causas e atenuações no manual. Trate esse ativo como um documento dinâmico que você atualiza ao longo do tempo.

✓ Adicionar mecanismos para 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 e configurações internas para lidar com essas falhas e 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 oferecem suporte à confiabilidade.

Problemas persistentes 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 a correção de problemas localizados dentro do aplicativo. Envolve examinar os fluxos críticos de usuários e sistemas do sistema e adicionar técnicas de autopreservação e esforços de recuperação. Estes 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 funcionalidades e configurações.

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

Risco: Os testes geralmente introduzem atrito no ciclo de desenvolvimento. Para mitigar esse risco, torne os testes de confiabilidade rastreáveis juntamente com as tarefas de desenvolvimento.

O desenvolvimento de funcionalidades é a prioridade, e os testes podem criar fricção no ciclo de desenvolvimento. É mais fácil começar a testar antes que o desenvolvimento de recursos seja concluído. Projetar aspetos não funcionais do aplicativo no início permite estendê-los à medida que adiciona recursos funcionais, em vez de criar uma lista de pendências de problemas para resolver mais tarde. Embora essa abordagem exija mais esforço inicialmente, ela é gerenciável e evita problemas maiores mais tarde.

Certifique-se de que o sistema permaneça funcional e estável, incorporando recursos de autopreservação e tendo um plano de recuperação básico para gerenciar falhas.

As 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 introduz 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, detetar e recuperar de falhas mais duradouras. Se não forem resolvidos, esses problemas podem se transformar em interrupções completas.

Os fluxos críticos identificados 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 os tamanhos de provisionamento inicial, as contagens de instâncias e as políticas de dimensionamento automático para reduzir os riscos de confiabilidade.

Neste nível, seja intencional sobre suas práticas de monitoramento e teste. Use técnicas avançadas de monitoramento que se alinham com as necessidades técnicas e são direcionadas para as equipes de desenvolvimento. Expanda o manual simples para cobrir componentes arquitetônicos que você desenvolve e possui, como o código do aplicativo.

Estratégias-chave

✓ 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 especifique o número de recursos redundantes a serem mantidos. Determine onde colocar esses recursos, seja 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 estã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 anteparas, para evitar que falhas se estendam 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. Esta abordagem mantém o sistema operacional mesmo se um componente a jusante falhar. Também impede que o sistema entre em um estado indeterminado. Explore as opções do Azure, incluindo o Barramento de Serviço do Azure para filas e os Hubs de Eventos do Azure para fluxos de eventos.

  Compensação: A comunicação assíncrona pode ajudar a evitar falhas em cascata através da dissociação de processos. No entanto, 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 qualquer alteração no padrão de projeto.

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

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

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

✓ Adicione capacidades técnicas ao seu sistema de monitorização

No Nível 1, você reuniu dados de monitoramento dos componentes da carga de trabalho, com foco na infraestrutura. A análise básica está completa 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 um passo adiante, adicionando recursos avançados de observabilidade aos seus recursos de carga de trabalho e adotando uma abordagem mais estruturada para analisar dados de monitoramento. Tire partido das ferramentas de análise que o seu serviço na nuvem fornece. Por exemplo, as ferramentas de análise do Azure Monitor, como as análises de VM e as análises de rede, fornecem visualizações de saúde e desempenho abrangendo dependências.

Planeje as capacidades de observabilidade nas camadas a seguir.

Aplicação

• Responda à sondagem do estado de saúde. Habilite o aplicativo para responder a solicitações de verificação de integridade de sondas. A aplicação deve ter endpoints dedicados para verificações de saúde que forneçam, no mínimo, informações de estado, como sadio ou insalubre. Essa abordagem permite que os sistemas de monitoramento avaliem se o aplicativo está funcionando corretamente e pode lidar com solicitações, ou se há problemas que precisam ser resolvidos.

  Os serviços de balanceamento de carga do Azure, como o Azure Front Door, o Azure Traffic Manager, o Azure Application Gateway e o Azure Load Balancer, suportam sondas de integridade. As sondas de integridade enviam solicitações de verificação de integridade para aplicativos.

• Avançar para o registo semântico. Inclua informações estruturadas sobre eventos e ações no aplicativo. Com o registro 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.

• Implemente o rastreamento distribuído. Quando uma solicitação flui através de diferentes componentes do sistema, é importante capturar dados de rastreamento entre fronteiras. Esses dados são úteis para obter informações 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, consultas com falha e outras métricas relevantes. Consultas de longa duração podem indicar restrições de recursos e, possivelmente, uma necessidade de ajustar o design do esquema.

  Nesta fase, a sua base de dados já está a funcionar há algum tempo. Preste atenção à taxa de crescimento de dados, especialmente em tabelas que crescem inesperadamente rápido. Essas informações são cruciais para planejar necessidades futuras de armazenamento e solucionar problemas de desempenho com antecedência.

• Monitore o status da replicação do banco de dados usando as ferramentas e o painel fornecidos pelo sistema de gerenciamento de banco de dados. Por exemplo, se utilizar o Azure Cosmos DB, utilize as informações do Azure Cosmos DB. Para o Banco de Dados SQL do Azure ou a Instância Gerenciada SQL do Azure, considere usar o inspetor de banco de dados para obter detalhes de diagnóstico sobre seus bancos de dados.

  À medida que o banco de dados cresce, 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, pois 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 construir operações em torno do sistema de monitoramento.

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

• Monitore os processos de backup e recuperação. Certifique-se de que os backups sejam armazenados com êxito em locais conforme planejado e que os dados da carga de trabalho sejam recuperados dentro de um prazo razoável. O monitoramento desses processos é importante para definir linhas de base para suas métricas de RPO (Recovery Point Objetive, objetivo de ponto de recuperação) em níveis posteriores.

✓ Estenda seu manual de mitigação de falhas

O nível 1 concentra-se nas falhas esperadas da plataforma. No Nível 2, você aborda pontos de falha em componentes e operações dentro de sua própria carga de trabalho. À medida que seu 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. Atenue esses problemas usando táticas de autopreservação ou recuperação.

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

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

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

O manual 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ões de projeto, ajustes de configuração da plataforma, gerenciamento de incidentes no local ao vivo, testes automatizados e treinamento de pessoal para detetar problemas durante revisões de código.

Comece com uma estratégia de degradação graciosa, que inclui correções temporárias quando partes do sistema não funcionam corretamente. O objetivo é continuar a servir os utilizadores apesar das falhas, desativando as peças que não funcionam e ajustando a experiência do utilizador. 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 controlada funcione, isole os componentes do sistema para que apenas as partes afetadas tenham problemas, enquanto os outros componentes continuam a funcionar. Implemente o padrão Bulkhead para obter isolamento de falhas.

Aproveite esta oportunidade para revisitar as opções de design que podem retardar 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 do DNS. Use um serviço dedicado como o Azure Front Door como o ponto de entrada para facilitar a reconfiguração durante as etapas de recuperação.

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

✓ Criar planos de teste

Crie planos de teste simulando interrupções e problemas identificados no manual de mitigação de riscos. Complemente essas mitigações com casos de teste simples para garantir que funcionem conforme o esperado e sejam viáveis. Verifique se esses recursos funcionam corretamente e conduza testes de degradação para ver como o sistema funciona quando componentes específicos falham. Mantenha o resultado simples, garantindo que o teste seja reprovado ou aprovado.

Use ferramentas de teste, como estruturas simuladas, para injetar falhas em solicitações HTTP, que ajudam a testar políticas de repetição mais explicitamente. 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 explorar. 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 expandir ou aumentar a escala de forma eficiente. Aproveite os recursos de dimensionamento automático fornecidos pelo Azure. Esses recursos ajustam os limites de capacidade de um serviço com base em configurações predefinidas. Esse ajuste permite que você dimensione o serviço para cima ou para baixo, conforme necessário.

• Identificar potenciais gargalos e compreender os riscos que estes podem representar. Por exemplo, a alta taxa de transferência não deve causar a quebra do fluxo.

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

  Observação

  Pode haver componentes que não podem ser expandidos, 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, a expansão gradual é mais comum. No entanto, as preocupações com a confiabilidade de fluxos críticos podem exigir um dimensionamento mais rápido para evitar interrupções. Em ambos os casos, evite escalas infinitas.

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 de que não precisa. Ao abordar a causa raiz, você pode garantir estabilidade a longo prazo e eficiência de custos.

: defina objetivos e metas de confiabilidade para manter a equipe responsável pelos procedimentos de recuperação.

Nos níveis iniciais, suas equipes se concentram em vitórias fáceis e capacidades básicas. Eles começam com pequenas melhorias, resolvendo problemas simples para criar uma base sólida enquanto dependem principalmente dos recursos de confiabilidade do Azure. À medida que suas equipes crescem, elas lidam com mais desafios técnicos relacionados a 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 engenheiros de confiabilidade do local (SREs) a atingir as metas de confiabilidade rapidamente.

Estratégias-chave

✓ Formalizar capacidades 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 as partes interessadas da empresa para discutir os tempos e custos de recuperação e fazer compromissos que se alinhem com os objetivos de negócios. Reúna as partes interessadas e conduza esta discussão como um workshop. Considere os seguintes pontos para a agenda do workshop:

• Explique 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 (Recovery Time Objetives, objetivos de tempo de recuperação) e RPOs (Recovery Point Objetives, objetivos de ponto de recuperação). Mostre como essas métricas se alinham com as metas de negócios. Concentre-se nos fluxos críticos de usuários. Por exemplo, numa aplicação de comércio eletrónico, o RTO para atualizar as preferências de e-mail é menos importante do que os utilizadores que realizam o checkout dos carrinhos de compras.

• Comunique as compensações. Muitas vezes, as partes interessadas esperam mais do que aquilo que pode ser alcançado. Explique como a expansão do escopo afeta o orçamento, os requisitos operacionais e o desempenho.

• Proponha metas objetivas. Com base na experiência arquitetural e no design de carga de trabalho, recomende metas como 99,9% de tempo de atividade, com RPO e RTO definidos em quatro horas. Facilitar uma discussão para as partes interessadas para fornecer feedback e fazer ajustes. Assegure-se de que as partes interessadas comerciais e técnicas se protejam contra expectativas irrealistas. Aborde as discussões com uma mentalidade colaborativa.

• Chegar a um consenso ou decisão. Procure um consenso, mas se isso não for possível, peça a um decisor que finalize as metas para garantir o progresso.

✓ Monitore 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 e aplicativos de plataforma. 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 a obtenção de dados de observabilidade de componentes da carga de trabalho, como o código do aplicativo.

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

A modelagem em 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 saúde geral do sistema. Comunicar definições e limiares claros às partes interessadas.

Visualize o modelo de saúde em painéis para ajudar os SREs a identificar problemas rapidamente, concentrando-se em fluxos com problemas 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. O amarelo indica tendências de ocorrência de problemas. A iteração através de versões de modelos de saúde garante fiabilidade e precisão, mas requer um esforço significativo para aplicações grandes.

Uma alteração no estado de saúde deve ser configurada como alerta. No entanto, para manter 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 da resposta, defina alertas claramente e forneça informações suficientes para uma ação rápida. Nomes e descrições de alertas detalhados podem ajudar a economizar tempo e esforço durante a solução de problemas. Configure cuidadosamente a gravidade, 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% a 90% se qualifica como uma emergência. Defina limites apropriados para garantir que os alertas sejam efetivamente definidos.

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

Crie uma única página de destino que tenha as informações necessárias para solucionar problemas de alertas de forma eficiente. Esta abordagem poupa tempo em comparação com acessar o portal Azure e procurar métricas. Se os recursos internos do Azure Monitor não atenderem totalmente às suas necessidades, considere desenvolver um painel personalizado.

✓ Realizar análise de modo de falha

Nos níveis anteriores, você criou um manual simples de mitigação de falhas para componentes individuais. Neste nível, evolua esse manual para um exercício formal de análise de modos de falha (FMA). O objetivo 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 autorrecuperação ou recuperação de desastres (DR). Para começar, monitorize o aumento das taxas de erro e detete impactos nos fluxos críticos. Use experiências anteriores 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 as ações como preventivas ou reativas. As ações preventivas identificam os riscos antes que eles causem uma interrupção, o que reduz sua probabilidade ou gravidade. As ações reativas abordam problemas para mitigar um estado de saúde degradado ou uma interrupção.

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

O FMA é complexo e pode ser demorado, portanto, construa sua análise progressivamente ao longo do tempo. Este processo é iterativo e continua a evoluir em fases posteriores.

Para obter mais informações, consulte RE:03 Recomendações para realizar 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, uma catástrofe requer uma abordagem mais ampla devido a perdas ou fracassos catastróficos. Os planos de DR são baseados em processos. Eles abrangem comunicação, etapas de recuperação detalhadas e, potencialmente, incluem artefatos técnicos, como scripts.

Primeiro, identifique os tipos de desastres a serem planejados, como interrupções de região, falhas em todo o Azure, interrupções de infraestrutura, corrupção de banco de dados e ataques de ransomware. Em seguida, desenvolva estratégias de recuperação para cada cenário e assegure-se de que os mecanismos estão em vigor para restaurar as operações. 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. Certifique-se de que sua equipe use os processos corretos, tenha as permissões certas e compreenda suas funções na recuperação. Algumas responsabilidades, como o relatório do CEO ao mercado ou o cumprimento de requisitos regulatórios, devem ser identificadas precocemente.

  Idealmente, você deve ter funções de recuperação e comunicação separadas e atribuir pessoas diferentes para 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 se agrava, os funcionários seniores podem lidar com a recuperação técnica, enquanto uma pessoa de negócios gerencia as comunicações.

• Tome decisões de negócios. Durante um desastre, os níveis de stress podem ser elevados, o que torna essencial a tomada de decisões claras. Um plano de DR bem estruturado requer discussões contínuas entre a equipe técnica e as partes interessadas do negócio 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 a partir de um backup durante o 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 se espera que a região primária esteja operacional dentro de um prazo aceitável.

• Restaure as operações do sistema. Durante um desastre, o foco deve ser o restabelecimento das operações e não a identificação da causa. Para recuperação técnica, especialmente em caso de falha de região, decida com antecedência sobre abordagens como ativo-ativo, ativo-passivo, standby quente ou standby frio.

  Preparar 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 DR 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 Implementar em configuração ativo-passiva para recuperação de desastres.

• Realizar análises pós-incidentes. Identificar a causa do incidente e encontrar formas de o prevenir no futuro. Faça alterações para melhorar os processos de recuperação. Este exercício poderá também revelar 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 DR é um documento dinâmico que se adapta às mudanças na sua carga de trabalho. Atualize seu plano de DR à medida que novos componentes e riscos surgem. Refine o plano com base em informações obtidas em exercícios ou desastres reais, reunindo informações realistas dos operadores de DR.

Controle os riscos decorrentes de mudanças técnicas e operacionais e priorize o gerenciamento de incidentes.

Nos níveis anteriores, a sua equipa de trabalho se concentra em desenvolver funcionalidades e tornar o sistema operacional. 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 exaustivamente testadas e implantadas com segurança para evitar tornar o sistema instável.

Esse processo requer melhorias nos controles operacionais, como o investimento em equipes dedicadas para gerenciar incidentes de confiabilidade. Exige também controlos técnicos para melhorar a fiabilidade do sistema para 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 dos dados pode exigir redesenhos, como particionamento, para garantir acesso e manutenção confiáveis.

Estratégias-chave

✓ Gestão de mudanças confiável

Os maiores riscos de confiabilidade ocorrem durante alterações, como atualizações de software, ajustes de configuração ou modificações de processos. Estes eventos são críticos do ponto de vista da fiabilidade. O objetivo é minimizar a probabilidade de problemas, interrupções, tempo de inatividade ou perda de dados. Cada tipo de mudança requer atividades específicas para gerir os seus riscos únicos de forma eficaz.

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

• Reaja à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 suporta atualizações automáticas ou manuais e o prazo para atualizações manuais.

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

    Aplique atualizações gradualmente. Mesmo que os testes mostrem que a atualização é segura, aplicá-la a todas as instâncias simultaneamente pode ser arriscado. Em vez disso, atualize algumas instâncias de cada vez e aguarde entre cada série.

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

  • Monitore mudanças repentinas ou graduais após a aplicação de uma atualização. Idealmente, o seu modelo de saúde deve notificá-lo dessas alterações.

• Testes completos com automação. Integre mais testes em seus pipelines de compilação e implantação ao implementar 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, o teste positivo pode verificar se o sistema funciona conforme o esperado. Deve validar que não há erros e que o tráfego flui corretamente.

  Ao planejar atualizações, identifique as portas de teste e os tipos de testes a serem aplicados. A maior parte dos testes deve ser realizada em estágios de pré-desenvolvimento, mas os testes de fumaça também devem ser executados em cada ambiente quando se atualiza.

• Siga 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árias e verde-azuladas, para aumentar a flexibilidade e a confiabilidade.

  Por exemplo, em implementações canárias, um pequeno subconjunto de utilizadores recebe a nova versão primeiro. Esse processo permite o monitoramento e a validação antes da implantação para toda a base de usuários. Técnicas como feature flags e dark launches facilitam o teste em produção antes de disponibilizar as alterações para todos os utilizadores.

• Atualize o seu plano de DR. Atualize regularmente seu plano de DR para mantê-lo relevante e eficaz. Evite instruções desatualizadas. Essa abordagem garante que o plano reflita o estado atual do seu 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 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 engenharia de confiabilidade do local (SRE) para gerenciamento de incidentes. Os SREs são especializados em problemas de produção e especialistas em eficiência, gerenciamento de mudanças, monitoramento, resposta a emergências e gerenciamento de capacidade. Uma equipe SRE proficiente pode reduzir significativamente a dependência da equipe de engenharia.

Forneça aos SREs as ferramentas, informações e conhecimentos necessários para lidar com incidentes de forma independente. Essa preparação reduz a dependência da equipe de engenharia. Os SREs devem ser treinados nos guias e no modelo de saúde da carga de trabalho desenvolvido nos níveis precedentes 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 cada vez.

✓ Automatize os processos de autorrecuperação

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

Compensação: A configuração da automação pode levar tempo e ser dispendiosa. 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 manual automatizado para SREs. Uma abordagem é aprimorar o manual com scripts que implementam etapas de mitigação. Explore as opções nativas do Azure, como usar grupos de ação do Azure Monitor, para configurar gatilhos que iniciam automaticamente várias tarefas.

✓ Estenda a resiliência para tarefas em segundo plano

A maioria das cargas de trabalho inclui componentes que não suportam diretamente os 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árias tarefas em segundo plano, como confirmação de e-mail, finalização de cobrança de cartão de crédito e notificação de depósito 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 seus fluxos de usuários principais, considere as tarefas em segundo plano. Use as técnicas e a infraestrutura já existentes e adicione melhorias para tarefas em segundo plano.

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

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

• Garanta a consistência. Impeça que o sistema entre em um estado inconsistente se uma tarefa em segundo plano parar 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 nas 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 no nível de tarefa ou transações de compensação para garantir que ela seja concluída.

• Integre tarefas em segundo plano em seu sistema de monitoramento e práticas de teste. Detete falhas e evite 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 forma que 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 Azure App Service WebJobs. Analise suas práticas recomendadas e limites ao implementar fluxos que se concentram na confiabilidade.

Permaneça resiliente à medida que a arquitetura de 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, aplicativos e operações devem ser confiáveis o suficiente para serem resilientes a interrupções e se recuperarem delas dentro dos tempos de recuperação desejados.

Use dados e metas de negócios futuras para reconhecer que, se sua empresa precisar ir além, mudanças arquitetônicas podem ser necessárias. À medida que sua carga de trabalho evolui e novos recursos são adicionados, esforce-se para minimizar as interrupções relacionadas a esses recursos e, ao mesmo tempo, reduzir ainda mais as interrupções dos recursos existentes.

Estratégias-chave

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

A este nível, tome decisões em colaboração com as partes interessadas do negócio. Considere os seguintes fatores:

• Analise métricas que indicam quantas vezes seu sistema ultrapassa os limites de confiabilidade dentro de um período de tempo e se isso é aceitável. Por exemplo, a ocorrência de cinco grandes interrupções num ano pode desencadear uma reavaliação da conceção do sistema e das práticas operacionais.

• Avaliar a criticidade de negócios do sistema. Por exemplo, um serviço que ofereça suporte a fluxos de trabalho de missão crítica pode exigir um redesenho para implantações sem tempo de inatividade e failover instantâneo, mesmo que isso 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 mudanças em outros pilares afetam a confiabilidade. Por exemplo, o aumento das medidas de segurança pode exigir mitigar questões de confiabilidade devido a saltos de segurança extras, o que pode introduzir potenciais pontos de vulnerabilidade.

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

Para ajudar as partes interessadas, engenheiros e gerentes de produto a tomar decisões informadas, considere visualizar os pontos de dados anteriores juntamente com insights extras. Esta abordagem fornece uma imagem completa da fiabilidade.

✓ Executar testes controlados em produção

A este nível, considere experiências controladas em produção apenas se a carga de trabalho exigir as mais elevadas garantias de resiliência. Essas práticas de teste são conhecidas como engenharia do caos. Os testes validam que o sistema pode se recuperar graciosamente e continuar funcionando em condições adversas.

Considere os seguintes exemplos de casos de uso:

• Análise do fluxo de dependência: Um caso de uso comum é o teste de aplicativos projetados como microsserviços. Você pode desativar instâncias aleatórias de microsserviço 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 desativando componentes específicos para analisar como os sistemas a jusante reagem. O objetivo é identificar acoplamento rígido ou dependências ocultas e testar o desempenho dos planos de redundância do sistema.

• Testes de degradação controlada: Avalie como o sistema funciona com funcionalidade reduzida em caso de falha. Por exemplo, você pode ocultar recursos não críticos se um mecanismo de recomendação falhar.

• Simulação de falhas de terceiros: Desative ou acelere chamadas para APIs externas para ver como seu sistema opera e se fallbacks ou novas tentativas 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 equipas de trabalho. Certifique-se de que existem proteções para limitar o raio de jateamento e evitar o impacto do usuário.

• Prepare-se organizando dias de simulação. Comece em ambientes de não produção que simulam condições do mundo real usando configurações de menor risco com transações sintéticas. Essa abordagem ajuda a identificar lacunas de processo, caminhos de erro humano e falhas de arquitetura.

  Quando os testes que não são de produção param de produzir informações valiosas, talvez seja hora de passar 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.

• Limitar o âmbito das experiências. Por exemplo, você pode desligar apenas uma instância. Defina claramente o objetivo do teste. Entenda o que você está testando e por quê.

Esses testes devem aderir aos contratos de nível de serviço, operando dentro de limites predefinidos e orçamentos de erro. Selecione os prazos apropriados para esses experimentos. Normalmente, realizá-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 desastres

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

Para cargas de trabalho regulamentares, os requisitos de conformidade podem ditar a frequência dos exercícios de recuperação de desastres (DR) para assegurar um registo do trabalho. Para outras cargas de trabalho, recomenda-se a realização desses exercícios regularmente. Um intervalo de seis meses oferece uma boa oportunidade para capturar alterações de carga de trabalho e atualizar os procedimentos de DR de acordo.

Os exercícios de DR devem ser mais do que exercícios de rotina. Quando conduzidas corretamente, as simulações de Recuperação de Desastres ajudam a treinar novos membros da equipa e a identificar lacunas em ferramentas, comunicação e outras tarefas relacionadas ao exercício. Eles também podem destacar novas perspetivas que, de outra forma, poderiam ser negligenciadas.

Considere os seguintes métodos-chave para conduzir exercícios DR, cada um variando em risco e praticidade:

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

• Simulações reais em ambientes de não produção: Esses ensaios permitem validar automação, scripts e processos sem qualquer risco para o negócio.

• Exercícios reais na produção: Estes exercícios proporcionam o mais alto nível de confiança e realismo. Realize esses exercícios somente depois de testar os dois métodos anteriores. Planejamento minucioso e estratégias de reversão são essenciais para minimizar o risco. Não prossiga se houver alguma chance de causar interrupções.

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

• Compreenda os sistemas de gerenciamento de incidentes e garanta que a equipe seja treinada em caminhos de escalonamento.

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

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

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

Troca: Essas simulações normalmente não são disruptivas, mas levam tempo. Para maximizar a sua eficácia, concentre-se nos aspetos chave e evite tarefas desnecessárias. Certifique-se de alocar tempo para essa prática em sua lista de pendências.

Ao criar planos de DR ou conduzir exercícios de DR, especificamente para os primeiros exercícios, considere incluir conhecimentos especializados. A sua contribuição sobre 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, certifique-se de incluí-la no processo de planejamento.

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

Os dados são dinâmicos e estão 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 sua arquitetura é essencial. Nesse nível, considere técnicas que simplifiquem o gerenciamento de dados e melhorem o desempenho para aumentar a confiabilidade geral. O particionamento é uma estratégia fundamental para alcançar esses resultados.

Explore técnicas como o particionamento a quente-frio, que divide os dados com base em 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 quente e frio pode ser combinado com a fragmentação, que é um processo que divide um grande banco de dados 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 independente de dados.

Compensação: O balanceamento de fragmentos requer processos operacionais para avaliar e confirmar sua distribuição. Essa abordagem ajuda a evitar partições quentes em que uma partição é usada em excesso. No entanto, exige também esforços e recursos contínuos para manter o equilíbrio.

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

• Desempenho melhorado: Ao distribuir solicitações em várias partições, você pode reduzir a carga em lojas individuais. Quando implementado de forma eficaz, 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.

• Melhor gerenciamento de dados: O particionamento a quente e frio permite que diferentes níveis de gerenciamento de dados sejam aplicados a cada nível de armazenamento. Por exemplo, mover dados de arquivamento para um armazenamento separado ajuda a evitar lentidão nas 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 ativos da carga de trabalho permanecem relacionais.

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

Compensação: Pode ser difícil manter ou modificar partições devido às fortes interdependências entre diferentes partições de dados. 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 estas medidas, a fiabilidade pode ficar comprometida.