SRE – Site Reliability Engineering

Tempo de leitura: 10 minutos

Emblema usado pelo time de SRE do Google
Emblema usado pelo time de SRE do Google

Google SRE – Site Reliability Engineering

SRE – Site Reliability Engineering

 

SRE – Site Reliability Engineer. No nosso idioma algo como Engenheiro de Confiabilidade do Site.

Talvez o termo DevOps seja algo que você esteja mais familiarizado, mas caso não esteja, da uma olhada neste outro artigo que escrevi sobre DevOps.

Bem, imaginando que DevOps não é mais um termo obscuro para você quero te mostrar um outro termo, que se ainda não explodiu, logo vai.

Atualmente SRE tem sido usado para descrever vagas de emprego, como uma cultura, como a implementação da cultura DevOps, ou para descrever um time de elite.

Este termo foi criado por Ben Treynor (atual VP de Engenharia do Google) em 2003 e esta documentado no livro Site Reliability Engineering (o’reilly) | Engenharia de Confiabilidade do Google (novatec/o’reilly).

Ben Treynor, criou este termo quando lhe foi dado a responsabilidade de criar/gerenciar um time de operações, definido no livro como “Equipe de Produção”. Isso ocorreu por volta de 2003 e eram 7 engenheiros e ele projetou o time com suas experiências de engenheiro de software. Atualmente o time de SRE do Google ainda segue fiel a suas origens conforme a visão de um engenheiro de software.

Como o mercado gerencia sistemas:
Por muito tempo empresas tem gerenciado seus ambientes de produção com Administradores de Sistema, ou Sysadmins. Como administrar o sistema envolve um conjunto especifico de habilidades em comparação com aquele exigido dos desenvolvedores, então é muito comum vermos a separação entre desenvolvimento e operações. Já vimos isso no meu artigo sobre DevOps.

Como o Google gerencia sistemas, SRE:
No Google é usado outra abordagem para gerenciamento de sistemas, as equipes de SRE. O time é composto por engenheiros de software que operam os produtos e criam sistemas para realizar o trabalho que seria realizado por sysadmins geralmente de forma manual.

“SRE é o que acontece quando você pede a um engenheiro de software para projetar uma equipe de operações” – Ben Treynor

Basicamente a equipe é composta de 50% a 60% Engenheiros de Software, pessoas contratadas para esse papel. Os outros 40%/50% são candidatos que ficaram muito próximos as qualificações de um Engenheiro de Software e que além disso, tinham um conjunto de habilidades técnicas uteis ao time de SRE. Habilidades como expertise no funcionamento interno do Unix e em redes (camadas 1 a 3), um perfil um tanto raro nos engenheiros de software.

O resultado dessa abordagem acabou com as equipes de pessoas que ficavam entediadas rapidamente realizando tarefas manualmente.

Isso porque além do compartilhamento de conhecimento, no Google existe um limite de 50% no trabalho de “ops” para todos os SREs (tickets, plantão, tarefas manuais). Esse limite garante que a equipe de SRE tenha tempo para deixar o serviço estável e operacional. Com o tempo se deixados por conta própria a equipe de SRE deverá acabar com a carga operacional e se envolverá no em tarefas de desenvolvimento pois o serviço basicamente opera sozinho. Eles preferem sistemas automáticos e não apenas automatizados. Na pratica a escala e novas funcionalidades sustentam os SREs.

Segue uma definição segundo Treynor do que é SRE:
“Site Reliability Engineer representa uma ruptura significativa das melhores práticas da indústria existente para gerenciar serviços grande e complicados. Motivado originalmente pela familiaridade – “como um engenheiro de software, isso é como eu gostaria de investir meu tempo para realizar um conjunto de tarefas repetitivas” – tornou-se muito mais: um conjunto de princípios, práticas, incentivos e um campo de atuação dentro de uma disciplina maior que é a engenharia de software.”

DevOps ou SRE?

Percebe-se a familiaridade com que DevOps e SRE estão interligados?

O que o time de SRE enxerga nessa similaridade segundo Treynor no livro?

O termo “DevOps” emergiu na indústria no fim de 2008 e como este texto foi escrito (início de 2016) está num estado de fluxo. Seus princípios básicos – envolvimento das funções de TI em cada fase da definição e desenvolvimento de um sistema, forte dependência da automação versus esforço humano, a aplicação das práticas de engenharia e ferramentas para tarefas operacionais – são consistentes com muitas práticas e princípios de SRE. Poderia ver o DevOps como uma generalização de vários princípios fundamentais para uma ampla e vasta gama de organizações, estruturas de gestão e pessoal. Poderia, de forma equivalente, ver o SRE como uma implementação do DevOps com algumas extensões peculiares.

Vamos conhecer os princípios básicos do SRE:

Garantindo um foco durável na Engenharia
Ja aprendemos que os SREs atuam 50% do tempo em atividades de operações.
Quando este percentual é atingido as atividades excedentes são direcionadas para o time de desenvolvimento de produto, assim funciona um sistema eficiente de feedback, orientando desenvolvedores a criar sistemas que não precisem de intervenção manual. Isso funciona bem quando toda a empresa entende por que o sistema de válvula de segurança existe e dá suporte a meta de não exceder essa margem.

Buscar a maior velocidade de mudança sem violar um serviço SLO (Service Level Objective)
Sabemos que a maioria dos aplicativos não atingem 100% de disponibilidade. Então o time de SRE define com os usuários finais o tempo máximo de disponibilidade do sistema. Se for acordado 99,9% então eles tem 0,01% de orçamento de erro (error budget). Um “error budget” é um limite máximo permitido para erros e interrupções.

A equipe de desenvolvimento pode “gastar” esse orçamento de erro da forma que eles quiserem. Se o produto estiver sendo executado dentro na normalidade, com poucos ou nenhum erro. Mas se atingir ou exceder esse orçamento, operando abaixo do SLO definido, todos os lançamentos (de novas funcionalidades) estão congelados até que o nível volte para dentro do acordado.

Essa pratica faz com que SREs e Desenvolvedores tenham um forte incentivo para trabalharem juntos minimizando os erros e indisponibilidades.

Monitoramento
Os quatro sinais de ouro – The Four Golden Signals – latência, tráfego, erros e saturação.
Você já deve fazer monitoramento como os SREs fazem, mas a dica está nos “quatros sinais de ouro” e vemos a implementação em detalhe no Capítulo 6 do livro.

Latência, é o tempo mensurado ao servir a uma requisição. Fique atento ao tempo que cada erro demora para acontecer.

Tráfego, medida de volume exigida pelo sistema, podendo ser numero de requisições HTTP, I/O ou R/W.

Erros, aqui podemos ter os erros https famosos, bem como uma requisição voltando 200 porém com conteudo invalido, ou seja, um erro. Outro detalhe é se você assume um SLA de resposta de 1 segundo por requisição e seu sistema começa a responder com 2 segundos, você também tem um erro.

Saturação, é uma fração do sistema e o quanto ela esta saturada, podendo ser memória, podendo ser I/O, etc. A saturação esta associada a previsões. Como por exemplo, “se você não expirar seus itens, seu cache vai lotar em 2 horas”

Monitorar disco, CPU e memória nem sempre a única abordagem para monitoramento e se você conseguir aplicar essas dicas de ouro terá um serviço de monitoramento bem coberto.

Resposta a emergências
MTTF (Mean Time to Failure) e MTTR (Mean Time to Repair) são indicadores essenciais para o SRE, principalmente o MTTR.

Registrar e documentar o máximo de incidentes, principalmente os eventos com intervenção humana, vai te ajudar e ter baixos índices de MTTR. Humanos acrescentam latência, e se seu sistema falhar e precisar de um humano e se ele tiver um manual de instruções o seu tempo para recuperar de uma falha vai ser baixo. Mas se seu sistema entrar em emergência, precisar de um humano, e ele não saber como agir, seu tempo para se recuperar da falha vai ser alto. Além do manual de instruções, guia de sobrevivência do plantonista, outras práticas ajudam a disseminar o conhecimento e deixar todos os SREs prontos para incidentes. No Google por exemplo existe um jogo a Roda do Azar (Wheel of Misfortune), onde ocorre simulações de incidentes já ocorridos com os próximos SREs plantonistas.

Gerenciamento de mudança
A maioria dos problemas de indisponibilidade estão relacionados às mudanças nos ambientes/sistemas em produção. Diante disso, rollouts progressivos, fast fail, e rollback podem te ajudar a impactar um numero menor de usuários quando mudanças ruins acontecem. Remover humanos do processo de lançamento também reduz a chance de falhas ao lançar uma mudança. Com isso, velocidade de lançamento de funcionalidades e confiança/segurança no ambiente são adquiridas.

Previsão de demanda e Capacity Planning
O planejamento de capacidade deve levar em conta tanto o crescimento natural do produto, ou seja, adoção do mesmo pelos usuários, quanto o crescimento resultado de eventos como lançamentos de funcionalidades, campanhas de marketing e etc…

Provisionamento
Para o Google o provisionamento dever ser feito somente quando necessário, pois capacidade tem um preço alto. Provisionar novos recursos, ou seja, adicionar mais capacidade, requer muito mais atenção, pois geralmente existe mudança significativa e isso envolve em validar se a nova capacidade esta realmente operacional e vai corresponder com o esperado.

Eficiência e Performance
Até mesmo no Google onde dinheiro é infinito (rsrsrs) o uso eficiente de recursos é uma premissa do SRE. O SRE (o time) se envolve em qualquer tarefa relacionada a utilização de recursos. Os SREs preveem demanda, fazem provisionamento e modificam o software, isso já corresponde a grande parte da eficiência de um serviço. Eficiência e desempenho alinhado ao custo é uma responsabilidade de SRE.

Bom, essas são as bases para o SRE dentro do Google e todo o conteúdo foi extraído do livro e site sobre SRE do Google. Sei que muito do que mostrado tem familiaridade com DevOps e deve ter muita coisa que você já deve usar no seu dia a dia.

Pra mim, opinião pessoal, o SRE cai muito bem na implementação da cultura DevOps, segue os princípios do C.A.M.S e descreve melhor o papel do profissional que atua nessa área, muito melhor do que chamar de DevOps um profissional que atua na disponibilidade e confiabilidade dos sistemas.

O livro é bem extenso, cerca de 600 paginas, mas pode ser lido em qualquer capitulo, é claro que o 1 e 2 devem ser lidos primeiros. Mas depois você pode ler qualquer capitulo e ver como o Google resolve os problemas de forma pontual, log, monitoramento e etc…

Espero que tenha ficado claro pra você o que é o SRE, como é a visão do Google para o profissional que administra sistemas complexos, além de suas similaridades com o DevOps. Vamos abordar mais sobre esse tema no AprendaCloud então se inscreve na nossa newsletter e seja avisado quando novos conteúdos como esse forem lançados.

Forte abraço!

fonte.

Insira o seu endereço de email abaixo para receber gratuitamente as atualizações do blog!

Fique tranquilo, seu e-mail está completamente <strong>SEGURO</strong> conosco!