Ciao! Noi di «Hosting Technologies» abbiamo lanciato — il primo hosting VDS progettato specificamente per sviluppatori. Puntiamo a renderlo facile da usare come DigitalOcean, ma con supporto in russo, metodi di pagamento locali e server in Russia. Ma DigitalOcean non è solo affidabilità e prezzo, è anche servizio.
Il software di ISPsystem si è rivelato una corda che ci legava le mani nel nostro cammino verso un servizio eccezionale. Tre anni fa utilizzavamo il sistema di fatturazione Billmanager e il pannello di controllo server VMmanager e abbiamo rapidamente capito che offrire un buon servizio senza un pannello proprietario è praticamente impossibile.
Come ISPsystem ha distrutto la comodità
Bug
Non potevamo risolvere i bug da soli: ogni volta dovevamo scrivere al supporto esterno e aspettare. Risolvere qualsiasi problema richiedeva la reazione di un'azienda terza.
Il supporto di ISPsystem rispondeva normalmente, ma le correzioni arrivavano solo dopo diversi rilasci, e nemmeno sempre e non tutte. A volte i bug critici venivano corretti dopo settimane. Dovevamo tranquillizzare i clienti, scusarci e aspettare che ISPsystem risolvesse il bug.
Il rischio di downtime
Gli aggiornamenti potevano generare downtime imprevedibili, che provocavano nuovi errori.
Ogni aggiornamento era come una lotteria: dovevamo fermare la fatturazione e sacrificare qualcosa agli dei degli aggiornamenti — un paio di volte l'aggiornamento ha causato un downtime di 10-15 minuti. I nostri amministratori in quel momento erano in attesa — non abbiamo mai saputo quanto sarebbe durata l'interruzione e non potevamo prevedere quando ISPsystem avrebbe deciso di rilasciare un nuovo aggiornamento.
Con la quinta generazione di Billmanager la situazione è migliorata, ma per accedere alle funzionalità necessarie è stato necessario installare la beta, che veniva aggiornata ogni settimana. Se qualcosa si rompeva, dovevamo dare accesso a sviluppatori esterni affinché sistemassero il problema.
Interfaccia del pannello poco intuitiva
Tutto era diviso in pannelli diversi e gestito da luoghi differenti. Ad esempio, i clienti pagavano attraverso Billmanager, mentre per riavviare o reinstallare il VDS dovevano utilizzare VMManager. Anche i nostri dipendenti dovevano passare da una finestra all'altra per aiutare il cliente, controllare il carico sul suo server o vedere quale OS stesse utilizzando.
Un'interfaccia del genere fa perdere tempo — sia a noi che ai clienti. Non si può certo parlare di comodità, come con DigitalOcean, in una situazione del genere.
Cicli di vita brevi con aggiornamenti frequenti dell'API
Abbiamo sviluppato plugin personalizzati — ad esempio, un plugin con metodi di pagamento aggiuntivi che non erano presenti in VMManager.
Negli ultimi anni, VMManager ha avuto un ciclo di vita relativamente breve, con nomi di variabili o funzioni nell'API che cambiavano arbitrariamente nelle nuove versioni — questo rompeva i nostri plugin. Il supporto per le versioni precedenti veniva rapidamente interrotto e dovevamo aggiornare.
Non si può estendere il codice
In realtà si può, ma è estremamente inefficiente. Le limitazioni di licenza impediscono di apportare modifiche al codice sorgente, è possibile solo scrivere plugin. Il massimo dei plugin consistono in alcuni elementi di menu e installatori guidati. ISPsystem è progettato per la versatilità, mentre noi avevamo bisogno di soluzioni specializzate.
Così è nata l'idea di scrivere il nostro pannello. Abbiamo fissato degli obiettivi:
- Reagire rapidamente a errori e bug e avere la possibilità di risolverli autonomamente, senza far aspettare il cliente.
- Modificare liberamente l'interfaccia in base ai flussi di lavoro e alle esigenze del cliente.
- Migliorare l'usabilità con un design chiaro e intuitivo.
E abbiamo avviato lo sviluppo.
Architettura del nuovo pannello
Abbiamo un team di sviluppo autonomo, quindi il pannello l'abbiamo scritto noi stessi.
Il lavoro principale è stato svolto da tre ingegneri: il direttore tecnico Sergey ha progettato l'architettura e scritto l'agente del server, Alexey ha realizzato la fatturazione, mentre il nostro frontend developer Artysh ha assemblato il frontend.
Passo 1. Agente del server
L'agente del server è un server web in Python che gestisce la libreria , che a sua volta gestisce .
L'agente gestisce tutti i servizi sul server: creazione, arresto, eliminazione di VDS, installazione dei sistemi operativi, modifica dei parametri e così via tramite la libreria libvirt. Al momento della pubblicazione di questo articolo, ci sono più di quaranta diverse funzioni, che integriamo a seconda delle esigenze e delle richieste del cliente.
In teoria, si poteva gestire libvirt direttamente dalla fatturazione, ma ciò richiedeva troppo codice aggiuntivo e abbiamo deciso di separare queste funzioni tra l'agente e la fatturazione: la fatturazione semplicemente invia richieste all'agente tramite JSON API.
L'agente è stata la prima cosa che abbiamo fatto, poiché non richiedeva alcuna interfaccia e poteva essere testato direttamente dalla console del server.
Cosa ci ha dato l'agente del server: è stata creata un'interfaccia che semplifica la vita a tutti: il billing non deve più inviare una marea di comandi, basta effettuare una richiesta. E l'agente farà tutto il necessario: ad esempio, assegnerà spazio su disco e memoria RAM.
Passo 2. Billing
Per il nostro sviluppatore Alex, non era la prima interfaccia di controllo: Alex è nel settore dell'hosting da tempo, quindi aveva una buona comprensione di ciò di cui avevano bisogno i clienti e cosa richiedeva l'hosting.
Noi chiamiamo il billing tra di noi "interfaccia di controllo": contiene non solo denaro e servizi, ma anche la gestione di questi, supporto clienti e molto altro.
Per la transizione dal software ISPSystem, era fondamentale mantenere completamente il funzionamento precedente per i clienti, trasferire tutte le operazioni finanziarie degli utenti dal vecchio billing a quello nuovo, così come tutti i servizi e le loro interconnessioni. Abbiamo analizzato cosa c'era nel prodotto attuale, poi le soluzioni dei concorrenti, principalmente DO e Vultr. Abbiamo esaminato i punti deboli e i punti di forza, raccogliendo feedback da persone che hanno lavorato con i vecchi prodotti di ISPsystem.
Nel nuovo sistema di fatturazione abbiamo utilizzato due stack: PHP classico, MySQL (in futuro prevediamo di passare a PostgreSQL), Yii2 come framework sul backend e VueJS sul frontend. Gli stack operano indipendentemente l'uno dall'altro, sviluppati da team diversi, e comunicano tra di loro tramite API JSON. Per lo sviluppo, sia allora che ora utilizziamo e di JetBrains e li amiamo teneramente (ciao ragazzi!)
Il pannello è progettato secondo un principio modulare: moduli per sistemi di pagamento, modulo per registrar dei domini o, ad esempio, un modulo per certificati SSL. È facile aggiungere una nuova funzionalità o rimuoverne una vecchia. L’architettura è stata concepita con un occhio all’espansione, incluso a retrocompatibilità, «fino all’hardware».
Cosa abbiamo ottenuto: un pannello di controllo, sul quale abbiamo il pieno controllo. Ora i bug vengono risolti in poche ore invece che settimane, e nuove funzionalità vengono implementate su richiesta dei clienti, non per desiderio di ISPSystem.
Passo 3. Interfaccia
L'interfaccia è il nostro orgoglio di squadra.
Inizialmente abbiamo esaminato cosa sarebbe successo se avessimo creato un sovrastruttura sopra l'API di ISPsystem, senza modificare radicalmente l'interfaccia. Il risultato non è stato soddisfacente, quindi abbiamo deciso di fare tutto da zero.
Credevamo che il punto principale fosse rendere l'interfaccia logica, con un design pulito e minimalista, così da ottenere un bellissimo pannello. Abbiamo discusso la disposizione degli elementi in Megaplan, e piano piano è emersa l'interfaccia che gli utenti vedono attualmente nella dashboard.
Per prima cosa, è stato creato il design della pagina di fatturazione, dato che avevamo già realizzato plugin di pagamento per ISPsystem.
Frontend
Abbiamo deciso di realizzare il pannello come un'applicazione SPA — leggera in termini di risorse e con un caricamento dati rapido. Il nostro frontend developer, Artysh, ha scelto di scriverla in Vue — in quel momento Vue era appena apparso. Abbiamo ipotizzato che il framework si sarebbe evoluto dinamicamente, come React, e che nel tempo la community di Vue si sarebbe ingrandita, portando a una miriade di librerie. Abbiamo puntato su Vue e non ci siamo pentiti — ora, aggiungere nuove funzionalità sul frontend già programmate sul backend richiede poco tempo. Approfondiremo il frontend del pannello in un articolo dedicato.
Collegamento del frontend con il backend
Abbiamo collegato il frontend al backend tramite push. È stato necessario impegnarsi e scrivere un gestore personalizzato, ma ora l'aggiornamento delle informazioni sulla pagina avviene quasi istantaneamente.
Ecco il risultato: L'interfaccia del pannello è diventata più semplice. L'abbiamo resa reattiva e il caricamento rapido consente di utilizzarla anche da dispositivi mobili negli ultimi minuti prima del decollo, senza installare un'applicazione separata per lavorare con il pannello.
Passo 4. Test e schema di migrazione
Quando tutto è stato avviato e abbiamo superato i primi test, è emersa la questione della migrazione. Per prima cosa, abbiamo installato il sistema di fatturazione e abbiamo iniziato a testarne il funzionamento con l'agente server.
Poi abbiamo scritto un semplice script che trasferisce il database dal vecchio sistema di fatturazione al nuovo.
Abbiamo dovuto testare e verificare letteralmente tutto, poiché i dati venivano fusi in un nuovo database da tre vecchi: Billmanager, VMmanager e IPmanager. Probabilmente, le migrazioni di test sono state la parte più difficile che abbiamo affrontato durante lo sviluppo del nuovo pannello.
Dopo ulteriori verifiche, abbiamo chiuso il vecchio sistema di fatturazione. La migrazione finale dei dati è stata un momento molto ansiogeno, ma, grazie a Dio, è stata completata in pochi minuti e senza problemi evidenti. Ci sono stati piccoli bug che abbiamo risolto nel corso di una settimana. La maggior parte del tempo è stata dedicata al test di ciò che abbiamo ottenuto.
Successivamente abbiamo inviato e-mail ai clienti con l'indirizzo del nuovo pannello e della fatturazione e abbiamo impostato il reindirizzamento.
In sintesi: È VIVO!
Epilogo felice
Fin dai primi momenti di utilizzo del nostro software, abbiamo sentito tutti i vantaggi del passaggio. Il codice era completamente nostro, con un'architettura intuitiva, e l'interfaccia era pulita e logica.
La prima recensione dopo il lancio del nuovo pannello
Abbiamo avviato il processo di transizione a dicembre, alla vigilia del nuovo anno 2017, quando c'erano meno carichi, per facilitare il passaggio ai clienti — quasi nessuno lavora prima delle festività.
La cosa principale che abbiamo guadagnato passando al nostro sistema (oltre a maggiore affidabilità e comodità) è stata la possibilità di aggiungere rapidamente funzionalità su misura per i clienti chiave — essere il loro volto, non la loro ombra.
E ora?
Stiamo crescendo, aumentando il numero di dati, clienti e dati dei clienti. Abbiamo dovuto aggiungere un server Memcached al backend e due gestori di coda con compiti diversi. Nel frontend ci sono caching e code proprie.
Ovviamente, abbiamo anche avuto avventure durante lo sviluppo e la complessità del prodotto, ad esempio quando abbiamo aggiunto HighLoad.
Nell'articolo seguente parleremo di come abbiamo lanciato il piano Hi-CPU: l'hardware, il software, quali sfide abbiamo affrontato e quali risultati abbiamo ottenuto.
Fonte: habr.com
