Capítulo 18 – Modelo de engajamento SRE

Por Michael Wildpaner, Gráinne Sheerin, Daniel Rogers, e Surya Prashanth Sanagavarapu (The New York Times) com Adrian Hilton e Shylaja Nukala

O Capítulo 32 do nosso primeiro livro sobre SRE descreve abordagens técnicas e procedimentais que uma equipe de SRE pode adotar para analisar e melhorar a confiabilidade de um serviço. Essas estratégias incluem Revisões de Prontidão para Produção (PRRs), engajamento precoce e melhoria contínua.

Simplificando, os princípios de SRE visam maximizar a velocidade de engenharia das equipes de desenvolvedores enquanto mantêm os produtos confiáveis. Esse objetivo duplo é bom para os usuários do produto e bom para a empresa. No entanto, há um limite para o que até mesmo a melhor equipe de SRE pode alcançar, e o modelo SRE é menos eficaz quando o domínio é muito grande e excessivamente complexo. O movimento atual de microsserviços torna essa dinâmica ainda mais aguda — uma pequena empresa pode facilmente ter mais microsserviços do que uma única equipe de SRE pode lidar. Dado um grande cenário de produção e com o conhecimento de que não podem cobrir todos os serviços, uma equipe de SRE deve decidir onde focar sua atenção para alcançar os melhores resultados. As equipes de desenvolvimento de produto e SRE podem colaborar para identificar o ponto de foco correto.

Este capítulo adota a perspectiva de uma equipe de SRE que pretende fornecer suporte para um novo serviço. Analisamos como se engajar da maneira mais eficaz com o serviço e com as equipes de desenvolvimento e produto que o possuem. Embora o engajamento de SRE geralmente se construa em torno de um ou mais serviços, o engajamento envolve muito mais do que os próprios serviços — ele se concentra em entender os objetivos das equipes de desenvolvedores e de produto e encontrar a maneira certa de apoiá-los.

A maior parte desta discussão é aplicável independentemente da escala da sua organização. Embora usemos a palavra “equipe” com frequência, uma equipe poderia teoricamente começar como uma única pessoa (embora essa pessoa ficaria bastante ocupada). Independentemente do tamanho da sua equipe, é importante definir proativamente o papel do SRE e gerenciar a comunicação e a colaboração com o desenvolvimento de produtos.

O ciclo de vida do serviço

Como descrito no prefácio do primeiro livro sobre SRE, as contribuições de uma equipe de SRE para a confiabilidade do serviço acontecem em todas as fases do ciclo de vida do serviço. A aplicação de conhecimento e experiência em produção pode melhorar substancialmente a confiabilidade de um serviço bem antes de qualquer SRE pegar o pager para o serviço.

A Figura 18-1 mostra os níveis ideais de engajamento do SRE ao longo da vida útil de um serviço. No entanto, uma equipe de SRE pode começar seu engajamento com um serviço em qualquer estágio do ciclo de vida. Por exemplo, se a equipe de desenvolvimento começar a planejar um serviço de substituição para um serviço suportado por SRE, o SRE pode estar envolvido no novo serviço muito cedo. Alternativamente, uma equipe de SRE pode se engajar formalmente com um serviço depois que ele estiver geralmente disponível por meses ou anos e estiver enfrentando desafios de confiabilidade ou escalabilidade. Esta seção fornece orientações sobre como as equipes de SRE podem contribuir efetivamente em cada fase.

Figura 18-1. Nível de engajamento do SRE durante o ciclo de vida do serviço

Fase 1: arquitetura e design

O SRE pode influenciar a arquitetura e o design de um sistema de software de várias maneiras:

Criando melhores práticas, como resiliência a diversos pontos únicos de falha, que uma equipe de desenvolvedores pode empregar ao construir um novo produto.
Documentando os “fazer e não fazer” de sistemas de infraestrutura específicos (com base em experiências anteriores) para que os desenvolvedores possam escolher seus blocos de construção sabiamente, usá-los corretamente e evitar armadilhas conhecidas.
Fornecendo consultoria de engajamento precoce para discutir arquiteturas específicas e escolhas de design em detalhes, e ajudar a validar suposições com a ajuda de protótipos direcionados.
Juntando-se à equipe de desenvolvedores e participando do trabalho de desenvolvimento.
Co-projetando parte do serviço.

Corrigir erros arquiteturais torna-se mais difícil posteriormente no ciclo de desenvolvimento. O engajamento precoce do SRE pode ajudar a evitar redesenhos custosos que se tornam necessários quando os sistemas interagem com usuários do mundo real e precisam escalar em resposta ao crescimento do serviço.

Fase 2: desenvolvimento ativo

À medida que o produto toma forma durante o desenvolvimento ativo, os SREs podem começar a preparar o serviço para a produção — deixando-o pronto para ser lançado em produção. A preparação para produção tipicamente inclui planejamento de capacidade, configuração de recursos extras para redundância, planejamento para lidar com picos e sobrecargas, implementação de balanceamento de carga e estabelecimento de práticas operacionais sustentáveis, como monitoramento, alertas e otimização de desempenho.

Fase 3: disponibilidade limitada

À medida que um serviço avança em direção à fase Beta, o número de usuários, a variedade de casos de uso, a intensidade de uso e as demandas de disponibilidade e desempenho aumentam. Nesta fase, o SRE pode ajudar a medir e avaliar a confiabilidade. Recomendamos fortemente definir SLOs antes da disponibilidade geral (GA) para que as equipes de serviço tenham uma medida objetiva de quão confiável é o serviço. A equipe de produto ainda tem a opção de retirar um produto que não consiga atingir sua meta de confiabilidade.

Durante esta fase, a equipe de SRE também pode ajudar a escalar o sistema construindo um modelo de capacidade, adquirindo recursos para as próximas fases de lançamento e automatizando ativação e redimensionamento do serviço no local. O SRE pode garantir uma cobertura de monitoramento adequada e ajudar a criar alertas que correspondam idealmente aos SLOs do serviço que está por vir.

Enquanto o uso do serviço ainda está mudando, a equipe de SRE pode esperar um aumento na quantidade de trabalho durante a resposta a incidentes e nas tarefas operacionais, porque as equipes ainda estão aprendendo como o serviço funciona e como gerenciar seus modos de falha. Recomendamos compartilhar esse trabalho entre as equipes de desenvolvimento e SRE. Dessa forma, a equipe de desenvolvimento ganha experiência operacional com o serviço e os SREs ganham experiência com o serviço em geral. O trabalho operacional e o gerenciamento de incidentes informarão as mudanças no sistema e as atualizações que os proprietários do serviço precisam fazer antes da GA (disponibilidade geral).

Fase 4: disponibilidade geral (GA)

Nesta fase, o serviço passou pela Revisão de Prontidão para Produção (consulte o Capítulo 32 em Livro SRE para mais detalhes) e está aceitando todos os usuários. Enquanto o SRE normalmente realiza a maioria do trabalho operacional, a equipe de desenvolvimento deve continuar a lidar com uma pequena parte do trabalho operacional e de resposta a incidentes para que não percam a perspectiva desses aspectos do serviço. Eles podem incluir permanentemente um desenvolvedor na rotação de chamadas para ajudar os desenvolvedores a acompanharem a carga operacional.

Na fase inicial da GA, enquanto a equipe de desenvolvimento se concentra em amadurecer o serviço e lançar os primeiros lotes de novos recursos, ela também precisa se manter informada para entender as propriedades do sistema sob carga real. Nas etapas posteriores da GA, a equipe de desenvolvimento fornece pequenos incrementos de recursos e correções, alguns dos quais são informados pelas necessidades operacionais e quaisquer incidentes de produção que ocorram.

Fase 5: descontinuação

Nenhum sistema funciona para sempre. Quando um sistema de substituição melhor estiver disponível, o sistema existente é fechado para novos usuários e todo o trabalho de engenharia se concentra na transição dos usuários do sistema existente para o novo. O SRE opera o sistema existente principalmente sem envolvimento da equipe de desenvolvimento e apoia a transição com trabalho de desenvolvimento e operacional.

Embora o esforço do SRE necessário para o sistema existente seja reduzido, o SRE está efetivamente suportando dois sistemas completos. A alocação de pessoal e equipe deve ser ajustada de acordo.

Fase 6: abandonado

Uma vez que um serviço é abandonado, a equipe de desenvolvimento geralmente retoma o suporte operacional. O SRE apoia os incidentes de serviço da melhor maneira possível. Para um serviço com usuários internos, o SRE transfere a gestão do serviço para quaisquer usuários restantes. Este capítulo fornece dois estudos de caso sobre como o SRE pode devolver um serviço às equipes de desenvolvimento.

Fase 7: sem suporte

Não há mais usuários, e o serviço foi desativado. O SRE ajuda a remover referências ao serviço em configurações de produção e na documentação.

Estabelecendo a relação

Um serviço não existe isoladamente: a equipe de SRE se envolve com a equipe de desenvolvimento que constrói o serviço e com a equipe de produto que determina como ele deve evoluir. Esta seção recomenda algumas estratégias e táticas para construir e manter boas relações de trabalho com essas equipes.

Comunicando prioridades de negócios e produção

Antes de poder ajudar alguém, é necessário entender suas necessidades. Para isso, os SREs precisam compreender o que os desenvolvedores de produtos esperam que o engajamento do SRE alcance. Ao se envolver com uma equipe de desenvolvimento, os SREs devem construir uma compreensão profunda dos objetivos do produto e do negócio. Os SREs devem ser capazes de articular seu papel e como o engajamento do SRE pode permitir que os desenvolvedores avancem em direção a esses objetivos.

As equipes precisam conversar regularmente sobre as prioridades de negócios e produção. As lideranças de SRE e desenvolvimento de produtos devem idealmente trabalhar como uma unidade, reunindo-se regularmente e trocando opiniões sobre desafios técnicos e de priorização. Às vezes, os líderes de SRE se juntam à equipe de liderança de desenvolvimento de produtos.

Identificar riscos

Como uma equipe de SRE está focada na confiabilidade do sistema, ela está bem posicionada para identificar potenciais riscos. Avaliar a probabilidade e o impacto potencial desses riscos da forma mais precisa possível é importante, pois o custo de interromper o desenvolvimento regular e o fluxo de funcionalidades é significativo para o produto e para os engenheiros.

Alinhando objetivos

As equipes de desenvolvimento e SRE se preocupam com confiabilidade, disponibilidade, desempenho, escalabilidade, eficiência, velocidade de lançamento de funcionalidades. No entanto, o SRE opera sob incentivos diferentes, favorecendo principalmente a viabilidade de longo prazo do serviço em detrimento dos novos lançamentos de recursos.

Em nossa experiência, as equipes de desenvolvimento e SRE podem encontrar o equilíbrio certo ao manterem seus focos individuais, mas também apoiarem explicitamente os objetivos do outro grupo. Os SREs podem ter como objetivo explícito apoiar a velocidade de lançamento da equipe de desenvolvimento e garantir o sucesso de todos os lançamentos aprovados. Por exemplo, o SRE pode afirmar: “Vamos apoiá-los para lançar o mais rápido possível, dentro dos limites de erro”. Os desenvolvedores, por sua vez, devem se comprometer a dedicar uma porcentagem razoável de tempo de engenharia para corrigir e prevenir problemas que estejam comprometendo a confiabilidade: resolver problemas contínuos do serviço no nível de design e implementação, pagar dívidas técnicas e incluir os SREs desde cedo no desenvolvimento de novos recursos, para que possam participar das conversas de design.

Metas compartilhadas: engajamentos de SRE no New York Times

por Surya Prashanth Sanagavarapu (The New York Times)

Em nossa organização, os recursos de SRE são muito demandados quando se trata de migrações para nuvem, aumento de produção e aplicativos migrando para contêineres. Além disso, as equipes de SRE têm suas próprias listas de tarefas para enfrentar. Diante de recursos limitados, essas prioridades concorrentes definem o sucesso da equipe de SRE. Embora contratar SREs seja uma maneira óbvia de lidar com a demanda por tempo de SRE, nem toda equipe tem o luxo, experiência ou tempo para fazer isso.

A missão central da função de SRE no New York Times é capacitar as equipes de desenvolvimento de produtos com ferramentas e processos para maximizar a confiabilidade e a resiliência em aplicativos que suportam nossa redação, possibilitando assim a distribuição de jornalismo de alta qualidade para os leitores. Adotamos um modelo de metas compartilhadas para alcançar um equilíbrio entre reduzir o backlog de automação e engajar-se com outras equipes.

Antes de nos engajarmos com as equipes, revisamos nosso backlog geral para o trimestre/ano atual e definimos claramente seus itens de trabalho e categorias. Por exemplo, os itens do nosso backlog podem incluir:

Adicionar automação para configurar monitoramento básico e alertas acionados pelos endpoints de status do serviço para aplicações.
Implementar pipelines de build mais confiáveis e/ou mais rápidos.

Quando as equipes procuram os SREs para ajuda, um dos fatores que consideramos ao priorizar uma solicitação é se um engajamento conjunto pode ajudar a reduzir nosso backlog.

Definindo o engajamento

Nossos SREs trabalham com as equipes de desenvolvimento de produtos de acordo com dois modelos diferentes:

Em tempo integral
Em tempo parcial para projetos bastante breves e restritos

Definimos o tipo de engajamento com base na capacidade da equipe de SRE. Para engajamentos em tempo integral, preferimos incorporar um SRE na equipe de desenvolvimento de produtos. Isso ajuda a fornecer foco e tempo para aliviar parte da carga das equipes de engenharia de produtos. Os times de SRE e de produtos têm tempo máximo para aprender um sobre o outro à medida que os desenvolvedores se aprimoram nas habilidades e capacidades de SRE. Para engajamentos de longo prazo, priorizamos aplicações que se encaixem melhor na estratégia da nossa empresa.

Ao definir o escopo do engajamento, tentamos avaliar a maturidade da equipe ou da aplicação em relação às práticas de SRE. Observamos que diferentes equipes estão em diferentes níveis de maturidade quando se trata de pensar em práticas e princípios de SRE. Estamos trabalhando na aplicação de um modelo de maturidade de aplicação para ajudar nesse aspecto.

Definindo metas e expectativas compartilhadas

Estabelecer expectativas claras é crucial para cumprir prazos e completar tarefas. Para isso, trabalhamos de acordo com os seguintes princípios:

Enfatizamos que os proprietários da aplicação, não os SREs, são diretamente responsáveis por fazer mudanças em uma aplicação.
O engajamento de SRE é para benefício de toda a empresa. Qualquer nova automação ou ferramenta deve melhorar as ferramentas comuns e a automação usada em toda a empresa e evitar o desenvolvimento de scripts isolados.
Os SREs devem informar a equipe de desenvolvimento sobre quaisquer novos processos que o engajamento possa introduzir (por exemplo, testes de carga).
Os engajamentos podem envolver Avaliações de Preparação de Aplicação (ARRs) e Avaliações de Preparação para Produção (PRRs), conforme descrito no Capítulo 32 da Engenharia de Confiabilidade de Sites. As mudanças propostas pelas ARR e PRR devem ser priorizadas em conjunto pelos desenvolvedores e pelos SREs.
Os SREs não são engenheiros de operações tradicionais. Eles não suportam trabalhos manuais, como executar um job para implantação.

Ao definirmos metas compartilhadas, as escrevemos em conjunto com a equipe de desenvolvimento e dividimos essas metas em marcos. Se sua empresa segue metodologia Agile, você pode escrever epics ou histórias. A equipe de SRE pode então mapear essas metas para seu próprio backlog.

Nosso padrão comum ao definir metas é:

Definir o escopo do engajamento.

Exemplo 1: No próximo trimestre, quero que todos os membros da minha equipe lidem com implantações GKE/GAE, se sintam confortáveis em ambientes de produção e sejam capazes de lidar com uma interrupção de produção.

Exemplo 2: No próximo trimestre, quero que os SREs trabalhem com a equipe de desenvolvimento para estabilizar o aplicativo em termos de escalabilidade e monitoramento, e desenvolver runbooks e automação para interrupções.

Identificar explicitamente o resultado de sucesso final.

Exemplo: Após o engajamento, a equipe de desenvolvimento de produtos será capaz de lidar com as interrupções de serviço no Google Kubernetes Engine sem escalonamento.

Sprints e comunicação

Qualquer engajamento com equipes de desenvolvimento de produtos começa com uma reunião de kickoff e planejamento. Antes do kickoff, nossa equipe de SRE revisa a arquitetura da aplicação e nossas metas compartilhadas para verificar se o resultado esperado é realista dentro do prazo estabelecido. Uma reunião de planejamento conjunta que cria epics (épicos) e stories (histórias) pode ser um bom ponto de partida para o engajamento.

Um roadmap para este engajamento pode ser:

Revisar a arquitetura da aplicação.
Definir metas compartilhadas.
Realizar a reunião de kickoff e planejamento.
Implementar ciclos de desenvolvimento para alcançar marcos.
Realizar retrospectivas para obter feedback sobre o engajamento.
Realizar Avaliações de Preparação para Produção (PRRs).
Implementar ciclos de desenvolvimento para alcançar marcos.
Planejar e executar lançamentos.

Exigimos que as equipes definam um método de feedback e concordem com sua frequência. Tanto as equipes de SRE quanto as de desenvolvimento precisam de feedback sobre o que está funcionando e o que não está. Para que esses engajamentos sejam bem-sucedidos, descobrimos que proporcionar um ciclo de feedback constante fora das revisões ágeis de sprint, por meio de um método acordado, é útil—por exemplo, estabelecendo retrospectivas quinzenais ou check-ins com os gerentes de equipe. Se um engajamento não estiver funcionando, esperamos que as equipes não hesitem em planejar o desengajamento.

Medindo o impacto

Achamos importante medir o impacto do engajamento para garantir que os SREs estejam realizando um trabalho de alto valor. Também medimos o nível de maturidade de cada equipe parceira para que os SREs possam determinar as maneiras mais eficazes de trabalhar com elas. Uma abordagem que adotamos ao trabalhar com a equipe de Engenharia de Confiabilidade do Cliente (CRE) do Google é realizar uma avaliação pontual com os líderes da equipe de engenharia de produtos antes de iniciar o engajamento.

Uma avaliação pontual consiste em percorrer uma matriz de maturidade, avaliando a maturidade do serviço ao longo dos vários eixos de preocupação para SRE (conforme descrito no Capítulo 32), e concordando com pontuações para áreas funcionais como observabilidade, planejamento de capacidade, gerenciamento de mudanças e resposta a incidentes. Isso também ajuda a adaptar o engajamento de forma mais apropriada após aprendermos mais sobre os pontos fortes, pontos fracos e pontos cegos da equipe.

Após o término do engajamento e quando a equipe de desenvolvimento estiver operando de forma independente, realizamos a avaliação novamente para medir o valor agregado pelo SRE. Se tivermos um modelo de maturidade em vigor, medimos em relação a esse modelo para verificar se o engajamento resultou em um nível mais alto de maturidade. À medida que o engajamento chega ao fim, planejamos uma celebração!

Estabelecendo regras básicas

Na Google, cada equipe de SRE tem dois objetivos principais:

Curto prazo

Atender às necessidades comerciais do produto fornecendo um sistema operacionalmente estável, disponível e escalável conforme a demanda, com foco na manutenibilidade.

Longo prazo

Otimizar as operações do serviço a um nível onde o trabalho humano contínuo não seja mais necessário, permitindo que a equipe de SRE avance para trabalhar no próximo engajamento de alto valor.

Para isso, as equipes devem concordar com alguns princípios de cooperação, tais como:

Definições (e um limite rígido) de trabalho operacional.

Um SLO acordado e mensurado para o serviço, utilizado para priorizar o trabalho de engenharia tanto para as equipes de desenvolvimento quanto para SRE. Você pode começar sem um SLO em vigor, mas nossa experiência mostra que não estabelecer esse contexto desde o início do relacionamento significa que você terá que retroceder para este passo mais tarde. Para um exemplo de como o trabalho de engenharia pode proceder de maneira menos ideal na ausência de um SLO, consulte o “Estudo de Caso 1: Escalando o Waze – De Mudanças Ad Hoc para Planejadas” na página 427.

Um error budget trimestral acordado que determina a velocidade de lançamento e outros parâmetros de segurança, como capacidade de serviço extra para lidar com o crescimento inesperado de uso.

Envolvimento dos desenvolvedores nas operações diárias para garantir que os problemas em curso sejam visíveis e que a correção de suas causas raiz seja priorizada.

Planejamento e execução

O planejamento proativo e a execução coordenada garantem que as equipes de SRE atendam às expectativas e aos objetivos do produto, ao mesmo tempo que otimizam as operações e reduzem os custos operacionais. Sugerimos planejar em dois níveis conectados:

Com a liderança de desenvolvimento, definir prioridades para produtos e serviços e publicar roadmaps anuais.

Revisar e atualizar roadmaps regularmente, e derivar metas (trimestrais ou outras) alinhadas com o roadmap.

Os roadmaps garantem que cada equipe tenha um horizonte de tempo de longo prazo para trabalhos claros e de alto impacto. Pode haver boas razões para não seguir roadmaps (por exemplo, se a organização de desenvolvimento estiver mudando muito rapidamente). No entanto, em um ambiente estável, a ausência de um roadmap pode ser um sinal de que a equipe de SRE pode se fundir com outra equipe, transferir o trabalho de gerenciamento de serviço de volta para as equipes de desenvolvimento, expandir o escopo ou dissolver.

Manter conversas estratégicas contínuas com a liderança de desenvolvimento ajuda a identificar rapidamente mudanças de foco, discutir novas oportunidades para o SRE adicionar valor ao negócio ou interromper atividades que não são rentáveis para o produto.

Os roadmaps podem se concentrar não apenas na melhoria do produto, mas também em como aplicar e melhorar tecnologias e processos comuns de SRE para reduzir custos operacionais.

Manter um relacionamento eficaz e contínuo

Relacionamentos saudáveis e eficazes requerem esforço contínuo. As estratégias delineadas nesta seção têm funcionado bem para nós.

Investindo tempo para trabalhar melhor juntos

O simples ato de passar tempo juntos ajuda os SREs e os desenvolvedores a colaborarem de maneira mais eficaz. Recomendamos que os SREs se encontrem regularmente com seus colegas responsáveis pelos serviços que gerenciam. Também é uma boa ideia que os SREs se reúnam periodicamente com outras equipes de SRE que administram serviços que enviam tráfego para o serviço ou fornecem infraestrutura comum que o serviço utiliza. A equipe de SRE pode então escalar de forma confiante e rápida durante incidentes ou discordâncias, porque as equipes se conhecem e já estabeleceram expectativas sobre como as escalas devem ser iniciadas e gerenciadas.

Manter uma linha aberta de comunicação

Além da comunicação diária entre equipes, encontramos alguns métodos de troca de informações mais formais que foram particularmente úteis ao longo do engajamento.

Os SREs podem apresentar trimestralmente uma “atualização do estado da produção” para a liderança de desenvolvimento de produtos, ajudando-os a entender onde devem investir recursos e como exatamente o SRE está ajudando seu produto ou serviço. Da mesma forma, os desenvolvedores podem fazer apresentações periódicas sobre o “estado do produto” para a equipe de SRE ou envolver o SRE nas apresentações executivas da equipe de desenvolvimento. Isso oferece à equipe de SRE uma visão geral do que a equipe de desenvolvimento alcançou no último trimestre (e permite que os SREs vejam como seu próprio trabalho possibilitou isso). Também fornece uma atualização sobre para onde o produto está indo nos próximos trimestres, e onde o líder do produto vê o SRE se engajando para tornar isso realidade.

Realização de avaliações regulares do serviço

Como os tomadores de decisão para o futuro do serviço, os líderes das equipes de SRE e desenvolvimento responsáveis pelo serviço devem se reunir pessoalmente pelo menos uma vez por ano. Realizar mais reuniões do que isso pode ser desafiador, por exemplo, devido a viagens intercontinentais. Durante essa reunião, geralmente compartilhamos nossos roadmaps para os próximos 12 a 18 meses e discutimos novos projetos e lançamentos.

Às vezes, as equipes de SRE facilitam um exercício retrospectivo, onde os líderes discutem o que as equipes desejam parar de fazer, continuar fazendo e começar a fazer. Os itens podem aparecer em mais de uma área e todas as opiniões são válidas. Essas sessões requerem facilitação ativa porque os melhores resultados vêm da participação completa da equipe. Frequentemente, essa é considerada a sessão mais útil na reunião de serviço porque gera detalhes que podem impulsionar mudanças significativas no serviço.

Reavaliando quando as regras fundamentais começam a vacilar

Se a cooperação em alguma das áreas acordadas começar a regredir, tanto os desenvolvedores quanto os SREs precisam mudar as prioridades para colocar o serviço de volta nos trilhos. Descobrimos que, dependendo da urgência, isso pode significar qualquer uma das seguintes ações:

As equipes identificam engenheiros específicos que devem abandonar suas tarefas de menor prioridade para se concentrarem na regressão.

Ambas as equipes convocam um “hackathon de confiabilidade”, mas as prioridades normais da equipe continuam fora dos dias do hackathon.

É declarado um congelamento de novas funcionalidades e a maioria das equipes se concentra em resolver a regressão.

A liderança técnica determina que a confiabilidade do produto está em risco agudo, e as equipes convocam uma resposta de “todos às mãos no convés”.

Ajustando prioridades de acordo com seus SLOs e error budget

A arte sutil de elaborar um SLO bem definido ajuda uma equipe a priorizar adequadamente. Se um serviço corre o risco de não cumprir o SLO ou esgotou o error budget, ambas as equipes podem trabalhar com alta prioridade para colocar o serviço de volta à segurança. Elas podem abordar a situação por meio de medidas táticas (por exemplo, superprovisionamento para lidar com regressões de desempenho relacionadas ao tráfego) e correções de software mais estratégicas (como otimizações, caching e degradação graciosa).

Se um serviço está bem dentro do SLO e possui um amplo error budgets restantes, recomendamos usar o excedente do error budgets para aumentar a velocidade de desenvolvimento de novas funcionalidades, em vez de direcionar esforços desproporcionais para melhorias no serviço.

Manejando erros adequadamente

Os seres humanos inevitavelmente cometem erros. Consistente com nossa cultura de postmortem, não culpamos as pessoas e, em vez disso, focamos no comportamento do sistema. Seus resultados podem variar, mas tivemos sucesso com as seguintes táticas.

Durma sobre isso

Se possível, evite realizar conversas de acompanhamento quando estiver cansado ou com as emoções exaltadas. Durante situações de alto estresse, as pessoas podem facilmente interpretar erroneamente o tom da comunicação escrita, como e-mails. Os leitores lembrarão como as palavras os fizeram sentir, não necessariamente o que foi escrito. Quando estiver comunicando entre locais diferentes, muitas vezes vale a pena investir tempo em uma videochamada para que você possa ver as expressões faciais e ouvir o tom de voz, o que ajuda a desambiguar as palavras.

Encontre-se pessoalmente (ou o mais próximo possível) para resolver problemas

Interações conduzidas apenas por revisões de código ou documentação podem se tornar rapidamente prolongadas e frustrantes. Quando um comportamento ou decisão de outra equipe está em desacordo com nossas expectativas, conversamos com eles sobre nossas suposições e pedimos informações que possam estar faltando.

Seja positivo

Agradeça às pessoas por seus comportamentos positivos. Isso pode ser simples, por exemplo, durante revisões de código, revisões de design e treinamentos de cenários de falha, pedimos aos engenheiros que destaquem o que foi bom e expliquem o motivo. Você também pode reconhecer bons comentários de código ou agradecer às pessoas pelo tempo que investem em uma revisão de design rigorosa.

Compreenda as diferenças na comunicação

Diferentes equipes têm diferentes expectativas internas sobre como a informação é disseminada. Compreender essas diferenças pode ajudar a fortalecer os relacionamentos.

Escalando SRE para ambientes maiores

Os cenários discutidos até agora envolvem uma única equipe de SRE, uma única equipe de desenvolvimento e um serviço. Empresas maiores, ou mesmo pequenas empresas que utilizam um modelo de microsserviços, podem precisar escalar alguns ou todos esses números.

Suportando múltiplos serviços com uma única equipe de SRE

Como os SREs possuem habilidades especializadas e são um recurso escasso, o Google geralmente mantém uma relação de SREs para desenvolvedores de < 10%. Portanto, uma equipe de SRE comumente trabalha com várias equipes de desenvolvimento em sua área de produto (PA).

Se os SREs são escassos em relação ao número de serviços que merecem suporte de SRE, uma equipe de SRE pode concentrar seus esforços em um serviço, ou em alguns serviços de um pequeno número de equipes de desenvolvimento.

Em nossa experiência, é possível escalar recursos limitados de SRE para muitos serviços se esses serviços apresentarem as seguintes características:

Os serviços fazem parte de um único produto. Isso proporciona propriedade completa da experiência do usuário e alinhamento com as necessidades do usuário.

Os serviços são construídos em pilhas tecnológicas similares. Isso minimiza a carga cognitiva e permite o reuso eficaz das habilidades técnicas.

Os serviços são desenvolvidos pela mesma equipe de desenvolvimento ou por um pequeno número de equipes de desenvolvimento relacionadas. Isso reduz o número de relacionamentos e facilita a harmonização de prioridades.

Estruturando um ambiente de equipe SRE múltipla

Se a sua empresa é grande o suficiente para ter várias equipes SRE e talvez vários produtos, você precisa escolher uma estrutura para como SRE e os grupos de produtos se relacionam.

Dentro do Google, nós apoiamos uma organização de desenvolvedores complexa. Conforme mostrado na Figura 18-2, cada PA consiste em vários grupos de produtos que por sua vez contêm múltiplos produtos. A organização SRE acompanha hierarquicamente a organização de desenvolvedores, com prioridades e melhores práticas compartilhadas em cada nível. Este modelo funciona quando todas as equipes em um grupo, ou todos os grupos em um PA, compartilham os mesmos ou similares objetivos específicos de negócio, e quando cada grupo de produtos tem tanto um líder de produto quanto um líder SRE.

Figura 18-2. Relacionamentos de equipe de desenvolvedores para SRE em grande escala (por área de produto)

Se sua organização possui múltiplas equipes SRE, você precisará agrupá-las de alguma forma. Os dois principais métodos que vimos funcionarem bem são:

Agrupar as equipes dentro de um produto, para que não precisem coordenar com muitas equipes de desenvolvedores diferentes.

Agrupar as equipes dentro de uma pilha de tecnologia (por exemplo, “armazenamento” ou “rede”).

Para evitar a rotatividade nas equipes SRE durante reorganizações de desenvolvedores, recomendamos organizar as equipes SRE de acordo com a tecnologia, em vez da estrutura de relatório de PA dos desenvolvedores. Por exemplo, muitas equipes que suportam sistemas de armazenamento são estruturadas e operam da mesma forma. Agrupar sistemas de armazenamento em grupos de produtos focados em tecnologia pode fazer mais sentido, mesmo que venham de diferentes partes da organização de desenvolvedores.

Adaptando estruturas de equipes SRE às circunstâncias em mudança

Se você precisa modificar a estrutura das suas equipes SRE para refletir as necessidades em evolução das PAs (Product Areas), recomendamos criar, dividir (sharding), fundir e dissolver equipes SRE com base nas necessidades de serviço e carga de engenharia e operacional. Cada equipe SRE deve ter um charter claro que reflita seus serviços, tecnologia e operações. Quando uma única equipe SRE tem muitos serviços, em vez de criar novas equipes do zero, preferimos dividir a equipe existente em várias equipes para transferir cultura e fortalecer a liderança existente. Mudanças como essas são inevitavelmente disruptivas para as equipes existentes, então recomendamos reestruturar as equipes apenas quando necessário.

Executando equipes SRE distribuídas de forma coesas

Se você precisa garantir cobertura 24/7 e continuidade do negócio, e possui presença global, vale a pena distribuir suas equipes SRE ao redor do globo para fornecer cobertura uniforme. Se você tem várias equipes distribuídas globalmente, recomendamos colocá-las juntas com base na adjacência e na similaridade de serviços e tecnologia compartilhada. Descobrimos que equipes isoladas geralmente são menos eficazes e mais vulneráveis aos efeitos de reorganizações fora da equipe — criamos tais equipes apenas se as necessidades de negócios estiverem claramente definidas e tivermos considerado todas as outras opções.

Muitas empresas não têm recursos para uma cobertura global completa, mas mesmo que você esteja dividido apenas entre edifícios (sem falar em continentes), é importante criar e manter um arranjo de dois locais.

Também é importante criar e manter padrões organizacionais que orientem o planejamento e a execução, e promovam e mantenham uma cultura de equipe compartilhada. Para isso, achamos útil reunir toda a equipe em um local físico periodicamente — por exemplo, em uma cúpula organizacional a cada 12 a 18 meses.

Às vezes, não faz sentido que todos na equipe assumam certas responsabilidades — por exemplo, conduzir restaurações regulares de testes a partir de backups ou implementar mandatos técnicos cruzados da empresa. Ao equilibrar essas responsabilidades entre os sites distribuídos da equipe, mantenha em mente as seguintes estratégias:

Atribua responsabilidades individuais a locais específicos, mas as rotacione regularmente (por exemplo, anualmente).

Compartilhe cada responsabilidade entre os locais, fazendo um esforço ativo para equilibrar o envolvimento e a carga de trabalho.

Não restrinja uma responsabilidade a um único local por vários anos. Descobrimos que os custos dessa configuração acabam superando os benefícios. Embora aquele local tenda a se tornar muito bom na execução dessas responsabilidades, isso fomenta uma mentalidade de “nós contra eles”, dificulta a distribuição de conhecimento e apresenta um risco para a continuidade do negócio.

Todas essas estratégias exigem que os locais mantenham uma comunicação tática e estratégica.

Encerrando o relacionamento

Engajamentos SRE não são necessariamente indefinidos. Os SREs fornecem valor através de um trabalho de engenharia impactante. Se o trabalho não é mais impactante (ou seja, a proposição de valor de um engajamento SRE desaparece), ou se a maioria do trabalho não está mais do lado da engenharia (versus operações), pode ser necessário revisar o engajamento SRE contínuo. Em geral, SREs individuais tendem a se afastar de equipes com carga de trabalho operacional pesada para equipes que oferecem trabalho de engenharia mais interessante.

Em nível de equipe, pode-se devolver um serviço se o SRE não mais proporcionar valor comercial suficiente para justificar os custos. Por exemplo:

Se um serviço foi otimizado a um nível onde o engajamento contínuo do SRE não é mais necessário.

Se a importância ou relevância de um serviço diminuiu.

Se um serviço está chegando ao fim de sua vida útil.

Os estudos de caso a seguir demonstram como dois modelos de engajamento SRE no Google foram encerrados. O primeiro termina com resultados em sua maioria positivos, enquanto o segundo termina com um resultado mais matizado.

Estudo de caso 1: Ares

As equipes de SRE de Abuso e Ferramenta Comum de Abuso (CAT) do Google forneciam proteção contra abuso para a maioria das propriedades do Google e trabalhavam com produtos voltados para o cliente para manter os usuários seguros. A equipe de SRE de Abuso aplicou trabalho de engenharia para reduzir o ônus de suporte operacional do CAT, permitindo que os desenvolvedores assumissem um papel direto no suporte aos seus usuários. Esses usuários eram os Googlers que operavam as propriedades defendidas pelo CAT, e tinham altas expectativas quanto à eficácia do CAT e ao tempo de resposta para problemas ou novas ameaças.

Para combater abusos de forma eficiente, é necessário atenção constante, mudanças adaptativas rápidas e flexibilidade ágil diante de novas ameaças e ataques. Esses requisitos entraram em conflito com os objetivos comuns de SRE de desenvolvimento de recursos confiáveis e planejados. As equipes CAT frequentemente precisavam implementar desenvolvimentos rápidos e novas proteções para propriedades sob ataque. No entanto, a equipe de SRE de Abuso resistiu às mudanças solicitadas, solicitando uma análise mais aprofundada das consequências de cada nova proteção para o sistema de produção como um todo. Restrições de tempo nas consultas entre equipes e revisões agravaram essa tensão.

Para tentar melhorar a situação, a liderança de Abuso SRE e CAT se envolveu em um projeto de vários anos para criar uma equipe de infraestrutura dedicada dentro do CAT. A recém-formada equipe “Ares” tinha o mandato de unificar a infraestrutura de combate a abusos para as propriedades do Google. Esta equipe foi composta por engenheiros do CAT que possuíam conhecimento em infraestrutura de produção e experiência na construção e operação de grandes serviços. As equipes iniciaram um programa de intercâmbio para transferir conhecimento de gerenciamento de produção dos SREs de Abuso para os membros da equipe de infraestrutura do CAT.

Os SREs de Abuso ensinaram à equipe Ares que a maneira mais fácil de lançar um novo serviço em produção (quando você já está executando grandes serviços distribuídos) é minimizar a carga cognitiva adicional que o serviço impõe. Para reduzir essa carga cognitiva, os sistemas devem ser o mais homogêneos possível. Implantar e gerenciar uma coleção de serviços de produção juntos significa que eles podem compartilhar a mesma estrutura de lançamento, planejamento de capacidade, subserviços para acesso ao armazenamento, e assim por diante. Seguindo este conselho, a equipe Ares redesenhou toda a pilha de combate ao abuso, aplicando conceitos de modularidade para migrar para um modelo de microsserviços. Eles também construíram uma nova camada que fornecia abstrações para os desenvolvedores, de modo que estes não precisassem se preocupar com detalhes de produção de nível inferior, como monitoramento, logging e armazenamento.

Neste ponto, a equipe Ares começou a atuar mais como uma equipe SRE para o CAT, administrando a nova infraestrutura de combate ao abuso. Enquanto isso, os SREs de Abuso focaram no deployment de produção e na operação eficiente do dia a dia da infraestrutura global de combate ao abuso.

A colaboração entre os engenheiros da equipe Ares e os SREs de Abuso resultou nas seguintes melhorias:

Como a equipe CAT agora tinha especialistas em produção “internos” que também eram especialistas em combate ao abuso, os SREs de Abuso não precisavam mais validar a integração de novos recursos. Isso reduziu significativamente o tempo até a produção para novos recursos. Ao mesmo tempo, a velocidade de desenvolvimento da equipe CAT aumentou porque a nova infraestrutura abstraiu os detalhes de gerenciamento de produção.

A equipe de SRE de Abuso recebeu muito menos solicitações da equipe CAT para lançar novos recursos, pois a maioria das solicitações não exigia mudanças na infraestrutura. A equipe também precisava de menos conhecimento para avaliar o impacto de um novo recurso, uma vez que mudanças na infraestrutura raramente eram necessárias. Quando mudanças na infraestrutura eram necessárias, os SREs de Abuso apenas precisavam esclarecer as implicações na infraestrutura, em vez da funcionalidade específica do recurso.

Os produtos que precisavam integrar-se à infraestrutura de combate ao abuso tiveram um tempo de resposta mais rápido e previsível, uma vez que a integração do produto agora equivalia em esforço ao lançamento de um recurso.

Essas melhorias demonstram como a colaboração eficaz entre as equipes de engenharia e SRE pode simplificar processos, acelerar o desenvolvimento e melhorar a eficiência operacional.

No final deste projeto, os SREs de Abuso deixaram de apoiar diretamente o CAT, focando em vez disso na infraestrutura subjacente. Isso não comprometeu a confiabilidade do CAT nem sobrecarregou a equipe CAT com trabalho operacional adicional; pelo contrário, aumentou a velocidade geral de desenvolvimento do CAT.

Atualmente, Ares protege usuários em um grande número de propriedades do Google. Desde o início da equipe, os SREs e o desenvolvimento de produtos têm trabalhado em parceria para tomar decisões colaborativas sobre como a infraestrutura funcionará em produção. Esta parceria só foi possível porque o esforço do Ares criou um senso de destino compartilhado.

Estudo de caso 2: pipeline de análise de dados

Às vezes, o custo de manter um relacionamento de suporte SRE é maior do que o valor (percebido ou mensurado) que os SREs fornecem. Nestes casos, faz sentido encerrar o relacionamento desmantelando a equipe SRE.

Quando o valor de um relacionamento diminui ao longo do tempo, é extremamente difícil identificar um ponto no tempo em que faz sentido terminar esse relacionamento. Dois times no Google que suportavam um pipeline de análise de dados crucial para a receita tiveram que enfrentar esse desafio. Descobrir que a separação era apropriada não foi uma tarefa trivial, especialmente após uma década de cooperação. Em retrospecto, pudemos identificar vários padrões na interação da equipe que foram fortes indicadores de que precisávamos reconsiderar o relacionamento entre a equipe SRE e a equipe de produto.

A virada

Três anos antes da redução, todas as partes envolvidas reconheceram que seu principal pipeline de análise de dados estava enfrentando limitações de escalabilidade. Naquela época, a equipe de desenvolvedores decidiu começar a planejar seu novo sistema e dedicou um pequeno número de engenheiros para esse esforço. Conforme esse esforço começou a se consolidar, fez sentido priorizar menos o desenvolvimento de características grandes, complexas ou arriscadas para o sistema existente em favor do trabalho no novo sistema. Isso teve dois efeitos importantes ao longo do tempo:

Uma regra informal foi aplicada a novos projetos: se a complexidade do projeto ou o risco envolvido em modificar o sistema existente para acomodar o projeto fosse suficientemente alto, então era melhor fazer esse investimento no novo sistema.

À medida que os recursos foram transferidos para o desenvolvimento do novo sistema, mesmo mudanças relativamente conservadoras no sistema existente se tornaram mais difíceis. No entanto, o uso continuou a crescer a uma taxa extremamente alta.

Quebra na Comunicação

Manter um sistema existente operacional enquanto um sistema de substituição é simultaneamente projetado, construído e lançado é um desafio para qualquer equipe de engenharia. Naturalmente, as tensões se acumulam entre as pessoas focadas nos sistemas novos e antigos, e as equipes precisam tomar decisões difíceis de priorização. Essas dificuldades podem ser agravadas quando as equipes estão separadas organizacionalmente — por exemplo, uma equipe SRE focada na manutenção e operação de um sistema existente e uma equipe de desenvolvedores trabalhando no sistema de próxima geração.

A comunicação regular, aberta e cooperativa é vital durante todo esse ciclo para manter e preservar um bom relacionamento de trabalho entre as equipes. Neste exemplo, uma lacuna na comunicação levou a uma quebra no relacionamento de trabalho entre as equipes.

Descomissionamento

Levou algum tempo para perceber que a desconexão entre as equipes de SRE e desenvolvimento era insuperável. No final, a solução mais simples foi remover a barreira organizacional e dar à equipe de desenvolvimento controle total sobre a priorização do trabalho nos sistemas antigo e novo. Esperava-se que os sistemas se sobrepusessem por 18 a 24 meses antes que o sistema antigo fosse totalmente desativado.

A combinação das funções de SRE e desenvolvimento de produtos em uma única equipe permitiu que a alta administração respondesse ao máximo às suas áreas de responsabilidade. Enquanto isso, a equipe poderia decidir como equilibrar as necessidades operacionais e a velocidade de desenvolvimento. Embora desativar duas equipes de SRE não tenha sido uma experiência agradável, isso resolveu a tensão contínua sobre onde investir esforço de engenharia.

Apesar da carga operacional adicional inevitável para a equipe de desenvolvimento, realinhar a propriedade do sistema antigo com pessoas que tinham maior conhecimento dos detalhes internos do serviço proporcionou a oportunidade de resolver problemas operacionais mais rapidamente. Essa equipe também tinha mais insights sobre possíveis causas de falhas, o que geralmente resultava em solução de problemas mais eficaz e resolução mais rápida de problemas. No entanto, houve alguns impactos negativos inevitáveis enquanto a equipe de desenvolvimento aprendia sobre os detalhes do trabalho operacional necessário para dar suporte ao serviço em um curto espaço de tempo. O último trabalho da equipe de SRE foi transferir esse conhecimento da maneira mais suave possível, capacitando a equipe de desenvolvimento a assumir o trabalho.

Vale ressaltar que, se o relacionamento de trabalho fosse mais saudável — com equipes trabalhando juntas de maneira eficaz para resolver problemas —, o SRE teria devolvido temporariamente o trabalho de produção para a equipe de desenvolvimento. Após estabilizar o sistema e fortalecê-lo para atender às necessidades esperadas de crescimento, o SRE normalmente reassumiria a responsabilidade pelo sistema. Equipes de SRE e desenvolvimento precisam estar dispostas a enfrentar problemas de frente e identificar pontos de tensão que precisam ser ajustados. Parte do trabalho do SRE é ajudar a manter a excelência de produção diante das mudanças nas necessidades comerciais, e muitas vezes isso significa engajar-se com os desenvolvedores para encontrar soluções para problemas desafiadores.

Conclusão

A forma de engajamento de uma equipe de SRE muda ao longo das várias fases do ciclo de vida de um serviço. Este capítulo ofereceu conselhos específicos para cada fase. Exemplos das equipes de SRE do Google e do New York Times mostram que gerenciar efetivamente o engajamento é tão importante quanto tomar boas decisões de design técnico. Às vezes, um engajamento de SRE deve chegar a uma conclusão natural. Estudos de caso do Ares e de uma equipe de pipeline de análise de dados forneceram exemplos de como isso pode acontecer e como encerrar o engajamento da melhor maneira.

Quando se trata das melhores práticas para estabelecer um relacionamento eficaz entre equipes de SRE e desenvolvimento de produtos, um senso compartilhado de propósito e metas, com comunicação regular e aberta, é fundamental. Você pode ampliar o impacto de uma equipe de SRE de várias maneiras, mas esses princípios de gestão de relacionamento devem sempre ser seguidos. Para sustentar o sucesso a longo prazo de um engajamento, investir no alinhamento dos objetivos da equipe e entender os objetivos uns dos outros é tão importante quanto defender os SLOs (Objetivos de Nível de Serviço).