Dicionário do DevOps - Ep. 1

Source: Dev.to

Fundamentos, conceitos e a linguagem do dia a dia

Entrar no mundo DevOps não é difícil por falta de ferramentas ou documentação, mas pode acontecer de existir uma barreira linguística que torne a entrada nesse mundo confusa.

Os mesmos termos são usados com significados diferentes dependendo da empresa, do cargo ou da maturidade do time (eu mesmo já passei por esse problema). Isso cria um efeito colateral perigoso: as pessoas passam a executar tarefas sem entender o sistema no qual essas tarefas existem.

Este artigo inaugura a série Dicionário do DevOps, cujo objetivo é simples:

• organizar o vocabulário real do DevOps, conectando termos, conceitos e ferramentas à prática diária;
• ajudar iniciantes que queiram entrar na área.

Mas afinal, o que é DevOps?

DevOps é um modelo de organização do trabalho em que o mesmo time seja responsável por todo o ciclo de vida do software, desde o código até a operação em produção, tratando entrega, infraestrutura e confiabilidade como partes de um único fluxo contínuo.

Ele surge da necessidade de resolver um problema clássico: desenvolvimento e operações otimizados para objetivos diferentes, gerando atrito, lentidão e falhas previsíveis.

Na prática, DevOps combina três pilares inseparáveis:

• Cultura – colaboração, responsabilidade compartilhada e feedback rápido;
• Processos – fluxo claro do código até a produção;
• Automação – redução do erro humano e aumento da previsibilidade.

DevOps busca tornar esse fluxo previsível e sustentável por meio de processos claros, automação de tarefas repetitivas e medição constante do comportamento do sistema em produção, reduzindo a dependência de ações manuais e decisões baseadas em sensação.

---

Automação: o que ela resolve

Automação é frequentemente tratada como sinônimo de DevOps, o que é um erro — mas ela é, sem dúvida, o braço operacional mais visível. Dentro de DevOps, a automação não existe para automatizar qualquer coisa possível; ela existe para resolver problemas específicos de entrega, operação e confiabilidade de sistemas.

Automatizar significa transformar atividades repetitivas, manuais e frágeis em processos reproduzíveis e rastreáveis.

No cotidiano DevOps, a automação aparece em:

• builds de aplicação;
• execução de testes;
• deploys;
• provisionamento de infraestrutura;
• configuração de ambientes;
• coleta de métricas e logs.

DevOps lida com fluxo de software em produção. Logo, a automação DevOps foca em tudo aquilo que afeta esse fluxo de forma direta e recorrente.

---

Pipeline: o espelho do processo do time

Uma pipeline é uma sequência de etapas ou processos que são executados em série para realizar uma tarefa ou conjunto de tarefas.

De forma objetiva, um pipeline é uma cadeia automatizada de estágios que transforma código em software executável em um ambiente específico.

Normalmente inclui:

• build;
• testes;
• validações;
• empacotamento;
• deploy.

O que pouca gente percebe é que pipelines revelam problemas organizacionais:

---

Ambientes: dev, staging e produção

Ambientes são frequentemente tratados como algo secundário, quando na verdade são parte central da confiabilidade do sistema.

Um ambiente é um contexto isolado de execução, com configurações, dependências e dados próprios.

Os mais comuns são:

• dev – experimentação e desenvolvimento;
• staging – validação próxima da realidade;
• prod – ambiente real de usuários.

Quando alguém diz “funciona no meu ambiente”, isso indica que o sistema não é previsível. E previsibilidade é um requisito básico de sistemas confiáveis.

---

Integração Contínua (CI): reduzindo o custo do erro

Integração Contínua, ou CI, é o processo no qual toda mudança de código é automaticamente verificada assim que entra no repositório principal do projeto. Isso significa que, sempre que alguém envia código novo, o sistema testa se ele compila, se os testes passam e se não quebra regras básicas do projeto.

CI significa integrar pequenas mudanças com frequência, validando automaticamente se o sistema continua íntegro.

Na prática, CI envolve:

• build automático a cada mudança;
• testes executados continuamente;
• feedback rápido para quem escreve código.

---

Continuous Delivery vs. Continuous Deployment

Esses dois termos são usados como sinônimos, mas não são.

Continuous Delivery

Continuous Delivery, ou entrega contínua, significa que o sistema está sempre em um estado em que pode ser colocado em produção sem improviso. O código já passou por testes, já foi empacotado e já está pronto para rodar no ambiente final. A diferença é que alguém ainda decide quando o deploy acontece.

Continuous Deployment

Continuous Deployment não envolve decisão humana para o deploy. Toda mudança que passa pelo processo de validação é automaticamente publicada em produção.

Ambos exigem:

• pipelines confiáveis;
• testes consistentes;
• ambientes previsíveis.

Pretendo trazer exemplos práticos de CI/CD; é um dos termos mais difíceis de entender caso você não esteja familiarizado na área.

---

SLA, SLO e SLI: confiabilidade sem discurso vazio

Quando um sistema está em produção, ele passa a ter usuários reais. Esses usuários não se importam com arquitetura, ferramentas ou pipelines. Eles se importam com duas coisas: se o sistema funciona e se ele responde em tempo aceitável.

• SLI (Service Level Indicator) – uma medida concreta do comportamento do sistema (tempo de resposta de uma API, taxa de erro, porcentagem de disponibilidade, etc.).
• SLO (Service Level Objective) – a meta que o time define a partir desse número (ex.: 99,9 % das requisições devem ser atendidas dentro de 200 ms).
• SLA (Service Level Agreement) – o acordo formal com o cliente que especifica as consequências caso o SLO não seja cumprido.

# SLA e Ferramentas de Infraestrutura

**SLA** é o acordo formal com o usuário ou cliente. Ele normalmente deriva do **SLO**, mas é mais conservador.  
Se o SLA não é cumprido, há consequência real, como multa, crédito ou quebra de contrato. Por isso, ninguém define SLA sem antes entender muito bem seus **SLIs** e **SLOs**.

---

Ferramentas: contexto, não protagonismo

Neste episódio, as ferramentas aparecem apenas como pano de fundo; cada uma será explorada em profundidade nos próximos episódios:

• Git – base do versionamento
• Ferramentas de CI/CD – executoras de pipeline
• Cloud – abstração de infraestrutura

Este primeiro episódio teve um objetivo claro:

organizar a linguagem antes de discutir ferramentas.

Sem esse alicerce, qualquer conversa sobre Docker, Kubernetes ou Cloud vira ruído técnico.
Com ele, decisões passam a ter contexto.