SRE – Site Reliability Engineering

Site Reliability Engeneering (em português, Engenharia de Confiabilidade de Sites) é um termo criado pelo Google para resolver um problema crônico que era o conflito entre times de desenvolvimento e operações.

O Google passou a contratar Engenheiros de Softwares para realizar o trabalho que seria feito manualmente por administradores de sistemas. Com os Engenheiros de Software, trabalhos que antes eram realizados de forma manual, passaram a ser sistematizados/automatizados.

Mas e os Administradores de Sistemas? Essa profissão está com os dias contados?

É muito difícil afirmar, mas vendo pelo lado da agilidade que tudo se encontra atualmente, cada vez mais essa profissão vai perdendo espaço para times multifuncionais, com capacidade de manter essa frente.

De acordo com o Google, os SREs devem operar em um modelo em que 50% do trabalho realizado por cada engenheiro é em tarefas de “Ops”, como resolução de problemas, plantão e intervenções manuais. Os outros 50% são gastos com desenvolvimento de novas funcionalidades, escala e automação.

Então na definição de Ben Treynor Sloss do Google, o significado de SRE é:

“O que acontece quando pedimos para um engenheiro de software projetar um time de operações”

Muitas empresas vêm adotando o SRE, e ajustando os processos e terminologias para sua própria transformação SRE.

DevOps ou SRE?

Muitos ainda confundem DevOps com o SRE, mas existem várias diferenças e semelhanças entre esses termos.

De acordo com o Google, o SRE é uma implementação do DevOps – mas não é tudo DevOps. SRE está mais para uma função de trabalho, enquanto DevOps vai além disso. DevOps é um trabalho de todos. Ele pode ser definido como um conjunto de práticas, diretrizes e cultura projetada para quebrar silos em desenvolvimento de TI, operações, arquitetura, rede e segurança. Já o SRE é um conjunto de práticas que encontramos para trabalhar, algumas crenças que animam essas práticas e uma função de trabalho.

Quais os princípios e práticas do SRE?

De acordo com o livro The Site Reliability Workbook, o background do SRE é composto pelos seguintes temas abaixo:

1. Operações é um problema de software

O seu princípio básico é que executar bem as operações é um problema de software, portanto deve-se usar abordagens de engenharia de software para resolver esse problema. Tudo que tem a ver com operações, agora é baseado em software.

2. Níveis de serviço

Aqui vou falar brevemente sobre esse assunto e seus termos, uma vez que os níveis de serviço merecem uma atenção especial e um artigo especialmente sobre. Os principais conceitos de níveis de serviços são:

SLO (Service Level Objective) – Objetivo de nível de serviço é uma meta de confiabilidade do seu serviço. No SRE os serviços são gerenciados para o SLO. A violação de um SLO pode gerar graves consequências.

SLI (Service Level Indicator) – Indicador de nível de serviço indica o nível do serviço que está sendo fornecido.

SLA (Service Level Agreement) – Acordo de nível de serviço é um contrato de negócio que entra em vigor quando seus usuários estão tão insatisfeitos que você precisa compensá-los de alguma forma.

3. Toil

É definido como qualquer tarefa realizada por um membro do time de operações que é executada manual, repetidamente e pode ser automatizada. Automatizando essas tarefas repetitivas, os SREs podem se concentrar em tarefas que adicionam valor para a organização. Como vimos antes, é recomendado que 50% do tempo do engenheiro seja gasto nesse tipo de tarefa.

4. Automação

O verdadeiro trabalho nessa área é determinar o que, em que condições e como automatizar. Adotar uma abordagem baseada na engenharia para os problemas, em vez de apenas trabalhar neles continuamente. Não automatize um processo ruim, conserte o processo primeiro.

5. Reduzir o custo da falha

Procure sempre melhorar o MTTR (Mean time to repair) – Tempo médio para reparo, pois os engenheiros não precisam perder tempo e se concentrar na limpeza após esses problemas. Quanto mais tarde no ciclo de vida do produto um problema for descoberto, mais caro será para consertar.

6. Responsabilidade compartilhada

Os engenheiros compartilham um conjunto de habilidades com equipes de desenvolvimento de produtos. A fronteira entre os times deve ser removida.

Conclusão

O Google criou o termo SRE e suas práticas, mas você pode adequar esse padrão para a sua empresa de acordo com as suas necessidades.

Lembre-se sempre dos princípios do SRE e defina bem suas métricas. Tenha um ambiente de monitoramento adequado (assunto para outro tópico), procure por defeitos o quanto antes e esteja pronto para reagir assim que surgir um problema.

Existem certificações para SRE, que podem serem encontradas no site do DevOps Institute.

Também existem treinamentos preparatórios para essa certificação que são ministrados pela empresa de treinamentos Quode.

Estude, aprofunde seu conhecimento cada vez mais, pois o mercado de trabalho está cada dia mais procurando profissionais com essas qualificações.