EBook - Impulsione Sua Carreira Com DevOps

Cícero Woshington
'
Tudo o que você precisa saber sobre essa forma

moderna e ágil de desenvolver software de qualidade
Apresentação 1
A Academia DevOps 1
O Autor 3
O Ebook 6
Introdução 8
A Engenharia de Software 8
O que é DevOps? 9
1. DevOps: juntando as peças 11
1.1. Desenvolvimento Ágil de Software 12
1.2. Virtualização e Containers 13
1.3. O Fenômeno da Computação em Nuvem 16
1.4. Automação e métricas 18
1.5. Aproximação de Desenvolvedores e Operadores 21
1.6. Infraestrutura como Código 23
Resumo do Capítulo 25
2. Uma Aplicação Segundo DevOps 26
2.1. Plan 28
2.2. Code 29
2.3. Build 30
2.4. Test 31
2.5. Release 32
2.6. Deploy 33
2.7. Operate 34
2.8. Monitor 35
2.9. Aplicação Desenvolvida no Processo DevOps 37
3. Mudança de Cultura 41
3.1. Dificuldades, Falhas e Pessoas 43
3.2. Automate Culture 45
3.3. Mais Software, Menos Documentação 46
4. Principais Ferramentas DevOps 49
4.1. Conhecimentos e Ferramentas básicas 50
4.2. Plan 54
4.3. Code 55
4.4. Build 56
4.5. Test 57
4.6. Release e Deploy 58
4.7. Operate 59
4.8. Monitor 60
5. Conclusão 62
DevOps e a Revolução no Desenvolvimento de Software 1
Apresentação
A Academia DevOps
A Academia DevOps é a materialização de um desejo de três

amigos em compartilhar o conhecimento desenvolvido ao longo de
mais de 20 anos na área da Tecnologia da Informação (TI) atuando
na educação superior e em empresas públicas e privadas, de
diversos portes e segmentos. Nossa missão é transformar vidas e
carreiras de profissionais que atuam nessa área.
A Academia DevOps é uma iniciativa para promover os

conhecimentos relacionados a este que é um dos mais promissores
ramos de atuação da área de TI. Quando estava fazendo minha
mudança de carreira para atuar como DevOps (no início de 2021), a
plataforma Linkedin apresentava algumas poucas vagas de
Engenheiro ou Analista DevOps (em torno de 15 para atuar
remotamente). Hoje, qualquer pesquisa pelo termo DevOps vai
resultar em centenas ou até milhares de vagas (mais de 4000
enquanto escrevo esse e-book). Tenho visto muitas oportunidades
formidáveis que não são preenchidas porque é muito difícil
preencher vagas de Engenheiros DevOps ou porque a disputa pelo
profissional beira o inimaginável. E nem sequer considero o termo
SRE1 que raramente aparecia nas minhas primeiras pesquisas e que
é muito comum hoje.
No momento em que escrevo esse e-book, a empresa na qual

trabalho tem 25 vagas abertas (excluindo banco de talentos e
1
A sigla SRE vem de Site Reliability Engineering, com a tradução livre de Engenharia
de Confiabilidade do Site.
estagiários) e 9 são para DevOps. O segundo lugar é dividido entre

Cientista de Dados e Desenvolvedor Java com 3 vagas cada. E essa
proporção já foi maior em favor de DevOps no mês passado.
Chegamos a ter 11 vagas de DevOps abertas ao mesmo tempo. Eu
mesmo, recebo propostas semanalmente para participar de outros
processos seletivos.
Outra mudança no mercado que é perceptível é que as empresas

queriam apenas profissionais de nível pleno e sênior para as vagas
de DevOps. Hoje, há espaço para juniores e para estagiários
também. As empresas abrem vagas para profissionais de maior
senioridade e acabam contratando um de menor senioridade por
entender que muitos estão fazendo uma transição de carreira. E por
isso, esse é o melhor momento para quem quer investir nessa
mudança de carreira em busca de novas oportunidades
profissionais.
É diante desse cenário de rápidas e profundas transformações em

uma das mais vibrantes áreas profissionais da atualidade que eu,
Cícero Woshington, e meus amigos, Sidney Lima e Allen Vidal,
iniciamos nosso projeto: Academia DevOps.
O Autor
Olá! Eu sou Cícero Woshington e minha trajetória

profissional começa na década de 1990. Em 1998 concluí o
curso técnico com três pensamentos muito fortes: quero
passar em um concurso público (na época o sonho era
assumir o cargo de Técnico de Operações de Rede do TRE
- Tribunal Regional Eleitoral); vou estudar para o resto da
vida (essa é a melhor parte de trabalhar com Tecnologia da
Informação); e que na minha profissão eu lido com
máquinas, não com pessoas.
Das três previsões da época, apenas uma continua

valendo: gosto de estudar e sei que continuarei estudando
por toda a minha vida. Muitos vêem nisso um fardo pesado,
mas se enganam porque o fato de lidar com coisas novas é
muito mais recompensador.
Passei em alguns concursos públicos incluindo Analista da

Infraero, Professor do Instituto Tecnológico de Educação
da Paraíba (IFPB) e Técnico de Operações de
Computadores do SERPRO (Serviço Federal de
Processamento de Dados), cargo que exerci por quase uma
década. Também passei para o cargo que era o meu sonho,
mas desiludido com o serviço público resolvi não assumir.
E mais uma previsão caiu por terra: tornei-me professor

universitário. Atividade que obviamente me fez lidar de
forma intensa e renovada a cada semestre com muitas
pessoas. O que foi transformador para mim, pois me
permitiu contribuir de maneira decisiva com conquistas

profissionais e pessoais de muitos de meus alunos.
Ministrei várias disciplinas, como Sistemas Operacionais,
Redes de Computadores, Gerência de Redes, Computação
em Nuvem, Engenharia de Software, Sistemas Distribuídos.
Sempre tentei tornar prática a minha abordagem e entendo
que fiz um bom trabalho. Durante minha jornada como
professor concluí a graduação em Tecnólogo em
Automação Industrial, minha especialização em Engenharia
de Software e meu mestrado em Engenharia de Software.
Tudo isso foi importante para minha carreira como
professor e na minha atuação como DevOps hoje.
Assim que terminei o mestrado tive a certeza de que

algumas das práticas usadas no que eu acabava de
conhecer como DevOps precisavam ser ensinadas aos
meus alunos (nessa época eu atuava em um curso de
bacharelado em Sistemas de Informação). Inserimos a
disciplina de Computação em Nuvem no curso e passei a
abordar algumas dessas práticas nas disciplinas de
Gerência de Redes e Sistemas Distribuídos. Muitos alunos
logo reconheceram a importância desses ensinamentos.
Outros reconheceram depois de ir para o mercado.
Por fim, eu mesmo percebi que eu precisava assumir uma

posição como Engenheiro DevOps para mergulhar ainda
mais e oferecer mais aos meus alunos. Mas esse mergulho
foi tão fundo que acabei deixando de lecionar para me
dedicar apenas ao novo desafio. E não me arrependo do
que fiz. Nem quando deixei o serviço público nem quando
decidi deixar de ser professor. Mas sinto falta da interação
com os alunos e do ambiente de ensino e aprendizagem

que preciso promover para mim mesmo por toda a vida.
Por isso, gostaria de compartilhar vários detalhes que me
foram importantes para assumir a responsabilidade como
um Analista DevOps, responsabilidade essa que faz meus
olhos brilharem a cada desafio. Também quero contar com
as sugestões de todos para retomar aquelas interações tão
ricas que eu tinha como professor.
O Ebook
O conteúdo apresentado neste material pode ser uma forma rápida

de compreender o que é ser um Engenheiro DevOps e quais os
principais passos para iniciar nessa área. Tenho plena convicção de
que qualquer um que tenha conhecimento mínimo da área de
Tecnologia da Informação e Desenvolvimento de Software vai
encontrar neste ebook as informações necessárias para formar
opinião e tomar a decisão correta. Mais que isso, esse ebook vai
mostrar as principais mudanças comportamentais e as principais
ferramentas a estudar.
Apesar de insistir na mudança de carreira, este ebook também vai

apresentar informações úteis para outras ocupações relacionadas à
Tecnologia da Informação:
● Gestores, Gerentes de Projeto, Tech Leaders e Chief
Technology Officers vão compreender melhor as vantagens e
desafios na adoção de DevOps.
● Desenvolvedores e Quality Assurance vão compreender
melhor quais os desafios de trabalhar em um time que segue o
modelo DevOps.
● Product Owners, Engenheiros de Requisitos e UX Designers
vão compreender melhor a dinâmica do processo de software
compatível com DevOps.
Esse ebook está dividido em cinco capítulos. O primeiro capítulo

mostra a relação entre DevOps e a Engenharia de Software, o
contexto do surgimento e as tecnologias mais intimamente
associadas. O segundo capítulo apresenta o processo de
desenvolvimento de software e suas características de acordo com
o modelo DevOps. O terceiro capítulo apresenta mudanças culturais
e comportamentais. O quarto capítulo mostra as principais
ferramentas utilizadas nas atividades de DevOps. O quinto capítulo
apresenta algumas recomendações finais para todos os
profissionais de TI que querem dar esse novo direcionamento às

suas carreiras.
Espero que gostem de tudo que está sendo preparado aqui e que
aproveitem ao máximo esse compilado de informações sobre
DevOps. Estamos trabalhando para produzir muitos outros materiais
didáticos para a Academia DevOps. Para sugestões de melhorias e
correções (sempre bem vindas), utilize o e-mail
suporte@academiadevops.dev.br.
Introdução
A Engenharia de Software
A Engenharia de Software nasceu olhando para outras engenharias

e, naquele momento, isso fazia muito sentido. Estamos falando das
décadas de 70 e 80 quando o cenário da computação era dominado
por mainframes com reduzida capacidade de processamento de
dados, mas começava a apresentar rápidas e contínuas
transformações. Em algum momento nessa transição, os
profissionais da Tecnologia da Informação sentiram falta de
ferramentas e processos para tratar o software que crescia
constantemente. Crescia rapidamente porque computadores tinham
cada vez mais recursos e se tornavam cada vez mais baratos como
acontece até hoje.
Os profissionais de então olharam em volta em busca de soluções e

passaram a “desenhar” o software antes de construí-lo, como os
Engenheiros Civis faziam antes de construir um prédio. Disso
nasceram várias iniciativas e temos até hoje os diagramas UML para
nos ajudar a especificar um software para que possa ser “visto”
antes de virar código.
Também olharam para a Engenharia de Produção e viram como os

processos de produção usados nas fábricas poderiam ser utilizados
na produção de software. O Kanban é um ótimo exemplo já que foi
criado por um engenheiro e usado na Toyota antes de ser adotado
como um processo de software.
Várias outras ideias podem ser citadas como métricas e auditorias

que vieram dos modelos de qualidade, como os planejamentos
estratégicos que vieram das ciências da administração, até da área
de UX que veio do estudo da cognição e da neurociência. Mas o
objetivo não é estudar como a Engenharia de Software chegou na
condição atual e sim analisar o passo que está sendo dado rumo ao
futuro chamado de DevOps.
O que é DevOps?
DevOps é um conceito difícil de sintetizar e por isso mesmo não é

fácil encontrar uma frase pronta e simples para apresentar aqui.
Acredito que qualquer um que tentar produzir essa simplificação
corre o risco de não abordar adequadamente todos os aspectos
interessantes que o conceito abriga. Mesmo sabendo dos riscos
das simplificações, entendo que uma abordagem muito rica em
detalhes e trazendo extensa discussão sobre o assunto pode
comprometer a boa compreensão da essência de conceitos
complexos. Assim, nas próximas páginas deste ebook tentei trazer
um equilíbrio para a amplitude, profundidade e clareza da
abordagem que proponho.
Para muitos DevOps é um modelo de processo de software, ou seja,

estabelece um conjunto de atividades, parcialmente ordenadas,
com a finalidade de gerar um produto de software. Para outros,
DevOps é um cargo de um operador que participa ativamente no
desenvolvimento de software, promovendo comunicação frequente
e colaboração em tempo real entre os times de desenvolvimento e
o pessoal de operações/suporte de TI, disparando e coordenando
fluxos de atividades. Há outros que afirmam que DevOps é uma
cultura que busca a promoção de uma dinâmica de trabalho onde
as interações entre as pessoas envolvidas em projetos de
desenvolvimento de software são colocadas acima do produto. Há
outros ainda que afirmam que são ferramentas e práticas
empregadas na elaboração de um software. A verdade é que todos

têm razão. DevOps é tudo isso e muito mais.
Uma ideia que me agrada muito é que DevOps continua sendo

aquela mesma busca que resultou na Engenharia de Software. Em
minha sincera e humilde opinião, ainda precisamos aperfeiçoar a
Engenharia de Software e DevOps é mais uma tentativa nesse
sentido. Por isso, como autor e profissional diretamente envolvido
nessa área tão empolgante e necessária, busquei apresentar neste
material o que considero um conjunto de pensamentos essenciais
não apenas para entender o que é DevOps, mas para se preparar
para o próximo passo da Engenharia de Software e da própria
Tecnologia da Informação.
1. DevOps: juntando as peças
DevOps é um conjunto muito grande de elementos relacionados ao

desenvolvimento de software. Antes de explorar cada item desse
conjunto, vamos tentar entender o contexto no qual essas ideias
foram materializadas e associadas. DevOps é uma ideia dos anos
2000, já no fim da década, e nesse momento o contexto era:
● Smartphones eram acessíveis e poucas pessoas ainda usavam

telefones tradicionais e a telefonia já havia dado muito espaço
para a comunicação pela Internet.
● O acesso à Internet era amplamente difundido e quase todos
passavam a ter Internet em casa ou acessavam a partir de
seus smartphones.
● Muitas pequenas empresas com ideias centradas na
Tecnologia da Informação e Comunicação estavam crescendo
e passaram a ser chamadas de startups bem depois do
estouro da bolha ponto-com.
● Muitos pequenos negócios baseados em TI passaram a
crescer e viram na computação em nuvem um mecanismo
eficaz para a escala do negócio.
● Muitas plataformas computacionais e linguagens de
programação disputavam o mercado com uma divisão
fortemente inclinada para o Java e o modelo cliente-servidor.
● Uso de virtualização como uma ferramenta para separar
serviços sem ter de se preocupar com essa divisão no
hardware ou com o sistema operacional instalado.
Foi nesse contexto que muitas empresas começaram as iniciativas

que culminaram no que conhecemos hoje como DevOps. Nas
próximas seções, algumas dessas iniciativas são apresentadas.
1.1. Desenvolvimento Ágil de Software

Hoje, as atividades de DevOps são amplamente suportadas por
alguns tipos de ferramentas de software que até uma década atrás
nem mesmo existiam. E o interessante é perceber que algumas
dessas ferramentas e também algumas práticas foram criadas para
dar apoio ao negócio e/ou resolver problemas específicos de
algumas das grandes empresas do segmento de Tecnologia da
Informação. E embora os contextos e abordagens que resultaram
no surgimento dessas ferramentas e práticas tenham suas variantes
o objetivo é o mesmo.
Por um lado, temos empresas que desenvolveram suas próprias

soluções como forma de estabelecer um diferencial competitivo,
caso especial de startups e negócios baseados fortemente na
Tecnologia da Informação. Essas empresas sabiam que enquanto
elas eram as únicas que resolviam aquele problema específico do
cotidiano teriam todo um mercado para crescerem sozinhas. Mas
no momento que um concorrente tivesse um produto de software
equivalente, teriam de dividir o mercado. Crescer rápido era
fundamental, como é até hoje para as empresas que se encaixam
nesse perfil.
Por outro lado, havia também empresas que enxergavam que esses
softwares não eram a razão de ser das empresas que os inventaram
e para elas era interessante disponibilizá-los na forma de software
livre. Isso seria uma forma de alavancar o desenvolvimento do
software de apoio com colaboradores externos ajudando
diretamente no desenvolvimento e aumentando rapidamente a base
de usuários que experimentam e comprovam o funcionamento.
Assim, o Docker foi inventado para suportar um negócio de
computação em nuvem e o Kubernetes foi inventado para suportar
as operações do Google.
Com isso tínhamos duas vertentes, aparentemente opostas, mas

com um interesse muito importante em comum: desenvolvimento
ágil de software. Para algumas era importante desenvolver
rapidamente e estar um passo à frente. Para outras era importante
ter uma ferramenta de apoio pronta o quanto antes e em constante
evolução. E a maior parte dessas empresas foram as primeiras a
adotar a cultura e as práticas e ferramentas DevOps.
Portanto, a primeira coisa a ter em mente quando for pensar em

DevOps é saber que suas raízes estão no desenvolvimento ágil de
software. Assim, adotar DevOps é adotar também o desenvolvimento
ágil em alguma medida (quanto mais melhor).
1.2. Virtualização e Containers

A Virtualização consiste na criação de um ambiente de computação
virtual em vez de um ambiente físico. Isso permite a simulação de
uma plataforma de hardware, sistema operacional, dispositivo de
armazenamento ou recursos de rede. Assim, um único computador
físico ou servidor pode abrigar diversas máquinas virtuais e cada
máquina virtual pode interagir de forma independente e executar
diferentes sistemas operacionais ou aplicativos ao mesmo tempo
compartilhando os recursos de um único computador host.
Embora a Virtualização não seja algo tão recente na computação,

podemos dizer que nessa época, pois virtualização não era uma
novidade e a maioria das empresas já usava. Mas, foi em meados
dos anos 2000 que ferramentas e técnicas de virtualização se
tornaram extremamente populares, não apenas nos ambientes
organizacionais, mas também nos desktops e notebooks de
profissionais de diversas áreas e até usuários domésticos. Até
mesmo fora dos ambientes das empresas, a virtualização se
popularizou. Muitos estudantes e professores usavam virtualização
como um ambiente de testes isolado do seu computador pessoal. E
essa era uma das características mais apreciadas na época: o

isolamento.
Usando uma máquina virtual podemos dar garantia que o sistema

operacional instalado na virtual machine (ou VM) está realmente
limpo e não se comunica diretamente com o sistema hospedeiro ou
host. Esse isolamento adicionado ao fato de que se algo der errado
dá para descartar tudo e iniciar novamente sem prejuízos deu
muitas ideias às empresas que buscavam por agilidade e
desempenho.
Por exemplo, ter uma aplicação rodando em um servidor virtual e

ter a possibilidade de iniciar outra VM com uma cópia da aplicação
no caso da VM titular enfrentar um problema parece muito
interessante. Ou ainda, durante um pico, ter uma VM titular e
adicionar uma réplica para dividir a carga de processamento. Essas
ideias passaram a ser consideradas cada vez mais, até que duas
inovações surgiram: containers e clusters de containers.
O grande problema de aplicar essas ideias com máquinas virtuais é

que os sistemas virtuais são grandes e levam muito tempo para dar
boot. Isso deixa a reação esperada lenta, especialmente nos casos
em que se quer uma resposta a um excesso de carga. Muitas
iniciativas foram desenvolvidas para deixarem as máquinas virtuais
menores, ao mesmo tempo em que ideias de alguns sistemas
operacionais que apresentavam um comportamento parecido foram
avaliadas e a evolução disso foi o que conhecemos hoje como
container.
Um container é um núcleo de sistema operacional, quase sempre

um kernel Linux, que não apresenta todos os componentes de um
sistema operacional. No lugar de todos os utilitários que seriam
embarcados, apenas uma aplicação e suas dependências são
incluídas num container. Outro detalhe é que mesmo a configuração
do kernel usado no container é feita no host e um ambiente
(container runtime) é necessário para compartilhar esse kernel.

Portanto, uma imagem de container instalada em um computador
tradicional não pode ser chamada de sistema operacional pois não
seria “operacional”.
Com as mesmas características de isolamento de uma VM e com

uma escala 10 vezes menor (ou mesmo 100 vezes menor em alguns
casos), todas as ideias imaginadas anteriormente passaram a ser
factíveis. Dá para subir 10 servidores na forma de container usando
o mesmo recurso que um único servidor usava como uma máquina
virtual. Como o “disco” ou imagem de container só tem a aplicação
a rodar (o kernel é o mesmo do host) e como não precisa dar boot e
esperar os serviços de um sistema operacional subirem, dá para
iniciar rapidamente, desligar quase que instantaneamente, rodar
vários serviços simultaneamente. E é exatamente isso que fazemos
hoje.
E quando um servidor fica sobrecarregado, dá para copiar a

imagem pela rede, rodar réplicas dos recursos num servidor com
recursos sobrando e ajudar num momento crítico. Por isso
precisamos de clusters e orquestradores de containers que avaliam
os recursos disponíveis em vários servidores e distribuem a carga
de modo a ter um crescimento sempre estável e linear, mesmo que
o uso dos serviços internos seja aleatório e imprevisível.
1.3. O Fenômeno da Computação em Nuvem

Foi nessa época também que a computação em nuvem apareceu e
se tornou basicamente o que é hoje. Muitas evoluções acontecem,
é claro, mas os serviços mais usados e as ideias mais disruptivas
foram dessa época.
E o fenômeno que dá título à seção não é o que a maioria pensa

como a ideia de “migrar para nuvem”. Nem o que já foi comentado
como potencial de escala para empresas baseadas em TI como as
startups. Essas coisas são interessantes e importantes em
diferentes graus, mas o que torna a computação em nuvem um
fenômeno é a transformação de hardware em software sob
demanda!
Há, espera um pouco, transformar hardware em software não é uma

mudança colocada em curso pela computação em nuvem, mas pela
virtualização. A verdade é que se você pudesse “abrir o capô” de
um provedor de nuvem, veria que o “motor” é na realidade
virtualização. Mas a computação em nuvem conseguiu algo que a
virtualização não conseguiu: desvincular completamente o
hardware do software e transformá-lo em um serviço sob demanda.
Assim, podemos dizer que a Computação em Nuvem consiste no

fornecimento escalável e sob demanda de capacidades e recursos
computacionais oferecidos na forma de serviço, por meio da internet.
Imagine virtualização em uma empresa. A empresa compra os

servidores e usa virtualização para transformar todo esse recurso
de hardware em componentes de software na forma de máquinas
virtuais. Essas máquinas virtuais podem ser exatamente como os
servidores eram usados ou podem ser um conjunto de máquinas de
modo que em cada uma há uma pequena porção do meu software e
se uma máquina virtual parar o software não para por completo.
Mas calma, estou me adiantando, falaremos de microsserviços e
escalabilidade em breve…
O fato é que para essa empresa, o limite dos recursos continua

sendo o hardware adquirido inicialmente. Transformar hardware em
software ajuda em várias atividades, mas não resolve
completamente o problema da escala e da utilização sob demanda.
O ideal seria que a empresa pudesse “alugar” mais recursos de
hardware para tratar um pico na demanda e “devolver” o hardware
depois de usá-lo. Acho que esse exemplo deixa claro que isso só é
possível usando virtualização, mas é o fato de poder usar quando
quiser que coloca a computação em nuvem em outro patamar.
Muitos modelos de negócio nasceram transformando propriedade

(aquisição) em aluguel (leasing). Por exemplo, as grandes
impressoras laser e fotocopiadoras eram caríssimas assim que
passaram a ser comercializadas e a maioria dos fabricantes tinha
algum modelo de aluguel que embutia a manutenção e o valor do
equipamento diluído ao longo do tempo. É exatamente o caso aqui
com a computação em nuvem. O que foi mais revolucionário foi o
esquema de entrega desses recursos: a Internet. Até então, poucas
iniciativas haviam tentado alugar algo pela Internet e nenhuma
delas deu tão certo quanto a computação em nuvem. Até então, no
máximo, o aluguel acontecia na forma de uma transação eletrônica,
mas o bem circulava fisicamente por algum serviço de entrega.
Com a computação em nuvem, até o acesso ao bem alugado é pela
Internet.
1.4. Automação e métricas

A automação no desenvolvimento de software foi sempre
perseguida. Tentar passar para a ferramenta o encargo relacionado
às tarefas repetitivas sempre aconteceu. Porém, os containers
elevaram exponencialmente essa necessidade. Primeiro porque
agora, no lugar de ter meia dúzia de servidores, a aplicação roda
em dezenas de containers. Em segundo lugar, porque os
desenvolvedores viram nos containers uma outra possibilidade
muito interessante: os microsserviços.
Com microsserviços, no lugar de colocar uma aplicação toda para

rodar em uma única plataforma (por exemplo colocar todo o código
Python rodando em um único servidor com Django instalado),
pode-se dividir o código em unidades menores e colocar uma
comunicação pela rede (já que efetivamente essa comunicação
acontece apenas no sistema operacional do host). Com isso é
possível ter containers ainda menores que executam e respondem
aos problemas mais rapidamente.
Além disso, há a possibilidade de escalar somente a parte que está

sendo efetivamente sobrecarregada. Por exemplo, uma aplicação
está recebendo o dobro de requisições que recebe normalmente
pela rede, faz algum processamento e salva o resultado no banco
de dados. Como é um container só para tudo, deve-se replicar e
passar a ter dois containers fazendo as mesmas operações em
paralelo.
Mas a aplicação pode ser dividida em 3 containers: um para receber

a requisição, outro para fazer o processamento e o terceiro para
salvar em um banco de dados. Pode-se perceber que apenas o
segundo container está sobrecarregado. Então replica-se apenas o
segundo mantendo um para receber a requisição que vai distribuir
igualmente para os dois que estão realizando o processamento e
estes vão enviar tudo para o último que trata de salvar no banco de
dados.
Exemplo simples com 3 imagens de container diferentes que vão

executar em 4 containers no ambiente. Mas a realidade é diferente!
Seguindo o modelo de microsserviços, poderiam ser várias imagens
de container (na faixa de dezenas) rodando em uma escala bem
maior (na faixa de centenas) para uma grande aplicação. E é
comum ter várias aplicações. Por isso, é necessário automatizar.
Imagine que antes você tinha um código só que precisava ser

compilado. A compilação demorava muito, mas uma vez terminada,
o artefato de software está pronto para ser executado. Agora você
tem 30 trechos de código separados em módulos, cada um
gerando uma imagem de container diferente. Você (como eu) já
deve estar pensando em como rodar um comando só e fazer os 30
trechos de código funcionarem de uma vez.
Na realidade existe uma estratégia melhor. Como o Git2 se tornou o

padrão de controle de versão de código, imagine que o momento
certo para disparar o processo de compilação é a instrução git push
que envia uma nova versão de código para o repositório. Então, no
repositório há um evento que dispara a compilação. Mas já que
estamos automatizando, vamos além… Vamos compilar e disparar
um teste, se o teste for bem sucedido criamos uma nova versão da
imagem e se a criação da imagem der certo implantamos logo no
ambiente de desenvolvimento. Mas e se pudermos fazer o teste de
integração no ambiente de desenvolvimento e, caso tudo dê certo,
entregarmos logo no ambiente de homologação? Não há limites
para a automação em desenvolvimento de software. E quanto mais
automatizado o processo melhor, desde que feito de forma
confiável.
2
Git é um sistema de controle de versões, usado principalmente no desenvolvimento de
software para versionamento de código, mas que pode ser usado para registrar o histórico de
edições de qualquer tipo de arquivo.
Outra coisa interessante de automatizar é a própria administração

dos containers. Imagine que no exemplo dos três containers usado
anteriormente, pudéssemos configurar uma regra do tipo:
IF ( (CPU > 0.8) OR ( MEM > 800M ) ) {

REPLICAS += 1
}
Seria ótimo ver a quantidade de réplicas subindo magicamente toda

vez que o container estiver sobrecarregado. Melhor ainda,
diminuindo quando a sobrecarga passa porque quando está tudo
parando a gente sempre vai ver o que está errado, mas quando
passa ninguém lembra de voltar lá, pois sempre tem algo mais
importante para tratar.
Por isso, métricas são tão importantes. Tanto para os operadores

entenderem o que acontece com os containers quanto para os
orquestradores de container nos ajudarem na administração.
Monitorar os recursos utilizados é o primeiro passo para alocá-los
de maneira eficiente e resolver os problemas. Métricas e logs vão
ser a principal fonte de informação quando algo estranho acontece
e, mesmo que já tenha sido resolvido, você não deseja que
aconteça novamente.
1.5. Aproximação de Desenvolvedores e

Operadores
Com as mudanças que vimos até agora, já dá para ter uma ideia de
que algumas tarefas ficam bem no meio das atividades de
desenvolvimento e operação. O pipeline3, por exemplo, começa
com um push no código (tarefa de desenvolvedor) e termina com a
implantação de uma aplicação em um servidor (tarefa de operador).
Mas o pipeline, muitas vezes, é um elemento único que executa
todas essas etapas. Fica muito claro que essa tarefa não vai ser
bem executada sem uma colaboração de ambas as partes.
Se o desenvolvedor fizer o pipeline, pode ser que ele consiga

compilar e testar o código corretamente. Provavelmente, o build do
container também vai ser tão bem feito quanto o esperado. Mas ele
vai precisar da ajuda para saber como implantar de forma
automatizada no cluster de destino. Da mesma maneira, o operador
vai precisar de ajuda para testar o código corretamente e para
avaliar os resultados dos testes antes de prosseguir.
Essa é geralmente a responsabilidade do Engenheiro DevOps4.

Aproximar-se dos desenvolvedores para compreender melhor o
código e aproximar-se dos operadores (geralmente são chamados
de SRE ou Site Reliability Engineering) para compreender bem onde
a aplicação vai rodar é o compromisso desse profissional. Mais que
isso, ele deve ser a ponte para que Devs e SRE entrem em contato
diretamente uns com os outros, afinal, o objetivo é a colaboração.
3
Um pipeline de DevOps é um conjunto de processos e ferramentas automatizados que
permitem que desenvolvedores e profissionais de operações trabalhem de maneira coesa na
criação e implementação de código em um ambiente de produção.
4
Uso sempre o termo Engenheiro DevOps ou Analista DevOps para identificar o profissional.
DevOps, pura e simplesmente, é um termo que pode ser associado a muitas outras atividades.
Mas o pior é que os desenvolvedores acreditam muitas vezes que não precisam entender
sobre DevOps já que existe o profissional DevOps para isso. Desenvolvedores só devem ser
incluídos em um ambiente DevOps se entenderem que também são Desenvolvedores DevOps.
Apesar, de ter sido usado um exemplo de pipeline, que é uma

atividade importante, o Engenheiro DevOps têm várias outras
responsabilidades dependendo do meio em que trabalha: cria,
modifica e monitora o ambiente de execução da aplicação; resolve
problemas, aplica soluções em escala, controla a infraestrutura
como código… Por falar em infraestrutura como código…
1.6. Infraestrutura como Código

Comentei nas seções anteriores que uma das vantagens da
virtualização e (principalmente) da computação em nuvem é
transformar hardware em software. Essa é a razão de ser das
ferramentas de infraestrutura como código ou IaC. A ideia aqui é
que se eu consigo criar um servidor virtual com um comando,
vamos usar essa estratégia para criar toda a infraestrutura e não
apenas um servidor.
Inicialmente, era assim mesmo que as coisas aconteciam: um script

era a melhor forma de automatizar a implantação da infraestrutura.
Depois a ideia evoluiu e um processo muito parecido com uma
compilação foi adotado. Um código declarativo5 tomou o lugar do
código imperativo. Uma ferramenta ou plugin interpreta o código e
aplica os recursos no ambiente.
Se algum recurso precisa ser modificado, uma mudança no código e

uma nova aplicação é feita para que o ambiente seja um reflexo
exato do código IaC. E não é por acaso que você deve ter lembrado
do pipeline da seção anterior. A mesma ideia pode ser aplicada
aqui.
Aliás, todas as ideias aplicáveis ao desenvolvimento de software

são bem vindas. Testes dos artefatos de código IaC podem evitar
problemas de implantação. Replicação, criar um ambiente ou criar
vários é equivalente a executar o mesmo código várias vezes
mudando apenas as configurações necessárias. Reusar
configurações usadas em determinado contexto pode ser a base
para configurar um componente parecido em outro. Usar uma
ferramenta de controle de versão de código para registrar quando
cada mudança aconteceu e sua justificativa. Enfim, hardware é
5
Código declarativo é um código na forma de uma lista de itens, como declarações de
variáveis, classes e atributos. Um código imperativo tem a forma de uma lista de ações ou
comandos. Ambos têm o mesmo efeito prático, mas declarar um servidor como se fosse uma
classe e suas características como atributos parece interessante. Bem mais que todos os
comandos para instalar uma aplicação ou serviço rodando scripts.
tratado como software aproximando mais ainda desenvolvedores e

operadores.
Mas não se engane. Muitas atividades ainda vão exigir os

conhecimentos usados na administração de servidores, redes e
sistemas operacionais. Afinal, recursos virtuais precisam de uma
plataforma para rodar e por mais que tentemos esconder os
servidores, eles continuam lá. Nem tudo pode virar um container e
ser replicado livremente e todos esses recursos precisam conviver
com serviços tradicionais.
Resumo do Capítulo
Partindo de um contexto temporal, vimos neste capítulo como

todas as principais ideias relacionadas à cultura, práticas e
ferramentas DevOps foram materializadas:
● Como a lógica do desenvolvimento ágil foi usada por várias

empresas inovadoras do segmento de Tecnologia da
Informação para a execução de seus próprios processos de
desenvolvimento de software, contribuindo para o surgimento
de práticas e ferramentas de DevOps.
● Como a computação em nuvem foi importante para
transformar hardware em software sob demanda e dar
possibilidade de escala.
● Como a virtualização e os containers mudaram as operações e
como foi possível tornar as aplicações mais resilientes.
● Como as atividades de automação tornaram possível
administrar o volume crescente de artefatos de software na
forma de containers e microsserviços.
● Como essas atividades aproximaram desenvolvedores e
operadores e exigiram um ambiente de maior colaboração.
● E como IaC tornou a implantação da infraestrutura uma tarefa
de desenvolvimento, mesmo que muitas das atividades ainda
sejam de operação.
2. Uma Aplicação Segundo DevOps
O conjunto que representa DevOps já tem vários elementos. Todos

esses elementos foram apresentados no capítulo anterior junto de
seu contexto e sua justificativa. Agora é o momento de colocá-los
em uma ordem e compreender melhor como colaboram entre si
para descrever um modelo de processo de software e o objetivo
desse modelo: entregar valor na forma de um produto de software.
Em outras palavras, vamos refinar o que vimos anteriormente
focando especialmente no modelo de processo de software e na
aplicação desenvolvida. Nos próximos capítulos o objetivo será
aprofundar na cultura e nas ferramentas.
O modelo de processo de software segue todos os valores e

princípios ágeis e esse é o fundamento do modelo adotado pelas
equipes DevOps. Apenas para relembrar são quatro os valores
descritos no manifesto ágil (https://agilemanifesto.org):
● Indivíduos e interações acima de processos e ferramentas

● Software funcionando acima de documentação compreensiva
● Colaboração com o cliente acima de negociação contratual
● Responder a mudanças acima de seguir um plano
Baseado nisso, não espere que o modelo DevOps seja um processo

descritivo que diz exatamente o que cada membro do time deve
fazer. O modelo é bem adaptável e a ideia é muito mais uma
maneira de promover esses valores adotando ou não algumas
práticas. Tudo depende muito do time, do ambiente no qual executa
suas tarefas e do desafio que enfrenta.
Para a apresentação do modelo de processo de software DevOps

vários autores usam uma figura que representa um ciclo contínuo na
forma do símbolo do infinito6. Do lado esquerdo temos as etapas

diretamente relacionadas ao desenvolvimento e do lado direito as
etapas relacionadas à operação.
As etapas apresentadas na cor azul são etapas de desenvolvimento

e as etapas na cor verde são etapas de operação. Você vai
perceber que essa figura não é unanimidade e há várias diferentes
versões. Em uma dessas versões as etapas test e release são
chamadas de continuous integration e as etapas monitor e plan são
chamadas de continous feedback. Faz sentido já que essas são as
etapas em que se passa de um lado ao outro do ciclo. Há outra
versão que inclui a parte de modelagem de software entre plan e
code. Outra que especifica etapas de teste mais detalhadas e outra
que chama release de integration. E mais uma que coloca deploy
antes de release. Há ainda modelos que tentam mapear a
segurança e estabelecer o modelo DevSecOps. Geralmente incluem
uma etapa de resposta a incidentes nesse diagrama. E se estiver
6
O símbolo do infinito tem um nome “oficial”, mas pouco conhecido: “lemniscata”; que, em
grego, significa algo como “guirlanda” (uma espécie de coroa de flores que pode ser usada
como objeto decorativo em portas, por exemplo).
disposto a catalogar essas diferentes versões vai rapidamente

perceber que estamos longe de um consenso em definir
exatamente que etapas são essas. Mais uma prova de que o
modelo não é prescritivo e quem quiser adaptá-lo está livre para
fazê-lo.
O consenso é que temos etapas de desenvolvimento do lado

esquerdo, compatíveis com tudo o que a Engenharia de Software
propôs antes de DevOps e etapas de operações à direita. E temos
um novo passo na evolução da Engenharia de Software: incluir as
operações no processo de desenvolvimento de software. Até então,
muito do que se fez foi incluir elementos relacionados à operação
(como a gerência de configuração para citar um exemplo), mas
incluir todas as operações em um modelo bem sucedido de
desenvolvimento de software acontece pela primeira vez com
DevOps.
2.1. Plan
Tudo começa com um planejamento inicial. É o que conhecemos
como Sprint Refinement e Sprint Planning no Scrum ou
Replenishment Meeting na adaptação de David J. Anderson para o
Kanban. O objetivo é especificar as tarefas a serem executadas
pelo time, definir como são avaliadas, mapear riscos e dificuldades.
O foco é sempre ficar atento ao menor conjunto de tarefas que,
devidamente executadas, entregam valor ao cliente. Também é
importante postergar a análise daquelas tarefas que são
importantes, mas que não têm os requisitos necessários para serem
iniciadas.
O plano também deve ser adaptável. A ideia, mais uma vez, é não
ser prescritivo e dar a autonomia para que cada um possa entregar
a tarefa da forma que julgar melhor. É necessário garantir aos
membros que a ajuda virá quando necessário. Desenvolvedores
precisam ter a ajuda dos operadores se sua tarefa mostrar essa
necessidade (vice-versa). Portanto, é muito comum planejar alguns

momentos de interação para cada um mostrar as suas dificuldades
e receber sugestões. Muitas vezes esses momentos acontecem
sob demanda e cada um vai direto àqueles que podem ajudar
quando precisam.
É muito importante ter uma equipe auto-gerenciada para que cada

membro seja capaz de administrar seu próprio tempo e equalizar o
tempo que leva em suas próprias tarefas e o tempo que leva
ajudando nas tarefas de outros. Além disso, a equipe deve ser
muito aberta e cada um deve relatar o quanto antes os seus erros
para receber ajuda. Tudo isso torna cada membro da equipe um
especialista de modo que todos sabem a quem recorrer quando
determinado assunto aparece e trabalham juntos para os assuntos
novos.
2.2. Code
Uma vez estabelecidas as tarefas e o modelo de colaboração, cada
um começa a executar as tarefas de desenvolvimento. Muitos
interpretam essa etapa do ciclo como atividades exclusiva de
desenvolvedores. Outros interpretam que operadores vão
desenvolver seus artefatos de IaC, de operação (como os usados
no Ansible apenas para citar um exemplo), pipelines, etc. O fato é
que seja nessa etapa ou nas etapas de release, deploy e operação,
essas atividades de codificação também serão executadas pelos
operadores.
É muito importante ter uma ideia de como o código é tratado no

pipeline para: (1) preparar o código para essa execução e (2) ter a
ideia de quais repercussões de um push de código. Imagine que o
pipeline faz toda a execução até o ambiente de produção e um
desenvolvedor pensa: “vou fazer um push só para gerar uma
imagem e poder testar…” Ele precisa saber que seu push não vai
apenas construir a imagem, mas também vai atualizar o deploy no
ambiente de desenvolvimento, ou mesmo, no ambiente produtivo.
E para não entrar muito na Engenharia de Software e ater-me ao

modelo de processo DevOps, uma pequena lista de como o
desenvolvimento precisa ser adequado:
● Padrões de código: PEP, docstrings, comentários, utilização

do Git (git-flow), frameworks e design patterns, modelos, etc.
● Padrões de teste: revisões, ferramentas de teste, camadas de
teste, automação, etc.
● Ferramentas: editores, codificação do texto, distribuição de
informações sensíveis, etc.
2.3. Build
O build é a etapa de construção do artefato de software no formato
em que vai ser utilizado no ambiente de runtime. Porém, muitas
checagens podem acontecer antes dessa construção,
especialmente checagens de estilo de código e testes estáticos. É
comum ter uma checagem de segurança também.
Checagens de estilo de código verificam se o código respeita

algumas regras de apresentação. O formato dos comentários e
docstrings, o tamanho máximo das linhas, a quantidade de atributos
de uma classe ou argumentos de um método. São elementos que
não geram erro, mas que melhoram a legibilidade e
manutenibilidade de um código.
Testes estáticos focam nos possíveis erros de um código sem a

necessidade de executá-lo. Variáveis não utilizadas, métodos não
executados, loops que podem nunca terminar, erros de sintaxe são
alguns exemplos. Muitas vezes não são incluídos no build do
pipeline por serem facilmente executados no próprio editor de
código, na etapa anterior.
Checagens de segurança são interessantes e evitam expor

informações sensíveis. Por exemplo, o desenvolvedor precisa incluir
as credenciais do banco de dados ou de acesso a algum recurso de
nuvem para testar seu código localmente. É muito comum usar um
arquivo com variáveis de ambiente junto do código. Porém, essas
informações não deveriam constar no repositório. A checagem de
segurança busca verificar se o código apresenta alguma informação
como essa.
Então temos o build propriamente dito. O código vai ser compilado

e a imagem de container criada. De acordo com a linguagem de
programação usada, o código não precisa ser compilado e pode ser
testado diretamente. Ou pode ser que o teste só possa ser
executado depois de haver uma imagem container pronta. De uma
forma ou de outra, temos uma etapa que inclui a construção da
imagem e os testes dinâmicos.
Muitas vezes, o pipeline também inclui a etapa de implantação

(continuous deploy), mas o build trata apenas da construção
(continuous integration). Cada equipe precisa avaliar o que é melhor
para seu próprio processo.
2.4. Test
Um bom estudo de testes aqui pode ser interessante para avaliar
quais os tipos de testes incluir no pipeline e quais testes serão
feitos após o build, manualmente. Testes unitários, de integração,
funcionais, end-to-end, de carga e performance podem ser
incluídos para executar nos diversos ambientes automaticamente.
Às vezes, é bom ter a avaliação de um QA7 experiente. Mais uma
vez a Engenharia de Software já tem muito a oferecer e vou me ater
ao que o modelo DevOps inclui como inovação. De maneira geral, o
7
A sigla significa Quality Assurance (QA), que pode ser traduzido como “Garantia de
Qualidade”, faz referência a um profissional ou uma equipe cuja função é garantir a qualidade
no desenvolvimento de um produto ou serviço, no caso específico um produto de sofware.
que dita os testes necessários é a realidade que a aplicação vai

enfrentar no ambiente de produção.
Do ponto de vista DevOps, todo trabalho repetitivo deve ser

automatizado. Portanto, todo teste que segue um padrão específico
deve ser automatizado. Desenvolvedores e QA devem se preocupar
apenas com as atividades que não podem ser automatizadas ou
verificar resultados dos testes que mostram alguma inconsistência.
O ideal é um ciclo no qual desenvolvedores e QA analisem as

deficiências dos testes automatizados e apresentem novas
oportunidades de automação. A longo prazo, todos os testes
necessários seriam automatizados e os desenvolvedores e QA vão
apenas avaliar os resultados e propor melhorias no código, não nos
testes.
2.5. Release
Agora estamos iniciando a abordagem das etapas que ficam do
lado direito do Ciclo DevOps (a parte de Operações, na figura do
início desta seção representada pelo lado verde). Release é a etapa
na qual todos vão trabalhar para que o que foi produzido e testado
nas etapas anteriores chegue ao ambiente de produção e esteja
acessível aos usuários. Muitas tarefas da equipe de operações vão
garantir que todas as configurações necessárias ao novo código
produzido sejam efetivadas e conferidas.
Geralmente, é a oficialização de todas as adaptações feitas para

rodar o novo código nos ambientes de desenvolvimento e
homologação. É comum ter de incluir novas variáveis de ambiente
ou instalar novos recursos, sejam bibliotecas na plataforma de
runtime, sejam recursos externos como uma tabela em um banco
de dados ou um serviço de mensageria.
Release também pode ser usado como um marco, apesar de não

ser o mais comum. Imagine que uma nova funcionalidade foi
elaborada e roda corretamente em desenvolvimento e
homologação. Mas imagine que a equipe de marketing e negócios
sugere que essa nova funcionalidade não seja disponibilizada para
os usuários antes de acontecer uma adaptação nas propagandas
ou no valor do serviço. Portanto, alguns ciclos vão rodar sem a
etapa de release e só em um momento específico uma release
sumarizando as atividades de alguns ciclos anteriores vai
acontecer. Isso pode ser uma demanda do time de operações
também, já que um novo recurso precisa ser adicionado e pode ser
necessário adquirir licenças de um banco ou provisionar um novo
recurso que leva mais tempo que o necessário em uma única
execução do ciclo. Ou pode ser uma aplicação em uma fase inicial
que não tem o suficiente para ir para produção.
Obviamente, seguindo as premissas do desenvolvimento ágil, o

ideal é que cada nova funcionalidade siga o mais rápido para a
produção e esteja disponível aos usuários o quanto antes. É
importante que o PO8 e os gestores das atividades do time tentem
blindar a equipe das influências externas. Nem sempre é possível…
2.6. Deploy
O deploy é o conjunto de atividades necessárias para colocar a
aplicação para rodar. Como já vimos, é comum essas atividades
estarem na sequência dos testes e serem executadas de forma
automatizada, especialmente no ambiente de desenvolvimento.
Contudo, olhando para o ciclo DevOps e assumindo que esteja após

a etapa release, estamos tratando agora do deploy em produção.
Deploy em produção é efetivamente um momento crítico para a
8
Em projetos de desenvolvimento ágil, PO ou Product Owner é o termo em inglês para
identificar o profissional que tem a visão do que será desenvolvido, as necessidades a serem
atendidas, o público que vai utilizar os serviços e os objetivos a serem alcançados. Toda essa
visão é proveniente do que o cliente precisa e deseja. A partir daí, ele cria o Product Backlog
(lista de funcionalidades), priorizando as necessidades do cliente, mas equilibrando com a
realidade da equipe.
operação. Se o código tiver algum erro, é nesse momento que a

reclamação vem do envolvido que menos deveria reclamar: o
usuário.
É muito comum usar estratégias de canary deployment para essa

fase. Canary deployment consiste em: (1) criar uma nova versão de
uma funcionalidade compatível com a que vai ser substituída; (2)
implantar os microsserviços em escala para ter vários containers
rodando o código; (3) implantar a nova versão do serviço em
paralelo com a versão antiga e redirecionar apenas uma parcela das
requisições para a nova versão; (4) ir aumentando gradualmente a
proporção do tráfego para a nova versão se nenhum problema for
detectado ou (5) interromper todos os containers rodando a nova
versão no caso de algum erro que precise ser avaliado.
Canary deployment é uma atividade avançada e permite ir fazendo

a substituição gradualmente. Não é necessário dizer que o
acompanhamento dos SRE e dos desenvolvedores é importante. O
SRE vai verificar se o ambiente está pronto para receber o novo
código e os desenvolvedores vão identificar novas mensagens de
erro presentes no código que os SRE ainda não conhecem.
2.7. Operate
Uma vez que a equipe esteja confiante que a release e o deploy
foram bem sucedidos, entramos em um momento mais tranquilo de
operação do ambiente no qual a aplicação roda. Esse é o momento
em que os operadores, geralmente os SRE em um time maior, vão
verificar problemas e fazer as modificações necessárias para a
continuidade da operação.
Como exemplos dessas atividades eles podem incluir mais nós em

um cluster, realizar backups da configuração, aumentar ou diminuir
a quantidade de réplicas de um container em execução, realizar
atualizações nos servidores do cluster, entre outras. Muito do
conhecimento de um Analista de Infraestrutura é importante nessas
atividades. Muito conhecimento de nuvem também é importante se

tudo isso acontece em um ambiente de computação em nuvem.
Alguns autores consideram que essa etapa e a seguinte

(Monitoramento) não deveriam estar separadas, já que as
ferramentas de monitoramento são a melhor fonte de informações
para operar o cluster.
Como aqui estamos no extremo direito do ciclo, bem inclinado às

operações, é comum que grandes organizações separem os
Engenheiros DevOps, pessoal mais ligado ao desenvolvimento, dos
SREs, profissionais mais ligados à operação. Mas isso só acontece
em organizações que tenham muitos envolvidos e vários times
DevOps simultaneamente. Muitas vezes o Engenheiro DevOps (com
um assistente, talvez) seja o responsável por todo o ciclo. Então é
importante conhecer todas as etapas.
É muito comum usar também ferramentas de service mesh que são

feitas para controlar o tráfego entre os containers de uma
aplicação. Enquanto o orquestrador de containers se preocupa com
a configuração do cluster: estado dos nós e dos containers,
quantidade de réplicas, configurações aplicadas aos containers;
endpoints dos serviços, etc. o service mesh se preocupa com itens
mais efêmeros relacionados à comunicação: quantidade de
mensagens entre os containers; quantidade de tráfego; taxa de
mensagens de erro; tempo entre a requisição e a resposta; políticas
de comunicação entre os containers, por exemplo.
2.8. Monitor
Outra atividade importante é o monitoramento. Coletar métricas é
essencial para entender: (1) o que acontece em “tempo real”; (2)
para entender as condições antes do acontecimento de um
problema; (3) prever a necessidade de recursos num futuro
próximo; (4) gerar insumos para atividade de otimização da solução
como um todo; (5) tracing de ocorrências problemáticas

específicas.
Para DevOps, monitoramento não é feito apenas para o time de

operações, mas também para os desenvolvedores e demais
membros do time. É importante que o desenvolvedor saiba usar e
demandar itens de monitoramento. Assim ele pode analisar um
painel e decidir que determinado método é crítico para o tempo de
resposta da aplicação. Ou que sob um cenário de aumento na
demanda, quais itens são mais importantes replicar.
Alertas são geralmente associados a essa etapa. Um alerta é uma

informação disparada para os interessados avisando da ocorrência
de algum evento como um erro, um novo recurso alocado
automaticamente ou a utilização que ultrapassou algum limite. Uma
das recomendações de DevOps é que esse alerta seja enviado ao
chat que todos os envolvidos usam para a comunicação diária.
Assim todos recebem essa informação ao mesmo tempo e podem
se mobilizar o quanto antes para tratar o possível problema.
Gerentes também precisam usar o monitoramento para

compreender quão complexa e quão extensa é a aplicação
implantada. Isso pode ser a justificativa que precisa para aumentar
a quantidade de membros num time, apenas para citar um exemplo.
Enfim, métricas são sempre insumos preciosos para a tomada de
decisão.
Uma vez finalizada essa etapa, as informações são usadas para um

novo planejamento e o ciclo se inicia novamente. A cada iteração as
funcionalidades e o próprio time cresce e entrega mais e mais
rápido elevando a automação necessária e integrando novas
funcionalidades da solução e do ambiente.
2.9. Aplicação Desenvolvida no Processo

DevOps
Se a empresa e a solução se encaixam em todas as características
descritas no capítulo 1, então a aplicação precisa ser resiliente,
escalável e vai se aproveitar das facilidades de um ambiente de
computação em nuvem. A aplicação precisa ser desenvolvida
rapidamente e um modelo incremental é preferível. Também vai
estar rodando em produção enquanto novas funcionalidades estão
sendo preparadas e integradas continuamente, sem interrupções.
Para finalizar esse capítulo, precisamos entender as características

de uma aplicação que segue o modelo DevOps. Como sempre,
essas características são uma proposta e não uma prescrição.
Dependendo do modelo de aplicação, algumas dessas
características não se aplicam ou outras características importantes
podem emergir. Contudo, essas são as mais relevantes.
Baseada em containers: Como já vimos antes, DevOps usa o

container como o componente padrão, especialmente, todos
aqueles componentes desenvolvidos na fase de codificação.
Containers promovem isolamento e facilitam a automação da
implantação e da operação do cluster que roda a aplicação. Como
características dos próprios containers, é interessante que sejam
pequenos e otimizados para comunicação pela rede. Containers
também definem uma nova plataforma de implantação, ou seja, com
containers qualquer sistema capaz de rodar um container é capaz
de rodar a aplicação independente de linguagem e framework
adotado.
Baseada em microsserviços: Também já foi dito que dividir a

aplicação em serviços menores que se comunicam uns com os
outros pela rede agrega várias vantagens, dentre elas, facilidade de
escala, resposta rápida a modificações, reaproveitamento de
módulos, eficiência no uso de recursos. Uma arquitetura baseada
em microsserviços também ajuda os operadores a compreender

melhor as características de cada módulo e o modelo de
comunicação adotado entre as partes
Cloud Native: Aplicações que seguem o modelo DevOps são

preparadas para aproveitar os recursos de computação em nuvem.
Portanto, é comum que um microsserviço use um blob storage
baseado em nuvem para salvar os arquivos no lugar de tentar salvar
no próprio container como aconteceria em um servidor. Junto a
isso, soma-se a ideia de que usar um serviço de nuvem deve
independer do próprio provedor. Por exemplo, cada provedor pode
ter seu próprio orquestrador de containers com diferentes
características, mas o orquestrador deve ser usado da mesma
maneira independente do provedor.
Escalável: É uma característica fundamental para reagir a

problemas, otimizar o uso da aplicação e enfrentar demandas
incertas. Muitos pensam na escalabilidade de recursos que é muito
importante, mas não é a única. Além de ser capaz de aumentar ou
diminuir a quantidade de recursos, a aplicação também deve ser
capaz de escalar geograficamente e administrativamente. Escalar
geograficamente é conseguir mudar os recursos de uma região
para outra onde são mais necessários. Escalar administrativamente
é manter o mesmo modelo administrativo independente da escala
geográfica ou de recursos.
Elástica: a ideia de Elasticidade está diretamente relacionada à

escalabilidade. Elasticidade é a medida de velocidade da
escalabilidade. Imagine um ambiente em que eu posso aumentar de
um para mil containers, mas isso leva uma hora para acontecer.
Podemos dizer que tem capacidade de escala, mas não é muito
elástica. Por outro lado, se temos um ambiente em que podemos ir
de 1 a 100 containers em 1 minuto, temos menos capacidade de
escala mas temos muito mais elasticidade.
Mensurável: Uma aplicação que segue o modelo DevOps precisa

ser mensurável. Não apenas usar as métricas fornecidas pelas
plataformas onde roda, mas ela própria deve ser uma fonte de
métricas. Desenvolvedores passam a incluir as medidas de métricas
que são importantes no próprio código e a externá-las para as
ferramentas de monitoramento. Mais que isso, desenvolvedores e
operadores colaboram para coletar as métricas de forma eficiente e
para medir o que é realmente necessário. Um grande problema aqui
é que muitas vezes o sistema de monitoramento acaba por se
tornar um fardo pesado.
Desacoplada: Como os microsserviços precisam ser escalados

individualmente, é importante que sejam desacoplados. Uma boa
estratégia é usar um broker de mensagens de modo que serviços
possam enviar mensagens para uma fila no lugar de fazer
requisições. Assim a fila vai ser consumida independente de
requisições e respostas. O modelo publish/subscribe é muito
adotado nesses casos, e um padrão de fato.
Feature-flags: É interessante que a aplicação leia um conjunto de

flags em um elemento de configuração e ative ou desative
funcionalidades no momento de executar o container. Assim novas
funcionalidades opcionais podem ser colocadas em execução e
ativadas ou desativadas conforme a necessidade e o
comportamento. O grande entendimento aqui é o seguinte:
podemos modificar o código e passar por todo o processo de build
e deploy para ver a modificação funcionando ou podemos fazer
todas as modificações de uma vez só e ir ativando ou desativando
depois de implantado. Isso torna todo o processo mais ágil.
E com tudo isso em mente, passamos a considerar e priorizar essas

características na definição dos requisitos e no processo de
software. Compreender bem essas características vai garantir uma
aplicação resiliente e escalável preparada para os ambientes de
execução mais exigentes.
Resumo do Capítulo
Vimos neste capítulo o ciclo DevOps para desenvolvimento de

software, representado na forma de um símbolo de infinito, apesar
de não ser unânime é um modelo que contempla as etapas:
● Plan: planejamento inicial para a iteração atual;

● Code: codificação das funcionalidades especificadas para a
iteração atual;
● Build: verificações estáticas, compilação e build do artefato de
código e container;
● Test: verificações dinâmicas e bateria de testes;
● Release: mudanças necessárias ao ambiente para implantar o
código em produção;
● Deploy: implantação do código no ambiente apropriado;
● Operate: operar o ambiente para que a solução execute
apropriadamente;
● Monitor: monitorar para agir em casos de falhas, identificação
de melhorias possíveis e planejamento das próximas ações.
Também vimos que há várias características importantes para

analisar em uma aplicação que segue o modelo DevOps:
● Containers: para isolamento e independência do ambiente;

● Microsserviços: para elevar a capacidade de escala e a
compreensão da divisão em módulos;
● Cloud native: para aproveitar melhor as facilidades de
provedores de nuvem;
● Escalável: para ser replicada facilmente: recursos,
geograficamente e administrativamente;
● Elástica: para mudar de escala rapidamente;
● Desacoplada: para evitar que use recursos síncronos e facilite
a escala;
● Mensurável: para usar e criar métricas para insights cada vez

mais interessantes e precisos;
● Feature-flags: para ativar e desativar funcionalidades em
tempo de execução.
3. Mudança de Cultura
Devo começar esclarecendo que muito do que está nesse capítulo é

baseado na minha experiência e na minha opinião pessoal.
Novamente, a ideia é não ser prescritivo e cada uma das iniciativas
apresentadas aqui é muito mais uma sugestão. Acredito que
algumas dessas práticas até extrapolam DevOps e podem ser
implantadas para qualquer time de desenvolvimento ou de
operações que trabalhe de forma mais tradicional.
Geralmente, a mudança mais complexa em um ambiente

organizacional é a de cultura. E muitas vezes uma mudança
superficial acontece e tende a um rápido fracasso. Por isso, a
primeira dica importante é que a mudança deve acontecer em
todos os níveis e não deve ser imposta, mas abraçada como uma
oportunidade de melhorar os resultados, o time, o ambiente de
trabalho. Mais que uma oportunidade de mudança é uma forma
mais eficiente de encarar um desafio complexo.
Como toda mudança cultural, muitas vezes todos sabem o que

fazer e às vezes até acreditam que estão fazendo, mas na realidade
continuam presos a antigas práticas. Por isso, em alguma medida, é
preciso avaliar as mudanças e comparar com o que se espera ou
com alguma meta. Muitas vezes uma pessoa externa é contratada
para auxiliar nesse processo. E muitas vezes o Engenheiro DevOps
acaba encarregado de ser um protetor dessa cultura9 e um crítico
das antigas práticas.
9
Eu acredito que essa não é uma atividade do Engenheiro DevOps. É a minha opinião, mas eu
mesmo já trabalhei em lugares em que assumi essa responsabilidade em algum grau. O fato é
que uma pessoa não muda a cultura sozinho e fazer “aliados” que ajudem a convencer os
demais é uma boa estratégia. Além disso, é importante dividir essa carga.
Uma boa estratégia é convencer a todos dos pequenos benefícios

progressivamente. Um Engenheiro DevOps recém contratado
trabalhando em uma equipe que atua de maneira tradicional jamais
deveria tentar implantar uma nova cultura por completo, mas muito
progressivamente, em doses pequenas e frequentes. Por exemplo,
olhar para os “calos” dos desenvolvedores e propor uma pequena
mudança que os ajude. Na sequência aproveitar que estão todos
felizes com a mudança e mostrar que na cultura DevOps esses
benefícios são comuns. Colaborar antes de pedir a colaboração.
Oferecer ajuda é outra prática que aproxima e promove a

colaboração. Muitos se enganam quando pensam que uma pessoa
que não tem a especialidade própria para uma tarefa não pode
ajudar. Na realidade continuo a me surpreender cada vez mais com
a ajuda que alguém com pensamento completamente adverso dá
quando explicamos calmamente o problema. As melhores ideias
surgem quando juntamos pessoas que pensam diferente mas não
se colocam em posições antagonistas.
3.1. Dificuldades, Falhas e Pessoas

As dificuldades, os problemas, as falhas sempre acontecem
indiscutivelmente. Uma frase recorrente nos ambientes DevOps é
que “falha não é uma questão de se, mas de quando”. Isso deixa
claro que falhas acontecem e deveriam ser encaradas como
situações naturais e não exceções desesperadoras. Então a
primeira ideia da cultura DevOps relacionada a falhas é o
comportamento natural e eficiente diante das falhas.
Falhas também precisam ser encaradas como algo que fugiu do

planejamento. E isso muda muito o modo de pensar. Se não estava
planejado devemos encarar como um problema a ser resolvido
agora ou como algo que deve ser planejado e tratado naturalmente
depois? Colocar essas duas possiblidades na mesa nos permite
abordar o problema como uma task que vai ser tratada depois, com
mais calma e sem a correria que uma falha geralmente exige. Então,
basta voltar à situação antes do problema.
Outra coisa que geralmente pensamos quando tratamos de falhas é

encontrar o porquê e o responsável. Encontrar o responsável por
uma falha é algo muito improdutivo, especialmente quando a falha
ainda impacta o ambiente produtivo. O ideal é resolver a falha o
quanto antes e os questionamentos posteriores mais interessantes
seriam:
● Estamos avaliando bem a complexidade das tarefas?

● Estamos subestimando algum risco importante? Estamos
ignorando algum risco?
● Nossas verificações automatizadas são eficientes? Como
podemos ter certeza?
● Quais as situações mais problemáticas e o que fazer para
evitar?
Veja, nenhum item da lista foca em quem. Mais que isso, temos de
promover um ambiente no qual podemos confiar nas pessoas,
especialmente em sua capacidade técnica. Se uma pessoa não é
capaz de executar uma tarefa como esperado o erro é a atribuição
da tarefa, não a execução. E se atribuímos uma tarefa confiamos
que o envolvido é capaz e o melhor profissional disponível para
executá-la. Confiamos nisso com a certeza de que o melhor
profissional do mundo também pode cometer falhas e que se elas
acontecerem vamos todos ajudar a resolver como um time. E se o
nosso companheiro de time ainda não é o melhor nisso temos de
ter a confiança de que ele está fazendo o necessário para chegar
lá. Ele vai se tornar o especialista que precisamos para alcançar os
objetivos necessários e pode contar com o resto do time para
ajudá-lo.
Isso promove um ambiente em que todos crescem naturalmente e

explora o que há de melhor tecnicamente em cada um. Esse é um
ambiente muito promissor a médio e longo prazo e cada membro

acaba se comprometendo naturalmente com os gaps da equipe e
abraça as novas tecnologias sempre que oportuno.
Isso leva a outra ideia que me agrada muito pessoalmente: as falhas

são o custo natural da inovação. Ninguém espera adotar uma nova
tecnologia e ter o mesmo desempenho de uma tecnologia já
conhecida. Adotar uma nova tecnologia deve ser encarado como
um processo de inovação necessário que vai ter uma curva que
passa por vários momentos até alcançar a excelência. E esse é um
período em que as falhas são frequentes. É o custo que se paga
para alcançar a excelência. Então a pergunta que deve ser feita é:
“quanto vamos investir do nosso tempo para alcançar a excelência
nessa nova tecnologia?”
3.2. Automate Culture

Um time em um ambiente DevOps precisar ter um mindset de
automação contínua. Automatizar tarefas repetitivas aumenta a
produtividade e permite à equipe trabalhar em escala. Foi nesse
sentido que surgiu um termo chamado de automate culture, que
inclui algumas sugestões interessantes.
Automate-first é a ideia de automatizar uma tarefa antes de

executá-la. De fato, quase sempre fazemos algo manualmente e só
então fazemos uma automação. Isso pode ser mais interessante
para compreender melhor o que vai ser feito antes de automatizar.
Mas para ter uma cultura de automação e mudar o mindset da
equipe, o interessante é pensar na automação antes e só então
realizar a tarefa.
De maneira geral, muitos vão acreditar que o tempo para a

conclusão da tarefa vai ser maior, mas a longo prazo, a automação
se torna cada vez mais natural. Além disso, algumas das
automações podem ser reaproveitadas ou adaptadas a outras
ocasiões. Por fim, a ideia de automatizar é mais um custo que vale à

pena pagar.
Fully automated é uma sugestão para que quando uma automação

tiver que ser feita, que ela seja feita de maneira a não ter nenhum
envolvimento humano. Isso tem dois motivos, o primeiro é que isso
garante uma automação robusta. O segundo motivo é que se a
automação toma tempo de supervisão humana, ela não atinge seu
principal objetivo. O ideal é ter um processo que faça o que precisa
ser feito sem nenhuma intervenção. Se algo der errado, a própria
automação deve acionar os envolvidos, apenas se for realmente
necessário.
“Liquid Workforce” é um termo usado por Jacob William (Forbes)

para identificar a necessidade de ter funcionários que se adaptam
às situações. É uma ideia difícil de expressar porque como foi
colocado parece que é uma responsabilidade dos funcionários
quando na verdade é o oposto. Um ambiente onde as pessoas
conseguem se adaptar facilmente é um ambiente que promove a
curiosidade, o aprendizado e a experimentação. Processos
precisam ser criticados e revisados a todo momento.
Essa ideia de automação recorrente reforça outra coisa importante

na cultura DevOps. Quase sempre, consertar é improdutivo. Destruir
tudo e começar novamente é mais prático. Com uma automação
eficiente, recriar um ambiente problemático na versão anterior do
recurso que apresenta falha é muito mais produtivo. O novo recurso
pode voltar para uma avaliação antes de ser colocado em uso
novamente.
3.3. Mais Software, Menos Documentação

Há uma falsa ideia de que documentação é algo incompatível com o
desenvolvimento ágil de software. Na realidade não é isso. A
realidade é que em um ambiente ideal e utópico seria muito
interessante ter um software completamente compreensível
baseado apenas no código, mesmo que sem nenhum comentário.

Mas essa situação é geralmente inalcançável.
O que todo time precisa encontrar é o meio termo em que exista

documentação suficiente para que um novo membro entenda o que
está acontecendo e o que aconteceu no passado. Se menos
documentação é bom, insuficiente não é aceitável. É um meio termo
difícil de encontrar e há muitas razões para isso.
A primeira razão é que em um ambiente baseado na confiança, às

vezes somos inclinados a achar que a documentação é
desnecessária quando temos um especialista em quem podemos
sempre confiar. Ou que um código complexo acaba sempre caindo
na mão daquele membro que é mais produtivo naquela linguagem
de programação.
Mas nesse ambiente também é mais fácil convencê-los de fazer um

momento de compartilhamento, de modo que ele possa explicar
aquela parte que só ele conhece ou a tecnologia que só ele sabe.
Então precisamos transformar esses momentos em documentação
do projeto, uma documentação que seja fácil de produzir para quem
compartilha e simples de compreender para quem usa.
Outro desafio é documentar as atividades de DevOps. Se por um

lado é importante que todos tenham ideia da repercussão de um
push de código errado no ambiente, também é importante que
todos sejam capazes de abstrair a parte que não compreendem
completamente para se tornarem mais produtivos. Por isso,
diferentes tipos de documentação devem ser dirigidos a diferentes
públicos.
É muito comum colocar como comentário no código apenas o que é

necessário a quem vai trabalhar naquele código e documentos mais
formais com explicações mais abstratas. Apresentações e vídeos
são mais direcionados a quem precisa de um entendimento mais
genérico e alcança mais pessoas de uma vez só.
Resumo do Capítulo
Neste capítulo vimos os principais pontos relacionados à cultura

DevOps. Mudanças culturais são sempre complexas e usar a
empatia e a colaboração são algumas das chaves para uma
mudança bem sucedida.
Dificuldades e falhas são ocorrências naturais e devem ser

encaradas como tal. Mais que isso, falhas são o custo natural da
inovação.
Automação é um objetivo que deve ser sempre perseguido.

Automate-first, fully automated e "liquid workforce" são algumas
estratégias interessantes que podem ser adotadas.
Documentação também é um ponto importante a equacionar. Se

muita documentação é ruim, nenhuma pode não ser a resposta. O
ideal é documentar rapidamente apenas o que ajuda outros
envolvidos a compreender o que se passou e o que vai se passar.
4. Principais Ferramentas DevOps
Uma vez que conhecemos o modelo de desenvolvimento de

software de acordo com a cultura e as práticas DevOps, podemos
associar ferramentas a cada etapa e dar uma forma mais prática a
cada ação que precisa ser executada. Antes de falar de cada
ferramenta que apresento nessa lista preciso incluir duas citações
que considero relevantes nesse ponto:
A primeira é atribuída a Abraham Maslow que disse: “para quem só

usa martelo, todo problema é prego”. Em outras palavras, quem se
sente confortável em usar as ferramentas que domina tem a forte
tendência de resolver tudo sempre da mesma forma ou com
pequenas variações. A inovação está do outro lado dessa moeda e
o ambiente DevOps é muito inclinado à inovação. Mesmo que
muitas vezes modismos acabem conquistando um espaço
importante, geralmente, novas ferramentas aparecem para que
possamos atacar problemas conhecidos de maneira mais eficaz.
A segunda é atribuída a Jamie Hyneman, apresentador de um

programa de TV que acompanhei por um bom tempo: “a fita adesiva
(duct tape ou silver tape) não é a solução perfeita para tudo, mas
com um pouco de criatividade é uma solução adequada para muitas
coisas”. Não pensem que estou sendo contraditório aqui. O que
quero deixar claro é que há ferramentas muito versáteis e outras
muito específicas. E o ponto ideal é geralmente um meio termo
muito complexo de encontrar. É como o canivete suíço. É uma
ferramenta que você pode ter no bolso e que faz de tudo: corta,
abre garrafas e latas, parafusa, saca rolhas, lixa… Mas não tente
usá-lo para fazer o trabalho de um facão ou vai se arrepender. Na
realidade, é importante ter ferramentas mais genéricas para as
situações mais simples e que resolvem várias coisas de uma vez só,
mas também é importante ter ferramentas específicas que resolvem
coisas mais complexas.
Essas afirmações ajudam a entender o contexto profissional da

Engenharia DevOps. Algumas ferramentas genéricas podem
resolver uma etapa ou duas do ciclo de desenvolvimento. Algumas
em especial atacam pontos específicos e precisam ser combinadas
com várias outras. Um Engenheiro DevOps pode querer uma
ferramenta mais genérica para build, deploy e testes e um conjunto
de ferramentas mais robusto de operação e monitoramento. Ou o
contrário, ter uma ferramenta boa de monitoramento e conhecer as
ferramentas de cada um dos gerenciadores de repositórios mais
utilizados do mercado para ter pipelines de CI10 robustos e outras
ferramentas específicas de CD11. Portanto, uma escolha difícil e uma
equação na qual o Engenheiro DevOps vai investir tempo de estudo
para equalizar.
Mas não se preocupe. Esse capítulo é para ajudar nessa escolha. A

ideia é apresentar as ferramentas disponíveis no mercado,
identificar quais delas servem a várias etapas simultaneamente e
sinalizar aquelas que são mais importantes. O objetivo não é
ensinar a usar a ferramenta mas ser um guia para que você, mesmo
com pouca experiência, possa fazer uma escolha assertiva de como
investir seu tempo.
4.1. Conhecimentos e Ferramentas básicas

Alguns conhecimentos são muito bem vindos em todas ou quase
todas as atividades de um Engenheiro DevOps. Como sempre, as
propostas não são prescritivas, mas uma tentativa de melhorar a
sua própria opinião sobre o que é mais importante ou não. Portanto,
faça-me saber se você pensa diferente de alguma ideia colocada
aqui.
10
CI (Continuous Integration ou Integração Contínua) é uma prática em desenvolvimento
utilizando DevOps em que DEVs frequentemente integram suas alterações de código em um
repositório central.
11
CD (Continuous Delivery – Entrega Contínua e/ou Implantação Contínua) é uma prática em
desenvolvimento utilizando DevOps em que os times de desenvolvimento lançam novas
funcionalidades de forma constante e automatizada.
Linux e Shell Script
Estes são conhecimentos muito interessantes para quem lida com

containers e quem realiza atividades de troubleshooting12. Como
containers são baseados em Linux na maioria dos casos, é muito
interessante compreendê-los bem e saber fazer adaptações para
contornar problemas. Também é necessário conhecer um bom
conjunto de comandos para as mais diversas tarefas e
compreender como combiná-los para construir um script. Um script
é a forma mais rápida e direta de automatizar qualquer atividade em
um container ou servidor, mesmo baseados em outros sistemas
operacionais.
A compreensão das configurações, especialmente de rede e

sistema de arquivos também é importante. Muitas vezes, um
desenvolvedor deixa uma configuração padrão insegura ou
incorreta por simples desconhecimento. Um Engenheiro DevOps
atento pode ser o responsável por evitar que aquela configuração
vá para produção sem uma análise mais criteriosa.
Muitas vezes o conhecimento é útil para evitar um consumo

excessivo de recursos ou para remover componentes
desnecessários à execução do container. Diminuir a superfície de
ataque e tornar o custo efetivo da solução mais atraente.
Conhecimentos relacionados a sistemas operacionais e sistemas
distribuídos podem ser interessantes para casos mais avançados.
Redes e Conectividade
Outro conhecimento que vale muito nas atividades de um

Engenheiro DevOps é redes e conectividade. Seja para configurar
12
O troubleshooting envolve a execução de técnicas para a resolução de ocorrências que
afetam a infraestrutura de computadores e sistemas, produtos e serviços de redes de
computadores.
uma VPN13 e tornar o tráfego seguro, seja para criar um gateway

eficiente para comunicação dos seus containers ou para configurar
o load balancer do provedor de nuvem, conhecimentos de redes e
conectividade ajudam muito. É importante compreender as
camadas do modelo OSI14 e os principais padrões da Internet: DNS,
Proxy, Cliente/Servidor, TCP, ICMP, roteamento e endereçamento,
etc. Também é importante fazer o diagnóstico e ter o senso crítico
para propor melhorias.
Muitas vezes, temos de fazer algumas atividades que extrapolam os

testes mais simples como configurar um container para ser o
roteador de uma parte do tráfego. Ou para compreender uma
configuração em uma ferramenta de controle de tráfego avançado
ou service mesh. Nesses casos, um conhecimento mais avançado é
importante.
Git e Controle de Versão
Já há algum tempo que o git se tornou o padrão do controle de

versão. Então, é importante compreender, no mínimo, os comandos
básicos para clonar, enviar, receber e comentar código. Se você
quer desfazer as suas próprias bagunças, aprenda pelo menos a
usar o git reset sem piorar a situação.
Lembre-se que você vai ter de trabalhar em conjunto com

desenvolvedores que vão fazer pull requests e merges frequentes.
Portanto, esteja preparado para realizar pelo menos essas
atividades ou empenhe-se em aprender com os colegas.
13
VPN significa “Virtual Private Network” (Rede Privada Virtual) e descreve a oportunidade de
estabelecer uma conexão de rede protegida ao usar redes públicas (comumente a Internet).
VPNs criptografam seu tráfego de Internet e disfarçam sua identidade online, o que torna mais
difícil para terceiros rastrear suas atividades online e roubar seus dados.
14
O Modelo OSI é um modelo de referência de rede de computador definido pela organização
de padronização ISO. O modelo é dividido em camadas de funções e estabelece padrões para
protocolos de comunicação entre os mais diversos sistemas em uma rede local.
Além de tudo o que os desenvolvedores fazem, aprenda, mesmo

que superficialmente, o que são git hooks, tanto client-side quanto
server-side. Git hooks são ferramentas ótimas para automatizar
tarefas durante eventos do git. Podemos até dizer que git hooks
são os precursores de ferramentas de pipeline modernas.
Computação em Nuvem
Todo Engenheiro DevOps deveria investir uma parcela do seu

tempo no estudo da computação em nuvem. Mesmo que não
trabalhe com isso (ainda!). Tente conhecer pelo menos o serviço de
computação básico para criar máquinas virtuais, as principais
configurações de rede, o serviço de armazenamento de arquivos e
o serviço para execução de funções (como AWS Lambda, GCP
Functions ou Huawei Function Graph).
Avance e conheça um serviço de mensageria e um de banco de

dados. Tenha também domínio sobre o utilitário de linha de
comando para poder começar a automatizar. E evolua o serviço de
computação básico para usar a escala automática e um
balanceador de carga.
Por fim, tente conhecer a ferramenta de IaC de cada provedor e

tente conhecer outros serviços que façam sentido no escopo do
seu trabalho: big data, IoT, machine learning. Tente também evoluir
seus conhecimentos arquiteturais sabendo onde ferramentas
equivalentes podem ter vantagens. Não esqueça de estudar a parte
de permissionamento e segurança.
Scrum ou Equivalente
Scrum é um modelo de processo ágil muito usado (provavelmente o

mais usado) e por isso é importante conhecer, pelo menos, o
básico. Compreenda o objetivo de cada cerimônia para ter certeza
de que está levando as alegações corretas para cada reunião.
Compreenda as práticas sugeridas para que sua contribuição seja

sempre positiva e pergunte sempre que tiver dúvidas.
Dito isso, vamos para as ferramentas específicas e associadas às

etapas do modelo de processo de software sugerido pela cultura e
práticas DevOps.
4.2. Plan
Um conjunto de ferramentas no qual há um envolvimento maior dos
gerentes de projetos e product owners é usado nessa fase. O leitor
não deve investir muito tempo nelas já que a maioria é muito
intuitiva. O objetivo é muito mais saber que existe que realmente
estudar e dominar. Por isso mesmo, vou quebrar o protocolo e vou
dividir as ferramentas pelo seu uso.
Dashboard de Tasks
Quase sempre usamos um dashboard de tasks como o Trello e o

Jira. Aqui não importa muito a ferramenta, mas é importante que o
time tenha ciência do que está sendo executado, por quem e o
andamento. Em um ambiente colaborativo isso é o mínimo que os
envolvidos precisam para pedir e oferecer ajuda sempre que
necessário. Também é importante para ter a ideia do andamento e
documentar minimamente as atividades executadas.
Ferramenta para Desenho de Fluxos
É interessante ter uma ferramenta para desenhos como o Draw.io

ou o Lucid Chart. Nem que seja um Jamboard. Sei que muitos vão
dizer que equipes realmente ágeis vão desenhar um rascunho e o
rascunho cheio de rabiscos é que vai ser a documentação. OK se
você concordar, mas é que às vezes, fazer o rabisco dá mais
trabalho que fazer um desenho eletrônico.
Ferramenta de Comunicação
É muito comum usar uma ferramenta de chat como o Slack ou

RocketChat. Muitos preferem uma ferramenta com mais recursos de
áudio e vídeo como o Discord ou uma suíte como as do Google e da
Microsoft. O fato é que em tempos de trabalho remoto, essas
ferramentas são importantes. Pense sempre em uma ferramenta na
qual seja fácil receber alertas das ferramentas de monitoramento.
4.3. Code
Essa é uma parte difícil de prever porque geralmente as
ferramentas mudam de acordo com a linguagem, o framework e
outras peculiaridades. De qualquer forma, tudo começa com um
bom editor de código.
VisualStudio Code
Se o projeto não exige um editor de código específico, um dos

editores de código mais utilizados na atualidade é o VSCode.
Aprenda as teclas de atalho básicas para ganhar produtividade e
conheça os plugins recomendados para as atividades que executa.
Muitos preferem o terminal do próprio editor e nesses casos a
recomendação é saber personalizá-lo.
Nano, VI e VIM
Gostaria muito de te dizer que o seu VSCode vai resolver todos os

problemas e que nunca vai precisar de outro editor, mas seria
mentira. Para um Engenheiro DevOps conhecer bem um editor de
texto para o terminal é tão importante ou mais que conhecer um
editor de código. Um editor como o VIM bem configurado pode ser
tão produtivo quanto o VSCode, mas a recomendação inicial não é
essa. Se tiver dificuldades comece pelo Nano que é simples e
completo. Ele já é uma boa escolha por si só. Mas é sempre bom
conhecer o VI já que dentro de um container, quanto menor o editor
melhor. Dedique até algum tempo para editar arquivos sem usar
editor se quiser fazer uso avançado. Evite estudar editores que
você não vai encontrar com frequência, por mais que seja tentador.
Git e seus Equivalentes
Como já foi dito, git é o padrão de controle de versão. Dependendo

das atividades, inclua GitHub, GitLab e BitBucket nos estudos (ou
pelo menos um deles). Estude as boas práticas de utilização e as
características do seu ambiente. Evite usar as branches principais
para mudanças corriqueiras e use Git Flow para um trabalho
organizado em equipe.
4.4. Build
Quanto ao CI temos duas vertentes: plataformas e ferramentas
agregadas a repositórios. Quando usamos uma plataforma,
geralmente há um evento que sinaliza uma ocorrência como um
push ou pull request. Geralmente é um webhook ou algo parecido
que dispara uma ação em uma plataforma independente.
Ferramentas agregadas quase sempre monitoram o evento e, elas
mesmas executam parte ou todo o processo de CI. Como opinião
pessoal, acho as ferramentas agregadas mais modernas e
eficientes, mas a gente nem sempre decide o que usar. Portanto, é
interessante conhecer ambos.
Jenkins
Sem dúvida, a ferramenta no formato de plataforma mais utilizada é

o Jenkins. Muitas empresas usam e muitas empresas já encaram o
Jenkins como um legado e uma mudança para qualquer outra
plataforma seria muito custosa. O fato é que o Jenkins é completo e
eficiente, mesmo que minha opinião pessoal não esteja ao seu lado,
ele resolve bem os problemas.
Geralmente é implantado na forma de um serviço ou um servidor.

Ele é capaz de iniciar máquinas virtuais e entregar a elas um
trabalho a ser executado na forma de um script em Groovy. Existe
uma versão nova chamada de JenkinsX que atualiza o Jenkins para
um modelo conhecido como GitOps. Há outras ferramentas que
seguem o modelo de plataforma como TravisCI e CircleCI.
Aprofunde-se apenas se tiver uma expectativa real de usá-lo no
futuro.
GitHub Actions
Das ferramentas agregadas aos repositórios de controle de versão

de código, uma das mais simples e diretas é o GitHub Actions. Ele
permite associar uma execução a um evento e toda vez que o
evento acontece, ele cria uma máquina virtual ou container para
executar seu script. O pipeline de CI pode contar com vários steps,
cada um rodando em containers diferentes e passando informações
de um step para o outro. Estes steps podem usar informações
sigilosas que são armazenadas na forma de secrets e nunca
aparecem nos logs de execução. Também é possível armazenar
artefatos na plataforma para serem usados posteriormente ou criar
jobs para serem disparados manualmente.
Por ser tão versátil, muitos usam essas ferramentas tanto para CI
quanto para CD. Você pode, por exemplo, cadastrar as credenciais
de acesso do seu cluster em um secret e rodar comandos kubectl
diretamente do seu pipeline para rodar aplicações no seu cluster de
containers. E como usa massivamente shell script qualquer coisa é
virtualmente possível, basta ter criatividade suficiente. Cada
plataforma tem seu próprio modelo muito parecido como o
GitLab-CI e o BitBucket-Pipelines.
4.5. Test
Essa é mais uma etapa que depende muito do projeto, da
linguagem adotada ou de frameworks utilizados. Apenas para
relembrar ideias importantes do capítulo 2, use ferramentas de

checagem de estilo de código e checagem estática de erros, no
mínimo. Também é necessário escolher ferramentas que executem
o código ou artefato compilado e realize testes dinâmicos. Por
exemplo, para Python é comum usar PyLint para checagem estática
e de estilo de código e PyTest para testes dinâmicos.
4.6. Release e Deploy

Particularmente, a diferença entre release e deploy é apenas o
ambiente que vai receber a aplicação. Portanto, as atividades e
ferramentas são as mesmas, o que muda é a atenção e os detalhes.
ArgoCD
Se o código vai rodar em um cluster Kubernetes, a minha primeira

recomendação vai ser sempre o ArgoCD. Ele segue um modelo
chamado de GitOps que seria um ótimo tema para outro ebook. Na
prática ele monitora um repositório de manifestos e aplica
mudanças no cluster (automaticamente ou manualmente à escolha
do responsável). Isso permite que desenvolvedores acompanhem o
deploy por uma interface web e façam as devidas intervenções
sempre que for oportuno.
Terraform
Se o código precisa ser implantado, antes disso deve-se implantar a

infraestrutura. E há hoje poucos concorrentes para o Terraform
como ferramenta de IaC. Terraform permite criar um código
declarativo e aplicar, sempre que houver mudanças. A linguagem é
da própria Hashi Corp e se parece com YAML. É muito usado em
infraestruturas de nuvem, mas também pode ser utilizado em
conjunto com ferramentas de virtualização.
4.7. Operate
Docker
Se você tiver que estudar uma ferramenta para executar containers

localmente use o Docker. Muitos focam nos problemas do Docker
para dizer que há outras opções, mas acredite: Docker é mais que
suficiente e você vai encontrar muito mais referências sobre Docker.
Não tem como errar.
K3S
Se você precisa de um cluster local para testes e com baixo

consumo de recursos não tenho como recomendar outro que não
seja o K3S. Um comando para instalar. Extremamente simples de
usar e o mais parecido com um cluster de verdade. Roda no Linux,
no MacOS e no WSL. Eu recomendaria até para um ambiente de
desenvolvimento barato.
Kubernetes
Mas no ambiente de produção, não tem como não ser o padrão do

mercado: Kubernetes. É a principal ferramenta DevOps e é
importantíssimo que o Engenheiro DevOps conheça bem seus
recursos. Também é importante reconhecer as facilidades quando
ofertado como um serviço de nuvem: AWS EKS, GCP GKE, Azure
AKS ou Huawei CCE. Só para citar um exemplo, usando o storage
class correto você pode criar um volume para seu container salvar
arquivos direto num bucket do serviço de blob storage ou num
disco do de computação. Kubernetes tem poucos concorrentes no
mercado e alguns deles são baseados no próprio Kubernetes.
Ansible
Se for necessário executar ações em vários dispositivos

simultaneamente, nada é mais prático que Ansible. Ansible é uma
ferramenta de operação, mas com poucas adaptações ela pode ser

usada para todo o pipeline e para deploy. É portanto uma
ferramenta generalista muito útil e que deve ser considerada.
4.8. Monitor
Prometheus
Prometheus é o coletor de métricas padrão para o Kubernetes.

Assim como o Kubernetes, é da iniciativa Cloud Native Computing
Foundation, é maduro e eficiente. Como é uma ferramenta padrão
de mercado, é muito fácil encontrá-lo rodando sempre que for usar
Kubernetes.
Grafana
Este é o painel de visualização mais utilizado quando se trata de

monitorar aplicações baseadas em containers, mas não se limita a
isso. O Grafana pode se conectar a várias fontes de dados como
Prometheus e Loki para gerar gráficos e alertas em tempo real.
Loki
Assim como o Prometheus é um coletor de métricas, Loki é um

coletor de logs. Portanto, no lugar de ter de consultar os logs de
cada container individualmente, Loki organiza todos os logs em
uma só lista e permite consultas avançadas para selecionar o que
realmente é necessário.
Istio
Istio é uma ferramenta de mesh de containers ou service mesh.

Enquanto o Kubernetes e as outras ferramentas de monitoramento
se preocupam com o estado de nós, containers e aplicações, Istio
se preocupa com o tráfego entre os containers. Permite
implementar políticas na comunicação entre containers e tem uma
ferramenta que mostra em tempo real a comunicação.
Resumo do Capítulo
Neste capítulo vimos as principais ferramentas usadas por um time

DevOps. Vimos os conhecimentos básicos necessários a todas as
atividades e vimos as ferramentas mais comuns usadas em cada
etapa do ciclo de desenvolvimento:
● Plan: dashboard de tasks, ferramenta para desenhos de fluxos

e para comunicação.
● Code: editor de código, editor de modo texto, git e seus
equivalentes.
● Build: Jenkins e GitHub Actions.
● Release e Deploy: ArgoCD, Terraform.
● Operate: Docker, K3S, Kubernetes, Ansible.
● Monitor: Prometheus, Grafana, Loki, Istio.
5. Conclusão
Na introdução vimos o contexto no qual se estabelece a relação

entre a Engenharia de Software e DevOps. Apresentamos a
Engenharia de Software e como DevOps estabeleceu um novo
estágio evolutivo.
No capítulo um pudemos perceber o contexto no qual DevOps

nasceu: a necessidade de desenvolvimento ágil de software para
colocar o software idealizado em produção rapidamente; a
necessidade de containers para agilizar a implantação de
aplicações e a resposta a incidentes; as facilidades apresentadas
pela computação e nuvem, especialmente a utilização de hardware
no formato de software sob demanda; a demanda por automação
dos processos de desenvolvimento e por métricas para servirem de
insumo nos processos de resposta a incidentes e para
planejamento evolutivo do software; a necessidade de uma equipe
de desenvolvimento que aproxima desenvolvedores e operadores
em um ambiente de colaboração; a utilização de código para definir
a própria infraestrutura no formato de infraestrutura como código.
No capítulo dois observamos as características do modelo de

processo de desenvolvimento de software que segue as práticas
DevOps. Vimos cada uma das etapas: plan, code, build, test,
release, deploy, operate e monitor. Vimos as atividades
recomendadas para cada uma dessas etapas e os envolvidos em
cada atividade. Vimos também as características de uma aplicação
que segue esse modelo: baseada em containers, baseada em
microsserviços, cloud native, escalável, elástica, mensurada e
feature-flags.
No terceiro capítulo abordamos alguns aspectos relacionados à

cultura DevOps. Vimos algumas estratégias para melhorar o
ambiente e convencer os envolvidos dos benefícios da cultura
DevOps. Vimos como a cultura DevOps trata as dificuldades, falhas

e a relação dos envolvidos diante disso. Vimos como usar
estratégias para promover a automação, algo muito importante no
contexto de DevOps. Por fim, discutimos alguns pontos
relacionados à documentação.
No quarto capítulo temos uma lista de conhecimentos e

ferramentas importantes para um Engenheiro DevOps. Para cada
ferramenta, uma pequena apresentação e o contexto de uso.
Apesar de não ser uma regra rígida, cada ferramenta é classificada
pela etapa do ciclo na qual é usada.
E com isso finalizamos uma apresentação concisa do que é DevOps

sob os aspectos mais relevantes: como um modelo de processo de
desenvolvimento de software, como uma cultura organizacional,
como um conjunto de ferramentas e como um cargo a ser exercido.
Esperamos que essa apresentação tenha sido realmente útil a todos
que precisam entender melhor o contexto de DevOps e
principalmente ajude os futuros Engenheiros e Analistas DevOps a
tomar os primeiros passos na carreira. Também é um conhecimento
interessante a Gerentes de Projetos e Desenvolvedores que
precisam compreender melhor o contexto de DevOps em suas
organizações, as vantagens e os desafios inerentes a sua adoção.
Quero complementar que essas informações foram importantes

durante a minha decisão de mudar de carreira. Quisera eu ter um
compilado de informações como este aqui para compreender
melhor o papel de um Engenheiro DevOps e seu campo de atuação.
Fui professor universitário por mais de uma década quando decidi
que alguns dos conhecimentos relacionados a DevOps precisavam
ser inseridos no contexto do ensino superior. Mais tarde, eu me
convenci de que essa mudança era importante para mim mesmo. E
agora tento contribuir para que outros que pensam como eu
também consigam.
Se você que me lê se interessa pela mudança de carreira ou mesmo

se você já atua em alguma medida como Engenheiro DevOps e
precisa preencher lacunas no seu perfil, gostaria de apresentar
mais algumas considerações:
● Defina um escopo de estudo. Dependendo do perfil que

deseja é importantíssimo definir se vai ser um estudo
superficial ou aprofundado. O fato é que é simplesmente
impossível conhecer tudo que um DevOps precisa usar a
longo prazo. Por isso é importante ter um foco e saber quando
começar e quando parar.
● Conheça as aplicações a implantar. Muitas vezes me vi
implantando serviços que nunca tinha utilizado como Redis ou
Elastic Stack. Desde muito cedo só defino que uma
implantação está concluída quando eu mesmo faço um "Hello
World!" no serviço implantado. Não é estudar, mas pesquisar
um modelo de teste que seja simples e eficiente. Em alguns
casos, estudar mais profundamente também faz sentido.
● Peça ajuda. Eu sei que já disse isso, mas é que quando
estamos em um ambiente DevOps todos querem ajudar. Então
não fique tentando e tentando. Estabeleça um prazo como "se
eu não terminar até a hora do almoço, depois do almoço eu
chamo um colega para me ajudar". Esse escopo é importante
para manter a produtividade e para dar a oportunidade dos
outros ajudarem.
● Use vídeos. Muitas vezes gravo vídeos para mim mesmo.
Como muitos dizem, é como se "o eu do presente esteja
mandando um recado para o eu do futuro". Muitas vezes esse
vídeo me ajuda ou ajuda outros.
Por fim, quero colocar-me à disposição para sanar outras dúvidas

que possam surgir e fico aberto a qualquer crítica ou sugestão que
considerar oportuna.

EBook - Impulsione Sua Carreira Com DevOps

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

EBook - Impulsione Sua Carreira Com DevOps

Enviado por

Direitos autorais:

Formatos disponíveis

Cícero Woshington

Tudo o que você precisa saber sobre essa forma

A Academia DevOps é a materialização de um desejo de três

A Academia DevOps é uma iniciativa para promover os

No momento em que escrevo esse e-book, a empresa na qual

estagiários) e 9 são para DevOps. O segundo lugar é dividido entre

Outra mudança no mercado que é perceptível é que as empresas

É diante desse cenário de rápidas e profundas transformações em

Olá! Eu sou Cícero Woshington e minha trajetória

Das três previsões da época, apenas uma continua

Passei em alguns concursos públicos incluindo Analista da

E mais uma previsão caiu por terra: tornei-me professor

permitiu contribuir de maneira decisiva com conquistas

Assim que terminei o mestrado tive a certeza de que

Por fim, eu mesmo percebi que eu precisava assumir uma

com os alunos e do ambiente de ensino e aprendizagem

O conteúdo apresentado neste material pode ser uma forma rápida

Apesar de insistir na mudança de carreira, este ebook também vai

Esse ebook está dividido em cinco capítulos. O primeiro capítulo

profissionais de TI que querem dar esse novo direcionamento às

A Engenharia de Software nasceu olhando para outras engenharias

Os profissionais de então olharam em volta em busca de soluções e

Também olharam para a Engenharia de Produção e viram como os

Várias outras ideias podem ser citadas como métricas e auditorias

DevOps é um conceito difícil de sintetizar e por isso mesmo não é

Para muitos DevOps é um modelo de processo de software, ou seja,

empregadas na elaboração de um software. A verdade é que todos

Uma ideia que me agrada muito é que DevOps continua sendo

1. DevOps: juntando as peças

DevOps é um conjunto muito grande de elementos relacionados ao

● Smartphones eram acessíveis e poucas pessoas ainda usavam

Foi nesse contexto que muitas empresas começaram as iniciativas

1.1. Desenvolvimento Ágil de Software

Por um lado, temos empresas que desenvolveram suas próprias

Com isso tínhamos duas vertentes, aparentemente opostas, mas

Portanto, a primeira coisa a ter em mente quando for pensar em

1.2. Virtualização e Containers

Embora a Virtualização não seja algo tão recente na computação,

essa era uma das características mais apreciadas na época: o

Usando uma máquina virtual podemos dar garantia que o sistema

Por exemplo, ter uma aplicação rodando em um servidor virtual e

O grande problema de aplicar essas ideias com máquinas virtuais é

Um container é um núcleo de sistema operacional, quase sempre

(container runtime) é necessário para compartilhar esse kernel.

Com as mesmas características de isolamento de uma VM e com

E quando um servidor fica sobrecarregado, dá para copiar a

1.3. O Fenômeno da Computação em Nuvem

E o fenômeno que dá título à seção não é o que a maioria pensa

Há, espera um pouco, transformar hardware em software não é uma

Assim, podemos dizer que a Computação em Nuvem consiste no

Imagine virtualização em uma empresa. A empresa compra os

O fato é que para essa empresa, o limite dos recursos continua

Muitos modelos de negócio nasceram transformando propriedade

1.4. Automação e métricas

Com microsserviços, no lugar de colocar uma aplicação toda para

Além disso, há a possibilidade de escalar somente a parte que está

Mas a aplicação pode ser dividida em 3 containers: um para receber

Exemplo simples com 3 imagens de container diferentes que vão

Imagine que antes você tinha um código só que precisava ser

Na realidade existe uma estratégia melhor. Como o Git2 se tornou o

Outra coisa interessante de automatizar é a própria administração

IF ( (CPU > 0.8) OR ( MEM > 800M ) ) {

Seria ótimo ver a quantidade de réplicas subindo magicamente toda