Hallo! Wir von „Hosting Technologien“ haben vor 5 Jahren — das erste VDS-Hosting ins Leben gerufen, das speziell für Entwickler geschaffen wurde. Unser Ziel ist es, es so benutzerfreundlich wie DigitalOcean zu machen, jedoch mit russischem Support, Zahlungsoptionen und Servern in Russland. DigitalOcean bietet nicht nur Zuverlässigkeit und Preis, sondern auch einen hervorragenden Service.
Die Software von ISPsystem stellte sich als eine Fessel heraus, die uns daran hinderte, einen erstklassigen Service anzubieten. Vor drei Jahren nutzten wir das Abrechnungssystem Billmanager und die Serververwaltungspalette VMmanager und erkannten schnell, dass es nahezu unmöglich ist, einen guten Service ohne unsere eigene Software bereitzustellen.
Wie ISPsystem die Benutzerfreundlichkeit beeinträchtigt hat
Fehler
Wir konnten Fehler nicht selbst beheben – jedes Mal mussten wir den externen Support kontaktieren und warten. Die Lösung jedes Problems erforderte eine Reaktion von einer Drittpartei.
Der Support von ISPsystem antwortete normalerweise, aber die Fixes kamen erst nach mehreren Releases, und das auch nicht immer und nicht für alle Probleme. Manchmal dauerte es mehrere Wochen, bis kritische Fehler behoben wurden. Wir mussten unsere Kunden beruhigen, uns entschuldigen und warten, bis ISPsystem den Fehler behob.
Bedrohung von Ausfallzeiten
Updates konnten unvorhersehbare Ausfallzeiten verursachen, die neue Fehler hervorriefen.
Jedes Update war ein Glücksspiel: wir mussten die Abrechnung schließen und Opfer an die Götter der Updates bringen – ein paar Mal verursachte das Update einen Ausfall von etwa 10-15 Minuten. In dieser Zeit saßen unsere Administratoren angespannt da – wir wussten nie, wie lange der Ausfall dauern würde, und konnten nicht vorhersagen, wann ISPsystem beschließen würde, ein neues Update herauszubringen.
In der fünften Generation von Billmanager wurde es besser, aber um auf die benötigten Funktionen zuzugreifen, mussten wir die Beta-Version installieren, die bereits wöchentlich aktualisiert wurde. Wenn etwas nicht funktionierte, mussten wir Fremdentwicklern Zugriff gewähren, damit sie Reparaturen vornehmen konnten.
Unhandliche Benutzeroberfläche des Panels
Alles war auf verschiedene Panels verteilt und von unterschiedlichen Orten aus gesteuert. Beispielsweise zahlten die Kunden über Billmanager, mussten jedoch ihre VDS in VMManager neu starten oder neu installieren. Auch unsere Mitarbeiter mussten zwischen den Fenstern wechseln, um dem Kunden zu helfen, die Serverauslastung zu überprüfen oder zu sehen, welches Betriebssystem verwendet wurde.
Eine solche Benutzeroberfläche kostet Zeit – sowohl unsere als auch die der Kunden. Von der Bequemlichkeit, wie bei DigitalOcean, kann in dieser Situation keine Rede sein.
Kurze Lebenszyklen mit häufigen API-Updates
Wir haben eigene Plugins entwickelt – zum Beispiel ein Plugin mit zusätzlichen Zahlungsmöglichkeiten, die im VMManager nicht vorhanden sind.
In den letzten Jahren hatte der VMManager einen relativ kurzen Lebenszyklus, wobei sich in neuen Versionen die Namen von Variablen oder Funktionen in der API willkürlich änderten – das führte zu Problemen mit unseren Plugins. Die Unterstützung älterer Versionen wurde schnell eingestellt, und wir mussten aktualisieren.
Es ist nicht möglich, Anpassungen vorzunehmen.
Genauer gesagt, es ist möglich, aber äußerst ineffizient. Lizenzbeschränkungen erlauben keine Änderungen am Quellcode, man kann nur Plugins schreiben. Maximal können Plugins einige Menüelemente und einen Schritt-für-Schritt-Assistenten bereitstellen. ISPsystem ist auf Universalisierung ausgelegt, während wir spezialisierte Lösungen benötigten.
So reifte die Entscheidung, unser eigenes Panel zu erstellen. Wir haben uns folgende Ziele gesetzt:
- Schnell auf Fehler und Bugs reagieren zu können und diese selbstständig zu beheben, ohne den Kunden warten zu lassen.
- Die Benutzeroberfläche flexibel an die Arbeitsabläufe und Bedürfnisse des Kunden anpassen zu können.
- Die Benutzerfreundlichkeit durch ein klares und verständliches Design zu erhöhen.
Und wir haben mit der Entwicklung begonnen.
Die Architektur des neuen Panels
Wir haben ein autarkes Entwicklungsteam, sodass wir das Panel selbst erstellt haben.
Die Hauptarbeit leisteten drei Ingenieure: Der technische Direktor Sergej entwarf die Architektur und implementierte den Server-Agenten, Alexej kümmerte sich um das Billing, und unser Frontend-Entwickler Artysh baute die Benutzeroberfläche.
Schritt 1. Server-Agent
Der Server-Agent ist ein Webserver, der in Python geschrieben ist und die Bibliothek verwaltet, die wiederum den .
Der Agent steuert alle Dienste auf dem Server: Er erstellt, stoppt und löscht VDS-Instanzen, installiert Betriebssysteme, ändert Parameter und so weiter über die libvirt-Bibliothek. Zum Zeitpunkt der Erstellung dieses Artikels umfasst dies über vierzig verschiedene Funktionen, die wir je nach Aufgabe und Kundenbedürfnissen erweitern.
Theoretisch wäre es möglich gewesen, libvirt direkt aus dem Billing zu steuern, aber das hätte zu viel zusätzlichen Code erfordert. Daher entschieden wir, diese Funktionen zwischen Agent und Billing aufzuteilen – das Billing sendet einfach Anfragen an den Agenten über die JSON-API.
Der Agent war das erste, was wir entwickelten, da er keine Benutzeroberfläche benötigte und direkt über die Serverkonsole getestet werden konnte.
Was der Server-Agent uns gebracht hat: Es gibt jetzt eine Schicht, die das Leben für alle einfacher macht – die Abrechnung muss nicht mehr eine Flut von Befehlen übermitteln, sondern lediglich eine Anfrage stellen. Der Agent erledigt alles Weitere: zum Beispiel vergibt er Speicherplatz auf der Festplatte und RAM.
Schritt 2. Abrechnung
Für unseren Entwickler Alex war dies nicht die erste Steuerungspanel – Alex ist schon lange im Hosting-Bereich, daher hatte er ein gutes Verständnis dafür, was der Kunde benötigt und was der Hosting-Anbieter braucht.
Wir bezeichnen die Abrechnung untereinander als „Steuerungspanel“: Hier werden nicht nur Geld und Dienstleistungen verwaltet, sondern auch deren Unterstützung und vieles mehr.
Für den Übergang von der ISPSystem-Software war es notwendig, allen Kunden die vorherige Funktionalität vollständig zu bewahren, alle finanziellen Transaktionen der Nutzer von der alten in die neue Abrechnung zu übertragen sowie alle Dienstleistungen und Verbindungen zwischen ihnen. Wir haben untersucht, was im aktuellen Produkt vorhanden ist, dann Lösungen der Wettbewerber, hauptsächlich DO und Vultr, betrachtet. Wir schauten uns die Mängel und Vorteile an und sammelten Feedback von Personen, die mit den alten Produkten von ISPsystem gearbeitet haben.
In der neuen Abrechnungssystem haben wir zwei Stacks verwendet: klassisches PHP, MySQL (in Zukunft planen wir die Umstellung auf PostgreSQL), Yii2 als Backend-Framework und VueJS für das Frontend. Die Stacks arbeiten unabhängig voneinander, werden von verschiedenen Personen entwickelt und kommunizieren über eine JSON-API. Für die Entwicklung verwenden wir damals wie heute und von JetBrains und haben eine große Vorliebe für sie (Hallo Leute!)
Das Panel ist modular aufgebaut: Module für Zahlungssysteme, ein Modul für Domain-Registrar oder beispielsweise ein Modul für SSL-Zertifikate. Es ist einfach, eine neue Funktion hinzuzufügen oder eine alte zu entfernen. Die Architektur ist auf Erweiterungen ausgelegt, auch in umgekehrter Richtung, „zur Hardware“.
Was wir erhalten haben: ein Kontrollpanel, über das wir die volle Kontrolle haben. Jetzt werden Bugs in Stunden und nicht in Wochen behoben, und neue Funktionen werden auf Wunsch der Kunden und nicht nach dem Ermessen von ISPSystem umgesetzt.
Schritt 3. Benutzeroberfläche
Die Benutzeroberfläche ist unser gemeinsames Kind.
Zunächst haben wir untersucht, was passiert, wenn wir eine Überlagerung über die API von ISPsystem machen, ohne die Benutzeroberfläche grundlegend zu ändern. Das Ergebnis war eher mittelmäßig und wir haben beschlossen, alles von Grund auf neu zu gestalten.
Wir glaubten, das Wichtigste sei, eine logische Benutzeroberfläche mit einem klaren und minimalistischen Design zu schaffen, um ein ansprechendes Dashboard zu erhalten. Die Anordnung der Elemente diskutierten wir im Megaplan, und schrittweise entstand die Benutzeroberfläche, die die Nutzer jetzt im Control Panel sehen.
Zuerst entstand das Design der Abrechnungsseite, da wir bereits Zahlungs-Plugins für ISPsystem entwickelt hatten.
Frontend
Das Panel entschieden wir als SPA-Anwendung zu realisieren – ressourcenschonend und mit schneller Datenladezeit. Unser Frontend-Entwickler Artysh entschied sich, es mit Vue zu schreiben – zu diesem Zeitpunkt war Vue gerade erst erschienen. Wir gingen davon aus, dass sich das Framework dynamisch entwickeln würde, ähnlich wie React, und in naher Zukunft die Vue-Community wachsen sowie viele Bibliotheken entstehen würden. Wir setzten auf Vue und haben es nicht bereut – jetzt benötigt das Hinzufügen neuer Funktionen, die wir bereits im Backend programmiert haben, nur noch wenig Zeit. Mehr über das Frontend des Panels werden wir in einem separaten Artikel berichten.
Die Verbindung von Frontend und Backend
Wir verbanden das Frontend mit dem Backend über Push-Nachrichten. Es war nötig, einen eigenen Handler zu schreiben, doch nun geschieht die Aktualisierung der Informationen auf der Seite fast in Echtzeit.
Das Ergebnis: Die Benutzeroberfläche des Panels wurde vereinfacht. Wir haben sie responsiv gestaltet, sodass eine schnelle Ladezeit es ermöglicht, sie auch kurz vor dem Abflug von mobilen Geräten aus zu nutzen, ohne eine separate App für die Arbeit mit dem Panel installieren zu müssen.
Schritt 4. Testen und Migrationsschema
Nachdem alles eingerichtet war und die ersten Tests erfolgreich abgeschlossen wurden, stellte sich die Frage nach der Migration. Zunächst haben wir die Abrechnungssysteme eingerichtet und deren Funktionsweise mit dem Server-Agenten getestet.
Anschließend haben wir ein einfaches Skript erstellt, das die Datenbank aus dem alten Abrechnungssystem in das neue überträgt.
Wir mussten buchstäblich alles testen und überprüfen, da die Daten aus drei alten Systemen (Billmanager, VMmanager und IPmanager) in eine neue Datenbank zusammengeführt wurden. Die Testmigrationen waren vermutlich die größte Herausforderung, mit der wir während der Entwicklung des neuen Panels konfrontiert waren.
Nach den Überprüfungen haben wir die alte Abrechnung geschlossen. Die finale Datenmigration war ein sehr angespanntes Ereignis, verlief jedoch zum Glück innerhalb weniger Minuten und ohne nennenswerte Probleme. Es gab einige kleinere Bugs, die wir im Laufe der Woche behoben haben. Die meiste Zeit wurde für das Testen dessen benötigt, was wir erreicht haben.
Anschließend haben wir unseren Kunden die Adresse des neuen Panels und der Abrechnung mitgeteilt und eine Weiterleitung eingerichtet.
Ergebnis: ES LEBT!
Happy End
Von den ersten Stunden an, in denen unsere Software lief, haben wir alle Vorzüge des Wechsels erlebt. Der Code war vollständig unser eigener und hatte eine benutzerfreundliche Architektur, während die Benutzeroberfläche klar und logisch war.
Das erste Feedback nach dem Start des neuen Panels
Wir haben den Übergangsprozess im Dezember gestartet, kurz vor dem Neuen Jahr 2017, als die Auslastung am niedrigsten war, um den Übergang für die Kunden zu erleichtern – fast niemand arbeitet vor den Feiertagen.
Das Wichtigste, was wir mit unserem Systemwechsel erzielt haben (neben besserer Zuverlässigkeit und Benutzerfreundlichkeit), ist die Möglichkeit, schnell Funktionen für Schlüsselkunden hinzuzufügen – ihnen ein Gesicht und nicht den Rücken zu zeigen.
Wie geht es weiter?
Wir wachsen, die Menge an Daten, Kunden und Kundendaten wächst. Im Backend mussten wir einen Memcached-Server und zwei Queue-Manager mit verschiedenen Aufgaben hinzufügen. Im Frontend gibt es Caching und eigene Warteschlangen.
Natürlich hatten wir auch Abenteuer während der Entwicklung und der Komplexität des Produkts, zum Beispiel als wir HighLoad hinzugefügt haben.
Im nächsten Artikel werden wir darüber berichten, wie wir das Hi-CPU-Paket gestartet haben: über die Hardware, die Software, welche Herausforderungen wir gemeistert haben und was wir erreicht haben.
Quelle: habr.com
