VPS gestito o non gestito: quale scegliere?

VPS gestiti e non gestiti: la risposta breve

Scegliere tra un VPS gestito e uno non gestito è una decisione sul lavoro da svolgere, non sul prodotto. Con un VPS non gestito, gli aggiornamenti, il firewall, i backup, il monitoraggio e il riavvio alle 2 di notte sono a tuo carico. Con un VPS gestito, il provider svolge una parte di queste attività per te, ma l'ampiezza del servizio varia molto da un host all'altro. L'unico confronto utile consiste nell'elenco delle attività che ciascun piano ti solleva dall'obbligo di gestire, rapportato al costo delle tue ore.

Non esiste una definizione standard del termine gestito. Per un host significa che il sistema operativo viene aggiornato e che una persona risponde ai ticket. Per un altro significa che è stato installato un pannello di controllo e che tutto ciò che sta al di sopra resta a tuo carico. Per un terzo significa un contratto di servizio scritto, con un tempo di risposta definito. Due piani che riportano la stessa parola possono differire in ogni aspetto importante. Leggi quindi il documento che definisce l'ambito del servizio prima di considerare il prezzo. Se non hai ancora deciso a cosa debba servire la macchina, la domanda migliore da chiarire prima è che cosa puoi fare davvero con un VPS.

Le attività di cui qualcuno deve essere responsabile

Ogni server in esecuzione comporta lo stesso elenco di attività. Con un piano non gestito, questo elenco è a tuo carico. Con un piano gestito, paghi perché alcune attività vengano rimosse dal tuo elenco. Esamina l’elenco e assegna un responsabile a ogni voce.

• Aggiornamento delle patch del sistema operativo e riavvii richiesti dagli aggiornamenti del kernel.
• Regole del firewall, mantenute corrette quando aggiungi o rimuovi servizi. Le nozioni di base del firewall ufw per un VPS descrivono il ruleset iniziale.
• Accesso SSH: gestione delle chiavi, disabilitazione dell’accesso con password, revoca di una chiave quando una persona lascia il team e una modalità di accesso alternativa se resti escluso.
• Backup, una copia offsite e un ripristino che hai effettivamente eseguito.
• Monitoraggio: sapere se il server è raggiungibile, se il disco ha spazio disponibile, se il servizio è ancora in esecuzione e se il certificato non è scaduto.
• Consultazione dei log e risposta quando qualcosa nei log sembra anomalo.
• Configurazione dei servizi per il web server, il database, il reverse proxy e la coda, se ne utilizzi una.
• Rinnovo dei certificati e risoluzione del problema quando il rinnovo automatico smette di funzionare.
• Capacità: rilevare che la memoria è esaurita prima che lo faccia il killer out of memory (OOM).
• Risposta agli incidenti: essere svegli e raggiungibili a un’ora che non hai scelto.

La maggior parte di queste attività è ordinaria e può essere affidata a uno script. La risposta agli incidenti è l’unica eccezione, perché richiede una persona in grado di prendere decisioni. Questo è il vero servizio venduto da un piano gestito. Per questo la checklist più avanti dedica la maggior parte delle domande all’ambito del supporto, non all’applicazione delle patch.

Cosa generalmente non include la gestione amministrata

È il punto in cui i clienti prendono decisioni errate, quindi è importante essere precisi. Un contratto di gestione amministrata copre normalmente il sistema operativo e il software installato dal provider. Il supporto si ferma al livello della tua applicazione.

Il codice che scrivi tu resta sotto la tua responsabilità. Un errore 500 generato dalla tua applicazione non è un problema del server. Il provider verificherà che il processo del web server sia in esecuzione e ti restituirà il ticket. È un confine corretto. È anche la principale differenza tra ciò che i clienti si aspettano e ciò che hanno acquistato.

I problemi a livello applicativo sono generalmente esclusi dal supporto. Una query lenta sul database, un plugin che ha smesso di funzionare dopo un aggiornamento, una cache configurata in modo errato o una coda di posta che non viene più elaborata: sono tutti problemi che si trovano oltre il perimetro del servizio, anche quando il provider ha installato il software sottostante.

La maggior parte delle operazioni di recupero dei dati è esclusa dal supporto. I backup del provider proteggono l'immagine del server gestita dal provider e servono per il caso in cui si guasti l'hardware dell'host. Raramente sono progettati per il caso in cui tu abbia eliminato una riga, eseguito una migrazione errata o danneggiato un file sei settimane fa e te ne sia accorto oggi. Chiedi qual è il periodo di conservazione, se è possibile recuperare un singolo file e chi esegue il ripristino.

Il software che installi tu resta sotto la tua responsabilità. Se installi Docker, in genere il provider è responsabile dell'host, mentre tu sei responsabile di tutto ciò che si trova all'interno dei container.

Le modifiche manuali possono invalidare il supporto. Alcuni contratti escludono un componente dal perimetro del supporto quando il cliente ne modifica direttamente la configurazione. Chiedi informazioni in merito se prevedi di apportare modifiche di ottimizzazione.

Valuta il tuo tempo rispetto alla differenza mensile

Prendi i due preventivi che hai davanti e annota la differenza mensile. Questo importo è il costo richiesto dal provider per eliminare le attività elencate sopra. Ora assegna un valore alla tua parte del confronto.

• Quanto vale un'ora del tuo tempo e quante ore al mese richiede quell'elenco dopo l'automazione?
• Quanto costa un'ora di downtime del servizio che esegue il carico di lavoro su questo server?

Un server Ubuntu stabile, con aggiornamenti automatici e monitoraggio esterno, richiede pochissima manutenzione ordinaria. Nella maggior parte dei mesi non richiede alcun intervento. Il lavoro ordinario costa poco quando viene gestito da uno script. Gli interventi imprevisti sono la parte costosa, e un piano gestito serve proprio a coprire questi interventi. Se il server esegue un progetto amatoriale, un'interruzione non ha costi e la gestione autonoma è la scelta ovvia. Se invece gestisce ordini, valuta con attenzione se un contratto di supporto riduce davvero la durata dell'interruzione, perché anche un provider gestito deve leggere il tuo ticket, riprodurre il problema e intervenire.

La differenza aumenta anche con il numero di server. I costi dei servizi gestiti vengono generalmente applicati per server, mentre l'automazione viene scritta una volta e poi copiata. Con il secondo server, il costo effettivo dello script scritto per il primo si dimezza; leggi quindi come gestire più server Linux prima di accettare un costo per server. Per i valori di base su entrambi i lati del confronto, quanto costa davvero un VPS al mese definisce il limite inferiore, mentre il confronto tra VPS e server dedicato diventa rilevante quando il carico di lavoro è abbastanza grande da rendere il sovrapprezzo del servizio gestito trascurabile per arrotondamento.

Domande da porre a un provider prima di pagare il sovrapprezzo per la gestione

Ponete le domande prima di pagare e chiedete risposte scritte. Una pagina commerciale non definisce l’ambito del servizio.

1. Che cosa è incluso, attività per attività? Chiedete l’elenco, non la brochure.
2. L’assistenza copre il software che installo io oppure soltanto quello installato da voi?
3. Applicate automaticamente le patch e riavviate il server per gli aggiornamenti del kernel senza chiedermelo prima?
4. Chi è responsabile se una patch applicata da voi causa il malfunzionamento della mia applicazione?
5. Eseguite backup? Dove vengono archiviati, per quanto tempo vengono conservati e chi esegue un ripristino?
6. Avete ripristinato di recente il server di un cliente? Quanto tempo ha richiesto?
7. Qual è il tempo di risposta ai ticket? Cambia alle 03:00 di domenica?
8. Mantengo l’accesso root? Il suo utilizzo limita l’assistenza che fornirete?
9. Il costo viene applicato per server o per account?
10. Se interrompo il rapporto, che cosa posso portare con me? Una configurazione che risiede all’interno di un pannello di controllo proprietario può essere difficile da esportare.

La domanda 5 determina la maggior parte delle altre risposte. Un provider che risponde in modo preciso dimostra di aver già eseguito questa procedura. Una risposta vaga indica che il ripristino non è mai stato verificato; un backup non testato è soltanto una copia. La domanda 5 ha anche un aspetto relativo alla posizione: il luogo fisico in cui sono archiviate le copie è una questione legale oltre che tecnica, e che cosa conta davvero nella scelta del Paese in cui ospitare i server analizza questo aspetto.

Il percorso intermedio: piano non gestito con automazione

La maggior parte dei lettori tecnici non vuole nessuno dei due estremi. Vuole un piano non gestito, con le attività di routine affidate alla macchina, e la propria attenzione riservata a ciò che una macchina non può valutare. Configuratelo il primo giorno. I primi dieci minuti su un nuovo VPS sono il punto di partenza pratico per chi sceglie un piano non gestito, e mettere in sicurezza l’accesso SSH rientra nella stessa prima sessione.

Aggiornamenti automatici di sicurezza

sudo apt update && sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
cat /etc/apt/apt.conf.d/20auto-upgrades

Quel file dovrebbe ora contenere APT::Periodic::Update-Package-Lists "1"; e APT::Periodic::Unattended-Upgrade "1";. Un file mancante, oppure un 0 su una delle due righe, significa che non viene eseguito nulla e non riceverete alcuna notifica.

Eseguite il test senza modificare il sistema. Notate che il pacchetto è unattended-upgrades, mentre il comando è al singolare:

sudo unattended-upgrade --dry-run --debug

L’output elenca tutti i pacchetti considerati e termina con una riga come No packages found that can be upgraded unattended quando non ci sono aggiornamenti in sospeso. Le esecuzioni effettive vengono scritte in /var/log/unattended-upgrades/unattended-upgrades.log, quindi controllate quel file invece di fare supposizioni.

Un aggiornamento del kernel non produce alcun effetto finché la macchina non viene riavviata, perché il kernel in esecuzione è quello caricato all’avvio. Il file /var/run/reboot-required compare quando è necessario un riavvio. Potete controllare la presenza del file oppure lasciare che sia la macchina a gestirlo tramite /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

Automatic-Reboot-WithUsers "false" impedisce il riavvio mentre un utente è connesso. È una scelta più sicura su una macchina che usate in modo interattivo e inutile su una macchina a cui nessuno accede. La configurazione completa degli aggiornamenti automatici su Ubuntu descrive la sintassi della blocklist e le opzioni per le email.

Monitoraggio eseguito da un altro sistema

Un monitor in esecuzione sul server non può informarvi che il server è inattivo, perché sarebbe inattivo anch’esso. Eseguite il controllo su un secondo host o su un servizio esterno. Uptime Kuma per il monitoraggio dello stato è la soluzione self-hosted più comune e deve essere installato su una macchina diversa da quella monitorata.

Controllate almeno quattro aspetti: raggiungibilità, utilizzo del disco, risposta dell’applicazione sulla sua porta effettiva e scadenza dei certificati. Il disco è l’aspetto che spesso coglie di sorpresa. Un file di log o un database che cresce ogni giorno anche di poco può portare la macchina al blocco in un momento che nessun altro indicatore prevede. Il primo sintomo è spesso un servizio che non riesce a scrivere e termina.

df -h
sudo du -xh --max-depth=1 /var | sort -h
journalctl --disk-usage

Aggiungete anche un heartbeat. Un timer sul server richiama un URL dopo ogni backup o controllo di integrità completato correttamente, e il monitor genera un avviso quando il richiamo smette di arrivare. Un server silenzioso produce così un avviso autonomamente, cosa che un controllo basato solo su richieste in ingresso non può fare quando il problema riguarda il percorso di rete.

Backup ripristinati almeno una volta

sudo apt install -y restic
sudo sh -c 'umask 077; printf %s "a-long-random-passphrase" > /root/.restic-pass'
export RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/web01
export RESTIC_PASSWORD_FILE=/root/.restic-pass
sudo -E restic init

restic init stampa created restic repository <id> at sftp:... una sola volta. Se lo eseguite su un repository già esistente, il comando termina con un errore invece di sovrascriverlo: è il comportamento desiderato. Conservate una copia di quella passphrase fuori dal server. Senza di essa il repository non è leggibile e non esiste alcuna procedura di recupero.

sudo -E restic backup /etc /home /srv
sudo -E restic snapshots
sudo -E restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
sudo -E restic check

restic snapshots dovrebbe elencare l’esecuzione appena effettuata con la data odierna. restic check verifica la struttura del repository e stampa no errors were found. Ora eseguite il passaggio che la maggior parte delle persone salta:

sudo -E restic restore latest --target /tmp/restore-check
ls /tmp/restore-check/etc

Il file atteso o esiste o non esiste, e scoprirlo ora richiede dieci minuti. Poi pianificate l’esecuzione con un timer, così non dipenderà da voi. Scrivete /etc/systemd/system/restic-backup.service:

[Unit]
Description=restic backup
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
Environment=RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/web01
Environment=RESTIC_PASSWORD_FILE=/root/.restic-pass
ExecStart=/usr/bin/restic backup /etc /home /srv
ExecStart=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

E /etc/systemd/system/restic-backup.timer:

[Unit]
Description=Run restic backup daily

[Timer]
OnCalendar=daily
RandomizedDelaySec=30m
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
sudo systemctl start restic-backup.service
journalctl -u restic-backup.service -n 30 --no-pager
systemctl list-timers restic-backup.timer

list-timers mostra la prossima esecuzione e il tempo rimanente. Un risultato vuoto significa che avete abilitato il service invece del timer: è l’errore più comune in questa fase. Persistent=true esegue un job saltato dopo il boot successivo, quindi una macchina rimasta spenta durante la notte eseguirà comunque il backup. Backup Restic su un VPS approfondisce la struttura e la conservazione dei repository, mentre service e timer systemd spiega i file delle unità riga per riga.

Cosa non vi offre l’automazione

L’automazione non sostituisce la capacità di valutazione. Un riavvio automatico alle 02:00 avviene indipendentemente dal fatto che l’applicazione torni operativa correttamente. Verificate quindi che ogni servizio si avvii autonomamente, poi eseguite intenzionalmente un riavvio mentre siete presenti:

systemctl is-enabled nginx docker
sudo reboot

Un aggiornamento automatico può inoltre installare un pacchetto che rende inutilizzabile l’applicazione, e nessun componente della pipeline sa che questo è accaduto. Se ne accorge il monitor, motivo per cui il monitoraggio non è opzionale quando gli aggiornamenti sono automatici. La macchina gestisce le attività di routine. La gestione dell’incidente resta a voi.

Quando il managed vale il costo

È importante considerare anche i vantaggi del managed. Quattro situazioni lo rendono la scelta giusta.

• Nessuno nel team gestisce Linux e assumere una persona non è previsto.
• Un requisito di conformità identifica un soggetto responsabile dell’applicazione delle patch e quel soggetto non può essere l’azienda.
• Lo stack rientra tra quelli su cui il provider è specializzato, quindi il suo supporto ha già affrontato problemi come quello in corso.
• La persona che altrimenti svolgerebbe il lavoro è il dipendente più costoso e un’ora del suo tempo costa più di un mese del sovrapprezzo.

Il managed non è automaticamente più sicuro. I piani managed applicano le patch più rapidamente di un proprietario che non presta attenzione, e questo rappresenta un vantaggio concreto. Spesso installano anche un pannello di controllo, cioè un’applicazione di grandi dimensioni esposta in rete, con una pagina di accesso e una propria cronologia di vulnerabilità. Può essere un compromesso ragionevole, ma resta comunque un compromesso.

La decisione si basa ogni volta sullo stesso elenco. Annotate le dieci attività, indicate chi è responsabile di ciascuna attività per ogni preventivo, quindi confrontate la differenza con il valore di un’ora della vostra attenzione. La maggior parte dei lettori tecnici che esegue questa analisi sceglie alla fine una soluzione unmanaged e affida le attività ricorrenti a un timer. È una scelta difendibile, non semplicemente economica.

FAQ

Qual è la differenza tra un VPS gestito e uno non gestito?

Un VPS non gestito fornisce la macchina e nient'altro. Gli aggiornamenti, il firewall, i backup, il monitoraggio e il riavvio dopo un aggiornamento del kernel sono quindi a tuo carico. Con un VPS gestito, parte di queste attività passa al provider, in genere la gestione del sistema operativo e del software installato dal provider. Il perimetro esatto dipende da ciascun provider, non dal termine utilizzato. Prima di confrontare due prezzi, chiedi quindi per iscritto quali attività sono incluse.

Un VPS gestito rende superflui i miei backup?

No. I backup del provider proteggono in genere l'immagine dell'intero server presso il provider e servono soprattutto in caso di guasto dell'host. Raramente sono utili se hai eliminato un file, eseguito una migrazione errata o danneggiato dati alcune settimane fa e te ne sei accorto solo oggi. Chiedi per quanto tempo vengono conservati gli snapshot, se è possibile ripristinare un singolo file e chi esegue il ripristino. Mantieni inoltre una copia offsite indipendente con uno strumento come restic e verificala con restic restore latest --target /tmp/restore-check per assicurarti che funzioni.

Un VPS gestito è più sicuro di uno non gestito?

Non per definizione. Un piano gestito applica gli aggiornamenti più rapidamente di un proprietario che non accede mai al server, riducendo concretamente il rischio. Molti piani gestiti installano anche un pannello di controllo. Un pannello è un'applicazione di grandi dimensioni esposta in rete, con una propria pagina di accesso e una propria cronologia di vulnerabilità. Un server non gestito con aggiornamenti di sicurezza automatici, firewall chiuso, accesso SSH solo tramite chiavi e nessun servizio aggiuntivo in ascolto è un bersaglio più piccolo rispetto a un server gestito con un pannello.

Posso iniziare con un VPS non gestito e passare in seguito a uno gestito?

Di solito sì, anche se raramente basta selezionare un'opzione. Prima di assumersene la responsabilità, i provider verificano o ricreano spesso il server, perché non forniscono supporto per una configurazione che non possono controllare. Chiedi cosa prevede l'onboarding, se è necessaria una reinstallazione e se, in seguito, eventuali configurazioni eseguite autonomamente resteranno fuori dal perimetro del supporto.

Mantengo l'accesso root su un VPS gestito?

Nella maggior parte dei piani VPS gestiti sì, ma l'accesso root interagisce con il perimetro del supporto. Alcuni provider riducono o annullano il supporto per un componente modificato manualmente. Altri possono ricreare il server a partire dal proprio template se l'analisi di un ticket diventa abbastanza approfondita. Fatti confermare questa regola per iscritto prima di modificare la configurazione e mantieni i file di configurazione sotto controllo versione, così una ricostruzione richiederà un'ora invece di un intero fine settimana.