Planteamiento y alcance
Diseña una plataforma interna para desarrolladores para una organización con muchos servicios, equipos y entornos de despliegue. La plataforma debe facilitar las tareas de entrega comunes sin convertirse en una cola de tickets ni forzar a cada equipo a adoptar una única arquitectura.
Trata a los desarrolladores como clientes con diferentes cargas de trabajo. Backstage describe un catálogo de software que rastrea entidades como servicios, librerías y dominios; DORA recomienda combinar el rendimiento de entrega con señales de experiencia del desarrollador en lugar de utilizar un único número de productividad.
Qué está evaluando el entrevistador
Están evaluando el pensamiento de plataforma como producto, la segmentación, la priorización de flujos de trabajo, la gestión del cambio, la gobernanza y el diseño de métricas. Una respuesta sólida vincula una capacidad de la plataforma con un trabajo del desarrollador y un resultado medible, preservando al mismo tiempo una vía de escape para excepciones válidas.
Preguntas para aclarar antes de responder
- ¿Quién es el primer objetivo: nuevos equipos, ingenieros de guardia, propietarios de servicios o revisores de seguridad?
- ¿Qué tarea repetitiva es más costosa: bootstrapping, despliegue, descubrimiento de propiedad, observabilidad o evidencia de cumplimiento?
- ¿Cuántos lenguajes, runtimes, nubes y niveles de madurez se deben admitir?
- ¿Qué restricciones son obligatorias y dónde pueden los equipos optar por no participar?
- ¿El objetivo es una entrega más rápida, cambios más seguros, una incorporación más sencilla o una menor carga cognitiva?
Un marco de respuesta de 30 segundos
“Comenzaría con los equipos que crean servicios repetidamente y tienen dificultades para encontrar la propiedad y valores predeterminados de despliegue seguros. El MVP es un catálogo con propietarios claros, una plantilla de servicio de autoservicio, un camino de despliegue pavimentado y runbooks con capacidad de búsqueda. Los equipos pueden salir del camino con motivos documentados. Haría una prueba piloto con tres equipos representativos, mediría el tiempo hasta el primer cambio en producción, la recuperación de despliegues fallidos, el tiempo de incorporación, la finalización de tareas y la satisfacción del desarrollador, y luego expandiría solo donde la evidencia demuestre una reducción de la fricción.”
Análisis detallado paso a paso
Paso 1: Segmentar los trabajos de los desarrolladores
Entrevista por separado a propietarios de servicios, nuevas contrataciones, ingenieros de guardia y operadores de plataforma. Sus puntos de dolor difieren: descubrir una dependencia, crear un repositorio, enviar a producción de forma segura o demostrar un control. Utiliza flujos de trabajo observados y tickets de soporte, no solo solicitudes de funciones.
Paso 2: Mapear el camino dorado (golden path)
Elige un recorrido frecuente y de alto riesgo y define su entrada, valores predeterminados, aprobaciones y salida. Un camino dorado debe ser la ruta segura más fácil, no un mandato oculto. Documenta dónde los equipos pueden personalizar o salir.
Paso 3: Construir el catálogo útil más pequeño
Comienza con la propiedad, el ciclo de vida, las dependencias críticas, los enlaces al despliegue y los runbooks, e indicadores de actualización. El modelo de catálogo de Backstage utiliza entidades y metadatos; exige un propietario y un archivo fuente para que los registros no se conviertan en un directorio sin mantenimiento.
Paso 4: Añadir acciones de autoservicio
Ofrece plantillas para el siguiente cuello de botella: crear un servicio, añadir CI estándar, solicitar un entorno o habilitar la observabilidad. Cada acción debe mostrar los requisitos previos, el tiempo estimado, el resultado y una ruta de recuperación cuando la automatización falle.
Paso 5: Diseñar la gobernanza como barandillas (guardrails)
Automatiza los valores predeterminados de seguridad y confiabilidad, pero separa la política de la implementación. Una plataforma puede bloquear un despliegue riesgoso con una razón explicable y un flujo de trabajo de excepción; no debe reescribir silenciosamente el código del equipo ni ocultar la propiedad.
Paso 6: Planificar la adopción y la migración
Recluta socios de diseño, migra un servicio real de extremo a extremo, publica ejemplos y ofrece horarios de consulta (office hours). Realiza un seguimiento del esfuerzo de migración y deja documentadas las rutas heredadas. La adopción ganada mediante una menor fricción es más duradera que un mandato sin soporte.
Paso 7: Definir la confiabilidad de la plataforma
Asigna a la plataforma sus propios SLO: actualización del catálogo, éxito de las plantillas, disponibilidad del flujo de trabajo de despliegue y respuesta a incidentes. Una plataforma interna rota se convierte en una dependencia de producción, por lo que debes proporcionar estado, reversión (rollback) y propiedad del soporte.
Paso 8: Medir resultados y barandillas
Utiliza métricas de entrega como la frecuencia de despliegue y el tiempo de recuperación de despliegues fallidos junto con medidas a nivel de tarea como el tiempo para crear un servicio, el tiempo hasta el primer despliegue, la finalización de autoservicio y los tickets de soporte. Añade encuestas a desarrolladores y barandillas para fallos en cambios, incidentes de plataforma e impacto desigual entre equipos.
Compensaciones y límites
Compensación 1: Estandarización o autonomía
Los valores predeterminados estándar reducen la carga cognitiva; la autonomía preserva la adaptación del equipo. Estandariza primero las interfaces y los controles de seguridad, y permite elecciones de implementación detrás de ellos.
Compensación 2: Construir o integrar
Construye solo el flujo de trabajo o la política que sea diferenciadora. Integra los sistemas existentes de catálogo, CI, secretos y observabilidad cuando cumplan con el contrato; cada integración se convierte en parte de la superficie de confiabilidad de la plataforma.
Compensación 3: Más funciones o mejor finalización
Un catálogo con veinte plugins que funcionan a medias crea más fricción que un pequeño conjunto de acciones confiables. Prioriza la finalización de tareas de extremo a extremo sobre la cantidad de funciones.
Simulacros de fallas y plan de evolución
Simulacro 1: Una plantilla falla a mitad de camino
Muestra al usuario qué se creó, cómo reintentar de forma segura y quién es el responsable de la limpieza. Haz que las acciones sean idempotentes siempre que sea posible y expón los logs sin requerir acceso de administrador de plataforma.
Simulacro 2: Los equipos eluden el camino dorado
Entrevístalos antes de etiquetarlo como incumplimiento. Es posible que al camino le falte un caso de uso legítimo, tenga valores predeterminados deficientes o imponga un costo de migración oculto. Mejora el recorrido y documenta las salidas justificadas.
Simulacro 3: Una interrupción de la plataforma bloquea los lanzamientos
Prueba el funcionamiento degradado, la comunicación de estado y una alternativa manual. La plataforma debe reducir el riesgo operativo, no convertirse en un punto único de falla opaco.
Errores comunes y seguimiento
Error 1: Tratar el portal como una página de inicio
Los enlaces por sí solos no eliminan el trabajo. Identifica una tarea y proporciona un resultado de autoservicio.
Error 2: Medir líneas de código o clics
Esos son recuentos de actividad, no resultados de producto. Combina los datos de entrega con la finalización de tareas y las señales de experiencia del desarrollador.
Error 3: Imponer una sola pila tecnológica (stack)
Un contrato de plataforma puede admitir múltiples runtimes. Explica qué restricciones tienen que ver con la seguridad y cuáles son meras preferencias.
Error 4: Ignorar la propiedad de los metadatos
Un catálogo desactualizado perjudica la respuesta a incidentes. Exige propietarios, metadatos controlados por versiones de código fuente, comprobaciones de actualización y una ruta de escalamiento.
Error 5: Migrar a todos los equipos primero
Comienza con socios de diseño y un recorrido medible. Una migración amplia antes de la validación genera resistencia y oculta brechas de usabilidad.
Error 6: Olvidar que la plataforma es software de producción
Establece SLO, propiedad de incidentes, controles de lanzamiento y rutas de reversión para la plataforma misma.