Tradicionalmente, a engenharia de software foca na arquitetura e desenvolvimento de sistemas. Pesquisas revelam que grande parte dos gastos de uma empresa de software surge após o desenvolvimento e lançamento do produto. A arquitetura e desenvolvimento do sistema é apenas parte da história pois, após seu lançamento é necessário atualizar, implementar novas funcionalidades, corrigir bugs e manter o ambiente estável. Para este ciclo de vida do software é importante que os desenvolvedores tenham habilidades adicionais, envolvendo conhecimento em infraestrutura e operações.
Site Reliability Engineering (SRE) é um termo criado por Ben Treynor Sloos, VP de engenharia do Google enquanto cumpria sua missão de liderar um time de operações composto por 7 engenheiros de software. O que ele fez daí em diante foi projetar e gerenciar essa equipe como se fosse um time efetivamente de engenharia de software. O resultado foi tão positivo que hoje SRE é a metodologia de gerenciamento de operações para todo os serviços dentro do Google.
O foco do SRE está na confiabilidade do sistema. Ben Treynor afirma que a principal característica de um sistema deve ser a confiabilidade. Afinal, um sistema não é muito útil se ninguém puder usa-lo. Com o foco na confiabilidade do sistema, o objetivo do SRE está em encontrar formas para aprimorar o design e a operação dos sistemas para fazê-los mais escaláveis, confiáveis e mais eficientes. O motivo disso é que, quando um sistema está confiável o suficiente, então é possível investir esforços em criar novas funcionalidades ou construir novos produtos.
O que está envolvido em um time de SRE?
Resumidamente: Perfeição e dedicação. Ter em mente a importância da preparação e documentação, ter uma consciência de o que poderia dar errado, juntamente com um forte desejo de evita-lo.
Na abordagem tradicional para times de operações, os sysadmins juntam todas as peças necessárias de software e infraestrutura para que o sistema trabalhe em um ambiente de produção. A partir deste ponto o time de sysadmins atua para mante-lo disponível. Visto que nesta abordagem tradicional as habilidades técnicas dos sysadmins são diferentes das habilidades do time de desenvolvimento, estes dois times trabalham separadamente e ambos crescem de acordo com crescimento do sistema, o tráfego e a complexidade da infraestrutura.
Esse modelo tradicional de gerenciamento de operações tem algumas vantagens, como: facilidade em encontrar profissionais, centenas de ferramentas prontas para uso e uma abundância de consultorias disponíveis para auxiliar na implementação. Em contrapartida, existem desvantagens, principalmente relacionadas a custo com pessoas e conflito de interesses entre o time de dev e o de ops.
Os custos estão relacionados ao crescimento do time de sysadmins de acordo com o crescimento do sistema e aumento do tráfego. Isto se dá porque na abordage tradicional ainda é necessário que várias atividades sejam executadas manualmente, fazendo com que o número de profissionais seja um gargalo. Quanto ao conflito de interesses, o time de sysadmins tem a meta de manter o ambiente o mais estável e confiável possível. Já o time de dev tem como objetivo entregar novas funcionalidades. Como a maioria das indisponibilidades de um sistema são causadas por algum tipo de mudança – como uma nova funcionalidade, os objetivos das duas equipes estão constantemente em tensão. Adicione a isso o fato de as duas equipes possuirem um vocabulário próprio e visões diferentes sobre riscos e confiabilidade do sistema. Não raro essas diferenças resultam em problemas de comunicação, de objetivos, de confiança e em algum casos até mesmo de respeito.
Qual é então a abordagem do Google para gerenciamento de serviços?
A equipe de SRE é composta por engenheiros de software que sustentam o produto e criam sistemas para realizar o trabalho que, de outra maneira, seria feito manualmente por um sysadmin.
O time é composto 100% por desenvolvedores, porém cerca da metade do time, além de saber desenvolver sistemas, também é especialista em alguma tecnologia que não é familiar para um dev, como Redes ou Unix. Como resultado dessa mescla de skills, o time terá competência e condições para rapidamente construir sistemas auxiliares para substituir trabalhos manuais.
O trabalho de engenharia para automatizar processos é fundamental para o ganho em escala. Por isso os times de SRE tradicionalmente gastam 50% do tempo atendendo tickets e trabalhando em atividades operacionais e 50% do tempo devem ser gastos desenvolvendo ferramentas para que o serviço trabalhe automaticamente, ou seja, que o sistema automaticamente se repare e se mantenha em funcionamento, sem interação humana. Quando um time de SRE está gastando mais do que 50% do seu tempo em atividades operacionais, então o gestor do time deve atuar para que seus desenvolvedores voltem a trabalhar em automatizar serviços. O gestor geralmente faz isso adicionando mais profissionais no time ou repassando algumas demandas para o time de produtos.
É interessante destacar a diferença entre ambiente automatizado e ambiente automático, conforme definido pelos SREs do Google. Enquanto sistemas automatizados continuam dependendo de interações humanas em certos momentos, sistemas automáticos são capazes de se reparar e escalar automaticamente, sem auxílio humano. Portanto, o foco dos times de SRE está em criar produtos automáticos, que não dependam de humanos para sua operação e saúde.
No Google todos os times de SRE compartilham um conjunto de responsabilidades básicas e aderem a princípios fundamentais que os apoiam. Em geral, uma equipe de SRE é responsável pela disponibilidade, latência, desempenho, eficiência, gerenciamento de mudanças, monitoramento, resposta de emergência e planejamento de capacidade de seus serviços. Os princípios fundamentais dos times de SRE do Google são:
Para todos esses princípios existe o jeito Google de fazer. A boa notícia é que eles podem ser aplicados em qualquer time de gerenciamento de operações.
SRE e DevOps
A relação do SRE com o DevOps é bem estreita, pois os princípios, como o envolvimento de operações em todas as etapas do desenvolvimento do sistema, a forte dependência da automação, a aplicação de práticas de engenharia e desenvolvimento de ferramentas para atividades operacionais, são consistentes com muitos dos princípios e práticas do SRE. Enquanto DevOps trata uma camada mais conceitual e genérica, o SRE atua como um método de implementação do DevOps e algo a mais.
Este tema é novo e não existe muito material a respeito. Para interessados em se aprofundar, recomendo fortemente a leitura do livro Site Reability Engineering. – How Google runs production systems.