Server virtuale per agenzie: come ospitare i siti dei clienti e non mescolare i loro rischi

Per uno studio web o un'agenzia di marketing, il server VDS consente di raccogliere i siti dei clienti in un unico ambiente gestito. Qui è possibile ospitare progetti di lavoro, copie di test, database e strumenti interni del team, senza creare un'infrastruttura separata per ogni piccolo ordine. Ma un server condiviso non deve significare password, directory e risorse condivise senza limiti. Altrimenti, un aggiornamento non riuscito di un plugin, un file infetto o un'importazione pesante di prodotti colpirà non solo un sito, ma l'intero gruppo.

Spesso il problema non sorge a causa di una potenza insufficiente del VPS. I siti vengono avviati da un unico utente di sistema, si connettono ai database tramite un account condiviso e finiscono in un unico grande archivio di backup. Inizialmente, questo schema sembra conveniente. Col tempo, si scopre che un progetto separato non può essere arrestato, ripristinato o trasferito a un altro sviluppatore in modo sicuro, senza toccare il resto dell'infrastruttura.

Come separare i progetti dei clienti all'interno di un VPS

Ogni sito dovrebbe essere considerato fin dall'inizio come un oggetto separato. Deve avere i propri file, database, log, impostazioni e limiti di utilizzo delle risorse. Allora può essere aggiornato, trasferito o ripristinato indipendentemente dai progetti vicini.

È meglio standardizzare lo schema di hosting di base e applicarlo a tutti i nuovi clienti:

creare un utente di sistema separato, una directory e un pool PHP per ogni sito;
utilizzare un database e un account separati senza accesso a tabelle altrui;
impostare limiti di memoria, tempo di CPU, numero di processi e spazio su disco;
separare gli ambienti di lavoro e di test;
tenere log separati degli errori e delle richieste per ogni progetto;
non memorizzare password e chiavi di accesso in file aperti o tabelle condivise dal team.

Un utente di sistema separato è necessario non solo per mantenere ordine nelle directory. Se più siti vengono avviati con gli stessi diritti, uno script dannoso su uno di essi può leggere o modificare i file dei progetti vicini. Nelle raccomandazioni per la sicurezza di WordPress si consiglia anche di limitare i diritti del file system e di non consentire ai processi di scrivere dove non è necessario.

È altrettanto pericoloso collegare tutti i siti ai database tramite un unico utente con diritti ampi. La compromissione di un file di configurazione in questo caso apre l'accesso ai dati di altri clienti. Per ogni CMS è opportuno creare un proprio account e consentirgli di lavorare solo con il database corrispondente.

Limita le risorse dei singoli siti

Un negozio durante un'importazione notturna può occupare tutta la memoria disponibile o avviare così tanti processi che gli altri siti iniziano a rispondere lentamente. Il negozio stesso può rimanere accessibile, quindi la causa del problema non viene sempre trovata immediatamente.

I limiti non devono essere troppo rigidi. Il loro compito è non rallentare il progetto, ma non consentire a un processo di utilizzare senza controllo l'intero server. Dopo il lancio di un nuovo sito, è opportuno monitorare il carico per alcune settimane e poi impostare i limiti con un margine ragionevole.

Concedi accesso solo al progetto necessario

Una password root condivisa, conosciuta da tutti gli sviluppatori e appaltatori, priva l'agenzia del controllo. Non è possibile stabilire chi ha apportato modifiche, chiudere rapidamente l'accesso a una persona o limitare il suo lavoro a un sito specifico.

Per gestire gli accessi, è opportuno introdurre alcune regole:

fornire chiavi SSH personali invece di una sola password per l'intero team;
non concedere accesso root se all'esperto bastano i diritti su una directory separata;
tenere un elenco degli accessi attivi con la data di emissione e la persona responsabile;
eliminare gli account e le chiavi dopo il completamento dei lavori;
una volta al trimestre, controllare chi ha ancora accesso al server e ai pannelli di controllo;
utilizzare l'autenticazione a due fattori per gli account con diritti estesi.

Di solito, un esperto SEO esterno ha bisogno di CMS, analisi e console di ricerca, ma non dell'ambiente file dell'intero VPS. Un content manager non ha bisogno di accesso al database, e uno sviluppatore di un sito non dovrebbe vedere le directory di altri clienti. Questo è in linea con il principio del minimo privilegio: l'utente riceve solo i diritti necessari per svolgere il proprio lavoro.

Proteggi lo staging non meno del sito di produzione

Se lo staging è ospitato nello stesso account di altri siti, la sua compromissione può aprire l'accesso non solo alla copia di test. Un malintenzionato può accedere alle directory vicine, trovare file di configurazione con password o modificare file di altri progetti.

Pertanto, l'accesso allo staging dovrebbe essere limitato da password, indirizzi IP o una rete privata. Il divieto di indicizzazione in robots.txt da parte di visitatori esterni non offre protezione.

Controlla anche le integrazioni: la versione di test non dovrebbe inviare email reali, effettuare pagamenti, creare contratti nel CRM o modificare le giacenze di prodotti.

Come mantenere l'infrastruttura dopo il lancio

Separare bene i siti all'inizio non è sufficiente. Il numero di clienti cresce, nei progetti compaiono nuovi moduli, cambiano gli appaltatori e le tempistiche degli aggiornamenti. Senza un controllo regolare, anche un VPS ben organizzato si trasforma gradualmente in una giungla digitale, dove nessuno sa quali processi sono attivi e a chi appartengono gli accessi.

Configura un backup separato per ogni sito

Un unico backup dell'intero VPS è comodo per il ripristino del server dopo un guasto totale, ma non si adatta bene al lavoro quotidiano dell'agenzia. Se a causa di un aggiornamento non riuscito un progetto si rompe, non è possibile ripristinare insieme ad esso altri quindici siti funzionanti.

Lo schema di backup deve tenere conto di:

copie separate di file e database per ogni cliente;
la frequenza di copia in base al ritmo di aggiornamento delle informazioni;
la conservazione di almeno una copia al di fuori del VPS principale;
la crittografia degli archivi con dati personali;
il controllo automatico del completamento delle attività e delle dimensioni dei file;
il ripristino periodico di test in un ambiente pulito.

La frequenza di backup non è determinata dalla dimensione del sito, ma dalla quantità di informazioni che è accettabile perdere. Per una risorsa aziendale, dove le notizie escono alcune volte al mese, potrebbe bastare un backup giornaliero. Per un negozio con ordini costanti, un backup al giorno significa già il rischio di perdere una parte significativa delle operazioni.

Monitora quale sito crea un carico di picco

Un sito che richiede molte risorse può rallentare tutti i progetti sul server. Le cause sono spesso importazioni di prodotti, backup, attività cron, traffico bot o errori di plugin.

Imposta notifiche per picchi di CPU e memoria, riempimento del disco, errori 5xx e aumento dei tempi di risposta. Quando trovi la fonte del carico, interrompi il processo problematico e controlla i log, i plugin, le attività cron e le query al database.

Se il carico è causato da un errore, deve essere risolto. Se il sito ha realmente bisogno di più risorse, limita il suo consumo o trasferiscilo su un server virtuale separato, in modo che non influisca sugli altri clienti.

Tieni una scheda tecnica di ogni progetto

Quando un'agenzia gestisce molti siti, le informazioni importanti non devono rimanere solo nella testa di uno sviluppatore. Per ogni progetto è opportuno registrare la versione di PHP, la posizione del database, i servizi esterni connessi, il programma di backup, i professionisti responsabili e l'ordine di ripristino in caso di emergenza.

È utile anche annotare quali processi creano il maggior carico. Se si sa che un negozio importa un catalogo ogni giorno alle 03:00, il team non dovrà indagare ogni volta su un breve picco nell'uso della CPU. E se il carico si verifica in un altro momento, può già essere considerato un'anomalia.

La scheda tecnica deve essere aggiornata dopo ogni modifica della configurazione del server, collegamento di una nuova integrazione o trasferimento del progetto a un altro team. Questo semplifica la manutenzione e riduce il tempo di ripristino dopo un errore.

Quando un sito cliente deve essere spostato su un server separato

Aumentare la configurazione dell'intero VPS a causa di un sito pesante non è sempre vantaggioso. L'agenzia inizia a pagare risorse aggiuntive per l'intero gruppo, anche se le utilizza principalmente un solo cliente. In questa situazione, è più logico separare il progetto.

Il fermo del progetto ha un costo elevato

Un piccolo sito vetrina e un negozio online, attraverso il quale passa la maggior parte delle vendite dell'azienda, non dovrebbero avere lo stesso modello di hosting solo perché entrambi funzionano su WordPress. Per un servizio critico, sono importanti backup separati, una propria riserva di risorse e la possibilità di effettuare lavori tecnici indipendentemente dagli altri clienti.

Per un grande negozio, un portale o un sistema con volumi significativi di dati, il passo successivo potrebbe essere l'affitto di un server dedicato. Tuttavia, la decisione non dovrebbe essere legata al numero di domini. Decine di siti semplici a volte richiedono meno risorse di un singolo catalogo con filtri complessi, ricerca, sincronizzazione delle giacenze e continua elaborazione di file.

Il progetto consuma regolarmente una parte significativa delle risorse

Se un negozio utilizza metà della memoria del VPS in un giorno normale, durante una svendita, una campagna pubblicitaria o un'importazione di massa non ci saranno più risorse. È meglio pianificare il trasferimento prima del periodo di picco, lasciando tempo per testare, sincronizzare il database e aggiornare il DNS.

Prima della migrazione, è opportuno verificare se è possibile ridurre il carico tramite caching, ottimizzazione delle query, code o modifica del programma delle attività in background. Un server separato non risolverà un codice lento, anche se gli darà più risorse.

Il sito ha bisogno di un ambiente software speciale

Un cliente può richiedere una versione diversa delle librerie di sistema, un proprio server web, moduli non standard o un programma di aggiornamenti separato. Adattare un VPS condiviso a lui è rischioso: una modifica della configurazione può compromettere il funzionamento degli altri siti.

Un ambiente separato è anche appropriato quando il cliente desidera avere accesso amministrativo. Non è possibile concederlo a un server dove sono ospitati progetti di terzi, nemmeno in presenza di buoni rapporti e accordi firmati.

Un VPS può rimanere per anni un centro comodo per i siti dei clienti. La stabilità non dipende dalla massima riserva di potenza, ma dalle regole secondo cui l'agenzia crea progetti, concede accessi, configura backup e risponde all'aumento del carico. Quando questi processi sono descritti e vengono eseguiti in modo coerente, il problema di un cliente non si trasforma in un'emergenza comune.