SRE: Site Reliability Engineering

Quando uma empresa tem um alto nível de adoção da cultura DevOps, os times de desenvolvimento começam a entregar cada vez mais rápido e com maior nível de qualidade, a maturidade do ciclo de desenvolvimento de uma empresa já está um pouco mais elevada, e existe uma grande sinergia entre as diversas áreas de um time de tecnologia. Sendo assim, é bem comum surgir a dúvida: “Qual o próximo passo? Como posso melhorar ainda mais meu ciclo de desenvolvimento de software?”.

Com certeza o termo SRE pode ser uma das respostas dessa pergunta. Site Reliability Engineering ou Engenharia de Confiabilidade de Software foi 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.

Muitas pessoas tendem a comparar SRE com DevOps. É bem comum encontrarmos materiais detalhando suas diferenças ou erroneamente direcionando os leitores a optarem por um dos dois. Enquanto DevOps traz várias práticas e princípios que visam entregar software cada vez mais rápido em produção com qualidade, SRE muitas vezes se baseia das mesmas práticas em princípios para que todo o ecossistema da aplicação seja confiável e resiliente, automatizando até mesmo a resolução dos problemas mais comuns no dia a dia.

Existe uma estimativa que cerca de 40% a 90% do custo total de um software, ocorre após a sua entrada em produção. Isso acontece por existir uma série de possíveis pontos de falha no ciclo de desenvolvimento de software, e um alto nível de complexidade para manter um ambiente estável; esse é o foco de um time SRE. Segundo o Google, eles são responsáveis pela disponibilidade, latência, desempenho, eficiência, gerenciamento de mudanças, monitoramento, resposta de emergência e planejamento de capacidade de seus serviços. Para atingir esses objetivos, seus princípios são:

1. Abraçar o risco;

2. Objetivos do Nível de Serviço (SLO);

3. Eliminar o trabalho repetitivo ou desnecessário;

4. Monitorar sistemas distribuídos;

5. Automação;

6. Engenharia de lançamento;

7. Simplicidade.

Em um modelo de operações tradicional, onde não existe nem mesmo a cultura DevOps, podemos encontrar uma série de pontos de falha em todo modelo operacional. Para começar, existe pouca automação, longo ciclo de entrega de software, pouca interação entre os times de desenvolvimento, operações e qualidade, resultando em vários problemas que fazem um ambiente não ser confiável.

Já em times que utilizam fielmente muitas práticas da cultura DevOps, geralmente possuem um processo de integração contínua, que agrega diariamente o trabalho do time de desenvolvimento com o time qualidade, entregando para o time de operações um software muito mais confiável e muito melhor testado, aumentando o nível de confiabilidade e segurança de um modelo de operações.

Já os times de SRE se planejam para deixar todo este ambiente ainda mais seguro e confiável, implementam práticas que criam pipelines de entrega, não só de software, mas também de sua infraestrutura, monitoração, alertas, e muitas vezes a resolução de problemas já mapeados sem nenhum tipo de interação humana.

Seguindo a própria definição do SRE no Google, existe uma grande diferença entre um ambiente automatizado e um ambiente automático. Um ambiente de operações automatizado é um ambiente que depende de algum tipo de interação humana, já um ambiente de operações automático é um ambiente que pode ser reparado sozinho, sem nenhuma interação humana.

Conclusão

Criar um processo que gere confiabilidade não somente no lançamento de novas versões, mas também na resolução dos problemas, é um diferencial para qualquer empresa, por isso empresas como LinkedIn, Netflix, Amazon e Google foram por esse caminho e esse é o caminho comum para a maioria das empresas que possuem ambientes críticos e altamente estratégicos.

Referências

https://www.fernandoike.com/pt/2017/03/23/site-reliability-engineer-sre/

https://www.kalendae.com.br/blog/sre/

Quer saber mais? Veja todos os artigos que escrevemos dessa série sobre DevOps:
https://blog.fcamara.com.br/categorias/devops/