Saluton! Ni estas "Gastigaj Teknologioj" kaj lanĉitaj antaŭ 5 jaroj — la unua vds-gastigado kreita specife por programistoj. Ni strebas igi ĝin oportuna, kiel DigitalOcean, sed kun rusa subteno, pagmanieroj kaj serviloj en Rusio. Sed DigitalOcean estas ne nur fidindeco kaj prezo, ĝi ankaŭ estas servo.
Programaro de ISPsystem montriĝis kiel ŝnuro, kiu ligis niajn manojn survoje al bonega servo. Antaŭ tri jaroj, ni uzis Billmanager-fakturadon kaj la VMmanager-servilan kontrolpanelon kaj rapide rimarkis, ke estas preskaŭ neeble provizi bonan servon sen nia propra kontrolpanelo.
Kiel ISPsistemo Mortigis Komforton
Cimoj
Ni mem ne povis ripari la cimon - ĉiufoje ni devis skribi al aliula subteno kaj atendi. La solvo de ajna problemo postulis la respondon de triapartnera kompanio.
ISP-sistemo-subteno respondis normale, sed korektoj venis nur post kelkaj eldonoj, kaj poste ne ĉiam kaj ne ĉiuj. Kelkfoje kritikaj cimoj estis korektitaj dum pluraj semajnoj. Ni devis trankviligi klientojn, pardonpeti kaj atendi ke ISP-sistemo riparu la cimon.
Malfunkcia Minaco
Ĝisdatigoj povus generi neantaŭvideblajn malfunkciojn, kiuj provokis novajn erarojn.
Ĉiu ĝisdatigo estis loterio: mi devis kaŝi fakturadon kaj fari oferojn al la dioj de ĝisdatigoj - kelkfoje la ĝisdatigo kaŭzis malfunkcion dum 10-15 minutoj. Niaj administrantoj ĉi-momente sidis sur siaj okuloj - ni neniam sciis kiom longe daŭros la malfunkcio kaj ne povis antaŭdiri kiam ISPsystem decidos liberigi novan ĝisdatigon.
En la kvina generacio, Billmanager pliboniĝis, sed por akiri aliron al la necesaj funkcioj, mi devis instali beta, kiu jam estis ĝisdatigita ĉiusemajne. Se io rompiĝis, mi devis doni aliron al aliaj programistoj por ke ili povu ion ripari.
Malkonvena panela interfaco
Ĉio estis dividita en malsamaj paneloj kaj kontrolita de malsamaj lokoj. Ekzemple, klientoj pagis per Billmanager, kaj ili devis rekomenci aŭ reinstali VDS en VMManager. Nia personaro ankaŭ devis ŝanĝi inter fenestroj por helpi klienton, kontroli la ŝarĝon sur lia servilo aŭ vidi kian OS li uzas.
Tia interfaco bezonas tempon - kaj nian kaj niajn klientojn. Ne estas demando pri iu ajn oportuno, kiel tiu de DigitalOcean, en tia situacio.
Mallongaj vivocikloj kun oftaj API-ĝisdatigoj
Ni skribis niajn proprajn kromaĵojn - ekzemple, kromprogramon kun pliaj pagmanieroj kiuj ne estas en VMManager.
En la lastaj jaroj, VMManager havis relative mallongan vivociklon, kaj en novaj versioj, la nomoj de variabloj aŭ funkcioj en la API povus ŝanĝi arbitre - ĉi tio rompis niajn kromaĵojn. Subteno por pli malnovaj versioj estis rapide forigita kaj devis esti ĝisdatigita.
Ne povas esti modifita
Pli precize, ĝi eblas, sed ege malefika. Licencaj limigoj ne permesas al vi fari ŝanĝojn al la fontkodo, vi povas nur skribi kromaĵojn. Maksimumaj kromaĵoj - kelkaj menueroj, paŝo post paŝo sorĉisto. ISP-sistemo estas desegnita por ĉiuflankeco, sed ni bezonis specialajn solvojn.
Do la decido estis matura verki mian propran panelon. Ni fiksis celojn:
- Respondu rapide al eraroj, cimoj kaj povu ripari ilin mem sen atendigi la klienton.
- Libere modifi la interfacon por laborfluoj kaj klientaj bezonoj.
- Pliigu uzeblon kun pura kaj komprenebla dezajno.
Kaj ni komencis disvolviĝon.
Nova Panela Arkitekturo
Ni havas memsufiĉan evoluan teamon, do ni mem skribis la panelon.
La ĉefa laboro estis farita de tri inĝenieroj - teknika direktoro Sergey elpensis la arkitekturon kaj skribis la servilan agenton, Alexey faris la fakturadon, kaj la front-end estis kunmetita de nia front-ender Artysh.
Paŝo 1: Servila Agento
La servila agento estas python-retservilo kiu administras la bibliotekon , kiu siavice regas .
La agento administras ĉiujn servojn en la servilo: krei, haltigi, forigi vds, instali operaciumojn, ŝanĝi parametrojn, kaj tiel plu per la libvirt-biblioteko. En la momento de publikigo de la artikolo, ĉi tiuj estas pli ol kvardek malsamaj funkcioj, kiujn ni kompletigas depende de la tasko kaj la bezonoj de la kliento.
En teorio, libvirt povus esti kontrolita rekte de fakturado, sed tio postulis tro da kroma kodo kaj ni decidis apartigi ĉi tiujn funkciojn inter la agento kaj fakturado - fakturado simple faras petojn al la agento per la JSON-API.
La agento estas la unua afero, kiun ni faris, ĉar ĝi ne postulis ajnan interfacon kaj eblis testi ĝin rekte de la servila konzolo.
Kion la servila agento donis al ni: aperis tavolo, kiu simpligas la vivon por ĉiuj - fakturado ne bezonas sendi tutan aron da komandoj, sed nur fari peton. Kaj la agento faros ĉion necesan: ekzemple, ĝi asignos diskspacon kaj RAM.
Paŝo 2. Fakturado
Por nia programisto Alex, ĉi tio ne estis la unua kontrolpanelo - Alex estis en gastigado dum longa tempo, do li ĝenerale komprenis, kion la kliento bezonas kaj kion la gastiganto bezonas.
Ni nomas fakturadon inter ni "kontrolpanelo": ĝi enhavas ne nur monon kaj servojn, sed ankaŭ ilian administradon, klienthelpon kaj multe pli.
Por ŝanĝi de ISPSystem-programaro, necesis plene konservi la antaŭan funkciecon por klientoj, translokigi ĉiujn financajn agojn de uzantoj de la malnova fakturado al la nova, kaj ankaŭ ĉiujn servojn kaj ligojn inter ili. Ni studis kio estas en la nuna produkto, tiam la solvoj de konkurantoj, ĉefe DO kaj Vultr. Ni rigardis la malavantaĝojn kaj avantaĝojn, kolektis komentojn de homoj, kiuj laboris kun malnovaj produktoj de ISPsystem.
La nova fakturado uzis du stakojn: klasika PHP, MySQL (kaj estonte estas planite ŝanĝi al PostgreSQL), Yii2 kiel kadro sur la malantaŭo kaj VueJS ĉe la fronto. Stakoj funkcias sendepende unu de la alia, estas evoluigitaj de malsamaj homoj kaj komunikas per la JSON-API. Por evoluo tiam kaj nun ni uzas и de JetBrains kaj amu ilin kore (hej infanoj!)
La panelo estas desegnita sur modula bazo: pagsistemmoduloj, domajna registrilo-modulo aŭ, ekzemple, SSL-atestmodulo. Vi povas facile aldoni novan funkcion aŭ forigi malnovan. La bazo por la ekspansio estas metita arkitekture, inkluzive en la kontraŭa direkto, "al la aparataro".
Kion ni ricevis: kontrolpanelo super kiu ni havas plenan kontrolon. Nun cimoj estas korektitaj en horoj, ne semajnoj, kaj novaj funkcioj estas efektivigitaj laŭ la peto de klientoj, kaj ne laŭ la peto de ISPSystem.
Paŝo 3 Interfaco
La interfaco estas ideo de nia teamo.
Unue, ni rigardis kio okazus se ni farus aldonaĵon super la ISPsystem API sen esence ŝanĝi ion en la interfaco. Ĝi rezultis tiel-tiel kaj ni decidis fari ĉion de nulo.
Ni kredis, ke la ĉefa afero estas logi la interfacon, kun pura kaj minimumisma dezajno, kaj tiam ni ricevos belan panelon. La loko de la elementoj estis diskutita en Megaplan kaj la interfaco, kiun uzantoj nun vidas en la kontrolpanelo, iom post iom naskiĝos.
La dezajno de la faktura paĝo estis la unua aperinta, ĉar ni jam faris pagajn kromaĵojn por ISPsystem.
Frontend
Ili decidis fari la panelon SPA-aplikaĵo - nepostulema al rimedoj kaj kun rapida datumŝarĝado. Nia ĉefo Artysh decidis skribi ĝin sur Vue — en tiu tempo Vue ĵus aperis. Ni supozis, ke la kadro disvolviĝus dinamike, kiel React, post iom da tempo la Vue-komunumo kreskos kaj aperos maro da bibliotekoj. Ni vetis je Vue kaj ne bedaŭris tion - nun necesas malmulte da tempo por aldoni novajn funkciojn al la fronto, kiuj jam estis programitaj en la malantaŭo. Ni rakontos al vi pli pri la antaŭa panelo en aparta artikolo.
Konektante la fasadon al la backend
La fasado estis konektita al la backend per puŝaj sciigoj. Mi devis multe labori kaj skribi mian propran prizorganton, sed nun la informoj sur la paĝo estas ĝisdatigita preskaŭ tuj.
Kio okazis: La panela interfaco fariĝis pli simpla. Ni faris ĝin adapta, kaj rapida ŝarĝo permesas vin uzi ĝin eĉ de poŝtelefonoj en la lastaj minutoj antaŭ ekflugo, sen instali apartan aplikaĵon por labori kun la panelo.
Paŝo 4. Testado kaj migrado-skemo
Kiam ĉio komenciĝis kaj la unuaj provoj pasis, la demando pri migrado ekestis. Antaŭ ĉio, ni instalis fakturadon kaj komencis testi ĝian funkciadon kun la servila agento.
Poste ni skribis simplan skripton, kiu transdonas la datumbazon de la malnova fakturado al la nova.
Mi devis testi kaj rekontroli laŭvorte ĉion, ĉar la datumoj estis kunfanditaj en unu novan datumbazon de tri malnovaj: Billmanager, VMmanager kaj la IPmanager de la administranto. Eble la testaj migradoj estas la plej malfacila afero, kiun ni renkontis en la procezo de evoluigado de nova panelo.
Post rekontrolado, ni fermis la malnovan fakturadon. La fina datummigrado estis tre ĝena momento, sed, dank' al Dio, ĝi estis kompletigita en kelkaj minutoj kaj sen rimarkindaj problemoj. Estis etaj eraroj, kiujn ni riparis dum la semajno. Plejparto de la tempo estis pasigita por provi kio okazis.
Poste ni sendis leterojn al klientoj kun la adreso de la nova panelo kaj fakturado kaj faris alidirektilon.
Eventuale: ĜI ESTAS VIVA!
Feliĉa fino
De la unuaj horoj de laboro de nia programaro, ni sentis ĉiujn ĝojojn de la transiro. La kodo estis tute nia kaj kun oportuna arkitekturo, kaj la interfaco estis pura kaj logika.
Unua revizio post la lanĉo de la nova panelo
Ni lanĉis la transiran procezon en decembro, antaŭ la nova jaro 2017, kiam la ŝarĝo estis la plej malgranda, por faciligi la transiron por klientoj - preskaŭ neniu laboras antaŭ la ferioj.
La ĉefa afero, kiun ni ricevis ŝanĝante al nia sistemo (krom ĝenerala fidindeco kaj komforto) estas la kapablo rapide aldoni funkciojn por ŝlosilaj klientoj - esti ilia vizaĝo, ne ilia azeno.
Kio sekvas?
Ni kreskas, la kvanto de datumoj, klientoj, kliento datumoj kreskas. Mi devis aldoni Memcached-servilon kaj du vicadministrantojn kun malsamaj taskoj al la backend. La fasado havas kaŝmemoron kaj siajn proprajn vostojn.
Kompreneble, ni ankoraŭ havis aventurojn dum la produkto disvolviĝis kaj fariĝis pli kompleksa, ekzemple kiam ni aldonis HighLoad.
En la sekva artikolo, ni rakontos al vi kiel la tarifo Hi-CPU estis lanĉita: pri aparataro, programaro, kiajn taskojn ni solvis kaj kion ni faris.
fonto: www.habr.com