SlideShare uma empresa Scribd logo
1 de 75
Baixar para ler offline
© 2016 Stefanini Proprietary and Confidential
1
Continuous
Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
2
Luis Cesar Teodoro
Arquiteto de Soluções na Stefanini
Sou Arquiteto de software, entusiasta DevOps, especialista plataforma Microsoft por formação(MCSA, MCPD),
Scrum Master por formação (CSM), consultor, palestrante e instrutor. Trabalho com TI há cerca de 15 anos,
gosto muito de documentar e compartilhar o que tenho aprendido. Além disto tudo, sou casado, pai da Laura e
do Mateus. Fique a vontade para entrar em contato :)
Microsoft Certified Solutions Expert: SharePoint
Microsoft Certified Solutions Developer: SharePoint, Web
CSM: Certified ScrumMaster®
Contato: lcteodoro@hotmail.com
Linkedin: https://br.linkedin.com/in/luís-cesar-teodoro-298a6116
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
3
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
4
Papo sobre DevOps
Normalmente querem que eu responda as seguintes
perguntas:
1. O que significa DevOps?
2. DevOps é um movimento?
3. DevOps é uma filosofia, é um conceito ou uma cultura?
4. DevOps é uma metodologia?
5. DevOps é algum tipo de ambiente ou grupo de ferramentas ?
6. O especialista DevOps é um devel que entende de infra?
7. O especialista DevOps é um sysadmin que entende de devel?
8. DevOps é um cargo? é um setor ou um departamento?
9. DevOps só funciona em startups ou serve para o ambiente corporativo?
10. O DevOps é algo novo?
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
5
Ao longo da apresentação eu pretendo responder a
todas estas questões, mas para respondê-las vamos
precisar entender algumas coisas antes.
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
6
Como tudo começou?
Precisamos ir ao cerne desta história. O movimento DevOps não começou em um lugar só,
existem muitos lugares que dão pistas sobre as origens do termo, mas aparentemente as
informações mais concretas sobre as origens deste movimento nos levam ao ano de 2008 -
Neste ano, começaram a utilizar o termo infraestrutura ágil em algumas listas de discussão
com foco em desenvolvimento ágil, e na mesma época durante evento Agile 2008, surgiram
conversas que abordavam o tema metodologia ágil para a administração de infraestrutura,
inspirada no modelo ágil de desenvolvimento, no entanto, foi a lista de discussão europeia com
nome agile-sysadmin que começou a abordar o tema com propriedade, com isso ela ajudou a
colocar os primeiros tijolos na ponte que faria a ligação entre developers e sysadmins. Um dos
participantes desta lista era Patrick Debois (@patrickdebois), além de muito ativo ele era e ainda
é um grande entusiasta do assunto.
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
7
Como tudo começou?
O termo DevOPS só foi criado de fato em 2009 durante a conferência Velocity da O’Reilly, nesta
conferência John Allspaw (Etsy.com) e Paul Hammond (Typekit) apresentaram o trabalho10+
Deploys Per Day: Dev and Ops Cooperation at Flickr, veja abaixo os slides desta palestra.
10+ Deploys Per Day: Dev and Ops Cooperation at Flickr from John Allspaw
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
8
Como tudo começou?
De lá para cá, Patrick Debois, Gildas Le Nadan, Andrew Clay Shafer, Kris Buytaert, JezzHumble,
Lindsay Holmwood, John Willis, Chris Read, Julian Simpson, R.I.Piennar (mcollective) e muitos
outros levaram o evento para diversas localidades, dentre elas:
• New York 2012
• Rome 2012
• Mountain View 2012
• India 2012
• Tokyo 2012
• Austin 2012
• Goteborg 2011
• Bangalore 2011
• Melbourne 2011
• Mountain View 2011
• Boston 2011
• Göteborg 2011
• Sao Paulo 2010
• Hamburg 2010
• Mountain View 2010 (video intro)
• Sydney 2010
• Ghent 2009
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
9
Como tudo começou?
Na abertura do evento DevOpsDay há sempre um vídeo de intro, veja dois deles:
Ghent 2009
https://www.youtube.com/watch?v=EOveXZhJpr4
Mountain View 2010
https://www.youtube.com/watch?v=a0N2ugDwi5g
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
10
DevOps Manifest
Apesar de terem organizado o DevOpsDays em diversos países, não foi estabelecido um manifesto
para o assunto, logo existem muitas interpretações acerca deste termo.
Mas antes de argumentar acerca do possível conteúdo de um manifesto DevOps, primeiro temos
que entender a dinâmica na relação entre as áreas de infraestrutura (infra) e desenvolvimento
(devel).
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
11
Analisando Infra e Devel
Para entender melhor o que DevOps significa, precisamos então analisar de forma prática e direta
a vida de sysadmins, desenvolvedores e o cotidiano destas áreas.
Vamos imaginar - hipoteticamente - uma empresa de comunicação que desenvolve aplicações web
em sua maioria para portais de notícias, e em alguns casos também faz aplicações web internas
(rh, financeiro, administrativo), nessa empresa o devel trabalha com PHP, PYTHON, RUBY e JAVA.
Para um melhor entendimento, considere as duas características abaixo como cotidianas nesta
empresa fictícia:
O Devel está começando a trabalhar com metodologias ágeis (proativo, evolutivo e contínuo).
A Infra continua trabalhando no modelo tradicional de administração (manual, caótico e reativo).
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
12
Infra em foco
A infra é composta em parte pelos sysadmins, estes rapazes e moças tem a missão de manter os
sistemas funcionando, são eles que fazem os deploys e os rollbacks das aplicações do devel, é
responsabilidade deles manter o ambiente de produção intacto.
Eles se preocupam com segurança, estabilidade e principalmente com o acordo de nível de serviço
(SLA) de cada produto sob sua responsabilidade, esta preocupação é fundamental para o negócio.
Em resumo, a infra (sysadmins) se preocupa em proteger o valor do negocio.
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
13
Devel em foco
O devel é composto em parte por desenvolvedores, estas moças e rapazes trabalham com lógica e
criatividade, eles passam boa parte de seu tempo codificando soluções, e focam seu trabalho nos
requisitos que o analista conseguiu mapear junto ao cliente.
Os desenvolvedores estão constantemente criando e aprimorando suas aplicações, com isto novas
versões são criadas e precisam ser disponibilizadas, assim seus clientes poderão usufruir dos
recursos solicitados.
Nova versão significa novo deploy, e caso ocorra algum problema, isto irá demandar um rollback,
ambos procedimentos envolvem equipes de infra.
Em resumo, podemos dizer que o devel se preocupa em aumentar o valor do negócio.
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
14
Onde está o conflito?
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
15
Onde está o conflito?
Os desenvolvedores querem colocar suas aplicações no ar o mais rápido possível, no entanto os
sysadmins querem ter certeza que a aplicação está estável o suficiente para entrar em produção sem
gerar incidentes.
Nos últimos anos esse conflito foi latente no mundo de TI, algumas empresas tinham regras tão rígidas
que só permitiam deploy uma vez por semana - em casos mais rígidos apenas uma vez por mês, tudo
isto pensando em proteger o negócio.
É claro que a infra trabalhando com os métodos que estava acostumada (deploy 1 vez por semana e
manual) não dava vazão as demandas, e também é óbvio que o devel não possuía uma infra adequada
para fazer o desenvolvimento de forma contínua.
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
16
Onde está o conflito?
Além de tudo isso, normalmente o devel não conhece e não tem como prever aspectos importantes
relativos a infra que fica de cara para o cliente, portanto, quando a aplicação vai para produção,
normalmente ocorrem - constantes - pequenos incidentes que geram uma enorme perda de valor no
negócio. Traduzindo, são aqueles ajustes na aplicação que precisam ser feitos de última hora pois o
ambiente devel é completamente diferente da produção.
O cliente por sua vez reclama - com razão - e depois a gerência de TI ficava tentando encontrar o dono
do problema (caça as bruxas), de um lado devel dizendo que infra é engessada, lenta e que não oferece
um ambiente adequado para desenvolverem suas aplicações, do outro lado a infra dizendo que o devel
faz código ruim e instável e que não é culpa deles se a aplicação não funciona.
Eu sou de infra há muitos anos, mas tenho que dizer que a infra devido a culturas arcaicas de
administração, heranças do tempo dos mainframes, tem mais culpa no cartório neste cenário, porém o
devel também tem seus problemas, afinal, como estão começando a aplicar métodos ágeis, ainda estão
criando a cultura de execução de testes e garantia de qualidade (QA).
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
17
Incidentes
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
18
Incidentes
Quando ocorre algum incidente, você vai ouvir da infra falando para o devel que o problema não são
as máquinas, é o código, e certamente o devel vai falar para infra que o problema não é o código,
são as máquinas, e provavelmente ainda vão dizer que o sistema está funcionando no notebook
deles, e infelizmente isso será algo cotidiano.
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
19
Incidentes
Espero que neste ponto você já esteja enxergando o problema
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
20
Incidentes
É preciso entender que infra e o devel trabalham em nichos, cada um no seu quadrado, cada um em
sua realidade e nenhum deles está muito disposto a mudar sua cultura, nenhum deles está disposto a
ceder. A infra não conhece o devel e não sabe como mudar para ajudá-los, o devel não conhece a infra
e não sabe como pedir o que precisam.
No final das contas, as pessoas não conseguem estabelecer uma forma sadia e eficiente de
comunicação, e com isso, não existe trabalho colaborativo entre estas duas áreas.
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
21
O combustível do conflito
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
22
O combustível do conflito
Acima eu apresentei o conflito comum entre as áreas, porém existe o combustível que o mantém
aceso, e esse combustível é o comportamento do sysadmin, portanto, há de fato uma razão para se
ter tanto ódio deles, vamos a elas:
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
23
O combustível do conflito
•Eles falam não
•Eles falam não pela segunda vez
•Eles falam não pela terceira vez
•Eles falam não o tempo todo por diversas razões, para diversos pedidos
•Eles demoram, atrasam e perdem prazos de atendimento
•Eles se recusam a quebrar as coisas mesmo que seja para encontrar o problema
•Eles se preocupam com UPTIME e não com o negócio
•Eles acham que o devel só quer saber de perfumarias e coisas do gênero
•Eles não se esforçam para ajudar o devel a encontrar o problema
•Eles acham que o problema do devel não é problema deles
•Eles não conseguem enxergar o negócio e não enxergam que infra e devel são parte de um todo
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
24
O combustível do conflito
E isso tudo faz parte daquele comportamento arcaico que eu já mencionei, eu quis reforçar isto pois é
bom mostrar as raízes de um problema para ajudar na reflexão do que é preciso mudar.
Veja que tal comportamento é inaceitável e incompatível com o mundo de hoje, mesmo assim ainda é
muito comum encontrar pessoas que possuem este tipo de atitude e perfil.
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
25
Uma pitada de realidade
Lembra que eu disse que a infra se preocupa em proteger o negócio e o devel se preocupa com
as formas de agregar valor ao negócio?
Esqueça o que eu disse, isso funcionava nos anos 70/80/90, mas hoje isso não é suficiente.
A infra deve entender que sua obrigação é oferecer os meios para fazer o negócio fluir, e isso também
é papel do devel.
Ambas equipes precisam mudar a forma de pensar e de agir, porém é preciso ter consciência de que
mudanças estão associadas a problemas, uma mudança pode quebrar seu produto e afetar o seu
negócio.
Então qual é a receita mágica?
Como mudar sem afetar o negócio?
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
26
Mudanças necessárias
A infra precisa evoluir, e precisa fazer isto rapidamente.
O devel precisa ter controle de todas as fases do deploy.
A infra precisa começar a trabalhar de forma automatizada e dinâmica, precisa ser mais veloz para
subir novos ambientes ou mesmo reconstruir/duplicar os ambientes existentes para suprir as
necessidades do devel, não dá mais para trabalhar de forma manual e usar as mesmas metodologias
da época dos mainframes.
O devel precisa conseguir passar para infra suas necessidades de forma clara, e tem que se esforçar
para fazer a infra entender isto - e eles não vão entender na primeira vez.
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
27
Busca de soluções
E foi a busca de soluções para estas necessidades que motivou importantes discussões no mundo da
TI, foi então que começaram a falar de ‘Infraestrutura ágil’ no ano de 2008, vamos agora entender o
que é isso.
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
28
Infraestrutura ágil
Infraestrutura como código
A discussão acerca de infraestrutura ágil ganhou força com o crescimento de duas tendências, são
elas virtualization e cloud computing. Desde 2003 empresas começaram a conviver com
ambientes virtualizados, logo um parque com poucas máquinas físicas poderia se tornar um parque
com dezenas máquinas virtuais, e após o recente advento da Cloud, dezenas de máquinas virtuais
podem se tornar centenas ou milhares de instâncias a serem administradas na nuvem.
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
29
Infraestrutura como código
Não havia mais espaço para se trabalhar infraestrutura da forma tradicional, foi necessário dar um
passo a diante e pensar em infraestrutura como código, principalmente quando paramos para
analisar o recente boom das startups, empresas pequenas com produtos de enorme alcance,
produtos que rodam em centenas de instâncias na nuvem, atendendo milhões de usuários, e tudo
isso é administrado por equipes mínimas.
O objetivo é fazer deploy não só de aplicações, mas deploy de infraestrutura de forma rápida e
controlada.
Isso significa que se você precisa subir um ambiente JBOSS você vai fazer isto em poucos minutos e
não em dias.
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
30
Ferramentas de infraestrutura ágil
Quando se fala em infraestrutura ágil o que vem a mente são ferramentas, e de fato elas são parte
disto.
Basicamente temos três tipos de ferramentas, são elas:
1.Orquestradores
2.Ferramentas para gerenciamento de configurações
3.Ferramentas para bootstrapping e provisionamento
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
31
Ferramentas de infraestrutura ágil
Orquestradores são ferramentas que nos permitem executar comandos e controlar nodes/instâncias
de nosso parque em tempo real. Alguns destes são Fabric, Capistano, Func e Mcollective.
Ferramentas de gerência de configuração normalmente controlam estados de seu sistema, ajudam a
centralizar toda as configurações e facilitam a administração e criação de novos ambientes. Algumas
delas são Puppet, Chef, Cfegine e Salt.
Ferramentas de bootstrapping são aquelas que nos ajudam a instalar um sistema operacional seja
em uma máquina física, seja em um máquina virtual, seja em uma instância na nuvem, dentre elas
temos alguns provedores de CLOUD como AWS e Rackspace que já oferecem isso nativamente,
existem também ferramentas como o Kickstart e Cobbler que atuam neste segmento.
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
32
Ferramentas de infraestrutura ágil
A combinação destes três tipos de ferramentas nos permite ter o que chamamos de infraestrutura
ágil.
Mas apesar da qualidade e dos ganhos em utilizar tais tecnologias, a ferramenta sozinha não
resolverá seus problemas, é preciso mudar a cultura e a forma de trabalhar a infraestrutura.
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
33
Equipe de infraestrutura ágil
Equipes que trabalham com infraestrutura ágil também precisam de um método diferenciado de
organização, normalmente estas equipes estão trabalhando seguindo estes eixos:
Versionamento do código e arquivos de configuração (git)
Organização de atividades de forma visual (KANBAN BOARD)
Trabalho em pares
Divisão das atividades em sprints
Reuniões ágeis diárias (standup meeting de 10 minutos - em pé)
Reuniões ágeis periódicas (retrospectiva e planejamento de sprints).
Parece com SCRUM mas não é, mas é fortemente inspirado nele e no Kanban.
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
34
Então DevOps e Infraestrutura ágil são a mesma coisa?
Não, infraestrutura ágil é parte da cultura DevOps.
DevOps depende de infraestrutura ágil, mas ainda tem muito mais.
Apesar da evolução da infra, ainda falta algo que conecte as duas áreas, precisamos de um agente de
mudanças principalmente no meio corporativo.
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
35
Cultura DevOps
Chegou a hora de entrar neste assunto, agora nós vamos aprofundar nossos estudos em relação a
cultura DevOps.
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
36
Características da cultura DevOps
Para entender a cultura DevOps sem fazer um texto muito longo, vou pontuar as suas principais
características.
Patrick Debois (foi quem cunhou o termo) diz que DevOps essencialmente é uma cultura, e a
descreve utilizando 4 eixos, são eles:
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
37
Em relação as características da cultura
Cultura
Colaboração
Fim das divisões
Relação saudável entre as áreas
Mudança de comportamento
Automação
Deploy
Controle
Monitoração
Gerência de configuração
Orquestração
Avaliação
Métricas
Medições
Performance
Logs e integração
Compartilhamento
O feedback é tudo
Boa comunicação entre a equipe
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
38
Em relação as características da cultura
"UM TOLO COM UMA FERRAMENTA AINDA É UM TOLO"
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
39
Em relação as características técnicas
Um ambiente DevOps deve ter/possuir/oferecer/permitir:
1. Infraestrutura como código
2. Orquestração de servidores
3. Gerência de configurações
4. Provisionamento dinâmico de ambientes
5. Controle de versões compartilhado entre infra e devel
6. Ambiente de desenvolvimento, teste e produção (no mínimo)
7. O ambiente de devel deve possibilitar TDD
8. Infra deve participar dos projetos desde o início [1]
9. Infra deve participar das reuniões de devel [2]
10. Devel deve participar das reuniões de infra [3]
11. Ambiente de entrega contínua [4]
12. Os desenvolvedores devem conseguir fazer o deploy sem interferência da infra [5]
13. Monitoramento eficaz com processamento adequado dos eventos e métricas
14. Capacidade de resposta rápida a incidentes e problemas
15. Backup e restore confiável
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
40
Em relação as características técnicas
Infra deve participar dos projetos desde o início [1]
O devel precisa envolver a infra nos projetos desde o início - isso significa participar das
reuniões técnicas ou SCRUM, afinal sem a infra não há projeto, e além disto, quanto
mais problemas foram resolvidos durante o projeto - com ajuda da infra, menos
problemas serão expostos aos clientes.
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
41
Em relação as características técnicas
Infra deve participar das reuniões de devel [2]
A infra também precisa observar quais são as metas da empresa a longo prazo,
principalmente aquelas ligadas ao devel, pois enxergando onde o devel quer chegar, ela
pode se programar melhor para ter certeza que a infraestrutura tecnológica estará
preparada para atendê-los quando esse momento chegar.
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
42
Em relação as características técnicas
Devel deve participar das reuniões de infra [3]
A infra precisa envolver o devel em suas reuniões técnicas para que o devel entenda e
tenha ciência da realidade da infra, assim eles vão conseguir enxergar suas qualidades,
atribuições, planos de melhorias, atualizações programadas, agendas de manutenção,
eles vão conhecer os recursos disponíveis e também descobrir a limitações da equipe,
sejam elas técnicas, sejam materiais. Além disto, o devel pode ser um grande aliado da
infra na solução de problemas, afinal o conhecimento que o devel traz pode ajudá-los a
melhorar a forma com que administram seu ambiente, tornando este processo mais
eficiente.
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
43
Em relação as características técnicas
Ambiente de entrega contínua [4]
O devel precisa adotar alguma metodologia de entrega ou desenvolvimento contínuo e a
infra precisa entender esse processo para que juntos criem os ambientes com as
ferramentas certas.
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
44
Em relação as características técnicas
Os desenvolvedores devem conseguir fazer o deploy sem interferência da infra [5]
A infra precisa ceder um pouco e evoluir, precisa oferecer ao devel um ambiente
adequado onde eles sejam o dono do produto, onde o devel consiga fazer todo o ciclo
de desenvolvimento de forma direta, o devel precisa conseguir gerar e controlar o
código, precisa fazer o commit com segurança, precisa fazer o build, testar o build,
validar a aplicação e entregar a nova versão de forma transparente sem que para isso
precise passar por um burocrático e engessado processo de mudança.
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
45
Em relação aos valores humanos
Para a adoção da cultura funcionar, a equipe precisa observar e exercitar os seguintes valores:
•Confiança no trabalho de sua equipe
•Respeito pessoal e profissional por todos da equipe
•Sinceridade sobre eventos e incidentes ocorridos
•Honestidade sobre as causas dos incidentes (não esconda nada da sua equipe)
•Entendimento de que o problema é responsabilidade de todos
•Entendimento de a solução é responsabilidade de todos
•Entendimento de que os resultados são o reflexo do trabalho de toda a equipe
•Comunicação efetiva e dinâmica
•Postura construtiva sempre
•Espírito de colaboração
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
46
Em relação a forma de trabalho
É recomendável que a equipe:
Internalize e adapte métodos ágeis como KABAN e SCRUM para seu dia-a-dia
Aprofunde estudos em entrega contínua
Aprofunde estudos em gerência de configurações e orquestração
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
47
Características técnicas
Valores humanos e forma de trabalhar
Espero que tenha ficado claro para você.
Em relação a forma de trabalho
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
48
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
49
Após observar as principais características deste movimento, normalmente pensamos
em como aplicar isto em nosso meio. Para ajudar na reflexão vamos avaliar o meio
startup e o meio corporativo.
Aplicando a cultura
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
50
A cultura DevOps combina muito com startups, nestes locais normalmente já se
trabalha desenvolvimento utilizando metologias ágeis, foi inclusive neste nicho em que
começaram a discutir infraestrutura ágil - a precursora do movimento DevOps, portanto,
as pessoas deste meio conseguem absorver os conceitos e a cultura DevOps sem
grandes dificuldades, eles conseguem compreender os preceitos de colaboração e
feedback pois já fazem isto em seu dia-a-dia.
Quem está uma startup não tem as amarras e vícios da corporação, este é um grande
facilitador e não é necessário nenhum tipo de intervenção para internalizar a cultura, a
partir do estímulo de um líder as pessoas começarão a estudar e aplicar DevOps
naturalmente.
Na startup normalmente não existe divisões, departamentos, todos trabalham juntos e
isso também é um facilitador, afinal não existem barreiras para se comunicar.
A realidade no ambiente startup
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
51
A corporação não funciona como a startup, lá existe burocracia e o uso vicioso de
métodos ultrapassados, portanto não bastará o estímulo da alta hierarquia para que
equipes de infra e devel comecem a vivenciar a cultura DevOps, neste tipo de
ambiente, em minha opinião pessoal e profissional, é necessário intervir cirurgicamente
para conseguir internalizar a cultura DevOps.
Em resumo, você precisa trazer alguém - de fora - que conhece DevOps para que esta
pessoa passe a contaminar os demais.
Esse processo é lento, mas se o especialista tiver os meios e o apoio do alto escalão,
mudanças fantásticas poderão ocorrer.
A realidade no ambiente corporativo
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
52
Ele foi trazido para atuar como um agente de mudanças, ele precisa contaminar as
áreas e mostrar que a cultura DevOps funciona.
O especialista DevOps no meio corporativo
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
53
Está na casa dos 30 anos ou mais
É um profissional sênior em infraestrutura
Tem um bom background em desenvolvimento
Tem um bom background em metodologias ágeis
Tem sólidos conhecimentos em soluções opensource e similares
Trabalha intensamente com automação e infraestrutura como código
Característica gerais de um especialista DevOps em 2013
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
54
Este especialista em DevOps terá um pé na infra e outro no devel, em alguns casos
também terá o pé na área de garantia de qualidade (QA).
Onde esse especialista atua?
Ele é a cola que faltava para unir infra, devel e qualidade.
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
55
Ele será a ponte entre as áreas de infra e devel, ele conhece a infra a fundo e entende
de forma ampla processos de desenvolvimento ágil.
Como esse especialista atua?
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
56
Ele participa dos projetos de desenvolvimento desde o seu nascimento, seu foco é
oferecer os recursos para os desenvolvedores trabalhem da forma mais eficiente, além
disto, com sua ótica de infra ele toma todas as precauções para que os aspectos de
segurança, monitoramento, eficiência e escalabilidade sejam observados desde o início
do projeto.
O DevOps vai ainda estudar todo o processo de desenvolvimento e definir - em
conjunto com o devel - as ferramentas que irão permitir um processo de
desenvolvimento e entrega contínua. Após definir ele vai instalar e manter esse infra.
Alguns DevOps conseguem até avaliar o código do produto e enxergar problemas de
performance, esse tipo de visão sistêmica e raciocínio rápido são diferencias
importantes para uma entrega com mais qualidade.
Pé no devel
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
57
Na infra ele é o principal agente de mudanças, é ele que vai puxar a fila para iniciar a
implantação de uma infraestrutura ágil, ele domina as ferramentas de orquestração,
gerência de configuração e provisionamento e vai usar esse conhecimento para que a
equipe passe a trabalhar a infraestrutura como código.
Este profissional também vai ajudá-los a mudar seu comportamento e cultura, ele vai
orientá-los nos métodos ágeis de execução de atividades, aqueles inspirados no SCRUM
e KANBAN.
Pé na infra
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
58
Para internalizar DevOps, normalmente estas barreiras não existem, infra e devel
devem habitar o mesmo espaço, sem paredes, sem divisórias, todos na mesma sala,
isso é fundamental para extinguir os nichos e criar uma equipe mais unida e coesa.
Respondendo a pergunta, ele deve ficar junto com as duas equipes se for possível, esse
é o melhor dos mundos.
Se não for possível ficarem todos juntos, o especialista deve se esforçar para interagir
com as duas equipes diariamente.
Ele vai ser o agente de mudanças até que infra e devel comecem a entender e adotar a
cultura de forma natural.
Ele fica na infra ou no devel?
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
59
Vamos avaliar dentro da ótica de cada área o que melhora com a adoção da cultura
DevOps
Quais os ganhos em adotar a cultura DevOps?
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
60
Infraestrutura como código (equipe para de administrar e passa a desenvolver a infra)
Infra mais eficiente e rápida usando métodos ágeis
Equipe de Infra mais organizada
Equipe de Infra se comunicando melhor
Infra fazendo mais em menos tempo com menos gente
Ambientes de gerência de configuração, orquestração e provisionamento implantados
Deploys de infra (novos ambientes) mais rápidos e seguros => entrega rápida
Ambiente padronizado e sob controle
Feedback rápido em todas as atividades de infra
Ganhos para a infra
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
61
Devel tem ambiente mais adequado para trabalhar (dev/teste/prod)
Devel passa a contar com ambiente de desenvolvimento contínuo
Devel passa a contar com testes automatizados
Deploys de apps (novas versões) mais rápidos e seguros => entrega rápida
Feedback rápido em todas as fases de desenvolvimento
Ganhos para o devel
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
62
Acaba a divisão Infra vs Devel (acaba a guerra)
Infra participa dos projetos e acompanha de perto tudo o que acontece
Infra participando resulta em melhor planejamento do ambiente de produção
Infra participando resulta em monitoramento mais eficaz da aplicação
Devel começa a compreender melhor a infra e isso resulta em um produto melhor
Equipes trabalhando em conjunto para aumentar o valor do negócio
Ganhos mútuos Infra/Devel
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
63
Melhor comunicação entre devel e infra (diminuição de conflitos)
Soluções rodando com maior estabilidade e desempenho
Entregas mais rápidas
Menor tempo de paradas
Diminuição de incidentes
Diminuição de custos
Diminuição de riscos
Aumento do valor do negócio
Ganhos para a empresa
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
64
Vamos partir para perguntas e respostas no melhor estilo FAQ.
Indo direto ao ponto (e respondendo as perguntas do início)
Amarrando as pontas
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
65
DevOps está diretamente relacionado a um melhor feedback entre as áreas de TI.
DevOps é um movimento, é um conceito, é uma cultura e uma filosofia, e não existe
uma explicação fácil.
DevOps possibilita diminuição dos riscos de mudanças através do uso de um
ferramental adequado e adoção de uma cultura específica.
DevOps busca entregar sistemas melhores, com menor custo, fazendo isto de forma
mais rápida e com menor risco.
DevOps envolve a área de Infra e Devel primariamente.
DevOps é pura metodologia ágil tanto na Infra quanto no Devel.
Respondendo sobre o termo DevOps:
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
66
DevOps só funciona se as equipes de infra e devel estiverem dispostas a ceder, mudar
sua cultura e método de trabalho.
DevOps não é um cargo, tão pouco um setor ou departamento, é uma cultura.
DevOps não está restrito ao ambiente das startups, é possível utilizar essa cultura no
meio corporativo.
DevOps não é algo novo, as boas práticas estão ai desde de sempre, logo esse ‘juntado’
de práticas não é novidade para muita gente, mas para alguns serve como uma boa
referência para aplicar mudanças necessárias.
Respondendo sobre o termo DevOps:
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
67
O especialista em DevOps de hoje é normalmente alguém que conhece muito de infra e
tem uma base sólida de devel.
O especialista em DevOps também pode ser alguém que veio do devel e que tem uma
base sólida de infra (esse geralmente é mais completo).
Respondendo sobre o especialista em DevOps:
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
68
Não existe um manual de conduta para dizer se você é um DevOps ou não, mas é
bastante comum encontrar profissionais que estão estudando infraestrutura ágil e se
denominando DevOps. A AWS (Amazon) lançou em 2015 a certificação DevOps.
Se você está buscando melhorar seu ambiente, entregar mais rápido, entregar algo com
mais qualidade, algo que minimize custos, algo que diminua riscos, algo que envolva
automatização pesada, se você trabalha infraestrutura como código, se você está
atuando como um agente de mudanças em sua equipe, penso que DevOps é um termo
adequado para descrever o seu trabalho, mesmo que não esteja diretamente envolvido
com uma equipe de Devel.
Eu trabalho com infra ágil, sou um DevOps?
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
69
Como eu já mencionei não existe uma metodologia clara, DevOps ainda é um
movimento em constante construção e definição, eu citei uma série de melhorias que
fazem parte da cultura DevOps, cabe a cada empresa ou a cada gestor estudar e
descobrir a melhor forma de combinar essas pequenas receitas técnicas e aplicar em
seu ambiente.
Não existe receita mágica ou caminho rápido
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
70
Vamos ver na pratica como funciona a junção de tudo isso.
DevOps na Pratica
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
71
Continuous Operations
DevOps
© 2016 Stefanini Proprietary and Confidential
72
Duvidas???
© 2016 Stefanini Proprietary and Confidential
73
Links Uteis
© 2016 Stefanini Proprietary and Confidential
74
Guto Carvalho
http://gutocarvalho.net/
DevOps
http://devops.com/
Microsoft Virtual Academy
https://mva.microsoft.com/
Windows Nano Server 2016
OBRIGADO!
Luis Cesar Teodoro
Arquiteto de Soluções
lcteodoro@Hotmail.com
© 2016 Stefanini Proprietary and Confidential
75
Dream big, work smart,
deliver fast.

Mais conteúdo relacionado

Destaque

Final Manual oct 2012 (2)
Final Manual oct 2012 (2)Final Manual oct 2012 (2)
Final Manual oct 2012 (2)Rajesh Neupane
 
Presentation Skills
Presentation Skills Presentation Skills
Presentation Skills MomilAsim
 
GEEK Up Android Developer JD
GEEK Up Android Developer JDGEEK Up Android Developer JD
GEEK Up Android Developer JDGEEK Up
 
Hacking Your Way to The Top: Essential Skills for Product Leaders
Hacking Your Way to The Top: Essential Skills for Product LeadersHacking Your Way to The Top: Essential Skills for Product Leaders
Hacking Your Way to The Top: Essential Skills for Product LeadersTathagat Varma
 
コンテナのユースケース考察
コンテナのユースケース考察コンテナのユースケース考察
コンテナのユースケース考察Shuji Yamada
 
Autoscaled Distributed Automation using AWS at Selenium London MeetUp
Autoscaled Distributed Automation using AWS at Selenium London MeetUpAutoscaled Distributed Automation using AWS at Selenium London MeetUp
Autoscaled Distributed Automation using AWS at Selenium London MeetUparagavan
 

Destaque (8)

Final Manual oct 2012 (2)
Final Manual oct 2012 (2)Final Manual oct 2012 (2)
Final Manual oct 2012 (2)
 
C.S. Resume
C.S. ResumeC.S. Resume
C.S. Resume
 
Presentation Skills
Presentation Skills Presentation Skills
Presentation Skills
 
GEEK Up Android Developer JD
GEEK Up Android Developer JDGEEK Up Android Developer JD
GEEK Up Android Developer JD
 
Hacking Your Way to The Top: Essential Skills for Product Leaders
Hacking Your Way to The Top: Essential Skills for Product LeadersHacking Your Way to The Top: Essential Skills for Product Leaders
Hacking Your Way to The Top: Essential Skills for Product Leaders
 
コンテナのユースケース考察
コンテナのユースケース考察コンテナのユースケース考察
コンテナのユースケース考察
 
Autoscaled Distributed Automation using AWS at Selenium London MeetUp
Autoscaled Distributed Automation using AWS at Selenium London MeetUpAutoscaled Distributed Automation using AWS at Selenium London MeetUp
Autoscaled Distributed Automation using AWS at Selenium London MeetUp
 
Rebecca Trocki Resume 12.16
Rebecca Trocki Resume 12.16Rebecca Trocki Resume 12.16
Rebecca Trocki Resume 12.16
 

Semelhante a DevOps - Operação contínua

Cultura DevOps - Integração entre infra e devel
Cultura DevOps - Integração entre infra e develCultura DevOps - Integração entre infra e devel
Cultura DevOps - Integração entre infra e develJose Augusto Carvalho
 
Cultura DevOps e integração entre infra e devel
Cultura DevOps e integração entre infra e develCultura DevOps e integração entre infra e devel
Cultura DevOps e integração entre infra e develJose Augusto Carvalho
 
Palestra sobre DevOps na ASSESPRO-MG
Palestra sobre DevOps na ASSESPRO-MGPalestra sobre DevOps na ASSESPRO-MG
Palestra sobre DevOps na ASSESPRO-MGWelington Monteiro
 
TechNet - e-Book- Artigos sobre Test Manager
TechNet - e-Book- Artigos sobre Test ManagerTechNet - e-Book- Artigos sobre Test Manager
TechNet - e-Book- Artigos sobre Test ManagerAlan Carlos
 
DevOps - A Origem
DevOps - A OrigemDevOps - A Origem
DevOps - A OrigemAndré Dias
 
E se ao invés de Dev e Ops for DevOps? Uma introdução a cultura DevOps
E se ao invés de Dev e Ops for DevOps? Uma introdução a cultura DevOpsE se ao invés de Dev e Ops for DevOps? Uma introdução a cultura DevOps
E se ao invés de Dev e Ops for DevOps? Uma introdução a cultura DevOpsEdson Celio
 
Metodologias interativas
Metodologias interativasMetodologias interativas
Metodologias interativasCriciúma Dev
 
Metodologias ágeis interativas
Metodologias ágeis interativasMetodologias ágeis interativas
Metodologias ágeis interativasElton Minetto
 
Introdução a DevOps e Continuous delivery agileday
Introdução a DevOps e Continuous delivery   agiledayIntrodução a DevOps e Continuous delivery   agileday
Introdução a DevOps e Continuous delivery agiledayCarlos Felippe Cardoso
 
ConnectionDay 2019 - Divinópolis - Transformação digital turbinada
ConnectionDay 2019 - Divinópolis - Transformação digital turbinadaConnectionDay 2019 - Divinópolis - Transformação digital turbinada
ConnectionDay 2019 - Divinópolis - Transformação digital turbinadaAndré Paulovich
 
Os príncipios por trás do DevOps
Os príncipios por trás do DevOpsOs príncipios por trás do DevOps
Os príncipios por trás do DevOpsGuilherme Cardoso
 
Xperience Superlógica 2018 - Infraestrutura Ágil
Xperience Superlógica 2018 - Infraestrutura ÁgilXperience Superlógica 2018 - Infraestrutura Ágil
Xperience Superlógica 2018 - Infraestrutura ÁgilGabriela Dias
 
DrupalCamp SP 2015 - DevOps, por onde começar? Por Sebastian Ferrari
DrupalCamp SP 2015 - DevOps, por onde começar? Por Sebastian FerrariDrupalCamp SP 2015 - DevOps, por onde começar? Por Sebastian Ferrari
DrupalCamp SP 2015 - DevOps, por onde começar? Por Sebastian FerrariTaller Negócio Digitais
 

Semelhante a DevOps - Operação contínua (20)

Quem e dev ops
Quem e dev opsQuem e dev ops
Quem e dev ops
 
Cultura DevOps - Integração entre infra e devel
Cultura DevOps - Integração entre infra e develCultura DevOps - Integração entre infra e devel
Cultura DevOps - Integração entre infra e devel
 
DevOps pela visão de um QA
DevOps pela visão de um QADevOps pela visão de um QA
DevOps pela visão de um QA
 
Cultura DevOps e integração entre infra e devel
Cultura DevOps e integração entre infra e develCultura DevOps e integração entre infra e devel
Cultura DevOps e integração entre infra e devel
 
O que é DevOps afinal?
O que é DevOps afinal?O que é DevOps afinal?
O que é DevOps afinal?
 
Webinar DevOps - Encontros Ágeis
Webinar DevOps - Encontros ÁgeisWebinar DevOps - Encontros Ágeis
Webinar DevOps - Encontros Ágeis
 
Palestra sobre DevOps na ASSESPRO-MG
Palestra sobre DevOps na ASSESPRO-MGPalestra sobre DevOps na ASSESPRO-MG
Palestra sobre DevOps na ASSESPRO-MG
 
TechNet - e-Book- Artigos sobre Test Manager
TechNet - e-Book- Artigos sobre Test ManagerTechNet - e-Book- Artigos sobre Test Manager
TechNet - e-Book- Artigos sobre Test Manager
 
DevOps - A Origem
DevOps - A OrigemDevOps - A Origem
DevOps - A Origem
 
E se ao invés de Dev e Ops for DevOps? Uma introdução a cultura DevOps
E se ao invés de Dev e Ops for DevOps? Uma introdução a cultura DevOpsE se ao invés de Dev e Ops for DevOps? Uma introdução a cultura DevOps
E se ao invés de Dev e Ops for DevOps? Uma introdução a cultura DevOps
 
DevOps é SIM uma questão de QA
DevOps é SIM uma questão de QADevOps é SIM uma questão de QA
DevOps é SIM uma questão de QA
 
Monografia-Devops
Monografia-DevopsMonografia-Devops
Monografia-Devops
 
Metodologias interativas
Metodologias interativasMetodologias interativas
Metodologias interativas
 
Metodologias ágeis interativas
Metodologias ágeis interativasMetodologias ágeis interativas
Metodologias ágeis interativas
 
Introdução a DevOps e Continuous delivery agileday
Introdução a DevOps e Continuous delivery   agiledayIntrodução a DevOps e Continuous delivery   agileday
Introdução a DevOps e Continuous delivery agileday
 
ConnectionDay 2019 - Divinópolis - Transformação digital turbinada
ConnectionDay 2019 - Divinópolis - Transformação digital turbinadaConnectionDay 2019 - Divinópolis - Transformação digital turbinada
ConnectionDay 2019 - Divinópolis - Transformação digital turbinada
 
Os príncipios por trás do DevOps
Os príncipios por trás do DevOpsOs príncipios por trás do DevOps
Os príncipios por trás do DevOps
 
DevOps - o que é?
DevOps - o que é?DevOps - o que é?
DevOps - o que é?
 
Xperience Superlógica 2018 - Infraestrutura Ágil
Xperience Superlógica 2018 - Infraestrutura ÁgilXperience Superlógica 2018 - Infraestrutura Ágil
Xperience Superlógica 2018 - Infraestrutura Ágil
 
DrupalCamp SP 2015 - DevOps, por onde começar? Por Sebastian Ferrari
DrupalCamp SP 2015 - DevOps, por onde começar? Por Sebastian FerrariDrupalCamp SP 2015 - DevOps, por onde começar? Por Sebastian Ferrari
DrupalCamp SP 2015 - DevOps, por onde começar? Por Sebastian Ferrari
 

Último

Apresentação Comercial VITAL DATA 2024.pdf
Apresentação Comercial VITAL DATA 2024.pdfApresentação Comercial VITAL DATA 2024.pdf
Apresentação Comercial VITAL DATA 2024.pdfCarlos Gomes
 
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)Alessandro Almeida
 
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...Dirceu Resende
 
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIAEAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIAMarcio Venturelli
 
Certificado - Data Analytics - CoderHouse.pdf
Certificado - Data Analytics - CoderHouse.pdfCertificado - Data Analytics - CoderHouse.pdf
Certificado - Data Analytics - CoderHouse.pdfLarissa Souza
 
From_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdf
From_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdfFrom_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdf
From_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdfRodolpho Concurde
 

Último (6)

Apresentação Comercial VITAL DATA 2024.pdf
Apresentação Comercial VITAL DATA 2024.pdfApresentação Comercial VITAL DATA 2024.pdf
Apresentação Comercial VITAL DATA 2024.pdf
 
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
[ServiceNow] Upgrade de versão - 2ª edição (Revisada, atualizada e ampliada)
 
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...
Apresentação Power Embedded - Descubra uma nova forma de compartilhar relatór...
 
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIAEAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
EAD Curso - CIÊNCIA DE DADOS NA INDÚSTTRIA
 
Certificado - Data Analytics - CoderHouse.pdf
Certificado - Data Analytics - CoderHouse.pdfCertificado - Data Analytics - CoderHouse.pdf
Certificado - Data Analytics - CoderHouse.pdf
 
From_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdf
From_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdfFrom_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdf
From_SEH_Overwrite_with_Egg_Hunter_to_Get_a_Shell_PT-BR.pdf
 

DevOps - Operação contínua

  • 1. © 2016 Stefanini Proprietary and Confidential 1 Continuous Operations DevOps
  • 2. © 2016 Stefanini Proprietary and Confidential 2 Luis Cesar Teodoro Arquiteto de Soluções na Stefanini Sou Arquiteto de software, entusiasta DevOps, especialista plataforma Microsoft por formação(MCSA, MCPD), Scrum Master por formação (CSM), consultor, palestrante e instrutor. Trabalho com TI há cerca de 15 anos, gosto muito de documentar e compartilhar o que tenho aprendido. Além disto tudo, sou casado, pai da Laura e do Mateus. Fique a vontade para entrar em contato :) Microsoft Certified Solutions Expert: SharePoint Microsoft Certified Solutions Developer: SharePoint, Web CSM: Certified ScrumMaster® Contato: lcteodoro@hotmail.com Linkedin: https://br.linkedin.com/in/luís-cesar-teodoro-298a6116
  • 3. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 3
  • 4. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 4 Papo sobre DevOps Normalmente querem que eu responda as seguintes perguntas: 1. O que significa DevOps? 2. DevOps é um movimento? 3. DevOps é uma filosofia, é um conceito ou uma cultura? 4. DevOps é uma metodologia? 5. DevOps é algum tipo de ambiente ou grupo de ferramentas ? 6. O especialista DevOps é um devel que entende de infra? 7. O especialista DevOps é um sysadmin que entende de devel? 8. DevOps é um cargo? é um setor ou um departamento? 9. DevOps só funciona em startups ou serve para o ambiente corporativo? 10. O DevOps é algo novo?
  • 5. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 5 Ao longo da apresentação eu pretendo responder a todas estas questões, mas para respondê-las vamos precisar entender algumas coisas antes.
  • 6. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 6 Como tudo começou? Precisamos ir ao cerne desta história. O movimento DevOps não começou em um lugar só, existem muitos lugares que dão pistas sobre as origens do termo, mas aparentemente as informações mais concretas sobre as origens deste movimento nos levam ao ano de 2008 - Neste ano, começaram a utilizar o termo infraestrutura ágil em algumas listas de discussão com foco em desenvolvimento ágil, e na mesma época durante evento Agile 2008, surgiram conversas que abordavam o tema metodologia ágil para a administração de infraestrutura, inspirada no modelo ágil de desenvolvimento, no entanto, foi a lista de discussão europeia com nome agile-sysadmin que começou a abordar o tema com propriedade, com isso ela ajudou a colocar os primeiros tijolos na ponte que faria a ligação entre developers e sysadmins. Um dos participantes desta lista era Patrick Debois (@patrickdebois), além de muito ativo ele era e ainda é um grande entusiasta do assunto.
  • 7. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 7 Como tudo começou? O termo DevOPS só foi criado de fato em 2009 durante a conferência Velocity da O’Reilly, nesta conferência John Allspaw (Etsy.com) e Paul Hammond (Typekit) apresentaram o trabalho10+ Deploys Per Day: Dev and Ops Cooperation at Flickr, veja abaixo os slides desta palestra. 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr from John Allspaw
  • 8. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 8 Como tudo começou? De lá para cá, Patrick Debois, Gildas Le Nadan, Andrew Clay Shafer, Kris Buytaert, JezzHumble, Lindsay Holmwood, John Willis, Chris Read, Julian Simpson, R.I.Piennar (mcollective) e muitos outros levaram o evento para diversas localidades, dentre elas: • New York 2012 • Rome 2012 • Mountain View 2012 • India 2012 • Tokyo 2012 • Austin 2012 • Goteborg 2011 • Bangalore 2011 • Melbourne 2011 • Mountain View 2011 • Boston 2011 • Göteborg 2011 • Sao Paulo 2010 • Hamburg 2010 • Mountain View 2010 (video intro) • Sydney 2010 • Ghent 2009
  • 9. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 9 Como tudo começou? Na abertura do evento DevOpsDay há sempre um vídeo de intro, veja dois deles: Ghent 2009 https://www.youtube.com/watch?v=EOveXZhJpr4 Mountain View 2010 https://www.youtube.com/watch?v=a0N2ugDwi5g
  • 10. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 10 DevOps Manifest Apesar de terem organizado o DevOpsDays em diversos países, não foi estabelecido um manifesto para o assunto, logo existem muitas interpretações acerca deste termo. Mas antes de argumentar acerca do possível conteúdo de um manifesto DevOps, primeiro temos que entender a dinâmica na relação entre as áreas de infraestrutura (infra) e desenvolvimento (devel).
  • 11. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 11 Analisando Infra e Devel Para entender melhor o que DevOps significa, precisamos então analisar de forma prática e direta a vida de sysadmins, desenvolvedores e o cotidiano destas áreas. Vamos imaginar - hipoteticamente - uma empresa de comunicação que desenvolve aplicações web em sua maioria para portais de notícias, e em alguns casos também faz aplicações web internas (rh, financeiro, administrativo), nessa empresa o devel trabalha com PHP, PYTHON, RUBY e JAVA. Para um melhor entendimento, considere as duas características abaixo como cotidianas nesta empresa fictícia: O Devel está começando a trabalhar com metodologias ágeis (proativo, evolutivo e contínuo). A Infra continua trabalhando no modelo tradicional de administração (manual, caótico e reativo).
  • 12. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 12 Infra em foco A infra é composta em parte pelos sysadmins, estes rapazes e moças tem a missão de manter os sistemas funcionando, são eles que fazem os deploys e os rollbacks das aplicações do devel, é responsabilidade deles manter o ambiente de produção intacto. Eles se preocupam com segurança, estabilidade e principalmente com o acordo de nível de serviço (SLA) de cada produto sob sua responsabilidade, esta preocupação é fundamental para o negócio. Em resumo, a infra (sysadmins) se preocupa em proteger o valor do negocio.
  • 13. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 13 Devel em foco O devel é composto em parte por desenvolvedores, estas moças e rapazes trabalham com lógica e criatividade, eles passam boa parte de seu tempo codificando soluções, e focam seu trabalho nos requisitos que o analista conseguiu mapear junto ao cliente. Os desenvolvedores estão constantemente criando e aprimorando suas aplicações, com isto novas versões são criadas e precisam ser disponibilizadas, assim seus clientes poderão usufruir dos recursos solicitados. Nova versão significa novo deploy, e caso ocorra algum problema, isto irá demandar um rollback, ambos procedimentos envolvem equipes de infra. Em resumo, podemos dizer que o devel se preocupa em aumentar o valor do negócio.
  • 14. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 14 Onde está o conflito?
  • 15. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 15 Onde está o conflito? Os desenvolvedores querem colocar suas aplicações no ar o mais rápido possível, no entanto os sysadmins querem ter certeza que a aplicação está estável o suficiente para entrar em produção sem gerar incidentes. Nos últimos anos esse conflito foi latente no mundo de TI, algumas empresas tinham regras tão rígidas que só permitiam deploy uma vez por semana - em casos mais rígidos apenas uma vez por mês, tudo isto pensando em proteger o negócio. É claro que a infra trabalhando com os métodos que estava acostumada (deploy 1 vez por semana e manual) não dava vazão as demandas, e também é óbvio que o devel não possuía uma infra adequada para fazer o desenvolvimento de forma contínua.
  • 16. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 16 Onde está o conflito? Além de tudo isso, normalmente o devel não conhece e não tem como prever aspectos importantes relativos a infra que fica de cara para o cliente, portanto, quando a aplicação vai para produção, normalmente ocorrem - constantes - pequenos incidentes que geram uma enorme perda de valor no negócio. Traduzindo, são aqueles ajustes na aplicação que precisam ser feitos de última hora pois o ambiente devel é completamente diferente da produção. O cliente por sua vez reclama - com razão - e depois a gerência de TI ficava tentando encontrar o dono do problema (caça as bruxas), de um lado devel dizendo que infra é engessada, lenta e que não oferece um ambiente adequado para desenvolverem suas aplicações, do outro lado a infra dizendo que o devel faz código ruim e instável e que não é culpa deles se a aplicação não funciona. Eu sou de infra há muitos anos, mas tenho que dizer que a infra devido a culturas arcaicas de administração, heranças do tempo dos mainframes, tem mais culpa no cartório neste cenário, porém o devel também tem seus problemas, afinal, como estão começando a aplicar métodos ágeis, ainda estão criando a cultura de execução de testes e garantia de qualidade (QA).
  • 17. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 17 Incidentes
  • 18. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 18 Incidentes Quando ocorre algum incidente, você vai ouvir da infra falando para o devel que o problema não são as máquinas, é o código, e certamente o devel vai falar para infra que o problema não é o código, são as máquinas, e provavelmente ainda vão dizer que o sistema está funcionando no notebook deles, e infelizmente isso será algo cotidiano.
  • 19. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 19 Incidentes Espero que neste ponto você já esteja enxergando o problema
  • 20. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 20 Incidentes É preciso entender que infra e o devel trabalham em nichos, cada um no seu quadrado, cada um em sua realidade e nenhum deles está muito disposto a mudar sua cultura, nenhum deles está disposto a ceder. A infra não conhece o devel e não sabe como mudar para ajudá-los, o devel não conhece a infra e não sabe como pedir o que precisam. No final das contas, as pessoas não conseguem estabelecer uma forma sadia e eficiente de comunicação, e com isso, não existe trabalho colaborativo entre estas duas áreas.
  • 21. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 21 O combustível do conflito
  • 22. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 22 O combustível do conflito Acima eu apresentei o conflito comum entre as áreas, porém existe o combustível que o mantém aceso, e esse combustível é o comportamento do sysadmin, portanto, há de fato uma razão para se ter tanto ódio deles, vamos a elas:
  • 23. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 23 O combustível do conflito •Eles falam não •Eles falam não pela segunda vez •Eles falam não pela terceira vez •Eles falam não o tempo todo por diversas razões, para diversos pedidos •Eles demoram, atrasam e perdem prazos de atendimento •Eles se recusam a quebrar as coisas mesmo que seja para encontrar o problema •Eles se preocupam com UPTIME e não com o negócio •Eles acham que o devel só quer saber de perfumarias e coisas do gênero •Eles não se esforçam para ajudar o devel a encontrar o problema •Eles acham que o problema do devel não é problema deles •Eles não conseguem enxergar o negócio e não enxergam que infra e devel são parte de um todo
  • 24. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 24 O combustível do conflito E isso tudo faz parte daquele comportamento arcaico que eu já mencionei, eu quis reforçar isto pois é bom mostrar as raízes de um problema para ajudar na reflexão do que é preciso mudar. Veja que tal comportamento é inaceitável e incompatível com o mundo de hoje, mesmo assim ainda é muito comum encontrar pessoas que possuem este tipo de atitude e perfil.
  • 25. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 25 Uma pitada de realidade Lembra que eu disse que a infra se preocupa em proteger o negócio e o devel se preocupa com as formas de agregar valor ao negócio? Esqueça o que eu disse, isso funcionava nos anos 70/80/90, mas hoje isso não é suficiente. A infra deve entender que sua obrigação é oferecer os meios para fazer o negócio fluir, e isso também é papel do devel. Ambas equipes precisam mudar a forma de pensar e de agir, porém é preciso ter consciência de que mudanças estão associadas a problemas, uma mudança pode quebrar seu produto e afetar o seu negócio. Então qual é a receita mágica? Como mudar sem afetar o negócio?
  • 26. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 26 Mudanças necessárias A infra precisa evoluir, e precisa fazer isto rapidamente. O devel precisa ter controle de todas as fases do deploy. A infra precisa começar a trabalhar de forma automatizada e dinâmica, precisa ser mais veloz para subir novos ambientes ou mesmo reconstruir/duplicar os ambientes existentes para suprir as necessidades do devel, não dá mais para trabalhar de forma manual e usar as mesmas metodologias da época dos mainframes. O devel precisa conseguir passar para infra suas necessidades de forma clara, e tem que se esforçar para fazer a infra entender isto - e eles não vão entender na primeira vez.
  • 27. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 27 Busca de soluções E foi a busca de soluções para estas necessidades que motivou importantes discussões no mundo da TI, foi então que começaram a falar de ‘Infraestrutura ágil’ no ano de 2008, vamos agora entender o que é isso.
  • 28. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 28 Infraestrutura ágil Infraestrutura como código A discussão acerca de infraestrutura ágil ganhou força com o crescimento de duas tendências, são elas virtualization e cloud computing. Desde 2003 empresas começaram a conviver com ambientes virtualizados, logo um parque com poucas máquinas físicas poderia se tornar um parque com dezenas máquinas virtuais, e após o recente advento da Cloud, dezenas de máquinas virtuais podem se tornar centenas ou milhares de instâncias a serem administradas na nuvem.
  • 29. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 29 Infraestrutura como código Não havia mais espaço para se trabalhar infraestrutura da forma tradicional, foi necessário dar um passo a diante e pensar em infraestrutura como código, principalmente quando paramos para analisar o recente boom das startups, empresas pequenas com produtos de enorme alcance, produtos que rodam em centenas de instâncias na nuvem, atendendo milhões de usuários, e tudo isso é administrado por equipes mínimas. O objetivo é fazer deploy não só de aplicações, mas deploy de infraestrutura de forma rápida e controlada. Isso significa que se você precisa subir um ambiente JBOSS você vai fazer isto em poucos minutos e não em dias.
  • 30. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 30 Ferramentas de infraestrutura ágil Quando se fala em infraestrutura ágil o que vem a mente são ferramentas, e de fato elas são parte disto. Basicamente temos três tipos de ferramentas, são elas: 1.Orquestradores 2.Ferramentas para gerenciamento de configurações 3.Ferramentas para bootstrapping e provisionamento
  • 31. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 31 Ferramentas de infraestrutura ágil Orquestradores são ferramentas que nos permitem executar comandos e controlar nodes/instâncias de nosso parque em tempo real. Alguns destes são Fabric, Capistano, Func e Mcollective. Ferramentas de gerência de configuração normalmente controlam estados de seu sistema, ajudam a centralizar toda as configurações e facilitam a administração e criação de novos ambientes. Algumas delas são Puppet, Chef, Cfegine e Salt. Ferramentas de bootstrapping são aquelas que nos ajudam a instalar um sistema operacional seja em uma máquina física, seja em um máquina virtual, seja em uma instância na nuvem, dentre elas temos alguns provedores de CLOUD como AWS e Rackspace que já oferecem isso nativamente, existem também ferramentas como o Kickstart e Cobbler que atuam neste segmento.
  • 32. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 32 Ferramentas de infraestrutura ágil A combinação destes três tipos de ferramentas nos permite ter o que chamamos de infraestrutura ágil. Mas apesar da qualidade e dos ganhos em utilizar tais tecnologias, a ferramenta sozinha não resolverá seus problemas, é preciso mudar a cultura e a forma de trabalhar a infraestrutura.
  • 33. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 33 Equipe de infraestrutura ágil Equipes que trabalham com infraestrutura ágil também precisam de um método diferenciado de organização, normalmente estas equipes estão trabalhando seguindo estes eixos: Versionamento do código e arquivos de configuração (git) Organização de atividades de forma visual (KANBAN BOARD) Trabalho em pares Divisão das atividades em sprints Reuniões ágeis diárias (standup meeting de 10 minutos - em pé) Reuniões ágeis periódicas (retrospectiva e planejamento de sprints). Parece com SCRUM mas não é, mas é fortemente inspirado nele e no Kanban.
  • 34. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 34 Então DevOps e Infraestrutura ágil são a mesma coisa? Não, infraestrutura ágil é parte da cultura DevOps. DevOps depende de infraestrutura ágil, mas ainda tem muito mais. Apesar da evolução da infra, ainda falta algo que conecte as duas áreas, precisamos de um agente de mudanças principalmente no meio corporativo.
  • 35. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 35 Cultura DevOps Chegou a hora de entrar neste assunto, agora nós vamos aprofundar nossos estudos em relação a cultura DevOps.
  • 36. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 36 Características da cultura DevOps Para entender a cultura DevOps sem fazer um texto muito longo, vou pontuar as suas principais características. Patrick Debois (foi quem cunhou o termo) diz que DevOps essencialmente é uma cultura, e a descreve utilizando 4 eixos, são eles:
  • 37. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 37 Em relação as características da cultura Cultura Colaboração Fim das divisões Relação saudável entre as áreas Mudança de comportamento Automação Deploy Controle Monitoração Gerência de configuração Orquestração Avaliação Métricas Medições Performance Logs e integração Compartilhamento O feedback é tudo Boa comunicação entre a equipe
  • 38. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 38 Em relação as características da cultura "UM TOLO COM UMA FERRAMENTA AINDA É UM TOLO"
  • 39. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 39 Em relação as características técnicas Um ambiente DevOps deve ter/possuir/oferecer/permitir: 1. Infraestrutura como código 2. Orquestração de servidores 3. Gerência de configurações 4. Provisionamento dinâmico de ambientes 5. Controle de versões compartilhado entre infra e devel 6. Ambiente de desenvolvimento, teste e produção (no mínimo) 7. O ambiente de devel deve possibilitar TDD 8. Infra deve participar dos projetos desde o início [1] 9. Infra deve participar das reuniões de devel [2] 10. Devel deve participar das reuniões de infra [3] 11. Ambiente de entrega contínua [4] 12. Os desenvolvedores devem conseguir fazer o deploy sem interferência da infra [5] 13. Monitoramento eficaz com processamento adequado dos eventos e métricas 14. Capacidade de resposta rápida a incidentes e problemas 15. Backup e restore confiável
  • 40. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 40 Em relação as características técnicas Infra deve participar dos projetos desde o início [1] O devel precisa envolver a infra nos projetos desde o início - isso significa participar das reuniões técnicas ou SCRUM, afinal sem a infra não há projeto, e além disto, quanto mais problemas foram resolvidos durante o projeto - com ajuda da infra, menos problemas serão expostos aos clientes.
  • 41. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 41 Em relação as características técnicas Infra deve participar das reuniões de devel [2] A infra também precisa observar quais são as metas da empresa a longo prazo, principalmente aquelas ligadas ao devel, pois enxergando onde o devel quer chegar, ela pode se programar melhor para ter certeza que a infraestrutura tecnológica estará preparada para atendê-los quando esse momento chegar.
  • 42. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 42 Em relação as características técnicas Devel deve participar das reuniões de infra [3] A infra precisa envolver o devel em suas reuniões técnicas para que o devel entenda e tenha ciência da realidade da infra, assim eles vão conseguir enxergar suas qualidades, atribuições, planos de melhorias, atualizações programadas, agendas de manutenção, eles vão conhecer os recursos disponíveis e também descobrir a limitações da equipe, sejam elas técnicas, sejam materiais. Além disto, o devel pode ser um grande aliado da infra na solução de problemas, afinal o conhecimento que o devel traz pode ajudá-los a melhorar a forma com que administram seu ambiente, tornando este processo mais eficiente.
  • 43. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 43 Em relação as características técnicas Ambiente de entrega contínua [4] O devel precisa adotar alguma metodologia de entrega ou desenvolvimento contínuo e a infra precisa entender esse processo para que juntos criem os ambientes com as ferramentas certas.
  • 44. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 44 Em relação as características técnicas Os desenvolvedores devem conseguir fazer o deploy sem interferência da infra [5] A infra precisa ceder um pouco e evoluir, precisa oferecer ao devel um ambiente adequado onde eles sejam o dono do produto, onde o devel consiga fazer todo o ciclo de desenvolvimento de forma direta, o devel precisa conseguir gerar e controlar o código, precisa fazer o commit com segurança, precisa fazer o build, testar o build, validar a aplicação e entregar a nova versão de forma transparente sem que para isso precise passar por um burocrático e engessado processo de mudança.
  • 45. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 45 Em relação aos valores humanos Para a adoção da cultura funcionar, a equipe precisa observar e exercitar os seguintes valores: •Confiança no trabalho de sua equipe •Respeito pessoal e profissional por todos da equipe •Sinceridade sobre eventos e incidentes ocorridos •Honestidade sobre as causas dos incidentes (não esconda nada da sua equipe) •Entendimento de que o problema é responsabilidade de todos •Entendimento de a solução é responsabilidade de todos •Entendimento de que os resultados são o reflexo do trabalho de toda a equipe •Comunicação efetiva e dinâmica •Postura construtiva sempre •Espírito de colaboração
  • 46. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 46 Em relação a forma de trabalho É recomendável que a equipe: Internalize e adapte métodos ágeis como KABAN e SCRUM para seu dia-a-dia Aprofunde estudos em entrega contínua Aprofunde estudos em gerência de configurações e orquestração
  • 47. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 47 Características técnicas Valores humanos e forma de trabalhar Espero que tenha ficado claro para você. Em relação a forma de trabalho
  • 48. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 48
  • 49. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 49 Após observar as principais características deste movimento, normalmente pensamos em como aplicar isto em nosso meio. Para ajudar na reflexão vamos avaliar o meio startup e o meio corporativo. Aplicando a cultura
  • 50. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 50 A cultura DevOps combina muito com startups, nestes locais normalmente já se trabalha desenvolvimento utilizando metologias ágeis, foi inclusive neste nicho em que começaram a discutir infraestrutura ágil - a precursora do movimento DevOps, portanto, as pessoas deste meio conseguem absorver os conceitos e a cultura DevOps sem grandes dificuldades, eles conseguem compreender os preceitos de colaboração e feedback pois já fazem isto em seu dia-a-dia. Quem está uma startup não tem as amarras e vícios da corporação, este é um grande facilitador e não é necessário nenhum tipo de intervenção para internalizar a cultura, a partir do estímulo de um líder as pessoas começarão a estudar e aplicar DevOps naturalmente. Na startup normalmente não existe divisões, departamentos, todos trabalham juntos e isso também é um facilitador, afinal não existem barreiras para se comunicar. A realidade no ambiente startup
  • 51. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 51 A corporação não funciona como a startup, lá existe burocracia e o uso vicioso de métodos ultrapassados, portanto não bastará o estímulo da alta hierarquia para que equipes de infra e devel comecem a vivenciar a cultura DevOps, neste tipo de ambiente, em minha opinião pessoal e profissional, é necessário intervir cirurgicamente para conseguir internalizar a cultura DevOps. Em resumo, você precisa trazer alguém - de fora - que conhece DevOps para que esta pessoa passe a contaminar os demais. Esse processo é lento, mas se o especialista tiver os meios e o apoio do alto escalão, mudanças fantásticas poderão ocorrer. A realidade no ambiente corporativo
  • 52. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 52 Ele foi trazido para atuar como um agente de mudanças, ele precisa contaminar as áreas e mostrar que a cultura DevOps funciona. O especialista DevOps no meio corporativo
  • 53. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 53 Está na casa dos 30 anos ou mais É um profissional sênior em infraestrutura Tem um bom background em desenvolvimento Tem um bom background em metodologias ágeis Tem sólidos conhecimentos em soluções opensource e similares Trabalha intensamente com automação e infraestrutura como código Característica gerais de um especialista DevOps em 2013
  • 54. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 54 Este especialista em DevOps terá um pé na infra e outro no devel, em alguns casos também terá o pé na área de garantia de qualidade (QA). Onde esse especialista atua? Ele é a cola que faltava para unir infra, devel e qualidade.
  • 55. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 55 Ele será a ponte entre as áreas de infra e devel, ele conhece a infra a fundo e entende de forma ampla processos de desenvolvimento ágil. Como esse especialista atua?
  • 56. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 56 Ele participa dos projetos de desenvolvimento desde o seu nascimento, seu foco é oferecer os recursos para os desenvolvedores trabalhem da forma mais eficiente, além disto, com sua ótica de infra ele toma todas as precauções para que os aspectos de segurança, monitoramento, eficiência e escalabilidade sejam observados desde o início do projeto. O DevOps vai ainda estudar todo o processo de desenvolvimento e definir - em conjunto com o devel - as ferramentas que irão permitir um processo de desenvolvimento e entrega contínua. Após definir ele vai instalar e manter esse infra. Alguns DevOps conseguem até avaliar o código do produto e enxergar problemas de performance, esse tipo de visão sistêmica e raciocínio rápido são diferencias importantes para uma entrega com mais qualidade. Pé no devel
  • 57. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 57 Na infra ele é o principal agente de mudanças, é ele que vai puxar a fila para iniciar a implantação de uma infraestrutura ágil, ele domina as ferramentas de orquestração, gerência de configuração e provisionamento e vai usar esse conhecimento para que a equipe passe a trabalhar a infraestrutura como código. Este profissional também vai ajudá-los a mudar seu comportamento e cultura, ele vai orientá-los nos métodos ágeis de execução de atividades, aqueles inspirados no SCRUM e KANBAN. Pé na infra
  • 58. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 58 Para internalizar DevOps, normalmente estas barreiras não existem, infra e devel devem habitar o mesmo espaço, sem paredes, sem divisórias, todos na mesma sala, isso é fundamental para extinguir os nichos e criar uma equipe mais unida e coesa. Respondendo a pergunta, ele deve ficar junto com as duas equipes se for possível, esse é o melhor dos mundos. Se não for possível ficarem todos juntos, o especialista deve se esforçar para interagir com as duas equipes diariamente. Ele vai ser o agente de mudanças até que infra e devel comecem a entender e adotar a cultura de forma natural. Ele fica na infra ou no devel?
  • 59. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 59 Vamos avaliar dentro da ótica de cada área o que melhora com a adoção da cultura DevOps Quais os ganhos em adotar a cultura DevOps?
  • 60. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 60 Infraestrutura como código (equipe para de administrar e passa a desenvolver a infra) Infra mais eficiente e rápida usando métodos ágeis Equipe de Infra mais organizada Equipe de Infra se comunicando melhor Infra fazendo mais em menos tempo com menos gente Ambientes de gerência de configuração, orquestração e provisionamento implantados Deploys de infra (novos ambientes) mais rápidos e seguros => entrega rápida Ambiente padronizado e sob controle Feedback rápido em todas as atividades de infra Ganhos para a infra
  • 61. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 61 Devel tem ambiente mais adequado para trabalhar (dev/teste/prod) Devel passa a contar com ambiente de desenvolvimento contínuo Devel passa a contar com testes automatizados Deploys de apps (novas versões) mais rápidos e seguros => entrega rápida Feedback rápido em todas as fases de desenvolvimento Ganhos para o devel
  • 62. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 62 Acaba a divisão Infra vs Devel (acaba a guerra) Infra participa dos projetos e acompanha de perto tudo o que acontece Infra participando resulta em melhor planejamento do ambiente de produção Infra participando resulta em monitoramento mais eficaz da aplicação Devel começa a compreender melhor a infra e isso resulta em um produto melhor Equipes trabalhando em conjunto para aumentar o valor do negócio Ganhos mútuos Infra/Devel
  • 63. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 63 Melhor comunicação entre devel e infra (diminuição de conflitos) Soluções rodando com maior estabilidade e desempenho Entregas mais rápidas Menor tempo de paradas Diminuição de incidentes Diminuição de custos Diminuição de riscos Aumento do valor do negócio Ganhos para a empresa
  • 64. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 64 Vamos partir para perguntas e respostas no melhor estilo FAQ. Indo direto ao ponto (e respondendo as perguntas do início) Amarrando as pontas
  • 65. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 65 DevOps está diretamente relacionado a um melhor feedback entre as áreas de TI. DevOps é um movimento, é um conceito, é uma cultura e uma filosofia, e não existe uma explicação fácil. DevOps possibilita diminuição dos riscos de mudanças através do uso de um ferramental adequado e adoção de uma cultura específica. DevOps busca entregar sistemas melhores, com menor custo, fazendo isto de forma mais rápida e com menor risco. DevOps envolve a área de Infra e Devel primariamente. DevOps é pura metodologia ágil tanto na Infra quanto no Devel. Respondendo sobre o termo DevOps:
  • 66. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 66 DevOps só funciona se as equipes de infra e devel estiverem dispostas a ceder, mudar sua cultura e método de trabalho. DevOps não é um cargo, tão pouco um setor ou departamento, é uma cultura. DevOps não está restrito ao ambiente das startups, é possível utilizar essa cultura no meio corporativo. DevOps não é algo novo, as boas práticas estão ai desde de sempre, logo esse ‘juntado’ de práticas não é novidade para muita gente, mas para alguns serve como uma boa referência para aplicar mudanças necessárias. Respondendo sobre o termo DevOps:
  • 67. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 67 O especialista em DevOps de hoje é normalmente alguém que conhece muito de infra e tem uma base sólida de devel. O especialista em DevOps também pode ser alguém que veio do devel e que tem uma base sólida de infra (esse geralmente é mais completo). Respondendo sobre o especialista em DevOps:
  • 68. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 68 Não existe um manual de conduta para dizer se você é um DevOps ou não, mas é bastante comum encontrar profissionais que estão estudando infraestrutura ágil e se denominando DevOps. A AWS (Amazon) lançou em 2015 a certificação DevOps. Se você está buscando melhorar seu ambiente, entregar mais rápido, entregar algo com mais qualidade, algo que minimize custos, algo que diminua riscos, algo que envolva automatização pesada, se você trabalha infraestrutura como código, se você está atuando como um agente de mudanças em sua equipe, penso que DevOps é um termo adequado para descrever o seu trabalho, mesmo que não esteja diretamente envolvido com uma equipe de Devel. Eu trabalho com infra ágil, sou um DevOps?
  • 69. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 69 Como eu já mencionei não existe uma metodologia clara, DevOps ainda é um movimento em constante construção e definição, eu citei uma série de melhorias que fazem parte da cultura DevOps, cabe a cada empresa ou a cada gestor estudar e descobrir a melhor forma de combinar essas pequenas receitas técnicas e aplicar em seu ambiente. Não existe receita mágica ou caminho rápido
  • 70. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 70 Vamos ver na pratica como funciona a junção de tudo isso. DevOps na Pratica
  • 71. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 71
  • 72. Continuous Operations DevOps © 2016 Stefanini Proprietary and Confidential 72
  • 73. Duvidas??? © 2016 Stefanini Proprietary and Confidential 73
  • 74. Links Uteis © 2016 Stefanini Proprietary and Confidential 74 Guto Carvalho http://gutocarvalho.net/ DevOps http://devops.com/ Microsoft Virtual Academy https://mva.microsoft.com/ Windows Nano Server 2016
  • 75. OBRIGADO! Luis Cesar Teodoro Arquiteto de Soluções lcteodoro@Hotmail.com © 2016 Stefanini Proprietary and Confidential 75 Dream big, work smart, deliver fast.