Dicionário do DevOps - Ep. 1

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 linguestica que torna 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 esse problemas). Isso cria um efeito colateral perigoso e 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 e ajudar iniciantes que queiram entrar na área.

Mas afinal, o que é DevOps?

DevOps é um modelo de organização do trabalho 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.

DevOps é um modelo de trabalho que surge da necessidade de resolver um problema clássico:

desenvolvimento 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é produção
• Automação: redução do erro humano e aumento de previsibilidade

Na prática, 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 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. Automação, dentro de DevOps, 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, 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:

• pipelines longos demais → processos burocráticos
• pipelines frágeis → ambientes inconsistentes
• pipelines manuais → falta de confiança no sistema

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 esse código compila, se os testes passam e se ele 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 existe 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 uns exemplos práticos de CI/CD, é um dos termos mais difícil 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): Um SLI é simplesmente uma medida concreta do comportamento do sistema. Pode ser o tempo de resposta de uma API, a taxa de erro de uma aplicação ou a porcentagem de tempo em que o serviço esteve disponível.

• SLO (Service Level Objective): Um SLO é a meta que o time define a partir desse número. Por exemplo, decidir que um serviço deve responder corretamente em 99,9% das requisições.

• SLA (Service Level Agreement): Um SLA é o acordo formal com o usuário ou cliente. Ele normalmente deriva do SLO, mas é mais conservador. Se o SLA não é cumprido, existe 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, ferramentas aparecem apenas como pano de fundo, cada uma será explorada em profundidade nos próximos episódios:

• Git como base do versionamento
• Ferramentas de CI/CD como executoras de pipeline
• Cloud como 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.