Ciao! Siamo "Hosting Technologies" e lanciati 5 anni fa — il primo hosting vds creato appositamente per gli sviluppatori. Ci sforziamo di renderlo conveniente, 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 ha legato le mani sulla strada per un servizio interessante. Tre anni fa, abbiamo utilizzato la fatturazione di Billmanager e il pannello di controllo del server VMmanager e ci siamo subito resi conto che era quasi impossibile fornire un buon servizio senza il nostro pannello di controllo.
Come ISPsystem ha ucciso la comodità
bugs
Non siamo riusciti a correggere il bug da soli: ogni volta dovevamo scrivere al supporto di qualcun altro e aspettare. La soluzione a qualsiasi problema richiedeva la risposta di un'azienda terza.
Il supporto del sistema ISP ha risposto normalmente, ma le correzioni sono arrivate solo dopo alcune versioni, quindi non sempre e non tutte. A volte i bug critici venivano corretti per diverse settimane. Abbiamo dovuto rassicurare i clienti, scusarci e attendere che ISPsystem risolvesse il bug.
Minaccia di inattività
Gli aggiornamenti potrebbero generare tempi di inattività imprevedibili che hanno provocato nuovi errori.
Ogni aggiornamento era una lotteria: dovevo coprire la fatturazione e fare sacrifici agli dei degli aggiornamenti: un paio di volte l'aggiornamento ha causato tempi di inattività per 10-15 minuti. I nostri amministratori in questo momento erano seduti con gli occhi aperti: non sapevamo mai quanto sarebbe durato il tempo di inattività e non potevamo prevedere quando ISPsystem avrebbe deciso di rilasciare un nuovo aggiornamento.
Alla quinta generazione, Billmanager è migliorato, ma per accedere alle funzionalità necessarie ho dovuto installare una versione beta, che veniva già aggiornata ogni settimana. Se qualcosa si rompeva, dovevo dare accesso ad altri sviluppatori in modo che potessero aggiustare qualcosa.
Interfaccia del pannello scomoda
Tutto era diviso in diversi pannelli e controllato da luoghi diversi. Ad esempio, i clienti hanno pagato tramite Billmanager e hanno dovuto riavviare o reinstallare VDS in VMManager. Il nostro staff doveva anche passare da una finestra all'altra per aiutare un cliente, controllare il carico sul suo server o vedere quale sistema operativo stava utilizzando.
Tale interfaccia richiede tempo, sia nostro che dei nostri clienti. Non si tratta di alcuna convenienza, come quella di DigitalOcean, in una situazione del genere.
Cicli di vita brevi con aggiornamenti API frequenti
Abbiamo scritto i nostri plug-in, ad esempio un plug-in con metodi di pagamento aggiuntivi che non sono in VMManager.
Negli ultimi anni, VMManager ha avuto un ciclo di vita relativamente breve e nelle nuove versioni i nomi delle variabili o delle funzioni nell'API potrebbero cambiare arbitrariamente: questo ha rotto i nostri plug-in. Il supporto per le versioni precedenti è stato rapidamente eliminato e doveva essere aggiornato.
Non può essere modificato
Più precisamente, è possibile, ma estremamente inefficiente. Le restrizioni di licenza non ti consentono di apportare modifiche al codice sorgente, puoi solo scrivere plugin. Numero massimo di plug-in: alcune voci di menu, una procedura guidata passo-passo. I sistemi ISP sono progettati per la versatilità, ma avevamo bisogno di soluzioni specializzate.
Quindi la decisione era matura per scrivere il mio pannello. Abbiamo fissato degli obiettivi:
- Rispondi rapidamente a errori, bug e correggili tu stesso senza far aspettare il cliente.
- Modifica liberamente l'interfaccia per i flussi di lavoro e le esigenze del cliente.
- Aumenta l'usabilità con un design pulito e comprensibile.
E abbiamo iniziato lo sviluppo.
Nuova architettura del pannello
Abbiamo un team di sviluppo autosufficiente, quindi abbiamo scritto noi stessi il panel.
Il lavoro principale è stato svolto da tre ingegneri: il direttore tecnico Sergey ha ideato l'architettura e ha scritto l'agente del server, Alexey ha fatto la fatturazione e il front-end è stato assemblato dal nostro front-ender Artysh.
Passaggio 1: agente del server
L'agente server è un server Web Python che gestisce la libreria , che a sua volta governa .
L'agente gestisce tutti i servizi sul server: creazione, arresto, eliminazione di vds, installazione di sistemi operativi, modifica dei parametri e così via tramite la libreria libvirt. Al momento della pubblicazione dell'articolo, si tratta di più di quaranta diverse funzioni, che integriamo a seconda dell'attività e delle esigenze del cliente.
In teoria, libvirt potrebbe essere controllato direttamente dalla fatturazione, ma ciò richiedeva troppo codice aggiuntivo e abbiamo deciso di separare queste funzioni tra l'agente e la fatturazione: la fatturazione effettua semplicemente richieste all'agente tramite l'API JSON.
L'agente è la prima cosa che abbiamo fatto, poiché non richiedeva alcuna interfaccia ed era possibile testarlo direttamente dalla console del server.
Cosa ci ha dato l'agente del server: è apparso uno strato che semplifica la vita a tutti: la fatturazione non ha bisogno di inviare un sacco di comandi, ma solo di fare una richiesta. E l'agente farà tutto ciò che è necessario: ad esempio, allocherà spazio su disco e RAM.
Passaggio 2. Fatturazione
Per il nostro sviluppatore Alex, questo non era il primo pannello di controllo: Alex è stato nell'hosting per molto tempo, quindi generalmente capiva di cosa aveva bisogno il cliente e di cosa aveva bisogno l'hoster.
Chiamiamo la fatturazione tra di noi un "pannello di controllo": contiene non solo denaro e servizi, ma anche la loro gestione, assistenza clienti e molto altro.
Per passare dal software ISPSystem, è stato necessario preservare integralmente le funzionalità precedenti per i clienti, trasferire tutte le azioni finanziarie degli utenti dalla vecchia fatturazione a quella nuova, nonché tutti i servizi e le connessioni tra di loro. Abbiamo studiato cosa c'è nel prodotto attuale, quindi le soluzioni dei concorrenti, principalmente DO e Vultr. Abbiamo esaminato gli svantaggi e i vantaggi, raccolto feedback da persone che hanno lavorato con vecchi prodotti di ISPsystem.
La nuova fatturazione utilizzava due stack: PHP classico, MySQL (e in futuro si prevede di passare a PostgreSQL), Yii2 come framework sul backend e VueJS sul fronte. Gli stack funzionano indipendentemente l'uno dall'altro, sono sviluppati da persone diverse e comunicano tramite l'API JSON. Per lo sviluppo allora e ora usiamo и da JetBrains e li amo teneramente (hey ragazzi!)
Il pannello è progettato su base modulare: moduli del sistema di pagamento, modulo del registrar di domini o, ad esempio, un modulo del certificato SSL. Puoi facilmente aggiungere una nuova funzione o rimuoverne una vecchia. Le basi per l'espansione sono poste architettonicamente, anche nella direzione opposta, "verso l'hardware".
Quello che abbiamo: un pannello di controllo su cui abbiamo il pieno controllo. Ora i bug vengono corretti in ore, non settimane, e le nuove funzionalità vengono implementate su richiesta dei clienti e non su richiesta di ISPSystem.
Passaggio 3 Interfaccia
L'interfaccia è il frutto dell'ingegno del nostro team.
Innanzitutto, abbiamo esaminato cosa accadrebbe se creassimo un componente aggiuntivo sull'API del sistema ISP senza modificare sostanzialmente nulla nell'interfaccia. Si è rivelato così così 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 poi otterremo un bellissimo pannello. La posizione degli elementi è stata discussa in Megaplan e gradualmente nascerà l'interfaccia che gli utenti vedono ora nel pannello di controllo.
Il design della pagina di fatturazione è stato il primo ad apparire, perché abbiamo già realizzato plug-in di pagamento per ISPsystem.
Fine frontale
Hanno deciso di trasformare il pannello in un'applicazione SPA, poco impegnativa per le risorse e con un rapido caricamento dei dati. Il nostro front-ender Artysh ha deciso di scriverlo su Vue - a quel tempo Vue era appena apparso. Abbiamo ipotizzato che il framework si sarebbe sviluppato in modo dinamico, come React, dopo un po 'la community di Vue sarebbe cresciuta e sarebbe apparso un mare di librerie. Abbiamo scommesso su Vue e non ce ne siamo pentiti: ora ci vuole poco tempo per aggiungere nuove funzioni al fronte che sono già state programmate sul backend. Ti diremo di più sul pannello front-end in un articolo separato.
Collegamento del frontend al backend
Il frontend è stato connesso al backend tramite notifiche push. Ho dovuto lavorare sodo e scrivere il mio gestore, ma ora le informazioni sulla pagina vengono aggiornate quasi istantaneamente.
Cosa è successo: L'interfaccia del pannello è diventata più semplice. L'abbiamo reso adattivo, e il caricamento veloce ti permette di usarlo anche da cellulare negli ultimi minuti prima del decollo, senza installare un'applicazione separata per lavorare con il pannello.
Passaggio 4. Schema di test e migrazione
Quando tutto si è avviato e sono stati superati i primi test, è sorta la questione della migrazione. Prima di tutto, abbiamo installato la fatturazione e iniziato a testarne il funzionamento con l'agente del server.
Poi abbiamo scritto un semplice script che trasferisce il database dalla vecchia fatturazione a quella nuova.
Ho dovuto testare e ricontrollare letteralmente tutto, poiché i dati sono stati uniti in un nuovo database da tre vecchi: Billmanager, VMmanager e IPmanager del gestore. Forse le migrazioni di prova sono la cosa più difficile che abbiamo incontrato nel processo di sviluppo di un nuovo pannello.
Dopo aver ricontrollato, abbiamo chiuso la vecchia fatturazione. La migrazione finale dei dati è stata un momento molto preoccupante, ma, grazie a Dio, è stata completata in pochi minuti e senza problemi evidenti. Ci sono stati bug minori che abbiamo corretto durante la settimana. La maggior parte del tempo è stata spesa per testare cosa è successo.
Quindi abbiamo inviato lettere ai clienti con l'indirizzo del nuovo pannello e la fatturazione e abbiamo effettuato un reindirizzamento.
In sintesi: È VIVA!
Lieto fine
Fin dalle prime ore di lavoro del nostro software, abbiamo sentito tutti i piaceri della transizione. Il codice era completamente nostro e con un'architettura conveniente, e 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 il carico era minimo, per facilitare la transizione ai clienti: quasi nessuno lavora alla vigilia delle vacanze.
La cosa principale che abbiamo ottenuto passando al nostro sistema (a parte l'affidabilità e la praticità generali) è la possibilità di aggiungere rapidamente funzionalità per i clienti chiave: essere la loro faccia, non il loro culo.
Quali sono le prospettive?
Stiamo crescendo, la quantità di dati, clienti, dati dei clienti sta crescendo. Ho dovuto aggiungere al backend un server Memcached e due gestori code con compiti diversi. Il frontend ha la memorizzazione nella cache e le proprie code.
Naturalmente, abbiamo avuto ancora avventure man mano che il prodotto si sviluppava e diventava più complesso, ad esempio quando abbiamo aggiunto HighLoad.
Nel prossimo articolo vi racconteremo come è stata lanciata la tariffa Hi-CPU: su hardware, software, quali compiti abbiamo risolto e cosa abbiamo fatto.
Fonte: habr.com