In , ho raccontato la storia della creazione di Veliam e della decisione di distribuirlo tramite sistema SaaS. In questo articolo, parlerò di cosa è stato necessario fare affinché il prodotto diventasse pubblico anziché locale. Discuterò di come è iniziata la distribuzione e delle difficoltà incontrate.
Pianificazione
L'attuale parte server per gli utenti era su Linux. Quasi ogni organizzazione ha server Windows, cosa che non si può dire per Linux. Il principale punto di forza di Veliam sono le connessioni remote ai server e all'hardware di rete dietro NAT. Tuttavia, questa funzionalità era strettamente legata al fatto che il router dovesse necessariamente essere un MikroTik. E questo chiaramente non avrebbe soddisfatto molti. All'inizio pensavo di aggiungere il supporto per i router dei fornitori più comuni. Ma capivo che sarebbe stata una corsa infinita ad ampliare l'elenco delle aziende supportate. Inoltre, anche quelle già supportate possono avere un insieme diverso di comandi per modificare le regole NAT a seconda del modello. L'unica soluzione che vedevo era VPN.
Poiché abbiamo deciso di distribuire il prodotto, ma non come open source, non è stato possibile includere nel nostro pacchetto varie librerie con licenze aperte come la GPL. Questo è un argomento a parte; dopo la decisione di vendere il prodotto, abbiamo dovuto rivedere metà delle librerie a causa della loro licenza GPL. Quando scrivevamo per uso interno, andava bene. Ma non va bene per la distribuzione. Il primo VPN che viene in mente è OpenVPN. Ma è GPL. C'era anche l'opzione di utilizzare SoftEther VPN giapponese. La sua licenza consentiva di includerlo nel nostro prodotto. Dopo alcuni giorni di vari test su come integrarlo in modo che l'utente non dovesse configurare nulla e non sapesse nulla di SoftEther VPN, abbiamo ottenuto un prototipo. Era tutto come doveva essere. Tuttavia, per qualche motivo, questo schema ci inquietava comunque e alla fine abbiamo deciso di abbandonarlo. Ma, naturalmente, l'abbiamo fatto dopo aver pensato a un'altra soluzione. Alla fine, abbiamo realizzato tutto su normali connessioni TCP. Parte delle connessioni funziona tramite un coordinatore, parte direttamente attraverso la tecnologia Nat Hole Punching (NHP), che è stata anche implementata su Free Pascal. Devo dire che non avevo mai sentito parlare di NHP prima. Non potevo nemmeno immaginare che fosse possibile collegare due dispositivi di rete, entrambi nascosti dietro NAT, direttamente. Ho studiato l'argomento, ho capito il principio di funzionamento e mi sono messo a scrivere. L'idea si è concretizzata: l'utente si collega con un clic al dispositivo desiderato dietro NAT tramite RDP, SSH o Winbox senza dover inserire password e configurare VPN. Inoltre, gran parte di queste connessioni passa oltre il nostro coordinatore, il che si riflette positivamente sul ping e sul costo di mantenimento di queste connessioni.
Traduzione della parte server da Linux a Windows
Ci sono stati diversi problemi durante la transizione a Windows. Il primo è che il wmic integrato in Windows non consente di eseguire query WQL, mentre nel nostro sistema tutto era già impostato su di esse. C'era anche qualcos'altro, ma ora non ricordo perché abbiamo deciso di abbandonarlo. Forse ci sono differenze tra le versioni di Windows. E il secondo problema riguarda il multithreading. Non trovando un'utile utility di terze parti con una licenza "accettabile" per noi, ho rilanciato l'IDE Lazarus. Ho scritto l'utility necessaria. In input riceve l'elenco degli oggetti e quali query devono essere eseguite, mentre in output ottengo i dati. E tutto questo in modalità multithreading. Ottimo.
Dopo aver configurato i pthreads per PHP su Windows, pensavo che tutto sarebbe andato a buon fine, ma non è stato così. Dopo un po' di debug, ho capito che i pthreads sembravano funzionare, ma nella nostra configurazione non andavano. È diventato chiaro che c'era qualche particolare nel funzionamento dei pthreads su Windows. Ed effettivamente è così. Ho letto la documentazione e vi era scritto che per Windows il numero di thread è limitato, e se non erro, in modo implicito. Questo ha creato un problema. Infatti, quando ho iniziato a ridurre il numero di thread per cui l'applicazione funzionava, essa eseguiva il lavoro molto lentamente. Ho riaperto l'IDE e nella stessa utility è stata aggiunta la funzionalità per il ping multi-threading degli oggetti. E per non farsi mancare nulla, anche la scansione delle porte. Insomma, dopo questo, la necessità di pthreads per PHP è scomparsa e non è più utilizzato. In seguito, a questa utility sono state aggiunte altre funzionalità e continua a funzionare fino ad oggi. Dopo di che, è stato assemblato un installer per Windows, che includeva Apache, PHP, MariaDB, l'applicazione PHP stessa e un insieme di utility per interagire con il sistema, scritte in Free Pascal. Per quanto riguarda l'installer, pensavo di risolvere rapidamente la questione, visto che è qualcosa di estremamente comune e necessario per quasi ogni software. O non cercavo nel modo giusto, o qualcos'altro. Ma continuavo a trovare prodotti che erano o insufficientemente flessibili, o costosi e comunque poco flessibili. Eppure, ho trovato un installer gratuito in cui si potevano prevedere tutte le personalizzazioni desiderate. Si tratta di InnoSetup. Scrivo qui di questo, perché ho dovuto cercare, magari riesco a risparmiare tempo a qualcun altro.
Abbandono del plugin a favore del proprio cliente
In precedenza avevo scritto che la parte client era un browser con un «plugin». Ci sono stati tempi in cui, dopo ogni aggiornamento di Chrome, il layout si deformava leggermente, oppure dopo l'aggiornamento di Windows i custom uri smettevano di funzionare. Non volevo assolutamente avere questo genere di sorprese nella versione pubblica del prodotto. Inoltre, i custom uri iniziavano a non funzionare dopo ogni aggiornamento di Windows. Microsoft semplicemente eliminava tutte le sue branche necessarie nella sezione appropriata. Inoltre, Google Chrome ora non consente di ricordare la scelta di aprire o meno l'applicazione da custom uri e pone questa domanda ad ogni clic sull'oggetto di monitoraggio. In generale, era necessario un normale interfacciamento con il sistema locale dell'utente, cosa che il browser non offre. La soluzione più semplice in questo schema sembrava semplicemente creare il proprio browser, come molti stanno già facendo tramite Electron. Tuttavia, molte cose erano già scritte in Free Pascal, compresa la parte server, quindi si è deciso di realizzare anche il client nello stesso linguaggio, evitando di creare uno zoo di linguaggi. Così è stato scritto il client con Chromium a bordo. Dopo di ciò, ha cominciato ad arricchirsi di vari wrapper.
Rilascio
Finalmente abbiamo scelto il nome per il sistema. Abbiamo esaminato diverse opzioni mentre lavoravamo alla transizione dalla versione locale a SaaS. Poiché inizialmente prevedevamo di uscire anche sul mercato estero, il principale criterio per la scelta del nome è stata la disponibilità di un dominio libero, o non troppo costoso, nella zona “.com”. Alcune funzioni/moduli non erano ancora stati portati dalla versione locale a Veliam, ma abbiamo deciso di rilasciare con le funzionalità attuali, e di completare il resto con aggiornamenti successivi. Nella prima versione non c'era HelpDesk, Veliam Connector, non era possibile modificare le soglie di attivazione delle notifiche e molte altre cose. Abbiamo acquistato un certificato di firma del codice e firmato le parti client e server. Abbiamo creato un sito per il prodotto e avviato le procedure di registrazione del software, del marchio, ecc. Insomma, eravamo pronti a partire. Una leggera euforia per il lavoro svolto e per il fatto che il nostro prodotto possa essere utilizzato da qualcuno, anche se su questo non avevamo dubbi. E qui arriva un freno. Un partner ha detto che senza notifiche nei messaggeri non si può entrare nel mercato. Si può fare a meno di molte altre cose, ma non di questo. Dopo brevi discussioni, è stata aggiunta l'integrazione con Telegram, che ci ha soddisfatti. Tra tutti i messaggeri attuali, è l'unico che offre accesso alle proprie API gratuitamente e senza complicate procedure di approvazione. Lo stesso WhatsApp invita a contattare i fornitori, che richiedono un bel po' di soldi per l'utilizzo dei loro servizi, tutte le lettere di richiesta di accesso sono state ignorate. E per quanto riguarda Viber… Non so chi lo utilizzi adesso, dato che lo spam e la pubblicità sono davvero eccessivi. Alla fine di dicembre, dopo una serie di test interni e test tra amici, abbiamo aperto le registrazioni per tutti e rilasciato il software per il download.
Inizio della diffusione
Fin dall'inizio abbiamo capito che avevamo bisogno di un piccolo numero di utenti del sistema affinché potessero testare il prodotto in modalità operativa e fornire un primo feedback. Alcuni post sponsorizzati su VK hanno dato i loro frutti. Sono arrivate le prime registrazioni.
Va detto che entrare nel mercato senza un nome famoso per la propria azienda e offrire funzionalità di monitoraggio senza agenti, in cui è necessario inserire le credenziali dei propri server e stazioni di lavoro, non è affatto semplice. Molte persone sono spaventate da questo. Fin dall'inizio, eravamo consapevoli che ci sarebbero state difficoltà e ci eravamo preparati sia tecnicamente che moralmente. Tutte le connessioni remote, nonostante RDP e SSH siano già criptati per impostazione predefinita, vengono ulteriormente crittografate dal nostro software secondo lo standard AES. Tutti i dati dai server locali vengono trasferiti nel cloud tramite HTTPS. Le credenziali sono conservate in forma crittografata. Le chiavi di crittografia per tutti i sottosistemi di ciascun cliente sono individuali. Per le connessioni remote vengono utilizzate chiavi di crittografia di sessione.
Tutto ciò che possiamo fare in questa situazione per tranquillizzare le persone è essere il più trasparenti possibile, lavorare sulla sicurezza e non stancarci di rispondere alle domande che le preoccupano.
Per molti, la comodità e la funzionalità del software superano la paura, e si registrano. Alcuni individui nei post pubblicati su VK hanno scritto che non si può usare questo software poiché raccoglie le loro password e proviene da un'azienda sconosciuta. Va detto che questo punto di vista non era condiviso da una sola persona. Molti non comprendono che, quando installano un altro software proprietario sul server, il quale funziona come un servizio, ha gli stessi diritti sul sistema e non ha bisogno di credenziali per fare qualcosa di illecito (è chiaro che si può cambiare l'utente da cui parte il servizio, ma anche in questo caso si può inserire qualsiasi account). In realtà, le preoccupazioni delle persone sono comprensibili. Installare software su un server è un'abitudine, mentre inserire le credenziali è già un po' spaventoso e intimo, poiché molte persone utilizzano una sola password per tutti i servizi, e creare un account separato anche solo per un test è faticoso. Tuttavia, attualmente ci sono un enorme numero di servizi ai quali le persone affidano le proprie credenziali e non solo. E noi ci sforziamo di diventare uno di questi.
Molti commenti del tipo che abbiamo rubato da qualche parte ci hanno sorpreso. Ci ha stupito un po'. Va bene, è l'opinione di una sola persona, ma commenti simili sono apparsi in diverse pubblicazioni da persone diverse. Inizialmente non sapevamo come rispondere. Se rattristarci per il fatto che alcune persone pensano che in Russia nessuno possa fare niente da solo e che possa solo rubare, o se rallegrarci perché pensano che qualcosa del genere possa essere rubato solo.
Ora abbiamo completato la procedura per ottenere il Certificato di firma EV Code. Per ottenerlo, è necessario superare una serie di controlli e inviare un sacco di documenti sull'azienda, parte dei quali devono essere autenticati da un avvocato. Ottenere il certificato EV Code Sign durante la pandemia è un argomento a parte per un articolo. La procedura si è protratta per un mese. E questo non è stato un mese di attesa, ma di continue richieste di documenti aggiuntivi. Forse la pandemia non c'entra nulla e a tutti la procedura è sembrata così lunga? Condividete.
Alcuni dicono che non useremo il servizio perché non abbiamo il certificato FSTEC. Dobbiamo spiegare che non possiamo ottenerlo e non lo faremo, poiché per ottenere questo certificato, la crittografia deve essere secondo lo standard GOST, mentre noi prevediamo di distribuire il software non solo in Russia e utilizziamo AES.
Tutti questi commenti sollevavano una certa incertezza riguardo alla possibilità di promuovere un prodotto che richiede l'inserimento di credenziali senza essere conosciuti. Anche considerando che sapevamo che ci sarebbero stati coloro che avrebbero reagito molto negativamente. Dopo che il numero di registrazioni ha superato le mille, abbiamo smesso di pensarci. Soprattutto dopo che, oltre alle critiche da parte di chi non aveva nemmeno provato il prodotto, sono iniziate a comparire anche recensioni molto positive. Va detto che queste recensioni positive sono il più grande motivatore per lo sviluppo del prodotto.
Aggiunta della funzionalità di accesso remoto per i dipendenti
Una delle richieste più comuni da parte dei clienti è "fai accedere Vani al suo computer da casa". Abbiamo implementato un VPN su MikroTik e creato account per gli utenti. Ma questo è davvero un problema. Gli utenti non riescono a seguire le istruzioni e ad attuarle passo dopo passo per connettersi via VPN. Ci sono diverse versioni di Windows. In un sistema va tutto bene, mentre in un altro serve un protocollo diverso. In generale, è sempre stato necessario riconfigurare le apparecchiature di rete che fungevano da server VPN, e non tutti i dipendenti hanno accesso a esse, il che risultava scomodo.
Ma noi abbiamo già connessioni remote a server e attrezzature di rete. Perché non sfruttare il trasporto già disponibile e creare un'utilità di piccole dimensioni da fornire all'utente per la connessione? Volevo solo fare in modo che l'utente non dovesse inserire alcuna informazione complicata. Basta un pulsante "connetti". Ma come farà questa utilità a sapere dove connettersi, se ha solo un pulsante? C'era l'idea di un'installazione online dell'applicazione necessaria sui nostri server. L'amministratore di sistema preme il pulsante "scarica collegamento", e a noi nel cloud viene inviata una richiesta per assemblare un binario personalizzato con le informazioni integrate per la connessione al server/computer desiderato tramite RDP. In generale, questo sarebbe stato possibile. Ma ci vorrebbe tempo; l'amministratore dovrebbe aspettare prima che il binario venga compilato e poi scaricato. Naturalmente, si potrebbe aggiungere un secondo file di configurazione, ma questo renderebbe tutto più complesso per l'utente che ha bisogno di un solo file. Un file, un pulsante e niente installer. Dando un'occhiata a Google, ho concluso che, se si aggiunge qualche informazione alla fine del file "eseguibile" compilato, questo non si danneggia (o quasi). Si può aggiungere qualsiasi cosa, perfino "Guerra e Pace", e continuerà a funzionare come prima. Sarebbe un peccato non approfittarne. Ora è possibile decomprimere l'applicazione direttamente nel client, che si chiama Veliam Connector, e semplicemente aggiungere le informazioni necessarie per la connessione alla fine. E l'app stessa sa come gestirle. Perché ho messo "quasi" tra parentesi poco sopra? Perché per questo comfort si deve pagare il prezzo che l'app perde la sua firma elettronica. Ma ora, a questo punto, riteniamo che sia un prezzo irrisorio per un simile comfort.
Licenze di moduli di terze parti
Come già accennato, dopo aver deciso di rendere il prodotto accessibile al pubblico e non solo per uso interno, è stata necessaria una considerevole ricerca per trovare sostituzioni per alcuni moduli che impedivano la loro inclusione nel nostro prodotto. Ma dopo il rilascio, abbiamo scoperto per caso una cosa piuttosto sgradevole. Nel Veliam Server utilizzato dal cliente c'era un database MariaDB con licenza GPL. La licenza GPL richiede che il software sia open source, e se nel nostro prodotto è inclusa MariaDB con questa licenza, anche il nostro prodotto deve essere sotto la stessa licenza. Per fortuna, l'obiettivo di questa licenza è l'open source, non la punizione legale per chi commette errori. Se il detentore dei diritti presenta un reclamo, deve informare il trasgressore per iscritto e quest'ultimo ha 30 giorni per rimediare alla violazione. Abbiamo scoperto il nostro errore da soli e non abbiamo ricevuto alcuna comunicazione, e ci siamo subito messi a cercare soluzioni per risolvere il problema. La soluzione si è rivelata ovvia: passare a SQLite. Questo database non ha restrizioni di licenza. La maggior parte dei browser moderni utilizza SQLite, così come molte altre applicazioni. Ho trovato informazioni online che affermano che SQLite sia considerato il database più diffuso nel mondo, proprio grazie ai browser, ma non ho cercato prove, quindi si tratta di un'informazione imprecisa. Ho iniziato a studiare quali potrebbero essere le conseguenze del passaggio a SQLite.
Diventa un compito non banale quando ci sono diverse centinaia di server con MariaDB installati presso i clienti con dati in essi. Alcune funzionalità di MariaDB non sono disponibili in SQLite. Ad esempio, nel codice erano state utilizzate query come
Select * FROM `table` WHERE `id`>1000 FOR UPDATE
Questa costruzione non solo esegue una selezione dalla tabella, ma blocca anche le righe di dati. Inoltre, ho dovuto riscrivere anche altre parti. Ma oltre alla riscrittura di molte query, è stato necessario inventare un meccanismo che, durante l'aggiornamento del Veliam Server presso il cliente, trasferisse tutti i dati nel nuovo DBMS e rimuovesse il vecchio. Inoltre, le transazioni non funzionavano in SQLite ed era un vero problema. Tuttavia, dopo aver esplorato le risorse della rete, ho trovato facilmente che le transazioni in SQLite possono essere attivate inviando un semplice comando durante la connessione
PRAGMA journal_mode=WAL;Alla fine, il compito è stato completato e ora la parte server presso i clienti funziona su SQLite. Non abbiamo notato cambiamenti nel funzionamento del sistema.
Nuovo HelpDesk
Dalla versione interna alla versione SaaS, è stata necessaria la migrazione del sistema HelpDesk, ma con alcune modifiche. La prima cosa che si desiderava realizzare è stata l'integrazione con il dominio del cliente per una registrazione trasparente degli utenti nel sistema. Ora, per accedere a HelpDesk e lasciare una richiesta, l'utente deve semplicemente cliccare sull'icona sul desktop e si apre il browser. L'utente non inserisce alcuna credenziale. Il modulo Apache SSPI, incluso in Veliam Server, autentica automaticamente l'utente con l'account di dominio. Per inviare una richiesta dal di fuori della rete aziendale, l'utente clicca su un pulsante e riceve un link via email, tramite il quale può accedere a HelpDesk senza password. Se un utente viene disabilitato o rimosso dal dominio, anche l'account in HelpDesk smetterà di funzionare. In questo modo, l'amministratore di sistema non deve monitorare manualmente gli account sia nel dominio che in HelpDesk. Se un dipendente si dimette — disabilita l'account nel dominio e non potrà accedere al sistema, né dalla rete aziendale né tramite link. Per far funzionare questa integrazione, l'amministratore di sistema deve impostare un GPO. e .
La seconda cosa che riteniamo assolutamente necessaria per i sistemi HelpDesk, almeno per noi, è la connessione al richiedente direttamente dalla richiesta con un solo clic. Inoltre, le connessioni devono funzionare anche se l'amministratore di sistema si trova in un'altra rete. Questo è essenziale per l'outsourcing, ma anche per gli amministratori di sistema interni è spesso molto utile. Esistono già diversi prodotti che gestiscono molto bene il compito delle connessioni remote. Abbiamo deciso di realizzare integrazioni per questi. Attualmente abbiamo completato l'integrazione per VNC e in futuro prevediamo di aggiungere Radmin e TeamViewer. Utilizzando il nostro trasporto di rete per connessioni remote all'infrastruttura, abbiamo facilitato la connessione di VNC a postazioni di lavoro remote dietro NAT. Lo stesso varrà per Radmin. Ora, per connettersi a un utente, basta semplicemente cliccare il pulsante "connetti al richiedente" direttamente nella richiesta. Si apre il client VNC e ci si connette al richiedente, indipendentemente dal fatto che siate nella stessa rete o che siate a casa in pantofole. In precedenza, l'amministratore di sistema deve installare VNC Server su tutte le workstation tramite le GPO.
Ora stiamo passando a un nuovo HelpDesk e utilizziamo l'integrazione con il dominio e VNC. È molto comodo per noi. Ora possiamo smettere di pagare per TeamViewer, che abbiamo usato per più di tre anni per il nostro servizio di supporto.
Cosa prevediamo di fare dopo
Quando abbiamo lanciato il prodotto, non abbiamo creato piani a pagamento, ma abbiamo semplicemente limitato il piano gratuito a 50 oggetti di monitoraggio. Pensavamo che cinque dozzine di dispositivi di rete e server sarebbero stati sufficienti per tutti. E invece sono arrivate richieste per aumentare il limite. Dire che siamo stati un po' sorpresi è poco. Davvero le aziende con un così alto numero di server si sono interessate al nostro software? Abbiamo ampliato gratuitamente il limite per coloro che hanno fatto tali richieste. A molti abbiamo chiesto il motivo di tanto interesse, se avevano davvero così tanti server e dispositivi di rete. E abbiamo scoperto che gli amministratori di sistema hanno iniziato a utilizzare il sistema in un modo che non avevamo affatto previsto. Tutto è stato semplice: hanno cominciato a monitorare non solo i server, ma anche le stazioni di lavoro. Da qui la mole di richieste per l'estensione dei limiti. Ora abbiamo già introdotto piani a pagamento e i limiti possono essere estesi autonomamente.
I server operano quasi sempre con sistemi di archiviazione SAN o con dischi locali in configurazione RAID. Abbiamo progettato il prodotto proprio per loro. Inizialmente, il monitoraggio SMART non era interessante per questa applicazione. Tuttavia, poiché le persone hanno adattato il software per monitorare le workstation, sono emerse richieste per l'implementazione del monitoraggio SMART. Presto lo realizzeremo.
Con l'arrivo di Veliam Connector, non è più necessario implementare un server VPN nella rete aziendale, né realizzare un RDGW, né inoltrare porte verso le macchine necessarie per connettersi tramite RDP. Molti utilizzano il nostro sistema esclusivamente per queste connessioni remote. Veliam Connector è disponibile solo per Windows, mentre alcuni utenti aziendali si connettono con i loro laptop personali che operano su MacOS alle workstation o terminali nella rete aziendale. Di conseguenza, l'amministratore di sistema è costretto a tornare a considerare l'inoltro delle porte o la VPN a causa di pochi utenti. Pertanto, stiamo già completando la versione di Veliam Connector per MacOS. Gli utenti della loro amata tecnologia Apple avranno anche la possibilità di connettersi all'infrastruttura aziendale con un semplice clic.
Ciò che mi piace molto è che, avendo un gran numero di utenti nel sistema, non dobbiamo preoccuparci di capire cosa desiderano e cosa sarebbe più comodo per loro. Scrivono da soli le loro richieste, quindi ci sono molti piani di sviluppo previsti per il prossimo futuro.
In parallelo, stiamo pianificando di tradurre il sistema in inglese e diffonderlo all'estero. Non sappiamo ancora come distribuire il prodotto al di fuori del nostro paese, stiamo cercando opzioni. Potrebbe esserci un articolo separato su questo in futuro. Forse qualcuno tra coloro che hanno letto questo articolo può suggerire un'idea utile, o magari sa già come farlo e offrirà i suoi servizi. Saremmo grati per l'aiuto.
Fonte: habr.com
