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.