Monitoramento e SLAs

Todo padrão deste tópico presume que você descobre

Redundância Multi-AZ, health checks do Auto Scaling, um plano de recuperação de desastres testado: todo padrão que este tópico cobriu até aqui presume algo, em silêncio. Presume que você descobre que uma falha está acontecendo, de preferência antes de um usuário descobrir, e presume que alguém consegue dizer depois, em números concretos, quão confiável o sistema realmente foi. Esta lição cobre as 2 metades: monitoramento, que é como você descobre, e SLAs, que são a promessa documentada sobre a frequência com que você não deveria ter precisado descobrir nada.

Monitoramento: métricas, logs e alarmes

3 blocos básicos cobrem quase tudo o que uma configuração de monitoramento faz. Uma métrica é um número acompanhado ao longo do tempo: uso médio de CPU, requisições por segundo, taxa de erro. Um log é o registro de um evento específico, uma linha dizendo exatamente o que aconteceu e quando, útil para investigar depois que algo já deu errado, não para acompanhar uma tendência. Um alarme observa uma métrica contra um limite e executa uma ação quando esse limite é ultrapassado por um período definido.

O Amazon CloudWatch é a implementação da AWS para os 3: coleta métricas automaticamente da maioria dos serviços da AWS, armazena e deixa você consultar logs, e permite definir alarmes em cima de qualquer um dos 2. Um exemplo concreto: um alarme observa o uso médio de CPU em períodos de 5 minutos, e se ele fica acima de 80% por 3 períodos consecutivos, o alarme dispara, o que pode acionar um engenheiro de plantão ou, conectando com a lição anterior, alimentar direto uma política de target tracking do Auto Scaling que sobe mais capacidade. O Azure Monitor e o Google Cloud Operations cumprem o mesmo papel em suas próprias plataformas; o vocabulário muda um pouco, mas métricas, logs e alarmes são as mesmas 3 peças em qualquer lugar.

SLI, SLO, SLA: medir, mirar, prometer

Esses 3 termos são usados quase como sinônimos na conversa do dia a dia, e a fronteira de prova entre eles vale a pena aprender com precisão.

Um Service Level Indicator (SLI) é uma medição quantitativa de como um serviço está performando de verdade, como a porcentagem de requisições bem-sucedidas. Um Service Level Objective (SLO) é a meta interna que um time define para esse SLI, como "miramos em 99,95% de requisições bem-sucedidas". Um Service Level Agreement (SLA) é a versão externa e contratual: uma promessa feita aos clientes que, se não cumprida, carrega consequências financeiras, normalmente um crédito de serviço.

Pense em um SLI como o marcador de velocidade de um carro, em um SLO como o limite de velocidade que o motorista se compromete a respeitar em particular, e em um SLA como a promessa feita a um passageiro de que a viagem não vai passar de uma certa velocidade, com reembolso garantido se passar. A comparação funciona para a relação entre medir, mirar e prometer, mas quebra em 1 ponto: um SLI normalmente não é uma leitura instantânea como um marcador de velocidade, costuma ser agregado ao longo de uma janela de tempo, 1 hora ou 1 mês, não um olhar rápido no painel.

Provedores definem o SLO deliberadamente mais rígido que o SLA. Se um SLA público promete 99,9% de uptime, o SLO interno que guia a operação do dia a dia pode ser 99,95%, dando ao time uma margem para perceber e reagir antes que uma meta interna não cumprida vire uma promessa externa não cumprida e sujeita a compensação.

Os noves: quanto uma porcentagem de uptime custa em downtime real

Números de disponibilidade são comparados casualmente, "estamos em 4 noves", sem sempre registrar o que isso realmente significa em horas. Cada nove adicional divide o downtime permitido por cerca de 10, e é por isso que o salto de 99,9% para 99,99% é um compromisso de engenharia muito maior do que os números sozinhos sugerem.

A maioria dos produtos SaaS e APIs mira em 3 noves. 5 noves fica reservado para sistemas em que até poucos minutos de downtime anual carregam consequências financeiras ou de segurança reais, e custa proporcionalmente mais para ser projetado.

Exemplo prático: lendo um SLA real

O SLA do Amazon EC2 é um caso concreto e útil. Ele garante uma Monthly Uptime Percentage no nível de região de pelo menos 99,99%, e separadamente uma Instance-Level Uptime Percentage de pelo menos 99,5% para instâncias individuais. Se o uptime real no nível de região fica abaixo disso em determinado mês, as camadas de crédito são 10% para 99,0% até menos de 99,99%, 30% para 95,0% até menos de 99,0%, e 100% abaixo de 95,0%.

Concretamente: se o uptime do EC2 no nível de região fica em 98,5% em 1 mês, isso cai na faixa de 95,0% a menos de 99,0%, e o cliente tem direito a um crédito de 30% na fatura daquele serviço no mês, aplicado automaticamente ou mediante solicitação dependendo do provedor, não um reembolso em dinheiro e não uma compensação pela receita que a queda custou ao próprio negócio do cliente.

O que um SLA promete, e o que não promete

É tentador tratar "respaldado por um SLA" como "isso nunca vai cair" ou como um seguro contra perdas do negócio. Nenhuma das 2 é verdade. Um SLA é um mecanismo de compensação pela falha do próprio provedor em cumprir seu compromisso publicado, pago como crédito em faturas futuras. Costuma excluir janelas de manutenção programada e fatores fora do controle do provedor, e, assim como o modelo de responsabilidade compartilhada visto antes neste domínio, só cobre o próprio serviço do provedor. Uma queda causada por um bug no código da própria aplicação do cliente é um problema de confiabilidade do cliente para monitorar e corrigir; nenhum SLA de provedor foi escrito para cobrir isso.

Fronteira: encadear serviços piora o número geral, não melhora

Uma carga de trabalho raramente depende de só 1 serviço. Encadeie 3 serviços com disponibilidade individual de 99,99%, 99,95% e 99,9%, e é tentador presumir que o mais forte ajuda a puxar a média para cima. Não ajuda: a disponibilidade composta multiplica as probabilidades individuais em vez de tirar uma média, então 99,99% vezes 99,95% vezes 99,9% dá algo perto de 99,84%, pior que qualquer componente isolado da cadeia. Cada dependência adicionada é um imposto sobre a confiabilidade geral, e é exatamente por isso que arquitetos contam quantos serviços um caminho de requisição crítico realmente atravessa, não só quão confiável cada um é isoladamente.

Dicas para a prova: encaixando um cenário no termo certo

Onde isso deixa você

Um SLA é um contrato de compensação definido em um piso abaixo do que um provedor mira internamente para si mesmo, nunca uma garantia de que nada vai falhar, e monitoramento é o que realmente diz a você, em tempo real, se hoje é um dos dias em que esse piso vai ser testado. Isso fecha Segurança e confiabilidade: agora você consegue nomear quem é dono de qual tarefa de segurança, como sistemas continuam no ar durante uma falha, como se recuperam de uma maior do que a redundância conseguia absorver, e o que uma promessa de uptime realmente significa quando ela não se cumpre. O próximo domínio vira de o que você sabe para onde isso leva: carreiras em nuvem e o caminho de certificação que este curso construiu até aqui.