Você chegou até este post de que maneira? Pesquisou por SRE no Google? Viu este link em alguma rede social como Twitter, ou Linkedin? Recebeu este link de um amigo no WhatsApp? Google, Twitter, Linkedin, WhatsApp são algumas das ferramentas que fazem parte da rotina de milhões de pessoas em todo mundo, assim como tantas outras como Netflix, Facebook, etc. Pense nos motivos que levam as pessoas a utilizar estas ferramentas. Funcionalidades interessantes, ter um app bacana e moderno, bom conteúdo (vamos fingir que isto é sempre verdade), e por aí vai. Se o Google continuasse com sua base de conteúdo atual, retornando resultados relevantes, no entanto demorasse 5 segundos para retornar uma busca, você continuaria a utilizá-lo? Se ao acessar o WhatsApp você não conseguisse enviar stickers no grupo do trabalho, ou mandar um belo “Bom dia” no grupo da família, pois a plataforma apresenta instabilidade constante, você continuaria a utilizá-lo? Imagine chegar em casa depois do trabalho para assistir a sua série favorita, e dia após dia o Netflix apresentasse lentidão na entrega do conteúdo, terrível, não é mesmo?

Uma breve introdução

Com a evolução e disseminação da internet, as pessoas estão cada vez mais cercadas de tecnologia, para realizar tarefas das mais diversas, tanto para fins pessoais quanto profissionais. Os devices (smartphones, laptops, smartvs, etc) são praticamente uma extensão de nós, e através deles interagimos com serviços diversos, para várias finalidades, movimentando negócios bilionários. Conforme os exemplos citados anteriormente, podemos perceber que a reputação destas marcas, com as quais interagimos diariamente, estão fortemente ligadas a responsividade e confiabilidade de seus serviços. Foi neste cenário, onde a confiabilidade tem se tornado peça-chave para estes negócios, que uma nova especialização da área de tecnologia, focada em confiabilidade surgiu: Site Reliability Engineering (SRE), ou em uma possível tradução, algo como Engenharia de Confiabilidade de Site.

Imagine que você recebe uma mensagem de um amigo dizendo que seu blog pessoal está fora. Ok, nada demais, assim que você estiver livre e disposto, você irá checar o que ocorreu. E se quem sabe, você produz cursos e treinamentos, e mantém sua plataforma própria de ensino a distância, e um de seus centenas de alunos lhe manda uma mensagem no Twitter dizendo que não consegue acessar. A criticidade já mudou um pouco, certo? Há dinheiro e reputação envolvida. E se você trabalhasse em um grande banco digital, e recebesse um alarme às 5h da manhã, informando que os clientes não conseguem logar no aplicativo? No mínimo você daria um pulo da cama, com uma trilha sonora imaginária de Vanessa Da Mata - Boa sorte, imaginando o que de pior possa ter acontecido. Esta adrenalina, em maior ou menor grau, sempre existirá quando você é o responsável por corrigir um problema em produção. Neste contexto, o que SRE define são guidelines para tornar mais sistemática e simples a tarefa de responder à incidentes.

Um pouco de história

Apesar deste conceito ser algo relativamente novo, ao menos no mainstream, é uma área que contempla um apanhado geral de várias ideias pré-existentes. Afinal, como disse o pai da Química, Antoine Lavoisier, há mais de 200 anos:

“Na natureza nada se cria, nada se perde, tudo se transforma.”

Na área de tecnologia não é diferente. O termo IT (Information Technology), apareceu pela primeira vez em 1958, na Harvard Business Review, e até hoje é utilizado para descrever a área responsável por desenvolver e manter tecnologias utilizadas para coletar, armazenar e distribuir dados e informações.

De lá pra cá muitas coisas mudaram, obviamente. Computadores do tamanho de uma sala, eram programados e mantidos por um time de pessoas único. Computadores foram diminuindo e se multiplicando ao longo do tempo e algumas pessoas passaram a se especializar em programá-los, e outras em mantê-los funcionando, prestando manutenção e configurações adequadas. Terminais-burros surgiram, conectados a um computador central, mantido por um time, enquanto era utilizado por programadores e usuários. Esses times “mantenedores”, passaram a cuidar de ambas as máquinas usadas pelos usuários. Um usuário escreve um e-email no computador local, e envia isso para um servidor remoto, para ser encaminhado ao destinatário. E isto se replica por centenas, milhares de máquinas, responsáveis por prover sistemas críticos. Estas pessoas que tinham a responsabilidade de manter estas máquinas passaram a ser chamadas de System Administrators (sysadmin), System Engineers ou System Operators. Enquanto isso, os Software Engineers (Engenheiros de Software ou Programadores), eram as pessoas que escreviam o código destes sistemas.

Os computadores diminuíram, programadores começaram a passar mais tempo lidando com infraestrutura, além de apenas escrever código para funcionalidades de negócio, configurando seus ambientes para que seus sistemas pudessem ser executados e validados, de maneira reproduzível e confiável, e em contrapartida, sysadmins começaram a escrever códigos e mais códigos, cada vez mais complexos, para operar e manter infraestrutura em escala. Com esta convergência de atividades e objetivos, estes times começaram a ter mais proximidade. Em pequenas empresas, é normal que uma mesma pessoa, ou equipe, seja focada em ambos os papeis, escrevendo código para infraestrutura e negócio, já em empresas maiores, é comum que haja uma separação de papeis, onde um time escreve, define ferramentas e processos que permitam com que os sistemas sejam mantidos de maneira confiável, enquanto os times de programação focados em negócio possam utilizar estas ferramentas para executarem seus sistemas.

A “junção” destas áreas, com intuito de entregar mais valor ao negócio, é comumente chamada de DevOps ou SRE. Não falarei sobre a cultura DevOps, que surgiu anos depois da definição de SRE, mas deixarei este belo artigo (e talk) do Fernando Ike, profissional referência no assunto.

O que é Site Reliability Engineering?

A área de especialização, ou disciplina, chamada de SRE, foi batizada em 2003, anterior ao movimento DevOps, pelo VP de Engenharia do Google, Benjamin Treynor Sloss, como:

“SRE é o que acontece quando você pede para um Engenheiro de Software projetar/definir uma equipe de operações”.

Surgiu no contexto de que Benjamin, quando entrou no Google, no mesmo ano, recebeu a tarefa de operar um “Time de Produção”, de sete engenheiros, tendo sido a vida inteira um Engenheiro de Software. Desde então, ele projetou e gerenciou este grupo de pessoas da maneira que ele gostaria que isso funcionasse, como se ele mesmo trabalhasse como um SRE. A partir daí, o resto é história, que virou livro, e até hoje é usado como uma bíblia sobre o assunto pelas companhias e indivíduos que decidem implementar, ou se inspirar, nas práticas de sucesso obtidas pela gigante da tecnologia.

O mercado busca — ao menos na teoria, visto a enormidade de vagas pelo mundo buscando por SREs no Linkedin e similares — profissionais que estejam aptos a assumirem esta posição, de modo a se encaixar, ou ajudar a implementar esta disciplina dentro das organizações. Mas de fato, o que seria uma definição mais prática desta área de atuação? Vou usar um exemplo contido no livro Real World SRE, de Nat Welch, que ensina através do nome completo da mesma, Site Reliability Engineering:

Juntando estas três definições, segundo Welch, temos uma definição como:

“The field focused on working artfully to bring about a website that performs consistently well.”

É claro que esta definição traz um monte de dúvidas, sobre a área ou o cargo em questão, gerando perguntas como, “Mas o que um SRE faz?“, “Só atende incidente?”, “É tipo sysadmin?”, “É um DevOps 24x7?”, “É um desenvolvedor que tem acesso à produção?” e por aí vai. E isto é natural. A resposta sobre o que um SRE faz, vai depender da empresa, do contexto em que ele(a) está inserido, assim como um Engenheiro(a) de Backend, de Frontend, um Engenheiro(a) de Qualidade ou de Redes. Nenhuma destas áreas ou papeis possui as mesmas responsabilidades e está sob as mesmas fronteiras em todas as empresas.

Lembrando a definição acima, da qual eu julgo como uma das melhores sobre a área, o objetivo de SRE é trabalhar para garantir que sites e sistemas performem bem com consistência. É neste sentido que seguirei esta série de posts, trazendo uma breve pitada de teorias sobre a disciplina, somada a algumas opiniões pessoais, além de dicas que podem ser úteis para você que já trabalha, pretende trabalhar ou apenas quer saber um pouco mais sobre o assunto.

No próximo post falarei um pouco sobre SRE como um framework, trazendo a famosa pirâmide de sete camadas, chamada de “Service Reliability Hierarchy“.

Espero que esta leitura tenha sido útil até aqui. Um abraço e até a próxima!

Este post também está no dev.to!

Referências:

Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (2016). Site Reliability Engineering: How Google Runs Production Systems. “ O’Reilly Media, Inc.”. https://landing.google.com/sre/sre-book/toc/index.html.

Welch, N. (2018). Real World SRE: The Survival Guide for Responding to a System Outage and Maximizing Uptime. Packt.

Leavitt, H. J., Whisler, T. L. (1958). Management in the 1980’s. Harvard Business Review. https://hbr.org/1958/11/management-in-the-1980s

Fernando Ike. (2020). DevOps é cultura ou ferramenta? https://www.fernandoike.com/2020/04/30/devops-%C3%A9-cultura-ou-ferramentas/