07 - Cultura e Práticas DevOps (2022) - 2 Iniciacao de Cultura e Praticas DevOps

Prévia do material em texto

Iniciação de Práticas 
DevOps
Marco Mendes
Como Escolher o Ponto 
de Partida para DevOps
Marco Mendes
A escolha de um fluxo de 
valor para a transformação 
DevOps merece consideração 
cuidadosa. 
Não só o fluxo de valor que 
escolhemos ditam a 
dificuldade de nossa 
transformação, mas também 
dita quem estará envolvido 
na transformação. 
Isso afetará a forma como 
precisamos organizar em 
equipes e como podemos 
melhor habilitar as equipes e 
os indivíduos nelas.
Caso Nordstrom
Varejista de moda com faturamento de 13 
bilhões anuais em 2014
Caso Nordstrom
A gerente sênior de sistemas Kissler e a equipe de 
gerenciamento de tecnologia da Nordstrom tiveram que 
decidir onde começar seus esforços de transformação inicial. 
Eles não queriam causar agitação em todo o sistema. 
Preferivelmente, quiseram centrar-se sobre áreas muito 
específicas do negócio de modo que pudessem 
experimentar e aprender. 
Seu objetivo era demonstrar vitórias antecipadas, o que 
daria a todos a confiança de que essas melhorias poderiam 
ser replicadas em outras áreas da organização. Como 
exatamente isso seria alcançado ainda era desconhecido.
Fonte: DevOps Enterprise Summit in 2014 and 2015.
Caso Nordstrom
Eles se concentraram em três áreas: a aplicação móvel do 
cliente, seus sistemas de restaurante na loja, e suas 
propriedades digitais. 
Cada uma dessas áreas tinha metas de negócios que não 
estavam sendo atendidas; assim, eles foram mais 
receptivos a considerar uma maneira diferente de trabalhar. 
As histórias dos dois primeiros são descritas a seguir.
Fonte: DevOps Enterprise Summit in 2014 and 2015.
Caso Nordstrom – App Móvel
• A aplicação móvel da Nordstrom tinha experimentado 
um começo muito ruim. Como a gerente sênior 
Courtney Kissler disse, "nossos clientes foram 
extremamente frustrados com o produto, e tivemos 
revisões uniformemente negativas na App Store”. 
• Pior, a estrutura e os processos existentes (aka "o 
sistema") haviam sido pensados para que pudessem 
liberar atualizações duas vezes por ano. " 
• Em outras palavras, qualquer correções para o 
aplicativo teria que esperar meses para chegar ao 
cliente.
Fonte: DevOps Enterprise Summit in 2014 and 2015.
Caso Nordstrom – App Móvel
• Seu primeiro objetivo era permitir lançamentos mais rápidos ou demanda, 
proporcionando uma iteração mais rápida e a capacidade de responder aos comentários 
dos clientes. Eles criaram uma equipe de produto dedicada que foi dedicada 
exclusivamente a apoiar o aplicativo móvel, com o objetivo de permitir que a equipe seja 
capaz de implementar, testar e entregar de forma independente o valor ao cliente. Ao 
fazer isso, eles não teriam mais que depender e coordenar com dezenas de outras 
equipes dentro da Nordstrom. 
• Além disso, eles se mudaram de planejamento uma vez por ano para um processo de 
planejamento contínuo. O resultado foi um backlog único priorizado de trabalho para o 
aplicativo móvel com base na necessidade do cliente
• As prioridades conflitantes que existiam quando a equipe tinha que suportar vários 
produtos sumiram.
• Durante o ano seguinte, eles eliminaram o teste como uma fase separada do trabalho, 
ou seja integrado ao trabalho diário de todos. 
• Eles dobraram a vazão de requisitos que estão sendo entregues por mês e reduziram 
os defeitos pela metade— criando um resultado bem-sucedido.
Fonte: DevOps Enterprise Summit in 2014 and 2015.
Caso Nordstrom – Restaurantes
• A Nordstrom tinha completado, em 2013, 11 
reestruturações dos restaurantes, que exigiu 
mudanças para as aplicações na loja, causando uma 
série de incidentes com impacto no cliente. 
• E eles haviam planejado mais 44 dessas 
reestruturações para 2014 — quatro vezes mais do 
que no ano anterior.
• Como Kissler afirmou, "um de nossos líderes de 
negócios sugeriu que triplicássemos o tamanho de 
nossa equipe para lidar com essas novas demandas, 
mas eu propus que tivéssemos que parar de jogar 
mais corpos no problema e, em vez disso, 
melhorarmos a maneira como trabalhamos".
Fonte: DevOps Enterprise Summit in 2014 and 2015.
Caso Nordstrom – Restaurantes
• Eles foram capazes de identificar áreas problemáticas, 
como em seus processos de recebimento e implantação de 
trabalho, que é onde eles concentraram seus esforços de 
melhoria. 
• Eles foram capazes de reduzir os tempos de execução de 
implantação de código em 60% e reduzir o número de 
incidentes de produção 60% a 90%.
• Ela disse: "Este é um desafio audacioso. Nós tínhamos 
muitos problemas em nosso estado atual. O processo e os 
tempos de ciclo não eram medidos consistentemente 
através das equipes, nem eram visíveis. Nossa primeira 
condição de destino nos obrigou a ajudar todas as nossas 
equipes a medir, torná-la visível e realizar experimentos 
para começar a reduzir seus tempos de processo, iteração 
por iteração."
Fonte: DevOps Enterprise Summit in 2014 and 2015.
Caso Nordstrom – Avaliação Geral
• Kissler concluiu: "a partir de uma perspectiva 
de alto nível, acreditamos que técnicas como 
mapeamento de fluxo de valor, reduzindo 
nossos tamanhos de lote em direção a fluxo de 
tamanho único, bem como a utilização de 
entrega contínua e microsserviços vai nos levar 
ao nosso estado desejado. No entanto, 
enquanto ainda estamos aprendendo, estamos 
confiantes de que estamos indo na direção 
certa, e todos sabem que esse esforço tem o 
apoio dos mais altos níveis de gestão. "
Fonte: DevOps Enterprise Summit in 2014 and 2015.
Resumo
• Caso Nordstrom - Práticas:
• Tornar o trabalho visível
• Medir os tempos de entrega e tempos 
de ciclo
• Pequenos experimentos
• Melhoria contínua
• Dicas para a escolha o fluxo de valor:
• Começar de onde você está
• Buscar mudanças evolucionárias
• Rode pequenos experimentos
• Gere aprendizados o mais rápido 
possível
• Instrumente os tempos de entrega para 
demonstrar resultados.
Iniciativas DevOps
Verdes e Marrons
Marco Mendes
Sistemas Verdes
Greenfield
Sistemas Marrons
Brownfield
Projetos DevOps verdes
Projetos DevOps verdes são 
normalmente pilotos para 
demonstrar 
a viabilidade de nuvens públicas 
ou privadas, criação de 
automação de implantação e 
ferramentas semelhantes.
Caso Real – E-Social em MG, 2018
Microsserviços
1
2 3 4
5
67
Projetos DevOps marrons
Na outra extremidade do espectro são projetos Devops marrons. 
Estes são produtos ou serviços existentes que já estão servindo 
os clientes e têm sido potencialmente em operação por anos ou 
mesmo décadas.
Projetos marrons muitas vezes vêm com quantidades 
significativas de dívida técnica, como não ter nenhuma 
automação de teste ou em execução em plataformas sem 
suporte. 
No exemplo Nordstrom apresentado anteriormente 
anteriormente, tanto os sistemas de restaurante na loja e 
sistemas de comércio eletrônico foram projetos marrons.
Casos populares DevOps em 
projetos marrons
DevOps para projetos verdes e marrons
• Embora muitos acreditem que DevOps é 
principalmente para projetos verdes, o DevOps 
tem sido usado para transformar com sucesso 
projetos marrons de todos os tipos. 
• Mais de 60% das histórias de transformação 
compartilhadas no DevOps Enterprise Summit em 
2014 foram para projetos marrons. Nesses casos, 
houve uma grande lacuna de desempenho entre 
o que o cliente precisava e o que a organização 
estava entregando atualmente, e as 
transformações do DevOps criaram um tremendo 
benefício comercial.
Aprendizado da indústria
Um dos achados do 2015 estado do 
relatório DevOps validado que a idade 
da aplicação não foi um preditor
significativo de desempenho; em vez 
disso, o desempenho previsto era se o 
aplicativo foi arquitetado (ou poderia 
ser re-arquitetado) para testabilidade
e implantabilidade.
Fonte: https://puppet.com/resources/whitepaper/2015-state-devops-report
Resumo
• Iniciativas DevOps verdes e 
marrons.
• Projetos verdes são mais simples 
para demonstrar resultados 
preliminares.
• Projetos marrons são mais 
complexos, mas podem gerar 
transformaçõesmais profundas.
Escolha de pessoas e áreas 
em iniciativas DevOps
Marco Mendes
Curva de Difusão de Inovações
Fonte: The Technology Adoption Curve (Source: Moore and McKenna,
Crossing The Chasm, 15.)
Não comece com o time mais conservador
e não faça big bangs
Especialmente nos estágios iniciais, não 
vamos gastar muito tempo tentando 
converter os grupos mais conservadores. 
Em vez disso, vamos focar a nossa energia 
na criação de sucessos com grupo com 
menor aversão ao risco e construir a 
nossa base de lá 
Mesmo que tenhamos os mais altos 
níveis de patrocínio executivo, evitamos a 
abordagem Big Bang, escolhendo em vez 
de focar nossos esforços em algumas 
áreas da organização, garantindo que 
essas iniciativas sejam bem-sucedidas e 
expandindo de lá
Ache os inovadores e os primeiros adeptos
No começo, nós focalizamos 
nossos esforços em equipes 
que realmente querem ajudar. 
Estes são nossos companheiros 
de viagem que são os 
primeiros a se voluntariar para 
iniciar uma jornada DevOps. 
No cenário ideal, estas são 
também as pessoas que são 
respeitadas e têm um alto grau 
de influência sobre o resto da 
organização, dando a nossa 
iniciativa mais credibilidade.
Construa massa crítica e maioria silenciosa
Na próxima fase, buscamos 
expandir as práticas de DevOps 
para mais equipes e fluxos de valor 
com o objetivo de criar uma base 
estável de suporte.
Ao trabalhar com equipes que são 
receptivas às nossas ideias, mesmo que 
não sejam os grupos mais visíveis ou 
influentes, expandimos a nossa 
coligação para gerar mais sucessos, 
criando um "efeito de manada" que 
aumenta ainda mais a nossa influência.
Identifique os sabotadores
Os sabotadores são o alto 
perfil, detratores influentes 
que são mais propensos a 
resistir (e talvez até mesmo 
sabotar) nossos esforços.
Abordamos este grupo apenas 
depois de alcançarmos uma 
maioria silenciosa, quando 
estabelecemos sucessos 
suficientes para proteger com 
sucesso a nossa iniciativa.
Resumo
• Saber em que áreas iniciar as suas 
práticas DevOps é essencial.
Mapeamento de Fluxos 
em DevOps
Marco Mendes
Todo o trabalho realizado na sua 
TI pode ser descrito através de 
um fluxo de valor. 
Identificar o trabalho e os 
envolvidos nesses fluxos de valor 
é fundamental para buscar 
melhorar o sistema de trabalho.
Na prática, como cada um dos papéis do seu 
fluxo de valor de TI participa do trabalho
Dono do produto 
(PO)
Time de 
desenvolvimento
QA
Equipe de 
operações
Equipe de 
segurança
Gerentes
Na prática, analisamos o tempo gasto por cada 
trabalhador, a sua efetividade de tempo e a 
qualidade do seu trabalho
Tempo de 
Entrega
Tempo de 
Valor 
Agregado
% Efetividade
Exemplo de mapeamento
Fonte: Humble, Molesky, and O’Reilly, Lean Enterprise, 139.
Use métricas para propor melhorias com DevOps
Utilizamos as métricas do nosso mapa de fluxo de valor para orientar os nossos 
esforços de melhoria. No exemplo Nordstrom, eles se concentraram nas taxas 
de baixa efetividade apresentado pelos gerentes de departamento, devido à 
ausência de números de funcionários. 
Em outros casos, poderia ser longos prazos de entrega ou taxas ruins de 
efetividade ao fornecer ambientes de teste configurados corretamente para 
equipes de desenvolvimento, ou pode ser o tempo de execução longo exigido 
para executar e passar o teste de regressão antes de cada versão de software.
Uma vez que identificamos a métrica que queremos melhorar, devemos 
realizar o próximo nível de observações e medições para entender melhor o 
problema e, em seguida, construir um mapa de fluxo de valor idealizado, 
futuro, que serve como uma condição de destino para alcançar.
Resumo
• Eficiência de fluxo em TI é 
tipicamente entre 5 a 15%.
• Compreender a eficiência do fluxo 
te fornece oportunidades ricas de 
melhorias.
Práticas para Iniciar 
DevOps
Marco Mendes
Pessoas Dedicadas
1
Atribua membros da equipe 
alocados exclusivamente aos 
esforços de transformação do 
DevOps (ao invés de "manter 
todas as suas responsabilidades 
atuais, mas gastar 20% do seu 
tempo nessa nova coisa de 
DevOps.").
2
Selecione os membros da equipe 
que são generalistas, que têm 
habilidades em uma ampla 
variedade de domínios.
3
Selecione os membros da equipe 
que têm relacionamentos de longa 
data e respeitosos com o resto da 
organização.
4
Crie um espaço físico separado 
para a equipe dedicada, se 
possível, para maximizar o fluxo de 
comunicação dentro da equipe e 
criar algum isolamento do resto da 
organização.
Crie metas globais
e compartilhadas
• Exemplos:
• Reduzir a percentagem do orçamento gasto no 
suporte ao produto e o trabalho não planejado 
em 50%.
• Garantir que o tempo de execução do check-in de 
código para liberação de produção é de uma 
semana ou menos para 95% das alterações.
• Garanta que as liberações sempre podem ser 
executadas durante o horário comercial normal 
com zero downtime.
• Integre todos os controles de segurança de 
informações necessários no pipeline de 
implantação para passar em todos os requisitos de 
conformidade necessários.
Busque melhorias de 
curto prazo
• Flexibilidade e a capacidade de 
priorizar e replanejar rapidamente
• Diminua o atraso entre o trabalho 
gasto e a melhoria realizada, o que 
fortalece nosso ciclo de feedback, 
tornando mais provável reforçar os 
comportamentos desejados — quando 
as iniciativas de melhoria são bem-
sucedidas, ela incentiva mais 
investimentos
• Aprendizado mais rápido gerado a 
partir da primeira iteração, 
significando uma integração mais 
rápida de nossos aprendizados na 
próxima iteração
• Redução da energia de ativação para 
obter melhorias
• Realização mais rápida de melhorias 
que fazem diferenças significativas em 
nosso trabalho diário
• Menos risco de o nosso projeto ser 
cancelado antes de podermos gerar 
resultados demonstráveis
Use ferramentas para reforçar 
comportamentos desejados
• Exemplos incluem:
• Feedback de 
teste de fumaça
• Mensagens 
instantâneas 
quando um build 
passar
• Feedback de 
refatoração de 
código
Ferramentas para reforçar 
comportamentos - Exemplos
Forneça pulmões para pagar os débitos técnicos
As organizações que não pagam a dívida técnica pode encontrar-se tão sobrecarregado com soluções diárias para 
os problemas deixados que eles não podem mais completar qualquer novo trabalho. Em outras palavras, eles estão 
agora apenas fazendo o pagamento de juros sobre a sua dívida técnica.
Devemos gerir ativamente essa dívida técnica, garantindo que investimos pelo menos 20% de todos os 
ciclos de desenvolvimento e operações em refatoração, investindo em trabalho de automação e 
arquitetura e requisitos não funcionais (NFRs, às vezes chamados de ”idades"), como manutenibilidade, 
gerenciabilidade, escalabilidade, confiabilidade, testabilidade, implantabilidade e segurança.
Ao dedicar 20% de nossos ciclos para que Devs e Ops possam criar contramedidas 
duradouras para os problemas que encontramos em nosso trabalho diário, 
garantimos que a dívida técnica não impessa nossa capacidade de desenvolver e 
operar de forma rápida e segura nossos serviços em produção.
E reduzir a pressão da dívida técnica dos trabalhadores também pode reduzir os níveis de 
estresse e demissões.
Resumo
• Possuir pessoas dedicadas, criar 
metas globais e compartilhadas, 
implementar melhorias de curto 
prazo e usar ferramentas de 
feedback contínuo são melhores 
práticas para fortalecer iniciativas 
DevOps
Uso da Lei de Conway
para DevOps
Marco Mendes
Exemplo prático – Equipes funcionais
A Lei de Conway para o DevOps
Em outras palavras, a forma como organizamos nossas equipes tem um efeito 
poderoso no software que produzimos, bem como nos resultados 
arquitetônicos e de produção resultantes. A fim de obter um fluxo rápido de 
trabalho de desenvolvimento em operações, com alta qualidade e grandes 
resultados dos clientes, temos de organizar as nossas equipas e nosso 
trabalho paraque a lei de Conway trabalha a nosso favor. 
Se mal feita, a lei de Conway impedirá que as equipes trabalhem de forma 
segura e independente; em vez disso, eles serão firmemente acoplados, todos 
esperando uns aos outros para o trabalho a ser feito, com até mesmo 
pequenas mudanças criando potencialmente global, consequências 
catastróficas.
Caso Real da Aplicação da Lei de Conway
Um exemplo de como a lei de Conway pode impedir ou reforçar nossos objetivos 
pode ser visto em uma tecnologia que foi desenvolvida no Etsy chamado sprouter.
Essa sprouter conectava pessoas, processos e tecnologia de maneiras que criaram 
muitos resultados indesejados. 
O Sprouter, abreviatura de "roteador de procedimento armazenado", foi 
originalmente projetado para ajudar a tornar a vida mais fácil para os 
desenvolvedores e equipes de banco de dados.
Como Ross Snyder, um engenheiro sênior na Etsy, disse durante sua apresentação no 
surge 2011, "sprouter foi projetado para permitir que as equipes dev para escrever 
código PHP na aplicação, os DBAs para escrever SQL dentro Postgres, com o sprouter
ajudando-os a se encontrar no meio do caminho."
Caso Real da Aplicação da Lei de Conway
A Etsy inicialmente tinha duas equipes, os desenvolvedores e os DBAs, que 
foram cada um responsável por duas camadas do serviço, a camada de 
lógica de aplicação e camada de procedimento armazenado. Duas equipas a 
trabalhar em duas camadas, como prevê a lei de Conway. 
A sprouter pretendia tornar a vida mais fácil para ambas as equipes, mas 
não funcionou como esperado — quando as regras de negócios mudaram, 
em vez de alterar apenas duas camadas, elas agora precisavam fazer 
alterações em três camadas (no aplicativo, nos procedimentos armazenados 
e agora no sprouter ). 
Os desafios resultantes da coordenação e priorização do trabalho em três 
equipes aumentaram significativamente os tempos de execução e 
causaram problemas de confiabilidade.
Caso Real da Aplicação da Lei de Conway
Na Primavera de 2009, como parte do que Snyder chamou de "a grande 
transformação cultural Etsy", Chad Dickerson juntou-se como seu novo 
CTO. Dickerson colocou em movimento muitas coisas, incluindo um 
investimento maciço na estabilidade do produto, onde os 
desenvolvedores iriam realizar suas próprias implantações em produção, 
bem como iniciar uma jornada de dois anos para eliminar o produto 
sprouter.
Para fazer isso, a equipe decidiu mover toda a lógica de negócios da 
camada de banco de dados para a camada de aplicativo, removendo a 
necessidade de sprouter. Eles criaram uma pequena equipe que escreveu 
uma camada de Object Relational Mapping (ORM) para PHP, permitindo 
que os desenvolvedores front-end fizessem chamadas diretamente para o 
banco de dados e reduzindo o número de equipes necessárias para 
alterar a lógica de negócios, de três equipes para uma equipe.
Caso Real da Aplicação da Lei de Conway
Eliminando o sprouter, eles também eliminaram os problemas 
associados a várias equipes que necessitam coordenar para 
mudanças na lógica de negócios, diminuíram o número de handoffs
e aumentaram significativamente a velocidade e o sucesso das 
implantações de produção, melhorando a estabilidade do local. 
Além disso, como as equipes pequenas poderiam desenvolver e 
implantar seu código independentemente sem exigir que outra 
equipe fizesse alterações em outras áreas do sistema, a 
produtividade do desenvolvedor aumentava.
Arquétipos Organizacionais e o impacto para DevOps
• As organizações funcionais orientadas para a especialização do conhecimento, divisão do 
trabalho ou reduzindo do custo. Essas organizações centralizam o expertise, o que ajuda a 
possibilitar o crescimento da carreira e o desenvolvimento de habilidades, e muitas vezes 
têm estruturas organizacionais hierárquicas altas. Este tem sido o método predominante de 
organização para operações (ou seja, administradores de servidor, administradores de rede, 
administradores de banco de dados, e assim por diante são todos organizados em grupos 
separados) e construção de produtos (desenvolvedores e QAs).
• As organizações orientadas para o mercado otimizam para responder rapidamente às 
necessidades do cliente. Essas organizações tendem a ser planas, compostas por várias 
disciplinas multifuncionais (por exemplo, marketing, engenharia, etc.), que muitas vezes 
levam a possíveis redundâncias em toda a organização. É assim que muitas organizações 
proeminentes que adotam o DevOps operam — em exemplos extremos, como na Amazon
ou Netflix, cada equipe de serviço é simultaneamente responsável pela entrega de recursos 
e suporte a serviços
• Organizações matriciais tentam combinar a orientação funcional e de mercado. No entanto, 
como muitos que trabalham ou gerenciam organizações matriciais observam, as 
organizações matriciais geralmente resultam em estruturas organizacionais complicadas, 
como contribuintes individuais relatando a dois gerentes ou mais, e às vezes alcançando 
nenhum dos objetivos do orientação funcional ou de mercado.
Também podemos alcançar os 
resultados desejados do 
DevOps por meio da 
orientação funcional, contanto 
que todos no fluxo de valor 
vistas clientes e resultados 
organizacionais como um 
objetivo compartilhado, 
independentemente de onde 
residem na organização.
DevOps em organizações funcionais
Fonte: Humble, Molesky, and O’Reilly, Lean Enterprise
A	organização	de	times	que	
criam	e	sustentam	produtos,
ao	invés	de	uma	lógica	centrada	em	
projetos,	facilita	a	adoção	de	
práticas,	melhoria	nos	sistemas	de	
trabalho,	redução	dos	tempos	de	
ciclo	e	melhorias	no	retrabalho.
Colocar	mais	ênfases	em	
produtos	que	projetos	
facilita	iniciativas	DevOps
Carreiras em T (ou E)
Forme “especialistas em 
generalização” que se 
aprofundam em uma 
área, mas também se 
desdobram em outras 
áreas.
60
Mantenha equipes Pequenas
Os membros da equipe se tornam menos 
produtivos à medida que o tamanho do 
grupo aumenta. 
Se possível, mantenha as equipes 
pequenas, mas suficientes para cobrir 
um fluxo de valor.
– Jacob Morgan, The Future of Work
E estabeleça Comunidades de Prática (as Guildas 
no Spotify)
Uma comunidade de prática (CoP) é um grupo de 
pessoas com uma preocupação, interesse ou paixão 
compartilhados, que aprofundam seus 
conhecimentos e experiências na área, pela 
interação de forma contínua.
– E. Wenger, R. McDermott, W. Snyder
Resumo
• Estruturas de times dentro de uma 
organização pode apoiar em 
iniciativas DevOps
• Práticas comuns:
• Comunidades de práticas
• Equipes pequenas
• Foco em produtos
• Carreiras em T