Instigado pelo artigo Caô do DevOps, resolvi tentar contribuir com a minha perspectiva sobre o que não é DevOps.
Talvez o primeiro ponto seja entender que DevOps não é um conceito simples. É difícil alguém que não trabalha (ou não trabalhou) com desenvolvimento de software entender quais dores e problemas DevOps se propõe a resolver.
Falácia #1: DevOps = Dev + Ops
Existem muitas pessoas que acreditam que DevOps é um papel, um cargo, um novo título. Este profissional seria alguém que desenvolve software mas também possui como responsabilidade operacionalizar o software, administrar o hardware, performance e outros requisitos não funcionais.
Isto não é DevOps. Embora seja uma tendência de mercado (que gera resultados positivos na grande maioria dos contextos) de que as equipes de desenvolvimento de software tenham cada vez mais propriedade e autonomia pelo desenvolvimento e manutenção/operação dos sistemas que produzem, DevOps possui uma abrangência maior.
Falácia #2: O Super Profissional Generalista Especialista
No passado, falávamos sobre o profissional em “T” (T Shaped Skills), ou seja, um profissional que é especialista em um tema mas possui uma abrangência de conhecimentos em outros. Vamos falar, por exemplo, em “Dev”, como desenvolvedores de software, ainda temos muitos desafios com relação a: entendimento dos requisitos e das necessidades de negócio, qualidade do software que nós escrevemos, validação do que está sendo construído apenas para citar alguns. Se poucos profissionais atingem um nível de maturidade e de qualidade como desenvolvedores durante toda a sua carreira, será que conseguimos encaixar mais responsabilidades e conhecimentos de infraestrutura e operações de uma forma madura?
Sim, há espaço para desenvolvedores aprenderem e se apropriarem mais sobre a infraestrutura e operações. Não, os desenvolvedores não vão possuir tanta profundidade quanto os profissionais de infraestrutura e operações tem.
A diferença, é que em uma organização que possua um ambiente com uma cultura DevOps, independente do profissional ser um Desenvolvedor ou um Analista de Infraestrutura ou Operações, todos eles tem como modelo mental: entrega de valor ao cliente, ao usuário final com qualidade adequada o mais breve possível.
Quanto a perfil e conhecimentos, os membros das equipes e da organização são profissionais multidisciplinares. Isto não significa que todos profissionais são especialistas em todas áreas de conhecimento, mas se complementam. Alguns membros da equipe possuem mais profundidade em infraestrutura, outros em operações, outros em qualidade e assim por diante. Assim como um time de futebol, o trabalho em equipe, com cada um dos 11 jogadores desempenhando a sua função, gera mais resultados do que ter o melhor jogador do mundo jogando sozinho.
Falácia #3: DevOps é seguro / SecDevOps
Segurança da informação é uma área de conhecimento que ao meu ver ainda é muito especializada. Existe uma grande demanda no mercado e poucos profissionais com conhecimento e experiência. A quantidade de vulnerabilidades e brechas nos sistemas que geramos diariamente é enorme.
Algumas pessoas acreditam que por termos uma maior cobertura de automação para provisionamento e configuração de ambientes isto significa que teremos uma maior segurança.
Na prática, tenho visto algumas organizações investindo em automação com apenas uma perspectiva ou Dev (sistemas) OU Ops (infraestrutura). Como não há conhecimento, nem experiência com segurança da informação e existe uma alta tendência a uma melhor experiência do usuário, o que acaba acontecendo é:
Então, a solução é criar o SecDevOps, ou seja, Segurança da Informação + DevOps. NÃÃÃÃÃÃÃÃOOOOO! DevOps contempla segurança da informação. Querer juntar outras áreas ou conhecimentos a DevOps, significa que você não entendeu o que é DevOps.
Com a promoção do DevOps sem entender do que DevOps trata, pode gerar problemas indesejados em alguns contextos organizacionais. Um exemplo é ignorar segurança da informação gerando mais problemas que os silos de segurança da informação sejam capazes de “limpar”. Falando em Silos…..
Falácia #4: DevOps = Dev + QA + Ops
Uma das tradicionais figuras para explicar o conceito de DevOps (e DevOps é cultura!) é esta abaixo. Mas esta figura é ruim, vou explicar os motivos..
Algumas organizações que possuem a competência de Tecnologia da Informação (TI), não tem como sua atividade primária o desenvolvimento de software. Geralmente isso faz com que na estrutura organizacional a TI seja pelo menos um silo e a área de negócio seja pelo menos um segundo silo. Uma das principais mudanças que DevOps traz para cultura organizacional é aproximação entre os silos. Aproximar os processos e profissionais da garantia da qualidade, desenvolvimento e engenharia de software e operações e infraestrutura faz todo sentido e é uma parte de DevOps. A figura acima é ruim, pois é uma abstração, os ganhos de aproximar estes três “silos” não geram impacto se as áreas de negócio não estiverem próximas.
Acima, uma imagem um pouco mais interessante. Mostra a aproximação de Qualidade + Negócio + Operações + Desenvolvimento. O centro da imagem original era de encantar o cliente, eu inclui DevOps por acreditar que uma cultura DevOps facilita atingir um nível de maturidade que os clientes são entendidos, ouvidos e encantados com os produtos e serviços providos. Quando eu digo que é um pouco mais interessante, é com o intuito de deixar claro que talvez existam outras partes importantes da organização que não estão representadas na figura e que devem deixar de ser silos distantes com objetivos independentes que podem atrapalhar os objetivos da organização como um todo.
Falácia #5: Área de DevOps
“Precisamos de uma área de DevOps na nossa organização”. Esta é uma frase e um pensamento que eu já ouvi em diversas empresas no último ano. Em raras exceções, esta abordagem pode fazer sentido, mas no geral é uma abordagem que vai contra a proposta de DevOps.
DevOps propõe aproximar os profissionais da organização, reduzir as áreas, reduzir as passagens de bastão, antecipar problemas de deploy e entregas em ambientes produtivos e não produtivos entre outras. Comunicação face a face e não baseada em tickets, processos ou contratos são bons exemplos que fazem parte da cultura DevOps. Colaborar com outras áreas, entender a criticidade e o valor de negócio de determinadas iniciativas para a organização ajudam na tomada de decisão
Falácia #6: “DevOps significa X e esta é a verdade”
Por fim, cada empresa pode ter a sua definição e interpretação de DevOps. Entendendo que DevOps é uma cultura e cultura representa o conjunto de ações e atitudes que os profissionais da empresa possuem, é natural que existam diferenças entre uma organização e outra. O que não pode ser diferente é a forma de pensar, reduzir os silos, foco em gerar mais valor e eliminar desperdícios.
Alguns elementos são básicos. DevOps sem aproximar áreas de negócio não é DevOps. DevOps. Equipes de desenvolvimento que não possuem autonomia para configurar, modificar e aplicar mudanças não é DevOps. Pipelines de entrega automatizada que não gerem feedback rápido para a equipe de desenvolvimento, não é DevOps. Equipes que não integram software continuamente, não é DevOps.
Deixe um comentário, e conte o que é DevOps para você. Conte também o que é DevOps para sua organização.
Caso tenha interesse, compartilho abaixo o video e material de uma palestra que eu fiz sobre Pipelines de entrega de software onde abordo alguns destes temas na introdução:
Agile Coach .Ninja 