Uues , rääkisin Veliami loomise eelajaloolisest taustast ja selle levitamise otsusest SaaS-süsteemis. Selles artiklis räägin, mida tuli teha, et toode muutuks mitte lokaalseks, vaid avalikuks. Kuidas levitamist alustati ja milliste probleemidega silmitsi seisti.
Planeerimine
Käesolev serveripool kasutajatele oli Linuxil. Peaaegu igas organisatsioonis on Windowsi serverid, mida ei saa öelda Linuxi kohta. Veliami põhivõimekus on kaugühenduste loomine serverite ja võrgu seadmetega NAT-i taga. Kuid see funktsioon oli väga rangelt seotud sellega, et marsruuteriks pidi kindlasti olema MikroTik. Ja see ei rahuldaks selgelt paljusid. Alguses hakkasin mõtlema, et lisada tugi kõige levinumate tootjate marsruuteritele. Kuid mõistsin, et see on lõputu võidujooks toetatud firmade loetelu laiendamisega. Veelgi enam, isegi need, mis on juba toetatud, võivad mudeli kaupa omada erinevaid NAT-i reeglite muutmise käske. Ainus väljapääs näis olevat VPN.
Kuna me otsustasime toodet levitada, kuid mitte avatud allikana, ei olnud võimalik lisada erinevaid avaliku litsentsiga teeke, nagu GPL. See on eraldi teema; toote müügiotsuse langetamise järel pidime läbi vaatama pool vaikest teekidest, kuna need olid GPL. Kui kirjutasime iseendale, oli see normaalne. Aga levitamiseks ei sobinud. Esimene VPN, mis pähe tuleb, on OpenVPN. Aga see on GPL. Samuti oli võimalus kasutada Jaapani SoftEther VPN-i. Selle litsents võimaldas selle oma toote koostisosaks lisada. Pärast paaripäevaseid erinevaid teste selle integreerimiseks nii, et kasutajal ei oleks midagi seadistama ning SoftEther VPN-ist midagi teadma, saime prototüübi valmis. Kõik oli nagu peab. Kuid miski pärast häiris meid see skeem, ja me loobusime sellest. Loomulikult loobusime pärast seda, kui olime mõelnud teise võimaluse. Lõppkokkuvõttes tegime kõik tavaliste TCP ühenduste peal. Osa ühendustest töötab koordinaatori kaudu, osa otse läbi NAT Hole Punchingu (NHP) tehnoloogia, mis oli samuti rakendatud Free Pascalis. Pean ütlema, et NHP-st polnud ma varasemalt isegi kuulnud. Ja ei tulnud pähe, et kahte võrgu seadet, mis mõlemad on NAT taga, võiks otse ühendada. Uurisin teema, mõistsin tööpõhimõtte ja hakkasin kirjutama. Plaanitud teostus, kasutaja saab ühe klikiga ühendust vajaliku seadmega NAT taga RDP, SSH või Winboxi kaudu ilma paroolide sisestamiseta ja VPN-i seadistamiseta. Pealegi läheb enamus neist ühendustest mööda meie koordinaatorist, mis avaldab head mõju latentsusele ja ühenduste hooldamise kuludele.
Serveri osa üleminek Linuxilt Windowsile
Windowsile ülemisel oli mitu probleemi. Esimene — sisseehitatud wmic Windowsis ei võimalda WQL päringute tegemist. Ja meie süsteem oli juba nende peal üles ehitatud. Ja oli veel midagi, kuid nüüd ma ei mäleta, miks me lõpuks selle kasutamisest loobusime. Võib-olla olid erinevused Windowsi versioonide vahel. Ja teine probleem — mitme lõime tugi. Olles leidnud hea kolmanda osapoole utiliidi meie jaoks "kasutamise lubatud" litsentsiga, käivitasin uuesti IDE Lazaruse. Ja kirjutasin vajaliku utiliidi. Sisendiks antakse vajalik objektide loetelu ja milliseid päringuid tuleb teha, ja vastuseks saan andmed. Ja kõik see toimub mitme lõime režiimis. Suurepärane.
Pärast seda, kui seadistasin pthreadid PHP Windows'il, arvasin, et kõik käivitub kohe, aga see polnud nii. Pärast mõningast tõrkeotsingut sain aru, et pthreadid töötavad, kuid meie süsteemis ei toiminud need. Selgus, et Windowsis on olemas mingi eriline omadus pthreadide töö jaoks. Nii oligi. Lugesin dokumentatsiooni ja seal oli kirjutatud, et Windowsis on lõime arv piiratud, ning kui ma õigesti mäletan, siis mitteavalikult. See tõi kaasa probleeme, kuna kui hakkasin vähendama nende lõimede arvu, mille korral rakendus töötas, toimis see väga aeglaselt. Taas avasin IDE ja selle utiliidi juurde lisati veel mitme kiirusliku objekti pingutamise funktsioon. Samuti lisasin sinna ka portide skaneerimise. Pärast seda kadus vajadus pthreadide järele PHP jaoks ning neid enam ei kasutatud. Hiljem lisati sellesse utiliiti veel mõned funktsioonid ja see töötab tänaseni. Pärast seda koostasin Windowsi installija, mis sisaldas Apache't, PHP'd, MariaDB't, ise PHP rakendust ning komplekti utiliite, mis on kirjutatud Free Pascal'is süsteemiga suhtlemiseks. Mis puutub installijasse, siis arvasin, et lahendan selle küsimuse kiiresti, kuna see on ülimalt levinud ja vajalik peaaegu iga tarkvara jaoks. Kas olin vale otsingus, või miski muu? Kuid mulle sattusid pidevalt tooted, mis olid kas liiga jäik või kallis ja samas ka jäik. Lõpuks leidsin tasuta installija, mis võimaldab arvestada igasuguste soovide ja vajadustega. See on InnoSetup. Kirjutan siin sellest, kuna mul tuli otsida, ehk säästan kellegi aega.
Pluginast loobumine oma kliendi hüvanguks
Olen varem kirjutanud, et kliendiosaks oli brauser koos "pluginiga". Oli selliseid aegu, mil Chrome uuendus ja kujundus natuke kaldus, või Windows uuendus ja kohandatud uri skeem kadus. Ei tahtnud selliseid üllatusi avalikus tootes. Lisaks hakkasid kohandatud uri pärast iga Windowsi uuendust kaduma. Microsoft eemaldas lihtsalt kõik mitte oma harud vajalikust sektsioonist. Samuti ei luba Google Chrome nüüd meelde jätta valikut avada rakendust kohandatud uri-st või mitte, ja küsib seda küsimust iga objekti jälgimise kliki ajal. Ja üldiselt oli vaja normaalset koostööd kasutaja lokaalse süsteemiga, mida brauser ei paku. Lihtsaim lahendus sellises skeemis näib olevat luua oma brauser, nagu paljud praegu teevad läbi Electroni. Kuid paljud asjad olid juba kirjutatud Free Pascalis, sealhulgas serveriosas, seega otsustasime ka kliendi teha samas keeles, mitte loomine mitmekesist zooti. Nii kirjutati klient, millel oli Chromium pardal. Pärast seda hakkas see erinevate sidemete kasvatamisega.
Väljalase
Lõpuks valisime süsteemile nime. Me käisime pidevalt läbi erinevaid variante, kui muutisime kohaliku versiooni SaaS-iks. Kuna me algselt plaanisime mitte ainult siseturule siseneda, oli peamine nimevaliku kriteerium vaba või mitte eriti kallis domeen tsoonis ".com". Mõned funktsioonid/moduulid ei olnud veel kohaliku versiooni Veliamisse kantud, kuid otsustasime, et käivitame praeguse funktsionaalsusega ja viime muudatused ellu hiljem uuendustena. Esimeses versioonis puudusid HelpDesk, Veliam Connector, ei olnud võimalik muuta teavituste aktiveerimise künniseid ja palju muud. Ostsime Code Sign Certificate’i, allkirjastasime kliendi- ja serveriosa. Kirjutasime tootele veebisaidi, alustasime tarkvara ja kaubamärgi registreerimise protseduuri jne. Ühesõnaga, oleme valmis alustama. Kerge eufooria tehtud töö üle ja mõte, et keegi võiks meie toodet kasutada, kuigi selle üle ei olnud meil kahtlusi. Ja siis stopp. Partner ütles, et ilma teavitusteta messengeri ei saa turule siseneda. Saame ilma paljude teiste asjadega, kuid mitte ilma selleta. Pärast lühikest vaidlust lisati integreerimine Telegramiga, mis sobis meile. Kõigist praegustest messengeritest on see ainus, mis annab juurdepääsu oma API-le tasuta ja ilma keeruliste kooskõlastamisprotseduurideta. WhatsApp pakub ühendust pakkujate kaudu, kes küsivad teenuse kasutamise eest head raha, kõik kirjad palvega juurdepääsu kohta mööndusteta jäid tähelepanuta. No ja Viber... Ma ei tea, kes seda praegu kasutab, kuna spämmi ja reklaami on seal üleliia. Detsembri lõpus, pärast mitmeid sise teste ja teste sõprade seas, avasime registreerimise kõigile ja panime tarkvara alla laadimiseks üles.
Leviku algus
Juba algusest saati mõistsime, et vajame väikest kasutajate voogu, et nad katsetaksid toodet reaalsetes oludes ja annaksid mingisuguse esialgse tagasiside. Mitmed ostetud postitused VK-s andsid tulemusi. Tulid esimesed registreeringud.
Siin tuleb öelda, et turule sisenemine, kui sinu ettevõttel pole tuntud nime, ja samal ajal pakkuda agentuurivaba jälgimise funktsionaalsust, kuhu tuleb sisestada kontod oma serverite ja tööjaamade jaoks, on väga keeruline. Paljusid inimesi paneb see hirmu tundma. Me mõistsime algusest peale, et sellega on probleeme ja olime valmis tehniliselt ja moraalselt. Kõik kaugühendused, kuigi RDP ja SSH on vaikimisi juba krüptitud, on meie tarkvara poolt täiendavalt krüptitud AES-standardiga. Kõik andmed kohalikest serveritest edastatakse pilve HTTPS-i kaudu. Kontod hoitakse krüptitud kujul. Krüpteerimisvõtmed kõigi süsteemide jaoks on igal kliendil individuaalsed. Kaugühenduste jaoks kasutatakse üldse seansivõtmeid.
Kõik, mida me saame teha, et inimesed tunneksid end rahulikumalt — on olla võimalikult avatud, töötada turvalisuse nimel ja mitte väsida inimestele nende murettekitavatele küsimustele vastamast.
Paljude jaoks kaaluvad tarkvara mugavus ja funktsionaalsus üles hirmu ning nad registreeruvad. Mõned isikud on avaldatud postitustes VK-s kirjutanud, et seda tarkvara kasutada ei saa, kuna see kogub nende paroole ja on üleüldiselt tundmatu ettevõte. Tuleb öelda, et see arvamus ei tulnud ainult ühelt inimeselt. Paljud ei mõista, et kui nad paigaldavad oma serverisse teise patendi alusel tarkvara, mis töötab teenusena, on sellel täisõigused süsteemis ja neile ei ole vaja kontosid, et midagi ebaseaduslikku teha (on selge, et teenuse käivitamisel kasutaja muutmine on võimalik, aga ka seal ei ole probleemi kontole, mida sisse viia). Tegelikult on inimeste kartused arusaadavad. Tarkvara paigaldamine serverisse on tuttav asi, kuid konto sisestamine on juba natuke hirmutav ja intiimne, kuna suurel osal inimestest on üks parool kõikidele teenustele ja eraldi konto loomine isegi testimiseks on laiskus. Kuid praegu on tohutult teenuseid, millele inimesed usaldavad oma volitusi ja mitte ainult. Ja me püüame saada üheks neist.
Paljud kommentaarid olid sarnased, et me oleme selle kuskilt varastanud. See üllatas meid veidi. No okei, see on ühe inimese arvamus, kuid taolisi kommentaare kohtasime erinevates väljaannetes erinevatelt inimestelt. Alguses ei teadnud, kuidas sellele reageerida. Kas kurvastada selle üle, et mõnel inimesel on arvamus, et Venemaal ei suuda keegi midagi ise teha, vaid saab ainult varastada, või rõõmustada, et arvatakse, et ainus võimalus on varastada selle.
Praegu oleme lõpetanud EV Code Sign Certificate'i hankimise protseduuri. Selle saamiseks tuleb läbida rida kontrolle ja esitada palju ettevõtte dokumente, millest osa peab olema juristi tõendatud. EV Code Sign sertifikaadi saamine pandeemia tingimustes on üldse eraldi teema artiklisse. Protseduur venis kuu aega. Ja see polnud ooteaeg, vaid pidev täiendavate dokumentide nõudmine. Võib-olla pole pandeemial sellega midagi pistmist, ja kõigil läks protsess nii kaua? Jagage.
Mõned ütlevad, et nad ei kasuta, kuna FSTEK sertifikaati ei ole. Peame selgitama, et me ei saa seda hankida ja me ei saa, kuna selle sertifikaadi saamiseks peab krüpteerimine toimuma vastavalt GOST-ile, aga me plaanime levitada tarkvara mitte ainult Venemaal ja kasutame AES-i.
Kõik need kommentaarid valmistasid mingi ebakindluse, et kas on võimalik toota toodet, millele tuleb luua kontod, olemata samal ajal tähelepanu keskpunktis. Isegi arvestades, et me teadsime, et leidub neid, kes sellele väga negatiivselt suhtuvad. Pärast seda, kui registreerimine ületas tuhande piiri, lõpetasime selle mõtlemise. Eriti pärast seda, kui lisaks nendele, kes isegi toodet ei proovinud, hakkasid ilmuma ka väga positiivsed arvustused. Tuleb öelda, et need positiivsed arvustused on kõige suurem motivatsioon toote arendamiseks.
Töötajate kaugjuhtimise funktsionaalsuse lisamine
Üks klientide sagedasi soove on "andke Vanele võimalus oma arvutile kodust ligi pääseda". Me tõstsime VPN-i Mikrotikule ja tegime kasutajatele kontod. Kuid see on tõeliselt probleem. Kasutajad ei suuda vaadata juhendit ja järgida samme VPN-iga ühenduse loomiseks. Erinevad Windowsi versioonid. Ühes Windowsis läheb kõik hästi, teises on vajalik teistsugune protokoll. Ja kokkuvõttes on see alati seotud võrguseadmete seadistamisega, mis toimib VPN-serverina, kuid mitte kõigil töötajatel pole sellele juurdepääsu ning see oli ebamugav.
Aga meil on juba kaugühendused serverite ja võrguseadmetega. Miks mitte kasutada olemasolevat transporti ja luua eraldi väike utiliit, mille saaks lihtsalt kasutajale ühendamiseks anda. Soov oli ainult teha nii, et kasutaja ei peaks seal midagi keerulist sisestama. Lihtsalt üks nupp „ühenda“. Kuid kuidas see utiliit peaks aru saama, kuhu ühenduda, kui seal on vaid üks nupp? Oli idee koostada vajalikke rakendusi meie serverites. Süsteemiadministraator vajutab nuppu „laadi ikoon alla“ ja meie pilve saadetakse käsk individuaalse binaari koostamiseks, kus on sisse kirjutatud teave, kuidas ühenduda vajalikku serverisse / arvutisse RDP kaudu. Üldiselt oleks seda võimalik teha. Kuid see võtaks kaua aega, administraator peaks esmalt ootama, kuni binaar koostatakse, ja seejärel ka alla laadima. Loomulikult oleks saanud lisada lihtsalt teise faili config jaoks, kuid see on juba 2 faili, ja kasutajale on lihtsuse nimel vajalik üks. Üks fail, üks nupp ja mingeid installereid pole. Veidi Google'i avarustes ringi vaadates jõudsin järeldusele, et kui manustada mingit teavet kompileeritud “.exe” lõppu, siis see ei riku (no peaaegu). Tood sisse isegi sõda ja rahu ja see töötab nagu varem. Häbi on seda mitte ära kasutada. Nüüd on võimalik lihtsalt jooksvalt kliendis rakendust dekompresseerida, muide selle nimi on Veliam Connector, ja lihtsalt kirjutada lõppu vajalikud ühenduse loomise andmed. Ja rakendus ise teab, mida sellega teha. Miks ma kirjutasin sulgudes „no peaaegu“? Sest selle mugavuse eest tuleb maksta sellega, et rakendus kaotab enda digitaalallkirja. Kuid meie praeguses etapis peame seda väikeseks hinnaks sellise mugavuse eest.
Kolmandate osapoolte moodulite litsentsid
Eelnevalt mainisin, et pärast otsust toode avalikuks teha, mitte ainult enda tarbeks, tuli kõvasti vaeva näha ja leida asendusi teatud moodulitele, mis ei võimaldanud neid meie toote koosseisu kaasata. Kuid juba pärast väljaandmist avastati juhuslikult üsna ebameeldiv asi. Veliam Serveri, mis oli kliendi poolel, koosseisus oli andmebaas MariaDB. Ja sellel on GPL-litsents. GPL-litsents eeldab, et tarkvara peab olema avatud lähtekoodiga, ja kui meie toote koosseisu kuulub MariaDB, millel on see litsents, siis peab ka meie toode olema selle litsentsi all. Kuid õnneks on selle litsentsi eesmärk avatud lähtekood, mitte karistamine kohtus neid, kes on kogemata eksinud. Kui õiguste omanikul tekib pretensioon, peab ta kirjalikult teavitama rikkumise tegijat ja see peab 30 päeva jooksul rikkumise kõrvaldama. Me avastasime oma vea ise ja kirju ei saanud ning asusime kohe kaaluma võimalusi, kuidas probleemi lahendada. Lahendus osutus ilmselgeks — üleminek SQLite'ile. Sellel andmebaasil ei ole mingeid litsentsimise piiranguid. Enamik kaasaegseid brauserid kasutab SQLite'i, samuti palju teisi programme. Leidsin internetist teavet, et SQLite on maailma kõige levinum andmebaas, just tänu brauseritele, kuid ma ei otsinud tõendeid, nii et see teave ei ole täpne. Alustasin uurimist, millised riskid kaasnevad üleminekuga SQLite'ile.
See muutub juba mittetüliks ülesandeks, kui klientidel on mitu sada serverit, kus on paigaldatud MariaDB ja kus on andmed. Mõned MariaDB funktsioonid ei ole SQLite'is saadaval. Näiteks, koodis kasutati päringuid, mis on kujul
Select * FROM `table` WHERE `id`>1000 FOR UPDATE
See konstruktsioon mitte ainult ei salvesta andmeid tabelist, vaid blokeerib ka vastavad read. Veel paar konstruktsiooni tuli samuti ümber kirjutada. Kuid lisaks sellele, et tuli ümber kirjutada palju päringuid, tuli välja mõelda ka mehhanism, mis Veliam Serveri uuendamisel kliendil kõik andmed uude andmebaasi seadistaks ja vana eemaldaks. Samuti ei töötanud SQLite'is tehingud ja see oli tõeliseks probleemiks. Kuid pärast internetis ringi vaatamist leidsin kergesti, et SQLite'is saab tehingud sisse lülitada, edastades ühendamisel lihtsa käsu
PRAGMA journal_mode=WAL;Kokkuvõttes on ülesanne täidetud ja nüüd töötab klientide serveripoolne osa SQLite'il. Me ei ole süsteemi töö osas mingeid muutusi täheldanud.
Uus HelpDesk
Sisemisest versioonist SaaS versiooniks oli vaja portida HelpDeski süsteem, kuid teatud muudatustega. Esimene asi, mida sooviti teha — oli klientide domeeniga integreerimine, et tagada kasutajate sujuv autentimine süsteemis. Nüüd, et kasutaja pääseks HelpDeski ja esitaks süsteemis taotluse, peab ta lihtsalt oma töölaual asjale klõpsama, mis avab brauseri. Kasutaja ei sisesta mingeid kontodetaile. Apache SSPI moodul, mis kuulub Veliam Serveri koosseisu, autentib kasutaja automaatselt domeeni kontoga. Kui kasutaja asub ettevõtte võrgust väljaspool ja soovib süsteemis taotlust esitada, siis vajutab ta nuppu ja saab meilile lingi, mille kaudu saab ta süsteemi HelpDesk ilma paroolideta sisse logida. Kui kasutaja domeenis keelatakse või kustutatakse, siis lõpetab ka tema HelpDeski konto toimimise. Seega ei pea süsteemiadministraator jälgima kontosid nii domeenis kui ka HelpDeskis. Kui töötaja lahkub, siis keelatakse tema konto domeenis ja kõik, ta ei pääse enam süsteemi ei ettevõtte võrgust ega ka lingiga. Selle integreerimise tööks peab süsteemiadministraator looma ühe GPO, mis ja .
Teine asi, mida peame HelpDeski süsteemide jaoks äärmiselt vajalikuks, vähemalt meie jaoks, on võimalus ühendust võtta kaebuse esitajaga otse kaebusest ühe klikiga. Veelgi enam, ühendused peaksid toimuma ka siis, kui süsteemiadministraator asub teises võrgus. Väljaäestamiseks on see hädavajalik ning ka tavapäraste süsteemiadministraatorite jaoks sageli väga vajalik. On juba mitmeid tooteid, mis teevad kaugühendusi suurepäraselt. Otsustasime nendele luua integratsioonid. Praegu oleme integreerinud VNC ning tulevikus kavandame Radmini ja TeamVieweri lisamist. Kasutades meie võrgutransporti kaugühenduste jaoks infrastruktuurile, saime teha nii, et VNC ühendub kaug-tööjaamadega NAT-i taga. Sama kehtib ka Radmini puhul. Praegu, et kasutajaga ühendust võtta, peab kaebuses lihtsalt klikkima nuppu "ühenda kaebuse esitajaga". Avaneb VNC klient, mis ühendub kaebuse esitaja juurde, sõltumata sellest, kas olete samas võrgus või istute kodus pükstes. Eelnevalt peaks süsteemiadministraator GPO vahendusel installima kõigile tööjaamadele VNC Serveri.
Praegu viime ise üle uuele HelpDeskile ja kasutame integreerimist domeeniga ja VNC-ga. See on meie jaoks väga mugav. Nüüd ei pea me maksma TeamVieweri eest, mida oleme kasutanud rohkem kui kolm aastat oma tugiteenuse tööks.
Mida plaanime edaspidi teha
Kui me toote turule tõime, ei hakanud me pakkuma tasulisi hindu, vaid piirasime tasuta plaani 50 jälgitava objektiga. Me mõtlesime, et viiskümmend võrguseadet ja serverit peaks kõigile piisama. Ja siis hakkasid tulema küsimised limiidi suurendamise kohta. Öelda, et olime veidi šokeeritud — oleks alahinnatud. Kas tõesti on meie tarkvara huvitatud ettevõtetest, kellel on nii palju servereid? Me suurendasime tasuta limiiti neile, kes seda küsisid. Mõnelt küsisime vastuseks, miks neil on nii palju, kas tõesti on neil nii palju servereid ja võrguseadmeid. Selgus, et süsteemi hakkasid kasutama süsteemiadministraatorid, nii nagu me üldse ei plaaninud. Kõik osutus lihtsaks — meie tarkvaraga hakati jälgima mitte ainult servereid, vaid ka tööjaamu. Seetõttu tuli palju küsida limiitide suurendamise kohta. Praegu oleme juba sisse viinud tasulised plaanid ja limite saab ise suurendada.
Serverid töötavad peaaegu alati kas SDH-de (salvestusseadmete süsteemide) või kohalike diskide RAID-massiividega. Alguses tegime me toote nende jaoks. SMART-i jälgimine ei olnud selle ülesande jaoks huvitav. Kuid arvestades, et inimesed kohandasid tarkvara tööjaamade jälgimiseks, tulid küsimised SMART-i jälgimise rakendamise kohta. Varsti viime selle ellu.
Veliam Connectori saabumisega on ettevõtte võrgus VPN-serveri seadistamine või RDGW loomine või lihtsalt sadamate suunamine vajalikest masinatest RDP ühendamiseks osutunud enam mitte vajalikuks. Paljud kasutavad meie süsteemi ainult nende kaugühenduste jaoks. Veliam Connector on saadaval ainult Windowsile, kuid mõned ettevõtte kasutajad ühendavad oma koduloodud MacOS-i sülearvutite kaudu tööjaamade või terminalide juurde ettevõtte võrgus. Seega peab süsteemiadministraator ikka veel tegelema sadamate suunamise või VPN-iga, kuna mõned kasutajad vajavad seda. Seetõttu viime praegu lõpule Veliam Connectori versiooni MacOS-i jaoks. Kasutajad saavad oma lemmik Apple'i seadmete kaudu ühe klikiga ettevõtte infrastruktuuri ühenduda.
Mulle meeldib väga, et suure arvu süsteemi kasutajatega ei ole vaja muretseda selle üle, mida inimesed vajavad ja mis neile mugav on. Nad kirjutavad ise oma soovid, nii et lähiajal on arendamiseks palju plaane.
Samas plaanime praegu süsteemi tõlkimist inglise keelde ja selle levitamist välismaal. Me ei tea veel, kuidas me toodet väljaspool meie riiki levitame, otsime võimalusi. Võimalik, et sellest tuleb hiljem eraldi artikkel. Võib-olla suudab keegi, kes on seda artiklit lugenud, soovitada vajalikku suunda, või teab ja oskab seda teha ning pakub oma teenuseid. Oleme aitamise eest tänulikud.
Allikas: habr.com
