Um exemplo de colaboração bem-sucedida entre SREs é um projeto chamado Viceroy, que é uma estrutura e serviço de painel de monitoramento. A atual arquitetura organizacional do SRE pode acabar com equipes que produzem múltiplas cópias ligeiramente diferentes do mesmo trabalho; por várias razões, as estruturas de painéis de monitoramento foram um terreno particularmente fértil para a duplicação de trabalho.

Os incentivos que levaram ao sério problema de lixo de muitas estruturas de monitoramento abandonadas e latentes eram bem simples: cada equipe era recompensada por desenvolver a sua própria solução, trabalhar fora dos limites da equipe era difícil, e a infraestrutura que tendia a ser fornecida a nível do SRE era tipicamente mais próxima de um conjunto de ferramentas do que de um produto. Este ambiente encorajou os engenheiros individuais a utilizarem o kit de ferramentas para fazer outro acidente em vez de reparar o problema para o maior número de pessoas possível (um esforço que, portanto, levaria muito mais tempo). 

A vinda do Viceroy

O viceroy era diferente. Começou em 2012, quando várias equipes estavam considerando como migrar para o Monarch, o novo sistema de monitoramento do Google. O SRE é profundamente conservador no que diz respeito aos sistemas de monitoramento, pelo que o Monarch demorou, ironicamente, mais tempo a obter tração dentro do SRE do que dentro das equipes não-SRE. Mas ninguém podia argumentar que o nosso sistema de monitoramento antigo, Borgmon (ver Capítulo 10), não tinha margem para melhorias. Por exemplo, os nossos consoles eram complicados porque utilizavam um sistema de templates HTML personalizado, com um sistema especial, cheio de casos funky edge, e difícil de testar. Nessa altura, Monarch tinha amadurecido o suficiente para ser aceito em princípio como substituto do sistema antigo e estava sendo adotado por cada vez mais equipes através do Google, mas ainda tínhamos problemas com os consoles. 

Aqueles de nós que tentaram usar o Monarch para os nossos serviços depressa descobriram que ele ficou aquém do suporte do console por duas razões principais:

• Os consoles eram fáceis de montar para um pequeno serviço, mas não se adaptavam bem a serviços com consoles complexos.

   

• Também não suportaram o sistema legado de monitoramento, tornando a transição para o Monarch muito difícil.

Como não existia nenhuma alternativa viável para implantar o Monarch dessa maneira na época, foram lançados vários projetos específicos de equipes. Como havia pouco em termos de soluções de desenvolvimento coordenadas ou mesmo rastreamento entre grupos na época (um problema que desde então foi resolvido), acabamos por duplicar esforços mais uma vez. Múltiplas equipes de Spanner, Ads Frontend, e uma variedade de outros serviços aceleraram os seus próprios esforços (um exemplo notável foi chamado Consoles++) ao longo de 12-18 meses, e acabou por prevalecer a sanidade quando engenheiros de todas essas equipes acordaram e descobriram os respectivos esforços uns dos outros. Decidiram fazer o mais sensato e unir forças a fim de criar uma solução geral para todos os SRE. Assim, o projeto Viceroy nasceu em meados de 2012.

No início de 2013, o Viceroy tinha começado a despertar o interesse de equipes que ainda não tinham saído do sistema legado, mas que queriam colocar o pé na água. Obviamente, as equipes com maiores projetos de monitoramento existentes tinham menos incentivos para mudar para o novo sistema: era difícil para estas equipes racionalizar o baixo custo de manutenção da sua solução existente que basicamente funcionava bem, para algo relativamente novo e não provado que exigiria muito esforço para fazer funcionar. A enorme diversidade de requisitos aumentou a relutância destas equipes, embora todos os projetos de console de monitoramento partilhassem dois requisitos principais, nomeadamente:

• Suportar painéis de instrumentos complexos com curadoria

   

• Apoiar tanto o Monarch como o sistema legado de monitoramento.

Cada projeto tinha também o seu próprio conjunto de requisitos técnicos, que dependiam da preferência ou experiência do autor. Por exemplo:

• Múltiplas fontes de dados fora dos sistemas centrais de monitoramento

   

• Definição de consoles usando configuração versus layout HTML explícito

   

• Sem Javascript versus adoção total de Javascript com AJAX

   

• Uso exclusivo de conteúdo estático, para que os consoles pudessem ser armazenados em cache no browser

Embora alguns destes requisitos fossem mais rígidos do que outros, de um modo geral, dificultavam os esforços de fusão. De fato, embora a equipe Consoles++ estivesse interessada em ver como o seu projeto se comparava ao Viceroy, o seu exame inicial no primeiro semestre de 2013 determinou que as diferenças fundamentais entre os dois projetos eram suficientemente significativas para impedir a integração. A maior dificuldade foi que o Viceroy por design não utilizava muito JavaScript, enquanto o Consoles++ era escrito principalmente em JavaScript. Havia, contudo, um vislumbre de esperança, na medida em que os dois sistemas tinham uma série de semelhanças subjacentes:

• Utilizaram sintaxes semelhantes para a renderização de modelos HTML.

   

• Partilharam uma série de objetivos a longo prazo, que nenhuma das duas equipes tinha ainda começado a abordar. Por exemplo, ambos os sistemas queriam armazenar em cache os dados de monitoramento e dar suporte a um pipeline offline para produzir periodicamente dados que o console pudesse usar, mas era demasiado caro em termos computacionais para produzir sob demanda.

Acabamos estacionando a discussão do console unificado por um tempo. No entanto, no final de 2013, tanto o Consoles++ como o Viceroy haviam se desenvolvido significativamente. As suas diferenças técnicas tinham diminuído, porque o Viceroy tinha começado a utilizar o JavaScript para apresentar os seus gráficos de monitoramento. As duas equipes reuniram-se e descobriram que a integração era muito mais fácil, agora que a integração se resumia a servir os dados dos Consoles++ a partir do servidor do Viceroy. Os primeiros protótipos integrados foram concluídos no início de 2014, e provaram que os sistemas podiam funcionar bem em conjunto. Ambas as equipes se sentiram à vontade para se empenharem num esforço conjunto nessa altura, e porque o Viceroy já tinha estabelecido a sua marca como uma solução de monitoramento comum, o projeto combinado manteve o nome Viceroy. O desenvolvimento da funcionalidade total levou alguns trimestres, mas no final de 2014, o sistema combinado estava completo.

A união de forças colheu enormes benefícios:

• O Viceroy recebeu uma série de fontes de dados e os clientes JavaScript para acessá-los.

   

• A compilação JavaScript foi reescrita para suportar módulos separados que podem ser incluídos de forma seletiva. Isto é essencial para dimensionar o sistema para qualquer número de equipes com o seu próprio código JavaScript.

   

• Os Consoles++ se beneficiaram das muitas melhorias que estão sendo feitas ativamente ao Viceroy, tais como a adição de sua cache e do seu pipeline de dados em segundo plano.

   

• No geral, a velocidade de desenvolvimento de uma solução foi muito maior do que a soma de toda a velocidade de desenvolvimento dos projetos duplicados.

Em última análise, a visão comum do futuro foi o fator-chave para combinar os projetos. Ambas as equipes encontraram valor na expansão da sua equipe de desenvolvimento e se beneficiaram das contribuições uma da outra. O impulso foi tal que, no final de 2014, o Viceroy foi oficialmente declarado a solução de monitoramento geral para todos os SRE. Talvez caracteristicamente para o Google, esta declaração não exigia que as equipes adotassem o Viceroy: em vez disso, recomendava que as equipes utilizassem o Viceroy, em vez de escreverem outro console de monitoramento.

Os desafios

Embora, em última análise, tenha sido um sucesso, o Viceroy não foi isento de dificuldades, e muitas delas surgiram devido à natureza entre sites do projeto.

Uma vez estabelecida a equipe estendida do Viceroy, a coordenação inicial entre os membros da equipe remota revelou-se difícil. Quando se conhecem pessoas pela primeira vez, as sugestões sutis na escrita e na fala podem ser mal interpretadas, porque os estilos de comunicação variam substancialmente de pessoa para pessoa. No início do projeto, os membros da equipe que não estavam localizados em Mountain View também perderam as discussões improvisadas sobre os refrigeradores de água que frequentemente aconteciam pouco antes e depois das reuniões (embora a comunicação tenha melhorado consideravelmente desde então).

Embora a equipe principal do Viceroy permaneceu bastante consistente, a equipe estendida de colaboradores foi bastante dinâmica. Os colaboradores tiveram outras responsabilidades que mudaram ao longo do tempo, e por isso muitos puderam dedicar entre um e três meses ao projeto. Assim, o grupo de colaboradores do desenvolvedor, que era inerentemente maior do que a equipe principal do Viceroy, caracterizou-se por uma quantidade significativa de rotatividade.

A adição de novas pessoas ao projeto exigiu treinar cada colaborador sobre o design geral e a estrutura do sistema, o que levou algum tempo. Por outro lado, quando um SRE contribuía para a funcionalidade principal do Viceroy e mais tarde regressava à sua própria equipe, era um perito local no sistema. Essa divulgação imprevista dos peritos locais do Viceroy levou a uma maior utilização e adoção.

À medida que as pessoas entravam e saíam da equipe, descobrimos que as contribuições casuais eram úteis e caras. O custo principal era a diluição da propriedade: uma vez que os recursos eram entregues e a pessoa saía, os recursos ficavam sem suporte com o tempo e geralmente eram descartados.

Além disso, o escopo do projeto Viceroy cresceu ao longo do tempo. Tinha objetivos ambiciosos no lançamento, mas o escopo inicial era limitado. No entanto, à medida que o escopo crescia, lutamos para entregar as características principais a tempo, e tivemos de melhorar a gestão do projeto e definir uma direção mais clara para assegurar que o projeto se mantivesse no bom caminho.

Finalmente, a equipe do Viceroy achou difícil possuir completamente um componente que tivesse contribuições significativas (determinantes) de sites distribuídos. Mesmo com a melhor vontade do mundo, as pessoas geralmente não seguem o caminho de menor resistência e discutem questões ou tomam decisões localmente sem envolver os proprietários remotos, o que pode conduzir a conflitos. 

Recomendações

Só se deve desenvolver projetos entre sites quando é necessário, mas muitas vezes há boas razões para o fazer. O custo de trabalhar entre sites é a maior latência para as ações e maior necessidade de comunicação; o benefício é – se obtiver a mecânica correta – um rendimento muito superior. O projeto de um único site também pode ser prejudicado por alguém fora desse site que saiba o que você está fazendo, por isso há custos para ambas as abordagens.

Colaboradores motivados são valiosos, mas nem todas as contribuições são igualmente valiosas. Certifique-se de que os colaboradores do projeto estejam realmente comprometidos e não estejam apenas se unindo a algum objetivo nebuloso de autorrealização (querendo ganhar um entalhe no seu cinto anexando o seu nome a um projeto brilhante; querendo codificar num novo projeto excitante sem se comprometerem a manter esse projeto). Colaboradores com um objetivo específico a atingir estarão geralmente mais motivados e manterão melhor as suas contribuições.

À medida que os projetos se desenvolvem, eles geralmente crescem, e nem sempre se encontra na feliz posição de ter pessoas na sua equipe local para contribuir para o projeto. Portanto, pense cuidadosamente sobre a estrutura do projeto. Os líderes do projeto são importantes: proporcionam uma visão a longo prazo para o projeto e asseguram que todo o trabalho se alinha com essa visão e é corretamente priorizado. Também precisam ter uma forma acordada de tomar decisões, e devem otimizar especificamente para tomarem mais decisões localmente se houver um elevado nível de acordo e confiança.

A estratégia padrão de “dividir e conquistar” aplica-se a projetos entre sites; reduz-se os custos de comunicação principalmente dividindo o projeto no maior número possível de componentes de dimensão razoável, e tentando assegurar que cada componente possa ser atribuído a um pequeno grupo, de preferência dentro de um site. Divida esses componentes entre as subequipes do projeto e estabeleça entregas e prazos claros. (Tente não deixar que a lei de Conway distorça a forma natural do software muito profundamente).

Um objetivo para uma equipe de projeto funciona melhor quando está orientada para fornecer alguma funcionalidade ou resolver algum problema. Esta abordagem assegura que os indivíduos que trabalham num componente saibam o que se espera deles, e que o seu trabalho só será concluído quando esse componente estiver totalmente integrado e utilizado no âmbito do projeto principal.

Obviamente, as melhores práticas habituais de engenharia aplicam-se a projetos de colaboração: cada componente deve ter documentos de design e revisões com a equipe. Desta forma, é dada a todos na equipe a oportunidade de se manterem a par das mudanças, além da oportunidade de influenciar e melhorar os projetos. Anotar as coisas é uma das principais técnicas que você tem para compensar a distância física e/ou lógica – use-a.

As normas são importantes. As diretrizes de estilo de codificação são um bom começo, mas são geralmente bastante táticas e, portanto, apenas um ponto de partida para o estabelecimento de normas da equipe. Sempre que há um debate em torno da escolha a fazer sobre um assunto, discuta-o totalmente com a equipe, mas com um limite de tempo rigoroso. Depois, escolha uma solução, documente-a, e siga em frente. Se não se chegar a acordo, é preciso escolher um árbitro que todos respeitem, e, mais uma vez, apenas avançar. Com o tempo, construirá uma coleção destas melhores práticas, o que ajudará as novas pessoas a se atualizarem.

Em última análise, não há substituto para a interação presencial, embora alguma parte da interação presencial possa ser adiada por uma boa utilização do VC e uma boa comunicação escrita. Se puder, peça aos líderes do projeto para se encontrarem pessoalmente com o resto da equipe. Se o tempo e o orçamento permitirem, organize uma reunião de equipe para que todos os membros da equipe possam interagir pessoalmente. Uma reunião também proporciona uma grande oportunidade para discutir os projetos e objetivos. Para situações em que a neutralidade é importante, é vantajoso realizar reuniões de equipes num local neutro, para que nenhum local individual tenha a “vantagem de casa”.

Finalmente, utilize o estilo de gestão do projeto que se adequa ao projeto no seu estado atual. Mesmo os projetos com objetivos ambiciosos começarão pequenos, então a sobrecarga deve ser correspondentemente baixa. À medida que o projeto cresce, é apropriado adaptar e mudar a forma como o projeto é gerenciado.  Dado o crescimento suficiente, o gerenciamento completo do projeto será necessário.