Allhankest arenduseni (2. osa)

В Eelmine artikkel, rääkisin Veliami loomise taustast ja otsusest levitada seda SaaS süsteemi kaudu. Selles artiklis räägin sellest, mida pidin tegema, et toode ei oleks kohalik, vaid avalik. Sellest, kuidas levitamine algas ja millised probleemid tekkisid.

Планирование

Praegune kasutajate taustaprogramm oli Linuxis. Peaaegu igal organisatsioonil on Windowsi serverid, mida Linuxi kohta öelda ei saa. Veliami peamine tugevus on kaugühendused serverite ja võrguseadmetega NAT-i taga. Kuid see funktsionaalsus oli väga tihedalt seotud asjaoluga, et ruuter pidi olema Mikrotik. Ja see ilmselgelt ei rahuldaks paljusid. Kõigepealt hakkasin mõtlema levinumate tarnijate ruuterite toe lisamisele. Kuid ma sain aru, et see oli lõputu võidujooks toetatavate ettevõtete nimekirja laiendamiseks. Veelgi enam, neil, mida juba toetatakse, võib olla erinev käskude komplekt NAT-reeglite mudelite muutmiseks. Ainus väljapääs olukorrast näis olevat VPN.

Kuna otsustasime toodet levitada, kuid mitte avatud lähtekoodiga, muutus erinevate avatud litsentsidega teekide, näiteks GPL, kaasamine võimatuks. See on üldiselt omaette teema, pärast toote müügiotsuse tegemist pidin pooled raamatukogud läbi käima, kuna need olid GPL. Kui nad enda jaoks kirjutasid, oli see normaalne. Kuid levitamiseks ei sobi. Esimene VPN, mis meelde tuleb, on OpenVPN. Aga see on GPL. Teine võimalus oli kasutada Jaapani SoftEther VPN-i. Tema litsents võimaldas tal selle oma tootesse lisada. Pärast paaripäevaseid erinevaid teste, kuidas seda nii integreerida, et kasutajal poleks vaja üldse midagi seadistada ja SoftEther VPN-ist teada, saadi prototüüp. Kõik oli nii nagu pidi. Kuid millegipärast ajas see skeem meid ikkagi segadusse ja lõpuks loobusime sellest. Kuid loomulikult keeldusid nad pärast seda, kui leidsid teise võimaluse. Lõpuks tehti kõik tavaliste TCP ühenduste peal. Mõned ühendused töötavad koordinaatori kaudu, mõned otse läbi Nat Hole Punchingi (NHP) tehnoloogia, mida rakendati ka Free Pascalis. Pean ütlema, et ma polnud NHP-st varem isegi kuulnud. Ja mulle ei tulnud pähegi, et oleks võimalik ühendada 2 võrguseadet, mis mõlemad on otse NAT-i taga. Uurisin teemat, sain aru tööpõhimõttest ja istusin kirjutama. Plaan realiseerub, kasutaja ühendub ühe klõpsuga NAT-i taga soovitud seadmega RDP, SSH või Winboxi kaudu ilma paroole sisestamata või VPN-i seadistamata. Pealegi läheb enamik neist ühendustest meie koordinaatorist mööda, millel on hea mõju pingile ja nende ühenduste teenindamise kuludele.

Serveriosa ülekandmine Linuxist Windowsi

Windowsile üleminekul tekkis mitmeid probleeme. Esimene on see, et Windowsi sisseehitatud wmic ei võimalda teil teha WQL-päringuid. Ja meie süsteemis oli kõik neile juba üles ehitatud. Ja seal oli veel midagi, aga nüüd olen unustanud, miks nad selle kasutamisest lõpuks loobusid. Võimalikud erinevused Windowsi versioonide vahel. Ja teine ​​probleem on mitmelõimeline. Kuna ma ei leidnud meie jaoks „vastuvõetava” litsentsi alusel head kolmanda osapoole utiliiti, käivitasin uuesti Lazaruse IDE. Ja ma kirjutasin vajaliku utiliidi. Sisendiks on vajalik nimekiri objektidest ja millised konkreetsed päringud tuleb teha ning vastuseks saan andmed. Ja seda kõike mitme keermega režiimis. Suurepärane.

Pärast PHP Windowsi jaoks pthreadide seadistamist arvasin, et kõik algab kohe, kuid see polnud nii. Pärast mõnda aega silumist mõistsin, et pthreads näis töötavat, kuid meie süsteemis see ei töötanud. Selgus, et Windowsis pthreadidega töötamisel on teatud eripära. Ja nii oligi. Lugesin dokumentatsiooni ja seal oli kirjas, et Windowsi puhul on lõimede arv piiratud ja minu mäletamist mööda kaudselt. Sellest sai probleem. Sest kui hakkasin rakenduse töötavate lõimede arvu vähendama, tegi see oma tööd väga aeglaselt. Avasin IDE uuesti ja samale utiliidile lisati objektide mitme lõimega pingimise funktsionaalsus. Noh, seal on ka juba palju pordi skannimist. Tegelikult kadus pärast seda PHP jaoks vajadus pthreadide järele ja seda enam ei kasutata. Lisaks lisati sellele utiliidile veel mitmeid funktsioone ja see töötab siiani. Pärast seda pandi kokku Windowsi installija, mis sisaldas Apache, PHP, MariaDB, PHP-rakendust ennast ja Free Pascalis kirjutatud utiliitide komplekti süsteemiga suhtlemiseks. Paigaldaja osas mõtlesin, et lahendan selle probleemi kiiresti, sest... See on väga levinud asi ja vajalik peaaegu iga tarkvara puhul. Kas ma otsisin valest kohast või midagi muud. Kuid pidevalt puutusin kokku toodetega, mis kas polnud piisavalt paindlikud või kallid ja ka paindumatud. Ja siiski leidsin tasuta paigaldaja, kus on võimalik kõiki soove täita. See on InnoSetup. Kirjutan sellest siin, sest pidin selle üle vaatama, juhuks kui kellegi aega säästan.

Pluginast keeldumine teie kliendi kasuks

Varem kirjutasin, et kliendi osa oli “pluginaga” brauser. Nii et oli aegu, mil Chrome'i värskendati ja paigutus oli veidi kõver, siis Windows värskendati ja kohandatud uri skeem kadus. Ma tõesti ei tahtnud, et toote avalikus versioonis oleks selliseid üllatusi. Pealegi hakkas kohandatud uri pärast iga Windowsi värskendust kaduma. Microsoft lihtsalt kustutas nõutavast jaotisest kõik mitte-oma filiaalid. Samuti ei luba Google Chrome nüüd meeles pidada valikut, kas rakendus kohandatud uri-st avada või mitte, ja esitab selle küsimuse iga kord, kui klõpsate jälgimisobjektil. Noh, üldiselt oli vajalik tavaline suhtlus kasutaja kohaliku süsteemiga, mida brauser ei paku. Selle skeemi kõige lihtsam variant näib olevat lihtsalt oma brauseri loomine, nagu paljud seda praegu Electroni kaudu teevad. Kuid paljud asjad olid juba Free Pascalis kirjutatud, sealhulgas serveriosas, nii et otsustasime teha kliendi samas keeles, mitte looma loomaaeda. Nii kirjutati Chromiumiga klient. Pärast seda hakkas see omandama erinevaid rihmasid.

Vabastage

Lõpuks valisime süsteemile nime. Samal ajal, kui kohalikult versioonilt SaaS-ile konverteerimine oli pooleli, tegime pidevalt erinevaid võimalusi. Kuna esialgu plaanisime siseneda mitte ainult siseturule, siis oli nime valiku peamiseks kriteeriumiks vaba või mitte väga kalli domeeni olemasolu .com tsoonis. Mõned funktsioonid/moodulid pole veel kohalikust versioonist Veliami teisaldatud, kuid otsustasime, et anname need välja praeguse funktsionaalsusega ja ülejäänud täidame uuendustena. Esimeses versioonis puudus HelpDesk, Veliam Connector, oli võimatu muuta teavituskäivitajate lävesid ja palju muud. Ostsime koodiallkirja sertifikaadi ja allkirjastasime kliendi ja serveri osad. Kirjutasime tootele veebisaidi, alustasime tarkvara, kaubamärgi jne registreerimisprotseduure. Üldiselt oleme alustamiseks valmis. Kerge eufooria tehtud tööst ja sellest, et äkki keegi kasutab teie toodet, kuigi me ei kahelnud selles. Ja siis peatu. Partner ütles, et ilma sõnumitoojate kaudu teavitamiseta on turule sisenemine võimatu. See on võimalik ilma paljude muude asjadeta, kuid mitte ilma selleta. Pärast mõningast arutelu lisati integratsioon Telegramiga, mis meile sobis. Kõigist praegustest kiirsõnumite saatjatest on see ainus, mis võimaldab juurdepääsu oma API-dele tasuta ja ilma keeruliste kinnitusprotseduurideta. Sama WhatsApp soovitab võtta ühendust teenusepakkujatega, kes võtavad oma teenuste kasutamise eest head raha; kõiki kirju, mis palusid juurdepääsu ilma tihenditeta, eirati. Noh, Viber... ma ei tea, kes seda praegu kasutab, sest... rämpspost ja reklaam on edetabelitest väljas. Detsembri lõpus avati pärast rida sise- ja sõprade teste registreerimine kõigile ja tarkvara tehti allalaadimiseks kättesaadavaks.

Levitamise algus

Algusest peale saime aru, et vajame väikest süsteemikasutajate voogu, et nad saaksid toodet lahingurežiimis testida ja esmast tagasisidet anda. Mitmed ostetud postitused VK-s kandsid vilja. Esimesed registreerimised on saabunud.

Siinkohal tuleb öelda, et turule sisenemine, kui teie ettevõttel pole kuulsat nime, ja samal ajal agentideta jälgimisfunktsiooni pakkumine, mille puhul peate oma serveritest ja tööjaamadest kontosid sisestama, on väga keeruline. See hirmutab paljusid inimesi. Saime algusest peale aru, et sellega on probleeme ja olime selleks valmis nii tehniliselt kui moraalselt. Kõik kaugühendused, hoolimata asjaolust, et RDP ja SSH on juba vaikimisi krüpteeritud, on meie tarkvara poolt täiendavalt krüpteeritud, kasutades AES-standardit. Kõik kohalike serverite andmed edastatakse HTTPS-i kaudu pilve. Kontod salvestatakse krüpteeritud kujul. Kõigi alamsüsteemide krüpteerimisvõtmed on kõigi klientide jaoks individuaalsed. Kaugühenduste jaoks kasutatakse tavaliselt seansi krüpteerimisvõtmeid.

Kõik, mida saame selles olukorras teha, et inimesed tunneksid end rahulikumalt, on olla võimalikult avatud, töötada ohutuse nimel ja mitte kunagi väsitada inimeste küsimustele vastamast.

Paljude jaoks kaalub tarkvara mugavus ja funktsionaalsus hirmu üles ning nad registreerivad end. Mõned inimesed kirjutasid VK-s avaldatud postitustes, et seda tarkvara ei saa kasutada, kuna See on nende paroolide kogu ja üldiselt nimetu ettevõte. Peab ütlema, et sellel arvamusel oli rohkem kui üks inimene. Paljud inimesed lihtsalt ei mõista, et kui nad installivad teenusena töötavasse serverisse muud patenteeritud tarkvara, on sellel ka süsteemis täielikud õigused ja nad ei vaja kontosid, et midagi ebaseaduslikku teha (on selge, et saate muuta kasutaja, kellelt teenus käivitati, kuid ka siin saate sisestada mis tahes konto). Tegelikult on inimeste hirmud mõistetavad. Tarkvara installimine serverisse on tavaline asi, kuid konto sisestamine on veidi hirmutav ja intiimne, kuna tubli pooltel inimestest on kõigi teenuste jaoks sama parool ning eraldi konto loomine isegi testi jaoks on laisk. Kuid praegu on tohutul hulgal teenuseid, mida inimesed usaldavad oma mandaatide ja muuga. Ja me püüame saada üheks neist.

Seal oli palju kommentaare, mis ütlesid, et me varastasime selle kuskile. See üllatas meid veidi. No okei, ühe inimese arvamus, aga selliseid kommentaare leiti erinevatest väljaannetest erinevatelt inimestelt. Alguses nad ei teadnud, kuidas sellele reageerida. Kas olla kurb selle üle, et mõnel on arvamus, et Venemaal ei saa keegi midagi ise teha, vaid saab ainult varastada, või olla õnnelik, et nad arvavad, et seda saab ainult varastada.

Oleme nüüdseks lõpetanud EV koodimärgi sertifikaadi saamise protseduuri. Selle saamiseks peate läbima mitmeid kontrolle ja saatma hunniku ettevõtte kohta dokumente, millest mõned peavad olema juristi poolt kinnitatud. EV koodimärgi sertifikaadi saamine pandeemia ajal on artikli eraldi teema. Protseduur kestis kuu. Ja see ei olnud kuu aega ootamist, vaid pidevaid lisadokumentide nõudmisi. Võib-olla polnud pandeemial sellega midagi pistmist ja protseduur võttis kõigil nii kaua aega? Jaga.

Mõned ütlevad, et me ei kasuta seda, kuna puudub FSTEC-sertifikaat. Peame selgitama, et me ei saa seda hankida ega saagi, sest selle sertifikaadi saamiseks peab krüpteerimine olema kooskõlas GOST-iga ning plaanime tarkvara levitada mitte ainult Venemaal ja kasutada AES-i.

Kõik need kommentaarid seavad kahtluse alla, kas on võimalik reklaamida toodet, mis nõuab kontode sisestamist, ilma et see oleks avalikult teada. Kuigi teadsime, et leidub neid, kes suhtuvad sellesse väga negatiivselt. Pärast seda, kui registreerimiste arv ületas tuhande piiri, lakkasime sellele mõtlemast. Eriti pärast seda, kui lisaks nende negatiivsusele, kes polnud toodet isegi proovinud, hakkasid ilmuma väga meeldivad ülevaated. Peab ütlema, et need positiivsed ülevaated on tootearenduse suurimaks motivaatoriks.

Töötajate kaugjuurdepääsu funktsioonide lisamine

Üks klientide sagedasi ülesandeid on "anna Vanyale juurdepääs oma arvutile kodust". Tõstsime Mikrotiku VPN-i ja lõime kasutajatele kontod. Kuid see on tõeline probleem. Kasutajad ei saa VPN-i kaudu ühenduse loomiseks juhiseid vaadata ja neid samm-sammult järgida. Windowsi erinevad versioonid. Ühes Windowsis ühendub kõik hästi, teises on vaja teistsugust protokolli. Ja üldiselt seostati seda alati VPN-serverina toiminud võrguseadmete ümberseadistamisega ja kõigil töötajatel pole sellele juurdepääsu ja see oli ebamugav.

Kuid meil on juba serverite ja võrguseadmetega kaugühendused. Miks mitte kasutada valmis transporti ja teha eraldi väike utiliit, mille saad lihtsalt kasutajale ühenduse loomiseks anda. Tahtsin lihtsalt veenduda, et kasutaja ei sisestaks sinna midagi segast. Ainult üks nupp "ühenda". Kuid kuidas saab see utiliit aru, kuhu ühendada, kui sellel on ainult üks nupp? Tekkis idee ehitada vajalik rakendus veebis meie serveritesse. Süsteemiadministraator klõpsab nuppu "allalaadimise otsetee" ja meie pilve saadetakse käsk, et luua individuaalne binaarfail koos juhtmega teabega soovitud serveri/arvutiga RDP kaudu ühenduse loomiseks. Üldiselt võiks seda teha. Kuid see võtab kaua aega; administraator peaks esmalt ootama, kuni kahendfail kompileeritakse ja seejärel alla laaditakse. Muidugi oleks võimalik lihtsalt lisada konfiguratsiooniga teine ​​fail, aga see on juba 2 faili ja lihtsuse mõttes on kasutajal vaja ühte. Üks fail, üks nupp ja installijaid pole. Veidi Google’ist lugedes jõudsin järeldusele, et kui kompileeritud “.exe” lõppu veidi infot lisada, siis see ei halvene (noh, peaaegu). Sinna saab lisada vähemalt sõja ja rahu ning see toimib nagu varem. Patt oleks seda mitte ära kasutada. Nüüd saate rakenduse lihtsalt lahti pakkida liikvel olles, otse kliendis endas, muide seda nimetatakse Veliam Connectoriks, ja lihtsalt lisada lõppu sellega ühenduse loomiseks vajalik teave. Ja rakendus ise teab, mida sellega teha. Miks ma kirjutasin “hästi peaaegu” sulgudes veidi kõrgemale? Sest selle mugavuse eest tuleb maksta, kuna rakendus kaotab oma digiallkirja. Kuid praeguses etapis usume, et see on väike hind, mida sellise mugavuse eest maksta.

Kolmanda osapoole moodulilitsentsid

Eespool juba kirjutasin, et pärast seda, kui otsustati toode avalikult kättesaadavaks teha, ja mitte ainult enda tarbeks, pidime kõvasti tööd tegema ja otsima asendusi mõnele moodulile, mis ei lasknud end meie tootesse kaasata. Kuid pärast vabastamist avastati kogemata väga ebameeldiv asi. Kliendi poolel asuv Veliam Server sisaldas MariaDB DBMS-i. Ja see on GPL-litsentsiga. GPL-litsents tähendab, et tarkvara peab olema avatud lähtekoodiga ja kui meie toode sisaldab MariaDB-d, millel on see litsents, peab meie toode olema selle litsentsi all. Kuid õnneks on selle litsentsi eesmärk avatud lähtekoodiga, mitte nende karistamine, kes kohtus kogemata eksivad. Kui autoriõiguse omajal on pretensioon, teatab ta sellest rikkujale kirjalikult ja ta peab rikkumise kõrvaldama 30 päeva jooksul. Avastasime oma vea ise ja ei saanud ühtegi kirja ning hakkasime kohe kaaluma võimalusi, kuidas probleemi lahendada. Lahendus osutus ilmseks – lülituge SQLite’ile. Sellel andmebaasil pole litsentsipiiranguid. Enamik kaasaegseid brausereid kasutab SQLite'i ja paljusid muid programme. Leidsin internetist infot, et SQLite’i peetakse maailmas kõige levinumaks DBMS-iks just brauserite tõttu, aga ma ei otsinud tõestust, seega on tegemist ebatäpse infoga. Hakkasin uurima SQLite'ile ülemineku ohte.

See muutub mittetriviaalseks ülesandeks, kui klientidele on installitud mitusada serverit koos MariaDB ja andmetega. Mõned MariaDB funktsioonid pole SQLite'is saadaval. Näiteks koodis kasutasime selliseid päringuid nagu

Select * FROM `table` WHERE `id`>1000 FOR UPDATE

See konstruktsioon mitte ainult ei tee tabelist valikut, vaid lukustab ka rea ​​andmed. Ja veel mitu kavandit tuli ka ümber kirjutada. Kuid lisaks sellele, et pidime palju päringuid ümber kirjutama, tuli välja mõelda ka mehhanism, mis kliendi Veliam Serveri värskendamisel portiks kõik andmed uude DBMS-i ja kustutaks vana. Samuti ei toiminud tehingud SQLite'is ja see oli tõeline probleem. Kuid pärast World Wide Webi avaruse lugemist leidsin probleemideta, et SQLite'is saab tehinguid lubada, kui anda ühenduse loomisel lihtne käsk

PRAGMA journal_mode=WAL;

Selle tulemusel sai ülesanne täidetud ja nüüd töötab kliendi serveriosa SQLite'is. Süsteemi töös muutusi me ei märganud.

Uus HelpDesk

HelpDeski süsteem oli vaja portida siseversioonilt SaaS-i versioonile, kuid mõningate muudatustega. Esimene asi, mida ma teha tahtsin, oli integreerimine kliendi domeeniga süsteemi läbipaistva kasutaja autoriseerimise mõttes. Nüüd klikib kasutaja HelpDeski sisselogimiseks ja süsteemi päringu jätmiseks lihtsalt töölaual oleval otseteel ja brauser avaneb. Kasutaja ei sisesta ühtegi mandaati. Apache SSPI moodul, mis on osa Veliam Serverist, volitab kasutaja automaatselt domeenikonto all. Taotluse jätmiseks süsteemi, kui kasutaja on väljaspool ettevõtte võrku, klõpsab ta nupul ja ta saab oma e-kirja lingi, mille kaudu ta logib sisse HelpDeski süsteemi ilma paroolideta. Kui kasutaja on domeenis keelatud või kustutatud, lakkab ka HelpDeski konto töötamast. Seega ei pea süsteemiadministraator ise jälgima kontosid nii domeenis kui ka HelpDeskis. Töötaja lahkub - ta katkestab oma konto domeenis ja ongi kõik, ta ei logi süsteemi sisse mitte ettevõtte võrgust ega lingi kaudu. Selle integratsiooni toimimiseks peab süsteemiadministraator looma ühe GPO, mis lisab siseveebisaidi sisevõrgu tsooni и jagab otsetee kõigile töölaual olevatele kasutajatele.

Teine asi, mida peame HelpDeski süsteemide puhul vähemalt enda jaoks äärmiselt vajalikuks, on taotlejaga ühenduse loomine otse rakendusest ühe klõpsuga. Lisaks peavad ühendused läbima, kui süsteemiadministraator on teises võrgus. Allhanke puhul on see kohustuslik, täiskohaga süsteemiadministraatoritele sageli ka väga vajalik. Juba on mitmeid tooteid, mis teevad kaugühenduste loomisel suurepärase töö. Ja me otsustasime nende jaoks integreerida. Oleme nüüd integreerinud VNC jaoks ja tulevikus plaanime lisada Radmini ja TeamVieweri. Kasutades oma võrgutransporti infrastruktuuri kaugühenduste jaoks, lõime VNC-l ühenduse NAT-i taga asuvate kaugtööjaamadega. Sama juhtub Radminiga. Nüüd peate kasutajaga ühenduse loomiseks klõpsama rakenduses endas nuppu "ühenda taotlejaga". VNC klient avaneb ja loob ühenduse taotlejaga, olenemata sellest, kas oled samas võrgus või istud kodus sussides. Esiteks peab süsteemiadministraator, kasutades GPO-d, installima VNC-serveri kõigisse tööjaamadesse.

Nüüd läheme ise üle uuele HelpDeskile ja kasutame integratsiooni domeeni ja VNC-ga. See on meile väga mugav. Nüüd saame vältida TeamVieweri eest tasumist, mida oleme tugiteenuse käitamiseks kasutanud juba üle kolme aasta.

Mida me järgmiseks plaanime teha?

Toote välja andmisel ei teinud me tasulisi tariife, vaid piirasime tasuta tariifi lihtsalt 50 seireobjektiga. Viiest tosinast võrguseadmest ja serverist peaks kõigile piisama, arvasime. Ja siis hakkas tulema palveid limiiti tõsta. Öelda, et olime veidi šokeeritud, tähendab mitte midagi öelda. Kas ettevõtted, kellel on nii palju servereid, on tõesti meie tarkvarast huvitatud? Pikendasime selliste sooviavalduste esitajatele limiiti tasuta. Vastuseks nende palvele küsisime mõnelt, miks neil nii palju vaja on, kas neil on tõesti nii palju servereid ja võrguseadmeid. Ja selgus, et süsteemiadministraatorid hakkasid süsteemi kasutama viisil, mida me polnud üldse planeerinud. Kõik osutus lihtsaks - meie tarkvara hakkas jälgima mitte ainult servereid, vaid ka tööjaamu. Seetõttu on palju taotlusi limiitide laiendamiseks. Nüüd oleme juba kasutusele võtnud tasulised tariifid ja limiite saab iseseisvalt laiendada.

Serverid töötavad peaaegu alati kas salvestussüsteemide või RAID-massiivis olevate kohalike ketastega. Ja algselt tegime toote neile. Ja SMART monitooring ei olnud selle ülesande jaoks huvitav. Kuid arvestades asjaolu, et inimesed on kohandanud tarkvara tööjaamade jälgimiseks, on ilmunud taotlused SMART monitooringu rakendamiseks. Rakendame selle peagi.

Veliam Connectori tulekuga muutus tarbetuks VPN-serveri juurutamine ettevõtte võrgus või RDGW tegemine või lihtsalt pordide edastamine vajalikele masinatele RDP kaudu ühenduse loomiseks. Paljud inimesed kasutavad meie süsteemi ainult nende kaugühenduste jaoks. Veliam Connector on saadaval ainult Windowsi jaoks ja mõned ettevõtte kasutajad loovad MacOS-i kasutavatest kodustest sülearvutitest ühenduse tööjaamade või ettevõtte võrgu terminalidega. Ja selgub, et süsteemiadministraator on sunnitud mitme kasutaja tõttu siiski pöörduma tagasi suunamise või VPN-i teema juurde. Seetõttu oleme nüüd lõpetamas Veliam Connectori versiooni MacOS-i jaoks. Apple'i lemmiktehnoloogia kasutajad saavad ka võimaluse luua ühe klõpsuga ühenduse ettevõtte infrastruktuuriga.

Mulle väga meeldib, et kui süsteemi kasutajaid on palju, ei pea te pead murdma selle üle, mida inimesed vajavad ja mis on mugavam. Nemad ise kirjutavad oma soovid, nii et lähituleviku arenguplaane on palju.

Paralleelselt plaanime nüüd hakata süsteemi inglise keelde tõlkima ja välismaale levitama. Me ei tea veel, kuidas toodet väljapoole oma riiki levitame, otsime võimalusi. Võib-olla tuleb selle kohta hiljem eraldi artikkel. Võib-olla oskab keegi, kes on seda artiklit lugenud, soovitada vajalikku vektorit või ta ise teab ja teab, kuidas seda teha ning pakub oma teenuseid. Oleksime teie abi tänulikud.

Allikas: www.habr.com

Lisa kommentaar