Uma das minhas mais recentes imersões em conhecimento foi destinada ao SRE – Site Reliability Engineering (Engenharia de Confiabilidade de Site). Essa imersão me permitiu escrever este guia, que vem temperado com um pouco de opinião.
O que é SRE?
SRE é o acrônimo de Site Reliability Engineering (ou Engenharia de Confiabilidade de Site).
Site Reliability Engineering (SRE) é uma disciplina que incorpora aspectos da engenharia de software e os aplica a problemas de infraestrutura e operações.
O SRE foi criado no Google por volta de 2003 e divulgado principalmente por meio de livros.
Você pode consultar todas as publicações e documentação adicional sobre SRE gratuitamente (em inglês) em: https://sre.google/books/
Uma das principais características do SRE é que ele aplica um foco de engenharia às operações.
Cenários e situações onde o SRE é (mais) aplicável
Mais importante do que responder do que se trata o SRE, é refletir sobre suas motivações.
A Google é a empresa responsável por “arquitetar” o SRE. E o motivo de terem desenvolvido tal framework se deu por conta da necessidade de manter a confiabilidade dos seus serviços mesmo diante de um crescimento exponencial de sua base de usuários/clientes.
Só pra você ter uma ideia. Há quase 4,39 bilhões de usuários de Internet, o que significa que o número de usuários do Google em todo o mundo é de quase quatro bilhões.
Seria impossível o Google ampliar os recursos para fornecimento de serviços na mesma proporção em que sua base de clientes aumenta.
E aí que entra uma das questões fundamentais que o SRE endereça: a confiabilidade de serviços em cenários de crescimento exponencial.
Em linhas gerais, temos as seguintes dimensões de crescimento (escala):
- Crescimento da plataforma, quando há grandes volumes de usuários, fluxos de dados irregulares e migração de arquiteturas legadas para modernas.
- Crescimento do escopo, quando há novos produtos / serviços sendo introduzidos.
- Aumento de tickets, como volume de incidentes e requisições.
Se uma organização está crescendo por um destes motivos, o SRE é uma resposta adequada para lidar com este desafio.
Isso não significa que não podemos utilizar o SRE como referência para adaptar práticas de ITSM em cenários distintos dos que foram citados acima.
Ao longo deste artigo pretendo trazer alguns destes insights.
Como o SRE se integra ao ecossistema de frameworks de gerenciamento?
Com tantos frameworks e modelos já disponíveis, fica sempre aquela dúvida: o que de realmente novo o SRE pode trazer para o gerenciamento de serviços de TI?
Antes de mais nada, é importante ressaltar que o SRE foi uma maneira que o Google encontrou para aplicar conceitos de engenharia de software em operações e resolver seus problemas internos como organização. Eles provavelmente não pensaram em tornar público esse conhecimento em um primeiro momento.
Dito isso, voltamos a questão de como o SRE se encaixa no ecossistema de frameworks.
O Google assume que o SRE é uma forma de implementação do movimento DevOps (ou parte dele).
Essa afirmação é bastante questionada pela comunidade por conta do SRE ressoar bastante nas operações.
Justamente por ser mais alinhado às operações, o SRE consegue contribuir com a retroalimentação de toda uma cadeia de valor através da sabedoria de produção.
Além disso, o SRE trás luz e inovação à muitas práticas de ITSM, conforme explico a seguir.
Gerenciamento de nível de serviço
Embora seja visto sob uma ótica puramente técnica, o coração da engenharia de confiabilidade de sites está nos níveis de serviço.
Sabemos que o termo SLA tem sido sobrecarregado e pode significar desde um contrato até uma cláusula de tempo de resposta a requisições.
Para o SRE , existem quatro conceitos chave para definir e monitorar níveis de serviço:
- SLA – Service Level Agreement (Acordo de Nível de Serviço) – um contrato explícito ou implícito com seus usuários que inclui as consequências de cumprir (ou não) os SLOs que eles contêm. As consequências são mais facilmente reconhecidas quando são financeiras – um desconto ou uma penalidade – mas podem assumir outras formas.
Uma maneira fácil de dizer a diferença entre um SLO e um SLA é perguntar “o que acontece se os SLOs não forem atendidos?”: se não houver uma consequência explícita, você quase certamente está olhando para um SLO.
The SRE Book
- SLO – Service Level Objective (Objetivo de Nível de Serviço) – especifica uma meta para a confiabilidade do serviço, por exemplo, a taxa de sucesso de 98%.
- SLI – Service Level Indicator (Indicador de Nível de Serviço) – um indicador do nível de serviço que está sendo fornecido. Ex: taxa de sucesso de solicitação de http 99%.
- Error Budgeting (Orçamento de erro) – é a quantidade máxima de tempo que um serviço pode falhar sem consequências contratuais.
O orçamento de erro é uma interessante inovação apresentada pelo SRE para equilibrar a confiabilidade do serviço com o ritmo da inovação.
É fato que as mudanças são uma importante fonte de instabilidade. E o trabalho de desenvolvimento de recursos compete com o trabalho de desenvolvimento pela estabilidade.
Nesse sentido, o orçamento de erro forma um mecanismo de controle para desviar a atenção para a estabilidade conforme necessário.
Vamos pegar um exemplo prático para ilustrar estes conceitos.
Se um serviço tem uma taxa média de login de 1.000 por hora em um período contínuo de 31 dias (mês) ou 744.000 por mês (31 * 24 * 1000)
Suponha que a organização defina que 99% dos logins a cada mês sejam bem-sucedidos. Este é um “objetivo de nível de serviço”. Isso equivale a “perder” cerca de 7.440 logins por mês (este é o orçamento de erro).
Um indicador de nível de serviço (SLI) é usado para informar quantos logins reais foram feitos em um mês.
Se mais 7.440 logins forem perdidos em um mês, há uma violação do orçamento de erro. E a falha em atingir um SLO requer consequências.
Estas consequências são definidas em políticas de orçamento de erro. Neste caso, poderia ser acionado um período de proteção de negócio, evitando novas liberações.
Habilitação (gerenciamento) de mudanças
Dois aspectos do SRE contribuem fortemente com a prática de gerenciamento de mudanças.
Um deles é o foco em automação.
Há uma recomendação de que os engenheiros de confiabilidade de site dediquem 50% de seu tempo fazendo trabalhos relacionados a “operações“, como resolução de problemas, plantão e intervenções manuais e outros 50% em tarefas de desenvolvimento, como novas funcionalidades, escala ou automação.
A automação de mudanças contribui para ampliar o volume de mudanças consideradas standards (pré-aprovadas, com risco baixo/controlado) e reduzir o volume de mudanças normais, que normalmente requerem uma análise individual, aprovação em CAB, etc.
O outro aspecto é o uso do orçamento de erro, que pode introduzir a oportunidade de uma política dinâmica de gerenciamento de mudanças.
A política de mudanças pode ser mais permissiva no início de um ciclo de orçamento de erro e a partir do momento que o orçamento se aproximar do seu limite, a política pode se tornar mais rígida.
Isso pode motivar as equipes a serem mais responsáveis no planejamento e execução das mudanças, uma vez que vão queimar menos orçamento com recuperação de mudanças com falha (outages) e vão poder usar o orçamento para implementar mais mudanças de melhoria e novas features
Gerenciamento de eventos
Um dos conceitos introduzidos pelo SRE é o da observabilidade, que eleva a prática de gerenciamento de eventos a um novo patamar.
Considerando que o monitoramento está focado em coisas que percebemos antecipadamente que irão dar errado, criando limites de aceitabilidade e alertas quando estes forem violados, a observabilidade se concentra em externalizar o máximo de dados possível sobre todo o serviço, permitindo-nos inferir qual é o estado atual desse serviço.
A ideia central da observabilidade é melhorar a relação de “sinal” para “ruído” para dar foco nos alertas que tem uma real significância e não em qualquer alerta de componentes individuais que podem não ter nenhum impacto para os SLOs.
Gerenciamento de incidentes
O Google acredita que, pior do que a ocorrência de incidentes, é não saber como responder a eles.
Por conta disso, a prática de gerenciamento de incidentes talvez seja onde o SRE aporte o maior volume de contribuições “acionáveis”, como um sistema de comando, uma divisão clara de papéis e responsabilidades, post mortem sem culpa, documentação live-state, on-call (plantões), etc.
Gerenciamento de requisições de serviço / Central de Serviços
Um dos princípios do SRE é a eliminação do Toil.
Toil é o tipo de trabalho vinculado à execução de um serviço de produção que tende a ser manual, repetitivo, automatizável, tático, desprovido de valor duradouro e que se dimensiona linearmente à medida que o serviço cresce.
Embora poderíamos encontrar toil em várias situações do gerenciamento de serviços, não há dúvidas de que uma das maiores concentrações de toil esteja depositada nas centrais de serviço, na forma de liberações manuais ou redefinições de senha.
Nesse sentido, o SRE contribui com abordagens para identificar e eliminar toil através de automação.
Por que profissionais de gerenciamento deveriam conhecer SRE?
Talvez por conta do SRE também ser descrito como uma área dentro das organizações e de haver uma função específica chamada de Engenheiro de Confiabilidade de Site, muitos acreditam que se trata de uma habilidade puramente técnica.
Acho essa uma visão bastante limitada.
Ainda que para funcionar, o SRE precisa se basear em uma ampla suite de ferramentas, é fundamental que uma estratégia de engenharia de confiabilidade seja definida. Aqui estamos falando desde compreender os ganhos potenciais do SRE para o negócio, a definição de como o SRE poderia ser implementado (consultoria, fatiado, full, etc) até a definição de SLOs compatíveis com a expectativa dos clientes.
Mesmo para profissionais que atuam em áreas técnicas, compreender os conceitos fundamentais de SRE os ajudam a realizar as atividades técnicas do dia a dia com maior eficácia.
Alguns pontos que foram discutidos neste artigo mostram que há oportunidade e espaço no SRE para diferentes perfis, como gestores de processo (mudanças, problemas, incidentes), gestores de níveis de serviço, etc.
De um ponto de vista de carreira profissional, também é importante ampliar o seu conhecimento em outros frameworks.
Aprender sobre SRE não te obriga a ser tornar um engenheiro de confiabilidade de site, assim como aprender sobre scrum não te obriga a atuar como product/project manager/owner.
Mas sendo um profissional de gerenciamento de serviços, aprender sobre eles aumentará sua “musculatura intelectual” para resolver os desafios das organizações, e claro, também vai te ajudar ser melhor visto pelo mercado.
Certificações na área de SRE
Atualmente, o único programa de certificação em SRE disponível no mercado é a do DevOps Institute.
Existem dois níveis de certificação: o nível de fundamentos e o nível praticante.
Se você tem interesse em se certificar nessa área, conheça os detalhes do nosso treinamento online oficial.
Muito bom o artigo, parabéns.
Uma sugestão como próximo artigo é como outros frameworks de ITSM (como ITIL) servem como base para o SRE e como a utilização deles em conjunto proporciona que as empresas ganhem confiabilidade, agilidade e escalabilidade.
Estou escrevendo meu artigo para MBA e senti muito falta de algum material comparativo do SRE, esse foi o mais próximo que encontrei.
Obrigado pelo comentário, Julia! Sugestão anotada 😉