Ícone do site Insights BRQ

SRE – Extreme Quality

O que é SRE? Com certeza você já ouviu muito sobre SRE e talvez não saiba do que se trata. 

SRE é uma sigla que significa Site Reliability Engineering, em português “Engenharia de Confiabilidade de Sites” e foi criada por Ben Treynor no Google em 2003. Ben era responsável por manter alguns sites do Google funcionando com alta disponibilidade e garantindo entregas contínuas sem impactar a experiência do cliente. A partir desse desafio, Ben e seus engenheiros reuniram as boas práticas adotadas para que os sites fossem confiáveis no aspecto de segurança, escaláveis e altamente disponíveis.  

Hoje em dia algumas empresas utilizam Services ao invés de Sites, o conceito é o mesmo! 

Invisible Customer Experience 

Você percebeu que tem tudo a ver com Customer Experience e nem falamos de navegação de telas e usabilidade? 

Pois bem, os profissionais SRE são praticamente CX invisíveis, com mindset Lean, proativos, propositivos, que acordam todos os dias pensando em como melhorar a engenharia de software para manter disponível os serviços aos clientes, automatizar e melhorar a forma de como os serviços são entregues aos clientes (deploy) para que não haja impacto no que já está funcionando.  

Quando falamos sobre qualidade e disponibilidade, estamos falando em entregar uma experiência fluída para o cliente de um serviço que não “para do nada”, um serviço seguro que não vazará seus dados, que conclui o que se propõe a fazer e de alta performance. 

O trabalho desses engenheiros consiste em primeiramente estabelecer processos e métricas. Toda empresa precisa ter claro como funciona o processo.  

Acordos de níveis de serviço –  SLI, SLO e SLA 

SLI (Service Level Indicator)  

O que está sendo medido e qual é o target

Observability na veia, sua aplicação precisa ser observável com indicadores direcionados à jornada de negócio. 

Exemplo: 

(Ver conceito percentil: https://pt.wikipedia.org/wiki/Percentil).

Exemplo: indicadores importantes para serem medidas, por exemplo: Bugs, Latência, Aumento de tráfego e Saturação.  

SLO (Service Level Objective

O quão bom deve ser? – É um acordo interno entre todas áreas envolvidas.  

Importante saber que quanto mais alto o SLO maior é a complexidade para atender a disponibilidade. Abaixo coloquei uma tabela que mostra de maneira simples o tempo que seu serviço pode ficar fora, de acordo com a quantidade de noves que são definidos na disponibilidade. 

SLA (Service Level Agreement 

SLO + Quais ações serão tomadas caso a empresa não cumpra o acordo? 

O SLA é um acordo externo, onde a empresa define quais ações serão tomadas caso o SLA não esteja dentro da normalidade. As ações devem ser focadas para o cliente, como por exemplo: 

Importante na definição entre SLO e SLA é estruturar métricas desafiadoras, mas com uma margem de manobra. Caso a empresa estoure o prazo do SLO, não impacte paralelamente o SLA. 

Dentro das ações do SLA, existe claramente a ação para o cliente, mas existem diversas ações internas de escalation para resolver o problema o mais rápido possível, pois é o momento onde a empresa está perdendo dinheiro, imagem e reputação. 

SRE não é DevOps 

O DevOps é um conceito cultural, unindo os times Dev e Ops, alinhado com o mindset de automação e agilidade, aplicando as melhores práticas de Engenharia de Software de acordo com cada desafio de negócio.  

No caso do SRE, tem a missão de alcançar níveis de serviço mais elevados e desafiadores para o negócio. 

Não é entregar código que estamos falando. mas sim cuidar do cliente. 

Quando temos a cultura DevOps aliada a um time de SRE assumindo o accountability do negócio, quem ganha é o cliente. 

Adilson SouzaGerente Executivo na BRQ

Sobre o Autor
Sair da versão mobile