¡Hola! Somos "Hosting Technologies" y lanzamos hace 5 años — el primer alojamiento vds creado específicamente para desarrolladores. Nos esforzamos por hacerlo conveniente, como DigitalOcean, pero con soporte ruso, métodos de pago y servidores en Rusia. Pero DigitalOcean no es solo confiabilidad y precio, también es un servicio.
El software de ISPsystem resultó ser una cuerda que nos ató las manos en el camino hacia un servicio genial. Hace tres años, usamos la facturación de Billmanager y el panel de control del servidor VMmanager y rápidamente nos dimos cuenta de que era casi imposible brindar un buen servicio sin nuestro propio panel de control.
Cómo el sistema ISP eliminó la comodidad
Bichos
No pudimos arreglar el error nosotros mismos, cada vez que teníamos que escribir al soporte de otra persona y esperar. La solución a cualquier problema requería la respuesta de una tercera empresa.
El soporte de ISPsystem respondió con normalidad, pero las correcciones llegaron solo después de algunos lanzamientos, y luego no siempre y no todos. A veces, los errores críticos se corrigieron durante varias semanas. Tuvimos que tranquilizar a los clientes, disculparnos y esperar a que ISPsystem corrigiera el error.
Amenaza de tiempo de inactividad
Las actualizaciones podían generar tiempos de inactividad impredecibles que provocaban nuevos errores.
Cada actualización era una lotería: tenía que encubrir la facturación y hacer sacrificios a los dioses de las actualizaciones; un par de veces, la actualización provocó un tiempo de inactividad de 10 a 15 minutos. En este momento, nuestros administradores estaban sentados en sus ojos: nunca sabíamos cuánto duraría el tiempo de inactividad y no podíamos predecir cuándo ISPsystem decidiría lanzar una nueva actualización.
En la quinta generación, Billmanager mejoró, pero para tener acceso a las funciones necesarias, tuve que instalar una versión beta, que ya se actualizaba todas las semanas. Si algo se rompía, tenía que dar acceso a otros desarrolladores para que pudieran arreglar algo.
Interfaz de panel inconveniente
Todo estaba dividido en diferentes paneles y controlado desde diferentes lugares. Por ejemplo, los clientes pagaban a través de Billmanager y tenían que reiniciar o reinstalar VDS en VMManager. Nuestro personal también tuvo que cambiar entre ventanas para ayudar a un cliente, verificar la carga en su servidor o ver qué sistema operativo estaba usando.
Tal interfaz lleva tiempo, tanto el nuestro como el de nuestros clientes. No se trata de ninguna conveniencia, como la de DigitalOcean, en tal situación.
Ciclos de vida cortos con actualizaciones frecuentes de API
Escribimos nuestros propios complementos, por ejemplo, un complemento con métodos de pago adicionales que no están en VMManager.
En los últimos años, VMManager tenía un ciclo de vida relativamente corto y, en las nuevas versiones, los nombres de las variables o funciones en la API podían cambiar arbitrariamente, lo que rompía nuestros complementos. El soporte para versiones anteriores se eliminó rápidamente y tuvo que actualizarse.
no se puede modificar
Más precisamente, es posible, pero extremadamente ineficiente. Las restricciones de licencia no le permiten realizar cambios en el código fuente, solo puede escribir complementos. Complementos máximos: algunos elementos de menú, un asistente paso a paso. Los sistemas ISP están diseñados para ser versátiles, pero necesitábamos soluciones especializadas.
Así que la decisión de escribir mi propio panel estaba madura. Nos hemos fijado objetivos:
- Responda rápidamente a errores, bugs y sea capaz de corregirlos usted mismo sin hacer esperar al cliente.
- Modifique libremente la interfaz para los flujos de trabajo y las necesidades del cliente.
- Aumente la usabilidad con un diseño limpio y comprensible.
Y comenzamos el desarrollo.
Nueva arquitectura de paneles
Tenemos un equipo de desarrollo autosuficiente, así que escribimos el panel nosotros mismos.
El trabajo principal fue realizado por tres ingenieros: el director técnico Sergey ideó la arquitectura y escribió el agente del servidor, Alexey hizo la facturación y el front-end fue ensamblado por nuestro front-ender Artysh.
Paso 1: Agente del servidor
El agente del servidor es un servidor web de Python que administra la biblioteca. , que a su vez gobierna .
El agente administra todos los servicios en el servidor: crear, detener, eliminar vds, instalar sistemas operativos, cambiar parámetros, etc. a través de la biblioteca libvirt. En el momento de la publicación del artículo, estas son más de cuarenta funciones diferentes, que complementamos según la tarea y las necesidades del cliente.
En teoría, libvirt podría controlarse directamente desde la facturación, pero esto requería demasiado código adicional y decidimos separar estas funciones entre el agente y la facturación: la facturación simplemente realiza solicitudes al agente a través de la API JSON.
El agente es lo primero que hicimos, ya que no requería de ninguna interfaz y era posible probarlo directamente desde la consola del servidor.
Lo que nos dio el agente del servidor: ha aparecido una capa que simplifica la vida de todos: la facturación no necesita enviar un montón de comandos, sino solo hacer una solicitud. Y el agente hará todo lo necesario: por ejemplo, asignará espacio en disco y RAM.
Paso 2. Facturación
Para nuestro desarrollador Alex, este no fue el primer panel de control: Alex ha estado en hosting durante mucho tiempo, por lo que generalmente entendió lo que necesitaba el cliente y lo que necesitaba el proveedor de alojamiento.
Llamamos a la facturación entre nosotros un "panel de control": contiene no solo dinero y servicios, sino también su gestión, atención al cliente y mucho más.
Para cambiar del software ISPSystem, era necesario preservar completamente la funcionalidad anterior para los clientes, transferir todas las acciones financieras de los usuarios de la facturación anterior a la nueva, así como todos los servicios y conexiones entre ellos. Estudiamos lo que hay en el producto actual, luego las soluciones de los competidores, principalmente DO y Vultr. Analizamos las desventajas y ventajas, recopilamos comentarios de personas que trabajaron con productos antiguos de ISPsystem.
La nueva facturación utilizó dos pilas: PHP clásico, MySQL (y en el futuro se planea cambiar a PostgreSQL), Yii2 como marco en el backend y VueJS en el frente. Las pilas funcionan de forma independiente, las desarrollan diferentes personas y se comunican mediante la API de JSON. Para el desarrollo entonces y ahora usamos и de JetBrains y los quiero mucho (¡hola chicos!)
El panel está diseñado de forma modular: módulos de sistema de pago, módulo registrador de dominios o, por ejemplo, un módulo de certificado SSL. Puede agregar fácilmente una nueva función o eliminar una antigua. La base para la expansión se establece arquitectónicamente, incluso en la dirección opuesta, "hacia el hardware".
Lo que tenemos: un panel de control sobre el que tenemos control total. Ahora los errores se solucionan en horas, no en semanas, y las nuevas funciones se implementan a pedido de los clientes, y no a pedido de ISPSystem.
Paso 3 Interfaz
La interfaz es una creación de nuestro equipo.
Primero, analizamos lo que sucedería si hiciéramos un complemento sobre la API del sistema ISP sin cambiar fundamentalmente nada en la interfaz. Resultó regular y decidimos hacer todo desde cero.
Creemos que lo principal es hacer que la interfaz sea lógica, con un diseño limpio y minimalista, y luego obtendremos un panel hermoso. La ubicación de los elementos se discutió en Megaplan y la interfaz que ahora ven los usuarios en el panel de control irá naciendo poco a poco.
El diseño de la página de facturación fue el primero en aparecer, porque ya hemos realizado complementos de pago para ISPsystem.
Interfaz
Decidieron convertir el panel en una aplicación SPA, poco exigente en cuanto a recursos y con una carga de datos rápida. Nuestro front-ender Artysh decidió escribirlo en Vue; en ese momento, Vue acababa de aparecer. Asumimos que el marco se desarrollaría dinámicamente, como React, después de un tiempo, la comunidad de Vue crecería y aparecería un mar de bibliotecas. Apostamos por Vue y no nos arrepentimos, ahora lleva poco tiempo agregar nuevas funciones al frente que ya han sido programadas en el backend. Le contaremos más sobre el panel frontal en un artículo separado.
Conectando el frontend al backend
El frontend se conectó al backend a través de notificaciones push. Tuve que trabajar duro y escribir mi propio controlador, pero ahora la información de la página se actualiza casi al instante.
Qué pasó: La interfaz del panel se ha simplificado. Lo hicimos adaptativo y la carga rápida le permite usarlo incluso desde teléfonos móviles en los últimos minutos antes del despegue, sin instalar una aplicación separada para trabajar con el panel.
Paso 4. Esquema de prueba y migración
Cuando todo se puso en marcha y pasaron las primeras pruebas, surgió la cuestión de la migración. En primer lugar, instalamos la facturación y comenzamos a probar su funcionamiento con el agente del servidor.
Luego escribimos un script simple que transfiere la base de datos de la facturación anterior a la nueva.
Tuve que probar y volver a verificar literalmente todo, ya que los datos se fusionaron en una nueva base de datos a partir de tres antiguas: Billmanager, VMmanager y el IPmanager del administrador. Quizás las migraciones de prueba son lo más difícil que encontramos en el proceso de desarrollo de un nuevo panel.
Después de volver a verificar, cerramos la facturación anterior. La migración de datos final fue un momento muy problemático, pero, gracias a Dios, se completó en unos minutos y sin problemas notables. Hubo errores menores que solucionamos durante la semana. La mayor parte del tiempo se dedicó a probar lo que sucedió.
Luego enviamos cartas a los clientes con la dirección del nuevo panel y facturación e hicimos una redirección.
En resumen: ¡ESTÁ VIVO!
Final feliz
Desde las primeras horas de trabajo de nuestro software, sentimos todas las delicias de la transición. El código era completamente nuestro y con una arquitectura conveniente, y la interfaz era limpia y lógica.
Primera revisión tras el lanzamiento del nuevo panel
Lanzamos el proceso de transición en diciembre, en la víspera del Año Nuevo 2017, cuando la carga era menor, para facilitar la transición a los clientes, casi nadie trabaja en la víspera de las vacaciones.
Lo principal que obtuvimos al cambiar a nuestro sistema (aparte de la confiabilidad y conveniencia generales) es la capacidad de agregar rápidamente funcionalidad para clientes clave, para ser su rostro, no su trasero.
¿Qué será lo próximo?
Estamos creciendo, la cantidad de datos, clientes, datos de clientes está creciendo. Tuve que agregar un servidor Memcached y dos administradores de colas con diferentes tareas al backend. La interfaz tiene almacenamiento en caché y sus propias colas.
Por supuesto, todavía tuvimos aventuras a medida que el producto se desarrollaba y se volvía más complejo, por ejemplo, cuando agregamos HighLoad.
En el siguiente artículo te contamos cómo se lanzó la tarifa Hi-CPU: sobre hardware, software, qué tareas resolvimos y qué hicimos.
Fuente: habr.com