ISPsystem, entschuldige und lebe wohl! Warum und wie wir unser eigenes Server-Control-Panel entwickelt haben.

Hallo! Wir sind „Hosting-Technologien“ und haben vor 5 Jahren gestartet VDSina — das erste VDS-Hosting, das speziell für Entwickler geschaffen wurde. Wir streben an, es so benutzerfreundlich wie DigitalOcean zu gestalten, jedoch mit russischer Unterstützung, Zahlungsmöglichkeiten und Servern in Russland. Aber DigitalOcean bietet nicht nur Zuverlässigkeit und Preis, sondern auch Service.

Die Software von ISPsystem stellte sich als das Seil heraus, das uns auf dem Weg zu einem großartigen Service die Hände band. Vor drei Jahren nutzten wir das Billing-System Billmanager und das Server-Management-Panel VMmanager und merkten schnell, dass es praktisch unmöglich ist, einen guten Service ohne unser eigenes Panel anzubieten.

Wie ISPsystem den Komfort zunichte machte

Bugs

Wir konnten Bugs nicht selbst beheben – jedes Mal mussten wir den Support eines Dritten kontaktieren und warten. Die Lösung eines Problems erforderte immer die Reaktion eines externen Unternehmens.

Der Support von ISPsystem antwortete normalerweise, aber die Fixes kamen nur mit mehreren Releases, und das auch nicht immer und nicht für alle. Manchmal wurden kritische Bugs Wochen lang nicht behoben. Wir mussten unsere Kunden beruhigen, uns entschuldigen und warten, bis ISPsystem den Bug behob.

Bedrohung durch Ausfallzeiten

Updates konnten unvorhersehbare Ausfallzeiten hervorrufen, die neue Fehler verursachten.

Jedes Update war ein Glücksspiel: Wir mussten das Billing-System schließen und Opfer an die Götter der Updates bringen – ein paar Mal führte ein Update zu einer Ausfallzeit von 10-15 Minuten. Unsere Admins saßen in der Zwischenzeit angespannt – wir hatten nie eine Ahnung, wie lange die Ausfallzeit dauern würde und konnten nicht vorhersagen, wann ISPsystem entschließen würde, ein neues Update herauszugeben.

Im fünften Generation von Billmanager wurde es besser, aber um Zugang zu den benötigten Funktionen zu erhalten, mussten wir die Beta installieren, die bereits wöchentlich aktualisiert wurde. Wenn etwas kaputt ging, mussten wir externen Entwicklern Zugang geben, damit sie etwas reparieren.

Unbequeme Benutzeroberfläche des Panels

Alles war auf verschiedene Panels aufgeteilt und wurde von verschiedenen Orten aus gesteuert. Zum Beispiel zahlten Kunden über Billmanager, während sie VDS in VMManager neu starten oder neu installieren mussten. Auch unsere Mitarbeiter mussten zwischen Fenstern wechseln, um dem Kunden zu helfen, die Last auf seinem Server zu überprüfen oder zu sehen, welches Betriebssystem er verwendet.

Eine solche Benutzeroberfläche kostet Zeit – sowohl unsere als auch die der Kunden. In einer solchen Situation kann von Benutzerfreundlichkeit wie bei DigitalOcean keine Rede sein.

Kurze Lebenszyklen mit häufigen API-Updates

Wir haben eigene Plugins geschrieben — zum Beispiel ein Plugin mit zusätzlichen Zahlungsmethoden, die in VMManager nicht vorhanden sind.

In den letzten Jahren hatte VMManager einen relativ kurzen Lebenszyklus, wobei die Namen der Variablen oder Funktionen in der API in neuen Versionen wahllos geändert werden konnten — das hat unsere Plugins gebrochen. Der Support für alte Versionen wurde schnell eingestellt, und es musste ein Update durchgeführt werden.

Kann nicht angepasst werden.

Genauer gesagt, kann man es, aber es ist äußerst ineffektiv. Lizenzbeschränkungen erlauben keine Änderungen am Quellcode, man kann nur Plugins schreiben. Die maximalen Plugins sind einige Menüelemente, ein Schritt-für-Schritt-Assistent. ISPsystem ist auf Universalität ausgelegt, aber wir benötigten spezielle Lösungen.

So reifte die Entscheidung, unser eigenes Panel zu schreiben. Wir setzen uns Ziele:

• Schnell auf Fehler und Bugs reagieren und die Möglichkeit haben, sie selbst zu beheben, ohne den Kunden warten zu lassen.
• Den Bereich frei an die Arbeitsabläufe und Bedürfnisse des Kunden anzupassen.
• Die Benutzerfreundlichkeit durch ein sauberes und verständliches Design zu erhöhen.

Und begannen mit der Entwicklung.

Die Architektur des neuen Panels.

Wir haben ein eigenständiges Entwicklerteam, sodass wir das Panel selbst geschrieben haben.
Die Hauptarbeit wurde von drei Ingenieuren geleistet — der technische Direktor Sergey entwarf die Architektur und schrieb den Server-Agenten, Alexey kümmerte sich um das Billing, und unser Frontend-Entwickler Artysh baute das Frontend zusammen.

Schritt 1. Server-Agent.

Der Server-Agent ist ein Webserver in Python, der die Bibliothek verwaltet libvirt, die wiederum verwaltet den Hypervisor Qemu-kvm..

Der Agent verwaltet alle Dienste auf dem Server: Erstellung, Stopp, Löschung von VDS, Installation von Betriebssystemen, Änderung von Parametern und so weiter über die Bibliothek libvirt. Zum Zeitpunkt der Veröffentlichung dieses Artikels sind das mehr als vierzig verschiedene Funktionen, die wir je nach Aufgabe und Bedarf des Kunden ergänzen.

Idealerweise könnte man libvirt direkt aus dem Billing heraus steuern, aber das erforderte zu viel zusätzlichen Code, und wir entschieden uns, diese Funktionen zwischen Agent und Billing aufzuteilen — das Billing stellt einfach Anfragen an den Agenten über die JSON-API.

Der Agent war das erste, was wir gemacht haben, da er keine Benutzeroberfläche erforderte und direkt aus der Konsole des Servers getestet werden konnte.

Was uns der Server-Agent gebracht hat: Es entstand eine Schicht, die das Leben für alle erleichtert - das Billing muss nicht mehr eine ganze Reihe von Befehlen übermitteln, sondern nur eine Anfrage stellen. Der Agent erledigt alles Notwendige: zum Beispiel wird Platz auf der Festplatte und RAM bereitgestellt.

Schritt 2. Billing

Für unseren Entwickler Alex war dies nicht das erste Control Panel - Alex ist schon lange im Hosting-Bereich tätig, daher wusste er im Allgemeinen, was der Kunde braucht und was der Host benötigt.

Billing nennen wir untereinander "Control Panel": es enthält nicht nur Geld und Dienstleistungen, sondern auch deren Verwaltung, Kundensupport und vieles mehr.

Für den Übergang von der Software ISPSystem war es notwendig, die vorherigen Funktionen für die Kunden vollständig zu bewahren, alle finanziellen Transaktionen der Nutzer aus dem alten Billing in das neue zu übertragen sowie alle Dienstleistungen und deren Verbindungen zu sichern. Wir haben untersucht, was im aktuellen Produkt vorhanden ist, dann die Lösungen der Wettbewerber, hauptsächlich DO und Vultr, betrachtet. Wir schauten uns die Nachteile und Vorteile an und sammelten Rückmeldungen von Personen, die mit den alten Produkten von ISPsystem gearbeitet haben.

Im neuen Billing haben wir zwei Stacks verwendet: klassisches PHP, MySQL (und in Zukunft ist geplant, auf PostgreSQL umzusteigen), Yii2 als Backend-Framework und VueJS für das Frontend. Die Stacks arbeiten unabhängig voneinander, werden von verschiedenen Personen entwickelt und kommunizieren über ein JSON-API. Für die Entwicklung nutzen wir damals und jetzt PHPStorm und WebStorm von JetBrains und wir lieben sie sehr (Leute, hallo!)

Das Panel ist modular aufgebaut: Module für Zahlungssysteme, ein Modul für Domainregistrare oder beispielsweise ein Modul für SSL-Zertifikate. Es ist einfach, eine neue Funktion hinzuzufügen oder eine alte zu entfernen. Die architektonische Grundlage für Erweiterungen ist gegeben, auch in umgekehrter Richtung, "zum Gerät hin."

Was wir erhalten haben: ein Control Panel, über das wir die volle Kontrolle haben. Jetzt werden Bugs in Stunden und nicht in Wochen behoben, und neue Funktionen werden auf Anfrage der Kunden und nicht nach dem Wunsch von ISPSystem umgesetzt.

Schritt 3. Interface

Das Interface ist unser gemeinsames Baby.

Zuerst haben wir geschaut, was passiert, wenn wir eine Erweiterung über die API von ISPsystem machen, ohne das Interface grundlegend zu ändern. Das Ergebnis war nicht zufriedenstellend und wir entschieden uns, alles von Grund auf neu zu machen.

Wir glaubten, dass das Wichtigste darin besteht, die Schnittstelle logisch zu gestalten, mit einem klaren und minimalistischen Design, um ein schönes Panel zu erhalten. Die Anordnung der Elemente wurde im Megaplan besprochen, und allmählich entstand die Schnittstelle, die die Benutzer jetzt im Kontrollpanel sehen.

Zuerst kam das Design der Abrechnungsseite, da wir bereits Zahlungs-Plugins für ISPsystem entwickelt hatten.

Frontend

Wir entschieden uns, das Panel als SPA-Anwendung zu gestalten – ressourcenschonend und mit schneller Datenladezeit. Unser Frontend-Entwickler Artysh entschied sich, es mit Vue zu schreiben – zu der Zeit war Vue gerade erschienen. Wir vermuteten, dass das Framework dynamisch wachsen würde, ähnlich wie React, und dass die Vue-Community sich erweitern und eine Fülle von Bibliotheken entstehen würde. Wir setzten auf Vue und bereuten es nicht – jetzt dauert es wenig Zeit, neue Funktionen, die bereits im Backend programmiert wurden, ins Frontend hinzuzufügen. Mehr über das Frontend des Panels werden wir in einem separaten Artikel berichten.

Verbindung zwischen Frontend und Backend

Das Frontend wurde mit dem Backend über Push-Nachrichten verbunden. Wir mussten uns anstrengen und einen eigenen Handler schreiben, aber jetzt erfolgt die Aktualisierung der Informationen auf der Seite nahezu in Echtzeit.

Was wir erreicht haben: Das Panel-Interface wurde einfacher. Wir haben es responsive gemacht, und das schnelle Laden ermöglicht die Nutzung auch auf Mobilgeräten in den letzten Minuten vor dem Abflug, ohne dass eine separate Anwendung für die Arbeit mit dem Panel installiert werden muss.

Schritt 4. Testen und Migrationsschema

Als alles gestartet war und die ersten Tests bestanden wurden, stellte sich die Frage der Migration. Zuerst richteten wir die Abrechnung ein und begannen, deren Zusammenarbeit mit dem Server-Agenten zu testen.

Dann schrieben wir ein einfaches Skript, das die Datenbank aus der alten Abrechnung in die neue überträgt.

Wir mussten tatsächlich alles testen und überprüfen, da die Daten in eine neue Datenbank aus drei alten: Billmanager, VMmanager und IPmanager zusammengeführt wurden. Vielleicht sind die Testmigrationen das Schwierigste, mit dem wir im Entwicklungsprozess des neuen Panels konfrontiert waren.

Nach den Überprüfungen schlossen wir die alte Abrechnung. Die endgültige Datenmigration war ein sehr angespanntes Ereignis, aber zum Glück wurde sie innerhalb weniger Minuten und ohne nennenswerte Probleme durchgeführt. Es gab einige kleinere Bugs, die wir im Laufe einer Woche beheben mussten. Die meiste Zeit nahm das Testen in Anspruch, was wir erreicht hatten.

Dann haben wir den Kunden E-Mails mit der Adresse des neuen Panels und der Abrechnung geschickt und eine Weiterleitung eingerichtet.

Insgesamt: ES LEBT!

Happy End

Von den ersten Stunden der Arbeit mit unserer Software haben wir die Vorteile des Wechsels gespürt. Der Code war vollständig unser eigener und hatte eine benutzerfreundliche Architektur, und die Benutzeroberfläche war klar und logisch.

Die erste Rückmeldung nach dem Start des neuen Panels

Wir haben den Übergangsprozess im Dezember gestartet, kurz vor dem Neujahr 2017, als die Last am geringsten war, um den Wechsel für die Kunden einfacher zu gestalten – fast niemand arbeitet vor den Feiertagen.

Das Wichtigste, was wir durch den Wechsel zu unserem System (neben allgemeiner Zuverlässigkeit und Benutzerfreundlichkeit) erhalten haben, ist die Möglichkeit, schnell Funktionen für Schlüsselkunden hinzuzufügen – ihnen ein Gesicht zu geben und nicht im Hintergrund zu agieren.

Was folgt jetzt?

Wir wachsen, die Menge an Daten, Kunden und Kundendaten wächst. Auf die Backend-Seite musste ein Memcached-Server und zwei Task-Manager mit unterschiedlichen Aufgaben hinzugefügt werden. Auf der Frontend-Seite gibt es Caching und eigene Warteschlangen.

Natürlich hatten wir auch Abenteuer während der Entwicklung und komplexer werdenden Produktgestaltung, zum Beispiel als wir HighLoad hinzugefügt haben.

Im nächsten Artikel werden wir erzählen, wie wir den Hi-CPU-Tarif gestartet haben: über die Hardware, Software, welche Aufgaben wir gelöst haben und was wir erreicht haben.

Quelle: habr.com