Planteamiento y contexto
Esta pregunta de diseño de sistemas de plataforma aborda el almacenamiento de componentes, sistemas, dominios, APIs, propietarios y aristas de dependencia a partir de repositorios, sistemas de despliegue y declaraciones humanas. Sirve para el descubrimiento, la respuesta a incidentes y la gobernanza; no debe convertirse en otra CMDB mantenida a mano en la que nadie confíe.
Qué evalúa el entrevistador
- Transformar la necesidad de "encontrar al propietario del servicio" en un modelo de entidades, una política de confianza de fuentes y una experiencia de búsqueda.
- Manejar conflictos, expiración y eliminación entre metadatos declarativos y escaneos automatizados.
- Explicar consultas de dependencias, aislamiento de permisos, límites de inquilinos (tenants) y SLOs de frescura.
- Elegir un despliegue progresivo de la plataforma que equilibre el valor con el costo de mantenimiento.
Preguntas de aclaración para hacer
Confirma la cantidad de entidades, el volumen diario de cambios, el retraso de metadatos, los picos de consultas, el aislamiento por organización o cliente, si las dependencias son estáticas o se observan en tiempo de ejecución, y quién puede declarar la titularidad. El uso en incidentes de alto riesgo requiere niveles de fuentes, marcadores de datos obsoletos y auditoría; un directorio para desarrolladores puede comenzar con requisitos de frescura más flexibles.
Estructura de respuesta en 30 segundos
Modelaría un grafo declarativo de entidades: los componentes, sistemas, dominios, APIs, equipos y relaciones tienen identidades estables. Los archivos de catálogo en los repositorios proporcionan la intención; las señales de despliegue y de tiempo de ejecución añaden versiones y aristas observadas; los recolectores escriben eventos versionados. Un servicio de consultas sirve propietarios, dependencias inversas y búsquedas mientras muestra la fuente y la hora de actualización. Los conflictos se convierten en un estado accionable en lugar de sobreescrituras silenciosas. Los permisos se aplican a entidades y campos, y las entidades obsoletas se conservan como históricas pero desaparecen de los resultados predeterminados.
Respuesta detallada paso a paso
1. Modelar entidades y relaciones
El modelo de entidades de Backstage es una referencia útil: los componentes pertenecen a sistemas, los sistemas a dominios, las APIs son provistas o consumidas por componentes, y los equipos son propietarios de los componentes. Asigna a cada entidad un nombre estable, un espacio de nombres (namespace) y una clave de versión. Las aristas de relación llevan la fuente, la hora de descubrimiento y el nivel de confianza. La titularidad debe hacer referencia a un principal de equipo resoluble, no a texto libre, para que el enrutamiento de incidentes pueda automatizarse.
2. Establecer capacidad y SLOs
Asume 10,000 entidades con 20 relaciones cada una, aproximadamente 200,000 aristas y un 5% de cambios diarios en las entidades, alrededor de 500 importaciones. Escribe a través de una cola de eventos y mantén un modelo de lectura con índices de propietarios y de adyacencia. Un objetivo inicial podría ser la visibilidad de la importación en cuestión de minutos, un P95 de búsqueda inferior a 300 milisegundos y consultas de dependencias de tres saltos en menos de un segundo; las vistas de alto riesgo también muestran la antigüedad de los datos.
3. Diseñar la ingesta y la precedencia de fuentes
Las declaraciones en los repositorios proporcionan la intención y la titularidad, los sistemas de despliegue proporcionan las versiones reales y los entornos, y la telemetría en tiempo de ejecución suministra las aristas de llamadas recientes. Cada importación almacena la fuente, la versión de commit y el resultado de validación, y utiliza una clave de idempotencia. Fusiona conflictos mediante políticas por campo: una observación en tiempo de ejecución no puede reescribir la titularidad declarada, y una arista en tiempo de ejecución no puede demostrar que una dependencia no exista. Coloca los conflictos en una cola y notifica a los propietarios.
4. Definir la semántica de frescura y eliminación
Almacena lastSeenAt, la versión de declaración y la política de expiración por entidad. Marca una entidad como obsoleta después de que sus fuentes dejen de actualizarse; ocúltala o degrada su posición en la búsqueda predeterminada mientras conservas el historial para la reproducción de incidentes. La eliminación de repositorios, el retiro de servicios y los entornos efímeros necesitan estados diferentes. La eliminación inmediata destruye el historial; no eliminar nunca contamina la búsqueda. Un reconciliador periódico reintenta las importaciones fallidas y elimina las aristas huérfanas.
5. Construir rutas de consulta, permisos y seguridad
Admite búsquedas por nombre, equipo, dominio, entorno, etiqueta y propietario. Limita la profundidad de dependencias y la cantidad de resultados para que el recorrido del grafo no sobrecargue el servicio. Asocia el alcance organizacional a entidades y campos; redacta rutas confidenciales de repositorios, endpoints internos y detalles de inquilinos de clientes por campo. Audita los cambios de titularidad y los accesos denegados; ocultar datos en el navegador no constituye autorización.
6. Desplegar progresivamente y mantener alternativas
La etapa uno cubre los servicios críticos y la búsqueda de propietarios con requisitos de fuente y frescura. La etapa dos añade grafos de dependencias, versiones de despliegue y enrutamiento de incidentes. La etapa tres evalúa la gobernanza automatizada. Si los equipos no mantienen las declaraciones, comienza con plantillas de repositorio y comprobaciones de CI en lugar de un catálogo para toda la empresa. Las directrices de PM de Amazon enfatizan los problemas del cliente y la evidencia de competencia; la adopción debe demostrarse mediante el éxito en las búsquedas, el tiempo de localización de incidentes y la tasa de mantenimiento de metadatos.
Respuesta modelo de alta calidad
Trataría el catálogo como un grafo de entidades con fuente y frescura, no como una hoja de cálculo. Los componentes, sistemas, dominios, APIs, equipos y relaciones tienen claves estables; las declaraciones en los repositorios definen la intención, el despliegue añade versiones de entorno y las señales en tiempo de ejecución añaden dependencias recientes. Los recolectores están orientados a eventos, son idempotentes y conservan las versiones de commit. Un modelo de lectura sirve propietarios, dependencias inversas y consultas acotadas de grafos. Los conflictos pasan a una cola, las entidades obsoletas se mantienen como históricas pero desaparecen de la búsqueda predeterminada y los permisos se aplican por organización y campo. Demostraría el éxito en las búsquedas, el tiempo de localización de incidentes y la tasa de mantenimiento en servicios críticos antes de expandirme.
Errores comunes
- Construir una CMDB mantenida manualmente → se vuelve obsoleta rápidamente → utiliza declaraciones de repositorio y recolección automatizada como hechos reales.
- Almacenar cadenas de texto para los propietarios → las notificaciones y el proceso de baja no se pueden validar → haz referencia a principales de equipo resolubles.
- Permitir que la fuente más reciente sobreescriba todo → el ruido de tiempo de ejecución reescribe hechos de gobernanza → clasifica las fuentes por prioridad y preserva los conflictos.
- Eliminar servicios retirados → la reproducción de incidentes pierde dependencias → utiliza estados de ciclo de vida y versiones históricas.
- Recorrido de dependencias sin límites → una sola consulta se expande a todo el grafo → limita la profundidad y los resultados y utiliza índices de adyacencia.
Preguntas de seguimiento y respuestas
¿Qué pasa si la titularidad declarada entra en conflicto con los datos de despliegue?
Represéntalos como atributos de fuentes independientes, fusiónalos mediante una política por campo y muestra el conflicto. Las declaraciones controladas son dueñas del campo de propietario; el sistema de despliegue es dueño de los campos de entorno. Notifica a ambas partes y resuelve mediante un commit correctivo.
¿Cómo manejas los entornos de vista previa de corta duración?
Asigna a las entidades un entorno y una expiración. Las entradas de vista previa reciben un peso predeterminado bajo y se archivan automáticamente. Si producción depende de una de ellas, las aristas en tiempo de ejecución pueden generar una alerta, pero la titularidad y la autorización de inquilinos siguen aplicando.
¿Qué ocurre si el catálogo no está disponible durante un incidente?
Mantén instantáneas (snapshots) exportables y una caché reciente de propietarios para servicios críticos y muestra su antigüedad. Las herramientas de incidentes pueden leer una instantánea, pero no deben presentar una instantánea expirada como la verdad en tiempo real.
¿Cómo evitas que los equipos traten el catálogo como una puerta de aprobación de lanzamientos?
Comienza con el descubrimiento y la respuesta a incidentes y mide el tiempo de búsqueda y localización. Conecta las comprobaciones de gobernanza solo después de que los metadatos y los permisos se estabilicen; una comprobación fallida debe proporcionar una ruta de reparación en lugar de bloquear cada lanzamiento.