Capítulo 20 – Ciclos de vida da equipe SRE

Por David Ferguson e Prashant Labhane com Shylaja Nukala

O Prefácio deste livro estabeleceu o objetivo de “dissipar a ideia de que o SRE é aplicável apenas em ‘escala do Google’ ou na ‘cultura do Google’.” Este capítulo apresenta um roteiro para amadurecer uma organização SRE desde a fase inicial, ainda sem equipe, mas aspiracional, passando por várias etapas de maturidade, até um conjunto robusto e (potencialmente) globalmente distribuído de equipes SRE. Independentemente de onde você está na sua jornada como organização SRE, este capítulo ajudará você a identificar estratégias para evoluir sua organização SRE.

Discutimos os princípios do SRE que precisam estar em vigor em cada estágio dessa jornada. Embora sua própria jornada varie dependendo do tamanho, da natureza e da distribuição geográfica da sua organização, o caminho que descrevemos para aplicar com sucesso os princípios do SRE e implementar práticas de SRE deve ser generalizável para muitos tipos diferentes de organizações.

Práticas de SRE sem SREs

Mesmo que você não tenha SREs, é possível adotar práticas de SRE utilizando SLOs. Como discutido no Capítulo 2, SLOs são a base para as práticas de SRE. Como tal, eles informam nosso primeiro princípio de SRE:

Princípio #1: SRE precisa de SLOs com consequências.

O desempenho do seu serviço em relação aos SLOs deve orientar suas decisões de negócios.

Acreditamos que as seguintes práticas — que você pode alcançar mesmo sem ter um único SRE — são os passos cruciais para implementar práticas de SRE:

Reconheça que você não deseja 100% de confiabilidade.
Defina uma meta de SLO razoável. Esse SLO deve medir a confiabilidade que é mais importante para seus usuários.
Concorde com uma política de orçamento de erros que ajudará a defender a experiência do usuário. Utilize o orçamento de erros para orientar:
— Ações táticas para mitigar falhas ou gerenciar mudanças que retornem seu sistema a um estado confiável
— Priorização de trabalho a longo prazo para tornar o sistema mais confiável e usar menos do orçamento de erros
Meça o SLO e comprometa-se a seguir a política de orçamento de erros. Esse compromisso requer acordo da liderança da empresa.

Mesmo que uma organização não tenha uma equipe de SRE, acreditamos que vale a pena definir SLOs para aplicações críticas para os clientes e implementar uma política de orçamento de erros, mesmo que apenas porque um SLO implícito de 100% significa que a equipe só pode ser reativa. Este princípio de SRE permite que você tome decisões baseadas em dados sobre como garantir a confiabilidade da sua aplicação.

Iniciando um papel de SRE

Encontrando seu primeiro SRE

É possível que seus primeiros funcionários de SRE não tenham experiência explícita como SRE. Encontramos as seguintes áreas relevantes para o papel de SRE e, portanto, apropriadas para serem abordadas em entrevistas:

Operações

Executar aplicações em produção fornece insights inestimáveis que não podem ser obtidos facilmente de outra forma.

Engenharia de Software

SREs precisam entender o software que estão apoiando e ter a capacidade de melhorá-lo.

Sistemas de monitoramento

Princípios de SRE exigem SLOs que podem ser medidos e contabilizados.

Automação de produção

Escalar operações requer automação.

Arquitetura de sistema

Escalar a aplicação exige uma boa arquitetura.

Seu primeiro SRE provavelmente ocupará uma posição difícil e ambígua entre metas de velocidade e confiabilidade. Eles precisarão ser resilientes e flexíveis para fornecer o equilíbrio certo entre permitir o desenvolvimento do produto e defender a experiência do cliente.

Colocando seu primeiro SRE

Depois de contratar seu primeiro SRE, você precisará decidir onde inseri-lo em sua organização. Você tem três opções principais:

Em uma equipe de desenvolvimento de produto

Em uma equipe de operações

Em um papel horizontal, consultando várias equipes

Recomendamos que você avalie os prós e contras de cada uma dessas três opções após ler este capítulo, levando em consideração:

Seu próprio papel e esfera de influência

Se você consegue influenciar efetivamente as equipes de desenvolvimento de produto, então colocar um SRE em operações ou em um papel horizontal pode ajudar a resolver problemas de produção complexos precocemente.

Os desafios imediatos que você enfrenta

Se os desafios exigem trabalho prático para mitigar um problema técnico ou risco de negócio, então colocar um SRE em uma equipe de operações ou de produto pode ser vantajoso. Isso elimina silos organizacionais e facilita a comunicação entre os membros da equipe.

Os desafios que você espera enfrentar nos próximos 12 meses

Por exemplo, se você está focado em lançamentos, pode fazer sentido colocar o SRE dentro de uma equipe de desenvolvimento de produto. Se você está focado em mudanças de infraestrutura, pode fazer mais sentido alocar o SRE em uma equipe de operações.

Seu plano para como você deseja mudar sua organização

Se você planeja avançar para uma organização SRE centralizada, pode não ser ideal colocar SREs nas equipes de desenvolvimento de produto inicialmente—pode ser difícil removê-los dessas equipes mais tarde.

A pessoa que você identificou como seu primeiro SRE

Decida onde esse primeiro SRE seria mais produtivo com base em seu histórico e habilidades.

Pode fazer sentido experimentar diferentes modelos enquanto você descobre qual abordagem funciona melhor para você. No entanto, recomendamos fortemente que você mantenha um modelo estável e coerente a longo prazo; caso contrário, a instabilidade comprometerá a eficácia do SRE.

Iniciando seu primeiro SRE

A missão inicial do seu primeiro SRE é se familiarizar com o serviço. Para ter um impacto positivo, um SRE precisa entender os problemas atuais do serviço, o esforço necessário (veja o Capítulo 6) e a engenharia necessária para manter o sistema dentro dos SLOs. Se sua organização ainda não tiver SLOs e orçamentos de erros conforme o Princípio #1, seu primeiro SRE precisará realizar a engenharia necessária para projetar e implementar essas ferramentas. Nesse momento, entra em cena nosso segundo princípio de SRE:

Princípio #2: Os SREs devem ter tempo para tornar o amanhã melhor do que hoje.

Sem este princípio, o esforço manual (toil) só aumentará à medida que o uso do serviço cresce e o sistema se torna correspondendo maior e mais complexo. Um equilíbrio saudável entre responsabilidades operacionais e trabalho em projetos é essencial—se o esforço manual se tornar excessivo, engenheiros talentosos abandonarão a equipe. Para mais orientações sobre como uma equipe de SRE pode alcançar esse equilíbrio, veja o Capítulo 17.

O trabalho inicial em projetos pode se concentrar em um dos seguintes aspectos:

Melhorar o monitoramento para entender melhor o sistema quando algo dá errado.
Abordar quaisquer ações de alta prioridade identificadas em postmortems recentes (veja o Capítulo 10).
Implementar automação para reduzir um elemento específico de esforço manual necessário para operar o serviço.

É vital que o SRE tenha um papel distinto e que seus projetos beneficiem toda a equipe. Fique atento a sinais de que o trabalho do SRE não está indo bem:

A mistura de trabalho é indistinguível do trabalho de engenharia de outros membros da equipe.
Se o seu primeiro SRE está em uma equipe de desenvolvimento de produto, ele está fazendo mais do que sua parte justa de trabalho operacional, ou é a única pessoa trabalhando em mudanças de configuração do serviço.
Os SLOs não estão sendo levados a sério, e o SRE não está avançando na medição e defesa da experiência do cliente.

SREs distribuídos

Se sua organização não tem (ou não planeja ter) uma equipe SRE distinta (ou equipes), é importante construir uma comunidade para SREs distribuídos. Esta comunidade deve promover o papel distinto do SRE e impulsionar mudanças consistentes em tecnologia ou práticas voltadas para a confiabilidade entre as equipes. Sem um grupo social, os SREs individuais podem se sentir muito isolados.

Sua primeira equipe de SRE

Você pode iniciar uma equipe de SRE de várias maneiras. Abordagens que utilizamos no Google, do menos ao mais complexo, incluem:

Criar uma nova equipe como parte de um projeto importante
Estabelecer uma equipe de SRE horizontal
Converter uma equipe existente (por exemplo, uma equipe de operações)

A abordagem que é melhor para sua organização é altamente situacional. Uma equipe precisa de um número suficiente de SREs para lidar com as tarefas operacionais necessárias para operar o serviço. Abordar essa carga de trabalho nos leva ao nosso terceiro princípio:

Princípio #3: As equipes de SRE têm a capacidade de regular sua carga de trabalho.

Fora de uma grande organização SRE, uma equipe provavelmente não conseguirá adotar este conceito desde o primeiro dia. Este princípio está aberto a interpretação e pode ser difícil de implementar organizacionalmente. Também é o mais sutil dos nossos três princípios e requer uma explicação mais detalhada. As seções seguintes abordam as etapas de construção de uma equipe, utilizando o modelo de desempenho de Tuckman e os estágios de formação, conflito, normalização e desempenho.

Formação

A equipe que você reunir deve ter experiência e especialização combinadas que incluam o seguinte:

Fazer mudanças no software de aplicação para melhorar a confiabilidade e o desempenho.
Escrever software para:
– Acelerar a detecção e mitigação de problemas em produção.
– Automatizar processos manuais.
Estabelecer e usar práticas e padrões de software sólidos para facilitar a manutenção a longo prazo.
Ter uma abordagem metódica e cuidadosa para fazer mudanças operacionais: ser capaz de descrever por que certas práticas são confiáveis.
Entender a arquitetura do sistema (design e operação de sistemas distribuídos).

Idealmente, sua equipe estará pronta para adotar uma nova forma de trabalho e terá um equilíbrio de habilidades e relacionamentos pessoais estabelecidos com outras equipes. Se possível, recomendamos que você forme a equipe com transferências internas. Isso pode reduzir o tempo necessário para que sua equipe comece a funcionar de forma eficaz.

Criando uma nova equipe como parte de um projeto importante

Você pode criar uma nova equipe de SRE para um projeto grande o suficiente para justificar novos cargos, e para o qual a confiabilidade e a capacidade operacional foram identificadas como riscos do projeto. Exemplos podem incluir a criação de um novo serviço ou uma mudança substancial em sua tecnologia (por exemplo, migração para a nuvem pública).

Montando uma equipe horizontal de SRE

Nesta abordagem (bem documentada no Capítulo 27 do nosso primeiro livro), uma pequena equipe de SREs consulta várias equipes. Esta equipe também pode estabelecer melhores práticas e ferramentas para gerenciamento de configuração, monitoramento e alerta.

Convertendo uma equipe existente

Você pode ser capaz de converter uma equipe existente em uma equipe de SRE. A equipe existente provavelmente não é uma equipe de desenvolvimento de produto; candidatos típicos incluem uma equipe de operações ou uma equipe responsável por gerenciar um componente de código aberto popular que sua organização usa extensivamente. Tenha cuidado para não renomear uma equipe de “Operações” para “SRE” sem antes aplicar práticas e princípios de SRE! Se seu esforço de rebranding falhar, sua organização pode ficar contra o conceito de SRE no futuro.

Conflito

Uma vez formada, a equipe precisa começar a trabalhar de forma colaborativa: os membros da equipe precisam se dar bem uns com os outros e também com outras equipes.

Você pode empregar várias táticas para promover esse tipo de coesão. No Google, tivemos sucesso ao fornecer um fórum regular para aprender e discutir práticas de SRE e refletir sobre o desempenho da equipe. Por exemplo, você pode realizar um almoço regular com transmissões de vídeos do SREcon ou um clube do livro, onde todos leem antecipadamente alguns conteúdos relevantes e discutem como aplicá-los.

Durante esta fase, incentive sua nova equipe de SRE a se desafiar. Seus novos SREs devem se sentir à vontade para falar sobre práticas de SRE que não se encaixam na sua organização e se vale a pena fazer a mudança para que elas se adequem.

Riscos e mitigações

Durante essa fase inicial da jornada SRE, há várias maneiras pelas quais a equipe pode falhar. A seguir, apresentamos alguns riscos e possíveis estratégias de mitigação, divididos de acordo com a forma como a nova equipe foi formada. Você pode usar uma ou mais das estratégias de mitigação para cada risco.

Nova equipe como parte de um projeto importante

Riscos

A equipe:

- - Se espalha demais ao assumir responsabilidade por muitos serviços de uma vez.
    — Uma equipe que está constantemente apagando incêndios não tem tempo para abordar os riscos de maneira mais permanente.

- - Torna-se excessivamente introspectiva ao tentar entender os princípios de SRE e como implementá-los, resultando em baixa entrega.
    — Por exemplo, a equipe pode ficar consumida pelo desenvolvimento da definição perfeita de SLO, negligenciando as necessidades do serviço no meio tempo.

- - Não examina seu trabalho de forma aprofundada, resultando na reversão da gestão do serviço para comportamentos anteriores.
    — A equipe é chamada 100 vezes por dia. Como as páginas não indicam que a intervenção imediata é necessária, elas são ignoradas.

- - Abandona princípios e práticas de SRE para cumprir marcos de produto.
    — Melhorias de confiabilidade para defender o SLO, como mudanças arquitetônicas, podem nunca ser implementadas porque atrasam os cronogramas de desenvolvimento.

- - Se distrai com conflitos com equipes existentes que percebem uma perda de influência ou poder como resultado da nova equipe de SRE.

- - Não possui a amplitude de habilidades necessárias, entregando apenas parte das melhorias necessárias.
    — Sem a capacidade de, por exemplo, programar, os SREs podem não conseguir instrumentar o produto para medir a confiabilidade.

Mitigações

A equipe:

- - Envolve-se inicialmente em um único serviço importante.
  - Envolve-se o mais cedo possível no projeto, idealmente na fase de design.
  - Tem participação no design, com foco particular na definição de SLOs e na análise dos riscos de confiabilidade inerentes ao design.
  - Faz parceria com a equipe de desenvolvimento de produto e trabalha em recursos específicos para confiabilidade e integração com plataformas operacionais existentes.
  - Não é esperada para ter responsabilidade operacional no primeiro dia. Em vez disso, essa responsabilidade inicialmente recai sobre a equipe de desenvolvimento de produto ou equipe do projeto. Isso pode ser uma mudança cultural significativa que necessita de suporte da gestão.
  - Tem um acordo claro sobre as condições que um serviço deve atender para ser incorporado pelo SRE (veja o Capítulo 32 de Site Reliability Engineering).

Além disso:

- - Se o projeto envolve uma migração, a equipe deve ter um sólido entendimento dos ambientes atuais e futuros. Se você precisar recrutar membros externos para a equipe, considere candidatos que tenham conhecimento de engenharia de software e do ambiente futuro.
  - Continue a manter o número de novas contratações abaixo de um terço da equipe para que o esforço de treinamento não sobrecarregue os membros existentes da equipe.

Equipe horizontal de SRE

Riscos

A equipe é percebida como uma nova “organização de controle” que não realiza trabalho real ou não agrega valor real.

Mitigações

A equipe:

- - É formada por engenheiros respeitados que possuem expertise relevante na área.
  - Realiza trabalhos de projeto que se concentram na entrega de ferramentas (para monitoramento, alerta, implantações, melhores práticas, checklists). Essas ferramentas devem ter um impacto benéfico de curto prazo em pelo menos duas outras equipes.
  - Comunica sucessos e benefícios. Uma equipe de SRE que faz um avanço em eficiência, automatiza tarefas manuais ou elimina permanentemente uma fonte de falta de confiabilidade do sistema deve ser celebrada.
  - Se vê como facilitadora, não como guardiã. Foque em soluções, não apenas em problemas.

Equipe convertida no local

Riscos

A equipe:

- - Percebe que o processo de conversão é o início de uma jornada lenta rumo à perda de empregos, à medida que a automação substitui os humanos.
  - Não apoia a mudança para uma equipe de SRE.
  - Não tem capacidade de folga que possa ser aproveitada para mudar as atividades diárias da equipe.
  - Não vê benefício em sua rotina diária após alguns meses.
  - Trabalha com sistemas que não suportam scripting ou automação.
  - Não possui as habilidades de engenharia de software necessárias para automatizar sua carga de trabalho atual.
  - Não possui consistentemente as habilidades necessárias para evoluir para SRE, ou interesse em adquirir essas habilidades.

Mitigações

A equipe:

- - Obtém o apoio da alta liderança para a mudança.
  - Renegocia responsabilidades para criar a folga necessária para efetuar a mudança.
  - Gerencia a comunicação da mudança com muito cuidado.
  - Tem acesso a suporte pessoal e técnico robusto durante toda a transição.
  - Lida diretamente com a preocupação sobre a perda de empregos. Em muitos ambientes, a automação elimina partes do trabalho, mas não os empregos como um todo; embora isso possa ser um passo no caminho para a perda de empregos, pelo menos libera tempo para fazer algo melhor (e mais valorizável para um futuro empregador) do que o trabalho manual não automatizado.
  - Consegue escapar da sobrecarga operacional e ter um impacto mais significativo. Se os engenheiros reduzirem o volume de trabalho manual a ponto de necessitar uma equipe menor, sua experiência deve ser altamente reutilizável em outras áreas da sua organização. Se a experiência deles não puder ser usada internamente, deve proporcionar uma vantagem na busca por trabalho em outros lugares.
  - Recebe treinamento para adquirir as habilidades necessárias para SREs. Sua equipe de desenvolvimento de produto pode fornecer treinamento sobre o produto, enquanto a orientação de SRE pode fazer uso deste livro e de outros recursos externos.
  - Muda a forma como o desempenho é avaliado—métricas que avaliam tanto a equipe quanto os indivíduos. As métricas da equipe devem estar alinhadas com os SLOs e a adoção de outras práticas de SRE; as métricas individuais devem estar alinhadas com evidências das habilidades de SRE.
  - Adiciona um SRE ou desenvolvedor experiente à equipe.
  - Tem a liberdade (orçamento ou tempo) para identificar e introduzir novos sistemas de monitoramento e alerta baseados em código aberto ou na nuvem para permitir a automação. Determinar se os sistemas existentes são suficientes deve ser uma prioridade inicial.
  - Revisa regularmente o progresso internamente e com as partes interessadas.

Norming

Norming envolve superar os problemas levantados em “Riscos e Mitigações” e alcançar um amplo acordo sobre as melhores práticas para as equipes de SRE da organização. As equipes precisam concordar sobre um nível aceitável de trabalho manual, limites adequados de alerta e práticas importantes e relevantes de SRE. Além disso, as equipes devem se tornar autossuficientes na identificação proativa dos desafios futuros do serviço e na definição de metas de médio e longo prazo para melhorar o serviço.

Durante a fase de Norming, as equipes devem alcançar os seguintes níveis de maturidade:

Os SLOs e os orçamentos de erro estão em vigor, e a política de orçamento de erro é aplicada após incidentes significativos. A liderança está interessada nas medições dos SLOs.
As rotações de plantão são estabelecidas e sustentáveis (veja o Capítulo 8). Os engenheiros de plantão são compensados pelo tempo de plantão. Há ferramentas, documentação e treinamento suficientes para apoiar qualquer membro da equipe durante um incidente significativo.
O trabalho manual é documentado, delimitado e gerenciado. Como resultado, os SREs completam projetos impactantes que melhoram a confiabilidade e a eficiência.
A cultura de postmortem está bem estabelecida (veja o Capítulo 10).
A equipe exibe a maioria dos princípios listados no Capítulo 1.
À medida que a equipe resolve os problemas iniciais listados em “Storming,” ela captura o que aprendeu e evita a repetição de problemas. A equipe realiza regularmente exercícios de treinamento, como Wheel of Misfortune ou DiRT (Disaster Recovery Testing). (Para mais informações sobre treinamento de plantão, veja o Capítulo 11 do nosso primeiro livro e o Capítulo 18 deste livro.)
A equipe de desenvolvimento de produto se beneficia por permanecer envolvida na rotação de plantão.
A equipe produz relatórios regulares (por exemplo, trimestrais) para seus stakeholders, que cobrem os destaques, os pontos negativos e as principais métricas do período de relatório.

______

Transformando uma equipe existente em uma equipe SRE

Por Brian Balser, New York Times

Quando o New York Times formou seu departamento de Entrega e Engenharia de Confiabilidade de Sites, montamos equipes de SRE a partir de engenheiros que já possuíam habilidades típicas de SRE, como construção de ferramentas e operação de sistemas de produção. Algumas equipes eram “greenfield”: foram projetadas com SRE em mente, tanto em relação ao talento quanto à visão e responsabilidade. Outras equipes já existiam há vários anos e acabaram assumindo a arquitetura de produção devido a uma combinação de conjuntos de habilidades, interesses e acaso.

Desafios

Uma das equipes existentes em transição para SRE estava em uma posição muito desafiadora. Com o passar dos anos, a equipe havia assumido a responsabilidade de gerenciar configurações, solicitações de mudanças e operações de um componente central da arquitetura do site. Eles efetivamente se tornaram uma equipe de serviço apoiando todas as nossas equipes de desenvolvimento de produto. Seu trabalho era guiado por tickets e problemas de produção, e estavam em um modo contínuo e reativo. Não tinham tempo para fazer melhorias, inovar ou realizar outros trabalhos estratégicos de maior valor.

Embora a equipe tivesse muitas ideias ótimas, estava sobrecarregada com trabalho manual e uma série de solicitações de serviço “bloqueadoras” de alta prioridade, geralmente ligadas a lançamentos de produtos. Esse modelo não era sustentável, e a equipe teria que crescer linearmente com os produtos para acompanhar esse fardo de suporte. Para agravar a situação, a pequena equipe tinha um grande volume de conhecimento institucional que havia se acumulado ao longo dos anos. Um alto volume de interrupções de equipes que precisavam dessas informações agravava a sobrecarga da equipe, e um fator de risco elevado pairava sobre ela.

Trabalhando a partir dos princípios fundamentais

Um princípio orientador da nossa organização de SRE é nos afastarmos do caminho crítico e empoderar as equipes de desenvolvimento de produto com soluções de autoatendimento. Com isso em mente, nosso objetivo ficou claro: inverter o modelo de responsabilidade para permitir que as equipes de desenvolvimento de produto implementem suas próprias mudanças. Esta estratégia teria dois benefícios principais:

Acelerar a entrega.
Liberar os SREs da gestão da rotatividade de configurações, permitindo que façam melhorias reais no sistema como um todo.

Melhoria de processos

Melhoramos nossos processos através de várias etapas de mudança:

Incorporamos um SRE na equipe de desenvolvimento para ajudar a aliviar a pressão.
Para permitir que as equipes de desenvolvimento de produto assumam a responsabilidade pela configuração de seus serviços de forma isolada, separamos cada configuração de serviço em um repositório baseado na equipe.
Migramos cada serviço do sistema de CI legado para nosso pipeline padrão de Drone CI/CD. O fluxo de trabalho amigável ao desenvolvedor foi completamente impulsionado por eventos do GitHub.
Integramos cada uma das equipes de produto às novas ferramentas e ao novo fluxo de trabalho para que pudessem enviar suas próprias solicitações de mudanças sem depender de um ticket de serviço.

Enquanto essas melhorias foram um grande avanço, ainda não havíamos alcançado nosso estado final ideal. A revisão de pull requests ainda frequentemente exigia expertise em SRE. Para tornar as interrupções causadas por revisões demoradas mais gerenciáveis, programamos horas de atendimento diárias. Essa prática consistente nos permitiu agrupar perguntas e discussões de forma mais previsível, e também proporcionou um espaço para compartilhar conhecimentos com as equipes em processo de integração.

Resultado final e próximos passos

A equipe de SRE agora está atingindo seu objetivo inicial de mais de 50% de trabalho em projetos (em comparação com trabalho relacionado a suporte). A equipe ainda possui uma vasta quantidade de conhecimento institucional, mas esse conhecimento está sendo disseminado de forma mais ampla, melhorando gradualmente o fator de risco e reduzindo as interrupções.

Agora que temos espaço para trabalho em projetos, nossos próximos passos são focar em adicionar capacidades mais avançadas, como implementações canárias, melhores ferramentas de teste e recursos de observabilidade e resiliência. Isso dará às equipes de desenvolvimento de produto mais confiança para exercer total autonomia sobre suas configurações de serviço, sem depender dos SREs para a gestão de mudanças.

______

Estabelecer um relacionamento saudável com sua equipe de desenvolvimento de produto forma a base de muitas dessas estratégias de mitigação. As equipes devem planejar o trabalho juntas, de acordo com o ciclo de planejamento da sua organização.

Antes de passar para o próximo passo: faça uma pausa, celebre esse sucesso e escreva uma retrospectiva que cubra sua jornada até agora.

Desempenho

A experiência da equipe SRE com produção e o trabalho realizado até este ponto deve ter conquistado o respeito e a atenção da organização mais ampla, estabelecendo a base para avançar estrategicamente. Na fase final do modelo de desempenho de Tuckman, desempenho, você deve esperar:

Parceria em todo o design e mudança de arquitetura

Desde a fase de design inicial, a equipe SRE deve definir os padrões para como o software é construído e estruturado para garantir a confiabilidade.

Determinação completa da carga de trabalho

As equipes devem aplicar consistentemente o Princípio 3 com a visão da saúde holística do sistema.

Parceria em arquitetura

A equipe de desenvolvimento de produtos deve começar a buscar a equipe SRE parceira para obter conselhos sobre todas as mudanças significativas no serviço. A equipe SRE agora tem a oportunidade de ter um dos seus maiores impactos.

Por exemplo, a equipe SRE pode fornecer contribuições iniciais para o design de uma nova arquitetura de serviço, reduzindo a probabilidade de reengenharia de alto custo no futuro. As equipes de desenvolvimento e SRE podem reconhecer suas diferenças de perspectiva nas decisões arquitetônicas para chegar a um bom processo de design. Um engajamento bem-sucedido pode agregar valor através de:

Melhoria na confiabilidade, escalabilidade e operabilidade
Melhor reutilização de padrões existentes
Migração mais simples (se necessário)

Autoregulação da carga de trabalho

Enquanto parcerias arquitetônicas devem emergir de forma um pouco orgânica ao longo do tempo, uma equipe SRE deve afirmar claramente o Princípio #3 para seus parceiros. Fazer isso requer uma forte liderança de equipe e um compromisso claro e prévio da alta administração. A capacidade de regular sua própria carga de trabalho garante à equipe SRE sua posição como uma equipe de engenharia que trabalha nos serviços mais importantes da organização, equiparada a seus pares da equipe de desenvolvimento de produtos.

Na prática, como uma equipe SRE determina sua própria carga de trabalho depende das equipes com as quais os SREs interagem. No Google, as equipes SRE interagem mais comumente com uma equipe de desenvolvimento de produtos distinta. Nesse caso, o relacionamento tem as seguintes características:

Uma equipe SRE escolhe se e quando incorporar um serviço (veja o Capítulo 32 de Site Reliability Engineering).
Em caso de sobrecarga operacional, a equipe pode reduzir o trabalho manual por:
— Reduzir o SLO
— Transferir o trabalho operacional para outra equipe (por exemplo, uma equipe de desenvolvimento de produtos)
Se se tornar impossível operar um serviço dentro dos limites de trabalho acordados e no SLO, a equipe SRE pode devolver o serviço para a equipe de desenvolvimento de produtos.
O envolvimento da SRE não é perpétuo — ele se sustenta resolvendo problemas em escala e melhorando a confiabilidade dos serviços. Se uma equipe SRE resolveu todos os problemas desse tipo para um serviço, você precisa:
— Considerar intencionalmente quais outros desafios de confiabilidade a equipe SRE precisa enfrentar.
— Tomar uma decisão intencional de devolver o serviço para a equipe de desenvolvimento de produtos.
Caso contrário, sua equipe corre o risco de rotatividade à medida que os SREs buscam oportunidades mais interessantes. A perda lenta devido à rotatividade pode colocar a produção em risco.

Nem todas as equipes de SRE têm equipes parceiras de desenvolvimento de produtos. Algumas equipes de SRE também são responsáveis por desenvolver os sistemas que gerenciam. Algumas equipes de SRE empacotam software, hardware ou serviços de terceiros (por exemplo, pacotes de código aberto, equipamentos de rede, algo-como-um-serviço) e transformam esses ativos em serviços internos. Nesse caso, você não tem a opção de transferir o trabalho para outra equipe. Em vez disso, considere as seguintes táticas:

Se o serviço não estiver conforme o SLO, pare o trabalho em projetos relacionados a recursos em favor de trabalho focado em confiabilidade.
Se se tornar impossível operar um serviço no SLO dentro dos limites de trabalho acordados, reduza seus SLOs — a menos que a administração forneça mais capacidade (pessoas ou infraestrutura) para lidar com a situação.

Fazendo mais equipes de SRE

Uma vez que sua primeira equipe SRE esteja funcionando, você pode querer formar uma equipe SRE adicional. Você pode fazer isso por um dos seguintes motivos:

Complexidade do serviço

À medida que um serviço ganha usuários e recursos, ele se torna mais complexo e difícil para uma única equipe SRE suportar de maneira eficaz. Você pode querer dividir a equipe em subequipes que se especializem em partes do serviço.

Implementação de SRE

Se sua primeira equipe SRE foi bem-sucedida e fez uma diferença clara, pode haver um interesse organizacional em adotar essa abordagem em mais serviços.

Divisão geográfica

Você deseja dividir a equipe em duas metades em diferentes fusos horários e passar para turnos de plantão de 12 horas.

Ao criar uma nova equipe SRE, recomendamos que você faça o seguinte:

Leia quaisquer relatórios pós-morte escritos após a formação de outras equipes. Identifique e repita o que deu certo e corrija e explore alternativas para o que não deu certo.
Forme a nova equipe com SREs da equipe existente — alguns dos seus melhores SREs e SREs com maior potencial que podem enfrentar o desafio. Em nossa experiência, encontrar candidatos qualificados para SRE é difícil, então formar rapidamente uma equipe com novas contratações muitas vezes não é realista.
Padronize o framework para estabelecer equipes e integrar serviços (veja o Capítulo 18).
Faça mudanças nas responsabilidades de plantão lentamente. Por exemplo:
— Para evitar uma perda repentina de engenheiros de plantão qualificados, mantenha os membros da equipe de plantão para os sistemas da equipe anterior por um período de transição. — Após a divisão das equipes, espere de três a seis meses para dividir as rotações de plantão.

Complexidade do serviço

Onde dividir

Se um serviço se tornar muito complexo para uma única equipe gerenciar, existem várias maneiras de dividir o trabalho. Considere as seguintes opções para simplificar a carga cognitiva dos membros da equipe:

Divisões arquitetônicas

Por exemplo, computação, armazenamento e rede; frontend e backend; frontend e banco de dados; cliente e servidor; frontend e pipelines.

Divisões por linguagem

Os princípios de SRE não dependem de linguagens de programação. No entanto, se seus SREs estiverem profundamente envolvidos no código-fonte, pode haver algum benefício em uma divisão ao longo dessas linhas.

Divisões por localização

Se a engenharia da sua organização abrange vários escritórios, você pode querer alinhar a localização das equipes SRE com o desenvolvimento de aplicativos.

Armadilhas

Quando uma equipe se divide, às vezes nenhuma das novas equipes assume a responsabilidade por um componente anteriormente gerido pela equipe original. Para mitigar esse risco, você pode:

Designar uma equipe como responsável por tudo o que não está coberto pelo escopo da segunda equipe.
Nomear um SRE sênior para um papel de liderança técnica abrangente em ambas as equipes.

Implementação de SRE

Se suas equipes SRE iniciais forem bem-sucedidas, sua organização pode querer mais delas. Recomendamos priorizar cuidadosamente os serviços que receberão suporte de SRE. Considere os seguintes pontos:

Priorize serviços para os quais a confiabilidade tem um grande impacto financeiro ou reputacional. Quanto maior o impacto, maior a prioridade.
Defina o conjunto mínimo viável de serviços que precisam estar funcionando para que o produto funcione. Priorize esses serviços e certifique-se de que os outros serviços se degradem de forma graciosa.
Um serviço não deve ser prioridade para SRE simplesmente porque é pouco confiável. SRE deve ser aplicado taticamente onde é mais relevante para o negócio. Você também não deve permitir que seus desenvolvedores ignorem a confiabilidade até que os SREs sejam envolvidos.

Divisões geográficas

Como descrito no Capítulo 11 do nosso primeiro livro, o Google frequentemente aloca equipes SRE irmãs em diferentes continentes. Fazemos isso por vários motivos:

Confiabilidade do serviço

Se um grande incidente (por exemplo, desastre natural) impedir uma equipe de operar, a outra equipe pode continuar a dar suporte ao serviço.

Estresse de plantão

Dividir a rotação de pager em turnos de 12 horas permite pausas adequadas para os engenheiros de plantão.

Recrutamento e retenção de talentos

Um turno de plantão que coincide com o horário normal de trabalho amplia a base de engenheiros que podemos recrutar para funções SRE, e enfatiza a parte de engenharia do nosso papel.

Maturidade da produção

Dividir a responsabilidade pelo serviço entre dois escritórios tende a levar a uma melhoria na maturidade, à medida que a necessidade de documentação, treinamento e padronização se torna mais importante.

Se a sua organização tiver a sorte de já ter equipes de engenharia em múltiplos continentes, recomendamos a formação de equipes SRE multisite. É possível ter uma equipe SRE em um escritório diferente da equipe de desenvolvimento, mas em nossa experiência, a colocalização oferece benefícios na forma de um diálogo saudável e robusto entre as equipes. Caso contrário, é mais difícil para os SREs entender como os serviços evoluem ou como a infraestrutura técnica é usada, e é mais difícil para os desenvolvedores de produto serem otimistas sobre melhorias na infraestrutura.

Posicionamento: quantos fusos horários de distância devem ter as equipes?

Assumindo que você tenha alguma escolha, a separação por fuso horário é uma consideração importante na decisão de onde localizar as duas equipes. Infelizmente, os objetivos são mutuamente exclusivos:

Minimizar o número de horas que os responsáveis pelo plantão têm que trabalhar fora do horário normal de expediente
Maximizar o tempo de sobreposição quando ambas as equipes estão online para que possam interagir regularmente umas com as outras

A situação é complicada pelo Horário de Verão.

Em nossa experiência, alocar equipes em fusos horários que estão de seis a oito horas de distância funciona bem e evita turnos de plantão das 0h às 6h. Você pode usar recursos online como https://www.timeanddate.com/worldclock/meeting.html para visualizar as sobreposições de fusos horários para várias localidades.

Pessoas e projetos: formando a equipe

Quando você divide uma equipe geograficamente, a primeira equipe SRE em um novo escritório estabelecerá as normas para as futuras equipes SRE. Sua probabilidade de sucesso será muito maior se você puder identificar um ou mais SREs que estejam dispostos a se mudar do local original de forma temporária ou permanente para estabelecer as práticas de SRE e recrutar e treinar a nova equipe. A nova equipe também deve empreender um projeto de alto valor que fomente a colaboração dentro da equipe e exija interação com sua equipe irmã.

Paridade: distribuindo o trabalho entre escritórios e evitando um “Turno Noturno”

Frequentemente, uma das duas equipes SRE irmãs está colocalizada (ou pelo menos no mesmo fuso horário) com a equipe de desenvolvimento de produtos (chamaremos isso de “Escritório 1”). Se esse for o caso, esteja atento para garantir que a equipe que não está colocalizada (“Escritório 2”) não se torne um turno noturno com pouco contato com a equipe de desenvolvimento de produtos, que pegue uma parte desproporcional de trabalho excessivo ou que seja atribuída apenas aos projetos menos interessantes ou impactantes.

As cargas de trabalho dos dois escritórios terão algumas diferenças naturais:

Seu serviço provavelmente tem um pico diário, e um escritório estará de plantão durante esse pico. Como resultado, a experiência de plantão dos dois locais será diferente.
Seu processo de desenvolvimento produzirá novos lançamentos com uma cadência específica. Um escritório provavelmente assumirá mais do ônus associado a implantações e reversões.
O Escritório 1 é mais propenso a ser interrompido durante seu horário de trabalho por perguntas da equipe de desenvolvimento de produtos.
É mais fácil para o Escritório 1 realizar trabalho de projeto associado a grandes lançamentos. Por outro lado, é mais fácil para o Escritório 2 realizar trabalho de projeto desvinculado dos objetivos imediatos do produto.

Você pode ajudar a manter o equilíbrio usando as seguintes práticas:

Equilibre a carga de plantão entre os escritórios. Designe uma maior porcentagem de tickets para o escritório que recebe uma menor porcentagem de páginas.
Associe áreas de desenvolvimento a equipes SRE em um escritório específico. Isso pode ser de curto prazo (por exemplo, de acordo com o projeto) ou de longo prazo (por exemplo, de acordo com o serviço). Caso contrário, a equipe de desenvolvimento de produtos provavelmente recorrerá ao Escritório 1 e não se engajará efetivamente com os SREs no Escritório 2.
Atribua uma maior porcentagem de projetos de melhoria interna de serviços (que provavelmente exigirão menos envolvimento com a equipe de desenvolvimento de produtos) ao Escritório 2.
Distribua de maneira justa os projetos mais interessantes e impactantes entre os dois escritórios.
Mantenha um tamanho de equipe e uma mistura de senioridade semelhantes entre os dois escritórios.
Divida os projetos entre os dois locais para fomentar deliberadamente as interações entre os escritórios de SRE. Embora a execução de um grande projeto a partir de um único escritório possa oferecer algumas eficiências, dividir os projetos entre os dois sites ajuda a espalhar o conhecimento e constrói confiança entre os escritórios.
Permita que os engenheiros viagem para o outro escritório regularmente. Isso permite criar um melhor relacionamento e, portanto, maior disposição para trabalhar do lado oposto.

Posicionamento: e quanto a ter três turnos?

Nossas tentativas de dividir equipes SRE entre três locais resultaram em vários problemas:

É impossível realizar uma reunião de produção entre escritórios que todos os SREs possam participar (veja o Capítulo 31 do nosso primeiro livro).
É mais difícil garantir a paridade de conhecimento, capacidade e resposta operacional entre três escritórios.
Se todas as funções de plantão ocorrem apenas durante o horário de expediente, há menos incentivo para automatizar tarefas repetitivas e páginas de baixo valor. Ser o herói que resolve problemas fáceis é divertido durante o horário de expediente. Mas se isso envolve algum custo pessoal, a motivação para garantir que isso nunca aconteça novamente é aguda e imediata.

Temporização: as duas metades da equipe devem começar ao mesmo tempo?

Você pode criar equipes irmãs usando qualquer um dos seguintes modelos:

Ambas as metades começam ao mesmo tempo.
Configure o escritório que está colocalizado com a equipe de desenvolvimento de produtos primeiro. Isso permite que os SREs se envolvam mais cedo no ciclo de vida do produto.
Configure o escritório que não está colocalizado com a equipe de desenvolvimento de produtos primeiro ou, se um serviço estiver em produção há algum tempo, a equipe SRE e a equipe de desenvolvimento de produtos podem compartilhar o pager.
Comece a fazer mudanças de acordo com onde as pessoas certas estão no momento certo.

Finanças: orçamento de viagens

É muito importante criar oportunidades para interações de alta qualidade entre as duas metades da equipe. Apesar da eficácia das videoconferências para reuniões do dia a dia, descobrimos que interações regulares presenciais contribuem significativamente para a construção de relacionamentos saudáveis e confiança. Recomendamos que:

Todo SRE, gerente de desenvolvimento de produtos e líder técnico no Site 1 visite o Site 2 anualmente (no mínimo), e vice-versa.
Todo SRE em um cargo de gestão ou liderança técnica no Site 1 visite o Site 2 pelo menos duas vezes por ano, e vice-versa.
Todos os SREs se reúnam pelo menos uma vez por ano.

Liderança: propriedade conjunta de um serviço

Se você tem múltiplos sites SRE, é provável que haja tomadores de decisão em cada escritório. Essas partes devem se encontrar regularmente, presencialmente e por videoconferência. Apenas estabelecendo um forte relacionamento pessoal eles podem:

Debater soluções para desafios que a equipe enfrenta.
Resolver diferenças de opinião e concordar com um caminho conjunto a seguir.
Defender a equipe um do outro (para evitar uma mentalidade de “nós contra eles”).
Apoiar a saúde da equipe um do outro.

Práticas sugeridas para gerenciar muitas equipes

Novos desafios surgem à medida que sua organização acumula mais SREs e equipes SRE. Por exemplo, você precisará:

Garantir que você ofereça aos SREs as oportunidades de carreira de que precisam.
Incentivar a consistência nas práticas e ferramentas.
Lidar com serviços que não justificam um engajamento completo de SRE.

Esta seção descreve várias das práticas que adotamos no Google para lidar com essas preocupações. Dependendo das especificidades de sua organização, algumas ou muitas podem funcionar para você também.

Controle de missão

O programa de Controle de Missão do Google oferece aos engenheiros das equipes de desenvolvimento de produtos a oportunidade de passar seis meses integrados a uma equipe SRE. Normalmente, esses engenheiros são designados para equipes SRE que trabalham em uma área claramente diferente de sua expertise. O engenheiro de software é treinado em sistemas e práticas de produção e eventualmente assume plantão para esse serviço. Após seis meses, alguns engenheiros decidem permanecer na SRE; outros retornam às suas equipes antigas com uma apreciação muito melhor pelo ambiente de produção e pelas práticas de SRE. As equipes SRE se beneficiam de recursos de engenharia adicionais e ganham uma visão valiosa sobre lacunas e imprecisões no material de treinamento e na documentação.

Troca de SRE

O programa de Troca de SRE do Google permite que um SRE passe uma semana trabalhando ao lado de uma equipe SRE diferente. O SRE visitante observa como a equipe anfitriã trabalha e compartilha práticas de sua equipe de origem que podem ser úteis para a equipe anfitriã. No final da troca, o SRE visitante escreve um relatório de viagem descrevendo sua semana, suas observações e suas recomendações para ambas as equipes. Este programa é útil no Google porque nossas equipes SRE são altamente especializadas.

Treinamento

O treinamento é fundamental para a capacidade da SRE de operar sistemas. Embora a maior parte seja oferecida dentro da equipe (veja “Roteiro de Treinamento” na página 150 do Capítulo 8), considere estabelecer um currículo de treinamento padrão para todos os SREs. No Google, todos os novos SREs participam do SRE EDU, um treinamento imersivo de uma semana que introduz conceitos-chave, ferramentas e plataformas com os quais quase todos os SREs trabalham. Isso fornece um nível básico de conhecimento entre todos os novos SREs e simplifica os objetivos de treinamento específicos da equipe e do serviço. A equipe do SRE EDU também realiza uma segunda série de aulas alguns meses depois, cobrindo as ferramentas e processos comuns que usamos para gerenciar grandes incidentes. Nosso processo de gestão de desempenho reconhece especificamente os SREs que facilitam esse treinamento.

Projetos horizontais

Como as equipes SRE estão fortemente alinhadas com um conjunto de serviços, há uma tentação para as equipes criarem soluções proprietárias para lidar com os desafios que encontram—por exemplo, ferramentas de monitoramento, implantação de software e configuração. Isso pode levar a uma duplicação significativa de esforços entre as equipes. Embora haja valor em permitir que várias soluções competam pela adoção “no mercado”, em algum momento, faz sentido convergir para uma solução padrão que:

Atenda à maioria dos requisitos das equipes
Forneça uma plataforma estável e escalável sobre a qual a próxima camada de inovação possa ser construída

O Google aborda esses esforços usando equipes horizontais, que são frequentemente compostas por SREs experientes. Essas equipes horizontais constroem e executam uma solução padrão e fazem parcerias com outras equipes SRE para garantir uma adoção tranquila. (Para mais informações sobre desenvolvimento de software horizontal, veja “Estudo de caso 2: adoção de ferramentas comuns em SRE” na do Capítulo 21).

Mobilidade SRE

O Google faz o possível para garantir que os engenheiros realmente queiram fazer parte de suas respectivas equipes. Para isso, garantimos que os SREs possam (e estejam cientes de que podem) transferir-se entre equipes. Supondo que não haja problemas de desempenho, os SREs são livres para se transferir para outras equipes SRE com vagas abertas. SREs que também passaram na nossa seleção para cargos de engenheiro de software podem se transferir para equipes de desenvolvimento de produtos.

Esse nível de mobilidade é muito saudável para indivíduos e equipes por várias razões:

Engenheiros podem identificar e ocupar funções de interesse.
Se as circunstâncias pessoais mudarem e as responsabilidades de plantão se tornarem impraticáveis, os SREs podem explorar oportunidades em equipes com funções de plantão menos exigentes. Eles podem obter essas informações conversando com outras equipes e revisando estatísticas de plantão da equipe.
SREs que se movem entre equipes ampliam a experiência das equipes que entram.
SREs que se movem entre escritórios ajudam a construir ou manter a consistência cultural entre diferentes escritórios.
SREs não são obrigados a trabalhar em serviços que estão insalubres ou para gerentes que não apoiam seu desenvolvimento pessoal.

Essa política também tem o efeito colateral de manter seus gerentes SRE focados em serviços e equipes saudáveis e felizes.

Viagens

Além das viagens necessárias para manter as equipes geograficamente divididas saudáveis (veja a seção “Finanças: Orçamento de viagens”), considere o financiamento para:

Construir comunidades internas de interesse que incluam SREs de vários escritórios. Esses grupos podem colaborar principalmente por e-mail e videoconferência, mas devem se encontrar pessoalmente pelo menos uma vez por ano.
Participar e apresentar em conferências de SRE e relacionadas à SRE de âmbito industrial para ampliar o conhecimento, aprender como outras organizações enfrentam problemas semelhantes e, esperançosamente, se inspirar e se energizar.

Equipes de Engenharia de Coordenação de lançamento

Como descrito no Capítulo 27 do nosso primeiro livro, uma equipe de Engenharia de Coordenação de Lançamento (LCE) pode aplicar princípios de SRE a um conjunto mais amplo de equipes de desenvolvimento de produtos—equipes que constroem serviços que não exigem o nível de atenção que justifica o engajamento completo de SRE. Assim como qualquer outra equipe SRE, uma equipe LCE deve estar ativamente envolvida na automação de suas operações diárias. Por exemplo, o desenvolvimento de ferramentas e frameworks padrão permite que as equipes de desenvolvimento de produtos projetem, construam e lancem seus serviços em um ambiente de produção.

Excelência em produção

À medida que o número de equipes SRE em sua organização cresce, uma série de melhores práticas surgirá. Cada equipe SRE evolui de maneira diferente, por isso a avaliação delas requer SREs seniores com visão sobre múltiplas equipes.

No Google, realizamos uma revisão regular de serviços chamada Excelência em Produção. Periodicamente, líderes seniores de SRE revisam cada equipe SRE, avaliando-as com base em uma série de medidas padrão (por exemplo, carga de pager, uso do orçamento de erros, conclusão de projetos, taxas de fechamento de bugs). A revisão tanto elogia o desempenho excepcional quanto fornece sugestões para equipes com desempenho abaixo do esperado.

SREs experientes estão preparados para avaliar cenários complexos. Por exemplo, pode ser desafiador identificar se uma queda na taxa de conclusão de projetos é causada por uma fusão ou divisão de equipe ou por problemas genuínos de desempenho da equipe. Se uma equipe está em risco de ficar sobrecarregada, os revisores podem e devem usar sua posição organizacional para apoiar a liderança da equipe na correção da situação.

Financiamento e contratação de SRE

No Google, utilizamos duas práticas para garantir que cada SRE contribua com um valor significativo:

Grande parte do financiamento para SRE vem da mesma fonte que o financiamento das equipes de desenvolvimento de produtos. Semelhante ao teste ou segurança, a confiabilidade é um pilar central do desenvolvimento de produtos e é financiada como tal.
Em nossa experiência, a oferta de SREs é sempre menor que a demanda por eles. Essa dinâmica garante que revisemos e priorizemos regularmente os serviços que recebem suporte de SRE.

Em resumo, você deve ter menos SREs do que a organização gostaria, e apenas o número suficiente de SREs para realizar seu trabalho especializado.

No Google, a proporção de SREs para engenheiros em equipes de desenvolvimento de produtos varia de cerca de 1:5 (por exemplo, serviços de infraestrutura de baixo nível) a cerca de 1:50 (por exemplo, aplicativos voltados para o consumidor com um grande número de microsserviços construídos usando frameworks padrão). Muitos serviços estão no meio dessa faixa, com uma proporção em torno de 1:10.

Conclusão

Acreditamos que uma organização de qualquer tamanho pode implementar práticas de SRE aplicando os seguintes três princípios:

SRE precisa de SLOs com consequências.
SREs devem ter tempo para tornar o amanhã melhor do que hoje.
Equipes SRE têm a capacidade de regular sua carga de trabalho.

Desde que o Google começou a falar publicamente sobre SRE, ele evoluiu de práticas específicas do Google para uma profissão praticada em muitas empresas. Esses princípios muitas vezes se mostraram verdadeiros—tanto ao longo de nossos anos de experiência direta em grande escala quanto durante nossa experiência mais recente de trabalhar com nossos clientes na adoção de práticas de SRE. Como vimos essas práticas funcionando tanto dentro quanto fora do Google, acreditamos que essas recomendações devem se mostrar úteis em uma variedade de organizações de diferentes tipos e tamanhos.