Por Alex Bramley, Ben Lutch, Michelle Duffy e Nir Tarcic com Betsy Beyer
Na introdução do primeiro livro de SRE, Ben Treynor Sloss descreve as equipes de SRE como “caracterizadas tanto pela rápida inovação quanto por uma grande aceitação de mudanças” e especifica a gestão de mudanças organizacionais como uma responsabilidade central de uma equipe de SRE. Este capítulo examina como a teoria pode ser aplicada na prática em equipes de SRE. Após revisar algumas teorias-chave de gestão de mudanças, exploramos dois estudos de caso que demonstram como diferentes estilos de gestão de mudanças se manifestaram de maneiras concretas no Google.
Observe que o termo “gestão de mudanças” tem duas interpretações: gestão de mudanças organizacionais e controle de mudanças. Este capítulo examina a gestão de mudanças como um termo coletivo para todas as abordagens destinadas a preparar e apoiar indivíduos, equipes e unidades de negócios na realização de mudanças organizacionais. Não discutimos este termo no contexto de gerenciamento de projetos, onde pode ser usado para se referir a processos de controle de mudanças, como revisão de mudanças ou versionamento.
SRE abraça a mudança
Há mais de 2.000 anos, o filósofo grego Heráclito afirmou que a mudança é a única constante. Esse axioma ainda é válido hoje—especialmente no que diz respeito à tecnologia e, particularmente, nos setores de internet e nuvem em rápida evolução.
As equipes de produto existem para criar produtos, lançar funcionalidades e encantar os clientes. No Google, a maioria das mudanças ocorre em um ritmo acelerado, seguindo uma abordagem de “lançar e iterar”. Executar essas mudanças normalmente requer coordenação entre sistemas, produtos e equipes distribuídas globalmente. Os engenheiros de confiabilidade de sites (SREs) estão frequentemente no centro desse cenário complexo e em rápida mudança, responsáveis por equilibrar os riscos inerentes à mudança com a confiabilidade e disponibilidade do produto. Error budgets (veja o Capítulo 2) são um mecanismo primário para alcançar esse equilíbrio.
Introdução à gestão de mudanças
A gestão de mudanças, como área de estudo e prática, cresceu desde os trabalhos fundamentais de Kurt Lewin na década de 1940. As teorias se concentram principalmente no desenvolvimento de estruturas para gerenciar mudanças organizacionais. Uma análise aprofundada de teorias específicas está além do escopo deste livro, mas para contextualizá-las no âmbito do SRE, descrevemos brevemente algumas teorias comuns e como cada uma pode ser aplicável em uma organização do tipo SRE. Embora os processos formais implícitos nesses quadros teóricos não tenham sido aplicados pelos SREs no Google, considerar as atividades de SRE sob a ótica dessas estruturas nos ajudou a refinar nossa abordagem para gerenciar mudanças. Após essa discussão, apresentaremos alguns estudos de caso que demonstram como elementos de algumas dessas teorias se aplicam às atividades de gestão de mudanças lideradas pelo SRE do Google.
O modelo de Três Estágios de Lewin
O modelo “descongelar–mudar–congelar” de Kurt Lewin para a gestão de mudanças é a mais antiga das teorias relevantes nesse campo. Esse modelo simples de três estágios é uma ferramenta para gerenciar a revisão de processos e as mudanças resultantes na dinâmica de grupo. O Estágio 1 envolve persuadir o grupo de que a mudança é necessária. Uma vez que o grupo esteja receptivo à ideia de mudança, o Estágio 2 executa essa mudança. Finalmente, quando a mudança está amplamente concluída, o Estágio 3 institucionaliza os novos padrões de comportamento e pensamento. O princípio central do modelo postula o grupo como o principal instrumento dinâmico, argumentando que as interações individuais e em grupo devem ser examinadas como um sistema quando o grupo está planejando, executando e concluindo qualquer período de mudança. Assim, o trabalho de Lewin é mais útil para planejar mudanças organizacionais em nível macro.
Modelo 7-S da McKinsey
Os sete S’s da McKinsey representam estrutura, estratégia, sistemas, habilidades, estilo, equipe e valores compartilhados. Semelhante ao trabalho de Lewin, esse framework também é um conjunto de ferramentas para mudanças organizacionais planejadas. Embora o framework de Lewin seja genérico, o 7-S tem o objetivo explícito de melhorar a eficácia organizacional. A aplicação de ambas as teorias começa com uma análise do propósito e dos processos atuais. No entanto, o 7-S também cobre explicitamente tanto elementos de negócios (estrutura, estratégia, sistemas) quanto elementos de gestão de pessoas (valores compartilhados, habilidades, estilo, equipe). Este modelo pode ser útil para uma equipe que está considerando a mudança de um foco tradicional em administração de sistemas para a abordagem mais holística da Engenharia de Confiabilidade de Sites (SRE).
O processo de Oito Passos de Kotter para liderar a mudança
A revista Time nomeou o livro de John P. Kotter, Leading Change (Harvard Business School Press, 1996), como um dos 25 livros de gestão empresarial mais influentes de todos os tempos. A Figura 21-1 mostra os oito passos no processo de gestão de mudanças de Kotter.
Figura 21-1. Modelo de gestão de mudanças de Kotter (fonte: https://www.kotterinc.com/8-steps-process-for-leading-change/)
O processo de Kotter é particularmente relevante para equipes e organizações de SRE, com uma pequena exceção: em muitos casos (por exemplo, o próximo estudo de caso sobre o Waze), não há necessidade de criar um senso de urgência. As equipes de SRE que dão suporte a produtos e sistemas com crescimento acelerado frequentemente enfrentam desafios urgentes de escalabilidade, confiabilidade e operações. Os sistemas componentes são frequentemente de propriedade de várias equipes de desenvolvimento, que podem abranger várias unidades organizacionais; questões de escalabilidade também podem exigir coordenação com equipes que vão desde infraestrutura física até gestão de produtos. Como o SRE está frequentemente na linha de frente quando problemas ocorrem, ele está singularmente motivado a liderar as mudanças necessárias para garantir que os produtos estejam disponíveis 24/7/365. Grande parte do trabalho do SRE (implicitamente) adota o processo de Kotter para garantir a continuidade da disponibilidade dos produtos que suporta.
O modelo Prosci ADKAR
O modelo Prosci ADKAR foca no equilíbrio entre os aspectos de negócios e de pessoas na gestão de mudanças. ADKAR é um acrônimo para os objetivos que os indivíduos devem alcançar para uma mudança organizacional bem-sucedida: conscientização, desejo, conhecimento, habilidade e reforço.
Em princípio, o ADKAR oferece uma estrutura útil, reflexiva e centrada nas pessoas. No entanto, sua aplicabilidade ao SRE é limitada, pois as responsabilidades operacionais frequentemente impõem consideráveis restrições de tempo. Proceder iterativamente pelos estágios do ADKAR e fornecer o treinamento ou coaching necessários requer ritmo e investimento em comunicação, o que é difícil de implementar no contexto de equipes globalmente distribuídas e focadas em operações. Dito isso, o Google utilizou com sucesso processos no estilo ADKAR para introduzir e construir apoio para mudanças de alto nível—por exemplo, introduzindo mudanças organizacionais globais para a equipe de gestão de SRE enquanto preserva a autonomia local para detalhes de implementação.
Modelos baseados em emoção
O Modelo de Transição de Bridges descreve as reações emocionais das pessoas em relação à mudança. Embora seja uma ferramenta de gestão útil para gestores de pessoas, não é um framework ou processo para a gestão de mudanças. Da mesma forma, a Curva de Mudança de Kübler-Ross descreve as emoções que as pessoas podem sentir quando enfrentam mudanças. Desenvolvido a partir da pesquisa de Elisabeth Kübler-Ross sobre morte e morrer, foi aplicado para entender e antecipar as reações dos funcionários às mudanças organizacionais. Ambos os modelos podem ser úteis para manter a alta produtividade dos funcionários durante períodos de mudança, já que pessoas infelizes raramente são produtivas.
O Ciclo de Deming
Também conhecido como Ciclo Plan-Do-Check-Act (ou PDCA), este processo do estatístico Edward W. Deming é comumente usado em ambientes DevOps para melhorias de processos—por exemplo, adoção de técnicas de integração contínua/entrega contínua. Não é adequado para a gestão de mudanças organizacionais porque não abrange o lado humano da mudança, incluindo motivações e estilos de liderança. O foco de Deming é pegar processos existentes (mecânicos, automatizados ou de fluxo de trabalho) e aplicar melhorias contínuas de forma cíclica. Os estudos de caso referidos neste capítulo lidam com mudanças organizacionais maiores, onde a iteração pode ser contraproducente: mudanças frequentes e drásticas na estrutura organizacional podem minar a confiança dos funcionários e impactar negativamente a cultura da empresa.
Como essas teorias se aplicam ao SRE
Nenhum modelo de gestão de mudanças é universalmente aplicável a todas as situações, então não é surpreendente que o Google SRE não tenha padronizado exclusivamente um único modelo. Dito isso, aqui está como gostamos de pensar na aplicação desses modelos a cenários comuns de gestão de mudanças em SRE:
- O Processo de Oito Passos de Kotter é um modelo de gestão de mudanças para equipes de SRE que necessariamente abraçam a mudança como uma responsabilidade central.
- O modelo Prosci ADKAR é uma estrutura que a gestão de SRE pode considerar para coordenar mudanças entre equipes globalmente distribuídas.
- Todos os gestores individuais de SRE se beneficiarão do conhecimento tanto do Modelo de Transição de Bridges quanto da Curva de Mudança de Kübler-Ross, que fornecem ferramentas para apoiar os funcionários em tempos de mudança organizacional.
Agora que introduzimos as teorias, vamos examinar dois estudos de caso que mostram como a gestão de mudanças se manifestou no Google.
Estudo de caso 1: escalando o Waze — de mudanças Ad Hoc para mudanças planejadas
Contexto
O Waze é um aplicativo de navegação baseado em comunidade adquirido pelo Google em 2013. Após a aquisição, o Waze entrou em um período de crescimento significativo em usuários ativos, equipe de engenharia e infraestrutura de computação, mas continuou a operar relativamente de forma autônoma dentro do Google. Esse crescimento trouxe muitos desafios, tanto técnicos quanto organizacionais.
A autonomia do Waze e o ethos de startup levaram a equipe a enfrentar esses desafios com uma resposta técnica de base, proveniente de pequenos grupos de engenheiros, em vez de mudanças organizacionais estruturadas e lideradas pela gestão, como implicado pelos modelos formais discutidos na seção anterior. No entanto, sua abordagem para disseminar mudanças por toda a organização e infraestrutura se assemelha significativamente ao modelo de gestão de mudanças de Kotter. Este estudo de caso examina como o processo de Kotter (que aplicamos retroativamente) descreve de forma adequada uma sequência de desafios técnicos e organizacionais que o Waze enfrentou à medida que cresceu após a aquisição.
A fila de mensagens: substituindo um sistema enquanto mantém a confiabilidade
O modelo de Kotter inicia o ciclo de mudança com um senso de urgência. A equipe de SRE do Waze precisou agir de forma rápida e decisiva quando a confiabilidade do sistema de fila de mensagens do Waze sofreu uma regressão significativa, levando a interrupções cada vez mais frequentes e severas. Como mostrado na Figura 21-2, o sistema de filas de mensagens era crítico para as operações, pois todos os componentes do Waze (tempo real, geocodificação, roteamento, etc.) o utilizavam para se comunicar com outros componentes internamente.
Figura 21-2. Caminhos de comunicação entre os componentes do Waze
À medida que o throughput na fila de mensagens cresceu significativamente, o sistema simplesmente não conseguiu lidar com as demandas cada vez maiores. Os SREs precisavam intervir manualmente para preservar a estabilidade do sistema em intervalos cada vez mais curtos. No pior momento, toda a equipe de SRE do Waze passou a maior parte de um período de duas semanas combatendo incêndios 24/7, eventualmente recorrendo ao reinício de alguns componentes da fila de mensagens a cada hora para manter o fluxo de mensagens e a satisfação de dezenas de milhões de usuários.
Como os SREs também eram responsáveis por construir e liberar todo o software do Waze, essa carga operacional teve um impacto notável na velocidade de implementação de novas funcionalidades—quando os SREs passavam todo o seu tempo apagando incêndios, mal tinham tempo para apoiar o lançamento de novas funcionalidades. Ao destacar a gravidade da situação, os engenheiros convenceram a liderança do Waze a reavaliar as prioridades e dedicar algum tempo de engenharia ao trabalho de confiabilidade. Uma coalizão orientadora composta por dois SREs e um engenheiro sênior se reuniu para formar uma visão estratégica de um futuro onde o trabalho dos SREs não fosse mais necessário para manter o fluxo de mensagens. Essa pequena equipe avaliou produtos de fila de mensagens prontos para uso, mas decidiu rapidamente que só poderiam atender aos requisitos de escalabilidade e confiabilidade do Waze com uma solução personalizada.
Desenvolver essa fila de mensagens internamente seria impossível sem uma forma de manter as operações enquanto isso. A coalizão removeu essa barreira à ação ao recrutar um exército de voluntários entre os desenvolvedores das equipes que usavam a fila de mensagens atual. Cada equipe revisou o código-fonte de seu serviço para identificar maneiras de reduzir o volume de mensagens que publicavam. A redução de mensagens desnecessárias e a implementação de uma camada de compressão sobre a fila antiga diminuíram um pouco a carga no sistema. A equipe também ganhou mais margem operacional construindo uma fila de mensagens dedicada para um componente específico que era responsável por mais de 30% do tráfego do sistema. Essas medidas proporcionaram um alívio operacional temporário suficiente para permitir uma janela de dois meses para montar e testar um protótipo do novo sistema de mensagens.
Migrar um sistema de fila de mensagens que lida com dezenas de milhares de mensagens por segundo é uma tarefa assustadora, mesmo sem a pressão de uma falha iminente no serviço. Mas, reduzir gradualmente a carga no sistema antigo aliviaria parte dessa pressão, proporcionando à equipe uma janela de tempo mais longa para concluir a migração. Com esse objetivo, a equipe de SRE do Waze reconstruíu as bibliotecas de cliente para a fila de mensagens de modo que pudessem publicar e receber mensagens usando um ou ambos os sistemas, utilizando uma superfície de controle centralizada para alternar o tráfego.
Uma vez que o novo sistema foi comprovado como funcional, o SRE iniciou a primeira fase da migração: identificou alguns fluxos de mensagens de baixa frequência, mas de alta importância, para os quais interrupções nas mensagens eram catastróficas. Para esses fluxos, escrever em ambos os sistemas de mensagens forneceu um caminho de backup. Alguns quase acidentes, onde o caminho de backup manteve os serviços principais do Waze operando enquanto o sistema antigo falhou, forneceram os ganhos de curto prazo que justificaram o investimento inicial.
A migração em massa para o novo sistema exigiu que o SRE trabalhasse em estreita colaboração com as equipes que o utilizam. A equipe precisava descobrir tanto a melhor forma de apoiar seus casos de uso quanto como coordenar a troca de tráfego. À medida que a equipe de SRE automatizou o processo de migração de tráfego e o novo sistema passou a suportar mais casos de uso por padrão, a taxa de migrações acelerou significativamente.
O processo de gestão de mudanças de Kotter termina com a institucionalização da mudança. Eventualmente, com a adoção do novo sistema ganhando impulso suficiente, a equipe de SRE pôde declarar o sistema antigo como obsoleto e não mais suportado. Eles migraram os últimos usuários restantes alguns trimestres depois. Hoje, o novo sistema lida com mais de 1000 vezes a carga do anterior e requer pouca intervenção manual dos SREs para suporte e manutenção contínuos.
O próximo ciclo de mudança: melhorando o processo de implantação
O processo de mudança como um ciclo foi um dos principais insights de Kotter. A natureza cíclica das mudanças significativas é particularmente evidente quando se trata dos tipos de mudanças técnicas enfrentadas pelo SRE. Eliminar um gargalo em um sistema frequentemente destaca outro. À medida que cada ciclo de mudança é concluído, as melhorias resultantes, padronização e automação liberam tempo de engenharia. As equipes de engenharia agora têm o espaço para examinar seus sistemas mais de perto e identificar mais pontos críticos, desencadeando o próximo ciclo de mudança.
Quando o SRE do Waze finalmente conseguiu dar um passo atrás dos problemas relacionados ao sistema de mensagens, um novo gargalo surgiu, trazendo com ele um novo senso de urgência: a propriedade exclusiva das liberações pelo SRE estava notoriamente e seriamente prejudicando a velocidade de desenvolvimento. A natureza manual das liberações exigia uma quantidade significativa de tempo dos SREs. Para agravar uma situação já subótima, os componentes do sistema eram grandes e, como as liberações eram caras, eram relativamente infrequentes. Como resultado, cada liberação representava uma grande mudança, aumentando significativamente a possibilidade de que um defeito grave necessitasse de um rollback.
Melhorias no processo de liberação ocorreram de forma incremental, já que o SRE do Waze não tinha um plano mestre desde o início. Para reduzir o tamanho dos componentes do sistema para que a equipe pudesse iterar cada um deles mais rapidamente, um dos desenvolvedores seniores do Waze criou uma estrutura para construção de microsserviços. Isso forneceu uma plataforma padrão com “baterias incluídas” que facilitou para a organização de engenharia começar a dividir seus componentes. O SRE trabalhou com esse desenvolvedor para incluir algumas funcionalidades focadas em confiabilidade—por exemplo, uma superfície de controle comum e um conjunto de comportamentos que eram passíveis de automação. Como resultado, o SRE pôde desenvolver um conjunto de ferramentas para gerenciar as partes anteriormente caras do processo de liberação. Uma dessas ferramentas incentivou a adoção ao agrupar todos os passos necessários para criar um novo microsserviço com a estrutura.
Essas ferramentas eram inicialmente improvisadas—os protótipos iniciais foram construídos por um SRE ao longo de vários dias. À medida que a equipe desmembrava mais microsserviços de seus componentes originais, o valor das ferramentas desenvolvidas pelo SRE rapidamente se tornou evidente para a organização mais ampla. O SRE estava gastando menos tempo orientando os componentes reduzidos para a produção, e os novos microsserviços eram muito menos custosos de liberar individualmente.
Embora o processo de liberação já estivesse muito melhorado, a proliferação de novos microsserviços significava que a carga geral sobre o SRE ainda era preocupante. A liderança de engenharia não estava disposta a assumir a responsabilidade pelo processo de liberação até que as liberações fossem menos onerosas.
Em resposta, uma pequena coalizão de SREs e desenvolvedores esboçou uma visão estratégica para mudar para uma estratégia de implantação contínua usando o Spinnaker, uma plataforma de entrega contínua de código aberto e multi-nuvem para construção e execução de fluxos de trabalho de implantação. Com o tempo economizado pelas ferramentas de inicialização, a equipe agora era capaz de projetar esse novo sistema para permitir construções e implantações com um clique de centenas ou milhares de microsserviços. O novo sistema era tecnicamente superior ao anterior em todos os aspectos, mas o SRE ainda não conseguia convencer as equipes de desenvolvimento a fazer a mudança. Essa relutância era impulsionada por dois fatores: o desincentivo óbvio de ter que empurrar suas próprias liberações para a produção, além da aversão à mudança gerada pela baixa visibilidade no processo de liberação.
O SRE do Waze derrubou essas barreiras à adoção mostrando como o novo processo agregava valor. A equipe construiu um painel centralizado que exibia o status das liberações de binários e várias métricas padrão exportadas pela estrutura de microsserviços. As equipes de desenvolvimento podiam facilmente vincular suas liberações a mudanças nessas métricas, o que lhes dava confiança de que as implantações foram bem-sucedidas. O SRE trabalhou de perto com algumas equipes de desenvolvimento orientadas a sistemas para mover serviços para o Spinnaker. Esses sucessos provaram que o novo sistema não só atendia aos requisitos, mas também agregava valor além do processo de liberação original. Nesse ponto, a liderança de engenharia estabeleceu uma meta para que todas as equipes realizassem liberações usando os novos pipelines de implantação do Spinnaker.
Para facilitar a migração, o SRE do Waze ofereceu sessões de treinamento sobre o Spinnaker em toda a organização e sessões de consultoria para equipes com requisitos complexos. Quando os primeiros adotantes se familiarizaram com o novo sistema, suas experiências positivas provocaram uma reação em cadeia de adoção acelerada. Eles descobriram que o novo processo era mais rápido e menos doloroso do que esperar que o SRE realizasse suas liberações. Agora, os engenheiros começaram a pressionar as dependências que não haviam sido movidas, já que eram elas o impedimento para uma maior velocidade de desenvolvimento — não a equipe de SRE!
Hoje, mais de 95% dos serviços do Waze utilizam o Spinnaker para implantação contínua, e as mudanças podem ser enviadas para a produção com muito pouco envolvimento humano. Embora o Spinnaker não seja uma solução única para todos, configurar um pipeline de liberação é trivial se um novo serviço for construído usando a estrutura de microsserviços, então novos serviços têm um forte incentivo para padronizar essa solução.
Lições aprendidas
A experiência do Waze em remover gargalos para mudanças técnicas contém uma série de lições úteis para outras equipes que tentam mudanças técnicas ou organizacionais lideradas pela engenharia. Para começar, a teoria de gerenciamento de mudanças não é uma perda de tempo! Ver esse processo de desenvolvimento e migração através da lente do processo de Kotter demonstra a aplicabilidade do modelo. Uma aplicação mais formal do modelo de Kotter na época poderia ter ajudado a agilizar e orientar o processo de mudança.
Mudanças originadas na base requerem uma colaboração próxima entre SRE e desenvolvimento, bem como o suporte da liderança executiva. Criar um grupo pequeno e focado com membros de todas as partes da organização — SRE, desenvolvedores e gestão — foi fundamental para o sucesso da equipe. Uma colaboração semelhante foi vital para instituir a mudança. Com o tempo, esses grupos ad hoc podem e devem evoluir para uma cooperação mais formal e estruturada, onde os SREs estejam automaticamente envolvidos em discussões de design e possam aconselhar sobre as melhores práticas para construir e implantar aplicações robustas em um ambiente de produção ao longo de todo o ciclo de vida do produto.
Mudanças incrementais são muito mais fáceis de gerenciar. Pular diretamente para a “solução perfeita” é um passo muito grande para dar de uma vez só (sem mencionar que provavelmente é inviável se seu sistema está prestes a colapsar), e o conceito de “perfeito” provavelmente evoluirá à medida que novas informações surgirem durante o processo de mudança. Uma abordagem iterativa pode demonstrar ganhos iniciais que ajudam uma organização a aderir à visão de mudança e justificar investimentos adicionais. Por outro lado, se as primeiras iterações não demonstrarem valor, você gastará menos tempo e recursos ao abandonar a mudança inevitavelmente. Como as mudanças incrementais não acontecem de uma vez só, ter um plano mestre é inestimável. Descreva os objetivos em termos amplos, seja flexível e garanta que cada iteração se mova na direção deles.
Finalmente, às vezes suas soluções atuais não conseguem suportar os requisitos da sua visão estratégica. Construir algo novo tem um grande custo de engenharia, mas pode valer a pena se o projeto o tirar de um máximo local e permitir o crescimento a longo prazo. Como um experimento mental, imagine onde podem surgir gargalos em seus sistemas e ferramentas à medida que seu negócio e organização crescem nos próximos anos. Se você suspeitar que algum elemento não escala horizontalmente ou tem crescimento superlinear (ou pior, exponencial) com relação a uma métrica de negócios central, como usuários ativos diários, pode ser necessário considerar redesenhar ou substituir esses elementos.
O desenvolvimento do novo sistema de fila de mensagens interno do Waze mostra que é possível para pequenos grupos de engenheiros determinados instituírem mudanças que movem a agulha em direção a uma maior confiabilidade do serviço. Mapeando o modelo de Kotter para a mudança, mostra-se que alguma consideração da estratégia de gerenciamento de mudanças pode ajudar a fornecer uma fórmula para o sucesso, mesmo em pequenas organizações lideradas pela engenharia. E, como o próximo estudo de caso também demonstra, quando as mudanças promovem a padronização de tecnologias e processos, a organização como um todo pode colher ganhos consideráveis de eficiência.
Estudo de caso 2: adoção de ferramentas comuns em SRE
Contexto
Os SREs têm opiniões bem definidas sobre o software que podem e devem usar para gerenciar a produção. Anos de experiência, observando o que funciona bem e o que não funciona, e examinando o passado através da lente dos pós-mortems, deram aos SREs um profundo conhecimento aliado a fortes instintos. Especificar, construir e implementar software para automatizar o trabalho deste ano é um valor central em SRE. Em particular, o Google SRE recentemente concentrou nossos esforços em software horizontal. A adoção da mesma solução por uma massa crítica de usuários e desenvolvedores cria um ciclo virtuoso e reduz a reinvenção da roda. Equipes que, de outra forma, poderiam não interagir, compartilham práticas e políticas que são automatizadas usando o mesmo software.
Este estudo de caso é baseado em uma evolução organizacional, e não em uma resposta a problemas de escalabilidade ou confiabilidade de sistemas (como discutido no estudo de caso do Waze). Portanto, o modelo Prosci ADKAR (mostrado na Figura 21-3) é mais adequado do que o modelo de Kotter, pois reconhece tanto as características explícitas de gerenciamento organizacional/pessoas quanto as considerações técnicas durante a mudança.
Figura 21-3. Modelo Prosci ADKAR de gerenciamento de mudanças
Declaração do problema
Há alguns anos, o Google SRE se viu utilizando várias soluções de software independentes para aproximadamente o mesmo problema em múltiplos espaços problemáticos: monitoramento, lançamentos e implementações, resposta a incidentes, gerenciamento de capacidade, e assim por diante.
Esse estado final surgiu em parte porque as pessoas que construíam ferramentas para SRE estavam dissociadas de seus usuários e de seus requisitos. Os desenvolvedores de ferramentas nem sempre tinham uma visão atualizada da declaração do problema ou do panorama geral da produção—o ambiente de produção muda muito rapidamente e de novas maneiras à medida que novos softwares, hardwares e casos de uso surgem quase diariamente. Além disso, os consumidores das ferramentas eram variados, às vezes com necessidades ortogonais (“essa implementação precisa ser rápida; uma aproximação é aceitável” versus “essa implementação precisa ser 100% correta; pode ser feita lentamente”).
Como resultado, nenhum desses projetos de longo prazo atendia completamente às necessidades de ninguém, e cada um era caracterizado por diferentes níveis de esforço de desenvolvimento, completude de recursos e suporte contínuo. Aqueles que esperavam pela grande solução—uma solução futura não específica, completa e ideal—esperavam por muito tempo, ficavam frustrados e usavam suas próprias habilidades de engenharia de software para criar suas próprias soluções específicas. Aqueles com necessidades menores e mais específicas eram relutantes em adotar uma solução mais ampla que não fosse tão adaptada às suas necessidades. Os benefícios técnicos e organizacionais de soluções mais universais eram claros, mas os clientes, serviços e equipes não estavam estruturados ou recompensados por esperar. Para agravar esse cenário, os requisitos das equipes de clientes, tanto grandes quanto pequenas, mudavam ao longo do tempo.
O que decidimos fazer
Para definir este cenário como um problema concreto, nos perguntamos: e se todos os SREs do Google pudessem usar um mecanismo de monitoramento comum e um conjunto de painéis de controle, que fossem fáceis de usar e suportassem uma ampla variedade de casos de uso sem exigir personalização?
Da mesma forma, poderíamos estender esse modelo de pensamento para lançamentos e implantações, resposta a incidentes, gerenciamento de capacidade e além. Se a configuração inicial de um produto abrangesse uma ampla representação de abordagens para atender à maioria das nossas necessidades funcionais, nossas soluções gerais e bem-informadas se tornariam inevitáveis com o tempo. Em algum momento, a massa crítica de engenheiros que interage com a produção superaria qualquer solução que estivessem usando e se auto-selecionaria para migrar para um conjunto comum e bem-suportado de ferramentas e automação, abandonando suas ferramentas personalizadas e os custos associados à manutenção.
O SRE no Google tem a sorte de contar com muitos engenheiros com formações e experiências em engenharia de software. Pareceu um passo natural incentivar engenheiros que eram especialistas e opinativos sobre problemas específicos—de balanceamento de carga a ferramentas de implantação, e resposta e gerenciamento de incidentes—para trabalhar como uma equipe virtual, auto-selecionada por uma visão comum de longo prazo. Esses engenheiros traduziriam sua visão em software funcional e real, que eventualmente seria adotado em todo o SRE e, posteriormente, em todo o Google, como funções básicas de produção.
Voltando ao modelo ADKAR para gestão de mudanças, os passos discutidos até agora—identificar um problema e reconhecer uma oportunidade—são exemplos clássicos da etapa de conscientização iniciada pelo ADKAR. A equipe de liderança do SRE no Google concordou com a necessidade (desejo) e tinha conhecimento e capacidade suficientes para passar para o design de soluções de forma bastante rápida.
Design
Nossa primeira tarefa foi convergir em torno de uma série de tópicos que concordamos serem centrais e que se beneficiariam imensamente de uma visão consistente: entregar soluções e planos de adoção que atendam à maioria dos casos de uso. Começando com uma lista de mais de 65 projetos propostos, passamos vários meses coletando requisitos dos clientes, verificando roteiros e realizando análises de mercado, e, no final, direcionamos nossos esforços para um punhado de tópicos validados.
Nosso design inicial criou uma equipe virtual de especialistas em SRE em torno desses tópicos. Essa equipe virtual contribuiria com uma porcentagem significativa de seu tempo, cerca de 80%, para esses projetos horizontais. A ideia por trás do tempo de 80% e da equipe virtual era garantir que não projetássemos ou construíssemos soluções sem contato constante com a produção. No entanto, descobrimos (talvez previsivelmente) alguns pontos problemáticos com essa abordagem:
- Coordenar uma equipe virtual — cujo foco era interrompido pelo plantão regular, em múltiplos fusos horários — era muito difícil. Havia muito estado a ser trocado entre executar um serviço e construir um software sério.
- Tudo, desde reunir consenso até revisões de código, foi afetado pela falta de um local central e de um horário comum.
- O número de pessoas para projetos horizontais inicialmente teve que vir de equipes existentes, que agora tinham menos recursos de engenharia para lidar com seus próprios projetos. Mesmo no Google, há uma tensão entre delegar pessoal para suportar o sistema como está e delegar pessoal para construir infraestrutura voltada para o futuro.
Com dados suficientes em mãos, percebemos que precisávamos redesenhar nossa abordagem e optamos por um modelo mais centralizado e familiar. O mais significativo foi a remoção da exigência de que os membros da equipe dividissem seu tempo 80/20 entre trabalho de projeto e plantão. A maior parte do desenvolvimento de software SRE é agora feita por pequenos grupos de engenheiros seniores com bastante experiência em plantão, mas que estão totalmente focados em construir software com base nessas experiências. Também centralizamos fisicamente muitas dessas equipes, recrutando ou transferindo engenheiros. O desenvolvimento em pequenos grupos (6–10 pessoas) é simplesmente mais eficiente em uma única sala (embora esse argumento não se aplique a todos os grupos—for example, equipes SRE remotas). Ainda conseguimos atender ao nosso objetivo de coletar requisitos e perspectivas de toda a organização de engenharia do Google por meio de videoconferências, e-mail e o bom e velho deslocamento.
Portanto, nossa evolução do design acabou realmente em um lugar familiar—equipes pequenas, ágeis, majoritariamente locais e de rápida movimentação—mas com a ênfase adicional em selecionar e construir automação e ferramentas para adoção por 60% dos engenheiros do Google (número que decidimos ser uma interpretação razoável do objetivo de “quase todos no Google”). O sucesso significa que a maior parte do Google está usando o que o SRE construiu para gerenciar seu ambiente de produção.
O modelo ADKAR mapeia a fase de implementação do projeto de mudança entre os estágios centrados nas pessoas de conhecimento e habilidade. Este estudo de caso confirma esse mapeamento. Tínhamos muitos engenheiros engajados, talentosos e conhecedores, mas estávamos pedindo a pessoas que haviam se concentrado em questões de SRE que agissem como engenheiros de desenvolvimento de software, focando em requisitos dos clientes, roteiros de produto e compromissos de entrega. Precisávamos revisitar a implementação dessa mudança para permitir que os engenheiros demonstrassem suas habilidades em relação a esses novos atributos.
Implementação: monitoramento
Para retornar ao espaço de monitoramento mencionado na seção anterior, o Capítulo 31 do primeiro livro de SRE descreveu como o Viceroy — o esforço do Google SRE para criar uma solução única de dashboard de monitoramento adequada para todos — abordou o problema das soluções personalizadas divergentes. Várias equipes de SRE trabalharam juntas para criar e executar a iteração inicial, e à medida que o Viceroy cresceu para se tornar a solução de monitoramento e painel de controle padrão no Google, uma equipe de desenvolvimento de SRE centralizada assumiu a propriedade do projeto.
Mas mesmo quando o framework Viceroy uniu o SRE sob uma estrutura comum, houve muito esforço duplicado à medida que as equipes criavam painéis personalizados complexos específicos para seus serviços. Embora o Viceroy fornecesse um método padrão hospedado para projetar e construir exibições visuais de dados, ainda exigia que cada equipe decidisse quais dados exibir e como organizá-los.
A equipe de desenvolvimento de software agora centralizada iniciou um segundo esforço paralelo para fornecer painéis comuns, construindo um sistema opinativo de zero configuração sobre o sistema “customizado” de nível inferior. Esse sistema de zero configuração forneceu um conjunto padrão de exibições de monitoramento abrangentes com base na suposição de que um determinado serviço estava organizado em um dos estilos populares. Com o tempo, a maioria dos serviços migrou para usar esses painéis padrão em vez de investir em layouts personalizados. Serviços muito grandes, únicos ou de alguma forma especiais ainda podem implantar visualizações personalizadas no sistema hospedado, se necessário.
Retornando ao modelo ADKAR, a consolidação das ferramentas de monitoramento no Google começou como um esforço de base, e as melhorias resultantes na eficiência operacional forneceram uma base quantificável (consciência e desejo) para iniciar um esforço mais amplo: o SRE autofinanciou uma equipe de desenvolvimento de software para construir ferramentas de gerenciamento de produção para todo o Google.
Lições aprendidas
Projetar a migração de peças interdependentes é frequentemente mais complicado do que um design do zero. Na prática, o trabalho de engenharia mais difícil acaba sendo a evolução de muitos sistemas pequenos/restritos em poucos sistemas mais gerais—sem perturbar serviços já em funcionamento dos quais muitos clientes dependem. Enquanto isso, ao lado dos sistemas existentes, novos sistemas pequenos são adicionados—alguns dos quais eventualmente surpreendem ao crescerem para se tornar grandes sistemas. Há uma atração intelectual em começar de novo com um grande design, apenas enfrentando as restrições realmente necessárias, mas a migração de sistemas e equipes acaba sendo o trabalho mais difícil de todos.
Desenhar software horizontal requer muito ouvir os usuários finais em potencial e, em muitos aspectos, as tarefas de construção e adoção se assemelham ao papel de um gerente de produto. Para que esse esforço alcance sucesso, tivemos que garantir que absorvíamos e priorizávamos as prioridades. Atender às necessidades dos clientes—tanto dos SREs quanto dos outros usuários de produção—também foi um elemento crítico para o sucesso. É importante reconhecer que a mudança para ferramentas comuns ainda é um trabalho em andamento. Iteramos na estrutura e no recrutamento das equipes que construíam nossas tecnologias compartilhadas para melhor atender às necessidades dos clientes, e adicionamos talentos em gerenciamento de produto e experiência do usuário (abordando conhecimentos ausentes).
Nos últimos um ou dois anos, vimos a adoção desses produtos projetados e construídos por SREs em uma ampla gama de equipes no Google. Aprendemos que, para alcançar o sucesso, o custo da migração (de soluções antigas, fragmentadas, mas especializadas) precisa ser pequeno em relação aos benefícios líquidos da nova solução comum. Caso contrário, a própria migração se torna uma barreira à adoção. Continuamos a trabalhar com as equipes individuais que constroem esses produtos para reforçar os comportamentos necessários para agradar os clientes com as soluções comuns que as equipes estão entregando.
Um tema comum que descobrimos em projetos de desenvolvimento de software horizontal foi que, não importa quão bons fossem os novos softwares e produtos, o custo da migração — de algo que já estava funcionando para algo novo — sempre era percebido como muito alto. Apesar da atração de uma gestão mais fácil e de menos conhecimento específico profundo, os custos de migrar para longe do familiar (com todas as suas imperfeições e trabalho árduo) geralmente eram uma barreira. Além disso, engenheiros individuais muitas vezes tinham um monólogo interno semelhante: “Não estou melhorando ou mudando o sistema; estou trocando uma peça funcionando por outra peça funcionando.” O ADKAR descreve essa resistência como a “lacuna de conhecimento para habilidade”. No lado humano, para reconhecer e abraçar a mudança, as pessoas precisam de tempo, orientação e treinamento em novas ferramentas e habilidades. No lado técnico, implementar a mudança requer entender os custos de adoção e incluir o trabalho para minimizar esses custos como parte do processo de lançamento.
Como resultado, os custos de migração precisam ser quase zero (“basta recompilar e você adota a nova solução”) e os benefícios precisam ser claros (“agora você está protegido contra a vulnerabilidade $foo”) para a equipe, para os indivíduos e para a empresa.
Anteriormente, o SRE costumava construir produtos com um compromisso de “melhor esforço”, o que significava que o tempo dedicado ao produto se encaixava nas lacunas entre tudo o que estávamos fazendo (gerenciamento de serviços principais, planejamento de capacidade, lidar com interrupções, etc.). Como resultado, nossa execução não era muito confiável; era impossível prever quando um recurso ou serviço estaria disponível. Por extensão, os consumidores de nossos produtos tinham menos confiança no resultado final, já que parecia perpetuamente atrasado e era gerido por uma equipe rotativa de gerentes de produto e engenheiros individuais. Quando engenheiros individuais ou equipes de SRE construíam ferramentas para seu próprio uso, o foco estava na resolução de problemas individuais para reduzir o custo de manutenção dos SLOs dos sistemas suportados. Ao se empenhar em construir ferramentas comuns para a maioria dos casos de uso no Google, precisávamos mudar o foco para medir o sucesso desse esforço em termos de adoção do produto.
Devido à nossa cultura organizacional e à nossa abundância de recursos, abordamos este projeto de uma forma de baixo para cima, em vez de cima para baixo. Em vez de obrigar os usuários a migrarem para nosso novo sistema de monitoramento, procuramos conquistar os usuários demonstrando que nossa nova oferta era melhor do que as soluções existentes.
Com o tempo, aprendemos que a forma como conduzíamos nosso processo de desenvolvimento influenciava a percepção dos potenciais usuários internos sobre o resultado final. Esses projetos ganharam real tração apenas quando foram liderados por engenheiros experientes em produção, dedicados 100% à construção de software, com cronogramas e suporte idênticos ao restante do desenvolvimento de software do Google. Construir software comum de forma transparente, como um relógio, com grande comunicação (“Teremos X pronto até a data Y”), melhorou significativamente a velocidade de migração para o novo sistema. As pessoas já confiavam no novo sistema porque podiam observar como ele estava sendo desenvolvido desde o início. Percepções sobre como o software é feito acabaram sendo mais importantes do que esperávamos desde o início. Nosso pensamento inicial de que “se você construir algo ótimo, as pessoas naturalmente irão para isso” não se comprovou. Em vez disso, esses projetos precisavam ser claramente definidos, bem divulgados com antecedência, avaliados contra uma variedade de casos de uso (começando pelos adotantes mais exigentes), muito melhores do que as opções existentes e adotáveis com pouco ou nenhum esforço.
Quanto mais consumidores você tiver para ferramentas comuns e adoção, mais tempo você terá que gastar fazendo coisas além de escrever código. Isso pode parecer óbvio em retrospectiva, mas ter metas claras, datas críveis, atualizações regulares e contato constante com os consumidores é fundamental. Muitas vezes, consumidores céticos perguntarão: “Se meu script de shell único está funcionando bem, eu realmente preciso disso?” A adoção de software ou processos comuns é análoga à confiabilidade como uma característica—você pode construir a melhor ferramenta do mundo, mas se as pessoas não a adotarem (ou não puderem usá-la se não for confiável), não será útil para ninguém. Ter um plano para adoção—desde campeões até testadores beta, patrocinadores executivos e engenheiros dedicados que compreendam a importância de minimizar barreiras à adoção—é tanto o objetivo final quanto o ponto de partida quando se trata de construir e adotar ferramentas e práticas comuns.
Isso porque a adoção impulsiona um efeito de rede: à medida que a escala e o alcance das ferramentas de software comuns aumentam, as melhorias incrementais nessas ferramentas se tornam mais valiosas para a organização. À medida que o valor das ferramentas aumenta, o esforço de desenvolvimento dedicado a elas também tende a aumentar. Parte desse esforço de desenvolvimento naturalmente se dirige à redução adicional dos custos de migração, incentivando uma maior adoção. A adoção ampla encoraja a construção de melhorias organizacionais em uma maneira consistente e semelhante a produtos, e justifica a formação de equipes completas para apoiar as ferramentas a longo prazo. Essas ferramentas devem ser caracterizadas por desenvolvimento rápido, estabilidade de recursos, superfícies de controle comuns e APIs automatizáveis.
Quando se trata de medir o impacto de tais esforços, podemos fazer perguntas semelhantes às seguintes:
- Com que rapidez um novo desenvolvedor de produtos pode construir e gerenciar um serviço de escala mundial?
- Capacitado por ferramentas e práticas comuns, com que facilidade um SRE em um domínio pode se transferir para outro domínio?
- Quantos serviços podem ser gerenciados com os mesmos princípios, como experiências do usuário de ponta a ponta, em vez de serviços separados?
Todas essas são maneiras possíveis e altamente valiosas de medir o impacto, mas nossa primeira medição deve ser a adoção.
Conclusão
Como demonstrado pelos estudos de caso da Waze e do software horizontal, mesmo dentro de uma única empresa, a gestão de mudanças em SRE pode precisar abordar uma variedade de espaços de problema e contextos organizacionais. Como resultado, é provável que não haja um único modelo formal de gestão de mudanças que se aplique perfeitamente ao espectro de mudanças que qualquer organização possa enfrentar. No entanto, esses frameworks, particularmente o processo de oito etapas de Kotter e o modelo Prosci ADKAR, podem fornecer insights úteis para abordar mudanças. Uma característica comum em qualquer mudança necessária em um ambiente tão dinâmico quanto o SRE é a constante reavaliação e iteração. Embora muitas mudanças possam começar organicamente de forma de base, a maioria pode se beneficiar de coordenação e planejamento estruturados à medida que as mudanças amadurecem.