Como criar uma equipa de Platform Engineering do zero

As equipas de plataforma costumam falhar de uma de duas formas. Um grupo de operações muda de nome, mantém a fila de tickets e nada mais muda. Ou uma equipa nova passa o primeiro trimestre a instalar um portal que mostra a confusão de sempre numa interface mais limpa.

Este guia segue o outro caminho: decide se precisas de uma equipa de plataforma, escreve aquilo por que ela é responsável e aquilo por que não é, contrata três pessoas, constrói um golden path de ponta a ponta e mede se encurtou alguma coisa.

Sinais de que precisas de uma equipa de plataforma

Os sinais são repetição e espera:

• A mesma infraestrutura existe em cópias que divergem. Cada equipa mantém o seu pipeline, Dockerfile, manifestos e Terraform. Atualizar a imagem base passa a ser um merge request por repositório, e alguns nunca chegam a ser integrados.
• Arrancar um serviço significa esperar. O código demora um dia; o namespace, os segredos, o registo DNS e o acesso ao registry demoram semanas de pedidos a pessoas diferentes.
• As mesmas perguntas aparecem todas as semanas. Como arranjo uma base de dados, porque é que o meu deploy está parado, quem me pode dar acesso. As respostas vivem na cabeça de duas pessoas.
• Os engenheiros sénior de produto gastam tempo real em canalização. Pergunta quantas horas foram, na semana passada, para pipelines e clusters, e multiplica pelo número de equipas.
• Uma auditoria precisa de evidência uniforme. A ISO 27001, o SOC 2 e a NIS2 pedem-te que demonstres que todos os serviços têm os mesmos controlos, e hoje a única prova é ler cada repositório.

Para pôr um número nisto, pega na última alteração que teve de chegar a todos os serviços, como uma atualização da imagem base. Conta os merge requests e os dias até o último chegar a produção. Uma equipa de plataforma transforma isso numa só alteração num só sítio.

Sinais de que precisas de algo mais pequeno:

• Uma ou duas equipas de produto e um único artefacto para implementar. Precisas de um bom pipeline partilhado e talvez de mais um SRE, não de uma equipa com charter.
• A dor é "ninguém sabe como", não "demora demasiado". É um problema de documentação. Escreve primeiro o runbook.
• A dor são os incidentes e a carga de on-call. Isso é trabalho de fiabilidade: SLO, alertas, postmortems. Uma equipa de plataforma não vai calar um pager ruidoso.

Escreve o charter antes de contratar

O charter é uma página: aquilo por que a equipa é responsável, aquilo por que não é e como chegar até ela. Escrito primeiro, impede que a equipa se torne o destino de todas as tarefas sem dono.

Começa por uma missão que um engenheiro de produto possa testar: uma equipa consegue passar de um repositório vazio a um serviço a correr em produção, observável e no caminho de implementação padrão, sem abrir um ticket.

A equipa de plataforma é responsável por:

• Os modelos de serviço, a definição do pipeline partilhado e as imagens base de contentor, incluindo a cadência de patches.
• O caminho de implementação: o repositório GitOps, o controlador GitOps e os add-ons do cluster de que cada serviço depende.
• As predefinições de observabilidade: scraping de métricas, envio de logs, exportação de traces, e um dashboard e um conjunto de alertas padrão por serviço.
• A fiabilidade da própria plataforma, com os seus próprios SLO e a sua própria escala de on-call.

Igualmente importante, não é responsável por:

• O código das aplicações, os alertas das aplicações ou o on-call dos serviços de produto. Apoia nesses incidentes; não os conduz.
• Infraestrutura avulsa fora do golden path. "Podes só criar-me uma VM?" passa a ser uma conversa de backlog, não um ticket resolvido em silêncio.
• A escolha de linguagem ou framework de cada equipa.
• A despesa cloud de uma equipa de produto. A plataforma torna o custo visível por serviço; a equipa é dona do número.

Fecha com o sítio para onde vão os pedidos e onde vive o roadmap. Se trouxeres ajuda externa em platform engineering, acerta primeiro nesta página: todas as decisões seguintes são confrontadas com ela.

As três primeiras contratações

Não comeces com uma pessoa. Um platform engineer sozinho torna-se a fila de tickets quase de imediato. Três é a equipa mais pequena que consegue pôr uma pessoa de serviço às interrupções em cada semana enquanto as outras duas constroem.

1. 1Um lead que já tenha gerido sistemas em produção e saiba dizer que não. Sénior, à vontade com Kubernetes, CI e infraestrutura como código, e disposto a ser o product manager da plataforma: entrevistas, roadmap, charter.
2. 2Um engenheiro de infraestrutura. Clusters, redes, o controlador GitOps, Terraform ou OpenTofu, segredos. A pessoa que torna o caminho fiável.
3. 3Um engenheiro de developer experience vindo de uma equipa de produto. Alguém que já escreveu serviços na tua linguagem principal e sentiu a dor como utilizador. Constrói o modelo, a documentação e os scripts, e repara no que é fácil para um operador mas confuso para um programador.

Fazer crescer a equipa por dentro tem uma vantagem clara: um engenheiro vindo de uma equipa de produto conhece o código e as pessoas, e chega com credibilidade. O custo: essa equipa perde uma pessoa sénior, e os hábitos de uma equipa arriscam-se a tornar-se o padrão de todas. Uma opção intermédia é a rotação: engenheiros de produto passam um ciclo na equipa de plataforma e voltam com contexto e feedback.

A plataforma mínima viável: um golden path de ponta a ponta

Escolhe o teu tipo de serviço mais comum, normalmente uma API HTTP na tua linguagem principal, e constrói um único caminho para ele, de um repositório vazio até produção. Nada mais é construído até uma equipa real ter chegado a produção por esse caminho.

O caminho tem cinco peças: um repositório modelo, um pipeline partilhado, um build de imagem, uma implementação GitOps e predefinições de observabilidade. Distribuídas por dois repositórios:

service-template/                # copied once per new service
├── Dockerfile                   # multi-stage, non-root user, pinned base image
├── catalog-info.yaml            # owner and lifecycle, for a catalog later
├── README.md                    # run, test, deploy: in that order
├── (CI entry file)              # one include of the shared pipeline, pinned to a tag
├── src/                         # hello-world handler serving /healthz and /metrics
└── test/

deployments/                     # one repository, watched by Argo CD
├── staging/
│   └── orders-api/
└── production/
    └── orders-api/              # adding this directory is the deploy request
        ├── kustomization.yaml   # image tag, bumped by the pipeline
        ├── deployment.yaml      # probes, requests and limits, securityContext
        ├── service.yaml
        └── servicemonitor.yaml  # Prometheus scraping, on by default

O pipeline partilhado vive no seu próprio repositório, versionado com tags para que as equipas atualizem de propósito. As etapas são as mesmas para todos os serviços: testes, build da imagem com a tag do SHA do commit, scan, push e, por fim, kustomize edit set image no diretório de staging do serviço, com o respetivo commit. A promoção para produção é um merge request que faz o mesmo no diretório de produção, por isso cada deploy fica com um registo revisível e reversível. Para reforçar esse pipeline, lê o nosso guia de um pipeline de CI/CD seguro com GitOps.

A peça que elimina o ticket é um ApplicationSet. Em vez de uma Application do Argo CD criada à mão por serviço, um único manifesto transforma cada diretório em production/ numa aplicação implementada:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: services-production
  namespace: argocd
spec:
  goTemplate: true
  generators:
    - git:
        repoURL: https://git.example.com/platform/deployments.git
        revision: main
        directories:
          - path: production/*
  template:
    metadata:
      name: '{{.path.basename}}-production'
    spec:
      project: default
      source:
        repoURL: https://git.example.com/platform/deployments.git
        targetRevision: main
        path: '{{.path.path}}'
      destination:
        server: https://kubernetes.default.svc
        namespace: '{{.path.basename}}'
      syncPolicy:
        automated:
          prune: true
          selfHeal: true
        syncOptions:
          - CreateNamespace=true

Um segundo ApplicationSet faz o mesmo para staging/. Num ambiente real, substitui project: default por um projeto do Argo CD que limite onde cada serviço pode fazer deploy. A nossa consultoria GitOps cobre esta estrutura e o fluxo de promoção em profundidade.

A observabilidade vem do modelo. O handler expõe /metrics e o ServiceMonitor recolhe-o. O modelo configura o SDK do OpenTelemetry a partir das variáveis padrão OTEL_SERVICE_NAME e OTEL_EXPORTER_OTLP_ENDPOINT, que a plataforma injeta. Os logs saem para stdout em JSON, e um dashboard e um conjunto de alertas associados ao nome do serviço existem desde o primeiro deploy.

"Concluído" é um teste, não uma demo. No teste de onboarding sem intervenção, um engenheiro de produto que nunca viu o caminho vai do zero a um deploy em produção enquanto a equipa de plataforma observa sem tocar no teclado. Cada pergunta que faz é uma lacuna na documentação ou no modelo. Corrige-as e repete com outra pessoa.

Não sabes que caminho pavimentar primeiro? Pede uma avaliação gratuita de platform engineering. Percorremos um dos teus serviços do commit até produção, cronometramos cada passagem entre pessoas e cada espera pelo caminho, e dizemos-te que golden path eliminaria a maior parte delas.

Gere a plataforma como um produto

Os programadores são os clientes da plataforma, e têm uma alternativa: fazer eles próprios, como fazem hoje.

• Fala com os utilizadores de forma regular. Acompanha a primeira semana de alguém que acabou de entrar. Senta-te com uma equipa enquanto cria um serviço. Faz office hours semanais. Lê o canal de chat da plataforma como investigação.
• Mantém um roadmap público. Agora, a seguir e mais tarde, visível para todos, mais o que recusaste e porquê.
• Conquista a adoção. O caminho pavimentado tem de ser a forma mais fácil de entregar. As equipas podem sair dele, mas sair significa assumir o que a plataforma fazia por elas: patches da imagem base, manutenção do pipeline, o mecanismo de deploy. Quando uma equipa contorna a plataforma, trata isso como uma descoberta sobre a plataforma.
• Escreve a política de descontinuação antes da primeira descontinuação. Anuncia com uma data de remoção, mantém o antigo e o novo a funcionar lado a lado durante um período de sobreposição, e entrega um guia de migração ou, melhor, um merge request que faça a migração. Nunca removas algo de que um serviço em produção dependa sem o acordo dessa equipa.

Mede

Recolhe valores de referência antes de a plataforma entregar seja o que for, ou não vais conseguir mostrar um depois.

As quatro métricas-chave DORA (as métricas de entrega, não o regulamento europeu): frequência de implementação, lead time das alterações, taxa de falha das alterações e tempo de reposição do serviço. Com a estrutura acima, a maioria sai do Git. Os deploys em produção por semana ISO são os commits que tocaram em production/:

git -C deployments log --since="12 weeks ago" --date=format:'%G-W%V' \
  --format='%ad' -- production/ | sort | uniq -c

O lead time vai de um commit no repositório de um serviço até ao commit de produção que o implementou; a tag da imagem é o SHA do commit, por isso um script curto junta os dois. A taxa de falha é a proporção de commits de produção seguidos de um revert ou de um hotfix, ou ligados a um incidente. O tempo de reposição vem da tua ferramenta de incidentes, da abertura à resolução.

Tempo de um repositório novo até ao seu primeiro deploy em produção. Compara o primeiro commit no repositório do serviço com o primeiro commit no respetivo diretório de produção:

first_commit=$(git -C orders-api log --reverse --format=%cI | head -1)
first_deploy=$(git -C deployments log --reverse --format=%cI -- production/orders-api/ | head -1)
echo "$first_commit -> $first_deploy"

Tempo de onboarding de um engenheiro novo. Dias desde a data de entrada até à primeira alteração em produção: a data vem dos RH; a alteração, do primeiro commit com o email de autor dessa pessoa que saiu num deploy de produção. Ao fim da primeira semana, pergunta-lhe o que a bloqueou.

Volume de tickets para a equipa de plataforma. Etiqueta cada pedido com uma categoria: acesso, infraestrutura nova, deploy partido, pergunta. Conta por categoria e por semana. Uma categoria recorrente é candidata a autosserviço; uma categoria que desce a zero depois de a automatizares é a tua evidência.

Antipadrões

A fila de tickets rebatizada de "plataforma". As mesmas pessoas, a mesma fila, um nome novo. Se a entrada são tickets e a saída são tickets fechados, é uma equipa de operações. A solução: trata cada categoria de ticket recorrente como um item de backlog cujo objetivo é tornar esse ticket desnecessário.

Um portal antes de qualquer golden path. Instalar o Backstage primeiro cataloga a forma como as coisas estão hoje. Um portal é uma porta de entrada, e só vale a pena construí-lo quando há alguma coisa por trás. Como o modelo já inclui um catalog-info.yaml, o catálogo preenche-se sozinho quando o acrescentares. Depois, a consultoria Backstage junta o catálogo e os modelos por cima do caminho que já tens.

Impor a plataforma. Uma imposição produz cumprimento, não adoção. As equipas seguem a regra no papel, deixam de dar feedback e escondem os seus atalhos.

Um tamanho único para todos. Jobs batch, pipelines de dados e cargas com GPU não cabem num modelo de serviço HTTP. Pavimenta o caminho comum, documenta o que implica sair dele e acrescenta um segundo caminho só quando várias equipas precisarem do mesmo.

Os primeiros 90 dias

Mês 1: charter, valores de referência e o primeiro caminho escolhido.

• O charter, acordado com a liderança de engenharia e publicado.
• Valores de referência das quatro métricas DORA, do tempo de repositório a produção, do tempo de onboarding e das categorias de tickets.
• Entrevistas com pelo menos um engenheiro por equipa de produto, e uma lista ordenada das passagens entre pessoas no caminho para produção.
• Uma equipa piloto que tenha aceitado usar o primeiro golden path.

Mês 2: o caminho construído e usado uma vez.

• Repositório modelo, pipeline partilhado com tags, imagem base, repositório de deployments e ApplicationSets, dashboards e alertas predefinidos.
• A equipa piloto leva um serviço real a produção pelo caminho.
• O teste de onboarding sem intervenção feito uma vez, e os problemas encontrados corrigidos.

Mês 3: o caminho usado sem ajuda.

• Mais duas equipas no caminho, integradas só com a documentação.
• Roadmap público e política de descontinuação publicados, office hours a funcionar.
• Uma primeira revisão face aos valores de referência, com os números tal como estão, e uma decisão sobre o passo seguinte: um segundo caminho, bases de dados em autosserviço ou um portal.

Se estás prestes a formar uma equipa de plataforma, ou se a tua se transformou numa fila de tickets, marca uma avaliação gratuita de platform engineering. Revemos o teu charter ou ajudamos-te a escrevê-lo, medimos o teu tempo atual de repositório a produção e identificamos o primeiro golden path que vale a pena construir.