В , я распавёў аб перадгісторыі стварэння Veliam і аб рашэнні яго распаўсюджванні па сістэме SaaS. У гэтым артыкуле, я раскажу аб тым, што прыйшлося зрабіць што б прадукт стаў не лакальным, а публічным. Аб тым, як пачыналі распаўсюджванне і з якімі праблемамі сутыкнуліся.
планаванне
Бягучая серверная частка для карыстачоў была на Linux. Амаль у кожнай арганізацыі ёсць Windows серверы, чаго нельга сказаць аб Linux. Асноўны моцны бок Veliam – выдаленыя падлучэнні да сервераў і сеткавага абсталявання за NAT. Але гэты функцыянал быў вельмі цвёрда завязаны на тое, што маршрутызатарам павінен быў быць абавязкова мікратык. І гэта відавочна шматлікіх бы не задавальняла. Я спачатку пачаў думаць аб тым, каб дадаць падтрымку маршрутызатараў самых распаўсюджаных вендараў. Але я разумеў, што гэта бясконцая гонка з пашырэннем спісу падтрымліваемых фірмаў. Больш за тое, так і тыя, якія ўжо падтрымліваюцца, могуць ад мадэлі да мадэлі мець розны набор каманд для змены правіл NAT. Адзіным выйсцем з сітуацыі бачыўся VPN.
Бо мы вырашылі распаўсюджваць прадукт, але не як open source, то і ўключаць у свой склад розныя бібліятэкі з адчыненымі ліцэнзіямі тыпу GPL стала нельга. Гэта ўвогуле асобная тэма, пасля прыняцця рашэння аб продажы прадукта, прыйшлося перабраць палову бібліятэк з-за таго, што яны былі GPL. Калі пісалі пад сябе, гэта было нармальна. Але для распаўсюджвання не падыходзіць. Першы ж VPN які прыходзіць у галаву – OpenVPN. Але ён GPL. Яшчэ быў варыянт выкарыстоўваць японскі SoftEther VPN. Яго ліцэнзія дазваляла ўключыць яго ў склад свайго прадукта. Пасля пары дзён розных тэстаў як інтэграваць яго такім чынам, каб карыстачу наогул нічога не трэба было наладжваць і ведаць пра SoftEther VPN – атрымаўся прататып. Усё было як трэба. Але чамусьці нас гэтая схема ўсё роўна бянтэжыла, і мы ад яе ў выніку адмовіліся. Але натуральна адмовіліся пасьля таго, як прыдумалі іншы варыянт. У выніку ўсё зрабілі на звычайных TCP злучэннях. Частка падлучэнняў працуе праз каардынатар, частка напрамую праз тэхналогію Nat Hole Punching (NHP), якая таксама рэалізоўвалася на Free Pascal. Трэба сказаць, што пра NHP я раней увогуле нават не чуў. І ў галаву не магло прыйсці, што можна звязаць 2 сеткавыя прылады, абодва з якіх знаходзяцца за NAT напрамую. Праштудзіраваў тэму, зразумеў прынцып працы і сеў пісаць. Задуманае ажыццёўлена, карыстач падлучаецца адным клікам да патрэбнай прылады за NAT па RDP, SSH або Winbox без уводу пароляў і налады VPN. Прычым большая частка гэтых падлучэнняў ідзе міма нашага каардынатара, што добра адбіваецца на пінгу і сабекошту абслугоўвання гэтых падлучэнняў.
Пераклад сервернай часткі з Linux на Windows
Праблем пры пераходзе на Windows было адразу некалькі. Першая - убудаваны wmic у windows не дазваляе рабіць WQL запыты. А ў нашай сістэме ўжо ўсё было пабудавана на іх. І было яшчэ нешта, але зараз забыўся чаму канчаткова адмовіліся ад яго выкарыстання. Магчыма, адрозненні паміж версіямі Windows. І другая праблема - шматструменнасць. Не знайшоўшы добрай іншай утыліты пад "дапушчальнай" для нас ліцэнзіяй, я зноў запусціў IDE Lazarus. І напісаў неабходную ўтыліту. На ўваход падаецца патрэбны спіс аб'ектаў і якія менавіта запыты трэба рабіць, а ў адказ атрымліваю даныя. І ўсё гэта ў шматструменным рэжыме. Выдатна.
Пасля таго як наладзіў pthreads для PHP Windows думаў, што ўсё прамы запусціцца, але не тут-то было. Па сканчэнні некаторага часу адладкі, я зразумеў, што pthreads накшталт працуе, але менавіта ў нашай сістэме не працаваў. Стала зразумела, што ёсць нейкая асаблівасць працы з pthreads у Windows. Так яно і было. Прачытаў дакументацыю, і тамака было напісана, што для Windows лік струменяў абмежавана, прычым, наколькі я памятаю няяўна. Гэта стала праблемай. Таму што, калі я пачаў скарачаць колькасць патокаў, пры якіх прыкладанне працавала, яно рабіла працу вельмі марудна. Ізноў адкрыў IDE і ў тую ж утыліту быў дададзены функцыянал па шматструменнай прапінгоўцы аб'ектаў. Ну і да кучы ўжо і сканіраванне партоў туды ж. Уласна, пасля гэтага, неабходнасць у pthreads для PHP знікла, і ен больш не выкарыстоўваецца. Далей у гэтую ўтыліту былі дададзены яшчэ некалькі функцыяналаў і працуе яна дагэтуль. Пасля гэтага быў сабраны ўсталёўшчык для Windows, які складаўся з Apache, PHP, MariaDB, само PHP прыкладанне і набор утыліт для ўзаемадзеяння з сістэмай, напісаных на Free Pascal. Што да ўсталёўніка, то я думаў, што гэтае пытанне хутка вырашу, т.к. гэта звыш распаўсюджаная і патрэбная амаль для кожнага софту рэч. Ці то я не так шукаў, ці то яшчэ нешта. Але мне трапляліся ўвесь час прадукты, якія былі альбо недастаткова гнуткія, альбо дарагія і пры гэтым таксама нягнуткія. І ўсёткі я знайшоў бясплатны ўсталёўшчык, у якім можна будзе прадугледзець любыя жаданні. Гэта InnoSetup. Пішу тут аб гэтым, таму што мне прыйшлося пашукаць, раптам я камусьці зэканомлю час.
Адмова ад плагіна на карысць свайго кліента
Я раней пісаў, што кліенцкай часткай быў браўзэр з «плагінам». Дык вось былі такія часы, калі, то Chrome абновіцца і вёрстка трохі крывіцца, то Windows абновіцца і custom uri scheme злятаюць. Вельмі не хацелася мець такога роду сюрпрызы ў публічнай версіі прадукта. Прычым, custom uri пачалі злётаць пасля кожнага абнаўлення Windows. Microsoft папросту выдаляла ўсё не яе галінкі ў патрэбнай частцы. Таксама Google Chrome зараз не дазваляе запомніць выбар адчыняць ці не прыкладанне з custom uri, і задае гэтае пытанне пры кожным кліку на аб'ект маніторынгу. Ну і ў цэлым, неабходна было звычайнае ўзаемадзеянне з лакальнай сістэмай карыстача, чаго браўзэр не дае. Самы проста варыянт у такой схеме бачыцца проста зрабіць свой браўзэр, як многія зараз робяць праз Electron. Але ўжо многія рэчы былі напісаны на Free Pascal, у тым ліку ў сервернай частцы, таму вырашылі і кліент зрабіць на той жа мове, а не пладзіць заапарк. Так быў напісаны кліент з Chromium на борце. Пасля гэтага ён пачаў абрастаць рознымі абвязкамі.
Рэліз
Нарэшце выбралі назву для сістэмы. Мы ўвесь час перабіралі розныя варыянты пакуль ішоў працэс перараблення з лакальнай версіі ў SaaS. Бо мы першапачаткова планавалі выйсце не толькі на ўнутраны рынак, то асноўным крытэрам падбору назову была наяўнасць незанятага, ці не вельмі дарагога дамена ў зоне ".com". Некаторыя функцыі/модулі яшчэ не былі партаваныя з лакальнай версіі ў Veliam, але мы вырашылі, што будзем выпускаць з бягучым функцыяналам, а астатняе дарабляць ужо ў выглядзе абнаўленняў. У самай першай версіі не было HelpDesk'а, Veliam Connector'а, нельга было змяняць парогі спрацоўвання трыгераў апавяшчэнняў і шматлікае іншае. Купілі Code Sign Certificate, падпісалі кліенцкую і серверную часткі. Напісалі сайт для прадукта, пачалі працэдуры рэгістрацыі праграмнага забеспячэння, таварнага знака і г.д. Увогуле гатовы пачынаць. Лёгкая эйфарыя ад праведзенай працы і ад таго, што магчыма тваім прадуктам будзе нехта карыстацца, хоць з гэтай нагоды ў нас не было сумневаў. І тут стоп. Партнёр сказаў, што без апавяшчэнняў у мэсэнджэры выходзіць на рынак нельга. Можна без шмат чаго іншага, але не без гэтага. Пасля непрацяглых спрэчак, была дададзена інтэграцыя з Telegram, якая нас задаволіла. З усіх бягучых месэнджараў, гэта адзіны, які дае доступ да сваіх API бясплатна і без якіх-небудзь складаных працэдур узгадненняў. Той жа WhatsApp прапануе звяртацца да правайдэрам, якія бяруць нядрэнныя грошы за карыстанне іх паслугамі, усе лісты з просьбай даць доступ без пракладак былі праігнараваны. Ну а вайбер… Я не ведаю хто ім карыстаецца зараз, т.я. спам і рэклама тамака зашкальваюць. У канцы снежня, пасля шэрагу ўнутраных тэсціраванняў, і тэсціраванняў сярод сяброў, адкрылі рэгістрацыю для ўсіх і выклалі софт для запампоўкі.
Пачатак распаўсюджвання
З самага пачатку мы разумелі, што нам патрэбен невялікі струмень карыстачоў сістэмы для таго, каб яны ўжо ў баявым рэжыме пратэставалі прадукт і далечы нейкі першы фідбэк. Некалькі набытых пастоў у ВК далі плён. Пайшлі першыя рэгістрацыі.
Тут трэба сказаць, што выходзіць на рынак, калі ў тваёй кампаніі няма знакамітага імя, і пры гэтым падаваць функцыянал безагентнага маніторынгу, у які трэба ўводзіць уліковыя запісы ад сваіх сервераў і працоўных станцый, вельмі няпроста. Вельмі шмат людзей гэта палохае. Мы з самага пачатку разумелі, што з гэтым будуць праблемы і былі гатовы да гэтага і тэхнічна і маральна. Усе выдаленыя падлучэнні, нягледзячы на тое, што RDP і SSH дык вось, шыфруюцца па змаўчанні, дадаткова шыфруюцца нашым софтам па стандарце AES. Усе дадзеныя з лакальных сервераў перадаюцца ў воблака па HTTPS. Уліковыя запісы захоўваюцца ў зашыфраваным выглядзе. Ключы шыфравання для ўсіх падсістэм ва ўсіх кліентаў індывідуальныя. Для выдаленых падлучэнняў наогул выкарыстоўваюцца сеансавыя ключы шыфравання.
Усё, што мы можам рабіць у гэтай сітуацыі, каб людзям было спакайней - гэта быць максімальна адкрытымі, працаваць над бяспекай і не стамляцца адказваць людзям на хвалюючыя іх пытанні.
Для многіх, зручнасць і функцыянал софту перавешваюць страх, і яны рэгіструюцца. Некаторыя асобы ў апублікаваных пастах у ВК пісалі, што гэтае ПЗ выкарыстоўваць нельга т.к. гэта зборка іх пароляў і наогул ноўнэйм кампанія. Трэба сказаць, што такое меркаванне было не ў аднаго чалавека. Шмат хто проста не разумее, што, калі яны ставяць да сябе іншы прапрыетарны софт на сервер, які працуе як служба, сапраўды гэтак жа мае поўныя правы ў сістэме і ім не патрэбныя ўлікі для таго каб рабіць нешта супрацьпраўнае (зразумела, што можна змяніць карыстальніка ад якога запускаецца служба, але так і тут, уводзіць можна уліковы запіс любую). Насамрэч - асцярогі людзей зразумелыя. Усталёўка софту на сервер - гэтая справа звыклае, а вось увод уліковага запісу - гэта ўжо трохі страшна і інтымна, бо ў добрай паловы людзей адзін пароль на ўсе сэрвісы, а рабіць асобны ўлік нават для тэсту ляніва. Але на дадзены момант ёсць вялікая колькасць сэрвісаў, якім людзі давяраюць свае ўліковыя дадзеныя і не толькі. І мы імкнемся стаць аднымі з іх.
Шмат каментароў было такога плана, што мы недзе гэта скралі. Нас гэта крыху здзівіла. Ну добра меркаванне аднаго чалавека, але такія каментары сустракаліся ў розных публікацыях ад розных людзей. Не ведалі спачатку як на гэта рэагаваць. Ці то сумаваць аб тым, што ў некаторых людзей меркаванне, што ў Расіі ніхто нічога не можа зрабіць сам, а можа толькі выкрасці ці то радавацца, што лічаць, што такое можна толькі выкрасці.
Цяпер мы завяршылі працэдуру атрымання EV Code Sign Certificate. Для яго атрымання неабходна прайсці шэраг праверак і адправіць кучу дакументаў аб кампаніі, частка з якіх павінны быць завераны адвакатам. Атрыманне EV Code Sign сертыфіката ва ўмовах пандэміі - гэта наогул асобная тэма для артыкула. Працэдура зацягнулася на месяц. І гэта быў месяц не чакання, а пастаянных запытаў дадатковых дакументаў. Можа пандэмія тут няма пры чым, і ва ўсіх працэдура праходзіла так доўга? Падзяліцеся.
Некаторыя гавораць, што не будзем карыстацца таму, што няма сертыфіката ФСТЭК. Даводзіцца тлумачыць, што мы не можам яго атрымаць і не будзем таму, што для атрымання гэтага сертыфіката – шыфраванне павінна быць па ДАСТ, а мы плануем распаўсюджванне ПЗ не толькі ў Расіі і выкарыстоўваем AES.
Усе гэтыя каментары навявалі некаторую няўпэўненасць у тым, што гэта магчыма - прасоўваць прадукт у які трэба ўводзіць уліковыя запісы, не будучы пры гэтым на слыху. Нават з улікам таго, што мы ведалі, што будуць тыя, хто вельмі негатыўна ставіцца да гэтага. Пасля таго як колькасць рэгістрацый пераваліла за тысячу, мы перасталі аб гэтым думаць. Асабліва пасля таго як апроч негатыву тых, хто нават не спрабаваў прадукт, сталі з'яўляцца і вельмі прыемныя водгукі. Трэба сказаць, што гэтыя пазітыўныя водгукі – самы вялікі матыватар да развіцця прадукта.
Даданне функцыяналу выдаленага доступу для супрацоўнікаў
Адна з частых задач ад кліентаў з'яўляецца "зрабіце Ваню доступ да яго кампутара з дому". Паднімалі VPN на мікрацік і рабілі для карыстачоў улікоўкі. Але гэта рэальна праблема. Карыстальнікі не ў стане глядзець інструкцыю і зрабіць яе па кроках каб падключыцца па VPN. Розныя версіі Windows. У адной віндзе ўсё добра падключаецца, у іншай патрэбен іншы пратакол. І ўвогуле гэта заўсёды было злучана з пераналадкай сеткавага абсталявання, якое выступала серверам VPN, а не ва ўсіх супрацоўнікаў ёсць да яго доступ і гэта было няёмка.
Але ў нас жа ўжо ёсць выдаленыя падлучэнні да сервераў і сеткавага абсталявання. Чаму б не скарыстацца гатовым транспартам і не зрабіць асобную ўтыліту маленькага памеру, якую можна проста даць карыстачу для падлучэння. Жадалася толькі зрабіць так, каб карыстач там нічога не ўводзіў разумнага. Проста адна кнопка "падключыцца". Але як гэтая ўтыліта будзе разумець куды падлучацца, калі ў ёй толькі адна кнопка. Была ідэя онлайн зборкі патрэбнага дадатку на нашых серверах. Сістэмны адміністратар націскае кнопку "спампаваць ярлык", і да нас у воблака падаецца каманда на зборку індывідуальнага бінарніка з зашытай інфармацыяй па падлучэнні да патрэбнага сервера / кампутара па RDP. У цэлым гэта можна было зрабіць. Але гэта доўга, адміністратару прыйшлося б чакаць спачатку пакуль бінарнік скампілюецца, а потым і спампуецца. Можна было б вядома дадаць проста другі файлік з канфігам, але гэта ўжо 2 файла, а для прастаты карыстачу патрэбен адзін. Адзін файлік, адна кнопка і ніякіх усталёўшчыкаў. Пачытаўшы крыху прасторы гугла, я прыйшоў да высновы што, калі ў канец скампіляванага ".exe" дадаць нейкую інфармацыю, то ён не псуецца (ну амаль). Туды можна хоць вайну і мір дадаць, і ён будзе працаваць, як і раней. Грэх гэтым не скарыстацца. Цяпер можна проста на хаду прама ў самім кліенце распакоўваць дадатак, дарэчы яно называецца Veliam Connector, і проста дапісваць да яго ў канец патрэбную для падключэння інфармацыю. А ўжо само прыкладанне ведае, што з гэтым рабіць. Чаму я крыху вышэй у дужках напісаў "ну амаль"? Таму, што за гэтую зручнасць даводзіцца плаціць тым, што дадатак губляе свой подпіс ЭЛП. Але мы, на дадзеным этапе, лічым, што гэта невялікі кошт за такую зручнасць.
Ліцэнзіі іншых модуляў
Вышэй я ўжо пісаў, што пасля таго як было вырашана зрабіць прадукт агульнадаступным, а не толькі для свайго карыстання, прыйшлося ладна папрацаваць і пашукаць замены некаторым модулям, якія не дазвалялі ўключаць сябе ў склад нашага прадукта. Але ўжо пасля рэлізу выпадкова выявілася вельмі непрыемная рэч. У складзе Veliam Server, які быў на баку кліента была СКБД MariaDB. І яна з ліцэнзіяй GPL. Ліцэнзія GPL мяркуе, што софт павінен быць з адчыненым зыходным кодам, і калі ў склад нашага прадукта ўключаная MariaDB якая мае гэтую ліцэнзію, то і наш прадукт павінен быць пад гэтай ліцэнзіяй. Але на шчасце, у гэтай ліцэнзіі мэта - адкрыты зыходны код, а не пакаранне ў судзе тых, хто выпадкова памыліўся. Калі ў праваўладальніка з'яўляецца прэтэнзія, то ён пісьмова паведамляе парушальніка і той павінен на працягу 30 дзён ухіліць парушэнне. Мы выявілі сваю памылку самі і лістоў не атрымлівалі і адразу прыняліся разглядаць варыянты як вырашыць праблему. Выйсце апынуўся відавочны - пераход на SQLite. У гэтай БД няма ніякіх абмежаванняў па ліцэнзаванні. Большасць сучасных браўзэраў выкарыстоўвае SQLite, ды і куча іншых праграм. Знаходзіў у інтэрнэце інфармацыю, што SQLite лічыцца самай распаўсюджанай СКБД у свеце, як раз-ткі з-за браўзэраў, але не шукаў пруфаў, так што гэта недакладная інфармацыя. Пачаў вывучаць, чым пагражае пераход на SQLite.
Гэта становіцца ўжо нетрывіяльнай задачай, калі ёсць некалькі сотняў усталяваных у кліентаў сервераў з MariaDB і дадзенымі ў ёй. Некаторыя фішкі MariaDB недаступныя ў SQLite. Ну, напрыклад, у кодзе выкарыстоўвалі запыты тыпу
Select * FROM `table` WHERE `id`>1000 FOR UPDATE
Дадзеная канструкцыя робіць не толькі выбарку з табліцы, але і блакуе дадзеныя радкі. І яшчэ некалькі канструкцый таксама прыйшлося перапісваць. Але апроч таго, што прыйшлося перапісваць шмат запытаў, гэтак жа прыйшлося прыдумляць механізм, які пры абнаўленні Veliam Server у кліента партуе ўсе дадзеныя ў новую СКБД і выдаліць старую. Таксама, не працавалі транзакцыі ў SQLite і гэта было рэальнай праблемай. Але пачытаўшы прасторы сусветнага павуціння, я без праблем знайшоў, што транзакцыі ў SQLite можна ўлучыць, перадаўшы пры падлучэнні простую каманду.
PRAGMA journal_mode=WAL;У выніку задача выканана і зараз серверная частка ў кліентаў працуе на SQLite. Нейкіх змен у працы сістэмы мы не заўважылі.
Новы HelpDesk
З унутранай версіі ў SaaS версію неабходна было партаваць HelpDesk сістэму, але з некаторымі зменамі. Першае, што хацелася зрабіць – гэта інтэграцыя з даменам кліента ў частцы празрыстай аўтарызацыі карыстальнікаў у сістэме. Цяпер карыстач каб зайсці ў HelpDesk і пакінуць заяўку ў сістэме, проста націскае на цэтлік на працоўным стале і адчыняецца браўзэр. Карыстальнік не ўводзіць ніякіх уліковых дадзеных. Модуль для Apache SSPI, які ўваходзіць у склад Veliam Server аўтаматычна аўтарызуе карыстача пад даменным уліковым запісам. Каб пакінуць заяўку ў сістэме, калі карыстач знаходзіцца за межамі карпаратыўнай сеткі, ён націскае на кнопку, і яму на пошту прыходзіць спасылка, па якой ён без пароляў аўтарызуецца ў сістэме HelpDesk. Калі карыстача выключыць ці выдаліць у дамене, то і ўліковы запіс у HelpDesk таксама перастане працаваць. Такім чынам, сістэмнаму адміністратару не трэба самому сачыць за ўліковымі запісамі і ў дамене, і ў HelpDesk. Звольніўся супрацоўнік - адключыў уліковы запіс у дамене і ўсё, ён не зойдзе ў сістэму не з карпаратыўнай сеткі, не па спасылцы. Для працы дадзенай інтэграцыі, сістэмнаму адміністратару трэба зрабіць адну GPO, якая и .
Другое, што лічым вельмі неабходным для сістэм HelpDesk, ва ўсякім разе для нас саміх - гэта падлучэнне да заяўніка прама з заяўкі ў адзін клік. Больш за тое, падлучэнні павінны праходзіць, калі сістэмны адміністратар знаходзіцца ў іншай сетцы. Для аўтсорса гэта абавязкова, для штатных сістэмных адміністратараў таксама часта вельмі патрэбна. Ёсць ужо некалькі прадуктаў, якія выдатна спраўляюцца з задачай выдаленых падлучэнняў. І мы вырашылі зрабіць для іх інтэграцыі. Цяпер мы зрабілі інтэграцыю для VNC, а ў будучыні плануем дадаць Radmin і TeamViewer. Выкарыстоўваючы наш сеткавы транспарт для выдаленых падлучэнняў да інфраструктуры, мы зрабілі так, што VNC падлучаецца да выдаленых працоўных станцый за NAT. Тое ж самае будзе і з Radmin. Цяпер, для таго каб падключыцца да карыстача, трэба проста ў самой заяўцы націснуць кнопку "падключыцца да заяўніка". Адкрываецца VNC кліент і падключаецца да заяўніка незалежна ад таго ў адной вы з ім сеткі ці сядзіце дома ў тэпціках. Папярэдне, сістэмны адміністратар, сродкамі ДВА павінен усталяваць усім на працоўныя станцыі VNC Server.
Цяпер мы самі пераходзім на новы HelpDesk і карыстаемся інтэграцыяй з даменам і VNC. Гэта вельмі зручна для нас. Цяпер мы можам не плаціць за TeamViewer, якім мы карысталіся больш за тры гады для працы нашай службы падтрымкі.
Што плануем рабіць далей
Калі мы выпусцілі прадукт, то не рабілі ніякіх платных тарыфаў, а проста абмежавалі бясплатны тарыф 50 аб'ектамі маніторынгу. Пяць дзясяткаў сеткавых прылад і сервераў павінна хапіць усім, падумалі мы. І тут пачалі паступаць запыты на павелічэнне ліміту. Сказаць, што мы былі крыху ў шоку - нічога не сказаць. Няўжо нашым софтам зацікавіліся кампаніі, у якіх такая колькасць сервераў. Мы бясплатна пашыралі ліміт для тых, хто рабіў такія запыты. У некаторых мы ў адказ на іх запыт спыталі навошта ім гэтулькі, няўжо ў іх такая вялікая колькасць сервераў і сеткавага абсталявання. І аказалася, што сістэмныя адміністратары пачалі выкарыстоўваць сістэму так, як мы ўвогуле не планавалі. Усё аказалася проста – маніторыць нашым софтам пачалі не толькі серверы, але і працоўныя станцыі. Адсюль і шмат запытаў на пашырэнне лімітаў. Цяпер мы ўжо ўвялі платныя тарыфы і ліміты можна пашырыць самастойна.
Серверы, у большасці выпадкаў працуюць або з СХД або з лакальнымі дыскамі ў RAID масіве. І мы рабілі першапачаткова прадукт для іх. І маніторынг SMART быў нецікавы для гэтай задачы. Але з улікам таго, што людзі прыстасавалі софт для маніторынгу працоўных станцый, з'явіліся запыты на рэалізацыю маніторынгу SMART. Неўзабаве мы яго рэалізуем.
З з'яўленнем Veliam Connector, стала непатрэбным разгортванне VPN сервера ў карпаратыўнай сетцы, ці рабіць RDGW, ці проста прабіваць парты да неабходных машын для падлучэння па RDP. Вельмі шматлікія карыстаюцца нашай сістэмай толькі толькі для гэтых выдаленых падлучэнняў. Veliam Connector ёсць толькі пад Windows, а некаторыя карыстачы кампаній падлучаюцца з хатніх наўтбукаў пад кіраваннем MacOS да працоўных станцый або тэрміналам у карпаратыўнай сетцы. І атрымліваецца, што сістэмны адміністратар змушаны з-за некалькіх карыстачоў усё роўна вяртацца да пытання пракідаў ці VPN. Таму зараз мы ўжо заканчваем рабіць версію Veliam Connector пад MacOS. Карыстальнікі сваёй каханай яблычнай тэхнікі гэтак жа атрымаюць магчымасць у адзін клік падлучацца да карпаратыўнай інфраструктуры.
Вельмі падабаецца тое, што, маючы вялікую колькасць карыстачоў сістэмы не даводзіцца ламаць галаву, што людзям трэба і што будзе зручней. яны самі пішуць свае пажаданні, таму планаў па распрацоўцы на бліжэйшы час вельмі шмат.
Паралельна, плануем зараз заняцца перакладам сістэмы на англійскую мову і распаўсюджваннем яе замежжа. Мы пакуль не ведаем, як будзем распаўсюджваць прадукт па-за нашай краінай, шукаем варыянты. Магчыма пра гэта пазней будзе асобны артыкул. Магчыма нехта з тых, хто прачытаў гэты артыкул, зможа падказаць патрэбны вектар, ну ці сам ведае і ўмее як гэта рабіць і прапануе свае паслугі. Будзем удзячныя за дапамогу.
Крыніца: habr.com