Bonjour! Nous sommes « Hosting Technologies » et nous avons lancé — le premier hébergement VDS, spécialement conçu pour les développeurs, il y a 5 ans. Nous nous efforçons de le rendre aussi pratique que DigitalOcean, mais avec un support russe, des moyens de paiement et des serveurs en Russie. Mais DigitalOcean, ce n'est pas seulement de la fiabilité et des prix compétitifs, c'est aussi un service.
Le logiciel d'ISPsystem s'est révélé être une corde qui nous a entravés dans notre quête d'un excellent service. Il y a trois ans, nous utilisions la facturation Billmanager et le panneau de contrôle des serveurs VMmanager, et nous avons rapidement compris qu'il était pratiquement impossible de fournir un bon service sans notre propre panneau.
Comment ISPsystem a tué la convivialité
Bugs
Nous ne pouvions pas corriger les bugs nous-mêmes - il fallait chaque fois écrire au support d'autrui et attendre. La résolution de tout problème nécessitait la réactivité d'une entreprise tierce.
Le support d'ISPsystem répondait correctement, mais les corrections arrivaient seulement après plusieurs versions, et même pas toujours et pas toutes. Parfois, des bugs critiques étaient corrigés après plusieurs semaines. Nous devions apaiser les clients, nous excuser et attendre qu'ISPsystem résolve le bug.
La menace des temps d'arrêt
Les mises à jour pouvaient entraîner des temps d'arrêt imprévisibles, qui provoquaient de nouvelles erreurs.
Chaque mise à jour était une loterie : il fallait suspendre la facturation et offrir des sacrifices aux dieux des mises à jour - quelques fois, une mise à jour provoquait un temps d'arrêt de 10 à 15 minutes. Nos administrateurs s'asseyaient en attendant - nous ne savions jamais combien de temps durerait le temps d'arrêt et ne pouvions pas prévoir quand ISPsystem déciderait de publier une nouvelle mise à jour.
Avec la cinquième génération de Billmanager, c'était un peu mieux, mais pour accéder aux fonctionnalités nécessaires, il fallait installer la version bêta, qui était déjà mise à jour chaque semaine. Si quelque chose se cassait, il fallait donner accès à des développeurs externes pour qu'ils règlent le problème.
Interface du panneau peu pratique
Tout était divisé en différents panneaux et géré depuis différents endroits. Par exemple, les clients payaient via Billmanager, mais devaient redémarrer ou réinstaller leur VDS dans VMManager. Nos employés devaient également basculer entre les fenêtres pour aider le client, vérifier la charge de son serveur ou voir quel système d'exploitation il utilisait.
Une telle interface prend du temps – tant le nôtre que celui des clients. Il n'est pas question de confort, comme chez DigitalOcean, dans une telle situation.
Des cycles de vie courts avec des mises à jour fréquentes de l'API
Nous avons développé nos propres plugins — par exemple, un plugin avec des méthodes de paiement supplémentaires qui ne figurent pas dans VMManager.
Au cours des dernières années, VMManager a eu un cycle de vie relativement court, et dans les nouvelles versions, les noms des variables ou des fonctions dans l'API pouvaient changer de manière aléatoire — cela a cassé nos plugins. Le support des anciennes versions était rapidement abandonné et nous devions nous mettre à jour.
Impossible de modifier
En fait, c'est possible, mais extrêmement inefficace. Les restrictions de licence ne permettent pas de modifier le code source, il est seulement possible d'écrire des plugins. Le maximum des plugins — certains éléments de menu, un assistant étape par étape. ISPsystem est conçu pour être universel, alors que nous avions besoin de solutions spécialisées.
C'est ainsi qu'a mûri la décision d'écrire notre propre panneau. Nous avons établi nos objectifs :
- Réagir rapidement aux erreurs, aux bugs et avoir la possibilité de les corriger soi-même, sans faire attendre le client.
- Modifier librement l'interface en fonction des processus de travail et des besoins du client.
- Améliorer l'ergonomie avec un design clair et compréhensible.
Et nous avons commencé le développement.
L'architecture du nouveau panneau
Nous avons une équipe de développement autonome, donc le panneau a été écrit par nos soins.
Le travail principal a été réalisé par trois ingénieurs — le directeur technique Sergey a imaginé l'architecture et a écrit l'agent serveur, Alexey a créé la facturation, et notre développeur frontend Artysh a assemblé le frontend.
Étape 1. Agent serveur
L'agent serveur est un serveur web en Python qui gère la bibliothèque , qui, à son tour, gère .
L'agent gère tous les services sur le serveur : création, arrêt, suppression de VDS, installation de systèmes d'exploitation, modification des paramètres, etc. via la bibliothèque libvirt. Au moment de la rédaction de cet article, cela comprend plus de quarante fonctions différentes, que nous complétons en fonction des tâches et des besoins du client.
En théorie, libvirt pouvait être géré directement depuis la facturation, mais cela nécessitait trop de code supplémentaire et nous avons décidé de répartir ces fonctions entre l'agent et la facturation — la facturation fait simplement des demandes à l'agent via l'API JSON.
L'agent a été la première chose que nous avons réalisée, car il ne nécessitait aucune interface et pouvait être testé directement depuis la console du serveur.
Ce que nous a apporté l'agent serveur : Une couche est apparue, simplifiant la vie de tous : la facturation n'a plus besoin de transmettre une multitude de commandes, mais simplement de faire une demande. L'agent s'occupera de tout ce qui est nécessaire : par exemple, allouer de l'espace sur le disque et de la mémoire vive.
Étape 2. Facturation
Pour notre développeur Alex, ce n'était pas son premier panneau de contrôle - Alex est dans l'hébergement depuis longtemps, il comprenait donc ce que le client avait besoin et ce qu'il fallait pour l'hébergeur.
Nous appelons la facturation entre nous « panneau de contrôle » : il ne s'agit pas seulement d'argent et de services, mais aussi de leur gestion, du support client, et bien plus encore.
Pour passer du logiciel ISPSystem, il était nécessaire de conserver entièrement le fonctionnement antérieur pour les clients, de transférer toutes les opérations financières des utilisateurs de l'ancienne facturation vers la nouvelle, ainsi que tous les services et leurs interconnexions. Nous avons examiné ce qui existe dans le produit actuel, puis les solutions des concurrents, principalement DO et Vultr. Nous avons observé les inconvénients et les avantages, et recueilli des avis de personnes ayant travaillé avec les anciens produits d'ISPsystem.
Dans la nouvelle facturation, nous avons utilisé deux stacks : PHP classique, MySQL (et une transition future vers PostgreSQL), Yii2 en tant que framework backend et VueJS en frontend. Les stacks fonctionnent indépendamment les uns des autres, développés par différentes personnes, et communiquent via une API JSON. Pour le développement, à l'époque et maintenant, nous utilisons et de JetBrains et nous les aimons tendrement (salut les gars !)
Le panneau est conçu selon un principe modulaire : modules de systèmes de paiement, module d'enregistreurs de domaines, ou par exemple, module de certificats SSL. Il est facile d'ajouter une nouvelle fonction ou de supprimer une ancienne. Une infrastructure extensible est incorporée architecturally, y compris en direction inverse, vers le « matériel ».
Ce que nous avons obtenu: panneau de contrôle, sur lequel nous avons un contrôle total. Maintenant, les bugs sont corrigés en quelques heures, et non en semaines, et de nouvelles fonctions sont mises en œuvre à la demande des clients, et non selon le désir d'ISPSystem.
Étape 3. Interface
L'interface est notre œuvre collective.
Au début, nous avons regardé ce qui se passerait si nous ajoutions une couche au-dessus de l'API ISPsystem, sans changer radicalement l'interface. Le résultat n'était pas concluant et nous avons décidé de tout refaire depuis le début.
Nous croyions que l'essentiel était de rendre l'interface logique, avec un design épuré et minimaliste, et ainsi obtenir un beau tableau de bord. L'emplacement des éléments a été discuté dans Megaplan, et progressivement cet interface a vu le jour, tel qu'il apparaît maintenant dans le panneau de contrôle.
Le design de la page de facturation est apparu en premier, car nous avions déjà créé des plugins de paiement pour ISPsystem.
Frontend
Nous avons décidé de réaliser le panneau en tant qu'application SPA — peu exigeante en ressources et avec un chargement rapide des données. Notre frontend développeur, Artysh, a choisi de l'écrire en Vue — à l'époque, Vue venait juste de sortir. Nous avons supposé que le framework évoluerait dynamiquement, à l'instar de React, et qu'avec le temps, la communauté Vue s'agrandit et que de nombreuses bibliothèques apparaîtraient. Nous avons misé sur Vue et ne l'avons pas regretté — il est désormais facile d'ajouter de nouvelles fonctionnalités sur le frontend, qui ont déjà été programmées sur le backend. Nous parlerons plus en détail du frontend du panneau dans un article séparé.
Connexion du frontend avec le backend
Le frontend a été relié au backend via des push. Nous avons dû nous battre et écrire notre propre gestionnaire, mais maintenant la mise à jour des informations sur la page se fait presque instantanément.
Ce que cela a donné : l'interface du panneau est devenue plus simple. Nous l'avons rendue responsive, et le chargement rapide permet de l'utiliser même sur des mobiles dans les dernières minutes avant le décollage, sans avoir à installer d'application séparée pour travailler avec le panneau.
Étape 4. Tests et schéma de migration
Lorsque tout a été mis en place et les premiers tests effectués, la question de la migration s'est posée. Notre première action a été d'installer le module de facturation et de commencer à tester son fonctionnement avec l'agent serveur.
Nous avons ensuite écrit un simple script qui transfère la base de données de l'ancienne facturation vers la nouvelle.
Il a fallu tester et vérifier presque tout, car les données étaient fusionnées dans une nouvelle base à partir de trois anciennes : Billmanager, VMmanager et IPmanager. Peut-être que les migrations de test ont été la partie la plus complexe que nous avons rencontrée lors du développement du nouveau panneau.
Après des vérifications, nous avons arrêté l'ancienne facturation. La migration finale des données a été un moment très anxieux, mais, heureusement, elle s'est réalisée en quelques minutes et sans problèmes notables. Il y a eu de petits bugs que nous avons corrigés au cours de la semaine. La majeure partie du temps a été consacrée au test de ce que nous avions obtenu.
Nous avons ensuite envoyé des emails aux clients avec l'adresse du nouveau panneau et de la facturation et avons mis en place une redirection.
En résumé : ÇA EXISTE !
Fin heureuse
Dès les premières heures de fonctionnement de notre logiciel, nous avons ressenti tous les avantages de la transition. Le code était entièrement le nôtre, avec une architecture pratique, et l'interface était claire et logique.
Le premier avis après le lancement du nouveau panneau
Nous avons lancé le processus de transition en décembre, à l'approche de la nouvelle année 2017, lorsque la charge était la plus faible, afin de faciliter le passage pour les clients — presque personne ne travaille avant les vacances.
L'essentiel que nous avons obtenu lors de la transition vers notre système (à part la fiabilité générale et la commodité) est la possibilité d'ajouter rapidement des fonctionnalités pour des clients clés — être en première ligne, pas en coulisse.
Et après ?
Nous grandissons, le volume de données, le nombre de clients et les données des clients augmentent. Nous avons dû ajouter un serveur Memcached et deux gestionnaires de files d'attente avec des tâches différentes sur le backend. Sur le frontend, il y a une mise en cache et nos propres files d'attente.
Bien sûr, nous avons également rencontré des aventures au fur et à mesure que le produit se développait et se complexifiait, par exemple, lorsque nous avons ajouté HighLoad.
Dans le prochain article, nous expliquerons comment nous avons lancé le tarif Hi-CPU : à propos du matériel, des logiciels, des problèmes que nous avons résolus et des résultats que nous avons obtenus.
Source : habr.com
