Gosta de DevOps? Espere até conhecer o SRE

O que, afinal de contas, é SRE?

A mente brilhante da Google por trás da SRE, Ben Treynor, ainda não publicou uma frase de definição única, mas descreve a confiabilidade do site como “o que acontece quando um engenheiro de software é encarregado do que era chamado de operações”.

O problema inerente é o seguinte: as equipes de desenvolvimento querem lançar novas funções incríveis para o público em geral e vê-los decolar em grande escala. As equipes de operações querem garantir que essas funções não prejudiquem nada. Sempre foi uma grande luta pelo poder, com operações tentando frear o máximo de lançamentos possíveis e desenvolvimento buscando novas maneiras inteligentes de driblar os processos que os bloqueavam. (Aposto que soa familiar).

A SRE elimina as suposições e argumentações sobre o que pode ser lançado e quando. Ela apresenta uma fórmula matemática para dar sinal verde ou vermelho para os lançamentos e dedica a equipe de pessoas com habilidades de operações (chamados de engenheiros de confiabilidade de serviço, ou SREs) para fazer a supervisão contínua da confiabilidade do produto. Como o próprio SRE da Google , Andrew Widdowson, descreve: “Nosso trabalho é como fazer parte da equipe de pit mais intensa do mundo. Trocamos os pneus de um carro de corrida enquanto ele está a 100 mph”.

Não parece tão revolucionário? A grande magia está no funcionamento. Aqui estão alguns dos princípios básicos, que também são algumas das grandes diferenças em relação às operações de TI tradicionais.

Primeiro, os novos lançamentos são destacados em verde com base no desempenho atual do produto.

A maioria dos aplicativos não atinge 100% de tempo de atividade. Assim, para cada serviço, a equipe de SRE define um contrato de nível de serviço (SLA) que estabelece o grau de confiança do sistema exigido pelos usuários finais. Se a equipe concorda com um SLA de 99,9%, ela pode contar com um orçamento para erros de 0,1%. Um orçamento para erros é como o nome já diz: é o limite máximo permitido para erros e interrupções.

Dica dos profissionais: você pode converter SLAs em "minutos de tempo de inatividade" com facilidade usando esta interessante folha de dicas de tempo de atividade.

O truque é este: a equipe de desenvolvimento pode "gastar" esse orçamento para erros como quiser. Se o produto estiver funcionando em perfeito estado, com poucos erros ou nenhum, ela vai poder lançar o que quiser, quando quiser. Por outro lado, se equipe atingir ou exceder o orçamento para erros e estiver operando no SLA definido ou abaixo dele, todos os lançamentos vão ficar congelados até que ela reduza o número de erros a um nível que permita a continuação do lançamento.

A genialidade? Tanto os SREs quanto os desenvolvedores têm um forte incentivo para trabalhar juntos buscando minimizar o número de erros.

Os SREs também sabem codificar

No modelo antigo, você jogava pessoas em um problema de confiabilidade e continuava exigindo uma solução (às vezes por um ano ou mais) até que o problema desaparecesse ou explodisse na cara.

No SRE não é assim. Tanto as equipes de desenvolvimento quanto as de SRE compartilham um só pool de funcionários, ou seja, para cada SRE contratado, há um desenvolvedor a menos disponível (e vice-versa). Assim, se encerra a batalha sem fim acerca do número de funcionários de desenvolvimento e operações e é criado um sistema de autopoliciamento no qual os desenvolvedores são recompensados com mais colegas de equipe quando escrevem códigos com melhor desempenho (ou seja, códigos que precisam de menos suporte de menos SREs).

Os desenvolvedores também colocam a mão na massa

Na Google, Ben Treynor teve que lutar por essa causa e está satisfeito com essa decisão. Na verdade, na grande palestra sobre SRE na SREcon14 , ele enfatiza que deve ser obrigatório garantir esse tipo de comprometimento dos executivos antes de lançar a SRE.

Para resumir, a equipe de desenvolvimento lida com 5% de toda a carga de trabalho de operações (manipulando tickets, oferecendo suporte de plantão, etc.). Assim, eles estão sempre conectados ao produto, veem como ele está funcionando e tomam melhores decisões de codificação e liberação.

Além disso, sempre que a carga de operações excede a capacidade da equipe de SRE, a sobrecarga é atribuída aos desenvolvedores. Quando o sistema está funcionando bem, os desenvolvedores começam a se autorregular aqui também, escrevendo código forte e fazendo lançamentos cuidadosos para evitar problemas futuros.

Os SREs são agentes livres (e podem ser removidos, se necessário)

Para garantir que as equipes continuem saudáveis e felizes, Treynor recomenda permitir que os SREs mudem para outros projetos que queiram ou, até mesmo, mudem de empresa. A SRE incentiva o trabalho em equipe motivado, dedicado e eficaz, portanto, nenhum membro da equipe deve ser impedido de perseguir os próprios objetivos pessoais.

Quando a equipe inteira de SREs e desenvolvedores não conseguem se dar bem e criam muitos problemas em vez de criar um código confiável, há uma medida drástica final que você pode tomar: remover toda a equipe de SRE do projeto e atribuir toda a carga de trabalho de operações direto à equipe de desenvolvimento. Treynor só tomou essa medida poucas vezes na carreira, pois a ameaça de que possa acontecer costuma ser suficiente para gerar um relacionamento de trabalho mais positivo entre as equipes.

Há mais conteúdo sobre SRE do que posso abordar em um só artigo: como a SRE evita incidentes de produção, como as equipes de suporte de plantão são montadas, as regras que elas seguem em cada turno etc.

A abordagem

O setor de TI é cheio de modismos e tendências, para se ter certeza. Em um momento é a nuvem, depois é DevOps, experiência do cliente ou até gamificação. A SRE tem tudo para ser muito mais que isto, até porque envolve muito mais as pessoas e os processos do que a tecnologia que os acompanha. Embora a tecnologia com certeza possa (e é provável que vá) se adaptar ao conceito conforme a SRE amadurece e mais equipes a adotam, você não precisa de novas ferramentas para alinhar as empresas de desenvolvimento e operações em torno dos princípios da Engenharia de confiabilidade do site.

Em artigos futuros, vamos falar disso: etapas práticas para caminhar em direção à SRE e o papel que a tecnologia pode desempenhar.