Recomendações para definir metas de confiabilidade
Aplica-se a esta recomendação da 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 a serem negociadas, obtenha consenso, defina expectativas e impulsione 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 métricas de destino de disponibilidade e recuperação para cargas de trabalho e fluxos críticos. Você deve derivar metas de confiabilidade de exercícios de workshop com as partes interessadas do negócio. Em seguida, refine essas metas monitorando e testando suas cargas de trabalho.
Defina expectativas realistas com suas partes interessadas internas sobre a confiabilidade da carga de trabalho. Em seguida, eles podem usar acordos contratuais para comunicar essas expectativas aos clientes. 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 maneira ideal às metas com as quais concorda.
Considere usar as métricas a seguir para quantificar seus requisitos de negócios.
| Termo | Definição |
|---|---|
| SLO (objetivo de nível de serviço) | Uma medida do desempenho e da confiabilidade de uma carga de trabalho ou aplicativo. Um SLO é uma meta específica e mensurável que você define para interações específicas com o cliente. É uma meta que você define para sua carga de trabalho ou aplicativo com base na qualidade do serviço que seus clientes esperam receber. |
| Indicador de nível de serviço (SLI) | Uma medida quantitativa de um aspecto específico do desempenho de um serviço. Você pode usar um SLI para medir a conformidade da carga de trabalho com um SLO. |
| SLA (Contrato de Nível de Serviço) | Um acordo contratual entre o provedor de serviços e o cliente do serviço. O não cumprimento do acordo pode ter consequências financeiras para o provedor 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. |
Principais estratégias de design
As metas de confiabilidade representam a meta de qualidade desejada de uma carga de trabalho, conforme prometido a seus usuários e às partes interessadas do negócio. Essa meta inclui disponibilidade e capacidade de recuperação da carga de trabalho. Lembre-se de que as metas de confiabilidade diferem das metas de desempenho, mas você deve incluir metas de desempenho nas metas de confiabilidade. Considere as seguintes metas de confiabilidade:
As metas de disponibilidade definem os padrões de qualidade para que um sistema permaneça acessível e funcional. Se não atender a esses padrões, o sistema será considerado não confiável. Use SLOs para ajudar a verificar se o sistema atende a esses padrões. As partes interessadas técnicas e de negócios colaboram para definir SLOs realistas e considerar fatores como análise comparativa, experiência do usuário e perfil de carga de trabalho.
As metas de correção garantem que a carga de trabalho execute corretamente suas funções com qualidade consistente. Para medir a correção, quantifique os indicadores da carga de trabalho para que você possa combiná-los em uma pontuação unificada e objetiva.
As metas de recuperação correspondem às métricas RTO, RPO, MTTR e MTBF, que quantificam a eficácia de seus planos e testes para continuidade dos negócios e recuperação de desastres.
Para definir metas de confiabilidade, as partes interessadas do negócio definem requisitos amplos. Em seguida, os especialistas técnicos avaliam o estado atual da carga de trabalho e trabalham para atingir e manter as metas por meio de monitoramento e alertas. Ambas as partes devem concordar com metas realistas.
Identifique e pontue os fluxos de usuários e sistemas com base em sua importância para seus requisitos de negócios. Use essas pontuações para orientar o design, a revisão, o teste e o gerenciamento de incidentes de sua carga de trabalho. Defina metas de confiabilidade para esses fluxos e entenda que não atingir essas metas pode afetar significativamente seus negócios.
Compensação: você pode ter uma lacuna entre os limites técnicos do seu sistema e seu impacto nos negócios, como taxa de transferência versus transações por segundo. Preencher essa lacuna pode ser difícil. Busque uma solução prática e econômica em vez de excesso de engenharia.
Definir objetivos de disponibilidade
O SLO geral de uma carga de trabalho reflete a qualidade holística, incluindo todas as suas dependências. Uma declaração madura do SLO deve indicar a meta geral de negócios para essa carga de trabalho, não apenas uma combinação dessas dependências. Por exemplo, se os clientes esperam 99,99% de disponibilidade, o SLO geral deve ter como objetivo atingir essa meta, mesmo que uma parte atinja apenas 99,80%.
As partes interessadas avaliam a experiência do cliente e consideram como o tempo de inatividade afeta a receita. Eles comparam essa perda com o custo de projetar e operar o fluxo de negócios. Os tomadores de decisão decidem se devem gastar mais dinheiro em confiabilidade para evitar perda de receita e manter sua reputação.
Os proprietários da carga de trabalho usam metas financeiras para determinar objetivos. Os requisitos de negócios são mapeados para métricas mensuráveis. O objetivo é identificar um conjunto de fatores que influenciam a qualidade da experiência do cliente.
Os arquitetos de carga de trabalho tomam muitas decisões técnicas com base em SLOs. Os SLOs podem:
Servir como entrada crítica em decisões de arquitetura ao considerar outras dependências.
Forneça uma visão quase em tempo real e uma compreensão compartilhada da integridade de uma carga de trabalho para permitir discussões objetivas. Eles também ajudam a equipe de carga de trabalho a priorizar esforços para melhorar a confiabilidade e desenvolver novos recursos.
Atue como um sinal primário para operações de implantação, o que impulsiona a reversão automatizada se ocorrerem problemas e fornece validação de que as alterações alcançam as melhorias esperadas na experiência do cliente.
Acelere a correção e a recuperação concentrando-se nos objetivos, impulsione a notificação automatizada de problemas aos clientes e crie confiança entre as equipes em sua organização.
Importante
Você deve saber a diferença entre SLAs e SLOs. Embora SLAs e SLOs possam usar ou até mesmo apresentar dados semelhantes, sua intenção é diferente. Um SLA é um contrato formal entre uma organização e seus clientes e tem implicações financeiras e legais diretas se a organização não cumprir sua promessa. As organizações usam SLOs para avaliar se o tempo de inatividade potencial está dentro dos limites toleráveis.
SLOs e SLAs compartilham um relacionamento comercial e devem ser controlados de forma independente. Se o SLA servir como uma tática de negócios, a organização poderá defini-lo intencionalmente como um valor alto com base nas metas do proprietário da empresa. Por outro lado, os SLOs podem ser maiores. Considere as cargas de trabalho críticas como exemplo. Essa classe de carga de trabalho não pode arcar com longos períodos de inatividade porque os efeitos, incluindo perdas financeiras e até ameaças à segurança humana, são significativos. Portanto, os SLOs normalmente visam 99,999% de tempo de atividade, comumente chamados de cinco noves. Se os SLOs não atingirem essas metas, as organizações deverão reagir rapidamente para mitigar falhas e evitar os resultados de um SLA com falha.
O exemplo neste artigo define um SLA alto para dar suporte a metas de negócios.
Os provedores de plataforma e tecnologia em nuvem publicam SLAs em suas ofertas. Você deve considerar os SLAs como parte do cálculo do SLO, mas não deve usá-los como estão sem entender o escopo de cobertura do SLA. Para obter mais informações, consulte Avaliar o impacto dos SLAs da Microsoft.
Considere SLOs comuns e fatores de influência
Cada SLO tem como alvo um critério de qualidade específico. Considere estes SLOs comuns para confiabilidade. Essa lista não é completa. Adicione SLOs com base em seus requisitos de negócios.
A taxa de sucesso mede o sucesso de solicitações e processos em relação àqueles que retornam um erro ou falham em sua tarefa.
A latência mede o tempo entre o momento em que uma solicitação de uma operação é iniciada e o momento em que o resultado está disponível ou o processo é concluído.
A capacidade mede o uso simultâneo, como o número de respostas baseadas em limitação.
A disponibilidade mede o tempo de atividade da perspectiva dos clientes.
A taxa de transferência mede a taxa mínima de transferência de dados durante um determinado período de tempo. A taxa de transferência é medida como uma unidade de taxa de dados, como transações por segundo (TPS) ou solicitações por segundo (RPS).
Entenda os cenários e as tolerâncias para sua carga de trabalho no Azure. Os serviços do Azure e os componentes do aplicativo afetam o SLO da carga de trabalho. Combine as respostas da tabela a seguir para derivar o SLO geral. Use essas perguntas como exemplos para avaliar a utilidade do componente de carga de trabalho.
| Características do componente | Interação do cliente | Outros fatores |
|---|---|---|
| - Ele expõe APIs de solicitação ou resposta? - Tem APIs de consulta? - É um componente de computação ? - É um componente de processamento de trabalho? |
- Acesso ao painel de controle e ao plano de gerenciamento para serviços do Azure voltados para o público. - Acesso ao plano de dados, por exemplo, operações CRUD (criar, ler, atualizar e excluir). |
- Seu processo de liberação envolve tempo de inatividade? - Qual é a probabilidade de introduzir bugs? Se a carga de trabalho se integrar a outros sistemas, talvez seja necessário considerar bugs de integração. - Como as operações de rotina, como aplicação de patches, afetam a meta de disponibilidade? Você considerou as dependências do parceiro? - Sua equipe é suficiente para suportar a rotação constante de emergência e backup de emergência? - O aplicativo tem vizinhos barulhentos fora do seu escopo de controle que podem causar interrupções? |
Determinar o escopo do SLO
Você pode definir SLOs em vários níveis, como para cada aplicativo, carga de trabalho ou um fluxo específico, em seu sistema. Defina SLOs específicos de nível para que você possa personalizar SLOs com base na importância de cada componente.
Em soluções de software como serviço (SaaS), meça os SLOs por cliente para otimizar a experiência de cada cliente. Os clientes podem ter diferentes recursos de infraestrutura em seus segmentos. Nesses casos, um SLO em todo o sistema que agrega todos os recursos em segmentos de clientes pode não fazer sentido. Em vez disso, meça os SLOs que se alinham ao contexto específico de cada cliente. Para obter mais informações, consulte Modelos de locação para uma solução multilocatário.
Definir metas de SLO compostas
Os SLOs devem ser mensuráveis e medidos dentro de uma janela de observabilidade.
Os SLOs geralmente são porcentagens como 99,90%, mas também podem ser declarações. Use os dois métodos para obter um valor numérico que inclua todos os fatores.
Um SLO consiste em SLIs mensuráveis que definem fatores aceitáveis. SLIs são métricas com um limite definido que pode ser alertado. Você pode coletá-los de uma plataforma ou aplicativo. Diferentes componentes emitem SLIs relevantes. Ao escolher SLIs, considere os fatores que influenciam o SLO.
Por exemplo, para calcular o SLO de um fluxo que usa uma API de resposta e solicitação, meça a latência do servidor e o tempo de processamento da solicitação. A taxa de transferência e as taxas de erro não se aplicam a ambientes de computação contínua, como VMs (máquinas virtuais), conjuntos de dimensionamento ou Lote do Azure.
Para acesso ao painel de controle, considere as taxas de erro e a latência para respostas de API e operações de longa execução, como criação de recursos. O acesso ao plano de dados depende das APIs usadas, cada uma com seus próprios destinos de SLO.
Um bom SLI mostra quando você pode violar um SLO. Geralmente é medido em percentis. Aqui estão alguns percentis comumente usados e o tempo estimado de não conformidade com a disponibilidade esperada.
| Objetivo | Não conformidade por semana | Não conformidade por mês | Não conformidade por ano |
|---|---|---|---|
| 99% | 1,68 hora | 7.20 horas | 3,65 dias |
| 99,90% | 10.10 minutos | 43.20 minutos | 8,76 horas |
| 99,95% | 5 minutos | 21.60 minutos | 4,38 horas |
| 99,99% | 1,01 minuto | 4,32 minutos | 52,56 minutos |
| 99,999% | 6 segundos | 25,90 segundos | 5,26 minutos |
Importante
Um valor de SLO composto é uma distribuição de produto dos fatores contribuintes.
Um exemplo de SLO composto é 99,95% × 99,99999% = ~99,95%.
Ao criar SLOs compostos para fluxos diferentes, considere sua criticidade e relevância variadas. Os fluxos podem ter componentes que você considera não críticos e omitir de seus cálculos. Você pode justificar sua omissão com base no fato de sua breve indisponibilidade afetar a experiência do cliente. Em alguns casos, um componente pode não ser relevante para o caso de uso que você considera para o SLO. Você também pode omitir esses componentes do cálculo.
O mesmo princípio se aplica às operações. Certas operações podem introduzir riscos ou afetar o SLO, e outras são insignificantes. A decisão deve ser explícita e baseada em consenso.
Para obter um exemplo ilustrativo de como definir e medir SLOs e SLIs, consulte a seção Exemplo .
Avalie o impacto dos SLAs da Microsoft
Um SLA da Microsoft fornece informações sobre a disponibilidade de áreas com as quais a Microsoft se compromete. Os SLAs não garantem uma oferta como um todo. Ao avaliar SLAs, tenha uma boa compreensão da cobertura fornecida em torno do percentil publicado.
Considere os Aplicativos Web, um recurso do Serviço de Aplicativo do Azure. O recurso é considerado disponível quando retorna um status 200 OK em um determinado caso de uso. Dentro desse contexto e prazo específicos, ele não cobre uma garantia com suporte financeiro sobre a disponibilidade de recursos como Easy Auth ou troca de slot. Você deve considerar áreas que não são mencionadas explicitamente no contrato como disponíveis pelo melhor esforço da plataforma.
Portanto, se sua carga de trabalho depender de slots de implantação, você não poderá derivar seu SLO apenas do SLA do Serviço de Aplicativo. Como uma equipe de carga de trabalho, você precisa proteger e prever a disponibilidade do tempo de atividade. No entanto, essa previsão pode ser incerta, e é por isso que vincular seu SLO ao SLA da plataforma pode ser problemático.
Considere outro exemplo. Se o Azure Front Door tiver 99,99% de disponibilidade, seu design deverá aderir a critérios específicos publicados no contrato. Por exemplo, seu back-end deve incluir armazenamento, você precisa de uma GET operação que possa recuperar um arquivo de pelo menos 50 KB de tamanho e precisa implantar agentes em vários locais em pelo menos cinco locais geograficamente diversos. Esse caso de uso restrito do Azure Front Door não garante recursos como cache, regras de roteamento ou um firewall de aplicativo Web. Esses aspectos estão fora do escopo do SLA.
Implementar destinos multirregionais
Do ponto de vista da confiabilidade, a implantação multirregional é uma implementação do princípio de redundância. O objetivo é mitigar o risco de uma interrupção regional ou desempenho degradado. Essa estratégia, quando projetada corretamente, pode melhorar os SLOs porque adiciona uma região secundária para fins de failover.
Existem dois casos de uso principais:
Padrão de alta disponibilidade, no qual você distribui uma carga entre regiões para obter mais capacidade. A alta disponibilidade não restringe os usuários da carga de trabalho a uma região, e o desempenho de todo o sistema contribui para o SLO.
Padrão de bulkhead, no qual você restringe os clientes a regiões específicas para segmentá-los. Nesses casos, trate as implantações multirregionais como implantações separadas, ou selos, em cada região. Meça a integridade de cada carimbo separadamente, com os SLIs apropriados à sua carga de trabalho. Considere o SLO da carga de trabalho geral com base na integridade de cada selo. Se você puder fazer failover entre carimbos, o SLO geral da carga de trabalho será maior porque uma falha em um carimbo pode ser recuperada por meio de um failover para outro carimbo.
Preste atenção em quanta redundância você precisa para atender a SLOs altos. Por exemplo, a Microsoft garante SLAs mais altos para implantações multirregionais do Azure Cosmos DB do que garante para implantações de região única.
Definir métricas de recuperação
As definições para metas de recuperação realistas, como métricas de RTO, RPO, MTTR e MTBF, 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. Ao definir esses destinos, considere as garantias de recuperação fornecidas pela plataforma. A Microsoft publica garantias de RTO e RPO apenas para alguns produtos, como o Banco de Dados SQL do Azure.
Antes de concluir este trabalho, discuta as metas aspiracionais com as partes interessadas e certifique-se de que o design da 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 completamente 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 você adiciona clientes ou 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 difícil de definir e garantir. Os modelos de plataforma como serviço (PaaS) ou SaaS podem falhar e se recuperar sem qualquer notificação do provedor de nuvem, e o processo pode ser totalmente transparente para você ou seus clientes. Se você definir metas para essa métrica, cubra apenas os componentes que estão sob seu controle.
Ao definir destinos de recuperação, defina limites para iniciar uma recuperação. Por exemplo, se um nó da Web estiver indisponível por mais de cinco minutos, adicione automaticamente um novo nó ao pool. Defina limites para todos os componentes e considere 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, como perda de dados ou interrupções de sessão para os clientes, das operações de recuperação.
Monitore e visualize os alvos
Use os dados coletados para suas metas de confiabilidade para criar seu modelo de integridade para cada carga de trabalho e os fluxos críticos associados. Um modelo de integridade define estados íntegros, degradados e não íntegros para os fluxos e cargas de trabalho. Quando o estado muda, o modelo deve alertar as partes responsáveis. Para obter considerações e recomendações detalhadas de design, consulte Diretrizes de modelagem de integridade.
Para manter suas equipes de operações e partes interessadas da carga de trabalho informadas, crie uma visualização que reflita o status em tempo real e as tendências gerais do modelo de integridade da carga de trabalho. Discuta soluções de visualização com as partes interessadas para garantir que você forneça informações que elas valorizem e que sejam fáceis de consumir. Eles também podem querer ver os relatórios gerados semanalmente, mensalmente ou trimestralmente.
Facilitação do Azure
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, os produtos dentro de um serviço têm SLAs diferentes. Para obter mais informações, consulte SLAs para serviços online.
O SLA do Azure inclui procedimentos para obter um crédito de serviço se sua carga de trabalho não atender ao SLA, juntamente com definições de disponibilidade para cada serviço. Esse aspecto do SLA atua como uma política de imposição.
Explore os painéis do Azure Monitor para seu sistema de visualização.
Exemplo
A Contoso, Ltd. está projetando uma nova experiência móvel para seu sistema de emissão de ingressos para eventos. Aqui está a arquitetura de alto nível.
O logotipo Grafana é uma marca comercial da sua respectiva empresa. Nenhum endosso é implícito pelo uso dessa marca.
Componentes
Aqui estão alguns componentes que ilustram o conceito de definição de SLO. Há componentes nessa arquitetura que não estão incluídos na lista a seguir. Por exemplo, embora o Key Vault faça parte do fluxo de solicitação crítica, ele não faz parte do caso de uso de resposta. Se o Key Vault não estiver disponível, o aplicativo continuará a funcionar usando segredos carregados durante a inicialização. No entanto, se o aplicativo precisar ser dimensionado, a disponibilidade do Key Vault se tornará crítica porque novos nós precisam ser carregados com segredos. Neste exemplo, as operações de dimensionamento não são consideradas. Outros componentes são omitidos por questões de brevidade.
O Azure Front Door é o único ponto de entrada que expõe uma API que os clientes usam para enviar solicitações.
Os Aplicativos de Contêiner do Azure são o ambiente que a equipe de carga de trabalho possui e usa para executar a lógica de negócios do aplicativo.
A Instância Gerenciada de SQL pertence e é gerenciada por outra equipe e é uma dependência crítica da carga de trabalho.
O Link Privado do Azure fornece conectividade privada entre as implantações do Azure Front Door e dos Aplicativos de Contêiner. A Instância Gerenciada de SQL também é exposta ao aplicativo por meio de um ponto de extremidade privado.
Nessa arquitetura, a equipe de API define um destino de SLO inicial para fluxos críticos no aplicativo. Eles adotam a estratégia descrita em Fatores que influenciam os SLOs. Eles visam definir objetivos que cubram a funcionalidade principal sem enfatizar excessivamente os recursos complementares. Eles medem a integridade de três fluxos de usuários críticos, que envolvem todas as principais funcionalidades da nuvem e executam código em implantações. No entanto, esses fluxos não abrangem todo o código ou acesso a dados. Aqui estão os fatores de influência.
Calcular um SLO composto
SLO de disponibilidade do Azure: o SLA de compromisso financeiro do Azure serve como um proxy para avaliar a confiabilidade da plataforma.
Componente do Azure Cobertura de SLA aplicável Não coberto pelo SLA SLO ajustado Porta da frente do Azure 99,99% para operações HTTP GETbem-sucedidasCache, mecanismo de regras 99.98% Aplicativos de Contêiner 99,95% com base em aplicativos implantados que podem ser acessados pela entrada interna Escalonamento automático, recursos de armazenamento de tokens 99.95% Instância Gerenciada de SQL 99,99% com base na conexão com a instância do SQL Server Desempenho, retenção de dados 99,80% Link privado 99,99% com base em minutos inteiros quando a rede de endpoint privado não aceitou tráfego ou quando o tráfego não fluiu entre o endpoint e o serviço de Link Privado Falhas individuais com duração inferior a um minuto 99,99% O ajuste é baseado em vários fatores que dependem da promessa da equipe de carga de trabalho aos seus objetivos. Um fator pode ser a confiança na capacidade da plataforma com base na experiência anterior. Por exemplo, para Aplicativos de Contêiner e Link Privado, a equipe se sente confortável em considerar o valor do SLA como está.
Existem também fatores diferenciados. Por exemplo, a equipe reduz o valor de SLO da Instância Gerenciada de SQL para 99,80% para levar em conta possíveis falhas em suas operações de dados, como alterações de esquema e backups.
A equipe define o SLO composto calculando o impacto dos valores individuais de SLO ajustados. Este valor é de 99,72%.
Existem outros fatores contribuintes. A arquitetura depende de componentes de rede do Azure, como redes virtuais e NSGs (grupos de segurança de rede) que não têm um SLA publicado. A equipe de carga de trabalho decide considerar esses fatores com 99,99% de disponibilidade para cada componente.
Um SLO composto com base na disponibilidade prevista da plataforma: 99,68% ao mês.
SLO do código do aplicativo: a equipe reconhece que bugs no código do aplicativo ou nos procedimentos armazenados podem afetar a disponibilidade do sistema e alocam uma hora de inatividade mensal para contabilizar erros relacionados ao código.
Eles usam percentis de tempo de inatividade comuns para estimar o SLO para fatores individuais, como defeitos de código, problemas de dimensionamento e outras considerações relacionadas ao código.
Um SLO composto baseado em código e disponibilidade de dados: 99,86% ao mês.
SLO de configuração de recursos e aplicativos: a equipe reconhece que os recursos de nuvem e o código do aplicativo devem ser configurados corretamente. Esse destino inclui a configuração de regras de dimensionamento automático, a implantação de regras de NSG e a seleção do tamanho correto de SKUs. Para contabilizar erros de configuração, eles reservam 10 minutos de tempo de inatividade mensal, o que representa cerca de 99,98% de disponibilidade.
Um SLO composto com base na disponibilidade de configuração: 99,95% ao mês.
SLO de operações: a equipe de carga de trabalho desenvolve uma boa cultura de DevOps seguindo os princípios do Well-Architected Framework para excelência operacional. Eles implantam recursos de nuvem, configuração e código a cada sprint.
A equipe considera as implantações um risco porque podem desestabilizar um sistema em execução. Pode haver erros como resultado de atualizações de certificado TLS, alterações de DNS ou erros de ferramenta. A equipe também considera o tempo de inatividade potencial causado por correções de emergência. Eles planejam um total de 20 minutos de inatividade mensal, o que representa aproximadamente 99,95% de disponibilidade.
As janelas de manutenção são períodos de tempo designados durante os quais ocorrem manutenção ou atualizações do sistema. A API não é usada por aproximadamente quatro horas por dia. Para reduzir o risco de indisponibilidade, a equipe pode agendar tarefas de manutenção durante essas horas menos ativas. Essa abordagem leva a um SLO mais alto, mas a equipe decide não incluir a janela de manutenção como parte de seu SLO.
Um SLO composto com base na disponibilidade das operações: 99,95% ao mês.
SLO de dependências externas: a equipe considera a Instância Gerenciada de SQL como a dependência primária, que já tem uma disponibilidade de 99,80% contabilizada na disponibilidade geral da plataforma. Nenhuma outra dependência externa é considerada.
Um SLO composto baseado em dependências externas: não aplicável.
Determinar o resultado geral do SLO composto
A meta geral de SLO composto é definida em 99,45%, o que equivale a aproximadamente quatro horas de inatividade por mês.
Para atender à meta de SLO de apenas quatro horas de indisponibilidade por mês, a equipe de carga de trabalho estabelece uma rotação de plantão. O suporte ao cliente e o monitoramento de transações sintéticas podem invocar o suporte de SRE (engenharia de confiabilidade do site) de plantão para iniciar imediatamente as etapas de recuperação para resolver problemas de SLO.
Definir o SLA da carga de trabalho
O SLA para a carga de trabalho é de 99,90% de disponibilidade por mês.
Os departamentos jurídico e financeiro da equipe de carga de trabalho definem o SLA para a carga de trabalho em 99,90% de disponibilidade por mês, o que excede a meta de SLO de 99,45%. Eles tomam essa decisão depois de analisar os pagamentos financeiros versus o crescimento projetado do cliente com base em um SLA atraente. O SLA abrange dois fluxos de usuário principais e inclui considerações de desempenho, não apenas disponibilidade. É um risco calculado assumido pela equipe de negócios para beneficiar o negócio, e a equipe de engenharia está ciente do compromisso.
Definir o SLO de exatidão
Os principais fluxos de usuário do aplicativo devem estar disponíveis e responsivos de forma utilizável ou até competitiva. A equipe define um SLO de tempo de resposta especificamente para a API, excluindo o tempo de processamento do cliente e a travessia da rede da Internet. Eles avaliam esse SLO somente durante os períodos de disponibilidade. Eles escolhem o 75º percentil como a meta de SLO e a medição de desempenho, que captura a experiência típica do cliente e exclui os piores cenários.
Links relacionados
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.