DEV Community: Tio Dani

O golpe do Perfil Dourado

Tio Dani — Thu, 24 Jul 2025 12:44:10 +0000

Fuja de quem tenta lucrar com sua insegurança profissional

Existe uma narrativa tentando convencer as pessoas de que elas não sabem se vender, e que isto as prejudica, tornando-as invisíveis às pessoas de recrutamento que poderiam lhes abordar com boas oportunidades.

Eu não estou aqui pra te convencer do contrário, e dizer que você não deveria cuidar da sua apresentação, e que o seu perfil não deveria ser elaborado de uma forma que destaque sua competência, sua experiência e suas habilidades técnicas e não técnicas (as famosas soft skills).

Eu mesmo não me considero exemplo de alguém qualificado pra dar tal conselho e, muito provavelmente, alguém que queira ver meu perfil poderá dizer que ele falha miseravelmente neste propósito. E esta é uma crítica que eu aceito numa boa, embora eu possa dizer que faço sim um esforço absurdo de tempos em tempos pra tentar reformulá-lo de uma forma mais atrativa. Ainda que subjetivo, é difícil medir essa qualidade, a não ser pelo número de visitas (que pode ser uma correlação, mas não uma causalidade) e as mensagens diretas que recebo para discutir diversos assuntos, incluindo novas posições.

Mas, independente da importância que é você tentar reformular seu perfil para torná-lo mais atraente para eventuais profissionais de RH, e você pode fazer isso de diversas formas, inclusive pagando cursos de pessoas que declaram ser especialistas em consultoria de carreiras, o que eu quero compartilhar aqui é pra chamar a atenção de uma inversão de valores.

Alguém está tentando te dar um golpe.

Alguém está tentando te convencer de que não importa o quão competente você é, do quão experiente você é, e do quanto suas habilidades são relevantes. Alguém está tentando te convencer de que pessoas menos competentes, menos qualificadas e menos preparadas estão tomando as oportunidades que deveriam se tuas. Estão fazendo entrevistas que deveriam ter sido agendadas com você. E estão recebendo ofertas que poderiam ter sido enviadas pra você. E estas pessoas só estão conseguindo fazer isto no teu lugar por que elas adotaram um método mágico de elaborar um perfil que irão fazê-las ser encontradas no teu lugar, apesar de você ter a experiência, competência e habilidades necessárias, e elas não.

E a forma de você reverter isto é: você deveria também aprender este método mágico, do Perfil Dourado, ou do Currículo Supremo, ou qualquer outro nome desses feitos para vender uma marca de algo que você certamente não precisa (a não ser que você realmente queira).

Eu gostaria que você parasse um pouco e refletisse sobre isso. Pois há uma desonestidade muito astuta na forma como isso está sendo comunicado a você. Alguém tenta convencer você de que há um sistema de contratação de pessoas incompetentes, inexperientes e até sem as habilidades necessárias, sob a justificativa de que o 'mercado' – essa entidade da qual muitos falam sem refletir – não estaria interessado em encontrar pessoas realmente qualificadas.

Se você tiver aceitado o meu convite pra refletir sobre isso, tente mastigar um pouco esta última frase e pense se ela faz algum sentido. É importante ser razoável em tempos onde as pessoas se aproveitam umas das outras pra lucrar com a insegurança alheia. E se você se sente inseguro, você não está sozinho. Todos nós, em algum grau, sofremos da mesma insegurança. Alguns mais, outros menos, mas não se engane. Ela nos atinge a todos.

E é aí onde mora o problema. A pessoa que tentar te convencer disso tudo não está apelando pra sua competência, não está tentando chamar a sua atenção para suas qualificações ou falta delas. Ela está tentando apelar para a sua insegurança. Ela está te vendendo a ideia de que você precisa criar um Perfil Dourado, não por que você é a pessoa competente que não está sendo abordada pelas pessoas recrutadoras. Mas, sim, por que você ter a insegurança de talvez ser a outra pessoa: a que não tem a qualificação necessária, a experiência necessária, as habilidades necessárias e, por isto, você poderia se beneficiar do tal método, para fazer parte daquele grupo, ainda que a abordagem que te fizeram tenha sido maquiada pra te fazer se sentir parte do primeiro grupo.

Elabore seu perfil. Dedique tempo para destacar o que valoriza sua carreira e o que pode ser apreciado pelas empresas que possam precisar de alguém como você lá dentro. Não aceite meus conselhos a respeito disto, por que eu não sou especialista neste assunto e, se você quiser ouvir alguém, procure um especialista credenciado nesta área. Mas não deixe ninguém te convencer de que o que você estudou e estuda para se manter atualizado e compentente não é importante. Não deixe ninguém te dizer que o tempo que você dedica aprendendo novas habilidades, consumindo conteúdo relacionado à sua área, ou fazendo cursos técnicos, ou lendo livros ou qualquer que seja a forma que você usa para se manter em dia com o que irá manter a sua empregabilidade seja menos importante do que a forma como você monta seu perfil profissional.

Se as empresas estão recrutando pessoas incompetentes sistematicamente, isso me parece mais problema deles, não seu. Se as pessoas são contratadas e se mantém nas vagas que ocupam, talvez elas não sejam incompetentes. Talvez alguém só quis te convencer disto pra lucrar em cima da sua insegurança.

Se você acha que as oportunidades não estão te alcançando por que você não está atendendo as expectativas delas, busque aprimorar suas habilidades, busque participar de grupos de estudo, leia, aprenda, exercite-se, cometa erros! Não se prive deste processo. Ele é a etapa mais importante para que você possa ter realmente um perfil atraente.

Abraço.

Codando sem medo na 'main'

Tio Dani — Tue, 18 Jul 2023 14:55:05 +0000

For non-Portuguese speakers, there is an English version of this article here.

Não. Isso não é bait. Prometo.

Talvez você já faça isso e, se for esse o caso, espero que a leitura ainda possa ser útil. Mas vou falar com aqueles que ainda não estão aproveitando do cobertor aconchegante da Integração Contínua. Minha equipe não está (embora seja um cenário específico, e irei explorá-lo mais tarde, mas ainda acho que deveriam). E se por acaso você achar que uma boa forma de pensar nisso seria "Depende!", eu arrisco e digo: "Tá, mas provavelmente não!".

Vamos admitir, por que você não está fazendo suas alterações diretamente na trunk (ou na main, ou como quer que você a chame)? Presumo que a maioria de vocês responderia de uma das seguintes formas:

Foi assim que me ensinaram! Eu nem pensei nisso desde então.
Você está louco? As pessoas ficariam bravas se eu quebrasse alguma coisa.
Estou ciente de onde isso vai dar, e li que seria o caso de trabalhar em branches quando o código é mantido por uma equipe grande, que é o meu cenário.

Se seus motivos forem diferentes desses, gostaria de saber. Considere gastar um minuto para deixar um comentário.

O terceiro caso é provavelmente o melhor cenário para o "Depende!", embora a definição do que seria uma "equipe grande" seja relativa e muito questionável. Mas eu não quero encher o saco de ninguém com isso, então vamos indo. É um tema quente cercado por equívocos e mal-entendidos, apesar de existir há décadas.

(Re)Descobrindo a Integração Contínua (CI)

Ah, tio! Você não pode estar falando sério. Eu já uso _____ há anos.

- Talvez você (preenchendo o espaço em branco com Jenkins, Github Actions, TravisCI, CircleCI ou qualquer outra ferramenta como essas).

Se você já estiver usando alguma ferramenta de automação de compilação para fazer algumas validações conforme o novo código é enviado para o controle de versão, isso é ótimo. Acredite em mim, ainda sei de equipes que não usam. Ainda assim, mesmo que seu pipeline de build esteja montado, isso não é suficiente para dizer que você está usando a Integração Contínua.

Integração Contínua refere-se à prática de frequentemente integrar alterações de código em um repositório compartilhado. Envolve automatizar o processo de merge, validação e build das alterações de código, garantindo que a integração seja contínua e confiável. A CI permite que as equipes de desenvolvimento trabalhem simultaneamente, colaborem com eficiência e detectem problemas de integração no início do ciclo de desenvolvimento.

Se você não confia que seu pipeline está fazendo um bom trabalho, garantindo que está tudo bem e pode simplesmente ser colocado em produção, ainda não está se beneficiando de CI. E se for seguro assumir que garante, deveria te permitir que você codifique na trunk sem medo.

"E por que isso importa?" você pode perguntar. Você se lembra do último post? Uma das Quatro métricas do Accelerate é Lead time, ou seja, o tempo que leva para uma mudança de código ser implementada e implantada na produção. O tempo necessário para implementar a mudança depende totalmente das pessoas engenheiras de software, mas, uma vez concluída a tarefa, quanto mais tempo demorar para entrar em produção, sentada em uma fila, esperando para ser implantada, maior será o Lead Time. Portanto, este indicador nos dá uma pista de quanto tempo acumulando poeira digital um commit deve esperar antes de ser implantado: Horas? Dias? Talvez semanas... (Já vi cenários onde um único deploy poderia levar até seis meses para ser feito, com centenas de commits).

E essa é uma preocupação central do DevOps: fazer com que o código chegue à produção de maneira suave e rápida. Daí a importância do indicador Lead Time, e o quão importante é depender do tempo que leva para o código ser implementado, e fazer com que o tempo de implantação seja cada vez menor, o máximo que pudermos.

Mas, se agilizar o deployment é uma das maiores preocupações, existe uma segunda, tão importante quanto a primeira, que é torná-lo confiável.

Então, como podemos tornar nosso pipeline de construção confiável o suficiente para nos dar o benefício do CI?

Use o controle de versão

Você provavelmente usa git. Eu sei que existem outros (em minha carreira eu usei CVS, Visual Source Safe, Subversion e até Perforce por um curto período), mas já tem algum tempo que o Git foi bem estabelecido como um padrão para programadores em um sentido geral. Mas usar uma ferramenta de gerenciamento de controle de código é apenas o meio para um fim, e lidar com o controle de versão adiciona uma nova camada à maneira como você o usa.

Por exemplo, a maioria das pessoas desenvolvedoras apenas usa o SCM para fazer o commit do código da sua aplicação, mas ignora que eles devem criar versões do código para configuração do sistema, configuração da aplicação e scripts para automatizar a construção e configuração dela. Portanto, se sua aplicação depende de um banco de dados, você deve implementar alguma automação para manter seu banco de dados alinhado com sua versão de código (manipulação de migração de schema, dados que precisam estar disponíveis quando a aplicação for executada etc.). Além disso, a configuração deve ser igualmente versionada. Considerando o caso da dependência do banco de dados, deveria ser fácil configurar as credenciais do banco de dados e injetá-las em tempo de execução para que a mesma versão possa ser implantada em ambientes produtivos e não produtivos (para testes, controle de qualidade ou preparação).

O livro Accelerate descreve uma pesquisa que foi realizada para o relatório "The State of DevOps" do Puppet, e eles descobriram que:

O mais interessante foi que manter a configuração do sistema e da aplicação no controle de versão estava mais correlacionado com o desempenho da entrega de software do que manter o código da aplicação em si no controle de versão. A configuração é normalmente considerada uma preocupação secundária para o código no gerenciamento de configuração, mas nossa pesquisa mostra que isso é um equívoco.

Portanto, usar o Controle de Versão e gerenciar a configuração do Sistema e Aplicação como parte de sua base de código, bem como scripts de automação, não é apenas uma etapa necessária para a Integração Contínua, mas também melhora o desempenho da equipe e torna a pipeline mais confiável.

Automação de teste

A essa altura, pode não ser uma surpresa para você que estou falando sobre coisas que já são discutidas há muito tempo: CI, Controle de versão e, agora, Automação de teste. Você provavelmente já ouviu falar deles e provavelmente sabe o que é TDD... talvez até tenha lido o livro eXtreme Programming, assistido a alguma palestra sobre isso em uma conferência ou ouvido falar sobre isso em algum post de blog ou vídeo do Youtube. E talvez você também tenha visto outras pessoas rejeitando-o (às vezes, completamente).

Sou um grande fã de TDD, mas independentemente do que você possa pensar sobre isso como uma ferramenta de design, o fato é que, para aumentar a confiabilidade do pipeline de build, você precisa usar automação de teste. E, para o bem da minha sanidade, aproveito para dar um conselho: considere usá-la fazendo TDD (prometo que não vou falar mais sobre isso).

Sim, a Automação de Testes é obrigatória. Se você estava pensando em parar de ler quando falei sobre versionar a configuração do sistema porque pensou que seria difícil, provavelmente está se arrependendo de continuar a leitura. Testar é difícil. Especialmente ao fazê-lo tardiamente no workflow de desenvolvimento (manterei minha promessa). Mais ainda, já que não estamos falando apenas de testes que nos garantem que nosso código está funcionando bem, mas também de tornar o pipeline de construção confiável e agora temos o código de configuração sendo versionado com o código da aplicação e os scripts de automação junto também. E tudo deve estar bem integrado (Integração Contínua, lembra?).

Hora da história:

Em 2013, eu estava trabalhando em um projeto usando .Net, e optamos por usar o recurso de Migrations do Entity Framework para lidar com o versionamento do schema do Banco de Dados. Um dia, quando estávamos tentando construir uma nova versão do aplicativo a pipeline tentou gerar o script para as alterações do banco de dados, recebemos um erro de migração e tivemos que adiar a implantação e investigar o problema.

Descobrimos que o recurso de migração do Entity Framework dependia de um timestamp para garantir que todas as migrações fossem mantidas em ordem, mas pessoas trabalhando em tarefas diferentes (usando branches diferentes) criaram alterações diferentes no banco de dados, cada uma com timestamps diferentes, mas a maneira como eles fizeram o merge do código posteriormente não estava na mesma ordem e as entradas não estavam seguindo a ordem cronológica correta, fazendo com que o Entity Framework entrasse em pânico. Então, a partir daquele momento, decidimos que deveríamos sempre verificar a ordem das migrações ao mergear o código na trunk (a gente usava GitFlow -- eu sei, você não precisa se lembrar de mim disso).

Mas isso não foi o suficiente. O objetivo é tornar a pipeline de build confiável e não podemos confiar que as pessoas se lembrem de verificar a linha do tempo das migrações para enviar seu código. Para ser confiável, a pipeline precisa verificar tudo novamente. É a proteção definitiva que evita que erros humanos causem problemas no fluxo de entrega.

Então começamos a criar um novo tipo de teste automatizado. As pessoas chamam de Testes de Infraestrutura (para diferenciá-los de outros, como testes de unidade ou testes de integração). E o primeiro caso de teste foi criar um novo banco de dados do zero usando a base de código (o que o tornaria compatível com a versão mais recente do código) e, em seguida, executar cada migração voltando para a primeira versão do banco de dados (testando as etapas de downgrade), e por fim rodando todas elas novamente, agora subindo para a última versão (testando as etapas de upgrade) e verificando se tudo foi feito ok.

Tivemos que gastar algum tempo descobrindo como hackear o Entity Framework para funcionar bem com o banco de dados SQLite na memória para que não demorasse muito para executar todos os testes. Assim, a compilação não seria afetada pelo tempo que levaria para executá-los.

Isso mostra como é valioso tornar o pipeline de construção confiável. Toda vez que rodava, a pipeline nos garantia que quaisquer problemas relacionados à ordem das migrações seriam detectados, para que pudéssemos apenas fazer nosso trabalho e confiar nela.

Certifique-se de que sua pipeline teste tudo que possa comprometer a Integração de sua aplicação. Não negligencie o valor que isso traz para o seu fluxo de entrega. Considere não apenas criar testes de unidade e obter uma boa cobertura de código deles, mas também fazer testes de integração, testes de infraestrutura e quaisquer outros testes que aumentem a confiabilidade da pipeline.

Aplique Inspeções de Qualidade e Segurança

Então, a aplicação está sendo compilada, os scripts de configuração e automação estão sendo consolidados junto com o código da aplicação, tudo está sendo bem testado e você tem uma boa cobertura de testes no código... olha só! Bom trabalho. E agora?

Agora temos que evitar outros gargalos que possam afetar nosso Lead Time e, consequentemente, sabotar a confiabilidade do pipeline. Primeiro, verificamos se o código está em conformidade com quaisquer padrões de qualidade que devemos seguir (Build quality in). Talvez você e sua equipe gostem de executar algum linter para verificar os padrões de código ou extrair alguns relatórios de métricas de código para verificar a complexidade ciclomática ou outros indicadores. Talvez esse não seja um problema que pare a pipeline, mas anteciparia o feedback de inspeções e revisões posteriores que poderiam fazer com que as alterações esperassem antes de serem implantadas.

O mesmo se aplica à segurança (Shift Left on Security). Talvez a equipe de Infosec da empresa tenha estabelecido conformidade de segurança que todos devem seguir. Você deve fazer sua pipeline verificar essas inspeções também. Talvez você precise executar varreduras de vulnerabilidade para verificar seu código, as dependências da aplicação e sua configuração... quanto mais você colocar em sua pipeline, mais confiável ela será.

Trabalhe em pequenos lotes e envie códigos regularmente

Agora sua pipeline está fazendo tudo o que precisa para garantir que toda a aplicação esteja íntegra e você pode confiar nela.

A melhor coisa que você deve fazer agora para realmente se beneficiar da Integração Contínua é evitar que seu código gaste muito tempo antes de ser enviado para a trunk. E a melhor maneira de fazer isso é codificar direto nela. Para evitar branches de vida longa, você deve evitar fazer seu trabalho em grandes lotes de código sendo enviados de uma só vez e trabalhar em etapas menores, valiosas e entregáveis, enviando pequenos lotes de código regularmente para a pipeline e observando seu fluxo de entrega enquanto ela roda para executar a integração de forma iterativa e incremental.

Além disso, você nunca deve esquecer que as coisas evoluem, e não existe algo como "definitivo", como uma pipeline final, Uma pipeline para governar todas. Você provavelmente enfrentará situações em que a confiabilidade de sua pipeline de build será desafiada e encontrará espaço para melhorias. Tome conta dela. Não a negligencie! Ela vai te ajudar a dormir melhor.

Conselhos Adicionais

Algumas pessoas (inclusive eu) gostam de manter uma versão menor da pipeline para executar enquanto enviam o código para o repositório de origem como uma forma de garantir, no último momento, que tudo está bem antes que o código chegue lá e quebre a trunk no GitHub (ou similar). Isso é útil, embora você provavelmente tenha que ter cuidado com o quão curto ela é em comparação com a original.

Outra opção seria rodar tudo localmente, no seu ambiente de desenvolvimento (embora isso nem sempre seja possível, mas se for, também é ótimo).

Muitas pessoas tendem a ficar aborrecidas se o build as fizer esperar algum tempo. Especialmente quando elas precisam executá-lo antes do envio. Muitas acham que deveriam gastar esse tempo codificando outras coisas. E é engraçado imaginar o quão relativo é dizer que demora muito, pois faz sentido se a coisa toda demorar mais de 10 minutos para terminar, mas você encontrará pessoas que provavelmente reclamariam mesmo que levasse apenas 2.

Conclusão

Eu sei... o artigo ficou longo... muito.

Mas cobrimos muito em uma das melhores práticas que temos para reduzir o Lead Time, que é uma das Quatro Métricas Chaves, Integração Contínua. Conversamos sobre como codificar na trunk não é uma maneira sem noção de trabalhar e, por meio da confiabilidade da pipeline, podemos ter certeza de fazê-lo sem hesitação.

No próximo post vou falar sobre a Entrega Contínua, que é outra ótima prática a ser utilizada nesse sentido.

Espero que você ache este post útil e estou ansioso para ver o que vocês pensam sobre isso.

Obrigado.

As Quatro Métricas de Accelerate

Tio Dani — Tue, 28 Mar 2023 02:11:25 +0000

For non-Portuguese speakers, there is an English version of this article here.

Na última vez que conversamos, eu estava tentando explicar como podemos usar uma cultura DevOps para desenvolver equipes de alto desempenho. Falei por um tempo sobre "As Três Maneiras" do livro de Gene Kim The Phoenix Project, e mencionei Accelerate, outro livro de Gene Kim (junto com Jez Humble e a Dra. Nicole Forsgren), como uma ideia para uma abordagem mais "tática" para estimular a cultura DevOps dentro da organização. Hoje, quero explorar mais essa abordagem, explorando um pouco mais Accelerate e ver como ele pode estabelecer uma diretriz geral para avaliar o quão maduros os times estão em relação a DevOps e como podem melhorá-lo.

No mundo do desenvolvimento e operações de software, alto desempenho é fundamental. Mas como você mede o desempenho e quais métricas são mais importantes?

Medindo a Maturidade do DevOps

Vamos deixar as coisas claras: Não sou a favor da adoção de qualquer modelo de maturidade DevOps para medir isso dentro de uma organização. Accelerate esclarece que devemos focar em capacidades em vez de maturidade, e vou seguir o livro sobre este assunto. Todo o primeiro capítulo descreve o esforço dos autores para criar medidas e métricas que poderiam indicar equipes de bom desempenho e o quão confiáveis elas são quando usadas para entender como a organização se classifica nessas medições.

Ao nos concentrarmos em capacidades, nos referimos à habilidade de uma equipe de executar determinadas práticas técnicas associadas ao alto desempenho. Essas práticas técnicas incluem coisas como controle de versão, testes automatizados, integração contínua e automação de deployment, entre outras. Medir as capacidades envolve avaliar o nível de proficiência de uma equipe em cada uma dessas práticas técnicas.

De acordo com Accelerate, existem quatro métricas principais nas quais as equipes de alto desempenho se concentram:

Lead Time
Frequência de Deployment
Tempo médio para restaurar o Sistema (MTTR)
Percentual de falha de mudança

Essas métricas fornecem uma visão abrangente do desempenho operacional e de entrega de software e mostraram ser fortes preditores do desempenho organizacional.

De acordo com Kim, "As organizações mais bem-sucedidas são aquelas capazes de alcançar altos níveis de throughput e estabilidade". Throughput (vazão) refere-se à capacidade de entregar novos recursos e atualizações rapidamente, enquanto estabilidade refere-se à capacidade de fazê-lo de forma confiável e com altos níveis de qualidade.

Vamos dar uma olhada mais de perto em cada uma das quatro métricas principais:

Lead Time

"Os melhores desempenhos têm Lead Time inferior a um dia, enquanto os piores desempenhos têm Lead Time superior a um mês." - Accelerate

Lead Time mede o tempo que leva para que uma mudança de código seja implementada e implantada em produção. Equipes de alto desempenho têm um Lead Time significativamente mais curto do que equipes de baixo desempenho, permitindo que elas entreguem valor aos clientes mais rapidamente e respondam mais rapidamente às condições de mercado em constante mudança.

Para alcançar um curto Lead Time, equipes de alto desempenho utilizam práticas como integração e entrega contínuas, teste automatizado e pequenos lotes de entrega. Automatizando tarefas repetitivas e dividindo o trabalho em peças menores, as equipes podem reduzir o tempo necessário para implementar mudanças de código em produção.

Frequência de Deployment

"Os melhores desempenhos implantam o código várias vezes por dia, enquanto os piores desempenhos implantam o código uma vez por mês ou menos." - Accelerate

Frequência de Deployment mede com que frequência as mudanças são implantadas em produção. Equipes de alto desempenho implantam mudanças com muito mais frequência do que equipes de baixo desempenho, permitindo que elas respondam às necessidades dos clientes mais rapidamente e iterem seu produto mais rapidamente.

No entanto, é importante observar que a frequência de deployment não deve ser perseguida às custas da estabilidade e confiabilidade. Equipes de alto desempenho são capazes de alcançar deployments frequentes e altos níveis de estabilidade por meio de práticas como teste automatizado, integração contínua e entrega contínua.

Tempo Médio de Restauração de Serviço (MTTR)

"Os melhores desempenhos têm tempos para restaurar o serviço inferiores a uma hora, enquanto os piores desempenhos têm tempos para restaurar o serviço superiores a um dia." - Accelerate

Tempo Médio de Restauração do Serviço mede o tempo que leva para restaurar o serviço após um incidente ou interrupção de produção. Equipes de alto desempenho são capazes de diagnosticar e corrigir rapidamente problemas em produção, minimizando o impacto nos clientes e reduzindo o tempo de queda do sistema.

Para alcançar tempos de restauração curtos, equipes de alto desempenho utilizam práticas como monitoramento, alertas e processos de resposta a incidentes. Monitorando proativamente seus sistemas, as equipes podem identificar rapidamente problemas quando ocorrem e respondem a eles antes que afetem os clientes. Quando um incidente ocorre, equipes com processos de resposta a incidentes fortes podem mobilizar rapidamente e trabalhar juntas para diagnosticar e corrigir o problema.

Percentual de Mudanças com Falha

"Os melhores desempenhos têm taxas de falha de mudança de menos de 15%, enquanto os piores desempenhos têm taxas de falha de mudança de mais de 46%." - Accelerate

Percentual de Mudanças com Falha mede a porcentagem de mudanças que resultam em uma falha ou defeito que deve ser corrigido. As equipes de alto desempenho têm taxas de falha de mudança significativamente menores do que as equipes de baixo desempenho, indicando que elas conseguem entregar mudanças para produção com níveis mais altos de qualidade.

Para alcançar baixas taxas de falha de mudança, equipes de alto desempenho utilizam práticas como teste automatizado, integração contínua e entrega contínua. Ao identificar problemas mais cedo no processo de desenvolvimento e garantir que as mudanças sejam testadas com rigor antes de serem implantadas, as equipes podem reduzir a probabilidade de defeitos e falhas na produção.

Também é importante observar que a taxa de falha da mudança não deve ser vista como uma métrica punitiva. Em vez disso, ela deve ser usada para identificar áreas de melhoria e impulsionar a melhoria contínua no processo de desenvolvimento.

Quinta Métrica do DORA: A Métrica de Desempenho Operacional

Isso mesmo ... há uma quinta métrica para as 4 Métricas Principais, assim como os Três Mosqueteiros (que eram na verdade quatro).

Além dessas quatro métricas principais, o DORA (DevOps Research and Assessment) tem uma métrica adicional para Desempenho Operacional, baseada em Confiabilidade. É uma medida de práticas operacionais modernas, indicando o quão bem os serviços atendem às expectativas do usuário, como disponibilidade, latência, desempenho e escalabilidade. De acordo com o 2022 State of DevOps Report do DORA, equipes com diferentes graus de desempenho de entrega têm melhores resultados (por exemplo: menos burnout) quando também priorizam o desempenho operacional.

Fitness Functions podem ser úteis para executar diagnósticos de desempenho e escalabilidade dentro do fluxo de trabalho de desenvolvimento, enquanto o monitoramento garantiria que o ambiente de produção garanta a consistência em relação a esse diagnóstico.

O que significa ser uma equipe de alta performance?

Tenho falado muito sobre usar a cultura DevOps para criar equipes de alta performance em uma organização e trouxe métricas para a discussão. Obviamente, medir com que frequência uma equipe consegue implementar ou quanto tempo leva para uma nova mudança chegar à produção dá à equipe um feedback sólido sobre sua própria maturidade. No livro Accelerate, os autores descrevem como usaram análise de cluster para categorizar o desempenho das equipes com base nos dados fornecidos pelos entrevistados. Eles aplicaram essa técnica por quatro anos de pesquisa (os resultados foram publicados pela Puppet como o relatório "State of DevOps Report" de 2014 a 2017) e descobriram que a cada ano havia categorias significativamente consistentes de desempenho na entrega de software na indústria.

Veja como os resultados de 2016 comparados às descobertas de dados em 2017 ilustram como as quatro métricas-chave ajudaram a análise de cluster a categorizar o desempenho (fonte: Accelerate):

2016	Alto Desempenho	Desempenho Médio	Baixo Desempenho
Frequência de Deployment	Sob demanda (múltiplas implementações por dia)	Entre uma vez por semana e uma vez por mês	Entre uma vez por mês e uma vez a cada seis meses
Lead Time	Menos de uma hora	Entre uma semana e um mês	Entre um mês e seis meses
MTTR	Menos de uma hora	Menos de um dia	Menos de um dia*
Taxa de Falha na Mudança	0-15%	31-45%	16-30%

2017	Alto Desempenho	Desempenho Médio	Baixo Desempenho
Frequência de Deployment	Sob demanda (múltiplas implementações por dia)	Entre uma vez por semana e uma vez por mês	Entre uma vez por semana e uma vez por mês*
Lead Time	Menos de uma hora	Entre uma semana e um mês	Entre uma semana e um mês*
MTTR	Menos de uma hora	Menos de um dia	Entre um dia e uma semana
Taxa de Falha na Mudança	0-15%	0-15%	31-45%

* Baixo desempenho foi menor em média (em um nível estatisticamente significativo), mas teve a mesma mediana que o desempenho médio.

Observe como o limite que distingue as categorias de desempenho para a Taxa de Falha de Mudança muda nos dados de 2016 para os dados de 2017: os times de Desempenho Médio melhoraram seu resultado de 21-45% em 2016 para 0-15% em 2017, sendo comparáveis aos times de Alto Desempenho, enquanto o oposto aconteceu com os Times de Baixo Desempenho, que tiveram 16-30% em 2016, mas em 2017 a análise os agrupou para serem entre 31-45%.

Recomendo ler o livro para obter mais informações sobre como a pesquisa foi projetada e como os autores usaram os dados. É uma excelente fonte de informação e continua explicando todo o processo de pesquisa.

Como as equipes de Engenharia de Plataforma e SRE podem ajudar a melhorar essas métricas?

Agora que estamos familiarizados com as Quatro Métricas Principais, vamos falar sobre como a Engenharia de Plataforma e SRE podem contribuir para ajudar as equipes a terem um desempenho melhor nessas métricas.

Primeiro, quando se trata de estabilidade, as métricas de "Desempenho Operacional", e todas as boas práticas mencionadas pelo Relatório DORA que contribuem para essa medição, acabam se resumindo ao que chamamos de Confiabilidade (Reliability). É senso comum que o software falha de vez em quando, algo errado vai acontecer, alguma parte do software vai se comportar mal, ou alguma máquina arbitrária vai falhar, a conectividade com a internet será perdida, uma série de coisas pode acontecer (e elas acontecerão, em Murphy devemos confiar). Confiabilidade é uma forma de medir o quão sólido é o seu sistema de monitoramento e o quão capaz você é de reconhecer que algo está errado para agir rápido, ou até mesmo para evitar a necessidade de reagir a tais cenários, preparando tarefas automatizadas que antecipam tais falhas e fazem com que todo o sistema reaja automaticamente a falhas (quase como se fosse capaz de se auto-restaurar). Esse é o objetivo da Engenharia de Confiabilidade do Site (SRE).

Em primeiro lugar, é crucial que a organização seja capaz de determinar que tipo de Operação de Desempenho é considerado "suficientemente bom" para manter, e o que é "suficientemente ruim" para agir. Isso tem que ser definido com base em como o usuário experimenta o produto: qual é a linha de base de latência que impacta na conversão, a partir de qual ponto a disponibilidade não vale a pena ser melhorada, pois provavelmente não será experimentada pelo usuário, o quanto estamos cientes da capacidade de carga para todo o sistema, para que possamos ser capazes de responder quando essa carga é excedida, e fazermos isso de maneira que o sistema seja capaz de lidar com a nova carga.

Para fazer isso, o SRE ajuda a organização a definir os Indicadores de Nível de Serviço (SLIs) que serão medidos, a fim de definir o que seria considerado "bom desempenho", e quando devemos tratá-lo como "ruim", esses limites são chamados de Objetivos de Nível de Serviço (SLOs), e eles ajudam as equipes a entender quando algo está errado. Em um artigo futuro, espero poder falar mais sobre SLIs e SLOs, bem como explorar Error Budgets e explicar mais sobre Observabilidade.

Quando se trata de Platform-Engineering, muito pode ser alcançado pelas equipes de entrega de software quando há um conjunto de ferramentas disponíveis para tornar todo o SDLC mais suave e confiável. Isso varia desde coisas simples como fornecer um Sistema de Controle de Versão e ferramentas de automação de compilação, permitir Integração Contínua e Entrega Contínua, até trazer ferramentas para o fluxo de trabalho para melhorar a segurança (shift-left on security) e automatizar toda a operação para o sistema e suas partes (gerenciamento de configuração, estratégias de rollout, circuit-breaking, etc.), idealmente abstraindo todo o "encanamento" da infraestrutura (containers, orquestração, proxies reversos, malhas de serviços, etc) para tornar todo o processo de publicação de serviços em produção mais fácil ao longo do tempo.

Não há dúvida de que teremos muito o que discutir no futuro para abordar como uma equipe de Platform-Engineering pode contribuir para criar fluxos de trabalho de entrega de software de alta performance.

No entanto, as equipes de entrega de software ainda são responsáveis por controlar a qualidade de seu software, automatizando testes e executando ferramentas de verificação de qualidade de código (padrões e métricas de análises).

Conclusão

Os quatro principais indicadores apresentados pelo livro Accelerate - Lead Time, frequência de deployment, tempo médio para restauração (MTTR) e taxa de falha de mudança - são ferramentas poderosas para avaliar a performance de equipes de software e operações e para identificar áreas de melhoria. Esses indicadores fornecem uma visão geral da entrega de software e desempenho operacional e têm sido mostrados como preditores fortes de desempenho organizacional.

Ao se concentrar nas capacidades das equipes em vez de sua maturidade em DevOps, as empresas podem obter insights valiosos sobre sua capacidade de entregar software de alta qualidade com rapidez e segurança. Com as práticas adequadas, como controle de versão, testes automatizados, integração contínua e automação de implantação, entre outras, as equipes podem melhorar esses quatro indicadores-chave e alcançar desempenho de alta qualidade.

Em resumo, a adoção de uma cultura DevOps é fundamental para as empresas que buscam alcançar um alto desempenho em seus projetos de software e operações. Com a ajuda de práticas de automação e ferramentas adequadas, as equipes podem melhorar significativamente sua capacidade de entrega de software com rapidez e segurança, mantendo altos níveis de qualidade e estabilidade. E a avaliação constante dos quatro principais indicadores de desempenho pode ajudar a garantir que as equipes estejam no caminho certo para atingir esses objetivos.

P.S.: Quero agradecer meus amigos @danielpilon e Frederico Vitorino pela revisão. Eu amo vocês.

Criando equipes de alto desempenho com a cultura DevOps

Tio Dani — Mon, 20 Mar 2023 18:16:51 +0000

For non-Portuguese speakers, there is an English version of this article here.

Você já se perguntou por que DevOps é um tópico tão confuso, cheio de misdirections e montes de tutoriais sobre todo o "Ops", como se todas as pessoas "Dev" precisassem se tornar SysAdmins para conhecer DevOps?

No meu dia-a-dia, sou responsável por uma equipe de Platform Engineering e um dos meus objetivos é enriquecer a cultura DevOps por toda a organização, o que pode ser desafiador dependendo do quanto as equipes adotam os princípios e valores que orientam essa cultura. Então, quando as pessoas tentam descobrir como aprender DevOps, geralmente encontram toneladas de materiais sobre Operações.

Quero dizer, tente se colocar no lugar de um novato e imagine como isso seria avassalador... como se já não fosse avassalador o suficiente. Tive dificuldade para aprender DevOps, e tenho mais de 20 anos de carreira na área. E, só para deixar claro, não estou dizendo que essas coisas não são valiosas para aprender. Estou apenas dizendo que DevOps não é sobre nada disso.

O que é DevOps?

Então, decidi escrever sobre DevOps, os desafios de implementar uma cultura DevOps e discutir um pouco sobre que tipo de tópicos devem ser considerados ao tentar implementar o DevOps em toda a organização.

Criar uma cultura DevOps é crucial para as organizações que desejam melhorar a velocidade, qualidade e confiabilidade da entrega de seu software. No entanto, criar essa cultura pode ser desafiador, especialmente quando os desenvolvedores não estão cientes das melhores práticas e valores que uma cultura DevOps deve trazer para a organização. Neste artigo, exploraremos os princípios e práticas-chave do DevOps e como eles podem ser aplicados para superar esses desafios.

Gene Kim e As Três Maneiras

Acredito que o conceito DevOps mais fundamental vem do The DevOps Handbook (2016, por Gene Kim, Jez Humble, Patrick Debois e John Willis). Estou falando das Três Maneiras do DevOps, apresentados em um livro anterior: The Phoenix Project (2013, de Gene Kim, Kevin Behr e George Spafford), mas melhores explorados no livro posterior.

A Primeira Maneira trata de criar fluxo, desde o desenvolvimento até a operação e entrega. Isso significa suavizar todo o processo pelo qual o código sai da máquina do desenvolvedor e entra em produção, aplicando quaisquer verificações necessárias e avaliando como ele se adequa para se tornar uma nova versão funcional do produto.

A Segunda Maneira trata de criar ciclos de feedback para que todos possam aprender e melhorar com suas experiências. Como está funcionando este código? Há novos bugs ou problemas em relação a comportamentos inesperados? Quanto tempo leva para corrigi-los? Como o usuário está experimentando o produto? O que mais podemos aprender com o produto que poderia nos dar uma visão do que mudanças devemos fazer para torná-lo melhor?

Por fim, a Terceira Maneira trata de criar uma cultura de experimentação e aprendizado, celebrando sucessos e falhas e criando um ambiente seguro onde as pessoas se sintam à vontade para correr riscos e experimentar coisas novas.

Em resumo, se eu tivesse que dar uma resposta curta sobre o que é a cultura DevOps, eu alegremente diria que é uma organização que valoriza todas as Três Maneiras e se deixa ser guiada por eles.

Criando equipes de alto desempenho

Mas se você precisa de uma abordagem mais tática para aprender como implementar uma cultura DevOps, eu também posso mencionar um outro livro do Gene Kim: Accelerate - A Ciência para Desenvolvimento de Software Ágil e DevOps: Construindo e Escalando Organizações Tecnológicas de Alto Desempenho (2018, por Nicole Forsgren, Ph.D., Jez Humble e Gene Kim). O livro elabora sobre como Kim, Humble e a Dra. Forsgren trabalharam juntos para conduzir a pesquisa anual para o Relatório Estado de DevOps da Puppet e a que conclusões chegaram com os dados que obtiveram. É uma ode a todas as Boas Práticas sobre as quais falamos nas últimas décadas, mas agora com dados concretos, metodologia de pesquisa e ciência.

De acordo com o livro, uma cultura DevOps é fundamental para organizações tecnológicas de alto desempenho. É caracterizada por uma compreensão compartilhada dos objetivos e metas da organização, bem como uma disposição para experimentar e aprender com os fracassos. Os líderes desempenham um papel crítico na criação de uma cultura DevOps, criando um ambiente seguro onde a experimentação e a aprendizagem são incentivadas, e promovendo uma cultura de colaboração e responsabilidade compartilhada.

Quando as pessoas desenvolvedoras não têm conhecimento das boas práticas, podem criar gargalos e atrasos no processo DevOps, atrasar a entrega e causar frustração para todos os envolvidos. Para abordar isso, as organizações devem se concentrar em educar as pessoas sobre as melhores práticas de DevOps e por que são importantes. Aqui estão algumas das melhores práticas identificadas por Kim e seus colegas:

Integração Contínua: Os desenvolvedores devem integrar seu código frequentemente em um repositório compartilhado e usar testes automatizados para identificar erros cedo.
Entrega Contínua: As mudanças de código devem ser construídas, testadas e implantadas automaticamente na produção.
Monitoramento e Logs: As organizações devem ter sistemas automatizados de monitoramento e logs para identificar e responder rapidamente aos problemas.
Infraestrutura como Código: A infraestrutura deve ser tratada como código e gerenciada através de sistemas de controle de versão para que as mudanças possam ser facilmente rastreadas e gerenciadas.
Colaboração: As equipes devem trabalhar em colaboração e compartilhar a responsabilidade pela entrega e suporte de seus sistemas.

O Surgimento das Equipes de Engenharia de Plataforma

Outra tendência-chave em DevOps é a ascensão das equipes de Engenharia de Plataforma. Essas equipes se concentram na construção e manutenção da infraestrutura e plataformas subjacentes que permitem que as equipes de entrega de software trabalhem de maneira mais eficiente e eficaz. Elas criam padronização e automação em torno dos componentes de infraestrutura principais, como bancos de dados e redes, para que as equipes de desenvolvimento possam se concentrar na construção de aplicativos em vez de se preocupar com a infraestrutura subjacente. Ao fornecer uma base sólida para as equipes de DevOps trabalharem, as equipes de Engenharia de Plataforma ajudam a melhorar a velocidade, qualidade e confiabilidade da entrega de software.

Considere por um minuto o que qualquer pessoa desenvolvedora de backend tem que se preocupar ao criar um serviço para uma API REST e imagine toda o ruído relacionado a DevOps adicionado a isso para tornar esse serviço operacional. É esse o problema que uma equipe de Engenharia de Plataforma se propõe a resolver. Eles cuidam de todo o "encanamento" (citando Armon Dadgar, co-fundador e CTO da Hashicorp) em relação a rede, automação, segurança, balanceamento de carga, serviços de cache, proxies reversos, firewalls, serviços em nuvem, serviços de observabilidade (logs, métricas, rastreamento) e os disponibilizam como serviços para as pessoas Engenheiras de Software, para que elas não precisem entender tudo isso (contêineres, Kubernetes, malha de serviço, tudo o mais) para levar seus serviços à produção, aproveitando toda a estabilidade, segurança e disponibilidade entregues pela plataforma.

SRE como Motor para Ciclos de Feedback

Site Reliability Engineering (SRE) é outra metodologia que combina engenharia de software e operações para criar sistemas de software altamente escaláveis e confiáveis. O SRE enfatiza a importância de automatizar tarefas repetitivas, reduzir o impacto das falhas e projetar sistemas para resiliência e escalabilidade. As equipes de SRE trabalham em estreita colaboração com as equipes de desenvolvimento para garantir que as aplicações sejam projetadas para serem altamente disponíveis e que possam se recuperar rapidamente de falhas.

Além disso, o SRE se baseia no fato de que a Confiabilidade pode ser projetada. Quero dizer, como você pode tornar um serviço mais confiável? Bem, o SRE trabalha para entender quais indicadores devem ser usados para definir a confiabilidade (SLIs), como tempo de resposta ou taxas de erro. Então, a equipe, juntamente com os especialistas em negócios e partes interessadas, tenta descobrir qual é o nível aceitável de falha para esses indicadores (SLOs), ou seja, qual é o ponto de inflexão em que todos concordam que não vale a pena tentar evitar falhas (talvez porque isso torne muito caro ou porque o próprio usuário não notará nenhuma melhoria em sua experiência). Por fim, os Orçamentos de Erro têm um papel a cumprir, ajudando as equipes a saber quando parar de implantar e começar a revisar seus problemas por um tempo. A Observabilidade também está no cerne de tudo isso, usando ferramentas para medir, monitorar e alertar o comportamento inesperado do serviço.

Conclusão

Em resumo, criar uma cultura DevOps é fundamental para organizações que desejam fornecer software de alta qualidade com rapidez e confiabilidade. No entanto, criar essa cultura pode ser um desafio, principalmente quando os desenvolvedores não estão cientes das melhores práticas e valores que uma cultura DevOps deve trazer para a organização. Ao educar os desenvolvedores sobre as melhores práticas de DevOps e incentivar uma cultura de experimentação e aprendizado, as organizações podem superar esses desafios e criar equipes de entrega de software de alto desempenho. O surgimento das equipes de Engenharia de Plataforma e SRE também pode ajudar a melhorar a eficiência e a confiabilidade dos sistemas de software.