Nuvem ou On-Prem: O que um SRE Verifica Embaixo do Serviço

O provedor de infraestrutura é a maior dependência isolada que qualquer serviço tem, e um SRE o trata como qualquer outra dependência: lê o que ele de fato se compromete a entregar, mapeia onde ele falha em conjunto e verifica o que acontece quando ele não responde. Isso vale tanto se o provedor é a AWS quanto se é um time de plataforma operando racks dois andares abaixo. As perguntas são idênticas nos dois casos; o que muda é quem as responde. Em uma nuvem o provedor responde e você verifica. On-prem você responde, e não há ninguém para verificar você. Este post é o checklist, em seis áreas: o compromisso, domínios de falha, control planes, limites, capacidade e manutenção.

Esta é a Parte 4 de Budget for Failure, a segunda parte de nível 201 e a última da série. A Parte 1 definiu o papel, a Parte 2 deu números a ele e a Parte 3 o levou para dentro do código da aplicação. Esta parte vai por baixo do código.

1. O compromisso: suas dependências limitam seu SLO

A Parte 2 listou o que quatro SLAs da AWS prometem. Agora faça a aritmética que a maioria das revisões de arquitetura pula. Uma requisição que precisa passar por um load balancer, uma camada de computação, um banco de dados e um armazenamento de objetos só tem sucesso quando os quatro têm. Se as falhas são independentes, as disponibilidades se multiplicam:

ALB (multi-AZ)      0.9999
EC2 (multi-AZ)      0.9999
RDS (Multi-AZ)      0.9995
S3 Standard         0.9990
------------------------------
product             0.9983   =  99.83%
allowed downtime    about 73 minutes in 30 days

Antes de o seu próprio código lançar uma única exceção, o piso contratual embaixo dessa pilha é 99,83 por cento. A AWS normalmente opera bem acima dos pisos de SLA, então o número prático é melhor, mas a conclusão se mantém: você não pode prometer 99,99 por cento em cima de uma dependência hard que se compromete com 99,9. Ou você reduz a promessa, ou torna a dependência soft com um cache, uma fila ou um fallback, como na Parte 3.

On-prem não há documento de SLA para multiplicar, então você monta a mesma tabela a partir do seu próprio histórico: disponibilidade medida do storage array, do cluster de hipervisor, da rede core, da energia. Se ninguém tem esses números, essa é a primeira constatação da revisão.

2. Domínios de falha: o que morre junto

A multiplicação presume independência. Um domínio de falha é um conjunto de coisas que compartilham uma causa de falha, e o trabalho do SRE é conhecê-los e distribuir réplicas entre eles.

Três verificações valem dos dois lados. As réplicas de cada sistema com estado estão mesmo em domínios diferentes, ou três nós de um quórum estão em uma zona ou em um rack? Há algo single-homed no caminho de algo multi-homed, como um único NAT gateway servindo três zonas, ou dois switches "redundantes" na mesma alimentação elétrica? E depois que o maior domínio que você planeja sobreviver se foi, a capacidade restante é suficiente para carregar toda a carga? Sobreviver à perda de uma zona com três zonas significa rodar cada uma com no máximo dois terços.

A série Nothing Fails Alone são quatro incidentes trabalhados exatamente sobre isso, incluindo um script somente leitura que encontra concentrações em zona única em uma conta AWS.

3. Control plane e data plane

Toda plataforma tem duas metades. O data plane faz o trabalho: instâncias rodam, load balancers encaminham, o DNS responde. O control plane muda as coisas: lança uma instância, modifica uma rota, escala um grupo. Control planes são mais complexos e falham com mais frequência, e tendem a falhar durante incidentes grandes, que é exatamente quando um plano de recuperação quer usá-los.

Então a pergunta para cada procedimento de recuperação é se ele precisa de uma chamada ao control plane para ter sucesso. Um design que sobrevive à perda de uma zona porque a capacidade já está rodando em outro lugar é estaticamente estável. Um que sobrevive porque o autoscaling vai lançar substitutos depende do control plane do EC2 no momento em que todos os outros clientes o estão chamando. O artigo da Amazon Builders' Library sobre estabilidade estática é a referência.

On-prem a mesma divisão existe sob outros nomes: o API server do Kubernetes, o vCenter, a automação de IPAM e DNS, o provedor de identidade do qual todo login e todo token de serviço dependem. Pergunte o que ainda funciona quando cada um deles está fora, e se as ferramentas usadas para corrigir uma queda (a VPN, o bastion, o pipeline de deploy, o sistema de chat) rodam na infraestrutura que elas deveriam consertar.

4. Limites: a queda que parece uma quota

Saturação, dos sinais de ouro da Parte 1, tem uma forma do lado do provedor que métricas de host nunca mostram. Na AWS, os limites que acabam em postmortems raramente são CPU:

• Service quotas. vCPUs On-Demand em execução por família de instância, execuções concorrentes de Lambda por conta, Elastic IPs, regras por security group. Um scale-out que bate numa quota falha no pior momento.
• Rate limits de API. APIs de control plane aplicam throttling por conta e Região. Uma ferramenta de deploy, um autoscaler e um agente de monitoramento, todos chamando Describe*, podem fazer throttling uns dos outros.
• Espaço de endereçamento. Uma subnet que ficou sem IPs livres para novos pods, novas interfaces de rede de Lambda e novas instâncias, com um erro que não menciona nenhum deles.
• Tetos por recurso. IOPS e throughput em um volume EBS, conexões em uma classe de instância RDS, portas em um NAT gateway.

Trate cada um como um SLI de saturação com um alarme bem antes de 100 por cento. Para muitas quotas o CloudWatch publica o uso no namespace AWS/Usage, e a função de metric math SERVICE_QUOTA() retorna o limite atual, então uma expressão dá a porcentagem de quota usada. Para o resto, um script de inventário agendado basta.

On-prem os limites são físicos e mais lentos de elevar: unidades de rack, energia e refrigeração por rack, portas de switch, cores licenciados, throughput da controladora de storage, o tamanho do plano de endereçamento feito cinco anos atrás.

5. Capacidade: elástico não é infinito

A promessa da nuvem é que capacidade chega em minutos. Normalmente chega, e um SRE planeja para as vezes em que não chega. Um tipo de instância específico em uma zona específica pode retornar InsufficientInstanceCapacity, na maioria das vezes durante um evento de zona, quando todo mundo está fazendo failover para as mesmas zonas sobreviventes. As defesas são diversidade (vários tipos de instância e todas as zonas no Auto Scaling group), pré-provisionamento para o caso de failover e On-Demand Capacity Reservations para as cargas que não podem esperar.

On-prem o lead time é de semanas a meses, então planejamento de capacidade é uma disciplina de previsão: crescimento medido, um calendário de compras e folga dimensionada como N+1 ou N+2 contra os domínios de falha acima. A decisão que mais afeta a confiabilidade é tomada na hora da compra, muito antes do incidente que a testa.

Nos dois mundos, faça teste de carga para encontrar o primeiro limite em vez de estimá-lo. O número que importa é o nível de tráfego em que o SLI da Parte 2 começa a degradar, e qual recurso causou isso.

6. Manutenção: os incidentes com data marcada

Uma fatia grande dos incidentes é agendada com antecedência por alguém e depois esquecida. Em uma nuvem: avisos de retirada de instância, janelas de manutenção de banco de dados, versões de engine e de Kubernetes chegando ao fim do suporte padrão, expiração de certificados, runtimes descontinuados. A AWS publica a maioria deles por conta via AWS Health, que pode ser roteado pelo EventBridge para a mesma fila do seu outro trabalho operacional. Não lidos, viram reboots surpresa.

On-prem a lista é mais longa e inteiramente sua: firmware, patches de hipervisor e sistema operacional, troca de discos e baterias, ciclos de renovação de hardware, contratos de suporte com fornecedores, peças de reposição no local. Cada item precisa de um dono e de um calendário. Uma plataforma três versões major atrás está gastando error budget adiantado.

A última verificação nesta área é como você descobre que o provedor está tendo um dia ruim. Uma página de status é escrita por pessoas durante um incidente e fica atrás dele. Meça o provedor você mesmo, de fora: um canário sintético que exercita o caminho real do usuário a partir de outra rede te avisa de um problema regional antes do dashboard, e mantém vivo o denominador do SLI quando o tráfego real não consegue chegar até você.

Quem é dono do quê

Nenhuma das colunas é mais curta porque o trabalho sumiu. Uma nuvem move as linhas de baixo para um provedor com mais prática nelas do que quase qualquer empresa isolada, e em troca você assume uma dependência que não consegue inspecionar. Essa troca normalmente é acertada. Ainda é uma troca, e o SRE é a pessoa capaz de enunciar os dois lados dela.

Modos de falha e o que observar

Tratar o SLA como previsão. É um termo de precificação com um crédito anexado. Projete para o comportamento medido e para os domínios de falha, não para a porcentagem na página.

Multi-zona só no diagrama. Três zonas na lista de subnets e uma no estado em execução, ou um failover que nunca foi exercitado. Teste de propósito, dentro do error budget.

Recuperação que precisa do que está quebrado. Runbooks cujo primeiro passo é um login no console ou uma execução de pipeline na Região afetada.

Limites descobertos em produção. Toda quota e todo teto da seção 4 são baratos de encontrar em um teste de carga e caros de encontrar durante um lançamento.

Onde isso te deixa

O caminho da série, de uma só vez. Você assume a confiabilidade como um problema de engenharia e limita o trabalho manual para que haja tempo de resolvê-lo (Parte 1). Você declara quão confiável o serviço deveria ser como um SLO, e gasta a folga de propósito como um error budget com uma política assinada (Parte 2). Você entra no repositório e corrige os timeouts, retries e rollouts que decidem o número, e aciona alguém por burn rate em vez de CPU (Parte 3). E você sabe o que a plataforma embaixo de você promete, onde ela falha em conjunto e o que vai fazer quando isso acontecer (Parte 4). As ferramentas para as quatro, a maioria dos engenheiros já usa. O que torna o trabalho SRE é que cada uma delas agora responde a uma única pergunta: os usuários estão recebendo a confiabilidade que acordamos, e qual é o jeito mais barato de manter isso assim?

Leia isto a seguir

• Parte 3 desta série: SRE no Código: Timeouts, Retries e Alertas como Código.
• A Correção Compartilha o Destino com a Queda: três incidentes em que o caminho de recuperação dependia do control plane que estava fora.
• Your LLM Bill Is an Observability Problem em ercan.ai: o mesmo raciocínio de dependência de provedor aplicado a APIs de modelos, onde quotas e custo são os sinais de saturação.

Para consultoria em AWS, arquitetura de nuvem, prática de SRE, pipelines de CI/CD, Linux e mais, comece em ercanermis.com.

Referências

• Amazon Builders' Library: Static stability using Availability Zones
• AWS whitepaper: AWS Fault Isolation Boundaries
• Amazon CloudWatch: Visualizing your service quotas and setting alarms
• Amazon EC2: On-Demand Capacity Reservations
• AWS Health: Monitoring events with Amazon EventBridge
• Amazon Compute Service Level Agreement
• Google SRE Book, Chapter 18: Software Engineering in SRE (capacity planning)