Insights

Notícias, novidades e informações sobre o mundo Hard Tech

Site Reliability Engineering: O que é e quais os principais riscos?

por: Inmetrics em

| 15.05.2019

Ben Treynor Sloos, VP de engenharia do Google nos EUA, é o criador do termo Site Reliability Engineering (SRE). Lançado em 2003, o conceito de SRE é o resultado de quando você pede a um engenheiro de software para projetar uma função de operação. Ou, nas palavras de Treynor, quando “um sistema não é muito útil, pois  ninguém consegue usá-lo”.

No mercado de tecnologia, entende-se que SREs são quando engenheiros de software são os responsáveis por assegurar que todos os serviços on-line são confiáveis e rápidos o tempo todo. Por falar em confiabilidade (reliability), ela  é a característica mais importante do seu projeto, produto ou serviço, pois incorpora aspectos de negócio como métricas e operação de TI.

O termo nasceu em uma missão de Treynor em liderar um time de sete engenheiros de software. A partir daí o trabalho foi projetar e gerenciar essa equipe de forma a focar mais na confiabilidade do que na disponibilidade. O resultado foi tão positivo que o SRE transformou-se na forma de gerenciar  todos os serviços dentro do Google, olhando para confiabilidade do sistema como a raiz de todos as ações.

Além do Google, o conceito de SRE foi adotado por empresas como Netflix, LinkedIn e Amazon, que possuem plataformas baseadas em nuvem. Outro casos de utilização são Mastercard, ING e JPMorgan, que possuem plataformas heterogêneas, de cloud a mainframe, e optaram por montar “tiger teams”, que estruturam a prática de maneira centralizada.

No Brasil, o SRE ainda é pouco utilizado nas organizações. Mas ganhou um grupo de entusiastas que pretende mudar esse cenário por aqui. O “São Paulo SRE, Observability and Automation Meetup” foi criado em dezembro de 2018 e realiza encontros para a discussão do tema. A nova aposta das organizações já é uma tendência no setor com impactos consideráveis no mercado de trabalho, na oferta e na busca por vagas na área.

O RISCO

Recentemente, no evento DevOps Enterprise Summit London, Stephen Thorne, engenheiro de SRE no Google, falou sobre como algumas organizações têm enfrentado dificuldades para entender as premissas básicas da metodologia.

Os principais mal-entendidos que Thorne percebeu foi confundir os Service Level Objectives (SLOs) com Service Level Agreements (SLAs) pois, embora ambas possuam aspectos em comum, são bem diferentes na prática. “O SRE precisa de SLOs com consequências que equilibram um nível aceitável de falha com o custo e a velocidade de entrega necessários”, completou ele.

O SLA (Service Level Agreement) é um acordo entre as partes contratantes no que se referente aos aspectos qualitativos da entrega do serviço. É com ele que se definem multas, gratificações, responsabilidades e garantias. Já os SLOs são as características mensuráveis do SLA, tais como: disponibilidade, frequência, tempo de resposta e qualidade. Estes conceitos, quando bem gerenciados durante o ciclo de vida dos projetos, constituem fatores elementais na avaliação do prestador de serviço e da performance.

Dentro dos SLAs encontramos os SLOs (Service Level Objectives ou Objetivos de Nível de Serviço), que são os tópicos efetivos a serem medidos dentro dos SLAs. É lá que achamos a lista do que um prestador de serviços deve oferecer em níveis.

Na prática, dentro das organizações, Stephen Thorne, indica que as metodologias devem ser adequados para cada organização. A premissa deve ser o foco em melhorar continuamente a experiência dos clientes, e não em estabelecer metas elevadas ou punições duras que possam ser contraproducentes. Ele apresenta 5 passos fundamentais para o SRE, que a gente compartilha com você a seguir:

  1. Definir SLOs focados no cliente;
  2. Definir de forma sensata a políticas de “Error Budget” (explicar antes em “artefato);
  3. Contratar profissionais de SREs e capacitá-los através de suporte de liderança;
  4. Permitir que os profissionais ajustem os SLOs e apliquem políticas de “Error Budget”;
  5. Atribuir a responsabilidade pela confiabilidade dos sistemas críticos às equipes de SRE, e a responsabilidade de outros sistemas para equipe de desenvolvimento tradicional (tem que dizer a diferença desses profissionais em “artefatos”).

E se você tem curiosidade em saber mais sobre o assunto, existe um site do Google tratando especificamente sobre SRE: https://landing.google.com/sre/ . Vem ver!

Se interessou pelo assunto? Entre em contato conosco.

Escrito por:

Thiago Maciel, Tech specialist Inmetrics