No mês passado, fui encarregado de estimar meu acordo de nível de serviço 'SLA' do serviço Serverless. Primeiro, eu precisava descobrir como abordar a tarefa.
Pelo que eu sabia, o SLA era um contrato juridicamente vinculativo entre uma empresa e seus clientes em relação à disponibilidade de seus serviços e ao tempo de inatividade previsto ao longo de um ano.
Além disso, se a empresa não cumprisse, ela teria que reembolsar seus clientes.
Esta postagem do blog é fruto da minha pesquisa e processo de pensamento.
Nesta postagem do blog, você encontrará minhas definições, diretrizes e abordagem para entender SLA, SLI, SLO, RTO e RTP, e outras definições relacionadas em um contexto de serviço Serverless, incluindo a estimativa de disponibilidade de um serviço Serverless. Além disso, você aprenderá como melhorar seu RTO e reduzir o tempo de inatividade do serviço.
Isenção de responsabilidade: não sou advogado, apenas um arquiteto tentando entender tudo, então consulte sua equipe jurídica antes de publicar um SLA.
Índice
Definições
Vamos revisar alguns termos e definições básicos antes de estimar um SLA potencial de serviço sem servidor.
Desastre de serviço
Antes de falarmos sobre a integridade ou disponibilidade do serviço, precisamos entender o que é um desastre de serviço.
Um desastre de serviço é um evento em que o caso de uso comercial crítico de um serviço deixa de funcionar por algum tempo. No entanto, isso não significa que todo o serviço esteja offline.
Pense em um serviço de visualização de logs. O serviço é online; você pode fazer login, mas não visualizar nenhum log. Isso se qualifica como um desastre de serviço?
Eu diria que sim. O caso de uso comercial crítico é que os usuários podem visualizar logs, e esse fluxo é quebrado. Eu posso fazer login no serviço, mas não posso fazer nada.
Por outro lado, você pode ter um caso de uso comercial secundário que deixa de funcionar, mas pode ser menos crítico para o cliente. Claro, é um incômodo e um problema de produção. No entanto, o cliente ainda pode usar o serviço neste caso, então pode não ser considerado "tempo de inatividade" oficial.
Para esclarecer, suas equipes de produto e jurídicas são as que definem esses casos de uso
É essencial entendê-los, pois afetam diretamente o tempo de inatividade.
Observação: diferentes casos de uso comercial podem ter outros requisitos de disponibilidade, mas neste guia, vou me concentrar no caso de uso simples em que todos eles compartilham uma definição de SLA.
SLI
Indicadores de nível de serviço (SLI) são os números reais que medem a saúde e a disponibilidade de um sistema. Registraremos cada tempo de inatividade de desastre e calcularemos a disponibilidade do serviço usando a seguinte fórmula:
Disponibilidade = Tempo de atividade ÷ (Tempo de atividade + tempo de inatividade)
Por exemplo, um serviço ficou online por 700 horas ao longo de um mês e 30 horas de inatividade devido a vários desastres.
Disponibilidade = 700 ÷ (700 + 30) * 100
Disponibilidade = 700 ÷ 730 * 100
Disponibilidade = 0,958 * 100
Disponibilidade = 95,8%
A organização se esforça para melhorar e aproximar o SLI do SLO.
SLO
Objetivo de nível de serviço (SLO) é a meta interna da organização para manter os sistemas disponíveis e com desempenho de acordo com os padrões.
Essa porcentagem representa onde a organização quer estar em termos de disponibilidade, onde ela se esforça para estar, mas atualmente NÃO ESTÁ lá.
Geralmente é maior que o SLI e o SLA.
Acordo de Nível de Serviço (SLA)
Um acordo de nível de serviço (SLA) define o nível de serviço esperado por um cliente de um fornecedor, estabelecendo as métricas pelas quais esse serviço é medido e as soluções ou penalidades, se houver, caso os níveis de serviço acordados não sejam alcançados. - https://www.cio.com/article/274740/outsourcing-sla-definitions-and-solutions.html
Por exemplo: SLA de implantação de código AWS:
A AWS define os termos de compensação para quando o contrato é violado e a porcentagem de tempo de atividade mensal do serviço fica abaixo do limite do SLA.
Mas o que significa 99,9?
De acordo com a calculadora de SLA, 99,9 se traduz em:
Então, se o AWS CodeDeploy ficar inativo por mais de 43 minutos e 28 segundos em um único mês, nós, os clientes, ganhamos 10% de crédito de serviço de volta. Legal!
Se houver um tempo de inatividade mais significativo, receberemos mais créditos de volta, até um crédito total para SLA de 95% ou menos, o que é mais de 1,5 dia de tempo de inatividade em um único mês.
Exemplo de negócio
O SLI do seu serviço foi de 99,94% no último ano, o que significa 5 horas e 12 minutos de tempo de inatividade. O SLI é baseado em incidentes reais de tempo de inatividade de desastres de serviço.
Por outro lado, vamos supor que sua meta de disponibilidade interna, SLO, seja 99,99%, o que se traduz em cerca de 4 minutos de inatividade mensal, o que é bastante ambicioso.
No entanto, você quer ter um pouco de "espaço de manobra" - então você define seu SLA como 99,9% de disponibilidade.
Seu SLI está acima do SLA, então os clientes estão satisfeitos e há espaço para melhorar para chegar ao SLO ambicioso.
Camadas de serviço
Um serviço tem duas camadas que nos interessam no contexto de disponibilidade:
Camada de aplicação - Código de negócios, no nosso caso, é o código dos manipuladores Lambda.
Camada de infraestrutura - Recursos e configuração sem servidor: DynamoDB, configuração do AppConfig, máquina de estado da função Step, etc.
Failover de zonas de disponibilidade vs. Failover de região
Todos os serviços não devem ter um único ponto de failover.
Você pode ter um serviço global onde o failover entre regiões é necessário; por exemplo,
Se o seu serviço não responder em us-east-1, você deverá encaminhar seu cliente para a região de fallback, us-east-2, o mais rápido possível.
A maioria dos serviços sem servidor oferece suporte imediato a failover de múltiplas zonas de disponibilidade e recuperação automática.
Serviços como DynamoDB e Aurora suportam o mecanismo da tabela global, que permite um failover de região automático. O Serverless torna esses aspectos bem simples, desde que você os configure corretamente em sua infraestrutura como configuração de código.
RTO
O RTO ajuda a entender a porcentagem de uptime do serviço SLA. Vamos defini-lo:
O objetivo de tempo de recuperação (RTO) significa Objetivo de Tempo de Recuperação e é uma medida de quão rápido após uma interrupção um aplicativo deve estar disponível novamente . Em outras palavras, o RTO é a resposta à pergunta: "Quanto tempo levou para se recuperar após a notificação de interrupção do processo de negócios?" - druva.com
Quatro estágios de tratamento de recuperação de desastres
Um desastre pode se manifestar em ambas as camadas de serviço. Pode acontecer devido à configuração incorreta de recursos de infraestrutura ou a um bug no código da função Lambda.
Lidar com um desastre consiste em vários estágios. A duração desses estágios faz com que o tempo de recuperação do serviço, o RTO:
Tempo para a primeira resposta : o desenvolvedor bombeiro ou engenheiro de suporte leva tempo para começar a lidar com o desastre desde o início do primeiro alerta ou notificação ao cliente.
Tempo para encontrar a causa : o tempo que o desenvolvedor bombeiro ou engenheiro de suporte leva para encontrar a causa raiz do desastre. Os desenvolvedores devem revisar logs, métricas e rastros para descobrir o problema.
Tempo para corrigir: o tempo para implementar uma correção de bug, reverter confirmações anteriores ou desabilitar um sinalizador de recurso. Essas alterações acionam uma execução de pipeline de CI/CD para produção. Melhor cenário: uma reversão de código é enviada e implementada nas últimas confirmações, o que não requer desenvolvimento adicional de uma correção de bug. Pior cenário: um desenvolvedor escreve um novo código e testa para corrigir o problema enquanto o serviço está inativo, o que se traduz em tempo de inatividade extra.
É hora de notificar os usuários de que o serviço está de volta e funcionando.
Muitos fatores podem impactar o tempo que os desenvolvedores gastam nos estágios 2 e 3, por exemplo:
Porcentagem de cobertura de código.
Complexidade do código de serviço.
Qualidade de observabilidade do serviço.
Dependência de serviços em serviços externos.
Proficiência em equipe.
Prontidão da equipe para recuperação de desastres, ou seja, scripts de backup, treinamento para lidar com desastres.
Como você pode ver, o RTO pode variar entre alguns minutos, várias horas ou até dias.
Os estágios 2 e 3 têm o maior potencial de causar tempo de inatividade prolongado.
RTO de serviços gerenciados da AWS
Por outro lado, o RTO dos serviços gerenciados da AWS é o tempo que a infraestrutura leva para:
Identifique que uma zona de disponibilidade ou região está inativa.
Rotear (failover) os dados do usuário ou serviço para uma A/Z ou região diferente.
Em serviços gerenciados da AWS, o failover e a recuperação A/Z são feitos automaticamente, tornando o RTO rápido. O DynamoDB é um exemplo de serviço gerenciado da AWS que cuida disso para você.
Quanto aos failovers regionais, o Route53 suporta failover automático de DNS , que pode rotear para uma região diferente se uma região estiver inativa.
O DynamoDB e o mecanismo de tabelas globais do Aurora são outros exemplos de serviços gerenciados pela AWS que gerenciam automaticamente o tempo de inatividade regional para você, agilizando o RTO.
Como você "estima" o RTO?
Eu chamo isso de palpite; você precisa de anos de dados do SLI para estimar o RTO com precisão.
Se esse não for o caso, você precisa fazer uma "estimativa" calculada, considerando os quatro estágios do tratamento de desastres e os fatores que os impactam.
Discutiremos como você pode melhorar esses fatores e o RTO na última parte deste post.
RPO
Um objetivo de ponto de recuperação (RPO) é o período máximo de tempo permitido para que os dados possam ser restaurados, o que pode ou não significar perda de dados. É a idade dos arquivos ou dados no armazenamento de backup necessária para retomar as operações normais se ocorrer uma falha no sistema de computador ou na rede. Para definir a diferença de forma mais concisa: RPO é o tempo do último backup de dados até que um incidente tenha ocorrido [que pode ter causado perda de dados]. - evolveip.net
O RPO depende da frequência de backup do banco de dados.
Se você usa bancos de dados Serverless, você está com sorte. Eles têm os melhores mecanismos de recuperação e backups point-in-time da categoria.
Quando configurado adequadamente, o RPO pode ser reduzido para minutos com backups pontuais do DynamoDB e do Aurora.
Colocando RTO e RPO em um exemplo de continuidade de negócios
Em nosso serviço de exemplo, um RTO típico é de uma hora, o RPO é de 15 minutos e o último backup do banco de dados ocorreu às 12h.
Às 12h15, segundos antes do próximo backup, ocorre um desastre.
O RTO é de uma hora em média, o que de fato foi o caso neste desastre. Às 13h15, após uma hora de inatividade, o serviço está online novamente. Nossa perda de dados, neste caso, é de 15 minutos, pois o último backup ocorreu às 12h00.
Como estimar o SLA
Siga estes passos:
Defina o que conta como um desastre no seu serviço. Defina os fluxos críticos no serviço e qual infraestrutura e código de aplicativo são relevantes para eles.
Calcule seu SLI de serviço atual de acordo com dados de incidentes passados. O SLI prevê o futuro e ajuda a supor quantos incidentes você terá em um ano.
Estime o RTO do seu serviço.
Calcule o tempo de inatividade anual em dias: suponha quantos incidentes por ano você pode esperar e multiplique pelo RTO calculado na etapa 3. Certifique-se de alterá-lo para uma unidade de dia.
Fórmula SLA: (365 - {dias de inatividade}) / 365 * 100 = SLA, onde 365 são 365 dias, o que se traduz em tempo de atividade anual do serviço 24 horas por dia, 7 dias por semana.
Exemplo de estimativa de SLA
Vamos estimar o SLA para um 'serviço de pedidos' sem servidor que permite aos clientes criar e visualizar pedidos de um produto.
Vamos seguir os quatro passos da estimativa de SLA:
Fluxo crítico de negócios - Crie novos pedidos de clientes. Visualizar pedidos existentes não é considerado um fluxo vital.
SLI atual - 99,99% (um incidente anterior na produção por cerca de uma hora)
RTO: veja a estimativa abaixo. Usaremos uma abordagem mais segura e assumiremos que incidentes futuros exigirão que a equipe depure e conserte o problema em vez de uma simples reversão de código.
Estimativa de dois incidentes anuais. Tempo de inatividade anual => 2* RTO = 2* 0,25 = 0,5 dias de tempo de inatividade ao longo de um ano.
Níveis de Atuação: (365-0,5)/365 * 100 = 99,86% Níveis de Atuação
Estimativa RTO
A camada de infraestrutura dos serviços usa AWS Lambda, Amazon API Gateway e Amazon DynamoDB.
A qualidade do código de serviço é alta; a cobertura do código é de cerca de 90%
SLA do serviço AWS em uso: mínimo SLA GARANTIDO: 99,95%
Vamos estimar um RTO de 6 horas, que é 0,25 dias, assumindo que incidentes futuros levem mais tempo para investigar e depurar do que apenas uma reversão de código que leva uma hora. Embora o único incidente passado tenha levado uma hora para ser resolvido, entendemos que foi a exceção e não a norma. É melhor estar do lado seguro do que prometer estimativas que sua equipe terá dificuldade em entregar no futuro.
No futuro, quando houver mais exemplos de incidentes anteriores, poderemos ajustar o número de RTO à média real de incidentes.
Observe como o SLA é menor do que o SLA do nosso serviço AWS garantido: 99,86 < 99,95. Isso faz sentido, pois podemos ter um SLA que seja menor/igual ao SLA da infraestrutura e dos serviços AWS dos quais dependemos, mas não maior!
Segunda observação: nosso SLI é maior que o SLA e atualmente oferecemos melhor disponibilidade do que o prometido aos clientes.
Como melhorar seu RTO - Preparando-se para desastres
Você deve aceitar que é apenas uma questão de tempo até que algo terrível aconteça.
Você não pode se preparar para tudo, mas pode ter apólices de seguro e tentar preparar sua equipe e serviço para muitos desastres.
Vamos revisar algumas ações que podem preparar sua equipe para o pior, diminuindo assim o RTO, melhorando a disponibilidade e melhorando a porcentagem potencial de SLA.
Práticas de CI/CD
Implantação Canary para funções AWS Lambda
Implantação canário para AWS Lambda - para um ambiente de produção, use implantações canário com reversões automáticas à primeira vista dos logs de erro do AWS Lambda ou alarmes acionados do AWS CloudWatch.
As implantações Canary transferem gradualmente o tráfego para sua nova versão do AWS Lambda e revertem a mudança ao primeiro sinal de erro.
Uma maneira de fazer isso é usar o AWS Code Deploy com o AWS Lambda.
Implantação Canary para configuração dinâmica do Lambda
As implantações canárias também são relevantes no domínio da configuração dinâmica de aplicativos.
Os sinalizadores de recurso são um tipo de configuração dinâmica e permitem que você altere rapidamente o comportamento da sua função AWS Lambda. Uma maneira de melhorar a confiança no lançamento de recurso é ativar ou desativar um recurso rapidamente.
Recuperação de crise
Cópias de segurança
Faça backup dos seus dados e dos dados dos clientes.
Habilite backups de hora em hora de suas tabelas DynamoDB, bancos de dados Aurora, índices OpenSearch ou qualquer outra entidade de banco de dados. É melhor prevenir do que remediar.
Alguns serviços, como o DynamoDB, oferecem backups automáticos e facilidade de restauração.
Quanto mais frequente for o backup, menor será o RPO.
O SOP (procedimento operacional padrão)
Tenha uma equipe de suporte 24 horas por dia, 7 dias por semana
Crie processos claros para lidar com desastres.
Os processos reduzem o RTO em caso de desastre.
Crie um processo para restaurar dados de produção a partir do backup.
Criar um backup é uma coisa, mas restaurar a partir de um backup quando o tempo está passando e clientes chateados estão batendo na sua porta é outra.
Você deve criar um processo bem definido para restaurar qualquer banco de dados de forma rápida e segura.
Desenvolva os scripts necessários, defina o processo de restauração (quem o executa, quando, como), teste-o em ambientes de não produção e treine sua equipe de suporte para usá-lo.
Além disso, você deve criar um processo para fazer alterações/scripts/correções ad-hoc na conta de produção. Às vezes, você não pode esperar por uma correção de bug para implantar da conta dev para a produção, e pode levar muito tempo para passar por todos os estágios do pipeline de CI/CD.
Às vezes, você precisa de uma maneira rápida, auditada e segura de alterar dados de produção.
Certifique-se de que ele seja auditado, exija aprovações extras e não viole nenhuma regulamentação que você seja obrigado a cumprir.
Pratique a execução desses scripts pelo menos uma vez por trimestre.
Engenharia do caos
Espere o inesperado. Interrupções e erros de servidor vão acontecer, mesmo no Serverless.
Você precisa estar preparado.
Use a Simulação de Injeção de Falhas da AWS para criar caos na sua conta da AWS, fazer com que suas chamadas de API da AWS falhem e ver como seu serviço se comporta.
Tente projetar para falhas o mais cedo possível em sua jornada sem servidor.
Observabilidade e prontidão de suporte
Boas práticas de observabilidade e registro ajudarão os desenvolvedores a resolver problemas mais rapidamente e a serem notificados sobre um incidente iminente antes que o desastre aconteça, reduzindo assim o RTO.
ID de correlação
Aos meus olhos, a sessão de depuração perfeita é aquela em que consigo rastrear uma única atividade do usuário em vários serviços com apenas um ID — o famoso valor de ID de correlação .
Uma maneira de obter essa experiência é injetar um valor de ID de correlação nos seus logs de serviço.
Além disso, você deve passar esse valor para qualquer chamada seguinte aos serviços por meio de cabeçalhos de solicitação/evento (atributos do AWS SNS/cabeçalhos HTTP, etc.).
Veja um exemplo aqui com o AWS Lambda Powertools Logger.
Painéis de Observabilidade
Crie painéis do AWS CloudWatch que forneçam uma visão geral de alto nível do status do seu serviço para sua equipe de SRE.
Ele deve conter logs de erros gerenciáveis e informações de serviço, para que pessoas não desenvolvedoras possam identificar rapidamente os erros e suas causas raiz.
Deixe os painéis complicados contendo métricas de serviço de baixo nível do CloudWatch para os painéis do desenvolvedor.
Trabalhe em estreita colaboração com a equipe de SRE, adicione mensagens de log precisas descrevendo problemas de serviço e crie o painel.
Leia mais sobre observabilidade e CloudWatch aqui .
Alertas
Defina alertas do CloudWatch em logs de erros críticos ou métricas do CloudWatch que se correlacionam a uma deficiência grave de serviço ou negação de serviço.
Isso pode incluir falhas na função Lambda, problemas de latência, tempos limite da função Lambda, erros do DynamoDB, problemas de login do Cognito, etc.
Cada alarme precisa ser investigado e mitigado rapidamente.
Treinamento
Invista tempo e esforço em treinamento de suporte para desenvolvedores e SREs.
Cada log de erro do painel ou métrica do CloudWatch deve ter uma ação predefinida para o SRE executar.
Inclua diretrizes como "Se você vir 'X' e 'Y', provavelmente significa que Z é um problema; siga estas etapas para mitigar Z."
Garanta que os SREs entendam a arquitetura de alto nível orientada a eventos do serviço para que possam oferecer suporte a ele de forma mais eficiente.
Obrigado Ronen Mintz pela avaliação e feedback.
Comentarios