Planteamiento y alcance
Esta pregunta de diseño de sistemas está dirigida a roles de plataforma, infraestructura en la nube y sistemas embebidos. Los dispositivos pueden estar desconectados durante semanas, tener almacenamiento limitado o pagar por ancho de banda celular; una imagen defectuosa puede desconectar a toda una flota. La plataforma debe garantizar que solo los dispositivos compatibles instalen un paquete firmado, que el despliegue se pueda pausar y que un dispositivo pueda recuperarse o regresar a su versión anterior.
Asume un millón de dispositivos, un máximo de 100,000 descargas por día y una actualización de 20 MiB. Agrupa los dispositivos por modelo, revisión de hardware, región y versión actual. La respuesta no requiere AWS; los productos en la nube solo ayudan a concretar los límites del plano de control y del plano de datos.
Qué evalúa el entrevistador
- Si separas la integridad del paquete, la autenticación del publicador, la autorización del dispositivo y las comprobaciones de compatibilidad.
- Si diseñas una máquina de estados para el plano de control y el plano de datos del dispositivo en lugar de limitarte a dibujar un bucket de descarga.
- Si calculas el ancho de banda, la concurrencia y los umbrales de aborto, y explicas la pausa, el reintento, la reversión y el escalamiento humano.
Una respuesta sólida define el “despliegue exitoso” como la verificación, instalación, reinicio y confirmación del estado de salud del dispositivo, no la finalización de la descarga en la CDN.
Aclaraciones antes de responder
- ¿Pueden los dispositivos arrancar desde dos ranuras? Las ranuras A/B permiten escribir en la ranura inactiva y recurrir a la anterior tras un fallo de arranque; los dispositivos de una sola ranura necesitan un gestor de arranque (bootloader) más conservador y una ruta de recuperación en campo.
- ¿Existen restricciones de seguridad o regionales? La segmentación debe incluir modelo, hardware, región, estado de certificados y versión actual, no solo una etiqueta del dispositivo.
- ¿Cuál es la fecha límite de la actualización? La fecha límite modifica el tamaño del lote, las ventanas de mantenimiento, los reintentos fuera de línea y si es aceptable una instalación forzada.
- ¿El fallo es a nivel de dispositivo o de cohorte? Un dispositivo individual puede reintentar; una tasa de fallos más alta para un modelo específico debería pausar esa cohorte en lugar de expandirse globalmente.
Una respuesta en 30 segundos
“Dividiría la plataforma en un repositorio de paquetes firmados, un plano de control de lanzamientos, un agente en el dispositivo y telemetría. La canalización de publicación genera un manifiesto con modelo, hardware, versión, dependencias y expiración, lo firma en un entorno controlado y hace que el dispositivo verifique la firma, el resumen criptográfico (digest) y la compatibilidad antes de la instalación. El plano de control apunta a cohortes mediante despliegues canary, de tasa fija o exponenciales, y almacena el estado por dispositivo con un ID de trabajo idempotente. El dispositivo descarga fragmentos de forma reanudable en la ranura inactiva, se reinicia y confirma la versión solo después de que se superen las comprobaciones de salud. Un aumento en los fallos, errores de descarga, reversiones de arranque o alertas de seguridad pausa la cohorte y preserva la versión anterior. Los dispositivos desconectados reintentan dentro de ventanas de mantenimiento, y cada acción es auditable y reproducible.”
Respuesta detallada paso a paso
Paso 1: Estimar el cuello de botella principal.
Si un millón de dispositivos descargan 20 MiB, el total es de aproximadamente 20 TiB. Completar 100,000 dispositivos por día representa unos 2 TiB/día, o un promedio de 23.7 MiB/s; los picos necesitan margen para la concurrencia y los reintentos. El almacenamiento de objetos y una CDN distribuyen los paquetes. El plano de control envía manifiestos y autorizaciones de descarga de corta duración en lugar de hacer que los dispositivos consulten continuamente una base de datos masiva.
Paso 2: Crear un paquete y manifiesto auténticos.
La canalización de compilación genera bytes inmutables, un resumen criptográfico y un manifiesto. Las claves de firma permanecen en un servicio de firma controlado, y la versión registra la versión del firmante y su aprobación. El dispositivo cuenta con una raíz de confianza (trust root) y verifica la firma, el resumen del paquete, el modelo de destino, el bootloader mínimo, el contador anti-reversión (anti-rollback) y la expiración. Una URL de descarga es un mecanismo de transporte, no el límite de confianza.
Paso 3: Separar los planos de control y de datos.
El plano de control crea versiones, resuelve los objetivos, crea cohortes y trabajos de dispositivo, y emite comandos de pausa. El plano de datos del dispositivo descarga fragmentos desde la CDN y reporta su estado a un endpoint de trabajos. Cada dispositivo actualiza (device_id, job_id) de forma idempotente, por lo que los reportes duplicados no pueden alterar el estado de forma incorrecta. Los estados incluyen QUEUED, DOWNLOADING, VERIFIED, INSTALLING, SUCCEEDED, FAILED, ROLLED_BACK y REJECTED.
Paso 4: Diseñar la instalación segura y la reversión.
Escribe el paquete en la ranura inactiva, verifica cada fragmento y el manifiesto final, y luego cambia la ranura de arranque. El bootloader registra los intentos y un tiempo límite para la confirmación del arranque. La aplicación confirma la actualización únicamente después de que se restablezcan las comprobaciones de salud, los sensores críticos y la comunicación. Los fallos repetidos seleccionan la ranura anterior y reportan el motivo. Un dispositivo de una sola ranura requiere una imagen de recuperación o servicio en campo; no cuenta con la atomicidad A/B de forma nativa.
Paso 5: Controlar el despliegue.
Comienza con dispositivos internos y un canary pequeño, luego expande por modelo y región. Tanto las tasas fijas como las exponenciales son válidas, pero cada cohorte requiere concurrencia máxima, una ventana de mantenimiento y criterios de aborto. Mide los umbrales por cohorte y separa los fallos de descarga, rechazos de firma, fallos de instalación, reversiones de arranque y tiempos de espera de comprobaciones de salud.
Paso 6: Manejar dispositivos desconectados, reintentos y auditoría.
Cuando un dispositivo se reconecta, reclama un trabajo no expirado. Las descargas por fragmentos utilizan reanudación y retroceso exponencial (exponential backoff); los reintentos reutilizan el mismo trabajo y versión de paquete. Un dispositivo que supera su fecha límite pasa a una cola de remediación en lugar de marcarse como exitoso. El plano de control conserva aprobaciones, manifiesto, instantánea de objetivos, transiciones de estado, actor y motivo de pausa para su reproducción y cumplimiento normativo.
Respuesta de ejemplo de alta calidad
“Separaría el plano de control, el repositorio de paquetes/CDN, el agente del dispositivo y la telemetría. La canalización de publicación genera bytes inmutables y un manifiesto que contiene el modelo de destino, la revisión de hardware, el bootloader mínimo, el contador de versión y el resumen criptográfico; un servicio de firma controlado lo firma y el dispositivo lo verifica mediante una raíz de confianza embebida. La URL de descarga solo transporta bytes.
Con un millón de dispositivos, un paquete de 20 MiB representa alrededor de 20 TiB, por lo que la CDN gestiona la distribución mientras el plano de control almacena el estado de la versión y de los trabajos por dispositivo. Los dispositivos descargan fragmentos en una ranura inactiva, verifican el resumen, se reinician y confirman la versión solo tras la confirmación de salud; los fallos seleccionan la ranura anterior y reportan un motivo. Empiezo con un canary y luego expando por modelo y región. Cada cohorte tiene umbrales de concurrencia, tasa de fallos y tasa de reversión; superar uno de ellos pausa el despliegue en lugar de propagar una imagen defectuosa. Los dispositivos desconectados reclaman el mismo trabajo en una ventana de mantenimiento, los reintentos se reanudan y las aprobaciones, estados y versiones permanecen auditables.”
Errores comunes
- Verificar únicamente HTTPS → la seguridad en el transporte no autentica el paquete ni sus bytes → verifica la firma del manifiesto y el resumen del paquete en el dispositivo.
- Marcar éxito tras la descarga → la instalación, el arranque y las comprobaciones de salud aún pueden fallar → haz que la confirmación de arranque sea la condición final de éxito.
- Lanzar a toda la flota a la vez → un defecto de compatibilidad puede afectar a todos → utiliza canaries, cohortes, tasas de ritmo y criterios de aborto.
- Crear un nuevo trabajo en cada reintento → el estado y el historial de auditoría se fragmentan → reutiliza un estado
(device_id, job_id)idempotente. - Permitir degradaciones de versión (downgrade) arbitrarias → un atacante puede reproducir una imagen vulnerable → utiliza contadores de versión firmados, políticas anti-rollback y una lista de excepciones controlada.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: Con un 2% de despliegue, un modelo alcanza una tasa de reversión de arranque del 4%. ¿Qué haces?
Pausa ese modelo y esa versión de paquete de inmediato mientras continúas observando los dispositivos exitosos. Segmenta por revisión de hardware, bootloader, región y compilación para encontrar el límite de compatibilidad; si es necesario, despliega una versión antigua verificada o un comando de recuperación. No continúes solo porque el promedio de toda la flota sea bajo.
Pregunta de seguimiento 2: Un dispositivo pierde energía al 80% de la descarga. ¿Cómo evita empezar de cero en el siguiente intento?
Escribe fragmentos en la ranura inactiva y persiste la versión del paquete, los resúmenes de los fragmentos, el desplazamiento (offset) confirmado y el resumen general del manifiesto. Tras reiniciar, verifica los fragmentos locales y el manifiesto, luego solicita un rango a partir del último fragmento confiable contiguo. Si el paquete o la firma cambian, descarta la ranura temporal en lugar de combinar dos versiones.
Pregunta de seguimiento 3: ¿Cómo evitas que un atacante reproduzca un paquete antiguo pero válido?
Incluye un contador de versión monótono o una versión de seguridad en el manifiesto y persiste el valor aceptado más alto en el dispositivo; el bootloader rechazará valores inferiores. Una reversión de emergencia requiere una firma controlada, una cohorte explícita y una autorización de tiempo limitado registrada en auditoría, de modo que un endpoint de descarga ordinario no pueda eludir la protección anti-reversión.