Tudo sobre engenharia de plataforma: por que ela é necessária, como construí-la e o que é sucesso

• Como uma disciplina organizacional que constrói e opera produtos internos tendo engenheiros internos como usuários, é uma área essencialmente diferente de um simples rebranding de DevOps ou da gestão de clusters Kubernetes
• Segundo o relatório DORA 2025, 90% das organizações adotaram pelo menos uma plataforma interna, e a qualidade da plataforma surgiu como um indicador que prevê diretamente se as ferramentas de IA geram valor ou não
• À medida que a nuvem e o open source oferecem primitivos infinitos, sua razão de existir central é resolver o problema do "pântano da generalização excessiva (over-general swamp)", em que cada equipe constrói pipelines à sua maneira
• Tratar a plataforma como um produto de verdade e ter abstrações de software para o desenvolvedor mediano, um registro de metadados e SLOs operacionais são condições estruturais para o sucesso
• Uma boa plataforma funciona de forma tão natural que o desenvolvedor esquece que ela existe, e uma plataforma ruim faz as ferramentas de IA amplificarem a confusão, enquanto uma boa amplifica a vazão

---

Por que a engenharia de plataforma existe

• O pântano da generalização excessiva (Over-General Swamp)

  • Como a nuvem e o OSS oferecem primitivos infinitos como filas, object storage, bancos de dados, runners de CI e service mesh, cada equipe de aplicação acaba fazendo escolhas diferentes
  • Um ano depois, tudo degenera em um pântano de código cola, em que cada serviço tem seu próprio pipeline de deploy, lógica de retry, convenções de monitoramento e bindings de IAM sutilmente errados
  • As duas causas desse pântano são a explosão de opções e expectativas operacionais mais altas (funcionamento 24/7, segurança, compliance e gestão de custos)
  • Em um projeto real de landing zone, houve um caso em que 20 equipes reinventaram separadamente módulos Terraform quase idênticos para VPC, IAM e alertas de orçamento, cada um com bugs diferentes

• Quatro coisas que a engenharia de plataforma realmente faz

  • Restringe os primitivos que o desenvolvedor vê, induzindo o uso apenas de formas curadas
  • Absorve trabalhos repetitivos de encanamento em serviços compartilhados para reduzir o código cola por aplicação
  • Quando os primitivos subjacentes mudam, a equipe de plataforma resolve isso uma vez só, centralizando o custo de migração
  • Permite que os desenvolvedores operem diretamente aquilo que construíram sem precisar se tornar especialistas em kernel Linux
  • DevOps era “o desenvolvedor deve assumir a operação”, e engenharia de plataforma é “vamos fornecer boas ferramentas para essa operação como um produto de verdade”
  • Na página de capacidades do DORA 2025, ela também é definida como uma disciplina sociotécnica, e não como uma categoria de ferramenta

Cinco pilares (Pillars)

• Abordagem de produto curada (Curated Product Approach)

  • Decidir com intenção o que a plataforma suporta e o que não suporta
  • Quando uma equipe quer Kafka em vez de Pub/Sub, em vez de dizer “aqui está o link da documentação”, orientar sobre “o escopo de suporte, por que ele existe e qual é a saída se não servir”
  • Dizer não também faz parte do trabalho

• Abstrações baseadas em software (Software-Based Abstractions)

  • A plataforma é software, não uma wiki, e sua interface é API, CLI e SDK
  • O desenvolvedor deve conseguir provisionar um serviço pronto para produção apenas escrevendo um pequeno arquivo declarativo
  • O projeto Score, sob a CNCF, é um caso representativo: com uma única especificação de workload, ele provisiona automaticamente banco de dados, tópico, conta de serviço e deploy
    • O desenvolvedor não precisa saber se, internamente, é Cloud SQL, Pub/Sub ou Cloud Run

• Customização de OSS e registro de metadados

  • Em vez de usar Argo CD ou Backstage puros, a operação aplica plugins, políticas padrão e integrações adequadas à organização
  • Sem um registro de metadados (catálogo de serviços), fica impossível saber quem é dono de quê, como estão as dependências e o que de fato está rodando
  • O Backstage é o framework OSS padrão de fato dessa camada, operado em produção por mais de 270 organizações
    • A CNCF lançou as certificações Certified Backstage Associate e Certified Cloud Native Platform Engineering Associate
    • Seja usando Backstage, Port ou Cortex, é preciso uma fonte única da verdade (single source of truth) sobre “quais serviços existem, quem é dono deles e quais são suas dependências”

• Serviço para uma base ampla de usuários

  • Plataformas internas têm um pequeno número de clientes muito barulhentos, mas o objetivo é dar bom suporte ao trabalho mediano do desenvolvedor mediano
  • Se for construída apenas para usuários de elite, o restante das equipes vai contornar a plataforma, criando uma plataforma sombra

• Operar como fundação

  • Se a plataforma cai, a empresa cai, então isso traz consigo plantão 24/7, SLOs reais, gestão de mudanças real e carga de suporte
  • Ela não é uma “ferramenta”, mas sim o “piso (floor)”, assumido como resistente por tudo o que é construído em cima

Quando e como começar

• Não crie uma equipe de plataforma cedo demais

  • Em uma escala de 10 engenheiros, o que é necessário não é uma equipe de plataforma, mas cooperação
    • Basta uma pessoa cuidar dos scripts de deploy, outra do Terraform e todos concordarem com convenções
  • Se a equipe for formada cedo demais com 1 ou 2 pessoas, elas viram uma fila de tickets e o resto da organização se torna passivo
  • Em geral, depois de 50 engenheiros, quando surgem vários alvos de deploy e ninguém mais sabe qual é a resposta certa para “como fazer o deploy de um novo serviço”, é o momento adequado para formar a equipe

• Transformar a organização de infraestrutura existente

  • Ao transformar uma equipe de infraestrutura/SRE em uma organização de plataforma, a parte mais difícil não é a tecnologia, mas a cultura
  • Profissionais de infraestrutura estão acostumados ao papel de gatekeeper do “não pode”, mas profissionais de plataforma precisam se tornar “quem oferece um sim fácil”
    • Conversar muito com os clientes
    • Contratar e desenvolver engenheiros de software que gostem de construir ferramentas, não apenas operadores
    • Atualizar o sistema de incentivos para que “deixamos 200 equipes 5% mais rápidas” seja mais reconhecido do que “fizemos o deploy de um novo cluster”
  • O modo de falha mais comum é colocar um PM por cima e achar que está resolvido; isso produz teatro, não plataforma

Construindo a equipe de plataforma

• Quatro funções

  • Software Engineer: constrói a superfície de produto da plataforma, como APIs, SDKs e portais
  • Systems Engineer: domina os primitivos subjacentes, como Kubernetes, Linux, redes e cloud control planes
  • Reliability Engineer: foca na qualidade operacional, plantão, SLOs e observabilidade
  • Systems Specialist: especialista profundo em domínios como banco de dados, segurança e redes
  • Se o foco em software for excessivo, um portal bonito desmorona sob carga real; se o foco em sistemas for excessivo, temos um cluster sólido que ninguém consegue usar sem abrir ticket

• Contratação

  • Empatia com o cliente (customer empathy) deve ser o principal critério de contratação
  • Um engenheiro que, após uma ligação com um desenvolvedor de aplicação frustrado, não consegue sair com um entendimento claro do problema não é adequado
  • Excelência técnica sem empatia cria uma plataforma correta, mas que ninguém usa
  • Para funções de software, use a mesma matriz de níveis, mas para especialistas de sistemas, como o valor de mercado e as habilidades não se mapeiam perfeitamente para a carreira de engenheiro de software, permita títulos flexíveis

• Gestores e outras funções

  • Três características em comum de um ótimo gestor de engenharia de plataforma: experiência real operando plataforma, experiência em entregar projetos de longo prazo que atravessam vários trimestres e obsessão por detalhes
    • Plataformas recompensam os detalhes, e os casos de 1% que parecem raros e são ignorados acabam consumindo 80% do tempo de suporte
  • PM, redator técnico, developer advocate e engenheiro de suporte são todos importantes, mas só devem ser contratados depois que a equipe de engenharia estiver madura o suficiente
  • Um PM colocado cedo em uma equipe de plataforma de 4 pessoas acaba sendo apenas uma cadeira em formato de roadmap

Plataforma como produto

• O cliente interno é mais difícil

  • O cliente interno é um usuário cativo para quem é difícil abandonar a plataforma, com opiniões fortes e fraca sensibilidade de produto
  • Ele diz o que quer (want), mas muitas vezes isso é diferente do que realmente precisa (need)
  • Exige que a plataforma faça o trabalho por ele, em vez de pedir ferramentas para fazer melhor o próprio trabalho
  • O backlog real está em sentar ao lado dessas pessoas e observar quantas trocas de contexto elas fazem para implantar uma única mudança

• Discovery, roadmap e modos de falha

  • O discovery de plataforma é feito com pilotos, não com testes A/B, usando times parceiros e medindo a redução do lead time após implantações reais
  • Os quatro horizontes de tempo do roadmap
    • Vision (multiannual): a direção da plataforma
    • Strategy (anual): as apostas do ano
    • Goals and Metrics (trimestral a anual): a definição de sucesso
    • Milestones (trimestral): o que realmente será entregue
  • Modos de falha que frequentemente derrubam equipes
    • Subestimar o custo de migração (sempre 2 a 3 vezes maior que o esperado)
    • Superestimar o orçamento de mudança dos usuários para novas funcionalidades
    • Focar em adicionar funcionalidades quando o problema real é estabilidade
    • Ter PMs demais para o tamanho do time de engenharia (2 PMs para 5 engenheiros é um problema)

Operação da plataforma

• On-call não é opcional

  • Como é operada como fundação, a cobertura 24/7 é inegociável
  • O princípio "you build it, you run it" também vale aqui, e isso não é punição, mas um ciclo de feedback
  • Se um único engenheiro recebe páginas mais de algumas vezes por semana, é preciso corrigir o sistema, não a escala
  • Engenheiro de plataforma esgotado entrega plataforma ruim

• Suporte: a metade oculta do trabalho

  • É uma área quase nunca tratada em conferências, mas representa a metade central da engenharia de plataforma
  • Framework em quatro etapas
    • Etapa 1: formalizar níveis de suporte (P0 vs P3, tempos de resposta etc.)
    • Etapa 2: separar suporte não crítico do on-call para que perguntas como "como adicionar um CronJob" não acordem alguém
    • Etapa 3: quando o volume justificar, contratar especialistas dedicados de suporte
    • Etapa 4: montar uma organização de suporte de engenharia compatível com a escala
  • Se você pular a etapa 1, os engenheiros passarão metade do tempo respondendo DMs no Slack e a outra metade reclamando

• Feedback operacional

  • SLO e SLA são obrigatórios; error budgets são úteis, mas opcionais
  • O monitoramento sintético captura modos de falha antes que os usuários abram tickets
  • Revisões operacionais não servem para dar uma olhada rápida em dashboards verdes, mas para forçar a revisão de dados reais
  • Nos dados do DORA 2025, a capacidade de plataforma com maior correlação com experiência do usuário foi feedback claro sobre o resultado do trabalho — em caso de falha, o usuário precisa saber exatamente o que falhou e o que fazer

Planejamento e entrega

• Projetos de longo prazo exigem documento de proposta

  • Projetos de plataforma como migrações, rearquiteturas e novos control planes levam trimestres
  • Elementos essenciais de uma boa proposta: o problema a ser resolvido, quem será beneficiado, o escopo, o que está explicitamente fora de escopo e a definição de sucesso
  • Antes de escrever código, escreva e revise o documento, depois converta isso em um plano de execução com marcos concretos
  • O modo de falha do "long slog" — quando o projeto se arrasta por anos e ninguém mais lembra por quê — é quase sempre resultado de pular essa etapa

• Planejamento de roadmap bottom-up

  • Os quatro tipos de trabalho no roadmap de plataforma: KTLO (keep-the-lights-on), determinações da liderança, melhorias de sistema decididas internamente e solicitações diretas de clientes
  • Não dá para priorizar só pela demanda do cliente: KTLO vem em primeiro, determinações em segundo, e o resto exige discussões francas com stakeholders

• Resultados e desafios quinzenais (Biweekly Wins and Challenges)

  • A cada duas semanas, escrever um documento curto: o que foi entregue (resultados), o que travou (desafios), de forma breve, pública e sem exageros
  • Três efeitos simultâneos: o time articula claramente o progresso, os stakeholders recebem a situação real, e os desafios aparecem cedo para estimular apoio da liderança
  • Um documento com apenas resultados é um documento em que ninguém confia, então não omita os desafios

Rearquitetura e migração

• Rearquitetura em vez de v2

  • Quando a plataforma envelhece, o impulso de dizer "vamos fazer uma v2" é quase sempre a resposta errada
  • Motivos de fracasso de projetos v2: congelamento dos investimentos na v1, prazo maior que o previsto e custo de migração para a v2 maior que o custo de rearquitetura que se tentou evitar
  • Rearquiteture dentro da plataforma existente, mantendo compatibilidade sempre que possível e usando ambientes inferiores, rollout lento e migração por tranches
  • Quatro etapas de planejamento
    • Pensar grande sobre o objetivo final da arquitetura
    • Considerar o custo de migração (sempre 2 a 3 vezes maior)
    • Identificar resultados principais em 12 meses que justifiquem o investimento contínuo
    • Garantir o acordo da liderança e estar pronto para esperar

• Segurança é arquitetural

  • É impossível acrescentar segurança depois; a arquitetura precisa impor menor privilégio, isolamento e rastreabilidade desde o design
  • Se a plataforma depende de todo time lembrar os bindings corretos de IAM, o problema não está nos times, mas na plataforma

• Migração: um problema difícil e subestimado

  • Antipadrões mais comuns
    • Dar a cada time uma área de transferência e um prazo e mandar que migrem por conta própria
    • Só impor a ordem sem um on-ramp e um off-ramp claros
    • Subestimar a cauda longa dos casos de uso peculiares
  • Formas de facilitar a engenharia de migração
    • Rastrear metadados de uso para identificar exatamente quem ainda usa a versão antiga
    • Se 200 times precisam migrar, quem deve escrever os scripts é o time de plataforma, não os times de aplicação
    • Projetar uma arquitetura de migração transparente em que o novo sistema use a API antiga
    • Documentar claramente o on-ramp para que novos times consigam fazer self-service
  • Mandatos só funcionam uma ou duas vezes; depois disso, viram ruído
  • Na maioria dos casos, o melhor é tornar o novo caminho bom o bastante para que o caminho antigo definhe naturalmente

• Descontinuação (Sunsetting)

  • Não tenha medo de eliminar produtos
  • Um sistema de deploy robusto é melhor do que sete sistemas de deploy meio suportados; descontinuar é característica de times maduros

Relações com stakeholders

• Matriz poder-interesse (Power-Interest Grid)

  • Mapear stakeholders em dois eixos: poder (power) e interesse (interest)
    • Alto poder, alto interesse: atualizações regulares e alinhamento
    • Baixo poder, baixo interesse: uma página de status basta
  • Não desperdice tempo do time informando upgrades de Kubernetes a um VP com pouco interesse

• Comunicação sem oversharing

  • Seja transparente, mas sem exagero — líderes seniores não precisam acompanhar discussões sobre três estratégias de retry de gRPC, e sim saber se os marcos estão sendo atingidos e quais são os riscos
  • Use reuniões 1:1 com cuidado e acompanhe expectativas e compromissos em um lugar visível

• Dizer não sem arruinar relacionamentos

  • Deixe o impacto de negócio claro, como em "se adicionarmos essa funcionalidade, a migração atrasa um trimestre, o que custa $X para a empresa"
  • "Sim, com concessões", "não, mas com um caminho alternativo" e, às vezes, permitir uma shadow platform pode custar menos do que brigar
  • Na temporada de orçamento, apresente agrupamentos por time e capacidade, não por pessoa, e tenha opinião forte sobre o que reduzir e o que manter — caso contrário, o financeiro decidirá por você, e decidirá mal

Como é o sucesso

• Plataforma alinhada (Aligned)

  • É necessário alinhamento de propósito (por que ela existe), alinhamento estratégico (as apostas são consistentes entre as equipes) e alinhamento de planejamento (sem conflito entre marcos)
  • Ocorre desalinhamento quando todas as equipes de runtime querem Kubernetes e a equipe de observabilidade tenta dar suporte a todos os frameworks
    • Isso se manifesta em guias conflitantes para clientes, trabalho duplicado e desenvolvedores irritados presos no meio
    • Resolve-se não com consenso, mas com liderança baseada em princípios

• Plataforma confiável (Trusted)

  • A confiança é construída lentamente e pode ser perdida com uma única migração ruim
  • A confiança se forma na forma de operar (comunicação durante incidentes, cumprimento de promessas), na forma de investir (implantar de fato as grandes apostas vendidas) e nas prioridades de entrega
  • Exemplo de "plataforma superacoplada (overcoupled platform)": colocar lógica customizada demais na plataforma faz com que toda mudança leve meses — a solução não é mais engenharia, e sim questionar as premissas sobre o escopo
    • Às vezes, o problema de confiança não vem de fazer de menos, mas de fazer demais

• Plataforma que gerencia a complexidade

  • A complexidade de software é inevitável, mas a complexidade acidental (accidental complexity) não é
  • É preciso distinguir entre a complexidade intrínseca do problema, a má coordenação humana, plataformas paralelas criadas nas sombras para resolver o mesmo problema duas vezes e a complexidade acidental gerada por crescimento infinito
  • Três alavancas práticas
    • Controlar o crescimento: uma plataforma que suporta tudo não suporta nada bem; explicite o escopo
    • Usar product discovery não só para decidir o que adicionar, mas também o que descontinuar
    • Gerenciar shadow platforms: quando equipes criam soluções em paralelo, isso sinaliza que falta algo real na plataforma ou que alguém está expandindo demais o domínio — ambos exigem resposta

• Plataforma amada (Loved)

  • Três formas
    • Amor do tipo "simplesmente funciona": a maioria dos usuários nem percebe a plataforma, os deploys acontecem, o CI passa — ser entediante é o maior elogio
    • Amor do tipo "parece mágica": pequenas alegrias, como um comando de CLI que faz a coisa obviamente certa sem exigir explicação
    • Amor do tipo "evidente": pontuação em pesquisas, retenção, adoção orgânica e recomendação da plataforma para outras equipes
  • Quando a plataforma é amada, as pessoas brigam por ela na hora de pedir orçamento; quando ela é apenas tolerada, um único incidente ruim já a coloca em risco de substituição

Prioridades práticas

• Ordem aproximada ao começar do zero ou reconstruir
  • Prioridade 1: definir, documentar e defender o escopo de suporte
  • Prioridade 2: investir em abstrações de software, não em wiki (Score, Crossplane, SDK próprio etc.; software com APIs reais)
  • Prioridade 3: construir um registro de metadados (com Backstage etc. para saber o que roda onde e quem é o responsável)
  • Prioridade 4: construir para a equipe mediana, não para a equipe mais barulhenta
  • Prioridade 5: tratar operações como recurso de primeira classe, com SLO, on-call, níveis de suporte etc.
  • Prioridade 6: contratar com base em empatia tanto quanto em capacidade de sistemas
  • Prioridade 7: comunicação implacável, com resultados e desafios quinzenais, roadmap transparente e gestão honesta de stakeholders
  • Prioridade 8: encerrar, consolidar e recusar o que não é necessário
• Em linha com os dados do DORA, a qualidade da plataforma é um multiplicador de tudo, inclusive da adoção de IA — uma plataforma ruim faz as ferramentas de IA amplificarem o caos; uma boa plataforma amplifica o throughput
• É preciso construir o chão antes de construir o foguete

[kalista22]

Acho que a comunicação interna é mais importante do que qualquer outra coisa.