SRE: o papel vital do engenheiro de confiabilidade do site

À medida que o mundo mudou para o on-line, a confiabilidade de sites, aplicativos em nuvem e infraestrutura em nuvem tornou-se um imperativo crítico para os negócios – desde operações de comércio eletrônico a bancos globais e mecanismos de busca. 

A maneira como gerenciamos os sistemas e suas cargas de trabalho mudou. Hoje, raramente pensamos em termos de servidores preciosos, de alto toque e desempenho, mas, em vez disso, rack sobre rack de servidores básicos reunidos por meio da virtualização, com arquitetura de software distribuída, impedindo que interrupções no servidor causem tempo de inatividade.  

O foco mudou do hardware para a infraestrutura definida por softwares e de processos manuais inconsistentes e propensos a erros para tarefas automatizadas consistentes, confiáveis e repetíveis. 

A engenharia de confiabilidade do site é a prática de manter essa infraestrutura programável e maximizar a disponibilidade das cargas de trabalho executadas nela.

O cargo de engenheiro de confiabilidade do site teve origem nos corredores do Google, que, na virada do milênio, queria redefinir o relacionamento entre desenvolvedores de software e equipe de operações – e ajudá-los a trabalhar juntos para criar sistemas robustos e flexíveis, com melhoria constante e automação como princípios fundamentais. 

O que é um SRE? 

No nível básico, os SREs trazem os princípios de engenharia de software para problemas de infraestrutura e operações, com o objetivo principal de criar sistemas altamente escaláveis e confiáveis. 

“Fundamentalmente, é o que acontece quando você pede a um engenheiro de software para projetar uma função de operações”, disse Ben Treynor, Vice-Presidente de Engenharia do Google e padrinho da SRE. 

A principal responsabilidade das SREs é estabelecer limites de nível de serviço, geralmente manifestos como objetivos de nível de serviço (SLOs), que ajudam a informar se uma liberação é ou não recebida.  

O Santo Graal é sempre o sagrado ‘cinco noves’ ou 99,999% de tempo de atividade. Quanto melhor o tempo de atividade, mais desenvolvedores conseguem lançar coisas legais e mais dormem os SREs, levando a um relacionamento mutuamente benéfico entre as funções, muito distante dos velhos tempos de antagonismo de desenvolvedor e operações. 

Uma função SRE normalmente será medida em um conjunto de métricas-chave de confiabilidade, a saber: desempenho do sistema, disponibilidade, latência, eficiência, monitoramento, planejamento de capacidade e resposta a emergências. 

Principais responsabilidades de um SRE 

Qualquer bom SRE ficará obcecado por uma coisa em particular: automação. 

Como Jason Qualman, um SRE da empresa de monitoramento de software New Relic, declara em um post no blog: “Muito desse papel é pensar em coisas ineficientes e demoradas que as pessoas estão fazendo e acabar com elas o mais rápido possível.

Em vez de chutar uma lata no caminho do trabalho manual, você está dizendo: ‘Vou dedicar um tempo para automatizar isso agora e impedir que outras pessoas tenham que fazer essa coisa dolorosa’”. 

Outro elemento-chave da função de SRE é o chamado “engenharia de lançamento”, que envolve a definição de práticas recomendadas para garantir que os lançamentos de software sejam consistentes e repetíveis. 

“Os engenheiros de lançamento têm um entendimento sólido (se não especialista) do gerenciamento de código fonte, compiladores, linguagens de configuração de compilação, ferramentas de compilação automatizadas, gerenciadores de pacotes e instaladores. Seu conjunto de habilidades inclui um profundo conhecimento de vários domínios: desenvolvimento, gerenciamento de configuração, integração de testes, administração de sistemas e suporte ao cliente”, escreveu Dinah McNutt, Gerente de Programa Técnico do Google, para o livro Site Reliability Engineering (publicado por O’Reilly em 2016 e de autoria dos googlers Jennifer Petoff, Niall Richard Murphy, Chris Jones e Betsy Beyer). 

Depois, há a parte de resposta da função, que envolve alertar, estar de plantão e solucionar problemas, juntamente com respostas a emergências e incidentes e post-mortem. 

Essencialmente, é importante que os SREs saibam como monitorar melhor os sistemas e reagir quando algo der errado, constantemente escrevendo e reescrevendo os manuais de respostas para reduzir o tempo e para corrigir qualquer falha que possa ocorrer. No Google, isso envolve documentar um incidente, entender todas as causas principais que contribuem e implementar futuras ações preventivas. 

“Escrever um post-mortem não é uma punição – é uma oportunidade de aprendizado para toda a empresa”, escrevem os Googlers John Lunney e Sue Lueder em um capítulo do livro Site Reliability Engineering. 

Engenheiros SREs vs. Devops 

Eu sei o que você está pensando. Tudo isso parece muito com devops, mas quando se trata de terminologia, o cargo do SRE realmente antecede o devops engineer por cerca de cinco anos. 

Ambos são baseados em princípios semelhantes, mas a diferença é sutil e importante. Ambas as formas de trabalho envolvem quebrar as barreiras entre desenvolvedores e equipe de operações, e ambas visam aumentar a velocidade das equipes de desenvolvedores, mantendo a resiliência principal desses serviços. 

A principal diferença é que os engenheiros de devops tendem a se concentrar no suporte à entrega contínua e à velocidade do desenvolvedor, enquanto os SREs assumem a responsabilidade pela confiabilidade e automação durante todo o ciclo de vida do software, com ênfase na implantação e no monitoramento bem-sucedidos de releases, bem como na manutenção da infraestrutura definida pelo software. O SRE tem uma função integral dentro da equipe de engenharia mais ampla: garantir que haja um assento de especialista na mesa focado na construção de sistemas estáveis. 

Como Jayne Groll, do The Devops Institute, coloca: “O Devops se concentra na engenharia de entrega contínua até o ponto de implantação; A SRE se concentra na engenharia de operações contínuas no ponto de consumo do cliente”. 

A história do SRE no Google 

Rastrear os princípios do SRE de volta às suas origens no Google no início dos anos 2000 fornece uma lição de objeto essencial na disciplina. 

“Quando cheguei ao Google, tive a sorte de fazer parte de uma equipe parcialmente composta por pessoas que eram engenheiros de software e que estavam inclinados a usar o software como uma maneira de resolver problemas que historicamente foram resolvidos manualmente. Portanto, quando chegou a hora de criar uma equipe formal para realizar esse trabalho operacional, era natural adotar a abordagem ‘tudo pode ser tratado como um problema de software’ e executá-la”, afirmou Ben Treynor em entrevista no blog interno do Google. 

 “Portanto, o SRE está fazendo fundamentalmente um trabalho que historicamente foi feito por uma equipe de operações, mas usando engenheiros com experiência em software e apostando no fato de que esses engenheiros são inerentemente predispostos e têm a capacidade de substituir a automação pelo trabalho humano, acrescenta Treynor. 

O Google também pensa rigidamente sobre como montar uma equipe de SRE. Todos os SREs do Google devem ser Google Software Engineers ou “candidatos muito próximos das qualificações da Google Software Engineering”. Eles também devem ter habilidades de gerenciamento de infraestrutura, mais comumente “experiência em sistemas internos e redes Unix (Camada 1 a Camada 3). 

As qualificações de SRE ainda tendem a variar de empresa para empresa, mas, no que diz respeito aos princípios básicos, a abordagem do Google é um sólido ponto de partida. Os detalhes dependerão das necessidades de negócios, processos estabelecidos e pilha de tecnologias já adotadas pela organização. 

Descrição e salário da função SRE 

Os SREs normalmente gastam cerca de 50% de seu tempo executando funções operacionais tradicionais, como estar de plantão e entrar para resolver problemas. Os outros 50% estão focados no desenvolvimento de software para tornar os sistemas subjacentes mais resilientes, automatizados e com autocorreção ao longo do tempo.  

É por isso que a função exige uma sólida mistura de habilidades de operações e de engenharia de software. Um bom SRE será organizado, frio sob pressão e um solucionador de problemas. Os gerentes de SRE são responsáveis pelo desempenho, estratégia e otimização da equipe. 

 Mas e as organizações nas quais a função de SRE não existe? No relatório O’Reilly “O que é SRE?”, Kurt Andersen do LinkedIn e Craig Sebenik da Split (um fornecedor de software de gerenciamento de lançamento) recomendam adotar uma abordagem “popular”. Eles recomendam encontrar “uma equipe de desenvolvimento motivada a mudar e implementar uma pequena equipe de SRE (ou indivíduo) lá. Com o tempo, você pode usar esse sucesso como um exemplo positivo para outras equipes”.  

O salário médio anual de um SRE é de aproximadamente US$ 130.000 nos EUA e £ 76.000 no Reino Unido, de acordo com o Indeed. 

Recursos SRE  

Existem muitos recursos para desenvolver habilidades de SRE, desde certificações do DevOps Institute a livros e recursos on-line da O´Reilly, Microsoft e Google. O já mencionado Site Reliability Engineering, de Jennifer Petoff, Niall Richard Murphy, Chris Jones e Betsy Beyer, é o livro mais comentado sobre o assunto, publicado em 2016. O livro também está disponível on-line gratuitamente no Google. 

Outros livros mais recentes sobre o tópico incluem Training Site Reliability Engineers, de Jennifer Petoff, JC van Winkel e Preston Yoshioka; Whta is SRE?, por Kurt Andersen e Craig Sebenik; Seeking SRE, por David N. Blank-Edelman; e The Site Reliability Workbookpor, de Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara e Stephen Thorne. 

O O’Reilly também tem uma biblioteca abrangente de ativos, vídeos e e-books on-line sobre o assunto, com curadoria prática desta lista de reprodução do SRE Essentials da ex-engenheira de confiabilidade de sites do Google, Liz Fong-Jones. 

A plataforma de aprendizagem on-line Coursera oferece vários cursos, incluindo a popular Site Reliability Engineering (SRE): The Big Picture, do Google Cloud Training. Este curso também está disponível na Pluralsight, assim como o curso para iniciantes Site Reliability Engineering (SRE): The Big Picture, de Elton Stoneman. A Linux Foundation oferece um curso autoguiado intitulado DevOps and SRE Fundamentals: Implementing Continuous Delivery.