DevOps Professional

Módulo 1 - Introdução ao DevOps

Introdução ao DevOps 3
O que é DevOps 3
Desenvolvimento (Dev) 3
Operações (Ops) 3
Onde os problemas DevOps Residem 4
Desenvolvimento, Operações e Negócio 4
DevOps: Uma definição 4
Exige 4
Aborda 4
DevOps e Ágil 5
Como o DevOps se relaciona com o Ágil, ele substitui o Ágil? 5
Ágil e DevOps 5
O que não é DevOps? 5
A Origem do DevOps 6
Lean 7
Valor 8
Exemplo de Valor 9
Desperdício 9
Exemplos de Desperdício 9
Fluxo de Valor (Value Stream) 9
Etapas do Fluxo de valor 10
Exemplo de Fluxo de Valor 10
Lead Time 11
Tempo de Processo (Process Time) 11
Percentual de conclusão e precisão (%C/P) 12
Mapa de fluxo de valor (value stream mapping) 12
Exemplo de mapa de Fluxo de valor 12
Outro exemplo de fluxo de valor 14
Passos para elaborar um mapa de fluxo de valor 15
Melhoria Kata (Kata Improvement) 15
Passo a passo Kata 15
Quadro de melhoria Kata 16
Working in Process - WIP 17
Agile 17
Movimento Agile 17
O Manifesto Ágil - Os 12 princípios 18
Introdução ao DevOps
Peso no exame: 2,5%

O que é DevOps

Desenvolvimento (Dev)
● A equipe de desenvolvimento é responsável por identificar e entender problemas de
negócio e desenvolver soluções, entregando com máxima qualidade e produtividade
as versões de software que deve ser colocadas em produção
● É composta normalmente por profissionais que desenvolvem as aplicações como
programadores, analistas de sistema, arquitetos de software, analistas de testes,
entre outros

Operações (Ops)
● A equipe de operações normalmente é responsável por manter os serviços em
produção e por fazer o deploy (liberação) de novas versões de softwares e artefatos
em produção
● Ela faz os deploys e os rollbacks enquanto mantém o ambiente de produção o mais
estável possível
● A equipe é composta geralmente pelos administradores de sistema
(sysadmins),DBA e arquitetos de infra também pode compor a equipe

Onde os problemas DevOps Residem

● No handover, ou seja, no passar de tarefas e atividades de uma área para outra, de
Desenvolvimento para Operações e vice-versa
 ● Geralmente apenas na implantação do software é que essas áreas se conversam,
não existe conversa durante o desenvolvimento
● Problemas em produção também geral atrito, cada área passando a culta para a
outra

Desenvolvimento, Operações e Negócio

● O negócio, ou seja, pessoas do negócio fazem pressão em ambas as áreas:
● Eles exigem velocidade nas entregas e exigem novas funcionalidades no software!
● Depois de entregue, exige que a aplicação não cai, seja estável e confiável
● Se não estiverem em sincronia, as áreas de Desenvolvimento e Operações terão
conflitos

DevOps: Uma definição

O DevOps é uma filosofia sob a qual as equipes de negócios, de desenvolvimento e de
operações colaboram continuamente para garantir que as soluções de TI estejam
disponíveis aos negócios no prazo e que sejam executadas sem interrupções

Exige
● Automação: Deploy automático
● Colaboração: Pessoas de ambas as áreas devem ser colaborativa
● Mudança Cultural: Vai exibir mudança cultural na empresa
● Estrutura Organizacional Simples

Aborda
● Pessoas
● Ferramentas
● Processo
DevOps e Ágil

Como o DevOps se relaciona com o Ágil, ele substitui o Ágil?

A resposta é não, ele pode ser utilizado junto com o Ágil

Ágil e DevOps
● Ágil tem como objetivo entregar valor rápido ao cliente fomentando a comunicação
contínua entre cliente e o fabricante do produto, geralmente um produto de software
● Imagine que na Data de liberação, se houver problemas, o benefício chave do Agile
- menor time-to-market - não é alcançado
● O problema da última milha (the last mile)
● DevOps pode ser visto como a continuação lógica da jornada do software Ágil
● O DevOps e o Agile se complementam para implantar software funcionando o mais
rápido possível

O que não é DevOps?

● Não existe um time DevOps: DevOps é sobre quebrar silos, não é criar um time ou
departamento novo!
● Não existe um cargo DevOps: Os departamentos e as pessoas devem trabalhar
baseado na cultura devops e não criar um cargos específico
 ● DevOps é cultura
● DevOps e integração entre áreas
● DevOps é visão sistêmica do fluxo de valor

A Origem do DevOps
● O movimento DevOps teve origem em torno de 2009, durante a convergência de
vários movimentos adjacentes que se reforçavam mutuamente
➢ Infraestrutura ágil (Mark Burgess e Luke Kanies)
➢ Integração e entrega contínua (Jez Humble)
➢ Lean Startup (Eric Ries)
➢ Cloud a plataforma como serviço (Paas)
 ● O DevOps e suas práticas culturais, arquiteturais e técnicas representam uma
convergência de muitos movimentos filosóficos e gerenciais
● O DevOps é o resultado da aplicação dos princípios mais confiáveis de manufatura e
liderança para a TI

Lean
● É uma filosofia de gestão inspirada nas práticas do sistema Toyota de Produção
● o Lean foca em criar valor mais rapidamente e remover desperdícios

1. Valor (Customer Value): Representa os requisitos do cliente em relação ao produto

ou serviço entregue
2. Fluxo de Valor (Value Stream): Representa os passos que um produto ou serviço
passa dentro da organização
3. Fluxo (Flow): As atividades não deve ter interrupções
 4. Sistema de produção puxado (pull): A demanda gera o gatilho no fluxo de valor para
reduzir o estoque
5. Perfeição (perfection): Fazer as coisas certas da primeira vez e melhorar
continuamente

Valor
● É algo que contribui para a forma, as características ou a função do produto/serviço
● Deve ser algo que o cliente esteja disposto a pagar para ter
○ Está associado aos benefícios de um produto ou serviço entregue ao cliente
○ Empresa cobram pelo valor adicionado ao produtos e serviços
○ O valor está vinculado ao preço através de um mecanismo de troca
Apenas quem sabe o que é valor pode falar em remover
desperdícios
● Nem sempre algo ruim é desperdício de tempo
● Um Relatório perfeito que não é utilizado pelo cliente, é um desperdício
Exemplo de Valor

● Se apenas o café é a necessidade do cliente, se você oferecer um café com biscoito

e cobrar um valor a mais pelo biscoito, o valor ao cliente não será atendido
● Ele gostaria de pagar um valor mais barato apenas pelo café

Desperdício
● O Lean não se preocupa apenas com a entrega do maior valor possível aos clientes,
mas também em garantir que os desperdícios sejam removidos
● O Valor para os clientes aumenta de duas formas:
○ Pela produção da porção de atividades desnecessárias
○ Pelo aumento da quantidade de atividades que agregam valor

Exemplos de Desperdício
● Qualquer atividade que consome recursos sem fornecer valor (tal como definido pelo
cliente)
● Se o cliente não está disposto a pagar por uma atividade, então ela é um
desperdício
● Desperdício não se trata somente de erros que acontecem durante o processo e que
precisam ser corrigidos, mas de qualquer coisa que, embora seja feita corretamente,
não gere valor aos olhos do cliente

Fluxo de Valor (Value Stream)

● Em DevOps, normalmente definimos nosso fluxo de valor de tecnologia como o
processo necessário para converter uma hipótese de negócios e um produto ou
serviço que entregue valor ao cliente
● É entender e enxergar como as coisas acontecem dentro da empresa
● É o passo a passo de todas as atividades que serão executadas para entregar
alguma coisa ao cliente.
 Fluxo de valor é sinônimo de Processo
Etapas do Fluxo de valor
● Começa quando um cliente solicita algo
● Etapas dentro da empresa
● Termina quando o cliente recebe algo

Exemplo de Fluxo de Valor

● Implantação de um novo sistema (ERP)
● Atendimento a erros e dúvidas
● Desenvolvimento e entrega de software
● Atendimento a requisição
Lead Time
● Lead Time é definido como o tempo entre o momento em que um cliente pediu algo
e o momento em que isso é entregue
● É um dos principais indicadores de desempenho de um fluxo de valor
● Inicia na solicitação do cliente e Finaliza quando é entregue ao cliente
● O Lead Time é o tempo que dura a entregue independente se é efetivamente
trabalhando no projeto, ou esperando uma aprovação, todo o tempo conta como
Lead Time

Tempo de Processo (Process Time)

Process Time (ou tempo de processamento) é efetivamente o esforço gasto em uma
atividade (tempo que alguém realmente trabalhou em gasto, empregou tempo)
Percentual de conclusão e precisão (%C/P)
Além do lead time e do tempo de processamento (valor agregado), a terceira métrica
principal no fluxo de valor é a porcentagem de vezes que a tarefa foi concluída e com
precisão - percent complete and accurate - %C/A
● Essa métrica reflete a qualidade de saída de cada etapa em nosso fluxo de valor
● Pergunte ao seu cliente qual a porcentagem do tempo em que ele recebe o trabalho
que é “utilizável como está”, significando que ele não precisou corrigir as
informações recebidas (Cliente interno e não externo)
Exemplo
● Em 90% das vezes, desenvolvedor recebe todas as informações de que necessita e
da forma correta
● Em 10% das vezes, desenvolvedor tem algum nível de retrabalho
● Já o QA 50% do trabalho recebido não precisa de retrabalho

O objetivo é identificar a qualidade do trabalho entregue para o próximo cliente do processo.

Isto deve ser uma preocupação de todos!

Mapa de fluxo de valor (value stream mapping)

● Para ajudar na identificação de um fluxo de valor, utilizamos uma ferramenta
chamada mapa de fluxo de valor (value stream mapping)
● O mapeamento do fluxo de valor é realizado com o objetivo de identificar gargalos e
desperdícios no processo de entrega de valor para o cliente

Exemplo de mapa de Fluxo de valor

● Nova ideia conceito Hipótese
○ Definir a historia do usuário
○ Desenvolver, codificar e testar
○ Deploy para ambiente de teste
○ Realizar teste de sistema
○ Deploy para pré-produção (stage)
○ Realizar testes de aceitação
○ Deploy para Produção
● Work time
○ 2h para Definir a historia do usuário
○ 4h para Desenvolver, codificar e testar
○ 30 min para Deploy para ambiente de teste
○ 3h para Realizar teste de sistema
○ 30 min para Deploy para pré-produção (stage)
○ 60 min para Realizar testes de aceitação
○ 30 min para Deploy para Produção
 ○ Total 11,5 horas (1,5 dias úteis)
● Tempo de Espera (Fila)
○ Definir a historia do usuário
■ 8h aguardando desenvolvedores iniciar
■ Desenvolver, codificar e testar
● 4h aguardando até iniciarem Deploy
● Deploy para ambiente de teste
○ 4h aguardando equipe de teste iniciar
○ Realizar teste de sistema
■ 2h aguardando equipe fazer Deploy
■ Deploy para pré-produção (stage)
● 40h aguardando cliente fazer testes
● Realizar testes de aceitação
○ 2h aguardando
○ Deploy para Produção
○ Total Desperdício = 60 horas (7,5 dias úteis)
● Eficiência
○ Divida o Tempo de Trabalho pelo Tempo Total
○ Nesse caso
■ 11,5 horas / 60 horas
■ 16% de eficiência
Outro exemplo de fluxo de valor
Pode ser o fluxo para correção de erros identificados em produção
Passos para elaborar um mapa de fluxo de valor
● Identificar o fluxo a ser melhorado
● Definir os limites do fluxo de valor
● Elaborar um para de fluxo de valor
● Determinar melhorias e criar um plano de ação
● Visualizar o estado futuro do fluxo de valor

Melhoria Kata (Kata Improvement)

Kata significa Forma de Fazer
● Repetição e prática são pré-requisitos para maestria
● A melhoria Kata requer a criação de estrutura para a prática diária e habitual de
trabalho de melhoria, porque a prática diária é o que melhora os resultados

Passo a passo Kata

1. Definia a direção ou desafio
a. Reduzir o desperdício total para 50% do montante original
2. Defina a situação atual
a. Onde estamos agora?
b. Por que temos tanto desperdício?
3. Estabeleça a próxima condição alvo
a. Reduzir os desperdícios em 5% nos próximos 6 meses
4. Conduza experimentos e melhoria diária para chegar lá
a. Comece a experimentar para chegar a uma solução de trabalho
b. Não desanime se não for resolvido imediatamente
c. Pode ser necessário muitas pequenas experiências e melhorias diárias, por
isso não procure por uma “bala de prata”
Quadro de melhoria Kata
● Conduza experimentos e melhoria diária para chegar lá
Working in Process - WIP
● Trabalho em Progresso (work in progress): Trabalho que entrou no sistema
produtivo (fluxo de valor), mas ainda não está concluído e disponível para um cliente
ou usuário
● Refere-se a todos os ativos ou produtos de trabalho em um produto ou serviço que
estão atualmente sendo trabalhos ou aguardando em uma fila para serem trabalhos
● Em progresso pode considerar o trabalho que foi assumido a fazer, mas ainda não
começou a ser feito, e também o trabalho que de fato começou, mas não foi
finalizado por alguma razão

Agile

Movimento Agile
Manifesto para o desenvolvimento ágil de software
Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e
ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar:
- Indivíduos e interação entre eles mais que processo e ferramentas
- Software em funcionamento mais que documentação abrangente
- Colaboração com o cliente mais que negociação de contratos
- Responder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda
O Manifesto Ágil - Os 12 princípios
1. Nossa maior prioridade é satisfazer o cliente, por meio da entrega adianta e contínua
de software de valor
2. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processo ágeis
se adequam as mudanças para que o cliente possa obter vantagens competitivas
3. Entregar software funcionando com frequência, na esla de semanas até meses, com
preferência aos períodos mais curtos
4. Pessoas relacionadas a negócios e desenvolvedores devem trabalhar em conjunto e
diariamente durante todo o curso do projeto
5. Construir projetos ao redor de indivíduos motivados, dando a eles o ambiente e
suporte necessários, e confiar que farão seu trabalho
6. Contínua atenção a excelência técnica e bom design aumenta a agilidade
7. O método mais eficiente e eficaz de transmitir informações dentro de um time de
desenvolvimento é através de uma conversa cara a cara
8. Software funcional é a medida primária de progresso
9. Processos ágeis promovem um ambiente sustentável. Os patrocinadores,
desenvolvedores e usuários devem ser capazes de manter indefinidamente passos
constantes
10. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser
feito
11. As melhores arquiteturas, requisitos e designs emergem de times auto organiza´veis
12. Em intervalos regulares, o time reflete sobre como ficar mais efetivo. Então, se
ajusta e otimiza seu comportamento de acordo