Në , tregova fola për historinë e krijimit të Veliam dhe zgjidhjen e shpërndarjes së tij në sistemin SaaS. Në këtë artikull, do të flas për atë që duhej bërë që produkto të bëhej jo lokale, por publike. Për fillimin e shpërndarjes dhe problemet që hasëm.
Planifikimi
Pjesa aktuale serverike për përdoruesit ishte në Linux. Gati çdo organizatë ka serverë Windows, gjë që nuk mund të thuhet për Linux. Forca kryesore e Veliam është lidhja e largët me serverët dhe pajisjet rrjetore përmes NAT. Por kjo funksionalitet ishte shumë e lidhur me faktin që routeri duhej të ishte patjetër MikroTik. Kjo do të kënaqte shumë njerëz. Fillimisht mendova të shtoja mbështetje për routerët e prodhuesve më të zakonshëm. Por e kuptova se kjo do të ishte një garë pafund për zgjerimin e listës së kompanive të mbështetur. Më shumë se kaq, ata që tashmë mbështeteshin, ndonjëherë mund të kenë një grup të ndryshëm komandash për ndryshimin e rregullave NAT nga modeli në model. Një zgjidhje e vetme që shikoja ishte VPN.
Duke u vendosëm të shpërndajmë produktin, por jo si open source, nuk ishte e mundur të përfshiheshin në përbërjen e tij biblioteka të ndryshme me licenca të hapura si GPL. Kjo është një temë krejtësisht e veçantë, pasi pas vendimit për shitjen e produktit, duhej të rishikohej gjysma e bibliotekave për shkak të licencës GPL. Kur e shkruanim për ne, ishte në rregull. Por për shpërndarje nuk funksionon. VPN-i i parë që vjen në mendje është OpenVPN. Por ai është GPL. Një alternativë ishte përdorimi i SoftEther VPN nga Japani. Licenca e tij lejonte përfshirjen në produktin tonë. Pas disa ditësh testeve të ndryshme për të integruar atë në mënyrë që përdoruesi të mos kishte nevojë të konfigurojë asgjë dhe të nuk dinte asgjë për SoftEther VPN, u krijua një prototip. Gjithçka ishte mirë. Megjithatë, për një arsye, kjo skemë na shqetësonte dhe në fund e hodhëm poshtë. Natyrisht, u tërhoqëm pas vënies në dispozicion të një varianti tjetër. Në fund, gjithçka u bë me lidhje TCP normale. Disa lidhje funksionojnë përmes koordinators, disa drejtpërdrejt përmes teknologjisë Nat Hole Punching (NHP), e cila gjithashtu u realizua në Free Pascal. Duhet të them se për NHP-un nuk kisha dëgjuar më parë. Nuk më kishte shkuar në mendje se mund të lidheshin dy pajisje rrjeti, të dyja nën NAT, direkt. E hulumtova temën, kuptova principin e punës dhe fillova të shkruaj. Ajo që kisha menduar u realizua, përdoruesi lidhet me një klik në pajisjen e dëshiruar nën NAT përmes RDP, SSH ose Winbox pa futur fjalëkalime dhe pa konfiguruar VPN. Dhe, pjesa më e madhe e këtyre lidhjeve kalon anash koordinators tonë, që ndikon mirë në ping dhe kostot e shërbimit të këtyre lidhjeve.
Përkthimi i pjesës serverike nga Linux në Windows
Ishin disa probleme gjatë kalimit në Windows. Problemi i parë — wmic i dëshmuar në Windows nuk lejon të bëhen kërkesa WQL. Dhe në sistemin tonë tashmë ishte ndërtuar gjithçka mbi to. Kishte edhe diçka tjetër, por tani e kam harruar pse përfundimisht u hoq përdorimi i tij. Ndoshta ndryshimet midis versioneve të Windows. Problemi i dytë — shumëfryrja. Pas mosgjetjes së një utilitari të mirë të jashtëm me një licencë “të pranueshme” për ne, e kam rihapur IDE-në Lazarus. Dhe shkrova utilitarin e nevojshëm. në hyrje jepet lista e nevojshme e objekteve dhe cilat kërkesa duhet të bëhen, ndërsa në përgjigje marr të dhënat. Dhe gjithçka ndodh në modin shumëfryrë. Shkëlqyer.
Pasi që konfigurava pthreads për PHP në Windows, mendoja se gjithçka do të funksiononte menjëherë, por jo. Pas një kohe të caktuar debugging-u, kuptova se pthreads duket se punonte, por në sistemin tonë nuk funksiononte. U bë e qartë se kishte ndonjë veçanti në punën me pthreads në Windows. Dhe ashtu ishte. Lexova dokumentacionin, dhe aty shkruhej se për Windows numri i thread-ëve është i kufizuar, për më tepër, sa mbaj mend, në mënyrë të implicit. Kjo u bë një problem. Sepse, kur fillova të reduktoj numrin e thread-ëve me të cilët aplikacioni punonte, ai e bënte punën shumë ngadalë. Përsëri hapja IDE-në dhe funksionaliteti për ping të shumëfishtë të objekteve u shtua në atë utilitet. Dhe, për të mos lënë pas, edhe skanimi i porteve u vendos aty. Saktësisht, pas kësaj, nevoja për pthreads për PHP u zhduk, dhe ai nuk përdoret më. Më vonë në këtë utilitet u shtuan edhe disa funksionalitete dhe ai funksionon ende sot. Pas kësaj, u ndërtua një instalues për Windows, i cili përfshinte Apache, PHP, MariaDB, vetë aplikacionin PHP dhe një grup utilitetesh për ndërveprimin me sistemin, të shkruara në Free Pascal. Sa i përket instaluesit, mendova se këtë çështje do ta zgjidhja shpejt, sepse është një gjë shumë e zakonshme dhe e nevojshme për pothuajse çdo software. Ose nuk kërkova siç duhej, ose diçka tjetër. Por vazhdimisht më dilnin produkte, të cilat ishin ose mjaft të rrepta, ose të shtrenjta dhe gjithashtu të ngurta. Megjithatë, e gjeta një instalues falas, në të cilin mund të parashikoja çdo dëshirë. Ky është InnoSetup. Po shkruaj këtu për këtë, sepse më duhej të kërkoja, ndoshta do t'i kursej ndokujt kohë.
Heqja e plugin-it në favor të klientit të tij
Unë kam shkruar më parë se pjesa e klientit ishte një shfletues me 'plugin'. Kështu që kishte kohë kur, ndonjëherë Chrome përditësohej dhe dizajni doli paksi i çrregullt, ndonjëherë Windows përditësohej dhe skema custom uri humbte. Nuk doja aspak të kisha këtë lloj surprizash në versionin publik të produktit. Për më tepër, skemat custom uri filluan të humbnin pas çdo përditësimi të Windows. Microsoft thjesht fshin të gjitha degët që nuk ishin të sajat në pjesën e nevojshme. Gjithashtu, Google Chrome tani nuk lejon të ruhet zgjedhja për të hapur ose jo aplikacionin nga custom uri, dhe e përsërit këtë pyetje me çdo klikim në objektin e monitorimit. Në përgjithësi, ishte e nevojshme të kishim një ndërveprim normal me sistemin lokal të përdoruesit, diçka që shfletuesi nuk e ofron. Varianteja më e thjeshtë në një skemë të tillë duket thjesht të bëjmë shfletuesin tonë, siç bëjnë shumë tani përmes Electron. Por tashmë shumë gjëra ishin shkruar në Free Pascal, përfshirë pjesën server, prandaj u vendos të bëjmë edhe klientin në të njëtin gjuhë, e jo të krijojmë një kopsht zoologjik. Kështu u shkrua klienti me Chromium në bordin e tij. Pas kësaj, ai filloi të mbushej me lidhje të ndryshme.
Lëshimi
Mundësisht përzgjodhëm emrin për sistemin. Gjithmonë jemi duke shqyrtuar mundësi të ndryshme gjatë procesit të kalimit nga versioni lokal në SaaS. Që në fillim planifikonim të dilnim jo vetëm në tregun e brendshëm, prandaj kriteri kryesor përzgjedhjes ishte disponueshmëria e një domeni të lirë, ose jo shumë të shtrenjtë në zonën “.com”. Disa funksione/modulë ende nuk ishin portuar nga versioni lokal në Veliam, por vendosëm që do të lansojmë me funksionalitetin aktual dhe do të përmirësojmë pjesën tjetër si përditësime. Versioni më i parë nuk kishte HelpDesk, Veliam Connector, nuk ishte e mundur të ndaheshin kufijtë e aktivizimit të njoftimeve dhe shumë gjëra të tjera. Blerëm Certifikatën e Nënshkrimit të Kodit, nënshkruam pjesët e klientit dhe serverit. Krijuam një website për produktin, filluam procedurat për regjistrimin e softuerit, markës tregtare, etj. Në përgjithësi, jemi gati të fillojmë. Një entuziazëm i lehtë për punën e bërë dhe mendimi se mund të ketë dikush që do ta përdorë produktin tuaj, pavarësisht se për këtë kishim dyshime. Dhe këtu ndal. Partneri tha se nuk mund të hyhet në treg pa njoftime në mesazherë. Mund të shkojë pa shumë gjëra të tjera, por jo pa këtë. Pas disa mosmarrëveshjeve të shkurtra, u shtua integrimi me Telegram, i cili na plotësoi. Nga të gjitha mesazherët aktualë, kjo është e vetmja që ofron qasje në API-të e saj pa pagesë dhe pa procedura të ndërlikuara miratimi. WhatsApp ofron të kontaktoni me ofruesit, të cilët marrin një shumë të mirë për shërbimet e tyre, dhe të gjitha kërkesat për qasje pa ndërmjetës u injoruan. Sa i përket Viber... Nuk e di se kush e përdor tani, pasi spam dhe reklamat janë tejet të shumta. Në fund të dhjetorit, pas serive të testimeve të brendshme dhe testimeve mes miqve, hapëm regjistrimin për të gjithë dhe nxorrëm softuerin për shkarkim.
Fillimi i shpërndarjes
Që nga fillimi, ne kuptuam se na duhej një numër i vogël përdoruesish të sistemit që të testonin produktin në mënyrë aktive dhe të ofronin ndonjë feedback të parë. Disa postime të blera në VK dhanë rezultatet e para. Registrimet e para filluan.
Është e rëndësishme të theksohet se është shumë e vështirë të hysh në treg kur kompania jote nuk ka një emër të njohur, dhe përveç kësaj ofron një funksionalitet paagjent të monitorimit, për të cilin nevojitet të futen akountet e serverëve dhe stacioneve të punës. Kjo frikëson shumë njerëz. Që në fillim ne ishim të vetëdijshëm që do të kishim probleme me këtë, dhe ishim të përgatitur si teknikisht ashtu edhe moralisch. Të gjitha lidhjet e largëta, pavarësisht se RDP dhe SSH janë të enkriptuara në mënyrë të paracaktuar, enkriptohen për më tepër nga softueri ynë sipas standardit AES. Të dhënat nga serverët lokalë transferohen në cloud përmes HTTPS. Akuntet mbahen në formë të enkriptuar. Çelësat e enkriptimit për të gjitha nën-sistemet janë individual për çdo klient. Për lidhjet e largëta, përdoren çelësat sesionit për enkriptim.
E gjithë çfarë mund të bëjmë në këtë situatë për t'i bërë njerëzit të ndjehen më të qetë është të jemi sa më të hapur, të punojmë në sigurinë dhe të mos lodhemi duke iu përgjigjur pyetjeve që i shqetësojnë ata.
Për shumë, komforti dhe funksionaliteti i softuerit e tejkalojnë frikën, dhe ata regjistrohen. Disa persona në postimet e publikuara në VK kanë shkruar se ky softuer nuk mund të përdoret sepse mbledh fjalëkalimet e tyre dhe është një kompani të panjohur. Duhet thënë se kjo mendim nuk ishte vetëm i një personi. Shumë thjesht nuk e kuptojnë se, kur vendosin një softuer tjetër pronar në serverin e tyre, i cili punon si shërbim, gjithashtu ka të drejta të plota në sistem dhe nuk kanë nevojë për llogari për të bërë diçka të paligjshme (sigurisht, mund të ndryshoni përdoruesin që ekzekuton shërbimin, por edhe këtu, mund të futni çdo llogari). Në të vërtetë — shqetësimet e njerëzve janë të kuptueshme. Instalimi i softuerit në server është një aktivitet i zakonshëm, ndërsa futja e llogarisë është pak më e frikshme dhe intime, pasi gjysma e mirë e njerëzve ka një fjalëkalim për të gjithë shërbimet, dhe të krijosh një llogari të veçantë edhe për testim është e lodhshme. Por në këtë moment ka një numër të madh shërbimesh që njerëzit i besojnë të dhënat e tyre dhe jo vetëm. Dhe ne synojmë të bëhemi një nga ato.
I shumë komente ishin të natyrës që ne e kemi vjedhur këtë ndonjëherë. Na befasoi pak. Mirë, është mendimi i një personi, por komente të tilla janë shfaqur në publikime të ndryshme nga njerëz të ndryshëm. Në fillim nuk e dinim se si të reagonim për këtë. Të trishtoheshim që disa njerëz mendojnë se në Rusi askush nuk mund të bëjë asgjë vetë, por vetëm të vjedhë, apo të gëzohemi që mendojnë se diçka e tillë mund të vjedhet vetëm.
Tani ne përfundimisht kemi mbyllur procedurën për të marrë Certifikatën EV Code Sign. Për ta marrë atë, është e nevojshme të kalosh një sërë kontrollesh dhe të dërgosh shumë dokumente për kompaninë, disa nga të cilat duhet të vërtetohen nga një avokat. Marrja e certifikatës EV Code Sign nën kushtet e pandemisë është një temë krejtësisht e veçantë për një artikull. Procedura zgjati një muaj. Dhe ky ishte një muaj jo pritjeje, por kërkesash të vazhdueshme për dokumente shtesë. Ndoshta pandemia nuk ka lidhje me këtë, dhe të gjithë e kaluan procedurën kaq ngadalë? Ndani mendimet tuaja.
Disa disa thonë se nuk do të përdorim, sepse nuk ka çertifikatë FSTEK. Na duhet të shpjegojmë se ne nuk mund ta marrim atë dhe nuk do ta marrim, sepse për të marrë këtë çertifikatë - enkriptimi duhet të jetë sipas GOST, ndërsa ne planifikojmë të shpërndajmë softuerin jo vetëm në Rusi dhe përdorim AES.
Të gjithë këta komente sjellin një shkallë të caktuar pasigurie përsa i përket mundësisë - për të promovuar një produkt në të cilin duhet të regjistrohesh, pa qënë në fakt në vëmendje. Edhe me faktin se ne e dinim se do të kishte ata që do e përqendronin negativisht. Pasi numri i regjistrimeve kaloi mijë, ne ndaluam së menduari për këtë. Sidomos pas faktit që, përveç negativizmit të atyre që nuk e provojnë produktin, filluan të shfaqen edhe komente shumë pozitive. Duhet thënë se këto komentet pozitive janë motivatori më i madh për zhvillimin e produktit.
Shtimi i funksionalitetit të qasjes së largët për punonjësit
Një nga detyrat e zakonshme nga klientët është "bëni që Vani të ketë qasje në kompjuterin e tij nga shtëpia". Ne ngremë një VPN në mikrotik dhe krijonim llogari për përdoruesit. Por kjo është vërtet një problem. Përdoruesit nuk janë në gjendje të lexonin udhëzimin dhe ta ndjekin atë hap pas hapi për t'u lidhur përmes VPN. Versionet e ndryshme të Windows. Në një version të Windows, gjithçka lidhet mirë, ndërsa në tjetrin nevoja për një protokoll tjetër. Dhe në përgjithësi, kjo gjithmonë ishte e lidhur me ri-konfigurimin e pajisjeve rrjetëse që shërbenin si server VPN, dhe jo të gjithë punonjësit kanë qasje në to, gjë që ishte e pakëndshme.
Por ndryshe, ne kemi tashmë lidhje të largëta me serverët dhe pajisjet rrjetore. Pse të mos shfrytëzojmë transportin që është gati dhe të krijojmë një utilitar të vogël që mund ta japim thjesht përdoruesit për t'u lidhur. Do të dëshironim të bënim që përdoruesi të mos kishte nevojë të shkruante ndonjë gjë të komplikuar. Thjesht një buton "lidhu". Por si do ta dinte ky utilitar ku të lidhej, nëse kishte vetëm një buton? Ishte një ide për të ndërtuar online aplikacionin e nevojshëm në serverët tanë. Administratorët e sistemit do të klikonin butonin "shkarko ikonën", dhe një komandë do të dërgohej në cloud për të ndërtuar një binar të personalizuar me informacionin e lidhjes për serverin / kompjuterin e kërkuar për RDP. Në përgjithësi, kjo mund të bëhej. Por, kjo do të ishte e gjatë, administratorët do të prisnin fillimisht që binari të kompilonte dhe pastaj të shkarkohej. Sigurisht, mund të shtonim thjesht një skedar të dytë me konfigurimin, por kjo do të thoshte dy skedarë, dhe për thjeshtësinë e përdoruesit ne duam një. Një skedar, një buton dhe asnjë instalues. Pas një hulumtimi të vogël në Google, arrita në përfundimin se, nëse në fund të " .exe" të kompiluar shtojmë ndonjë informacion, ai nuk prish rezultatin (pothuajse). Mund të shtosh madje edhe "Luftën dhe Paqen", dhe ai do të funksionojë si më parë. Është një mëkat të mos e shfrytëzosh këtë. Tani mund të zbërthej aplikacionin në lëvizje, dhe me rastin, emri i tij është Veliam Connector, dhe thjesht të shtoj në fund informacionin e nevojshëm për lidhjen. Aplikacioni vetë e di se çfarë të bëjë me këtë. Pse e kam shkruar pak më lart në parantezë "pothuajse"? Për shkak se për këtë lehtësi duhet të paguash duke humbur nënshkrimin e tij të certifikatës digjitale. Por ne, në këtë fazë, mendojmë se kjo është një çmim i vogël për një lehtësi të tillë.
Licencat e moduleve të palëve të treta
Më parë kam shkruar se pasi u vendos të bëhej produkti publik dhe jo vetëm për përdorim personal, mushoj dhe kërkova alternativa për disa module që nuk lejonin të ishin përfshirë në produktin tonë. Por pas lansimit, rastësisht u zbulua një gjë tepër e pakëndshme. Në përbërje të Veliam Server, i cili ishte në anën e klientit, kishte një DBMS MariaDB. Dhe ajo kishte licencën GPL. Licenca GPL parashikon që softi duhet të jetë me kod të hapur, dhe nëse në produktin tonë përfshihet MariaDB e cila ka këtë licencë, atëherë edhe produkti ynë duhet të jetë nën këtë licencë. Por fatmirësisht, qëllimi i kësaj licence është kod i hapur dhe jo ndëshkimi në gjykatë të atyre që kanë bërë ndonjë gabim aksidental. Nëse titullari i të drejtave ka një pretendim, ai e njofton me shkrim shkelësin dhe ai duhet brenda 30 ditëve të eliminojë shkeljen. Ne e zbuluam gabimin tonë vetë dhe nuk morëm letra dhe menjëherë filluam të shqyrtonim mundësi për të zgjidhur problemin. Zgjidhja ishte e qartë — kalimi në SQLite. Ky DB nuk ka asnjë kufizim lidhur me licencimin. Shumica e shfletuesve modernë përdorin SQLite, ashtu si shumë programe të tjera. Kam gjetur në internet informacion që SQLite konsiderohet si DBMS më i përhapur në botë, pikërisht për shkak të shfletuesve, por nuk kërkova prova, kështu që kjo është informacion jo i saktë. Kam filluar të studioj çfarë ndjesh kalimi në SQLite.
Kjo bëhet një detyr e paqëndrueshme kur ka disa qindra serverë të instaluar te klientët me MariaDB dhe të dhëna në të. Disa funksione të MariaDB nuk janë të disponueshme në SQLite. Për shembull, në kod u përdorën kërkesa si
Select * FROM `table` WHERE `id`>1000 FOR UPDATE
Ky konstruksion bën jo vetëm seleksionimin nga tabela, por edhe bllokon ato rreshta të dhënash. Gjithashtu, disa konstruksione të tjera duhej të rishkruheshin. Por, përveç faktit që duhej të rishkruaja shumë kërkesa, gjithashtu duhej të mendonim një mekanizëm që, gjatë azhurnimit të Veliam Server te klientët, do të eksportonte të gjitha të dhënat në një SGBD të re dhe do të fshinte të vjetrën. Për më tepër, transaksionet në SQLite nuk funksiononin dhe kjo ishte një problem real. Por pasi lexova në hapësirat e internetit, e gjeta lehtësisht se transaksionet në SQLite mund të aktivizohen duke dërguar një komandë të thjeshtë gjatë lidhjes
PRAGMA journal_mode=WAL;Në fund, detyra u përfundua dhe tani pjesa serverike te klientët punon në SQLite. Nuk kemi vënë re ndonjë ndryshim në funksionimin e sistemit.
HelpDesk i ri
Nga versioni i brendshëm në versionin SaaS, duhej të portoheshin sistemin HelpDesk, por me disa ndryshime. E para që dëshironim të bënim ishte integrimi me domenin e klientit për autorizimin e përdoruesve në sistem. Tani, për të hyrë në HelpDesk dhe për të lënë një kërkesë në sistem, përdoruesi thjesht klikon mbi ikonën në desktop dhe hapet shfletuesi. Përdoruesi nuk ka nevojë të futë asnjë informacion identifikimi. Moduli për Apache SSPI, i cili është pjesë e Veliam Server, autorizon automatikisht përdoruesin me llogarinë e tij të domenit. Për të lënë një kërkesë në sistem, kur përdoruesi është jashtë rrjetit korporativ, ai klikon mbi butonin dhe një lidhje dërgohet në emailin e tij, me të cilën autorizohet në sistemin HelpDesk pa fjalëkalime. Nëse përdoruesi fiket ose fshihet nga domeni, atëherë llogaria e tij në HelpDesk gjithashtu do të ndalojë së funksionuari. Në këtë mënyrë, administratori i sistemit nuk ka nevojë të ndjekë llogaritë si në domen ashtu edhe në HelpDesk. Nëse një punonjës është shkarkuar — ai fik llogarinë në domen dhe gjithçka, ai nuk hyn në sistem as jashtë rrjetit korporativ, as përmes lidhjes. Për të operuar këtë integrim, administratorit të sistemit i nevojitet të krijojë një GPO, e cila dhe .
E dyta që e konsiderojmë shumë të nevojshme për sistemet HelpDesk, të paktën për ne vetë — është lidhja me aplikuesin drejtpërdrejt nga kërkesa me një klik. Për më tepër, lidhjet duhet të funksionojnë nëse administratori i sistemit është në një rrjet tjetër. Kjo është e domosdoshme për outsourcing-un, dhe shpesh e nevojshme edhe për administratorët e sistemit të punësuar. Ka disa produkte që e menaxhojnë mirë detyrën e lidhjeve të largëta. Ne vendosëm të bëjmë integrime për ta. Tani kemi bërë integrimin për VNC, dhe në të ardhmen planifikojmë të shtojmë Radmin dhe TeamViewer. Duke përdorur transportin tonë rrjetësor për lidhje të largëta me infrastrukturën, ne e bëmë që VNC të lidhet me stacionet e punës përmes NAT. E njëjta do të ndodhë edhe me Radmin. Tani, për t'u lidhur me përdoruesin, është e mjaftueshme të klikohet butoni "lidhu me aplikuesin" në vetë kërkesën. Hapet klienti VNC dhe lidhet me aplikuesin pavarësisht nëse jeni në të njëjtin rrjet me të ose në shtëpi në pantofla. Më parë, administratori i sistemit duhet të instalohet në të gjitha stacionet e punës VNC Server përmes GPO.
Aktualisht po kalojmë në një HelpDesk të ri dhe po shfrytëzojmë integrimin me domenin dhe VNC. Kjo është shumë e përshtatshme për ne. Tani mund të mos paguajmë për TeamViewer, që e kemi përdorur për më shumë se tre vjet për punën e shërbimit tonë të mbështetjes.
Çfarë planifikojmë të bëjmë më pas
Kur ne kemi lansuar produktin, ne nuk bëmë asnjë tarifë pagese, por thjesht kufizuam planin falas në 50 objekte monitorimi. Pesëdhjetë pajisje rrjeti dhe serverë duhet të jenë të mjaftueshme për të gjithë, menduam ne. Dhe pastaj filluan të vijnë kërkesa për të rritur kufirin. Të themi se ishim pak të habitur - nuk ka dyshim. A mund të besojmë se kompania jonë kishte interes për kompani që kishin kaq shumë serverë? Ne me kostot e paanshme zgjerojmë kufirin për ata që bënin këto kërkesa. Disa prej tyre, në përgjigje të kërkesës së tyre, pyetëm pse u duhej kaq shumë, a kishin vërtet kaq shumë serverë dhe pajisje rrjeti. Dhe rezultoi se administratorët e sistemeve filluan të përdorin sistemin në një mënyrë që ne as nuk e kishim planifikuar. Të gjitha ishin të thjeshta - ata filluan të monitoronin jo vetëm serverat, por edhe stacionet e punës me softin tonë. Prandaj kemi pasur kaq shumë kërkesa për zgjerimin e kufijve. Tani ne kemi futur tarifat e paguara dhe kufijtë mund të zgjerohen vetë.
Serverat, pothuajse gjithmonë punojnë me ose me ruajtje të brendshme ose me disqe të vendosur në RAID. Ne e krijuam fillimisht produktin për ta. Dhe monitorimi SMART nuk ishte interesant për këtë detyrë. Por meqenëse njerëzit e përshtatën softin për monitorimin e stacioneve të punës, kërkesat për realizimin e monitorimit SMART u shfaqën. Shpejt do ta realizojmë atë.
Me shfaqjen e Veliam Connector, u bë e panevojshme të vendoset një server VPN në rrjetin korporativ, ose të bëhet RDGW, ose thjesht të hapen portet për makinat e nevojshme për lidhjet RDP. Shumë njerëz e përdorin sistemin tonë vetëm për këto lidhje të largëta. Veliam Connector është vetëm për Windows, ndërsa disa përdorues të kompanive lidhen me stacionet e punës ose terminalet në rrjetin korporativ nga laptopët e tyre me MacOS. Dhe kjo do të thotë se administratorët e sistemeve janë të detyruar, për shkak të disa përdoruesve, të kthehen sërish në çështjen e hapjeve të portit ose VPN. Prandaj tani po përfundojmë versionin e Veliam Connector për MacOS. Përdoruesit e pajisjeve të tyre të preferuara nga Apple gjithashtu do të kenë mundësinë të lidhen në një klikim me infrastrukturën korporative.
Më pëlqen shumë që, me numrin e madh të përdoruesve të sistemit, nuk duhet të shqetësohem se çfarë iu nevojitet njerëzve dhe çfarë do të ishte më e përshtatshme. Ata vetë shkruajnë dëshirat e tyre, kështu që ka shumë plane për zhvillim në afat të shkurtër.
Për paralel, tani planifikojmë të merremi me përkthimin e sistemit në anglisht dhe me shpërndarjen e tij jashtë vendit. Ende nuk e dimë se si do të shpërndajmë produktin jashtë vendit tonë, jemi duke kërkuar mundësi. Ndoshta më vonë do të ketë një artikull të veçantë për këtë. Ndoshta ndonjë nga ata që lexuan këtë artikull do të mund të na ndihmojë me drejtimin e duhur, ose që e di dhe mund të ofrojë shërbimet e tij. Do të ishim të mirënjohur për ndihmën.
Burimi: habr.com
