EXIN - DEVOPS PROFESSIONAL

Três maneiras:
Fluxo, Feedback, Aprendizado contínuo.

Fluxo: Desenvolvimento rápido - Esquerda para a direita

Feedback: Rapidamente da Direita apara a esquerda
Aprendizado contínuo: Cultura de experiencia, experimentação e tomada de risco

DevOps é um conjunto de melhores práticas que enfatizam a colaboração e a

comunicação de profissionais de TI no clico de vida de aplicações e serviços.

Conceitos básicos do DevOps:

Implantação contínua
Infraestrutura ágil
Kata
WIP
Débito técnico
Lead time

Lean (enxuto): Filosofia de gestão baseado na Toyota - Evitar desperdícios

Toyota Kata: Rotinas de ensino para preservar e passar conhecimento.
Movimentos repetidos exaustivamente para fixação
Kanban: Gestão de fluxo de trabalho de forma bem visual
WIP (work in progress): Tarefa que está em execução (coluna DOING do Kanban).
Boa prática de limitar quantidade de trabalho simultaneo
-Valor: Benefício gerado pelo produto ou serviço ao cliente
-Fluxo de Valor: Converter hipotese em produto ou serviço
Mapa de fluxo de valor: Identificar desperdícios
Lead time: Mede o tempo de execução de cada etapa
Process time: Mede somente o tempo trabalhado em cada etapa/atividade (work
time)
Percent complete and accurate (%C/A): Mede qualidade da entrega
Se não houve retrabalho, o %C/A é 100%
Se houver 10% de retrabalho, o %C/A é 90%
-Fluxo
-Produção Puxada
-Perfeição

Manifesto ágil
4 valores:
-Indivíduos e interações entre eles mais que processos 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
12 princípios:
1 Nossa maior prioridade é satisfazer o cliente através da entrega contínua e
adiantada de software com valor agregado
2 Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis
se adequam a mudanças, para que o cliente possa tirar vantagens competitivas
3 Entregar frequentemente software funcionando, de poucas semanas a poucos meses,
com preferencia a menor escala de tempo4
4 Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por
todo o projeto
5 Construir projetos em torno de indivíduos motivados. Dando a eles o ambiente e o
suporte necessário, e confiando neles para fazer o trabalho
6 O método mais eficiente e eficaz de transmitir informações para e entre uma
equipe de desenvolvimento é através de conversa face a face
7 Software funcionando é a medida primária de progesso
8 Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores,
desenvolvedores e usuários devem ser capazes de manter um ritmo constante
indefinidamente
9 Contínua atenção a excelencia técnica e bom design aumenta a agilidade
10 Simplicidade: A arte de maximizar a quantidade de trabalho não realizado é
essencial
11 As melhores arquiteturas, requisitos e designs emergem de times auto
organizáveis
12 Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e
então refina e ajusta seu comportamento de acordo

Infraestrutura ágil

Pipeline de implantação
É a sequencia de atividades automatizadas para levar o código da máquina do
desenvolvedor para o ambiente de produção. Essa expressão é uma abstração que
envolve os processos de:
Integração contínua
Entrega contínua
Implantação contínua

A entrega contínua é a extensão da integração contínua. Permite mais testes,

implementações, integração entre áreas.
Ela garante que tanto o código quanto e infraestrura estejam sempre em um estado
implantável.

Implantação contínua garante que o código assim que entregue em um repositório,

possa ser implementado em produção automaticamente, sem intervenção manual.

Débito técnico: Custo de retrabalho

A primeira maneira: Fluxo

Esquerda -> Direita
Dev -> Ops
-Tornar o trabalho visivel
Kanban
-Limitar WIP
Limitar a quantidade de quadros de trabalhos simultaneos (Kanban)
-Reduzir o tamanho do lote de trabalho
Limitar o trabalho a uma atividade por vez
-Reduzir o número de transferências
-Identificar e melhorar as restrições
-Eliminar atritos e desperdicios no fluxo de valor
-Reduzir o numero de transferencias de informação, para evitar perdas por ruídos
-Identificar e mitigar as restrições: Reduzir lead time e aumentar o throughput
Principais restrições:
Criação de ambientes
Implementação de código
Execução de testes
Arquitetura altamente acoplada
No lean, desperdício é qualquer coisa que gere atraso na entrega

Segunda maneira: Feedback (Direita -> Esquerda)

Ver os problemas à medida que eles ocorrem (criação de processos automatizados)
Andon Cord: Resolver os problemas em conjunto
-Feedback rapido
-Rapidez no diagnóstico e resolução
-Foco na solucao
-Previnir que a falha ocorra novamente
 -Aprendizado
-Evita esquecimentos ou outros fatores que tornem dificil encontra a
causa raiz

Controle de qualidade:
Aplicar Peer Reviews em mudanças
Automação de todo o trabalho possível
Testes sob demanda

Otimize o trabalho pensando na próxima etapa do fluxo

Terceira maneira: Aprendizado contínuo e experimentação

-Criar Aprendizado organizacional
-Criar uma cultura de segurança
"Ao remover a culpa, voce remove o medo; Removendo o medo, voce permite
a honestidade; E a honestidade permite a prevenção." -Bethany Macri

Blameless Post-Mortem*
-Institucionalizar a melhoria do trabalho diário
Kaizen Blitzes - Foco em solução de débito técnico
-Transformar descobertas locais em melhorias globais
Tornar relatorios de Blameless Post-Mortem acessivel a todos
KBs e repositorios compartilhados
-Adicionar testes de resiliencia no trabalho diario
Game days: Simular falhas em larga escala
Injetar problemas na infraestrutura para avaliar o comportamento, vizando melhorias
Adicionar resiliencia ao trabalho diário
-Líderes devem reforçar uma cultura de Aprendizado

Organização de empresas voltadas para DevOps

A chave é o fluxo de valor
Greenfield - Novo projeto de software
Brownfield - Produto ou servico ja existente - Geralmente vem com divida técnica

System of Registry (SoR) - Sistemas que suportam o negócio (criticos)

Tipo 1 - As empresas preferem fazer da forma correta do que da forma rápida
System of Engagement (SoE) - Não primordiais
Tipo 2 - Contrario do tipo 1

Recomendação para adoção DevOps - Começar com times mais bem dispostos e inovadores
(early adopters)
Identifique o time que suportará seu fluxo de valor
-Product Owners
-Development
-QA
-Operations
-Infosec
-Release managers
-Technology executives or value stream managers
*Criar um time 100% dedicado a transformação
Crie um espaço separado para este time (junto e isolado, livre de algumas regras e
políticas)

Arquétipos organizacionais
-Organizacao orientadas por funcao
-Organizacao orientadas por mercado ou Produto
-Organizacao matricial

Perfis de profissionais
 I-Shaped - Especialista
T-Shaped - Generalista
E-Shaped - Alem de experiencia em varias areas tem especialidade em mais de
uma área (Maior aderencia com DevOps)

Conway's Law - Sistemas desenvolvidos de acordo com a organizaçao (mais rigida ou

flexivel)
Manter Ops perto, atraves de daily meetings, ver o trabalho de Ops em Kanban
Vantagem da regra Two-Pizza Team:
-Compreensão mais clara do processo
-Limita taxa de crescimento do produto/servico
-Descentralização do poder e autonomia
-Revezamento da liderança gerando mais experiencia

A primeira maneira: O Fluxo

Pipeline de implantação
Ambientes identicos ao de produção
Ambientes Self-Service
Recursos para automatização:
Vmware, EC2, vagrant
Bare metal - PXE
Puppet, Ansible, Chef, Salt..
Containers
Nuvem publica, privada ou paas

Benefício do container no pipeline de implantação: Dar uma stack identica para o

desevvolvedor testar seu código

Repositório unico para todo o Ambiente:

Codigo e dependencias
Scripts para schemas de banco
ferramentas e configuracao de infra as a code
dockerfile, dockercompose
manuais
scripts para deploy
arquivos de configuracao de cloud
scripts da infraestrutura (dns, firewall...)
DoD - Definition of Done - Definicao de Pronto
Otinizando o fluxo de valor

Elinine ou automatize:
Comunicacoes
Aprovacoes
Colaboracao
Trabalhe com Containers
Trabalhe IaaC
Use repositorios compartilhados
Adapte o DoD
De muita atencao ao %C/A no fluxo de valor
Use ferramental para construcao de Ambientes
Automação de Testes

Piramide de Testes - A regra é que devemos encontrar os erros nas categorias de

testes que sao executados mais rapidamente
Piramide ideal - Erros encontrados no inicio do teste - Do mais rapido pro
mais lento
Testes automatizados
Piramide nao ideal - Erros encontrados manualmente e de integraçao - Do mais
lento pro mais rapido
Testes manuais

TDD - Test-Driven Development

Pequenos ciclos de repeticoes - Um Teste para cada funcionalidade do sistema

Cliclo de desenvolvimento do TDD

Escrevemos um teste que inicialmente nao passa (red)
Adicionamos a funcionalidade do sistema
Fazemos o teste passar (green)
Refatoramos o codigo da nova funcionalidade (refactoring)
Escrevemos o proximo teste
Beneficios
Feedback
Codigo mais limpo
Seguranca
Produtividade
Codigo mais flexivel (menos acoplado)
Confianca na correcao do bug
Tempo de desenvolvimento menor
Integracao continua

Integraçao contínua
CI -> CDelivery -> CD
É a primeira etapa do pipeline CI/CD, ou seja, interaçao do desenvolvedor com
o repositorio
Maior quantidade de Branches, mais dificil a Integracao

Estrategias de branch:
Otimizadas para produtividade individual
Muitas branches - Perda de Produtividade
Otimizadas para produtividade do time
Sem branches - Trunk-Based
Andon cord
Deployment lead time

Reduzir débito técnico

Simplificar e automatizar o maior numero possivel de tarefas
Implementar servidor de CI
Escolher estrategia de Branches
Investir em automacao de Testes
Implementar infraestrutura que permita testes em VM
Fluxo de peca unica (WIP)

Kaizen Blitz (Metodo Toyota)

Tempo dedicado para resolucao de questao tecnica (deep dive)

Outros eventos direcionados a Reduzir divida tecnica:

Dojo
Sprint/Fall clearing
Ticket queue inversion week
Hack days
Hackathons

Releases de baixo risco

Deployment
Instalacao de uma versao especifica do software para determinado
Ambiente
Release
 Disponibilização de produto

Padrao de release baseado em Ambiente

Blue-Green - Roteamento do trafego dos usuarios para blue (new) ou green
(atual). Simples rollback
Canary - Pequena parte de usuarios utilizando a versao nova. Mudanca gradual

Padrao de release baseado em aplicacao

Feature flags
Feature toggles
Dark launches

Segunda maneira: Feedback

Telemetria - É um processo automatizado de comunicação onde medições e outros são
coletados de dispositivos remotos e transmitidos para equipamentos de monitoramento
(plataforma de monitoração)
Quando estamos construindo nossas aplicações e ambientes, temos que desenha-
las com a implementação da telemetria. Visão global do ambiente

Framework de monitoramento
Coleta de dados
Eventos, logs, metricas..
Devem ser enviados para um serviço comum
Ferramentas que coletam informaçõesde desempenho: Dynatrace,
AppDynamics, NewRellic, DataDog.....
Roteador de eventos
Armazena dados
Toma ação em cima dos dados armazenados

Telemetria Self-Service
Importante usar a telemetria em produção, pré-produção e pipeline
Ter condições de propagar informação para todos os envolvidos no fluxo de
valor
Senso de responsabilidade compartilhada
Garantir o fácil acesso aos dados coletados, preferencialmente através de API
´s self-service
Níveis de logs
Debug level - monitora tudo e gera bastante log
Info level - monitora ações específicas
Warn level - monitora condição que pode gerar erros
Error level - informações sobre condições de erros
Fatal level - ultimo status do erro

Usando bem a telemetria:

Decisões de autenticação
Acesso a dados e sistemas
Mudança de sistemas e aplicações
Mudança de dados, como add, del ou edit
inputs inválidos

Monitorar recursos computacionais (hardware e serviços)

Como restaurar rapidamente erros em ambientes de produção

Feature toggles
Desativar recurso problematicos via código (mais fácil e menos
arriscada)
Fix Forward
Alteração no código para correção do problema via pipeline/novo commit
Rollback
 Retornar o ambiente para release anterior, por meio de feature toggles
ou alterando roteamento para padrões Blue-Green ou Canary

Sustentando serviços em operação

S.R.E - Site Reliability Engineering
Os desenvolvedores gerenciam seus próprios serviços em produção antes
de se tornamremelegíveis para um grupo de engenheiros gerencias
Possibilita transição suave do serviço para operações
Ideal é definir um checklist de requisitos antes da liberação do
serviço
Após liberação do serviço para o operacional, os desenvolvedores atuam
como consultores
LRR - Launch Readiness Review/Revisão de Prontidão de Lançamento -
Revisão do checklist para liberação - Time do produto que faz/aplica/valida o
checklist
Antes da publicação do servico
HRR - Hand-off readiness review/Análise de Prontidão de Hands-Off -
(lista de requisitos) verificação de segurança para transferencia do serviço - Time
de sustentação que faz/aplica/valida o checklist
Após estado gerenciável
O que conta no checklist
-Contagem e severidade de defeitos
-Tipo / Frequencia de alertas
-Cobertura de monitoramento
-Arquitetura do sistema
-Processo de implantação
-Higiene da produção
Necessidade do SRE (lançamento baseado em DevOps) LRR e HRR:
-Necessidade de monitoramento eficaz
-Implantações confiáveis e determinísticas
-Arquitetura de suporte implementações rapidas e frequentes

UX como feedback
Ajuda a criar requisitos não funcionais codificados para atendimento de
backlog
Criação de qualidade e resulta em empatia

Testes A/B
EX.: Com base em análise estatística, é possível medir a experiencia do
usuario com duas versoes diferentes de página
Para termos testes A/B rápidos e iterativo precisamos ter:
-Implantação em produção sob demanda
-Feature Toggles
-Poder entregar varias versoes de codigo simultaneas a segmentos de clientes
-Telemetria de produção em todos os niveis da stack de aplicação

Revisão de código
Peer Review
Pull request (GitHub foi pioneiro)
Inspeção aumentando a qualidade
Bom PR
Detalhes sobre o motivo da mudança
Como a mudança foi feita
Quais os riscos e contramedidas
Ruim PR
Sem documentação ou informação
O objetivo é ter colegas proximo, examinando as mudanças, gerando
melhor qualidade e aprendizado entre o time
Pair programming - programação por dois programadores aleatoriamente
 Sem metricas de melhorias
Revisão contínua de código
Eficaz para encontrar bugs
Não funciona com desenvolvedores remotos e não possui metricas de
melhoria no processo
Over-the-shoulder
Informal e fácil de ser implementada
Pode funcionar com trabalho remoto
Sem verificação de correção
Sem métricas de melhoria de processo
Preparation > Inspection meeting > Rework > Complete
E-mail pass-around
Autor ou sistema SCM (sistema de gerenciamento de código) envia código
por e-mail para os revisores
Discução para sugestão de alterações
Pode ser feito remotamente
Sem interrupção dos revisores
Bastante ineficiente
Sem verificação de correção de bugs
Sem métricas de melhoria
Revisão de código assistida por ferramentas
Uso de ferramentas especializadas
Coletar arquivos, transmitir, exibir arquivos, comentários e
problemas entre os participantes
Possui metricas
Maior controle no fluxo de trabalho

Terceira maneira
Aprendizagem
Organizações resilientes
Habeis em detectar problemas, resolver, multiplicar os efeitos,
tornando as soluções disponiveis em toda a organização
Chaos Monkey
Injeção de falha no ambiente de produção (Netflix)
Oportunidade de aprendizado
Simian Army Monkey
Suite criada pela netflix para simulação de falha
Teste de resiliencia
Game Day
Engenharia de resiliencia / Teste de injeção de falhas
Expor defeitos latentes no sistema
Ajuda a criar manuais

Cultura livre de culpa

Teoria da maçã podre é falha, segundo Dr Dekker
Ao inves de buscar culpados, devemos buscar entender o que
precisamos melhorar em nosso processo/servico
Reunião de blameless pos-mortem
Construa uma linha do tempo e colete detalhes sobre a
falha, garantindo não punir as pessoas
Garanta que não haverão culpados, permitindo que as pessoas
fornecam detalhes de sua contribuição para a falha
Habilite e incentive as pessoas que cometem erros a serem
especialistas que educam o restante sobre como não cometer o mesmo erro
Aceite que ha sempre um espaço onde os seres humanos podem
decidir agir ou nao, que o julgamento dessas decisoes está em retrospectiva
Proponha contramedidas para evitar que um acidente
semelhante aconteca no futuro
Quejm deve estar presente nesta reuniao
 As pessoas envolvidas em decisoes, as que identificaram o
problema, as que responderam ao problema, que diagnosticaram o problema, que foram
afetadas pelo problema, e quem estevier interessado
Informações coletadas no pos-mortem devem ficar disponivel a
todos

Ainda sobre o chaos monkey:

Simian Army Monkey
Chaos gorilla
Simula a falha de toda uma zona de disponibilidade da AWS
Chaos kong
Simula falha de regiões inteiras da AWS
Latency Monkey
Induz latencia artificial ou tempo de inatividade para
simular degradação do servico
Conformity monkey
Localiza e desliga instancias da AWS que não seguem
práticas recomendadas
Security monkey
Localiza e desliga instancias da AWS com falha de segurança
Doctor monkey
Atua nas verificações de integridade que são executadas em
cada instancia, na busca de instancias não integras, desativando-as se não houver
correção
Janitor monkey
Garante ambientes de nuvem livre de desordem e desperdício.
Procura por recurso não utilizado e os elimina

Requisitos não funcionais (NFR)

São requisitos relacionados ao uso da aplicação em termos de desempenho,
usabilidade, confiabilidade, segurança, disponibilidade, manutenção e tecnologias
envolvidas
Telemetria suficiente
Serviços resilientes
Compatibilidade com versões anteriores e futuras
Analise de logs
Rastreabilidade de solicitações de usuários por meio de vários serviços
Configuração simples e centralizada de tempo de execução (feature
flags)
Padronizar tarefas manuais.
Automatizar o máximo possível

Crie histórias de usuários de operação reutilizaveis no desenvolvimento

Para os trabalhos recorrentes, é necessário saber:
Qual o trabalho necessário
Quem é necessário para executá-lo
Quais são as etapas para concluí-lo

Um único repositorio de codigo fonte compartilhado para toda a organizaçao

Padrões de configuração (lib e infra)
Ferramentas
Testes
Codigos
Tutoriais e documentação

Compartilhamento de conhecimento
Compartilhar bibliotecas permite a propagação de conhecimentos e melhorias
Manter bibliotecas atualizadas e completas
Grupos de discursão ou salas de bate-papo
Segurança da informação
Adicionar ao repositorio compartilhado, mecanismos ou ferramentas que
garantam a segurança no ambiente
Utilizar bibliotecas pré-validadas pela equipe de segurança
Bibliotecas de serviço de autenticação e criptografia
Controle de versão para mecanismo de comunicação sobre como as coisas estão
sendo feitas
Manter equipes de projetos envolvidas com a segurança da informação
Integrar equipe de InfoSec no projeto, o mais cedo possível (no final de cada
sprint)
Integração da segurança no pipeline de implantação
Automatizar ao máximo testes de secinfo
Feedback rápido sobre seu trabalho
Detectar e corrigir problemas de segurança com mais rapidez
Telemetria de segurança na aplicação
Logins de usuários (bem e mau sucedidos)
Redefinições de senha
Alteração de end. de e-mail
Alteração de cartão de crédito
Criar alertas sobre eventos importantes para detectar e corrigir mais
rapidamente
Effective Patching

Gerenciamento de Mudanças
Principais controles para reduzir os riscos de segurança na operação

REVISÃO

Telemetria
Informação rápida

Organizações de alta performance possuem capacidade de rapidamente

identificar a causa raíz do problema e corrigi-la rapidamente

Telemetria é um processo automatizado de comunicação de coleta de dados para

dispositivos de monitoramento
Plataforma de monitoração

Necessário criar telemetria entre nossas aplicações e ambientes. Producao, pre-

producao e pipeline de implantacao

Unifircar logs! dev e ops

Visão global do ambiente

Alertas pro-ativos

Framework de monitoramento:
Coletor de dados
Camada do logica de negocios
Camada de aplicacao
Sistema operacional
Roteador de eventos
Armazena eventos e metricas
Threshoulds

Telemetria self-service
 Qualquer pessoa pode ter acesso as informações relevantes
Senso de responsabilidade compartilhada / Cultura sem culpa

Debug level - Monitora sistemas

Info level - ações de usuarios ou sistemas especificos
Warn level - condicao q pode levar ao erro
Error level - info de condicao de erro
Fatal level - ultimo status do erro