El modo de emergencia (también conocido como IPKVM), que permite conectarse a un VPS sin RDP directamente desde el nivel del hipervisor, ahorra entre 15 y 20 minutos a la semana.
Lo primero y más importante: no enojar a la gente. En todo el mundo, el soporte se divide en líneas, y el personal de primera línea debe intentar las soluciones típicas. Si la tarea se sale de sus límites, debe pasar a la segunda línea. Así, entre los administradores de VDS, hay muchas personas que saben pensar. A diferencia de muchos otros soportes. Bueno, al menos significativamente más a menudo. Y estructuran bien el ticket, describiendo de inmediato todo lo necesario. Si la primera línea se 'ciega' y por error responden pidiendo reiniciar, eso es un fracaso.
La tarea es muy simple: hacer que el soporte de nuestro hosting VDS sea adecuado con el mínimo de gastos. Porque somos la comida rápida del mundo de los proveedores de hosting: sin ningún 'repulido' especial, precios bajos, calidad normal. Ya he contado sobre cómo, con la llegada de las encantadoras de Instagram que intentan automatizar la gestión de cuentas y dueños de pequeñas empresas con contabilidad remota y otras personas no muy avanzadas en tecnología, la comunicación 'como un administrador con otro administrador' dejó de funcionar. Fue necesario cambiar el lenguaje de comunicación.
Ahora hablaré un poco más sobre los procesos y los errores inevitables que vienen con ellos.
No enojar a la gente № 1
Cualquier soporte es una producción en cadena. Llega una solicitud, el personal de primera línea intenta reconocer de inmediato la situación típica que ha ocurrido mil veces y volverá a ocurrir mil veces más. Hay un 90 % de probabilidad de que la solicitud sea típica, y se puede responder con solo pulsar un par de botones para que se inserte la plantilla. Normalmente, solo hay que escribir un par de palabras en la plantilla y listo. O entrar en la interfaz de gestión y pulsar un par de botones allí. En casos más complejos (traslados de una zona a otra, por ejemplo), es necesario seguir un algoritmo.
Lo que más enoja a la gente, independientemente de las otras cualidades del soporte, es la reacción típica a una solicitud atípica. Llega un ticket donde todo está detalladamente descrito, hay un montón de datos necesarios para tres preguntas por adelantado, el cliente anticipa el diálogo… Y al escuchar las primeras palabras, el personal de soporte automáticamente escribe el acorde para insertar la plantilla 'intente reiniciar, debería ayudar'.
Esto es lo que realmente irrita a las personas, y es después de estas situaciones que quedan más críticas negativas y comentarios enojados. Está claro que hemos cometido errores, de ahí conocemos las estadísticas. Nos hemos equivocado de diferentes maneras, pero tales casos son simplemente absurdos. Esto es especialmente cierto para nosotros mismos. Por supuesto, quisiéramos que esto no ocurriera en absoluto. Pero en la práctica no es muy posible: una vez cada pocas semanas, un empleado cansado de la monotonía puede presionar inadvertidamente botones divertidos.
No enfurecer a las personas Nº 2
Lo segundo que irrita de igual manera es cuando nadie responde a un ticket durante demasiado tiempo. En Europa, tal comportamiento del soporte es normal: tres días hasta que se acepta un incidente es más que norma. Incluso si es muy urgente y algo está ardiendo — no hay redes sociales, ni teléfono, ni mensajería, solo correo y espera tu turno. En Rusia esto es mucho menos común, pero aun así algunos tickets son "olvidados". Desde el principio establecimos un SLA para la primera respuesta de 15 minutos. Y eso con un servicio 24/7 honesto. Está claro que cuando el hosting VDS se vuelve grande, esto aparece. Pero los proveedores de servicios dudosos no tienen esto. Y al inicio éramos justamente dudosos y solo después nos volvimos más o menos grandes. Bueno, más o menos medianos.
La primera línea son los operadores a quienes se les dieron guiones y se les enseñó a reaccionar ante situaciones típicas. Ellos clasifican rápidamente los problemas y tratan de responder en 15 minutos con una acción típica o informar que el ticket está en proceso y pasarlo a la segunda línea.
La segunda línea son ya los administradores de hosting, que saben hacer casi todo manualmente. También está allí el jefe de soporte, que sabe hacer todo y un poco más. La tercera línea son los desarrolladores, a quienes llegan tickets como "corrijan esto en la interfaz" o "un cierto parámetro se cuenta incorrectamente allí".
Reducir el número de solicitudes
Por razones obvias, si deseas brindar soporte de manera económica, no debes aumentar la primera línea para que las personas con scripts resuelvan más rápido, sino incrementar la automatización. Así, en lugar de personas con scripts, debemos tener scripts reales. Por eso, una de las primeras cosas que hicimos fue automatizar los procesos de creación de máquinas virtuales, escalado de recursos (incluyendo disco hacia arriba y hacia abajo, pero no la frecuencia del procesador) y otras tareas similares. Cuanto más pueda hacer el usuario desde la interfaz, más fácil será para la primera línea y menor debe ser su tamaño. Cuando un usuario presenta un problema que está en su panel personal, hay que mostrarle cómo puede resolverlo por sí mismo.
Si no necesitas soporte, significa que está funcionando bien.
Otra característica que ahorra mucho tiempo es la extensa creación de la base de conocimientos. Si un usuario tiene un problema que no está en la lista de acciones soportadas (la mayoría de las veces preguntas como '¿cómo instalar un servidor de Minecraft?' o '¿dónde configurar un VPS en Win Server?'), se escribe un artículo en la base de conocimientos. Se redacta un artículo detallado para todas las consultas inusuales. Por ejemplo, si un usuario pide soporte para eliminar el firewall integrado de Windows Server, le enviamos a leer sobre qué sucederá si realmente lo desactivamos y cómo permitir únicamente los permisos para el software seleccionado. Porque el problema generalmente radica en que algo no puede conectarse debido a la configuración, no con el firewall en sí. Pero explicar esto cada vez en un diálogo es muy complicado. Y desactivar el firewall no es deseable, porque pronto podríamos perder ya sea la máquina virtual o al cliente.
Si algo relacionado con el software de aplicación en la base de conocimientos se vuelve muy visitado, se puede listar un distribuidor en el marketplace para ofrecer el servicio de 'levantar un servidor con esto ya instalado'. De hecho, esto sucedió con Docker y también con el servidor de Minecraft. Una vez más, un solo botón de 'hágamelo bien' en la interfaz ahorra hasta cien tickets al año.
Modo de emergencia
Después de estas acciones, la mayoría de las averías graves que requieren intervención manual quedan vinculadas a que el usuario ha perdido, por alguna razón, el medio de acceso remoto al sistema operativo huésped en el hipervisor. El caso más frecuente es una configuración incorrecta del firewall; el segundo más común son errores que impiden que Windows arranque normalmente y obligan a reiniciarse en Modo Seguro. En Modo Seguro, RDP no está disponible de forma predeterminada.
Hemos habilitado un modo de emergencia para este caso. Normalmente, para acceder a una máquina VDS se necesita algún cliente para el trabajo remoto. Generalmente, esto implica acceso a consola, RDP, VNC o algo similar. La desventaja de estos métodos es que no funcionan sin un sistema operativo. Pero a nivel de hipervisor podemos obtener tanto la imagen en pantalla como enviar pulsaciones de teclado. Eso sí, esto carga bastante el procesador (debido a la transmisión de video), pero permite obtener el resultado deseado.
Por eso, hemos otorgado acceso al modo de emergencia a todos los usuarios, aunque está limitado en cuanto a duración continua de uso. Afortunadamente, como muestra la práctica, este tiempo es más que suficiente para reiniciar y corregir algo.
El resultado es que hay aún menos tickets de soporte. Y en los casos donde el administrador puede resolver el ticket por sí mismo, el soporte no necesita intervenir ni complicarse.
Problemas restantes
Frecuentemente, los usuarios creen que el soporte les está vendiendo algo. Desgraciadamente, no se puede hacer nada al respecto (o no hemos encontrado una solución). Los dos ejemplos más comunes son los límites de recursos y la protección DDoS.
Cada máquina virtual tiene límites en la carga del disco, la memoria y el tráfico permitido. La posibilidad de establecer límites está especificada en la oferta, y los límites en sí se configuran para que la mayoría de los usuarios puedan trabajar cómodamente, incluso sin saber que existen. Sin embargo, si comienzas a saturar mucho el canal y el disco, los algoritmos advierten automáticamente al usuario. Desde abril del año pasado, eliminamos el bloqueo automático. En su lugar, se establecen límites suaves por un período variable.
Antes era así: advertencia, luego, si el usuario no prestaba atención, bloqueo automático. Y en ese momento, las personas se ofendían: «¿Qué les pasa, su sistema está fallando, no había nada!» — y luego se podía intentar resolver el problema del software o proponer un aumento en el plan tarifario. No tenemos la posibilidad de investigar el funcionamiento del software aplicado, porque está fuera del alcance del soporte. Aunque los primeros casos los analizamos juntos con los usuarios. Especialmente recuerdo aquel, donde un aumentador de vistas en YouTube tenía un troyano incorporado, y este troyano estaba consumiendo memoria. Al final, llegamos a la conclusión de que no eran errores del sistema, sino problemas de los usuarios; de lo contrario, nos habríamos visto inundados con solicitudes similares. Pero hasta ahora, ninguna persona ha confesado que pudo haber superado los límites por sí misma.
Historia similar con DDoS: escribimos que usted, estimado usuario, está bajo ataque. Por favor, active la protección. Y el usuario: «¡Ustedes son los que me atacan!» Claro, estamos atacando a un solo usuario con DDoS para sacarles 300 rublos. Es un buen negocio. Sí, sé que muchas grandes empresas de hosting del segmento más caro incluyen esta protección en el plan, pero nosotros no podemos hacer eso: la economía de comida rápida impone otros precios mínimos.
No menos frecuentemente, el soporte es criticado por aquellos cuyos datos hemos eliminado. En el sentido de que los eliminamos legítimamente tras el final del periodo pagado. Si alguien no renueva el alquiler de un VDS, recibe varias notificaciones explicando lo que sucederá a continuación. Al momento de finalizar el pago, la máquina virtual se detiene, pero su imagen se guarda. Llega otra notificación y luego un par más. La imagen se conserva siete días adicionales y solo después se elimina de forma permanente. Hay una categoría de personas que están muy descontentas con esto. Desde «el administrador fue despedido, las notificaciones llegaban a su correo, restauren» hasta acusaciones de fraude y amenazas de violencia física. La razón sigue siendo los mismos precios para todos los demás usuarios. Si almacenamos durante un mes, necesitaremos más espacio de almacenamiento. Esto significará mayores precios para cada cliente en particular. Y la economía de comida rápida... Bueno, ya lo han entendido. Como resultado, en los foros recibimos comentarios del tipo «cobraron, eliminaron los datos, son estafadores».
Cabe señalar que ofrecemos una gama de tarifas premium. Ahí, por supuesto, la situación es diferente, ya que tomamos en cuenta las solicitudes del cliente y ajustamos tanto el límite como la eliminación en caso de impago (lo llevamos a negativo, solo para no bloquearlo). En ese caso, ya es económicamente viable, porque realmente ocurren diversas situaciones, y mantener a un cliente importante a largo plazo tiene un alto costo.
A veces los usuarios tienen malas intenciones. En varias ocasiones hemos tenido problemas en nuestro sistema al bloquear cientos de máquinas virtuales debido a acciones claramente ilegítimas de los clientes. De hecho, precisamente por estas situaciones necesitamos controladores de red propios para monitorear la actividad en la red y ver que el usuario no está realizando un ataque desde su servidor. El monitoreo de este tipo es importante para que los límites de las máquinas virtuales vecinas no sean violados por usuarios problemáticos.
Hay quienes simplemente envían spam, minan o de otra manera violan el contrato. Luego, se comunican con el soporte y preguntan qué salió mal y por qué su máquina fue bloqueada. Si el proceso en el ticket se llama ‘envío de spam.exe’ en la captura de pantalla, entonces, probablemente, algo no está bien. Además, aproximadamente cada dos semanas recibimos quejas de empresas como Sony o Lucasfilm (ahora Disney), indicando que alguien desde nuestra máquina virtual en nuestro rango de direcciones IP está distribuyendo una película pirata. Por eso, se bloquea inmediatamente y se devuelve el saldo restante en la cuenta según el contrato (recuerdo: el corte es por segundo, es decir, el saldo siempre será exacto). Y para devolver el dinero, según la ley, se debe mostrar una identificación: esto es parte de la lucha contra el lavado de dinero. Los piratas, por alguna razón, en lugar de mostrar su identificación, escriben que les hemos robado dinero, olvidando clarificar parte de las circunstancias.
Ah, sí. Nuestra mejor consulta del año fue: ‘¿Se puede probar la máquina virtual de 30 rublos al mes durante unos días antes de la compra?’.
Summary
La primera línea clasifica los tickets y responde con acciones típicas. Aquí es donde más insatisfacción hay. No será posible solucionar esto, ya que la base de la corrección está en la automatización del hosting, es decir, en un enorme backlog. Sí, tenemos más que muchos en el mercado, pero aún no es suficiente. Por lo tanto, lo mejor que se puede hacer es establecer un monitoreo de la primera línea. El monitoreo del servicio de atención al cliente implica cumplir con los KPI de la primera línea. En tiempo real se pueden ver los retrasos en el SLA: quién falla, y a menudo —por qué. Gracias a estas alertas, las solicitudes nunca se pierden. Sí, puede que se responda a un ticket con un template fuera de tema, pero eso lo sabemos gracias a los comentarios.
Si el cliente lo solicita con insistencia, el especialista de segunda línea puede acceder al servidor y hacer lo que sea necesario para el cliente (la condición es la confirmación por escrito, donde informe los datos de acceso al servidor).
Hacemos esto muy raramente y confiamos tal trabajo solo a los mejores, porque queremos tener garantías de que los datos del usuario no se dañen. Los mejores son el soporte de segunda línea.
La primera línea tiene una base de conocimientos donde se pueden enviar consultas más complejas.
Un panel de control rico en funciones más una base de conocimientos — y así logramos reducir el número de consultas a 1–1.5 al año por cliente en promedio.
La segunda línea generalmente maneja solicitudes complejas que requieren trabajo manual. Curiosamente, cuanto más caro es el plan, menos de estas solicitudes hay por máquina virtual. Normalmente porque aquellos que pueden permitirse un plan caro, ya sea tienen expertos en su equipo o simplemente la mitad de los problemas no surgen porque la configuración es suficiente para todo. Aún recuerdo a ese héroe que instaló un Windows Server no tan viejo en una configuración con 256 MB de RAM.
La segunda línea tiene un conjunto de distribuciones y un conjunto de scripts de automatización. Ambos pueden actualizarse según sea necesario.
La segunda línea y los gerentes personales de planes VIP pueden agregar notas en el perfil del cliente. Si es un administrador de Linux, así lo anotaremos. Esto será una pista para la primera línea: el usuario sabe que no será un disparo en el pie, sino una destrucción controlada.
La tercera línea gobierna lo más extraño. Por ejemplo, tuvimos un error que impedía acceder a una de las funciones del panel de usuario en Firefox. El usuario prácticamente chantajeó: "Si no lo arreglan en un plazo de 12 horas, escribiré en todas las reseñas de hosting". Resulta que el problema estaba en un adblocker personalizado. En el lado del usuario, por extraño que parezca. A menudo llegan errores complejos sin detalles, y ya no pueden reproducirlos. A veces hay detectives con capturas de pantalla: "¿Por qué lo están arreglando desde hace un mes?" — "Sí, solo estamos buscando su error durante todo este tiempo", "Ah, bueno, me volvió a pasar hoy, pero de nuevo no pude reproducirlo"...
En realidad, nunca sabes dónde terminará una captura de pantalla del diálogo con soporte, y si alguien está contactando al soporte, tiene un problema. Se puede mejorar la relación. Al menos, intentarlo.
Sí, sabemos que nuestro soporte no es perfecto, pero, como me gustaría creer, combina una velocidad adecuada con una calidad suficiente. Y no aumenta los precios de los planes para aquellos que pueden prescindir de él.
Fuente: habr.com
