Reuniões causadas por deploys lentos (2015)
(tidyfirst.substack.com)- Em uma situação em que engenheiros sentem que “não conseguem entregar código por causa das reuniões”, a causa real pode ser a sobrecarga organizacional criada por uma capacidade lenta de deploy
- Chuck Rossi, do Facebook, considera que a quantidade de mudanças que um único deploy consegue comportar parece ser quase fixa, e que, para aumentar o volume de mudanças, é preciso aumentar a frequência de deploys
- O Facebook aumentou o deploy de código PHP de semanal para diário e depois para 3 vezes ao dia, e também reduziu o ciclo de deploy de apps móveis de 6 semanas para 4 semanas e depois 2 semanas; isso foi liderado principalmente pela equipe de engenharia de release
- Quando a produção de mudanças ultrapassa o limite de deploy, a quantidade de mudanças por deploy não aumenta facilmente; em vez disso, cresce a sobrecarga como reuniões, revisões e handoffs, e a organização se adapta reduzindo o volume total de mudanças
- Para fazer passar mais mudanças, não basta apenas reduzir reuniões: é preciso aumentar a capacidade de deploy melhorando ciclo de deploy, testes, monitoramento, isolamento e relações sociais dentro da equipe
Reuniões podem ser consequência, não causa
- A reclamação comum de que “há tantas reuniões que não consigo fazer deploy de código” pode ter a causalidade invertida
- Adicionar ou remover sobrecarga organizacional é relativamente fácil, mas aumentar a capacidade da organização de fazer deploy de código é mais difícil
- Reuniões e revisões podem ser o resultado da adaptação da organização para evitar que o sistema de deploy fique sobrecarregado
- Chuck Rossi observou no Facebook que parecia haver um número definido de mudanças que um único deploy conseguia processar
- Se você quer mais mudanças, precisa de mais deploys
- O deploy de código PHP passou de semanal para diário e depois para 3 vezes ao dia
- O ciclo de deploy de apps móveis caiu de 6 semanas para 4 semanas e depois 2 semanas
- Essa melhoria foi impulsionada principalmente pela equipe de engenharia de release
Se a capacidade de deploy não aumentar, a sobrecarga cresce
- “Mudanças por deploy” parece ser uma métrica inelástica que não aumenta facilmente, e só melhora com grande esforço
- Quando o número de mudanças criadas ultrapassa o limite atual, surge uma pressão para reduzir o volume total de mudanças, em vez de aumentar o número de mudanças por deploy
- Reuniões, revisões, handoffs e outras sobrecargas aumentam
- Com o tempo, entusiasmo e iniciativa também podem diminuir
- O aumento da sobrecarga pode criar um loop de feedback positivo
- Menos trabalho é processado
- A pressão aumenta
- Os erros aumentam
- O número de mudanças por deploy diminui ainda mais
- A sobrecarga volta a aumentar
- Tentativas isoladas de apenas reduzir a sobrecarga podem aumentar a pressão e acabar elevando novamente a sobrecarga
- Para fazer passar mais mudanças, é preciso alargar a capacidade de deploy, a “ponta distante da mangueira”
- Método difícil: reduzir o ciclo de deploy e lidar com a confusão resultante
- Método mais difícil: aumentar o número de mudanças por deploy com testes melhores, monitoramento, isolamento entre componentes e relações sociais dentro da equipe
- Só tentar reduzir reuniões pode levar a “reuniões para discutir como reduzir reuniões”
- Pode ser visto como um exemplo de Thinkie de causalidade reversa, que organiza ideias que à primeira vista parecem erradas
2 comentários
Achei muito boa essa opinião.
Comentários no Hacker News
Infelizmente, acho que a conclusão deste texto está um pouco invertida. É importante reduzir o risco de deploy melhorando testes e atributos organizacionais, mas essa não é a única abordagem que funciona.
O autor disse que o número de mudanças por deploy é fixo e difícil de aumentar, mas acho que o “Reversie Thinkie” aqui é, na verdade, reduzir o número de mudanças por deploy. O motivo de existirem reuniões de deploy é o risco, e quanto mais mudanças houver em um único deploy, maior a chance de introduzir bugs ou problemas operacionais. Ao fazer deploys pequenos com frequência, dá para entregar valor mais rapidamente e também tornar as falhas menores.
Se isso for combinado com deploy canário e rollout gradual, o deploy deixa de ser uma questão de apertar um interruptor e ver se quebra ou não, e passa a ser um mundo em que falhas são transformadas em degradação de desempenho ou impacto limitado. Essa abordagem é bem tratada na pesquisa DORA[0], em Accelerate[1], The Phoenix Project[2] e em seu antecessor espiritual, The Goal[3].
[0] https://dora.dev/
[1] https://www.amazon.co.uk/Accelerate-Software-Performing-Tech...
[2] https://www.amazon.co.uk/Phoenix-Project-Helping-Business-An...
[3] https://www.amazon.co.uk/Goal-Process-Ongoing-Improvement/dp...
O ponto central é quanto tempo e recursos a organização investe em testes automatizados. Reuniões de release surgem porque não há infraestrutura para validar antes e depois do deploy, nem infraestrutura para fazer rollback de mudanças com falha, e a falta de validação automática acaba sendo compensada por verificações manuais improvisadas. Quando a organização de QA não tem capacidade técnica suficiente, ela empurra procedimentos manuais por autopreservação.
Pior ainda, às vezes passar por essas reuniões é embalado como sinal de excelência e boas práticas. Isso acontece porque pessoas contratadas para mitigar o problema não têm incentivo para eliminá-lo pela raiz. Se um bug vaza para produção, vira “um problema criado pelos desenvolvedores que o QA não pegou por tais e tais motivos”; com testes automatizados, porém, seria difícil até deixar passar na etapa de PR.
As reuniões não surgem por causa do risco, mas porque há, dentro da organização, papéis que precisam que o risco exista para justificar sua existência e que não têm a tecnologia para reduzi-lo. Se for possível automatizar verificações mínimas de que a mudança foi executada e está funcionando após o deploy, e fazer rollback automático em caso de falha, a reunião deixa de ser necessária.
Vejo muitos desses processos como respostas racionais, mas não técnicas, para tornar uma situação ruim o mais suportável possível quando não há uma solução fundamental. Mas isso não quer dizer que sejam totalmente inofensivos. Em algumas organizações, mesmo em novos projetos ou em projetos para eliminar ineficiências existentes, os tomadores de decisão continuavam apresentando processos centrados em pessoas como solução.
É um caso de falta de imaginação técnica ou de pessoas presas ao enquadramento dos problemas existentes, então quem tem essa imaginação precisa se manifestar e dizer que, onde for possível, devemos minimizar processos humanos por meio de mudanças técnicas. Nem todo processo humano pode ser eliminado com tecnologia, mas não quero ficar me espalhando por cima de coisas desnecessárias.
Pode-se estimar que mudar mais de 2% do total dos processos em determinado período é “demais”, e esse valor pode ser ajustado. Isso também deve variar por área, então a equipe do código de processamento de pagamentos e a equipe do código de RH deveriam ter critérios diferentes, e pode fazer sentido alternar releases ou equipes.
Neste período, esta equipe faz o trabalho difícil e, quando for para produção, volta para um trabalho mais fácil, por exemplo. O mesmo princípio se aplica a ataques de trincheira, avanço de batalhão e operações de armas combinadas.
Claro que isso é um problema de gestão, mas boa parte pode ser automatizada, e sinais de entrada como quais equipes fizeram commits recentemente em módulos sensíveis também são úteis. Por fim, essa perspectiva torna os sprints do Agile/Scrum estranhos. Sabemos que não dá para correr a maratona inteira em ritmo de sprint; então como preparar a rotação dos sprints?
Dá para usar feature flags, mas então se cria um “backlog de funcionalidades não ativadas”. No fim, funcionalidades geralmente são consumidas por pessoas, e pessoas precisam de treinamento para mudanças.
Muito antes de alguém escrever The Phoenix Project, ele já tratava de fluxo, traduzia princípios do Toyota Production System e aplicava física a processos de negócio. Também gosto de The Phoenix Project, mas, comparado a The Goal, ele é quase uma adaptação barata feita para que pessoas de TI não leiam uma história sobre linhas de produção e saiam correndo dizendo “eu sou PrOgrAmmEr, então trabalho criativo não pode ser otimizado como uma fábrica”.
Portanto, The Phoenix Project é o sucessor espiritual de The Goal, não o contrário.
Tento explicar o conceito de “literacia em software”. A ideia é que, assim como hoje uma empresa pode ser operada por frases em inglês, como documentos de políticas e e-mails, um negócio também pode ser operado por código.
Daí surgem conclusões como “se a GPU faz o trabalho, o coder é o novo gerente”, ou que é necessário um aparato de testes em toda a empresa para que o impacto das mudanças fique claro. Isso também parece diretamente relacionado a este excelente texto. Se todos os tomadores de decisão não enxergam o código, e não o Jira ou um plano de projeto, como objeto de primeira classe no processo de mudança, então esses tomadores de decisão não têm literacia em software.
A questão “como discutir isso com executivos não técnicos” aparece com frequência, e a resposta é que não dá. Esses executivos precisam mudar. É uma enorme barreira geracional que eu já achava problemática 30 anos atrás, mas ingenuamente imaginava que desapareceria quando os coders crescessem. Mas, como não é preciso programar para “operar” uma empresa, será difícil superá-la até que não saber programar passe a ser tão vergonhoso quanto um editor de jornal não saber escrever.
O ponto central não é SOPs, testes ou reuniões, mas a necessidade de uma empresa que possa ser operada por um novo conjunto de conceitos que se reforçam mutuamente, como sistemas enquanto comunicação.
Mas não sei por que chamar isso de “literacia”. O termo autopoiesis, de Maturana & Varela, parece mais próximo do núcleo da questão, e Autopoietic Systems, de Stafford Beer, também parece oferecer uma boa base intelectual.
Ainda assim, em algum momento, um “negócio” puramente de software não acaba simplesmente parecendo SaaS?
A organização vai bloquear ativamente qualquer tentativa de melhorar o deploy. Dizem, com cara séria, coisas como “Jenkins não pode ficar perto do ambiente de produção”, “não podemos colocar no ar sem QA”, “precisamos desse tempo para garantir qualidade de software suficiente”.
Enquanto isso, há milhões de bugs em produção, e o produto mal atende aos requisitos dos usuários. No fim, na maioria das organizações, lutar contra a burocracia é praticamente impossível. Ainda mais se você não fizer parte das 200 camadas de gestão que geram essas reuniões.
Dá vontade de mandar todo mundo embora, deixando só uns dois programadores e designers, e deixá-los brigar entre si sem coach ágil, product owner, scrum master ou especialista de produto. Deploy lento é um problema, mas não é o problema em si.
Se você continua caindo em lugares que parecem impossíveis de mudar, precisa perguntar mais sobre isso nas entrevistas. Em empresas pequenas, encontrei muitas sem burocracia insana, do jeito que eu prefiro; agora estou em uma grande empresa, mas, quando se age de forma consistente e persuasiva, muita coisa também vai, aos poucos, na direção certa.
É preciso entender que as coisas levam tempo, compreender por que as pessoas as fizeram daquele jeito e então encontrar argumentos convincentes para torná-las melhores. Existem lugares realmente ruins, e faz sentido não ficar neles, mas o desespero não ajuda muito.
Haveria muita coisa a destrinchar, mas meu viés tende a concordar com esse argumento.
Jenkins é o Wordpress do desenvolvimento de software. É um enorme loop com estado que executa plugins sem separação de privilégios. Dar credenciais de administrador de produção a uma instância do Jenkins pode equivaler a entregar as chaves de root a uma pessoa aleatória na Romênia que criou um plugin que você nunca auditou. É perfeitamente compreensível que nem todo mundo queira isso.
“Não podemos colocar no ar sem QA” também. Se você faz deploy em produção de algo que nunca passou por QA, para que existe QA? Para consertar depois? Se você não dá autoridade ao QA, ele não tem a chance de fazer bem o próprio trabalho, nem de ter orgulho dele.
Em qualquer iniciativa, desde o primeiro dia o Jenkins levava até produção, muitas vezes direto com desenvolvimento baseado em trunk, e a qualidade era responsabilidade de todos os desenvolvedores. No nível de contribuidor individual, não havia “luta contra a burocracia”, embora, quando parceiros externos e stakeholders estavam profundamente envolvidos, a liderança provavelmente tivesse discussões intensas de vez em quando.
A ideia de deixar só programadores e designers funciona bem para mim, mas não escala. É preciso haver pelo menos um “dono”, “especialista” ou “gerente” de produto para enfileirar as prioridades dos stakeholders. Esse papel pode ser um “chapéu” que desenvolvedores e designers revezam entre si, mas algumas pessoas são excepcionalmente boas nessa habilidade.
Também entendo que muitas organizações não operam assim. Ao mudar uma empresa nessa direção, ajudou criar uma única equipe experimental, baseada em voluntários comprometidos com essas práticas, protegida por autoridade vinda de cima, mas não comandada por ela. Claro, isso é na Califórnia.
Um caso um pouco relacionado: já trabalhei em um lugar onde o pipeline de CI levava cerca de 25 minutos, dos quais mais de 3.000 testes unitários/de integração consumiam 18 minutos.
Toda vez que havia um problema em produção, acrescentávamos mais testes e, naturalmente, quando algo dava errado, a recuperação exigia no mínimo 50 minutos. Depois de muita reflexão, decidimos focar na recuperação, afrouxamos e simplificamos alguns testes para fazer tudo rodar em menos de 5 minutos e usamos deploy canário em vez de rolling update.
Para nós foi uma experiência realmente revigorante, mas, de certa forma, também parecia errada.
Claro que todo tipo de coisa acaba embutida nessa velocidade de deploy, mas quase tudo é coisa boa.
Um pouco tangencial, mas por que o CloudFormation é tão lento?
Houve um caso em que uma Lambda dentro de uma VPC foi removida e estava conectada ao EFS; o deploy em si foi bem rápido, mas o CloudFormation levou cerca de 20 minutos para limpar tudo e terminar
Toda vez que uma mudança de estado é implantada como uma transação, é preciso verificar pré-condições e pós-condições em cada etapa. Para lançar um conjunto de mudanças com qualquer dependência entre si, não há alternativa a não ser implantá-las em etapas sequenciais. Cada etapa faz várias chamadas de rede para aplicar a mudança, autenticar e fazer polling de estado, cada uma levando algo como 50–200 ms, e isso se acumula rapidamente
Mesmo ao implantar a mesma aplicação em outro provedor de nuvem com Terraform ou Ansible, o resultado é parecido. Se você implantar manualmente a mesma mudança, algo que levaria minutos vira um suplício de um dia
O maior problema de IaC é que ela é de alto nível demais e faz coisas demais internamente, de modo que surgem pessoas que não sabem que mudança está sendo realmente aplicada nem o que ela está fazendo. E então reclamam que demora
Passei por algo parecido pessoalmente no trabalho. Antes das férias de Natal houve uma grande mudança, e havia muito medo. A organização reagiu aumentando os testes, isto é, aumentando os testes de regressão e, com isso, o overhead
Isso elevou o risco de uma mudança em dev quebrar as mudanças no meu branch. Não era um risco de conflito de merge de código, mas um risco na perspectiva de sistemas adaptativos complexos. Para lidar com esse risco, criei reuniões e, ao apresentar o cronograma do projeto, expliquei aos colegas as expectativas: se deixassem comentários de estilo de código no PR, eles seriam empurrados para um PR posterior e acabariam sendo ignorados
O que era necessário eram testes mais granulares, com melhor isolamento entre componentes. O problema é que a liderança enxerga tudo apenas em um nível alto demais e vê reuniões não como um meio, mas como um objetivo que tem valor por si só. A lógica é: se há muitas reuniões, há muita colaboração, e isso é bom. Eu gostaria de ver conselhos sobre como conduzir mudanças técnicas junto com gestores não técnicos
Post relacionado: Slow Deployment Causes Meetings - https://news.ycombinator.com/item?id=10622834 - novembro de 2015, 26 comentários
Com microsserviços, dá para escalar horizontalmente também a frequência de deploy
Com uma aplicação monolítica composta por módulos independentes, também é possível fazer deploy com a mesma frequência sem microsserviços, evitando os principais pontos negativos: a complexidade de infraestrutura/CI·CD e a transformação de chamadas de função dentro da aplicação em um problema instável de comunicação de sistemas distribuídos. É preciso resistir à complexidade acidental desnecessária
[1] https://www.fearofoblivion.com/build-a-modular-monolith-firs...
[2] https://ardalis.com/introducing-modular-monoliths-goldilocks...
E ganha novos problemas divertidos, como planejamento de deploy e sincronização de lançamento de funcionalidades
Caso contrário, você ganha ao mesmo tempo problemas de dados distribuídos e mais camadas de complexidade — ou seja, mais reuniões do que em um monólito
Em monólitos, existe o risco de cair em uma enorme confusão de SOLID, DRY e outras bobagens de “código limpo”, até chegar a um estado em que ninguém consegue mudar nada por medo de quebrar algo. Não quer dizer que os princípios de orientação a objetos estejam obviamente errados em si, mas eles costumam ser tão extremamente ambíguos que quase ninguém consegue aplicá-los direito
Sempre acho engraçado quando o Uncle Bob, diante de qualquer crítica, despacha com “eles entenderam os princípios errado”. Se tanta gente erra, talvez os princípios é que sejam ruins, não? Microsserviços também não protegem contra má governança; ela apenas aparece em outra forma de problema. Acho muito fácil e comum criar vários microsserviços e acabar numa situação em que ninguém sabe que impacto uma mudança terá sobre outros serviços
No fim, é um problema de gestão de equipes e, pela minha experiência, é a área em que nosso setor é pior. Talvez melhore quando uma nova geração, com ideias como “Team Topologies”, chegar, mas mesmo que isso de fato se resolva, levará décadas. Em muitos casos, isso escapa das mãos do departamento de digitalização quando a organização enxerga “TI” apenas como centro de custo e não formula demandas de um modo que possam ser incorporadas a processos de boas práticas de engenharia de software
Um dos motivos pelos quais gosto de Go como linguagem de uso geral é que, por design, ela é simples e muitas vezes leva a bases de código fáceis de modificar. Vi alguns bancos online e plataformas de aluguel/gestão patrimonial migrarem para Go e crescerem porque passaram a conseguir entregar de fato o que o negócio precisava. Enquanto isso, concorrentes ficavam presos a bases de código Java ou C# intratáveis, lançando uma funcionalidade cheia de bugs uma vez a cada seis meses, quando tinham sorte
Isso não é um problema de Go, Java ou C# em si, mas do fato de que arquiteturas e designs orientados a objetos à moda antiga são fáceis demais de estragar. Em um lugar onde trabalhei, havia mais de mil interfaces em C#, e nenhuma delas era consumida por mais de uma classe. Dezenas de milhares de interfaces estavam todas na mesma pasta e no mesmo namespace, e encontrar o que você precisava era questão de sorte. Dá para fazer isso em Go ou em qualquer linguagem, mas é menos provável se você não estiver imerso na cultura antiga de linguagens de “código limpo” orientadas a objetos. Especialmente em C#, a abstração por padrão está tão profundamente enraizada na cultura que é mais difícil não fazer isso
Pessoalmente, tenho um carinho secreto por organizações Python. Elas sempre entregam rápido, e o código é horrível. É adorável
Em geral está correto, mas também é igualmente irrelevante
Em resumo, o que importa é o desempenho do software e, portanto, o desempenho humano. Gestão de risco e aceitação de risco podem ser medidas em números. Em software, isso é muito mais simples do que em outras profissões, porque engenheiros de software só podem aceitar riscos dentro de restrições operacionais conhecidas, e todo o restante é adiado
Se quiser ficar mais rápido, antes de tudo é preciso maximizar a frequência de iteração humana. Se você não consegue iterar porque está esperando permissão, está bloqueado; se está esperando um build ou uma atualização de tela, está ficando mais lento. Isso também pode ser medido em números
Se A consegue iterar 100 vezes mais rápido que B, a precisão se torna secundária. Como B é lento, precisa maximizar a precisão. A tem extrema flexibilidade para aprender, falhar e melhorar a fim de ficar mais rápido e mais preciso
Uma parte de reduzir riscos enquanto se itera mais rapidamente é a automação rápida de testes. Se A consegue executar mais de 90% de cobertura de testes no tempo de 4 iterações humanas, essa automação de testes ainda é 25 vezes mais rápida do que uma única iteração de B, e o risco de regressão é mais de 90% menor
Deploys rápidos criam war rooms para resposta a incidentes
Muito mais importante do que essa queda foi o fato de que, quando surgia um problema, encontrar a causa ficou muito mais rápido. Como as mudanças revertidas eram muito pequenas, fazer rollback também era muito mais seguro e fácil. Ninguém quer reverter 3 semanas de trabalho. Isso é caos