{"id":83002,"date":"2020-05-27T13:42:38","date_gmt":"2020-05-27T11:42:38","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/delaem-podderzhku-deshevle-starayas-ne-rasteryat-kachestvo"},"modified":"2020-05-27T13:42:38","modified_gmt":"2020-05-27T11:42:38","slug":"delaem-podderzhku-deshevle-starayas-ne-rasteryat-kachestvo","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/delaem-podderzhku-deshevle-starayas-ne-rasteryat-kachestvo","title":{"rendered":"Offriamo supporto a un costo inferiore, cercando di non perdere qualit\u00e0","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Offriamo<\/a><\/noindex>La modalit\u00e0 di emergenza (nota anche come IPKVM), che consente di connettersi a VPS senza RDP direttamente dal livello dell'hypervisor, risparmia 15\u201320 minuti a settimana.<\/i><\/p>\n

La prima e principale cosa \u00e8 non irritare le persone.<\/b> Nel mondo intero, il supporto \u00e8 diviso in livelli, e un dipendente di primo livello deve provare a risolvere con metodi tipici. Se la questione esce dai loro limiti, deve essere trasferita al secondo livello. Ebbene, tra gli amministratori VDS ci sono abbastanza spesso persone che sanno pensare. A differenza di molti altri supporti. Beh, almeno notevolmente pi\u00f9 spesso. E strutturano bene il ticket, descrivendo subito tutto ci\u00f2 che serve. Se il primo livello 'si abitua' e accidentalmente chiede di accendere e spegnere in risposta a tale richiesta, \u00e8 un fiasco.<\/p>\n

La missione \u00e8 molto semplice: rendere il supporto del nostro VDS hosting adeguato con il minimo costo. Perch\u00e9 siamo il fast food del mondo dei fornitori di hosting: niente particolari 'lustrini', prezzi bassi, qualit\u00e0 normale. Precedentemente<\/a><\/noindex> \u00e8 gi\u00e0 stata raccontata la storia su come, con l'arrivo delle ragazze di Instagram, che cercano di automatizzare la gestione degli account e dei proprietari di piccole imprese con contabilit\u00e0 remota e di altre persone non molto esperte con la tecnologia, la comunicazione 'da amministratore a amministratore' ha smesso di funzionare. \u00c8 stato necessario cambiare il linguaggio di comunicazione.<\/p>\n

Ora parler\u00f2 di processi in modo pi\u00f9 dettagliato \u2014 e degli inevitabili errori associati.
\n<\/a><\/noindex><\/p>\n

Non irritare le persone n. 1<\/h2>\n

\nQualsiasi supporto \u00e8 una produzione in serie. Arriva una richiesta, e un dipendente di primo livello cerca immediatamente di riconoscere una situazione tipica, che \u00e8 successa mille volte e accadr\u00e0 altre mille. C'\u00e8 il 90% di probabilit\u00e0 che la richiesta sia tipica, e che si possa rispondere con la pressione di letteralmente un paio di pulsanti, facendo apparire il template. Di solito nel template \u00e8 necessario inserire un paio di parole \u2014 ed \u00e8 fatta. Oppure accedere all'interfaccia di gestione e premere l\u00e0 un paio di pulsanti. Nei casi pi\u00f9 complessi (come i trasferimenti da zona a zona, per esempio) \u00e8 necessario eseguire azioni secondo un algoritmo. <\/p>\n

Ci\u00f2 che infastidisce di pi\u00f9 le persone, indipendentemente da altre qualit\u00e0 del supporto, \u00e8 la tipica reazione a una richiesta atipica. Arriva un ticket, dove tutto \u00e8 descritto in dettaglio, ci sono un sacco di dati necessari per tre domande in avanti, il cliente prevede un dialogo... E alle prime parole, l'operatore del supporto inizia automaticamente a digitare il messaggio predefinito \"provate a riavviare, dovrebbe aiutare\". <\/p>\n

Questo fatto colpisce direttamente la mente delle persone e dopo situazioni simili rimangono il maggior numero di recensioni negative e commenti arrabbiati. \u00c8 chiaro che abbiamo sbagliato in questo modo, ed \u00e8 da qui che conosciamo le statistiche. Abbiamo sbagliato in vari modi, ma questi casi sono sempre semplicemente assurdi. Questo vale anche per noi. Ci piacerebbe, ovviamente, che ci\u00f2 non accadesse affatto. Ma nella pratica non \u00e8 molto possibile: ogni poche settimane, un operatore stanco della monoton\u00eca pu\u00f2 cliccare su alcuni pulsanti divertenti. <\/p>\n

Non infastidire le persone n\u00b0 2<\/h2>\n

\nLa seconda cosa che, con lo stesso successo, colpisce la mente \u00e8 quando nessuno risponde a un ticket abbastanza a lungo. In Europa, questo comportamento di supporto \u00e8 normale: tre giorni prima di accettare un incidente per elaborazione \u00e8 pi\u00f9 che una norma. Anche se avete un'urgenza e qualcosa brucia \u2014 niente social, niente telefono, niente messaggistica, solo e-mail e aspettate il vostro turno. In Russia, questo \u00e8 molto meno comune, ma ci sono comunque alcuni ticket che vengono \"dimenticati\". Anche all'inizio abbiamo imposto un SLA per la prima risposta di 15 minuti. E questo in un contesto 24\/7 serio. \u00c8 ovvio, quando il VDS hosting diventa grande, questo accade. Ma con i fornitori di servizi sospetti questo non accade. E noi, all'inizio, eravamo proprio sospetti e solo in seguito siamo diventati pi\u00f9 o meno grandi. Va bene, pi\u00f9 o meno medi. <\/p>\n

La prima linea \u2014 operatori che hanno ricevuto script e sono stati formati a reagire a situazioni tipiche. Ordinano rapidamente i problemi e cercano di rispondere entro 15 minuti con un'azione standard o informare che il ticket \u00e8 in lavorazione e passarli alla seconda linea.<\/p>\n

La seconda linea \u2014 sono gi\u00e0 gli amministratori di hosting, che sanno fare quasi tutto manualmente. L\u00ec c'\u00e8 anche il responsabile del supporto, che sa fare tutto e anche qualcosa in pi\u00f9. La terza linea \u2014 sono gi\u00e0 gli sviluppatori, a loro arrivano ticket come \"correggete questo nell'interfaccia\" o \"non \u00e8 considerato correttamente questo parametro l\u00ec\". <\/p>\n

Ridurre il numero di richieste<\/h2>\n

\nPer ragioni comprensibili, se desideri fornire supporto a basso costo, \u00e8 necessario non aumentare la prima linea, affinch\u00e9 le persone con gli script possano gestirsi pi\u00f9 rapidamente, ma aumentare l'automazione. In modo che al posto degli esseri umani con gli script ci siano veri e propri script. Pertanto, una delle prime cose che abbiamo fatto \u00e8 stata automatizzare i processi di avvio della macchina virtuale, di scalabilit\u00e0 delle risorse (inclusi anche lo spazio su disco, su e gi\u00f9, ma non la frequenza della CPU) e altre cose simili. Pi\u00f9 un utente pu\u00f2 fare dall'interfaccia, pi\u00f9 \u00e8 facile per la prima linea, e minore pu\u00f2 essere. Quando un utente si rivolge con qualcosa che \u00e8 presente nel proprio account personale, deve essere spiegato e raccontato come eseguire autonomamente tale operazione. <\/p>\n

Se non hai bisogno di supporto, significa che funziona bene. <\/p>\n

La seconda caratteristica che fa risparmiare tempo \u00e8 il lungo completamento della base di conoscenza. Se un utente ha un problema che non rientra nell'elenco delle azioni supportate (molto spesso si tratta di domande come \"come installare un server di Minecraft\" o \"Dove in Win Server configurare VPS\"), viene scritto un articolo nella base di conoscenze. Un articolo altrettanto dettagliato viene redatto per tutte le richieste strane. Ad esempio, se un utente chiede supporto per rimuovere il firewall integrato di Windows Server, lo indirizziamo a leggere cosa accadr\u00e0 se viene effettivamente disattivato e come configurare le autorizzazioni solo per il software selezionato. Poich\u00e9 il problema \u00e8 solitamente che qualcosa non pu\u00f2 connettersi a causa delle impostazioni, e non con il firewall stesso. Ma spiegare tutto questo ogni volta in dialogo \u00e8 molto complicato. E disattivare il firewall non \u00e8 gradito, perch\u00e9 in breve tempo perderemo o la macchina virtuale o il cliente. <\/p>\n

Se qualcosa relativo a software applicativo nella base di conoscenza diventa molto visitato, \u00e8 possibile creare un pacchetto nel marketplace, in modo che ci sia un servizio di \"avviare un server con gi\u00e0 installato questo\". In effetti, \u00e8 stato cos\u00ec per Docker e per il server di Minecraft. Ancora una volta, un solo pulsante \"fate che funzioni bene per me\" nell'interfaccia risparmia fino a cento ticket all'anno. <\/p>\n

Modalit\u00e0 di emergenza<\/h2>\n

\nDopo queste operazioni, il problema pi\u00f9 serio, che richiede intervento manuale, si verifica quando l'utente ha perso, per qualche motivo, il mezzo di accesso remoto al sistema operativo guest nel hypervisor. Il caso pi\u00f9 frequente \u00e8 semplicemente una configurazione errata del firewall, il secondo per frequenza \u00e8 qualche bug che impedisce l'avvio normale di Windows e costringe a riavviarlo in Modalit\u00e0 Sicura. In modalit\u00e0 sicura, RDP \u00e8 di default non disponibile. <\/p>\n

Abbiamo creato una modalit\u00e0 di emergenza per questo caso. Di solito, per accedere a una macchina VDS, \u00e8 necessario avere un client per il lavoro remoto. Pi\u00f9 spesso si tratta di accesso console, RDP, VNC o qualcosa di simile. Il difetto di questi metodi \u00e8 che non funzionano senza il sistema operativo. Ma noi, a livello di hypervisor, possiamo ottenere sia l'immagine sullo schermo sia inviare le pressioni della tastiera! Certo, questo carica piuttosto il processore (a causa della trasmissione video effettiva), ma permette di ottenere il risultato desiderato. <\/p>\n

Perci\u00f2 abbiamo dato accesso alla modalit\u00e0 di emergenza a tutti gli utenti, ma \u00e8 limitato in termini di durata continuativa di utilizzo. Fortunatamente, come dimostra la pratica, questo tempo \u00e8 pi\u00f9 che sufficiente per riavviarsi e sistemare qualcosa.<\/p>\n

Il risultato \u00e8 ancora meno ticket di supporto. E dove l'amministratore pu\u00f2 correggere il ticket da solo, non \u00e8 necessario che il supporto intervenga manualmente per risolvere. <\/p>\n

Problemi rimanenti<\/h2>\n

\nMolto spesso gli utenti pensano che il supporto stia cercando di vendergli qualcosa. <\/b>Purtroppo non possiamo fare nulla al riguardo (o comunque non ci abbiamo pensato). I due esempi pi\u00f9 frequenti sono i limiti delle risorse e la protezione DDoS. <\/p>\n

Ogni macchina virtuale ha dei limiti di carico sul disco, sulla memoria e sul traffico consentito. La possibilit\u00e0 di impostare limiti \u00e8 dettagliata nell'offerta, e i limiti stessi sono definiti in modo che la maggior parte degli utenti possa lavorare tranquillamente, anche senza esserne a conoscenza. Ma se all'improvviso inizi a sovraccaricare molto il canale e il disco, gli algoritmi avvisano automaticamente l'utente. Da aprile dello scorso anno abbiamo rimosso i blocchi automatici. Invece, abbiamo impostato limiti morbidi per un periodo variabile. <\/p>\n

In passato era cos\u00ec: avviso, poi, se l'utente non rispondeva, \u2014 blocco automatico. E in quel momento le persone si arrabbiavano: \u00abMa che dite, il vostro sistema ha dei problemi, non c'era nulla!\u00bb \u2014 e da l\u00ec si poteva o tentare di indagare nel software applicativo, o proporre di elevare il piano tariffario. Non abbiamo possibilit\u00e0 di occuparci del funzionamento del software applicativo, perch\u00e9 questo esula dal supporto. Anche se nei primi casi ne abbiamo discusso insieme agli utenti. Ricordo particolarmente quello in cui un bot di visualizzazioni su YouTube aveva un trojan integrato, e questo trojan aveva una perdita di memoria. Alla fine siamo giunti alla conclusione che non si trattava di 'geizenbug', ma di problemi degli utenti, altrimenti saremmo stati sommersi da richieste analoghe. Tuttavia, nessuno ha mai ammesso di aver superato i limiti dei piani tariffari da solo. <\/p>\n

Una storia simile riguarda gli attacchi DDoS: diciamo che tu, stimato utente, sei sotto attacco. Ti preghiamo di attivare la protezione. E l'utente risponde: \u00abMa siete voi a attaccarmi!\u00bb Certo, stiamo esaurendo un solo utente con un DDoS per estorcergli 300 rubli. \u00c8 un affare vantaggioso. S\u00ec, so che molti grandi hosting di fascia alta includono questa protezione nelle loro tariffe, ma noi non possiamo farlo: l'economia del fast food impone prezzi minimi diversi. <\/p>\n

Non meno spesso il supporto \u00e8 oggetto di insoddisfazione per quelli i cui dati abbiamo cancellato.<\/b> Nel senso che abbiamo cancellato legittimamente al termine del periodo di pagamento. Se qualcuno non rinnova l'affitto del VDS, arriva qualche notifica con spiegazioni su cosa accadr\u00e0 dopo. Al termine del pagamento, la macchina virtuale si ferma, ma la sua immagine viene salvata. Arriva un'altra notifica, e poi altre due. L'immagine viene conservata per sette giorni aggiuntivi e solo dopo viene cancellata definitivamente. Ecco, c'\u00e8 una categoria di persone che non \u00e8 affatto contenta di questo. A partire da 'l'amministratore \u00e8 stato licenziato, le notifiche arrivavano sulla sua email, ripristinate' fino ad accuse di frode e minacce fisiche. La ragione \u2014 sono sempre gli stessi prezzi per tutti gli altri utenti. Se conservassimo per un mese, servirebbero pi\u00f9 risorse di archiviazione. Questo significherebbe prezzi pi\u00f9 alti per ciascun cliente specifico. E l'economia del fast food... Ecco, avete capito. E alla fine sui forum riceviamo commenti come 'hanno preso i soldi, hanno cancellato i dati, truffatori'.<\/p>\n

Voglio sottolineare che abbiamo una gamma di piani premium. L\u00ec, ovviamente, la situazione \u00e8 diversa, poich\u00e9 teniamo conto delle esigenze del cliente e configuriamo in modo flessibile sia il limite che la disattivazione in caso di mancato pagamento (portandolo in negativo, solo per non bloccarlo). Qui \u00e8 gi\u00e0 economicamente sensato, perch\u00e9 accade davvero di tutto e mantenere un grande cliente abituale ha un costo elevato. <\/p>\n

A volte gli utenti possono essere malintenzionati. <\/b>Ci sono stati diversi casi in cui il nostro sistema ha subito guasti a causa della chiusura di centinaia di macchine virtuali a causa di azioni evidentemente illegittime da parte dei clienti. In effetti, \u00e8 proprio a causa di tali situazioni che abbiamo avuto bisogno dei nostri driver di rete, per monitorare l'attivit\u00e0 di rete e vedere che l'utente non stesse eseguendo un attacco dal proprio server. Il monitoraggio di questo tipo \u00e8 importante affinch\u00e9 i confini delle macchine virtuali vicine non siano violati da ragazzi indisciplinati. <\/p>\n

Ci sono quelli che semplicemente spammiano, minano o violano l'offerta in altro modo. Poi contattano il supporto e chiedono cosa \u00e8 andato storto e perch\u00e9 la macchina \u00e8 bloccata. Se il processo nel ticket nello screenshot si chiama \"spammer.exe\", allora probabilmente qualcosa non va. Ogni due settimane circa, riceviamo lamentele da aziende come Sony o Lucasfilm (ora Disney), che qualcuno dalla nostra macchina virtuale del nostro range di indirizzi IP sta distribuendo un film pirata. Per questo motivo ci sono immediatamente blocchi e restituzione del saldo rimanente sul conto secondo l'offerta (ricordo: la quantificazione \u00e8 al secondo, quindi il saldo sar\u00e0 sempre preciso). E per restituire i soldi, secondo la legge, bisogna mostrare un documento d'identit\u00e0: \u00e8 una misura contro il riciclaggio di denaro. I pirati, per qualche motivo, invece di mostrare un documento, scrivono che noi abbiamo preso i loro soldi, dimenticando di chiarire alcuni dettagli. <\/p>\n

Ah, s\u00ec. La migliore richiesta dell'anno da parte nostra \u00e8 stata: \"Posso testare la macchina virtuale al piano di 30 rubli al mese per alcuni giorni prima dell'acquisto?\".<\/p>\n

Risultato<\/h2>\n

\nLa prima linea gestisce i ticket e risponde con azioni tipiche. Qui si concentra la maggior parte delle lamentele. Non sar\u00e0 possibile risolvere questo problema, poich\u00e9 la chiave per la risoluzione \u00e8 l'automazione dell'hosting, il che significa un enorme backlog. S\u00ec, abbiamo pi\u00f9 di molti sul mercato, ma ancora non basta. Quindi, la cosa migliore che possiamo fare \u00e8 migliorare il monitoraggio della prima linea. Il monitoraggio dell'assistenza clienti implica il raggiungimento dei KPI della prima linea. In tempo reale, possiamo vedere i ritardi rispetto al SLA: chi sbaglia, e spesso, il perch\u00e9. Le richieste, grazie a questi allerta, non vengono mai perse. S\u00ec, un ticket pu\u00f2 ricevere una risposta con un template non pertinente, ma lo scopriamo gi\u00e0 attraverso il feedback. <\/p>\n

Se il cliente lo richiede particolarmente, uno specialista della seconda linea pu\u00f2 accedere al server e fare ci\u00f2 di cui il cliente ha bisogno (la condizione \u00e8 la conferma via email, in cui il cliente fornisce i dati per accedere al server).<\/p>\n

Facciamo questo molto raramente e affidiamo tale lavoro solo ai migliori, perch\u00e9 vogliamo avere garanzie che i dati degli utenti non vengano danneggiati. I migliori sono la seconda linea di supporto.<\/p>\n

La prima linea dispone di una knowledge base dove poter inviare persone per consultare problematiche complesse. <\/p>\n

Un'area clienti ricca di funzionalit\u00e0 pi\u00f9 una knowledge base \u2014 e cos\u00ec siamo riusciti a ridurre il numero di richieste a 1\u20131,5 all'anno per cliente in media. <\/p>\n

La seconda linea gestisce normalmente richieste complesse che richiedono lavoro manuale. \u00c8 caratteristico notare che, quanto pi\u00f9 costoso \u00e8 il piano tariffario, tanto meno numerose sono queste richieste in relazione alla macchina virtuale. Di solito perch\u00e9 chi pu\u00f2 permettersi piani costosi ha sia esperti interni, sia che molte problematiche non si presentano poich\u00e9 le configurazioni sono adeguate. Ricordo ancora quel protagonista che aveva installato una versione non troppo recente di Windows Server su una configurazione con 256 MB di RAM. <\/p>\n

La seconda linea ha a disposizione un insieme di distribuzioni e un insieme di script di automazione. Entrambi possono essere aggiornati secondo necessit\u00e0. <\/p>\n

La seconda linea e i manager personali dei piani VIP possono aggiungere note nel profilo del cliente. Se \u00e8 un amministratore Linux, cos\u00ec lo annotiamo. Questo sar\u00e0 un promemoria per la prima linea: l'utente sa perfettamente che non si tratter\u00e0 di un autogol, ma di una demolizione controllata. <\/p>\n

La terza riga corregge la cosa pi\u00f9 strana. Ad esempio, avevamo un bug per cui non potevamo accedere a una delle funzioni del pannello di controllo in Firefox. L'utente ci ha minacciato: \"Se non lo risolvete entro 12 ore, scriver\u00f2 su tutte le recensioni degli host\". Come \u00e8 emerso, il problema era nel blocco degli annunci personalizzato. Sul lato dell'utente, per quanto strano sia. Spesso arrivano errori complessi senza dettagli e non riescono a riprodurli. Ci sono detective con screenshot: \"Perch\u00e9 lo stai correggendo da un mese?\" - \"Stiamo semplicemente cercando il tuo bug da tutto questo tempo\", \"Ah, bene, mi era ricapitatato oggi, ma non riesco di nuovo a riprodurlo\"...<\/p>\n

In realt\u00e0, non sai mai dove finir\u00e0 lo screenshot del dialogo con il supporto, e se qualcuno contatta il supporto, ha un problema. Si pu\u00f2 migliorare la situazione. Almeno, provare. <\/p>\n

S\u00ec, sappiamo che il nostro supporto non \u00e8 perfetto, ma, per quanto mi piaccia credere, combina una velocit\u00e0 sufficiente con una qualit\u00e0 adeguata. E non aumenta i prezzi dei piani a chi pu\u00f2 fare a meno di esso.<\/p>\n

\"Offriamo<\/a><\/noindex><\/p>\n

Fonte: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u0410\u0432\u0430\u0440\u0438\u0439\u043d\u044b\u0439 \u0440\u0435\u0436\u0438\u043c (\u0442\u0430\u043a\u0436\u0435 \u0443\u043f\u043e\u043c\u0438\u043d\u0430\u0435\u0442\u0441\u044f \u043a\u0430\u043a IPKVM), \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u044e\u0449\u0438\u0439 \u043f\u043e\u0434\u043a\u043b\u044e\u0447\u0430\u0442\u044c\u0441\u044f \u043a VPS \u0431\u0435\u0437 RDP \u043f\u0440\u044f\u043c\u043e \u0441 \u0443\u0440\u043e\u0432\u043d\u044f \u0433\u0438\u043f\u0435\u0440\u0432\u0438\u0437\u043e\u0440\u0430, \u044d\u043a\u043e\u043d\u043e\u043c\u0438\u0442 15\u201320 \u043c\u0438\u043d\u0443\u0442 \u0432 \u043d\u0435\u0434\u0435\u043b\u044e. \u041f\u0435\u0440\u0432\u043e\u0435 \u0438 \u0433\u043b\u0430\u0432\u043d\u043e\u0435 \u2014 \u043d\u0435 \u0431\u0435\u0441\u0438\u0442\u044c \u043b\u044e\u0434\u0435\u0439. \u0412\u043e \u0432\u0441\u0451\u043c \u043c\u0438\u0440\u0435 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0430 \u0440\u0430\u0437\u0434\u0435\u043b\u0435\u043d\u0430 \u043d\u0430 \u043b\u0438\u043d\u0438\u0438, \u0438 \u0441\u043e\u0442\u0440\u0443\u0434\u043d\u0438\u043a \u043f\u0435\u0440\u0432\u043e\u0439 \u0434\u043e\u043b\u0436\u0435\u043d \u043f\u043e\u043f\u0440\u043e\u0431\u043e\u0432\u0430\u0442\u044c \u0442\u0438\u043f\u0438\u0447\u043d\u044b\u0435 \u0441\u043f\u043e\u0441\u043e\u0431\u044b \u0440\u0435\u0448\u0435\u043d\u0438\u044f. \u0415\u0441\u043b\u0438 \u0437\u0430\u0434\u0430\u0447\u0430 \u0432\u044b\u0431\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0437\u0430 \u0438\u0445 \u043f\u0440\u0435\u0434\u0435\u043b\u044b \u2014 \u043f\u0435\u0440\u0435\u0434\u0430\u0442\u044c \u0432\u0442\u043e\u0440\u043e\u0439 \u043b\u0438\u043d\u0438\u0438. \u0422\u0430\u043a \u0432\u043e\u0442, […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":83003,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-83002","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Rendiamo il supporto pi\u00f9 economico, cercando di non perdere qualit\u00e0 | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/delaem-podderzhku-deshevle-starayas-ne-rasteryat-kachestvo","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0414\u0435\u043b\u0430\u0435\u043c \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0443 \u0434\u0435\u0448\u0435\u0432\u043b\u0435, \u0441\u0442\u0430\u0440\u0430\u044f\u0441\u044c \u043d\u0435 \u0440\u0430\u0441\u0442\u0435\u0440\u044f\u0442\u044c \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u043e | ProHoster","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/delaem-podderzhku-deshevle-starayas-ne-rasteryat-kachestvo","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-05-27T11:42:38+00:00","article:modified_time":"2020-05-27T11:42:38+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"83002","title":null,"description":null,"keywords":null,"keyphrases":{"focus":[],"additional":[]},"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 15:27:22","updated":"2026-08-11 12:50:16","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/83002","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=83002"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/83002\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/83003"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=83002"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=83002"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=83002"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}