Ciao! Siamo «Hosting Tecnologie» e cinque anni fa abbiamo lanciato — il primo hosting VDS creato appositamente per gli sviluppatori. Ci impegniamo a renderlo comodo come DigitalOcean, ma con supporto russo, metodi di pagamento e server in Russia. Ma DigitalOcean non è solo affidabilità e prezzo, è anche un servizio.
Il software di ISPsystem si è rivelato una corda che ci legava le mani nel percorso verso un servizio eccezionale. Tre anni fa utilizzavamo il billing Billmanager e il pannello di gestione dei server VMmanager e abbiamo capito rapidamente che fornire un buon servizio senza il nostro pannello era praticamente impossibile.
Come ISPsystem distruggeva la comodità
Bug
Non potevamo risolvere i bug da soli: ogni volta dovevamo scrivere al supporto di qualcun altro e attendere. La risoluzione di qualsiasi problema richiedeva la reazione di un'altra azienda.
Il supporto di ISPsystem rispondeva in modo adeguato, ma le correzioni arrivavano solo dopo diverse versioni e anche in quel caso non sempre per tutti. A volte, bug critici rimanevano irrisolti per settimane. Dovevamo tranquillizzare i clienti, scusarci e aspettare che ISPsystem risolvesse il problema.
Minacce di downtime
Gli aggiornamenti potevano causare downtime imprevedibili, che provocavano nuovi errori.
Ogni aggiornamento era una lotteria: dovevamo sospendere il billing e fare sacrifici agli dèi degli aggiornamenti — alcune volte l'aggiornamento causava un downtime di circa 10-15 minuti. I nostri amministratori in quel momento erano in ansia — non sapevamo mai quanto sarebbe durato il downtime e non potevamo prevedere quando ISPsystem decidesse di rilasciare un nuovo aggiornamento.
Con la quinta generazione di Billmanager le cose sono migliorate, ma per accedere alle funzionalità necessarie abbiamo dovuto installare la beta, che veniva già aggiornata ogni settimana. Se qualcosa si rompeva, dovevamo dare accesso a sviluppatori esterni affinché correggessero il problema.
Interfaccia del pannello poco intuitiva
Tutto era suddiviso in pannelli diversi e gestito da luoghi differenti. Ad esempio, i clienti pagavano tramite Billmanager, mentre per riavviare o reinstallare il VDS dovevano utilizzare VMManager. Anche i nostri dipendenti dovevano passare da una finestra all'altra per assistere i clienti, controllare il carico del loro server o vedere quale sistema operativo utilizzavano.
Un'interfaccia del genere fa perdere tempo — sia a noi che ai clienti. In una situazione simile, non si può parlare di comodità come da DigitalOcean.
Cicli di vita brevi con aggiornamenti frequenti dell'API
Abbiamo scritto plugin personalizzati, ad esempio, un plugin con metodi di pagamento aggiuntivi che non sono 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, rompendo così i nostri plugin. Il supporto per le versioni precedenti veniva rapidamente abbandonato e bisognava aggiornarsi.
Non si può modificare
In effetti, si può, ma è estremamente inefficace. Le limitazioni di licenza non consentono di apportare modifiche al codice sorgente, si possono solo scrivere plugin. Il massimo dei plugin sono alcuni elementi di menu e un wizard step-by-step. ISPsystem è orientato all'universalità, mentre noi avevamo bisogno di soluzioni specializzate.
Così è maturata la decisione di creare il nostro pannello. Abbiamo fissato gli obiettivi:
- Reagire rapidamente agli errori e ai 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 necessità del cliente.
- Migliorare l'usabilità con un design chiaro e comprensibile.
E abbiamo iniziato lo sviluppo.
L'architettura del nuovo pannello
Abbiamo un team di sviluppo autonomo, quindi abbiamo scritto il pannello noi stessi.
Il lavoro principale è stato svolto da tre ingegneri: il direttore tecnico Sergey ha concepito l'architettura e scritto l'agente server, Alexey ha gestito la fatturazione, mentre il frontend è stato assemblato dal nostro frontend developer Artysh.
Passo 1. Agente server
L'agente 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 di sistemi operativi, modifica delle impostazioni e così via attraverso la libreria libvirt. Al momento della pubblicazione dell'articolo, ci sono più di quaranta diverse funzioni che integriamo a seconda delle necessità del cliente.
In teoria, si poteva gestire libvirt direttamente dalla fatturazione, ma questo richiedeva troppi codici aggiuntivi e abbiamo deciso di separare queste funzioni tra l'agente e la fatturazione: quest'ultima effettua semplicemente richieste all'agente tramite l'API JSON.
L'agente è la prima cosa che abbiamo realizzato, poiché non richiedeva alcun'interfaccia e si poteva testare direttamente dalla console del server.
Cosa ci ha dato l'agente server: È stata introdotta una interfaccia che semplifica la vita a tutti: il billing non deve più inviare un intero insieme di comandi, ma può semplicemente effettuare una richiesta. L'agente farà tutto il necessario: ad esempio, alloca spazio su disco e RAM.
Passo 2. Billing
Per il nostro sviluppatore Alex non era la prima dashboard: Alex lavora nel hosting da molto tempo, quindi aveva già un'idea chiara di ciò che serve ai clienti e a chi offre il servizio.
Noi chiamiamo il billing «dashboard»: contiene non solo denaro e servizi, ma anche la gestione degli stessi, il supporto ai clienti e molto altro.
Per migrare dal software ISPSystem, era necessario mantenere completamente per i clienti le precedenti funzionalità, trasferire tutte le operazioni finanziarie degli utenti dal vecchio billing al nuovo, così come tutti i servizi e le connessioni tra di essi. Abbiamo esaminato cosa c'era nel prodotto attuale, poi le soluzioni dei concorrenti, principalmente DO e Vultr. Abbiamo analizzato difetti e punti di forza, raccogliendo feedback da persone che avevano lavorato con i vecchi prodotti di ISPsystem.
Nel nuovo billing sono stati utilizzati due stack: PHP classico, MySQL (e in futuro è prevista la transizione a PostgreSQL), Yii2 come framework sul backend e VueJS sul frontend. Gli stack operano indipendentemente l'uno dall'altro, sviluppati da persone diverse, e comunicano tramite JSON API. Per lo sviluppo, allora e ora utilizziamo e di JetBrains e li amiamo teneramente (ragazzi, ciao!)
La dashboard è progettata secondo un principio modulare: moduli per sistemi di pagamento, moduli per registratori di domini o, ad esempio, moduli per certificati SSL. È facile aggiungere una nuova funzionalità o rimuoverne una vecchia. L'architettura è predisposta per l'espansione, anche in reverse, «verso l'hardware».
Cosa abbiamo ottenuto: una dashboard su cui abbiamo il pieno controllo. Ora i bug vengono risolti in ore e non in settimane, e le nuove funzioni vengono implementate su richiesta dei clienti e non per volontà di ISPSystem.
Passo 3. Interfaccia
L'interfaccia è una nostra creazione collettiva.
All'inizio abbiamo esaminato cosa sarebbe successo se avessimo creato un'overlayer sull'API di ISPsystem, senza cambiare nulla di radicale nell'interfaccia. Il risultato è stato mediocre e abbiamo deciso di fare tutto da zero.
Credevamo che la cosa principale fosse rendere l'interfaccia logica, con un design pulito e minimalista, e così avremmo ottenuto un bel pannello. Abbiamo discusso la disposizione degli elementi in Megaplan e gradualmente è nato l'interfaccia che gli utenti vedono ora nel pannello di controllo.
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 applicazione SPA — poco esigente in termini di risorse e con un rapido caricamento dei dati. Il nostro frontend developer, Artysh, ha deciso di scriverlo in Vue — in quel momento Vue era appena apparso. Abbiamo ipotizzato che il framework si sarebbe evoluto dinamicamente, proprio come React; dopo un po', la comunità di Vue sarebbe cresciuta e sarebbero emerse molte librerie. Abbiamo scommesso su Vue e non ci siamo pentiti: ora aggiungere nuove funzionalità frontend, già programmate nel backend, richiede poco tempo. Parleremo di più del frontend del pannello in un articolo separato.
Collegamento tra frontend e backend
Abbiamo collegato il frontend al backend tramite push. Abbiamo dovuto impegnarci e scrivere un nostro gestore, ma ora gli aggiornamenti delle informazioni sulla pagina avvengono quasi istantaneamente.
Cosa è stato ottenuto: l'interfaccia del pannello è diventata più semplice. L'abbiamo resa reattiva e il rapido caricamento consente di utilizzarla anche da dispositivi mobili negli ultimi minuti prima del decollo, senza dover installare un'applicazione separata per lavorare con il pannello.
Passo 4. Test e schema di migrazione
Quando tutto è stato avviato e sono stati eseguiti i primi test, è emersa la questione della migrazione. Prima di tutto, 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 a quello nuovo.
È stato necessario testare e ricontrollare praticamente tutto, poiché i dati venivano uniti in un nuovo database da tre vecchi: Billmanager, VMmanager e IPmanager. Probabilmente, le migrazioni di test sono state la parte più complicata con cui ci siamo confrontati durante lo sviluppo del nuovo pannello.
Dopo i ricontrolli, abbiamo disattivato il vecchio sistema di fatturazione. La migrazione finale dei dati è stata un momento molto ansioso, ma, grazie a Dio, si è svolta 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 era stato ottenuto.
Successivamente, abbiamo inviato lettere ai clienti con l'indirizzo del nuovo pannello e della fatturazione e abbiamo attivato il reindirizzamento.
Alla fine: È VIVO!
Felice fine
Fin dalle prime ore di utilizzo del nostro software, abbiamo percepito tutti i vantaggi del passaggio. Il codice era completamente nostro e con un'architettura conveniente, mentre l'interfaccia era pulita e logica.
Prima recensione dopo il lancio del nuovo pannello
Abbiamo avviato il processo di transizione a dicembre, alla vigilia del nuovo anno 2017, quando i carichi erano minimi, per semplificare il passaggio ai clienti—quasi nessuno lavora prima delle festività.
La cosa principale che abbiamo ottenuto passando al nostro sistema (oltre alla maggiore affidabilità e comodità) è stata la possibilità di aggiungere rapidamente funzionalità per i clienti chiave—essere il loro punto di riferimento, non un'appendice.
Cosa succede dopo?
Stiamo crescendo, cresce la quantità di dati, clienti e dati sui clienti. È stato necessario aggiungere un server Memcached al backend e due gestori di code con compiti diversi. Sul frontend ci sono cache e code proprie.
Ovviamente abbiamo avuto anche avventure durante lo sviluppo e il complessizzarsi del prodotto, per esempio quando abbiamo aggiunto HighLoad.
Nel prossimo articolo parleremo di come abbiamo lanciato la tariffa Hi-CPU: hardware, software, quali problemi abbiamo affrontato e quali risultati abbiamo ottenuto.
Fonte: habr.com
