Platform Engineering: onde DevOps e SRE se encontram

1. O problema: cada time reinventa a roda

Uma empresa tem dez times de desenvolvimento. Cada um escolheu seu jeito de empacotar a aplicação, seu pipeline, seu monitoramento e seu passo a passo de deploy. Funciona, até que:

• uma falha de segurança aparece numa biblioteca e ninguém sabe quais dos dez jeitos usam essa biblioteca;
• uma pessoa troca de time e precisa reaprender tudo do zero;
• para criar um banco de teste, o time abre um ticket e espera uma semana.

O time não está errado. Ele só tem coisa demais para saber. Isso tem nome: carga cognitiva, o quanto uma pessoa precisa manter na cabeça para fazer o trabalho. Quando a carga é alta, sobra pouca energia para o produto.

2. DevOps: quem constrói também opera

Antes do DevOps, um time escrevia o código e outro colocava em produção. Os dois tinham metas opostas: um queria mudar rápido, o outro queria que nada mudasse. O DevOps propôs juntar os dois lados: o time que constrói também cuida do que roda, com automação para entregar mudanças pequenas e frequentes.

DevOps é, antes de tudo, cultura e prática. Não é cargo nem ferramenta. A pesquisa do DORA mostra que times que entregam em lotes pequenos, com testes automáticos e deploy automatizado, são ao mesmo tempo mais rápidos e mais estáveis.

3. SRE: confiabilidade com meta

O SRE (Site Reliability Engineering) nasceu no Google com uma pergunta simples: e se a operação fosse tratada como problema de engenharia? Em vez de "o sistema nunca pode cair", o SRE combina uma meta, o SLO, e aceita um pouco de falha, o error budget. Se a meta está sendo cumprida com folga, o time pode arriscar mais. Se não, a prioridade passa a ser estabilidade.

O SRE também mede o trabalho repetitivo e procura automatizá-lo. O toil aparece na parte 5 desta lição. O SLO e o error budget ficam para a etapa "Manter no ar" da trilha.

4. Platform Engineering: as duas ideias viram produto

Quando cada time precisa cuidar do próprio deploy e da própria confiabilidade, cada um monta tudo sozinho. Platform Engineering resolve isso com uma plataforma interna: um conjunto de ferramentas, serviços e caminhos prontos que os times usam por conta própria.

Três ideias definem uma boa plataforma:

• Self-service. O time cria um serviço, um banco ou um ambiente sozinho, em minutos, sem esperar outra pessoa.
• Caminhos prontos. O jeito recomendado já vem com segurança, observabilidade e deploy configurados. São os golden paths.
• Produto interno. A plataforma tem clientes, os times de desenvolvimento, e só existe porque ajuda esses clientes. O white paper de plataformas da CNCF trata isso como ponto central.

5. Toil: o primeiro alvo

O livro de SRE do Google chama de toil o trabalho que é manual, repetitivo, automatizável, tático (reage ao que aparece), sem valor duradouro e que cresce junto com o serviço. Exemplos que você vai reconhecer:

• criar usuário de banco à mão, toda semana, seguindo uma lista;
• renovar certificado copiando arquivos entre servidores;
• responder no chat, pela décima vez, "como eu faço deploy?".

Mapear e automatizar o toil é uma das primeiras entregas de um time de plataforma, porque libera tempo de todo mundo e mostra valor rápido.

6. O que faz quem trabalha com plataforma

No dia a dia, quem trabalha com plataforma:

• conversa com os times para descobrir onde eles perdem tempo;
• escreve infraestrutura como código, pipelines e módulos reutilizáveis;
• mantém a base que roda tudo, como clusters, registries e observabilidade;
• escreve documentação e templates que outra pessoa entende sem ajuda;
• mede se a plataforma está ajudando, com números e com conversas.

Repare que a lista mistura técnica, produto e comunicação. Por isso esta trilha mistura as duas coisas.

7. Missão final