FAQ: Information Technology (IT)

L’app di Lokad è una webapp fornita come SaaS (Software as a Service). Lo scopo di Lokad è fornire analisi predictive per ottimizzare la supply chain (migliori scorte, migliori prezzi, ecc.). L’app di Lokad è concepita come un livello analitico che opera accanto ai sistemi transazionali (ERP, WMS, CRM, ecc.). Viene fornita con una tariffa mensile fissa che di solito include l’app stessa e servizi professionali. Questi servizi professionali, forniti dagli ingegneri di Lokad (Supply Chain Scientists), riducono quasi completamente la necessità di supporto tecnico da parte del dipartimento IT per questo scopo. Il contributo principale richiesto dal dipartimento IT è la configurazione di un flusso di dati che invia file flat (tramite SFTP o FTPS) a Lokad e potenzialmente reintegra i risultati generati.

Pubblico di destinazione: Dipartimento IT
Ultima modifica: 30 novembre 2023

Panoramica tecnica

L’app di Lokad è multitenant. Ogni tenant (cioè account cliente) ha il proprio file system dedicato e il proprio repository di codice dedicato. Il file system è accessibile tramite FTPS, SFTP e un’interfaccia web. Questo file system è orientato verso grandi file flat (fino a 100 GB per file) e offre il versioning dei dati (come Git). Il repository di codice viene utilizzato per ospitare gli script Envision. Envision è un DSL (Domain Specific programming Language) proprietario sviluppato da Lokad. Questo DSL è fortemente specializzato per casi d’uso di ottimizzazione predittiva. Gli script Envision vengono utilizzati per eseguire le analisi numeriche di base (inclusi algoritmi di machine learning, risolutori, …) e per generare dashboard ricche di dati.

L’app viene ripubblicata completamente ogni martedì tra le 10:00 e le 14:00 (ora di Parigi). Il tempo di inattività viene di solito mantenuto inferiore a 5 minuti. Lokad si occupa completamente di tutte le questioni di versioning.

Non ci si aspetta che il dipartimento IT acquisisca mai competenze specifiche con la stack di Lokad. Tuttavia, se sei curioso, c’è una documentazione tecnica completa.

Panoramica del contributo IT

Ci aspettiamo che il dipartimento IT configuri un flusso di dati che invii una breve serie di estrazioni di file flat pertinenti a Lokad tramite SFTP o FTPS. Le estrazioni vengono eseguite sui sistemi transazionali (ad esempio ERP). Abbiamo una forte preferenza per le estrazioni di tabelle grezze (senza filtri, senza join, senza trasformazioni), che richiedono uno sforzo minimo. Dal punto di vista ETL, richiediamo solo la parte ‘E’ (estrarre) nella sua forma più semplice (copia semplice). Per quanto riguarda il formato, Lokad è compatibile con ogni file flat ragionevolmente tabulare.

Ci aspettiamo che il flusso di dati venga eseguito almeno su base giornaliera e che sia completamente automatizzato. La quantità di lavoro per il dipartimento IT dipende dallo scopo dell’estrazione dei dati (quali sistemi? quali tabelle?). Tuttavia, come regola generale, la configurazione del flusso di dati richiede tipicamente circa 15-45 giorni-uomo, anche per grandi aziende. Una volta che il flusso di dati è in funzione, Lokad richiede di solito solo un monitoraggio minimo da parte del dipartimento IT, che di solito viene effettuato con 1 o 2 giorni-uomo al mese.

Panoramica della sicurezza

L’app è ospitata nei data center di Microsoft Azure situati nell’UE. Non elaboriamo dati personali, poiché non ne abbiamo bisogno per operare. Quando si stabilisce lo scopo dell’estrazione dei dati, escludiamo qualsiasi colonna o campo che contenga dati personali.

Per l’autenticazione, la nostra preferenza va a SAML. Suggeriamo vivamente di far accedere gli utenti a Lokad tramite un’identità federata come Azure Active Directory, Office 365 o Google Workspace. Questo elimina tutti i problemi legati alle password.

Su richiesta, possono essere effettuati audit di sicurezza e test di penetrazione da parte dei nostri clienti. I dettagli dipendono dagli accordi negoziati.

Per ulteriori dettagli, consulta Sicurezza di Lokad.

Panoramica della linea temporale

La Supply Chain Quantitativa è più un percorso che un fine in sé. Tuttavia, allo stesso tempo, la leadership della supply chain che coinvolge la propria azienda in un’iniziativa di Supply Chain Quantitativa richiede visibilità quando si tratta della linea temporale del progetto. Mentre si possono ottenere rendimenti positivi in un paio di mesi, spesso ci vogliono fino a due anni per sbloccare tutto il potenziale della Supply Chain Quantitativa. Nel pezzo seguente, forniamo una panoramica di una tipica linea temporale associata a un’iniziativa di Supply Chain Quantitativa per un’azienda di medie dimensioni. Per le grandi aziende, ci si dovrebbe aspettare che i tempi siano il doppio.

Avvio del progetto: I rappresentanti di entrambe le parti si presentano reciprocamente e pianificano incontri settimanali. Questi incontri settimanali dureranno fino al raggiungimento della fase di produzione. Lo Supply Chain Scientist presenta le diverse fasi di implementazione e i vari deliverable che il cliente può aspettarsi. Il resto della chiamata è dedicato alla revisione dei vari dettagli della supply chain e delle caratteristiche IT dell’integrazione. Dopo la chiamata, viene prodotto un riassunto che documenta gli aspetti organizzativi del progetto e viene inviato al cliente.

Specifiche dei dati: Poco dopo l’incontro di avvio, lo Supply Chain Scientist produce le specifiche dei dati necessarie per l’implementazione del progetto. Queste specifiche vengono revisionate e validate insieme al cliente. In particolare, questo documento deve definire i dati da estrarre dai sistemi IT del cliente. Come regola generale, l’estrazione dovrebbe rimanere il più possibile vicina ai dati originali come esistono nei sistemi IT del cliente.

1° caricamento dei dati: Dopo aver validato le specifiche, il primo set di dati viene caricato sui server di Lokad dal cliente. In genere, in questa fase, il caricamento non viene ancora effettuato tramite un processo automatizzato poiché di solito sono necessari diversi tentativi per stabilire un consenso sui dettagli delle specifiche dei dati.

Validazione dei dati: Lo Supply Chain Scientist effettua un’indagine approfondita del contenuto del dataset del cliente. In particolare, vengono introdotti controlli di coerenza per monitorare la qualità dei dati secondo diverse metriche. L’obiettivo è assicurarsi che 1) il dataset venga correttamente aggiornato dal processo di caricamento, 2) il dataset rifletta correttamente la realtà del business e 3) il dataset sia coerente e completo a sufficienza per scopi di ottimizzazione della supply chain.

In termini di deliverable, durante questa fase lo Supply Chain Scientist fornisce al cliente vari cruscotti che valutano la salute dei dati. Questi cruscotti possono essere utilizzati dal cliente anche per scopi che vanno oltre l’iniziativa di Supply Chain Quantitativa stessa, ad esempio come parte del loro processo interno di controllo della qualità dei dati.

Audit di metà progetto: 6 settimane dopo l’avvio iniziale, viene programmato un incontro per valutare lo stato di completamento del progetto. L’obiettivo di questo “audit” è affrontare, il prima possibile, i problemi che potrebbero essere riscontrati durante l’implementazione, in particolare quelli che potrebbero ritardare la fase di produzione. Presso Lokad, questo “audit” consiste in uno scambio tra lo Supply Chain Scientist e il cliente, basato su una checklist che viene comunicata al cliente in anticipo dallo Supply Chain Scientist, subito dopo l’incontro di avvio.

Automazione del caricamento: Una volta che entrambe le parti hanno validato la qualità complessiva del dataset che è stato caricato finora, il cliente implementa un processo automatizzato che trasferisce il proprio dataset a Lokad regolarmente, idealmente ogni giorno. Allo stesso tempo, sul lato di Lokad, la logica di controllo della salute dei dati - con i suoi molteplici controlli - viene pianificata per essere aggiornata dopo ogni caricamento.

Configurazione dell’ottimizzazione: Da questo punto in poi, lo Supply Chain Scientist ha tutti gli ingredienti necessari per implementare l’ottimizzazione delle decisioni che sono state concordate in precedenza con il cliente. Pertanto, implementa script per generare diversi output quantitativi: suggerimenti operativi per gli acquisti, suggerimenti per le spedizioni, ecc. Le cifre prodotte da questi script possono essere visualizzate sotto forma di dashboard. In questa fase, queste dashboard rappresentano solo una versione preliminare delle dashboard finali e devono essere riviste insieme al cliente.

Feedback e perfezionamento: Le richieste del cliente di apportare qualche tipo di modifica o “aggiustamento” ai diversi output di solito portano a un perfezionamento degli script scritti dallo Supply Chain Scientist. Ci sono molti parametri e metodi che possono essere adottati per allineare adeguatamente le caratteristiche della supply chain che viene ottimizzata con la logica di ottimizzazione. Quando la metodologia stessa è di importanza strategica per il cliente, ciò viene discusso esplicitamente tra il cliente e lo Supply Chain Scientist.

Produzione: Dopo diverse fasi di perfezionamento e revisione, il cliente raggiunge una fase in cui inizia a fidarsi della logica implementata dallo Supply Chain Scientist. A questo punto, il cliente può iniziare a utilizzare il servizio in produzione, ovvero può eseguire direttamente le decisioni della supply chain come originariamente calcolate dal software. Quando il cliente convalida che la soluzione è pronta per la produzione, lo Supply Chain Scientist fornisce una documentazione che garantisce la manutenibilità della soluzione.

Supporto e manutenzione: La soluzione è operativa e viene utilizzata dal cliente mentre lo Supply Chain Scientist monitora l’esecuzione quotidiana regolare del flusso di dati. Vengono organizzate regolarmente chiamate tra il cliente e lo Supply Chain Scientist per verificare che l’ottimizzazione fornisca il grado di prestazioni della supply chain previsto. Inoltre, le supply chain non sono statiche, quindi, i cambiamenti aziendali o IT, piccoli o grandi, devono essere riesaminati: un nuovo magazzino, spostamento del mercato, nuovo processo, ecc. Lo Supply Chain Scientist propone modifiche adeguate per adattarsi a questi diversi cambiamenti. Le chiamate di controllo sono programmate con una frequenza concordata, di solito mensile.

Domande frequenti (FAQ)

1. Gestione delle versioni

1.1 Come funzionano le versioni per Lokad?

Lokad gestisce tutte le versioni internamente, il che aiuta a garantire completa trasparenza per i clienti. Eventuali versioni che potrebbero influire su un cliente vengono coordinate con loro - tramite i team tecnici del cliente - con largo anticipo. In generale, Lokad adotta un approccio cauto alle versioni: se una versione programmata non fornisse un tempo sufficiente di preparazione per un cliente, la versione sarebbe temporaneamente posticipata.

Le versioni di Lokad sono molto granulari e il design di solito consente al cliente di escludere un particolare elemento tecnico di una versione complessiva. Pertanto, se dobbiamo posticipare l’implementazione di un elemento - per il quale il nostro cliente non è ancora pronto - la versione complessiva può comunque avvenire (e implementare gli altri elementi non influenti).

1.2 Con quale frequenza vengono rilasciate le versioni?

Lokad rilascia una nuova versione ogni martedì, tipicamente intorno alle 11:00 (CET).

1.3 Fornite un piano delle prossime versioni?

Sì, vedi Gestione delle versioni 1.2.

1.4 Un cambio di versione comporta una reinstallazione o solo un aggiornamento?

Lokad rilancia, tramite mezzi automatizzati (script), la propria soluzione. Non applichiamo patch ai sistemi in produzione. Se abbiamo una “patch di sicurezza” da distribuire, rilanceremo la soluzione tramite i nostri soliti mezzi automatizzati.

1.5 Quanto tempo ci vuole per applicare una versione principale?

Il processo automatizzato richiede circa 1 ora. Viene effettuato un roll-out graduale (macchina per macchina), poiché intendiamo mantenere operativa e accessibile la piattaforma di Lokad durante il rilascio. L’operatività durante un roll-out viene discussa in Gestione delle versioni 1.7.

1.6 Chi è responsabile dell’esecuzione corretta del rilascio?

Il team di Lokad si assume la piena responsabilità dell’esecuzione corretta del rilascio.

1.7 C’è un periodo di inattività durante il rilascio?

Principalmente no, ma tieni presente che la soluzione di Lokad è un sistema distribuito dedicato a calcoli su larga scala. Pertanto, l’impatto di un rilascio differisce tra i sistemi front-end e back-end. I sottosistemi rivolti al cliente, come i dashboard, sono progettati per non avere tempi di inattività. I sistemi back-end, come quelli responsabili dell’esecuzione dei job batch, potrebbero essere messi in pausa per alcuni minuti (almeno per alcuni job). Tuttavia, questi job batch possono essere pianificati, quindi una pianificazione proattiva dovrebbe consentire il completamento dei job batch al di fuori del periodo di rilascio.

1.8 Qual è il vostro processo o strategia di testing per un rilascio?

Lokad utilizza processi automatizzati dedicati al testing e alla verifica della correttezza di un prossimo rilascio. Questi processi includono suite estese di test automatizzati (misurate in migliaia); test unitari, test funzionali, test di performance, ecc. Abbiamo anche sviluppato strumenti dedicati che ci consentono di riprodurre intere sequenze di esecuzioni di job passate all’interno della piattaforma di Lokad. Questi strumenti ci permettono di verificare che gli script di Envision abbiano lo stesso comportamento esatto prima/dopo un prossimo rilascio. Inoltre, possiamo verificare che i profili di performance degli script esistenti rimangano in linea con le aspettative di pianificazione, come definite dai nostri clienti.

1.9 Avete più ambienti?

Sì, tuttavia, gli ambienti alternativi (a livello di piattaforma, oltre a quello di produzione) di solito non sono destinati ai nostri clienti. Oltre all’ambiente di produzione e agli ambienti di sviluppo transitori, abbiamo un ambiente ’evergreen’ che corrisponde all’ultima versione stabile del nostro codice. Questo convalida un subset specifico dei nostri processi di testing automatizzati. I nostri clienti possono accedere al nostro ambiente ’evergreen’ per verificare che un prossimo rilascio specifico si comporti come previsto. Questa situazione può verificarsi se c’è un’integrazione IT tra Lokad e il cliente. Nella pratica, questa situazione è rara.

Se l’obiettivo è essere in grado di eseguire (affiancati) più varianti di script Envision, allora un account Lokad può essere suddiviso in più “ambienti”. Se l’obiettivo è essere in grado di eseguire qualsiasi tipo di test, allora può essere fornito un secondo account Lokad per scopi di testing transitori. Questo secondo approccio mantiene l’account client principale (usato per la produzione) isolato da questi test.

1.10 Quante versioni diverse possono coesistere?

Lokad è un SaaS multi-tenant che esegue la stessa versione unica per tutti i suoi clienti, tuttavia, Lokad ha la capacità di operare quante versioni distinte desiderate dal cliente.

1.11 Un cliente può escludersi da un rilascio?

Poiché Lokad è un SaaS multi-tenant che esegue la stessa versione unica per tutti i clienti, non è possibile escludersi da un rilascio. Tuttavia, dal punto di vista aziendale, questo è irrilevante poiché qualsiasi “cambiamento” viene implementato tramite l’esecuzione di script Envision all’interno della soluzione di Lokad.

Per situazioni in cui un rilascio può essere temporaneamente posticipato, vedere Gestione dei rilasci 1.1.

1.12 Avete delle note di rilascio? Le fornite ai vostri clienti?

Sì. Queste note vengono condivise internamente (con i nostri team di supply chain scientist). Se esplicitamente concordato come parte di un contratto, queste note di rilascio possono essere rese accessibili a un cliente. In pratica, le note di rilascio della piattaforma Lokad sono interessanti solo per le persone che lavorano con il codice Envision.

1.13 Qual è il processo per un cliente per richiedere un’evoluzione della soluzione?

La maggior parte dei nostri clienti beneficia di un’offerta “software + esperto”, in cui un team di supply chain scientist di Lokad è responsabile dell’implementazione e della manutenzione della soluzione di supply chain di un cliente. Queste situazioni sono note come “supply chain as a service”. In queste situazioni, il cliente interagisce regolarmente con uno (o più) supply chain scientist. Inoltre, la maggior parte dei clienti beneficia di un comitato di steering settimanale o mensile per discutere lo stato attuale della soluzione e eventuali evoluzioni desiderate. Questo metodo viene utilizzato da Lokad per raccogliere tutte le richieste di evoluzione e proporre una roadmap per l’implementazione dei cambiamenti.

1.14 È possibile amministrare il web-service dell’applicazione e configurare i suoi parametri?

Sì, nel senso che la piattaforma Lokad è di natura programmabile. La logica “analitica” di Lokad assume la forma di script Envision - Envision è il DSL (Domain-Specific Language) sviluppato da Lokad per l’ottimizzazione predittiva della supply chain.

Pertanto, in un certo senso, ogni singola configurazione dei parametri è disponibile sfruttando gli script Envision all’interno dell’account.

2. Performance

2.1 Il vostro SLA (accordo di livello di servizio) copre un uptime del 99.xy%?

Sì. L’SLA fa parte del nostro accordo contrattuale predefinito. Tuttavia, la nozione di uptime nel contesto di un sistema informatico distribuito - dedicato all’ottimizzazione predittiva delle supply chain - è complessa. Considera i seguenti scenari: - Lokad riceve i dati del cliente (un passaggio giornaliero) con 2 ore di ritardo rispetto all’orario previsto. Questo potrebbe interrompere l’efficienza ordinaria delle euristiche di allocazione delle risorse di Lokad. Ciò, a sua volta, potrebbe prolungare il tempo necessario per eseguire i job batch di Lokad (ad esempio, 75 minuti invece dei consueti 60). Alcuni potrebbero considerare questo un downtime di 15 minuti, ma questo è al di là del nostro controllo.

• Lokad riceve gli stessi dati del cliente in tempo, ma i dati presentano una notevole diminuzione dei livelli di stock. Questo comporterebbe un’interruzione dei job batch (lato Lokad) e avviserebbe un supply chain scientist per indagare sul problema. Il supply chain scientist nota che un ordine di rifornimento automatizzato è eccezionalmente grande. Il supply chain scientist decide che è necessaria una valutazione diretta da parte del cliente. Il giorno successivo, il cliente conferma che i dati sugli stock erano corrotti e avrebbero comportato una grande cancellazione di stock. Alcuni potrebbero considerare questo un downtime di 24 ore, ma sembra praticamente ottuso in contesto.

Il pericolo più grande per una soluzione di ottimizzazione della supply chain non è essere un po’ in ritardo; è essere molto sbagliati. Una volta presa una decisione sulla supply chain, come (in modo errato) avviare un lotto di produzione, annullarla può essere estremamente costoso. Incoraggiamo i nostri clienti a non attaccarsi arbitrariamente agli indicatori isolati, poiché questa attitudine può incentivare le persone a fornire un lavoro complessivamente inferiore purché sembri soddisfare un KPI (come l’uptime x.y%).

2.2 Garantite un tempo di risposta per le richieste degli utenti entro X secondi?

Sì, entro 500 ms, ma con alcune limitazioni.

Abbiamo progettato ciò che potremmo definire “dashboard a tempo costante”. Sotto il cofano, la visualizzazione di una dashboard richiede una singola richiesta sulla rete e nel nostro backend collociamo tutti i dati della dashboard per mantenere basso il numero di richieste di rete (di solito misurate in cifre singole). Questa scelta di progettazione va molto lontano nel “garantire” la bassa latenza della tipica richiesta dell’utente nella visualizzazione di una dashboard. Questa scelta di progettazione impedisce anche alla dashboard di diventare affollata di riquadri, ognuno dei quali richiederebbe richieste di rete, rallentando così l’esperienza complessiva dell’utente.

Per quanto riguarda la durata dei job batch, attraverso Envision possiamo fornire garanzie - al momento della compilazione - che un job batch verrà completato. Possiamo anche garantire tempi di completamento ampiamente riproducibili per i nostri job batch. Queste garanzie vengono ottenute attraverso l’analisi statica e la progettazione attenta del linguaggio Envision - che rende possibili determinate classi di analisi statica in primo luogo. Questo approccio ha dei limiti, ma è nettamente superiore a progetti che non offrono alcuna garanzia.

Tuttavia, la latenza end-to-end non è completamente nelle nostre mani. Ad esempio, non controlliamo la qualità della connessione internet utilizzata dai nostri clienti. Un grande foglio di calcolo di Lokad richiederà tempo per essere scaricato su una rete a banda ridotta.

2.3 Avete registri di audit delle prestazioni di sistema?

Sì. Raccogliamo registri di prestazioni molto dettagliati per tutte le risorse di calcolo coinvolte: CPU, memoria, storage, larghezza di banda, ecc. Questi registri di prestazioni vengono utilizzati, tra le altre cose, per garantire che una nuova versione della piattaforma, ancora non rilasciata, soddisfi le nostre aspettative in termini di prestazioni. Testiamo ciò confrontando le prestazioni della nuova versione con quelle delle versioni precedenti, come evidenziato da questi registri.

2.4 È possibile monitorare risposte lente o congestione?

Sì. La piattaforma Lokad è dotata di un scheduler interno che può monitorare l’esecuzione tempestiva dei job batch. La progettazione di Lokad garantisce in gran parte una risposta a tempo costante per tutte le richieste, ad eccezione delle operazioni a lunga durata, che vengono trattate come job batch.

Poiché Lokad è una piattaforma multi-tenant, una grande parte del monitoraggio delle prestazioni non è direttamente accessibile ai nostri clienti (poiché copre le prestazioni della piattaforma nel suo complesso). Come ci si può aspettare, i team di Lokad monitorano continuamente le prestazioni della nostra piattaforma.

2.5 Avete bilanciatori di carico?

Sì. I bilanciatori di carico di Lokad sono principalmente destinati a scopi di affidabilità piuttosto che di prestazioni. Il bilanciamento del carico a livello di rete viene effettuato attraverso il livello di rete della piattaforma di cloud computing che utilizziamo (Microsoft Azure). Tuttavia, la distribuzione del carico di lavoro di elaborazione dei dati interni, gestita dalla piattaforma Lokad, non avviene tramite bilanciatori di carico, ma tramite un orchestratore interno associato alla nostra stack di compilazione.

2.6 Raggruppate le risorse come connessioni DB, sessioni, ecc.?

Sì. Tuttavia, la piattaforma Lokad non si basa su un database transazionale per funzionare. Pertanto, non ci sono connessioni al database da raggruppare. Tuttavia, raggruppiamo molte altre risorse, quando ha senso dal punto di vista delle prestazioni.

2.7 Supportate l’elaborazione parallela?

Sì. Envision (il nostro DSL) è progettato attorno al concetto di esecuzione automatica parallelizzata. La piattaforma Lokad sfrutta attivamente la parallelizzazione a più livelli: a livello di core della CPU attraverso operazioni SIMD (Single Instruction/Multiple Data); a livello di CPU attraverso esecuzioni multithreaded; e a livello di cluster attraverso il calcolo distribuito. Poiché l’elaborazione parallela è un aspetto fondamentale del design di Envision, la quasi totalità dei carichi di lavoro eseguiti sulla piattaforma Lokad beneficia di una parallelizzazione estesa, di default, senza alcuno sforzo specifico da parte dei nostri clienti o dei nostri supply chain scientist.

2.8 Supportate la memorizzazione nella cache di dati frequentemente accessibili?

Sì. Tuttavia, la memorizzazione nella cache viene spesso introdotta come soluzione alternativa per far fronte alle limitazioni di prestazioni dei database transazionali. Dato che la piattaforma Lokad non include database transazionali, non utilizziamo la memorizzazione nella cache per questo scopo.

2.9 Comprimete i dati per ridurre il traffico di rete?

Sì, comprimiamo la maggior parte del traffico di rete. Tuttavia, non possiamo comprimerlo tutto poiché ciò presenterebbe una vulnerabilità di sicurezza nota come BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext). BREACH si verifica quando sono presenti tre fattori combinati.

1. Una risposta viene compressa.

2. Una risposta contiene un segreto.

3. Una risposta contiene una stringa che può essere raccolta dall’attaccante che crea la richiesta.

Per difenderci da BREACH, Lokad disabilita la compressione su tutte le risposte in cui è vera la terza condizione. Comprimiamo anche i dati per motivi che vanno oltre la riduzione del traffico di rete; in primo luogo, per ridurre i costi di archiviazione dei dati; e in secondo luogo, per ridurre i ritardi di calcolo.

2.10 Effettuate test di prestazione?

Sì. Lokad dispone di un’estesa strumentazione automatizzata orientata alle prestazioni. Questa serie di strumenti ci consente di valutare, prima di ogni rilascio, la differenza di prestazioni della versione imminente rispetto a quella ottenuta con la versione attualmente distribuita. Questo strumento ci consente di riprodurre gli stessi carichi di lavoro, come osservato in produzione, e monitorare le prestazioni risultanti; non solo in termini di tempo effettivo, ma considerando tutte le risorse di calcolo rilevanti (memoria, larghezza di banda, I/O, CPU, ecc.).

2.11 Monitorate le prestazioni a livello di transazione?

Sì. Tuttavia, poiché la piattaforma Lokad non utilizza un database transazionale, non ci sono “transazioni” da monitorare (nel senso tradizionale). L’equivalente più vicino è l’esecuzione degli script Envision. Per questi script, monitoriamo le prestazioni a un livello molto dettagliato, che è approssimativamente analogo al monitoraggio dei dettagli dell’esecuzione del piano di query (dal punto di vista di un database transazionale).

Consulta Autorizzazione 3.6 e Registrazione e Monitoraggio 5.3 nella nostra documentazione sulla Sicurezza per ulteriori informazioni sulle “transazioni” nella soluzione Lokad.

2.12 Qual è l’impatto sulle prestazioni di avere utenti concorrenti sulla soluzione?

Quasi nullo. Il design di Lokad garantisce che i dashboard possano essere serviti in tempo costante anche per un grande numero di utenti (secondo gli standard B2B). Questo approccio è in netto contrasto con molte architetture alternative, in particolare i database transazionali e i cubi di Business Intelligence.

Tuttavia, dato che ogni singolo utente potrebbe (se in possesso dei diritti di sistema appropriati) attivare carichi di lavoro arbitrariamente grandi, il numero di utenti concorrenti è, al massimo, una preoccupazione secondaria per quanto riguarda le prestazioni della soluzione. Per quanto riguarda l’ottimizzazione predittiva della supply chain, i job batch utilizzati per eseguire le analisi di interesse rappresentano più del 99% del carico di lavoro. Meno dell'1% rimanente è dedicato a soddisfare le richieste degli utenti.

2.13 Il sistema è progettato per scalare verticalmente e orizzontalmente?

Sì. Dal nostro punto di vista, lo scaling verticale e orizzontale sono complementari e il design della piattaforma Lokad ne fa leva entrambe. L’orchestratore interno - quello responsabile della parallelizzazione - inizia tipicamente con lo scaling verticale, poiché lo scaling verticale facilita in gran parte la collocazione dei dati. Successivamente, l’orchestratore fa leva sullo scaling orizzontale se il carico di lavoro è sufficientemente grande da beneficiare dell’esecuzione su più macchine.

2.14 Effettuate l’auto-scaling dei calcoli e dello storage secondo necessità?

Sì. La piattaforma Lokad è multi-tenant. Attraverso il multi-tenancy, effettuiamo allocazioni di risorse di calcolo su larga scala a bassa latenza. Ciò significa che lo scaling automatico dei calcoli fornito da Lokad è di ordini di grandezza più veloce rispetto alla creazione di grandi VM (macchine virtuali) da un provider di cloud computing. Lo scaling automatico dello storage viene in gran parte eseguito sfruttando le proprietà di auto-scaling del key-value store persistente, fornito dalla piattaforma di cloud computing sottostante (Microsoft Azure).

2.15 Come gestisce la vostra applicazione i requisiti di “Big Data”?

La piattaforma Lokad è stata progettata appositamente per l’elaborazione di “Big Data”. A gennaio 2023, l’intera piattaforma Lokad gestisce circa 1 petabyte di dati in tutta la nostra base clienti. La nostra piattaforma può elaborare singoli file fino a 100 GB e elaboriamo regolarmente tabelle con decine di miliardi di righe. Vai a Sicurezza di Lokad 4.10

Questo punto è particolarmente tecnico e va oltre lo scopo di questo documento. Per una spiegazione approfondita, consigliamo la serie in 4 parti di Victor Nicollet sul design della Virtual Machine Envision.

2.16 La soluzione basata su cloud di Lokad può essere configurata in base a vincoli di larghezza di banda e latenza (lato client) stretti? Ad esempio: larghezza di banda = 3Mbps (download) / 1Mbps (upload), latenza = 600-800ms

Sì, l’app web progettata da Lokad è stata progettata per supportare scenari in cui la connettività è “scarsa” (sia in termini di larghezza di banda che di latenza). Queste preoccupazioni sono affrontate principalmente attraverso scelte di progettazione tecnologica fondamentali. Queste scelte di progettazione architetturale separano anche Lokad dalla massa. Le preoccupazioni sulla larghezza di banda sono affrontate in due modi. Primo, siamo parsimoniosi quando si tratta di componenti JavaScript di terze parti. Abbiamo meno di 1 MB di risorse da recuperare inizialmente. Secondo, la piattaforma offre un controllo completo sulla quantità di dati da includere in ogni singolo dashboard. Pertanto, se la connettività è scarsa, è possibile rendere il dashboard appropriatamente “leggero”. Per quanto riguarda le preoccupazioni sulla latenza, i nostri dashboard sono stati progettati per raggruppare tutti i dati rilevanti del dashboard in una singola richiesta HTTP. Ciò riduce al minimo l’attrito causato dagli utenti finali a bassa latenza.

2.17 Quali sono le capacità medie e di picco di throughput dei dati della soluzione rispetto a un benchmark di 1 (basso) e 5 (alto) messaggi al secondo?

La piattaforma Lokad non opera con messaggi. Allo stesso modo, le interazioni con la piattaforma Lokad non vengono effettuate tramite messaggi. Tuttavia, il throughput è importante per elaborare rapidamente vasti set di dati transazionali. La piattaforma Lokad gestisce, in totale, oltre 1 petabyte di dati. Gestiamo regolarmente oltre 1 terabyte al minuto per grandi batch di calcoli.

Un throughput molto elevato è importante per evitare ritardi operativi durante l’elaborazione di set di dati molto grandi (decine di terabyte) con calcoli complessi che includono passaggi di machine learning e ottimizzazione matematica.

2.18 Quali dimensioni di messaggi può gestire la soluzione? Fornire dettagli relativi ai valori minimi, massimi e medi.

La piattaforma Lokad non opera con messaggi. La cosa più simile sarebbero i “file piatti”. Questi file piatti possono essere inviati a Lokad e recuperati da Lokad. La piattaforma Lokad può elaborare file di dimensioni fino a 100 GB. Tuttavia, questa non è una pratica consigliata in quanto solitamente è un po’ scomoda (non per Lokad, ma per i clienti che dovranno familiarizzare con strumenti esterni per produrre e consumare i grandi file).

3. Incidenti

3.1 Qual è il processo per un cliente per segnalare un incidente?

La maggior parte dei nostri clienti beneficia di un pacchetto che include l’accesso al nostro team di supply chain scientist. Questi supply chain scientist sono il primo punto di contatto per segnalare gli incidenti. In caso di incidente, suggeriamo ai clienti di telefonare direttamente al loro supply chain scientist - se il problema è urgente - o di inviare un’e-mail. I supply chain scientist si occupano della gestione degli incidenti, comprese eventuali escalation all’interno dell’organizzazione di Lokad.

3.2 Offrite un sistema di ticketing?

Sì. Lokad utilizza un sistema di ticketing di terze parti. Tuttavia, a partire da gennaio 2023, abbiamo iniziato a sviluppare una soluzione interna che offre un’integrazione completa con il resto della nostra piattaforma.

3.3 Supportate la segnalazione di incidenti a strumenti di terze parti?

Sì, previa stipula di un accordo contrattuale dedicato.

Nel contesto dell’ottimizzazione predittiva della supply chain, gli “incidenti” possono variare e essere difficili da definire. In generale, i nostri clienti non considerano gli eventi minori a livello di piattaforma (come i brevi tempi di inattività) come “incidenti”. Piuttosto, sarebbero migliori candidati le anomalie effettive della supply chain - che possono o meno riflettere problemi con gli script Envision implementati nell’account del cliente. I dipartimenti IT esterni sono raramente coinvolti nella risoluzione di questi incidenti.

3.4 Come garantite l’alta disponibilità?

Lokad è diventata una delle prime adottanti (circa nel 2010) delle piattaforme di cloud computing proprio per garantire una maggiore disponibilità. Oltre a rendere l’infrastruttura ridondante (vedi Incidenti 3.5), il design della soluzione di Lokad enfatizza fortemente la semplicità. A differenza delle soluzioni software aziendali comparabili, abbiamo significativamente meno dipendenze complesse (quasi un ordine di grandezza in meno). Un’enorme complessità assente dalla nostra soluzione è un database transazionale. Avendo meno componenti in movimento, abbiamo molti meno modi di fallire, il che ci aiuta a mantenere un’alta disponibilità per i nostri clienti (che sono distribuiti su diversi fusi orari).

3.5 Avete un’infrastruttura ridondante (se sì, come)? Evitate i punti di singolo guasto?

Sì. I nostri sistemi critici sono ridondanti, proprio per evitare punti di singolo guasto. I sistemi ridondanti includono i sottosistemi che supportano protocolli stateful come SFTP. Inoltre, lo storage dei dati non è solo ridondante ma anche geograficamente ridondante. Questa ridondanza viene sfruttata durante i nostri rilasci per preservare il tempo di attività mentre il roll-out è in corso.

3.6 Come vi riprendete dai guasti hardware?

La ripresa dalla maggior parte dei guasti hardware viene eseguita in modo trasparente dalla piattaforma di cloud computing utilizzata da Lokad. La ridondanza integrata della piattaforma di Lokad garantisce che i guasti hardware transitori non influiscano sul tempo di attività mentre la piattaforma di cloud computing rialloca una nuova risorsa non difettosa. Per lo storage dei dati persistenti, Lokad utilizza solo servizi (ad esempio, key-value store) che sono protetti da guasti hardware attraverso i loro livelli di ridondanza.

3.7 Avete un backup?

Sì. Abbiamo un ambiente di backup dedicato a scenari di ripristino da disastro gravi (oltre a un’interruzione a livello di data center). Questo ambiente di backup è completamente isolato dall’ambiente di produzione. L’ambiente di backup può leggere da quello di produzione (ma non scrivere), mentre l’ambiente di produzione non può né leggere né scrivere da quello di backup.

3.8 Avete un piano di ripristino da disastro?

Sì. A livello tecnico, il piano di ripristino da disastro copre la completa reinizializzazione della piattaforma di Lokad. Questa parte sfrutta ampiamente i processi automatizzati che abbiamo in atto per i nostri rilasci settimanali. A livello aziendale, il piano di ripristino da disastro prevede di contattare ogni cliente che abbiamo, seguendo tipicamente un processo concordato con ciascuno di essi. Per la maggior parte dei nostri clienti, gli scienziati della supply chain designati agiscono come punti di contatto principali per la durata del ripristino.

3.9 La soluzione supporta il ripristino a un punto nel tempo (PITR) tra database e dati al di fuori del database? Qual è l’obiettivo del punto di ripristino (RPO) della soluzione?

La soluzione di Lokad presenta un design di protezione continua dei dati attraverso il backup incrementale in tempo reale sia del suo event store che della sua fonte di contenuti. Pertanto, possiamo eseguire il ripristino a un determinato momento (fino al livello dei minuti).

Abbiamo un RPO di 1 minuto per i disastri a livello di data center, se i dati non sono compromessi. Raggiungiamo questo obiettivo sfruttando scritture geograficamente ridondanti del nostro persistent key-value store. Se il key-value store viene compromesso, Lokad si ripristina dallo storage di backup (mantenuto isolato quanto possibile dai nostri sistemi di produzione), ospitato anche in una diversa posizione geografica. In questo caso, abbiamo un RPO di 12 ore.

3.10 La soluzione è in grado di generare avvisi di violazione dell’integrità? La soluzione ha la capacità di aggiungere o estendere controlli di integrità secondo i requisiti?

Sì, anche se questo tipo di problema riflette principalmente un design software basato su un database transazionale. La piattaforma di Lokad non opera con un database transazionale ma con un event store, adottando un design basato su event sourcing anziché su uno relazionale. Ciò non elimina la necessità di garantire l’integrità dei dati, ma tali preoccupazioni vengono affrontate in modi alternativi.

Per quanto riguarda l’elaborazione dei dati del cliente, Envision (DSL di Lokad) ha ampie capacità volte a verificare la loro qualità. Attraverso Envision, è possibile verificare l’integrità e generare avvisi. Questa logica può essere estesa o modificata in qualsiasi modo ritenuto appropriato dal cliente.

3.11 I backup vengono testati periodicamente per verificare la corretta funzionalità di ripristino dei dati?

Sì. Il design di event-sourcing di Lokad, combinato con il suo content-addressable store, semplifica molto di più il testing per il backup e la funzionalità di ripristino dei dati rispetto a quanto avviene per la maggior parte dei design mainstream che sfruttano database relazionali (come SQL).

Vedi anche Incidenti 3.7.

3.12 I piani di ripristino da disastro vengono testati periodicamente per verificare la corretta funzionalità di ripristino da disastro?

Sì. La strategia di distribuzione di Lokad si avvale di script automatizzati end-to-end, mantenendo deliberatamente poche interventi umani - una notevole eccezione è la possibilità di avviare un ripristino completo della produzione. Questo approccio fortemente automatizzato facilita il testing della funzionalità di ripristino da disastro.

Vedi Incidenti 3.8.

3.13 È possibile eseguire il ripristino per singoli clienti e/o ambienti dei clienti?

Sì. I nostri strumenti interni supportano la possibilità di ripristinare l’account di un cliente selezionato (compreso il ripristino dell’account/ambiente a un determinato punto nel tempo). Tuttavia, considerando che la piattaforma di Lokad stessa dispone di ampie capacità di versioning (ad esempio, gli script Envision sono versionati e le versioni precedenti sono accessibili dall’app stessa), questa funzionalità viene raramente utilizzata.

3.14 I piani di backup e ripristino da disastro soddisfano i requisiti di RTO (Recovery Time Objective), RPO (Recovery Point Objective) e scenari di disastro dei clienti (come definiti e concordati con i rispettivi clienti)?

Sì. L’obiettivo di tempo di ripristino (RTO) si riferisce qui alla quantità di tempo in cui la piattaforma di Lokad potrebbe essere teoricamente inattiva senza causare danni significativi al cliente, nonché al tempo impiegato per ripristinare la piattaforma e i suoi dati in modo che possa riprendere le normali operazioni dopo un incidente significativo.

L’RTO dipende molto dai dettagli specifici dei processi supportati/forniti da Lokad. Ad esempio, un cliente che si affida a Lokad per pianificare ordini di acquisto mensili all’estero potrebbe avere un RTO di 1 settimana. Al contrario, un cliente che si affida a Lokad per ottimizzare la spedizione giornaliera dell’inventario da un magazzino a più negozi potrebbe avere un RTO di 1 ora.

Nella pratica, possono essere adottate varie contingenze tecniche per migliorare sostanzialmente l’RTO (ossia ridurre un tempo di inattività teorico). Ad esempio, le “decisioni di failover” possono essere calcolate in anticipo. Queste decisioni possono essere utilizzate nel caso in cui la piattaforma di Lokad non sia disponibile. Rispetto alle decisioni “regolari” ottimizzate, le decisioni di failover possono mostrare una prestazione di fornitura leggermente degradata dato che (per definizione) non sfrutterebbero i dati assoluti più recenti.

Per i nostri account gestiti, è responsabilità del Supply Chain Scientist di Lokad elaborare congiuntamente un processo - con i team operativi del cliente - che fornisca un alto RTO, ma anche che garantisca un impatto aziendale minimo in caso di incidente effettivo. Dal nostro punto di vista, questa sfida è prima di tutto un problema di supply chain anziché di IT.

Vedi anche Incidenti 3.9.

3.15 Se un difetto non è riproducibile nell’ambiente di test, Lokad può verificare che il difetto sia avvenuto dai log e dai dati di supporto, nonché garantire che il difetto sia corretto secondo l’Accordo di Livello di Servizio (SLA)?

Sì, i difetti possono essere riprodotti nei nostri ambienti. La rigorosa riproducibilità di tutti gli stati dei dati e tutti i calcoli è un principio di design fondamentale della piattaforma e dell’architettura di Lokad. Ad esempio, il file system all’interno della piattaforma di Lokad è completamente versionato (come Git), proprio per affrontare questa problematica.

Va notato che i log sono più efficaci per risolvere problemi banali, come il downtime del server. Quando si tratta di risolvere problemi complessi e difetti in un ambiente di dati su larga scala - in cui sono coinvolti terabyte di dati - i log spesso non sono sufficienti.

Pertanto, sebbene Lokad mantenga e consulte i log quando appropriato, non ci affidiamo ai log per risolvere i difetti o verificare che i difetti siano stati corretti. Invece, sfruttiamo principalmente scelte di design superiori per fornire una maggiore comprensione, tracciabilità e riproducibilità.

Queste scelte di design deliberate ci consentono di identificare, riprodurre e correggere difetti in un modo che non sarebbe possibile solo con i log.

Si prega di consultare Architettura di Lokad per una dettagliata analisi delle diverse scelte di design che adottiamo per evitare intere classi di problemi software comuni.

3.16 Mantenete un registro di tutte le richieste di servizio e le chiamate di servizio (inclusa la categoria di ogni chiamata) effettuate dall’azienda cliente? I record includono: l’identità della persona che chiama e della persona chiamata; la natura dell’errore, del problema o dell’incidente segnalato; il tempo di risposta di Lokad; la gestione della chiamata di servizio; la risoluzione; i tempi di risoluzione; e la disponibilità del sistema?

Sì, la piattaforma di Lokad dispone di funzionalità di gestione dei task/ticket/problemi che forniscono i dettagli elencati.

Per quanto riguarda le “risoluzioni”, vale la pena notare che la filosofia quantitativa della supply chain di Lokad (QSC) consiste nel trovare il compromesso più vantaggioso dal punto di vista finanziario quando si presenta un problema. La QSC non è, tecnicamente, un approccio di “risoluzione dei problemi”, poiché i problemi della supply chain non sono problemi che vengono “risolti”, ma vengono attenuati attraverso compromessi finanziariamente consapevoli.

In breve, Lokad possiede gli strumenti e i processi per risolvere prontamente “problemi semplici” (come il downtime del server) in modo diretto. Quando si tratta di problemi più grandi e più significativi della supply chain (come l’allocazione delle scorte al dettaglio o i problemi di riapprovvigionamento dell’inventario), di solito si tratta di discussioni più aperte e in corso con i clienti su quali compromessi massimizzino il loro ritorno sull’investimento.

4. Architettura

4.1 Quali linguaggi di programmazione utilizzate?

La piattaforma di Lokad è sviluppata in C#, F# e TypeScript. La piattaforma include anche Envision (DSL di Lokad), che viene utilizzato per implementare le soluzioni di supply chain specifiche per il cliente.

4.2 Quale suite di sviluppo utilizzate?

I team di ingegneria del software di Lokad utilizzano Microsoft Visual Studio. I team di scienziati della supply chain utilizzano la stessa piattaforma di Lokad, che dispone della propria suite di sviluppo.

4.3 Quale sistema operativo supportate?

Lokad è una piattaforma basata sul web e supportiamo tutti i sistemi operativi che hanno accesso a un browser web moderno (ad esempio Firefox). Internamente, la piattaforma di Lokad è compatibile sia con Linux che con Microsoft Windows, anche se tutti i nostri sistemi di produzione sono distribuiti su Linux (Ubuntu).

4.4 Quale sistema di database utilizzate o supportate?

Lokad supporta tutti i sistemi di database che possono produrre esportazioni di file piatti. Ciò include praticamente tutti i sistemi di database del mercato, compresi i modelli più vecchi. Internamente, Lokad non utilizza un sistema di database, ma un archivio chiave-valore. Al momento della stesura (gennaio 2023), utilizziamo Blob Storage fornito da Microsoft Azure.

4.5 Quale sistema di caching utilizzate?

Lokad ha progettato i propri sottosistemi di caching in C#/.NET. Questi sottosistemi sono strettamente integrati con il resto della soluzione e non riflettono i tradizionali sistemi di caching principalmente intesi per mitigare i problemi di prestazioni con un database relazionale (che Lokad non ha).

4.6 Come gestisce la soluzione i certificati?

Lokad sfrutta Let’s Encrypt attraverso rinnovi automatici dei certificati.

4.7 Quali sono i prerequisiti tecnici per utilizzare la soluzione?

Il principale prerequisito tecnico è un sistema di transazioni che tiene traccia dell’inventario. Inoltre, è utile se il cliente ha qualche esperienza nell’estrazione dei dati (come file piatti) dai propri sistemi transazionali, ma questo non è certamente un prerequisito.

4.8 Elencare tutte le licenze di terze parti aggiuntive necessarie per utilizzare la soluzione di Lokad (ad esempio, OS, SQL,…).

N/A. Lokad non richiede alcuna licenza di terze parti per funzionare. Esistono una vasta gamma di strumenti open-source per supportare l’integrazione di Lokad (ad esempio, file piatti trasferiti tramite FTPS o SFTP); quindi, non è richiesta alcuna licenza di terze parti, nemmeno indirettamente, per beneficiare della piattaforma di Lokad.

4.9 Il servizio richiede plug-in del browser o software speciale?

Lokad è un’applicazione web. Non richiede plug-in del browser o software speciale.

4.10 Quali sono le interfacce di ingresso e uscita dell’applicazione?

La soluzione di Lokad offre un’interfaccia web - accessibile tramite HTTPS - e protocolli di file, ovvero SFTP e FTPS.

4.11 Come garantite che non ci siano fughe di dati tra i tenant?

La soluzione di Lokad separa i dati dei tenant attraverso il suo stesso design, che garantisce che non si verifichino fughe di dati (anche accidentali). Inoltre, tutto il codice spedito in produzione viene sottoposto a revisione tra pari, fornendo così un ulteriore livello di protezione. Infine, indirizziamo i ricercatori di sicurezza (persone che eseguono pentest) per indagare specificamente sulla possibilità di fughe di dati. Forniamo loro accesso a più account di Lokad - in un ambiente dedicato e completamente isolato che replica quello di produzione - in modo che possano verificare in modo aggressivo questa proprietà della nostra piattaforma.

4.12 La soluzione può essere containerizzata?

Sì, ma per la piattaforma di Lokad c’è poco o nessun beneficio nell’essere containerizzata. La containerizzazione porta valore quando ci sono dipendenze complesse (ad esempio, un database transazionale, un sistema di caching isolato, ecc.). Non utilizziamo container in produzione o sviluppo, il che migliora la nostra sicurezza eliminando intere classi di vulnerabilità. Invece, manteniamo la soluzione sufficientemente semplice in modo che il deployment possa essere eseguito anche con piccoli script shell.

4.13 I componenti GUI possono essere disaccoppiati dal backend?

Sì, i componenti GUI (in questo caso, le interfacce web) sono autonomi. Questo design aiuta a ottenere una maggiore disponibilità. Gli utenti finali possono accedere ai dashboard del loro account Lokad anche se un’interruzione improvvisa colpisce uno degli altri sottosistemi.

4.14 L’applicazione Lokad supporta le funzioni di localizzazione (come il cambio di lingua)?

Sì, l’applicazione supporta le funzioni di localizzazione. Tutte le interfacce utente prodotte dalla piattaforma di Lokad possono essere localizzate in qualsiasi lingua. In particolare, l’intero stack tecnologico adotta UTF-8, al fine di supportare tutti i set di caratteri che esistono oltre quello latino. In particolare, qualsiasi interfaccia utente prodotta dalla piattaforma di Lokad può essere rilocalizzata - dopo la consegna - in un’altra lingua.

4.15 È possibile per gli utenti finali aggiornare o creare nuove traduzioni dopo la consegna dei dati post-elaborati da Lokad?

Sì, vedere la domanda 4.14 sopra.

4.16 Il sistema ha una guida integrata? Se sì, in quale/i lingua/e?

Sì, Lokad viene fornito con una documentazione pubblica molto estesa (in inglese). Tuttavia, l’utilizzo della piattaforma Lokad comporta la creazione di interfacce utente personalizzate e il nostro processo regolare prevede almeno due forme di documentazione o assistenza.

In primo luogo, i dashboard creati all’interno della soluzione Lokad sono destinati ad essere documentati contestualmente - direttamente dal dashboard stesso. In particolare, abbiamo persino una tile Markdown dedicata alla documentazione in formato testo. In secondo luogo, i nostri deliverable includono un “Manuale di Procedura Condivisa”. Nel complesso, il manuale fornisce un’analisi dettagliata non solo della meccanica della soluzione, ma anche del motivo per cui ogni elemento è stato selezionato (e come soddisfa le specifiche esigenze di supply chain del cliente).

4.17 L’applicazione web è responsive?

L’applicazione web di Lokad, insieme ai relativi materiali di supporto (come la documentazione tecnica), è stata progettata per essere responsive. Tuttavia, alcune funzionalità avanzate, come la modifica del codice, sono impraticabili per dispositivi mobili e/o tablet. Pertanto, il design è inteso a massimizzare la responsività per le attività previste eseguite su PC e dispositivi più piccoli, rispettivamente.

4.18 Se il sistema è un’applicazione web, quali browser e versioni supportate? Qual è lo standard minimo del browser internet?

Lokad è un’applicazione web e supportiamo i principali browser web “evergreen” come Chrome, Firefox e Safari. Non cerchiamo di supportare browser più vecchi per motivi di sicurezza, poiché il supporto di quei browser mette implicitamente a rischio i nostri clienti. In parole povere, un browser vulnerabile può essere sfruttato da un attore malintenzionato per esfiltrare dati. Detto questo, siamo anche piuttosto conservativi quando si tratta di nuove funzionalità dei browser. Come regola generale, evitiamo di supportare qualsiasi funzionalità dei browser che non sia stata adottata da tutti i principali browser web per almeno 1 anno.

4.19 Per le applicazioni mobile e tablet, quali sistemi operativi (e versioni) supporta Lokad?

N/D. Poiché Lokad è un’applicazione web fornita come SaaS, i nostri clienti non sono interessati al supporto del sistema operativo. Internamente, Lokad è sviluppato su Windows, mentre tutto il nostro ambiente di produzione ospitato su cloud è su Linux. Pertanto, siamo abbastanza fiduciosi nella ampia portabilità della soluzione Lokad. Sebbene non sentiamo alcuna necessità attuale di modificare questa configurazione, se si presentasse una valida evidenza, ci adatteremo di conseguenza.

4.20 L’applicazione web di Lokad può fornire notifiche agli utenti finali? Se sì, quale tecnologia/protocollo viene utilizzato?

Sì, Lokad ha la capacità di inviare notifiche tramite notifiche programmabili tramite hook HTTP. Questi hook possono essere utilizzati per utilizzare un sistema di terze parti, spesso già presente nell’azienda cliente, per inviare una notifica via email o qualsiasi altro tipo di notifica ritenuta appropriata. Gli hook vengono anche utilizzati tipicamente per segnalare la disponibilità dei dati da recuperare dalla piattaforma Lokad tramite SFTP o FTPS.

4.21 Ci sono elementi condivisi nella soluzione che sono comuni a tutti i clienti (come funzioni di monitoraggio, soluzioni di backup o gestione dei patch, ecc.)?

Sì, poiché Lokad è un’app multi-tenant, le capacità a livello di infrastruttura sono tutte condivise tra/i tenant, ovvero gli account dei clienti. Ciò include il monitoraggio per il tempo di attività, le prestazioni e per motivi di sicurezza, il backup, la gestione dei patch, l’aggiornamento, ecc.

4.22 La soluzione consente la funzionalità di messaggistica multi-destinazione (ovvero la possibilità di inviare un messaggio a più destinatari o applicazioni)?

La piattaforma Lokad non opera con messaggi. Tuttavia, forniamo funzionalità di hook HTTP che possono essere utilizzate per generare notifiche di messaggi arbitrariamente complesse, tipicamente tramite sistemi di terze parti a basso costo. Tali notifiche vengono talvolta utilizzate dai team di supply chain per monitorare il completamento tempestivo di batch di calcolo mission-critical con la piattaforma Lokad.

4.23 Tutti i sistemi e componenti critici utilizzano la stessa fonte di tempo (NTP) o sincronizzano i loro orologi in qualche altro modo affidabile?

Sì. Lokad utilizza il servizio NTP predefinito fornito con Ubuntu - ntp.ubuntu.com. Più specificamente, viene eseguito ntpd come servizio di sincronizzazione del tempo, che si sincronizza con una fonte di tempo NTP esterna a cui si accede tramite la rete.

4.24 Esiste un elenco di inventario delle risorse o un database di gestione della configurazione (CMDB)?

Sì, abbiamo un software di gestione delle risorse IT per supportare i nostri processi. Questa piattaforma ci aiuta a mantenere un elenco completo delle risorse e funge da nostro database di gestione della configurazione (CMDB). Attraverso questo sistema, possiamo tracciare, gestire e allocare efficientemente risorse hardware e software in tutta l’organizzazione. I nostri team hanno la possibilità di identificare rapidamente lo stato, la posizione e la configurazione di qualsiasi risorsa, garantendo risposte tempestive a modifiche, aggiornamenti o potenziali problemi.

Inoltre, il nostro strumento fornisce funzionalità che consentono una gestione dettagliata del ciclo di vita, garantendo che le risorse siano catalogate in modo accurato dalla fase di approvvigionamento alla fine del ciclo di vita. Le capacità di audit automatizzate, abbinate a funzionalità di report dettagliate, garantiscono che manteniamo piena visibilità e controllo sul nostro ambiente IT, facilitando la conformità e l’allocazione efficiente delle risorse.

4.25 Ogni connessione a una rete esterna viene terminata da un firewall (ad esempio, Internet, reti di partner)?

No, non terminiamo ogni connessione a una rete esterna con un firewall, che si tratti di Internet o reti di partner. La nostra decisione è radicata in preoccupazioni reali sull’efficacia e le implicazioni di tali misure.

Dal nostro punto di vista, sebbene i firewall siano tipicamente considerati una difesa di prima linea, possono ironicamente ampliare l’area di superficie di attacco. Più componenti e sistemi integriamo, più punti deboli potenziali introduciamo. I firewall, per loro natura, operano come processi ad alta autorizzazione. Ciò significa che diventano obiettivi primari per gli attacchi informatici e, quando vengono compromessi, i risultati possono essere devastanti. Un caso illustrativo è l’attacco SolarWinds, in cui i sistemi stessi destinati a salvaguardare le informazioni sono stati sfruttati, portando a violazioni significative.

Inoltre, la presenza di firewall rigorosi può essere controproducente dal punto di vista pratico. La nostra esperienza ha dimostrato che tali sistemi spesso incentivano i dipendenti a cercare mezzi alternativi per accedere e condividere informazioni. Ciò comporta tipicamente il bypass della rete aziendale (impedendo quindi qualsiasi monitoraggio) e l’utilizzo di connessioni personali 4G o 5G dai propri dispositivi. Tali pratiche aumentano involontariamente il rischio di violazioni della sicurezza e perdite di dati.

Pertanto, sebbene siamo profondamente impegnati nella sicurezza, il nostro approccio è olistico e informato da considerazioni pratiche anziché basarsi esclusivamente su misure tradizionali.

4.26 La rete dispone di un ambiente DMZ che trasmette, elabora o archivia sistemi critici (come server web, DNS, servizi di directory e accesso remoto), nonché dati dei clienti?

No, Lokad non utilizza un ambiente DMZ tradizionale all’interno della nostra rete per la trasmissione, l’elaborazione o l’archiviazione di sistemi critici e dati dei clienti. Invece, abbiamo adottato un approccio di fiducia zero alla sicurezza della rete.

Questo modello non si basa su DMZ, ma si basa invece sul principio di “non fidarti mai, verifica sempre”. Ogni richiesta di accesso viene convalidata e autenticata, indipendentemente dalla sua origine, che sia interna o esterna all’organizzazione.

Ciò garantisce una postura di sicurezza più robusta e olistica, poiché non dipende dalle difese perimetrali come una DMZ, ma si concentra invece sulla sicurezza di ogni singolo punto di accesso e transazione dati. Crediamo che l’approccio di fiducia zero offra una protezione superiore per i nostri sistemi critici e i dati dei clienti.