Helló! Mi vagyunk a "Hosting Technologies" és 5 évvel ezelőtt indítottuk el — az első VDS tárhelyszolgáltatás, amit kifejezetten fejlesztők számára készítettek. Célunk, hogy olyan kényelmes legyen, mint a DigitalOcean, de orosz nyelvű támogatással, fizetési módokkal és orosz szerverekkel. A DigitalOcean azonban nemcsak megbízhatóságot és árat jelent, hanem szolgáltatást is.
Az ISPsystem szoftvere olyan kötélszerű akadályként hatott, amely megkötötte a kezünket a kiváló szolgáltatás elérésének útján. Három évvel ezelőtt a Billmanager számlázást és a VMmanager szerverkezelő panelt használtuk, és gyorsan rájöttünk, hogy jó szolgáltatást nyújtani gyakorlatilag lehetetlen a saját panel nélkül.
Hogyan akadályozta meg az ISPsystem a kényelmet
Hibák
Nem tudtuk saját magunk javítani a hibákat — mindig idegen támogatást kellett kérnünk, és várni. Bármilyen probléma megoldása egy harmadik cég reakcióját igényelte.
Az ISPsystem támogatása elfogadhatóan válaszolt, de a javítások csak néhány kiadás után érkeztek, és nem mindig, és nem mind. Néha kritikus hibák javítása hetekbe telt. Meg kellett nyugtatnunk az ügyfeleinket, elnézést kellett kérnünk, és várnunk kellett, amíg az ISPsystem kijavítja a hibát.
A leállások fenyegetése
A frissítések előre nem látható leállásokat okozhattak, amelyek új hibákat provokáltak.
Minden frissítés olyan volt, mint egy lottó: le kellett zárnunk a számlázást és áldozatokat kellett hoznunk a frissítések isteneinek — néhányszor a frissítés 10-15 perces leállást okozott. Adminisztrátoraink ilyenkor a szemünk előtt idegeskedtek — sosem tudtuk, mennyi ideig tart a leállás, és nem tudtuk megjósolni, mikor dönt úgy az ISPsystem, hogy kiad egy új frissítést.
Az ötödik generációs Billmanager valamivel jobb lett, de hogy hozzáférjünk a szükséges funkciókhoz, bétaverziót kellett telepítenünk, ami már heti frissítéseket kapott. Ha valami elromlott, idegen fejlesztőknek kellett hozzáférést biztosítanunk, hogy javítani tudják.
A panel kényelmetlen felülete
Minden rész külön panelekbe volt osztva, és különböző helyekről irányították. Például az ügyfelek a Billmanageren keresztül fizettek, míg a VDS-t újraindítani vagy újratelepíteni kellett a VMManagerben. Dolgozóinknak is váltogatniuk kellett az ablakok között, hogy segítsenek az ügyfeleknek, ellenőrizzék a leterheltséget a szerverükön vagy megnézzék, melyik operációs rendszert használják.
Ez a felület időt rabol — mind a miénkből, mind az ügyfelekéből. A DigitalOcean-szerű kényelemről ilyen helyzetben szó sem lehet.
Rövid életciklusok a gyakori API-frissítésekkel
Saját bővítményeket írtunk — például egy bővítményt, amely további fizetési módszereket kínál, amelyek nem találhatók a VMManagerben.
Az utóbbi években a VMManager viszonylag rövid élettartama volt, és az új verziókban véletlenszerűen változhattak az API változók vagy funkciók nevei — ez tönkretette a bővítményeinket. A régi verziók támogatását gyorsan megszüntették, és frissítenünk kellett.
Nem lehet továbbfejleszteni.
Pontosabban lehet, de rendkívül hatástalan. A licencszerződések nem teszik lehetővé a forráskód módosítását, csak bővítményeket lehet írni. A bővítmények maximális száma — néhány menüelem, lépésről lépésre mester. Az ISPsystem általános megoldásokra épül, míg nekünk speciális megoldásokra volt szükségünk.
Így jutottunk el arra a döntésre, hogy saját panelt írjunk. Célokat tűztünk ki:
- Gyorsan reagálni a hibákra, bugokra, és képesek legyenek önállóan megszüntetni őket, nem kényszerítve a ügyfelet a várakozásra.
- Szabadon módosítani az interfészt a munkafolyamatok és az ügyfél igényeihez.
- Növelni a használhatóságot tiszta és érthető dizájnnal.
És megkezdtük a fejlesztést.
Az új panel architektúrája
Van egy önálló fejlesztőcsapatunk, így a panelt magunk írtuk.
A legfőbb munkát három mérnök végezte — a műszaki igazgató, Szergej, kitalálta az architektúrát és megírta a szerver ügynököt, Alexej elkészítette a billinget, míg a frontendot Artys állította össze.
1. lépés. Szerverügynök
A szerverügynök egy Python alapú webszerver, amely kezeli a könyvtárat, , amely viszont kezeli .
Az ügynök minden szolgáltatást kezel a szerveren: vds-ek létrehozása, leállítása, törlése, operációs rendszerek telepítése, paraméterek módosítása és így tovább a libvirt könyvtáron keresztül. A cikk megjelenésekor ez több mint negyven különböző funkciót jelent, amelyeket az ügyfél igényei és feladatok függvényében bővítünk.
Elvileg a libvirt-t közvetlenül a billingből is lehetett volna kezelni, de ez túl sok további kódot igényelt, ezért úgy döntöttünk, hogy ezeket a funkciókat az ügynök és a billing között elválasztjuk — a billing egyszerűen JSON API-n keresztül kérdéseket intéz az ügynökhöz.
Az ügynök volt az első, amit elkészítettünk, mivel nem igényelt semmilyen interfészt, és közvetlenül a szerver konzoljáról is tesztelhető volt.
Mit adott nekünk a szerverügynök: Megjelent egy réteg, amely megkönnyíti az életet mindenkinek - a billingnek nem kell egy halom parancsot átadnia, csak egy kérést kell tennie. Az ügynök mindent elintéz: például helyet foglal a lemezen és a RAM-ban.
2. lépés. Billing
Számunkra Alex már nem az első vezérlőpult – Alex régóta a hostingban dolgozik, így nagyjából tudta, mire van szüksége az ügyfélnek és a hosting szolgáltatónak.
A billinget magunk között "vezérlőpultnak" nevezzük: nemcsak pénz és szolgáltatások találhatók benne, hanem azok kezelése, ügyféltámogatás és sok más.
Az ISPSystem szoftverről való áttéréshez teljes mértékben meg kellett őriznünk az ügyfelek korábbi funkcióit, átvinni az összes pénzügyi tranzakciót az új billinghez, valamint az összes szolgáltatást és azok közötti kapcsolatokat. Megvizsgáltuk, hogy mi áll rendelkezésre a jelenlegi termékben, majd az konkurenciát, főleg a DO-t és a Vultr-t. Megnéztük a hátrányokat és az előnyöket, összegyűjtöttük a visszajelzéseket azoktól, akik a régi ISPSystem termékeken dolgoztak.
Az új billingben két technológiai stack-et használtunk: klasszikus PHP, MySQL (a jövőben tervezett a PostgreSQL-ra való áttérés), Yii2 mint backend keretrendszer és VueJS a frontendhez. A stackek függetlenül működnek, különböző emberek fejlesztik őket, és JSON API-n kommunikálnak egymással. A fejlesztéshez akkor és most is használjuk és a JetBrains-től, és nagyon szeretjük őket (srácok, üdvözlet!)
A panel moduláris elv szerint lett megtervezve: a modulok közé tartoznak a fizetési rendszerek, a domain regisztrátorok modulja vagy például az SSL tanúsítvány modul. Könnyen hozzáadhatunk új funkciót, vagy eltávolíthatunk egy régit. Az architektúrába beépítették a bővítés lehetőségét is, beleértve a "hardverhez" való visszajelzést.
Mit kaptunk: egy vezérlőpultot, amelyen teljes kontrollunk van. Most a hibákat órák alatt kijavítjuk, nem hetek alatt, és az új funkciókat az ügyfelek kérésére valósítjuk meg, nem az ISPSystem akaratára.
3. lépés. Felhasználói felület
A felhasználói felület - a mi közös gyermekünk.
Először megnéztük, mi történik, ha a ISPsystem API-ra építünk, anélkül hogy jelentősen megváltoztatnánk a felhasználói felületet. Elég gyenge lett, és úgy döntöttünk, hogy mindent nulláról kezdünk.
Mindenekelőtt azt tartottuk fontosnak, hogy a felhasználói felület logikus legyen, tiszta és minimalista dizájnnal, így egy szép panelt kaphatunk. Az elemek elhelyezését a Megaplanben vitattuk meg, és fokozatosan megszületett az a felhasználói felület, amelyet a felhasználók jelenleg látnak az irányítópultban.
Elsőként a billing oldal dizájnja készült el, hiszen már korábban is készítettünk fizetési plugineket az ISPsystem számára.
Frontend
A paneleket SPA alkalmazássá döntöttük, amely nem követel meg sok erőforrást és gyors adatbetöltést kínál. A frontend fejlesztőnk, Artysh úgy döntött, hogy Vue-t használ, hiszen akkoriban a Vue éppen megjelent. Feltételeztük, hogy a keretrendszer dinamikusan fejlődni fog, hasonlóan a React-hoz, és idővel a Vue közössége is bővülni fog, számos könyvtárral. Ráálltunk a Vue-ra, és nem bántuk meg – most már új funkciók hozzáadása a frontendhez, amelyeket már elkezdtünk programozni a backendben, számottevően rövid időt vesz igénybe. A frontend panel részleteiről külön cikkben beszélünk.
A frontend és a backend kapcsolata
A frontendet a backendhez kapcsoltuk push üzenetek útján. Meg kellett dolgoznunk érte, és saját kezelőt kellett írnunk, de most már az információk frissítése az oldalon szinte azonnal megtörténik.
A végeredmény: a panel felülete egyszerűbb lett. Reszponzívvá tettük, így a gyors betöltés lehetővé teszi, hogy még a felszállás előtti utolsó pillanatban is mobiltelefonról használják, anélkül, hogy külön alkalmazást kellene telepíteni a panel kezelésére.
4. lépés: Tesztelés és migrációs séma
Amikor minden működött és túlestünk az első teszteken, felmerült a migráció kérdése. Először a billing szoftvert telepítettük, és elkezdtük tesztelni annak működését a szerver ügynökkel.
Ezután írtunk egy egyszerű szkriptet, amely az adatbázist a régi billing rendszerből az újba migrálta.
Mindent gyakorlatilag tesztelnünk és ellenőriznünk kellett, mivel az adatokat három régi adatbázisból – Billmanager, VMmanager és IPmanager – egy újba öntöttük. Valószínűleg a tesztelési migrációk voltak a legnehezebb feladatok, amivel a új panel fejlesztése során találkoztunk.
Miután újra ellenőriztük, leállítottuk a régi billing rendszert. Az adatok végső migrálása nagyon izgalmas pillanat volt, de hála Istennek, néhány perc alatt és látható problémák nélkül teljesült. Voltak apró hibák, amelyeket egy héten át javítottunk. A legnagyobb időt a végeredmény tesztelésére fordítottuk.
Ezután leveleket küldtünk az ügyfeleknek az új panel és a számlázás címével, és átirányítást hajtottunk végre.
Végül: ÉL!
Boldog vége
A szoftverünk első óráitól kezdve már éreztük az átmenet minden előnyét. A kód teljesen a miénk volt, kényelmes architektúrával, az interfész pedig tiszta és logikus.
Első visszajelzés az új panel indítása után
Decemberben indítottuk el az átállási folyamatot, a 2017-es új év előestéjén, amikor a terhelés a legkisebb volt, hogy az ügyfelek számára megkönnyítsük az átmenetet — szinte senki sem dolgozik az ünnepek előtt.
A legfontosabb dolog, amit az átállással nyertünk (a megbízhatóság és a kényelem mellett) — a kulcsfontosságú ügyfelekhez való gyors funkciók hozzáadása — hogy arcot adunk nekik, nem pedig hátat.
Mi következik?
Növekszünk, nő az adatok, az ügyfelek, az ügyfelek adatai száma. A backendhez Memcached szervert és két különböző feladatokkal rendelkező üzenetsor-kezelőt kellett hozzáadni. A frontendben van cache-elés és saját soraink.
Természetesen voltak még kalandjaink a termék fejlesztése és bonyolítása során, például amikor hozzáadtuk a HighLoad-ot.
A következő cikkben arról fogunk mesélni, hogyan indítottuk el a Hi-CPU tarifát: a hardverről, a szoftverről, milyen feladatokat oldottunk meg és mit értünk el.
Forrás: habr.com
