Recomendações para definir metas de confiabilidade

Aplica-se a esta recomendação de lista de verificação de Confiabilidade do Azure Well-Architected Framework:

RE:04	Defina as metas de confiabilidade e recuperação para os componentes, os fluxos e a solução geral. Visualize as metas para negociar, obter consenso, definir expectativas e direcionar ações para alcançar o estado ideal. Use os destinos definidos para criar o modelo de integridade. O modelo de saúde define como são estados saudáveis, degradados e insalubres.

Este guia descreve as recomendações para definir métricas de destino de disponibilidade e recuperação para cargas de trabalho e fluxos críticos. As metas de confiabilidade são obtidas por meio de exercícios de workshop com os stakeholders de negócios. As metas são refinadas por meio de monitoramento e testes.

Com os stakeholders internos, defina expectativas realistas de confiabilidade da carga de trabalho para que eles possam comunicar essas expectativas aos clientes por meio de contratos. Expectativas realistas também ajudam as partes interessadas a entender e apoiar suas decisões de projeto arquitetônico e saber que você está projetando para atender de forma ideal às metas acordadas.

Considere o uso das métricas a seguir para quantificar os requisitos de negócios.

Termo	Definição
Objetivo de nível de serviço (SLO)	Uma medida do desempenho e da confiabilidade de uma carga de trabalho ou aplicativo. Um SLO é um alvo específico e mensurável definido para interações específicas com o cliente. É um destino que você define para sua carga de trabalho no aplicativo com base na qualidade do serviço que seus usuários devem esperar receber.
Indicador de nível de serviço (SLI)	Uma métrica emitida por um serviço. As métricas de SLI são agregadas para quantificar um valor de SLO.
SLA (Contrato de Nível de Serviço)	Um acordo contratual entre o prestador de serviços e o cliente do serviço. O não cumprimento do contrato pode ter consequências financeiras para o prestador de serviços.
Tempo médio para recuperação (MTTR)	O tempo necessário para restaurar um componente após a detecção de uma falha.
Tempo médio entre falhas (MTBF)	A duração pela qual a carga de trabalho pode executar a função esperada sem interrupção, até que ela falhe.
RTO (objetivo de tempo de recuperação)	Tempo máximo aceitável que um aplicativo pode ficar indisponível após um incidente.
RPO (Objetivo de Ponto de Recuperação)	A duração máxima aceitável da perda de dados durante um incidente.

Defina os valores de destino da carga de trabalho para essas métricas no contexto de fluxos de usuário e fluxos do sistema. Identifique e classifique esses fluxos de acordo com o quão críticos eles são para suas necessidades. Use os valores para conduzir o design de sua carga de trabalho em termos de arquitetura, revisão, teste e operações de gerenciamento de incidentes. O não cumprimento das metas afetará o negócio além do nível de tolerância.

Principais estratégias de design

As discussões técnicas não devem orientar como você define metas de confiabilidade para seus fluxos críticos. Em vez disso, as partes interessadas de negócios devem se concentrar nos clientes à medida que definem os requisitos de uma carga de trabalho. Especialistas técnicos ajudam as partes interessadas a atribuir valores numéricos realistas que se correlacionam a esses requisitos. À medida que compartilham conhecimento, os especialistas técnicos permitem a negociação e o consenso mútuo sobre SLOs realistas.

Considere um exemplo de como mapear requisitos para valores numéricos mensuráveis. As partes interessadas estimam que, para um fluxo crítico de usuários, uma hora de inatividade durante o horário comercial regular resulta em uma perda de X dólares em receita mensal. Esse valor em dólar é comparado ao custo estimado de projetar um fluxo que tenha um SLO de disponibilidade de 99,95%, em vez de 99,9%. Os tomadores de decisão devem discutir se o risco dessa perda de receita supera os custos adicionais e a carga de gerenciamento necessários para se proteger contra ela. Siga esse padrão ao examinar os fluxos e criar uma lista completa de destinos.

Lembre-se de que as metas de confiabilidade diferem das metas de desempenho. As metas de confiabilidade se concentram na disponibilidade e na recuperação. Para definir metas de confiabilidade, comece definindo os requisitos mais amplos e, em seguida, defina métricas mais específicas para atender aos requisitos de alto nível.

Os requisitos de confiabilidade e recuperação de mais alto nível e as métricas correlacionadas podem incluir, por exemplo, uma disponibilidade de aplicativos de 99,9% para todas as regiões ou um RTO de destino de 5 horas para a região das Américas. A definição desses tipos de destinos ajuda a identificar quais fluxos críticos estão envolvidos nesses destinos. Em seguida, você pode considerar destinos em nível de componente.

Compensação: pode existir uma lacuna conceitual entre as limitações técnicas dos componentes da carga de trabalho e o que isso significa para os negócios, por exemplo, taxa de transferência em megabits por segundo versus transações por segundo. Criar um modelo entre esses dois modos de exibição pode ser um desafio. Em vez de sobreprojetar a solução, tente abordá-la de forma econômica, mas significativa.

Métricas de disponibilidade

SLOs e SLAs

Um SLO é uma medida do desempenho e da confiabilidade de uma carga de trabalho ou aplicativo. Um SLO é um alvo específico e mensurável definido para interações específicas com o cliente. É uma meta que você define para sua carga de trabalho ou aplicativo sobre a qualidade do serviço que seus usuários devem esperar receber.

Um SLO pode ser definido em termos de uma variedade de métricas, como disponibilidade, tempo de resposta, taxa de transferência, taxa de sucesso e outras. Por exemplo, um SLO para um serviço Web pode ser que ele estará disponível para os usuários 99,9% do tempo em um determinado mês, ou que responderá a 95% das solicitações dentro de 500 milissegundos.

Antes de definir os SLOs para seu aplicativo ou carga de trabalho, revise os SLAs publicados pela Microsoft para os serviços subjacentes nos quais seu aplicativo ou carga de trabalho está hospedado.

Observação

Os SLAs de serviço da Microsoft não são SLIs ou SLOs de plataforma

Ao revisar o SLA de cada serviço, preste atenção à quantidade de redundância necessária para atender a SLAs altos. Por exemplo, a Microsoft garante SLAs mais altos para implantações de várias regiões do Azure Cosmos DB do que garante para implantações de região única.

Observação

Os SLAs do Azure nem sempre abrangem todos os aspectos de um serviço. Por exemplo, o Gateway de Aplicativo do Azure tem um SLA de disponibilidade, mas a funcionalidade do Firewall de Aplicativo Web do Azure não fornece nenhuma garantia para impedir a passagem de tráfego mal-intencionado. Considere essa limitação ao desenvolver seus SLAs e SLOs.

Depois de reunir os SLAs para os componentes de carga de trabalho individuais, calcule um SLA composto. O SLA composto deve corresponder ao SLO de destino da carga de trabalho. O cálculo de um SLA composto envolve vários fatores, dependendo do design da arquitetura. Considere os exemplos a seguir.

Observação

Os valores de SLA nos exemplos a seguir são hipotéticos e são apenas para fins de demonstração. Eles não se destinam a representar valores atuais suportados pela Microsoft.

Os SLAs compostos envolvem vários serviços que oferecem suporte a um aplicativo, com diferentes níveis de disponibilidade. Por exemplo, considere um aplicativo Web do Serviço de Aplicativo do Azure que grava no Banco de Dados SQL do Azure. Hipoteticamente, esses SLAs podem ser:

• Aplicativos Web do Serviço de Aplicativo = 99,95%
• Banco de dados SQL = 99,99%

Qual é o tempo máximo de inatividade que você pode esperar para este aplicativo? Se o serviço falhar, o aplicativo inteiro falhará. A probabilidade de cada serviço falhar é independente, portanto, o SLA composto para esse aplicativo é de 99,95% × 99,99% = 99,94%. Esse valor é menor do que os SLAs individuais. Essa conclusão não é surpreendente porque um aplicativo que depende de vários serviços tem mais pontos de falha em potencial.

Você pode melhorar o SLA de composição ao criar caminhos independentes de fallback. Por exemplo, se o banco de dados SQL não estiver disponível, coloque as transações em uma fila, para serem processadas posteriormente:

Nesse design, o aplicativo ainda está disponível mesmo que não possa se conectar ao banco de dados. No entanto, ele falhará se o banco de dados e a fila falharem ao mesmo tempo. A porcentagem esperada de tempo para uma falha simultânea é de 0,0001 × 0,001, portanto, aqui está o SLA composto para esse caminho combinado:

Banco de dados ou fila = 1,0 − (0,0001 × 0,001) = 99,99999 por cento

O SLA composto total:

Aplicativo Web e (banco de dados ou fila) = 99,95% × 99,99999% = ~99,95%

Essa abordagem apresenta compensações:

• A lógica do aplicativo é mais complexa.
• Você paga pela fila.
• Você precisa considerar os problemas de consistência de dados.

Para implantações de várias regiões, o SLA composto é calculado da seguinte maneira:

• N é o SLA composto para o aplicativo implantado em uma região.

• R é o número de regiões em que o aplicativo é implantado.

A chance esperada de que o aplicativo falhe em todas as regiões ao mesmo tempo é ((1 − N) ^ R). Por exemplo, se o SLA hipotético de região única for de 99,95%:

• O SLA combinado para duas regiões = (1 − (1 − 0,9995) ^ 2) = 99,999975 por cento

• O SLA combinado para quatro regiões = (1 − (1 − 0,9995) ^ 4) = 99,999999 por cento

A definição de SLOs adequados leva tempo e consideração cuidadosa. As partes interessadas da empresa devem entender como os principais clientes usam o aplicativo. Eles também devem entender a tolerância à confiabilidade. Esse feedback deve informar as metas.

Valores de SLA

A tabela a seguir define valores comuns de SLA.

SLA	Tempo de inatividade por semana	Tempo de inatividade por mês	Tempo de inatividade por ano
99%	1,68 hora	7,2 horas	3,65 dias
99,9%	10,1 minutos	43,2 minutos	8,76 horas
99,95%	5 minutos	21,6 minutos	4,38 horas
99,99%	1,01 minuto	4,32 minutos	52,56 minutos
99,999%	6 segundos	25,9 segundos	5,26 minutos

Quando você pensa em SLAs compostos no contexto de fluxos, lembre-se de que diferentes fluxos têm diferentes definições de criticidade. Considere essas diferenças ao criar seus SLAs compostos. Os fluxos não críticos podem ter componentes que você deve omitir de seus cálculos porque eles não afetam a experiência do cliente se estiverem brevemente indisponíveis.

Observação

As cargas de trabalho voltadas para o cliente e as cargas de trabalho de uso interno têm SLOs diferentes. Normalmente, as cargas de trabalho de uso interno podem ter SLOs de disponibilidade muito menos restritivas do que as cargas de trabalho voltadas para o cliente.

LES

Pense em SLIs como métricas de nível de componente que contribuem para um SLO. Os SLIs mais significativos são aqueles que afetam seus fluxos críticos da perspectiva de seus clientes. Para muitos fluxos, as SLIs incluem latência, taxa de transferência, taxa de erro e disponibilidade. Um bom SLI ajuda a identificar quando um SLO corre o risco de ser violado. Correlacione o SLI a clientes específicos quando possível.

Para evitar a coleta de métricas inúteis, limite o número de SLIs para cada fluxo. Busque três SLIs por fluxo, se possível.

Métricas de recuperação

Os destinos de recuperação correspondem às métricas RTO, RPO, MTTR e MTBF. Em contraste com as metas de disponibilidade, as metas de recuperação para essas medições não dependem muito dos SLAs da Microsoft. A Microsoft publica garantias de RTO e RPO apenas para alguns produtos, como o Banco de Dados SQL.

As definições para metas de recuperação realistas dependem de sua análise de modo de falha e de seus planos e testes para continuidade de negócios e recuperação de desastres. Antes de concluir este trabalho, discuta as metas aspiracionais com as partes interessadas e certifique-se de que seu projeto de arquitetura ofereça suporte às metas de recuperação da melhor maneira possível. Comunique claramente às partes interessadas que quaisquer fluxos ou cargas de trabalho inteiras que não sejam exaustivamente testadas para métricas de recuperação não devem ter SLAs garantidos. Certifique-se de que as partes interessadas entendam que as metas de recuperação podem mudar ao longo do tempo à medida que as cargas de trabalho são atualizadas. A carga de trabalho pode se tornar mais complexa à medida que os clientes são adicionados ou à medida que você adota novas tecnologias para melhorar a experiência do cliente. Essas alterações podem aumentar ou diminuir suas métricas de recuperação.

Observação

MTBF pode ser difícil de definir e garantir. Plataformas como serviço (PaaS) ou software como serviço (SaaS) podem falhar e se recuperar sem qualquer notificação do provedor de nuvem, e o processo pode ser completamente transparente para você ou seus clientes. Se você definir destinos para essa métrica, abranja apenas os componentes que estão sob seu controle.

Ao definir metas de recuperação, defina limites para iniciar uma recuperação. Por exemplo, se um nó da Web ficar indisponível por mais de 5 minutos, um novo nó será adicionado automaticamente ao pool. Defina limites para todos os componentes, considerando o que a recuperação de um componente específico envolve, incluindo o efeito em outros componentes e dependências. Seus limites também devem levar em conta falhas transitórias para garantir que você não inicie ações de recuperação muito rapidamente. Documente e compartilhe com as partes interessadas os riscos potenciais das operações de recuperação, como perda de dados ou interrupções de sessão para os clientes.

Construindo um modelo de saúde

Use os dados coletados para suas metas de confiabilidade para criar seu modelo de integridade para cada carga de trabalho e fluxos críticos associados. Um modelo de saúde define estados saudáveis, degradados e insalubres para os fluxos e cargas de trabalho. Os estados garantem a priorização operacional adequada. Este modelo também é conhecido como um modelo de semáforo. O modelo atribui verde para saudável, amarelo para degradado e vermelho para insalubre. Um modelo de integridade garante que você saiba quando o estado de um fluxo muda de íntegro para degradado ou insalubre.

A forma como você define estados íntegros, degradados e não íntegros depende de suas metas de confiabilidade. Aqui estão alguns exemplos de maneiras de definir os estados:

• Um estado verde ou íntegro indica que os principais requisitos e metas não funcionais estão totalmente satisfeitos e que os recursos são usados de forma otimizada. Por exemplo, 95% das solicitações são processadas em <=500 ms com o uso do nó do Serviço de Kubernetes do Azure (AKS) em X por cento.

• Um estado amarelo ou degradado indica que um ou mais componentes do fluxo estão alertando contra seu limite definido, mas o fluxo está operacional. Por exemplo, a limitação de armazenamento foi detectada.

• Um estado vermelho ou não íntegro indica que a degradação persistiu por mais tempo do que o permitido pelas metas de confiabilidade ou que o fluxo se tornou indisponível.

Observação

O modelo de saúde não deve tratar todas as falhas da mesma forma. O modelo de saúde deve distinguir entre falhas transitórias e não transitórias . Ela deve distinguir claramente entre falhas transitórias esperadas, mas recuperáveis, e um estado de desastre verdadeiro.

Esse modelo funciona usando uma estratégia de monitoramento e alerta que é desenvolvida e operada com base nos princípios da melhoria contínua. À medida que suas cargas de trabalho evoluem, seus modelos de saúde devem evoluir com elas.

Para obter considerações detalhadas de design e recomendações para um modelo de integridade de aplicativo em camadas, consulte as diretrizes de modelagem de integridade encontradas nas áreas de design de carga de trabalho de missão crítica. Para obter orientações detalhadas sobre configurações de monitoramento e alerta, consulte o guia de monitoramento de integridade.

Visualização

Para manter suas equipes de operações e partes interessadas da carga de trabalho informadas sobre o status em tempo real e as tendências gerais do modelo de integridade da carga de trabalho, considere a criação de painéis em sua solução de monitoramento. Discuta soluções de visualização com as partes interessadas para garantir que você forneça as informações que elas valorizam e que sejam fáceis de consumir. Eles também podem querer ver relatórios gerados semanalmente, mensalmente ou trimestralmente.

Azure facilitation

Os SLAs do Azure fornecem os compromissos da Microsoft para tempo de atividade e conectividade. Serviços diferentes têm SLAs diferentes e, às vezes, SKUs dentro de um serviço têm SLAs diferentes. Para obter mais informações, consulte Contratos de nível de serviço para serviços online.

O SLA do Azure inclui procedimentos para obter um crédito de serviço se o SLA não for atendido, juntamente com definições de disponibilidade para cada serviço. Esse aspecto do SLA atua como uma política de imposição.

Links relacionados

• Orientação de missão crítica do Well-Architected Framework para modelagem de integridade: modelagem de integridade e observabilidade de cargas de trabalho de missão crítica no Azure

Lista de verificação de confiabilidade

Consulte o conjunto completo de recomendações.

Lista de verificação de confiabilidade