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: 
Infraestrutura
Aplicação
SpringBoot (https://spring.io/)


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:

management:
  metrics:
    export:
      influx:
        db: db_dev (aqui é a database onde serão persistidas as métricas do Actuator)
        uri: http://127.0.0.1:8086 (coloque aqui a URL do InfluxDB do seu ambiente)
        step: 1m (intervalo de envio)
        enabled: true


Classe de exemplo de métrica customizada:
package org.athome.example.metrics;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;

import org.athome.example.model.Order;
import io.micrometer.core.instrument.Counter;
import io.micrometer.core.instrument.MeterRegistry;

@Component
public class OrdersCustomMetrics {

@Autowired
private MeterRegistry registry;
public void CounterOrder(Order order, String reason) {
Counter.builder("Orders")
  .description("counter of orders")
  .tag("orderType", order.getOrder.Type())
  .tag("reason", reason)
  .tag("Id", order.getOrderId())
  .register(registry)
  .increment(1);
}
}





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







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.