O veterano do DevOps, Chris Bytaert, que foi o pioneiro do DevOpsDays, compartilha sua experiência, e suas descobertas irão surpreendê-lo.
Dez anos atrás, repentinamente fizemos uma viagem. Reunimos alguns de nossos bons amigos em Ghent (Bélgica) para discutir experiências ágeis, de código aberto e de computação em nuvem inicial. Em 2009, John Allspoe e Paul Hammond deram uma palestra na Velocity sobre "Mais de 10 implantações por dia: colaboração de desenvolvimento e operações no Flickr" (e vale a pena assistir). Depois de ver essa palestra, Patrick Debois decidiu fundar DevOpsDays.
É verdade que o mundo DevOps mudou muito nesses 10 anos? Tenho participado de eventos DevOpsDays desde o início da conferência e, durante esse tempo, acumulei uma experiência significativa. Nesta postagem, compartilharei 10 tutoriais que também podem ser úteis para você.
1. Não existe engenheiro DevOps
Muitas equipes têm uma pessoa com o título de DevOps Engineer, e nem todos os especialistas gostam desse título. Esse nome de profissão dá a falsa impressão de que DevOps é um trabalho que pode ser executado por uma pessoa. Na maioria das vezes, um engenheiro de DevOps é um engenheiro Linux que, com alguma sorte, pode resolver problemas de automação. Quando os recrutadores começam a procurar um engenheiro de DevOps, os candidatos devem se fazer as perguntas certas: “O que a empresa realmente quer do candidato? Eles estão procurando um engenheiro de montagem? Señora, que entende os requisitos não funcionais? Um especialista do departamento de operações capaz de lidar com automação ou outra pessoa? " Na maioria das vezes, as empresas procuram um especialista que distraia o restante dos funcionários de não cumprir os princípios e requisitos práticos do Agile.
Em organizações com grandes departamentos de DevOps, como regra, ninguém está envolvido no DevOps. A palavra "DevOps" fala apenas em separação do resto da equipe, e o candidato pode receber um bom salário e aprender novas habilidades no trabalho, mas não "fará DevOps".
2. As equipes DevOps não existem
Já dissemos com frequência que o objetivo do DevOps é eliminar a confusão entre equipes diferentes. Em particular, entre desenvolvedores e funcionários dos departamentos operacionais. No entanto, recentemente encontramos um novo fenômeno - o surgimento de muitas equipes DevOps.
Construir uma equipe DevOps parece uma nova prática, mas existem contradições óbvias aqui. Em uma organização, essa equipe lidará com ferramentas de desenvolvimento; em outra, é literalmente uma parede entre a equipe de desenvolvimento e os especialistas em operações. O problema é que essa parede cria confusão, frustração e reduz o nível de interação útil. A equipe chamada "DevOps", na melhor das hipóteses, resolve uma variedade de problemas e tem alguma responsabilidade pelos serviços com os quais trabalha. Normalmente, as equipes profissionais preferem não ter a palavra "DevOps" em seus nomes.
Em minha experiência, ter a palavra “DevOps” no nome de uma equipe pode dificultar a obtenção dos resultados desejados.
3. Os projetos DevOps não existem
Todos os projetos são finitos. Você desenvolve, implanta sua solução e segue em frente. Além disso, nos últimos 10 anos, tem-se falado que DevOps é melhoria contínua e que a melhoria contínua é infinita. Por sua vez, o resultado de seus projetos são serviços de longa duração, e o serviço implica na sequência "Desenvolvimento -> Implementação -> Suporte de saúde"
É somente depois de olharmos para os serviços fora dos projetos que podemos ver aspectos que são facilmente esquecidos: requisitos não funcionais. Os requisitos não funcionais incluem funcionalidade que não se ajusta a um comportamento específico. Esses requisitos também determinam nossa avaliação do desempenho do sistema. Esses requisitos geralmente incluem aspectos classificados como DevOps: confiabilidade, usabilidade, capacidade de manutenção e escalabilidade. Todas essas características são importantes para o alcance dos resultados comerciais.
Ao trabalhar com projetos de curto prazo, existe o risco de não prestar atenção suficiente a este trabalho. Ao passar para o próximo projeto, você não pensará mais nos requisitos não funcionais do anterior, pois assumirá novos desafios e os demais problemas não o incomodarão mais. Por sua vez, ao gerenciar um serviço, você realmente fica imerso no trabalho, e é do seu interesse polir tudo de forma que tudo corra bem.
4. As ferramentas DevOps não existem
Embora muitos fornecedores tentem vender várias ferramentas, incluindo uma que resolva todos os seus problemas, DevOps não se trata de ferramentas. DevOps trata de pessoas e suas interações. Algumas ferramentas realmente ajudam as pessoas a colaborar. Muitas vezes, as ferramentas podem ajudar pessoas de diferentes origens a compartilhar a mesma terminologia e ecossistemas. No entanto, com a mesma frequência, as ferramentas atrapalham uma comunicação eficaz.
Uma cultura baseada em ferramentas pode isolar as pessoas em vez de ajudá-las a interagir. O fato é que as pessoas ficam obcecadas com sua cadeia de ferramentas e se afastam daqueles que não a usam. Embora certas ferramentas possam ser muito úteis do ponto de vista técnico, uma série de novas ferramentas (convencionalmente chamadas de DevOps) aumentaram o fosso entre os diferentes grupos. Por exemplo, costumo ouvir a frase “isso funciona no meu contêiner”. Os desenvolvedores usam essa frase para indicar que "seu" trabalho está concluído. Os contêineres por si só não resolvem os problemas de interoperabilidade associados à execução eficiente de aplicativos. Não podemos permitir que ferramentas nos distanciem uns dos outros.
5. Não há certificação em DevOps
Nenhum teste de múltipla escolha pode confirmar que você é capaz de se comunicar efetivamente com os colegas. As organizações que oferecem certificação podem ter um conhecimento técnico incrível (e até mesmo uma comunicação eficaz), mas a certificação não pode mostrar que alguém é bom em DevOps.
Infelizmente, as equipes de gerenciamento exigem certificações em uma área que é difícil de certificar. Aprenda sobre seu software e hardware favoritos e explore a nuvem. Estude em uma universidade local, leia livros com os quais você pode aprender muito, como Deming , Forsgren , Humble e muitos mais... Mas não espere ser o melhor em DevOps depois de obter a certificação. Interagir com os colegas é muito mais importante.
6. O pipeline DevOps não existe
“O DevOps já funcionou?” “O pipeline do DevOps está funcionando”. "O pipeline de DevOps está quebrado." Sempre que ouço essas declarações, fico surpreso ao vermos essa terminologia. Reestruturamos o pipeline de implantação ou é que em algumas empresas as equipes de DevOps estão trabalhando nesta infraestrutura? Ou talvez seja porque os desenvolvedores estão ligando equipe operacional se o duto estiver quebrado?
Apesar da imensa importância das tecnologias de CI / CD, sou cético quanto ao uso do termo "pipeline de DevOps". Se o pipeline de desenvolvimento quebrar, a equipe de operações é a culpada. Os desenvolvedores não pensam no pipeline enquanto escrevem os testes. O próprio conceito também é enganoso. Os pipelines são criados para cada serviço ou aplicativo separadamente, em vez de em todo o domínio DevOps. Ao criar pipelines genéricos, corremos o risco de aumentar a lacuna entre as equipes, e esse não é o objetivo do DevOps.
Eu recomendo usar uma técnica que já vi em centenas de organizações ao redor do mundo: chame cada pipeline individual de pipeline do Aplicativo X. Essa terminologia tornará mais fácil saber qual aplicativo está tendo problemas durante o teste, implantação ou atualização. Também saberemos qual equipe trabalhará nas correções do Apêndice X (talvez com a ajuda de amigos da equipe de operações).
7. DevOps não tem padrões
A mais difícil das milhares de histórias de DevOps é a padronização. Da mesma forma que não podemos certificar pessoas, não existe um tamanho único para todos os padrões de DevOps. Cada organização tem seu próprio caminho, e esses caminhos podem ser muito diferentes. Não existe uma receita mágica que liste as ferramentas e descreva os métodos para criar fluxos de automação que de repente se tornarão DevOps em sua organização.
O padrão no DevOps significa que você aplica uma determinada metodologia que permitirá que sua organização comece a colaborar e se distancie da política do escritório. Também deve melhorar a qualidade do trabalho, aumentar o moral e permitir que você alcance melhores resultados com menos interrupções.
DevOps deve ser entendido como um conjunto de práticas semelhantes à metodologiaITIL . Lembre-se de que o L em ITIL significa Biblioteca. E esta biblioteca não deve ser tomada como um guia de ação, mas como uma lista das melhores práticas a partir da qual você precisa escolher a mais aplicável para você. ITIL era odiado precisamente por causa de implementações malsucedidas, nas quais a biblioteca era usada precisamente como uma instrução passo a passo. A padronização no DevOps levará aos mesmos resultados.
8. Não existe DevSecOps
Começamos o DevOpsDays em 2009 e esta conferência foi aberta a todos. Claro, inicialmente era um evento para desenvolvedores e funcionários de equipes operacionais, mas todos vieram até nós: administradores de banco de dados, testadores, analistas de negócios, financiadores e, claro, especialistas em segurança. Em 2012, falamos nas reuniões do OWASP , falando sobre o que temos feito. Brincamos que o “S” em DevOps significa segurança, assim como o “S” em HTTPS.
DevOps trata da segurança em seu núcleo. Descobri que os princípios do CD são mais adequados para equipes de segurança. O CD é um requisito de segurança: você deve ser capaz de implantar a qualquer momento; isso lhe dará a capacidade de implantar e implementar as atualizações exigidas por sua empresa ou questões de segurança.
Por um lado, é triste que tenhamos que criar palavras para incluir as pessoas responsáveis pela segurança. Por outro lado, é bom termos discutido isso novamente. Basicamente, não há diferença entre DevSecOps e DevOps. A segurança sempre fez parte do desenvolvimento e das operações. Posso usar o termo DevSecOps para isso, mas é melhor usar apenas o termo DevOps.
9. Você não pode pegar e mudar para DevOps
Você já conheceu uma empresa que faz uma declaração como “Estamos fazendo um projeto DevOps no quarto trimestre deste ano e, no próximo ano, vamos mudar para DevOps completamente”, que realmente teve sucesso? Então, eu não conheci.
A entrega de software nunca para, a tecnologia sempre muda, sempre precisa de suporte e (idealmente) a abordagem e a atitude em relação ao DevOps devem permanecer as mesmas. Depois de refinar sua abordagem de entrega, você desejará melhorar ainda mais. Não porque todas as funcionalidades do seu aplicativo foram implementadas ou porque o ecossistema no qual ele vive parou de se desenvolver. Você vai querer continuar se desenvolvendo porque a qualidade do seu trabalho está crescendo exponencialmente e, ao mesmo tempo, a qualidade de vida também. O DevOps continuará a evoluir mesmo depois que alguma tarefa obtiver o status Concluída.
10. Existe algo como Dev-oops
Infelizmente, muitas pessoas não entendem a importância da colaboração. Eles constroem paredes entre as equipes, acreditam que as ferramentas são mais importantes do que as práticas, exigem certificação de tudo e de todos. Eles também acreditam que todas as 9 afirmações anteriores estão incorretas. E essas pessoas vão lutar para sempre para ter sucesso no que eu chamo de Dev-Oops.
DevOps é sobre pensar que as ferramentas e a separação da equipe são mais importantes do que os verdadeiros princípios do DevOps que podem melhorar seu trabalho. Vamos nos esforçar para fazer DevOps, não DevOops.
o objetivo principal
Temos conduzido DevOpsDays há 10 anos e, durante esse tempo, milhares de pessoas aprenderam muitas coisas interessantes umas com as outras em um ambiente fácil e aberto. Alguns dos conceitos que considero conflitantes com os objetivos do DevOps e do Agile são populares. Concentre-se em fazer com que seus serviços ajudem sua empresa e não pare de aprender. E não se trata de copiar ferramentas e implementá-las em sua organização. Trata-se de focar na melhoria contínua em todos os sentidos.
Saiba mais sobre como obter uma profissão de alto perfil do zero ou Subir de nível em habilidades e salários, fazendo os cursos online pagos da SkillFactory:
- Curso DevOps (12 meses)
Mais cursos
- - (8 )
- UX- (9 )
- Web- (7 )
- Machine Learning (12 )
- Data Science (12 )
- (9 )
- «Python -» (9 )