Hace 2 años, comenzamos un blog sobre Habr, comenzando con un
texto de revisión sobre lo que hacemos, las tecnologías que utilizamos y hacia dónde nos movemos. Desde 2017, mucho ha cambiado, y hoy le diremos cómo tomar nuestra decisión: la plataforma de gestión global de Connected Cars, que es utilizada por muchos usuarios y empresas de varios niveles. El material se desglosa por proceso, desde la declaración del problema hasta la implementación.
El producto estrella Bright Box,
Remoto , es una plataforma tecnológicamente sofisticada y rica en funciones para Connected Car, que incluye equipos, software para distribuidores y fabricantes de automóviles, además de una aplicación móvil para el usuario. Según el análisis principal de Bright Box entre los propietarios de automóviles, resultó que, en primer lugar, necesitan el control remoto de las cerraduras de las puertas, el control del clima y una búsqueda de automóviles con alertas sobre descargas o evacuación. Este último ya es un clásico. Ahora, el bloque Remoto proporciona al usuario los siguientes servicios: control remoto de las funciones del vehículo, la capacidad de recibir datos desde hardware y CAN, GPRS, SMS, Bluetooth y control de la potencia de salida a la unidad de encendido electrónico. El usuario recibe esta información en una aplicación móvil.
Y dicho usuario puede ser no solo el propietario de la máquina. La información disponible para la recopilación puede ser una herramienta útil para muchos participantes del mercado de automóviles. Por ejemplo, compartir coche. Hoy en día, las compañías de autos compartidos son los jugadores más activos en el mercado automotriz. Moscú se ha convertido en la ciudad número uno en el número total de automóviles involucrados en el intercambio de automóviles. Para 2020, el uso compartido de automóviles debería alcanzar la marca de 40 mil automóviles en Rusia. Las compañías de automóviles compartidos se convierten en propietarios de los siguientes datos: kilometraje, coordenadas GPS, velocidad, estado de la puerta y nivel de combustible. La clave de todo esto es un teléfono inteligente, que es una opción más barata y segura.
Andrey Kuprikov, cofundador y director de desarrollo comercial de YouDrive y uno de los clientes de Bright Box:“Compartir el automóvil sin una solución telemática es difícil de imaginar. Nuestra plataforma está obligada a recopilar toda la información posible sobre el automóvil, qué y cómo sucede. De lo contrario, afectará al negocio. Es la telemática la que proporciona información sobre el costo de reparaciones y repuestos, el costo del tiempo de inactividad de un automóvil que está en reparación debido a la falta de un amante de la velocidad. Con un dispositivo telemático a bordo, puede crear un programa único de fidelización de usuarios ".
Desde principios de este año, Remoto se ha convertido en un proveedor de soluciones para dos grandes compañías de autos compartidos, YouDrive y EasyRide, con 1,000 autos en su flota. Usar la solución para compartir el automóvil no solo es conveniente, sino también efectivo desde el punto de vista de la seguridad y el aspecto financiero, en la forma de reducir el riesgo de accidentes y en el programa de lealtad. Con el desarrollo del uso compartido de automóviles, los datos de los usuarios se están acumulando, y ahora el uso compartido de automóviles, como los bancos, tiene un cierto sistema de puntuación de clientes. Escribimos sobre la lógica de los algoritmos de puntuación para usuarios de usuarios de automóviles compartidos, analizando primero
el algoritmo de puntuación basado en aceleraciones bruscas y frenado, y luego
los algoritmos de análisis de estilo de conducción basados en los valores de velocidad, velocidad del motor e indicadores del acelerómetro .
Pero estamos trabajando activamente no solo en el mercado ruso, sino que este es un desafío adicional. Con la expansión de la geografía del trabajo, quedó claro que la reestructuración correcta y efectiva de la vertical de ingeniería es un momento clave de desarrollo.
Diga Vitaly Baum, Director de Producto
y Vyacheslav Sokolov, Director de Ingeniería:Nuestro sistema consta de un conjunto de componentes. En ingeniería, los equipos dedicados son responsables de ellos. De hecho, Ingeniería incluye 3 procesos de negocio y un conjunto de servicios de soporte.
Los siguientes procesos de negocios se pueden distinguir dentro de las unidades de Ingeniería:
- Desarrollo de un dispositivo telemático con software integrado para integración con automóviles. Trata con el departamento de ingeniería de HW.
- El proceso de fabricación de dispositivos para un cliente específico por orden de una unidad de negocios Responsable de fabricación
- Desarrollo de Remoto Cloud Services, responsable de la interacción del cliente, usuario y dispositivo telemático. Es una multitud de servicios de back-end con un conjunto de portales para varios usuarios, aplicaciones móviles de clientes, Data lake. La producción es manejada por el departamento de gestión de productos. El desarrollo de toda la parte del software es el departamento de Desarrollo de Producto, con lanzamientos y soporte, el equipo operativo de RCS.
Vale la pena señalar que la tarea de determinar los requisitos funcionales para una característica particular recae en el departamento de Gestión de Productos, que, además de expertos en productos, también incluye analistas y diseñadores. Además, los requisitos van al departamento de desarrollo de productos, que se enfrenta a la difícil tarea de descomponer las características en componentes del sistema, incluido el firmware del dispositivo. Esta tarea es manejada por el Arquitecto de Desarrollo de Producto, junto con un equipo de analistas de sistemas.
¿Cómo es la planificación de productos? Recientemente, la gestión de productos se ha convertido en parte de un equipo de ingeniería. Y esa estructura organizativa se reflejó en cómo comenzamos a trabajar. El equipo de PM determina qué producto debe ser en general, qué funciones debe tener, independientemente de los componentes del sistema. Resulta breve: una descripción superficial de lo que hay que hacer en la tarea. Después de eso, se preparan las especificaciones funcionales, que llamamos FSD, o un conjunto de historias de trabajo, por ejemplo, la capacidad de enviar una aplicación de "registro para mantenimiento" en el producto. Cada característica se describe mediante un conjunto de historias de trabajo similares.
Los PM también están involucrados en el diseño técnico. Realizan un análisis técnico de la especificación funcional y crean un diseño técnico: TDD (Documento de diseño técnico), discuten este diseño técnico con los desarrolladores y lo entienden bajo su comprensión. Después de que se escriben los requisitos funcionales y el diseño técnico, comenzamos a trabajar en la interfaz: esta es la interfaz de experiencia del usuario.
Por lo tanto, los ingenieros de producto forman un cierto conjunto de "unidades" de utilidad para el cliente ("registrarse para el mantenimiento" puede ser una unidad de utilidad de este tipo) y se lo pasan a un especialista que describe la lógica de este conjunto. La utilidad en una solicitud de mantenimiento significa que el cliente puede completar un formulario con la información necesaria, que coincide con lo que los distribuidores esperan al presentar una solicitud de mantenimiento. El especialista del producto también analiza el mercado, estudia qué debería estar en el producto y qué valor le da a los clientes.
Nuestros expertos en productos hoy se comunican más con los negocios dentro de la empresa o con los clientes directamente. La hoja de ruta está formada por el comité de la hoja de ruta, que incluye a los altos directivos de la empresa para tener en cuenta todas las áreas del desarrollo de la empresa. El comité se reúne una vez por trimestre.
Esto se hace con el fin de coordinar los entendimientos comunes y garantizar la integridad del producto para que las características se adapten sin problemas a la visión actual del producto.
Existe un servicio separado: la seguridad cibernética, que interactúa con las personas que trabajan con dispositivos y especialistas del departamento de back-end para identificar vulnerabilidades, cerrarlas y evaluar los riesgos, que pueden conducir a estos riesgos. Hoy, la directora de ingeniería, que también dirige el equipo de producto, establece la tarea de esta división y, a su vez, se comunica con el cliente y comprende lo que ahora se necesita para cumplir con todos los estándares de seguridad cibernética. Todo esto está incluido en el plan de lanzamiento, se cierran las vulnerabilidades, se obtienen certificados y, en general, se elimina la brecha de seguridad.
Una vez que la ingeniería ha evaluado la funcionalidad y la ha evaluado el departamento de seguridad, su especificación se dirige al equipo de desarrollo de productos, donde el grupo de trabajo descompone las funciones de acuerdo con los componentes del sistema: qué se relaciona con el backend, qué dispositivo, qué debe hacer la aplicación móvil. El equipo de desarrollo de productos y el equipo de ingeniería de HW acuerdan la cooperación, todo se reduce a un plan conjunto y no está de acuerdo con los equipos.
¿Cómo desplegamos
Al final del desarrollo, el resultado recopilado se somete a pruebas de integración y despliegue a la versión en la plataforma en la nube. En la plataforma en la nube donde alojamos (Azure), entornos alojados para clientes. El entorno es responsable del equipo operativo en el que trabajan los ingenieros, DevOps y el soporte.
Comentario de Vladimir Glazkov, ingeniero sénior de DevOps:Toda nuestra infraestructura se describe como código. Hacemos todos los cambios solo a través del código. Este enfoque reduce el riesgo del factor humano durante las actualizaciones. También le permite implementar rápidamente una instancia adicional del entorno para algunas necesidades urgentes temporales. En el caso de una falla de energía informática (VM / VMSS), puede implementar rápidamente una nueva instancia.
Acerca de CI / CD: en este momento usamos un montón de TeamCity / Octopus Deploy. TeamCity está en proceso de ensamblar proyectos .net, se lanzan pruebas unitarias, luego de lo cual se crea una versión en Octopus y se implementa en los objetivos apropiados (VM / VMSS / K8S). Después de una implementación exitosa, se inician las pruebas de aceptación. Si alguna de las pruebas falla, se notificará al equipo de desarrollo.
Inicialmente, para cada proyecto empresarial, se crearon conjuntos de recursos separados, incluidas las herramientas de CI / CD. Rápidamente, se dio cuenta de que con un aumento en el número de proyectos, este enfoque está condenado al fracaso: es simplemente imposible administrar dicho zoológico de manera efectiva. Hace dos años, se lanzó un proyecto de unificación, que finalizó 4 meses después. En su proceso, se asignaron los componentes principales del sistema, para ellos el proceso de montaje e implementación es el mismo para todos los entornos. También se describió e implementó la capacidad de agregar un ensamblaje / implementación de componentes adicionales específicos para un proyecto empresarial en particular. Al crear nuevos entornos, ya no se requieren instancias individuales de TeamCity y Octopus. Se escribieron scripts que, a través de la API, crean y configuran todo lo necesario para el ensamblaje y la implementación.
Llegamos al siguiente uso de entornos: para el desarrollo, cada equipo usa dos entornos:
- el primero para, de hecho, el desarrollo de nuevas funcionalidades, verificación de características por parte del autor, etc.
- El segundo es para la estabilización.
Puede haber muchos de estos conjuntos de entornos; darles servicio es bastante simple en vista de la unificación llevada a cabo.
También hay un entorno para la aceptación del lanzamiento por parte del equipo responsable del entorno de combate. Pasa la prueba final antes del lanzamiento en producción.
Tenemos un acuerdo con los desarrolladores sobre el dispositivo para transformar los archivos de configuración. En cada proyecto, hay un archivo que contiene un conjunto de parámetros que tienen diferentes significados en diferentes entornos. Los desarrolladores completan el archivo con los parámetros necesarios (cadenas de conexión de base de datos, claves de conexión, etc.), los valores de estos parámetros son variables. Para cada entorno, los valores de estas variables son individuales. Con este enfoque, los desarrolladores no interfieren con la recopilación local y la comprobación por sí mismos. Las variables se almacenan en Octopus Deploy.
Para el monitoreo, utilizamos Azure Monitor, Application Insights y Log Analytics. Zabbix está viviendo su tiempo, probablemente en el futuro se le asignará el honorable papel de los controles externos.
Cuando me uní a la empresa, crear un nuevo entorno tomó tres semanas. Casi no hubo instrucciones, los cambios se realizaron manualmente y no se registraron en ningún lado. Nuestro viaje a IaaC comenzó con una automatización simple, que redujo el proceso a 1 semana. Ahora crear un nuevo entorno lleva 4 horas. Automatizado alrededor del 95% de las acciones.
Nuestro backend está escrito en .net (4.6 / 4.7 y core), el frente es JS. Para el alojamiento, usamos
Virtual Machine Scale Sets y K8S. En consecuencia, es muy fácil escalar bajo cambios de carga.
Cómo funciona el sistema en el interior
Dice Ivan Stolet, Jefe de Desarrollo de Plataforma Bright Box:
Siempre puede encontrar un diagrama de la arquitectura actual
en el sitio .
Todos los datos en el sistema se almacenan distribuidos. Existen bases de datos separadas para el almacenamiento de datos personales con referencia a la región y organizadas de acuerdo con la legislación local. Existen bases de datos en las que se acumula el contenido de los servicios de retención de clientes, almacenamiento de noticias, aplicaciones, datos de diversos sistemas de integración de concesionarios y fabricantes de automóviles. La información de telemetría procesada se recopila por separado, así como la configuración y otros datos necesarios para garantizar la operatividad de los servicios de Remoto y nuestros dispositivos. Recopilamos datos de telemetría en frío por separado utilizando bases de datos diseñadas para almacenar grandes cantidades de información. Además, se han construido almacenes de datos separados que brindan la capacidad de operar sistemas Remoto AI. Con la ayuda de los llamados rastreadores, se recopila toda la información estadística necesaria; sobre la base, la inteligencia artificial selecciona grupos de usuarios y construye "predicciones".
La recopilación de datos de los dispositivos se lleva a cabo utilizando la solución IoT de Microsoft. Los dispositivos están conectados a la plataforma, la plataforma recopila toda la telemetría y la coloca en un centro de eventos de almacenamiento de datos temporal intermedio. Nuestros trabajadores ya están conectados a centros de eventos, procesan telemetría, registran datos en frío y datos procesados, como rutas y eventos de tráfico, y ejecutan comandos. Un servicio separado puede solicitar datos de diagnóstico del dispositivo, analizar el estado del automóvil y generar informes personalizados.
Para aplicaciones móviles personalizadas, se implementa una API, con la cual el usuario obtiene acceso a la telemetría procesada, así como la capacidad de ejecutar comandos para el dispositivo instalado en el automóvil. La misma API se utiliza para obtener acceso a los datos del servicio de retención de clientes, el usuario recibe noticias, ofertas especiales de concesionarios y fabricantes de automóviles en su aplicación móvil, tiene la oportunidad de utilizar servicios, por ejemplo, llenar una solicitud para una prueba de manejo o un préstamo. A través de la aplicación móvil, el usuario puede establecer la configuración del dispositivo, activar servicios telemáticos, como empujar sobre golpes, acelerar o abandonar la zona, así como configurar el arranque automático del motor de acuerdo con el horario o la temperatura.
Los distribuidores, a su vez, utilizando los portales provistos tienen la oportunidad de realizar diagnósticos en el dispositivo del usuario, bloquear el arranque remoto del motor, por ejemplo, para trabajo técnico o servicio postventa, formar una oferta personal especial y también procesar solicitudes de los usuarios. La comunicación con el usuario en tales casos se realiza con mayor frecuencia mediante notificaciones push.
El concesionario también tiene la oportunidad de personalizar la aplicación móvil, el concesionario o el fabricante de automóviles pueden pintar la aplicación con los colores de su marca, cambiar los iconos clave, determinar el conjunto de funciones disponibles en la aplicación y algunas otras funciones cosméticas, se ha creado un portal separado para esto.
Para proporcionar asistencia al cliente, hay un portal técnico en el que puede validar la configuración actual de los usuarios y sus dispositivos, diagnosticar la operatividad del dispositivo, si es necesario, los datos se pueden ajustar a petición del cliente, por ejemplo, si el usuario elige otro modelo de automóvil durante la configuración, el especialista de soporte puede arreglarlo. El portal también ofrece la posibilidad de que FOTA (firmware por aire) actualice el firmware de un dispositivo o grupo de dispositivos en caso de una nueva versión del firmware con nuevas funciones o correcciones de errores.
Y algunas palabras sobre seguridad
Comentario de Artyom Nerob, CISO:Hoy, el equipo de seguridad de la compañía está en diálogo activo con el negocio.
Nos esforzamos por cumplir con los requisitos legales: ley de datos personales y GDPR. Es más importante que nunca establecer un proceso de ciclo de desarrollo seguro, es decir. agregar algunos puntos de control a los procedimientos de desarrollo actuales en forma de verificación de código antes de que se lance la aplicación, análisis de código adicional de terceros, lo que aumenta la conciencia de los desarrolladores en términos de cómo escribir código seguro inicialmente. Las prácticas y estándares mundiales recomiendan la preocupación por la seguridad durante el desarrollo, y no después. Porque después del lanzamiento, el costo de corregir la vulnerabilidad es un 30% más alto. Periódicamente verificamos la seguridad del producto por parte de los clientes, es decir Pruebas de penetración. Dada la mayor seguridad de la información, ahora estamos pasando estas pruebas con bastante éxito, y no hay vulnerabilidades con riesgos críticos o altos en el producto de una versión a otra.
Hoy contamos con un equipo para realizar pruebas de penetración, y lo consideramos como un equipo que nos ayudará en el proceso de desarrollo a realizar una revisión de la seguridad del código que se tendrá en cuenta en futuras versiones. Estas no serán pruebas de penetración completas, sino simplemente una revisión que se incorporará a nuestro proceso comercial de desarrollo, lo cual es extremadamente correcto desde el punto de vista de un ciclo de desarrollo de código seguro.
Además,
hemos confirmado el certificado de ISO 27001 , el estándar para la gestión de seguridad de la información según una auditoría realizada por BSI.
¿Cómo vivimos y qué sigue?
Aquí en Bright Box, buscamos constantemente formas de desarrollar la plataforma de Remoto Car conectado.
, , , , , . , , Honda, Motor Car, MINI. 2017 Zurich.
, Bright Box « ». , . , , :
: , .«»:
- ( ), , ( );
- ( );
- /, ;
- ;
- (///);
- .
, , , .
?, , .
, . work-life 1- , . .
, , , - .. , .
– .
? , .
, , . , 3 . .
, . :
– , . , «» . , .
– , . , – , , . , – 1-2% .
– , . 1- , .
, – .
– .
, , , .
Bright Box . , , ,
.
, Connected Cars
.
Driving to the future Medium .