La modalità di emergenza (nota anche come IPKVM), che consente di accedere al VPS senza RDP direttamente dal livello del hypervisor, fa risparmiare 15–20 minuti alla settimana.
La cosa più importante è non infastidire le persone. In tutto il mondo, il supporto è suddiviso in linee, e un operatore di prima linea deve provare a risolvere i problemi con metodi tipici. Se il compito esce dai loro limiti, viene trasferito alla seconda linea. Ebbene, tra gli amministratori VDS si trovano spesso persone che sanno pensare. A differenza di molti altri supporti. Beh, perlomeno, molto più spesso. E strutturano bene il ticket, descrivendo subito tutto ciò che è necessario. Se alla prima linea 'si abitua l'occhio' e in risposta a una richiesta simile chiedono casualmente di accendere e spegnere — è un fiasco.
L'obiettivo è molto semplice: rendere il supporto per il nostro hosting VDS adeguato con il minimo costo. Perché siamo il fast food del mondo dei fornitori di hosting: niente 'coccole' speciali, prezzi bassi, qualità normale. C'è già stata una discussione su come, con l'arrivo delle influencer di Instagram, che cercano di automatizzare la gestione degli account e i proprietari di piccole imprese con contabilità remota, e altre persone non troppo esperte di tecnologia, la comunicazione "come admin con admin" non funziona più. È stato necessario cambiare il linguaggio di comunicazione.
Ora parlerò di più sui processi — e sui problemi inevitabili che ne derivano.
Non infastidire le persone n° 1
Qualsiasi supporto è una produzione in serie. Arriva una richiesta, un operatore di livello 1 cerca subito di riconoscere la situazione tipica, che è già successa mille volte e succederà ancora mille volte. C'è il 90% di probabilità che la richiesta sia standard, e rispondere può avvenire premendo praticamente un paio di tasti, per far apparire il modello. Di solito, è necessario inserire qualche parola nel modello — ed è fatto. Oppure accedere all'interfaccia di gestione e premere lì un paio di tasti. Nei casi più complessi (come i trasferimenti da una zona all'altra, per esempio), è necessario eseguire le azioni secondo un algoritmo.
Ciò che infastidisce di più le persone, indipendentemente da altri aspetti del supporto, è la reazione tipica a una richiesta atipica. Arriva un ticket, dove tutto è descritto in dettaglio, con un sacco di dati necessari per rispondere a tre domande in anticipo, il cliente prevede il dialogo... E alle prime parole, l'operatore del supporto automaticamente scrive il solito messaggio preimpostato: «provate a riavviare, dovrebbe aiutare».
Questo colpisce direttamente il cervello delle persone e, proprio dopo situazioni del genere, rimangono le recensioni più negative e i commenti arrabbiati. È chiaro che abbiamo sbagliato in questo modo, ed è da lì che conosciamo le statistiche. Abbiamo commesso errori in vari modi, ma questi casi sono sempre semplicemente incredibili. Anche per noi stessi. Certamente, vorremmo che tali cose non accadessero mai. Ma non è molto praticabile: ogni poche settimane, un operatore stanco della monotonia potrebbe premere casualmente i tasti divertenti.
Non infastidire le persone n. 2
La seconda cosa che mette in crisi il cervello è quando non ci sono risposte ai ticket per un tempo eccessivo. In Europa è normale che il supporto impieghi tre giorni per accettare un incidente — è più che accettabile. Anche se hai un'urgenza e c'è qualcosa che brucia, nessun social media, nessun telefono, nessun messaggero; solo email e aspetta il tuo turno. In Russia questo è molto meno comune, ma alcuni ticket vengono comunque "dimenticati". Inizialmente abbiamo impostato un SLA per la prima risposta di 15 minuti. E questo è in un supporto onesto 24/7. Ovviamente, quando l'hosting VDS diventa grande, questa pratica compare. Ma non ci sono casi simili con fornitori di servizi discutibili. All'inizio eravamo proprio tra i fornitori di servizi discutibili, e solo dopo siamo diventati mediamente riconosciuti.
Il primo livello è composto da operatori che hanno ricevuto degli script e sono stati formati a rispondere a situazioni tipiche. Lavorano velocemente per classificare i problemi e tentano di fornire una risposta tipica entro 15 minuti, oppure comunicare che il ticket è in lavorazione e trasferirlo al secondo livello.
La seconda linea consiste già negli amministratori di hosting, che sono in grado di fare quasi tutto manualmente. Lì c'è anche il responsabile del supporto, che sa fare tutto e anche di più. La terza linea consiste già negli sviluppatori, a cui arrivano ticket come "aggiusta questo nell'interfaccia" o "il parametro tale è conteggiato in modo errato lì".
Ridurre il numero di richieste
Per ovvie ragioni, se desideri fornire supporto a basso costo, non devi aumentare la prima linea in modo che le persone con gli script possano gestire tutto più velocemente, ma aumentare l'automazione. Dovresti sostituire le persone che usano gli script con veri script. Quindi una delle prime cose che abbiamo fatto è stata automatizzare i processi di avvio della macchina virtuale, scalando le risorse (incluso lo spazio su disco verso l'alto e verso il basso, ma non la frequenza della CPU) e altre cose simili. Più il cliente può fare dall'interfaccia, più è semplice per la prima linea, e più piccola può essere. Quando un utente chiede qualcosa che è nel proprio pannello, è necessario mostrare come può farlo autonomamente.
Se non hai bisogno di supporto, significa che sta funzionando bene.
La seconda caratteristica che consente di risparmiare molto tempo è la lunga compilazione della base di conoscenza. Se un utente ha un problema che non è elencato tra le azioni supportate (spesso si tratta di domande come "come impostare un server di Minecraft" o "dove configurare il VPS in Windows Server"), viene redatto un articolo nella base di conoscenza. Un articolo dettagliato viene scritto anche per tutte le richieste strane. Ad esempio, se un utente chiede supporto per rimuovere il firewall integrato di Windows Server, lo invitiamo a leggere cosa succede se lo disattiviamo e come aprire le autorizzazioni solo per il software selezionato. Il problema di solito è che qualcosa non riesce a connettersi a causa delle impostazioni, non per il firewall stesso. Spiegare tutto questo ogni volta in un dialogo è molto complicato. Disattivare il firewall non è una soluzione desiderabile, perché perderemmo presto sia la macchina virtuale che il cliente.
Se un'applicazione nella nostra base di conoscenze diventa molto popolare, è possibile inserire una distribuzione nel marketplace, così da offrire il servizio "avvia un server con già installato questo". È successo con Docker e con il server di Minecraft. Ancora una volta, un pulsante "fateci un favore" nell'interfaccia può risparmiare fino a cento ticket all'anno.
Modalità di emergenza
Dopo queste azioni, gli guasti più gravi che richiedono intervento manuale rimangono legati al fatto che l'utente ha perso per qualche motivo l'accesso remoto al sistema operativo guest nel hypervisor. Il caso più comune è una semplice configurazione errata del firewall, il secondo più frequente sono alcuni bug che impediscono l'avvio corretto di Windows e costringono a riavviarsi in modalità provvisoria. E in modalità provvisoria, RDP non è abilitato per impostazione predefinita.
Abbiamo implementato una modalità di emergenza per questo. In genere, per accedere a una macchina VDS, è necessario un cliente per il lavoro remoto. Di solito si tratta di accesso alla console, RDP, VNC o qualcosa di simile. Il problema di questi metodi è che non funzionano senza un sistema operativo. Ma noi, a livello di hypervisor, possiamo ottenere sia l'immagine dello schermo che trasmettere le pressione dei tasti! Certo, questo carica notevolmente il processore (a causa della trasmissione video), ma permette di ottenere il risultato desiderato.
Perciò abbiamo dato accesso alla modalità di emergenza a tutti gli utenti, ma è limitato nella durata dell'uso continuo. Fortunatamente, come dimostra la prassi, questo tempo è generalmente sufficiente per riavviarsi e correggere qualcosa.
Il risultato è ancora meno ticket di assistenza. E dove l'amministratore può risolvere il ticket da solo, il supporto non deve intervenire manualmente per capire.
Problemi rimanenti
Molto spesso gli utenti pensano che il supporto stia cercando di fargli qualcosa. Purtroppo, non si può fare nulla al riguardo (o non abbiamo trovato una soluzione). I due esempi più comuni sono i limiti sulle risorse e la protezione DDoS.
Ogni macchina virtuale ha dei limiti per l'utilizzo del disco, della memoria e del traffico consentito. La possibilità di impostare limiti è specificata nell'offerta, mentre i limiti stessi sono progettati in modo che la maggior parte degli utenti possa lavorare tranquillamente, anche senza conoscerli. Tuttavia, se inizi a utilizzare intensamente canale e disco, gli algoritmi avvisano automaticamente l'utente. Dallo scorso aprile abbiamo rimosso i blocchi automatici. Invece, sono stati introdotti dei limiti soft per un periodo variabile.
In passato le cose erano così: prima un avviso, poi, se l'utente non reagiva, scattava automaticamente il blocco. In quel momento, le persone si offendevano: "Cosa state facendo, è il vostro sistema che ha un problema, non c'era nulla!". A quel punto si poteva tentare di approfondire il software applicativo oppure suggerire di passare a un piano tariffario superiore. Non abbiamo la possibilità di esaminare il funzionamento del software applicativo, poiché ciò va al di là del supporto. Tuttavia, i primi casi sono stati analizzati insieme agli utenti. Ricordo in particolare un caso in cui un manipolatore di visualizzazioni su YouTube aveva un trojan incorporato, e questo trojan perdeva memoria. In conclusione, abbiamo stabilito che non si trattava di glitch, ma di problemi degli utenti; altrimenti saremmo stati sommersi da segnalazioni simili. Eppure, nessuna persona ha mai confessato di aver superato i limiti da sola.
Una storia simile riguarda i DDoS: noi scriviamo che lei, gentile utente, è sotto attacco. La preghiamo di attivare la protezione. E l'utente: «Siete voi a lanciarmi l'attacco!» Certo, è proprio un utente che facciamo cadere sotto DDoS per estorcere 300 rubli. È un affare vantaggioso. Sì, so che molti grandi provider di hosting di fascia alta includono questa protezione nel loro piano, ma noi non possiamo farlo: l'economia del fast food impone altri prezzi minimi.
Non sono rari i casi in cui il supporto è insoddisfatto da coloro i cui dati abbiamo rimosso. In the sense that they were legitimately deleted after the paid period expired. If someone does not renew their VDS rental, they receive several notifications explaining what will happen next. At the end of the payment term, the virtual machine stops, but its image is preserved. Another notification is sent, followed by a couple more. The image is stored for an additional seven days before being permanently deleted. There are indeed people who are very unhappy about this. Starting with 'the admin left, notifications went to his email, restore it' and ending with accusations of fraud and threats of physical harm. The reason is the same prices for all other users. If we store it for a month, it will require more storage. This would mean higher prices for each individual client. And the fast-food economy... Well, you understand. As a result, we receive feedback on forums like 'they took the money, deleted the data, fraudsters.'
Voglio sottolineare che abbiamo una gamma di tariffe premium. Qui, ovviamente, la situazione è diversa, poiché teniamo conto delle esigenze del cliente e personalizziamo in modo flessibile sia il limite che la disattivazione in caso di mancato pagamento (lo portiamo in negativo, pur di non bloccarlo). Qui diventa anche economicamente vantaggioso, perché possono davvero succedere molte cose, e mantenere un cliente importante è molto costoso.
A volte gli utenti possono essere malevoli. Diverse volte abbiamo riscontrato problemi nel nostro sistema con il blocco di centinaia di macchine virtuali a causa di azioni chiaramente illegittime da parte dei clienti. In effetti, è per questi tipi di situazioni che abbiamo avuto bisogno di driver di rete propri, per monitorare l'attività di rete e vedere che l'utente non stesse eseguendo un attacco dal proprio server. Un monitoraggio di questo tipo è importante per garantire che i limiti delle macchine virtuali vicine non vengano violati dai ragazzi turbolenti.
Ci sono persone che semplicemente fanno spam, minano o violano in altro modo il contratto. Poi contattano il supporto e chiedono cosa sia andato storto e perché la macchina è stata bloccata. Se il processo nel ticket nello screenshot si chiama "sendmail.exe", allora probabilmente qualcosa non va. Inoltre, ogni due settimane riceviamo reclami da aziende come Sony o Lucasfilm (ora Disney), che qualcuno dalla nostra virtuale sta distribuendo un film pirata dal nostro range di indirizzi IP. In tali casi, il bloccaggio è immediato e il rimborso degli importi rimanenti sul conto è garantito (ricordo che la nostra fatturazione è al secondo, quindi l'importo residuo sarà sempre esatto). E per riavere i soldi, per legge è necessario mostrare un documento d'identità: questa è una misura contro il riciclaggio di denaro. I pirati, in qualche modo, invece di mostrare il documento scrivono che noi abbiamo rubato i loro soldi, dimenticando di precisare alcune circostanze.
Ah, sì. La richiesta migliore dell'anno è stata: "Posso testare la macchina virtuale a tariffa di 30 rubli al mese per alcuni giorni prima di acquistare?".
Risultato
Il primo livello smista i ticket e risponde con azioni tipiche. Qui si riscontra la maggior parte del malcontento. Non possiamo risolvere tutto, poiché la base della correzione risiede nell'automazione dell'hosting, il che significa un enorme backlog. Sì, abbiamo più di molti altri sul mercato, ma non è comunque sufficiente. Pertanto, la cosa migliore da fare è stabilire un monitoraggio per il primo livello. Monitorare il servizio clienti equivale a rispettare gli KPI del primo livello. In tempo reale si possono vedere i ritardi rispetto agli SLA: chi sbaglia e spesso — perché. Le richieste non vengono mai perse grazie a questi allerta. Sì, qualcuno potrebbe rispondere a un ticket utilizzando un template non pertinente, ma lo scopriamo attraverso il feedback.
Se il cliente lo richiede con insistenza, un tecnico di secondo livello può accedere al server e fare ciò che il cliente necessita (è condizione fondamentale confermare via email con le informazioni di accesso al server).
Facciamo questo molto raramente e affidiamo tale lavoro solo ai migliori, poiché vogliamo avere la certezza che i dati degli utenti non vengano compromessi. I migliori sono il secondo livello di supporto.
Il primo livello ha una base di conoscenze dove è possibile inviare per guardare i problemi complessi.
Un'area clienti ricca di funzionalità e una base di conoscenze — e così siamo riusciti a ridurre il numero di richieste a 1-1,5 all'anno per cliente in media.
La seconda linea gestisce solitamente richieste complesse che richiedono intervento manuale. È caratteristico che quanto più costoso è il piano tariffario, tanto meno sono le richieste di questo tipo relative alla macchina virtuale. Di solito, perché chi può permettersi un piano costoso ha sia specialisti in organico, sia semplicemente perché molti problemi non si presentano grazie a configurazioni adeguate. Ricordo ancora quel personaggio che installava un Windows Server non proprio datato su una configurazione con 256 MB di RAM.
La seconda linea dispone di una serie di distribuzioni e di uno script di automazione. Entrambe le cose possono essere aggiornate secondo necessità.
La seconda linea e i manager personali dei piani VIP possono aggiungere note al profilo del cliente. Se è un amministratore Linux, lo annoteremo. Questo sarà un promemoria per la prima linea: l'utente sa esattamente che non sarà un errore mortale, ma una distruzione controllata.
La terza linea gestisce le situazioni più strane. Ad esempio, abbiamo avuto un bug che impediva l'accesso a una delle funzioni del pannello di controllo su Firefox. Un utente minacciava direttamente: «Se non risolvete entro 12 ore, scriverò su tutte le recensioni di hosting». Si è scoperto che il problema era dovuto a un adblocker personalizzato. Sul lato dell'utente, com'è strano. Spesso arrivano errori complessi senza dettagli, e non possono riprodurli. Ci sono i detective con uno screenshot: «Perché lo state correggendo da un mese?» — «Stiamo semplicemente cercando il tuo bug da tutto questo tempo», «Ah, beh, mi è ricapitato oggi, ma non sono riuscito a riprodurlo di nuovo»…
In generale, non si sa mai dove potrebbe finire uno screenshot del dialogo con il supporto, e se una persona contatta il supporto, ha un problema. Si può migliorare il rapporto. Almeno, provare.
Sì, sappiamo che il nostro supporto non è perfetto, ma, come spero, combina una velocità sufficiente con una qualità adeguata. E non aumenta i prezzi dei piani per chi può farne a meno.
Fonte: habr.com
