Da terceirização ao desenvolvimento (Parte 2)

В artigo anterior, falei sobre os antecedentes da criação do Veliam e a decisão de distribuí-lo através do sistema SaaS. Neste artigo falarei sobre o que tive que fazer para que o produto não fosse local, mas público. Sobre como a distribuição começou e quais problemas encontraram.

planejamento

O back-end atual para usuários estava no Linux. Quase todas as organizações possuem servidores Windows, o que não pode ser dito sobre o Linux. O principal ponto forte do Veliam são as conexões remotas com servidores e equipamentos de rede por trás do NAT. Mas essa funcionalidade estava fortemente ligada ao fato de o roteador ter que ser Mikrotik. E isso obviamente não satisfaria muitos. Comecei a pensar em adicionar suporte para roteadores dos fornecedores mais comuns. Mas entendi que se tratava de uma corrida sem fim para ampliar a lista de empresas apoiadas. Além disso, aqueles que já são suportados podem ter um conjunto diferente de comandos para alterar as regras NAT de modelo para modelo. A única saída da situação parecia ser uma VPN.

Como decidimos distribuir o produto, mas não como código aberto, tornou-se impossível incluir diversas bibliotecas com licenças abertas como a GPL. Geralmente esse é um tópico à parte; depois de tomar a decisão de vender o produto, tive que passar por metade das bibliotecas devido ao fato de serem GPL. Quando eles escreviam para si mesmos, era normal. Mas não é adequado para distribuição. A primeira VPN que vem à mente é o OpenVPN. Mas é GPL. Outra opção era usar a VPN japonesa SoftEther. Sua licença permitiu que ele incluísse isso em seu produto. Depois de alguns dias de vários testes sobre como integrá-lo de forma que o usuário não precise configurar nada e conhecer o SoftEther VPN, foi obtido um protótipo. Tudo foi como deveria ser. Mas, por alguma razão, esse esquema ainda nos confundia e acabamos por abandoná-lo. Mas naturalmente eles recusaram depois de encontrarem outra opção. No final, tudo foi feito em conexões TCP regulares. Algumas conexões funcionam através de um coordenador, outras diretamente através da tecnologia Nat Hole Punching (NHP), que também foi implementada em Free Pascal. Devo dizer que nunca tinha ouvido falar de NHP antes. E nunca me ocorreu que fosse possível conectar 2 dispositivos de rede, ambos diretamente atrás do NAT. Estudei o assunto, entendi o princípio de funcionamento e sentei para escrever. O plano é implementado, o usuário se conecta com um clique ao dispositivo desejado via NAT via RDP, SSH ou Winbox sem inserir senhas ou configurar uma VPN. Além disso, a maioria dessas conexões passa pelo nosso coordenador, o que tem um bom efeito no ping e no custo de manutenção dessas conexões.

Transferindo o lado do servidor do Linux para o Windows

Houve vários problemas ao mudar para o Windows. A primeira é que o wmic integrado no Windows não permite fazer consultas WQL. E em nosso sistema tudo já foi construído sobre eles. E havia outra coisa, mas agora esqueci por que finalmente abandonaram seu uso. Possivelmente diferenças entre as versões do Windows. E o segundo problema é o multithreading. Não encontrando um bom utilitário de terceiros com uma licença “aceitável” para nós, lancei o IDE Lazarus novamente. E eu escrevi o utilitário necessário. A entrada é a lista necessária de objetos e quais consultas específicas precisam ser feitas e, em resposta, recebo os dados. E tudo isso no modo multithread. Ótimo.

Depois de configurar o pthreads para PHP Windows, pensei que tudo começaria imediatamente, mas não foi o caso. Depois de algum tempo de depuração, percebi que os pthreads pareciam funcionar, mas não funcionavam em nosso sistema. Ficou claro que existe alguma peculiaridade em trabalhar com pthreads no Windows. E assim foi. Eu li a documentação e estava escrito lá que para o Windows o número de threads é limitado e, pelo que me lembro, implicitamente. Isso se tornou um problema. Porque quando comecei a reduzir o número de threads em que o aplicativo era executado, ele fez o trabalho muito lentamente. Abri o IDE novamente e a funcionalidade para ping multithread de objetos foi adicionada ao mesmo utilitário. Bem, já há muita varredura de portas lá também. Na verdade, depois disso, a necessidade de pthreads para PHP desapareceu e ele não é mais usado. Além disso, várias outras funcionalidades foram adicionadas a este utilitário e ele ainda funciona até hoje. Em seguida, foi montado um instalador para Windows, que incluía Apache, PHP, MariaDB, a própria aplicação PHP e um conjunto de utilitários para interação com o sistema, escritos em Free Pascal. Quanto ao instalador, pensei em resolver esse problema rapidamente, pois... Isso é algo muito comum e necessário para quase todos os softwares. Ou eu estava procurando no lugar errado ou outra coisa. Mas constantemente me deparei com produtos que não eram flexíveis o suficiente ou eram caros e também inflexíveis. E ainda assim, encontrei um instalador gratuito no qual será possível atender a qualquer desejo. Este é o InnoSetup. Estou escrevendo sobre isso aqui porque tive que pesquisar caso economize tempo de alguém.

Recusa do plugin em favor do seu cliente

Escrevi anteriormente que a parte do cliente era um navegador com um “plugin”. Então houve momentos em que o Chrome foi atualizado e o layout ficou um pouco torto, depois o Windows foi atualizado e o esquema de uri personalizado desapareceu. Eu realmente não queria ter esse tipo de surpresa na versão pública do produto. Além disso, o uri personalizado começou a desaparecer após cada atualização do Windows. A Microsoft simplesmente excluiu todas as filiais que não eram suas na seção obrigatória. Além disso, o Google Chrome agora não permite que você se lembre da opção de abrir ou não um aplicativo a partir do uri personalizado e faz essa pergunta toda vez que você clica em um objeto de monitoramento. Bem, em geral, era necessária uma interação normal com o sistema local do usuário, o que o navegador não fornece. A opção mais simples neste esquema parece ser simplesmente criar seu próprio navegador, como muitos estão fazendo agora através do Electron. Mas muitas coisas já haviam sido escritas em Free Pascal, inclusive na parte do servidor, então decidimos fazer o cliente na mesma linguagem, e não criar um zoológico. Foi assim que um cliente com Chromium integrado foi escrito. A partir daí, passou a adquirir diversas cintas.

Liberação

Finalmente escolhemos um nome para o sistema. Constantemente passamos por várias opções enquanto o processo de conversão da versão local para SaaS estava em andamento. Como inicialmente planejávamos entrar não apenas no mercado nacional, o principal critério para a seleção de um nome foi a presença de um domínio desocupado ou pouco caro na zona “.com”. Algumas funções/módulos ainda não foram portados da versão local para o Veliam, mas decidimos que iríamos liberá-los com a funcionalidade atual e completar o restante como atualizações. Na primeira versão não existia HelpDesk, Veliam Connector, era impossível alterar os limites dos gatilhos de notificação e muito mais. Compramos um Certificado de Sinal de Código e assinamos as partes do cliente e do servidor. Escrevemos um site para o produto, iniciamos procedimentos de registro de software, marca, etc. Em geral, estamos prontos para começar. Uma ligeira euforia pelo trabalho realizado e pelo facto de talvez alguém utilizar o seu produto, embora não tivéssemos dúvidas disso. E então pare. O sócio disse que é impossível entrar no mercado sem notificações via mensageiros. É possível sem muitas outras coisas, mas não sem isto. Depois de algum debate, foi adicionada integração com o Telegram, o que nos agradou. De todos os mensageiros instantâneos atuais, este é o único que oferece acesso às suas APIs gratuitamente e sem procedimentos complexos de aprovação. O mesmo WhatsApp sugere entrar em contato com provedores que cobram um bom dinheiro pela utilização de seus serviços; todas as cartas solicitando acesso sem gaxetas foram ignoradas; Bem, Viber... não sei quem usa agora, porque... spam e publicidade lá são fora de série. No final de dezembro, após uma série de testes internos e entre amigos, as inscrições foram abertas para todos e o software foi disponibilizado para download.

Início da distribuição

Desde o início entendemos que precisávamos de um pequeno fluxo de usuários do sistema para que pudessem testar o produto em modo de combate e dar um primeiro feedback. Vários posts comprados no VK deram frutos. As primeiras inscrições chegaram.

Aqui é preciso dizer que entrar no mercado quando sua empresa não tem um nome famoso e ao mesmo tempo fornecer funcionalidade de monitoramento sem agente na qual você precisa inserir contas de seus servidores e estações de trabalho é muito difícil. Isso assusta muita gente. Compreendemos desde o início que haveria problemas com isso e estávamos preparados para isso tanto técnica quanto moralmente. Todas as conexões remotas, apesar de RDP e SSH já estarem criptografados por padrão, são criptografadas adicionalmente pelo nosso software usando o padrão AES. Todos os dados dos servidores locais são transferidos para a nuvem via HTTPS. As contas são armazenadas de forma criptografada. As chaves de criptografia para todos os subsistemas são individuais para todos os clientes. Para conexões remotas, geralmente são usadas chaves de criptografia de sessão.

Tudo o que podemos fazer nesta situação para que as pessoas se sintam mais calmas é sermos o mais abertos possível, trabalharmos na segurança e nunca nos cansarmos de responder às perguntas das pessoas.

Para muitos, a conveniência e a funcionalidade do software superam o medo e eles se registram. Algumas pessoas escreveram em postagens publicadas no VK que este software não pode ser usado porque Esta é uma coleção de suas senhas e geralmente uma empresa sem nome. É preciso dizer que mais de uma pessoa teve essa opinião. Muitas pessoas simplesmente não entendem que quando instalam outro software proprietário em um servidor que funciona como um serviço, ele também tem direitos totais no sistema e não precisam de contas para fazer algo ilegal (é claro que você pode alterar o usuário de quem o serviço foi lançado, mas aqui também você pode inserir qualquer conta). Na verdade, os medos das pessoas são compreensíveis. Instalar software em um servidor é algo comum, mas entrar em uma conta é um pouco assustador e íntimo, já que boa metade das pessoas tem a mesma senha para todos os serviços, e criar uma conta separada até para teste é preguiçoso. Mas no momento há um grande número de serviços nos quais as pessoas confiam suas credenciais e muito mais. E nos esforçamos para nos tornar um deles.

Houve muitos comentários dizendo que roubamos em algum lugar. Isso nos surpreendeu um pouco. Bem, tudo bem, a opinião de uma pessoa, mas tais comentários foram encontrados em várias publicações de pessoas diferentes. No início eles não sabiam como reagir a isso. Ou ficar triste porque algumas pessoas têm a opinião de que na Rússia ninguém pode fazer nada sozinho, mas apenas roubar, ou ficar feliz por pensarem que isso só pode ser roubado.

Concluímos agora o procedimento para obter um Certificado de Sinal de Código EV. Para obtê-lo, é necessário passar por uma série de verificações e enviar uma série de documentos sobre a empresa, alguns dos quais devem ser autenticados por um advogado. A obtenção de um certificado EV Code Sign durante uma pandemia é um tópico separado para um artigo. O procedimento durou um mês. E não foi um mês de espera, mas de pedidos constantes de documentos adicionais. Será que a pandemia não teve nada a ver com isso e o procedimento demorou tanto para todos? Compartilhar.

Alguns dizem que não vamos usar porque não existe certificado FSTEC. Temos que explicar que não podemos obtê-lo e não o faremos porque, para obter este certificado, a criptografia deve estar de acordo com GOST, e planejamos distribuir o software não apenas na Rússia e usar AES.

Todos esses comentários levantam dúvidas de que é possível promover um produto que exige o acesso a contas sem ser conhecido publicamente. Mesmo sabendo que haveria quem tivesse uma atitude muito negativa em relação a isso. Depois que o número de inscrições ultrapassou mil, paramos de pensar nisso. Principalmente depois que, além da negatividade de quem ainda nem havia experimentado o produto, começaram a aparecer críticas muito agradáveis. É preciso dizer que essas críticas positivas são o maior motivador para o desenvolvimento de produtos.

Adicionando funcionalidade de acesso remoto para funcionários

Uma das tarefas frequentes dos clientes é “dar acesso a Vanya ao seu computador em casa”. Levantamos VPN no Mikrotik e criamos contas para usuários. Mas este é um problema real. Os usuários não conseguem seguir as instruções e segui-las passo a passo para se conectar via VPN. Diferentes versões do Windows. Em um Windows tudo se conecta bem, em outro é necessário um protocolo diferente. E em geral isso sempre esteve associado à reconfiguração dos equipamentos de rede, que funcionavam como servidor VPN, e nem todos os funcionários têm acesso a ele e isso era inconveniente.

Mas já temos conexões remotas com servidores e equipamentos de rede. Por que não usar um transporte pronto e fazer um pequeno utilitário separado que você pode simplesmente dar ao usuário para conectar. Eu só queria ter certeza de que o usuário não inseriu nada obscuro ali. Apenas um botão “conectar”. Mas como esse utilitário entenderá onde conectar se tiver apenas um botão? Houve uma ideia de construir o aplicativo necessário online em nossos servidores. O administrador do sistema clica no botão “atalho de download” e um comando é enviado à nossa nuvem para construir um binário individual com informações conectadas para conexão ao servidor/computador desejado via RDP. Em geral, isso poderia ser feito. Mas isso leva muito tempo; o administrador teria que esperar primeiro até que o binário fosse compilado e depois baixado. Claro, seria possível simplesmente adicionar um segundo arquivo com a configuração, mas já são 2 arquivos, e para simplificar o usuário precisa de um. Um arquivo, um botão e nenhum instalador. Depois de ler um pouco no Google, cheguei à conclusão que se você adicionar alguma informação ao final do “.exe” compilado, ele não se deteriora (bem, quase). Você pode pelo menos adicionar guerra e paz lá, e tudo funcionará como antes. Seria um pecado não tirar vantagem disso. Agora você pode simplesmente descompactar o aplicativo em qualquer lugar, direto no próprio cliente, aliás se chama Veliam Connector, e simplesmente adicionar as informações necessárias para conectar-se a ele no final. E o próprio aplicativo sabe o que fazer com isso. Por que escrevi “bem, quase” entre parênteses um pouco mais alto? Porque você tem que pagar por essa comodidade, pois o aplicativo perde a assinatura digital. Mas nesta fase acreditamos que este é um pequeno preço a pagar por tal comodidade.

Licenças de módulos de terceiros

Já escrevi acima que depois que foi decidido disponibilizar o produto ao público, e não apenas para uso próprio, tivemos que trabalhar muito e procurar substitutos para alguns módulos que não nos permitiam ser incluídos em nosso produto. Mas após o lançamento, algo muito desagradável foi descoberto acidentalmente. O Veliam Server, que estava no lado do cliente, incluía o MariaDB DBMS. E é licenciado pela GPL. A licença GPL implica que o software deve ser de código aberto, e se nosso produto incluir MariaDB, que possui esta licença, então nosso produto deverá estar sob esta licença. Mas, felizmente, o objetivo desta licença é de código aberto, não punindo quem acidentalmente comete erros na Justiça. Se o detentor dos direitos autorais tiver uma reclamação, ele notificará o infrator por escrito e deverá eliminar a violação no prazo de 30 dias. Nós mesmos descobrimos nosso erro e não recebemos nenhuma carta e imediatamente começamos a considerar opções para resolver o problema. A solução acabou sendo óbvia - mude para SQLite. Este banco de dados não tem restrições de licenciamento. A maioria dos navegadores modernos usa SQLite e vários outros programas. Encontrei informações na Internet de que o SQLite é considerado o SGBD mais difundido no mundo, justamente por causa dos navegadores, mas não procurei provas, então esta é uma informação imprecisa. Comecei a estudar os perigos de mudar para o SQLite.

Isso se torna uma tarefa nada trivial quando os clientes têm centenas de servidores instalados com MariaDB e dados nele. Alguns recursos do MariaDB não estão disponíveis no SQLite. Bem, por exemplo, no código usamos consultas como

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

Essa construção não apenas faz uma seleção na tabela, mas também bloqueia os dados da linha. E vários outros designs também tiveram que ser reescritos. Mas além de termos que reescrever muitas consultas, também tivemos que criar um mecanismo que, ao atualizar o Veliam Server do cliente, portasse todos os dados para o novo SGBD e excluísse o antigo. Além disso, as transações no SQLite não funcionavam e isso era um problema real. Mas depois de ler a vastidão da World Wide Web, descobri sem problemas que as transações no SQLite podem ser habilitadas passando um simples comando ao conectar

PRAGMA journal_mode=WAL;

Como resultado, a tarefa foi concluída e agora a parte do servidor do cliente roda em SQLite. Não notamos nenhuma alteração no funcionamento do sistema.

Novo suporte técnico

Foi necessária a portabilidade do sistema HelpDesk da versão interna para a versão SaaS, mas com algumas alterações. A primeira coisa que quis fazer foi a integração com o domínio do cliente em termos de autorização transparente do usuário no sistema. Agora, para fazer login no HelpDesk e deixar uma solicitação no sistema, basta o usuário clicar no atalho da área de trabalho e o navegador será aberto. O usuário não insere nenhuma credencial. O módulo Apache SSPI, que faz parte do Veliam Server, autoriza automaticamente o usuário em uma conta de domínio. Para deixar uma solicitação no sistema quando o usuário está fora da rede corporativa, ele clica em um botão e recebe em seu e-mail um link através do qual faz login no sistema HelpDesk sem senhas. Se um usuário for desativado ou excluído de um domínio, a conta do HelpDesk também deixará de funcionar. Assim, o administrador do sistema não precisa monitorar contas tanto no domínio quanto no próprio HelpDesk. Um funcionário sai - ele desconecta sua conta no domínio e pronto, ele não entra no sistema nem pela rede corporativa, nem por link. Para que esta integração funcione, o administrador do sistema precisa criar um GPO, que adiciona um site interno à zona da intranet и distribui um atalho para todos os usuários na área de trabalho.

A segunda coisa que consideramos extremamente necessária para os sistemas HelpDesk, pelo menos para nós, é conectar-se ao solicitante diretamente do aplicativo com um clique. Além disso, as conexões deverão passar se o administrador do sistema estiver em uma rede diferente. Para a terceirização isso é obrigatório, mas para administradores de sistema em tempo integral também é muitas vezes muito necessário. Já existem vários produtos que fazem um excelente trabalho de conexões remotas. E decidimos fazer integrações para eles. Agora integramos o VNC e, no futuro, planejamos adicionar o Radmin e o TeamViewer. Usando nosso transporte de rede para conexões de infraestrutura remota, fizemos com que o VNC se conectasse a estações de trabalho remotas por meio de NAT. O mesmo acontecerá com o Radmin. Agora, para se conectar a um usuário, basta clicar no botão “conectar ao candidato” no próprio aplicativo. O cliente VNC abre e se conecta ao solicitante, independentemente de você estar na mesma rede ou sentado em casa de chinelos. Primeiro, o administrador do sistema, usando GPO, deve instalar o VNC Server nas estações de trabalho de todos.

Agora nós mesmos estamos mudando para o novo HelpDesk e usando integração com domínio e VNC. Isto é muito conveniente para nós. Agora podemos evitar pagar pelo TeamViewer, que usamos há mais de três anos para executar nosso serviço de suporte.

O que estamos planejando fazer a seguir?

Quando lançamos o produto, não pagamos nenhuma tarifa, simplesmente limitamos a tarifa gratuita a 50 objetos de monitoramento. Cinco dúzias de dispositivos de rede e servidores deveriam ser suficientes para todos, pensamos. E então começaram a chegar pedidos para aumentar o limite. Dizer que ficamos um pouco chocados é não dizer nada. As empresas que possuem tantos servidores estão realmente interessadas em nosso software? Estendemos o limite gratuitamente para quem fez essas solicitações. Em resposta ao seu pedido, perguntamos a alguns por que eles precisavam tanto, se eles realmente tinham um número tão grande de servidores e equipamentos de rede. E aconteceu que os administradores do sistema começaram a usar o sistema de maneiras que não havíamos planejado. Tudo acabou sendo simples - nosso software passou a monitorar não só servidores, mas também estações de trabalho. Portanto, há muitos pedidos para expandir os limites. Agora já introduzimos tarifas pagas e os limites podem ser ampliados de forma independente.

Os servidores quase sempre funcionam com sistemas de armazenamento ou discos locais em uma matriz RAID. E inicialmente fizemos o produto para eles. E o monitoramento SMART não foi interessante para esta tarefa. Mas tendo em conta que as pessoas adaptaram software para monitorizar estações de trabalho, surgiram pedidos para a implementação de monitorização SMART. Iremos implementá-lo em breve.

Com o advento do Veliam Connector, tornou-se desnecessário implantar um servidor VPN na rede corporativa, ou fazer RDGW, ou simplesmente encaminhar portas para as máquinas necessárias para conexão via RDP. Muitas pessoas usam nosso sistema apenas para essas conexões remotas. O Veliam Connector está disponível apenas para Windows, e alguns usuários corporativos se conectam de laptops domésticos executando MacOS a estações de trabalho ou terminais na rede corporativa. E acontece que o administrador do sistema é obrigado, por conta de vários usuários, a ainda voltar à questão do encaminhamento ou VPN. Portanto, estamos terminando de fazer uma versão do Veliam Connector para MacOS. Os usuários de sua tecnologia favorita da Apple também terão a oportunidade de se conectar à infraestrutura corporativa com um clique.

Gosto muito do fato de que, tendo um grande número de usuários do sistema, você não precisa ficar pensando no que as pessoas precisam e no que será mais conveniente. Eles próprios escrevem os seus desejos, por isso há muitos planos de desenvolvimento para o futuro próximo.

Paralelamente, planeamos agora começar a traduzir o sistema para inglês e distribuí-lo no estrangeiro. Ainda não sabemos como vamos distribuir o produto fora do nosso país, estamos em busca de opções. Talvez haja um artigo separado sobre isso mais tarde. Talvez alguém que tenha lido este artigo possa sugerir o vetor necessário, ou ele mesmo saiba e saiba fazê-lo e oferecerá seus serviços. Agradecemos sua ajuda.

Fonte: habr.com

Adicionar um comentário