Fra outsourcing til udvikling (del 2)

В forrige artikel, jeg talte om baggrunden for oprettelsen af ​​Veliam og beslutningen om at distribuere det gennem SaaS-systemet. I denne artikel vil jeg fortælle om, hvad jeg skulle gøre for at gøre produktet ikke lokalt, men offentligt. Om hvordan distributionen begyndte og hvilke problemer de stødte på.

planlægning

Den nuværende backend for brugere var på Linux. Næsten alle organisationer har Windows-servere, hvilket ikke kan siges om Linux. Veliams største styrke er fjernforbindelser til servere og netværksudstyr bag NAT. Men denne funktionalitet var meget tæt knyttet til, at routeren skulle være Mikrotik. Og dette ville åbenbart ikke tilfredsstille mange. Jeg begyndte først at tænke på at tilføje support til routere fra de mest almindelige leverandører. Men jeg forstod, at dette var et endeløst kapløb om at udvide listen over støttede virksomheder. Desuden kan de, der allerede understøttes, have et andet sæt kommandoer til at ændre NAT-regler fra model til model. Den eneste vej ud af situationen syntes at være en VPN.

Da vi besluttede at distribuere produktet, men ikke som open source, blev det umuligt at inkludere forskellige biblioteker med åbne licenser såsom GPL. Dette er generelt et separat emne; efter at have truffet beslutningen om at sælge produktet, var jeg nødt til at gennemgå halvdelen af ​​bibliotekerne på grund af det faktum, at de var GPL. Når de skrev for sig selv, var det normalt. Men ikke egnet til distribution. Den første VPN, der kommer til at tænke på, er OpenVPN. Men det er GPL. En anden mulighed var at bruge den japanske SoftEther VPN. Hans licens tillod ham at inkludere det i sit produkt. Efter et par dages forskellige test af, hvordan man integrerer det på en sådan måde, at brugeren ikke behøver at konfigurere noget som helst og kende til SoftEther VPN, blev der opnået en prototype. Alt var som det skulle være. Men af ​​en eller anden grund forvirrede denne ordning os stadig, og vi opgav den til sidst. Men de nægtede naturligvis, efter at de fandt på en anden mulighed. I sidste ende blev alt gjort på almindelige TCP-forbindelser. Nogle forbindelser fungerer gennem en koordinator, nogle direkte gennem Nat Hole Punching (NHP) teknologien, som også blev implementeret i Free Pascal. Jeg må sige, at jeg aldrig havde hørt om NHP før. Og det faldt mig aldrig ind, at det var muligt at forbinde 2 netværksenheder, som begge er direkte bag NAT. Jeg studerede emnet, forstod operationsprincippet og satte mig ned for at skrive. Planen realiseres, brugeren forbinder med et klik til den ønskede enhed bag NAT via RDP, SSH eller Winbox uden at indtaste adgangskoder eller opsætte en VPN. Desuden går de fleste af disse forbindelser forbi vores koordinator, hvilket har en god effekt på ping og omkostningerne ved at servicere disse forbindelser.

Overførsel af serverdelen fra Linux til Windows

Der var flere problemer ved skift til Windows. Den første er, at den indbyggede wmic i Windows ikke tillader dig at lave WQL-forespørgsler. Og i vores system var alt allerede bygget på dem. Og der var noget andet, men nu har jeg glemt, hvorfor de endelig opgav at bruge det. Muligvis forskelle mellem Windows-versioner. Og det andet problem er multithreading. Da jeg ikke fandt et godt tredjepartsværktøj under en "acceptabel" licens for os, lancerede jeg Lazarus IDE igen. Og jeg skrev det nødvendige hjælpeprogram. Indgangen er den påkrævede liste over objekter og hvilke specifikke forespørgsler der skal laves, og som svar modtager jeg data. Og alt dette i multi-threaded mode. Store.

Efter jeg havde sat pthreads op til PHP Windows, troede jeg, at alt ville starte med det samme, men det var ikke tilfældet. Efter nogen tids debugging indså jeg, at pthreads så ud til at virke, men det virkede ikke på vores system. Det blev klart, at der er noget særegent ved at arbejde med pthreads på Windows. Og sådan var det. Jeg læste dokumentationen, og der stod der, at for Windows er antallet af tråde begrænset, og, så vidt jeg husker, implicit. Dette blev et problem. For da jeg begyndte at reducere antallet af tråde, applikationen kørte på, klarede den arbejdet meget langsomt. Jeg åbnede IDE igen, og funktionalitet til multi-threaded ping af objekter blev tilføjet til det samme værktøj. Nå, der er allerede en masse port-scanning der også. Faktisk efter dette forsvandt behovet for pthreads til PHP, og det bruges ikke længere. Yderligere blev flere funktioner tilføjet til dette værktøj, og det fungerer stadig den dag i dag. Herefter blev der samlet et installationsprogram til Windows, som inkluderede Apache, PHP, MariaDB, selve PHP-applikationen og et sæt værktøjer til at interagere med systemet, skrevet i Free Pascal. Med hensyn til installatøren troede jeg, at jeg hurtigt ville løse dette problem, fordi... Dette er en meget almindelig ting og nødvendig for næsten enhver software. Enten ledte jeg det forkerte sted, eller noget andet. Men jeg stødte hele tiden på produkter, der enten ikke var fleksible nok, eller dyre og også ufleksible. Og alligevel fandt jeg et gratis installationsprogram, hvor det vil være muligt at sørge for eventuelle ønsker. Dette er InnoSetup. Jeg skriver om dette her, fordi jeg var nødt til at slå det op, hvis jeg skulle spare nogen tid.

Afvisning af plugin til fordel for din klient

Jeg skrev tidligere, at klientdelen var en browser med et “plugin”. Så der var tidspunkter, hvor Chrome blev opdateret, og layoutet var lidt skævt, så blev Windows opdateret, og det brugerdefinerede uri-skema forsvandt. Jeg ville virkelig ikke have den slags overraskelser i den offentlige version af produktet. Desuden begyndte den brugerdefinerede uri at forsvinde efter hver Windows-opdatering. Microsoft slettede simpelthen alle ikke-dets filialer i den påkrævede sektion. Desuden tillader Google Chrome dig nu ikke at huske valget om at åbne eller ej et program fra den tilpassede uri, og stiller dette spørgsmål, hver gang du klikker på et overvågningsobjekt. Nå, generelt var normal interaktion med brugerens lokale system nødvendig, hvilket browseren ikke tilbyder. Den enkleste mulighed i denne ordning ser ud til at være simpelthen at lave din egen browser, som mange nu gør gennem Electron. Men mange ting var allerede skrevet i Free Pascal, inklusive i serverdelen, så vi besluttede at lave klienten på samme sprog og ikke oprette en zoologisk have. Sådan blev en klient med Chromium ombord skrevet. Derefter begyndte den at anskaffe sig forskellige stropper.

Frigøre

Til sidst valgte vi et navn til systemet. Vi gennemgik konstant forskellige muligheder, mens processen med at konvertere fra den lokale version til SaaS var i gang. Da vi oprindeligt planlagde ikke kun at gå ind på hjemmemarkedet, var hovedkriteriet for valg af navn tilstedeværelsen af ​​et ledigt eller ikke særlig dyrt domæne i ".com"-zonen. Nogle funktioner/moduler er endnu ikke blevet overført fra den lokale version til Veliam, men vi besluttede, at vi ville frigive dem med den nuværende funktionalitet og fuldføre resten som opdateringer. I den allerførste version var der ingen HelpDesk, Veliam Connector, det var umuligt at ændre tærsklerne for notifikationsudløsere og meget mere. Vi købte et kodetegncertifikat og signerede klient- og serverdelene. Vi skrev en hjemmeside for produktet, begyndte procedurer for registrering af software, et varemærke osv. Generelt er vi klar til at starte. En lille eufori fra det udførte arbejde og fra det faktum, at nogen måske vil bruge dit produkt, selvom vi ikke var i tvivl om dette. Og så stop. Partneren sagde, at det er umuligt at komme ind på markedet uden meddelelser via messengers. Det er muligt uden mange andre ting, men ikke uden dette. Efter lidt debat blev der tilføjet integration med Telegram, hvilket passede os. Af alle de nuværende instant messengers er dette den eneste, der giver adgang til sine API'er gratis og uden nogen komplekse godkendelsesprocedurer. Den samme WhatsApp foreslår at kontakte udbydere, der opkræver gode penge for at bruge deres tjenester; alle breve, der beder om adgang uden pakninger, blev ignoreret. Nå, Viber... Jeg ved ikke, hvem der bruger det nu, fordi... spam og reklame der er ude af hitlisterne. I slutningen af ​​december, efter en række interne tests og tests blandt venner, blev der åbnet for registrering for alle, og softwaren blev gjort tilgængelig til download.

Start af distribution

Helt fra begyndelsen forstod vi, at vi havde brug for et lille flow af systembrugere, så de kunne teste produktet i kamptilstand og give noget første feedback. Flere indkøbte indlæg på VK bar frugt. De første tilmeldinger er kommet.

Her skal det siges, at det er meget svært at komme ind på markedet, når din virksomhed ikke har et kendt navn, og samtidig levere agentløs overvågningsfunktionalitet, hvor du skal indtaste konti fra dine servere og arbejdsstationer. Dette skræmmer mange mennesker. Vi forstod helt fra starten, at der ville være problemer med dette og var forberedt på dette både teknisk og moralsk. Alle fjernforbindelser, på trods af at RDP og SSH allerede er krypteret som standard, krypteres desuden af ​​vores software ved hjælp af AES-standarden. Alle data fra lokale servere overføres til skyen via HTTPS. Konti gemmes i krypteret form. Krypteringsnøgler for alle undersystemer er individuelle for alle klienter. Til fjernforbindelser bruges sessionskrypteringsnøgler generelt.

Alt, hvad vi kan gøre i denne situation for at få folk til at føle sig roligere, er at være så åbne som muligt, arbejde på sikkerheden og aldrig blive trætte af at besvare folks spørgsmål.

For mange opvejer softwarens bekvemmelighed og funktionalitet frygten, og de registrerer sig. Nogle personer skrev i publicerede indlæg på VK, at denne software ikke kan bruges pga Dette er en samling af deres adgangskoder og generelt et firma uden navn. Det skal siges, at mere end én person havde denne mening. Mange mennesker forstår simpelthen ikke, at når de installerer anden proprietær software på en server, der kører som en tjeneste, har den også fulde rettigheder i systemet, og de behøver ikke konti for at gøre noget ulovligt (det er klart, at du kan ændre bruger, fra hvem tjenesten er lanceret, men også her kan du indtaste en hvilken som helst konto). Faktisk er folks frygt forståelig. Installation af software på en server er en almindelig ting, men at indtaste en konto er lidt skræmmende og intimt, da godt halvdelen af ​​mennesker har den samme adgangskode til alle tjenester, og at oprette en separat konto selv til en test er doven. Men i øjeblikket er der et stort antal tjenester, som folk stoler på med deres legitimationsoplysninger og mere. Og vi stræber efter at blive en af ​​dem.

Der var mange kommentarer, der sagde, at vi stjal det et sted. Dette overraskede os lidt. Nå, okay, en persons mening, men sådanne kommentarer blev fundet i forskellige publikationer fra forskellige mennesker. Først vidste de ikke, hvordan de skulle reagere på dette. Enten for at være kede af, at nogle mennesker har den opfattelse, at i Rusland kan ingen gøre noget på egen hånd, men kun kan stjæle, eller for at være glad for, at de tror, ​​at dette kun kan stjæles.

Vi har nu afsluttet proceduren for at opnå et EV-kodeskiltcertifikat. For at få det skal du igennem en række kontroller og sende en masse dokumenter om virksomheden, hvoraf nogle skal attesteres af en advokat. At opnå et EV Code Sign-certifikat under en pandemi er et separat emne for en artikel. Proceduren tog en måned. Og det var ikke en måneds ventetid, men med konstante anmodninger om yderligere dokumenter. Måske havde pandemien ikke noget med det at gøre, og proceduren tog så lang tid for alle? Del.

Nogle siger, at vi ikke vil bruge det, fordi der ikke er noget FSTEC-certifikat. Vi er nødt til at forklare, at vi ikke kan få det og ikke vil, fordi for at opnå dette certifikat skal kryptering være i overensstemmelse med GOST, og vi planlægger at distribuere softwaren ikke kun i Rusland og bruge AES.

Alle disse kommentarer sår en vis tvivl om, at det er muligt at promovere et produkt, der kræver, at du indtaster konti uden at være offentligt kendt. Også selvom vi vidste, at der ville være dem, der havde en meget negativ holdning til dette. Efter at antallet af tilmeldinger oversteg tusinde, holdt vi op med at tænke på det. Især efter, ud over negativiteten hos dem, der ikke engang havde prøvet produktet, begyndte der at dukke meget behagelige anmeldelser op. Det skal siges, at disse positive anmeldelser er den største motivator for produktudvikling.

Tilføjelse af fjernadgangsfunktionalitet for medarbejdere

En af de hyppige opgaver fra kunder er "give Vanya adgang til sin computer hjemmefra." Vi rejste VPN på Mikrotik og oprettede konti til brugere. Men dette er et reelt problem. Brugere er ikke i stand til at se instruktionerne og følge dem trin for trin for at oprette forbindelse via VPN. Forskellige versioner af Windows. I et Windows forbinder alt godt, i et andet er det nødvendigt med en anden protokol. Og generelt var dette altid forbundet med omkonfigurationen af ​​netværksudstyr, som fungerede som en VPN-server, og ikke alle medarbejdere har adgang til det, og det var ubelejligt.

Men vi har allerede fjernforbindelser til servere og netværksudstyr. Hvorfor ikke bruge en færdiglavet transport og lave et separat lille hjælpeprogram, som du blot kan give til brugeren for at forbinde. Jeg ville bare sikre mig, at brugeren ikke indtastede noget abstrut der. Kun én knap "tilslut". Men hvordan vil dette værktøj forstå, hvor det skal forbindes, hvis det kun har én knap? Der var en idé om at bygge den nødvendige applikation online på vores servere. Systemadministratoren klikker på "download genvej"-knappen, og en kommando sendes til vores sky for at bygge en individuel binær med fastkablet information til at oprette forbindelse til den ønskede server/computer via RDP. Generelt kunne dette lade sig gøre. Men dette tager lang tid; administratoren skal først vente, indtil binærfilen er kompileret og derefter downloadet. Selvfølgelig ville det være muligt blot at tilføje en anden fil med config, men dette er allerede 2 filer, og for nemheds skyld har brugeren brug for en. Én fil, én knap og ingen installationsprogrammer. Efter at have læst lidt på Google, kom jeg til den konklusion, at hvis du tilføjer nogle oplysninger til slutningen af ​​den kompilerede ".exe", så forringes det ikke (nå, næsten). Du kan i det mindste tilføje krig og fred der, og det vil fungere som før. Det ville være synd ikke at udnytte dette. Nu kan du blot pakke applikationen ud, mens du er på farten, lige i selve klienten, som den hedder Veliam Connector, og blot tilføje de nødvendige oplysninger til at oprette forbindelse til den til sidst. Og applikationen ved selv, hvad den skal gøre med den. Hvorfor skrev jeg "nå næsten" i parentes lidt højere? Fordi du skal betale for denne bekvemmelighed, idet applikationen mister sin digitale signatur. Men på nuværende tidspunkt mener vi, at dette er en lille pris at betale for en sådan bekvemmelighed.

Tredjeparts modullicenser

Jeg skrev allerede ovenfor, at efter det blev besluttet at gøre produktet offentligt tilgængeligt, og ikke kun til eget brug, skulle vi arbejde hårdt og lede efter erstatninger til nogle moduler, der ikke lod os indgå i vores produkt. Men efter udgivelsen blev der ved et uheld opdaget en meget ubehagelig ting. Veliam Server, som var på klientsiden, inkluderede MariaDB DBMS. Og det er GPL-licenseret. GPL-licensen indebærer, at softwaren skal være open source, og hvis vores produkt inkluderer MariaDB, som har denne licens, skal vores produkt være under denne licens. Men heldigvis er formålet med denne licens open source, og straffer ikke dem, der ved et uheld laver fejl i retten. Hvis indehaveren af ​​ophavsretten har et krav, underretter han skriftligt krænkeren, og han skal fjerne krænkelsen inden for 30 dage. Vi opdagede selv vores fejl og modtog ingen breve og begyndte straks at overveje muligheder for at løse problemet. Løsningen viste sig at være oplagt - skift til SQLite. Denne database har ingen licensbegrænsninger. De fleste moderne browsere bruger SQLite og en masse andre programmer. Jeg fandt information på internettet om, at SQLite anses for at være den mest udbredte DBMS i verden, netop på grund af browserne, men jeg ledte ikke efter beviser, så det er unøjagtig information. Jeg begyndte at studere farerne ved at skifte til SQLite.

Dette bliver en ikke-triviel opgave, når klienter har flere hundrede servere installeret med MariaDB og data i den. Nogle MariaDB-funktioner er ikke tilgængelige i SQLite. Nå, for eksempel, i koden brugte vi forespørgsler som

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

Denne konstruktion foretager ikke kun et valg fra tabellen, men låser også rækkedataene. Og flere designs skulle også omskrives. Men udover at vi skulle omskrive en masse forespørgsler, skulle vi også finde på en mekanisme, der ved opdatering af klientens Veliam Server ville portere alle data til det nye DBMS og slette det gamle. Også transaktioner i SQLite virkede ikke, og dette var et reelt problem. Men efter at have læst det store World Wide Web, fandt jeg uden problemer ud af, at transaktioner i SQLite kan aktiveres ved at sende en simpel kommando, når du forbinder

PRAGMA journal_mode=WAL;

Som et resultat blev opgaven fuldført, og nu kører klientens serverdel på SQLite. Vi har ikke bemærket nogen ændringer i driften af ​​systemet.

Ny HelpDesk

Det var nødvendigt at portere HelpDesk-systemet fra den interne version til SaaS-versionen, men med nogle ændringer. Det første jeg ville gøre var integration med klientens domæne i form af gennemsigtig brugerautorisation i systemet. Nu, for at logge ind på HelpDesk og efterlade en anmodning i systemet, klikker brugeren blot på genvejen på skrivebordet, og browseren åbnes. Brugeren indtaster ingen legitimationsoplysninger. Modulet til Apache SSPI, som er en del af Veliam Server, autoriserer automatisk brugeren under en domænekonto. For at efterlade en anmodning i systemet, når brugeren er uden for virksomhedens netværk, klikker han på en knap, og han modtager et link i sin e-mail, hvorigennem han logger ind på HelpDesk-systemet uden adgangskoder. Hvis en bruger er deaktiveret eller slettet i et domæne, vil HelpDesk-kontoen også holde op med at fungere. Systemadministratoren behøver således ikke selv at overvåge konti i både domænet og HelpDesk. En medarbejder afslutter - han afbryder forbindelsen til sin konto i domænet, og det er det, han vil ikke logge ind på systemet, ikke fra virksomhedens netværk, ikke via et link. For at denne integration skal fungere, skal systemadministratoren oprette én GPO, som tilføjer et internt websted til intranetzonen и distribuerer en genvej til alle brugere på skrivebordet.

Den anden ting, vi anser for yderst nødvendig for HelpDesk-systemer, i hvert fald for os selv, er at oprette forbindelse til ansøgeren direkte fra applikationen med et enkelt klik. Desuden skal forbindelser bestå, hvis systemadministratoren er på et andet netværk. For outsourcing er dette obligatorisk, for fuldtidsansatte systemadministratorer er det også ofte meget nødvendigt. Der er allerede flere produkter, der gør et fremragende stykke arbejde med fjernforbindelser. Og vi besluttede at lave integrationer til dem. Vi har nu integreret til VNC, og i fremtiden planlægger vi at tilføje Radmin og TeamViewer. Ved at bruge vores netværkstransport til fjerninfrastrukturforbindelser fik vi VNC til at forbinde til fjernarbejdsstationer bag NAT. Det samme vil ske med Radmin. Nu, for at oprette forbindelse til en bruger, skal du blot klikke på knappen "Opret forbindelse til ansøger" i selve applikationen. VNC-klienten åbner og forbinder til ansøgeren, uanset om du er på samme netværk eller sidder hjemme i hjemmesko. Først skal systemadministratoren, ved hjælp af GPO, installere VNC Server på alles arbejdsstationer.

Nu skifter vi selv til den nye HelpDesk og bruger integration med domænet og VNC. Dette er meget praktisk for os. Nu kan vi slippe for at betale for TeamViewer, som vi har brugt i mere end tre år til at drive vores supportservice.

Hvad planlægger vi at gøre næste gang?

Da vi udgav produktet, lavede vi ingen betalte tariffer, men begrænsede blot den gratis takst til 50 overvågningsobjekter. Fem dusin netværksenheder og servere burde være nok til alle, troede vi. Og så begyndte der at komme anmodninger om at øge grænsen. At sige, at vi var lidt chokerede, er at sige ingenting. Er virksomheder, der har så mange servere, virkelig interesserede i vores software? Vi udvidede grænsen gratis for dem, der fremsatte sådanne anmodninger. Som svar på deres forespørgsel spurgte vi nogle, hvorfor de havde brug for så meget, havde de virkelig et så stort antal servere og netværksudstyr. Og det viste sig, at systemadministratorer begyndte at bruge systemet på måder, vi slet ikke havde planlagt. Alt viste sig at være enkelt - vores software begyndte at overvåge ikke kun servere, men også arbejdsstationer. Derfor er der mange anmodninger om at udvide grænserne. Nu har vi allerede indført betalte takster, og grænserne kan udvides selvstændigt.

Servere arbejder næsten altid med enten lagersystemer eller lokale diske i et RAID-array. Og vi lavede i første omgang produktet til dem. Og SMART-overvågning var ikke interessant til denne opgave. Men taget i betragtning, at folk har tilpasset software til overvågning af arbejdsstationer, er der opstået anmodninger om implementering af SMART-overvågning. Vi implementerer det snart.

Med fremkomsten af ​​Veliam Connector blev det unødvendigt at installere en VPN-server i virksomhedens netværk, eller lave RDGW eller blot videresende porte til de nødvendige maskiner for at oprette forbindelse via RDP. Mange mennesker bruger kun vores system til disse fjernforbindelser. Veliam Connector er kun tilgængelig for Windows, og nogle virksomhedsbrugere opretter forbindelse fra bærbare hjemmecomputere, der kører MacOS, til arbejdsstationer eller terminaler på virksomhedens netværk. Og det viser sig, at systemadministratoren på grund af flere brugere er tvunget til stadig at vende tilbage til spørgsmålet om videresendelse eller VPN. Derfor er vi nu ved at færdiggøre en version af Veliam Connector til MacOS. Brugere af deres foretrukne Apple-teknologi vil også have mulighed for at oprette forbindelse til virksomhedens infrastruktur med et enkelt klik.

Jeg kan virkelig godt lide det faktum, at du med et stort antal systembrugere ikke behøver at tænke på, hvad folk har brug for, og hvad der vil være mere praktisk. De skriver selv deres ønsker, så der er en del udviklingsplaner for den nærmeste fremtid.

Parallelt hermed planlægger vi nu at begynde at oversætte systemet til engelsk og distribuere det til udlandet. Vi ved endnu ikke, hvordan vi vil distribuere produktet uden for vores land, vi leder efter muligheder. Måske kommer der en separat artikel om dette senere. Måske vil nogen, der har læst denne artikel, være i stand til at foreslå den nødvendige vektor, eller han selv ved og ved, hvordan man gør det og vil tilbyde sine tjenester. Vi ville sætte pris på din hjælp.

Kilde: www.habr.com

Tilføj en kommentar