FAQ: Tecnologia dell'Informazione (IT)

L’app Lokad è un’applicazione web fornita come SaaS (Software as a Service). Lo scopo di Lokad è fornire analisi predictive al fine di ottimizzare la supply chain (migliori scorte, migliori prezzi, ecc.). L’app Lokad è concepita come uno strato 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 con servizi professionali. Questi servizi professionali, forniti dagli ingegneri di Lokad (Supply Chain Scientists), eliminano quasi interamente la necessità di supporto tecnico da parte del dipartimento IT per questo scopo. Il contributo chiave atteso dal dipartimento IT è la configurazione di un data pipeline che invia file flat (tramite SFTP o FTPS) a Lokad, e potenzialmente reintegra i risultati generati.

Pubblico previsto: Il dipartimento IT
Ultima modifica: 30 novembre 2023

Panoramica tecnica

L’app Lokad è multi-tenant. 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 è progettato per file flat di grandi dimensioni (fino a 100 GB per file) e presenta versionamento dei dati (come Git). Il repository del codice viene utilizzato per ospitare script Envision. Envision è un DSL (Linguaggio di programmazione specifico del dominio) 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 ridistribuita completamente ogni martedì tra le 10:00 e le 14:00 (ora di Parigi). Il tempo di inattività è tipicamente mantenuto sotto i 5 minuti. Lokad si occupa completamente di tutte le questioni di versionamento.

Non è previsto che il dipartimento IT acquisisca mai alcuna competenza specifica con lo stack di Lokad. Tuttavia, se sei curioso, c’è una documentazione tecnica completa.

Panoramica del contributo IT

Ci aspettiamo che il dipartimento IT configuri un data pipeline che invii una breve serie di estrazioni di file flat rilevanti verso 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 sforzi minimi. Dal punto di vista dell’ETL, richiediamo solo la parte ‘E’ (estrazione) nella sua forma più semplice (copia semplice). Per quanto riguarda il formato, Lokad è compatibile con ogni file flat ragionevolmente tabulare.

Ci aspettiamo che il data pipeline venga eseguito almeno su base giornaliera e che sia completamente automatizzato. La quantità di lavoro per il dipartimento IT dipende dallo scope dell’estrazione dei dati (quali sistemi? quali tabelle?). Tuttavia, come regola generale, la configurazione del data pipeline richiede tipicamente circa 15-45 giorni-uomo, anche per grandi aziende. Una volta che il data pipeline è in funzione, Lokad richiede tipicamente 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 scope dell’estrazione dei dati, escludiamo qualsiasi colonna o campo che potrebbe contenere dati personali.

Per l’autenticazione, preferiamo 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, vedere Sicurezza presso Lokad.

Panoramica 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 nell’attuare un’iniziativa di Supply Chain Quantitativa richiede visibilità quando si tratta della timeline del progetto. Mentre si possono ottenere rendimenti positivi in un paio di mesi, spesso ci vogliono fino a due anni per sbloccare il pieno potenziale della Supply Chain Quantitativa. Nel pezzo seguente, forniamo una panoramica di una tipica timeline 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 l’un l’altro e pianificano incontri settimanali. Questi incontri settimanali dureranno fino alla fase di Produzione. Il 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 di vari dettagli della supply chain e alle 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, il Supply Chain Scientist produce le specifiche dei dati necessarie per l’implementazione del progetto. Queste specifiche vengono esaminate e validate insieme al cliente. In particolare, questo documento definirà 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 dati: Dopo aver validato le specifiche, il primo set di dati viene caricato sui server di Lokad dal cliente. Generalmente, 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.

Convalida dei dati: Il Supply Chain Scientist esegue un’indagine approfondita del contenuto del dataset del cliente. In particolare, vengono introdotti controlli di coerenza per monitorare la qualità dei dati secondo molteplici metriche. L’obiettivo è assicurarsi che 1) il dataset sia 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 il Supply Chain Scientist fornisce al cliente vari dashboard che valutano la salute dei dati. Questi dashboard 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 assicurazione della qualità dei dati.

Audit a metà progetto: 6 settimane dopo l’avvio iniziale, viene fissato 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, specialmente quelli che potrebbero ritardare la fase di produzione. Presso Lokad, questo “audit” consiste in uno scambio tra il Supply Chain Scientist e il cliente, basato su una checklist che viene comunicata al cliente in anticipo dal Supply Chain Scientist, subito dopo l’incontro di avvio.

Automazione dell’upload: Una volta che entrambe le parti convalidano la qualità complessiva del set di dati finora caricato, il cliente implementa un processo automatizzato che trasferisce il loro set di dati a Lokad su base regolare - idealmente giornaliera. Allo stesso tempo, sul lato di Lokad, la logica della salute dei dati - con i suoi molteplici controlli - è programmata per essere aggiornata dopo ogni upload.

Configurazione dell’ottimizzazione: Da questo momento in poi, il Supply Chain Scientist ha tutti gli ingredienti necessari per implementare l’ottimizzazione delle decisioni 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 in forma di dashboard. In questa fase, questi dashboard rappresentano solo una versione preliminare dei dashboard finali e devono essere rivisti 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 dal Supply Chain Scientist. Ci sono molti parametri e metodi che possono essere adottati per allineare adeguatamente le caratteristiche della supply chain in fase di ottimizzazione con la logica di ottimizzazione. Quando la metodologia stessa è di importanza strategica per il cliente, questo viene discusso esplicitamente tra il cliente e il Supply Chain Scientist.

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

Supporto e manutenzione: La soluzione è operativa e viene utilizzata dal cliente mentre il Supply Chain Scientist monitora l’esecuzione quotidiana regolare del data pipeline. Le chiamate sono regolarmente organizzate tra il cliente e il Supply Chain Scientist per verificare che l’ottimizzazione fornisca il grado previsto di performance della supply chain. 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. Il Supply Chain Scientist propone modifiche adeguate per accomodare questi diversi cambiamenti. Le chiamate di controllo sono programmate con una frequenza concordata, tipicamente mensile.

Domande Frequenti (FAQ)

1. Gestione delle Release

1.1 Come funzionano le release per Lokad?

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

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

1.2 Con quale frequenza avvengono le release?

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

1.3 Fornite un piano delle prossime release?

Sì, vedi Gestione delle Release 1.2.

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

Lokad ri-deploya, attraverso mezzi automatizzati (script), la propria soluzione. Non apportiamo patch ai sistemi in produzione. Se dobbiamo distribuire un “patch di sicurezza”, ri-deployeremo la soluzione attraverso i nostri soliti mezzi automatizzati.

1.5 Quanto tempo ci vuole per applicare una release importante?

Il processo automatizzato richiede circa 1 ora. C’è un roll-out graduale (macchina per macchina), poiché intendiamo mantenere operativa e accessibile la piattaforma di Lokad durante la release. L’operatività durante un roll-out è discussa in Gestione delle Release 1.7.

1.6 Chi è responsabile dell’esecuzione corretta della release?

Il team di Lokad si assume piena responsabilità dell’esecuzione corretta della release.

1.7 C’è un downtime durante la release?

Principalmente no, ma tenete presente che la soluzione di Lokad è un sistema distribuito dedicato a calcoli su larga scala. Pertanto, l’impatto di una release differisce tra i sistemi front-end e back-end. I sottosistemi rivolti al cliente, come i dashboard, sono progettati per non avere downtime. 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 release.

1.8 Qual è il vostro processo o strategia di testing per una release?

Lokad utilizza processi automatizzati dedicati al testing e alla garanzia della correttezza di una prossima release. Questi processi includono ampie suite di test automatizzati (misurati in migliaia); test unitari, test funzionali, test di performance, ecc. Abbiamo anche progettato 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 prima/dopo una prossima release. Inoltre, possiamo verificare che i profili di performance degli script esistenti rimangano in linea con le aspettative di programmazione, come definite dai nostri clienti.

1.9 Avete più ambienti?

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

Se l’obiettivo è quello di poter eseguire (affiancati) più varianti di script Envision, allora un account Lokad può essere partizionato in più “ambienti”. Se l’obiettivo è quello di poter eseguire qualsiasi tipo di testing, 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 diverse versioni 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 una release?

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

Per situazioni in cui una release potrebbe essere temporaneamente posticipata, vedere Gestione delle release 1.1.

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

Sì. Queste note sono condivise internamente (con i nostri team di scienziati della supply chain). 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 di interesse 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 scienziati della supply chain di Lokad è responsabile dell’implementazione e della manutenzione della soluzione della supply chain di un cliente. Queste situazioni sono conosciute come “supply chain as a service”. In queste disposizioni, il cliente interagisce regolarmente con uno (o più) scienziati della supply chain. Inoltre, la maggior parte dei clienti beneficia di un comitato direttivo settimanale o mensile per discutere lo stato attuale della soluzione e eventuali evoluzioni desiderate. Questo metodo è utilizzato da Lokad per raccogliere tutte le richieste di evoluzione e proporre una roadmap per l’implementazione dei cambiamenti.

1.14 È possibile amministrare il servizio web dell’applicazione e configurarne i parametri?

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

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

2. Prestazioni

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. Considerate i seguenti scenari: - Lokad riceve i dati del cliente (un passaggio giornaliero) con 2 ore di ritardo. 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 scatenerebbe un’interruzione dei job batch (lato Lokad) e avviserebbe uno scienziato della supply chain per indagare sul problema. Lo scienziato della supply chain vede che un ordine di rifornimento automatico è eccezionalmente grande. Lo scienziato della supply chain decide che è necessaria un’analisi 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 più grande pericolo 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 attivare (in modo errato) un lotto di produzione, annullarla può essere estremamente costoso. Incoraggiamo i nostri clienti a non attaccarsi arbitrariamente agli indicatori isolati, poiché questo atteggiamento può incentivare le persone a fornire un lavoro complessivamente inferiore pur apparendo soddisfacente per 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 equivale approssimativamente a “dashboard a tempo costante”. Nel backend, 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 progettazione va molto lontano nel “garantire” la bassa latenza della tipica richiesta dell’utente nella visualizzazione di una dashboard. Questa scelta progettuale impedisce anche alla dashboard di diventare affollata di riquadri - ognuno dei quali richiederebbe richieste di rete - e rallentare l’esperienza complessiva dell’utente.

Riguardo alla durata dei job batch, attraverso Envision possiamo fornire garanzie - a tempo di compilazione - che un job batch verrà completato. Possiamo anche garantire tempi di completamento ampiamente riproducibili per i nostri job batch. Queste garanzie sono ottenute attraverso un’analisi statica e una progettazione attenta del linguaggio Envision - che rende possibili certe classi di analisi statiche in primo luogo. Questo approccio ha dei limiti, ma è nettamente superiore a progettazioni che non offrono alcuna garanzia.

Tuttavia, la latenza end-to-end non è interamente nelle nostre mani. Ad esempio, non controlliamo la qualità della connessione internet utilizzata dai nostri clienti. Un grande foglio di calcolo da Lokad impiegherà del tempo a scaricarsi su una rete a bassa larghezza di banda.

2.3 Avete registri di audit delle prestazioni di sistema?

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

2.4 È possibile monitorare risposte lente o congestione?

Sì. La piattaforma Lokad è dotata di uno scheduler interno che può tracciare l’esecuzione tempestiva dei job batch. Il design di Lokad garantisce in gran parte una risposta a tempo costante per tutte le richieste - ad eccezione delle operazioni a lunga esecuzione, che sono 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 alla affidabilità piuttosto che alle prestazioni. Il bilanciamento del carico a livello di rete avviene attraverso lo strato di rete della piattaforma di cloud computing che utilizziamo (Microsoft Azure). Tuttavia, la distribuzione del carico di lavoro di elaborazione dati interno, gestita dalla piattaforma Lokad, non è gestita tramite bilanciatori di carico, ma attraverso un orchestratore interno associato alla nostra pila di compilatori.

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

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

2.7 Supportate l’elaborazione parallela?

Sì. Envision (il nostro DSL) è progettato attorno alla nozione di esecuzione automaticamente parallelizzata. La piattaforma Lokad sfrutta attivamente la parallelizzazione a più livelli: a livello di core 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 progettuale fondamentale di Envision, la quasi totalità dei carichi di lavoro eseguiti sulla piattaforma Lokad beneficiano di una vasta parallelizzazione, per impostazione predefinita, senza alcuno sforzo specifico per i nostri clienti o i nostri scienziati della catena di approvvigionamento.

2.8 Supportate la memorizzazione nella cache di dati frequentemente accessati?

Sì. Tuttavia, la memorizzazione nella cache viene spesso introdotta come soluzione alternativa per far fronte alle limitazioni delle prestazioni dei database transazionali. Dato che la piattaforma Lokad non include database transazionali, non utilizziamo la 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 comprimere 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 una combinazione di 3 fattori.

1. Una risposta è 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 è vero il terzo condizione. Comprimiamo anche i dati per motivi oltre alla riduzione del traffico di rete; innanzitutto, per ridurre i costi di archiviazione dei dati; e in secondo luogo, per ridurre i ritardi di calcolo.

2.10 Effettuate test di prestazioni?

Sì. Lokad dispone di un’estesa struttura di strumentazione automatizzata orientata alle prestazioni. Questa serie di strumenti ci consente di valutare, prima di ogni rilascio, la differenza di prestazioni della prossima versione 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 tempo di clock, 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 granulare, che è approssimativamente analogo al monitoraggio del dettaglio dell’esecuzione del piano di query (dal punto di vista di un database transazionale).

Consultare 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 gran numero di utenti (secondo gli standard B2B). Questo approccio è in netto contrasto con molte architetture alternative, in particolare database transazionali e 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 sfrutta entrambi. L’orchestratore interno - quello responsabile della parallelizzazione - inizia tipicamente con lo scaling verticale, poiché lo scaling verticale facilita in larga misura la colocalizzazione dei dati. Successivamente, l’orchestratore sfrutta lo scaling orizzontale se il carico di lavoro è abbastanza grande da beneficiare dell’esecuzione su più macchine.

2.14 Effettuate lo scaling automatico di calcolo e archiviazione 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 del calcolo 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 dell’archiviazione è in larga parte eseguito sfruttando le proprietà di autoscaling del negozio di chiavi persistente, come 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 specificamente per il processing 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 file individuali fino a 100GB, e elaboriamo regolarmente tabelle con decine di miliardi di righe. Vai alla Sicurezza di Lokad 4.10

Questo punto è particolarmente tecnico e va oltre lo scopo di questo documento. Per una spiegazione dettagliata, 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 alla luce di vincoli di banda e latenza stretti (lato client)? Ad esempio: banda = 3Mbps (download) / 1Mbps (upload), latenza = 600-800ms

Sì, l’app web progettata da Lokad è stata progettata per supportare scenari in cui la connettività è “scadente” (sia in termini di banda che di latenza). Queste preoccupazioni sono affrontate principalmente dalle scelte di progettazione tecnologica fondamentali. Queste scelte di progettazione architetturale separano anche Lokad dalla massa. Le preoccupazioni sulla banda sono affrontate in due modi. Primo, siamo parsimoniosi quando si tratta di componenti JavaScript di terze parti. Abbiamo meno di 1MB di risorse da recuperare inizialmente. In secondo luogo, la piattaforma offre un controllo completo sulla quantità di dati da includere in qualsiasi 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 imballare tutti i dati rilevanti del dashboard in una singola richiesta HTTP. Questo minimizza l’attrito causato dagli utenti finali a bassa latenza.

2.17 Quali sono le capacità medie e di picco di throughput 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 avvengono tramite messaggi. Tuttavia, il throughput è importante per elaborare rapidamente vaste quantità di dati transazionali. La piattaforma Lokad gestisce, in totale, oltre 1 petabyte di dati. Gestiamo regolarmente oltre 1 terabyte al minuto per grandi lotti di calcolo.

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

2.18 Che 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 singolarmente grandi fino a 100GB. Tuttavia, questa non è una pratica consigliata in quanto di solito è un po’ scomoda (non per Lokad, ma piuttosto per i clienti che dovranno familiarizzare con strumenti esterni per produrre e consumare i file di grandi dimensioni).

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 scienziati della supply chain. Questi scienziati della supply chain sono il primo punto di contatto per segnalare incidenti. In caso di incidente, suggeriamo ai clienti di telefonare direttamente al loro scienziato della supply chain - se il problema è urgente - o di inviare un’email. Gli scienziati della supply chain 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 stretta 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 brevi tempi di inattività) come “incidenti”. Piuttosto, le particolarità effettive della supply chain - che possono o meno riflettere problemi con gli script di Envision implementati nell’account del cliente - sarebbero candidati migliori. I dipartimenti IT esterni sono raramente coinvolti nella risoluzione di questi incidenti.

3.4 Come garantite un’elevata disponibilità?

Lokad è diventata una pioniera (circa 2010) delle piattaforme di cloud computing proprio per garantire una maggiore disponibilità. Oltre a rendere l’infrastruttura ridondante (vedi Incidents 3.5), il design della soluzione di Lokad enfatizza fortemente la semplicità. Contrariamente alle soluzioni software enterprise comparabili, abbiamo significativamente meno dipendenze complesse (quasi di un ordine di grandezza). Uno strato enorme di complessità assente dalla nostra soluzione è un database transazionale. Avendo meno componenti in movimento, abbiamo molto meno modalità di fallimento, 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 singoli di fallimento?

Sì. I nostri sistemi critici sono ridondanti, proprio per evitare punti singoli di fallimento. 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 rollout è in corso.

3.6 Come vi riprendete dai guasti hardware?

Il ripristino dalla maggior parte dei guasti hardware viene eseguito in modo trasparente dalla piattaforma di cloud computing che Lokad utilizza. La ridondanza integrata della piattaforma di Lokad garantisce che i guasti hardware transitori non influenzino il tempo di attività mentre la piattaforma di cloud computing rialloca una nuova risorsa non difettosa. Per lo storage dei dati persistente, Lokad utilizza solo servizi (ad esempio, store chiave-valore) che sono protetti dai guasti hardware attraverso i propri strati di ridondanza.

3.7 Avete un backup?

Sì. Abbiamo un ambiente di backup dedicato a scenari di ripristino da disastri 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 dall’ambiente di produzione (ma non scrivere), mentre l’ambiente di produzione non può né leggere né scrivere dall’ambiente di backup.

3.8 Avete un piano di ripristino da disastri?

Sì. A livello tecnico, il piano di ripristino da disastri 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 disastri include il contatto con ogni cliente che abbiamo, seguendo tipicamente un processo concordato con ciascuno di essi. Per la maggior parte dei nostri clienti, i supply chain scientists 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) attraverso il database e i dati al di fuori del database? Qual è l’Obiettivo di Ripristino del Punto (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 fare il PITR per qualsiasi momento specifico (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 store chiave-valore persistente. Se lo store chiave-valore è compromesso, Lokad si ripristina dal suo storage di backup (mantenuto il più isolato possibile dai nostri sistemi di produzione), ospitato anche in una posizione geografica diversa. 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 di event sourcing anziché uno relazionale. Ciò non elimina la necessità di far rispettare l’integrità dei dati, ma tali preoccupazioni sono affrontate in modi alternativi.

Per quanto riguarda l’elaborazione dei dati del cliente, Envision (DSL di Lokad) ha ampie capacità volte a verificare la sua qualità. Attraverso Envision, è possibile controllare 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 store indirizzabile dal contenuto, rende il testing per il backup e la funzionalità di ripristino dei dati molto più semplice rispetto a quanto lo sia per la maggior parte dei design mainstream che sfruttano database relazionali (come SQL).

Vedi anche Incidenti 3.7.

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

Sì. La strategia di distribuzione di Lokad sfrutta script automatizzati end-to-end, mantenendo deliberatamente poche interventi umani - una nota eccezione è la capacità di attivare un completo ripristino della produzione. Questo approccio fortemente automatizzato facilita il testing della funzionalità di ripristino di emergenza.

Vedi Incidenti 3.8.

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

Sì. Il nostro strumento interno supporta la possibilità di ripristinare l’account di un cliente selezionato (incluso il ripristino dell’account/ambiente a un dato punto nel tempo). Tuttavia, considerando che la piattaforma Lokad stessa presenta ampie capacità di versionamento (ad esempio, gli script Envision sono versionati e le versioni precedenti sono accessibili dall’app stessa), questa capacità viene raramente utilizzata.

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

Sì. Il Recovery Time Objective (RTO) si riferirebbe qui alla quantità di tempo in cui la piattaforma di Lokad potrebbe teoricamente essere inattiva senza causare danni significativi al cliente, nonché il 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 del magazzino a più negozi potrebbe avere un RTO di 1 ora.

In pratica, varie contingenze tecniche possono essere messe in atto per migliorare sostanzialmente l’RTO (cioè, ridurre un downtime teorico). Ad esempio, le decisioni di failover possono essere calcolate in anticipo. Queste decisioni possono essere utilizzate nel caso in cui la piattaforma Lokad non sia disponibile. Rispetto alle decisioni “regolari” ottimizzate, le decisioni di failover potrebbero 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 uno 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 piuttosto che informatico.

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 Lokad è completamente versionato (come Git), proprio per affrontare questa preoccupazione.

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 dati su larga scala - dove 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 affrontare difetti o verificare che i difetti siano stati corretti. Invece, sfruttiamo principalmente scelte di design superiori per fornire una maggiore conoscenza, tracciabilità e riproducibilità.

Queste scelte di design deliberate ci consentono di identificare, riprodurre e correggere difetti in modo che affidarsi esclusivamente ai log non consentirebbe.

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

3.16 Mantenete record di tutte le richieste di servizio e le chiamate di servizio (inclusa la categoria di ciascuna 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 disposizione 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.

Riguardo alle “risoluzioni”, vale la pena notare che la filosofia quantitativa della supply chain di Lokad è volta a 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 facendo scelte finanziariamente informate.

In breve, Lokad possiede gli strumenti e i processi per risolvere prontamente “problemi facili” (come il downtime del server) in modo diretto. Quando si tratta dei problemi più grandi e più significativi della supply chain (come l’allocazione di stock al dettaglio o i problemi di rifornimento di magazzino), si tratta tipicamente 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 specifiche della supply chain del 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 piattaforma Lokad stessa, 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 sotto Linux (Ubuntu).

4.4 Quale sistema di database utilizzate o supportate?

Lokad supporta tutti i sistemi di database che possono produrre esportazioni in file piatti. Ciò include praticamente tutti i sistemi di database del mercato, compresi i modelli più datati. 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 destinati a 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 tenga traccia dell’inventario. Inoltre, è utile se il cliente ha un po’ di esperienza nell’estrazione dei dati (come file piatti) dai propri sistemi transazionali, ma questo non è certamente un prerequisito.

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

N/D. 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 Lokad.

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

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

4.10 Quali sono le interfacce in ingresso e in 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 gli inquilini?

La soluzione di Lokad separa i dati degli inquilini 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) affinché indaghino specificamente sulla possibilità di fughe di dati. Forniamo loro accesso a più account Lokad - in un ambiente dedicato e completamente isolato che riflette quello di produzione - in modo che possano verificare aggressivamente questa proprietà della nostra piattaforma.

4.12 La soluzione può essere containerizzata?

Sì, ma c’è poco o nessun beneficio per la piattaforma di Lokad 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 rilascio 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 proprio 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 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 a quello latino. In particolare, qualsiasi interfaccia utente prodotta dalla piattaforma Lokad può essere ri-localizzata - 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 4.14 sopra.

4.16 Il vostro sistema ha un sistema di Aiuto integrato? Se sì, in quali lingue?

Sì, Lokad è dotato di 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 aiuto.

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 casella Markdown dedicata alla documentazione in formato testo ricco. In secondo luogo, i nostri prodotti includono un “Manuale di Procedura Condiviso”. In generale, il manuale fornisce un’analisi dettagliata non solo della meccanica della soluzione, ma anche del motivo per cui è stato selezionato ciascun elemento (e come soddisfa le specifiche esigenze della catena di approvvigionamento del cliente).

4.17 Il webapp è responsive?

Il webapp di Lokad, insieme ai suoi materiali di supporto (come la documentazione tecnica), è stato progettato per essere responsive. Tuttavia, alcune funzionalità avanzate, come la modifica del codice, sono impraticabili per dispositivi mobili e/o tablet. Pertanto, il design è pensato per massimizzare la reattività per le attività previste eseguite su PC e dispositivi più piccoli, rispettivamente.

4.18 Se il vostro sistema è un webapp, quali browser e versioni supportate? Qual è il vostro standard minimo di browser internet?

Lokad è una webapp 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 poche parole, un browser vulnerabile può essere sfruttato da un attore malintenzionato per esfiltrare dati. Detto ciò, siamo anche piuttosto conservativi quando si tratta di nuove capacità dei browser. Come regola generale, evitiamo di supportare qualsiasi capacità del browser che non sia stata adottata da tutti i principali browser web per almeno 1 anno.

4.19 Per le applicazioni mobili e tablet, quali OS (e versioni) supporta Lokad?

N/D. Poiché Lokad è un’app web fornita come SaaS, i nostri clienti non sono interessati al supporto OS. Internamente, Lokad è sviluppato su Windows, mentre tutto il nostro ambiente cloud-hosted di produzione è su Linux. Pertanto, siamo piuttosto fiduciosi nella ampia portabilità della soluzione Lokad. Anche se non sentiamo alcuna necessità attuale di modificare questa configurazione, se dovesse presentarsi una valida evidenza ci adatteremo di conseguenza.

4.20 Il webapp 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 sulla 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/gli inquilini, cioè gli account clienti. Questo 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 a destinazione multipla (ossia, la capacità di inviare un messaggio a più destinatari o applicazioni)?

La piattaforma Lokad non opera con messaggi. Tuttavia, forniamo capacità di hook HTTP che possono essere utilizzate per generare notifiche di messaggi arbitrariamente complessi, tipicamente attraverso sistemi di terze parti a basso costo. Queste notifiche vengono talvolta utilizzate dai team della supply chain per monitorare il completamento tempestivo di batch di calcoli critici per la missione 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, ntpd viene eseguito 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 degli asset o un database di gestione delle configurazioni (CMDB)?

Sì, abbiamo un software di gestione degli asset IT per supportare i nostri processi. Questa piattaforma ci aiuta a mantenere un elenco completo degli asset e funge da nostro database di gestione delle configurazioni (CMDB). Attraverso questo sistema, possiamo tracciare, gestire e allocare in modo efficiente gli asset hardware e software in tutta l’organizzazione. I nostri team hanno la capacità di identificare rapidamente lo stato, la posizione e la configurazione di qualsiasi asset, 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 gli asset siano catalogati in modo accurato dall’acquisizione alla fine della vita. Le capacità di audit automatizzate, unite 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 termina in un firewall (ad esempio, Internet, reti partner)?

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

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

Inoltre, la presenza di firewall rigorosi può essere controproducente in senso pratico. La nostra esperienza ha dimostrato che tali sistemi spesso incentivano i dipendenti a cercare mezzi alternativi per accedere e condividere informazioni. Questo comporta tipicamente il bypass della rete aziendale (impedendo quindi qualsiasi monitoraggio), utilizzando 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 memorizza 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 trasmettere, elaborare o memorizzare 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 piuttosto sul principio del “mai fidarsi, sempre verificare”. Ogni richiesta di accesso viene convalidata e autenticata, indipendentemente dalla sua origine, che provenga dall’interno o dall’esterno dell’organizzazione.

Ciò garantisce una postura di sicurezza più robusta e olistica, poiché non dipende dalle difese perimetrali come un DMZ ma si concentra invece sulla sicurezza di ciascun 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.