Se lavorate nel web vi sarà capitato di vedere discussioni online in cui qualcuno chiede consiglio su aziende di hosting. Ci avete fatto caso che ognuno ne consiglia una diversa? Ad un certo punto ero tentato di aprirne una mia; il nome sarebbe dovuto essere “Hosting Definitivo”. Poi ho capito che:
- non sono un imprenditore, ma un professionista (secondo voi qual è la differenza? scrivetelo nei commenti)
- per le persone, un’azienda di hosting vale l’altra
Ho notato che in questo settore si possono verificare tutta una serie di situazioni che il cliente tenta di risolvere cambiando continuamente fornitore e sperando di azzeccare finalmente quello giusto. Ma quello giusto – indovinate un po’? – alla fine non si trova mai, proprio come il principe azzurro? Viceversa, come accade in tutti i rapporti, anche in quello tra l’azienda di hosting e il proprietario di siti è possibile lavorarci su e renderlo un po’ più… definitivo: in questo ho trovato il mio personale ikigai. Ora vi faccio alcuni esempi.
L’aumento di prezzo
Per rivendere hosting non servono investimenti strutturali: basta prendersi un server, installarci sopra un pannello di controllo e iniziare ad aprirci account. Ovviamente ci sono delle normative a cui adempiere, ma questo è un altro discorso. Per attirare clienti scontenti (e abbiamo che ce ne sono) basta applicare dei prezzi bassi e il gioco è fatto: ora iniziano i problemi. Con poco margine di guadagno appena un cliente apre un ticket rischiamo di andare in perdita. Ragion per cui saremo prima o poi costretti a rivedere il nostro listino per continuare a inseguire il mito della rendita passiva. Qualcuno è chiaro fin dal principio, prospettando un anno in promozione prima della tariffa: questo evita che le persone cambino per ripicca, rischiando però di spendere tempo e denaro con la migrazione.
La carenza di risorse
Per massimizzare la rendita un fornitore di hosting cerca sempre di stipare quanti più siti possibili all’interno di un server, sfruttando magari appositi sistemi per contenere l’invasività dei singoli siti (uno su tutti: CloudLinux). Può capitare quindi di ricevere dei messaggi relativi all’eccessivo sfruttamento di una qualche risorsa, o di vedere addirittura il sito offline per qualche minuto. A volte queste situazioni possono essere semplicemente un modo subdolo per proporre un piano più costoso (se le visite sono più o meno costanti inizia a drizzare le orecchie), altre volte potrebbe esserci una vera problematica:
- bot stupidi o malvagi potrebbero aver preso di mira il tuo sito, saturando la CPU, cioè le risorse di calcolo
- script PHP “buggati” possono farti incappare in un max_execution_time o in un memory_limit
- la configurazione errata di uno o più plugin di backup o una politica di logging scriteriata potrebbero saturare lo spazio disco
In questi casi l’interesse dell’azienda di hosting è quello di salvaguardare la stabilità del server, accettando che il singolo cliente possa cambiare fornitore: tanto basta una promozione o magari un nuovo brand per rifare il pieno di clienti, no? Il proprietario del sito spesso non può fare altro che spendere di più, anche perché chi ha realizzato il sito se non si rende irreperibile potrebbe comunque non avere le competenze per risolvere il problema.
Gli incidenti
Al di là dei problemi di risorse a volte possono capitare eventi catastrofici che comportano un tempo significativo di buio. Hard disk ed alimentatori si possono guastare; anche se ormai sono piuttosto ridondati e sostituiti rapidamente. Possono scatenarsi anche cortocircuiti e incendi, come capitò ad Aruba e ad OVH. Dando per scontato che voi abbiate sempre un backup del sito per il caso pessimo in questi casi bisogna accettare che nella vita esistono eventi imprevedibili e che la ruota gira per tutti: ciò che conta in questi casi è la tempestività nelle reazioni e la chiarezza nelle comunicazioni.
Le intrusioni
Un sito è continuamente esposto a tentativi di intrusione, i quali possono avere successo sia perché le password sono deboli, sia perché abbiamo trascurato aggiornamenti di un CMS o dei suoi componenti (temi, plugin, ecc…). È bene sottolineare che in questi casi il sito non quasi mai il bersaglio dell’attacco, ma solo uno strumento per poi iniziare a mandare spam, caricare pagine per il phishing, inoltrare i visitatori. A questo punto chi gestisce il server riceve un sollecito da parte del provider in cui si paventa il blocco dell’IP, e per evitare che tale blocco coinvolga tutti i clienti del server viene bloccato l’hosting del malcapitato. La soluzione di questa problematica deve essere radicale: il sito va ricreato senza riutilizzare i file presenti sul server, perché i codici malevoli possono essere infilati in qualsiasi file, a qualsiasi altezza; non si può per esempio ricaricare un backup e metterlo in sicurezza perché è impossibile sapere quando è avvenuta l’intrusione.
Nel caso di WordPress il giusto approccio è:
- scaricarsi la directory degli uploads
- cancellare tutto
- controllare la tabella dei cron
- caricare un core aggiornato
- caricare il tema aggiornato
- caricarsi i plugin aggiornati
- ricaricare gli uploads una volta eliminati tutti i file php che potrebbero essere stati caricati all’interno
- ricreare un file wp-config.php, con password del database e chiavi di salatura aggiornate
- cancellare amministratori abusivi e cambiare la password di quelli legittimi
- ricreare il file .htaccess
Il tutto ammesso e concesso che non siano stati caricati dei file FTP estranei a WordPress: in questo caso vanno controllati (o fatti controllare) riga per riga se sono script PHP, altrimenti possono essere di nuovo caricati via FTP. Per questo motivo io raccomando sempre di avere solo un’installazione di WordPress in uno spazio hosting, sfruttando magari la funzionalità multisite, e di caricare tutti i file tramite l’apposita funzionalità di upload di WordPress.
La versione di PHP
Il nostro hosting potrebbe avere una versione di php troppo vecchia per le versioni recente di WordPress, ma spesso basta agire sul pannello dell’hosting per impostarne una più recente. Conviene sempre andare per gradi, senza impostare subito l’ultimissima versione e verificando ad ogni step che il sito si comporti come previsto. Esiste anche il problema inverso, che si verifica ad esempio quando il sito viene migrato dal nostro fornitore su un server più recente, e il sito smette di funzionare proprio perché viene fatto affidamento su funzionalità di php rimosse. Si può tentare di aggiornare via FTP i componenti che danno errore, oppure cercare di tornare provvisoriamente ad una versione precedente.
Il sito è troppo lento
I vari CMS stanno diventando sempre più esigenti in termini di risorse. Se si ha un Magento per esempio ha poco senso il cercare di risparmiare con un server condiviso. Ma la maggior parte delle volte si riescono a risolvere gran parte dei problemi di prestazioni agendo direttamente sul pannello dell’hosting e sul CMS.
Questi sono i punti da tenere in considerazione:
- La selezione di una versione di php più recente
- L’attivazione di http/2, Opcache e Redis
- L’ottimizzazione delle immagini
- La cache statica
- La semplificazione delle pagine
Questa materia ultimamente sta diventando un lavoro a parte, soprattutto da quando Google ha introdotto i Web Vitals.
L’assistenza tecnica
Ecco un’immagine che secondo trasmette lo spirito dello scambio di messaggi tra un tipico cliente e una tipica azienda di hosting:
Avete mai sentito parlare del problema XY? Ve lo spiego subito.
- il cliente incontra un problema X, e non sa come risolverlo.
- il cliente si convince che riuscirà a risolvere il problema con Y
- il cliente non sa neanche come arrivare ad Y
- a questo punto prende coraggio e scrive all’assistenza per avere Y
- l’operatore consegna Y, anche se magari la richiesta è inconsueta
- il problema non si risolve e la situazione degenera
Il problema è che proprio le persone con un minimo di infarinatura tecnologica che arrivano a chiederti Y, e se non si ha la massima delicatezza e il massimo rispetto conviene dare Y e basta. Purtroppo Y potrebbe essere qualcosa che compromette la stabilità e la sicurezza del server (“…tu vuoi COSA? … per fare CHE???”), ma questi sono concetti che interessano poco a chi ha bisogno che il sito funzioni per vendere i suoi prodotti o servizi. Spesso infine l’ansia e il panico annebbiano la mente, e tante volte le persone hanno semplicemente bisogno di sentire la voce di un essere umano in empatia con loro per ritrovare la lucidità e arrivare a spiegare il problema X.
“La gente non vuole un trapano, vuole un buco nel muro” (Philip Kotler)
Parlami della tua esperienza
Facciamo una bella cosa. Se ciò che ti ho scritto ti sembra famigliare e vorresti un mio supporto professionale sul tuo hosting attuale o sul tuo server prendi pure un appuntamento, senza impegno. Che ne dici?
1 thought on “Perché le persone continuano a cambiare fornitore di hosting?”