Π , Veliam-en sorreraren aurrekariei eta SaaS sistemaren bidez banatzeko erabakiari buruz hitz egin nuen. Artikulu honetan, produktua bertakoa ez, publikoa izan dadin egin behar nuenari buruz hitz egingo dut. Banaketa nola hasi zen eta zer arazo aurkitu zituzten.
plangintza
Erabiltzaileentzako egungo backend-a Linux-en zegoen. Ia erakunde guztiek Windows zerbitzariak dituzte, eta hori ezin da Linux-i buruz esan. Veliam-en indargune nagusia NAT atzean dauden zerbitzariekin eta sareko ekipoekin urruneko konexioak dira. Baina funtzionalitate hori oso lotuta zegoen bideratzaileak Mikrotik izan behar zuela. Eta honek, jakina, ez luke asko asetuko. Lehenik eta behin, saltzaile ohikoenen bideratzaileentzako laguntza gehitzea pentsatzen hasi nintzen. Baina ulertu nuen lasterketa amaigabea zela lagundutako enpresen zerrenda zabaltzeko. Gainera, dagoeneko onartzen direnek NAT arauak eredu batetik bestera aldatzeko beste komando batzuk izan ditzakete. Egoeratik ateratzeko modu bakarra VPN bat zela zirudien.
Produktua banatzea erabaki genuenez, baina ez kode ireki gisa, ezinezkoa bihurtu zen GPL bezalako lizentzia irekiak zituzten hainbat liburutegi sartzea. Orokorrean gai bereizia da; produktua saltzeko erabakia hartu ondoren, liburutegien erditik pasatu behar izan nuen GPL zirelako. Beraiek idazten zutenean, normala zen. Baina banaketarako ez da egokia. Burura datorkidan lehen VPNa OpenVPN da. Baina GPL da. Beste aukera bat Japoniako SoftEther VPN erabiltzea zen. Bere lizentziak bere produktuan sartzeko aukera eman zion. Erabiltzaileak ezer konfiguratu beharrik ez duen eta SoftEther VPN-ri buruz jakin behar ez duen moduan integratzeko hainbat proba egin eta gero, prototipo bat lortu zen. Dena behar zen bezala zegoen. Baina arrazoiren batengatik eskema honek oraindik nahastu gintuen, eta azkenean bertan behera utzi genuen. Baina, jakina, uko egin zuten beste aukera bat asmatu ostean. Azkenean, dena TCP konexio arruntetan egin zen. Konexio batzuk koordinatzaile baten bidez funtzionatzen dute, beste batzuk zuzenean Nat Hole Punching (NHP) teknologiaren bidez, Free Pascal-en ere ezarri zena. Esan behar dut ez dudala inoiz NHPren berri ere entzun. Eta inoiz ez zait bururatu 2 sareko gailu konektatzea posible zenik, biak zuzenean NAT atzean daudenik. Gaia aztertu, funtzionamendu printzipioa ulertu eta idazten eseri nintzen. Plana gauzatzen da, erabiltzailea klik batekin konektatzen da NAT atzean nahi duen gailura RDP, SSH edo Winbox bidez pasahitzak sartu edo VPN bat konfiguratu gabe. Gainera, konexio horietako gehienak gure koordinatzailearen ondotik pasatzen dira, eta horrek eragin ona du pingean eta konexio hauen zerbitzuaren kostuan.
Zerbitzariaren aldea Linuxetik Windowsera transferitzea
Windowsera aldatzean hainbat arazo izan ziren. Lehenengoa Windows-en wmic integratuak ez dizula WQL kontsultak egiten uzten. Eta gure sisteman dena jada eraikita zegoen haien gainean. Eta bazegoen beste zerbait, baina orain ahaztu egin zait zergatik utzi zuten erabilera azkenean. Baliteke Windows bertsioen arteko desberdintasunak. Eta bigarren arazoa multithreading da. Guretzako lizentzia "onargarri" baten azpian hirugarrenen erabilgarritasun on bat aurkitu gabe, Lazarus IDE abiarazi nuen berriro. Eta beharrezko erabilgarritasuna idatzi nuen. Sarrera eskatzen den objektuen zerrenda da eta zer kontsulta zehatz egin behar diren, eta erantzun moduan datuak jasotzen ditut. Eta hori guztia hari anitzeko moduan. Bikaina.
PHP Windows-erako pthreads konfiguratu ondoren, dena berehala hasiko zela pentsatu nuen, baina ez zen horrela izan. Denbora pixka bat arazketa egin ondoren, pthread-ek funtzionatzen zuela konturatu nintzen, baina gure sisteman ez zuela funtzionatu. Argi geratu zen Windows-en pthreads-ekin lan egitean berezitasun bat dagoela. Eta hala izan zen. Dokumentazioa irakurri nuen, eta hor idatzita zegoen Windows-erako hari kopurua mugatua dela, eta, gogoratzen dudanez, inplizituki. Hau arazo bihurtu zen. Aplikazioak exekutatzen zituen hari kopurua murrizten hasi nintzenean, oso poliki egiten zuen lana. IDEa berriro ireki nuen eta hari anitzeko objektuen ping egiteko funtzionaltasuna gehitu zitzaion utilitate berean. Beno, dagoeneko portuak eskaneatzeko asko dago hor ere. Egia esan, honen ondoren, PHPrako pthread-en beharra desagertu zen, eta jada ez da erabiltzen. Gainera, erabilgarritasun honi hainbat funtzionalitate gehiago gehitu zaizkio eta gaur egun ere funtzionatzen du. Honen ostean, Windows-erako instalatzaile bat muntatu zen, bertan Apache, PHP, MariaDB, PHP aplikazioa bera eta sistemarekin elkarreragiteko utilitate multzo bat, Free Pascal-en idatzia. Instalatzaileari dagokionez, arazo hau azkar konponduko nuela pentsatu nuen, zeren... Hau oso gauza arrunta da eta beharrezkoa ia software guztietan. Edo okerreko lekuan bilatzen ari nintzen, edo beste zerbait. Baina etengabe egin nuen topo nahiko malguak ez zirenak, edo garestiak eta malguak ere ez zirenak. Eta, hala ere, doako instalatzaile bat aurkitu dut, zeinetan nahi duzun guztia emateko aukera izango duen. Hau InnoSetup da. Honetaz idazten ari naiz hemen, norbaitek denbora aurrezten badut begiratu behar izan nuelako.
Pluginari uko egitea zure bezeroaren alde
Lehenago idatzi nuen bezeroaren zatia "plugin" batekin nabigatzailea zela. Beraz, Chrome eguneratu zen eta diseinua pixka bat okertu zen, gero Windows eguneratu zen eta uri eskema pertsonalizatua desagertu zen. Benetan ez nuen horrelako sorpresarik eduki nahi produktuaren bertsio publikoan. Gainera, uri pertsonalizatua desagertzen hasi zen Windows eguneratze bakoitzaren ondoren. Microsoft-ek bere ez diren adar guztiak ezabatu besterik ez du egin behar den atalean. Gainera, Google Chrome-k orain ez dizu onartzen uri pertsonalizatutik aplikazio bat irekitzeko edo ez egiteko aukera gogoratzeko, eta galdera hau egiten du monitorizazio-objektu batean klik egiten duzun bakoitzean. Beno, oro har, erabiltzailearen sistema lokalarekin interakzio normala beharrezkoa zen, arakatzaileak ematen ez duena. Eskema honetako aukerarik errazena zure arakatzailea egitea besterik ez dela dirudi, orain asko Electron bidez egiten ari diren bezala. Baina jadanik gauza asko idatzita zeuden Free Pascal-en, zerbitzariaren zatian barne, beraz, bezeroa hizkuntza berean egitea erabaki genuen, eta ez zoorik sortzea. Horrela idatzi zen Chromium barnean zuen bezero bat. Horren ostean, hainbat uhal eskuratzen hasi zen.
Askatu
Azkenik sistemarako izen bat aukeratu dugu. Bertsio lokaletik SaaSra bihurtzeko prozesua abian zegoen bitartean hainbat aukera igaro genituen etengabe. Hasiera batean barne-merkatuan ez ezik, barne-merkatuan sartzeko asmoa genuenez, izena hautatzeko irizpide nagusia ".com" eremuan okupatu gabeko edo ez oso garestia den domeinu bat egotea zen. Funtzio/modulu batzuk oraindik ez dira tokiko bertsiotik Veliam-era eraman, baina erabaki genuen egungo funtzionaltasunarekin kaleratu eta gainerakoak eguneratze gisa osatuko genituela. Lehen bertsioan ez zegoen HelpDesk, Veliam Connector, ezinezkoa zen jakinarazpenen abiarazleen atalaseak eta askoz gehiago aldatzea. Kode seinalearen ziurtagiria erosi genuen eta bezeroaren eta zerbitzariaren zatiak sinatu genituen. Produkturako webgune bat idatzi genuen, softwarea erregistratzeko izapideak, marka komertziala, etab. Oro har, hasteko prest gaude. Euforia apur bat egindako lanagatik eta agian norbaitek zure produktua erabiliko duelako, honen inguruan zalantzarik ez genuen arren. Eta gero gelditu. Bazkideak esan zuen ezinezkoa dela merkatuan sartzea mezularien bidez jakinarazpenik gabe. Beste gauza askorik gabe posible da, baina hau gabe ez. Eztabaida baten ostean, Telegram-en integrazioa gehitu zen, eta hori egokitu zitzaigun. Egungo berehalako mezulari guztien artean, hau da bere APIetarako sarbidea doan eta onarpen prozedura konplexurik gabe ematen duen bakarra. WhatsApp-ek bere zerbitzuak erabiltzeagatik diru ona kobratzen duten hornitzaileekin harremanetan jartzea iradokitzen du; junturarik gabe sarbidea eskatzen zuten gutun guztiak ez ziren aintzat hartu. Tira, Viber... Ez dakit nork erabiltzen duen orain, zeren... spam eta publizitatea zerrendetatik kanpo daude. Abendu amaieran, lagunen artean barne-proba eta proba batzuk egin ostean, denontzako izen-ematea ireki zen eta softwarea deskargatzeko moduan jarri zen.
Banaketaren hasiera
Hasiera-hasieratik, sistemaren erabiltzaileen fluxu txiki bat behar genuela ulertu genuen, produktua borroka moduan probatu ahal izateko eta lehen iritzia emateko. VK-n erositako hainbat argitalpenek fruituak eman zituzten. Iritsi dira lehen izen emateak.
Hemen esan behar da zure enpresak izen ospetsurik ez duenean merkatuan sartzea eta, aldi berean, zerbitzarietatik eta lan-estazioetatik kontuak sartu behar dituzun agenterik gabeko monitorizazio funtzionaltasuna eskaintzea, oso zaila dela. Horrek jende asko beldurtzen du. Hasiera-hasieratik ulertu genuen honek arazoak izango zituela eta horretarako prestatu ginen bai teknikoki eta bai moralki. Urruneko konexio guztiak, RDP eta SSH lehenespenez zifratuta dauden arren, gure softwareak AES estandarra erabiliz enkriptatzen ditu gainera. Tokiko zerbitzarietako datu guztiak HTTPS bidez transferitzen dira hodeira. Kontuak zifratuta gordetzen dira. Azpisistema guztien enkriptazio-gakoak banakakoak dira bezero guztientzat. Urruneko konexioetarako, saio enkriptatzeko gakoak erabili ohi dira.
Egoera honetan jendea lasaiago senti dadin egin dezakeguna da ahalik eta irekien egotea, segurtasuna lantzea eta jendearen galderei erantzuteaz nekatu.
Askorentzat, softwarearen erosotasuna eta funtzionaltasuna beldurra baino handiagoa da, eta erregistratzen dira. Pertsona batzuek VK-n argitaratutako mezuetan idatzi zuten software hau ezin dela erabili Hau haien pasahitzen bilduma da eta, oro har, izenik gabeko enpresa bat da. Esan beharra dago batek baino gehiagok zuela iritzi hori. Jende askok ez du ulertzen zerbitzu gisa exekutatzen den zerbitzari batean beste software jabedun bat instalatzen dutenean, sisteman eskubide osoak ere badituela eta ez dutela konturik behar legez kanpoko zerbait egiteko (argi dago alda dezakezula zerbitzua abiarazten duen erabiltzailea, baina hemen ere edozein kontu sar dezakezu). Izan ere, jendearen beldurrak ulergarriak dira. Zerbitzari batean softwarea instalatzea gauza arrunta da, baina kontu bat sartzea pixka bat beldurgarria eta intimoa da, jendearen erdi onek pasahitz berdina baitute zerbitzu guztietarako, eta kontu bat sortzea proba baterako ere alferra da. Baina momentu honetan jendeak bere kredentzialekin eta gehiago fidatzen dituen zerbitzu ugari daude. Eta horietako bat izaten ahalegintzen gara.
Nonbait lapurtu genuela esaten zuten iruzkin asko zeuden. Horrek pixka bat harritu gintuen. Beno, ados, pertsona baten iritzia, baina horrelako iruzkinak pertsona ezberdinen hainbat argitalpenetan aurkitu ziren. Hasieran ez zekiten nola erreakzionatu honen aurrean. Edo triste egoteko batzuek Errusian inork bere kabuz ezer ezin duela egin, lapurtu baino ezin duela uste dutelako, edo zoriontsu izatea hori lapurtu daitekeela uste dutelako.
Orain amaitu dugu EV Code Sign ziurtagiria lortzeko prozedura. Hori lortzeko, hainbat kontrol egin eta enpresari buruzko dokumentu mordoa bidali behar dira, horietako batzuk abokatu batek egiaztatu beharko ditu. Pandemia batean EV Code Sign ziurtagiria lortzea artikulu baterako gai bereizia da. Prozedurak hilabete iraun zuen. Eta ez zen hilabete itxaronaldia izan, dokumentu osagarrien etengabeko eskaerak baizik. Agian pandemiak ez zuen zerikusirik horrekin, eta prozedurak hainbeste denbora behar izan zuen guztiontzat? Partekatu.
Batzuek diote ez dugula erabiliko FSTEC ziurtagiririk ez dagoelako. Azaldu behar dugu ezin dugula lortu eta ez dela lortuko, zeren eta ziurtagiri hau lortzeko, enkriptatzea GOSTren araberakoa izan behar da, eta softwarea Errusian ez ezik AES erabiltzeko asmoa dugu.
Iruzkin hauek guztiek zalantzan jartzen dute publikoki ezagutu gabe kontuak sartzea eskatzen duen produktu bat sustatzea posible dela. Nahiz eta bagenekien egongo zela honen aurrean oso jarrera negatiboa zutenak. Inskripzio kopurua milatik gorakoa izan ostean, pentsatzeari utzi diogu. Batez ere, produktua probatu ere egin ez zutenen negatibotasunaz gain, kritika oso atseginak agertzen hasi ziren. Esan beharra dago iritzi positibo hauek produktuak garatzeko motibatzaile handiena direla.
Langileentzako urruneko sarbidearen funtzionaltasuna gehitzea
Bezeroen lan sarrietako bat "Vanyari bere ordenagailurako sarbidea etxetik ematea" da. Mikrotik-en VPNa sortu dugu eta erabiltzaileentzako kontuak sortu ditugu. Baina hau benetako arazo bat da. Erabiltzaileek ezin dituzte argibideak ikusi eta urratsez urrats jarraitu VPN bidez konektatzeko. Windows-en bertsio desberdinak. Windows batean dena ondo konektatzen da, beste batean beste protokolo bat behar da. Eta, oro har, hau beti sareko ekipoen birkonfigurazioarekin lotuta zegoen, VPN zerbitzari gisa jokatzen zuena, eta langile guztiek ez dute bertara sartzeko eta hori deserosoa zen.
Baina dagoeneko baditugu urruneko konexioak zerbitzarietarako eta sareko ekipoetarako. Zergatik ez erabili prest egindako garraioa eta egin erabiltzaileari konektatzeko besterik gabe eman diezaiokezun erabilgarritasun txiki bat. Ziurtatu nahi nuen erabiltzaileak ez zuela ezer abstrusorik sartu bertan. "Konektatu" botoi bakarra. Baina nola ulertuko du utilitate honek non konektatu botoi bakarra badu? Gure zerbitzarietan beharrezko aplikazioa linean eraikitzeko ideia bat zegoen. Sistema-administratzaileak "deskargatu lasterbidea" botoian klik egiten du, eta komando bat bidaltzen da gure hodeira bitar indibidual bat eraikitzeko, nahi duzun zerbitzari/ordenagailu RDP bidez konektatzeko kabledun informazioarekin. Oro har, hori egin liteke. Baina honek denbora asko behar du; administratzaileak lehenengo bitarra konpilatu eta gero deskargatu arte itxaron beharko luke. Jakina, posible izango litzateke konfigurazioarekin bigarren fitxategi bat gehitzea, baina dagoeneko 2 fitxategi dira, eta sinpletasunerako erabiltzaileak bat behar du. Fitxategi bat, botoi bat eta instalatzailerik gabe. Google-n apur bat irakurri ondoren, konpilatutako ".exe"ren amaieran informazio batzuk gehitzen badituzu, orduan ez dela hondatzen (beno, ia) ondorioztatu nuen. Gutxienez gerra eta bakea gehi ditzakezu bertan, eta lehen bezala funtzionatuko du. Bekatua litzateke honetaz ez aprobetxatzea. Orain aplikazioa deskonprimitu dezakezu edonon, bezeroan bertan, Veliam Connector deitzen zaion moduan, eta amaieran konektatzeko beharrezkoa den informazioa gehi dezakezu. Eta aplikazioak berak badaki zer egin horrekin. Zergatik idatzi nuen "ondo ia" parentesi artean apur bat gorago? Erosotasun hori ordaindu behar duzulako, aplikazioak sinadura digitala galtzen baitu. Baina fase honetan, erosotasun horiengatik ordaintzeko prezio txikia dela uste dugu.
Hirugarrenen moduluen lizentziak
Dagoeneko goian idatzi nuen produktua jendaurrean jartzea erabaki ondoren, eta ez bakarrik gure erabilerarako, gogor lan egin eta gure produktuan sartzen uzten ez zuten modulu batzuen ordezkoak bilatu behar izan genituela. Baina kaleratu ostean, ustekabean gauza oso desatsegina aurkitu zen. Veliam Server, bezeroaren aldetik zegoena, MariaDB DBMS barne hartzen zuen. Eta GPL lizentzia du. GPL lizentziak esan nahi du softwareak kode irekia izan behar duela, eta gure produktuak MariaDB barne badu, lizentzia hau duena, orduan gure produktuak lizentzia honen pean egon behar du. Baina, zorionez, lizentzia honen helburua kode irekia da, ez da auzitegietan ustekabean akatsak egiten dituztenak zigortzea. Egile-eskubideen jabeak erreklamazioren bat badu, urratzaileari idatziz jakinaraziko dio eta urraketa ezabatu beharko du 30 eguneko epean. Gure akatsa guk geuk aurkitu genuen eta ez genuen gutunik jaso eta berehala arazoa konpontzeko aukerak aztertzen hasi ginen. Irtenbidea begi-bistakoa izan zen: aldatu SQLite-ra. Datu-base honek ez du lizentzia-murrizketarik. Arakatzaile moderno gehienek SQLite eta beste programa mordo bat erabiltzen dute. Interneten aurkitu dut SQLite munduko DBMS hedatuena dela dioen informazioa, nabigatzaileengatik hain zuzen, baina ez dut frogarik bilatu, beraz, informazio zehatza da. SQLite-ra aldatzearen arriskuak aztertzen hasi nintzen.
Hau zeregin ez-trivial bihurtzen da bezeroek MariaDBrekin eta bertan datuak dituzten ehunka zerbitzari instalatuta dituztenean. MariaDB ezaugarri batzuk ez daude eskuragarri SQLite-n. Tira, adibidez, kodean bezalako kontsultak erabili ditugu
Select * FROM `table` WHERE `id`>1000 FOR UPDATE
Eraikuntza honek taulako hautaketa bat egiteaz gain, errenkadako datuak blokeatzen ditu. Eta beste hainbat diseinu ere berridatzi behar izan ziren. Baina kontsulta asko berridatzi behar izateaz gain, bezeroaren Veliam Server eguneratzean datu guztiak DBMS berrira eraman eta zaharra ezabatuko zuen mekanismo bat ere asmatu behar izan genuen. Gainera, SQLite-ko transakzioak ez zuten funtzionatu eta hau benetako arazoa zen. Baina World Wide Web-aren zabaltasuna irakurri ondoren, arazorik gabe aurkitu nuen SQLite-n transakzioak gaitu daitezkeela komando sinple bat pasatuz konektatzean.
PRAGMA journal_mode=WAL;Ondorioz, zeregina amaitu zen eta orain bezeroaren zerbitzariaren zatia SQLite-n exekutatzen da. Ez dugu aldaketarik nabaritu sistemaren funtzionamenduan.
HelpDesk berria
Beharrezkoa zen HelpDesk sistema barneko bertsiotik SaaS bertsiora eraman, baina aldaketa batzuekin. Egin nahi nuen lehenengo gauza bezeroaren domeinuarekin integratzea zen, sisteman erabiltzaileen baimen gardenari dagokionez. Orain, HelpDesk-en saioa hasteko eta sisteman eskaera bat uzteko, erabiltzaileak mahaigaineko lasterbidean klik egin eta arakatzailea irekitzen da. Erabiltzaileak ez du inolako kredentzialik sartzen. Veliam Server-en parte den Apache SSPI moduluak automatikoki baimentzen dio erabiltzaileari domeinu-kontu baten pean. Erabiltzailea sare korporatibotik kanpo dagoenean eskaera bat sisteman uzteko, botoi batean klik egiten du eta esteka bat jasotzen du bere posta elektronikoan, zeinaren bidez, pasahitzik gabe HelpDesk sisteman sartzen den. Erabiltzaile bat domeinu batean desgaituta edo ezabatzen bada, HelpDesk kontuak ere funtzionatzeari utziko dio. Horrela, sistemaren administratzaileak ez ditu domeinuko kontuak eta HelpDesk berak kontrolatu beharrik. Langile batek irten egiten du - bere kontua deskonektatzen du domeinuan eta kito, ez du sisteman sartuko sare korporatibotik, ez esteka baten bidez. Integrazio honek funtziona dezan, sistema-administratzaileak GPO bat sortu behar du, hau da ΠΈ .
HelpDesk sistemetarako oso beharrezkoa ikusten dugun bigarren gauza, guretzat behintzat, eskatzailearekin zuzenean aplikaziotik klik bakarrean konektatzea da. Gainera, konexioak gainditu behar dira sistemaren administratzailea beste sare batean badago. Outsourcing hori derrigorrezkoa da, lanaldi osoko sistema administratzaileentzat ere oso beharrezkoa izaten da. Dagoeneko badira hainbat produktu urruneko konexioen lan bikaina egiten dutenak. Eta haientzat integrazioak egitea erabaki genuen. Orain VNCrako integratuta gaude, eta etorkizunean Radmin eta TeamViewer gehitzeko asmoa dugu. Gure sare-garraioa urruneko azpiegitura-konexioetarako erabiliz, VNC urruneko lan-estazioetara konektatu genuen NAT atzean. Gauza bera gertatuko da Radminekin. Orain, erabiltzaile batekin konektatzeko, aplikazioan bertan dagoen "konektatu eskatzailearekin" botoia sakatu besterik ez duzu egin behar. VNC bezeroa irekitzen da eta eskatzailearekin konektatzen da, sare berean zauden edo etxean zapatilekin eserita zauden ala ez. Lehenik eta behin, sistemaren administratzaileak, GPO erabiliz, VNC Server instalatu behar du guztion lan-estazioetan.
Orain gu ere HelpDesk berrira aldatzen ari gara eta domeinuarekin eta VNCrekin integrazioa erabiltzen ari gara. Hau oso erosoa da guretzat. Orain hiru urte baino gehiago daramatzagun TeamViewer ordaintzea saihestu dezakegu, gure laguntza-zerbitzua martxan jartzeko.
Zer egiteko asmoa dugu hurrengoan?
Produktua kaleratu genuenean, ez genuen ordaindutako tarifarik egin, baizik eta doako tarifa 50 monitorizazio objektutara mugatu genuen. Bost dozena sareko gailu eta zerbitzari nahikoak izan beharko lirateke guztiontzat, pentsatu genuen. Eta orduan hasi ziren sartzen muga handitzeko eskaerak. Pixka bat harrituta geundela esatea ezer ez esatea da. Hainbeste zerbitzari dituzten enpresak benetan interesatzen al dira gure softwarean? Doan zabaldu genuen muga horrelako eskaerak egiten zituztenentzat. Haien eskaerari erantzunez, batzuei galdetu genien zergatik behar zuten hainbeste, benetan zerbitzari eta sare ekipamendu kopuru handia zuten. Eta ondorioztatu zen sistema-administratzaileak sistema batere aurreikusi ez genuen moduan erabiltzen hasi zirela. Dena sinplea izan zen - gure softwarea zerbitzariak ez ezik, lan-estazioak ere kontrolatzen hasi zen. Horregatik, mugak zabaltzeko eskaera asko daude. Orain dagoeneko sartu ditugu ordaindutako tarifak eta mugak modu independentean zabal daitezke.
Zerbitzariek ia beti lan egiten dute biltegiratze sistemekin edo disko lokalekin RAID array batean. Eta hasieran beraientzat egin genuen produktua. Eta SMART monitorizazioa ez zen interesgarria zeregin horretarako. Baina jendeak lantokiak monitorizatzeko softwarea egokitu duela kontuan hartuta, SMART monitorizazioa ezartzeko eskaerak agertu dira. Laster ezarriko dugu.
Veliam Connector-en etorrerarekin, ez zen beharrezkoa VPN zerbitzari bat zabaltzea sare korporatiboan, edo RDGW egitea, edo, besterik gabe, RDP bidez konektatzeko beharrezkoak diren makinetara portuak bidaltzea. Jende askok gure sistema urruneko konexio horietarako bakarrik erabiltzen du. Veliam Connector Windows-erako bakarrik dago erabilgarri, eta konpainiako erabiltzaile batzuk MacOS exekutatzen duten etxeko ordenagailu eramangarrietatik konektatzen dira sare korporatiboko lan-estazioetara edo terminaletara. Eta ematen du sistemaren administratzailea behartuta dagoela, hainbat erabiltzaileren ondorioz, oraindik birbidaltzearen edo VPNaren gaira itzultzera. Hori dela eta, MacOSerako Veliam Connector-en bertsio bat egiten amaitzen ari gara. Apple-ren teknologia gogokoenaren erabiltzaileek ere aukera izango dute azpiegitura korporatibora klik bakarrean konektatzeko.
Asko gustatzen zait sistemaren erabiltzaile kopuru handi bat edukita, ez duzula zertan buru-belarri ibili behar jendeak zer behar duen eta zer izango den erosoagoa. Beraiek idazten dituzte euren nahiak, beraz, etorkizun hurbilerako garapen plan asko daude.
Aldi berean, sistema ingelesera itzultzen eta atzerrian banatzen hasteko asmoa dugu. Oraindik ez dakigu nola banatuko dugun produktua gure herrialdetik kanpo, aukeren bila gabiltza. Beharbada, artikulu bereizi bat izango da geroago honi buruz. Beharbada, artikulu hau irakurri duen norbaitek eskatuko duen bektorea iradokitzeko gai izango da, edo berak badaki eta badaki nola egin eta bere zerbitzuak eskainiko ditu. Zure laguntza eskertuko genuke.
Iturria: www.habr.com