Esperança não é uma estratégia: sete princípios da engenharia de confiabilidade local (SRE)

Engenharia de confiabilidade local, ou SRE, é uma abordagem que trata problemas de operações como se fossem problemas de software. O termo foi originalmente nomeado e descrito em 2003 por Ben Treynor Sloss, engenheiro do Google. Como disciplina, a SRE tem como objetivo manter a disponibilidade, o desempenho e a eficiência de um sistema em particular.

SRE pode ser difícil de definir. É uma abordagem ou disciplina, e não um conjunto prescritivo de tarefas, assumindo diferentes formas de acordo com as necessidades de uma determinada organização. Felizmente, existem sete princípios da engenharia de confiabilidade local que podem ajudar a orientar uma equipe de SRE rumo ao sucesso.

Grande parte do desenvolvimento de software é justamente focada na criação, incluindo o DevOps, um campo relacionado, mas distinto, que se preocupa mais com todo o ciclo de vida de um produto. Mas o trabalho está longe de estar completo quando o sistema é lançado. No prefácio do guia do Google sobre SRE, os autores observam que “40 a 90% dos custos totais de um sistema são incorridos após o nascimento.” A SRE se ocupa do que acontece depois do lançamento, visando garantir que um produto continue o mais utilizável possível.

O elemento mais importante da SRE é a confiabilidade e o tempo de atividade do sistema. O melhor serviço do mundo não pode servir a ninguém se não estiver operacional. A SRE, portanto, foca em minimizar o downtime e criar sistemas confiáveis.

As equipes de SRE também garantem que todos os elementos do produto estejam atualizados, por meio do gerenciamento cuidadoso de atualizações de software e segurança. Normas e regulamentações estão sujeitas a mudanças, e as equipes de engenharia garantem conformidade contínua.

As práticas de SRE também podem trazer economias financeiras. Muitos dos princípios centrais de SRE estão relacionados a eficiências que podem levar a economias significativas de custo e esforço, incluindo automação e gerenciamento de recursos.

Os sete princípios de SRE incluem:    

• A aceitação de riscos
• Objetivos de nível de serviço
• Eliminação de trabalho excessivo
• Monitoramento
• Automação
• Engenharia de lançamentos
• Simplicidade

Embora a SRE esteja fortemente preocupada em gerenciar e limitar o downtime, isso não significa que o objetivo seja manter os serviços com 100% de confiabilidade. Na verdade, um dos pilares centrais da SRE é que 100% de confiabilidade não é apenas irrealista, como também não é necessariamente o resultado mais desejável.

Na SRE, o risco é entendido como um contínuo, em que a redução do risco se torna exponencialmente mais difícil e custosa à medida que se aproxima de 100% de confiabilidade. Tentar passar de 99,99% confiável para 99,999% confiável é muito mais difícil do que passar de 80% para 99%. Os recursos necessários para se aproximar cada vez mais de 100% reduzem a capacidade da equipe de desenvolvimento de executar outras tarefas, como inovar com novos recursos e atualizações. Em vez disso, uma equipe possui orçamentos de erro para representar quantidades apropriadas de falha.

Outro ponto contra a confiabilidade total, por mais contraintuitivo que pareça, é que os clientes normalmente não percebem melhorias de confiabilidade além de um certo limite. Não é apenas custoso; também há pouca recompensa. O ideal é que uma meta seja definida e alcançada, mas não ultrapassada em excesso.

Em vez disso, a SRE utiliza métricas de disponibilidade para medir a aceitabilidade do risco de downtime. Em uma métrica, um ano com 99,99% de confiabilidade incluiria 52,6 minutos de downtime. Métricas mais complexas consideram a possibilidade de downtime em uma localização ou em um elemento de um serviço, enquanto outros permanecem ativos.

Uma equipe de SRE deve avaliar cada serviço e determinar um nível aceitável de falta de confiabilidade. Quanto downtime é aceitável? Diferentes tipos de falhas, originadas de diferentes causas, têm efeitos diferentes na experiência do usuário? Quanto (em termos de trabalho e finanças) custará para ultrapassar esse limite? Onde está o equilíbrio?

Escolher metas e medir quão efetivamente essas metas são alcançadas, e por quê, é vital para uma equipe de SRE. Um objetivo de nível de serviço, ou SLO, é uma meta específica e mensurável que representa um nível de qualidade definido pela equipe de SRE. Esses SLOs podem assumir a forma de várias métricas, mas disponibilidade, taxa de consultas, taxa de erros e tempo de resposta são comuns.

Esses objetivos são medidos por meio de um indicador de nível de serviço, ou SLI, que é uma medição bruta de desempenho, como a latência. Nesse caso, o SLI seria a métrica de latência, e o SLO seria manter essa métrica abaixo de um certo limite. Os SLOs, por sua vez, podem fazer parte de um acordo de nível de serviço, ou SLA, que é um contrato entre provedor e usuário que define os SLOs, bem como as consequências por não atingi-los.

Escolher SLOs pode ser complicado. Idealmente, os SLOs devem ser estruturados em torno do que é mais importante para os usuários. Para um serviço de jogos em nuvem, por exemplo, o SLO pode girar em torno da baixa latência, mas a latência não teria tanta relevância para um serviço de contabilidade.

O ideal é que um engenheiro de confiabilidade local use relativamente poucos SLOs para focar em atingir esses objetivos; o mais importante é acertar a tarefa principal. Definir metas realistas também é importante; como discutido anteriormente, perfeição não é nem realista nem desejável.

Os criadores de SRE fazem questão de definir trabalho excessivo ("toil") como uma categoria de esforço que se sobrepõe, mas não é o mesmo que trabalho. Trabalho excessivo é, na verdade, composto por aquelas tarefas manuais que escalam linearmente, que são tipicamente manuais e repetitivas, e que muitas vezes podem ser realizadas por automação.

Trabalho que precisa ser feito repetidamente é classificado como trabalho excessivo; de preferência, uma tarefa individual deveria exigir apenas uma ou duas execuções. Trabalho que não melhora o produto também é excessivo. “Se o seu serviço permanece no mesmo estado depois de terminar uma tarefa, provavelmente era trabalho excessivo”, escreve Vivek Rau, do Google. Correções de bugs, melhorias de funcionalidades e otimizações não são trabalho excessivo, mas baixar métricas manualmente é. Resposta a incidentes (que pode incluir significativa coordenação entre engenheiros e equipes de operações) não é trabalho excessivo, e as táticas de gerenciamento de incidentes devem ser planejadas antes do lançamento.

Há também o trabalho excessivo cognitivo. Você já teve uma receita básica que usa de vez em quando, mas precisa olhar os ingredientes e medidas todas as vezes? Isso é trabalho excessivo cognitivo: é um desperdício de tempo e esforço ter que reaprender algo repetidamente. Em vez disso, a SRE defende a criação de mais guias e padrões, que eliminam a necessidade de lembrar ou reaprender continuamente metodologias e tarefas.

Uma das partes mais importantes da engenharia de confiabilidade local é o monitoramento: usar ferramentas para medir, analisar e melhorar continuamente os recursos principais e o desempenho do sistema. Esses recursos principais geralmente incluem o que é chamado de os “quatro sinais de ouro” do monitoramento:

Latência: no nível mais básico, quanto tempo leva para atender a uma solicitação? Observe que isso pode variar dependendo se a solicitação foi bem-sucedida ou não; às vezes, uma mensagem de erro pode demorar significativamente mais para ser processada.

Tráfego: qual é a carga ou demanda colocada sobre o serviço? As unidades específicas podem variar; pode ser visualizações de página, transações ou solicitações HTTP.

Erros: geralmente medidos por taxa, os erros podem incluir buscar dados incorretos, buscar dados mais lentamente do que o definido em um SLA ou não conseguir buscar de forma alguma.

Saturação: essencialmente, a saturação é uma medida de quão próximo da capacidade um serviço está. Compreender a saturação é importante porque alguns serviços começam a falhar, a ficar lentos ou a produzir mais erros quando se aproximam de 100% de saturação.

Existem muitas ferramentas de monitoramento que podem coletar dados, definir referências, depurar e analisar problemas, fornecer dashboards de observabilidade úteis e alertar as SREs sobre possíveis interrupções ou outros problemas. Também é importante fornecer relatórios robustos de post-mortem após a resolução de um incidente, explicando o contexto do incidente, causa raiz e gatilhos, impacto, metodologia de resolução e lições para o futuro. Um post-mortem detalhado e objetivo pode ser inestimável para evitar repetir o mesmo erro.

Assim como em muitos outros elementos da tecnologia moderna, o objetivo de incorporar a automação em um fluxo de trabalho é libertar os engenheiros de tarefas repetitivas que não agregam valor. Com esse tempo livre recém-criado, os engenheiros podem então trabalhar em tarefas que a automação não consegue realizar: criação, ideação, orientação em larga escala e mais.

A automação pode ser especialmente valiosa para os seguintes objetivos:

Consistência: o problema das tarefas manuais e repetitivas não é apenas que podem ser entediantes e consumir tempo de ações mais valiosas. Se essas tarefas, como a criação de contas de usuário, forem realizadas por ferramentas de automação, erros e inconsistências podem ser quase eliminados. Um novo funcionário pode fazer as coisas de maneira diferente de um antigo; um usuário pode inserir acidentalmente um valor no campo errado. Um processo automatizado (geralmente) não fará isso.

Escalabilidade: a escalabilidade é um benefício de longo prazo importante da automação. Vamos pegar nosso exemplo anterior de criação de contas de usuário. Se a criação de contas aumentar exponencialmente, a carga de trabalho para o humano responsável pela configuração da conta também aumentará exponencialmente, afastando esse funcionário de outros aspectos potencialmente mais valiosos do trabalho. Um sistema automatizado não terá esse problema.

Velocidade: certas tarefas, como encontrar e corrigir bugs no código, podem levar muito tempo para um humano. Sistemas de software automatizados têm a capacidade de monitorar grandes quantidades de dados e podem frequentemente detectar erros mais rapidamente do que humanos por meio de reconhecimento avançado de padrões e outras ferramentas. As correções podem ser aplicadas com a mesma rapidez, muitas vezes sem qualquer envolvimento humano.

Há também, é claro, perigos que acompanham qualquer processo de automação. Estes incluem:

Custos iniciais: automações precisam ser criadas antes de serem implementadas. Isso pode exigir uma quantidade significativa de tempo, esforço e até custos de hardware. O valor da automação deve ser considerado como um equilíbrio entre o esforço para criá-la e os recursos reais que economizará uma vez lançada.

Manutenção: tarefas automatizadas podem dar a impressão de que podem rodar para sempre, mas isso geralmente não acontece. O código de automação deve ser mantido atualizado e sincronizado com outros códigos e atualizações de sistema. Se novos recursos forem adicionados, o código de automação também poderá precisar ser atualizado por intervenção humana para incluir novas ações ou para evitar erros.

A inteligência artificial oferece algumas possibilidades novas e empolgantes para a SRE, mais obviamente no campo da automação. Tanto os custos iniciais quanto a manutenção podem, teoricamente, ser modulados por novos modelos de IA. Dito isso, a IA também traz novos potenciais pontos problemáticos: alucinação, segurança e privacidade, mais notavelmente.

Engenharia de lançamentos é uma subdisciplina da engenharia de software especificamente focada nas etapas necessárias para, bem, lançar software. Essas etapas incluem versionamento, cronogramas de lançamento, builds contínuos ou periódicos, a seleção e coleta de métricas de lançamento e muito mais. Na SRE, a engenharia de lançamento é incorporada desde o início, e não como uma reflexão tardia; o objetivo é evitar uma designação aleatória de tarefas de lançamento no último minuto.

A engenharia de lançamentos, como disciplina, inclui vários princípios fundamentais. Estes incluem:

Automação e autoatendimento: idealmente, muitos processos de lançamento podem ser automatizados e exigem interação mínima ou nenhuma interação dos engenheiros. Isso garante lançamentos rápidos e estáveis.

Velocidade: na engenharia de lançamentos, uma filosofia de lançamentos rápidos e frequentes é preferida. Ao disponibilizar os lançamentos rapidamente, talvez até com frequência horária durante o período inicial, há menos mudanças entre as versões. Essa velocidade permite testes e solução de problemas mais fáceis.

Compilações herméticas: os processos de compilação devem ser totalmente independentes da própria máquina de compilação, usando os compiladores, bibliotecas e ferramentas mais populares. “Se duas pessoas tentarem compilar o mesmo produto na mesma revisão no repositório de código-fonte em máquinas diferentes, esperamos resultados idênticos”, escreve Dinah McNutt, do Google.

Padrões e políticas: por razões de segurança, é vital que haja verificações em determinadas tarefas, incluindo implementação, alterações no código-fonte, novos lançamentos e mudanças na configuração da compilação.

Grande parte da engenharia de confiabilidade local está a serviço da simplicidade. O software é, escreve Max Luebbe do Google, “inerentemente dinâmico e instável”. Com isso em mente, a simplicidade é fundamental para minimizar potenciais problemas e tentar conter essa instabilidade inerente.

Com esse objetivo, a engenharia de confiabilidade local promove várias tarefas que podem simplificar e esclarecer um projeto.

1. Selecionar cuidadosamente quais funcionalidades incluir é útil, mas pode ser igualmente útil simplesmente excluir todas as funcionalidades que não acrescentem significativamente à utilidade do produto. Mais funcionalidades equivalem a mais complexidade.
2. Lançamentos menores e mais frequentes permitem uma depuração e uma solução de problemas muito mais fáceis. Um novo lançamento com dezenas de novas funcionalidades pode introduzir erros que seriam extremamente difíceis de rastrear. Um lançamento com apenas uma nova funcionalidade? Quaisquer problemas potenciais só podem vir de um único lugar.
3. Da mesma forma, pode ser tentador adicionar complexidade às APIs por meio do uso de múltiplos endpoints, microsserviços e outros elementos. Isso deve ser evitado. APIs mais simples são mais rápidas de configurar, exigem menos documentação e reduzem o tempo e os custos de integração.