Recomendações para a definição de objetivos de fiabilidade
Aplica-se a esta recomendação da lista de verificação de Fiabilidade do Azure Well-Architected Framework:
| RE:04 | Defina 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 impulsionar 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 os 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. Você deve derivar metas de confiabilidade de exercícios de workshop com partes interessadas do negócio. Em seguida, refine essas metas monitorando e testando suas cargas de trabalho.
Defina expectativas realistas com as 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 forma ideal às metas acordadas.
Considere usar as métricas a seguir para quantificar seus 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 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 medição quantitativa de um aspeto particular do desempenho de um serviço. Você pode usar um SLI para medir a conformidade da sua carga de trabalho com um SLO. |
| Contrato de nível de serviço (SLA) | Um acordo contratual entre o prestador de serviços e o cliente do serviço. O incumprimento do acordo pode ter consequências financeiras para o prestador de serviços. |
| Tempo médio de recuperação (MTTR) | O tempo necessário para restaurar um componente após uma falha é detetado. |
| 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. |
| Objetivo de tempo de recuperação (RTO) | O tempo máximo aceitável que um aplicativo pode ficar indisponível após um incidente. |
| Objetivo de ponto de recuperação (RPO) | A duração máxima aceitável da perda de dados durante um incidente. |
Principais estratégias de design
As metas de confiabilidade representam o objetivo de qualidade desejado de uma carga de trabalho, conforme prometido aos seus usuários e às partes interessadas do negócio. Esse objetivo inclui a disponibilidade e a 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 as 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 é considerado não confiável. Use SLOs para ajudar a verificar se seu 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 adequadamente 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 de negócios e recuperação de desastres.
Para definir metas de confiabilidade, as partes interessadas do negócio definem requisitos amplos. Em seguida, os peritos técnicos avaliam o estado atual da carga de trabalho e trabalham no sentido de alcançar e manter as metas através de monitorização e alertas. Ambas as partes devem chegar a acordo sobre objetivos realistas.
Identifique e classifique os fluxos de usuários e sistemas com base em sua importância para os requisitos do seu negócio. Use essas pontuações para orientar o design, a revisão, os testes e o gerenciamento de incidentes de sua carga de trabalho. Defina metas de confiabilidade para esses fluxos e entenda que o não cumprimento dessas 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. Colmatar esta lacuna pode ser difícil. Procure uma solução prática e económica em vez de uma engenharia excessiva.
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 o objetivo comercial geral para essa carga de trabalho, não apenas uma composição dessas dependências. Por exemplo, se os clientes esperam 99,99% de disponibilidade, o SLO geral deve visar esse objetivo, 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 então se devem gastar mais dinheiro em confiabilidade para evitar a 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:
Sirva como entrada crítica para decisões de arquitetura quando você 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.
Atua como um sinal primário para as operações de implantação, o que impulsiona a reversão automatizada se ocorrerem problemas e fornece a validação de que as alterações alcançam as melhorias esperadas para a experiência do cliente.
Acelere a remediação e a recuperação concentrando-se nos objetivos, direcione a notificação automatizada de problemas aos clientes e crie confiança entre as equipes da 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 uma relação comercial e devem ser controlados de forma independente. Se o SLA servir como uma tática de negócios, a organização pode intencionalmente defini-lo para um alto valor com base nos objetivos do proprietário do negócio. Por outro lado, os SLOs podem ser maiores. Considere cargas de trabalho de missão crítica como um exemplo. Essa classe de carga de trabalho não pode suportar 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 referido como os cinco nove. Se os SLOs não atingirem essas metas, as organizações devem reagir rapidamente para mitigar falhas e evitar os resultados de um SLA falhado.
O exemplo neste artigo define um SLA alto para dar suporte às 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á sem entender o escopo de cobertura do SLA. Para obter mais informações, consulte Avaliar o impacto dos SLAs da Microsoft.
Considerar SLOs comuns e fatores de influência
Cada SLO tem como alvo um critério de qualidade específico. Considere esses SLOs comuns para confiabilidade. Esta lista não é exaustiva. 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 quando uma solicitação para uma operação é iniciada e quando 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 do ponto de vista 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 dos componentes | Interação do cliente | Outros fatores |
|---|---|---|
| - Expõe APIs de solicitação ou resposta? - Tem APIs de consulta? - É um componente de computação? - É um componente de processamento de trabalho? |
- Controle o acesso ao plano e ao plano de gerenciamento para serviços do Azure voltados para o público. - Acesso ao plano de dados, por exemplo, operações de criação, leitura, atualização e exclusão (CRUD). |
- Seu processo de liberação envolve tempo de inatividade? - Qual é a probabilidade de introduzir bugs? Se a carga de trabalho se integrar com outros sistemas, talvez seja necessário considerar bugs de integração. - Como operações de rotina, como patching, afetam a meta de disponibilidade? Já levou em conta as dependências dos parceiros? - Sua equipe é suficiente para suportar a constante rotação de emergência e backup de emergência em permanê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 SLOs por cliente para otimizar a experiência de cada cliente. Os clientes podem ter diferentes recursos de infraestrutura em seus segmentos. Para esses 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 SLOs que se alinham com o 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.
SLOs são muitas vezes percentuais como 99,90%, mas também podem ser declarações. Use ambos os 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. Pode recolhê-los a partir de uma plataforma ou de uma aplicação. Diferentes componentes emitem SLIs relevantes. Ao escolher SLIs, considere os fatores que influenciam o SLO.
Por exemplo, para calcular o SLO para 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 máquinas virtuais (VMs), conjuntos de escala ou Azure Batch.
Para acesso ao plano de controle, considere as taxas de erro e a latência para respostas de API e operações de longa duração, como a criação de recursos. O acesso ao plano de dados depende das APIs usadas, cada uma com seus próprios destinos 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 | Incumprimento por mês | Incumprimento por ano |
|---|---|---|---|
| 99% | 1,68 horas | 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 minutos | 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 diferentes fluxos, considere sua criticidade e relevância variáveis. Os fluxos podem ter componentes que você considera não críticos e omitem de seus cálculos. Você pode justificar sua omissão com base em se sua breve indisponibilidade afeta 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. Algumas operações podem introduzir riscos ou afetar o SLO, e outras são insignificantes. A decisão deve ser explícita e assentar num consenso.
Para obter um exemplo ilustrativo de como definir e medir SLOs e SLIs, consulte a seção Exemplo .
Avaliar 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 período de tempo específicos, ele não cobre uma garantia financeiramente apoiada na disponibilidade de recursos como Easy Auth ou troca de slots. 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 somente do SLA do Serviço de Aplicativo. Como uma equipe de carga de trabalho, você precisa proteger e prever a disponibilidade de 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 aos 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 estreito do Azure Front Door não garante recursos como cache, regras de roteamento ou um firewall de aplicativo Web. Estes aspetos não se inserem no âmbito do SLA.
Implementar metas multirregionais
Do ponto de vista da confiabilidade, a implantação multirregional é uma implementação do princípio da 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 antepara, no qual você restringe os clientes a regiões específicas para segmentá-los. Nesses casos, trate as implantações de várias regiões como implantações separadas, ou carimbos, em cada região. Meça a integridade de cada carimbo separadamente, com os SLIs adequados à sua carga de trabalho. Considere o SLO da sua carga de trabalho geral com base na integridade de cada selo. Se você puder fazer failover entre carimbos, seu SLO de carga de trabalho geral será maior porque uma falha em um carimbo é recuperável por meio de um failover para outro carimbo.
Preste atenção à quantidade de redundância necessária para atender a SLOs 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.
Definir métricas de recuperação
As definições para metas de recuperação realistas, como métricas 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 essas metas, 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 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 forma 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 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.
Nota
MTBF pode ser difícil de definir e garantir. Os modelos de plataforma como serviço (PaaS) ou SaaS podem falhar e recuperar sem qualquer notificação do provedor de nuvem, e o processo pode ser completamente 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 metas 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 para um componente específico envolve, incluindo o efeito sobre 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 que você coleta 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 os responsáveis. Para obter considerações e recomendações detalhadas de projeto, 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 valorizam e que são 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, 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 aspeto 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 tíquetes de eventos. Aqui está a arquitetura de alto nível.
O logótipo Grafana é uma marca registada da respetiva empresa. O uso desta marca não implica qualquer endosso.
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 Cofre da Chave faça parte do fluxo de solicitação crítica, ele não faz parte do caso de uso de resposta. Se o Cofre da Chave não estiver disponível, o aplicativo continuará a funcionar usando segredos que são carregados durante a inicialização. No entanto, se o aplicativo precisar ser dimensionado, a disponibilidade do Cofre de Chaves 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 uma questão 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 SQL pertence e é gerenciada por outra equipe e é uma dependência crítica da carga de trabalho.
O Azure Private Link fornece conectividade privada entre implantações do Azure Front Door e Container Apps. A Instância Gerenciada SQL também é exposta ao aplicativo por meio de um ponto de extremidade privado.
Nessa arquitetura, a equipe de API define um destino 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 abrangem a funcionalidade principal sem enfatizar excessivamente os recursos suplementares. Eles medem a integridade de três fluxos críticos de usuários, que envolvem todas as principais funcionalidades de nuvem e executam código entre implantações. No entanto, esses fluxos não cobrem todo o código ou acesso a dados. Aqui estão os fatores que influenciam.
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 Azure Front Door 99,99% para operações HTTP GETbem-sucedidasCaching, mecanismo de regras 99.98% Aplicativos de contêiner 99,95% com base em aplicativos implantados que podem ser acessados pela entrada integrada Dimensionamento automático, recursos de armazenamento de tokens 99,95% Instância Gerida do SQL 99,99% com base na conexão com a instância do SQL Server Desempenho, retenção de dados 99.80% Private Link 99,99% com base em minutos inteiros quando a rede de ponto de extremidade privada não aceitou tráfego ou quando o tráfego não fluiu entre o ponto de extremidade e o serviço Private Link 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 Container Apps e Private Link, a equipe se sente confortável em aceitar o valor do SLA como está.
Há também fatores matizados. Por exemplo, a equipe reduz o valor de SLO para Instância Gerenciada SQL para 99,80% para levar em conta possíveis falhas em suas operações de dados, como alterações de esquema e realização de backups.
A equipe define o SLO composto calculando o impacto dos valores individuais e ajustados do SLO. Esse valor é de 99,72%.
Há outros fatores que contribuem. A arquitetura depende de componentes de rede do Azure, como redes virtuais e grupos de segurança de rede (NSGs) 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 baseado 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 comuns de tempo de inatividade 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 NSG e a seleção do tamanho correto das SKUs. Para contabilizar os erros de configuração, eles orçamentam 10 minutos de tempo de inatividade mensal, o que representa cerca de 99,98% de disponibilidade.
Um SLO composto baseado na disponibilidade da 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 da estrutura bem arquitetada 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 orçamentam um total de 20 minutos de tempo 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 atualizações ou manutenção do sistema. A API fica praticamente sem uso 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 baseado na disponibilidade das operações: 99,95% ao mês.
SLO de dependências externas: a equipe considera a Instância Gerenciada SQL como a dependência principal, que já tem uma disponibilidade de 99,80% considerada 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 composto do SLO
A meta geral composta de SLO é definida em 99,45%, o que equivale a aproximadamente quatro horas de inatividade por mês.
Para cumprir a meta do SLO de apenas quatro horas de indisponibilidade por mês, a equipe de carga de trabalho estabelece um rodízio de plantão. Tanto o suporte ao cliente quanto o monitoramento de transações sintéticas podem invocar o suporte SRE (engenharia de confiabilidade do local) de plantão para iniciar prontamente 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 definiram 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ários 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 correto
Os principais fluxos de usuários do aplicativo devem estar disponíveis e responsivos de forma utilizável ou mesmo 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 de internet. Eles avaliam este SLO apenas durante os períodos de disponibilidade. Eles escolhem o percentil 75 como o objetivo do SLO e a medição de desempenho, que captura a experiência típica do cliente e exclui os piores cenários.
Ligações relacionadas
Modelagem de integridade e observabilidade de cargas de trabalho de missão crítica no Azure
Lista de verificação de fiabilidade
Consulte o conjunto completo de recomendações.