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

La aplicación Lokad es una aplicación web proporcionada como SaaS (Software as a Service). El propósito de Lokad es ofrecer análisis predictivo para optimizar la cadena de suministro (mejores stocks, mejores precios, etc.). La aplicación Lokad está diseñada como una capa analítica que opera junto a sistemas transaccionales (ERP, WMS, CRM, etc.). Viene con una tarifa plana de suscripción mensual que generalmente incluye la aplicación en sí misma con servicios profesionales. Estos servicios profesionales, proporcionados por los ingenieros de Lokad (Supply Chain Scientists), eliminan casi por completo la necesidad de soporte técnico por parte del departamento de TI para este fin. La única contribución clave esperada del departamento de TI es la configuración de un canal de datos que envíe archivos planos (por SFTP o FTPS) a Lokad, y potencialmente reintegrar los resultados generados.

Público objetivo: El departamento de TI
Última modificación: 30 de noviembre de 2023

Resumen técnico

La aplicación Lokad es multiinquilino. Cada inquilino (es decir, cuenta de cliente) tiene su propio sistema de archivos dedicado y su propio repositorio de código dedicado. El sistema de archivos es accesible a través de FTPS, SFTP y una interfaz web. Este sistema de archivos está diseñado para archivos planos grandes (hasta 100 GB por archivo) y cuenta con versionado de datos (como Git). El repositorio de código se utiliza para alojar scripts de Envision. Envision es un DSL (Lenguaje de Programación Específico del Dominio) propietario desarrollado por Lokad. Este DSL está altamente especializado para casos de uso de optimización predictiva. Los scripts de Envision se utilizan para realizar los análisis numéricos principales (incluidos algoritmos de aprendizaje automático, solucionadores, …) y para generar paneles de datos ricos.

La aplicación se vuelve a implementar por completo todos los martes entre las 10:00 y las 14:00 (hora de París). El tiempo de inactividad se mantiene típicamente por debajo de 5 minutos. Lokad se hace cargo de todas las preocupaciones de versionado.

No se espera que el departamento de TI adquiera nunca ninguna competencia específica con la pila de Lokad. Sin embargo, si tienes curiosidad, hay una documentación técnica completa.

Resumen de la contribución de TI

Esperamos que el departamento de TI configure un canal de datos que envíe una breve serie de extracciones de archivos planos relevantes hacia Lokad por SFTP o FTPS. Las extracciones se realizan sobre los sistemas transaccionales (por ejemplo: ERP). Tenemos una fuerte preferencia por las extracciones de tablas en bruto (sin filtro, sin unión, sin transformación), lo que requiere un esfuerzo mínimo. Desde una perspectiva de ETL, solo requerimos la parte ‘E’ (extraer) en su forma más simple (copia simple). En cuanto al formato, Lokad es compatible con cualquier archivo plano tabular razonable.

Se espera que el canal de datos se ejecute al menos diariamente y que esté completamente automatizado. La cantidad de trabajo para el departamento de TI depende del alcance de la extracción de datos (¿qué sistemas? ¿qué tablas?). Sin embargo, como regla general, la configuración del canal de datos generalmente requiere alrededor de 15 a 45 días laborales, incluso para empresas grandes. Una vez que el canal de datos está en su lugar, Lokad generalmente requiere solo un monitoreo mínimo por parte del departamento de TI, que generalmente se realiza con 1 o 2 días laborales al mes.

Resumen de seguridad

La aplicación se aloja en centros de datos de Microsoft Azure ubicados en la UE. No procesamos datos personales, ya que no necesitamos dichos datos para operar. Al establecer el alcance de la extracción de datos, excluimos cualquier columna o campo que contenga datos personales.

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

A solicitud, nuestros 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

La Supply Chain Quantitativa se trata más de un viaje que de un fin en sí mismo. Sin embargo, al mismo tiempo, el liderazgo de la cadena de suministro que involucra a su empresa en llevar a cabo una iniciativa de Supply Chain Quantitativa requiere visibilidad cuando se trata de la línea de tiempo del proyecto. Si bien se pueden obtener retornos positivos en un par de meses, a menudo se tarda hasta dos años en desbloquear todo el potencial de la Supply Chain Quantitativa. En el siguiente fragmento, proporcionamos 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 empresas grandes, se deben esperar líneas de tiempo el doble de largas.

Inicio del proyecto: Los representantes de ambas partes se presentan entre sí y programan reuniones semanales. Estas reuniones semanales durarán hasta que se alcance la fase de Producción. El Supply Chain Scientist presenta las diferentes fases de implementación y los diversos entregables que el cliente puede esperar. El resto de la llamada se dedica a revisar varios detalles de la cadena de suministro y características de TI de la integración. Después de la llamada, se produce un resumen documentando los aspectos organizativos del proyecto y se envía al cliente.

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

1ra Carga de datos: Después de validar las especificaciones, el primer conjunto de datos se carga en los servidores de Lokad por parte del cliente. Generalmente, en esta etapa, la carga aún no se realiza a través de un proceso automatizado, ya que generalmente se requieren varios intentos para establecer un consenso sobre los detalles específicos de la especificación de datos.

Validación de los datos: El Supply Chain Scientist realiza una investigación exhaustiva del contenido del conjunto de datos del cliente. En particular, se introducen controles de integridad 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 correctamente la realidad del negocio y 3) el conjunto de datos sea coherente y lo suficientemente completo para fines de optimización de la cadena de suministro.

En cuanto a los entregables, durante esta fase el Supply Chain Scientist proporciona al cliente varios paneles de control que evalúan la salud de los datos. Estos paneles de control pueden ser utilizados por el cliente incluso para propósitos que van más allá de la iniciativa de Supply Chain Quantitativa en sí misma, como parte de su proceso interno de aseguramiento de la calidad de los datos, por ejemplo.

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

Automatización de la carga: Una vez que ambas partes validan la calidad general del conjunto de datos que se ha cargado hasta el momento, el cliente implementa un proceso automatizado que transfiere su conjunto de datos a Lokad de forma regular, idealmente a diario. Al mismo tiempo, en el lado de Lokad, la lógica de integridad de los datos, con sus múltiples controles, está programada para actualizarse después de cada carga.

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

Retroalimentación y ajuste fino: Las solicitudes del cliente para realizar algún tipo de alteración o “ajuste” en las diferentes salidas generalmente conducen a un ajuste fino de los scripts escritos por el Supply Chain Scientist. Hay muchos parámetros y métodos que se pueden adoptar para alinear adecuadamente las características de la cadena de suministro que se está optimizando con la lógica de optimización. Cuando la metodología en sí misma es de importancia estratégica para el cliente, esto se discute explícitamente entre el cliente y el Supply Chain Scientist.

Producción: Después de varias rondas de ajuste fino y revisión, el cliente llega a una etapa en la que confía en la lógica implementada por el Supply Chain Scientist. En este punto, el cliente puede comenzar a utilizar el servicio en producción, es decir, puede ejecutar directamente las decisiones de la cadena de suministro tal como fueron calculadas originalmente por el software. Cuando el cliente valida que la solución está lista para la producción, 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 ejecución diaria fluida del pipeline de datos. Se organizan llamadas regularmente entre el cliente y el Supply Chain Scientist para verificar que la optimización brinde el grado esperado de rendimiento de la cadena de suministro. Además, las cadenas de suministro no son estáticas, por lo tanto, los cambios comerciales o de TI, pequeños o grandes, deben ser revisados: un nuevo almacén, cambio en el mercado, nuevo proceso, etc. El Supply Chain Scientist propone modificaciones adecuadas para adaptarse a estos diferentes cambios. Se programan llamadas de control con una frecuencia acordada, típicamente mensual.

Preguntas frecuentes (FAQ)

1. Gestión de versiones

1.1 ¿Cómo funcionan las versiones para Lokad?

Lokad maneja todas las versiones internamente, lo que ayuda a garantizar una transparencia completa para los clientes. Cualquier versión que pueda afectar a un cliente se coordina con ellos, a través de los equipos técnicos del cliente, con suficiente antelación. En general, Lokad adopta un enfoque cauteloso con las versiones: si una versión programada no proporcionaría suficiente tiempo de preparación para un cliente, la versión se pospondría temporalmente.

Las versiones de Lokad son muy detalladas, y el diseño generalmente permite al cliente optar por no participar en un elemento técnico particular de una versión general. Por lo tanto, si debemos posponer la implementación de un elemento, para el cual nuestro cliente aún no está listo, la versión general aún puede tener lugar (e implementar los otros elementos que no afectan).

1.2 ¿Con qué frecuencia se lanzan las versiones?

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

1.3 ¿Proporcionan un plan de las próximas versiones?

Sí, consulta Gestión de versiones 1.2.

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

Lokad redeploya, a través de medios automatizados (scripts), su propia solución. No parcheamos sistemas en producción. Si tenemos un “parche de seguridad” para implementar, redeployaremos la solución a través de nuestros medios automatizados habituales.

1.5 ¿Cuánto tiempo lleva aplicar una versión importante?

El proceso automatizado lleva aproximadamente 1 hora. Hay una implementación gradual (máquina por máquina), ya que pretendemos mantener operativa y accesible la plataforma de Lokad durante la versión. La operatividad durante una implementación se discute en Gestión de versiones 1.7.

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

El equipo de Lokad se hace cargo de la correcta ejecución de la versión.

1.7 ¿Hay tiempo de inactividad durante la versión?

Principalmente no, pero ten en cuenta que la solución de Lokad es un sistema distribuido dedicado a cálculos a gran escala. Como tal, el impacto de una versión difiere entre los sistemas de front-end y back-end. Los subsistemas orientados al cliente, como los paneles de control, están diseñados para no tener tiempo de inactividad. Los sistemas de back-end, como los encargados de la ejecución de trabajos por lotes, podrían pausarse durante unos minutos (al menos para algunos trabajos). Sin embargo, estos trabajos por lotes pueden programarse, por lo que la planificación proactiva debería permitir la finalización de los trabajos por lotes fuera del marco de tiempo de la versión.

1.8 ¿Cuál es su proceso o estrategia de prueba para una versión?

Lokad utiliza procesos automatizados dedicados a probar y garantizar la corrección de una próxima versión. Estos procesos incluyen extensas suites de pruebas automatizadas (medidas en miles); pruebas unitarias, pruebas funcionales, pruebas de rendimiento, etc. También hemos desarrollado herramientas dedicadas que nos permiten reproducir secuencias completas de ejecuciones de trabajos pasados dentro de la plataforma de Lokad. Estas herramientas nos permiten verificar que los scripts de Envision tengan el mismo comportamiento antes/después de una próxima versión. Además, podemos verificar que los perfiles de rendimiento de los scripts existentes sigan estando en línea con las expectativas de programación, según lo definido por nuestros clientes.

1.9 ¿Tienen múltiples entornos?

Sí, sin embargo, los entornos alternativos (a nivel de plataforma, además del de producción) generalmente no están destinados a nuestros clientes. Además del entorno de producción y los entornos de desarrollo transitorios, tenemos un entorno ’evergreen’ que coincide con la última versión estable de nuestro código base. Esto valida un subconjunto específico de nuestros procesos de prueba automatizados. Nuestros clientes pueden acceder a nuestro entorno ’evergreen’ para validar que una próxima versión específica se comporte como se espera. Esta situación puede surgir si hay integración de TI 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 de Envision, entonces una cuenta de Lokad se puede dividir en múltiples “entornos”. Si el objetivo es poder realizar cualquier tipo de prueba, entonces se puede proporcionar una segunda cuenta de Lokad para fines 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 multiinquilino 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 una versión?

Como Lokad es un SaaS multiinquilino que ejecuta la misma versión única para todos los clientes, no es posible optar por no participar en una versión. Sin embargo, desde una perspectiva empresarial, esto es irrelevante ya que cualquier “cambio” se implementa a través de la ejecución de scripts de Envision dentro de la solución de Lokad.

Para situaciones en las que una versión pueda ser pospuesta temporalmente, consulte Gestión de versiones 1.1.

1.12 ¿Tienen notas de versión? ¿Las proporcionan a sus clientes?

Sí. Estas notas se comparten internamente (con nuestros equipos de científicos de la cadena de suministro). Si se acuerda explícitamente como parte de un contrato, estas notas de versión pueden hacerse accesibles para un cliente. En la práctica, las notas de versión de la plataforma de Lokad solo son de interés para las personas que trabajan con código de 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 “software + experto”, donde un equipo de científicos de la cadena de suministro de Lokad es responsable de la implementación y mantenimiento de la solución de cadena de suministro de un cliente. Estas situaciones se conocen como “cadena de suministro como servicio”. En este arreglo, el cliente interactúa rutinariamente con uno (o más) científicos de la cadena de suministro. Además, la mayoría de los clientes se benefician de un comité de dirección 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 un plan para la implementación de 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 de Lokad es programática por naturaleza. La lógica “analítica” de Lokad toma la forma de scripts de Envision, siendo Envision el DSL (Lenguaje Específico de Dominio) diseñado por Lokad con el propósito de la optimización predictiva de la cadena de suministro.

Por lo tanto, en cierto sentido, cada configuración de parámetros está disponible aprovechando los scripts de Envision dentro de la cuenta.

2. Rendimiento

2.1 ¿Su SLA (acuerdo de nivel de servicio) cubre un tiempo de actividad del 99.xy%?

Sí. El SLA es parte de nuestro acuerdo contractual por defecto. 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 cadenas de suministro - es compleja. Considere los siguientes escenarios: - Lokad recibe datos del cliente (un paso diario) con 2 horas de retraso. Esto bien podría interrumpir la eficiencia ordinaria de nuestras heurísticas de asignación de recursos. Esto, a su vez, puede prolongar el tiempo necesario para realizar los trabajos por lotes de Lokad (por ejemplo, 75 minutos en lugar de los habituales 60). Algunos pueden considerar esto como 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 muestran una caída considerable en los niveles de stock. Esto desencadenaría una interrupción de los trabajos por lotes (lado de Lokad) y alertaría a un Supply Chain Scientist para investigar el problema. El Supply Chain Scientist ve que un pedido de reposición automatizado es excepcionalmente grande. 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 habrían resultado en una gran cancelación de stock. Algunos pueden considerar esto como un tiempo de inactividad de 24 horas, pero eso parece prácticamente obtuso en contexto.

El mayor peligro para una solución de optimización de la cadena de suministro no es llegar un poco tarde; es estar muy equivocado. Una vez que se toma una decisión de la cadena de suministro, como (incorrectamente) activar un lote de producción, deshacerla puede ser extremadamente costoso. Alentamos 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 general inferior siempre y cuando parezca satisfacer un KPI (como el tiempo de actividad x.y%).

2.2 ¿Garantizan un tiempo de respuesta para las solicitudes de usuario dentro de X segundos?

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

Hemos diseñado lo que equivale aproximadamente a “paneles de tiempo constante”. Bajo el capó, la visualización de un panel requiere una sola solicitud a través de la red, y en nuestro backend, colocamos todos los datos del panel para mantener bajo el número de solicitudes de red (generalmente medidas en cifras simples). Esta elección de diseño va muy lejos para “garantizar” la baja latencia de la solicitud típica del usuario en la visualización de un panel. Esta elección de diseño también evita que el panel se llene de mosaicos, cada uno de los cuales requeriría solicitudes de red, y ralentice la experiencia general del usuario.

En cuanto a la duración de los trabajos por lotes, a través de Envision podemos proporcionar garantías - en tiempo de compilación - de que un trabajo por lotes se completará. También podemos garantizar tiempos de finalización en gran medida reproducibles para nuestros trabajos por lotes. Estas garantías se obtienen a través de un análisis estático y un diseño cuidadoso del lenguaje Envision, que hace posible ciertas clases de análisis estáticos en primer lugar. Este enfoque tiene límites, pero es vastamente superior a los diseños que no ofrecen garantías en absoluto.

Sin embargo, la latencia de extremo a extremo no está completamente en nuestras manos. 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 baja velocidad de banda ancha.

2.3 ¿Tienen 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 garantizar 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 evidenciado en estos registros.

2.4 ¿Es posible monitorear respuestas lentas o congestión?

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

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

2.5 ¿Tienen balanceadores de carga?

Sí. Los balanceadores de carga de Lokad están destinados principalmente a la confiabilidad en lugar de a propósitos de rendimiento. El balanceo de carga a nivel de red se realiza a través de la capa de red de la plataforma de computación en la nube que utilizamos (Microsoft Azure). Sin embargo, la distribución de la carga de trabajo de procesamiento de datos internos, manejada por la plataforma de Lokad, no se gestiona a través de balanceadores de carga, sino a través de un orquestador interno asociado con nuestra pila de compiladores.

2.6 ¿Agrupan recursos como conexiones de BD, sesiones, etc.?

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

2.7 ¿Soportan el procesamiento paralelo?

Sí. Envision (nuestro DSL) está diseñado en torno a la noción de ejecución paralela automática. La plataforma de Lokad aprovecha activamente la paralelización en múltiples niveles: a nivel del núcleo de la CPU a través de operaciones SIMD (Instrucción Única/Múltiples Datos); a nivel de la CPU a través de ejecuciones multinúcleo; y a nivel de clúster a través de computación distribuida. Dado que el procesamiento paralelo es un aspecto de diseño fundamental de Envision, la casi totalidad de las cargas de trabajo ejecutadas en la plataforma de Lokad se benefician de una extensa paralelización, por defecto, sin ningún esfuerzo específico por parte de nuestros clientes o nuestros científicos de la cadena de suministro.

2.8 ¿Soportan la caché de datos frecuentemente accedidos?

Sí. Sin embargo, la caché se introduce con frecuencia como una solución temporal para hacer frente a las limitaciones de rendimiento de las bases de datos transaccionales. Dado que la plataforma de 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 comprimir todo, ya que eso presentaría una vulnerabilidad de seguridad conocida como BREACH (Reconocimiento y Extracción del Navegador a través de la Compresión Adaptativa de Hipertexto). BREACH ocurre cuando se presentan 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 elabora la solicitud.

Para defenderse contra BREACH, Lokad deshabilita la compresión en todas las respuestas donde el tercer condición es verdadera. También comprimimos datos por razones 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 los retrasos de computación.

2.10 ¿Realizan pruebas de rendimiento?

Sí. Lokad tiene 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 implementada. Esta herramienta nos permite reproducir las mismas cargas de trabajo, como se observa en producción, y monitorear el rendimiento resultante; no solo en tiempo de reloj, sino considerando todos los recursos informáticos relevantes (memoria, ancho de banda, E/S, CPU, etc.).

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

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

Consulta Autorización 3.6 y Registro y Monitoreo 5.3 en nuestra documentación de Seguridad para obtener más información sobre “transacciones” 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 garantiza que los paneles de control 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, especialmente 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, como máximo, una preocupación secundaria en lo que respecta al rendimiento de la solución. En lo que respecta a la optimización predictiva de la cadena de suministro, los trabajos por lotes utilizados para realizar el análisis de interés representan más del 99% de la carga de trabajo. 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 de Lokad aprovecha ambas. El orquestador interno, el encargado de la paralelización, comienza típicamente con la escalabilidad vertical, ya que esta facilita en gran medida la colocació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 de Lokad es multiinquilino. A través del multiinquilinato, realizamos asignaciones de recursos informáticos a gran escala y baja latencia. Esto significa que el escalado automático de la computación que proporciona Lokad es órdenes de magnitud más rápido que la creación de grandes VM (máquinas virtuales) a partir de un proveedor de computación en la nube. El escalado automático del almacenamiento se realiza en gran medida aprovechando las propiedades de escalado automático de la tienda de clave-valor persistente, proporcionada por la plataforma de computación en la nube subyacente (Microsoft Azure).

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

La plataforma de Lokad ha sido diseñada específicamente para el procesamiento de “Big Data”. A partir de enero de 2023, toda la plataforma de Lokad maneja aproximadamente 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 Seguridad de Lokad 4.10

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

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

Sí, la aplicación web diseñada por Lokad ha sido diseñada para poder soportar escenarios donde la conectividad es “pobre” (tanto en términos de ancho de banda como de latencia). Estas preocupaciones se abordan principalmente mediante elecciones fundamentales de diseño tecnológico. Estas elecciones de diseño arquitectónico también diferencian a Lokad de la corriente principal. Las preocupaciones sobre el ancho de banda se abordan de dos maneras. Primero, somos parcimoniosos cuando se trata de componentes de terceros en JavaScript. Tenemos menos de 1MB de activos que se deben recuperar inicialmente. En segundo lugar, la plataforma ofrece un control completo sobre la cantidad de datos que se incluirán en cualquier panel único. Por lo tanto, si la conectividad es deficiente, es posible hacer que el panel sea apropiadamente “ligero”. En cuanto a las preocupaciones de latencia, nuestros paneles han sido diseñados para empaquetar todos los datos relevantes del panel en una sola solicitud HTTP. Esto minimiza la fricción incurrida por los usuarios finales de baja latencia.

2.17 ¿Cuáles son las capacidades de rendimiento de datos promedio y pico de la solución en comparación con un punto de referencia de 1 (bajo) y 5 (alto) 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 vastos conjuntos de datos de transacciones. La plataforma de Lokad maneja, en conjunto, más de 1 petabyte de datos. Rutinariamente 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 pasos de aprendizaje automático y optimización matemática.

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

La plataforma de Lokad no opera con mensajes. Lo más cercano serían los “archivos planos”. Estos archivos planos pueden enviarse a Lokad y recuperarse de él. La plataforma de Lokad puede procesar archivos que individualmente son tan grandes como 100GB. Sin embargo, esta no es una práctica recomendada, ya que suele ser un poco engorrosa (no para Lokad, sino para los clientes que tendrán que familiarizarse con herramientas externas para producir y consumir los archivos grandes).

3. Incidentes

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

La mayoría de nuestros clientes se benefician de un paquete que incluye acceso a nuestro equipo de científicos de la cadena de suministro. Estos científicos de la cadena de suministro son el primer punto de contacto para informar incidentes. En caso de un incidente, sugerimos a los clientes que llamen directamente a su científico de la cadena de suministro, si el problema es urgente, o envíen un correo electrónico. Los científicos de la cadena de suministro se encargan de la gestión de incidentes, incluidas las escaladas dentro de la organización de Lokad.

3.2 ¿Ofrecen un sistema de tickets?

Sí. Lokad aprovecha un sistema de tickets de terceros. Sin embargo, a partir de enero de 2023, hemos comenzado a desarrollar una solución interna que ofrece una integración estrecha con el resto de nuestra plataforma.

3.3 ¿Apoyan la presentación de incidentes a herramientas de terceros?

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

En el contexto de la optimización predictiva de la cadena de suministro, los “incidentes” pueden variar y ser difíciles de definir. Generalmente, nuestros clientes no consideran eventos menores a nivel de plataforma (como tiempos de inactividad mínimos) como “incidentes”. Más bien, las rarezas reales de la cadena de suministro, que pueden o no reflejar problemas con los scripts de Envision implementados en la cuenta del cliente, serían mejores candidatos. Los departamentos de TI externos rara vez participan en la resolución de estos incidentes.

3.4 ¿Cómo garantizan una alta disponibilidad?

Lokad se convirtió en un pionero (c. 2010) en plataformas de computación en la nube precisamente para garantizar una mayor disponibilidad. Además de hacer redundante la infraestructura (ver Incidentes 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 (casi en un orden de magnitud). Una enorme capa de complejidad ausente de nuestra solución es una base de datos transaccional. Al tener menos piezas en movimiento, tenemos muchos menos modos de falla, lo que nos ayuda a mantener una alta disponibilidad para nuestros clientes (que están distribuidos en varios husos horarios).

3.5 ¿Tienen una infraestructura redundante (si es así, cómo)? ¿Evitan puntos únicos de falla?

Sí. Nuestros sistemas críticos son redundantes, precisamente para evitar puntos únicos de falla. Los sistemas redundantes incluyen los subsistemas que admiten protocolos estatales como SFTP. Además, el almacenamiento de datos no solo es redundante, sino también geográficamente redundante. Esta redundancia se aprovecha durante nuestras versiones para preservar el tiempo de actividad mientras se realiza la implementación.

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

La recuperación de la mayoría de las fallas 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 garantiza que las fallas de hardware transitorias no afecten el tiempo de actividad mientras la plataforma de computación en la nube asigna un nuevo recurso no defectuoso. Para el almacenamiento de datos persistente, Lokad solo aprovecha servicios (es decir, almacenes clave-valor) que están protegidos contra fallas de hardware a través de sus propias capas de redundancia.

3.7 ¿Tienen una copia de seguridad?

Sí. Tenemos un entorno de copia de seguridad dedicado para escenarios graves de recuperación de desastres (más allá de un tiempo de inactividad a nivel de centro de datos). Este entorno de copia de seguridad está completamente aislado del entorno de producción. El entorno de copia de seguridad puede leer del entorno de producción (pero no escribir), mientras que el entorno de producción no puede leer ni escribir en el de copia de seguridad.

3.8 ¿Tienen un plan de recuperación de desastres?

Sí. A nivel técnico, el plan de recuperación de desastres cubre la completa reinstalación de la plataforma de Lokad. Esta parte aprovecha extensamente los procesos automatizados que tenemos en marcha para nuestras versiones semanales. A nivel empresarial, el plan de recuperación de desastres incluye contactar a cada cliente que tenemos, siguiendo típicamente un proceso acordado con cada uno. Para la mayoría de nuestros clientes, los científicos de la cadena de suministro designados actúan como los puntos de contacto principales durante la recuperación.

3.9 ¿La solución admite la recuperación en un momento específico (PITR) en toda la base de datos y 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 cuenta con un diseño de protección continua de datos a través de la copia de seguridad incremental en vivo tanto de su almacén de eventos como de su fuente de contenido. Por lo tanto, podemos hacer 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 se ven comprometidos. Logramos esto aprovechando las escrituras geográficamente redundantes de nuestro almacén de valores clave persistente. Si el almacén de valores clave se ve comprometido, Lokad se recupera de su almacenamiento de respaldo (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 de violación de integridad? ¿La solución tiene la capacidad de agregar o extender controles 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 almacén de eventos, adoptando un diseño de origen de eventos en lugar de uno relacional. Esto no elimina la necesidad de hacer cumplir la integridad de los datos, pero esas preocupaciones se abordan de formas alternativas.

En lo que respecta al procesamiento de datos de clientes, Envision (DSL de Lokad) tiene capacidades extensas orientadas a verificar su calidad. A través de Envision, es posible verificar la integridad y generar alertas. Esta lógica puede ser extendida o modificada de cualquier manera que el cliente considere apropiada.

3.11 ¿Se prueban periódicamente las copias de seguridad para garantizar la funcionalidad adecuada de restauración de datos?

Sí. El diseño de origen de eventos de Lokad, combinado con su almacén de direcciones de contenido, hace que las pruebas de copia de seguridad y funcionalidad de restauración de datos sean mucho más sencillas que para la mayoría de los diseños convencionales que utilizan bases de datos relacionales (como SQL).

Ver también Incidentes 3.7.

3.12 ¿Se prueban periódicamente los planes de recuperación de desastres para garantizar la funcionalidad adecuada de recuperación de desastres?

Sí. La estrategia de implementación de Lokad aprovecha scripts automatizados de extremo a extremo, manteniendo deliberadamente muy pocas intervenciones humanas, siendo una excepción notable la capacidad de desencadenar una redistribución completa de producción. Este enfoque altamente automatizado facilita las pruebas de funcionalidad de recuperación de desastres.

Ver Incidentes 3.8.

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

Sí. Nuestra herramienta interna admite la posibilidad de restaurar la cuenta de un cliente seleccionado (incluida la restauración de la cuenta/entorno a un momento dado). Sin embargo, considerando que la plataforma de Lokad en sí misma cuenta con amplias capacidades de versionado (por ejemplo, los scripts de Envision están versionados y las versiones anteriores son accesibles desde la aplicación), esta capacidad rara vez se utiliza.

3.14 ¿Los planes de copia de seguridad y recuperación de desastres cumplen con los objetivos de tiempo de recuperación (RTO), punto de recuperación (RPO) y requisitos de escenarios de desastre de los clientes (según lo definido y acordado con los respectivos clientes)?

Sí. El Objetivo de Tiempo de Recuperación (RTO) se referiría aquí al tiempo que la plataforma de Lokad podría estar teóricamente inactiva sin causar daños significativos al cliente, así como el tiempo dedicado a 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 admitidos/proveídos por Lokad. Por ejemplo, un cliente que depende de Lokad para programar pedidos mensuales de compras en el extranjero puede tener un RTO de 1 semana. Por el contrario, un cliente que depende de Lokad para optimizar el despacho diario de inventario desde un almacén a múltiples tiendas puede 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, las decisiones de conmutación por error pueden calcularse con antelación. 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 conmutación por error pueden mostrar un rendimiento de suministro ligeramente degradado dado que (por definición) no aprovecharían los datos más recientes de forma absoluta.

Para nuestras cuentas gestionadas, es responsabilidad del Supply Chain Scientist de Lokad elaborar conjuntamente un proceso, junto con los equipos operativos del cliente, que proporcione un alto RTO, pero también que garantice un impacto comercial mínimo en caso de incidente real. Desde nuestra perspectiva, este desafío es ante todo un problema de la cadena de suministro en lugar de uno de TI.

Ver también Incidentes 3.9.

3.15 Si un defecto no es reproducible en el entorno de prueba, ¿puede Lokad verificar que el defecto ha ocurrido a partir de registros y datos de soporte, y asegurar que el defecto se corrija según el Acuerdo de Nivel de Servicio (SLA)?

Sí, los defectos pueden reproducirse en nuestros entornos. La reproducibilidad estricta de todos los estados de datos y todos los cálculos es un principio de diseño fundamental de la plataforma y 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 destacar que los registros son más efectivos para solucionar problemas triviales, como la caída del servidor. Cuando se trata de solucionar problemas complejos y defectos en un entorno de datos a gran escala, donde están involucrados terabytes de datos, los registros a menudo son insuficientes.

Por lo tanto, si bien Lokad mantiene y consulta registros cuando es apropiado, no confiamos en los registros para abordar defectos o verificar que los defectos se hayan corregido. En su lugar, principalmente aprovechamos elecciones de diseño superiores para proporcionar una mayor visibilidad, trazabilidad y reproducibilidad.

Estas elecciones de diseño deliberadas nos permiten identificar, reproducir y corregir defectos de una manera que no permitiría depender puramente de los registros.

Por favor, revise Arquitectura de Lokad para obtener un desglose detallado de las varias elecciones de diseño clave que adoptamos para evitar clases enteras de problemas comunes de software.

3.16 ¿Mantiene registros de todas las solicitudes de servicio y llamadas de servicio (incluida la categoría de cada llamada) realizadas por la empresa cliente? ¿Los registros incluyen: la identidad de la persona que llama y 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 tiene capacidades de gestión de tareas/tickets/incidencias que proporcionan los detalles mencionados.

En cuanto a las “resoluciones”, cabe destacar que la filosofía de supply chain quantitativa de Lokad (QSC) se trata de encontrar el compromiso más beneficioso financieramente cuando se presenta un problema. QSC no es, técnicamente, un enfoque de “solución de problemas”, ya que los problemas de la cadena de suministro no son problemas que se “solucionan”, sino que se atenúan haciendo compromisos financieramente informados.

En resumen, Lokad posee las herramientas y procesos para resolver rápidamente “problemas sencillos” (como la caída del servidor) de manera directa. Cuando se trata de problemas más grandes y significativos de la cadena de suministro (como la asignación de stock minorista o problemas de reposición de inventario), estos suelen ser discusiones más abiertas y continuas con los clientes sobre qué compromisos maximizan su retorno de inversión.

4. Arquitectura

4.1 ¿Qué lenguajes de programación utilizan?

La plataforma de Lokad está desarrollada en C#, F# y TypeScript. La plataforma también cuenta con Envision (DSL de Lokad), que se utiliza para implementar soluciones de cadena de suministro específicas para el cliente.

4.2 ¿Qué suite de desarrollo utilizan?

Los equipos de ingeniería de software de Lokad utilizan Microsoft Visual Studio. Los equipos de científicos de la cadena de suministro utilizan la propia plataforma de Lokad, que cuenta con su propia suite de desarrollo.

4.3 ¿Qué sistema operativo admiten?

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

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

Lokad admite todos los sistemas de base de datos que pueden producir exportaciones de archivos planos. Esto incluye prácticamente todos los sistemas de base de datos del mercado, incluidos los modelos más antiguos. Internamente, Lokad no utiliza un sistema de base de datos, sino un almacén de clave-valor. En el momento de escribir esto (enero de 2023), utilizamos Blob Storage proporcionado por Microsoft Azure.

4.5 ¿Qué sistema de almacenamiento en caché utilizan?

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

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

Lokad aprovecha Let’s Encrypt a través de renovaciones automáticas de certificados.

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

El requisito técnico principal es un sistema de transacciones que lleve un registro de su inventario. Además, es útil si el cliente tiene experiencia extrayendo datos (como archivos planos) de sus sistemas transaccionales, pero esto ciertamente no es un requisito previo.

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

N/A. Lokad no requiere ninguna licencia de terceros para operar. Existe una amplia variedad 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 indirectamente, para beneficiarse de la plataforma Lokad.

4.9 ¿La aplicación requiere algún complemento de navegador o software especial?

Lokad es una aplicación web. No requiere complementos de navegador ni ningún 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, a saber, SFTP y FTPS.

4.11 ¿Cómo se asegura de que no haya 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 ocurran fugas de datos (incluso accidentales). Además, todo el código enviado a producción es revisado por pares, lo que proporciona una capa adicional de protección. Finalmente, dirigimos a investigadores de seguridad (personas que realizan pruebas de penetración) para investigar específicamente la posibilidad de fugas de datos. Les damos acceso a varias cuentas de Lokad, en un entorno dedicado y completamente aislado que refleja el de producción, para que puedan verificar agresivamente esta propiedad de nuestra plataforma.

4.12 ¿Puede la solución ser contenerizada?

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

4.13 ¿Pueden los componentes de la GUI estar desacoplados del backend?

Sí, los componentes de la GUI (en este caso, 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 uno de los otros subsistemas.

4.14 ¿La aplicación de Lokad admite funciones de localización (como cambiar de idioma)?

Sí, la aplicación admite funciones de localización. Todas las interfaces de usuario producidas por la plataforma de Lokad pueden ser localizadas en cualquier idioma. En particular, toda la pila tecnológica adopta UTF-8, para poder acomodar todos los juegos de caracteres que existen más allá del latino. En particular, cualquier interfaz de usuario producida por la plataforma de Lokad puede ser relocalizada, 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 los datos postprocesados de Lokad?

Sí, ver 4.14 arriba.

4.16 ¿Su sistema tiene una Ayuda incorporada? Si es así, ¿en qué idioma(s)?

Sí, Lokad viene con una documentación pública muy extensa (en inglés). Sin embargo, el uso de la plataforma Lokad implica la creación de interfaces de usuario personalizadas y nuestro proceso regular implica al menos dos formas de documentación o ayuda.

En primer lugar, los paneles elaborados dentro de la solución de Lokad están destinados a ser documentados contextualmente, directamente desde el panel mismo. En particular, incluso tenemos una ficha de Markdown dedicada a la documentación de texto enriquecido. En segundo lugar, 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 la cadena de suministro del cliente).

4.17 ¿Es la aplicación web de Lokad receptiva?

La aplicación web de Lokad, junto con sus materiales de soporte (como la documentación técnica), ha sido diseñada para ser receptiva. Sin embargo, algunas capacidades avanzadas, como la edición de código, son imprácticas para dispositivos móviles y/o tabletas. Por lo tanto, el diseño está destinado a maximizar la receptividad para las actividades anticipadas realizadas en PC y dispositivos más pequeños, respectivamente.

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

Lokad es una aplicación web y admitimos los principales navegadores web “evergreen” como Chrome, Firefox y Safari. No intentamos admitir navegadores antiguos por razones de seguridad, ya que admitir esos navegadores pone en peligro implícitamente a nuestro(s) cliente(s). En pocas palabras, un navegador vulnerable puede ser aprovechado por un actor malicioso para extraer datos. Dicho esto, también somos bastante conservadores cuando se trata de nuevas capacidades del navegador. Como regla general, evitamos admitir cualquier capacidad del navegador que no haya sido adoptada por todos los principales navegadores web durante al menos 1 año.

4.19 Para aplicaciones móviles y de tableta, ¿qué SO (y versiones) admite Lokad?

N/A. Como Lokad es una aplicación web servida como SaaS, nuestros clientes no se preocupan por el soporte del SO. Internamente, Lokad se desarrolla en Windows, mientras que todo nuestro entorno de producción alojado en la nube está en Linux. Por lo tanto, tenemos bastante confianza en la amplia portabilidad de la solución de Lokad. Aunque no sentimos ninguna necesidad presente de cambiar esta configuración, si se presenta evidencia válida, nos adaptaremos en consecuencia.

4.20 ¿Puede la aplicación web de Lokad proporcionar notificaciones a los usuarios finales? Si es así, ¿qué tecnología/protocolo se aprovecha?

Sí, Lokad tiene la capacidad de enviar notificaciones a través de notificaciones de gancho HTTP programables. Estos ganchos se pueden aprovechar para utilizar un sistema de terceros, frecuentemente ya en su lugar en la empresa cliente, para enviar una notificación por correo electrónico u otro tipo de notificaciones alternativas consideradas apropiadas. Los ganchos 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 ¿Hay elementos compartidos en la solución que son comunes a todos los clientes (como funciones de monitoreo, soluciones de respaldo o gestión de parches, etc.)?

Sí, como Lokad es una aplicación multiinquilino, las capacidades a nivel de infraestructura se comparten entre/entre inquilinos, es decir, cuentas de clientes. Esto incluye monitoreo de tiempo de actividad, 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 con 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 gancho HTTP que se pueden utilizar para generar notificaciones de mensajes arbitrariamente complejas, típicamente a través de sistemas de terceros de bajo costo. A veces, los equipos de la cadena de suministro utilizan estas notificaciones para monitorear la finalización oportuna de lotes de cálculos críticos para la misión con la plataforma de Lokad.

4.23 ¿Todos los sistemas y componentes críticos utilizan 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, ntpd se ejecuta como el servicio de sincronización de tiempo, que se sincroniza con una fuente de tiempo NTP externa 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 configuración (CMDB)?

Sí, tenemos un software de gestión de activos de TI para respaldar nuestros procesos. Esta plataforma nos ayuda a mantener una lista de inventario de activos completa y actúa como nuestra base de datos de gestión de configuración (CMDB). A través de este sistema, podemos realizar un seguimiento, gestionar y asignar eficientemente 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 rápidas 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 automatizadas, junto con funciones detalladas de informes, garantizan que mantengamos una visibilidad y control completos sobre nuestro entorno de TI, facilitando el cumplimiento y una 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 en Internet o en redes de socios. Nuestra decisión se basa en preocupaciones del mundo real sobre la efectividad e implicaciones de tales medidas.

Desde nuestra perspectiva, si bien los firewalls suelen verse como una defensa de primera línea, irónicamente pueden ampliar la superficie de ataque. Cuantos más componentes y sistemas integramos, 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 se ven 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 llevó a brechas significativas.

Además, la presencia de firewalls estrictos puede ser contraproducente en un sentido práctico. Nuestra experiencia ha demostrado que dichos 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 (impidiendo así cualquier monitoreo), utilizando conexiones personales 4G o 5G desde sus propios dispositivos. Tales prácticas aumentan inadvertidamente el riesgo de brechas de seguridad y filtraciones de datos.

Por lo tanto, si bien estamos profundamente comprometidos con la seguridad, nuestro enfoque es holístico y está informado por preocupaciones prácticas en lugar de depender únicamente de medidas tradicionales.

4.26 ¿La red tiene un entorno de zona desmilitarizada (DMZ) que transmite, procesa o almacena 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 su lugar, hemos adoptado un enfoque de confianza cero para la seguridad de la red.

Este modelo no se basa en DMZs, sino que opera en el principio de “nunca confiar, siempre verificar”. Cada solicitud de acceso se valida y autentica, independientemente de su origen, ya sea desde dentro o fuera de la organización.

Esto garantiza una postura de seguridad más sólida 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.