Прывітанне! Мы «Хостынг тэхналогіі» і 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