Participação no ThreadCast em Maio
Falamos sobre os posts:
https://helkmut.blogspot.com/2021/03/buscando-e-retendo-talentos-sem-o-hype.html
https://helkmut.blogspot.com/2020/04/devops-quando-as-coisas-nao-acontecem.html
quarta-feira, 26 de maio de 2021
ThreadCast SouthSystem - DevOps - Quando as coisas não acontecem
https://helkmut.blogspot.com/2021/03/buscando-e-retendo-talentos-sem-o-hype.html
https://helkmut.blogspot.com/2020/04/devops-quando-as-coisas-nao-acontecem.html
sexta-feira, 12 de março de 2021
Buscando e retendo talentos sem o hype da tecnologia
Como engajar novos e atuais colaboradores da área de tecnologia se o negócio não requer tecnologias de ponta (Hype)? Esse é um dos grandes desafios de muitas empresas e vamos falar mais sobre ele.
Aquecimento do mercado de trabalho de TI
Com as mudanças geradas nos modelos de negócio do mundo todo, em quase todos os segmentos, muitas empresas voltaram seus olhos para a TI. Sejam lojas que precisaram voltar a sua estratégia para o e-commerce (uma vez que os negócios físicos ficaram impedidos de abrir) ou mesmo indústrias que, em tempos de contenção, precisaram reduzir seus custos operacionais.
Este tipo de movimento do mercado em busca de tecnologias também gera outro efeito colateral: o aquecimento de oportunidades e posições de profissionais de diversas áreas da Tecnologia da Informação (TI), às vezes os mesmos profissionais que foram dispensados na primeira semana de pandemia, onde não se sabia muito bem qual estratégia traçar.
Brotam de um lado recrutadores com vagas cheias de desafios e, do outro lado, crescem DevOps Engineers, Site Reliability Engineering (SRE) e muitas outras nomenclaturas que pouco se sabe na prática quando “a mão vai para a graxa”.
Mas qual a origem destas nomenclaturas? Por que todos os dias temos um novo nome para atuar em uma nova tecnologia? Sim, além da necessidade de agilidade do mercado temos também a ansiedade pelo uso do que está em evidência.
Ligação entre mercado e plataformas self-service está na formação de novos recursos
Este anseio pelo novo, em nosso entendimento, é também obra de um processo sistêmico das empresas de consultoria e startups onde, seja por programa de formação ou requisito no programa de recrutamento, essas tecnologias são apresentadas como o melhor, e qualquer coisa mais antiga “é ruim”, “é legado”, ou seja, não presta.
Veja a referência do Gartner sobre as 10 (dez) principais tendências (https://www.gartner.com/pt-br/conferences/la/infrastructure-operations-cloud-brazil/gartner-insights/top-10-trends-impacting-io-2020), onde há exatamente um direcionamento para plataformas self-service.
plataformas self-service : Do ponto de vista prático é a composição de diversas stacks, sejam open source ou enterprise, nos modelos IaaS (Infrastructure as a Service) ou SaaS (Software as a Service). Tais stacks são coordenadas para proporcionar um ciclo completo, desde a esteira de publicação até o delivery em um ambiente estável, confiável e escalável.
Em organizações que não estão abertas a mudança cultural, para que seus produtos sejam desenvolvidos e ocorra uma tentativa de redução de rotatividade (seja de consultoria de terceiros ou mão de obra própria), requisitam a construção de ambientes mais complexos, com tecnologias mais atuais, sem que de fato gere vantagem para o negócio.
Criam-se plataformas e times focados em tecnologias sem uma necessidade, estes times ao longo do tempo se desmotivam pela frustração de falta de propósito.
Plataforma Self-Service : Quais as vantagens e desvantagens de negócio
Mas qual necessidade? A necessidade de atender o “time to market” de inovações para fazer frente a ambientes cada vez mais concorridos de mercado, gerando agilidade, qualidade nas aplicações, disponibilidade e confiabilidade do ambiente ao ciclo de rollout.
Mas o que envolve este ciclo? É o ciclo de construção, testes, publicação e sustentação de serviços, pois estamos inseridos em ambientes que dependem da TI para que sejam competitivos em um momento tão dinâmico como este. Veja, estes são ambientes em que precisam se reinventar comercialmente ou aprimorar a velocidade e qualidade dos serviços e produtos oferecidos.
Se a organização está inserida em um mercado não-volátil, seguindo estável mesmo em períodos turbulentos, antes de montar uma plataforma e decidir usar determinadas tecnologias ou metodologias, é primordial avaliar se todo este investimento faz sentido.
A ausência de demanda ou necessidade geram reflexos como o método “go horse”, retornando velhos hábitos, como forma de exceção. Neste caso começam as intervenções manuais, promoção de novas releases que não seguem completamente o fluxo de publicação e, no pior dos casos, estas exceções se tornam o padrão, pois ao longo do tempo para a camada estratégica da empresa perde-se o sentido de custo de operação, solicitando “skips” no processo, geralmente burlando ou negligenciando os testes automatizados ou provisionamentos de infraestrutura controlados.
O time e gestão precisam ver valor no fluxo (valor para o negócio) e, caso pensem em abrir mão de algum ponto, precisam estar cientes de qual valor também estarão abrindo mão, este processo é chamado de Gestão de Risco.
Veja que até aqui não citamos um tipo específico de solução, pois isto varia de acordo com a realidade e complexidade do ambiente alvo. Lembramos da máxima de que nem sempre precisamos de um Kubernetes para termos um ambiente saudável, mas algo a nós não é discutível, processos como garantia de estado, fluxo de versionamento, testes automatizados, rastreabilidade e observabilidade.
Mas como gerar engajamento retendo e obtendo novos talentos para seu time se não pode oferecer estes desafios e tecnologias?
Primeiro precisamos identificar em qual cenário a organização alvo faz parte: ou o mercado onde está inserida não é tão dinâmico, ou a organização está tão distante de inovações tecnológicas e atuais de engenharia de software que opera com sistemas ainda criados antes de 2010 (os famosos “legados”), com processo de publicação manual, etc. Para cada um destes cenários, precisamos descobrir a resposta da pergunta: ‘o que gera engajamento para novos talentos, ou retêm os existentes se a organização não possui tais desafios?’, mas as mudanças serão obtidas em momentos diferentes, pois serão mudanças culturais muito grandes e isto leva tempo, mais tempo do que sua carreira possa esperar.
Um ponto importante em nosso ponto de vista é que em ambos os cenários não podemos e nem devemos vislumbrar um cenário saindo de um datacenter on-premise e indo dentro de 1 ano para uma cloud híbrida com plataforma self-service, onde todos processos de testes e rollout de ambientes sejam automatizados. Isto demanda esforço, tempo, disciplina e, principalmente, a priorização do time estratégico da empresa. Sem isso, talentos procurarão outros desafios, e cada vez mais o time A virará o time C em vários aspectos, mantendo velhos hábitos.
Observe que estamos olhando do ponto de vista ainda de carreira e do colaborador, todas as práticas necessárias não partem da camada operacional e tática, por mais dinheiro e recursos que sua organização possua, nem sempre é de dinheiro que estamos falando, mas de outros valores e requisitos. Vejam alguns fatores comuns que mapeamos:
Fatores que geram engajamento
- Perspectiva de evolução (profissional, pessoal e financeira)
- Desafios técnicos alinhados com a carreira
- Autonomia para fazer mudanças
- Flexibilidade de horário de trabalho
- Possibilidade de trabalho remoto
- Conciliação com a vida pessoal, qualidade de vida
- Trabalhar com pessoas qualificadas
- Liderança servidora que escuta atentamente
- Coach Sessions e 101s
- Guilds, Hackathons, Dojos, sessions de LTs
- Cultura de inovação e de Deep Dive
- PTO (Paid Time Off)
- Hosting de meetups
- Suporte a participação de projetos Open source
- Pub Crawls com o time
- Acreditar na iniciativa que se está trabalhando, e não só o faz por motivos meramente financeiros ou de tendência
Fatores que podem desmotivar
- Falsas promessas de crescimento
- Inflexibilidade
- Problemas de ordem Política / Segurança psicológica
- Não propiciar mudanças
- Falta de propósito
- Escritórios, cubículos ou ambientes no-open-space
- Muitas reuniões, lidar com questões administrativas e comerciais
- Forçar um modelo de contratação (CLT, PJ, etc.)
Aqui não elencamos quais fatores são mais ou menos importantes, o fato de serem citados quando questionados ‘Quais os fatores que lhe geram engajamento em projetos em que atuou/atua? Quais fatores já os fizeram sair de algum projeto?’ nos mostram que, se estão presentes, em algum momento foram relevantes em uma tomada de decisão do colaborador, seja para ingressar em um projeto ou para deixá-lo.
Ainda não respondemos a pergunta inicial: “O que gera engajamento para novos talentos, ou retêm os existentes se a organização não possui tais desafios?”
O primordial é não apresentar falsas promessas ou falsos desafios, isso frustra mais do que a sinceridade. Só diga que está com o desafio de transformação digital e a implantação de novas tecnologias se de fato tem uma movimentação clara da direção para isto. Caso não tenha, seja verdadeiro, não dê falsas esperanças, pois este novo recurso ou quem está pensando em sair não permanecerá muito tempo.
Se a organização não tem o apoio estratégico, seja honesto e mude o discurso. Diga que o desafio, seja com o conhecimento do time ou de quem se quer contratar, é experimentar novas práticas de engenharia de software (e esteja aberto a isto), utilizá-la em projetos pilotos para mostrar aos diretores resultados com essa nova abordagem. Que isto demandará tempo, que muitas vezes não terão apoio e o risco deve ser compartilhado, mas nunca omitido. Estará dando a oportunidade de ambos os lados entrarem em acordo sabendo o jogo que está sendo jogado.
Tudo isto pode mostrar alternativas e modificações de planos, sem frustrações, de maneira flexível, sem sonhos, com decisões mais reais, baseadas em vantagens para o negócio, e não baseadas em tendências. O time pode decidir em conjunto que, a curto prazo, talvez não seja um Kubernetes que se precisa, e nem o uso de microsserviços se o monolito ou a estrutura modular atende bem.
Concluímos que as organizações que estão inseridas nestes cenários, ou ainda empresas de outsourcing e consultoria, que cometem equívocos ao usar alguma destas práticas dificilmente obterão êxito no preenchimento de todas as suas posições em aberto. Entretanto, aumentará a imagem de transparência e, por consequência, a retenção de talentos.
Também é necessário lembrar que qualquer tecnologia ou metodologia nova deve ser considerada se houver uma clara vantagem de retorno para o negócio. Não fazer o uso sem sentido ou por tendência. Procurar fazer estudos sobre as vantagens e desvantagens de cada implantação, uma vez que escolhas ruins sempre levarão ao prejuízo.
Busque consultorias, parceiros que estão dispostos a crescer com o seu negócio e apresentar soluções alinhadas com suas estratégias: que nem sempre lhe digam o que estás esperando ouvir, não lhe digam sim somente para alocar mais recursos e ter mais lucros, mas buscar o lucro em conjunto com o resultado da sua organização.
As pessoas, em sua maioria, se motivam e se engajam mais pelo resultado (de negócio) do seu trabalho, não apenas por usar uma tecnologia que, ao final, gerará caos tecnológico pela complexidade sem efetividade ou retorno ao negócio.
Indicações de leitura
Fontes
Sobre os autores
* Gabriel Prestes, formado em Gestão da Tecnologia da Informação, DevOps Engineer da ilegra, entusiasta de carros antigos e apaixonado por VW Santana, vulgo “lasanheiro”.
* Tales Viegas, formado em Ciência da Computação, Arquiteto de Software na ilegra, tem mais anos trabalhando com informática do que muitos dos seus colegas tem de vida, viciado em Marvel, viagens e sofrimentos futebolísticos.
Conteúdo também disponível em : https://ilegra.com/blog/buscando-e-retendo-talentos-sem-o-hype-da-tecnologia/
Agradecimentos : Inácio Klassmann, Jackson Oliveira, Diego Pacheco, Isaías Prestes, Gediel Luchetta e César Mesquita.
domingo, 26 de abril de 2020
DevOps, quando as coisas não acontecem
'DevOps - quando as coisas não acontecem’ conta em forma de narrativa como é difícil mudar a cultura de organizações, lições aprendidas e quando deves seguir adiante pelo bem maior, sua carreira.
Aos que leem a publicação, não é uma publicação de caso de sucesso. Estamos em tempos onde todos querem contar uma história de sucesso, onde tudo dá certo e afeta positivamente a todos com valor para o negócio. Bacana! Mas não podemos esquecer que o PPT aceita tudo quando vira uma apresentação bonita. Demonstrações onde tudo é preparado e maquiado para não apresentar débitos técnicos e códigos chumbados.
Meio pessimista, não? A publicação não é técnica, ainda que o técnico e a cultura tenham sido os fatores que nos levaram ao abandono no final.
Começando com a história do Gabriel (isso, estamos nos citando em terceira pessoa), não mencionando aqui todo histórico desde que nasceu da barriga da sua mãe, mas sim, o que o motivou a ingressar na empresa do caso em questão.
Já viram aquelas vagas que utilizam palavras chamativas como ‘desafio’, ‘squads’, ‘métodos ágeis’ e ‘ambiente dinâmico’? Elas são ótimas e uma delas chamou a atenção dele.
Gabriel já tinha uma carreira sólida, estabilidade financeira, trabalhava em projetos de bons clientes em uma empresa de consultoria, tinha contas a pagar por gastar demais, logo tornava-se mercenário e sedento por qualquer cinco pratas a mais no valor hora.
A vaga em questão pagava melhor e como atrativo tinha palavras no anúncio como as citadas no parágrafo anterior. Ele contatou o recrutador que marcou uma entrevista com o cliente, o arquiteto principal do projeto. Entusiasmado, mas com medo de julgamentos, foi a tal entrevista temeroso por perguntas técnicas profundas. As abordagens foram vagas, nada técnico, o que deixou o Gabriel apreensivo. A empresa era do ramo financeiro, de grande porte e isso não causou receio. Ao perguntar sobre o projeto recebeu como resposta a palavra “plataforma”. Palavra que foi sondada com: “uma plataforma de um time SRE (https://landing.google.com/sre/)?” E obteve resposta incerta “É, isso aí!”.
Aqui vai a primeira lição aprendida: Para qualquer projeto com palavras de impacto, sonde os seus publicadores para saber se de fato as entendem, isso lhe mostrará com um perfil interessado e pode lhe livrar de projetos sem dados, sem objetivos e repleto de palavras bonitas que na prática não se aplicam.
Deixamos sugestões para mitigar essas “armadilhas”:
- O que vocês entendem por time de SRE?
- Quais são as práticas de engenharia que já estão disseminadas nos times de desenvolvimento?
- O que já existe na plataforma atual e qual é o roadmap de curto, médio e longo prazo?
- Quantas pessoas fazem parte do time SRE e quais são os perfis delas?
- A empresa tem uma visão de produto para tratar a plataforma?
Muitas empresas brasileiras tentam aplicar conceitos e inovações de TI (tecnologia da informação) sem saber muito bem o que estão fazendo e o que aqueles conceitos realmente significam.
Começa aí então a frustração generalizada dos profissionais em cascata que acreditaram que aquilo - agora - seria “diferente”.
Segunda lição aprendida: Normalmente recrutadores desconhecem a realidade do projeto e farão a vaga parecer ser mais desafiadora do que na verdade é, afinal, o trabalho deles é recrutar pessoas.
Ao Ingressar no projeto, Gabriel entendeu que a vaga era para atuar dando play em job de Jenkins (https://jenkins.io/), e a plataforma ao que o arquiteto se referia era o nome do projeto em si e não o conceito de plataforma em SRE.
O cenário visualmente era agradável, um prédio parecido com garagem, puffs bacanas, mas todo e qualquer processo técnico era feito por GMUD, engessado. Um servidor novo e uma tecnologia nova eram coisas de meses de espera. Distante do conceito de plataforma self-service que um time de SRE deve buscar e implementar.
Em menos de um mês Gabriel queria retornar ao seu emprego antigo, tentou outras oportunidades, enfim, bateu o desespero. Foi quando conheceu Inácio, que já estava há mais tempo na empresa.
Vamos fazer uma pausa e contar a história do Inácio, da sua chegada a empresa ao momento dos acontecimentos desta publicação.
Este projeto de transformação digital necessitava de alguém que pudesse contribuir com experiência em soluções de software, estruturação de times e também ter experiência com tecnologias mais atuais. Então o Inácio foi chamado para atuar nesta transformação.
Inicialmente foi muito produtivo, os times de desenvolvimento foram reestruturados, a arquitetura e algumas tecnologias foram definidas.
A primeira release foi projetada e o software começou a ser desenvolvido. Estava tudo indo muito bem, Inácio tinha alinhamento com o time do cliente. Ambos com a mesma expectativa. Tinham o aval e a abertura da empresa para implementar as mudanças e realizar a construção de um software com escalabilidade, observabilidade e sustentabilidade.
Até que chegou o momento de construir a arquitetura e implementar as tecnologias. Então foi onde Inácio e o time foram surpreendidos, pois esbarraram na dificuldade de que aquela liberdade era ilusória.
Existiam setores dentro da empresa que não estavam efetivamente trabalhando para fazer a transformação digital (sendo um dos aspectos colocar o cliente no centro). O que realmente faziam era trabalharem para manterem os seus empregos. Usavam seus cargos importantes para garantir que não mudassem as tecnologias, mantendo-se como tutores e influenciadores dos seus silos.
Gabriel conhecia Inácio de vista, de um grupo de arquitetos os quais mantinham uma comunidade chamada ArqTI (http://arqti.org/). Ambos estreitaram contatos quando o arquiteto principal pediu para que ele, Gabriel, fizesse a análise de um problema que se passava em um projeto de outra unidade da organização, no caso, a unidade em que Inácio trabalhava. Eram somente algumas horas e tinha que ser superficial e objetivo na tal análise. Gabriel viu no momento, ao conhecer o PO (product owner) a oportunidade de mudar o cenário em que se encontrava, pois este PO era alguém que tinha sangue nos olhos e dedicação pelo que fazia, ainda que as coisas não acontecessem na velocidade e qualidade que ele (product owner) desejava. Então resta citar a terceira lição.
Terceira lição aprendida: Fique próximo de pessoas que fazem a diferença, e dadas as oportunidades, faça o seu melhor sempre, independente da motivação atual. Nos inspiramos no dia a dia em uma entrevista do Waldez Ludwig (http://www.ludwig.com.br/), a qual menciona um jogador de futebol em começo de carreira: ele não faz gol contra quando as coisas não estão bem, é aí que ele marca mais gols e joga melhor - com o objetivo claro de que um clube grande o encontre.
Gabriel fez o seu melhor no relatório, e o tempo que passou nesta unidade (02 dias) usou para estreitar seus laços interpessoais e levantar dores e demandas que ninguém queria ouvir. As colocou em uma lista de demandas.
Quarta lição aprendida: Seja gentil e educado com todos. Criar boas relações aumentam suas possibilidades futuras. E veja: deves ser justo, sendo educado e gentil do porteiro que lhe atende sorrindo até o diretor da empresa. Isto lhe permitirá encontrar possibilidades e demandas que algumas pessoas não compartilharão com o comercial da empresa, mas com o técnico que entende o problema.
Neste ponto entra o Inácio novamente, o Gabriel sempre fala que esse cara é 10!!! Inácio ajudou na montagem da lista de demandas e como já estava há mais tempo na organização tinha maior influência para que estes pontos, que eram deveras relevantes, chegassem a quem realmente precisava, e chegou! Chegou a uma gerente que entendia do negócio como poucos ali. Sua postura? Ímpar. Ela priorizou as demandas e os alocou focados para esta unidade. De largados e players de Jenkins passaram a recursos vitais para que o lançamento do novo produto do cliente fosse realidade, Inácio e Gabriel, o time de DevOps, como falavam.
Agora a situação dava uma reviravolta para Gabriel na empresa: eles podiam implementar tecnologias inovadoras. A experiência do Inácio na arquitetura de software e a bagagem que Gabriel trazia da área de operação não tinha como dar errado.
No meio do percurso constataram que as demandas aumentavam, e somente dois não seriam suficientes para atender o prazo desejado. Então lhes possibilitaram a alocação de mais um recurso e assim o fizeram, eles chamaram um colega, em especial amigo, para trabalharem juntos no projeto.
A entrega foi feita de exatamente todos os itens e, uma migração feita completamente dentro da expectativa do cliente.
Então o leitor deve se perguntar: mas não é uma história de DevOps que não aconteceu? Sim, e foi depois da entrega que as coisas começaram a dar errado.
A sustentação do ambiente deve ser do time do produto, certo? Mas esse não é um conto de fadas. Muitas organizações que dizem estar em processo, ou já fizeram a transformação digital, mantém times de NOC que são responsáveis em sustentar e serem plantões de produtos e tecnologias que desconhecem.
Foi aí que começam a ligar para o Gabriel, para o Inácio, pedindo que atendesse e resolvessem "a arte" instaurada por amor a camisa. Começaram também a pressionar eles por usarem tecnologias que não eram homologadas pela organização. Uma lista foi criada de tecnologias suportadas por profissionais que desconheciam tools de DevOps. Veja, isso não limita o conceito de inovação?!
Inácio e Gabriel colocaram-se à disposição de sustentar o produto, a opção foi desconsiderada pela gestão e somente um repasse foi feito aos sysadmins da empresa (NOC) que estavam operando ainda monólitos.
Vários fatores os levaram a desistir de uma luta cultural:
- Assédio por ter que responder por escolhas tecnológicas inovadoras;
- Responsabilidade por soluções que não eram enterprise;
- Por ter que seguir políticas de segurança de 1990;
- Por entrar em um processo de GMUDs;
- A obrigação de manter um modelo on-premises onde servidores demoravam 01 mês para ficarem prontos;
- Medo de retornar ao projeto e dar play em Jenkins.
E aí vai a quinta e última lição!
Quinta lição aprendida: Aceite desafios e lutas que pode vencer enquanto elas não lhe fazem menor, enquanto elas não lhe trancam a processos legados. Seja o dono da sua carreira e faça dela o ponto mais importante. Busque objetivos que te façam sentido e principalmente aprenda a ver o momento de seguir em diante, ou seja, pular fora. Muitas vezes nos deparamos em situações onde algumas pessoas da organização possuem interesses diferentes, ou seja, metas distintas que não contribuem para o objetivo em comum da empresa. Empresa que deveria, a seu turno, ser focada em seu consumidor final. Infelizmente existem coisas que não podem ser mudadas de baixo para cima. É necessário que exista uma força de cima para baixo também para fazer a transformação acontecer.
Quando identificaram a ausência deste cenário, foi quando Inácio e Gabriel perceberam que estavam perdendo tempo naquele lugar, foi então que optaram por procurar algo que agregasse mais valor em suas carreiras. Tudo então virou passado. Estava aberto o horizonte para novos e positivos desafios profissionais.
Fontes e Citações
SRE - https://landing.google.com/sre/
CICD Jenkins - https://jenkins.io/
ArqTI - http://arqti.org/
Waldez Ludwig - http://www.ludwig.com.br/
Agradecimentos
Felipe Santos, nosso amigo, e ainda que hoje ele more distante faremos um bom churrasco juntos.
Gediel Luchetta, pela disponibilidade, sugestões e revisão da publicação.
Sara Gabriela Dhein, pela disponibilidade e revisão da publicação.
Isaías Prestes, pela disponibilidade, sugestões e revisão da publicação.
Sobre os autores
* Gabriel Prestes, formado em Gestão da Tecnologia da Informação, DevOps Engineer da ilegra, é um entusiasta de carros antigos que cultiva em sua garagem um Gurgel Supermini funcionando.
* Inácio Klassmann, Head of strategy and innovation na South System, homem de 2 paixões, sua moto e sua família.
terça-feira, 7 de janeiro de 2020
SpringBoot - Métricas customizadas com Micrometer
A história:
Com o uso mais frequente de microsserviços, e a arquitetura baseada em eventos (mensageria), métricas de aplicações são importantes para que saibamos status básico dos componentes. Tais componentes, por vezes, encontram-se distribuídos em vários clusters, orquestrados em contêineres, que dificultam e alteram o modelo tradicional de monitoramento de indicadores operacionais das aplicações.
Assim, perguntamos a seguir : Métricas básicas de aplicações, tais como threads, requests, tempo de resposta, são suficiente para atender a necessidade de negócio? Esse é o tema que vamos aprofundar, mostrando como gerar métricas customizadas em uma aplicação SpringBoot 2.x.
O monitoramento básico de componentes computacionais e de aplicação não são suficientes, e não será o nosso alvo, reconhecemos que alguns indicadores ainda são relevantes ao time de infraestrutura, mas apresentar ao business owner (BO) tais indicadores não agregam valor e são tratados como comodity.
Necessidade:
Fazemos parte de um time site reliability engineer (SRE), o qual orienta soluções aderentes aos times de desenvolvimento, e a demanda por nós recebida foi de apresentarmos dashboards de negócio com o ciclo do pedido, um monitoramento capaz de produzir alertas quando um determinado pedido não evoluísse de estado em um determinado intervalo de tempo.
Não podemos considerar sempre a criação de novos modelos, ou como se diz reinventar a roda, até mesmo pela importância de estabelecermos e após mantermos um padrão independente da stack de telemetria/monitoramento em uso. Com isto, ao decorrer do tempo observamos que em um módulo de negócio dos quais atendemos, com diversos microsserviços, uma stack de telemetria se destacava, pelo uso de um padrão como procurávamos, sua estabilidade e simplicidade de implementação.
Deixamos aqui os méritos ao Marco Pokorski Stefani (https://www.linkedin.com/in/marcops) que implantou o padrão, ao Douglas Rossi (https://www.linkedin.com/in/douglasrossi) o qual estendeu em métricas customizadas de negócio, e ao César Mesquita (https://www.linkedin.com/in/cmesquita00) responsável pela concepção de arquitetura de telemetria do módulo.
Stack:
Componentes:
Fluxo de funcionamento:
Utilizamos soluções de continuous integration (CI), continuous deployment (CD) do cloud provider[1], onde durante o processo de publicação descritores, testes e dependências são satisfeitas em uma esteira[2]. Veja que em um ambiente distribuído não podemos concentrar o monitoramento no modelo tradicional, pois hora estaremos com 1 réplica da aplicação ativa, e outrora com mais, valores que são controlados pelo horizontal pod autoscaler (HPA)[3].
Dessa forma, cada réplica enviará suas métricas ao InfluxDB[4], e por fim estes dados serão consolidados com o uso do Grafana[5], este responsável pela apresentação, agregação e produção de alertas para os times.
Atualmente para envio de algumas métricas ainda não customizadas diretamente na aplicação utilizamos coletores externos que coletam os dados de origens distintas, tais como message broker, data lakes. Tais coletores implementam a mesma stack citada: Segue exemplo de funcionamento do e gatilhos para os alertas:
O coletor analisa um grupo de dados, em que para cada evento há uma atualização de compra. Para cada compra será incrementado o contador do estado atual correspondente. Quando o coletor analisar todas as atualizações de compras, fará o download de mais X atualizações de compras.
No Grafana alertas são gerados quando:
- O número de pedidos que estão ou já estiveram no estado “solicitado” for menor do que o número de pedidos que estão ou já estiveram no estado “computado”;
- O número de pedidos que estão ou já estiveram no estado “embrulhado” for menor do que o número de pedidos que estão ou já estiveram no estado “pago”;
- A somatória de pedidos que estão ou já estiveram no estado “pago” e “embrulhado” for menor que o número de pedidos que estão ou já estiveram no estado “disponível”;
- O número de pedidos que estão ou já estiveram no estado “disponível” for menor que o número de pedidos que estão ou já estiveram no estado “entregue”.
Implementação:
Iniciamos pela descrição breve do Actuator, uma simples que satisfaz o que precisamos aqui é de uma publicação no Medium (https://medium.com/projuristech/monitorando-uma-aplica%C3%A7%C3%A3o-spring-boot-2-x-cef826ae793c) que segue:
“É uma biblioteca do próprio Spring para coletar métricas, entender o tráfego e o estado da aplicação.”
Assim como o Actuator, o envio de métricas utilizando o Micrometer é gerenciado pelo SpringBoot, logo não precisamos nos preocupar com dependências para métricas padrões do Actuator.
Para implantarmos o Actuator devemos adicionar a dependência ‘spring-boot-starter-actuator’ ao projeto. Seja ele Maven ou Grandle. Após isto inclua no bootstrap, config-server o seguinte em seu YAML:
Properties config-server ou bootstrap:
Classe de exemplo de métrica customizada:
O uso da classe deve ser realizado por interação na implementação dos estados do pedido. Com isto, poderemos gerar alertas de total de pedidos e pedidos inválidos por razões de negócio - quanto se alguma ordem não mudar de estado em X tempo.
O framework também permite o uso de outros tipos de métricas, tais como gauge, histogram, entre outros. Permite também enviar métricas para outras soluções como Elastic, Datadog, Dynatrace. O importante para métricas customizadas é saber o tipo de dado e tipo de métrica que irá expor.
Para maiores detalhes acesse: https://micrometer.io/docs/concepts#_meters
Conclusão e atualidade:
Conforme citado anteriormente, nem todas as aplicações geram métricas customizadas em tempo de execução. Por isto, ainda não conseguimos receber as alterações de estados no tempo em que ocorrem, precisando assim fazer uso de outros coletores com certo delay (atraso), consultando também dados analíticos, e observando a interação de eventos em um message broker.
Ainda assim o product owner (PO) responsável pelos módulos está vinculando às novas entregas do produto stories que incluem a implementação de métricas customizadas como critério de aceitação para que não sejam necessários futuramente os coletores.
Fontes
- https://medium.com/projuristech/monitorando-uma-aplicação-spring-boot-2-x-cef826ae793c
- https://medium.com/projuristech/monitorando-uma-aplica%C3%A7%C3%A3o-spring-boot-2-x-fc939257db8e?
- https://www.baeldung.com/micrometer
- https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
Sobre os autores
* Gabriel Prestes, formado em Gestão da Tecnologia da Informação, DevOps Engineer da ilegra, é um entusiasta de carros antigos que cultiva em sua garagem um Gurgel Supermini funcionando.
* Thamires Tissot, estudante de Analise e Desenvolvimento de Sistemas, Desenvolvedora na ilegra e ceramista nas horas vagas.
Assinar:
Postagens (Atom)