Përshëndetje! Ne jemi "Hosting Technologies" dhe kemi nisur 5 vjet më parë — pritja e parë vds e krijuar posaçërisht për zhvilluesit. Ne përpiqemi ta bëjmë atë të përshtatshëm, si DigitalOcean, por me mbështetjen ruse, metodat e pagesës dhe serverët në Rusi. Por DigitalOcean nuk është vetëm besueshmëri dhe çmim, por është edhe një shërbim.
Softueri nga ISPsystem doli të ishte një litar që na lidhi duart në rrugën drejt një shërbimi të lezetshëm. Tre vjet më parë, ne përdorëm faturimin e Billmanager dhe panelin e kontrollit të serverit VMmanager dhe kuptuam shpejt se ishte pothuajse e pamundur të ofronim një shërbim të mirë pa panelin tonë të kontrollit.
Si sistemi ISP vrau komoditetin
Bugs
Ne nuk mund ta rregullonim vetë defektin - sa herë që duhej t'i shkruanim mbështetjes së dikujt tjetër dhe të prisnim. Zgjidhja e çdo problemi kërkonte përgjigjen e një kompanie të palës së tretë.
Mbështetja e sistemit ISP u përgjigj normalisht, por rregullimet erdhën vetëm pas disa lëshimeve, dhe më pas jo gjithmonë dhe jo të gjitha. Ndonjëherë gabimet kritike korrigjoheshin për disa javë. Ne duhej të siguronim klientët, të kërkonim falje dhe të prisnim që sistemi ISP të rregullonte defektin.
Kërcënimi për kohën e ndërprerjes
Përditësimet mund të gjenerojnë ndërprerje të paparashikueshme që provokojnë gabime të reja.
Çdo përditësim ishte një llotari: më duhej të mbuloja faturimin dhe të bëja sakrifica për perënditë e përditësimeve - disa herë përditësimi shkaktoi ndërprerje për 10-15 minuta. Administratorët tanë në këtë kohë ishin ulur në sy - ne kurrë nuk e dinim se sa do të zgjaste ndërprerja dhe nuk mund të parashikonim se kur sistemi ISP do të vendoste të lëshonte një përditësim të ri.
Në gjeneratën e pestë, Billmanager u bë më i mirë, por për të pasur akses në veçoritë e nevojshme, më duhej të instaloja një beta, e cila tashmë përditësohej çdo javë. Nëse diçka prishej, më duhej t'u jepja akses zhvilluesve të tjerë që të mund të rregullonin diçka.
Ndërfaqja e papërshtatshme e panelit
Gjithçka ishte e ndarë në panele të ndryshme dhe e kontrolluar nga vende të ndryshme. Për shembull, klientët paguanin përmes Billmanager, dhe atyre iu desh të rindiznin ose riinstalonin VDS në VMManager. Stafi ynë gjithashtu duhej të kalonte mes dritareve për të ndihmuar një klient, për të kontrolluar ngarkesën në serverin e tij ose për të parë se çfarë OS po përdorte.
Një ndërfaqe e tillë kërkon kohë - e jona dhe e klientëve tanë. Nuk bëhet fjalë për ndonjë lehtësi, si ajo e DigitalOcean, në një situatë të tillë.
Cikli i shkurtër i jetës me përditësime të shpeshta API
Ne kemi shkruar shtojcat tona - për shembull, një shtojcë me mënyra shtesë pagese që nuk janë në VMManager.
Në vitet e fundit, VMManager kishte një cikël jetësor relativisht të shkurtër, dhe në versionet e reja, emrat e variablave ose funksioneve në API mund të ndryshonin në mënyrë arbitrare - kjo prishi shtojcat tona. Mbështetja për versionet e vjetra u hoq shpejt dhe duhej të përditësohej.
Nuk mund të modifikohet
Më saktësisht, është e mundur, por jashtëzakonisht joefikase. Kufizimet e licencës nuk ju lejojnë të bëni ndryshime në kodin burimor, mund të shkruani vetëm shtojca. Shtojcat maksimale - disa artikuj të menysë, një magjistar hap pas hapi. Sistemi ISP është krijuar për shkathtësi, por ne kishim nevojë për zgjidhje të specializuara.
Kështu që vendimi ishte i pjekur për të shkruar panelin tim. Ne kemi vendosur synime:
- Përgjigjuni shpejt gabimeve, gabimeve dhe jini në gjendje t'i rregulloni ato vetë pa e detyruar klientin të presë.
- Ndryshoni lirisht ndërfaqen për rrjedhat e punës dhe nevojat e klientit.
- Rritni përdorshmërinë me një dizajn të pastër dhe të kuptueshëm.
Dhe ne filluam zhvillimin.
Arkitektura e re e panelit
Ne kemi një ekip zhvillimi të vetë-mjaftueshëm, kështu që e shkruam vetë panelin.
Puna kryesore u krye nga tre inxhinierë - drejtori teknik Sergey doli me arkitekturën dhe shkroi agjentin e serverit, Alexey bëri faturimin, dhe pjesa e përparme u montua nga balli ynë Artysh.
Hapi 1: Agjenti i serverit
Agjenti i serverit është një server në internet python që menaxhon bibliotekën , e cila nga ana tjetër qeveris .
Agjenti menaxhon të gjitha shërbimet në server: krijimin, ndalimin, fshirjen e vds, instalimin e sistemeve operative, ndryshimin e parametrave, e kështu me radhë përmes bibliotekës libvirt. Në momentin e publikimit të artikullit, këto janë më shumë se dyzet funksione të ndryshme, të cilat ne i plotësojmë në varësi të detyrës dhe nevojave të klientit.
Në teori, libvirt mund të kontrollohej drejtpërdrejt nga faturimi, por kjo kërkonte shumë kod shtesë dhe ne vendosëm t'i ndajmë këto funksione midis agjentit dhe faturimit - faturimi thjesht i bën kërkesa agjentit nëpërmjet API-së JSON.
Agjenti është gjëja e parë që bëmë, pasi nuk kërkonte ndonjë ndërfaqe dhe ishte e mundur ta testonim drejtpërdrejt nga tastiera e serverit.
Çfarë na dha agjenti i serverit: është shfaqur një shtresë që thjeshton jetën për të gjithë - faturimi nuk ka nevojë të dërgojë një grup të tërë komandash, por vetëm të bëjë një kërkesë. Dhe agjenti do të bëjë gjithçka që nevojitet: për shembull, do të ndajë hapësirën në disk dhe RAM.
Hapi 2. Faturimi
Për zhvilluesin tonë Alex, ky nuk ishte paneli i parë i kontrollit - Alex ka qenë në pritje për një kohë të gjatë, kështu që ai në përgjithësi e kuptoi se çfarë kishte nevojë klienti dhe çfarë i nevojitej hostit.
Ne e quajmë faturimin midis nesh një "panel kontrolli": ai përmban jo vetëm para dhe shërbime, por edhe menaxhimin e tyre, mbështetjen e klientit dhe shumë më tepër.
Për të kaluar nga softueri ISPSystem, ishte e nevojshme të ruhej plotësisht funksionaliteti i mëparshëm për klientët, të transferoheshin të gjitha veprimet financiare të përdoruesve nga faturimi i vjetër në atë të ri, si dhe të gjitha shërbimet dhe lidhjet ndërmjet tyre. Ne studiuam se çfarë ka në produktin aktual, pastaj zgjidhjet e konkurrentëve, kryesisht DO dhe Vultr. Ne shikuam disavantazhet dhe avantazhet, mblodhëm komente nga njerëzit që punonin me produkte të vjetra nga sistemi ISP.
Faturimi i ri përdori dy rafte: PHP klasik, MySQL (dhe në të ardhmen është planifikuar të kalojë në PostgreSQL), Yii2 si kornizë në pjesën e pasme dhe VueJS në pjesën e përparme. Stacks funksionojnë në mënyrë të pavarur nga njëri-tjetri, zhvillohen nga njerëz të ndryshëm dhe komunikojnë duke përdorur JSON API. Për zhvillim atëherë dhe tani ne përdorim и nga JetBrains dhe i dua shumë (hej djema!)
Paneli është projektuar mbi një bazë modulare: modulet e sistemit të pagesave, moduli i regjistruesit të domenit ose, për shembull, një modul certifikate SSL. Mund të shtoni lehtësisht një veçori të re ose të hiqni një të vjetër. Baza për zgjerimin është hedhur arkitekturisht, duke përfshirë në drejtim të kundërt, "drejt harduerit".
Çfarë morëm: një panel kontrolli mbi të cilin kemi kontroll të plotë. Tani gabimet rregullohen në orë, jo me javë, dhe veçoritë e reja zbatohen me kërkesë të klientëve, dhe jo me kërkesë të ISPSystem.
Hapi 3 Ndërfaqja
Ndërfaqja është ideja e ekipit tonë.
Së pari, ne shikuam se çfarë do të ndodhte nëse bënim një shtesë mbi API-në e sistemit ISP pa ndryshuar rrënjësisht asgjë në ndërfaqe. Doli kështu dhe ne vendosëm të bënim gjithçka nga e para.
Ne besuam se gjëja kryesore është ta bëjmë ndërfaqen logjike, me një dizajn të pastër dhe minimalist, dhe më pas do të kemi një panel të bukur. Vendndodhja e elementeve u diskutua në Megaplan dhe ndërfaqja që përdoruesit shohin tani në panelin e kontrollit do të lindë gradualisht.
Dizajni i faqes së faturimit ishte i pari që u shfaq, sepse ne kemi bërë tashmë shtojcat e pagesave për sistemin ISP.
Frontend
Ata vendosën ta bëjnë panelin një aplikacion SPA - pa kërkesa për burimet dhe me ngarkim të shpejtë të të dhënave. Përfaqësuesi ynë Artysh vendosi ta shkruante atë në Vue - në atë kohë Vue sapo ishte shfaqur. Supozuam se korniza do të zhvillohej në mënyrë dinamike, si React, pas disa kohësh komuniteti Vue do të rritej dhe do të shfaqej një det bibliotekash. Ne bastuam në Vue dhe nuk u penduam - tani duhet pak kohë për të shtuar funksione të reja në pjesën e përparme që tashmë janë programuar në pjesën e pasme. Ne do t'ju tregojmë më shumë rreth panelit të përparmë në një artikull të veçantë.
Lidhja e pjesës së përparme me pjesën e pasme
Pjesa e përparme u lidh me pjesën e pasme nëpërmjet njoftimeve shtytëse. Më duhej të punoja shumë dhe të shkruaja mbajtësin tim, por tani informacioni në faqe përditësohet pothuajse menjëherë.
Cfare ndodhi: Ndërfaqja e panelit është bërë më e thjeshtë. Ne e bëmë atë të adaptueshëm dhe ngarkimi i shpejtë ju lejon ta përdorni edhe nga telefonat celularë në minutat e fundit para nisjes, pa instaluar një aplikacion të veçantë për të punuar me panelin.
Hapi 4. Skema e testimit dhe migrimit
Kur gjithçka filloi dhe testet e para kaluan, u ngrit çështja e migrimit. Para së gjithash, ne instaluam faturimin dhe filluam testimin e funksionimit të tij me agjentin e serverit.
Më pas kemi shkruar një skript të thjeshtë që transferon bazën e të dhënave nga faturimi i vjetër në atë të ri.
Më duhej të testoja dhe rishikoja fjalë për fjalë gjithçka, pasi të dhënat u bashkuan në një bazë të dhënash të re nga tre të vjetra: Billmanager, VMmanager dhe IPmanager i menaxherit. Ndoshta migrimet testuese janë gjëja më e vështirë që kemi hasur në procesin e zhvillimit të një paneli të ri.
Pas rishikimit, mbyllëm faturimin e vjetër. Migrimi përfundimtar i të dhënave ishte një moment shumë shqetësues, por, falë Zotit, u përfundua në pak minuta dhe pa probleme të dukshme. Kishte defekte të vogla që i rregulluam gjatë javës. Pjesa më e madhe e kohës kaloi duke testuar atë që ndodhi.
Më pas u dërguam letra klientëve me adresën e panelit të ri dhe faturimin dhe bëmë një ridrejtim.
Në përmbledhje: ESHTE GJALLE!
Fund i lumtur
Që në orët e para të punës së softuerit tonë, ne ndjemë të gjitha kënaqësitë e tranzicionit. Kodi ishte plotësisht i yni dhe me një arkitekturë të përshtatshme, dhe ndërfaqja ishte e pastër dhe logjike.
Rishikimi i parë pas lançimit të panelit të ri
Ne e nisëm procesin e tranzicionit në dhjetor, në prag të Vitit të Ri 2017, kur ngarkesa ishte më e pakta, për ta bërë më të lehtë tranzicionin për klientët - pothuajse askush nuk punon në prag të festave.
Gjëja kryesore që kemi marrë kur kalojmë në sistemin tonë (përveç besueshmërisë dhe komoditetit të përgjithshëm) është aftësia për të shtuar shpejt funksionalitetin për klientët kryesorë - të jenë fytyra e tyre, jo gomari i tyre.
Çka më tej?
Ne po rritemi, sasia e të dhënave, klientëve, të dhënave të klientëve po rritet. Më duhej të shtoja një server Memcached dhe dy menaxherë të radhëve me detyra të ndryshme në fund. Frontend ka caching dhe radhët e veta.
Sigurisht, ne kishim akoma aventura ndërsa produkti u zhvillua dhe u bë më kompleks, për shembull kur shtuam HighLoad.
Në artikullin tjetër, ne do t'ju tregojmë se si u lançua tarifa Hi-CPU: për harduerin, softuerin, cilat detyra zgjidhëm dhe çfarë bëmë.
Burimi: www.habr.com