Salut! Suntem «Tehnologii de Hosting» și acum 5 ani am lansat — primul hosting vds creat special pentru dezvoltatori. Ne străduim să-l facem la fel de convenabil ca DigitalOcean, dar cu suport în limba română, metode de plată și servere în România. Dar DigitalOcean nu înseamnă doar fiabilitate și preț, ci și servicii.
Software-ul de la ISPsystem s-a dovedit a fi o frână pe calea spre un serviciu excelent. Acum trei ani foloseam sistemul de facturare Billmanager și panoul de control al serverelor VMmanager și ne-am dat seama rapid că a oferi un serviciu de calitate fără panoul nostru este practic imposibil.
Cum ISPsystem a distrus confortul
Bugs
Nu puteam să reparăm bug-urile noi — de fiecare dată trebuia să scriem la suportul altora și să așteptăm. Rezolvarea oricărei probleme necesita reacția unei companii terțe.
Suportul de la ISPsystem răspundea rezonabil, dar soluțiile veneau doar după câteva versiuni, și nu întotdeauna și nu toate. Uneori, bug-urile critice erau reparate după câteva săptămâni. Trebuia să ne liniștim clienții, să ne cerem scuze și să așteptăm ca ISPsystem să rezolve bug-ul.
Amenințarea timpilor de nefuncționare
Actualizările puteau provoca timp de nefuncționare imprevizibil, care provocau erori noi.
Fiecare actualizare era o loterie: trebuia să închidem sistemul de facturare și să facem sacrificii zeilor actualizărilor — de câteva ori, actualizarea a provocat timp de nefuncționare de 10-15 minute. Administratorii noștri stăteau în expectație — niciodată nu știau cât va dura timpul de nefuncționare și nu puteau prezice când ISPsystem va decide să lanseze o nouă actualizare.
În a cincea generație a Billmanager-ului a devenit mai bine, dar pentru a accesa funcțiile necesare a fost necesară instalarea unei versiuni beta, care se actualiza săptămânal. Dacă ceva se strica, trebuia să dăm acces dezvoltatorilor terți pentru a repara ceva.
Interfața incomodă a panoului
Totul era împărțit în panouri diferite și gestionat din locuri diferite. De exemplu, clienții plăteau prin Billmanager, dar pentru a reporni sau reinstala VDS trebuiau să folosească VMManager. Angajații noștri trebuiau să comute între feronerie pentru a ajuta clientul, a verifica sarcina serverului său sau a vedea ce sistem de operare folosește.
O astfel de interfață consumă timp — atât al nostru, cât și al clienților. Într-o astfel de situație, nu poate fi vorba de confortul aferent DigitalOcean.
Cicluri scurte de viață cu actualizări frecvente ale API-ului
Am scris plugin-uri proprii — de exemplu, un plugin cu metode de plată suplimentare care nu există în VMManager.
În ultimii ani, VMManager a avut un ciclu de viață relativ scurt, iar în versiunile noi denumirile variabilelor sau funcțiilor din API s-au schimbat aleatoriu — ceea ce a rupt plugin-urile noastre. Suportul pentru versiunile mai vechi a fost rapid închis, și a trebuit să ne actualizăm.
Nu se poate extinde
Mai exact, se poate, dar extrem de ineficient. Limitările de licență nu permit modificarea codului sursă, se pot scrie doar plugin-uri. Maximul de plugin-uri este — câteva elemente de meniu, un wizard pas cu pas. ISPsystem este orientat spre universalitate, iar noi aveam nevoie de soluții specializate.
Astfel s-a maturizat decizia de a scrie propriul nostru panel. Ne-am stabilit obiectivele:
- A reacționa rapid la erori, bug-uri și a putea să le remediem singuri, fără a-l face pe client să aștepte.
- A modifica liber interfața conform fluxurilor de lucru și nevoilor clientului.
- A îmbunătăți utilizabilitatea printr-un design curat și clar.
Și am început dezvoltarea.
Arhitectura noului panel
Avem o echipă de dezvoltare autosuficientă, așa că panelul l-am scris noi înșine.
Principala muncă a fost realizată de trei ingineri — directorul tehnic Serghei a conceput arhitectura și a scris agentul de server, Alexei a realizat billing-ul, iar frontend-ul a fost construit de frontend-erul nostru Artyș.
Pasul 1. Agentul de server
Agentul de server este un server web pe Python, care gestionează biblioteca , care, la rândul ei, gestionează .
Agentul controlează toate serviciile de pe server: crearea, oprirea, ștergerea VDS-urilor, instalarea sistemelor de operare, modificarea parametrilor și așa mai departe prin biblioteca libvirt. La data publicării acestui articol, acesta are peste patruzeci de funcții diferite, pe care le completăm în funcție de sarcina și nevoile clientului.
Teoretic, libvirt ar fi putut fi gestionat direct din billing, dar acest lucru ar fi necesitat prea mult cod suplimentar și am decis să distribui aceste funcții între agent și billing — billing-ul face pur și simplu cereri agentului prin JSON API.
Agentul a fost primul lucru pe care l-am făcut, deoarece nu necesita nicio interfață și putea fi testat direct din consola serverului.
Ce ne-a adus agentul de server: A apărut un strat care simplifică viața tuturor — facturarea nu trebuie să transmită o mulțime de comenzi, ci doar să facă o solicitare. Apoi, agentul va face tot ce este necesar: de exemplu, va aloca spațiu pe disc și memorie RAM.
Pasul 2. Facturarea
Pentru dezvoltatorul nostru Alex, aceasta nu era prima sa interfață de administrare — Alex este de mult timp în hosting, așa că înțelege în general ce are nevoie clientul și ce îi trebuie furnizorului.
Noi numim facturarea între noi «panoul de control»: în el nu sunt doar bani și servicii, ci și gestionarea acestora, suport pentru clienți și multe altele.
Pentru a migra de la softul ISPSystem, a fost necesar să păstrăm complet funcționalitatea anterioară pentru clienți, să transferăm toate acțiunile financiare ale utilizatorilor din vechea facturare în nouă, precum și toate serviciile și conexiunile dintre ele. Am studiat ce există în produsul actual, apoi soluțiile competitorilor, în principal DO și Vultr. Am analizat defectele și avantajele, am adunat recenziile persoanelor care au lucrat cu vechile produse de la ISPsystem.
În noua facturare am folosit două stive: PHP clasic, MySQL (iar în viitor ne propunem să trecem la PostgreSQL), Yii2 ca framework pe backend și VueJS pe frontend. Stivele funcționează independent una de cealaltă, sunt dezvoltate de persoane diferite și comunică prin intermediul JSON API. Pentru dezvoltare, atunci și acum folosim și de la JetBrains și le iubim cu căldură (băieți, salut!)
Panoul este proiectat pe un principiu modular: module ale sistemelor de plată, modul pentru înregistratorii de domenii sau, de exemplu, modul pentru certificatele SSL. Este ușor să adăugăm o nouă funcție sau să eliminăm una veche. Extensibilitatea a fost arhitectural concepută, inclusiv în partea de «hardware».
Ce am obținut: un panou de control, asupra căruia avem control complet. Acum erorile sunt corectate în câteva ore, nu săptămâni, iar noile funcții sunt implementate la cererea clienților, nu după dorința ISPSystem.
Pasul 3. Interfața
Interfața este creația echipei noastre.
Mai întâi am verificat ce s-ar întâmpla dacă am face o extensie peste API-ul ISPsystem, fără a schimba radical interfața. Rezultatul a fost mediocre, așa că am decis să facem totul de la zero.
Am crezut că cel mai important este să facem interfața logică, cu un design curat și minimalist, iar apoi vom obține un panou frumos. Discuțiile despre amplasarea elementelor au avut loc în Megaplan și, treptat, a prins viață interfața pe care utilizatorii o văd acum în panoul de control.
Primul a apărut designul paginii de facturare, deoarece deja realizasem pluginuri pentru plăți pentru ISPsystem.
Frontend
Am decis să facem panoul o aplicație SPA — care nu consumă multe resurse și se încarcă rapid. Frontendul nostru, Artysh, a decis să-l scrie pe Vue — pe atunci Vue abia apăruse. Am presupus că framework-ul se va dezvolta dinamic, la fel ca React, și, după un timp, comunitatea Vue se va extinde, apărând o mulțime de biblioteci. Ne-am bazat pe Vue și nu am regretat — acum, adăugarea de noi funcții pe frontend, deja programate pe backend, necesită puțin timp. Vom vorbi mai multe despre frontendul panoului într-un articol separat.
Legătura dintre frontend și backend
Frontendul a fost conectat la backend prin push-uri. A fost nevoie de multă muncă pentru a scrie un handler propriu, dar acum actualizarea informațiilor pe pagină se face aproape instantaneu.
Ce a ieșit: interfața panoului a devenit mai simplă. Am făcut-o adaptivă, iar încărcarea rapidă permite utilizarea ei chiar și de pe telefoane mobile în ultimele minute înainte de decolare, fără a necesita instalarea unei aplicații separate pentru lucrul cu panoul.
Pasul 4. Testare și schema de migrare
Când totul a fost configurat și s-au efectuat primele teste, a fost ridicată problema migrației. Primul lucru pe care l-am făcut a fost să instalăm sistemul de facturare și să începem testarea funcționării sale cu agentul serverului.
Apoi am scris un script simplu care transferă baza de date din vechiul sistem de facturare în cel nou.
A fost necesar să testăm și să verificăm practic totul, deoarece datele au fost consolidate într-o nouă bază din trei vechi: Billmanager, VMmanager și IPmanager. Probabil, migrarea testelor a fost cea mai complicată parte cu care ne-am confruntat în procesul de dezvoltare a noului panou.
După verificări, am închis vechiul sistem de facturare. Migrarea finală a datelor a fost un moment foarte emoționant, dar, din fericire, s-a realizat în câteva minute și fără probleme notabile. Au fost mici bug-uri, pe care le-am corectat pe parcursul săptămânii. Timpul principal a fost ocupat de testarea a ceea ce am obținut.
Apoi am trimis e-mailuri clienților cu adresa noii panouri și facturării și am realizat redirecționarea.
În concluzie: E VIDA!
Sfârșit fericit
Din primele ore de funcționare a software-ului nostru, am simțit toate avantajele tranziției. Codul a fost complet al nostru și cu o arhitectură convenabilă, iar interfața - curată și logică.
Prima recenzie după lansarea noii panouri
Am început procesul de tranziție în decembrie, cu câteva zile înainte de Anul Nou 2017, când erau cele mai mici încărcări, pentru a face tranziția mai ușoară pentru clienți - aproape nimeni nu lucrează înainte de sărbători.
Ceea ce am obținut în urma tranziției la propriul nostru sistem (în afară de fiabilitatea și confortul general) a fost posibilitatea de a adăuga rapid funcționalitate pentru clienții cheie - a fi fața lor, nu spatele.
Ce urmează?
Creștem, crește volumul de date, clienții, datele clienților. A trebuit să adăugăm un server Memcached pe backend și doi manageri de cozi cu sarcini diferite. Pe frontend există caching și propriile cozi.
Desigur, am avut și aventuri pe măsură ce produsul s-a dezvoltat și s-a complicat, de exemplu, când am adăugat HighLoad.
În următorul articol, vom povesti cum am lansat planul Hi-CPU: despre hardware, software, ce sarcini am rezolvat și ce am obținut.
Sursa: habr.com
