Здравейте! Ние сме „Хостинг технологии“ и преди 5 години стартирахме — първият vds хостинг, създаден специално за разработчици. Стремим се да го направим удобен, като DigitalOcean, но с руска поддръжка, методи за плащане и сървъри в Русия. Но DigitalOcean не е само надеждност и цена, а също и сервиз.
Софтът от ISPsystem се оказа въжето, което ни връзваше ръцете по пътя към страхотен сервиз. Преди три години използвахме биллинг Billmanager и панел за управление на сървъри VMmanager и бързо осъзнахме, че е практически невъзможно да се предоставя добър сервиз без собствен панел.
Как ISPsystem убиваше удобството
Бъгове
Не можехме сами да поправим бъгове — всеки път беше необходимо да пишем до чужда поддръжка и да чакаме. Решението на всеки проблем изискваше реакция на трета страна.
Поддръжката на ISPsystem отговаряше нормално, но корекциите идваха само след няколко релиза и то не винаги и не за всички. Понякога критични бъгове се поправяха в продължение на няколко седмици. Беше необходимо да успокояваме клиентите, да се извиняваме и да чакаме, докато ISPsystem поправи бъга.
Заплаха от даунтайми
Актуализациите можеха да предизвикат непредсказуеми даунтайми, които предизвикваха нови грешки.
Всяка актуализация беше лотария: трябваше да затворим биллинга и да жертваме на боговете на актуализациите — няколко пъти актуализацията предизвикваше даунтайм за 10-15 минути. Нашите администратори в това време сякаш сивееха — никога не знаехме колко ще продължи даунтаймът и не можем да предвидим кога ISPsystem ще реши да пусне нова актуализация.
На петото поколение Billmanager стана по-добре, но за да получим достъп до необходимите функции, трябваше да инсталираме бета версия, която вече се актуализираше всяка седмица. Ако нещо се счупеше, трябваше да даваме достъп на чужди разработчици, за да поправят нещо.
Неудобен интерфейс на панела
Всичко беше разделено на различни панели и се управляваше от различни места. Например, клиентите плащаха през Billmanager, а трябваше да рестартират или преинсталират VDS в VMManager. Нашите служители също трябваше да превключват между прозорците, за да помогнат на клиента, да проверят натоварването на неговия сървър или да видят каква ОС използва.
Този интерфейс отнема време — както нашето, така и на клиентите. Не става въпрос за никакво удобство, като при DigitalOcean, в такава ситуация.
Кратки жизнени цикли с често обновление на API
Създадохме собствени плъгини — например, плъгин с допълнителни методи на плащане, които не присъстват в VMManager.
През последните години VMManager имаше сравнително кратък жизнен цикъл, като в новите версии имената на променливите или функциите в API можеха произволно да се променят — това разрушаваше нашите плъгини. Поддръжката на стари версии бързо се прекратяваше и се налагаше да се ъпдейтваме.
Не може да се доразвива
Поради спецификата на лицензионните ограничения, измененията на изходния код не са позволени, могат да се пишат само плъгини. Максимум плъгини — някакви елементи от менюто, стъпков асистент. ISPsystem е проектирана за универсалност, а ние се нуждаехме от специализирани решения.
Така се роди решението да напишем своя собствена платформа. Поставихме си цели:
- Бързо да реагираме на грешки и бъгове и да можем да ги отстраняваме сами, без да караме клиента да чака.
- Свободно да модифицираме интерфейса според работните процеси и нуждите на клиента.
- Да повишим удобството за потребителя с чист и разбираем дизайн.
И започнахме разработката.
Архитектура на новата платформа
Имаме самостоятелен екип за разработка, така че платформата я написахме сами.
Основната работа беше извършена от трима инженера — техническият директор Сергей измисли архитектурата и написа сървърния агент, Алексей направи фактурирането, а фронтендът беше сглобен от нашия фронтенд разработчик Артыш.
Стъпка 1. Сървърен агент
Сървърният агент е уеб сървър на Python, който управлява библиотеката , която пък управлява .
Агентът управлява всички услуги на сървъра: създаване, спиране, изтриване на VDS, инсталиране на операционни системи, промяна на параметри и др. чрез библиотеката libvirt. Към момента на публикуване на статията това включва повече от четиридесет различни функции, които допълваме в зависимост от задачите и нуждите на клиента.
Идеята беше, че libvirt може да се управлява директно от фактурирането, но това изискваше твърде много допълнителен код, така че решихме да разделим тези функции между агента и фактурирането — фактурирането просто прави заявки към агента чрез JSON API.
Агентът беше първият, който направихме, тъй като не изискваше интерфейс, и можеше да бъде тестван директно от конзолата на сървъра.
Какво ни даде сървърният агент: появи се слой, който улеснява живота на всички - на billing не му се налага да предава куп команди, а само да направи запитване. А агентът ще направи всичко необходимо: например, ще выдели място на диска и оперативна памет.
Стъпка 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. Вероятно тестовите миграции бяха най-сложната част от процеса на разработка на новия панел.
След прегледите закрихме старото фактуриране. Финалната миграция на данни беше много тревожен момент, но, слава Богу, се осъществи за няколко минути и без забележими проблеми. Имаше малки бъгове, които ремонтирахме през следващата седмица. Основното време отне тестването на това, което постигнахме.
След това изпратихме имейли до клиентите с адреса на новия панел и фактурирането и направихме пренасочване.
В крайна сметка: ТОЙ Е ЖИВ!
Щастливият край
От първите часове на работа с нашия софтуер усетихме всички предимства на прехода. Кодът беше изцяло наш и с удобна архитектура, а интерфейсът - чист и логичен.
Първият отзив след старта на новия панел
Започнахме процеса на преход през декември, преди Нова 2017 година, когато натоварването беше най-малко, за да улесним прехода за клиентите – почти никой не работи преди празниците.
Основното, което получихме при преминаването към нашата система (освен общата надеждност и удобство) – възможността бързо да добавяме функционалност за ключови клиенти – да бъдем с тях лице в лице, а не зад тях.
Какво следва?
Растем, нараства броят на данните, клиентите, данните на клиентите. На бекенда добавихме Memcached сървър и два мениджъра на опашки с различни задачи. На фронтенда има кеширане и собствени опашки.
Разбира се, имахме и приключения по време на разработката и усложняването на продукта, например, когато добавяхме HighLoad.
В следващата статия ще разкажем как стартирахме Hi-CPU тарифата: за хардуера, софтуера, какви задачи решавахме и какво постигнахме.
Източник: habr.com
