Princípios SRE: As 7 Regras Fundamentais

Os sete princípios SRE vêm de uma empresa que possui seus data centers, sua rede, seus balanceadores de carga e cada linha de código entre eles. Sua pilha provavelmente não é assim. Grande parte do que seus usuários experimentam roda em infraestrutura que você não pode acessar via SSH: um CDN, um provedor de autenticação, um gateway de pagamento, DNS, um gerenciador de tags, uma API parceira.

Essa lacuna importa, porque os princípios ainda valem fora do Google. Mas vários deles mudam de forma quando o componente que está falhando não é seu para consertar. Um orçamento de erros se comporta diferente quando um terço dele é gasto por uma falha de outra empresa. Os quatro sinais dourados parecem diferentes fora do firewall do que dentro dele. E o risco que você não pode eliminar pela engenharia, precisa medir.

Este artigo percorre todos os sete princípios da maneira como o livro do Google SRE os define, e então adiciona a parte que o livro pula: como cada princípio se manifesta quando você depende de serviços que não controla. Se você é novo na função, comece com o que um engenheiro de confiabilidade de site faz e depois volte aqui.

O que são os Princípios SRE?

Os princípios SRE são as regras de trabalho que o Google codificou para executar sistemas confiáveis em escala: abraçar e gerenciar risco, objetivos de nível de serviço, eliminar trabalho repetitivo (toil), monitoramento, automação, engenharia de releases e simplicidade. Juntos eles respondem a uma pergunta: quão confiável esse serviço precisa ser, e qual é a forma sustentável mais barata de mantê-lo assim?

A lista não mudou desde que o livro SRE foi publicado em 2016. O que mudou foi a pilha média. Microsserviços, dependências SaaS e scripts de terceiros significam que parte da sua confiabilidade agora está nas mãos de outras empresas. Cada seção abaixo cobre o princípio conforme escrito, depois o que se quebra quando a dependência não é sua. No final, uma lista curta de melhores práticas SRE extraídas dos sete princípios.

Princípio 1 – Abraçar e Gerenciar o Risco

A formulação do Google: 100% de confiabilidade é a meta errada. Usuários acessam você por meio de redes e dispositivos que falham por conta própria, então, além de um certo ponto, os “nines” extras custam dinheiro real e ninguém nota a diferença. Escolha uma meta de confiabilidade que o negócio possa defender e trate a diferença entre essa meta e a perfeição como um orçamento que você pode gastar enviando funcionalidades. O capítulo Abraçando o Risco expõe isso em detalhes.

Dentro do Google, isso funciona porque o risco é um dial (controle) que eles podem ajustar. Mais replicação, mais redundância, implantações mais lentas: gaste dinheiro, obtenha “nines”.

Fora do Google, parte desse dial não está conectado a nada. Você não pode adicionar uma réplica ao seu gateway de pagamento. Não pode ajustar o comportamento de failover do seu provedor de DNS. A confiabilidade deles é um termo contratual, não um parâmetro de engenharia.

Então o princípio muda de forma: para os componentes que você possui, gerencie risco pela engenharia. Para os componentes que não possui, gerencie-o pela medição. Você precisa saber a disponibilidade real do seu provedor de autenticação medida do lado dos seus usuários na internet, não o número na página de status dele. Páginas de status rotineiramente exibem verde durante falhas parciais, e uma dependência que está ativa no próprio data center ainda pode ser inacessível do seu. Medição independente é o que transforma “achamos que o CDN está instável” em uma conversa de renovação embasada por dados. Este é o primeiro trabalho que o Dotcom-Monitor faz aqui: colocar uma checagem externa em cada dependência crítica. Uma checagem DNS contra os servidores de nome do provedor, uma checagem HTTP(S) na borda do CDN, uma checagem de API contra o gateway de pagamento. Cada uma constrói seu próprio histórico de tempo de atividade e tempo de resposta a partir de uma rede global. E onde os números justificam, rode em volta do risco: um segundo provedor DNS, um caminho de pagamento reserva, uma cópia em cache do script de terceiros.

Como Implementar o Gerenciamento de Risco

• Liste todas as dependências que um pedido do usuário acessa (DNS, CDN, autenticação, pagamentos, tags de terceiros) e marque quais você pode controlar pela engenharia e quais só pode medir.
• Crie um dispositivo Dotcom-Monitor para cada uma que só possa medir: uma tarefa DNS apontada para os servidores de nome do provedor, uma tarefa HTTP(S) na borda do CDN, uma tarefa de serviços web contra o endpoint de pagamento ou autenticação.
• Execute essas checagens de vários locais de monitoramento nas regiões dos seus usuários, para que uma falha regional no fornecedor não fique escondida atrás de uma região saudável.
• Leve o relatório de uptime de cada dispositivo para a conversa com o fornecedor, e adicione rotas reserva (DNS secundário, caminho de pagamento reserva) só onde esses dados indicarem que o risco justifica o custo.

Princípio 2 – Objetivos de Nível de Serviço (SLA, SLO, SLI)

Três termos se confundem constantemente, então aqui está a separação:

• SLA (Service Level Agreement, Acordo de Nível de Serviço): o contrato. O que você promete aos clientes, com penalidades se não cumprir.
• SLO (Service Level Objective, Objetivo de Nível de Serviço): a meta que você define para um indicador de nível de serviço, tipicamente interno e mais restrito que o SLA para que o alarme próprio dispare antes do contrato ser quebrado. 99,9% de uptime, finalização do checkout em menos de 3 segundos, esse tipo de meta.
• SLI (Service Level Indicator, Indicador de Nível de Serviço): a medição propriamente dita. O número real de uptime, o tempo de resposta real, a taxa de erro observada.

O SLI mede, o SLO define a meta, o SLA promete. Tudo a jusante, incluindo os relatórios de uptime e SLA que você entrega a um cliente, depende do SLI ser confiável.

E é aqui que a maioria dos times tem um ponto cego: um orçamento de erro é tão preciso quanto a medição por trás dele. Se suas checagens rodarem a cada 5 minutos, cada falha registrada tem um começo e um fim conhecidos apenas dentro de um intervalo de 5 minutos, e falhas mais curtas que esse intervalo podem acabar sem nunca serem vistas. Veja o que isso faz ao orçamento mensal de erro nos alvos SLO comuns, usando um mês de 30 dias (43.200 minutos):

Você não pode medir um SLO mensal de 99,99% com checagens de 5 minutos. Um único intervalo de checagem é maior que todo o seu orçamento mensal de erro.

A matemática da probabilidade é tão rigorosa quanto. Com um intervalo de checagem de I minutos, uma falha aleatória que dura D minutos (onde D é menor que I) é capturada com uma probabilidade aproximada de D/I, assumindo que o início da falha seja independente da escala de checagem. Então uma falha de 4 minutos contra um intervalo de 5 minutos é capturada cerca de 4 vezes em 5, e a chance restante de 1 em 5 é a falha ocorrendo inteiramente entre duas checagens sem ser registrada. Para falhas que duram mais que o intervalo, o atraso médio de detecção é cerca de metade dele, então checagens de 5 minutos adicionam em média 2,5 minutos antes de qualquer um saber.

Um caveat: a tabela assume uma única checagem agendada e contagem de downtime baseada em intervalos. Confirmação multi-local e SLIs baseados em requisição mudam detalhes, não o problema da amostragem.

Falhas curtas também não são casos extremos. Entre as falhas que o Dotcom-Monitor detecta, cerca de 38% se resolvem em menos de 5 minutos. São principalmente oscilações de roteamento de rede, reinicializações, reinícios e failovers que se corrigem antes que alguém possa intervir razoavelmente, e nosso Filtro de Resposta segura o alerta exatamente por esse motivo. Mas filtradas do alerta não significa filtradas do registro: esses tempos de inatividade ainda contam contra o SLA, interno ou de fornecedor, e precisam ser contabilizados. Das falhas que disparam alerta, mais de 56% se resolvem em até 15 minutos da primeira notificação, cerca de 18% duram mais que uma hora, e aproximadamente 3% passam de 24 horas. A divisão varia um pouco entre tipos de serviços, mas a forma se mantém: mais de um terço de todas as falhas estão em um intervalo que uma checagem de 5 minutos mal consegue ver. Por isso a frequência de checagem é uma decisão de medição, não só de custo: em intervalos de 1 minuto, o quantum de medição cai para 2,3% de um orçamento mensal de 99,9% ao invés de 11,6%, e as falhas curtas que dominam os incidentes começam a aparecer no seu registro. É por isso que o Dotcom-Monitor executa checagens até a cada minuto e baseia seus relatórios SLA nesses registros: o número de conformidade que você mostra a um cliente é tão confiável quanto a amostragem por trás dele.

Como Implementar Objetivos de Nível de Serviço

• Defina dois ou três SLIs que seus usuários reconheceriam, como uptime medido de um navegador real ou tempo de checkout, e faça uma checagem Dotcom-Monitor ser a fonte oficial de cada um.
• Configure cada SLO mais restrito que o SLA que protege, depois ajuste a frequência de checagem do dispositivo para se adequar ao nível: conforme a tabela acima, qualquer meta além de 99,9% necessita de checagens a cada 1 minuto.
• Agende relatórios de uptime e SLA para as pessoas que gerenciam a conversa do SLA, para que o número de conformidade venha do mesmo registro da checagem que gera os alertas.
• Combine antecipadamente o que acontece quando o orçamento de erro acabar, enquanto ninguém discute um incidente específico.

Princípio 3 – Elimine Trabalho Repetitivo (Toil)

Toil é trabalho manual, repetitivo que escala com o tamanho do serviço e não produz valor duradouro. O capítulo Eliminando Toil definiu um limite famoso: SREs não devem gastar mais da metade do seu tempo com isso, e o resto em engenharia para eliminar o toil.

Definições abstratas fazem toil fácil de concordar e difícil de identificar. Então nomeie-o. Na maioria dos times, ele se parece com isso:

• Alguém entra todo dia de manhã para confirmar se o fluxo de checkout ainda funciona.
• Alguém testa manualmente o formulário de cadastro após cada deploy.
• Alguém mantém um lembrete de calendário para datas de expiração de certificados SSL.
• Alguém consulta uma API parceira manualmente sempre que os tickets de suporte aumentam, para saber se o problema é do seu lado ou deles.

Cada um desses é uma transação roteirizada esperando para ser escrita, e é onde o Dotcom-Monitor ganha seu valor diretamente. Um script gravado com o EveryStep, seu gravador de transações point-and-click, percorre o mesmo caminho de checkout a cada poucos minutos em um navegador real e dispara um alerta no momento que qualquer passo falhar. Suas checagens de certificado acompanham a data de expiração sem precisar do calendário. As checagens de API sondam o endpoint parceiro numa agenda e mantêm o histórico de tempo de resposta que resolve a discussão “nosso lado ou deles” num piscar de olhos.

O teste para decidir o que automatizar primeiro não é sofisticação, é recorrência. A checagem humana diária é a que a máquina deve fazer a cada minuto.

Como Implementar a Eliminação de Toil

• Registre por uma semana todas as checagens manuais que alguém no time faz; a recorrência, não a dificuldade, decide o que automatizar primeiro.
• Grave a que mais se repete como um script EveryStep clicando pelo fluxo uma vez, depois deixe rodar a cada poucos minutos em vez de uma vez por manhã.
• Substitua o calendário de expiração do certificado pelas checagens SSL do Dotcom-Monitor, e coloque APIs parceiras em checagens programadas de serviços web para que ninguém precise lembrar delas de cabeça.
• Monitore as horas de checagem manual removidas a cada trimestre, para que o trabalho de automação continue visível e financiado.

Princípio 4 – Monitoramento e os Quatro Sinais Dourados

O capítulo Monitoramento de Sistemas Distribuídos nomeia quatro sinais dourados: latência, tráfego, erros e saturação. Acompanhe esses quatro e você pegará a maioria dos problemas.

O capítulo menciona monitoramento black-box, mas a maioria dos times acaba instrumentando os quatro sinais de dentro do sistema. Observe-os de onde seus usuários estão, e três dos quatro mudam:

Leia a tabela honestamente e a conclusão não é “exterior é melhor.” É que nenhum ponto de vista vê tudo. Tráfego e saturação pertencem às suas ferramentas internas: Prometheus, Datadog, New Relic, qualquer que seja sua pilha APM. Latência e erros na experiência do usuário pertencem ao monitoramento sintético externo. Essa é a metade que o Dotcom-Monitor cobre. Checagens em navegador real de uma rede global carregam suas páginas como os usuários fazem e cronometrizam o caminho todo: resolução DNS, handshake TLS, borda do CDN, renderização da página, passos de usuário roteirizados. Checagens de protocolo para HTTP(S), API, DNS, TCP e ICMP acompanham as dependências ao redor da página. Os dois não competem; são visões diferentes dos mesmos quatro sinais, e você precisa de ambos.

A regra prática: todo sinal que seus usuários possam sentir precisa ter pelo menos uma medição feita de onde os usuários estão. Um painel APM mostrando verde enquanto o CDN entrega páginas de erro em cache a metade da Europa não é hipotético. É o modo padrão de falha do monitoramento interno apenas.

Como Implementar o Monitoramento

• Mantenha tráfego e saturação em seu stack APM ou Prometheus; dê latência e erros para as checagens em navegador real do Dotcom-Monitor rodando das regiões onde seus usuários realmente estão.
• Configure asserções de conteúdo nessas checagens, não só checagens de código de status, para que o checkout quebrado atrás de um HTTP 200 falhe do mesmo jeito que falha para o usuário.
• Roteirize as transações que importam (login, busca, checkout) com o EveryStep, para que o monitoramento percorra o mesmo caminho que seus usuários.
• Compare os números internos e externos regularmente; a lacuna entre eles é sua camada de CDN, DNS e terceiros.

Princípio 5 – Automação

O argumento SRE para automação é consistência em escala. Humanos esquecem passos, máquinas não, e qualquer resposta que precise acontecer às 3 da manhã não deve depender de um humano alerta às 3 da manhã.

A parte que muda fora do Google: automação é tão boa quanto o sinal que a aciona. Scripts de failover, jobs de rollback e regras de autoescalonamento disparam com um evento de detecção, então todo minuto de atraso na detecção é um minuto somado a cada resposta automatizada que você construiu. A matemática da seção SLO se aplica diretamente: um failover automatizado disparado por uma checagem de 5 minutos dá à falha uma vantagem média de 2,5 minutos.

E alguns gatilhos de automação só podem vir de fora. Um script que faz failover para um provedor de pagamento reserva precisa saber que o primário está falhando para os usuários, não só que o endpoint de saúde responde ping dentro da mesma rede. O Dotcom-Monitor fecha esse ciclo disparando alertas e webhooks pelas suas checagens externas, então o failover é disparado pelo que os usuários estão vivenciando, não pelo que o endpoint de saúde afirma.

Como Implementar Automação

• Comece pelas respostas que você já faz manualmente durante incidentes: reinicializações, failovers, rollbacks.
• Integre os webhooks de alerta do Dotcom-Monitor aos scripts que realizam essas ações, para que o gatilho seja uma falha confirmada externamente e não um endpoint interno de saúde.
• Use grupos de escalonamento de alerta para que a primeira notificação alcance a pessoa ou sistema que age, e não uma caixa de entrada compartilhada que ninguém monitora às 3 da manhã.
• Deixe o Filtro de Resposta absorver falhas que se resolvem sozinhas para que elas não acionem suas automações, e revise os gatilhos trimestralmente contra as taxas de falsos positivos.

Princípio 6 – Engenharia de Releases

Engenharia de releases é a disciplina de construir e entregar software da mesma maneira toda vez: builds versionados, pipelines repetíveis, rollbacks que funcionam porque foram ensaiados.

CI/CD moderno cobre a maior parte disso dentro do pipeline. Testes passam, artefatos são construídos, deploys são enviados atrás de flags. O que o pipeline não consegue dizer é se o sistema funciona para usuários após o deploy. CI prova o build; por si só não diz nada sobre o registro DNS que não propagou, o cache do CDN servindo o pacote antigo, a tag de terceiros que quebrou em combinação com seu código novo, ou o valor de configuração que só existe em produção.

É a verificação pós-deploy que preenche essa lacuna. Um script EveryStep que percorre o caminho crítico (carrega a página, faz login, finaliza a transação), rodado da rede do Dotcom-Monitor contra produção imediatamente após cada release, é o único teste que exercita o que os usuários realmente recebem. Times que o adotam tratam como a etapa final do pipeline: deploy, verificar de fora, e só então marcar o release como concluído. Se a checagem falha, o rollback ocorre enquanto o raio de impacto ainda é medido em minutos.

Como Implementar Engenharia de Releases

• Versione todo build e faça rollback ser uma ação ensaiada, de um passo, não improvisada.
• Faça uma transação EveryStep contra produção a etapa final do pipeline de deploy, rodando da rede Dotcom-Monitor para que DNS, cache CDN e tags de terceiros façam parte do teste.
• Direcione o webhook de alerta da checagem de volta para o pipeline, para que uma execução pós-deploy com falha vire um sinal automático de rollback e não um ticket para de manhã.
• Mantenha a mesma checagem rodando entre releases; seu histórico é a linha de base para saber se um deploy deixou as coisas mais lentas.

Princípio 7 – Simplicidade

O capítulo Simplicidade argumenta que confiabilidade e complexidade estão em conflito: cada componente que você adiciona é um componente que pode falhar, e o software deve ser exatamente tão complexo quanto precisa para seu trabalho.

Aplique isso à pilha de monitoramento em si, porque o monitoramento é onde a complexidade se acumula silenciosamente. Times acabam com uma ferramenta APM, uma plataforma de logs, um pingador de uptime, um serviço de página de status e três dashboards que ninguém abre. Cada ferramenta alerta conforme seu próprio cronograma, e o resultado combinado é a fadiga de alertas: tantas notificações que a que importa é apagada junto com o resto.

Um fornecedor de monitoramento dizendo para você usar menos ferramentas de monitoramento é um argumento incomum, exatamente por isso vale a pena fazê-lo. O teste de simplicidade para uma pilha de monitoramento tem duas perguntas. Primeiro: para cada coisa que você monitora, você sabe qual ferramenta é autoritária quando duas discordam? Segundo: cada alerta que dispara tem uma pessoa que age sobre ele? Se uma ferramenta falhar nessas duas perguntas para tudo o que monitora, ela não está monitorando, é barulho com taxa de assinatura. Consolidar monitoramento de uptime, transações, API e infraestrutura numa só plataforma com um caminho único de alerta é uma decisão de simplicidade antes de uma decisão de compra. É assim que o Dotcom-Monitor é construído: essas checagens em um lugar só, um caminho único de alerta, trabalhando junto com a ferramenta APM que monitora o interno, em vez de substituí-la.

Como Implementar Simplicidade

• Inventarie suas ferramentas de monitoramento e anote, para cada uma, a única coisa para a qual é autoritária.
• Delete todo alerta que não tem dono e nenhuma ação associada; se ninguém age, é barulho.
• Integre as checagens externas (uptime, página, transação, API, infraestrutura) no Dotcom-Monitor como uma plataforma única com um caminho único de alertas, e deixe seu APM cuidar do interno.
• Repita a auditoria anualmente; pilhas de monitoramento acumulam complexidade sozinhas.

Melhores Práticas SRE

Os princípios dizem o que buscar. Estas são as práticas que se mantêm nos times que não possuem toda a pilha:

• Defina SLOs no que os usuários experienciam, não no que os servidores reportam. “Checkout finaliza em menos de 4 segundos em um navegador real” é um SLO que os usuários reconhecem. “API p95 abaixo de 200ms” é um insumo para isso.
• Adapte a frequência de checagem ao seu SLO. Conforme a tabela do orçamento de erros acima: em 99,95%, um quantum de 5 minutos já consome 23% do orçamento mensal, e em 99,99% ultrapassa o orçamento completamente. Trate checagens de 1 minuto como o limite prático a partir de 99,95%.
• Monitore suas dependências como monitora a si mesmo. DNS, CDN, pagamento, autenticação: uma checagem externa para cada dependência crítica, com seu próprio histórico de tempo de resposta. Quando a página de status delas mostra verde e seus usuários dizem “quebrado”, esses dados resolvem a disputa.
• Escreva a política de orçamento de erro antes de gastar o orçamento. Concorde de antemão o que acontece quando o orçamento acaba: congelamento de funcionalidades, sprints de confiabilidade, prioridades de postmortem. Um orçamento sem política é um gráfico que ninguém usa.
• Ensaie a resposta a incidentes antes de precisar. Plantões, caminhos de escalonamento e postmortems sem culpados são abordados em profundidade no nosso guia de gestão de incidentes SRE.
• Mantenha honesta a contagem de ferramentas. Audite anualmente a pilha de monitoramento contra as duas perguntas de simplicidade acima. Nossa seleção de ferramentas SRE cobre as categorias que valem a pena.
• Faça do relatório de confiabilidade um hábito, não uma corrida contra o tempo. Relatórios agendados de uptime e SLA fazem a conversa de conformidade começar a partir de números compartilhados, e não de uma caça no log após desacordo.

Conclusão

Os sete princípios SRE sobreviveram à saída do Google. O que não sobreviveu foi a suposição por trás deles: que o time que os aplica controla a pilha onde aplicam. Você não controla, e isso muda o trabalho. O risco que você não pode eliminar pela engenharia precisa ser medido. Orçamentos de erro são tão reais quanto o intervalo da checagem por trás deles. Ferramentas internas monitoram tráfego e saturação; latência experienciada pelo usuário e erros só aparecem de um ponto de vista externo. A verificação pós-deploy precisa rodar de fora, porque só lá o sistema inteiro existe.

O fio condutor comum é a medição de fora. Cada princípio, aplicado a uma pilha cheia de componentes que você não possui, acaba precisando de um ponto de vista independente: checagens por dependência para risco, intervalos de 1 minuto para orçamentos de erro, navegadores reais para os sinais dourados, transações roteirizadas para toil e releases, uma plataforma para simplicidade. Esse é o papel que o Dotcom-Monitor desempenha em todos os sete. Não é preferência de ferramenta — é o que os princípios exigem quando a pilha deixa de ser sua.

Perguntas Frequentes