Recomendações para definir destinos de confiabilidade

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

RE:04	Defina os destinos 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 impulsionar ações para alcançar o estado ideal. Use os destinos definidos para criar o modelo de integridade. O modelo de integridade define como são os estados íntegros, degradados e não íntegros.

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

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

Considere usar as métricas a seguir para quantificar os requisitos de negócios.

Termo	Definição
SLO (objetivo de nível de serviço)	Um destino percentual que representa a integridade do componente e da camada de confiabilidade. Quanto maior a camada, mais confiável será o componente. O SLO composto representa o destino agregado de toda a carga de trabalho e as contas para os SLOs do componente.
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 contrato contratual entre o provedor de serviços e o cliente de serviço. O contrato define os SLOs. O não cumprimento do contrato pode ter consequências financeiras para o provedor de serviços.
MTTR (tempo médio de recuperação)	O tempo necessário para restaurar um componente após a detecção de uma falha.
Tempo médio entre falha (MTBF)	A duração para a 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 marque esses fluxos pelo quão críticos eles são para seus requisitos. Use os valores para impulsionar o design da carga de trabalho em termos de arquitetura, revisão, teste e operações de gerenciamento de incidentes. A falha no cumprimento das metas afetará os negócios 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, os stakeholders de negócios devem se concentrar nos clientes à medida que definem os requisitos de uma carga de trabalho. Especialistas técnicos ajudam os stakeholders a atribuir valores numéricos realistas que se correlacionam com esses requisitos. À medida que compartilham conhecimento, especialistas técnicos permitem negociação e consenso mútuo sobre SLOs realistas.

Considere um exemplo de como mapear requisitos para valores numéricos mensuráveis. Os stakeholders estimam que, para um fluxo de usuário crítico, uma hora de tempo de inatividade durante o horário comercial normal resulta em uma perda de X dólares na receita mensal. Esse valor em dólar é comparado com o custo estimado de projetar um fluxo que tem 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 gestão necessária para se proteger contra ela. Siga esse padrão enquanto examina fluxos e cria 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 defina métricas mais específicas para atender aos requisitos de alto nível.

Os requisitos de confiabilidade e recuperação de nível mais alto e as métricas correlacionadas podem incluir, por exemplo, uma disponibilidade de aplicativo de 99,9% para todas as regiões ou um RTO de destino de 5 horas para a região américas. Definir esses tipos de destinos ajuda a identificar quais fluxos críticos estão envolvidos nesses destinos. Em seguida, você pode considerar destinos no nível do 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 a empresa, por exemplo, taxa de transferência em megabits por segundo versus transações por segundo. Criar um modelo entre essas duas exibições pode ser um desafio. Em vez de superengenhar a solução, tente abordá-la de forma econômica, mas significativa.

Métricas de disponibilidade

SLOs e SLAs

As métricas de disponibilidade correlacionam-se aos SLOs, que você usa para definir SLAs. O SLO da carga de trabalho determina quanto tempo de inatividade é tolerável em um determinado período, por exemplo, menos de 1 hora por mês. Para garantir que você possa atender ao destino do SLO, examine os SLAs da Microsoft para cada componente. Preste atenção à quantidade de redundância necessária para atender aos 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, Gateway de Aplicativo do Azure tem um SLA de disponibilidade, mas a funcionalidade de Firewall de Aplicativo Web do Azure não fornece nenhuma garantia de impedir que o tráfego mal-intencionado passe. Considere essa limitação ao desenvolver seus SLAs e SLOs.

Depois de coletar 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 os valores atuais com suporte da Microsoft.

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

• Serviço de Aplicativo aplicativos Web = 99,95%
• Banco de Dados SQL = 99,99%

Qual é o tempo de inatividade máximo 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 este aplicativo é de 99,95% × 99,99% = 99,94%. Esse valor é menor 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 potenciais.

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 estará 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. O percentual esperado de tempo para uma falha simultânea é 0,0001 × 0,001, portanto, aqui está o SLA composto para este caminho combinado:

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

O SLA composto total:

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

Essa abordagem representa compensações:

• A lógica do aplicativo é mais complexa.
• Você paga pela fila.
• Você precisa considerar 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 hipotético SLA 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%

Definir SLOs adequados leva tempo e consideração cuidadosa. Os stakeholders de negócios devem entender como os principais clientes usam o aplicativo. Eles também devem entender a tolerância à confiabilidade. Esses comentários devem informar os destinos.

Valores de SLA

A tabela a seguir define valores SLA comuns.

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ê pensar em SLAs compostos no contexto de fluxos, lembre-se de que fluxos diferentes têm definições de criticalidade diferentes. Considere essas diferenças ao criar seus SLAs compostos. 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 eles estiverem brevemente indisponíveis.

Observação

Cargas de trabalho voltadas para o cliente e 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.

SLIs

Pense em SLIs como métricas de nível de componente que contribuem para um SLO. Os SLIs mais significativos são os que afetam seus fluxos críticos da perspectiva de seus clientes. Para muitos fluxos, os SLIs incluem latência, taxa de transferência, taxa de erro e disponibilidade. Um bom SLI ajuda você a identificar quando um SLO corre o risco de ser violado. Correlacionar 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. Aponte para 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. Ao contrário das metas de disponibilidade, as metas de recuperação para essas medidas não dependem muito dos SLAs da Microsoft. A Microsoft publica garantias de RTO e RPO apenas para alguns produtos, como Banco de Dados SQL.

As definições para destinos de recuperação realistas dependem da análise do modo de falha e de seus planos e testes para continuidade dos negócios e recuperação de desastres. Antes de concluir este trabalho, discuta os destinos aspiracionais com os stakeholders e verifique se seu design de arquitetura dá suporte às metas de recuperação com o melhor de sua compreensão. Comunique-se claramente aos stakeholders que todos os fluxos ou cargas de trabalho inteiras que não são totalmente testados para métricas de recuperação não devem ter SLAs garantidos. Certifique-se de que os stakeholders entendam que as metas de recuperação podem ser alteradas 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

O MTBF pode ser um desafio para definir e garantir. As PaaS (plataformas como serviço) ou SaaS (software como serviço) podem falhar e se recuperar sem nenhuma 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, cubra apenas os componentes que estão sob seu controle.

Conforme você define destinos 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 qual recuperação para 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 os stakeholders os riscos potenciais de operações de recuperação, como perda de dados ou interrupções de sessão para os clientes.

Criando um modelo de integridade

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 integridade define estados íntegros, degradados e não íntegros para os fluxos e cargas de trabalho. Os estados garantem a priorização operacional apropriada. Esse modelo também é conhecido como um modelo de semáforo. O modelo atribui verde para íntegro, amarelo para degradado e vermelho para não íntegro. Um modelo de integridade garante que você saiba quando o estado de um fluxo muda de íntegro para degradado ou não íntegro.

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 destinos não funcionais são totalmente atendidos e que os recursos são usados de forma ideal. Por exemplo, 95% das solicitações são processadas em <=500 ms com uso de nó 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 em relação ao 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 ficou indisponível.

Observação

O modelo de integridade não deve tratar todas as falhas da mesma forma. O modelo de integridade 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 nos princípios de melhoria contínua. À medida que suas cargas de trabalho evoluem, seus modelos de integridade devem evoluir com eles.

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

Visualização

Para manter as equipes de operações e os stakeholders de carga de trabalho informados sobre os status em tempo real e as tendências gerais do modelo de integridade da carga de trabalho, considere criar painéis em sua solução de monitoramento. Discuta as soluções de visualização com os stakeholders 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, mensais ou trimestrais.

Facilitação do Azure

Os SLAs do Azure fornecem os compromissos da Microsoft para tempo de atividade e conectividade. Diferentes serviços 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

• Well-Architected Framework diretrizes críticas para modelagem de integridade: modelagem de integridade e observabilidade de cargas de trabalho críticas no Azure

Lista de verificação de confiabilidade

Consulte o conjunto completo de recomendações.

Lista de verificação de confiabilidade