Zdravo! Smo "Hosting Technologies" in smo začeli delovati pred 5 leti — prvo gostovanje vds, ustvarjeno posebej za razvijalce. Prizadevamo si, da bi bilo priročno, kot je DigitalOcean, vendar z rusko podporo, načini plačila in strežniki v Rusiji. Toda DigitalOcean nista le zanesljivost in cena, je tudi storitev.
Programska oprema ISPsystem se je izkazala za vrv, ki nam je zvezala roke na poti do kul storitve. Pred tremi leti smo uporabljali Billmanager billing in nadzorno ploščo strežnika VMmanager in hitro ugotovili, da je brez lastne nadzorne plošče skoraj nemogoče zagotoviti dobre storitve.
Kako je ISPsystem ubil udobje
Napake
Napake nismo mogli odpraviti sami - vsakič smo morali pisati podpori nekoga drugega in čakati. Rešitev kakršne koli težave je zahtevala odziv tretjega podjetja.
Podpora ISPsystem se je odzvala normalno, vendar so popravki prišli šele po nekaj izdajah, pa še to ne vedno in ne vseh. Včasih so bile kritične napake odpravljene več tednov. Stranke smo morali pomiriti, se opravičiti in počakati, da ISPsystem odpravi napako.
Nevarnost izpadov
Posodobitve lahko povzročijo nepredvidljive izpade, ki izzovejo nove napake.
Vsaka posodobitev je bila loterija: moral sem prikriti zaračunavanje in se žrtvovati bogovom posodobitev - nekajkrat je posodobitev povzročila izpad za 10-15 minut. Naši skrbniki so takrat sedeli na očeh - nikoli nismo vedeli, kako dolgo bo trajal izpad, in nismo mogli predvideti, kdaj se bo ISPsystem odločil izdati novo posodobitev.
V peti generaciji je bil Billmanager boljši, vendar sem moral za dostop do potrebnih funkcij namestiti beta, ki je bila že posodobljena vsak teden. Če se je kaj pokvarilo, sem moral dati dostop drugim razvijalcem, da so lahko kaj popravili.
Neprijeten vmesnik plošče
Vse je bilo razdeljeno na različne panele in nadzorovano z različnih krajev. Stranke so na primer plačevale prek Billmanagerja in so morale znova zagnati ali znova namestiti VDS v VMManagerju. Naše osebje je moralo tudi preklapljati med okni, da bi pomagalo stranki, preverilo obremenitev njegovega strežnika ali videlo, kateri OS uporablja.
Takšen vmesnik zahteva čas – tako naš kot naših strank. V takšni situaciji ni govora o kakršni koli udobju, kot je DigitalOcean.
Kratki življenjski cikli s pogostimi posodobitvami API-ja
Napisali smo svoje vtičnike – na primer vtičnik z dodatnimi načini plačila, ki jih ni v VMManagerju.
V zadnjih letih je imel VMManager razmeroma kratek življenjski cikel in v novih različicah so se lahko imena spremenljivk ali funkcij v API-ju poljubno spreminjala - to je pokvarilo naše vtičnike. Podpora za starejše različice je bila hitro opuščena in jo je bilo treba posodobiti.
Ni mogoče spreminjati
Natančneje, možno je, a izjemno neučinkovito. Licenčne omejitve vam ne dovoljujejo spreminjanja izvorne kode, pišete lahko le vtičnike. Največje število vtičnikov - nekaj elementov menija, čarovnik po korakih. Sistemi ISP so zasnovani za vsestranskost, vendar smo potrebovali specializirane rešitve.
Tako je dozorela odločitev, da napišem svojo ploščo. Postavili smo si cilje:
- Hitro se odzovite na napake, hrošče in jih lahko odpravite sami, ne da bi stranka čakala.
- Prosto spreminjajte vmesnik za poteke dela in potrebe strank.
- Povečajte uporabnost s čistim in razumljivim dizajnom.
In začeli smo z razvojem.
Nova arhitektura plošč
Imamo samooskrbno razvojno ekipo, zato smo ploščo napisali sami.
Glavno delo so opravili trije inženirji - tehnični direktor Sergey je zamislil arhitekturo in napisal strežniškega agenta, Alexey je zaračunaval, sprednji del pa je sestavil naš front-ender Artysh.
1. korak: Agent strežnika
Strežniški agent je spletni strežnik python, ki upravlja knjižnico , ki pa vlada .
Agent upravlja vse storitve na strežniku: ustvarjanje, zaustavitev, brisanje vd-jev, namestitev operacijskih sistemov, spreminjanje parametrov itd. prek knjižnice libvirt. V času objave članka je to več kot štirideset različnih funkcij, ki jih dopolnjujemo glede na nalogo in potrebe naročnika.
Teoretično bi lahko libvirt nadzorovali neposredno iz zaračunavanja, vendar je to zahtevalo preveč dodatne kode in odločili smo se, da te funkcije ločimo med agentom in zaračunavanjem - zaračunavanje posredniku preprosto posreduje zahteve prek API-ja JSON.
Agent je prva stvar, ki smo jo naredili, saj ni zahteval nobenega vmesnika in ga je bilo mogoče testirati neposredno iz strežniške konzole.
Kaj nam je dal agent strežnika: pojavila se je plast, ki vsem poenostavi življenje - za obračunavanje ni treba poslati celega kupa ukazov, ampak samo narediti zahtevo. In agent bo naredil vse, kar je potrebno: na primer, dodelil bo prostor na disku in RAM.
2. korak. Obračun
Za našega razvijalca Alexa to ni bila prva nadzorna plošča - Alex se že dolgo ukvarja z gostovanjem, zato je na splošno razumel, kaj potrebuje stranka in kaj potrebuje gostitelj.
Zaračunavanje med seboj imenujemo »nadzorna plošča«: ne vsebuje samo denarja in storitev, temveč tudi njihovo upravljanje, podporo strankam in še marsikaj.
Za prehod s programske opreme ISPSystem je bilo potrebno v celoti ohraniti prejšnje funkcionalnosti za stranke, prenesti vsa finančna dejanja uporabnikov iz starega obračuna v novega ter vse storitve in povezave med njimi. Preučevali smo, kaj je v trenutnem izdelku, nato rešitve konkurentov, predvsem DO in Vultr. Ogledali smo si slabosti in prednosti, zbrali povratne informacije ljudi, ki so delali s starimi izdelki ISPsystem.
Novo zaračunavanje je uporabilo dva sklada: klasični PHP, MySQL (v prihodnosti je predviden prehod na PostgreSQL), Yii2 kot ogrodje na zaledju in VueJS na sprednji strani. Skladi delujejo neodvisno drug od drugega, razvijajo jih različni ljudje in komunicirajo z uporabo API-ja JSON. Za razvoj nekoč in danes uporabljamo и iz JetBrains in jih imam neizmerno rad (hej fantje!)
Panel je zasnovan modularno: moduli plačilnega sistema, modul registrarja domen ali npr. modul SSL certifikata. Z lahkoto lahko dodate novo funkcijo ali odstranite staro. Temelji za širitev so postavljeni arhitekturno, tudi v obratni smeri, »k strojni opremi«.
Kaj smo dobili: nadzorna plošča, nad katero imamo popoln nadzor. Zdaj so napake odpravljene v urah, ne v tednih, nove funkcije pa so implementirane na zahtevo strank in ne na zahtevo ISPSystem.
3. korak Vmesnik
Vmesnik je plod naše ekipe.
Najprej smo pogledali, kaj bi se zgodilo, če bi naredili dodatek preko API-ja ISPsystem, ne da bi bistveno spremenili karkoli v vmesniku. Izkazalo se je tako in odločili smo se, da naredimo vse iz nič.
Verjeli smo, da je glavna stvar narediti vmesnik logičen, s čistim in minimalističnim dizajnom, in potem bomo dobili čudovito ploščo. Lokacija elementov je bila obravnavana v Megaplanu in vmesnik, ki ga uporabniki zdaj vidijo na nadzorni plošči, se bo postopoma rodil.
Prva se je pojavila zasnova obračunske strani, saj smo za ISPsystem že izdelali plačilne dodatke.
Frontend
Odločili so se, da bo panel SPA aplikacija – nezahtevna do virov in s hitrim nalaganjem podatkov. Naš front-ender Artysh se je odločil, da ga napiše na Vue — takrat se je Vue ravno pojavil. Predvidevali smo, da se bo okvir razvijal dinamično, tako kot React, čez nekaj časa bo skupnost Vue rasla in pojavilo se bo morje knjižnic. Stavili smo na Vue in ni nam bilo žal - zdaj potrebuje malo časa, da na sprednjo stran dodamo nove funkcije, ki so bile že programirane na zadnji strani. Več o sprednji plošči vam bomo povedali v ločenem članku.
Povezovanje frontenda z backendom
Sprednji del je bil povezan z zaledjem prek potisnih obvestil. Moral sem se prepotiti in napisati lastnega upravljalnika, zdaj pa so informacije na strani posodobljene skoraj v trenutku.
Kaj se je zgodilo: Vmesnik plošče je postal preprostejši. Naredili smo ga prilagodljivega, hitro nalaganje pa vam omogoča, da ga uporabljate tudi iz mobilnih telefonov v zadnjih minutah pred vzletom, ne da bi namestili ločeno aplikacijo za delo s ploščo.
Korak 4. Shema testiranja in migracije
Ko se je vse skupaj zagnalo in so opravili prvi testi, se je pojavilo vprašanje selitve. Najprej smo namestili billing in začeli testirati njegovo delovanje s strežniškim agentom.
Nato smo napisali preprosto skripto, ki bazo prenese iz starega obračuna v novega.
Moral sem testirati in ponovno preveriti dobesedno vse, saj so bili podatki združeni v eno novo bazo iz treh starih: Billmanager, VMmanager in upraviteljev IPmanager. Morda so testne migracije najtežja stvar, s katero smo se srečali v procesu razvoja nove plošče.
Po ponovnem pregledu smo stari obračun zaprli. Končna migracija podatkov je bila zelo mučen trenutek, a je bila, hvala bogu, zaključena v nekaj minutah in brez opaznih težav. Prišlo je do manjših napak, ki smo jih odpravili med tednom. Večino časa smo porabili za testiranje, kaj se je zgodilo.
Nato smo strankam poslali dopise z naslovom novega panela in obračunom ter naredili preusmeritev.
Če povzamemo: ŽIVO JE!
Srečen konec
Od prvih ur dela naše programske opreme smo občutili vse užitke prehoda. Koda je bila popolnoma naša in s priročno arhitekturo, vmesnik pa čist in logičen.
Prvi pregled po lansiranju nove plošče
Prehod smo začeli decembra, na pragu novega leta 2017, ko je bila obremenitev najmanjša, da bi strankam olajšali prehod - na predpraznični dan skoraj nihče ne dela.
Glavna stvar, ki smo jo dobili ob prehodu na naš sistem (poleg splošne zanesljivosti in udobja), je možnost hitrega dodajanja funkcionalnosti za ključne stranke - biti njihov obraz, ne njihov rit.
Kaj sledi?
Rastemo, raste količina podatkov, strank, podatkov o strankah. V zaledje sem moral dodati strežnik Memcached in dva upravitelja čakalnih vrst z različnimi nalogami. Frontend ima predpomnjenje in lastne čakalne vrste.
Seveda smo imeli še vedno dogodivščine, ko se je izdelek razvijal in postajal kompleksnejši, na primer, ko smo dodali HighLoad.
V naslednjem članku vam bomo povedali, kako je bila uvedena tarifa Hi-CPU: o strojni opremi, programski opremi, katere naloge smo rešili in kaj smo počeli.
Vir: www.habr.com