Web hosting per aziende: come scegliere senza sbagliare tra prestazioni, backup e assistenza

Prima di scegliere un piano di web hosting, raccogli le informazioni che il provider rende disponibili e trasformale in domande verificabili. La matrice proposta qui separa otto dimensioni: uptime e condizioni dello SLA, risorse e limiti, prestazioni osservabili, backup e ripristino, staging, sicurezza, supporto e scalabilità o migrazione.

La matrice non richiede necessariamente un punteggio numerico. Puoi annotare per ogni voce che cosa è documentato, che cosa è incluso, quali condizioni si applicano e quali aspetti richiedono un chiarimento.

1. Parti dalle domande del progetto

Prima di confrontare i piani, prepara una lista di domande riferite al sito da gestire. L’obiettivo è stabilire quali voci della matrice devono essere verificate con maggiore attenzione.

• Continuità: quali condizioni di uptime e SLA sono dichiarate?
• Prestazioni: quali pagine o funzioni devono essere osservate e con quali dati?
• Dati: quali contenuti devono essere recuperabili e attraverso quale procedura?
• Cambiamenti: esiste un ambiente separato per eseguire test prima della pubblicazione?
• Operatività: quali canali di supporto sono disponibili e quali attività restano a carico del cliente?
• Evoluzione: come vengono gestiti un upgrade o una migrazione?

Puoi usare anche scenari ipotetici per ordinare le domande. In uno scenario con pubblicazioni frequenti, inserisci in evidenza staging, trasferimento delle modifiche e procedura di ritorno. In uno scenario con attenzione prioritaria al recupero dei dati, porta in primo piano frequenza dei backup, conservazione, separazione e ripristino.

2. La matrice decisionale in otto dimensioni

Uptime e condizioni dello SLA

Non fermarti alla percentuale di disponibilità riportata nella scheda del piano. Chiedi che cosa copre lo SLA, quali eventi sono esclusi, come viene misurata l’indisponibilità e che cosa è previsto se le condizioni dichiarate non vengono rispettate.

Nella matrice inserisci la formula utilizzata, le condizioni applicabili e il metodo di verifica. Se una voce è descritta soltanto con una promessa generica, annotala come elemento da chiarire.

Risorse e limiti

Raccogli le risorse dichiarate e i limiti operativi. Le domande possono riguardare ciò che accade quando il sito utilizza più risorse del previsto, quali configurazioni sono modificabili e quali interventi richiedono un altro piano.

Affianca alla voce relativa allo spazio disponibile le informazioni su limiti, configurazioni e attività che richiedono assistenza. In questo modo il confronto resta legato a ciò che il piano documenta.

Prestazioni osservabili

Un’etichetta come “server veloce” non è sufficiente per valutare le prestazioni. È opportuno distinguere tra misurazioni di laboratorio e dati reali degli utenti e osservare metriche come LCP, INP e CLS. L’hosting è una componente della prestazione complessiva e non costituisce una garanzia automatica di buoni risultati.

Chiedi quali dati possono essere raccolti prima e dopo una modifica dell’infrastruttura. La domanda operativa è: quale cambiamento può essere osservato e con quale metodo? Se una proposta non indica un criterio di osservazione, registrala come promessa non ancora verificata.

Per approfondire la differenza tra dati reali e misurazioni di laboratorio puoi consultare la documentazione di Google for Developers.

Backup e ripristino

Un piano di backup è più credibile quando specifica frequenza, conservazione, protezione, separazione dalla sorgente e modalità di ripristino. È utile verificare anche se le copie sono separate dalla sorgente, protette quando appropriato e sottoposte a test regolari di disponibilità e integrità.

Inserisci nella matrice queste domande:

• Con quale frequenza viene eseguito il backup?
• Per quanto tempo vengono conservate le copie?
• Dove sono mantenute rispetto alla sorgente?
• Chi può accedervi?
• Qual è la procedura di ripristino?
• Il ripristino è stato testato e quale esito è documentabile?

RPO e RTO sono criteri utili per il confronto. Il primo aiuta a chiarire quanta perdita di dati è accettabile; il secondo quanto tempo può trascorrere prima del ripristino del servizio. La loro presenza consente di formulare un requisito operativo verificabile invece di fermarsi alla parola “backup”.

Le indicazioni di CISA possono essere usate per preparare domande su separazione, protezione e test dei backup.

Staging e pubblicazione

Lo staging dovrebbe essere un ambiente separato nel quale eseguire test finali prima della pubblicazione e, quando possibile, dovrebbe rispecchiare la configurazione di produzione. Nella matrice verifica se esiste davvero, se è incluso nel piano e se può essere sincronizzato o ripristinato senza operazioni manuali rischiose.

Chiedi come vengono trasferite le modifiche verso l’ambiente online e come si torna indietro se un aggiornamento crea un problema. Se il provider usa il termine “staging” per indicare una copia manuale del sito, annota la procedura effettiva e le attività richieste.

Per questo confronto puoi consultare la documentazione di Microsoft Learn sullo staging e sulla configurazione dell’ambiente destinato ai test finali.

Sicurezza verificabile

Per confrontare la sicurezza dell’offerta, chiedi controlli e procedure verificabili invece di fermarti a badge o formule promozionali. Le aree da chiarire includono gestione degli accessi, aggiornamenti, protezione dei dati, logging, risposta agli incidenti e responsabilità condivise.

Una domanda utile è: quale attività è compresa nel piano, quale è a carico del cliente e quale viene gestita su richiesta? La risposta può essere annotata nella matrice insieme alla documentazione disponibile.

OWASP ASVS può essere utilizzato come riferimento per strutturare domande tecniche e requisiti di verifica delle applicazioni web. Il suo utilizzo non consente di dichiarare automaticamente sicuro un piano.

Supporto e responsabilità

Per la voce supporto, registra canali disponibili, orari dichiarati, tipo di assistenza, informazioni necessarie per aprire una richiesta e modalità di escalation.

Chiedi inoltre chi esegue le attività operative relative a backup, ripristini, aggiornamenti, configurazioni e incidenti: il provider, il team che gestisce il sito oppure il cliente. Puoi usare tre esiti nella matrice: responsabilità chiara, responsabilità condivisa da dettagliare, responsabilità non documentata.

Scalabilità e migrazione

Per questa voce raccogli le informazioni su risorse, configurazioni e responsabilità quando il progetto richiede un upgrade o un cambiamento di ambiente. Chiedi quali passaggi sono previsti, quali condizioni si applicano e quali attività devono essere pianificate.

Per una migrazione, prepara una lista con accessi, backup, trasferimento dei contenuti, configurazioni, DNS, certificati, test e piano di ritorno. Se un passaggio non è documentato, trattalo come una richiesta di chiarimento o come un’attività da pianificare.

3. Trasforma la matrice in una procedura if/then

La matrice può diventare una sequenza di decisioni operative:

1. Se il provider non documenta frequenza, conservazione e ripristino dei backup, allora chiedi queste informazioni prima di procedere al confronto.
2. Se le prestazioni sono presentate solo con un’etichetta commerciale, allora richiedi un metodo di osservazione basato sulle pagine e sui dati del progetto.
3. Se lo staging non è incluso o non rispecchia la produzione, allora annota le operazioni necessarie per testare e pubblicare le modifiche.
4. Se la sicurezza è descritta soltanto con badge, allora chiedi controlli, responsabilità e procedure verificabili.
5. Se SLA, supporto o migrazione hanno condizioni poco chiare, allora inserisci una richiesta di chiarimento nella matrice.
6. Se il piano non documenta il passaggio a una configurazione diversa, allora chiedi quali attività e responsabilità sono previste.

Questa sequenza può essere utilizzata come checklist durante il confronto tra le offerte, senza trasformare una caratteristica dichiarata in un risultato garantito.

4. Come trattare il prezzo nel confronto

Il prezzo può essere annotato insieme alle condizioni e alle funzioni incluse, senza usarlo come unico criterio. Per ogni piano, registra:

• che cosa è incluso;
• quali funzioni richiedono un livello superiore;
• quali attività sono a carico del cliente;
• quali condizioni si applicano all’assistenza o alla migrazione;
• quale procedura è prevista per cambiare configurazione.

Questa raccolta consente di mantenere separati il dato economico, le caratteristiche dichiarate e le attività operative da chiarire.

5. Checklist finale prima della scelta

Prima di approvare un piano, verifica di poter rispondere alle seguenti domande:

1. Le condizioni di uptime e SLA sono leggibili e verificabili?
2. Risorse e limiti sono descritti senza ambiguità?
3. Esiste un metodo per osservare le prestazioni del progetto?
4. Backup, conservazione, separazione e ripristino sono documentati?
5. RPO e RTO sono definiti?
6. Lo staging è realmente disponibile e utilizzabile?
7. Controlli di sicurezza e responsabilità sono definiti?
8. Il supporto ha canali e procedure chiari?
9. Upgrade e migrazione sono pianificabili?
10. Le condizioni economiche e operative sono state annotate insieme?

Se una risposta manca, trasformala in una richiesta di chiarimento o in un’attività da pianificare. La matrice resta aggiornata finché ogni voce non presenta una risposta, una condizione o un elemento da verificare.

Quando coinvolgere chi progetta e gestisce il sito

Se devi definire o rivedere l’infrastruttura di un progetto aziendale, puoi approfondire il percorso di realizzazione di siti web di Indicaweb. Il confronto può includere scelta, configurazione e gestione dell’infrastruttura, insieme alle attività previste per il sito.

Usa la matrice per mantenere distinti dati dichiarati, condizioni contrattuali, procedure operative e domande ancora aperte. In questo modo la scelta dell’hosting può essere discussa sulla base di elementi verificabili.