Indo para DevOps

lego4
Compartilhar no facebook
Compartilhar no linkedin
Compartilhar no twitter
Compartilhar no whatsapp
Sobre o autor: Guilherme Teles é um cara qualquer que não dorme direito e acaba escrevendo. Sou Certificado CISSP, CHFI, CEH, LPIC-3, AWS CDA, AWS SAA, AWS SOA Quer assinar a newsletter do site e receber esse e outros artigos? Clique aqui! Aproveite e navegue pelo smeu blog. Quem sabe você não está exatamente precisando de uma ajuda ?  

Pessoal, tive muitos retornos positivos dos artigos citados abaixo:

Mudança de comportamento para a cultura DevOps

 

Por isso, resolvi escrever mais um artigo sobre os desafios da introdução do DevOps na configuração de uma empresa tradicional.

É certamente algo que eu mesmo como um consultor/especialista lutei por algum tempo, tanto para entender, como para transmitir as pessoas. Não é possível transmitir anos de experiência em mover uma grande empresa, de qualquer segmento, para um modo de pensar do DevOps, mas espero dar os três principais pilares de como eu abordei anteriormente.

IMPORTANTE, nada disso menciona tecnologia e ferramentas: DevOps é principalmente uma ideia cultural e, portanto, afeta as pessoas acima de qualquer outra coisa.

1) Traga especialistas no assunto

Se você está se mudando para o DevOps em sua empresa, junte pessoas diferentes de diferentes áreas e, em seguida, esperando que eles (sob efeito de mágica) cooperem e concordem magicamente em tudo é um pouco irreal. É praticamente impossível sem uma liderança competente.

Se você está lidando com equipes que tem muito tempo de empresa, misturando terceiros e funcionários, onde na grande maioria das empresas é uma realidade, então, a fragmentação de áreas provavelmente será um desafio significativo.

Alinhar incentivos torna as coisas muito mais fáceis. Opa, mas o que significa isso ? Calma, não estou falando apenas de incentivos financeiros, não entrarei neste aspecto, mas pense em incentivos/bônus como algo a ser conquistado. Seja o tradicional bônus da empresa, uma foto com o diretor, uma divulgação do seu trabalho, qualquer coisa.

Continuando, se tanto os seus desenvolvedores, analistas de requisitos e infraestrutura, são incentivados com um bônus (pode até ser um almoço legal para a família), dependendo de quanto mudarem o mindset, que eles fazem como meta de em até um ano, é uma maneira simples de fazê-los concordar sobre se eles devem automatizar os projetos, por exemplo. Isso é um pouco simplista, mas espero que você entenda o que quero dizer.

Isso pode muito bem chegar ao custo de outra coisa. A primeira coisa que vem à mente no último exemplo é a qualidade.

Vamos colocar tudo de maneira clara ok ? Nós somos pagos para isso. Por idéias, sugestões, intelecto. Ninguém nos contratou porque somos legais. Tá bom, parece um pouco ríspido, então vamos de outra forma.

Pense de maneira clara, nós estamos em um momento de revolução, mudanças, então, em primeiro lugar, você precisa reunir as pessoas com maior capacidade técnica possível em cada área e, em última instância, capacitar alguém a tomar decisões quando não pode ser alcançada através do consenso. Quanto mais áreas, consultorias, você juntar, então, maior será a possibilidade de eles não tomarem uma decisão.

Você pode ter ouvido falar sobre essa idéia de DevOps com algum amigo especialista, onde os profissionais mais capacitados conseguem fazer tudo vendados. Mentira! São raras as pessoas que tem maturidade e conhecimentos sincronizados. E mesmo que tenham, não “soltam” tudo de maneira uniforme, soltam conhecimento de forma gradativa. Afinal, estamos em um momento de mudanças. Em qualquer ambiente corporativo, deve-se ter cautela. Muitas destas pessoas tentam influenciar através da educação e persuasão, e apontam as pessoas na direção certa. Eles ajudam os times a alcançar as decisões certas em si, em vez de uma abordagem top-down do modelo “faça o que eu digo”.

Então, qual é o meu ponto? Se você está tentando se mover em direção a DevOps, então contratar profissionais altamente especializados requer cuidado. Pois esta pessoa deverá ter poder de persuasão, alguém que já fez isso antes. Alguém com um senso muito maduro do que DevOps é e, de preferência, alguém que fez a maioria dos trabalhos que ele/ela está tentando influenciar.

Além disso, contratar alguém que tem como instinto a integração, é tentar levar as pessoas à sua maneira de pensar. E, finalmente, alguém que não tem medo de colocar o seu time na linha e tomar uma decisão. Em startups ou em áreas iniciando o conceito de DevOps é muito comum indecisões.

2) Estrutura dos times

A definição tradicional de DevOps é dividir os times entre Desenvolvimento e Operações para que eles realizem metas compartilhadas. No entanto, eu sou um forte defensor de que o DevOps não é apenas Dev e Ops. É sobre todas as funções que se juntam para alcançar mudanças significativas.

Os desenvolvedores, analistas de requisitos, gerentes de projetos, os empresários e os técnicos devem ter compartilhado objetivos e incentivos. Sempre que possível, eles deveriam estar sentados ao redor da mesma mesa. A equipe deve subir e cair coletivamente (não há “nós e eles”). A equipe deve gerenciar a mudança do berço ao túmulo (requisitos, compilação, teste, implantação, suporte).

Para esse fim, o DevOps tem tanto a ver com “pessoas” do que com novas ferramentas e processos.

Com isso em mente, potencialmente você está falando de mudanças bastante radicais em um grande número de pessoas de várias habilidades, experiência e tipos de personalidade. Eu acho que realmente depende do como sua organização está estruturada, das habilidades de sua equipe e de muitos outros fatores. Para muitas, isso, no entanto, significa mudanças fundamentais.

Começamos alinhando as funções de mudança (desenvolvedores, testadores, etc.) para unidades de negócios individuais (em vez de serviços de grupo compartilhados).

Essa mudança fundamental foi patrocinada na parte traseira de algumas vitórias iniciais e pequenas implementando coisas como Integração Contínua e rotulando-a “DevOps”. Ok, então não é DevOps, mas se usar esse termo começa a obter visibilidade e movimento dentro de sua organização, então não acho que isso seja ruim. Eu sempre acreditei que precisávamos de uma bandeira para a modernização do departamento. Se essa faixa lê “DevOps”, então seja assim.

Quando qualquer time, ou empresa começa a usar o “DevOps”, teremos muitas questões como:

  1. Por que você está me dizendo como fazer meu trabalho?
  2. Você está usando as ferramentas erradas
  3. Não vejo o benefício
  4. Eu sei mais sobre isso do que você faz
  5. O que você está tentando fazer é fácil
  6. Nós não temos as pessoas certas
  7. Esta é uma ideia de modinha
  8. Há razões regulatórias para que isso não funcione
  9. O time de infra resolve

Isso é estressante quando você está tentando fazer o que é certo e mover-se em frente.

Eu não acho que nós nos ajudamos para começar. Sempre tem gente tentando retirar e mudar as tecnologias e processos de outras equipes. Não é suficiente levar a outra equipe a água e ajudá-los a implementar algo em si. Deve-se andar de mãos dadas.

3) Criar uma equipe para ajudar os outros

Eu mencionei que o DevOps é uma idéia cultural e não um título de trabalho. Definitivamente não. Inimaginável em principio. Então, como faço para executar uma equipe “DevOps”? Certamente, esse é um coletivo de “analistas desenvolvedores operacionais requisitos” ?!

Acredito que devemos ter um time de “Platform Services”,  suportando a idéia da plataforma de mudanças. A plataforma de mudança consiste em ferramentas como Chef, Jenkins, Puppet, uDeploy, Teamcity, TFS e alguns outros.

Alguém finalmente precisa “possuir” as ferramentas certificando-se de que elas são mantidas, criando melhores práticas e estabelecendo um roteiro para o futuro. Não apenas em ferramentas de deploy de códigos, mas de inventários, monitoramento, etc.

Esta equipe vai além disso e ajuda as diferentes funções de mudança a se adaptarem à plataforma de mudanças e são evangelistas para coisas como DevOps e Continuous Delivery.

Com o DevOps preocupado em destruir os paradigmas, é contraditório ter uma equipe que engasgue o conhecimento e as habilidades. Para esse fim, a Platform Services é a destruidora de paradigmas, ajudando outros a escolher as ferramentas e processos e implementá-los.

Por exemplo, não fazer implantações, mas vendemos os benefícios para outras equipes e ajudamos a adotar as ferramentas e os processos.

Eu acho que este é um bom modelo e ajuda a espalhar o sucesso do DevOps em torno da função de TI.

Sobre o autor: Guilherme Teles é um cara qualquer que não dorme direito e acaba escrevendo. Sou Certificado CISSP, CHFI, CEH, LPIC-3, AWS CDA, AWS SAA, AWS SOA Quer assinar a newsletter do site e receber esse e outros artigos? Clique aqui! Aproveite e navegue pelo smeu blog. Quem sabe você não está exatamente precisando de uma ajuda ?  

Conteúdos relacionados

All articles loaded
No more articles to load

© 2019 GRRP Tech. Todos os direitos reservados.

Desenvolvido por Upsites