Hallo! Wir sind „Hosting Technologies“ und wurden vor 5 Jahren gegründet – das erste VDS-Hosting, das speziell für Entwickler entwickelt wurde. Wir streben danach, es bequem zu machen, wie DigitalOcean, aber mit russischem Support, Zahlungsmethoden und Servern in Russland. Aber DigitalOcean ist nicht nur Zuverlässigkeit und Preis, sondern auch ein Service.
Die Software von ISPsystem erwies sich als Seil, das uns die Hände auf dem Weg zu einem coolen Service fesselte. Vor drei Jahren haben wir Billmanager Billing und das VMmanager Server Control Panel genutzt und schnell gemerkt, dass es ohne unser eigenes Control Panel fast unmöglich ist, einen guten Service zu bieten.
Wie das ISP-System die Bequemlichkeit zunichte machte
Käfer
Wir konnten den Fehler nicht selbst beheben – jedes Mal mussten wir den Support eines anderen anschreiben und warten. Die Lösung jedes Problems erforderte die Reaktion eines Drittunternehmens.
Der ISP-Systemsupport reagierte normal, aber Korrekturen kamen erst nach einigen Veröffentlichungen und dann nicht immer und nicht bei allen. Manchmal wurden kritische Fehler mehrere Wochen lang behoben. Wir mussten die Kunden beruhigen, uns entschuldigen und darauf warten, dass ISPsystem den Fehler behebt.
Bedrohung durch Ausfallzeiten
Updates könnten zu unvorhersehbaren Ausfallzeiten führen, die neue Fehler provozieren.
Jedes Update war eine Lotterie: Ich musste die Abrechnung vertuschen und den Göttern der Updates Opfer bringen – ein paar Mal verursachte das Update eine Ausfallzeit von 10 bis 15 Minuten. Unsere Administratoren saßen zu diesem Zeitpunkt untätig da – wir wussten nie, wie lange die Ausfallzeit dauern würde und konnten nicht vorhersagen, wann ISPsystem sich für die Veröffentlichung eines neuen Updates entscheiden würde.
Auf der fünften Generation wurde Billmanager besser, aber um Zugriff auf die notwendigen Funktionen zu erhalten, musste ich eine Beta installieren, die bereits jede Woche aktualisiert wurde. Wenn etwas kaputt ging, musste ich anderen Entwicklern Zugriff gewähren, damit sie etwas reparieren konnten.
Unbequeme Panel-Schnittstelle
Alles wurde in verschiedene Panels unterteilt und von verschiedenen Orten aus gesteuert. Beispielsweise zahlten Kunden über Billmanager, mussten aber VDS in VMManager neu starten oder neu installieren. Unsere Mitarbeiter mussten auch zwischen Fenstern wechseln, um einem Kunden zu helfen, die Auslastung seines Servers zu überprüfen oder zu sehen, welches Betriebssystem er verwendete.
Eine solche Schnittstelle braucht Zeit – sowohl unsere als auch die unserer Kunden. Von einer Bequemlichkeit wie bei DigitalOcean kann in einer solchen Situation keine Rede sein.
Kurze Lebenszyklen mit häufigen API-Updates
Wir haben unsere eigenen Plugins geschrieben – zum Beispiel ein Plugin mit zusätzlichen Zahlungsmethoden, die nicht in VMManager enthalten sind.
In den letzten Jahren hatte VMManager einen relativ kurzen Lebenszyklus und in neuen Versionen konnten sich die Namen von Variablen oder Funktionen in der API willkürlich ändern – das hat unsere Plugins kaputt gemacht. Der Support für ältere Versionen wurde schnell eingestellt und musste aktualisiert werden.
Kann nicht geändert werden
Genauer gesagt ist es möglich, aber äußerst ineffizient. Lizenzbeschränkungen erlauben es Ihnen nicht, Änderungen am Quellcode vorzunehmen, Sie können nur Plugins schreiben. Maximale Plugins – einige Menüpunkte, ein Schritt-für-Schritt-Assistent. ISP-Systeme sind auf Vielseitigkeit ausgelegt, wir brauchten jedoch spezielle Lösungen.
Daher war die Entscheidung reif, mein eigenes Panel zu schreiben. Wir haben uns Ziele gesetzt:
- Reagieren Sie schnell auf Fehler und Bugs und können Sie diese selbst beheben, ohne dass der Kunde warten muss.
- Passen Sie die Benutzeroberfläche frei an Arbeitsabläufe und Kundenanforderungen an.
- Erhöhen Sie die Benutzerfreundlichkeit mit einem klaren und verständlichen Design.
Und wir haben mit der Entwicklung begonnen.
Neue Panel-Architektur
Da wir über ein eigenständiges Entwicklungsteam verfügen, haben wir das Panel selbst geschrieben.
Die Hauptarbeit wurde von drei Ingenieuren geleistet – der technische Direktor Sergey entwarf die Architektur und schrieb den Serveragenten, Alexey erledigte die Abrechnung und das Front-End wurde von unserem Front-Ender Artysh zusammengestellt.
Schritt 1: Server-Agent
Der Serveragent ist ein Python-Webserver, der die Bibliothek verwaltet , die wiederum regiert .
Der Agent verwaltet alle Dienste auf dem Server: Erstellen, Stoppen, Löschen von VDS, Installieren von Betriebssystemen, Ändern von Parametern usw. über die libvirt-Bibliothek. Zum Zeitpunkt der Veröffentlichung des Artikels handelt es sich um mehr als vierzig verschiedene Funktionen, die wir je nach Aufgabenstellung und Bedarf des Kunden ergänzen.
Theoretisch könnte libvirt direkt über die Abrechnung gesteuert werden, aber dafür war zu viel zusätzlicher Code erforderlich, und wir haben uns entschieden, diese Funktionen zwischen dem Agenten und der Abrechnung zu trennen – die Abrechnung stellt lediglich Anfragen an den Agenten über die JSON-API.
Der Agent war das erste, was wir gemacht haben, da er keine Schnittstelle benötigte und es möglich war, ihn direkt von der Serverkonsole aus zu testen.
Was uns der Serveragent gegeben hat: Es ist eine Ebene entstanden, die das Leben für alle vereinfacht – die Abrechnung muss nicht eine ganze Reihe von Befehlen senden, sondern nur eine Anfrage stellen. Und der Agent erledigt alles Notwendige: Er weist beispielsweise Speicherplatz und RAM zu.
Schritt 2. Abrechnung
Für unseren Entwickler Alex war dies nicht das erste Control Panel – Alex war schon lange im Hosting tätig, daher verstand er im Allgemeinen, was der Kunde brauchte und was der Hoster brauchte.
Wir bezeichnen die Abrechnung untereinander als „Kontrollpanel“: Sie enthält nicht nur Geld und Leistungen, sondern auch deren Verwaltung, Kundenbetreuung und vieles mehr.
Um von der ISPSystem-Software zu wechseln, war es notwendig, die bisherige Funktionalität für Kunden vollständig beizubehalten, alle finanziellen Aktionen der Benutzer von der alten Abrechnung auf die neue zu übertragen sowie alle Dienste und Verbindungen zwischen ihnen. Wir haben untersucht, was im aktuellen Produkt enthalten ist, dann die Lösungen der Wettbewerber, hauptsächlich DO und Vultr. Wir haben uns die Nachteile und Vorteile angesehen und Feedback von Leuten gesammelt, die mit alten Produkten von ISPsystem gearbeitet haben.
Die neue Abrechnung verwendete zwei Stacks: klassisches PHP, MySQL (und in Zukunft ist die Umstellung auf PostgreSQL geplant), Yii2 als Framework im Backend und VueJS auf der Vorderseite. Stacks funktionieren unabhängig voneinander, werden von verschiedenen Personen entwickelt und kommunizieren über die JSON-API. Für die Entwicklung damals und heute verwenden wir и von JetBrains und ich liebe sie sehr (hey Leute!)
Das Panel ist modular aufgebaut: Zahlungssystemmodule, Domain-Registrar-Modul oder beispielsweise ein SSL-Zertifikatsmodul. Sie können ganz einfach eine neue Funktion hinzufügen oder eine alte entfernen. Die Weichen für den Ausbau werden architektonisch gestellt, auch in umgekehrter Richtung, „hin zur Hardware“.
Was wir haben: ein Bedienfeld, über das wir die volle Kontrolle haben. Jetzt werden Fehler innerhalb von Stunden und nicht mehr in Wochen behoben, und neue Funktionen werden auf Wunsch der Kunden und nicht auf Wunsch von ISPSystem implementiert.
Schritt 3 Schnittstelle
Die Schnittstelle ist eine Idee unseres Teams.
Zuerst haben wir uns angesehen, was passieren würde, wenn wir ein Add-on über die ISPsystem-API erstellen würden, ohne etwas an der Schnittstelle grundlegend zu ändern. Es lief so lala und wir beschlossen, alles von Grund auf neu zu machen.
Wir waren davon überzeugt, dass es vor allem darauf ankommt, die Benutzeroberfläche logisch zu gestalten, mit einem klaren und minimalistischen Design, und dann erhalten wir ein schönes Panel. Die Position der Elemente wurde in Megaplan besprochen und die Benutzeroberfläche, die Benutzer jetzt im Bedienfeld sehen, wird nach und nach entstehen.
Das Design der Abrechnungsseite erschien als erstes, da wir bereits Zahlungs-Plugins für ISPsystem erstellt haben.
Frontend
Sie beschlossen, das Panel zu einer SPA-Anwendung zu machen – ressourcenschonend und mit schnellem Datenladen. Unser Front-Ender Artysh beschloss, es auf Vue zu schreiben – zu diesem Zeitpunkt war Vue gerade erst erschienen. Wir gingen davon aus, dass sich das Framework wie React dynamisch entwickeln würde, nach einiger Zeit würde die Vue-Community wachsen und ein Meer von Bibliotheken erscheinen. Wir haben auf Vue gesetzt und es nicht bereut – jetzt dauert es nur noch wenig Zeit, neue Funktionen im Frontend hinzuzufügen, die bereits im Backend programmiert wurden. Mehr zum Frontend-Panel erzählen wir Ihnen in einem separaten Artikel.
Verbindung des Frontends mit dem Backend
Das Frontend wurde über Push-Benachrichtigungen mit dem Backend verbunden. Ich musste hart arbeiten und meinen eigenen Handler schreiben, aber jetzt werden die Informationen auf der Seite fast sofort aktualisiert.
Was ist passiert: Die Panel-Schnittstelle ist einfacher geworden. Wir haben es anpassungsfähig gemacht und das schnelle Laden ermöglicht es Ihnen, es in den letzten Minuten vor dem Start sogar von Mobiltelefonen aus zu verwenden, ohne eine separate Anwendung für die Arbeit mit dem Panel installieren zu müssen.
Schritt 4. Test- und Migrationsschema
Als alles in Gang kam und die ersten Tests bestanden, stellte sich die Frage der Migration. Zunächst haben wir die Abrechnung installiert und begonnen, ihren Betrieb mit dem Serveragenten zu testen.
Dann haben wir ein einfaches Skript geschrieben, das die Datenbank von der alten Abrechnung auf die neue überträgt.
Ich musste buchstäblich alles testen und erneut überprüfen, da die Daten aus drei alten in einer neuen Datenbank zusammengeführt wurden: Billmanager, VMmanager und dem IPmanager des Managers. Die Testmigrationen sind vielleicht das Schwierigste, was uns bei der Entwicklung eines neuen Panels begegnet ist.
Nach erneuter Prüfung haben wir die alte Abrechnung geschlossen. Die abschließende Datenmigration war ein sehr beunruhigender Moment, aber Gott sei Dank wurde sie in wenigen Minuten und ohne nennenswerte Probleme abgeschlossen. Es gab kleinere Fehler, die wir im Laufe der Woche behoben haben. Die meiste Zeit wurde damit verbracht, zu testen, was passiert ist.
Dann haben wir den Kunden Briefe mit der Adresse des neuen Panels und der Rechnung geschickt und eine Weiterleitung vorgenommen.
Zusammengefasst: ES LEBT!
Glückliches Ende
Schon in den ersten Betriebsstunden unserer Software spürten wir alle Freuden des Übergangs. Der Code war vollständig von uns und hatte eine praktische Architektur, und die Benutzeroberfläche war sauber und logisch.
Erster Rückblick nach dem Start des neuen Panels
Wir haben den Übergangsprozess im Dezember, am Vorabend des neuen Jahres 2017, gestartet, als die Belastung am geringsten war, um den Kunden den Übergang zu erleichtern – am Vorabend der Feiertage arbeitet fast niemand.
Das Wichtigste, was wir bei der Umstellung auf unser System erreicht haben (abgesehen von der allgemeinen Zuverlässigkeit und Bequemlichkeit), ist die Möglichkeit, schnell Funktionen für wichtige Kunden hinzuzufügen – um ihr Gesicht zu sein, nicht ihr Arsch.
Was kommt als nächstes?
Wir wachsen, die Menge an Daten, Kunden, Kundendaten wächst. Ich musste dem Backend einen Memcached-Server und zwei Warteschlangenmanager mit unterschiedlichen Aufgaben hinzufügen. Das Frontend verfügt über Caching und eigene Warteschlangen.
Natürlich erlebten wir immer noch Abenteuer, als sich das Produkt weiterentwickelte und komplexer wurde, zum Beispiel als wir HighLoad hinzufügten.
Im nächsten Artikel erzählen wir Ihnen, wie der Hi-CPU-Tarif eingeführt wurde: über Hardware, Software, welche Aufgaben wir gelöst haben und was wir getan haben.
Source: habr.com