Indice dei contenuti dell'articolo:
Nel mondo dell’hosting e della gestione delle infrastrutture web, AWS (Amazon Web Services) è spesso considerato il punto di riferimento per la scalabilità e l’affidabilità. Tuttavia, come ogni strumento potente, il successo di AWS dipende dalla sua corretta configurazione e gestione. Questo articolo analizza un caso concreto di un sito di astronomia, passioneastronomia.it, che ha subito un downtime di 4 ore nonostante fosse ospitato su AWS. Esploreremo le cause del problema, l’uso di CloudFront e CloudFlare, e l’importanza della Full Page Cache per migliorare le prestazioni e ridurre il consumo di risorse.
Il Caso: passioneastronomia.it
Qualche mese fa, un nostro stimato cliente con un traffico mensile di circa 50 milioni di pagine viste, ci ha segnalato un sito emergente di astronomia che periodicamente aveva problemi di downtime per il troppo traffico.
Lui, che seguiva la pagina di Passione Astronomia, veniva informato dai post pubblicati su Facebook dalla stessa Passione Astronomia. Ogni volta che un post causava un sovraccarico e il sito andava offline, lo comunicavano vantandosi del fatto che il server non riuscisse a gestire l’elevato traffico. Tuttavia, per il proprietario di un sito abituato a gestire 50 milioni di visualizzazioni di pagina al mese, con picchi di oltre 3 milioni al giorno, risulta alquanto “curioso” vedere come un sito che ne fa circa un decimo, ovvero circa 6 milioni al mese (secondo le stime di SimilarWeb), possa andare offline così frequentemente senza che nessuno si adoperi per risolvere il problema.
Questo è realmente un problema, poiché di norma, quando si verifica un downtime e il traffico diretto al sito non riesce a contattarlo o accumula numerosi errori 500, i browser che utilizzano Chromium (il motore alla base di Chrome), tra cui ovviamente anche Chrome, segnalano l’accaduto a Google. Di conseguenza, Google invierà meno traffico verso quel sito nelle ore successive, essendo consapevole che qualcosa non funziona correttamente. Questo può avere un impatto significativo sulla visibilità e sulla performance del sito, penalizzandone ulteriormente il traffico e l’affidabilità agli occhi degli utenti e dei motori di ricerca, oltre che ovviamente un danno di immagine.
Oltretutto anche quando il sito risulta online, non sembra garantire chissà quali performance con un Time To First Byte di circa 500ms alle 8 di mattina con il sito praticamente poco visitato e senza post lanciati che generano traffico. Di seguito potete ad esempio visionare il test TTFB per l’europa con il test TTFB di SpeedVitals.com
Di seguito invece potete visionare il nostro TTFB di Managedserver.it, sito che curiamo in modo maniacale per ottenere le migliori performance.
Stiamo parlando di un TTFB (Time to First Byte) che è 10 volte inferiore e ampiamente al di sotto dei 200 ms massimi che Google considera accettabili prima di segnalare che il tempo di risposta del server è troppo elevato, indicando la necessità di “Migliorare il tempo di risposta del server”.
Oltretutto la lentezza di un TTFB così elevato, fino a diventare irraggiungibile in alcuni momenti della giornata in modo frequente, tra cui anche downtime prolungati, influisce negativamente sui Core Web Vitals che possiamo vedere dal report di Google PageSpeed Insight qui di seguito.
Un Time to First Byte (TTFB) elevato, come mostrato nell’immagine con un valore di 2,3 secondi, può influenzare negativamente gli altri parametri dei Core Web Vitals. Un TTFB alto significa che c’è un ritardo significativo prima che il browser inizi a ricevere dati dal server. Questo ritardo contribuisce a un First Contentful Paint (FCP) elevato (3,4 secondi) e a un Largest Contentful Paint (LCP) elevato (4,7 secondi), poiché il rendering iniziale della pagina è ritardato. Inoltre, un TTFB alto può influire negativamente sull’Interaction to Next Paint (INP) e sul Cumulative Layout Shift (CLS), dato che un caricamento lento della pagina può portare a un’esperienza utente meno fluida e a spostamenti di layout più frequenti.
Abituati a gestire picchi di traffico significativi, anche oltre 2 milioni di visite all’ora e 200 mila al minuto, e specializzati nell’Ottimizzazione dei Core Web Vitals, abbiamo offerto i nostri servizi e la nostra expertise ai proprietari di passioneastronomia.it contattandoli per proporre una gestione managed della loro infrastruttura o migrare ai nostri performanti hosting, tuttavia, la nostra offerta è stata probabilmente fraintesa e sottovalutata, nonchè rifiutata senza troppi complimenti e giri di parole.
Eppure il nostro sito vanta di un TTFB ottimale di appena 22ms in Italia ed un PageSpeed che supera brillantemente il test dei Core Web Vitals come potete vedere di seguito.
Con un portfolio clienti di tipo editoriale significativo e i numeri menzionati in precedenza, che potevano essere valutati in modo imparziale utilizzando gli strumenti messi a disposizione da Google, sembrava incredibile che, in un momento di difficoltà caratterizzato da continui downtime, non avessero colto l’occasione per risolvere in un battibaleno tutti i problemi. Questo avrebbe potuto avvenire a un costo probabilmente pari alla metà di quello del loro attuale fornitore, il quale li vedeva spesso offline o con prestazioni pessime, come indicato dai test sopra riportati.
Passioneastronomia.it e WordPress
Passioneastronomia.it è un sito editoriale sviluppato in WordPress, basato su PHP e MySQL. Sebbene queste tecnologie siano ormai considerate datate rispetto a linguaggi e tecnologie più moderne ed asincrone come Node.js, Go, o database NoSQL come Cassandra, MongoDB o REDIS, continuano a essere ampiamente utilizzate. PHP, ad esempio, è stato sviluppato negli anni ’90 e ha subito numerosi aggiornamenti nel corso del tempo, ma rimane meno performante in situazioni di carico elevato rispetto ai moderni linguaggi asincroni. Allo stesso modo, MySQL, pur essendo un robusto sistema di gestione di database relazionale, può incontrare difficoltà in termini di scalabilità e performance quando gestisce grandi volumi di dati e richieste contemporanee.
Nonostante queste limitazioni, WordPress rimane il sistema di publishing di contenuti più versatile e di facile implementazione disponibile oggi. La sua vasta comunità di sviluppatori, la miriade di plugin disponibili e l’interfaccia intuitiva ne fanno una scelta popolare sia per piccoli blog che per grandi aziende. Anche testate giornalistiche di rilievo come Il Fatto Quotidiano utilizzano WordPress come CMS per la pubblicazione editoriale, dimostrando che, con la giusta configurazione e ottimizzazione, è possibile ottenere performance eccellenti anche con tecnologie considerate meno moderne.
D’altronde anche la NASA, massima espressione da sempre nell’immaginario collettivo della divulgazione scientifica usa WordPress come CMS.
Passioneastronomia.it inizialmente (almeno da quando ce ne hanno parlato circa un anno fa), era ospitato su SiteGround, un servizio di hosting che non sempre è in grado di gestire traffico di questo livello. Successivamente, ad aprile, il sito è passato ad AWS, la scelta del mercato e di molti grandi nomi come Netflix, Airbnb, Spotify, Twitch, LinkedIn, Adobe, Slack e la BBC.
- Netflix: Utilizza AWS per lo streaming video, archiviazione e analisi dei dati.
- Airbnb: Si avvale di AWS per gestire la sua piattaforma globale di ospitalità e il marketplace online.
- Spotify: Utilizza AWS per la distribuzione di musica in streaming, analisi dei dati e machine learning.
- Twitch: La piattaforma di streaming video di proprietà di Amazon si basa su AWS per la trasmissione dei video live e la gestione dei dati.
- LinkedIn: Anche se parte della sua infrastruttura è interna, LinkedIn utilizza AWS per alcuni dei suoi servizi di archiviazione e analisi dei dati.
- Adobe: Offre i suoi servizi di Creative Cloud e altre applicazioni SaaS attraverso AWS.
- Slack: Utilizza AWS per la sua piattaforma di messaggistica e collaborazione.
- BBC: La BBC utilizza AWS per la trasmissione di contenuti video on-demand e la gestione dei dati.
Nonostante la potenza e la scalabilità di AWS, passioneastronomia.it ha continuato a sperimentare downtime, culminando in un’interruzione di 4 ore il 16 maggio, dalle 19:00 alle 23:13, monitorata dal nostro tool Uptime Kuma.
Le cause del Downtime
Il problema principale non risiede in AWS come infrastruttura, ma nella configurazione e gestione del servizio. AWS offre una vasta gamma di servizi, tra cui EC2, database, load balancer, filesystem distribuiti, e CDN come CloudFront. Tuttavia, se utilizzato in modo inappropriato, AWS può portare a gravi problemi di performance.
Il sito passioneastronomia.it non disponeva di un sistema di Full Page Cache adeguato come CloudFront o la versione Pro o Business di CloudFlare con supporto di Cache HTML, o anche un “semplice” Varnish. Gli header di risposta del sito mostrano chiaramente che la cache HTML non era attivata:
HTTP/2 200
date: Thu, 16 May 2024 22:02:18 GMT
content-type: text/html; charset=UTF-8
set-cookie: AWSALBTG=gkrvkTmzuBE7uhKteG6ihiCGQH60BIdF48ki+7cvKP9ia2ltc4cAgn5dVM5l+/WaO8fbb8dzylYF1OYP7PZnmhHdLsauuVLuLntiKviIt8EAxKNbM3yBSyKqrMaGu1SXAQaPGkLnjoHwqz3OkmDHAVqvBB0V3v4d0WOcshbhqixspvTJTic=; Expires=Thu, 23 May 2024 22:02:17 GMT; Path=/
set-cookie: AWSALBTGCORS=gkrvkTmzuBE7uhKteG6ihiCGQH60BIdF48ki+7cvKP9ia2ltc4cAgn5dVM5l+/WaO8fbb8dzylYF1OYP7PZnmhHdLsauuVLuLntiKviIt8EAxKNbM3yBSyKqrMaGu1SXAQaPGkLnjoHwqz3OkmDHAVqvBB0V3v4d0WOcshbhqixspvTJTic=; Expires=Thu, 23 May 2024 22:02:17 GMT; Path=/; SameSite=None; Secure
cf-edge-cache: cache,platform=wordpress
link: <https://www.passioneastronomia.it/wp-json/>; rel="https://api.w.org/"
link: <https://www.passioneastronomia.it/wp-json/wp/v2/pages/49>; rel="alternate"; type="application/json"
link: <https://www.passioneastronomia.it/>; rel=shortlink
vary: Accept-Encoding
cf-cache-status: DYNAMIC
report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v4?s=dvOaq3CI0sDGSeXsjICpJUT0nF1zmp%2BFj1TKPfqJKvyRd%2FuybtNnkc9FKE6SLu7CldFY7brUo1HZwF1kvPoDyisecYzzZC3aI%2FlrjkKCKcs%2BD4LVRylVZMmSQViSYJRA6fO9JU1sg2ejKUk%3D"}],"group":"cf-nel","max_age":604800}
nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
server: cloudflare
cf-ray: 884ea6b518c20e4d-MXP
alt-svc: h3=":443"; ma=86400 La versione Free di CloudFlare non supporta la Cache HTML nella modalità DYNAMIC, causando un carico eccessivo sui server AWS con continue richieste HTML che passano direttamente attraverso i processi PHP e le connessioni al database.
Nel primo caso quanto il carico aumenta in modo significativo il Web Server dell’origin arriva a saturazione essendo impossibilitato addirittura a rispondere e mandando in timeout il reverse proxy della CDN di CloudFlare come nell’immagine seguente :
Nel secondo caso, anche qualora per qualche sprazzo riesca a rispondere il Web Server, certamente il carico di query SQL al database MySQL farà in modo di restituire un errore di connessione al Database come nello screenshot di seguito.
Più sinteticamente è corretto dire senza andare troppo a fondo nel mondo dei DBMS, gestione delle tabelle, delle query e degli indici che questa mancanza di caching adeguato ha diverse implicazioni negative, specialmente per siti ad alto traffico come passioneastronomia.it.
Implicazioni della Mancanza di Cache HTML
- Carico Aumentato sui Server Origin:Senza la cache HTML, ogni richiesta di pagina HTML deve essere elaborata direttamente dai server origin. Questo comporta che ogni visita al sito attivi processi PHP per generare il contenuto dinamico della pagina, aumentando notevolmente il carico sui server. Di conseguenza, il server deve gestire un numero elevato di richieste contemporanee, portando a un rapido esaurimento delle risorse disponibili.
- Sovraccarico del Database:Ogni richiesta HTML può comportare una serie di query al database per recuperare i dati necessari a generare la pagina. Quando il traffico aumenta, il numero di connessioni al database può superare il limite gestibile, causando rallentamenti o addirittura crash del database. Questo sovraccarico del database è spesso la causa principale di downtime prolungati.
- Tempi di Risposta Elevati:Senza caching, il tempo necessario per generare una pagina HTML può essere significativamente più lungo. Ogni richiesta richiede il caricamento e l’esecuzione di script PHP, l’interazione con il database e la generazione dinamica del contenuto. Questo processo è molto più lento rispetto a servire una pagina cacheata, portando a tempi di risposta elevati e un’esperienza utente subottimale.
- Rischio di Downtime:Quando i server origin sono costantemente sotto pressione a causa del numero elevato di richieste, il rischio di downtime aumenta. I server possono diventare non responsivi o addirittura crashare se il carico supera la loro capacità di gestione. Questo è esattamente ciò che è successo a passionaastronomia.it, dove il sito ha sperimentato un downtime significativo a causa dell’incapacità di gestire il traffico elevato senza un adeguato sistema di caching.
Uso Inadeguato di AWS EC2
Sebbene AWS EC2 sia una soluzione potente, l’utilizzo di un’istanza EC2, anche Etra large, senza una corretta configurazione può risultare inefficace. Un’istanza EC2 non è altro che un’istanza virtualizzata con una certa quantità di core e RAM, che offre notevoli risorse computazionali. Tuttavia, senza una corretta gestione del traffico e caching, queste risorse possono essere rapidamente sovraccaricate. La configurazione inadeguata può trasformare un’istanza potente in un collo di bottiglia, incapace di gestire i picchi di traffico elevato.
Per esempio, in assenza di meccanismi di bilanciamento del carico, un singolo server può essere sommerso da un numero eccessivo di richieste simultanee, esaurendo rapidamente la CPU e la memoria disponibili. Inoltre, senza un’efficace strategia di caching, ogni richiesta degli utenti deve essere elaborata completamente dal server origin, coinvolgendo processi PHP e query al database per generare le pagine dinamiche. Questo non solo aumenta i tempi di risposta, ma mette anche a dura prova il database, che può diventare un punto di fallimento critico nonostante come possiamo vedere, il Database sia ospitato su un servizio di Database Gestito come RDS.
MySQL RDS (Relational Database Service) di Amazon AWS è un servizio di database gestito che facilita l’impostazione, il funzionamento e il ridimensionamento di un database MySQL nel cloud. Con MySQL RDS, Amazon si occupa della gestione delle attività amministrative come l’hardware, il sistema operativo, le patch del database e i backup. Questo permette agli utenti di concentrarsi maggiormente sullo sviluppo delle applicazioni e meno sulla gestione dell’infrastruttura.
Anche le migliori istanze EC2 possono quindi fallire se non vengono supportate da una solida architettura di backend. Per massimizzare l’efficienza di un’istanza EC2, è essenziale implementare sistemi di caching a livello di applicazione e utilizzare CDN come CloudFront o CloudFlare per distribuire il carico. In aggiunta, configurare Auto Scaling per adattarsi automaticamente alle variazioni di traffico può prevenire sovraccarichi improvvisi. Solo con una gestione attenta e una configurazione ottimale, un’istanza EC2 può sfruttare appieno le sue potenzialità, garantendo alte prestazioni e affidabilità.
CloudFront e CloudFlare cosa sono ?
CloudFront
CloudFront è una CDN (Content Delivery Network) offerta da AWS che distribuisce contenuti in tutto il mondo, riducendo la latenza e migliorando la velocità di caricamento delle pagine. Questo servizio è particolarmente utile per siti ad alto traffico come passioneastronomia.it, poiché è in grado di cachare intere pagine HTML, riducendo il carico sui server origin e migliorando significativamente l’esperienza utente. La distribuzione dei contenuti tramite una rete globale di nodi edge consente di avvicinare i dati agli utenti finali, garantendo tempi di risposta più rapidi e una maggiore affidabilità. Inoltre, CloudFront offre funzionalità avanzate come la protezione DDoS e l’integrazione con AWS Shield e AWS WAF, che contribuiscono a migliorare la sicurezza del sito. L’uso di CloudFront permette anche di gestire meglio i picchi di traffico, assicurando che le risorse del server origin non siano sovraccaricate durante i periodi di alta domanda. La sua flessibilità e scalabilità lo rendono una soluzione ideale per migliorare le prestazioni del sito e offrire un’esperienza di navigazione più fluida e veloce agli utenti.
CloudFlare
CloudFlare è un altro servizio CDN che offre una vasta gamma di funzionalità per migliorare le prestazioni e la sicurezza dei siti web. A differenza di CloudFront, CloudFlare offre diverse opzioni di caching, inclusa la Cache HTML per le versioni Pro e Business.
I vantaggi di CloudFront e CloudFlare possono essere molto simili, se non addirittura sovrapponibili, il vantaggio più noto di CloudFlare rispetto a CloudFront è che CloudFlare offre un piano di tariffazione Flat con un piano base da 25 dollari al mese che sarebbe stato più che sufficiente per rendere perfettamente conforme il sito passioneastronomia.it ai picchi di traffico che quotidaniamente riceve.
CloudFront invece offre un piano a consumo pertanto il costo è direttamente proporzionale ai dati spostati.
Di fatto, sia CloudFlare che CloudFront offrono un servizio di Full Page Cache in modalità PaaS (Platform as a Service), distinguendosi dalle soluzioni Self Hosted come Varnish Cache. Questa differenza è significativa, poiché un servizio PaaS come quello fornito da CloudFlare e CloudFront elimina la necessità di gestire e mantenere l’infrastruttura di caching da parte dell’utente. Con soluzioni PaaS, l’implementazione e la gestione della cache sono automatizzate e integrate nel servizio, riducendo il carico amministrativo e permettendo ai team di concentrarsi su altre attività critiche.
Ad esempio, CloudFlare e CloudFront offrono interfacce user-friendly per configurare le regole di caching, gestire le invalidazioni e monitorare le prestazioni del sito, il tutto senza richiedere competenze tecniche approfondite in ambito di gestione dei server. Al contrario, soluzioni Self Hosted come Varnish Cache richiedono una configurazione manuale e una gestione continua dell’infrastruttura di caching. Questo comporta la necessità di disporre di personale tecnico qualificato in grado di installare, configurare, monitorare e aggiornare il software di caching, oltre a gestire i server fisici o virtuali su cui esso opera.
Le soluzioni PaaS di CloudFlare e CloudFront offrono anche un vantaggio significativo in termini di scalabilità e affidabilità. Essendo servizi cloud, possono sfruttare la rete globale di nodi distribuiti per offrire prestazioni elevate e bassa latenza agli utenti finali, indipendentemente dalla loro ubicazione geografica. La distribuzione dei contenuti attraverso una rete globale di edge server riduce la latenza e migliora i tempi di caricamento delle pagine, offrendo un’esperienza utente ottimale.
Inoltre, CloudFlare e CloudFront integrano funzionalità avanzate di sicurezza, come la protezione DDoS e l’integrazione con certificati SSL, che possono essere gestite e configurate direttamente dalla piattaforma senza richiedere interventi manuali. Questo livello di automazione e integrazione facilita la protezione delle applicazioni web e garantisce una maggiore tranquillità ai proprietari dei siti.
Mentre soluzioni Self Hosted come Varnish Cache possono offrire un controllo più granulare e personalizzato sulla configurazione della cache, richiedono un impegno significativo in termini di risorse e competenze tecniche. D’altra parte, le soluzioni PaaS di CloudFlare e CloudFront forniscono un servizio completo, automatizzato e altamente scalabile che semplifica la gestione della cache, riduce il carico amministrativo e offre un livello superiore di performance e sicurezza.
Full Page Cache cos’è ?
La Full Page Cache (FPC) è una tecnica di caching che memorizza l’intera pagina HTML generata da un sito web. Questa tecnica è fondamentale per siti ad alto traffico poiché riduce drasticamente il numero di richieste al server origin, diminuendo il carico di lavoro dei processi PHP e delle connessioni al database.
Come Funziona
Quando un utente visita una pagina web, il server genera la pagina HTML e la memorizza nella cache. Le visite successive alla stessa pagina vengono servite direttamente dalla cache, evitando la rigenerazione della pagina e riducendo i tempi di risposta.
Conclusione
La mancanza di una cache HTML è un esempio classico di come l’assenza di una strategia di caching adeguata possa mettere a dura prova anche le infrastrutture più robuste come AWS. Per siti con traffico elevato, l’implementazione di un sistema di caching efficiente è cruciale per ridurre il carico sui server origin, migliorare i tempi di risposta e prevenire downtime significativi. In questo caso specifico, sarebbe bastato utilizzare la versione da 25 dollari mensili di CloudFlare, configurata da un buon sistemista, per risolvere i problemi di downtime. Ancora meglio, implementare un sistema Varnish Cache con CloudFlare posizionato davanti avrebbe permesso di ottenere un doppio strato di cache. Questa configurazione avrebbe offerto il massimo delle performance con un costo sicuramente inferiore rispetto a quello attuale. Utilizzando tali soluzioni, è possibile ottenere significativi miglioramenti nelle prestazioni e nella stabilità del sito, garantendo un’esperienza utente ottimale anche durante i picchi di traffico.
Ciò dimostra che al di là del fornitore dei servizi che si decide di utilizzare, quello che veramente conta è la competenza tecnica e l’expertice dei tecnici che si occupano della messa in opera della migliore strategia di caching al fine di migliorare le performance ed il delivery dei contenuti.
Di seguito il traffico del sito del nostro cliente che ci ha segnalato la redazione di passioneastronomia.it per problemi che avremmo potuto risolvere in 1 ora di lavoro e consulenza, probabilmente risparmiando circa il 75% del budget che stanno spendendo su AWS per andare offline. Ma come si dice in questi casi, chi è causa del suo male, pianga se stesso.
Ci sarà da ridere quando arriveranno le “bollette” di AWS ed in particolare di Amazon RDS per MySQL che è un servizio Pay Per Use e che probabilmente farà lievitare i costi del tutto in modo importante. La sistemistica non è un gioco da ragazzi e come potete vedere consulenti tecnici inesperti possono oltre che far danni, prosciugare il vostro budget, non sapendo quanto possa essere più conveniente spendere investendo su CDN, e Full Page Cache, piuttosto che su servizi di Database Managed come RDS di AWS.
Noi glielo avevamo detto …
Aggiornamenti a distanza di due mesi.
A seguito di questo post e delle presenti elucubrazioni, abbiamo reputato fosse corretto (seppur non dovuto) condividere dei suggerimenti tecnici con l’azienda di Passione Astronomia. Abbiamo pertanto inviato una mail che racchiudeva consigli tecnici estremamente precisi ed utili per lo scenario di hosting attuale su Amazon AWS, consigliando pertanto di installare o una Full Page Cache lato server come CloudFront di Amazon, oppure di abilitare la Cache HTML di CloudFlare che stanno già utilizzando nella modalità Free, magari utilizzando direttamente APO di CloudFlare ad un costo esiguo di circa 5 dollari al mese.
Ci aspettavamo fiduciosi che da li a qualche giorno avremmo visto implementati i nostri preziosi suggerimenti tecnici, tuttavia a distanza di quasi due mesi, dall’analisi degli header di risposta non risultano alcuni cambiamenti in atto, di Cloudfront nemmeno l’ombra, di CloudFlare che cacha l’HTML nemmeno l’ombra ed un tempo di risposta superiore ai 200ms massimi tollerati da Google.
La prova del 9 è stata data dal downtime dell’8 Luglio 2024, cioè ieri, serata in cui il nostro sistema di monitoring Uptime Kuma ci segnalava un downtime prolungato del sito in questione, con un totale e completo offline di 2 ore e 20 minuti, come possiamo visionare dalla dashboard seguente.
Siamo rimasti piuttosto colpiti dal fatto che i nostri consigli, del tutto disinteressati e basati su anni di esperienza, non siano stati recepiti né implementati. È particolarmente sorprendente considerando che realtà editoriali tra le più grandi e importanti del panorama italiano sono disposte a pagare svariate migliaia di euro per risolvere problemi di stabilità, velocità e performance che noi siamo in grado di affrontare efficacemente.
Questo ci porta a una riflessione legittima: gli operatori del settore, nonché i nostri eventuali “colleghi”, sono davvero consapevoli dei capisaldi necessari per la gestione di un progetto importante e di successo come questo? Forse è giunto il momento di pensare seriamente all’istituzione di un Albo Professionale con un esame di stato per l’abilitazione a professioni come quella della sistemistica. Un passo del genere garantirebbe standard elevati di competenza e responsabilità, assicurando che solo i professionisti più preparati possano operare in un settore così cruciale per il successo delle imprese moderne.
