Bonjour! Nous sommes "Hosting Technologies" et lancés il y a 5 ans — le premier hébergement vds créé spécifiquement pour les développeurs. Nous nous efforçons de le rendre pratique, comme DigitalOcean, mais avec un support russe, des méthodes de paiement et des serveurs en Russie. Mais DigitalOcean n'est pas seulement fiabilité et prix, c'est aussi un service.
Le logiciel d'ISPsystem s'est avéré être une corde qui nous a lié les mains sur le chemin d'un service sympa. Il y a trois ans, nous avons utilisé la facturation Billmanager et le panneau de contrôle du serveur VMmanager et avons rapidement réalisé qu'il était presque impossible de fournir un bon service sans notre propre panneau de contrôle.
Comment ISPsystem a tué la commodité
Bugs
Nous ne pouvions pas résoudre le bogue nous-mêmes - à chaque fois, nous devions écrire au support de quelqu'un d'autre et attendre. La solution à tout problème nécessitait l'intervention d'une société tierce.
Le support ISPsystem a répondu normalement, mais les correctifs n'ont été apportés qu'après quelques versions, et pas toujours et pas toutes. Parfois, des bugs critiques ont été corrigés pendant plusieurs semaines. Nous avons dû rassurer les clients, nous excuser et attendre qu'ISPsystem corrige le bug.
Menace d'indisponibilité
Les mises à jour pouvaient générer des temps d'arrêt imprévisibles qui provoquaient de nouvelles erreurs.
Chaque mise à jour était une loterie : j'ai dû couvrir la facturation et faire des sacrifices aux dieux des mises à jour - à quelques reprises, la mise à jour a causé des temps d'arrêt de 10 à 15 minutes. Nos administrateurs à ce moment-là étaient assis sur leurs yeux - nous ne savions jamais combien de temps durerait le temps d'arrêt et nous ne pouvions pas prédire quand ISPsystem déciderait de publier une nouvelle mise à jour.
Sur la cinquième génération, Billmanager s'est amélioré, mais pour avoir accès aux fonctionnalités nécessaires, j'ai dû installer une version bêta, qui était déjà mise à jour chaque semaine. Si quelque chose se cassait, je devais donner accès à d'autres développeurs afin qu'ils puissent réparer quelque chose.
Interface de panneau peu pratique
Tout était divisé en différents panneaux et contrôlé depuis différents endroits. Par exemple, les clients payaient via Billmanager et devaient redémarrer ou réinstaller VDS dans VMManager. Notre personnel devait également passer d'une fenêtre à l'autre pour aider un client, vérifier la charge de son serveur ou voir quel système d'exploitation il utilisait.
Une telle interface prend du temps, le nôtre comme celui de nos clients. Il n'est question d'aucune commodité, comme celle de DigitalOcean, dans une telle situation.
Cycles de vie courts avec des mises à jour fréquentes de l'API
Nous avons écrit nos propres plugins - par exemple, un plugin avec des méthodes de paiement supplémentaires qui ne sont pas dans VMManager.
Ces dernières années, VMManager avait un cycle de vie relativement court, et dans les nouvelles versions, les noms des variables ou des fonctions de l'API pouvaient changer arbitrairement - cela cassait nos plugins. La prise en charge des anciennes versions a été rapidement supprimée et a dû être mise à jour.
Ne peut pas être modifié
Plus précisément, c'est possible, mais extrêmement inefficace. Les restrictions de licence ne vous permettent pas d'apporter des modifications au code source, vous ne pouvez écrire que des plugins. Plugins maximum - certains éléments de menu, un assistant étape par étape. Les systèmes ISP sont conçus pour être polyvalents, mais nous avions besoin de solutions spécialisées.
La décision était donc mûre d'écrire mon propre panel. Nous nous sommes fixé des objectifs :
- Répondez rapidement aux erreurs, bugs et soyez capable de les corriger vous-même sans faire attendre le client.
- Modifiez librement l'interface pour les flux de travail et les besoins des clients.
- Améliorez la convivialité avec un design épuré et compréhensible.
Et nous avons commencé le développement.
Nouvelle architecture de panneau
Nous avons une équipe de développement autonome, nous avons donc écrit le panneau nous-mêmes.
Le travail principal a été effectué par trois ingénieurs - le CTO Sergey a conçu l'architecture et écrit l'agent serveur, Alexey a fait la facturation et le frontend a été assemblé par notre frontender Artysh.
Étape 1 : Agent serveur
L'agent serveur est un serveur web python qui gère la bibliothèque , qui régit à son tour .
L'agent gère tous les services sur le serveur : création, arrêt, suppression de vds, installation de systèmes d'exploitation, modification de paramètres, etc. via la bibliothèque libvirt. Au moment de la publication de l'article, ce sont plus de quarante fonctions différentes, que nous complétons en fonction de la tâche et des besoins du client.
En théorie, libvirt pouvait être contrôlé directement depuis la facturation, mais cela nécessitait trop de code supplémentaire et nous avons décidé de séparer ces fonctions entre l'agent et la facturation - la facturation fait simplement des requêtes à l'agent via l'API JSON.
L'agent est la première chose que nous avons faite, car il ne nécessitait aucune interface et il était possible de le tester directement depuis la console du serveur.
Ce que l'agent serveur nous a donné : une couche est apparue qui simplifie la vie de tout le monde - la facturation n'a pas besoin d'envoyer tout un tas de commandes, mais seulement de faire une demande. Et l'agent fera tout ce qui est nécessaire : par exemple, il allouera de l'espace disque et de la RAM.
Étape 2. Facturation
Pour notre développeur Alex, ce n'était pas le premier panneau de contrôle - Alex est dans l'hébergement depuis longtemps, il comprenait donc généralement ce dont le client avait besoin et ce dont l'hébergeur avait besoin.
Nous appelons la facturation entre nous un «panneau de contrôle»: il contient non seulement de l'argent et des services, mais également leur gestion, le support client et bien plus encore.
Pour passer du logiciel ISPSystem, il fallait conserver intégralement la fonctionnalité précédente pour les clients, transférer toutes les actions financières des utilisateurs de l'ancienne facturation vers la nouvelle, ainsi que tous les services et connexions entre eux. Nous avons étudié ce qu'il y a dans le produit actuel, puis les solutions des concurrents, principalement DO et Vultr. Nous avons examiné les inconvénients et les avantages, recueilli les commentaires des personnes qui ont travaillé avec d'anciens produits d'ISPsystem.
La nouvelle facturation utilisait deux stacks : PHP classique, MySQL (et dans le futur il est prévu de passer à PostgreSQL), Yii2 comme framework sur le backend et VueJS sur le front. Les piles fonctionnent indépendamment les unes des autres, sont développées par différentes personnes et communiquent à l'aide de l'API JSON. Pour le développement d'hier et d'aujourd'hui, nous utilisons и de JetBrains et je les aime beaucoup (hé les gars !)
Le panel est conçu sur une base modulaire : modules de système de paiement, module d'enregistrement de domaine ou, par exemple, un module de certificat SSL. Vous pouvez facilement ajouter une nouvelle fonctionnalité ou en supprimer une ancienne. Les bases de l'agrandissement sont posées architecturalement, y compris en sens inverse, « vers la quincaillerie ».
Ce que nous avons: un panneau de contrôle sur lequel nous avons un contrôle total. Désormais, les bogues sont corrigés en quelques heures, et non plus en semaines, et les nouvelles fonctionnalités sont implémentées à la demande des clients, et non à la demande d'ISPSystem.
Interface de l'étape 3
L'interface est une idée originale de notre équipe.
Tout d'abord, nous avons examiné ce qui se passerait si nous faisions un add-on sur l'API ISPsystem sans rien changer fondamentalement à l'interface. Cela s'est avéré moyen et nous avons décidé de tout faire à partir de zéro.
Nous pensions que l'essentiel était de rendre l'interface logique, avec un design épuré et minimaliste, puis nous obtiendrions un beau panneau. L'emplacement des éléments a été discuté dans Megaplan et l'interface que les utilisateurs voient maintenant dans le panneau de contrôle va progressivement voir le jour.
Le design de la page de facturation a été le premier à apparaître, car nous avons déjà réalisé des plugins de paiement pour ISPsystem.
L'extrémité avant
Ils ont décidé de faire du panneau une application SPA - peu exigeante en ressources et avec un chargement rapide des données. Notre front-ender Artysh a décidé de l'écrire sur Vue - à ce moment-là, Vue venait juste d'apparaître. Nous avons supposé que le framework se développerait de manière dynamique, comme React, après un certain temps, la communauté Vue se développerait et une mer de bibliothèques apparaîtrait. Nous avons parié sur Vue et nous ne l'avons pas regretté - il faut maintenant peu de temps pour ajouter de nouvelles fonctions à l'avant qui ont déjà été programmées à l'arrière. Nous vous en dirons plus sur le panneau frontal dans un article séparé.
Connecter le frontend au backend
Le frontend était connecté au backend via des notifications push. J'ai dû travailler dur et écrire mon propre gestionnaire, mais maintenant les informations sur la page sont mises à jour presque instantanément.
Qu'est-il arrivé: L'interface du panneau est devenue plus simple. Nous l'avons rendu adaptatif et le chargement rapide vous permet de l'utiliser même à partir de téléphones mobiles dans les dernières minutes avant le décollage, sans installer d'application distincte pour travailler avec le panneau.
Étape 4. Schéma de test et de migration
Lorsque tout a démarré et que les premiers tests ont passé, la question de la migration s'est posée. Tout d'abord, nous avons installé la facturation et commencé à tester son fonctionnement avec l'agent serveur.
Ensuite, nous avons écrit un script simple qui transfère la base de données de l'ancienne facturation vers la nouvelle.
J'ai dû tout tester et revérifier littéralement, puisque les données ont été fusionnées en une nouvelle base de données à partir de trois anciennes : Billmanager, VMmanager et IPmanager manager. Les migrations de test sont peut-être la chose la plus difficile que nous ayons rencontrée dans le processus de développement d'un nouveau panel.
Après revérification, nous avons fermé l'ancienne facturation. La migration finale des données a été un moment très troublant, mais, Dieu merci, elle a été achevée en quelques minutes et sans problèmes notables. Il y avait des bugs mineurs que nous avons corrigés au cours de la semaine. La plupart du temps a été consacré à tester ce qui s'est passé.
Ensuite, nous avons envoyé des lettres aux clients avec l'adresse du nouveau panneau et la facturation et avons fait une redirection.
En résumé: C'EST VIVANT!
Fin heureuse
Dès les premières heures de travail de notre logiciel, nous avons ressenti tous les délices de la transition. Le code était entièrement à nous et avec une architecture pratique, et l'interface était propre et logique.
Premier examen après le lancement du nouveau panel
Nous avons lancé le processus de transition en décembre, à la veille du Nouvel An 2017, lorsque la charge était la plus faible, pour faciliter la transition pour les clients - presque personne ne travaille à la veille des vacances.
La principale chose que nous avons obtenue lors du passage à notre système (en dehors de la fiabilité et de la commodité générales) est la possibilité d'ajouter rapidement des fonctionnalités pour les clients clés - pour être leur visage, pas leur cul.
Quelle est la prochaine?
Nous grandissons, la quantité de données, de clients, de données clients augmente. J'ai dû ajouter un serveur Memcached et deux gestionnaires de files d'attente avec différentes tâches au backend. Le frontend a une mise en cache et ses propres files d'attente.
Bien sûr, nous avons encore eu des aventures au fur et à mesure que le produit se développait et devenait plus complexe, par exemple lorsque nous avons ajouté HighLoad.
Dans le prochain article, nous vous expliquerons comment le tarif Hi-CPU a été lancé : à propos du matériel, des logiciels, des tâches que nous avons résolues et de ce que nous avons fait.
Source: habr.com