Implementação do Modelo SRE e a Engenharia de Plataforma (PEs)

Preparação de um Time SRE

A preparação de um time SRE é uma demanda estratégica e tática, alinhada ao modelo operacional da empresa e às necessidades de escalabilidade e agilidade dos negócios. Não existe uma fórmula mágica para implementar SRE, mas aqui estão alguns formatos que, quando conectados à área de negócios, podem contribuir significativamente para a visão estratégica do SRE.

É importante destacar que o Google, criador do modelo SRE, é um provedor de Cloud com serviços totalmente digitais e autoescaláveis. O modelo do Google é uma excelente referência, mas as práticas e os princípios de SRE precisam ser adaptados para se alinhar com a realidade e os objetivos de cada organização. Portanto, seguir o modelo deles “by the book” faça para poucas empresas do setor de serviços.

Adaptar os princípios e práticas do SRE à realidade e aos objetivos específicos do seu negócio é fundamental para o sucesso da implementação.

Embedded (ou SRE integrado)

SRE Dentro de um Time de Desenvolvimento

Neste modelo, o SRE participa ativamente das cerimônias do time de desenvolvimento, como daily stand-ups, plannings, sprints, entre outras. O SRE pode se reportar diretamente ao gerente de desenvolvimento ou a um gerente de SRE, dependendo da estrutura organizacional. Ele trabalha especificamente em um produto, adquirindo um conhecimento profundo sobre seu funcionamento. Este modelo, conhecido como SRE Embedded, pode ser adotado de forma padrão ou temporária, especialmente em projetos que necessitam de uma entrega rápida e eficiente, onde a presença do SRE no time é crucial para acelerar o processo.

Vantagens:
- Conhecimento Profundo: O SRE desenvolve um entendimento detalhado do produto com o qual trabalha.
- Transferência de Conhecimento: Facilita a transferência de conhecimentos de SRE para os times de desenvolvimento, promovendo melhores práticas e maior eficiência.

Desvantagens:
- Prioritização de Demandas: Pode haver dificuldades na priorização das demandas de SRE (eficiência operacional, novos habilitadores, SLI, SLO, correções), pois o foco do time geralmente está nas novas funcionalidades.
- Padronização de Processos: A padronização dos processos pode ser prejudicada, já que o SRE não está vinculado a um time central de SRE, o que pode levar a inconsistências na aplicação das melhores práticas.

Este modelo promove uma integração mais estreita entre o SRE e o time de desenvolvimento, permitindo uma colaboração mais eficaz e um conhecimento profundo do produto, ao mesmo tempo em que apresenta desafios na gestão de prioridades e na padronização de processos.

Squads SRE (SRE Estendido)

SRE como Equipe de Sistema

Neste modelo, o SRE atua como um grupo que se integra aos times de desenvolvimento conforme necessário (SRE Estendido). Embora não estejam diretamente envolvidos na entrega do produto, eles têm o papel de garantir que os produtos estejam alinhados com os habilitadores de tecnologia. Este modelo é sugerido em alguns frameworks, pois faz sentido para manter a isonomia do Chapter SRE.

Vantagens:
- Autonomia: Os times ganham mais autonomia sobre as plataformas.
- Especialização: Os engenheiros se especializam mais em um campo de atuação e nos produtos.
- Expertise em Produtos: Os times se tornam mais especialistas nos produtos que desenvolvem.

Desvantagens:
- Complexidade: Pode haver dificuldade em criar padrões de automação e reutilização. Esta questão pode ser resolvida com um time de SRE Master voltado à governança.
- Comprometimento: É necessário monitorar para que o comprometimento do SRE não se torne ambíguo, alternando entre o squad e a engenharia.
- Plantões Compartilhados: Durante plantões compartilhados, pode faltar experiência em determinadas plataformas, necessitando de apoio mais profundo de outros engenheiros.

Este modelo equilibra a especialização e autonomia dos times de desenvolvimento com a expertise dos engenheiros SRE, embora requeira uma gestão cuidadosa para evitar problemas de governança e compromisso.

Engenharia de Plataforma (PEs)

Modelo de Engenharia de Plataforma

Outro modelo é a Engenharia de Plataforma, onde este time recebe demandas dos times de desenvolvimento e tem a responsabilidade de criar uma infraestrutura que permita aos desenvolvedores provisionarem recursos de forma autônoma quando necessário. Esse time se reporta diretamente a um gestor de SRE e segue as cerimônias de um time regular, como plannings, daily meetings, reviews, entre outros.

Dentro desse modelo, surgem algumas funções específicas, como o DRE (Data Reliability Engineer). Com o aumento da necessidade de transformar dados em informações valiosas, essa área tem crescido significativamente. Os Data Reliability Engineers são responsáveis por gerenciar os fluxos de dados da empresa, desde a coleta até a transformação e armazenamento. Além disso, há o time de eficiência, responsável por fornecer indicadores operacionais e viabilizar novos habilitadores.

Vantagens:
- Padronização: Criação de padrões e habilitadores de consumo consistentes.
- Priorização de Demandas: Foco nas demandas relacionadas a processos e melhorias de confiabilidade nos produtos.
- Autonomia e Treinamento: Proporciona autonomia aos desenvolvedores e viabiliza treinamentos para o consumo adequado dos recursos.

Desvantagens:
- Escalabilidade das Demandas: Inicialmente, é necessário foco na automação, mas a tendência é que a automação torne o time mais enxuto.

Este modelo favorece a padronização e a eficiência, proporcionando uma infraestrutura robusta para os times de desenvolvimento, ao mesmo tempo em que requer uma gestão cuidadosa para balancear o foco entre a plataforma e os produtos de negócios.

Conclusão

As principais diferenças entre o SRE e o PE:

Enquanto o SRE se concentra na confiabilidade e disponibilidade dos serviços em produção (Infra, Redes, Provedores, Landing Zone, DMZ, Ingress/Egress, Tokens, Repositório de Infra, IaC Infra, Observação de Infra, etc) o Engenheiro de Plataforma se concentra na criação e sustentação dos serviços para o desenvolvimento (CI/CD, Repositórios de Desenvolvimento, IaC Dev, Esteiras, Containers, GIT, Testes, Observação de Desenvolvimento, etc) que capacita a construção de novos produtos.

O time de Plataforma atua no apoio ao time de produtos, fornecendo tecnologia necessária para que o desenvolvedor tenha foco na construções de códigos, mantendo sua independência em relação a viabilidade do negócio. Este time é de natureza perene, com um histórico de reutilização, processos bem definidos, métodos estabelecidos e um contínuo aprendizado sobre o formato de consumo dos recursos de tecnologia.

Ao contrário dos Squads, o time de plataforma é multidisciplinar, não podendo ser dissolvido como um produto que não obteve viabilidade. Diferentemente de uma operação tradicional, a Plataforma traz consigo indicadores de performance que abrangem aspectos de DevOps (DORA), qualidade e capacidade.

Referências:

Site Reliability Engineering: How Google Runs Production Systems
— Autores: Niall Richard Murphy, Betsy Beyer, Chris Jones, and Jennifer Petoff

The Site Reliability Workbook: Practical Ways to Implement SRE
— Autores: Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara, and Stephen Thorne

Seeking SRE: Conversations About Running Production Systems at Scale
—Autor: David N. Blank-Edelman

The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win
— Autores: Gene Kim, Kevin Behr, and George Spafford

Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations
— Autores: Nicole Forsgren, Jez Humble, and Gene Kim