DEV Community: Gabriel Lopes

DevOps além das ferramentas

Gabriel Lopes — Tue, 19 Dec 2023 13:37:32 +0000

E lá vamos nós…

Aqui quero tentar dar a perspectiva prática de pontos
importantes do dia a dia de uma pessoa DevOps. Vou abstrair a parte ferramental e focar em conceitos mais abrangentes da área que possam ser algum norteador para quem está começando ou quer fundar a área no seu time e não sabe bem por onde começar.

Mas é cultura ou cargo?

Aqui não vou entrar na polêmica de discutir sobre Devops ser cultura, porque na prática o mercado já absorveu a ideia de existe um cargo e uma pessoa ou grupo de pessoas que desempenha esse papel. A proposta é trazer uma abordagem mais prática, então não vou discutir conceitualmente mas tentar mostrar que a cultura deve fazer parte do contexto diário da pessoa que desempenha esse papel.

Contexto

Vamos começar do começo. Quando olhamos o processo de desenvolvimento de software como um todo, entendemos que existem várias etapas, desde sua concepção e análise do problema até o momento em que o artefato (o site, a web api, o binário, etc) é disponibilizado para o usuário final. Hoje podemos observar uma maturidade nesse processo todo, impulsionado pela evolução em termos de tecnologia e do aumento da complexidade das aplicações, onde temos papéis mais definidos e especializados para cada etapa desse processo. Temos desenvolvedores frontend, backend, designers, UX, e por aí vai. Lógico que não é todo lugar que tem uma pessoa para cada papel, mas temos visibilidade que são papéis diferentes, mesmo que uma ou mais pessoas desempenham vários papéis, cenário que é bem comum em times com estruturas organizacionais menores como startups. Todavia, num passado não muito distante, todos eram desempenhados pelo webmaster no contexto de aplicações web ou por times dedicados à infraestrutura.

Com isso quero dizer que o papel do profissional devops, como o responsável por preparar o terreno para publicar, monitorar e escalar as aplicações sempre existiu, mas estava ofuscado numa única entidade. Hoje temos esse mesmo papel melhor definido e mais palpável.

O problema a ser resolvido

Acredito que a principal dor a ser sanada pela mudança de visualização do papel, é o de criar uma ponte sustentável entre os times de infraestrutura e desenvolvimento.

De um lado o time de infra com métricas de sucesso atreladas a confiabilidade e estabilidade e do outro o time de desenvolvimento com métricas associadas a constantes alterações e criação de novas funcionalidades. São objetivos conflitantes quando operados na forma tradicional, onde o time de desenvolvimento “arremessa” código por cima de um muro e espera que o time de infra, do outro lado do muro, receba e aplique o mais rápido possível aquele conjunto de códigos. O devops surge como ideia de cultura de colaboração para colocar ambos os lados com objetivos comuns e associar práticas que auxiliem nesses objetivos. Foi uma mudança de paradigma para ambos os lados. Tanto o time de desenvolvimento entender que para derrubar esse muro, algumas diretrizes e práticas tem que ser adotadas por eles assim como uma grande mudança no dia a dia do time de infra com novas metodologias, conceitos e ferramentas.

Ok, mas e na prática, o que isso significa?

Do ponto de vista de processo, significa tornar ágil o ciclo de desenvolvimento de software como um todo, do momento em que o código é entregue pelo time de desenvolvimento até o momento em o artefato é medido e observado pelo devops. Aqui não vamos entrar no mérito do como, mas no o que, isso porque “o como” fazer pode ser muito diverso em ferramental e depende do contexto do negócio e das aplicações. Podemos abordar isso no futuro mas neste momento a ideia é direcionar ao que, do meu ponto de vista, deveria ser feito.

Podemos quebrar essa parte do ciclo em 3 estágios

Pré-publicação

Aqui contempla tudo que precisa ser feito antes da publicação do artefato. Nessa etapa comumente nos preocupamos em validar a qualidade do código, fazendo análises estáticas, rodamos testes automatizados, validando padrões de escrita de código com algum linter.
Passadas as validações de qualidade e seria o momento do build, o momento de pegar o código e empacotar em algo entregável, criando o nosso artefato.

Nessa etapa também é comum já termos a infraestrutura que irá receber o artefato preparada ou ao menos planejada, isso significa responder a algumas perguntas para prepararmos esse terreno:

Existe expectativa de quantos usuários/requisições para essa aplicação?
É uma aplicação crítica para o negócio? Ou seja, é preciso se preocupar com disaster recovery de forma imediata? Quais opções de resiliencia de infraestrutura precisamos preparar?

Publicação

Aqui vamos para a etapa de publicar a aplicação. Já temos nosso artefato em mãos, agora é o momento de distribuir ele de acordo com a necessidade da aplicação e do negócio em si. E aqui temos mais algumas perguntas para responder:

Qual o plano de publicação? Vamos usar alguma estratégia de deployment? Tem horários/períodos do ano críticos para se evitar?
Existe algum plano de rollback? Qual a métrica usada para decidir se o rollback vai ser executado?

Pós-publicação

Aqui vencemos as barreiras de transformar o código do time de desenvolvimento em um artefato de valor que está em uso pelo cliente final. Sucesso, certo? Sim, mas calma lá que o trabalho não acaba por aí. Agora que está tudo entregue e em uso, temos que cuidar para que tudo continue assim. Agora temos a preocupação de monitorar e medir o serviço em produção para fazer os ajustes necessários. Para nos guiar nessa etapa podemos responder algumas perguntas:

Quais as métricas relevantes dessa aplicação que acabei de publicar? Como saber se está tudo bem ou é necessária alguma ação?
Como poderemos consultar essas informações?
Quem vai ser avisado se algo der errado? O que deve ser verificado e qual tarefa deve ser realizada se for recebido algum alerta?
A infraestrutura provisionada anteriormente atende o serviço? Está com recursos escassos ou com muito recurso sobrando?

Além de processos

De forma mais objetiva e prática tivemos o entendimento do que é a essência dos processos. Mas o que considerar antes de buscar implantar esses processos? Aqui vão alguns tópicos que acredito ser importantes:

Comunicação

A questão chave do Devops é criar colaboração, correto? Não tem como haver colaboração sem comunicação efetiva. Ela é a base para alinhar expectativas, objetivos e conseguir dialogar com o time de desenvolvimento.
Muitas vezes alguma melhoria pode ser detectada e precisa ser repassada ao time de desenvolvimento ou mesmo alguma mudança arquitetural pode ser sugerida e precisa ser bem comunicada para ser validada pelos seus pares.

Maturidade

Outro item importante antes de querer sair implementando novos processos é entender a maturidade do que já está construído. Do meu ponto de vista, a maturidade tem haver com compreender que, o que foi construído tem seu valor, as pessoas fizeram o que fizeram por motivos e contextos que provavelmente você desconheça. Sendo assim, não queira como primeira iniciativa refazer tudo. Mas olhe com cuidado, entenda quais são os pontos críticos que trazem melhoras significativas de forma mais rápida e conforme for necessário planeje as grandes mudanças. Nada se cria da noite para o dia, mas vai amadurecendo conforme tempo é investido nas mudanças.

O escopo geral

Aqui tem haver com a visualização no todo, entender que a área também faz parte da cadeia de valor que entrega algo para o cliente final e isso significa entender o que o negócio faz, em que ramo atua, qual o valor do produto final para o cliente.
Pode não parecer importante, talvez no dia a dia de frente com a tela preta do terminal de fato não seja, mas com certeza isso te leva a outro patamar ao poder visualizar o impacto do seu trabalho nessa cadeia de valor e poder ser mais assertivo na hora de propor mudanças, pois vai estar mais embasado naquilo que pode agregar valor real ao negócio. No final das contas, é revertido em valor para você enquanto área ou profissional.

Isso também se aplica na parte técnica para compreender como os serviços que você precisa manter online se conectam e qual seria a responsabilidade de cada um. Isso tem um valor enorme na hora de investigar problemas, compreender o ciclo da requisição ou de uma ação do usuário, é um atalho para solucionar e localizar problemas na produção.

Concluindo

Em resumo, a essência do DevOps vai além de ser apenas uma cultura, um conjunto de ferramentas, processos ou um cargo específico, mas também sobre pessoas, comunicação e uma compreensão profunda do ecossistema em que atuamos. Ao adotar essa abordagem, podemos construir pontes sustentáveis entre desenvolvimento e operações, promovendo uma entrega de software mais eficiente, confiável e alinhada com as metas estratégicas do negócio.

Engenharia orientada a produtos

Gabriel Lopes — Mon, 02 Oct 2023 13:57:53 +0000

A principal meta de uma empresa costuma ser unir várias áreas em torno de um objetivo comum de criar valor para o cliente final. Como membro dessa equipe, minha intenção é me conectar a esse propósito e contribuir para o processo de geração de valor.

Mas sendo um profissional de tecnologia, como fazer isso? Ainda mais estando em um cargo onde não tenho tanto poder de decisão estratégica e estou mais no dia a dia operacional?

Lógico que não existe uma única forma, mas aqui vou falar sobre uma delas que coloco em prática e tem dado certo para mim desde então.

Num primeiro momento podemos pensar nosso papel na geração de valor como uma pequena engrenagem na grande máquina de operações que é a organização. Desempenhando meu papel da melhor forma, escrevendo meus códigos, criando minhas pipelines, entregando software e chegando ao final do dia com a sensação de dever cumprido. Talvez essa seja uma forma, a depender do contexto de atuação, mas não consigo imaginar um dia a dia onde ser um apertador de botões profissional pode gerar impacto real na outra ponta, até mesmo porque tecnologia é um meio e não um fim. Tecnologia por tecnologia não faz nada se não tiver um objetivo claro atrelado ao seu uso.

Aí que entra o que acredito ser uma prática de engenharia orientada a produtos. Atuar como uma pessoa solucionadora de problemas, tendo em vista como as abstrações se conectam e como o pedaço de software que está entregando poderá ser utilizado pelo cliente. Ouvi uma frase do Eduardo Santos em um podcast do Data Hackers que acredito que traduz bem o que quero dizer. Ele comenta que: “O engenheiro de software deveria ser o cara na empresa que tem a capacidade de ter uma visão sistêmica sobre os processos organizacionais e como isso se transforma em software no final”.
Quando se desenvolve essa visão sistêmica, somos capazes de nos conectar com os processos e o produto de forma que muda complementarmente a forma como iremos desempenhar o nosso papel.

Uma parte da minha experiência profissional foi atuando como suporte em uma software house que o principal produto era um ERP e após os primeiros anos atendendo e treinando clientes tinha o sistema todo de cabeça. Atalhos, configurações e mais que isso, tinha o contato com o cliente e o que o software significava para cada um deles. Quando se tem essa visão do produto se torna muito mais simples desenvolver software, porque antes de pensar em criar classes, código desacoplado e arquiteturas complexas acabo pensando em que problema eu estou resolvendo, que informações preciso para resolver esse problema e para onde as informações vão depois. Quando comecei a desenvolver software nessa empresa, essa experiência prévia de contato com cliente foi essencial para conseguir desempenhar meu papel.

Com esse processo eu fico conectado com o produto, consigo ter visão do impacto que aquele desenvolvimento vai gerar e posso então dialogar com os envolvidos para entender melhor até onde vai esse impacto ou ainda propor outras soluções e tudo isso sem pensar em código. Uma vez que tenho a visão da solução na cabeça, agora sim é hora de planejar e executar. A diferença é que ao chegar no momento de implementar já adquiri um pouco mais de domínio sobre o significado do que estou fazendo e qual o potencial para gerar valor.

Nas outras empresas que atuei procurei fazer o mesmo e parecia uma receita de sucesso para ter um ramp-up significativo e conseguir me tornar produtivo de forma rápida. A diferença estava no processo de como conseguir essa visão do todo, uma vez que agora já não tinha a vivência do produto nem dos clientes.

Então como colocar isso em prática?

Na realidade não tem nada muito mirabolante, podemos partir de algumas premissas: Conexão (que pode ser interna ou externa) e abstração.

Conexão interna: Quando se é novo em um contexto (nova área, nova empresa, novo produto) não tem como adivinhar as coisas. É preciso perguntar. Conversar com quem vivencia aqueles processos para compreender como a solução pode se encaixar na vida daquela pessoa. E quando não se tem acesso a essa pessoa, precisamos buscar quem saiba, seus pares, seus líderes;
Conexão externa: A forma como a empresa ou o produto se apresentam e se vendem para o mundo exterior podem dizer muito sobre si mesmos. Podemos consumir o material divulgado em mídias sociais ou portais de conteúdo. Também podemos buscar compreender como os concorrentes operam. Isso ajuda bastante a vivenciar o ecossistema que a você está inserido;
Abstração: É preciso exercitar a capacidade de abstrair os processos do mundo real e como isso se traduz em solução no mundo digital. Programar é um exercício constante de abstração, agora precisa exercitar isso sem escrever código e usar essa potencialidade para ligar os pontos do que conseguiu extrair das suas conexões com o produto;

Portanto, ao adotar a mentalidade de um solucionador de problemas e desenvolver uma visão sistêmica dos processos organizacionais, você estará bem posicionado para gerar valor em sua empresa como profissional de tecnologia e esse valor retorna para você como experiência, conhecimento e currículo. Você não precisa ser apenas um "apertador de botões" - você pode ser um catalisador de mudanças e inovações.

Especialista em ser generalista

Gabriel Lopes — Mon, 18 Sep 2023 13:25:44 +0000

Passado os primeiros 10 anos de carreira me peguei refletindo sobre que tipo de profissional sou hoje e qual tipo serei nos próximos 10 anos. Acho que tenho buscado me tornar um especialista em ser generalista. Me especializando em aprender e conseguir resolver problemas reais com as novas ferramentas adquiridas. Mas o curioso é que olhando as discussões em redes sociais vejo um certo receio sobre ser generalista e que se assemelha a ser um pato. A ideia de que um pato, faz tudo: anda, nada e voa. Porém não faz nenhuma dessas coisas direito.

É uma frase que carrega meias verdades, mas para fins didáticos vamos analisar sob outros aspectos, primeiro ponto é qual o objetivo de cada atividade dessa? Andar pode ser uma atividade somente com objetivo de deslocar do ponto A ao ponto B e talvez o andar desengonçado do pato ainda sim atinja o objetivo de forma satisfatória. Se sua vida dependesse disso, talvez apelaria para uma habilidade mais desenvolvida.
Com isso quero dizer que não necessariamente é algo ruim você desenvolver várias habilidades sem se aprofundar muito nelas, desde que consiga atingir os objetivos propostos.

Levo muito a ideia da proporção de Pareto, onde necessito de 20% de um conhecimento para resolver 80% dos problemas que envolvem aquele conhecimento para minha vida pessoal e profissional. Sempre gostei de estudar e aprender coisas novas e uma perspectiva de me manter no mesmo nicho de conhecimento, a vida toda, nunca me atraiu muito. O fato de ser curioso, de querer resolver problemas me ajudou a construir esse perfil generalista. E esse perfil me ajuda muito a poder olhar para outras áreas de conhecimento, próximas da minha, mas que se fosse trilhar um caminho de especialidade não teria tempo hábil para procurar compreender e estudar um pouco além da área que estaria focado.

Lógico que tenho um conjunto de áreas mais afins, mas passeio pelo maior número de informações sem me preocupar se estou fugindo ou não da trilha principal. Não faço isso a esmo, existe uma lógica para ter alguma efetividade no estudo, irei abordar isso em outro post. Mas a ideia aqui seria não restringir minhas opções e poder atuar de forma horizontalizada.

Isso não significa que ser generalista é melhor ou pior que ser especialista. Significa apenas que é uma opção e que pode fazer sentido para sua carreira. Acredito que a grande maioria das nossas decisões não são binárias, cada uma delas vai depender de um contexto, de um momento de vida e também não são cravadas em mármore, para nunca mais serem modificadas. É possível transitar entre esses modelos.

E quais são as vantagens de ser um generalista? Com base na minha experiência, posso destacar algumas, como (a mais óbvia) capacidade de atuar em diversas áreas e, assim, adquirir um conhecimento diversificado. Além disso, ser um generalista é uma vantagem para aqueles que, como eu, não gostam de ficar presos na mesma rotina por muito tempo, pois permite explorar diferentes desafios e oportunidades. Isso, por sua vez, contribui para o desenvolvimento de habilidades polivalentes.

Outra maneira de encarar essa questão é focar na criação de um impacto real em sua carreira, com base no ponto de vista de negócios, em vez de se concentrar apenas em habilidades e conhecimentos específicos. Isso significa que você pode direcionar sua trajetória profissional com base no valor que pode agregar, em vez de estar “limitado” a uma única área de especialização.

Um exemplo pessoal que posso compartilhar é a minha experiência como desenvolvedor. Inicialmente, foquei meus estudos em desenvolvimento, mas ao longo do tempo, meu interesse se voltou para DevOps e infraestrutura. Investi tempo estudando e experimentando em ambientes locais, e quando surgiu a oportunidade, comecei a lidar com as demandas de infraestrutura e a solucionar problemas persistentes em minha área de atuação. Esse processo de exploração e aprendizado me permitiu não apenas desenvolver minhas habilidades, mas também capacitar outras pessoas a enfrentarem desafios semelhantes. Essa jornada trouxe um valor significativo à minha carreira, pois desbravar novos caminhos, aprender com os erros e criar soluções onde antes não existiam resultou em um crescimento substancial. Portanto, ser um generalista pode abrir portas para oportunidades inesperadas e contribuir para o seu sucesso profissional de maneiras que você talvez não tenha previsto.

Posso ainda falar de experiências semelhantes mesmo dentro da linha de desenvolvimento, atuando com mobile, web, desktop, mas o ponto é que existem diversos caminhos para se experimentar e por vezes, vivenciar o caminho pode ser a melhor forma de saber se gosta ou não daquele tipo de desafio.

Invariavelmente, com o tempo, você irá ganhar algum nível de profundidade nos assuntos que passar mais tempo de convívio. Olha só, outra vantagem, agora além de ter conhecimentos horizontais de uma variedade de temas agora tem um nível de especialização em algum assunto. Lógico, que ao se comparar com alguém que se especializou somente no assunto, o nível de profundidade não é equiparável, mas novamente, na sua carreira, você realmente precisa dessa profundidade de conhecimento? Você quer isso? Ou o nível de especialização alcançado basta para resolver os problemas e continuar evoluindo?

O objetivo desse texto não era trazer nada conclusivo, apenas trazer uma perspectiva de que a sua carreira: é sua. E existem muitos caminhos que são possíveis.

Aviso: se você, que lê esse texto nesse momento, está iniciando na carreira talvez essa não seja a abordagem ideal. Quando iniciei, também foquei esforços mais direcionados, mas a partir do momento em que já me sentia mais confortável com meu ponto focal naquele momento, passava a me guiar pela curiosidade, pelo desejo de aprender outras coisas e de ficar animado ao descobrir como as tecnologias funcionam em diferentes aspectos.