El mode de reserva (també conegut com a IPKVM), que us permet connectar-vos a un VPS sense RDP directament des de la capa d'hipervisor, estalvia entre 15 i 20 minuts per setmana.
El primer i més important és no enfadar la gent. A tot el món, el suport es divideix en línies i l'empleat és el primer a provar les solucions típiques. Si la tasca va més enllà dels seus límits, transferiu-la a la segona línia. Per tant, entre els administradors de VDS sovint hi ha gent que sap pensar. A diferència de molts altres suports. Bé, almenys significativament més sovint. I estructuren bé el tiquet, descrivint de seguida tot el que cal. Si la primera línia "es borrosa" i accidentalment us demana que l'enceneu i desactiveu com a resposta a això, és un fiasco.
La tasca és molt senzilla: oferir un suport adequat per al nostre allotjament VDS amb un cost mínim. Perquè som el menjar ràpid del món dels proveïdors d'allotjament: sense "llepades" especials, preus baixos, qualitat normal. Ja hi havia una història sobre el fet que amb l'arribada dels amors d'Instagram que intentaven automatitzar la gestió de comptes i els propietaris de petites empreses amb comptabilitat remota i altres persones poc avançades en tecnologia, la comunicació "com a administrador a un administrador" va deixar de funcionar. Vaig haver de canviar el llenguatge de comunicació.
Ara us explicaré una mica més sobre els processos i sobre els problemes inevitables amb ells.
No enfadis la gent amb el número 1
Qualsevol suport és una producció en línia de muntatge. Arriba una aplicació, l'empleat de primera línia de seguida intenta reconèixer una situació típica que ja ha passat mil vegades i tornarà a passar mil vegades. Hi ha un 90% de possibilitats que l'aplicació sigui una típica, i podeu respondre-la prement literalment un parell de botons perquè la plantilla es substitueixi. Normalment només cal escriure un parell de paraules a la plantilla i ja està. O aneu a la interfície de gestió i premeu un parell de botons allà. En casos més complexos (transferències de zona a zona, per exemple), cal seguir l'algorisme.
El que més irrita la gent, independentment de les altres qualitats de suport, és la típica reacció davant una petició atípica. Arriba un bitllet, on es descriu tot detalladament, hi ha moltes dades necessàries per a tres preguntes per endavant, el client anticipa un diàleg... I segons les primeres paraules, l'empleat de suport en pilot automàtic tecleja un acord per substituir la plantilla. "Intenta reiniciar, hauria d'ajudar".
Això és el que realment obre la ment de la gent, i és després d'aquestes situacions que es mantenen les crítiques més negatives i els comentaris enfadats. Està clar que estàvem molt equivocats, és allà on coneixem les estadístiques. En general, vam cometre errors de diferents maneres, però aquests casos sempre són salvatges. Inclòs per nosaltres mateixos. Per descomptat, ens agradaria que això no passés gens. Però això no és gaire possible a la pràctica: un cop cada poques setmanes, un empleat cansat de la monotonia prem els botons divertits.
No enfadis la gent amb el número 2
La segona cosa que obre igualment la ment és quan ningú respon a un bitllet durant el temps suficient. A Europa, aquest comportament de suport és normal: tres dies abans que un incident sigui acceptat per treballar és més que la norma. Fins i tot si sou molt urgent i alguna cosa s'està cremant: sense xarxes socials, sense telèfon, sense missatgeria, només envieu un correu electrònic i espereu el vostre torn. A Rússia això és molt menys comú, però alguns bitllets encara estan "oblidats". Al principi del treball, vam establir un SLA per a la primera resposta de 15 minuts. I això és honest les 24 hores del dia. Està clar que quan l'allotjament VDS es fa gran, això apareix. Però els proveïdors de serveis dubtosos no tenen això. I només dubtàvem al principi i només després ens vam fer més o menys grans. Bé, més o menys mitjana.
La primera línia són els operadors als quals se'ls va donar guions i se'ls va ensenyar a reaccionar davant de situacions típiques. Solucionen ràpidament els problemes i intenten, en 15 minuts, respondre amb una acció típica o informar que el bitllet està en curs i transferir-lo al segon.
La segona línia és els administradors d'allotjament; saben com fer gairebé tot a mà. També hi ha un gestor de suport que pot fer-ho tot i una mica més. La tercera línia són els desenvolupadors, reben entrades com "arreglar això a la interfície" o "tal i tal paràmetre es té en compte incorrectament".
Reduir el nombre de sol·licituds
Per raons òbvies, si voleu oferir assistència econòmica, no hauríeu d'augmentar la primera línia perquè la gent pugui gestionar els scripts més ràpidament, sinó que augmenteu l'automatització. De manera que en lloc de persones amb guions hi hagi guions reals. Per tant, una de les primeres coses que vam fer va ser automatitzar els processos d'aixecament d'una màquina virtual, escalant per recursos (inclosos per disc amunt i avall, però no per freqüència del processador) i altres coses semblants. Com més pugui fer l'usuari des de la interfície, més fàcil serà viure amb la primera línia, i més petita pot ser. Quan un usuari accedeix a alguna cosa que es troba al seu compte personal, ha de fer-ho i dir-li com ho pot fer ell mateix.
Si no necessites suport, està fent una bona feina.
La segona característica, que estalvia molt de temps, és el temps que es necessita per omplir la base de coneixement. Si l'usuari té un problema que no s'inclou a la llista d'accions compatibles (la majoria de vegades es tracta de preguntes a nivell de "com instal·lar un servidor de Minecraft" o "On configurar un VPS al servidor Win"), article està escrit a la base de coneixement. El mateix article detallat està escrit per a totes les peticions estranyes. Per exemple, si un usuari demana al suport per eliminar el tallafoc de Windows Server integrat, l'enviem a llegir què passarà si realment està desactivat i com canviar els permisos només per al programari seleccionat. Perquè el problema sol ser amb el fet que alguna cosa no es pot connectar a causa de la configuració, i no amb el tallafoc en si. Però és molt difícil explicar-ho cada cop en diàleg. Però d'alguna manera no vull desactivar el tallafoc, perquè ben aviat perdrem la màquina virtual o el client.
Si alguna cosa sobre el programari d'aplicació a la base de coneixement es fa molt popular, podeu afegir la distribució al mercat perquè aparegui el servei "configureu un servidor amb això ja instal·lat". De fet, això és el que va passar amb Docker i això és el que va passar amb el servidor de Minecraft. Un cop més, un botó "Fes-me bé" a la interfície estalvia fins a centenars d'entrades a l'any.
Mode d'emergència
Després d'aquests passos, les avaries més greus que requereixen un treball manual es queden amb el fet que l'usuari per algun motiu va perdre els mitjans d'accés remot al sistema operatiu convidat a l'hipervisor. El cas més comú és una configuració del tallafoc simplement incorrecta, el segon més comú són alguns errors que impedeixen que Win s'iniciï amb normalitat i us obliguen a reiniciar el mode segur. I en mode segur, RDP no està disponible per defecte.
Hem creat un mode d'emergència per a aquest cas. De fet, normalment per accedir a una màquina VDS cal tenir algun tipus de client per al treball remot. Molt sovint estem parlant d'accés a consola, RDP, VNC o alguna cosa semblant. El desavantatge d'aquests mètodes és que no funcionen sense un sistema operatiu. Però a nivell d'hipervisor podem rebre la imatge a la pantalla i transmetre-hi les pulsacions del teclat! És cert que això carrega bastant el processador (a causa de la transmissió de vídeo real), però us permet obtenir el resultat desitjat.
Per tant, hem donat accés al mode d'emergència a tots els usuaris, però està limitat pel que fa a la durada de l'ús continuat. Afortunadament, com mostra la pràctica, aquesta vegada és suficient per reiniciar i arreglar alguna cosa.
El resultat són encara menys bitllets de suport. I quan l'administrador pot arreglar el bitllet ell mateix, el suport no ha d'entrar i esbrinar-ho.
Problemes restants
Molt sovint, els usuaris pensen que el suport els està impulsant alguna cosa. Malauradament, no es pot fer res al respecte (o no hem trobat res). Els dos exemples més comuns són els límits de recursos i la protecció DDoS.
Cada màquina virtual té límits de càrrega de disc, memòria i trànsit permès. La possibilitat d'establir límits s'especifica a l'oferta, però els mateixos límits es seleccionen perquè la majoria dels usuaris puguin treballar en silenci sense ni tan sols saber-ne. Però si de sobte comenceu a jugar massa amb el canal i el disc, els algorismes avisen automàticament l'usuari. Des de l'abril de l'any passat, hem eliminat els panys automàtics. En canvi, establiu límits suaus per a un període variable.
Abans, era així: un avís, després, si l'usuari no feia cas, un bloqueig automàtic. I en aquell moment la gent es va ofendre: "De què estàs parlant, és el teu sistema el que té errors, no ha passat res!" - i després podeu intentar entendre el programari d'aplicació o oferir-vos augmentar el pla de tarifes. No tenim l'oportunitat d'entendre el funcionament del programari d'aplicació, perquè això està fora de l'abast del suport. Encara que els primers casos es van resoldre conjuntament amb els usuaris. Recordo especialment aquell en què el trampós de visualitzacions de YouTube tenia un troià integrat i aquest troià estava filtrant memòria. Al final, vam arribar a la conclusió que no eren Heisenbugs, sinó problemes amb els usuaris, en cas contrari ens hauríem inundat de peticions similars. Però ni una sola persona ha admès encara que ell mateix podria superar les tarifes.
Una història semblant passa amb DDoS: escrivim que vostè, estimat usuari, està sota atac. Connecteu la protecció, si us plau. I l'usuari: "Sí, tu mateix m'estàs atacant!" Per descomptat, només fem DDoS un usuari per tal d'enganyar-los de 300 rubles. És un negoci rendible. Sí, sé que molts grans llocs d'allotjament de la categoria més cara inclouen aquesta protecció a la tarifa, però això no ho podem fer: l'economia del menjar ràpid dicta altres preus mínims.
Amb la mateixa freqüència, aquells dels quals hem suprimit les dades no estan satisfets amb el suport. En el sentit que es va suprimir legítimament després de la finalització del període de pagament. Si algú no renova el seu lloguer de VDS, s'envien diverses notificacions explicant què passarà a continuació. Quan s'ha completat el pagament, la màquina virtual s'atura, però la seva imatge es desa. Arriba una altra notificació, i després un parell més. La imatge s'emmagatzema durant set dies addicionals abans de ser suprimida permanentment. Per tant, hi ha una categoria de persones que estan molt descontents amb això. A partir de "l'administrador va sortir, es van enviar notificacions al seu correu electrònic, restablir" i acabant amb acusacions de frau i amenaces de dany físic. El motiu són els mateixos preus per a tots els altres usuaris. Si el guardem durant un mes, necessitarem més emmagatzematge. Això significarà preus més elevats per a cada client individual. I l'economia del menjar ràpid... Bé, enteneu la idea. I com a resultat, als fòrums rebem ressenyes amb l'esperit de "van agafar diners, van suprimir dades, estafadors".
M'agradaria assenyalar que tenim una línia de tarifes premium. Allà, per descomptat, la situació és diferent, ja que tenim en compte els desitjos del client i configurem de manera flexible tant el límit com la supressió en cas d'impagament (ho posem al menys, per no bloquejar-lo). Allà ja és econòmicament viable, perquè realment pot passar qualsevol cosa, i retenir un gran client permanent és car.
De vegades els usuaris són maliciosos. Diverses vegades el nostre sistema va experimentar errors amb centenars de màquines virtuals bloquejades a causa d'algunes accions clarament il·legítimes dels clients. De fet, va ser precisament per aquestes situacions que necessitàvem els nostres propis controladors de xarxa per controlar l'activitat de la xarxa i veure que l'usuari no executava un atac des del seu servidor. El seguiment d'aquest pla és important perquè els nois rumorosos no violin els límits de les màquines virtuals veïnes.
Hi ha qui simplement envia correu brossa, el meu o infringeix l'oferta. Llavors truca per demanar suport i pregunta què ha fallat i per què el cotxe està bloquejat. Si el procés del bitllet de la captura de pantalla s'anomena "spam sender.exe", és probable que alguna cosa vagi malament. Aproximadament cada dues setmanes rebem queixes de Sony o Lucasfilm (ara Disney) que algú de la nostra màquina virtual de la nostra gamma d'adreces IP distribueix una pel·lícula gravada. Per a això, immediatament bloquejaràs i tornaràs els diners restants al compte segons l'oferta (permeteu-me que us recordi: la nostra quantificació és per segon, és a dir, sempre hi haurà saldo segur). I per recuperar els diners, segons la llei, cal mostrar el passaport: això és contra el blanqueig de capitals. Per alguna raó, en lloc de mostrar el passaport, els pirates escriuen que els vam extreure diners, oblidant-nos d'aclarir algunes de les circumstàncies.
Oh sí. La nostra millor petició de l'any és: "Puc provar una màquina virtual durant uns dies a un ritme de 30 rubles al mes abans de comprar?"
Total
La primera línia ordena els bitllets i respon amb accions típiques. Aquí és on hi ha més insatisfacció. Encara no serà possible arreglar-ho, perquè la base per solucionar-ho està en l'automatització de l'allotjament, és a dir, en un gran endarreriment. Sí, tenim més de molts al mercat, però encara no n'hi ha prou. Per tant, el millor que es pot fer és establir un seguiment de primera línia. Monitorització del servei d'ajuda - Implementació de KPI de primera línia. Els retards en l'SLA són visibles en temps real: qui s'està fent la merda, sovint, per què. Gràcies a aquestes alertes, les aplicacions mai es perden. Sí, el bitllet es pot respondre amb una plantilla que no està relacionada amb el tema, però això ja ho sabem a partir dels comentaris.
Si el client ho demana realment, l'especialista de segona línia pot anar al servidor i fer-hi el que necessiti (la condició és la confirmació per carta en la qual proporcionarà la informació d'inici de sessió al servidor).
Ho fem molt poques vegades i confiem aquest treball només als millors, perquè volem tenir garanties que les dades dels usuaris no es danyin. Els millors són la segona línia de suport.
La primera línia té una base de coneixement on podeu enviar per buscar coses complexes.
Un compte personal ric en funcions i una base de coneixements, i ara hem pogut reduir el nombre de sol·licituds entre 1 i 1,5 per any per client de mitjana.
La segona línia sol processar aplicacions complexes que requereixen mà d'obra. El que és típic: com més car és el pla de tarifes, menys sol·licituds d'aquest tipus per màquina virtual. En general, perquè els que es poden permetre una tarifa cara o tenen especialistes al personal, o simplement la meitat dels problemes no sorgeixen perquè hi ha prou configuració per a tot. Encara recordo l'heroi que va instal·lar el Windows Server no més antic en una configuració amb 256 MB de RAM.
La segona línia té un conjunt de kits de distribució i un conjunt d'scripts d'automatització. Tots dos es poden actualitzar segons sigui necessari.
La segona línia i els gestors personals de les tarifes VIP poden afegir notes al perfil del client. Si és un administrador de Linux, ho anotarem. Aquesta serà la primera pista: l'usuari sap del cert que no serà un tret a la cama, sinó una destrucció controlada.
La tercera línia mana la més estranya. Per exemple, vam tenir un error que va fer impossible accedir a una de les funcions del vostre compte personal a Firefox. L'usuari va fer xantatge directament: "Si no ho solucioneu en 12 hores, escriuré a totes les ressenyes de l'amfitrió". Com va resultar, el problema estava en el bloc d'anuncis personalitzat. Pel costat dels usuaris, curiosament. Sovint es produeixen errors complexos sense detalls i ja no es poden repetir. Hi ha detectius amb una captura de pantalla: "Per què ho arregles durant un mes?" - "Sí, hem estat buscant el teu error tot aquest temps", "Ah, bé, avui m'he tornat a trobar, però no ho he pogut tornar a repetir"...
En general, mai se sap on acabarà una captura de pantalla d'un diàleg amb suport, i si una persona truca per demanar suport, llavors té un problema. Pots millorar la teva actitud. Almenys prova-ho.
Sí, sabem que el nostre suport no és perfecte, però m'agradaria creure que combina la velocitat suficient amb la qualitat suficient. I no augmenta els preus de les tarifes per a aquells que poden prescindir-ne.
Font: www.habr.com