Olá! Nós somos a "Tecnologia de Hospedagem" e há 5 anos lançamos — a primeira hospedagem vds criada especialmente para desenvolvedores. Estamos empenhados em torná-la tão conveniente quanto a DigitalOcean, mas com suporte em russo, opções de pagamento e servidores na Rússia. Contudo, a DigitalOcean não é apenas confiabilidade e preço, mas também um excelente serviço.
O software da ISPsystem se tornou a corda que nos amarrava no caminho para um excelente serviço. Há três anos, utilizamos a fatura Billmanager e o painel de controle de servidores VMmanager e rapidamente percebemos que oferecer um bom serviço sem nosso próprio painel é praticamente impossível.
Como a ISPsystem prejudicava a conveniência
Erros
Não podíamos consertar erros por conta própria — sempre precisávamos entrar em contato com um suporte externo e esperar. A resolução de qualquer problema exigia a reação de uma empresa terceirizada.
O suporte da ISPsystem respondia de forma adequada, mas as correções chegavam apenas em algumas versões posteriores, e nem sempre eram todas. Às vezes, erros críticos eram corrigidos após várias semanas. Tínhamos que tranquilizar os clientes, pedir desculpas e esperar até que a ISPsystem resolvesse o problema.
A ameaça de interrupções
Atualizações poderiam gerar interrupções imprevisíveis, que provocavam novos erros.
Cada atualização era uma loteria: precisávamos suspender a faturação e sacrificar aos deuses das atualizações — algumas vezes uma atualização causava uma interrupção de 10 a 15 minutos. Nossos administradores ficavam tensos, pois nunca sabíamos quanto tempo duraria a interrupção e não podíamos prever quando a ISPsystem decidiria lançar uma nova atualização.
Na quinta geração do Billmanager melhorou um pouco, mas para acessar as funcionalidades necessárias, tivemos que instalar a versão beta, que já estava sendo atualizada toda semana. Se algo quebrasse, tínhamos que dar acesso a desenvolvedores externos para que eles fizessem correções.
Interface do painel inconveniente
Tudo estava dividido em diferentes painéis e gerenciado de locais distintos. Por exemplo, os clientes pagavam através do Billmanager, mas precisavam reiniciar ou reinstalar o VDS no VMManager. Nossos funcionários também tinham que alternar entre janelas para ajudar o cliente, verificar a carga em seu servidor ou ver qual sistema operacional estava utilizando.
Esse tipo de interface consome tempo — tanto nosso quanto dos clientes. Não há como falar em conveniência, como na DigitalOcean, sob tais circunstâncias.
Ciclos curtos com atualizações frequentes de API
Escrevemos nossos próprios plugins — por exemplo, um plugin com métodos de pagamento adicionais que não estão no VMManager.
Nos últimos anos, o VMManager teve um ciclo de vida relativamente curto, e em novas versões, os nomes das variáveis ou funções na API podiam mudar arbitrariamente — isso quebrou nossos plugins. O suporte para versões antigas foi rapidamente encerrado e tivemos que nos atualizar.
Não é possível aprimorar
Na verdade, é possível, mas extremamente ineficiente. As restrições de licença não permitem alterações no código-fonte, é possível apenas criar plugins. O máximo de plugins — alguns elementos de menu, assistente passo a passo. A ISPsystem é voltada para a versatilidade, enquanto nós precisávamos de soluções especializadas.
Assim surgiu a decisão de criar nosso próprio painel. Estabelecemos os seguintes objetivos:
- Responder rapidamente a erros, bugs e ter a capacidade de resolvê-los de forma independente, sem fazer o cliente esperar.
- Modificar livremente a interface para se adequar aos fluxos de trabalho e necessidades do cliente.
- Aumentar a usabilidade com um design limpo e claro.
E começamos o desenvolvimento.
Arquitetura do novo painel
Temos uma equipe de desenvolvimento autossuficiente, então desenvolvemos o painel nós mesmos.
O trabalho principal foi realizado por três engenheiros — o diretor técnico Sergey idealizou a arquitetura e escreveu o agente do servidor, Alexey fez a cobrança, enquanto o frontend foi montado pelo nosso frontendista Artysh.
Passo 1. Agente do servidor
O agente do servidor é um servidor web em Python, que gerencia a biblioteca , que, por sua vez, gerencia .
O agente controla todos os serviços no servidor: criação, parada, exclusão de VDS, instalação de sistemas operacionais, alteração de parâmetros e assim por diante através da biblioteca libvirt. No momento da publicação deste artigo, são mais de quarenta funções diferentes, que complementamos dependendo das tarefas e necessidades dos clientes.
Teoricamente, poderia-se gerenciar o libvirt diretamente da cobrança, mas isso exigia muito código adicional e decidimos separar essas funções entre o agente e a cobrança — a cobrança simplesmente faz solicitações ao agente via API JSON.
O agente foi a primeira coisa que fizemos, pois não exigia nenhuma interface e poderia ser testado diretamente no console do servidor.
O que o agente do servidor nos proporcionou: apareceu uma camada que simplifica a vida de todos — a cobrança não precisa enviar um monte de comandos, apenas fazer um pedido. E o agente fará tudo o que é necessário: por exemplo, alocará espaço no disco e memória operacional.
Passo 2. Cobrança
Para nosso desenvolvedor Alex, este não era seu primeiro painel de controle — Alex está no setor de hospedagem há muito tempo, portanto, ele já entendia o que o cliente precisa e o que o provedor precisa.
Chamamos a cobrança entre nós de "painel de controle": nele não estão apenas dinheiro e serviços, mas também a gestão deles, suporte ao cliente e muito mais.
Para a migração do software ISPSystem, era necessário manter completamente para os clientes a funcionalidade anterior, transferir todas as ações financeiras dos usuários do sistema antigo para o novo, assim como todos os serviços e as conexões entre eles. Estudamos o que havia no produto atual, depois as soluções dos concorrentes, principalmente DO e Vultr. Observamos as desvantagens e vantagens, coletamos feedback de pessoas que trabalharam com os antigos produtos da ISPsystem.
No novo sistema de cobrança usamos duas pilhas: PHP clássico, MySQL (e no futuro planejamos mudar para PostgreSQL), Yii2 como framework no backend e VueJS no frontend. As pilhas funcionam independentemente uma da outra, são desenvolvidas por pessoas diferentes, e se comunicam através de uma API JSON. Para o desenvolvimento, naquela época e agora usamos e da JetBrains e os amamos muito (pessoal, um abraço!)
O painel foi projetado modularmente: módulos de sistemas de pagamento, módulo de registradores de domínios ou, por exemplo, módulo de certificados SSL. É fácil adicionar uma nova função ou remover uma antiga. A arquitetura foi desenvolvida com espaço para expansão, inclusive retroativamente, "para o hardware".
O que obtivemos: painel de controle, sobre o qual temos total controle. Agora, bugs são corrigidos em horas, e não em semanas, e novas funções são implementadas a pedido dos clientes, e não por desejo da ISPSystem.
Passo 3. Interface
A interface é nossa criação coletiva.
Primeiro, olhamos o que aconteceria se fizéssemos uma camada sobre a API ISPsystem, sem mudar nada drasticamente na interface. O resultado foi medíocre e decidimos fazer tudo do zero.
Acreditávamos que o principal era criar uma interface lógica, com um design limpo e minimalista, e, assim, obter um painel bonito. A posição dos elementos foi discutida no Megaplan, e gradualmente nasceu a interface que os usuários veem no painel de controle atualmente.
O design da página de cobrança surgiu primeiro, já que já tínhamos desenvolvido plugins de pagamento para o ISPsystem.
Frontend
Decidimos fazer o painel como um aplicativo SPA — que não exige muitos recursos e carrega os dados rapidamente. Nosso desenvolvedor frontend, Artysh, decidiu escrevê-lo em Vue — que na época estava apenas começando. Presumimos que o framework se desenvolveria dinamicamente, como o React, e que, em algum momento, a comunidade Vue cresceria e haveria uma infinidade de bibliotecas. Apostamos no Vue e não nos arrependemos — agora adicionar novas funcionalidades no frontend, que já programamos no backend, leva pouco tempo. Falaremos mais sobre o frontend do painel em um artigo separado.
Conexão do frontend com o backend
Conectamos o frontend ao backend por meio de push notifications. Tivemos que nos esforçar e escrever nosso próprio manipulador, mas agora a atualização das informações na página ocorre quase instantaneamente.
O que conseguimos: a interface do painel se tornou mais simples. Tornamo-la responsiva, e o carregamento rápido permite utilizá-la mesmo em celulares nos últimos minutos antes da decolagem, sem precisar instalar um aplicativo separado para trabalhar com o painel.
Etapa 4. Teste e esquema de migração
Quando tudo começou a funcionar e os primeiros testes foram concluídos, surgiu a questão da migração. Primeiro, instalamos a cobrança e começamos a testar seu funcionamento com o agente do servidor.
Depois, escrevemos um script simples que transfere o banco de dados da antiga cobrança para a nova.
Tivemos que testar e verificar praticamente tudo, pois os dados foram mesclados em um novo banco vindo de três antigos: Billmanager, VMmanager e IPmanager. Sem dúvida, as migrações de teste foram a parte mais desafiadora do processo de desenvolvimento do novo painel.
Após as verificações, desativamos a antiga cobrança. A migração final dos dados foi um momento muito tenso, mas, felizmente, foi concluída em alguns minutos e sem problemas visíveis. Havia pequenos bugs que corrigimos ao longo da semana. A maior parte do tempo foi dedicada a testar o que conseguimos.
Em seguida, enviamos e-mails para os clientes com o endereço do novo painel e sistema de cobrança e fizemos o redirecionamento.
No final: ESTÁ VIVO!
Feliz final
Desde as primeiras horas de operação do nosso software, sentimos todas as vantagens da transição. O código era totalmente nosso, com uma arquitetura conveniente, e a interface — limpa e lógica.
O primeiro feedback após o lançamento do novo painel
Iniciamos o processo de migração em dezembro, véspera do Ano Novo de 2017, quando a carga era mínima, para facilitar a transição para os clientes — quase ninguém trabalha na véspera das festividades.
O principal benefício que obtivemos ao migrar para nosso próprio sistema (além da confiabilidade geral e conveniência) foi a possibilidade de adicionar rapidamente funcionalidades para clientes-chave — ser seu rosto, e não apenas uma sombra.
E agora?
Estamos crescendo, o número de dados, clientes e informações dos clientes está aumentando. Foi necessário adicionar um servidor Memcached ao backend e dois gerenciadores de fila com diferentes tarefas. No frontend, há cache e nossas próprias filas.
Claro, ainda tivemos algumas aventuras durante o desenvolvimento e a complexidade do produto, por exemplo, quando adicionamos HighLoad.
No próximo artigo, contaremos como lançamos a tarifa Hi-CPU: sobre hardware, software, quais problemas resolvemos e quais resultados obtivemos.
Fonte: habr.com
