Hej! Vi er «Hosting teknologi», og for 5 år siden lancerede vi — den første vds hosting, der er skabt specifikt til udviklere. Vi stræber efter at gøre det så brugervenligt som DigitalOcean, men med dansk support, betalingsmetoder og servere i Danmark. Men DigitalOcean er ikke kun pålidelighed og pris, det handler også om service.
Softwaren fra ISPsystem viste sig at være en snare, der bandt vores hænder i vores stræben efter en fantastisk service. For tre år siden brugte vi billingsystemet Billmanager og serverstyringspanelet VMmanager, og vi lærte hurtigt, at det er næsten umuligt at levere god service uden vores eget panel.
Hvordan ISPsystem ødelagde brugervenligheden
Bugs
Vi kunne ikke selv rette bugs — hver gang måtte vi kontakte en ekstern support og vente. At løse ethvert problem krævede reaktion fra et tredje selskab.
Supporten fra ISPsystem svarede ok, men rettelserne kom ofte først gennem flere versioner, og ikke altid og ikke alle. Nogle kritiske bugs blev rettet efter flere uger. Vi måtte berolige kunderne, undskylde, og vente på, at ISPsystem retter bug'en.
Trussel mod nedetid
Opdateringer kunne forårsage uforudsigelig nedetid, hvilket udløste nye fejl.
Hver opdatering var et lotteri: vi måtte lukke billingen og ofre os til opdateringsguderne — et par gange forårsagede en opdatering 10-15 minutters nedetid. Vores administratorer sad frustreret og vidste aldrig, hvor længe nedetiden ville vare, og vi kunne ikke forudsige, hvornår ISPsystem ville beslutte at udsende en ny opdatering.
Det blev bedre med femte generation af Billmanager, men for at få adgang til de nødvendige funktioner måtte vi installere betaversionen, som blev opdateret hver uge. Hvis noget gik i stykker, måtte vi give adgang til eksterne udviklere for at få dem til at rette det.
Upraktisk grænseflade til panelet
Alt var opdelt i forskellige paneler og blev styret fra forskellige steder. For eksempel betalte kunderne gennem Billmanager, men de måtte genstarte eller geninstallere VDS i VMManager. Vores medarbejdere måtte også skifte mellem vinduer for at hjælpe klienten, tjekke belastningen på deres server eller se, hvilken OS de bruger.
Sådan en grænseflade tager tid — både vores og kundernes. Der er slet ikke tale om nogen form for brugervenlighed som hos DigitalOcean under sådanne forhold.
Korte livscykler med hyppige API-opdateringer
Vi har udviklet vores egne plugins - for eksempel et plugin med yderligere betalingsmetoder, som ikke findes i VMManager.
I de seneste år har VMManager haft en relativt kort livscyklus, og i de nye versioner kunne navne på variabler eller funktioner i API'et ændre sig vilkårligt - hvilket brød vores plugins. Supports for gamle versioner blev hurtigt udfaset, og vi måtte opdatere.
Det kan ikke forbedres
Nærmere bestemt kan det, men det er ekstremt ineffektivt. Licensbegrænsningerne tillader ikke ændringer i kildekoden, man kan kun skrive plugins. Maksimalt antal plugins er nogle menupunkter, en trin-for-trin vejledning. ISPsystem er designet til alsidighed, men vi havde brug for specialiserede løsninger.
Så vi gik i gang med at skrive vores egen kontrolpanel. Vi satte os mål:
- Hurtigt reagere på fejl og problemer og have mulighed for selv at løse dem, uden at kunden skal vente.
- Frit kunne modificere grænsefladen til arbejdsprocesser og kundens behov.
- Forbedre brugervenligheden med et rent og forståeligt design.
Og vi begyndte udviklingen.
Arkitekturen af det nye panel
Vi har et selvstændigt udviklingsteam, så vi har skrevet panelet selv.
Det primære arbejde blev udført af tre ingeniører - teknisk direktør Sergey fandt på arkitekturen og skrev serveragenten, Alexey lavede billing, mens vores frontend-udvikler Artysh samlede frontend-delen.
Trin 1. Serveragent
Serveragenten er en webserver skrevet i Python, der styrer biblioteket , som i sin tur styrer .
Agenten styrer alle tjenester på serveren: oprettelse, stop, sletning af VDS, installation af operativsystemer, ændring af parametre osv. gennem biblioteket libvirt. På tidspunktet for artikelens offentliggørelse er der mere end fyrre forskellige funktioner, som vi supplerer alt efter opgaven og kundens behov.
I teorien kunne man styre libvirt direkte fra billing, men det ville kræve for meget ekstra kode, så vi besluttede at dele disse funktioner mellem agenten og billing - billing sender simpelthen anmodninger til agenten gennem JSON API.
Agenten var det første, vi lavede, da den ikke krævede nogen grænseflade, og vi kunne teste den direkte fra serverens konsol.
Hvad serveragenten gav os: Der er opstået et lag, der gør livet lettere for alle – faktureringen behøver ikke at overføre en masse kommandoer, men kun sende en forespørgsel. Og agenten vil gøre alt, hvad der er nødvendigt: for eksempel tildele plads på disken og RAM.
Trin 2. Fakturering
For vores udvikler Alex var dette ikke første gang, han brugte et kontrolpanel – Alex har været i hostingbranchen længe, så han forstod generelt, hvad kunden havde brug for, og hvad der var nødvendigt for hosten.
Vi kalder faktureringen for 'kontrolpanelet': det indeholder ikke bare penge og tjenester, men også styring af dem, kundesupport og meget mere.
For at overføre fra ISPSystem-software var det nødvendigt fuldstændigt at bevare tidligere funktionalitet for kunderne, overføre alle finansielle handlinger fra det gamle faktureringssystem til det nye, samt alle tjenester og forbindelser imellem. Vi studerede, hvad der er i det nuværende produkt, derefter løsninger fra konkurrenter, hovedsageligt DO og Vultr. Vi kiggede på mangler og fordele, indsamlede anmeldelser fra folk, der har arbejdet med gamle produkter fra ISPsystem.
I det nye faktureringssystem brugte vi to stacks: klassisk PHP, MySQL (og i fremtiden planlægges det at skifte til PostgreSQL), Yii2 som backend-ramme og VueJS på frontenden. Stacks arbejder uafhængigt af hinanden, udvikles af forskellige mennesker, og kommunikerer via JSON API. Vi bruger stadig og har brugt til udvikling og fra JetBrains og holder dem meget af (hej, folkens!)
Panelet er designet på en modulær måde: moduler til betalingssystemer, moduler til domæneregistratorer eller for eksempel modul til SSL-certifikater. Det er nemt at tilføje en ny funktion eller fjerne en gammel. Der er arkitektonisk plads til udvidelse, også i modsatte retning, 'til hardwaren'.
Hvad vi har opnået: et kontrolpanel, som vi har fuld kontrol over. Nu rettes fejl på timer og ikke uger, og nye funktioner implementeres på kunders anmodning, og ikke efter ISPSystems ønsker.
Trin 3. Interface
Interface – vores fælles skabelsesværk.
Først så vi på, hvad der ville ske, hvis vi lavede et overlay over ISPsystems API, uden at ændre noget væsentligt i interface. Resultatet var ikke tilfredsstillende, så vi besluttede at bygge det hele fra bunden.
Vi troede, at det vigtigste var at lave et logisk interface med et rent og minimalistisk design, og så ville vi få et smukt panel. Placeringen af elementerne blev diskuteret i Megaplan, og gradvist blev det interface til, som brugerne ser i kontrolpanelet nu.
Først kom designet af billing-siden, da vi allerede havde lavet betalingsplugins til ISPsystem.
Frontend
Vi besluttede at lave panelet som en SPA-applikation — ressourcekrævende og med hurtig dataloading. Vores frontend-udvikler Artysh valgte at skrive det i Vue — på det tidspunkt var Vue kun lige kommet frem. Vi antog, at rammeværket ville udvikle sig dynamisk som React, og efter noget tid ville Vue-fællesskabet vokse, og der ville komme en masse biblioteker. Vi satsede på Vue og har ikke fortrudt det — nu tager det lidt tid at tilføje nye funktioner på frontenden, som allerede er programmeret på backend. Vi vil fortælle mere om frontend-panelet i en separat artikel.
Forbindelse mellem frontend og backend
Frontend var forbundet med backend via push-notifikationer. Vi måtte arbejde hårdt og skrive vores egen handler, men nu opdateres informationerne på siden næsten øjeblikkeligt.
Hvad der kom ud af det: grænsefladen til panelet blev enklere. Vi gjorde den responsiv, og den hurtige indlæsning gør det muligt at bruge den selv fra mobiltelefoner i de sidste minutter før takeoff, uden at installere en separat applikation til at arbejde med panelet.
Trin 4. Testning og migrationsplan
Da alt var sat op, og de første tests var gennemført, opstod spørgsmålet om migration. Først installerede vi billing og begyndte at teste dets arbejde med serveragenten.
Derefter skrev vi et simpelt script, der overfører databasen fra den gamle billing til den nye.
Vi måtte teste og genchecke bogstaveligt talt alt, da dataene blev overført til en ny database fra tre gamle: Billmanager, VMmanager og IPmanager manager. Måske var testmigreringer det sværeste, vi stod over for i udviklingsprocessen af det nye panel.
Efter gencheckene lukkede vi den gamle billing. Den endelige migrationsdata var et meget nervepirrende øjeblik, men heldigvis blev den udført på få minutter og uden synlige problemer. Der var små fejl, som vi rettede i løbet af en uge. Det meste af tiden gik med at teste, hvad der blev til.
Derefter sendte vi e-mails til kunderne med adressen på den nye panel og fakturering og lavede en omdirigering.
I sidste ende: DET ER LIVE!
Happy end
Fra de første timer af arbejdet med vores software følte vi alle fordelene ved overgangen. Koden var helt vores med en brugervenlig arkitektur, og brugergrænsefladen var ren og logisk.
Første anmeldelse efter lanceringen af det nye panel
Vi startede overgangen i december, dagen før det nye år 2017, da belastningen var lavest for at gøre overgangen lettere for kunderne - næsten ingen arbejdede dagen før ferien.
Det vigtigste, vi fik ved overgangen til vores system (udover generel pålidelighed og brugervenlighed) - muligheden for hurtigt at tilføje funktionaliteter til nøglekunder - at være ansigtet udadtil, ikke bagsiden.
Hvad nu?
Vi vokser, mængden af data, kunder og kundedata vokser. På backend måtte vi tilføje en Memcached-server og to køadministratorer med forskellige opgaver. På frontend er der caching og egne køer.
Selvfølgelig havde vi også eventyr undervejs, da vi udviklede og komplicerede produktet, for eksempel da vi tilføjede HighLoad.
I den næste artikel vil vi fortælle, hvordan vi lancerede Hi-CPU planen: om hardware, software, hvilke opgaver vi løste, og hvad vi opnåede.
Kilde: habr.com
