Recomendações para definir metas de confiabilidade
Aplica-se a esta recomendação da lista de verificação de confiabilidade bem arquitetada: Power Platform
| RE:04 | Defina metas de confiabilidade e recuperação para os componentes, os fluxos e a solução geral. Visualize as metas para negociar, chegar a um consenso, estabelecer expectativas e direcionar ações para atingir o estado ideal. Use as metas definidas para compilar o modelo de integridade. O modelo de integridade define a aparência dos estados de integridade, degradação e não integridade. |
|---|
Este guia descreve as recomendações para definir métricas desejadas de disponibilidade e recuperação para cargas de trabalho críticas. As metas de confiabilidade derivam dos exercícios de workshop com os stakeholders do negócio.
As metas são aprimoradas por meio de monitoramento e teste. Trabalhe com os stakeholders internos para estabelecer expectativas realistas de confiabilidade. Este exercício também vai ajudar os stakeholders a dar suporte às escolhas de design arquitetônico e compreender que você está projetando para atender melhor às metas acordadas.
O Microsoft Power Platform resolve a maioria das preocupações de disponibilidade e confiabilidade no nível da infraestrutura para você. No entanto, a disponibilidade das cargas de trabalho compiladas por você tem responsabilidade compartilhada. É importante compreender que, mesmo com o compromisso da Microsoft com a alta disponibilidade, o risco de tempo de inatividade do sistema nunca é zero.
Leve em consideração 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 meta de porcentagem que representa a integridade do componente e o nível de confiabilidade. Quanto mais alto for o nível, mais confiável será o componente. O SLO composto representa a meta agregada de toda a carga de trabalho e considera os SLOs dos componentes. |
| Indicador do 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. |
| Contrato de nível de serviço (SLA) | Um contrato entre o provedor de serviços e o cliente do serviço. O contrato define os SLOs. O descumprimento do contrato pode ter consequências financeiras para o provedor de serviços. |
| Tempo médio de recuperação (MTTR) | O tempo necessário para restaurar um componente depois da detecção de uma falha. |
| Tempo médio entre falhas (MTBF) | A duração na qual a carga de trabalho pode realizar a função esperada, sem interrupção, até que ela falhe. |
| Objetivo do tempo de recuperação (RTO) | O tempo máximo aceitável em que um aplicativo pode permanecer indisponível após um incidente. |
| Objetivo do ponto de recuperação (RPO) | A duração máxima aceitável da perda de dados durante um incidente. |
Defina os valores desejados da carga de trabalho para essas métricas no contexto dos fluxos de usuário e sistema. Identifique e classifique esses fluxos de acordo com o quão críticos eles são para seus requisitos. Use os valores para orientar o design da carga de trabalho em termos de arquitetura, revisão, teste e operações de gerenciamento de incidentes. O descumprimento das metas vai afetar os negócios além do nível de tolerância.
Estratégias-chave de design
As discussões técnicas não devem determinar como você define metas de confiabilidade para os fluxos críticos. Em vez disso, os stakeholders de negócios devem se concentrar nos requisitos e nas expectativas dos usuários finais da carga de trabalho. Os especialistas técnicos ajudam os stakeholders a atribuir valores numéricos realistas que atendam a esses requisitos. Por meio da troca de informações, especialistas técnicos permitem a discussão e o acordo sobre SLOs viáveis.
Leve em consideração 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 regular acarrete em uma perda de X dólares em receita mensal. Esse valor em dólares é comparado com o custo estimado do design de um fluxo que tenha um SLO com disponibilidade de 99,95%, em vez de 99,9%. Os tomadores de decisão devem debater se o risco dessa perda de receita supera os custos adicionais e a carga de gerenciamento necessária para se proteger dela.
Siga esse padrão ao examinar os fluxos e compilar uma lista completa de metas.
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.
Entre os requisitos de confiabilidade e recuperação de mais alto nível e as métricas correlacionadas podem estar, por exemplo, uma disponibilidade de aplicativo de 99,9% para todas as regiões ou um RTO desejado de cinco horas para a região das Américas. A definição desses tipos de metas ajuda a identificar quais fluxos críticos estão envolvidos nessas metas. Em seguida, você pode levar em consideração metas no nível de componente.
Métricas de disponibilidade
As metas de disponibilidade correspondem às métricas de SLO, SLA e SLI.
SLOs e SLAs
As métricas de disponibilidade estão correlacionadas a 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 uma hora por mês. Para garantir que você possa atingir a meta de SLO, revise os SLAs da Microsoft de cada componente.
Para estabelecer os SLOs, pense em:
Requisitos não funcionais da carga de trabalho (por exemplo, taxas de solicitação de pico, usuários simultâneos) nos próximos de um a dois anos.
Métricas disponíveis sobre o que você pode avaliar por um período específico. Esses dados vão informar quais SLIs especificar.
Depois de reunir os SLAs dos componentes da 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 diversos fatores, dependendo do design da arquitetura.
A definição de SLOs indicados demanda tempo e uma consideração cuidadosa. Os stakeholders do negócio devem compreender a tolerância à confiabilidade. Esses comentários devem informar as metas.
Valores de SLA
A tabela a seguir define os valores de SLA em comum.
| SLA | Tempo de inatividade por semana | Tempo de inatividade por mês | Tempo de inatividade por ano |
|---|---|---|---|
| 99% | 1.68 horas | 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 minutos | 4.32 minutos | 52.56 minutos |
| 99,999% | 6 segundos | 25.9 segundos | 5.26 minutos |
Quando você pensar em SLAs compostos no contexto dos fluxos de usuário e sistema, lembre-se de que fluxos de usuário e sistema diferentes têm diferentes definições de gravidade. Leve em consideração essas diferenças ao compilar os SLAs compostos. Os fluxos não críticos podem ter componentes que você deve omitir dos cálculos porque eles não afetarão a experiência do cliente se estiverem indisponíveis brevemente.
SLIs
Pense em SLIs como métricas no nível do componente que favorecem um SLO. Os SLIs mais significativos são aqueles que afetam os fluxos críticos da perspectiva dos clientes. Para muitos fluxos, 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
As metas de recuperação correspondem às métricas de RTO, RPO, MTTR e MTBF. Diferentemente das metas de disponibilidade, as metas de recuperação para essas medições não dependem muito dos SLAs da Microsoft. A Microsoft só publica garantias de RTO e RPO para alguns produtos, como o Banco de Dados SQL.
As definições de metas de recuperação realistas dependem da análise do modo de falha e dos planos e testes da continuidade de negócios e da recuperação de desastre. Antes de terminar esse trabalho, debata as metas desejadas com os stakeholders e se certifique de que o design de arquitetura dá suporte às metas de recuperação da melhor maneira possível. Informe claramente aos stakeholders que todas as partes da carga de trabalho que não foram completamente testadas em relação às métricas de recuperação não devem ter SLAs garantidos. Certifique-se de que os stakeholders compreendam que as metas de recuperação podem mudar com o passar do tempo à medida que as cargas de trabalho são atualizadas. A carga de trabalho pode ficar mais complexa à medida que você adota novas tecnologias para melhorar a experiência do usuário. Essas alterações podem aumentar ou diminuir as métricas de recuperação.
Observação
Pode ser difícil de definir e garantir o MTBF. As plataformas como serviço (PaaS) ou o software como serviço (SaaS) podem falhar e se recuperar sem nenhuma notificação do provedor de nuvem, e o processo pode ser completamente transparente para você. Se você definir metas para essa métrica, aborde apenas os componentes que estejam sob controle.
Compilação de um modelo de integridade
Use os dados coletados para das metas de confiabilidade para compilar o modelo de integridade para cada carga de trabalho e fluxos críticos associados. Um modelo de integridade define os estados íntegro, degradado e não íntegro* para os fluxos e as cargas de trabalho. Os estados garantem a priorização operacional indicada. Este 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 maneira como você define os estados íntegro, degradado e não íntegro depende das metas de confiabilidade. Aqui estão alguns exemplos de como convém definir os estados:
Um estado verde ou íntegro indica que os principais requisitos e metas não funcionais estão totalmente atendidos e que os recursos são usados de maneira ideal.
Um estado amarelo ou degradado indica que um ou mais componentes do fluxo estão emitindo um alerta para o limite definido, embora o fluxo esteja 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 igualmente. O modelo de saúde deve distinguir entre falhas transitórias e não transitórias . Ele deve distinguir claramente falhas transitórias esperadas, mas recuperáveis, de um estado verdadeiramente de desastre.
Esse modelo funciona usando uma estratégia de monitoramento e alerta desenvolvida e operada com base nos princípios da melhoria contínua. À medida que as cargas de trabalho evoluem, os modelos de integridade devem evoluir com elas.
Para obter diretrizes detalhadas sobre configurações de monitoramento e alerta, consulte o guia do monitoramento de integridade.
Visualização
Para manter as equipes de operações e stakeholders da carga de trabalho informados do status em tempo real e das tendências gerais do modelo de integridade da carga de trabalho, leve em consideração a criação de painéis na solução de monitoramento. Debata soluções de visualização com os stakeholders para garantir que você dê as informações valorizadas por eles e que sejam fáceis de consumir. Também é possível que eles queiram consultar os relatórios gerados semanal, mensal ou trimestralmente.
Facilitação do Power Platform
Os SLAs do Power Platform 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 Power Platform inclui procedimentos para obter um crédito de serviço caso o SLA não seja atendido, além das definições de disponibilidade para cada serviço. Esse aspecto do SLA funciona como uma política de imposição.
O Microsoft Business Applications oferece capacidades de continuidade dos negócios e recuperação de desastres (BCDR) para todos os ambientes do tipo de produção no Dynamics 365 e aplicativos SAAS do Power Platform. Saiba como Microsoft garante que seus dados de produção sejam resilientes durante interrupções regionais.
Alinhamento organizacional
O Cloud Adoption Framework dá diretrizes para recomendações de SLOs e SLIs relacionados ao monitoramento em toda a organização.
Para obter mais informações, consulte SLOs de monitoramento de nuvem.
Lista de verificação de confiabilidade
Consulte o conjunto completo de recomendações.