Cómo crear un equipo de Platform Engineering desde cero

Los equipos de plataforma suelen fracasar de una de dos maneras. Un grupo de operaciones cambia de nombre, conserva su cola de tickets y nada más cambia. O un equipo nuevo dedica su primer trimestre a instalar un portal que muestra el desorden de siempre con una interfaz más limpia.

Esta guía toma el otro camino: decide si necesitas un equipo de plataforma, pon por escrito de qué es responsable y de qué no, contrata a tres personas, construye un golden path de punta a punta y mide si acortó algo.

Señales de que necesitas un equipo de plataforma

Las señales son repetición y espera:

• La misma infraestructura existe en copias que divergen. Cada equipo mantiene su propio pipeline, Dockerfile, manifiestos y Terraform. Actualizar la imagen base se convierte en un merge request por repositorio, y algunos nunca se fusionan.
• Arrancar un servicio significa esperar. El código lleva un día; el namespace, los secretos, el registro DNS y el acceso al registry llevan semanas de peticiones a personas distintas.
• Las mismas preguntas aparecen cada semana. Cómo consigo una base de datos, por qué está atascado mi deploy, quién me puede dar acceso. Las respuestas viven en la cabeza de dos personas.
• Los ingenieros sénior de producto dedican tiempo real a la fontanería. Pregunta cuántas horas se fueron la semana pasada en pipelines y clusters, y multiplica por el número de equipos.
• Una auditoría necesita evidencia uniforme. ISO 27001, SOC 2 y NIS2 te piden demostrar que todos los servicios tienen los mismos controles, y hoy la única prueba es leer cada repositorio.

Para ponerle un número, toma el último cambio que tuvo que llegar a todos los servicios, como una actualización de la imagen base. Cuenta sus merge requests y los días hasta que el último llegó a producción. Un equipo de plataforma convierte eso en un solo cambio en un solo sitio.

Señales de que necesitas algo más pequeño:

• Uno o dos equipos de producto y un único desplegable. Necesitas un buen pipeline compartido y quizá un SRE más, no un equipo con charter.
• El dolor es "nadie sabe cómo", no "tarda demasiado". Es un problema de documentación. Escribe primero el runbook.
• El dolor son los incidentes y la carga de on-call. Eso es trabajo de fiabilidad: SLO, alertas, postmortems. Un equipo de plataforma no va a silenciar un pager ruidoso.

Escribe el charter antes de contratar

El charter es una página: de qué es responsable el equipo, de qué no y cómo contactarlo. Escrito primero, evita que el equipo se convierta en el destino de toda tarea sin dueño.

Empieza por una misión que un ingeniero de producto pueda comprobar: un equipo puede pasar de un repositorio vacío a un servicio en producción, observable y en el camino de despliegue estándar, sin abrir un ticket.

El equipo de plataforma es responsable de:

• Las plantillas de servicio, la definición del pipeline compartido y las imágenes base de contenedor, incluida su cadencia de parches.
• El camino de despliegue: el repositorio GitOps, el controlador GitOps y los add-ons del cluster de los que depende cada servicio.
• Los valores por defecto de observabilidad: scraping de métricas, envío de logs, exportación de trazas, y un dashboard y un conjunto de alertas estándar por servicio.
• La fiabilidad de la propia plataforma, con sus propios SLO y su propia rotación de on-call.

Igual de importante, no es responsable de:

• El código de las aplicaciones, sus alertas ni el on-call de los servicios de producto. Apoya en esos incidentes; no los dirige.
• La infraestructura puntual fuera del golden path. "¿Me puedes crear una VM?" se convierte en una conversación de backlog, no en un ticket resuelto en silencio.
• La elección de lenguaje o framework de cada equipo.
• El gasto cloud de un equipo de producto. La plataforma hace visible el coste por servicio; el equipo es dueño de la cifra.

Cierra con dónde van las peticiones y dónde vive el roadmap. Si traes ayuda externa en platform engineering, acierta primero con esta página: cada decisión posterior se contrasta con ella.

Las tres primeras contrataciones

No empieces con una persona. Un platform engineer en solitario se convierte en la cola de tickets casi de inmediato. Tres es el equipo más pequeño que puede poner a una persona de guardia para las interrupciones cada semana mientras las otras dos construyen.

1. 1Un lead que haya llevado sistemas en producción y sepa decir que no. Sénior, con soltura en Kubernetes, CI e infraestructura como código, y dispuesto a ser el product manager de la plataforma: entrevistas, roadmap, charter.
2. 2Un ingeniero de infraestructura. Clusters, redes, el controlador GitOps, Terraform u OpenTofu, secretos. La persona que hace fiable el camino.
3. 3Un ingeniero de developer experience que venga de un equipo de producto. Alguien que haya escrito servicios en tu lenguaje principal y haya sufrido el dolor como usuario. Construye la plantilla, la documentación y los scripts, y detecta lo que es fácil para un operador pero desconcertante para un desarrollador.

Hacer crecer el equipo desde dentro tiene una ventaja clara: un ingeniero que viene de un equipo de producto conoce el código y a las personas, y llega con credibilidad. El coste: ese equipo pierde a una persona sénior, y los hábitos de un equipo corren el riesgo de convertirse en el estándar de todos. Una opción intermedia es la rotación: ingenieros de producto pasan un ciclo en el equipo de plataforma y vuelven con contexto y feedback.

La plataforma mínima viable: un golden path de punta a punta

Elige tu tipo de servicio más común, normalmente una API HTTP en tu lenguaje principal, y construye un único camino para él, desde un repositorio vacío hasta producción. No se construye nada más hasta que un equipo real haya llegado a producción por ese camino.

El camino tiene cinco piezas: un repositorio plantilla, un pipeline compartido, un build de imagen, un despliegue GitOps y valores por defecto de observabilidad. Repartidas en dos repositorios:

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

El pipeline compartido vive en su propio repositorio, versionado con tags para que los equipos actualicen a propósito. Sus etapas son las mismas para todos los servicios: test, build de la imagen etiquetada con el SHA del commit, escaneo, push, y después kustomize edit set image en el directorio de staging del servicio, con su commit. La promoción a producción es un merge request que hace lo mismo en el directorio de producción, así que cada deploy deja un registro revisable y reversible. Para endurecer ese pipeline, consulta nuestra guía de un pipeline de CI/CD seguro con GitOps.

La pieza que elimina el ticket es un ApplicationSet. En lugar de una Application de Argo CD creada a mano por servicio, un único manifiesto convierte cada directorio bajo production/ en una aplicación desplegada:

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

Un segundo ApplicationSet hace lo mismo con staging/. En un entorno real, sustituye project: default por un proyecto de Argo CD que limite dónde puede desplegar cada servicio. Nuestra consultoría GitOps cubre a fondo esta estructura y el flujo de promoción.

La observabilidad viene de la plantilla. El handler expone /metrics y el ServiceMonitor lo recoge. La plantilla configura el SDK de OpenTelemetry a partir de las variables estándar OTEL_SERVICE_NAME y OTEL_EXPORTER_OTLP_ENDPOINT, que inyecta la plataforma. Los logs salen por stdout en JSON, y un dashboard y un conjunto de alertas asociados al nombre del servicio existen desde el primer deploy.

"Terminado" es una prueba, no una demo. En la prueba de onboarding sin intervención, un ingeniero de producto que nunca ha visto el camino pasa de cero a un deploy en producción mientras el equipo de plataforma mira sin tocar el teclado. Cada pregunta que hace es un hueco en la documentación o en la plantilla. Corrígelos y repite con otra persona.

¿No sabes qué camino pavimentar primero? Solicita una evaluación gratuita de platform engineering. Recorremos uno de tus servicios del commit a producción, cronometramos cada traspaso y cada espera por el camino, y te decimos qué golden path eliminaría la mayoría.

Gestiona la plataforma como un producto

Los desarrolladores son los clientes de la plataforma, y tienen una alternativa: hacerlo ellos mismos, como hacen hoy.

• Habla con los usuarios de forma periódica. Acompaña la primera semana de una nueva incorporación. Siéntate con un equipo mientras crea un servicio. Ofrece office hours semanales. Lee el canal de chat de la plataforma como investigación.
• Mantén un roadmap público. Ahora, después y más adelante, visible para todos, y además lo que rechazaste y por qué.
• Gánate la adopción. El camino pavimentado tiene que ser la forma más fácil de entregar. Los equipos pueden salirse, pero salirse significa asumir lo que la plataforma hacía por ellos: parches de la imagen base, mantenimiento del pipeline, el mecanismo de deploy. Cuando un equipo esquiva la plataforma, trátalo como un hallazgo sobre la plataforma.
• Escribe la política de deprecación antes de la primera deprecación. Anuncia con una fecha de retirada, mantén lo viejo y lo nuevo funcionando en paralelo durante un periodo de solapamiento, y entrega una guía de migración o, mejor, un merge request que haga la migración. Nunca retires algo de lo que dependa un servicio en producción sin el acuerdo de ese equipo.

Mídelo

Toma líneas base antes de que la plataforma entregue nada, o no podrás mostrar un después.

Las cuatro métricas clave de DORA (las métricas de entrega, no el reglamento europeo): frecuencia de despliegue, lead time de los cambios, tasa de fallo de los cambios y tiempo de recuperación del servicio. Con la estructura anterior, la mayoría sale de Git. Los deploys a producción por semana ISO son los commits que tocaron production/:

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

El lead time va desde un commit en el repositorio de un servicio hasta el commit de producción que lo desplegó; la etiqueta de la imagen es el SHA del commit, así que un script corto une ambos. La tasa de fallo es la proporción de commits de producción seguidos de un revert o un hotfix, o vinculados a un incidente. El tiempo de recuperación sale de tu herramienta de incidentes, de la apertura a la resolución.

Tiempo desde un repositorio nuevo hasta su primer deploy en producción. Compara el primer commit del repositorio del servicio con el primer commit en su directorio de producción:

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"

Tiempo de onboarding de un ingeniero nuevo. Días desde su fecha de incorporación hasta su primer cambio en producción: la fecha la da RR. HH.; el cambio, el primer commit con su email de autor que salió en un deploy de producción. Tras la primera semana, pregúntale qué le bloqueó.

Volumen de tickets al equipo de plataforma. Etiqueta cada petición con una categoría: acceso, infraestructura nueva, deploy roto, pregunta. Cuenta por categoría y por semana. Una categoría recurrente es candidata a autoservicio; una categoría que cae a cero después de automatizarla es tu evidencia.

Antipatrones

La cola de tickets rebautizada como "plataforma". Mismas personas, misma cola, nombre nuevo. Si la entrada son tickets y la salida son tickets cerrados, es un equipo de operaciones. La solución: trata cada categoría de ticket recurrente como un elemento de backlog cuyo objetivo es que ese ticket deje de ser necesario.

Un portal antes de cualquier golden path. Instalar Backstage primero cataloga cómo están las cosas hoy. Un portal es una puerta de entrada, y merece la pena construirlo cuando hay algo detrás. Como la plantilla ya incluye un catalog-info.yaml, el catálogo se llena solo cuando lo añadas. Después, la consultoría Backstage añade el catálogo y las plantillas sobre el camino que ya tienes.

Imponer la plataforma. Una imposición produce cumplimiento, no adopción. Los equipos siguen la norma sobre el papel, dejan de dar feedback y esconden sus atajos.

Una talla para todos. Los jobs batch, los pipelines de datos y las cargas con GPU no encajan en una plantilla de servicio HTTP. Pavimenta el camino común, documenta qué implica salirse de él y añade un segundo camino solo cuando varios equipos necesiten lo mismo.

Los primeros 90 días

Mes 1: charter, líneas base y el primer camino elegido.

• El charter, acordado con la dirección de ingeniería y publicado.
• Líneas base de las cuatro métricas de DORA, del tiempo de repositorio a producción, del tiempo de onboarding y de las categorías de tickets.
• Entrevistas con al menos un ingeniero por equipo de producto, y una lista priorizada de los traspasos en el camino a producción.
• Un equipo piloto que haya aceptado usar el primer golden path.

Mes 2: el camino construido y usado una vez.

• Repositorio plantilla, pipeline compartido con tags, imagen base, repositorio de deployments y ApplicationSets, dashboards y alertas por defecto.
• El equipo piloto lleva un servicio real a producción por el camino.
• La prueba de onboarding sin intervención hecha una vez, y los problemas encontrados corregidos.

Mes 3: el camino usado sin ayuda.

• Dos equipos más en el camino, incorporados solo con la documentación.
• Roadmap público y política de deprecación publicados, office hours en marcha.
• Una primera revisión frente a las líneas base, con las cifras tal como son, y una decisión sobre lo siguiente: un segundo camino, bases de datos en autoservicio o un portal.

Si estás a punto de formar un equipo de plataforma, o el tuyo se ha convertido en una cola de tickets, reserva una evaluación gratuita de platform engineering. Revisamos tu charter o te ayudamos a escribirlo, medimos tu tiempo actual de repositorio a producción e identificamos el primer golden path que merece la pena construir.