Вітання! Ми «Хостинг технології» і 5 років тому запустили - Перший vds хостинг, створений спеціально для розробників. Ми прагнемо зробити його зручним, як DigitalOcean, але з російською підтримкою, способами оплати та серверами у Росії. Але DigitalOcean це не лише надійність та ціна, це ще й сервіс.
Софт від ISPsystem виявився мотузкою, яка зв'язувала нам руки на шляху до крутого сервісу. Три роки тому ми використовували білінг Billmanager та панель управління серверами VMmanager і швидко зрозуміли, що надавати хороший сервіс без своєї панелі практично нереально.
Як ISPsystem вбивав зручність
баги
Ми не могли самі пофіксувати баг — щоразу доводилося писати на чужу підтримку та чекати. Вирішення будь-якої проблеми вимагало реакції сторонньої компанії.
Підтримка ISPsystem нормально відповідала, але фікси приходили лише через кілька релізів, і то не завжди і не всі. Іноді критичні баги керувалися кілька тижнів. Нам доводилося заспокоювати клієнтів, вибачатися і чекати, поки ISPsystem полагодять баг.
Загроза даунтаймів
Оновлення могли породжувати непрогнозовані даунтайми, які провокували нові помилки.
Кожен апдейт був лотереєю: доводилося прикривати білінг і приносити жертви богам оновлень - кілька разів апдейт викликав даунтайм на хвилин 10-15. Наші адміни в цей час сивіли на очах - ми ніколи не знали, скільки триватиме даунтайм і не могли спрогнозувати, коли ISPsystem вирішить випустити новий апдейт.
На п'ятому поколінні Billmanager стало краще, але щоб отримати доступ до необхідних фіч довелося ставити бету, яка вже оновлювалася щотижня. Якщо щось ламалося, доводилося давати доступ чужим розробникам, щоб вони щось поправили.
Незручний інтерфейс панелі
Все було поділено на різні панелі та керувалося з різних місць. Наприклад, клієнти платили через Billmanager, а перезавантажувати або встановлювати заново VDS їм доводилося в VMManager. Нашим співробітникам також доводилося перемикатися між вікнами, щоб допомогти клієнту, перевірити навантаження на його сервері або подивитися, яку ОС він використовує.
Такий інтерфейс забирає час і наш, і клієнтів. Ні про яку зручність, як у DigitalOcean, у такій ситуації не йдеться.
Короткі лайфцикли з найчастішим оновленням API
Ми писали власні плагіни - наприклад, плагін з додатковими способами оплати, яких немає в VMManager.
В останні роки у VMManager був відносно короткий життєвий цикл, причому в нових версіях могли довільно змінюватися назви змінних або функцій в API - це ламало наші плагіни. Підтримку старих версій швидко згортали і доводилося оновлюватись.
Не можна доопрацьовувати
Точніше можна, але дуже неефективно. Ліцензійні обмеження не дають вносити зміни до вихідних джерел, можна лише писати плагіни. Максимум плагінів – якісь елементи меню, покроковий майстер. ISPsystem заточили на універсальність, а нам потрібні були спеціалізовані рішення.
Так назріло рішення написати свою панель. Ми поставили цілі:
- Швидко реагувати на помилки, баги та мати можливість самостійно усувати їх, не змушуючи клієнта чекати.
- Вільно модифікувати інтерфейс під робочі процеси та потреби клієнта.
- Підвищити юзабіліті чистим та зрозумілим дизайном.
І розпочали розробку.
Архітектура нової панелі
Ми маємо самодостатню команду розробки, так що панель ми написали самі.
Основну роботу виконали три інженери — технічний директор Сергій вигадав архітектуру і написав серверний агент, Олексій зробив білінг, а фронтенд зібрав наш фронтендер Артиш.
Крок 1. Серверний агент
Серверний агент — це веб-сервер на пітоні, який керує бібліотекою , яка, у свою чергу, керує .
Агент керує всіма послугами на сервері: створення, зупинка, видалення vds, встановлення операційних систем, зміна параметрів тощо через бібліотеку libvirt. На момент виходу статті це більше сорока різних функцій, які ми доповнюємо залежно від завдання та потреб клієнта.
За ідеєю libvirt можна було керувати прямо з білінгу, але це вимагало надто багато додаткового коду і ми вирішили рознести ці функції між агентом та білінгом – білінг просто робить запити агенту через JSON API.
Агент - перше, що ми зробили, оскільки він не вимагав ніякого інтерфейсу і тестувати його можна було прямо з серверної консолі.
Що дав нам серверний агент: з'явився прошарок, який спрощує життя всім — білінгу не потрібно передавати цілу купу команд, а лише зробити запит. А агент зробить усе, що потрібно: наприклад, виділить місце на диску та оперативну пам'ять.
Крок 2. Білінг
Для нашого розробника Алекса це була вже не перша панель управління — Алекс у хостингу давно, тому він загалом розумів, що потрібно клієнту та що потрібно хостеру.
Біллінг ми і називаємо між собою «панеллю управління»: у ньому не лише гроші та послуги, а й управління ними, підтримка клієнтів та багато іншого.
Для переходу з софту ISPSystem необхідно було повністю зберегти клієнтам попередній функціонал, перенести всі фінансові дії користувачів зі старого білінгу в новий, а також всі послуги та зв'язки між ними. Ми вивчили, що є в поточному продукті, потім рішення конкурентів, в основному DO і Vultr. Подивилися на недоліки та переваги, зібрали відгуки людей, які працювали зі старими продуктами від ISPsystem.
У новому білінгу використовували два стеки: класичний PHP, MySQL (а в майбутньому планується перейти на PostgreSQL), Yii2 як фреймворк на бекенді та VueJS на фронті. Стеки працюють незалежно один від одного, розробляються різними людьми, спілкуються за допомогою JSON API. Для розробки тоді і зараз ми використовуємо и від JetBrains і ніжно їх любимо (хлопці, привіт!)
Панель спроектована за модульним принципом: модулі платіжних систем, модуль реєстраторів доменів або, наприклад, модуль SSL-сертифікатів. Можна легко додати нову функцію або забрати стару. Заділ на розширення закладено архітектурно, у тому числі і у зворотний бік, «до заліза».
Що ми отримали: панель управління, над якою у нас повний контроль. Тепер баги правляться за години, а не тижні, а нові функції реалізуються на прохання клієнтів, а не за бажанням ISPSystem.
Крок 3. Інтерфейс
Інтерфейс – наше командне дітище.
Спочатку ми подивилися, що буде, якщо зробити надбудову над API ISPsystem, нічого кардинально не змінюючи в інтерфейсі. Вийшло так собі і ми вирішили все зробити з нуля.
Ми вірили, що головне зробити інтерфейс логічним, з чистим і мінімалістичним дизайном і тоді отримаємо красиву панель. Розташування елементів обговорювали в Мегаплані та поступово народиться той інтерфейс, який користувачі бачать у панелі управління зараз.
Першою з'явився дизайн сторінки білінгу, адже ми вже робили плагіни оплати для ISPsystem.
Фронтенд
Панель вирішили зробити SPA додатком — невибагливою до ресурсів та швидкого завантаження даних. Наш фронтендер Артиш вирішив писати її на Vue - на той момент Vue тільки-но з'явився. Ми припустили, що фреймворк розвиватиметься динамічно, як React, через якийсь час ком'юніті Vue розростеться і з'явиться море бібліотек. Ми поставили на Vue і не пошкодували — тепер додати нові функції, які вже запрограмували на бекенді, займає мало часу. Докладніше про фронтенд панелі ми розповімо в окремій статті.
Зв'язок фронтенду з бекендом
Фронтенд пов'язали з бекендом через пуші. Довелося попітніти та написати власний обробник, але тепер оновлення інформації на сторінці відбувається майже миттєво.
Що вийшло: інтерфейс панелі став простішим. Ми зробили її адаптивною, а швидке провантаження дозволяє користуватися нею навіть з мобільних телефонів в останні хвилини перед зльотом, не встановлюючи окрему програму для роботи з панеллю.
Крок 4. Тестування та схема міграції
Коли все завелося і пройшли перші тести, постало питання міграції. Насамперед ми поставили білінг і почали тестувати його роботу з серверним агентом.
Потім написали простий скрипт, який переносить базу даних зі старого білінгу до нового.
Доводилося тестувати і перевіряти ще раз буквально все, так як дані зливали в одну нову базу з трьох старих: Billmanager, VMmanager і IPmanager менеджера. Мабуть, тестові міграції найскладніше, з чим ми зіткнулися в процесі розробки нової панелі.
Після повторних перевірки, ми прикрили старий білінг. Фінальна міграція даних була дуже тривожним моментом, але, дякувати Богу, виконалася за кілька хвилин і без помітних проблем. Були дрібні баги, які ми лагодили протягом тижня. Основний час зайняв тестування того, що вийшло.
Потім ми надіслали листи клієнтам з адресою нової панелі та білінгу і зробили редирект.
У підсумку: IT'S ALIVE!
Хепіенд
З перших годин роботи свого софту ми відчули всю красу переходу. Код був повністю наш і із зручною архітектурою, а інтерфейс – чистим та логічним.
Перший відгук після запуску нової панелі
Ми запустили процес переходу у грудні, напередодні Нового 2017 року, коли навантаження було найменше, щоб зробити перехід простіше для клієнтів — майже ніхто не працює напередодні свят.
Головне, що ми отримали при переході на свою систему (крім загальної надійності та зручності) можливість швидко додавати функціонал під ключових клієнтів бути до них обличчям, а не дупою.
Що далі?
Ми зростаємо, зростає кількість даних, клієнтів, даних клієнтів. На бекенд довелося додати Memcached-сервер та два менеджери черг з різними завданнями. На фронтенді є кешування та свої черги.
Звичайно, у нас ще були пригоди з розробкою та ускладненням продукту, наприклад, коли ми додавали HighLoad.
У наступній статті розповімо, як запускали Hi-CPU тариф: про залізо, програмне забезпечення, які завдання ми вирішували і що у нас вийшло.
Джерело: habr.com