Unidade IV-Conceitos DevOps

Prévia do material em texto

Conceitos DevOps 
 
Material Teórico 
1 / 3 
Objetivo 
• Conhecer a cultura DevOps e seu impacto nas 
organizações. 
DevOps 
É uma metodologia de desenvolvimento de software que pretende 
integrar funções de desenvolvimento de software e operações de 
software num mesmo ciclo. Para isso ocorrer, é mandatório um alto 
nível de maturidade e coordenação envolvendo todas as áreas 
relacionadas desde negócios, passando por engenharia, 
desenvolvimento, testes e qualidade entre outros. 
 Trata-se de um processo integrado e requer também alto grau de 
automação para garantir a entrega constante, ou seja, Automação de 
Infraestrutura e Entrega Contínua. 
 
Figura 1 – Ciclo de desenvolvimento e operação DEVOPS 
 
Fonte: Reprodução 
Conforme o excerto do artigo de Mueller (2010), podemos definir 
que DevOps segue os princípios ágeis de desenvolvimento em todas as 
suas etapas. 
Valores do DevOps: Creio que os valores fundamentais do DevOps são 
efetivamente capturados no Manifesto ágil - com talvez uma leve 
emenda para se concentrar no serviço geral ou software totalmente 
entregue ao cliente em vez de simplesmente "software de trabalho". 
Algumas definições anteriores do DevOps, como "People Over Process, 
Over Tools", de Alex Honor , faz eco das declarações básicas do Agile 
Manifesto e solicita a colaboração direta de dev + ops (nesse caso 
literalmente apoio de desenvolvimento e operações). 
Princípios DevOps: Não há consenso, mas no nível conceitual é 
principalmente o alargamento dos princípios ágeis para incluir 
sistemas e operações em vez de interromper suas preocupações 
no checkout de código. 
Métodos DevOps: Alguns dos métodos como Scrum com operações, 
Kanban com operações etc. (embora geralmente com mais foco na 
integração de operações com dev, QA e produtos nas equipes). 
Práticas DevOps: Técnicas específicas utilizadas como parte da 
implementação dos conceitos e processos acima. Integração contínua e 
implantação contínua. Para tanto utilizar a virtualização e a 
computação em nuvem como prática comum para acelerar a mudança 
no mundo da infraestrutura moderna. 
DevOps Tools: Houve uma explosão de ferramentas em lançamento 
(jenkins, travis, teamcity), gerenciamento de configurações (fantoche, 
chef, ansible, cfengine), orquestração (zookeeper, noah, mesos), 
monitoramento, virtualização e contêineres (AWS, OpenStack , 
vagabund, docker) e muito mais. 
MUELLER, 2010, p.2 
Valores do DevOps: Creio que os valores fundamentais do DevOps são 
efetivamente capturados no Manifesto ágil - com talvez uma leve 
emenda para se concentrar no serviço geral ou software totalmente 
entregue ao cliente em vez de simplesmente "software de trabalho". 
Algumas definições anteriores do DevOps, como "People Over Process, Over 
Tools", de Alex Honor , faz eco das declarações básicas do Agile 
Manifesto e solicita a colaboração direta de dev + ops (nesse caso 
literalmente apoio de desenvolvimento e operações). 
Princípios DevOps: Não há consenso, mas no nível conceitual é 
principalmente o alargamento dos princípios ágeis para incluir 
sistemas e operações em vez de interromper suas preocupações 
no checkout de código. 
Métodos DevOps: Alguns dos métodos como Scrum com operações, 
Kanban com operações etc. (embora geralmente com mais foco na 
integração de operações com dev, QA e produtos nas equipes). 
Práticas DevOps: Técnicas específicas utilizadas como parte da 
implementação dos conceitos e processos acima. Integração contínua e 
implantação contínua. Para tanto utilizar a virtualização e a 
computação em nuvem como prática comum para acelerar a mudança 
no mundo da infraestrutura moderna. 
DevOps Tools: Houve uma explosão de ferramentas em lançamento 
(jenkins, travis, teamcity), gerenciamento de configurações (fantoche, chef, 
ansible, cfengine), orquestração (zookeeper, noah, mesos), monitoramento, 
virtualização e contêineres (AWS, OpenStack , vagabund, docker) e muito 
mais. 
MUELLER, 2010, p.2 
 
Figura 2 – Ciclo de desenvolvimento e operação DevOps com 
sugestão de ferramental para cada item do processo 
 
Fonte: Reprodução 
Conceitos de DevOps: Continuous 
Integration (integração contínua) 
É uma prática de desenvolvimento em que os desenvolvedores integram 
o código em um repositório compartilhado com frequência, de 
preferência várias vezes ao dia. Cada integração pode então ser 
verificada por uma construção automatizada e testes automatizados. 
Embora o teste automatizado não seja estritamente parte da integração 
contínua, normalmente está implícito. 
Um dos principais benefícios da integração regular é que você pode 
detectar erros rapidamente e localizá-los com mais facilidade. Como 
cada mudança introduzida é normalmente pequena em relação ao todo, 
localizar com precisão a mudança específica que introduziu um defeito 
pode ocorrer rapidamente. 
Integração contínua se tornou uma prática recomendada para o 
desenvolvimento de software e é guiada por um conjunto de princípios-
chave. Entre eles, estão o controle de revisão, automação de build e 
testes automatizados. 
O processo de integração contínua permite que os desenvolvedores 
integrem as alterações de código em um repositório compartilhado 
continuamente. O código, nesse processo, é continuamente testado e 
incorporado de forma mais suave. 
Conceitos de DevOps: Continuous 
Delivery (entrega contínua) 
É a capacidade de obter mudanças de todos os tipos, incluindo novas 
funcionalidades, alterações de configuração, correções de bugs e 
experimentos em produção, ou nas mãos de usuários, de forma segura e 
rápida de forma sustentável. 
As práticas no centro da entrega contínua que nos ajudam a alcançar 
vários benefícios importantes são: 
• Lançamento de baixo risco: é tornar as implantações 
de software eventos de baixo risco que podem ser 
realizados a qualquer momento, sob demanda, aplicando 
padrões como implantações com tempo de inatividade 
zero que são indetectáveis para os usuários. 
• Tempo de lançamento no mercado mais rápido: não é 
incomum que a fase de integração e teste, correção do 
ciclo de vida de entrega de software em fases tradicional 
consuma semanas ou até meses. Quando as equipes 
trabalham juntas para automatizar a construção e 
implantação, provisionamento de ambiente e processos 
de teste de regressão, os desenvolvedores podem 
incorporar integração e teste de regressão em seu 
trabalho diário e remover completamente essas fases. 
• Maior qualidade: utilizar ferramentas automatizadas que 
descobrem regressões em minutos, as equipes ficam 
livres para concentrar seus esforços na pesquisa do 
usuário e, em atividades de teste de nível superior, como 
teste exploratório, teste de usabilidade e teste de 
desempenho e segurança. 
• Custos mais baixos: qualquer produto ou serviço 
de software bem-sucedido evoluirá significativamente ao 
longo de sua vida útil. Ao investir em construção, teste, 
implantação e automação de ambiente, reduzimos 
substancialmente o custo de fazer e entregar mudanças 
incrementais no software. 
• Produtos melhores: a entrega contínua torna mais 
econômico trabalhar em pequenos lotes. Isso significa que 
podemos obter feedback dos usuários durante todo o ciclo 
de vida da entrega com base no software em 
funcionamento. 
Conceitos 
de DevOps: Continous Deployment (implantação 
contínua) 
Significa que cada mudança passa pelo pipeline e, se todos os testes 
forem aprovados, ela irá automaticamente para a produção. Com essa 
abordagem, você pode ter várias implantações de produção em um 
único dia, dependendo da rapidez com que a equipe está realizando as 
alterações. 
Portanto, a implantação contínua é uma etapa na qual cada mudança no 
código-fonte é implantada na produção automaticamente, sem a 
aprovação explícita de um desenvolvedor. O trabalho de um 
desenvolvedor normalmente termina na revisão de uma 
solicitação pull de um colega de equipe, e mesclá-la com o branch 
master, estamos falando do repositório central de códigoem um 
controlador de versão. Um serviço assume a partir daí, executando 
todos os testes e implantando o código para produção, enquanto 
mantém a equipe informada sobre o resultado de cada evento 
importante. 
A implantação contínua exige uma cultura altamente desenvolvida de 
monitoramento, disponibilidade e capacidade de recuperação rápida. 
A maioria das empresas começou a adotar práticas DevOps tornando 
o DevOps Engineer uma das funções mais procuradas no setor de TI hoje. 
Mas quais são as habilidades procuradas? Veja: 
• Fundamentos e scripts do Linux 
• Conhecimento em várias ferramentas e 
tecnologias DevOps 
o Gerenciamento do código-fonte 
o Gerenciamento de configuração 
o Integração Contínua 
o Teste contínuo 
o Monitoramento contínuo 
o Containerização 
• Integração contínua e entrega contínua 
• Infraestrutura como código 
• Principais conceitos de DevOps 
• Habilidades pessoais 
Desafiador, não é mesmo? Nossa recomendação é para começar com o 
básico, Linux, bash e outros. Foque na sequência nas práticas de DevOps. 
Cremos que habilidades pessoais vistas hoje como as “famosas” soft 
skills deverão ser desenvolvidas por você em paralelo. As exigências do 
mercado estão ficando maiores a cada dia e soft skills são ainda vistas 
como um diferencial. Aproveite, pois, com certeza, isso em breve será 
obrigatório. 
Talvez devamos usar uma definição mais específica 
para DevOps baseada no que acabamos de escrever logo acima, não é 
mesmo? 
DevOps é o domínio de engenharia responsável pelo design, 
implementação e gerenciamento de estruturas, integração contínua e 
entrega contínua, que mais recentemente também agregou ao termo a 
responsabilidade pelo design e gerenciamento de contêineres (serviços, 
micro serviços, e tudo o mais que envolve isso). 
Pessoas, processos e ferramentas são os três pilares de um projeto de 
desenvolvimento de software. Ao adotar uma cultura DevOps, eles devem 
estar devidamente alinhados com as necessidades atuais. A organização 
de processos que resulta em um ciclo de vida de desenvolvimento 
de software reduzido e a infraestrutura certa de ferramentas e 
tecnologias, sem dúvida, promoverá a implementação perfeita 
do DevOps. No entanto, as equipes e, em particular, as pessoas nessas 
equipes devem ser uma prioridade. Deve haver um sentimento de 
comunidade, compartilhando um objetivo comum e contribuindo para 
uma causa comum. E para que isso aconteça, a gestão deve ter como 
objetivo manter todas as equipes alinhadas. 
No modelo tradicional de desenvolvimento de software, 
desenvolvedores e operações tinham funções separadas. Mas, 
no DevOps, os dois grupos trabalham como uma equipe totalmente 
responsável pelo aplicativo do início ao fim. Um dos princípios básicos é 
o controle e a responsabilidade dos serviços desde o início até o fim. 
Tradicionalmente, os desenvolvedores escreveram código e operações 
implantando esse código, mas que leva a todos os tipos de ineficiências 
de diferenças na produção de problemas de desempenho e ambientes 
imprevisíveis. 
Para que o código seja de alta qualidade, ele precisa de testes regulares, 
portanto, DevOps exige teste automatizado. De forma geral, isso acelera 
o SDLC e permite que os desenvolvedores corrijam problemas em 
“movimento”. O lema é teste frequentemente, teste antecipadamente; 
isso é para detectar e retificar os defeitos antes que eles entrem em 
produção. A automação permitirá a execução de mais testes, além da 
economia de tempo, o qual poderia ser gasto em testes manuais. Teste 
de configuração de middleware, exame regular de alterações de rede e 
banco de dados, suporte ao processo de desenvolvimento por meio de 
carga automatizada, teste de unidade ou regressão, tudo contribui para 
a otimização em DevOps. 
A manutenção de alta frequência e estabilidade de implantação é um 
dos princípios fundamentais do DevOps. Portanto, a implantação do 
código deve ser automatizada, repetível e previsível em pequenos lotes. 
Assim, as equipes que implantam com mais frequência do que uma vez 
por semana também podem corrigir o código mais rápido, resolver 
prontamente as vulnerabilidades de segurança recém-descobertas e 
entregar valor aos clientes regularmente. Não haverá necessidade de 
esperar até a próxima janela de atualização agendada para implantar 
mudanças de emergência. 
Para fazer isso funcionar, devemos considerar uma cadência 
de sprint ágil semanal. Assim, não será problema determinar quais 
equipes podem agregar valor com mais frequência do que outras. 
Tido como um fator-chave em DevOps é o fato que devemos estabelecer 
monitoramento contínuo e observabilidade em integração contínua e 
entrega contínua. O problema-chave aqui são as falhas, por isso, 
monitoramos continuamente para permitir a identificação rápida 
dessas falhas, de tal forma que minimizaremos o seu impacto nos 
negócios, isso melhorará a visibilidade e facilitará o aumento da 
produtividade da equipe. 
Aqui vão algumas dicas, as ferramentas de monitoramento mais 
populares são Sensu, Prometheus e Nagios, mas precisamos de 
ferramentas de alerta como Slack, PagerDuty e ServiceNow, que podem 
fornecer às equipes informações importantes sobre os problemas que 
ocorreram para que eles possam agir. Porém, não adianta apenas avisar 
e fazer com que os desenvolvedores resolvam bugs, é importante termos 
controle, InfluxDB, Splunk e AWS podem armazenar as métricas que 
ajudarão a agregar e aprender com os dados coletados, todos crescem. 
Lembre-se de que integração contínua é uma prática de 
desenvolvimento de implementar pequenas mudanças e checá-las para 
repositórios de controle de versão regularmente. As equipes de 
desenvolvimento que praticam a integração contínua provavelmente 
terão que configurar testes automatizados para verificar se as 
alterações no código não quebraram nenhum recurso ou teste existente. 
Isso acontece muito, portanto, redobre a atenção aqui, a quebra 
do branch do teste simplesmente para a execução e impede a liberação 
em última instância, porque faltarão partes inteiras da funcionalidade 
que não foram testadas, por exemplo. 
Falamos de ferramentas, mas é bom dar uma lida e assistir a este vídeo, 
pois ele mostra essa integração e consumo de ferramentas no DevOps. 
Conheça as principais ferramentas OpenSource para DevOps 
ACESSE 
IaC: Infrastructure as Code 
Nos últimos anos, as coisas mudaram dramaticamente. Tendências 
como a computação em nuvem revolucionaram a maneira como as 
organizações projetam, desenvolvem e mantêm sua infraestrutura de 
TI. 
A computação em nuvem fornece recursos de computação sob 
demanda, que são separados do hardware físico e da configuração 
subjacente necessária. Os sistemas de software autônomos fornecem 
esses recursos de computação na nuvem para alcançar a automação que 
a computação em nuvem oferece. Por causa dessa automação, é possível 
controlar e manipular os recursos disponíveis programaticamente, 
fazendo interface com os provedores de nuvem. Dessa forma, as 
mudanças na infraestrutura como escalonamento de recursos podem 
ser implementadas de forma mais rápida e confiável e operadas 
principalmente sem interação manual, mas ainda com a capacidade de 
supervisionar todo o processo e reverter as mudanças se algo não sair 
de acordo com o planejado. 
Definir exatamente o que é uma infraestrutura em nuvem pode ser 
amplo e complexo, porque tem vários componentes, incluindo: 
servidores, software, dispositivos de rede e outros recursos de 
armazenamento. Todos são necessários para criar aplicativos que são 
acessados por meio da nuvem. Esses aplicativos podem ser recuperados 
remotamente pela Internet, serviços de telecomunicações, redes de 
longa distância e outros meios de comunicação em rede. 
A parte que nos interessa aqui é IaaS, ou seja, infraestrutura como 
serviço porque ela oferece o máximo de controle interno, permitindo 
acesso e manutenção direta à maioria dos recursos de nuvem. 
Ela é amplamente automatizada e escalonável,pois os clientes podem 
comprar recursos conforme necessário, sem depender 
de hardware interno. Os serviços em nuvem são gerenciados 
principalmente por uma empresa ou provedor, tem vários gigantes 
trabalhando nisso como Amazon, Microsoft, Alibaba e Google, entre 
outros, incluindo aplicativos, dados, tempo de execução, middleware e 
sistemas operacionais. Esses provedores são responsáveis pelos 
serviços, armazenamento, rede e virtualização. 
É importante você saber que uma infraestrutura de nuvem como 
serviço, assim como toda tecnologia de nuvem, é acessada pela internet 
por meio de um datacenter do provedor, que é responsável por manter e 
gerenciar o hardware local tradicional, como servidores e outros 
dispositivos de armazenamento, bem como networking e visualização. 
Isso significa que a equipe de TI da empresa contratante tem liberdade e 
controle para gerenciar aplicativos, dados, middleware e outros 
sistemas operacionais inclusive. 
Claro, nem tudo é facilidade, existem serviços de infraestrutura 
importantes, como monitoramento de rede, segurança, faturamento a 
gente chama isso de “billing”, recuperação de desastres e 
balanceamento de carga. Também há automação e orquestração 
avançadas para simplificar o desempenho e o gerenciamento do 
aplicativo, bem como facilitar a instalação de sistemas operacionais, 
implantar middleware, iniciar máquinas virtuais e criar armazenamento 
de carga de trabalho, backups e, claro, testar a recuperação do que foi 
feito o backup – chamamos isso de restore. 
Quatro itens são preocupantes e necessitam de planejamento antes de 
migrar: 
• Gerenciamento de Serviços e Recursos 
• Integração de ferramentas de gerenciamento de data 
center 
• Relatórios, Visibilidade, Confiabilidade, Segurança 
• interfaces para usuários, administradores e 
desenvolvedores 
Lembre-se de que os recursos de computação e armazenamento de 
dados são frequentemente virtualizados na computação em nuvem, 
tornando mais fácil para os usuários aproveitarem esses recursos com 
mais simplicidade e menos desperdício. 
Conforme esse volume de virtualização e a complexidade crescem, à 
medida que a escala da infraestrutura continua a se expandir, o 
gerenciamento da infraestrutura se reduziu a lidar com várias 
instâncias menores ao mesmo tempo, ao invés de algumas instâncias 
grandes. 
A natureza cíclica da infraestrutura moderna tornou imperativo 
transformar a maneira como a infraestrutura é projetada, desenvolvida, 
configurada, gerenciada e mantida nesse ambiente virtualizado, e é aí 
que entra a infraestrutura como código. 
Infraestrutura como código ou IaC como também é conhecida é a 
abordagem de automatizar a implantação e as alterações da 
infraestrutura, definindo os estados de recursos desejados e seus 
relacionamentos mútuos no código. O código é escrito em linguagens de 
ferramentas IaC especializadas e legíveis por pessoas. Os recursos reais 
na nuvem são criados ou modificados quando você executa o código. 
Isso, então, solicita que a ferramenta faça interface com o provedor de 
nuvem ou sistema de implantação em seu nome para aplicar as 
alterações necessárias, sem usar a interface da web de um provedor de 
nuvem. 
O código pode ser modificado sempre que necessário, após a execução 
do código, a ferramenta IaC cuidará de encontrar as diferenças entre a 
infraestrutura desejada no código e a infraestrutura real na nuvem, 
tomando medidas para tornar o estado real igual ao desejado. Conforme 
escritos de SAVIC (2020), para que o IaC funcione na prática, os 
recursos criados não devem ser modificados manualmente depois, pois 
isso cria discórdia entre a infraestrutura esperada no código e o estado 
real na nuvem. 
Diz ainda que os recursos modificados manualmente podem ser 
recriados ou excluídos durante as futuras execuções do código, e toda 
essa personalização seria perdida. Para que possamos incorporar as 
modificações, é necessário que acrescentemos as modificações no 
código da infraestrutura. 
Portanto, IaC permite a criação de recursos de forma consistente, sem 
erros, ao mesmo tempo em que reduz o gerenciamento e o tempo de 
configuração manual. Vejamos algumas vantagens e benefícios da IaC 
conforme SAVIC (2020). 
Os principais benefícios do IaC são: 
Velocidade: a infraestrutura como código fornece o elemento de 
velocidade ao permitir que os usuários configurem a infraestrutura no 
menor período possível, simplesmente executando um script. Isso pode 
ser feito para todos os ambientes, desde o desenvolvimento até o 
controle de qualidade, produção e teste, trazendo maior eficiência para 
todo o ciclo de vida do desenvolvimento. 
Responsabilidade: Como os arquivos de configuração de Infraestrutura 
como Código podem ser controlados como qualquer outro arquivo de 
código-fonte, há transparência total sobre o impacto de cada 
configuração. Essa transparência ajuda a corrigir a responsabilidade 
pelo que está funcionando e pelo que não está. 
Consistência: eliminar a necessidade de manuseio manual da 
infraestrutura diminui o risco de erro humano. Isso significa que não há 
discrepâncias, inconsistências, erros ou lapsos de comunicação na 
forma como a infraestrutura é projetada, implantada ou gerenciada. Os 
arquivos de configuração atuam como uma fonte única. Eles podem ser 
implantados várias vezes sem risco de erros. 
Implementação : remover a interação de provisionamento manual com 
provedores de nuvem significa uma velocidade de implementação mais 
rápida. 
Recuperação : identificar problemas na configuração pode significar 
recuperação rápida de falhas. 
Consistência : os recursos de implantação são sempre os mesmos, 
resolvendo a fragilidade da infraestrutura. 
Modificação : a modificação de recursos pode ter um tempo de resposta 
rápido. 
Reutilização : reutilização de partes da arquitetura de infraestrutura em 
projetos futuros. 
Controle de versão : armazenamento do código de infraestrutura em 
sistemas de controle de versão. 
Visibilidade : escrever a configuração como código atua como 
documentação para a infraestrutura. 
SAVIC, 2020, p.3 
Os principais benefícios do IaC são: 
Velocidade: a infraestrutura como código fornece o elemento de 
velocidade ao permitir que os usuários configurem a infraestrutura no 
menor período possível, simplesmente executando um script. Isso pode 
ser feito para todos os ambientes, desde o desenvolvimento até o 
controle de qualidade, produção e teste, trazendo maior eficiência para 
todo o ciclo de vida do desenvolvimento. 
Responsabilidade: Como os arquivos de configuração de Infraestrutura 
como Código podem ser controlados como qualquer outro arquivo de 
código-fonte, há transparência total sobre o impacto de cada 
configuração. Essa transparência ajuda a corrigir a responsabilidade 
pelo que está funcionando e pelo que não está. 
Consistência: eliminar a necessidade de manuseio manual da 
infraestrutura diminui o risco de erro humano. Isso significa que não há 
discrepâncias, inconsistências, erros ou lapsos de comunicação na 
forma como a infraestrutura é projetada, implantada ou gerenciada. Os 
arquivos de configuração atuam como uma fonte única. Eles podem ser 
implantados várias vezes sem risco de erros. 
Implementação : remover a interação de provisionamento manual com 
provedores de nuvem significa uma velocidade de implementação mais 
rápida. 
Recuperação : identificar problemas na configuração pode significar 
recuperação rápida de falhas. 
Consistência : os recursos de implantação são sempre os mesmos, 
resolvendo a fragilidade da infraestrutura. 
Modificação : a modificação de recursos pode ter um tempo de resposta 
rápido. 
Reutilização : reutilização de partes da arquitetura de infraestrutura em 
projetos futuros. 
Controle de versão : armazenamento do código de infraestrutura em 
sistemas de controle de versão. 
Visibilidade : escrever a configuração como código atua como 
documentação para a infraestrutura. 
SAVIC, 2020, p.3Figura 3 – Exemplo de fluxo de trabalho IaC. “Em um fluxo de 
trabalho IaC, você pode ativar a infraestrutura repetidamente de 
maneira padronizada, o que significa que o desenvolvimento e o 
teste de software são um processo mais rápido porque os 
ambientes de desenvolvimento, preparação, teste de garantia de 
qualidade e produção são separados. Você pode repetir o 
processo de escrever código e testá-lo ao vivo, implantando a 
infraestrutura quantas vezes forem necessárias. Depois que sua 
infraestrutura escrita atender a todos os requisitos, você pode 
implantá-la nos ambientes de nuvem desejados. Quando surgem 
novos requisitos, você pode reiterar o processo.” Extraído de 
(SAVIC, 2020, p.3). 
 
Fonte: Reprodução 
Como você já deve ter percebido, para controlar IaC, é importante 
usarmos um software de controle de versão como o GIT no GitHub ou 
outro VCS – Version Control Software (software de controle de versão) se 
for o caso. Portanto, as declarações de infraestrutura ficam facilmente 
recuperáveis, com alterações visíveis para todos, e fornece instantâneos 
em pontos históricos da configuração, para que sempre possamos 
voltar para uma versão anterior se novas modificações criarem erros. 
Aqui é importante pontos de retorno ou rollback, claro, aqui voltamos a 
falar de GMUD. 
Infraestrutura como código refere-se ao processo de provisionamento e 
gerenciamento de infraestruturas de TI, como redes, balanceadores de 
carga, máquinas virtuais, data centers e topologia de conexão em um 
modelo descritivo por meio de arquivos de definição legíveis por 
máquina com a ajuda do controle de versão usado por a 
equipe DevOps como código-fonte. 
NERO, 2020, p.1 
Infraestrutura como código refere-se ao processo de provisionamento e 
gerenciamento de infraestruturas de TI, como redes, balanceadores de 
carga, máquinas virtuais, data centers e topologia de conexão em um 
modelo descritivo por meio de arquivos de definição legíveis por 
máquina com a ajuda do controle de versão usado por a 
equipe DevOps como código-fonte. 
NERO, 2020, p.1 
Isso torna redundante o uso de ferramentas de configuração interativas 
ou configuração de hardware físico. 
 
Figura 4 – Visão da IaC. “Simplificando, o IaC permite que você 
gerencie a infraestrutura de tecnologia apenas usando arquivos 
de configuração. Portanto, diferentes pessoas lidando com as 
configurações e gerenciamento manualmente da infraestrutura 
de TI, as discrepâncias e inconsistências se tornam uma parte 
inevitável das configurações manuais da infraestrutura. Tudo 
isso pode ser tratado com um único arquivo de código. Como a 
infraestrutura é gerenciada de maneira eficaz e executada apenas 
com texto, você pode ajustá-la de acordo com seus requisitos e 
colocá-la sob controle de origem, como faria com qualquer outro 
arquivo de código-fonte.” 
 
Fonte: Adaptado de NERO, 2020, p.2 
Infraestrutura Mutável versus Imutável 
As equipes de DevOps se ocuparam em dar as boas-vindas aos clientes 
com lançamentos novos e contínuos; sem saber, também deram boas-
vindas às vulnerabilidades de aplicativos. 
Infraestrutura mutável é a infraestrutura de TI sujeita a alterações de 
acordo com os requisitos do desenvolvedor, aplicativo ou implantação. 
Com a chegada a uns 10 anos do DevOps, até mesmo os desenvolvedores 
têm direitos de acesso para alterar a infraestrutura para o ambiente de 
teste ou pré-produção, se não para o ambiente de produção. Isso tem 
trazido sérios problemas de segurança que é claro, afeta também a 
privacidade de dados em última instância porque as vulnerabilidades 
criam brechas importantes que ampliam a superfície de ataques para os 
chamados black hats. 
Para Thota (2020), essas decisões dos desenvolvedores em alterar o 
ambiente ou a infraestrutura eram necessárias para acelerar os 
lançamentos e aumentar o nível de satisfação dos clientes. Então, 
ameaças à segurança, como não acompanhar o processo de 
documentação, tornando o rastreamento de versão difícil avançando 
para a segurança do ambiente, teste, controle de qualidade impactando 
também os gerentes de produto que começaram a ter dificuldade em 
acompanhar as mudanças de configuração, foram acumulando 
fragilidades para a segurança. 
Quando se trata de proteger a infraestrutura, o acesso aos sistemas ou 
ao servidor é a prática mais comum, seguido de patch de atualização e 
gerenciamento de vulnerabilidade para atualizar 
o software oportunamente. Por fim, o gerenciamento de APIs é outro 
desafio em infraestrutura. 
Uma coisa é certa e todos da área de TI sabem disso, apesar de DevOps e 
a automação terem ajudado, por outro lado, o gerenciamento de 
configuração complicou-se exponencialmente. Frequentemente, em 
uma infraestrutura mutável, as equipes de DevOps enfrentam a situação 
em que alguém modificou o servidor, levando a um servidor de 
produção ruim, resultando em tempo de inatividade ou consequências 
desconhecidas e infelizmente desastrosas. 
Infraestrutura mutável como código cria um ecossistema onde apenas 
um conjunto específico de profissionais pode resolver os problemas 
relacionados a servidores específicos, também conhecidos como flocos 
de neve ou snow flakes. Isso significa que o processo de resolução de 
problemas pode ser interrompido ou prejudicado se a pessoa ou equipe 
designada não estiver disponível a qualquer momento. Na verdade, por 
mais que se queira enxergar benefícios, e existem alguns, a 
infraestrutura mutável coloca as operações de negócios em risco de 
variações na configuração. Variações na configuração não são coisas 
boas de acontecerem em ambientes de produção que devem ser estáveis 
e evitar paradas de negócios e listas intermináveis de aberturas de 
chamado de usuários bravos e gerentes caçando culpados na área de TI. 
Isso, ao longo do tempo, atinge o desempenho do projeto no longo 
prazo. 
Mudar de infraestrutura mutável para imutável ainda é caro, porém, 
necessário ao longo do tempo. Inclui práticas de gerenciamento e 
manutenção de servidores e convencimento da equipe de segurança e 
desenvolvimento de TI a se esquecer de seu ambiente anterior e adotar 
novos princípios. Portanto, estamos descrevendo aqui que é necessária 
a mudança de comportamento, mindset profundo. Flores (2020) coloca 
de forma clara os prós e contras da infraestrutura mutável: 
Prós da infraestrutura mutável 
• Sua equipe de TI não precisa criar servidores do zero 
sempre que uma mudança é necessária. 
• Você pode distribuir atualizações para servidores 
individuais, o que torna o processo de atualização mais 
rápido. 
• Você pode garantir que a infraestrutura utilizada atenda 
às necessidades específicas de cada usuário. 
• Você pode entender cada servidor em um nível individual, 
o que torna mais fácil diagnosticar problemas. 
Contras da infraestrutura mutável 
• Como cada servidor é único na configuração, fica mais 
difícil diagnosticar e gerenciar cada servidor. Isso é 
chamado de desvio de configuração. 
• Controle de versão indiscreto - As alterações feitas no 
servidor não são documentadas, o que torna o 
rastreamento difícil e o diagnóstico quase impossível. 
• As atualizações podem falhar devido a vários motivos, 
como falha de DNS ou conectividade de rede ruim, que 
demoram para serem reconhecidos e corrigidos. 
• A depuração é demorada devido a problemas de 
rastreamento de atualização. 
Você pode acabar com várias versões de uma atualização sem qualquer percepção 
do problema. 
FLORES, 2020, p.3 
Prós da infraestrutura mutável 
• Sua equipe de TI não precisa criar servidores do zero sempre que uma mudança é 
necessária. 
• Você pode distribuir atualizações para servidores individuais, o que torna o processo 
de atualização mais rápido. 
• Você pode garantir que a infraestrutura utilizada atenda às necessidades específicas de 
cada usuário. 
• Você pode entender cada servidor em um nível individual, o que torna mais fácil 
diagnosticar problemas. 
Contras da infraestrutura mutável 
• Como cada servidoré único na configuração, fica mais difícil diagnosticar e gerenciar 
cada servidor. Isso é chamado de desvio de configuração. 
• Controle de versão indiscreto - As alterações feitas no servidor não são documentadas, 
o que torna o rastreamento difícil e o diagnóstico quase impossível. 
• As atualizações podem falhar devido a vários motivos, como falha de DNS ou 
conectividade de rede ruim, que demoram para serem reconhecidos e corrigidos. 
• A depuração é demorada devido a problemas de rastreamento de atualização. 
Você pode acabar com várias versões de uma atualização sem qualquer percepção do 
problema. 
FLORES, 2020, p.3 
Bem, vamos ao contraponto, a infraestrutura imutável não é capaz de 
mudar, tornando-a mais resiliente. Como cada componente de 
Infraestrutura como Código aqui é feito sob medida para especificações 
precisas, também é uma solução mais futurística. Nero (2020) a 
descreve como não tendo espaço para lidar com pequenos desvios 
individualmente. Se uma mudança for necessária, toda a infraestrutura 
é provisionada novamente para atender a esses requisitos e a antiga é 
desativada. 
Embora possa parecer um exercício inútil, ele se mostra imensamente 
eficaz em alcançar uniformidade e consistência em infraestrutura como 
código. É o resultado da virtualização, amplamente suportada pela 
computação em nuvem. Nesse modelo, tanto o software quanto 
o hardware são mantidos na nuvem, o que significa que as empresas não 
precisam se preocupar em provisionar uma nova infraestrutura ou 
descartar a existente para atender a seus requisitos de mudança. 
Em suma, a infraestrutura não pode ser modificada depois de 
implantada. Quando mudanças são necessárias, você precisa implantar 
novamente, adicionar infraestrutura e desativar a infraestrutura antiga. 
Pode parecer pouco, mas é muito, porque evitamos a implementação de 
uma atualização problemática como ocorre no modelo mutável, e 
apenas transferir usuários quando tiver certeza da funcionalidade do 
novo servidor. Além do mais, você não acaba com várias máquinas 
inutilizáveis, isso aumenta o custo da solução sobremaneira. Isso 
diminui desvios na configuração e consequentemente no 
gerenciamento desta. 
As “coisas” devem ser simples quando lidamos com ambientes 
interativos complexos e repletos de mudanças. Portanto, a codificação 
das práticas de segurança em IaC dá disciplina a todo o processo de 
implantação de novos ambientes em infraestrutura imutável. 
Depois que todas as práticas de segurança são codificadas e colocadas 
em modo de automação, não há espaço para erros manuais e falsas 
interpretações. Isso aumenta significativamente a segurança como um 
todo, pois há apenas um servidor que as equipes precisam cuidar, fazer 
alterações, atualizar e, em seguida, destruir. 
 
Figura 5 –Diferença entre Infraestrutura como código mutável x 
imutável. 
 
Flores (2020) destaca as vantagens e desvantagens da infraestrutura 
como código mutável: 
Vantagens da infraestrutura imutável 
• Controle de versão discreto - cada versão do servidor é 
independente da outra. Você não terá duas versões em 
execução ao mesmo tempo. 
• Rastreamento mais fácil - Como você cria novas versões 
do servidor quando precisa fazer alterações, pode 
rastrear o erro de cada versão. Não há zona intermediária. 
• É mais fácil testar servidores diferentes e distribuir 
atualizações, pois as configurações em cada servidor são 
consistentes. 
• Você gosta de previsibilidade, pois os servidores 
permanecem os mesmos. 
• Ótimo para ambientes interdependentes, como 
tecnologias de nuvem. 
• Você pode reverter as implantações, pois as versões 
anteriores não são afetadas. 
Contras da infraestrutura imutável 
• Você não pode modificar os servidores existentes. Em 
caso de problemas, servidores com a mesma 
configuração precisam de uma revisão completa. 
• Você precisa externalizar o armazenamento de dados em 
vez de copiá-lo para um disco local. 
FLORES, 2020, p.4 
Vantagens da infraestrutura imutável 
• Controle de versão discreto - cada versão do servidor é independente da outra. Você 
não terá duas versões em execução ao mesmo tempo. 
• Rastreamento mais fácil - Como você cria novas versões do servidor quando precisa 
fazer alterações, pode rastrear o erro de cada versão. Não há zona intermediária. 
• É mais fácil testar servidores diferentes e distribuir atualizações, pois as configurações 
em cada servidor são consistentes. 
• Você gosta de previsibilidade, pois os servidores permanecem os mesmos. 
• Ótimo para ambientes interdependentes, como tecnologias de nuvem. 
• Você pode reverter as implantações, pois as versões anteriores não são afetadas. 
Contras da infraestrutura imutável 
• Você não pode modificar os servidores existentes. Em caso de problemas, servidores 
com a mesma configuração precisam de uma revisão completa. 
• Você precisa externalizar o armazenamento de dados em vez de copiá-lo para um 
disco local. 
FLORES, 2020, p.4 
A infraestrutura imutável oferece suporte à implantação automática. 
Esse tipo de infraestrutura é construído principalmente em torno da 
virtualização. 
Portanto, você não precisa se preocupar com provisionamento e 
desprovisionamento de hardware e software conforme necessário. 
No ambiente de nuvem, você pode documentar todos os processos 
realizados para criar um recurso. Conforme os ataques cibernéticos 
continuam a crescer, a infraestrutura imutável se torna ainda mais 
importante porque fornecem proteção de segurança contra injeções 
de malware em servidores, código comprometido, patching e 
vulnerabilidades de atualização, além disso, bloqueiam muitas 
maneiras pelas quais os cibercriminosos podem acessar a 
infraestrutura. 
Há formas de se implementar diferentes e as chamamos de declarativas 
e imperativas. Conhecer a infraestrutura declarativa versus imperativa 
como código pode significar a diferença entre ter uma vida fácil ou um 
pesadelo total. 
Modelos Declarativos versus Imperativos 
Na abordagem imperativa, a responsabilidade de definir as etapas 
exatas necessárias para atender a uma meta final é do usuário. Isso 
significa que o usuário deve especificar as instruções de instalação 
do software, criação do banco de dados, configuração e assim por diante. 
Uma abordagem declarativa, por outro lado, concentra-se na definição 
do estado final, e não nas etapas exatas. Um usuário especifica, ou 
declara o número de cargas de trabalho a serem armazenadas em 
contêineres ou virtualizadas, o aplicativo e as máquinas que precisam 
ser implantadas e como cada uma será configurada. No entanto, você 
não precisa se preocupar com as etapas exatas necessárias para concluir 
esses processos. Um código é executado para completar as operações 
necessárias para atingir o estado final declarado pelo usuário. 
As diferenças entre os modelos declarativo e imperativo podem ser 
resumidas em uma frase: o imperativo se concentra em como, e o 
declarativo se concentra em quê. Um descreve o que precisa acontecer; 
as minúcias para torná-lo assim são deixadas para o sistema. Em 
contraste, a programação imperativa envolve escrever código que segue 
etapas explícitas para resolver um problema, concluir uma tarefa ou 
alcançar o resultado desejado. 
Gerenciamento de configuração dentro da infraestrutura como código é 
fortemente dependente de linguagem adequada a essa programação. 
Vejamos o exemplo do Puppet, ele é declarativo: o sysadmin descreve um 
estado final desejado e a ferramenta tenta alcançá-lo. Sua linguagem de 
domínio específico é usada para criar descrições de alto nível do estado 
do servidor desejado, em oposição às instruções e ações a serem 
realizadas. Portanto, nos scripts ou manifestos, que contêm informações 
de configuração, podem ser usadas quantas vezes quiserem, para obter 
os mesmos resultados, ou seja, se o estado final desejado já tiver sido 
alcançado, no caso do Puppet, ele simplesmente ignora o item em 
questão, então os usuários só precisam se preocupar com oestado final 
desejado do sistema a ser configurado, não com a sequência de etapas 
necessárias para chegar lá. 
Por outro lado, peguemos o Chef, concorrente do Puppet, ele é 
absolutamente imperativo. Os usuários definem comandos e sua ordem 
de execução em instruções de configuração chamadas Receitas, que por 
sua vez podem ser organizadas em Livros de Receitas para facilitar o 
gerenciamento. 
Vejamos este exemplo: 
Esta receita verifica o JDK 7 no nó de destino – se ele existir, o Chef 
instalará o OpenJDK 7. Caso contrário, um aviso será gerado. Observe 
que as Receitas do Chef são estruturadas como listas sequenciais de 
comandos, em oposição aos Manifestos de Marionetes, que contêm 
apenas descrições dos estados finais desejados. 
Vamos, analisar três perspectivas: a de um programador, administrador 
de sistema e desenvolvedor FULL STACK . 
Apaixonado por escrever código eficiente, estruturado e fácil de 
entender, o programador não é o maior fã de modelos declarativos que 
empregam abstrações pesadas. Ele está acostumado a ditar como as 
coisas devem acontecer com loops for, instruções condicionais, 
variáveis e assim por diante. A lógica de negócios do software em que 
ele trabalha é principalmente de natureza imperativa. 
Melhor ajuste: ferramentas obrigatórias de CM como Chef 
O administrador de sistemas gosta de administrar de maneira restrita, 
e por um bom motivo: se a infraestrutura cair, a empresa para de 
repente. Ele é um mago do Bash, proficiente em Python e Perl e prefere 
usá-los a aprender novas linguagens como Ruby. Ele prefere o modelo 
declarativo ao invés do imperativo, mas está ciente dos desafios que o 
primeiro tem no gerenciamento de infraestruturas de nuvem 
dinâmicas. 
Melhor ajuste: ferramentas híbridas de CM como Ansible ou SaltStack 
O desenvolvedor full stack pode atravessar a pilha com facilidade e 
adora a ideia de abstrair a infraestrutura para o código. Normalmente, 
quando experiente, é um ninja em Ruby/RoR, é fã tanto do Chef quanto 
do Puppet. Pode apreciar os méritos de cada modelo; para ele, qualquer 
tipo de ferramenta torna seu trabalho de construir e lançar 
continuamente software de qualidade mais rápido, mais eficiente e 
menos sujeito a erros. 
Melhor ajuste: qualquer um dos modelos. Puppet, Chef e SaltStack são 
opções viáveis. 
UPGUARD, 2020, p.6 
Vamos, analisar três perspectivas: a de um programador, administrador 
de sistema e desenvolvedor FULL STACK . 
Apaixonado por escrever código eficiente, estruturado e fácil de 
entender, o programador não é o maior fã de modelos declarativos que 
empregam abstrações pesadas. Ele está acostumado a ditar como as 
coisas devem acontecer com loops for, instruções condicionais, 
variáveis e assim por diante. A lógica de negócios do software em que 
ele trabalha é principalmente de natureza imperativa. 
Melhor ajuste: ferramentas obrigatórias de CM como Chef 
O administrador de sistemas gosta de administrar de maneira restrita, 
e por um bom motivo: se a infraestrutura cair, a empresa para de 
repente. Ele é um mago do Bash, proficiente em Python e Perl e prefere 
usá-los a aprender novas linguagens como Ruby. Ele prefere o modelo 
declarativo ao invés do imperativo, mas está ciente dos desafios que o 
primeiro tem no gerenciamento de infraestruturas de nuvem 
dinâmicas. 
Melhor ajuste: ferramentas híbridas de CM como Ansible ou SaltStack 
O desenvolvedor full stack pode atravessar a pilha com facilidade e adora 
a ideia de abstrair a infraestrutura para o código. Normalmente, quando 
experiente, é um ninja em Ruby/RoR, é fã tanto do Chef quanto do Puppet. 
Pode apreciar os méritos de cada modelo; para ele, qualquer tipo de 
ferramenta torna seu trabalho de construir e lançar continuamente 
software de qualidade mais rápido, mais eficiente e menos sujeito a 
erros. 
Melhor ajuste: qualquer um dos modelos. Puppet, Chef e SaltStack são 
opções viáveis. 
UPGUARD, 2020, p.6 
Podemos perceber, em linhas gerais, sem causar muita controvérsia e 
respeitando ambas as formas que o estilo declarativo parece ser mais 
vantajoso para infraestrutura como código. Observe, no entanto, as 
limitações. Por um lado, essas vantagens podem não se aplicar a outras 
formas de programação, como vimos no exemplo dado 
por Upguard (2020). Com o estilo declarativo, estamos dando uma 
grande quantidade de controle sobre como as alterações são feitas em 
seus provedores de serviços em nuvem. Isso pode ser problemático 
dependendo dos padrões da sua organização. Seria melhor adotarmos o 
caminho do meio, claro, sem “ficar em cima do muro”, mas temos um 
compromisso que é empregar uma abordagem híbrida, portanto, 
manter a infraestrutura como declarativa e, em seguida, usar o estilo 
imperativo para o código de implantação para gerenciar outros 
requisitos. 
Em suma, o modelo declarativo funciona bem para IaC, pois podemos 
criar infraestrutura em grande escala que não exigir muito 
gerenciamento por parte da equipe. A implementação subjacente lidará 
com os detalhes do recurso, então poderemos nos concentrar em lidar 
com o que desejamos fazer. Porém, apesar de o modelo imperativo 
fornecer mais controle, ele exige mais trabalho por parte do time de 
desenvolvedores. Temperança é o caminho. 
Engenharia de Plataforma 
O surgimento de microsserviços, orquestração de contêineres e coisas 
do gênero introduziram novos desafios de engenharia. Equipes de 
engenharia de plataforma foram formadas em várias organizações para 
assumir essas responsabilidades. Em alguns aspectos, a função de um 
engenheiro de plataforma não mudou drasticamente em relação a 
outras funções relacionadas ao DevOps. 
Conforme os escritos de Daigler (2020), empresas maduras com 
infraestrutura legada estão se mobilizando em preparação para a 
grande migração para a nuvem, e os provedores de nuvem estão 
prontos para aceitá-los de braços abertos. Mas, com essa migração, 
vem a necessidade de conhecimento em nuvem e orquestração de 
contêineres; será que não é o momento de se devem formar uma equipe 
de engenharia de plataforma. Essa tendência está em franca ascensão 
no mundo, grande parte motivada pela rápida adoção 
de Kubernetes e IaC. 
A engenharia de plataforma permite que os desenvolvedores de 
aplicativos coloquem o software nas mãos dos usuários de maneira 
mais fácil. Algumas dessas maneiras podem padronizar as 
implantações do Kubernetes de uma organização, garantindo que a 
infraestrutura seja auditável, automatizando vários processos de 
implantação e escrevendo documentação para desenvolvedores de 
aplicativos. Aqui, podemos pensar de forma evolucionária, afinal, lá 
para os anos de 2001-2003 DevOps era bastante ad hoc. 
Daigler (2020) nos explica de forma clara onde DevOps se diverge da 
Engenharia de Plataforma e isso é bom: 
Para descrever melhor a função da engenharia de plataforma em uma 
organização, vamos considerar um exemplo. Suponha que uma 
seguradora fundada na década de 1980 comece a mudar sua 
infraestrutura para a nuvem. Agora, suponha que nessa organização os 
engenheiros de software estejam divididos em duas categorias: 
desenvolvimento de aplicativos e infraestrutura. Antes da era da 
nuvem, era comum que os engenheiros de infraestrutura se parecessem 
com uma equipe de backend que oferecia APIs. 
Essas responsabilidades são geralmente cumpridas por meio do uso de 
infraestrutura como código (IaC). Algumas infraestruturas comuns 
como ferramentas de código são Terraform, Vagrant, Chef, Puppet e 
AWS CloudFormation. Várias dessas ferramentas são de código aberto. 
Geralmente, a plataforma construída por engenheiros de plataforma é 
composta por essas ferramentas de código aberto. Os engenheiros de 
plataforma de uma organização adaptam a infraestrutura como 
ferramentas de código às necessidades dos desenvolvedores de 
aplicativos da organização. 
DAIGLER, 2020, p.3 
Para descrever melhor a função da engenharia de plataforma em uma 
organização, vamosconsiderar um exemplo. Suponha que uma 
seguradora fundada na década de 1980 comece a mudar sua 
infraestrutura para a nuvem. Agora, suponha que nessa organização os 
engenheiros de software estejam divididos em duas categorias: 
desenvolvimento de aplicativos e infraestrutura. Antes da era da 
nuvem, era comum que os engenheiros de infraestrutura se parecessem 
com uma equipe de backend que oferecia APIs. 
Essas responsabilidades são geralmente cumpridas por meio do uso de 
infraestrutura como código (IaC). Algumas infraestruturas comuns 
como ferramentas de código são Terraform, Vagrant, Chef, Puppet e 
AWS CloudFormation. Várias dessas ferramentas são de código aberto. 
Geralmente, a plataforma construída por engenheiros de plataforma é 
composta por essas ferramentas de código aberto. Os engenheiros de 
plataforma de uma organização adaptam a infraestrutura como 
ferramentas de código às necessidades dos desenvolvedores de 
aplicativos da organização. 
DAIGLER, 2020, p.3 
 
Figura 6 – Fluxo de um exemplo de infraestrutura implementada 
com ferramentas utilizadas. A figura ilustra como a 
infraestrutura, à medida que os engenheiros de código e 
plataforma se encaixam em uma equipe de desenvolvimento, e 
também como essas ferramentas, em última análise, levam a 
mais recursos. Tal como acontece com muitas tecnologias, 
existem diferentes abordagens para a infraestrutura como 
código. Os mais comuns são modelos declarativos e imperativos. 
Estruturas declarativas, como a oferecida pelo Kubernetes, 
exigem que os usuários definam um estado desejado. Em um 
modelo declarativo, o sistema desenvolve um plano para atingir 
e manter o estado especificado. 
 
Fonte: DAIGLER, N. The Rise of Platform Engineering . 2020. 
 
 
2 - 
Material Complementar 
 
 
https://alt-5d152e0e8981d.blackboard.com/bbcswebdav/pid-10273307-dt-content-rid-134564987_1/courses/3610_12_40_BACKUP/3610_12_40_BACKUP/materialReferencial/materialDidatico/un_IV/flip/index.html#/lessons/PpJs6iVBynqoC46TmnbwGn_Q11qY-rgf
https://alt-5d152e0e8981d.blackboard.com/bbcswebdav/pid-10273307-dt-content-rid-134564987_1/courses/3610_12_40_BACKUP/3610_12_40_BACKUP/materialReferencial/materialDidatico/un_IV/flip/index.html#/lessons/PpJs6iVBynqoC46TmnbwGn_Q11qY-rgf
https://alt-5d152e0e8981d.blackboard.com/bbcswebdav/pid-10273307-dt-content-rid-134564987_1/courses/3610_12_40_BACKUP/3610_12_40_BACKUP/materialReferencial/materialDidatico/un_IV/flip/index.html#/lessons/PpJs6iVBynqoC46TmnbwGn_Q11qY-rgf
https://alt-5d152e0e8981d.blackboard.com/bbcswebdav/pid-10273307-dt-content-rid-134564987_1/courses/3610_12_40_BACKUP/3610_12_40_BACKUP/materialReferencial/materialDidatico/un_IV/flip/index.html#/lessons/PpJs6iVBynqoC46TmnbwGn_Q11qY-rgf