FAQ: Tecnología de la Información (TI)

The Lokad app is a webapp provided as SaaS (Software as a Service). El propósito de Lokad es ofrecer analítica predictiva con el fin de optimizar el supply chain (mejores stocks, mejores precios, etc.). The Lokad app is intended as an analytical layer that operates alongside transactional systems (ERP, WMS, CRM, etc.). It comes with a monthly subscription flat fee that typically bundles the app itself with professional services. Those professional services, provided by Lokad’s engineers (Supply Chain Scientist), alleviate almost entirely the need for technical support from the IT department itself for this scope. The one key contribution expected from the IT department is the setup of a data pipeline pushing flat files (by SFTP or FTPS) to Lokad, and potentially reintegrating the results generated.

Audiencia prevista: El departamento de TI
Last modified: 30 de noviembre de 2023

Resumen técnico

The Lokad app is multitenant. Each tenant (i.e. client account) has its own dedicated file system and its own dedicated codebase repository. El sistema de archivos es accesible mediante FTPS, SFTP and a web interface. This filesystem is geared toward large flat files (up to 100 GB per file) and features data versioning (like Git). The codebase repository is used to host Envision scripts. Envision is a proprietary DSL (Domain Specific programming Language) developed by Lokad. This DSL is heavily specialized for predictive optimization use cases. Los scripts de Envision se utilizan para realizar los análisis numéricos fundamentales (including machine learning algorithms, solvers, …) and to generate data rich dashboards.

The app is redeployed in full every Tuesday between 10:00 and 14:00 (time of Paris). La aplicación se vuelve a desplegar en su totalidad cada martes entre las 10:00 y las 14:00 (hora de París). The downtime is typically kept under 5min. Lokad takes full ownership of all the versioning concerns.

The IT department is not expected to ever acquire any specific competency with Lokad’s stack. However, if you are curious, there is a complete technical documentation.

Visión general de la contribución del departamento de TI

Se espera que el departamento de TI configure un data pipeline que envíe una breve serie de extracciones relevantes de archivos planos hacia Lokad mediante SFTP o FTPS. Las extracciones se realizan sobre los sistemas transaccionales (ex: ERP). Tenemos una fuerte preferencia por extracciones de tablas en crudo (no filter, no join, no transformation), lo que requiere un esfuerzo mínimo. Desde la perspectiva ETL, solo requerimos la parte ‘E’ (extract) en su forma más simple (plain copy). Format-wise, Lokad is compatible with every reasonably tabular flat file.

Se espera que el data pipeline se ejecute al menos a diario y que esté completamente automatizado. La cantidad de trabajo para el IT department depende del alcance de la extracción de datos (¿which systems? ¿which tables?). However, as a rule of thumb, the data pipeline setup typically requires about 15 to 45 man-days, even for large companies. Once the data pipeline is in place, Lokad typically requires only minimal monitoring from the IT department, which is typically done with 1 or 2 man-days per month.

Visión general de seguridad

La aplicación se aloja en centros de datos de Microsoft Azure ubicados en la EU. No procesamos ningún dato personal, ya que no necesitamos dichos datos para operar. Al establecer el alcance de la extracción de datos, se excluye cualquier columna o campo que pudiera contener datos personales.

Para la autenticación, nuestra preferencia es SAML. Sugerimos encarecidamente que los usuarios accedan a Lokad vía una identidad federada como Azure Active Directory, Office 365 o Google Workspace. Esto elimina todos los problemas relacionados con las contraseñas.

A solicitud, los clientes pueden realizar auditorías de seguridad y pruebas de penetración. Los detalles dependen de los acuerdos negociados.

Para más detalles, consulte Seguridad en Lokad.

Resumen de la línea de tiempo

El Supply Chain Quantitativa es más acerca de un viaje que de un fin en sí mismo. Sin embargo, al mismo tiempo, el liderazgo del supply chain que compromete a su empresa en la realización de una iniciativa de Supply Chain Quantitativa requiere visibilidad en lo que respecta a la línea de tiempo del proyecto. Aunque se pueden obtener retornos positivos en un par de meses, frecuentemente toma hasta dos años para desbloquear el potencial completo del Supply Chain Quantitativa. En el siguiente texto, se proporciona una visión general de una línea de tiempo típica asociada con una iniciativa de Supply Chain Quantitativa para una empresa mediana. Para grandes empresas, se debe esperar que las líneas de tiempo sean el doble de largas.

Inicio del proyecto: Los representantes de ambas partes se presentan y programan reuniones semanales. Estas reuniones semanales continuarán hasta alcanzar la fase de Production. El Supply Chain Scientist presenta las diferentes fases de implementación y los diversos entregables que se pueden esperar por el cliente. El resto de la llamada se dedica a revisar varios detalles del supply chain y las características de IT de la integración. Después de la llamada, se elabora y envía un resumen que documenta los aspectos organizativos del proyecto al cliente.

Especificaciones de datos: Poco después de la reunión de inicio, el Supply Chain Scientist elabora las especificaciones de datos requeridas para la implementación del proyecto. Estas especificaciones se revisan y validan junto con el cliente. En particular, este documento debe definir los datos a extraer de los sistemas de IT del cliente. Como regla general, la extracción debe mantenerse lo más cercana posible a los datos originales tal como existen en los sistemas de IT del cliente.

Primera carga de datos: Tras validar las especificaciones, el primer conjunto de datos es subido a los servidores de Lokad por el cliente. Generalmente, en esta etapa, la carga aún no se realiza mediante un proceso automatizado ya que se requieren varios intentos para establecer un consenso sobre los pormenores de las especificaciones de datos.

Validación de los datos: El Supply Chain Scientist realiza una investigación en profundidad del contenido del conjunto de datos del cliente. En particular, se introducen sanity checks para monitorear la calidad de los datos según múltiples métricas. El objetivo es asegurarse de que 1) el conjunto de datos se actualice correctamente mediante el proceso de carga, 2) el conjunto de datos refleje de manera precisa la realidad del negocio y 3) el conjunto de datos sea lo suficientemente coherente y completo para fines de optimización del supply chain.

En términos de entregables, durante esta fase el Supply Chain Scientist proporciona al cliente diversos dashboards que evalúan la salud de los datos. Estos dashboards pueden ser utilizados por el cliente incluso para fines que van más allá de la iniciativa de Supply Chain Quantitativa, por ejemplo, como parte de su proceso interno de aseguramiento de la calidad de los datos.

Auditoría a mitad del proyecto: 6 semanas después de la reunión de inicio, se programa una reunión para evaluar el estado de avance del proyecto. El objetivo de esta “auditoría” es abordar lo antes posible los problemas que puedan surgir durante la implementación, especialmente aquellos que podrían retrasar la fase de Production. En Lokad, esta “auditoría” consiste en un intercambio entre el Supply Chain Scientist y el cliente, basado en una checklist que se comunica al cliente con antelación por el Supply Chain Scientist, justo después de la reunión de inicio.

Automatización de la carga: Una vez que ambas partes validan la calidad general del conjunto de datos cargado hasta el momento, el cliente implementa un proceso automatizado que transfiere su conjunto de datos a Lokad de manera regular – idealmente a diario. Al mismo tiempo, en el lado de Lokad, la lógica de data health – con sus múltiples checks – se programa para actualizarse tras cada carga.

Configuración de la optimización: A partir de este punto, el Supply Chain Scientist dispone de todos los ingredientes necesarios para implementar la optimización de las decisiones que se han acordado previamente con el cliente. Por lo tanto, implementa scripts para generar diferentes salidas cuantitativas: operational purchase suggestions, dispatch suggestions, etc. Las cifras producidas por estos scripts pueden visualizarse en forma de dashboard. En esta etapa, estos dashboards representan solo una versión preliminar de los dashboards finales y deben ser revisados junto con el cliente.

Retroalimentación y ajustes: Las solicitudes del cliente para efectuar algún tipo de alteración o tweak en las diferentes salidas suelen conducir a un ajuste fino de los scripts escritos por el Supply Chain Scientist. Existen muchos parámetros y métodos que se pueden adoptar para alinear adecuadamente las características del supply chain que se está optimizando con la lógica de optimización. Cuando la propia metodología es de importancia estratégica para el cliente, esto se discute explícitamente entre el cliente y el Supply Chain Scientist.

Producción: Tras varias rondas de ajuste fino y revisión, el cliente alcanza un punto en el que llega a confiar en la lógica implementada por el Supply Chain Scientist. En este momento, el cliente puede comenzar a utilizar el servicio en Production, es decir, puede ejecutar directamente las decisiones del supply chain tal como fueron originalmente calculadas por el software. Cuando el cliente valida que la solución está lista para Production, el Supply Chain Scientist entrega una documentación que garantiza la mantenibilidad de la solución.

Soporte y mantenimiento: La solución está operativa y es utilizada por el cliente mientras el Supply Chain Scientist supervisa la correcta ejecución diaria del data pipeline. Se organizan llamadas regularmente entre el cliente y el Supply Chain Scientist para verificar que la optimización ofrezca el grado esperado de rendimiento del supply chain. Además, los supply chain no son estáticos, por lo que los cambios en el negocio o en IT, sean pequeños o grandes, deben ser revisados: un nuevo almacén, un cambio en el mercado, un nuevo proceso, etc. El Supply Chain Scientist propone modificaciones adecuadas para acomodar estos diferentes cambios. Se programan llamadas de seguimiento con una frecuencia acordada, típicamente mensual.

Preguntas Frecuentes (FAQ)

1. Gestión de versiones

1.1 ¿Cómo funcionan los lanzamientos para Lokad?

Lokad gestiona todos los lanzamientos internamente, lo que ayuda a garantizar una transparencia completa para los clientes. Cualquier lanzamiento que pueda impactar a un cliente se coordina con ellos – via the client’s technical teams – con bastante antelación. Generalmente, Lokad adopta un enfoque cauteloso respecto a los lanzamientos: si un lanzamiento programado no proporcionara suficiente tiempo de preparación para un cliente, éste se pospondría temporalmente.

Los lanzamientos de Lokad son muy granulares, y el diseño generalmente permite al cliente optar por no incluir un elemento técnico particular de un lanzamiento global. Así, si debemos posponer la implementación de un elemento – para el que nuestro cliente aún no está listo – el lanzamiento global puede llevarse a cabo de todas formas (e implementar los otros elementos sin impacto).

1.2 ¿Con qué frecuencia se realizan los lanzamientos?

Lokad lanza una nueva versión cada martes, típicamente alrededor de las 11 AM (CET).

1.3 ¿Proporcionan un plan de los próximos lanzamientos?

Sí, consulte Gestión de versiones 1.2.

1.4 ¿Un cambio de versión implica una reinstalación o solo un parche?

Lokad vuelve a desplegar, mediante medios automatizados (scripts), su propia solución. No aplicamos parches a los sistemas en Production. Si tenemos un “security patch” que desplegar, volveremos a desplegar la solución mediante nuestros métodos automatizados habituales.

1.5 ¿Cuánto tiempo se tarda en aplicar un lanzamiento importante?

El proceso automatizado tarda aproximadamente 1 hour. Hay un despliegue en fases (machine by machine), ya que pretendemos mantener la plataforma de Lokad operativa y accesible durante el lanzamiento. La operatividad durante un despliegue se discute en Gestión de versiones 1.7.

1.6 ¿Quién es responsable de la correcta ejecución del lanzamiento?

El equipo de Lokad asume la total responsabilidad de la correcta ejecución del lanzamiento.

1.7 ¿Tienen tiempo de inactividad durante el lanzamiento?

En su mayoría no, pero tenga en cuenta que la solución de Lokad es un sistema distribuido dedicado a cálculos a gran escala. Como tal, el impacto de un lanzamiento difiere entre los sistemas front-end y back-end. Los subsistemas de cara al cliente, como los dashboards, están diseñados para garantizar cero tiempo de inactividad. Los sistemas back-end, tales como aquellos encargados de la ejecución de batch jobs, podrían pausarse durante unos minutos (al menos para algunos jobs). Sin embargo, estos batch jobs pueden programarse, por lo que una planificación proactiva debería permitir la finalización de los batch jobs fuera del marco temporal del lanzamiento.

1.8 ¿Cuál es su proceso o estrategia de pruebas para un lanzamiento?

Lokad utiliza procesos automatizados dedicados a probar y asegurar la corrección de un próximo lanzamiento. Estos procesos incluyen amplias suites de pruebas automatizadas (measured in the thousands); unit tests, functional tests, performance tests, etc. También hemos desarrollado herramientas dedicadas que nos permiten reproducir secuencias completas de ejecuciones pasadas de jobs dentro de la plataforma de Lokad. Estas herramientas nos permiten verificar que los Envision scripts tengan el mismo comportamiento exacto antes/después de un próximo lanzamiento. Además, podemos comprobar que los perfiles de rendimiento de los scripts existentes se mantienen en línea con las expectativas de schedule definidas por nuestros clientes.

1.9 ¿Tienen múltiples entornos?

Sí, sin embargo, los entornos alternativos (at the platform level, besides the production one) generalmente no están destinados para nuestros clientes. In addition to the production environment and the transient development ones, tenemos un entorno ’evergreen’ que coincide con la última versión estable de nuestra codebase. Esto valida un subconjunto específico de nuestros procesos automatizados de testing. Nuestros clientes pueden acceder a nuestro entorno ’evergreen’ para validar que un próximo lanzamiento específico se comporta según lo esperado. Esta situación puede surgir si existe IT integration entre Lokad y el cliente. En la práctica, esta situación es poco frecuente.

Si el objetivo es poder ejecutar (lado a lado) múltiples variantes de scripts Envision, entonces una cuenta de Lokad se puede dividir en múltiples “environments”. Si el objetivo es poder realizar cualquier tipo de prueba, entonces se puede proporcionar una segunda cuenta de Lokad para propósitos de prueba transitoria. Este segundo enfoque mantiene la cuenta principal del cliente (utilizada para producción) aislada de estas pruebas.

1.10 ¿Cuántas versiones diferentes pueden coexistir?

Lokad es un SaaS multi-inquilino que ejecuta la misma versión única para todos sus clientes, sin embargo, Lokad tiene la capacidad de operar tantas versiones distintas como desee el cliente.

1.11 ¿Puede un cliente optar por no participar en un lanzamiento?

Dado que Lokad es un SaaS multi-inquilino que ejecuta la misma versión única para todos los clientes, no es posible optar por no participar en un lanzamiento. Sin embargo, desde una perspectiva empresarial, esto es irrelevante ya que cualquier “cambio” se implementa mediante la ejecución de scripts Envision dentro de la solución de Lokad.

Para situaciones en las que un lanzamiento pueda ser pospuesto temporalmente, ver Release Management 1.1

1.12 ¿Tienen notas de lanzamiento? ¿Se las proporcionan a sus clientes?

Sí. Estas notas se comparten internamente (con nuestros equipos de Supply Chain Scientist). Si se acuerda explícitamente como parte de un contrato, estas notas de lanzamiento pueden ponerse a disposición de un cliente. En la práctica, las notas de lanzamiento de la plataforma Lokad solo son de interés para las personas que trabajan con código Envision.

1.13 ¿Cuál es el proceso para que un cliente solicite una evolución de la solución?

La mayoría de nuestros clientes se benefician de una oferta de “software + expert”, en la que un equipo de Supply Chain Scientist de Lokad es responsable de la implementación y el mantenimiento de la solución de supply chain de un cliente. Estas situaciones se conocen como “supply chain as a service”. En estos arreglos, el cliente interactúa rutinariamente con uno (o más) Supply Chain Scientist. Además, la mayoría de los clientes se benefician de un comité directivo semanal o mensual para discutir el estado actual de la solución y cualquier evolución deseada. Este método es utilizado por Lokad para recopilar todas las solicitudes de evolución y proponer una hoja de ruta para la implementación de los cambios.

1.14 ¿Es posible administrar el servicio web de la aplicación y configurar sus parámetros?

Sí, en el sentido de que la plataforma Lokad es programática por naturaleza. La lógica “analytical” de Lokad toma la forma de scripts Envision - siendo Envision el DSL (Domain-Specific Language) diseñado por Lokad con el propósito de la optimización predictiva de supply chain.

Así, en cierto sentido, cada configuración de parámetro está disponible gracias al aprovechamiento de scripts Envision dentro de la cuenta.

2. Rendimiento

2.1 ¿Cubre su SLA (service level agreement) un tiempo de actividad del 99.xy%?

Sí. El SLA es parte de nuestro acuerdo contractual predeterminado. Sin embargo, la noción de tiempo de actividad en el contexto de un sistema informático distribuido - dedicado a la optimización predictiva de supply chains - es compleja. Considere los siguientes escenarios: - Lokad recibe datos del cliente (un paso diario) con 2 horas de retraso. Esto puede muy bien interrumpir la eficiencia ordinaria de nuestras heurísticas de asignación de recursos. Esto, a su vez, puede prolongar el tiempo necesario para ejecutar los trabajos batch de Lokad (por ejemplo, 75 minutos en lugar de los habituales 60). Algunos pueden considerar esto un tiempo de inactividad de 15 minutos, pero eso está fuera de nuestro control.

• Lokad recibe los mismos datos del cliente a tiempo, pero los datos presentan una caída considerable en los niveles de stock. Esto desencadenaría una interrupción de los trabajos batch (del lado de Lokad) y alertaría a un Supply Chain Scientist para investigar el problema. El Supply Chain Scientist observa que una orden de reposición automatizada es sin precedentes en magnitud. El Supply Chain Scientist decide que es necesaria una evaluación directa por parte del cliente. Al día siguiente, el cliente confirma que los datos de stock estaban corruptos y que habrían resultado en una gran pérdida de stock. Algunos pueden considerar esto un tiempo de inactividad de 24 horas, pero eso parece prácticamente obtuso en este contexto.

El mayor peligro para una solución de optimización de supply chain no es llegar un poco tarde; es estar muy equivocado. Una vez que se toma una decisión de supply chain, como (incorrectamente) disparar un lote de producción, deshacerla puede ser sumamente costoso. Animamos a nuestros clientes a no apegarse arbitrariamente a indicadores de forma aislada, ya que esta actitud puede incentivar a las personas a entregar un trabajo global inferior siempre y cuando parezca satisfacer un KPI (como x.y% de tiempo de actividad).

2.2 ¿Garantizan el tiempo de respuesta para las solicitudes de los usuarios en X segundos?

Sí, en menos de 500ms, pero con salvedades.

Hemos diseñado lo que equivale, aproximadamente, a dashboards de tiempo constante. Bajo el capó, la visualización de un dashboard requiere una única solicitud a través de la red, y en nuestro back end, colocalizamos todos los datos del dashboard para mantener el número de solicitudes de red bajo (generalmente medido en dígitos individuales). Este diseño contribuye en gran medida a “garantizar” la baja latencia de la solicitud típica del usuario en la visualización de un dashboard. Esta elección de diseño también previene que el dashboard se sature de tiles - cada uno de los cuales requeriría solicitudes de red - y ralentice la experiencia global del usuario.

En lo que respecta a la duración de los trabajos batch, a través de Envision podemos proporcionar garantías - en tiempo de compilación - de que un trabajo batch se completará. También podemos garantizar tiempos de finalización en gran medida reproducibles para nuestros trabajos batch. Estas garantías se obtienen mediante análisis estático y un diseño cuidadoso del lenguaje Envision - lo que hace posibles ciertas clases de análisis estáticos desde el principio. Este enfoque tiene límites, pero es enormemente superior a los diseños que no ofrecen ninguna garantía.

Sin embargo, la latencia de extremo a extremo no está completamente bajo nuestro control. Por ejemplo, no controlamos la calidad de la conexión a internet utilizada por nuestros clientes. Una gran hoja de cálculo de Lokad tardará en descargarse a través de una red de bajo ancho de banda.

2.3 ¿Dispone de registros de auditoría de rendimiento del sistema?

Sí. Recopilamos registros de rendimiento muy detallados para todos los recursos informáticos involucrados: CPU, memoria, almacenamiento, ancho de banda, etc. Estos registros de rendimiento se utilizan, entre otras cosas, para asegurar que una nueva versión aún no lanzada de la plataforma cumpla con nuestras expectativas en términos de rendimiento. Probamos esto comparando el rendimiento de la nueva versión con el rendimiento de las versiones anteriores, según lo evidencian estos registros.

2.4 ¿Es posible monitorear respuestas lentas o congestiones?

Sí. La plataforma Lokad viene con un programador interno que puede rastrear la ejecución oportuna de los trabajos batch. El diseño de Lokad asegura en gran medida una respuesta de tiempo constante para todas las solicitudes - excepto las operaciones de larga duración, que se tratan como trabajos batch.

Dado que Lokad es una plataforma multi-inquilino, una gran parte del monitoreo de rendimiento no es directamente accesible para nuestros clientes (ya que cubre el rendimiento de la plataforma en su totalidad). Como era de esperarse, los equipos de Lokad monitorean continuamente el rendimiento de nuestra plataforma.

2.5 ¿Dispone de balanceadores de carga?

Sí. Los balanceadores de carga de Lokad están destinados primordialmente a la fiabilidad más que a propósitos de rendimiento. El balanceo de carga a nivel de red se realiza a través de la capa de redes de la plataforma de computación en la nube que utilizamos (Microsoft Azure). Sin embargo, la distribución de la carga de procesamiento de datos interno, manejada por la plataforma Lokad, no se gestiona mediante balanceadores de carga, sino a través de un orquestador interno asociado con nuestro compilador.

2.6 ¿Agrupan recursos como conexiones DB, sesiones, etc.?

Sí. Sin embargo, la plataforma Lokad no se basa en una base de datos transaccional para operar. Por lo tanto, no hay conexiones DB que agrupar. No obstante, agrupamos muchos otros recursos, siempre que tenga sentido desde una perspectiva de rendimiento.

2.7 ¿Soportan el procesamiento paralelo?

Sí. Envision (nuestro DSL) ha sido diseñado en torno a la noción de ejecución paralelizada automática. La plataforma Lokad aprovecha activamente la paralelización en múltiples niveles: a nivel de núcleo de CPU mediante operaciones SIMD (Single Instruction/Multiple Data); a nivel de CPU mediante ejecuciones multihilo; y a nivel de clúster mediante computación distribuida. Dado que el procesamiento paralelo es un aspecto central del diseño de Envision, la casi totalidad de las cargas de trabajo ejecutadas en la plataforma Lokad se benefician de una extensa paralelización, por defecto, sin ningún esfuerzo específico por parte de nuestros clientes o de los Supply Chain Scientist.

2.8 ¿Soportan la caché de datos frecuentemente accedidos?

Sí. Sin embargo, la caché se introduce con frecuencia como una solución para hacer frente a las limitaciones de rendimiento de las bases de datos transaccionales. Dado que la plataforma Lokad no incluye bases de datos transaccionales, no utilizamos la caché para este propósito.

2.9 ¿Comprimen datos para reducir el tráfico de red?

Sí, comprimimos la mayor parte del tráfico de red. Sin embargo, no podemos comprimirlo todo ya que eso presentaría una vulnerabilidad de seguridad conocida como BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext). BREACH ocurre cuando se presenta una combinación de 3 factores.

1. Una respuesta está comprimida.

2. Una respuesta contiene un secreto.

3. Una respuesta contiene una cadena que puede ser recopilada por el atacante que elabore la solicitud.

Para defenderse contra BREACH, Lokad deshabilita la compresión en todas las respuestas donde se cumple la tercera condición. Además, comprimimos los datos por razones que van más allá de reducir el tráfico de red; en primer lugar, para reducir los costos de almacenamiento de datos; y en segundo lugar, para reducir las demoras en el procesamiento.

2.10 ¿Realizan pruebas de rendimiento?

Sí. Lokad cuenta con una extensa capa de instrumentación automatizada orientada al rendimiento. Esta serie de herramientas nos permite evaluar, antes de cada lanzamiento, la diferencia de rendimiento de la próxima versión en comparación con la obtenida con la versión actualmente desplegada. Esta herramienta nos permite reproducir las mismas cargas de trabajo, tal como se observan en producción, y monitorear el rendimiento resultante; no solo en tiempo real, sino considerando todos los recursos informáticos relevantes (memoria, ancho de banda, I/O, CPU, etc.).

2.11 ¿Monitorean el rendimiento a nivel de transacción?

Sí. Sin embargo, dado que la plataforma Lokad no utiliza una base de datos transaccional, no hay “transactions” que monitorear (en el sentido tradicional). El equivalente más cercano es la ejecución de scripts Envision. Para estos scripts, monitoreamos el rendimiento a un nivel muy detallado, que es aproximadamente análogo a monitorear la letra pequeña de la ejecución del plan de consulta (desde una perspectiva de base de datos transaccional).

Consulte Authorization 3.6 y Logging and Monitoring 5.3 en nuestra documentación de Security para obtener más información sobre las “transactions” en la solución de Lokad.

2.12 ¿Cuál es el impacto en el rendimiento de tener usuarios concurrentes en la solución?

Casi ninguno. El diseño de Lokad asegura que los dashboards puedan ser atendidos en tiempo constante incluso para un gran número de usuarios (según los estándares B2B). Este enfoque contrasta fuertemente con muchas arquitecturas alternativas, sobre todo las bases de datos transaccionales y los cubos de Business Intelligence.

Sin embargo, dado que cualquier usuario individual podría (si posee los derechos del sistema apropiados) desencadenar cargas de trabajo arbitrariamente grandes, el número de usuarios concurrentes es, en el mejor de los casos, una preocupación secundaria en lo que respecta al rendimiento de la solución. En lo que respecta a la optimización predictiva de supply chain, los trabajos batch utilizados para realizar los análisis de interés representan más del 99% de la carga de trabajo. El menos del 1% restante se dedica a atender las solicitudes de los usuarios.

2.13 ¿Está diseñado el sistema para escalar vertical y horizontalmente?

Sí. Desde nuestra perspectiva, la escalabilidad vertical y horizontal son complementarias, y el diseño de la plataforma Lokad aprovecha ambas. El orquestador interno - el encargado de la paralelización - típicamente comienza con la escalabilidad vertical, ya que ésta facilita en gran medida la colocalización de datos. Luego, el orquestador aprovecha la escalabilidad horizontal si la carga de trabajo es lo suficientemente grande como para beneficiarse de la ejecución en múltiples máquinas.

2.14 ¿Escalan automáticamente la computación y el almacenamiento según sea necesario?

Sí. La plataforma Lokad es multi-inquilino. A través de la multi-tenancy, realizamos asignaciones de recursos de computación a gran escala y baja latencia. Esto significa que el auto-escalado de computación que proporciona Lokad es órdenes de magnitud más rápido que iniciar grandes VMs (virtual machines) desde un proveedor de computación en la nube. El auto-escalado de almacenamiento se realiza en gran medida aprovechando las propiedades de auto-escalado del almacén persistente de clave-valor, según lo proporcionado por la plataforma de computación en la nube subyacente (Microsoft Azure).

2.15 ¿Cómo gestiona su aplicación los requerimientos de “Big Data”?

La plataforma Lokad ha sido diseñada específicamente para el procesamiento de “Big Data”. A partir de enero de 2023, toda la plataforma Lokad gestiona alrededor de 1 petabyte de datos en toda nuestra base de clientes. Nuestra plataforma puede procesar archivos individuales de hasta 100GB, y rutinariamente procesamos tablas con decenas de miles de millones de líneas. Ir a Security of Lokad 4.10

Este punto es particularmente técnico y va más allá del alcance de este documento. Para una explicación extensa, recomendamos la serie de 4 partes de Victor Nicollet sobre el diseño de la Envision Virtual Machine.

2.16 ¿Se puede configurar la solución basada en la nube de Lokad teniendo en cuenta restricciones estrictas de ancho de banda y latencia (en el lado del cliente)? Por ejemplo: ancho de banda = 3Mbps (descarga) / 1Mbps (carga), latencia = 600-800ms

Sí, la webapp diseñada por Lokad ha sido concebida para poder soportar escenarios donde la conectividad es “poor” (tanto en términos de ancho de banda como de latencia). Estas preocupaciones se abordan principalmente mediante elecciones fundamentales en el diseño tecnológico. Estas architectural design choices también diferencian a Lokad del enfoque convencional. Las preocupaciones sobre el ancho de banda se abordan de dos maneras. Primero, somos parsimoniosos en lo que respecta a componentes de terceros en JavaScript. Tenemos menos de 1MB de assets para ser recuperados inicialmente. Segundo, la plataforma ofrece control completo sobre la cantidad de datos a incluir en cualquier dashboard. Así, si la conectividad es poor, es posible hacer el dashboard adecuadamente “light”. Con respecto a las preocupaciones de latencia, nuestros dashboards han sido diseñados para empaquetar todos los datos relevantes del dashboard en una única solicitud HTTP. Esto minimiza la fricción que experimentan los usuarios finales con baja latencia.

2.17 ¿Cuáles son las capacidades medias y máximas de throughput de datos de la solución en comparación con un punto de referencia de 1 (bajo rendimiento) y 5 (alto rendimiento) mensajes por segundo?

La plataforma de Lokad no opera con mensajes. De manera similar, las interacciones con la plataforma de Lokad no se realizan a través de mensajes. Sin embargo, el rendimiento es importante para procesar rápidamente enormes conjuntos de datos transaccionales. La plataforma de Lokad gestiona, en conjunto, más de 1 petabyte de datos. Habitualmente manejamos más de 1 terabyte por minuto para grandes lotes de cálculos.

Un rendimiento muy alto es importante para evitar retrasos operativos al procesar conjuntos de datos muy grandes (decenas de terabytes) con cálculos complejos que incluyen machine learning y pasos de optimización matemática.

2.18 ¿Qué tamaño de mensajes puede manejar la solución? Por favor, proporcione detalles respecto a los valores mínimos, máximos y promedio.

La plataforma de Lokad no opera con mensajes. Lo más parecido serían los “flat files”. Estos flat files se pueden enviar a - y recuperar desde - Lokad. La plataforma de Lokad puede procesar archivos que, individualmente, alcanzan un tamaño de hasta 100GB. Sin embargo, esta no es una práctica recomendada, ya que suele ser algo engorrosa (no para Lokad, sino para los clientes que tendrán que familiarizarse con herramientas externas para producir y consumir dichos archivos grandes).

3. Incidentes

3.1 ¿Cuál es el proceso para que un cliente reporte un incidente?

La mayoría de nuestros clientes se benefician de un paquete que incluye acceso a nuestro equipo de Supply Chain Scientist. Estos Supply Chain Scientist son el primer punto de contacto para reportar incidentes. En caso de un incidente, sugerimos a los clientes que llamen telefónicamente a su Supply Chain Scientist directamente -si el problema es urgente- o que envíen un correo electrónico. Los Supply Chain Scientist se encargan de la gestión de incidentes, incluyendo cualquier escalación dentro de la organización de Lokad.

3.2 ¿Ofrecen un sistema de tickets?

Sí. Lokad utiliza un sistema de ticketing de terceros. Sin embargo, desde enero de 2023, hemos empezado a desarrollar una solución interna que ofrece una integración estrecha con el resto de nuestra plataforma.

3.3 ¿Soportan reportar incidentes a herramientas de terceros?

Sí, bajo la condición de un acuerdo contractual dedicado.

En el contexto de la optimización predictiva de supply chain, los “incidentes” pueden variar y ser difíciles de definir. Generalmente, nuestros clientes no consideran eventos menores a nivel de plataforma (como pequeñas interrupciones) como “incidentes”. Más bien, las verdaderas rarezas de supply chain -que pueden o no reflejar problemas con los scripts de Envision implementados en la cuenta del cliente- serían candidatos más adecuados. Los departamentos de TI externos rara vez se involucran en la resolución de estos incidentes.

3.4 ¿Cómo aseguran una alta disponibilidad?

Lokad se convirtió en uno de los primeros en adoptar (c. 2010) las plataformas de computación en la nube precisamente para garantizar una mayor disponibilidad. Además de hacer redundante la infraestructura (ver Incidents 3.5), el diseño de la solución de Lokad enfatiza fuertemente la simplicidad. En contraste con soluciones de software empresarial comparables, tenemos significativamente menos dependencias complejas (por casi un orden de magnitud). Una enorme capa de complejidad ausente en nuestra solución es una base de datos transaccional. Al tener menos partes móviles, disponemos de muchos menos modos de fallo, lo que nos ayuda a mantener una alta disponibilidad para nuestros clientes (quienes se distribuyen en varias zonas horarias).

3.5 ¿Tienen una infraestructura redundante (y de ser así, ¿cómo)? ¿Evitan puntos únicos de fallo?

Sí. Nuestros sistemas críticos son redundantes, precisamente para evitar puntos únicos de fallo. Los sistemas redundantes incluyen los subsistemas que soportan protocolos con estado como SFTP. Además, el almacenamiento de datos no solo es redundante, sino también geográficamente redundante. Se aprovecha esta redundancia durante nuestros lanzamientos para preservar el tiempo de actividad mientras se lleva a cabo el despliegue.

3.6 ¿Cómo se recuperan de fallos de hardware?

La recuperación de la mayoría de los fallos de hardware se realiza de forma transparente por la plataforma de computación en la nube que utiliza Lokad. La redundancia incorporada en la plataforma de Lokad asegura que los fallos de hardware transitorios no afecten el tiempo de actividad mientras la plataforma de computación en la nube reasigna un nuevo recurso no defectuoso. Para el almacenamiento persistente de datos, Lokad solo utiliza servicios (es decir, almacenes key-value) que están protegidos contra fallos de hardware mediante sus propias capas de redundancia.

3.7 ¿Tienen un backup?

Sí. Contamos con un entorno de backup dedicado a escenarios de recuperación ante desastres severos (más allá de un tiempo de inactividad a nivel de centro de datos). Este entorno de backup está completamente aislado del entorno de producción. El entorno de backup puede leer desde el de producción (pero no escribir), mientras que el entorno de producción no puede ni leer ni escribir desde el de backup.

3.8 ¿Cuentan con un plan de recuperación ante desastres?

Sí. A nivel técnico, el plan de recuperación ante desastres abarca la reinstanciación completa de la plataforma de Lokad. Esta parte aprovecha extensamente los procesos automatizados que tenemos implementados para nuestros lanzamientos semanales. A nivel empresarial, el plan de recuperación ante desastres incluye contactar a cada uno de nuestros clientes, generalmente siguiendo un proceso que se ha acordado con cada uno. Para la mayoría de nuestros clientes, los Supply Chain Scientist designados actúan como los puntos de contacto principales durante la recuperación.

3.9 ¿La solución soporta la recuperación a un punto en el tiempo (PITR) tanto en la base de datos como en los datos fuera de la base de datos? ¿Cuál es el Objetivo de Punto de Recuperación (RPO) de la solución?

La solución de Lokad presenta un diseño de protección continua de datos mediante el backup incremental en vivo tanto de su event store como de su fuente de contenido. Por lo tanto, podemos realizar PITR para cualquier momento dado (hasta el nivel de minutos).

Tenemos un RPO de 1 minuto para desastres a nivel de centro de datos, si los datos no han sido comprometidos. Logramos esto aprovechando escrituras geográficamente redundantes de nuestro almacén key-value persistente. Si el almacén key-value se ve comprometido, Lokad se recupera a partir de su almacenamiento de backup (mantenido lo más aislado posible de nuestros sistemas de producción), también alojado en una ubicación geográfica diferente. En este caso, tenemos un RPO de 12 horas.

3.10 ¿La solución es capaz de generar alertas por violación de integridad? ¿Tiene la solución la capacidad de añadir o ampliar las verificaciones de integridad según los requisitos?

Sí, aunque este tipo de problema refleja principalmente un diseño de software basado en una base de datos transaccional. La plataforma de Lokad no opera con una base de datos transaccional, sino con un event store, adoptando un diseño de event sourcing en lugar de uno relacional. Esto no elimina la necesidad de hacer cumplir la integridad de los datos, pero esas preocupaciones se abordan de maneras alternativas.

En lo que respecta al procesamiento de los datos del cliente, Envision (el DSL de Lokad) cuenta con amplias capacidades orientadas a verificar su calidad. A través de Envision, es posible comprobar la integridad y generar alertas. Esta lógica puede ser ampliada o modificada de la manera que el cliente considere apropiada.

3.11 ¿Se prueban periódicamente los backups para asegurar una correcta funcionalidad de restauración de datos?

Sí. El diseño basado en event sourcing de Lokad, combinado con su content-addressable store, hace que probar la funcionalidad de backup y restauración de datos sea mucho más sencillo que en la mayoría de los diseños convencionales que utilizan bases de datos relacionales (como SQL).

Ver también Incidents 3.7.

3.12 ¿Se prueban periódicamente los planes de recuperación ante desastres para confirmar su correcta funcionalidad?

Sí. La estrategia de despliegue de Lokad utiliza scripts automatizados de extremo a extremo, manteniendo deliberadamente muy pocas intervenciones humanas -una excepción notable es la capacidad de activar un redeployment completo de producción. Este enfoque altamente automatizado facilita la prueba de la funcionalidad de recuperación ante desastres.

Ver Incidents 3.8.

3.13 ¿Se puede realizar la recuperación para clientes individuales y/o entornos de clientes?

Sí. Nuestras herramientas internas soportan la posibilidad de restaurar la cuenta de un cliente seleccionado (incluida la restauración de la cuenta/entorno a un punto en el tiempo determinado). Sin embargo, considerando que la propia plataforma de Lokad cuenta con amplias capacidades de versionado (por ejemplo, los scripts de Envision están versionados, y versiones anteriores son accesibles desde la aplicación), esta capacidad se utiliza raramente.

3.14 ¿Cumplen los planes de backup y recuperación ante desastres con los requisitos de RTO (Recovery Time Objective), RPO (Recovery Point Objective) y escenarios de desastre de los clientes (según lo definido y acordado con cada uno)?

Sí. El Recovery Time Objective (RTO) se referiría aquí a la cantidad de tiempo que la plataforma de Lokad podría estar inactiva teóricamente sin causar daños significativos al cliente, así como el tiempo empleado en restaurar la plataforma y sus datos para que pueda reanudar sus operaciones normales después de un incidente significativo.

El RTO depende en gran medida de los detalles específicos de los procesos soportados/proporcionados por Lokad. Por ejemplo, un cliente que confía en Lokad para programar órdenes de compra mensuales en el extranjero podría tener un RTO de 1 semana. Por el contrario, un cliente que confía en Lokad para optimizar su despacho diario de inventario desde un almacén a varias tiendas podría tener un RTO de 1 hora.

En la práctica, se pueden implementar diversas contingencias técnicas para mejorar sustancialmente el RTO (es decir, disminuir un tiempo de inactividad teórico). Por ejemplo, se pueden calcular por adelantado decisiones de failover. Estas decisiones pueden utilizarse en caso de que la plataforma de Lokad no esté disponible. En comparación con las decisiones optimizadas “regulares”, las decisiones de failover pueden exhibir un rendimiento de supply chain ligeramente degradado, dado que (por definición) no aprovecharían los datos absolutos y más recientes.

Para nuestras cuentas gestionadas, es responsabilidad del Supply Chain Scientist de Lokad elaborar conjuntamente un proceso -con los equipos operativos del cliente- que proporcione un alto RTO, pero también que asegure un impacto comercial mínimo en caso de un incidente real. Desde nuestra perspectiva, este desafío es, ante todo, un problema de supply chain y no de TI.

Ver también Incidents 3.9.

3.15 Si un defecto no es reproducible en el entorno de pruebas, ¿puede Lokad verificar que el defecto ha ocurrido a partir de los logs y datos de soporte, además de asegurar que el defecto sea corregido según el Acuerdo de Nivel de Servicio (SLA)?

Sí, los defectos pueden ser reproducidos en nuestros entornos. La reproducibilidad estricta de todos los estados de datos y de todos los cálculos es un principio de diseño fundamental de la plataforma y la arquitectura de Lokad. Por ejemplo, el sistema de archivos dentro de la plataforma de Lokad está completamente versionado (como Git), precisamente para abordar esta preocupación.

Cabe señalar que los logs son más efectivos para la resolución de problemas triviales, como el tiempo de inactividad del servidor. Cuando se trata de resolver problemas y defectos complejos en un entorno de datos a gran escala -donde se manejan terabytes de datos- los logs a menudo son insuficientes.

Así, aunque Lokad mantiene y consulta logs cuando es apropiado, no dependemos de los logs para abordar defectos o verificar que éstos hayan sido corregidos. En su lugar, aprovechamos principalmente decisiones de diseño superiores para ofrecer mayor visibilidad, trazabilidad y reproducibilidad.

Estas decisiones de diseño deliberadas nos permiten identificar, reproducir y corregir defectos de una manera que confiar únicamente en los logs no permitiría.

Por favor, revise Architecture of Lokad para obtener un desglose detallado de las diversas decisiones de diseño clave que adoptamos para evitar clases enteras de problemas comunes de software.

3.16 ¿Mantienen registros de todas las solicitudes de servicio y llamadas de servicio (incluida la categoría de cada llamada) realizadas por la empresa cliente? ¿Incluyen los registros: la identidad de la persona que llama y de la persona llamada; la naturaleza del error, problema o incidente reportado; el tiempo de respuesta de Lokad; la disposición de la llamada de servicio; la resolución; los tiempos de resolución; y la disponibilidad del sistema?

Sí, la plataforma de Lokad posee capacidades de gestión de tareas/tickets/incidencias que proporcionan los detalles mencionados.

Con respecto a las “resoluciones”, cabe destacar que la filosofía Supply Chain Quantitativa de Lokad se centra en encontrar el compromiso financieramente más beneficioso al presentarse un problema. Técnicamente, QSC no es, en sentido estricto, un enfoque de “solución de problemas”, ya que los problemas de supply chain no son algo que se “solucione”, sino que se atenúan realizando compromisos financieramente informados.

En resumen, Lokad posee las herramientas y procesos para resolver de manera inmediata “problemas fáciles” (como el tiempo de inactividad del servidor) de forma directa. Cuando se trata de problemas de supply chain más importantes y de mayor trascendencia (como la asignación de stock en retail o problemas de reposición de inventario), estos suelen ser discusiones más abiertas y continuas con los clientes acerca de qué compromisos maximizan su retorno de inversión.

4. Arquitectura

4.1 ¿Qué lenguajes de programación utilizan?

La plataforma de Lokad se desarrolla en C#, F# y TypeScript. La plataforma también cuenta con Envision (el DSL de Lokad), que se utiliza para implementar las soluciones de supply chain específicas para cada cliente.

4.2 ¿Qué suite de desarrollo utilizan?

Los equipos de ingeniería de software de Lokad utilizan Microsoft Visual Studio. Los equipos de Supply Chain Scientist utilizan la propia plataforma de Lokad, que cuenta con su propia suite de desarrollo.

4.3 ¿Qué sistema operativo soportan?

Lokad es una plataforma basada en la web y soportamos todos los sistemas operativos que tienen acceso a un navegador web moderno (ej: Firefox). Internamente, la plataforma de Lokad es compatible tanto con Linux como con Microsoft Windows, aunque todos nuestros sistemas de producción se despliegan bajo Linux (Ubuntu).

4.4 ¿Qué sistema de base de datos utilizan o soportan?

Lokad soporta todos los sistemas de bases de datos que pueden producir exportaciones en flat file. Esto incluye prácticamente todos los sistemas de bases de datos del mercado, incluidos los modelos más antiguos. Internamente, Lokad no utiliza un sistema de bases de datos, sino un key-value store. Al momento de escribir esto (enero de 2023), usamos Blob Storage tal como lo proporciona Microsoft Azure.

4.5 ¿Qué sistema de caché utilizan?

Lokad ha desarrollado sus propios subsistemas de caché en C#/.NET. Estos subsistemas están estrechamente integrados con el resto de la solución y no reflejan los sistemas de caché tradicionales destinados principalmente a mitigar problemas de rendimiento con una base de datos relacional (la cual Lokad no posee).

4.6 ¿Cómo maneja la solución los certificados?

Lokad aprovecha Let’s Encrypt through renovaciones automáticas de certificados.

4.7 ¿Cuáles son los requisitos técnicos para utilizar la solución?

El principal requisito técnico es un sistema de transacciones que permite hacer un seguimiento del inventario. Además, es útil que el cliente tenga algo de experiencia extrayendo datos (como archivos planos) de sus sistemas transaccionales, pero ciertamente no es un prerrequisito.

4.8 Enumere cualquier licencia de terceros adicional requerida para operar la solución de Lokad (por ejemplo, OS, SQL,…).

N/A. Lokad no requiere ninguna licencia de terceros para operar. Existe una amplia gama de herramientas de código abierto para apoyar la integración de Lokad (es decir, archivos planos transferidos a través de FTPS o SFTP); por lo tanto, no se requiere ninguna licencia de terceros, ni siquiera de manera indirecta, para beneficiarse de la plataforma de Lokad.

4.9 ¿Requiere el servicio algún complemento para el navegador o software especial?

Lokad es una aplicación web. No requiere complementos para el navegador ni software especial.

4.10 ¿Cuáles son las interfaces de entrada y salida de la aplicación?

La solución de Lokad ofrece una interfaz web - accesible a través de HTTPS - y protocolos de archivos, concretamente SFTP y FTPS.

4.11 ¿Cómo se asegura de que no se produzcan fugas de datos entre inquilinos?

La solución de Lokad segrega los datos de los inquilinos a través de su diseño, lo que garantiza que no se produzcan fugas de datos (incluso accidentales). Además, todo el código que se despliega en producción es revisado por pares, proporcionando así una capa adicional de protección. Finalmente, dirigimos a los investigadores de seguridad (personas que realizan pentests) para que investiguen específicamente la posibilidad de fugas de datos. Les damos acceso a múltiples cuentas de Lokad - en un entorno dedicado y completamente aislado que replica el de producción - para que puedan comprobar de manera exhaustiva esta propiedad de nuestra plataforma.

4.12 ¿Puede la solución ser containerizada?

Sí, pero hay poco o ningún beneficio en que la plataforma de Lokad sea contenedorizada. La contenedorización aporta valor cuando hay dependencias complejas (por ejemplo, una base de datos transaccional, un sistema de caché aislado, etc.). No usamos contenedores en producción ni en desarrollo, lo que mejora nuestra seguridad al eliminar clases enteras de vulnerabilidades. En cambio, mantenemos la solución lo suficientemente simple como para que el despliegue se pueda realizar incluso con pequeños scripts de shell.

4.13 ¿Pueden los componentes de la interfaz gráfica (GUI) desvincularse del backend?

Sí, los componentes de la GUI (en este caso, las interfaces web) son independientes. Este diseño ayuda a lograr una mayor disponibilidad. Los usuarios finales pueden acceder a los paneles de control de sus cuentas de Lokad incluso si una caída repentina afecta a alguno de los otros subsistemas.

4.14 ¿Soporta la aplicación de Lokad funciones de localización (como el cambio de idioma)?

Sí, la aplicación soporta funciones de localización. Todas las interfaces de usuario producidas por la plataforma de Lokad se pueden localizar a cualquier idioma. En particular, toda la pila tecnológica adopta UTF-8, para acomodar todos los conjuntos de caracteres que existen más allá del latino. En particular, cualquier interfaz de usuario producida por la plataforma de Lokad puede ser re-localizada - después de la entrega - a otro idioma.

4.15 ¿Es posible que los usuarios finales actualicen o creen nuevas traducciones después de la entrega de datos postprocesados de Lokad?

Sí, ver 4.14 arriba.

4.16 ¿Cuenta su sistema con una Ayuda incorporada? Si es así, ¿en qué idioma(s)?

Sí, Lokad viene con una documentación pública muy extensa (en inglés) public documentation. Sin embargo, usar la plataforma de Lokad implica la creación de interfaces de usuario hechas a la medida y nuestro proceso habitual involucra al menos dos formas de documentación o ayuda.

Primero, los paneles de control elaborados dentro de la solución de Lokad están diseñados para estar documentados contextualmente, directamente desde el propio panel. En particular, incluso contamos con un bloque Markdown dedicado a la documentación en texto enriquecido. Segundo, nuestros entregables incluyen un “Manual de Procedimiento Conjunto”. En general, el manual proporciona un análisis detallado no solo de la mecánica de la solución, sino también de por qué se seleccionó cada elemento (y cómo satisface las necesidades específicas de supply chain del cliente).

4.17 ¿Es responsive la aplicación web?

La aplicación web de Lokad, junto con sus materiales de soporte (como la documentación técnica), ha sido diseñada para ser responsive. Sin embargo, algunas capacidades avanzadas, como la edición de código, son poco prácticas para dispositivos móviles y/o tablets. Por lo tanto, el diseño está pensado para maximizar la capacidad de respuesta para las actividades previstas que se realicen en PCs y dispositivos más pequeños, respectivamente.

4.18 Si su sistema es una aplicación web, ¿qué navegador y versiones soporta? ¿Cuál es su estándar mínimo de navegador de internet?

Lokad es una aplicación web y soportamos los principales navegadores “evergreen” como Chrome, Firefox y Safari. No intentamos soportar navegadores antiguos por razones de seguridad, ya que apoyarlos pone en riesgo implícitamente a nuestros clientes. En pocas palabras, un navegador vulnerable puede ser aprovechado por un actor malicioso para exfiltrar datos. Dicho esto, también somos bastante conservadores en lo que respecta a las nuevas capacidades de los navegadores. Como regla general, evitamos soportar cualquier capacidad del navegador que no haya sido adoptada por todos los principales navegadores durante al menos 1 año.

4.19 Para aplicaciones móviles y de tablet, ¿qué sistemas operativos (y versiones) soporta Lokad?

N/A. Dado que Lokad es una aplicación web ofrecida como SaaS, a nuestros clientes no les preocupa el soporte del sistema operativo. Internamente, Lokad se desarrolla en Windows, mientras que todo nuestro entorno de producción en la nube se encuentra en Linux. Por lo tanto, tenemos bastante confianza en la amplia portabilidad de la solución de Lokad. Aunque no sentimos la necesidad actual de cambiar esta configuración, si se presentase evidencia válida, nos adaptaremos en consecuencia.

4.20 ¿Puede la aplicación web de Lokad proporcionar notificaciones a los usuarios finales? En caso afirmativo, ¿qué tecnología/protocolo se utiliza?

Sí, Lokad tiene la capacidad de enviar notificaciones mediante notificaciones programables de HTTP hook. Estos hooks pueden ser utilizados para emplear un sistema de terceros, frecuentemente ya presente en la empresa cliente, para enviar una notificación por correo electrónico o cualquier otro tipo de notificación considerada apropiada. Los hooks también se utilizan típicamente para señalar la disponibilidad de datos que se pueden recuperar de la plataforma de Lokad a través de SFTP o FTPS.

4.21 ¿Existen elementos compartidos en la solución que sean comunes a todos los clientes (como funciones de monitoreo, soluciones de respaldo o gestión de parches, etc.)?

Sí, dado que Lokad es una aplicación multiinquilino, las capacidades a nivel de infraestructura son compartidas entre todos los inquilinos, es decir, cuentas de clientes. Esto incluye monitoreo de disponibilidad, rendimiento y, por razones de seguridad, respaldo, gestión de parches, actualización, etc.

4.22 ¿Permite la solución la funcionalidad de mensajería a múltiples destinos (es decir, la capacidad de enviar un mensaje a más de un destinatario o aplicación)?

La plataforma de Lokad no opera con mensajes. Sin embargo, proporcionamos capacidades de HTTP-hook que se pueden utilizar para generar notificaciones de mensajes arbitrariamente complejas, típicamente a través de sistemas de terceros de bajo costo. Esas notificaciones son a veces utilizadas por equipos de supply chain para monitorear la finalización oportuna de lotes de cómputo críticos para la misión con la plataforma de Lokad.

4.23 ¿Utilizan todos los sistemas y componentes críticos la misma fuente de tiempo (NTP) o sincronizan sus relojes de alguna otra manera confiable?

Sí. Lokad utiliza el servicio NTP predeterminado que viene con Ubuntu - ntp.ubuntu.com. Más específicamente, se ejecuta ntpd como el servicio de sincronización de tiempo, el cual se sincroniza contra una fuente externa de tiempo NTP a la que se accede a través de la red.

4.24 ¿Existe una lista de inventario de activos o una base de datos de gestión de la configuración (CMDB)?

Sí, contamos con un software de gestión de activos de TI para apoyar nuestros procesos. Esta plataforma nos ayuda a mantener una lista de inventario de activos integral y actúa como nuestra base de datos de gestión de la configuración (CMDB). A través de este sistema, podemos rastrear, gestionar y asignar de manera eficiente los activos de hardware y software en toda la organización. Nuestros equipos tienen la capacidad de identificar rápidamente el estado, la ubicación y la configuración de cualquier activo, asegurando respuestas ágiles a cambios, actualizaciones o posibles problemas.

Además, nuestra herramienta proporciona funcionalidades que permiten una gestión detallada del ciclo de vida, asegurando que los activos estén catalogados con precisión desde la adquisición hasta el final de su vida útil. Las capacidades de auditoría automatizada, junto con las características de reporte detallado, garantizan que mantengamos plena visibilidad y control sobre nuestro entorno de TI, facilitando el cumplimiento y la asignación eficiente de recursos.

4.25 ¿Se termina cada conexión a una red externa en un firewall (por ejemplo, Internet, redes de socios)?

No, no terminamos cada conexión a una red externa en un firewall, ya sea Internet o redes de socios. Nuestra decisión se basa en preocupaciones del mundo real acerca de la efectividad e implicaciones de tales medidas.

Desde nuestra perspectiva, aunque los firewalls suelen verse como una defensa de primera línea, irónicamente pueden expandir la superficie de ataque. Cuantos más componentes y sistemas integremos, más puntos débiles potenciales introducimos. Los firewalls, debido a su naturaleza, operan como procesos de alto privilegio. Esto significa que se convierten en objetivos principales para los ciberataques, y cuando son comprometidos, los resultados pueden ser devastadores. Un caso ilustrativo es el ataque de SolarWinds, donde los mismos sistemas destinados a salvaguardar la información fueron explotados, lo que condujo a brechas significativas.

Además, la presencia de firewalls estrictos puede ser contraproducente en un sentido práctico. Nuestra experiencia ha demostrado que tales sistemas a menudo incentivan a los empleados a buscar medios alternativos para acceder y compartir información. Esto suele implicar eludir por completo la red corporativa (evitando así cualquier monitoreo), utilizando conexiones 4G o 5G personales desde sus propios dispositivos. Tales prácticas aumentan inadvertidamente el riesgo de brechas de seguridad y fugas de datos.

Así, aunque estamos profundamente comprometidos con la seguridad, nuestro enfoque es holístico y se basa en preocupaciones prácticas en lugar de depender únicamente de medidas tradicionales.

4.26 ¿Cuenta la red con un entorno DMZ que transmita, procese o almacene sistemas críticos (como servidores web, DNS, servicios de directorio y acceso remoto), así como datos de clientes?

No, Lokad no utiliza un entorno DMZ tradicional dentro de nuestra red para transmitir, procesar o almacenar sistemas críticos y datos de clientes. En cambio, hemos adoptado un enfoque de confianza cero para la seguridad de la red.

Este modelo no se basa en DMZs, sino que opera bajo el principio de “nunca confiar, siempre verificar”. Cada solicitud de acceso es validada y autenticada, sin importar su origen, ya sea interno o externo a la organización.

Esto asegura una postura de seguridad más robusta y holística, ya que no depende de defensas perimetrales como una DMZ, sino que se centra en asegurar cada punto de acceso individual y transacción de datos. Creemos que el enfoque de confianza cero ofrece una protección superior para nuestros sistemas críticos y datos de clientes.