La modalità di emergenza (nota anche come IPKVM), che consente di connettersi a VPS senza RDP direttamente dal livello dell'hypervisor, risparmia 15–20 minuti a settimana.
La prima e principale cosa è non irritare le persone. Nel mondo intero, il supporto è 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ù spesso. E strutturano bene il ticket, descrivendo subito tutto ciò che serve. Se il primo livello 'si abitua' e accidentalmente chiede di accendere e spegnere in risposta a tale richiesta, è un fiasco.
La missione è molto semplice: rendere il supporto del nostro VDS hosting adeguato con il minimo costo. Perché siamo il fast food del mondo dei fornitori di hosting: niente particolari 'lustrini', prezzi bassi, qualità normale. è già 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à remota e di altre persone non molto esperte con la tecnologia, la comunicazione 'da amministratore a amministratore' ha smesso di funzionare. È stato necessario cambiare il linguaggio di comunicazione.
Ora parlerò di processi in modo più dettagliato — e degli inevitabili errori associati.
Non irritare le persone n. 1
Qualsiasi supporto è una produzione in serie. Arriva una richiesta, e un dipendente di primo livello cerca immediatamente di riconoscere una situazione tipica, che è successa mille volte e accadrà altre mille. C'è il 90% di probabilità 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 è necessario inserire un paio di parole — ed è fatta. Oppure accedere all'interfaccia di gestione e premere là un paio di pulsanti. Nei casi più complessi (come i trasferimenti da zona a zona, per esempio) è necessario eseguire azioni secondo un algoritmo.
Ciò che infastidisce di più le persone, indipendentemente da altre qualità del supporto, è la tipica reazione a una richiesta atipica. Arriva un ticket, dove tutto è 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".
Questo fatto colpisce direttamente la mente delle persone e dopo situazioni simili rimangono il maggior numero di recensioni negative e commenti arrabbiati. È chiaro che abbiamo sbagliato in questo modo, ed è 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ò non accadesse affatto. Ma nella pratica non è molto possibile: ogni poche settimane, un operatore stanco della monotonìa può cliccare su alcuni pulsanti divertenti.
Non infastidire le persone n° 2
La seconda cosa che, con lo stesso successo, colpisce la mente è quando nessuno risponde a un ticket abbastanza a lungo. In Europa, questo comportamento di supporto è normale: tre giorni prima di accettare un incidente per elaborazione è più che una norma. Anche se avete un'urgenza e qualcosa brucia — niente social, niente telefono, niente messaggistica, solo e-mail e aspettate il vostro turno. In Russia, questo è 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. È 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ù o meno grandi. Va bene, più o meno medi.
La prima linea — 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 è in lavorazione e passarli alla seconda linea.
La seconda linea — sono già gli amministratori di hosting, che sanno fare quasi tutto manualmente. Lì c'è anche il responsabile del supporto, che sa fare tutto e anche qualcosa in più. La terza linea — sono già gli sviluppatori, a loro arrivano ticket come "correggete questo nell'interfaccia" o "non è considerato correttamente questo parametro lì".
Ridurre il numero di richieste
Per ragioni comprensibili, se desideri fornire supporto a basso costo, è necessario non aumentare la prima linea, affinché le persone con gli script possano gestirsi più 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 è stata automatizzare i processi di avvio della macchina virtuale, di scalabilità delle risorse (inclusi anche lo spazio su disco, su e giù, ma non la frequenza della CPU) e altre cose simili. Più un utente può fare dall'interfaccia, più è facile per la prima linea, e minore può essere. Quando un utente si rivolge con qualcosa che è presente nel proprio account personale, deve essere spiegato e raccontato come eseguire autonomamente tale operazione.
Se non hai bisogno di supporto, significa che funziona bene.
La seconda caratteristica che fa risparmiare tempo è 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à se viene effettivamente disattivato e come configurare le autorizzazioni solo per il software selezionato. Poiché il problema è solitamente che qualcosa non può connettersi a causa delle impostazioni, e non con il firewall stesso. Ma spiegare tutto questo ogni volta in dialogo è molto complicato. E disattivare il firewall non è gradito, perché in breve tempo perderemo o la macchina virtuale o il cliente.
Se qualcosa relativo a software applicativo nella base di conoscenza diventa molto visitato, è possibile creare un pacchetto nel marketplace, in modo che ci sia un servizio di "avviare un server con già installato questo". In effetti, è stato così 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.
Modalità di emergenza
Dopo queste operazioni, il problema più 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ù frequente è semplicemente una configurazione errata del firewall, il secondo per frequenza è qualche bug che impedisce l'avvio normale di Windows e costringe a riavviarlo in Modalità Sicura. In modalità sicura, RDP è di default non disponibile.
Abbiamo creato una modalità di emergenza per questo caso. Di solito, per accedere a una macchina VDS, è necessario avere un client per il lavoro remoto. Più spesso si tratta di accesso console, RDP, VNC o qualcosa di simile. Il difetto di questi metodi è 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.
Perciò abbiamo dato accesso alla modalità di emergenza a tutti gli utenti, ma è limitato in termini di durata continuativa di utilizzo. Fortunatamente, come dimostra la pratica, questo tempo è più che sufficiente per riavviarsi e sistemare qualcosa.
Il risultato è ancora meno ticket di supporto. E dove l'amministratore può correggere il ticket da solo, non è necessario che il supporto intervenga manualmente per risolvere.
Problemi rimanenti
Molto spesso gli utenti pensano che il supporto stia cercando di vendergli qualcosa. Purtroppo non possiamo fare nulla al riguardo (o comunque non ci abbiamo pensato). I due esempi più frequenti sono i limiti delle risorse e la protezione DDoS.
Ogni macchina virtuale ha dei limiti di carico sul disco, sulla memoria e sul traffico consentito. La possibilità di impostare limiti è 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.
In passato era così: avviso, poi, se l'utente non rispondeva, — blocco automatico. E in quel momento le persone si arrabbiavano: «Ma che dite, il vostro sistema ha dei problemi, non c'era nulla!» — e da lì si poteva o tentare di indagare nel software applicativo, o proporre di elevare il piano tariffario. Non abbiamo possibilità di occuparci del funzionamento del software applicativo, perché 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.
Storia analoga — con DDoS: scriviamo che lei, gentile utente, è sotto attacco. Per favore, attivi la protezione. E l'utente: «Siete voi che mi attaccate!» Certo, ci mettiamo a fare un DDoS a un solo utente per estorcere 300 rubli. È un affare vantaggioso. Sì, so che molti grandi hosting nella fascia più costosa includono questa protezione nel piano, ma noi non possiamo fare così: l'economia del fast food impone altri prezzi minimi.
Non meno spesso il supporto è oggetto di insoddisfazione per quelli i cui dati abbiamo cancellato. 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à 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'è una categoria di persone che non è affatto contenta di questo. A partire da 'l'amministratore è stato licenziato, le notifiche arrivavano sulla sua email, ripristinate' fino ad accuse di frode e minacce fisiche. La ragione — sono sempre gli stessi prezzi per tutti gli altri utenti. Se conservassimo per un mese, servirebbero più risorse di archiviazione. Questo significherebbe prezzi più 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'.
Voglio sottolineare che abbiamo una gamma di piani premium. Lì, ovviamente, la situazione è diversa, poiché 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 è già economicamente sensato, perché accade davvero di tutto e mantenere un grande cliente abituale ha un costo elevato.
A volte gli utenti possono essere malintenzionati. 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, è proprio a causa di tali situazioni che abbiamo avuto bisogno dei nostri driver di rete, per monitorare l'attività di rete e vedere che l'utente non stesse eseguendo un attacco dal proprio server. Il monitoraggio di questo tipo è importante affinché i confini delle macchine virtuali vicine non siano violati da ragazzi indisciplinati.
Ci sono quelli che semplicemente spammiano, minano o violano l'offerta in altro modo. Poi contattano il supporto e chiedono cosa è andato storto e perché la macchina è 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 è al secondo, quindi il saldo sarà sempre preciso). E per restituire i soldi, secondo la legge, bisogna mostrare un documento d'identità: è 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.
Ah, sì. La migliore richiesta dell'anno da parte nostra è stata: "Posso testare la macchina virtuale al piano di 30 rubli al mese per alcuni giorni prima dell'acquisto?".
Risultato
La prima linea gestisce i ticket e risponde con azioni tipiche. Qui si concentra la maggior parte delle lamentele. Non sarà possibile risolvere questo problema, poiché la chiave per la risoluzione è l'automazione dell'hosting, il che significa un enorme backlog. Sì, abbiamo più di molti sul mercato, ma ancora non basta. Quindi, la cosa migliore che possiamo fare è 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é. Le richieste, grazie a questi allerta, non vengono mai perse. Sì, un ticket può ricevere una risposta con un template non pertinente, ma lo scopriamo già attraverso il feedback.
Se il cliente lo richiede particolarmente, uno specialista della seconda linea può accedere al server e fare ciò di cui il cliente ha bisogno (la condizione è la conferma via email, in cui il cliente fornisce i dati per accedere al server).
Facciamo questo molto raramente e affidiamo tale lavoro solo ai migliori, perché vogliamo avere garanzie che i dati degli utenti non vengano danneggiati. I migliori sono la seconda linea di supporto.
La prima linea dispone di una knowledge base dove poter inviare persone per consultare problematiche complesse.
Un'area clienti ricca di funzionalità più una knowledge base — e così siamo riusciti a ridurre il numero di richieste a 1–1,5 all'anno per cliente in media.
La seconda linea gestisce normalmente richieste complesse che richiedono lavoro manuale. È caratteristico notare che, quanto più costoso è il piano tariffario, tanto meno numerose sono queste richieste in relazione alla macchina virtuale. Di solito perché chi può permettersi piani costosi ha sia esperti interni, sia che molte problematiche non si presentano poiché 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.
La seconda linea ha a disposizione un insieme di distribuzioni e un insieme di script di automazione. Entrambi possono essere aggiornati secondo necessità.
La seconda linea e i manager personali dei piani VIP possono aggiungere note nel profilo del cliente. Se è un amministratore Linux, così lo annotiamo. Questo sarà un promemoria per la prima linea: l'utente sa perfettamente che non si tratterà di un autogol, ma di una demolizione controllata.
La terza riga corregge la cosa più 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ò su tutte le recensioni degli host". Come è 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é 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"...
In realtà, non sai mai dove finirà lo screenshot del dialogo con il supporto, e se qualcuno contatta il supporto, ha un problema. Si può migliorare la situazione. Almeno, provare.
Sì, sappiamo che il nostro supporto non è perfetto, ma, per quanto mi piaccia credere, combina una velocità sufficiente con una qualità adeguata. E non aumenta i prezzi dei piani a chi può fare a meno di esso.
Fonte: habr.com
