TecNoticias, tu portal de información

Los equipos de desarrolladores conocen bien este ciclo. Finalmente obtienen un producto para lanzar y celebrar durante las próximas 48 horas cuando todo se siente increíble. Pero pronto llegó la fría realidad y el arduo trabajo de tener un producto en el campo: nunca habrá un lanzamiento sin problemas. No es una falla de talento o tecnología. Jack Ganssle, autor de firmware y orador, sostiene que cada 1000 líneas de código tiene entre 10 y 100 defectos. Como la mayoría de los dispositivos IoT tienen miles de líneas de código, la lógica de Ganssle sugiere que existen cientos, posiblemente miles, de defectos dentro de cada uno. Si bien muchos son insignificantes, algunos defectos son graves y no se pueden ignorar. No importa cuán buenos sean los procesos de control de calidad de una organización, algunos problemas solo surgen en producción. ¿Por qué? Si ocurre un error una vez cada 10 000 horas, ese error es extremadamente difícil de encontrar en un puñado de dispositivos en control de calidad. Pero, una vez que hay 10.000 unidades en el campo, ese error aparece cada hora. Errores, problemas de seguridad, características que faltan: todo esto genera clientes insatisfechos y, a menudo, un aluvión de quejas de los clientes. Y la planificación de estos problemas posteriores al lanzamiento debe ser parte del ciclo de vida del producto. Este enfoque, denominado ingeniería de confiabilidad de dispositivos (DRE), incluye las prácticas de ingeniería, las infraestructuras y las herramientas que se pueden usar para administrar la confiabilidad a escala, posterior al lanzamiento. Con la inevitabilidad de los errores y problemas en el campo, la adopción de tres técnicas clave de DRE puede ayudar a los equipos de todo el mundo a evitar el riesgo del lanzamiento de un producto.

1. OTA integral

Considere las actualizaciones inalámbricas (OTA), que son entregas inalámbricas de nuevo software, firmware u otros datos a dispositivos conectados, es decir, una póliza de seguro; sin él, la única opción es retirar el producto. Con OTA, los desarrolladores pueden enviar actualizaciones y mantener los dispositivos operativos. Diseñar correctamente OTA hace que sea más probable que funcione bien, lo que incluye garantizar una cobertura de prueba óptima. Los sistemas exitosos admiten cohortes, implementaciones por etapas y firma de firmware. Las cohortes son cuando los desarrolladores agrupan sus dispositivos y actualizan cada grupo por separado. Las cohortes son una forma sencilla de probar los lanzamientos, lo que permite realizar pruebas A/B y otros tipos de experimentación. También resulta útil cuando se trabaja con múltiples clientes industriales que desean actualizaciones en un horario diferente. Los lanzamientos por etapas ofrecen la capacidad de impulsar de forma incremental nuevas actualizaciones a la flota de dispositivos. Debido a que cada lanzamiento presenta un riesgo, la implementación de actualizaciones limita gradualmente el radio de explosión de cualquier problema nuevo y puede evitar que un problema afecte a todos los clientes a la vez. Idealmente, los desarrolladores pueden configurar un sistema para dirigir los problemas informados al sistema OTA; si no se informan problemas, pueden aumentar automáticamente los incrementos de implementación hasta que llegue a toda la flota. La firma de firmware es un método que prueba que un archivo fue creado por una fuente confiable y no ha sido manipulado. Lo hace creando una firma verificable para un archivo. Al implementar la verificación de firmas en un gestor de arranque, los desarrolladores pueden identificar la autenticidad de una actualización de firmware determinada, y el gestor de arranque puede decidir advertir al usuario, anular la garantía del dispositivo o simplemente negarse a ejecutar un binario no autenticado.

2. Métricas de rendimiento

Después del lanzamiento, los desarrolladores de IoT deben tener acceso a datos duros, lo cual es fundamental para ayudarlos a monitorear el estado de la flota de dispositivos. Las cinco métricas más útiles son la conectividad, la duración de la batería, el uso de la memoria, el rendimiento del sensor y la capacidad de respuesta del sistema. El sistema que recopila estas métricas debe tener tres características esenciales:

Gastos indirectos bajos. La recopilación de métricas no debería afectar el rendimiento del dispositivo.
Fácil de extender. Cuando los equipos deciden agregar una métrica, no puede requerir la colaboración de tres equipos diferentes.
Preservación de la privacidad. Dado el panorama regulatorio en California, Europa y otros lugares donde se puede usar un dispositivo, las protecciones de privacidad deben incorporarse desde el principio. Por lo general, hay dos casos de uso principales para estas métricas. El primero es mirar las métricas del dispositivo. Al recopilar diferentes puntos de datos para dispositivos individuales, los desarrolladores pueden investigar informes específicos de dispositivos que se comportan mal, ya sea a través de equipos de soporte al cliente o de ingeniería. Las organizaciones deben poder capturar los cronogramas de los dispositivos para que, cuando un cliente llame con una queja sobre la duración de la batería, el equipo de atención al cliente o los ingenieros puedan ver rápidamente las correlaciones operativas, como el uso de la batería y la escritura en la memoria flash. Un sistema métrico sólido lo hace posible. Una cosa clave para recordar acerca de la captura de métricas de rendimiento es que se puede hacer de forma asíncrona, una característica especialmente crítica para dispositivos de conectividad limitada. Más allá de las métricas individuales, debe haber algún nivel de agregación y paneles para dar una indicación del rendimiento general de la flota y una forma de identificar rápidamente las tendencias de datos. El otro caso de uso principal es para la configuración de alertas. Un sistema métrico debe tener una forma de configurar alertas. Configure el sistema para enviar alertas por correo electrónico, mensajería instantánea o plataformas de gestión de incidentes cuando se cumplan ciertas condiciones. En lugar de esperar a que alguien mire los gráficos, las alertas llaman la atención inmediata del equipo sobre los problemas.

3. Depuración remota

Considere los diversos pasos involucrados con la depuración tradicional. Por lo general, comienza con varios informes diferentes de diferentes problemas de los clientes; todos pueden ser el mismo problema, pero no se describen de manera lo suficientemente similar para que los equipos de diseño los sepan. El equipo de soporte contesta el teléfono o responde a correos electrónicos individuales. Eventualmente, las organizaciones recopilan comentarios y luego los convierten en un par de registros diferentes para que los clientes los recopilen manualmente. Con estos datos, los equipos regresan los dispositivos al laboratorio y luego se envían a los ingenieros. Requiere mucho tiempo y es costoso. La depuración remota convierte este proceso largo y costoso en algo automatizado que puede ocurrir mucho más rápido. Crea una forma para que los dispositivos informen problemas de forma automática introduciéndolos en una canalización en la nube que analiza esos datos, recopila los informes en instancias de error que se deduplican y luego comparte esos informes con ingeniería. Los volcados del núcleo son una técnica de depuración estándar. Son diagnósticos automáticos y detallados que se capturan cada vez que se producen problemas. Vienen con registros, trazas inversas y memoria, y brindan a los ingenieros la información que necesitan para resolver el problema. Los desarrolladores deben recopilar datos de diagnóstico, cargarlos y crear alguna forma de verlos. La conectividad ha transformado el desarrollo de dispositivos al extender el ciclo de vida del producto. Antes, enviar un producto significaba que probablemente no volvía a haber interacción. Ahora, el ciclo de vida del producto continúa mucho después de que un producto ha sido enviado a manos de los clientes. Al adoptar técnicas de DRE, los desarrolladores pueden reducir el riesgo de lanzamiento de un producto, prepararse para la inevitabilidad de los problemas posteriores al lanzamiento y ofrecer un producto de mayor calidad y mejora continua en general.
Sobre el Autor
François Baldassari es fundador y director ejecutivo de Memfault, un proveedor de plataformas de observabilidad de dispositivos conectados. Ingeniero de software integrado de profesión, la pasión de Baldassari por las herramientas y la automatización en la ingeniería de software lo llevó a iniciar Memfault. Antes de Memfault, Baldassari dirigió el equipo de firmware en Oculus y creó el sistema operativo en Pebble. Baldassari tiene una licenciatura en ingeniería eléctrica de la Universidad de Brown.