Ao deixar o LinkedIn
(corecursive.com)- Chris Krycho contou que, ao longo de cerca de 5 anos no LinkedIn, foi responsável pela infraestrutura de frontend e pela experiência de desenvolvimento do app web para desktop, lidando com o conflito entre mudar com segurança uma base de código enorme e a pressão por executar o produto rapidamente
- O app desktop do LinkedIn, que tinha cerca de 2 milhões de linhas de JavaScript quando ele entrou, depois cresceu para um monorepo de cerca de 3,2 milhões de linhas, e migrações eram, na prática, difíceis sem automação e sem minimizar a carga sobre os times de produto
- A modernização do Ember e a adoção de TypeScript tinham como meta reduzir erros e melhorar a qualidade do desenvolvimento, e uma análise mostrando que a migração para TypeScript poderia reduzir em pelo menos 25% os erros registrados nos logs da aplicação foi usada para convencimento interno
- O plano de sair do Ember para React colocou em choque a estratégia gradual de automação de 3 a 5 anos do time de Chris e uma abordagem que queria redesenhar profundamente o modo existente de trabalhar para permitir experimentação de produto mais rápida
- Durante a resposta a uma grande falha, ficaram expostas limitações em alertas, observabilidade, resiliência e code review, e Chris saiu por entender que a direção organizacional de priorizar velocidade acima de tudo não combinava com seus valores
O trabalho de 5 anos e o tamanho da base de código
- Chris Krycho entrou no LinkedIn no fim de janeiro de 2019 e trabalhou lá por cerca de 5 anos
- Sua área não era infraestrutura de servidores, mas sim infraestrutura de frontend e melhorias na experiência de desenvolvimento do app web desktop do LinkedIn
- Liderou grandes projetos de modernização de JavaScript no app desktop, responsável pela experiência do LinkedIn.com em navegadores não móveis
- O app de sua empresa anterior tinha cerca de 150 mil linhas, mas o frontend do LinkedIn tinha cerca de 2 milhões de linhas de código quando ele entrou
- A cada trimestre, entre 150 e 200 engenheiros faziam commits no mesmo app, e dezenas de times continuavam publicando um único produto
- Quando entrou, havia menos de 100 engenheiros remotos entre vários milhares no total, e Chris era um caso incomum trabalhando remotamente do Colorado
Como migrar uma base com 2 milhões de linhas de código
- Um dos primeiros grandes trabalhos foi introduzir a sintaxe moderna de classes do JavaScript em código baseado em Ember
- Havia problemas quando classes antigas do Ember e classes nativas de JavaScript se misturavam na cadeia de herança, algo que internamente era chamado de “Zebra Striping”
- Uma migração desse tamanho precisava ser o mais automatizada possível
- Corrigir manualmente 2 milhões de linhas poderia levar muitos meses
- Era difícil exigir que os times de produto parassem o desenvolvimento de funcionalidades apenas para adotar nova sintaxe
- O LinkedIn tinha um processo de iniciativas horizontais (horizontal initiatives) que cruzava vários times, com o princípio operacional de manter a participação dos times de produto abaixo de 10%
- O time de Chris concluiu que, em vez de pedir aos times de produto que executassem codemods por conta própria, seria mais fácil obter adesão se o time de infraestrutura automatizasse a criação dos PRs e os times de produto ficassem com review e smoke test
- O trabalho relacionado ao Ember levou 18 meses no total; a maior parte aconteceu em 6 meses, mas atrasos de alguns times deixaram uma longa cauda
A lógica de redução de erros usada para defender o TypeScript
- Depois da modernização do Ember, o time de Chris escolheu como próximo alvo o grande volume de erros de JavaScript no frontend
- O LinkedIn usava infraestrutura interna de logging em vez de serviços externos, devido à escala dos logs de erro
- A empresa havia passado de 1 bilhão de membros no ano anterior, e quando Chris saiu o monorepo tinha cerca de 3,2 milhões de linhas
- Metade era código de teste
- Metade era código de produção
- O time de Chris analisou separadamente as categorias de erro que o TypeScript conseguiria capturar
- Alguns erros não poderiam ser detectados pelo TypeScript, mas a avaliação era de que, ao concluir toda a migração, seria possível reduzir em pelo menos 25% o volume de logs da aplicação dentro de um universo de milhões de erros de JavaScript por dia
- Um documento escrito por Chris sobre a migração para TypeScript foi compartilhado repetidamente entre engenheiros e gerentes
- O problema que se queria resolver
- Os benefícios esperados
- A comparação em termos de competitividade de contratação
- Os critérios para comparar essa decisão com outras prioridades
- Depois disso, Chris passou a atuar como especialista interno para ajudar com problemas difíceis de tipagem em TypeScript
De Ember para React: transição gradual versus reimaginação total
- O LinkedIn era o maior usuário de EmberJS do mundo, mas o trabalho de Chris acabou se voltando para planejar a migração de Ember para React
- Líderes mais altos entendiam que o custo de migração do LinkedIn era alto demais e desacelerava o ritmo do produto
- O plano do time de Chris era uma estratégia gradual de automação de 3 a 5 anos
- Reforçar a automação para que os times de produto quase não precisassem parar
- Separar e migrar, em sequência, pipeline de build, camada de dados, camada de roteamento, sistema de reatividade e camada de view
- Ao final, substituir o sistema de renderização e reatividade do Ember pelo lado do React
- Outro time atacava o problema de velocidade de forma mais direta
- O objetivo era reduzir de meses para semanas o tempo entre uma ideia e um teste A/B
- O problema, para eles, estava nas pilhas diferentes e no longo cycle time de web desktop, web mobile, iOS e Android
- Chris descreveu a abordagem desse time como próxima de um modo “finger guns mode”
- Ele sentia que não se tratava adequadamente dos problemas que surgiriam ao ampliar uma experiência que atendia dezenas de pessoas para dar suporte a centenas de engenheiros
- Na visão dele, muitas respostas a questionamentos eram no tom de “isso não vai ser um problema”
- O plano de 3 a 5 anos do time de Chris não teve boa recepção da liderança
- O plano em si era longo e pouco empolgante
- O próprio time o apresentou como a “opção menos ruim”, o que reduziu seu poder de persuasão
Problemas de resiliência expostos na resposta a incidentes
- Depois que Chris voltou do recesso de Natal, surgiu um problema em que alguns usuários do LinkedIn ficaram sem ver páginas do LinkedIn.com por até cerca de 20 minutos
- O problema estava ligado a um serviço de prerenderização que executava código cliente em Node.js para reunir dados do backend e entregá-los mais rapidamente
- O serviço tinha vazamento de memória, e os contêineres reiniciavam quando ultrapassavam o limite de memória
- Vários fatores contribuíram para agravar a falha
- Não havia alertas suficientes para kills por memória
- A configuração do número de contêineres que podiam reiniciar ao mesmo tempo existia como uma chave em um arquivo YAML
- O valor era válido do ponto de vista de tipo, mas inadequado para esse sistema
- Na prática, ele ficava perto do número total de serviços em execução
- Quando uma pausa de deploy se prolongava, como em um feriado longo, os serviços esgotavam memória em momentos parecidos e reiniciavam todos de uma vez, deixando de atender requisições de usuários
- Quando parte dos servidores caía, a carga sobre os demais aumentava, e o uso de memória deles também subia mais rápido, levando a quedas em escala de datacenter
- Ao mesmo tempo, estava em andamento um trabalho de rightsizing para reduzir uso de CPU e memória da fleet, o que diminuiu a folga disponível
- Chris e outros engenheiros concluíram que eram necessários melhores alertas, observabilidade e resiliência
- Mesmo que um servidor Node entrasse em estado runaway, ele não deveria derrubar também o processo hospedeiro
- Seria mais seguro encerrar apenas o processo Node, emitir alerta e reiniciar
- Também foi considerada uma rota de fallback para fetch no lado do cliente quando o serviço ficasse indisponível
O choque sobre o que code review consegue evitar
- As reuniões de resposta ao incidente aconteciam várias vezes por semana, com foco em compartilhar progresso e reportar a executivos
- Um gerente de outro time assumiu a resposta ao incidente e trouxe mais gente, e Chris interpretou isso como um movimento de desconfiança em relação às respostas dele e do time original
- Nesse processo, um engenheiro sênior perguntou: “Por que code review não consegue resolver isso?”
- Chris entendia que só code review não poderia garantir que o mesmo problema não aconteceria de novo
- Pessoas cometem erros
- Um engenheiro júnior dificilmente vai questionar se um valor de configuração faz sentido em um PR de um SRE muito sênior
- O sistema precisa operar com segurança não apenas no melhor dia de um engenheiro sênior, mas também no pior dia de um engenheiro júnior
- Para Chris, engenharia de software inclui projetar sistemas que deem suporte aos engenheiros responsáveis por entregar resultados de produto
- Falhas técnicas e comunicação organizacional não eram separáveis e, como diz Charity Majors, em níveis altos não existem problemas puramente sociais ou puramente técnicos
Liderança, cultura remota e conflito de valores
- Chris sentia que seu time e sua abordagem foram superados pela proposta de outro grupo
- O plano desse outro time cresceu para uma reavaliação tanto do desktop quanto dos apps móveis, tornando-se uma revisão mais ampla de como o LinkedIn constrói produtos
- Chris queria melhorar a proposta, mas sentia que suas preocupações e perguntas não eram realmente acolhidas
- Ele contou que um gerente lhe disse que ele era “idealista demais”, que não se preocupava o suficiente com lucro e prejuízo e que precisava mudar seus valores
- Chris acredita que o trabalho remoto influenciou sua capacidade de construir relações
- O LinkedIn tinha uma cultura fortemente presencial, e muita gente criava vínculos naturalmente no refeitório ou nos corredores
- Ele sentia que o contato físico recorrente com engenheiros seniores e executivos podia fazer diferença em momentos de conflito
- Chris também reconhece que tinha limitações próprias na construção de relacionamentos
Por que ele acabou saindo
- Chris vê muitos problemas da base de código existente como resultado de supervalorizar velocidade e não corrigir nem remover problemas nos caminhos auxiliares
- Na visão dele, quando velocidade vira o valor máximo, é possível ganhar rapidez no começo, mas isso se torna difícil de sustentar com o tempo
- Ele contou que havia sofrido burnout no emprego anterior e teve enxaquecas severas, dores abdominais, incapacidade de se exercitar, crises de choro repentinas e ataques de pânico
- Acreditava que, se continuasse no LinkedIn, seguiria tendo de se esforçar todos os dias para não viver com raiva
- Comparando a situação a tentar mudar a direção de uma organização enorme usando um pequeno bote a remo, decidiu não gastar anos trabalhando de um jeito e em objetivos nos quais não acreditava
- Chris disse ter aprendido no LinkedIn sobre um app de 3 milhões de linhas, migração de TypeScript em grande empresa e grandes problemas de engenharia em escala, mas saiu para buscar um trabalho alinhado com seus valores
1 comentários
Opiniões no Hacker News
Acho que o trecho mais interessante do podcast foi o feedback de que ele era “idealista demais, não se preocupava o suficiente com lucros e perdas e precisava mudar seus valores”. Eu já tinha ficado com essa impressão antes de ler, e ao longo do texto parece que ele recebeu feedback valioso, mas o ignorou de propósito
O difícil para um engenheiro sênior staff não é “estar certo” em si, mas criar alinhamento em toda a organização rumo à solução correta. Como participei do trabalho de reescrever o facebook.com em React em 2019, achei essa história particularmente interessante
Consegui me comunicar até certo ponto, mas durante meu tempo no LinkedIn não tive muito sucesso nesse alinhamento. Parte disso é minha responsabilidade, e parte também é responsabilidade do LinkedIn
Dito isso, neste caso, “idealista demais” realmente queria dizer “não se preocupe com nada que não contribua diretamente para lucros e perdas”, e eu rejeito isso até a medula. Lucros e perdas são importantes, mas a experiência do usuário, a experiência do desenvolvedor e a ética básica sobre o que construímos também importam
Em uma organização, você defende da melhor forma possível aquilo que acredita ser correto, e outra pessoa, ou um grupo de consenso, decide se concorda. Cabe a mim decidir se aceito esse resultado, se faço concessões ou se vou embora; na minha carreira, já fiz as duas coisas
Em um unicórnio famoso, havia um engenheiro sênior staff muito inteligente, racional e gentil. Ele defendeu atualizar um framework usado em escala de 50 milhões de dólares por ano da v2 para a v3, e, comparado a uma migração do Python 2 para o 3, era uma mudança muito pequena
A investigação mostrou que basicamente se poderia esperar uma melhoria de desempenho de 10%, mas a liderança não queria “perder tempo com upgrade de versão”. No fim, esse engenheiro tocou a iniciativa sozinho, criou uma versão de prévia em menos de um mês e, em até dois meses, migrou parte do trabalho que gerava grande impacto, economizando várias vezes o próprio salário
Depois que os custos políticos iniciais e os custos de engenharia foram pagos, todo mundo quis migrar; um ano depois, quando o rollout terminou, a estrutura de gestão acima havia sido reduzida pela metade por demissões e saídas, mas o engenheiro e a migração continuavam lá. Às vezes, um staff engineer não está sendo teimoso; pode ser a única pessoa sã em um mundo insano
Já estive nessa posição e pude optar por não participar, mas nem sempre isso é possível
Já vi casos em que, mesmo sem a melhor ideia ou o melhor plano, alguém convenceu a liderança com as conexões certas, o almoço certo e as palavras certas
A frase “você é idealista demais e não se preocupa o suficiente com lucros e perdas” também pode ser um rótulo usado para empurrar alguém para fora. Especialmente se vier de alguém que vendeu a si mesmo e suas ideias para a alta liderança exatamente dessa forma
Pessoalmente, em uma organização menor que o Facebook, mas com centenas de engenheiros e uma grande base de código, já conduzi várias mudanças e upgrades em larga escala envolvendo Ruby, Rails e Postgres, e a metodologia que Chris descreveu é muito razoável e condiz com as formas que eu senti serem bem-sucedidas
Concordo que papéis de liderança precisam de confiança e respeito para serem eficazes. Claro, para essa confiança ser útil, a pessoa também precisa estar certa de fato. Progresso na direção errada não é progresso
Nunca trabalhei com a base de código do LinkedIn, nem a conheço, mas já vi várias vezes bases de código e estruturas organizacionais/políticas assustadoramente parecidas. Por isso, em geral defendo a abordagem “finger guns”
Uma reescrita no estilo finger guns também pode ser bem implementada. Se há vários clientes que fazem a mesma coisa, um deles pode servir de base para outra plataforma; e, mesmo começando do zero, dá para fazer algo limpo, rápido e enxuto
A chave do sucesso é colocar o novo sistema nas mãos de uma equipe pequena de veteranos que sejam especialistas no domínio e também tecnicamente fortes. É controverso, mas vejo todos os sucessos vindo daí, incluindo até os problemas comuns de operação e manutenção. O resto só desacelera
O grande problema que a maioria dos executivos de tecnologia repete é entregar o próximo grande sistema às pessoas menos experientes. Eu também gostaria de ouvir uma entrevista simétrica do lado dos finger guns
É natural, já que são coisas comprovadas que funcionaram para elas, mas nem sempre é o melhor. Além disso, mesmo quando uma equipe de veteranos inicia um projeto, raramente permanece até o fim; e, se ela não precisa arcar com os resultados ou os efeitos colaterais, é fácil demais tomar decisões
O plano precisa ter opções realistas para lidar com obstáculos, e isso inclui não só alternativas técnicas, mas também o tempo e a capacidade das pessoas que farão o trabalho. Por exemplo, se o plano é que várias equipes operem servidores, isso pode ser tecnicamente possível, mas, se as equipes não têm tempo ou capacidade, não é uma opção realista
Por outro lado, também é ruim planejar um caminho elaborado que contorne todos os obstáculos. Até você chegar lá, os obstáculos podem ter se movido, e pode haver obstáculos no caminho que você ainda desconhece. Se você planejou um único caminho, vai parar ali
Dito isso, o que estamos vendo agora é uma explicação de podcast que resume como desenho animado um debate arquitetural complexo, então não dá para saber qual espantalho estava mais próximo do que realmente aconteceu no LinkedIn
Segundo ela, o conselho disse a toda a engenharia que, dali em diante, em nenhum projeto ninguém poderia determinar detalhes para ninguém
Parece que Chris fez algumas escolhas infelizes. Propôs um plano de 5 anos, conduziu o incidente para o lado da culpa em vez da liderança, falou mais sobre o problema do que o resolveu, e parece que também faltou construção de relacionamentos
Ao mesmo tempo que simpatizo com Chris, também parece que ele não sabia como entregar resultados nesse ambiente. E tudo bem. Nem todo mundo precisa aprender a trabalhar em meio a nós burocráticos; startups são mais simples nesse aspecto
Há um motivo para grandes empresas perderem o fio da navalha com o tempo, e para um executivo encarar uma perda de -10% ano contra ano numa sala de reunião sem um único vice-presidente sendo franco
Quando você está numa situação dessas, perde psicologicamente o senso de direção. Parece que eu estou certo, mas será que estou mesmo? As pessoas ao redor são realmente tão incompetentes e tão desinteressadas em aprender com colegas?
Anos depois, você sai e olha para trás: essas pessoas foram demitidas ou saíram, a organização ainda não consegue fazer X, e a agilidade e a competência das equipes que entraram depois de fato existiam
Por um lado, pode ser arrogância, incompetência política e incapacidade de se adaptar a uma cultura de trabalho patológica. Por outro, talvez essa seja a reação correta
Se a organização está passando por uma fase cultural patológica, talvez faça sentido que pessoas talentosas, ponderadas e apaixonadas enlouqueçam por causa disso. As pessoas que não enlouquecem com isso podem ser irrelevantes para produtividade e crescimento, ou, pior, podem ser uma perda líquida
Por isso, esse tipo de ambiente vira um psicodrama. A situação é realmente tão ruim assim, ou sou eu que estou reagindo demais?
Mas também era o único plano que sentíamos que dava para levar adiante numa situação em que os executivos diziam: “não reduzam em nada a velocidade de iteração do produto, nem mesmo para a migração que pedimos”
Não entendo bem o que significa dizer que conduzi o incidente para a culpa. Tentei fazer justamente o contrário, e não culpei a pessoa que reduziu o limite de memória nem a pessoa que digitou por engano um valor errado no YAML. Apenas insisti para que não deixássemos a causa raiz abandonada até a próxima pessoa explodir tudo de novo, e que realmente a corrigíssemos
Também não entendo bem a parte de que eu só falei em vez de resolver os problemas. Eu só não fiquei me gabando longamente no programa sobre o que consegui fazer; os problemas que resolvi ali foram resolvidos muito bem
A falta de construção de relacionamentos, como mencionei no episódio, era meu ponto mais fraco. Eu tinha boas relações com os engenheiros, mas fracassei bastante em criar confiança política, especialmente com a gestão mais acima
Mesmo assim, não acho que tenha sido simplesmente porque eu não sabia como entregar resultados naquele ambiente. Eu via um caminho pelo qual poderia ter sucesso, mas também escolhi não agir de uma forma em que não acreditava. Muitos engenheiros que respeito fazem a dança política por aquilo em que acreditam, mas não fazem isso por coisas em que não acreditam
Atualmente trabalho no LinkedIn. O papel do Chris e o podcast parecem tratar de Ember e desenvolvimento web front-end, e a quantidade de linhas de código e o build que ele mencionou provavelmente se referem ao voyager-web, o app web representativo monolítico do LinkedIn
O LinkedIn tem outros sistemas com milhões de linhas de código e builds longos. Camada intermediária, stack de dados offline, sistemas de métricas e coisas como KafkaKafkaKafka
Infelizmente, um build de 17 minutos é até bem bom. Se der 17 minutos sem falhas temporárias de infraestrutura, está ótimo
Quase não existe conceito de testes em toda a empresa, e também não há QA. Engenheiros empurram projetos meio crus para colocar no material de promoção e seguem para o próximo
Usando ferramentas internas no dia a dia, era preciso resolver problemas demais por conta própria, e a estrutura fazia com que engenheiros que só queriam trabalhar acabassem, na prática, virando QA
Em vez disso, deveriam ir na direção de tornar os builds rápidos ou tornar a infraestrutura de build mais rápida e barata
Pelo menos nas equipes em que estive, havia uma ênfase considerável em qualidade de código, e a cultura continuava melhorando. Mas já trabalhei em uma tarefa no voyager, e lembro dela como um pesadelo
Reescritas em larga escala são arriscadas até em bases de código gerenciáveis, e os restos que sobram parecem nunca desaparecer de vez. Quem vai querer ganhar pontos, anos depois, reescrevendo uma página de configurações enfiada em algum canto?
Já vi tantas tentativas desse tipo que parece que deveria existir um framework para reescrever bases de código, mas não existe. Ferramentas automáticas de modificação de código exigem consistência, mas poucos lugares mantêm esse tipo de consistência. Os padrões de código evoluem tanto com o tempo que parece observar anéis de crescimento de uma árvore
Basicamente colocamos código em caixas, reorganizamos as caixas e afirmamos de forma plausível que uma organização é mais eficiente que outra. Então por que não encontramos um jeito melhor? A automação funciona no nível do código, mas não no nível das caixas
Este é um caso em que a Lei de Conway está em ação. Como a organização não mudou, há uma boa chance de recriarem a mesma sopa de código
Falando como alguém que já esteve no mesmo barco, iniciativas positivas de engenharia precisam vir de cima para baixo, com patrocínio de alguém em posição muito alta. Não dá para mudar a organização de baixo para cima, e quem cria a base de código é, no fim, a organização
A Lei de Conway não muda, mas não depende necessariamente apenas do organograma formal. Dá para lidar com isso criando estruturas temporárias de comunicação entre os líderes técnicos certos e gestores competentes
Mas basta haver no meio alguns gestores tecnicamente fracos ou tentando construir seus próprios feudos para tudo se quebrar facilmente; dependendo do ciclo de vida da empresa, talvez já não haja esperança por causa da Lei de Ferro da Burocracia de Pournelle
Por exemplo, se todos os desenvolvedores forem péssimos, dão a eles um framework popular. É uma desculpa para não lidar com problemas de pessoas, como permitir que crianças administrem a creche
Se você quer excelência, precisa estabelecer padrões altos com regras que cobrem responsabilidade e imponham propriedade, recompensas e consequências. Não é complicado, mas exige firmeza de cima e não ter medo de conflito
Só que você pode acabar perdendo toda a esperança de que uma empresa como a Microsoft consiga criar algo e depois não estragar
Passei 12 anos no LinkedIn. Tristemente, está longe da organização de engenharia de antigamente. A época em que Kevin Scott liderava engenharia foi realmente muito boa em comparação
Centenas de milhares de linhas de JavaScript — isso por si só é a encarnação do inchaço
Eu vinha pensando em reimplementar algo como o LinkedIn ou, mais precisamente, criar meu banco de dados de contatos sem recursos “à la Facebook”
O problema é como fazer meus contatos migrarem em massa. À parte o inchaço, o principal problema do Microsoft LinkedIn é que ele não deixa exportar informações de contatos, e para uma plataforma de contatos isso deveria ser um recurso essencial
https://queue.acm.org/detail.cfm?id=2567673
Resumo: https://www.pixelstech.net/article/1395463142-Why-does-Linke...
O LinkedIn migrou para Node no início de 2010
Mas, vendo as reações nesta thread, fico pensando se talvez esse número estivesse errado
Não tentei no LinkedIn, mas é um truque sujo que uso para exportar listas de participantes de conferências publicadas em sites públicos. Pode depender do caso
Achei impressionante a forma como Chris Krycho falou com franqueza sobre suas dificuldades sem cair no jogo de culpas. CoRecursive é um dos meus podcasts favoritos porque trata do contexto complexo por trás do código
Parece quase sempre um papel difícil de liderança soft. Um cargo em que você tem “responsabilidade” por algo, mas pouca ou nenhuma autoridade sobre o restante da organização
Se existe liderança técnica de verdade, talvez ela esteja ausente, ou esteja ali há tempo demais e, mesmo sendo “especialista no sistema”, já não esteja mais em contato com os problemas reais. Já passei por isso, e dispenso repetir