Ahoj! Jsme „Hosting technologie“ a před 5 lety jsme spustili — první VDS hosting, vytvořený speciálně pro vývojáře. Snažíme se, aby byl stejně pohodlný jako DigitalOcean, ale s ruskou podporou, platebními metodami a servery v Rusku. Ale DigitalOcean to není jen spolehlivost a cena, je to také služba.
Software od ISPsystem se ukázal jako provaz, který nám svazoval ruce na cestě k skvělé službě. Před třemi lety jsme používali billing Billmanager a serverový panel VMmanager a rychle jsme pochopili, že poskytovat dobrou službu bez našeho vlastního panelu je téměř nemožné.
Jak ISPsystem zabíjel pohodlí
Bugs
Nemohli jsme si sami opravit bug — pokaždé jsme museli psát do cizí podpory a čekat. Řešení jakéhokoli problému vyžadovalo reakci třetí strany.
Podpora ISPsystem normálně odpovídala, ale opravy přicházely jen přes několik verzí, a to ne vždy a ne všechny. Někdy kritické chyby byly opraveny týdny. Museli jsme uklidňovat klienty, omlouvat se a čekat, až ISPsystem opraví bug.
Hrozba výpadků
Aktualizace mohly způsobit nepředvídatelné výpadky, které vyvolávaly nové chyby.
Každá aktualizace byla loterie: museli jsme zavřít billing a přinést oběti bohům aktualizací — párkrát aktualizace způsobila výpadek na 10-15 minut. Naši administrátoři v té době seděli s úzkostí — nikdy jsme nevěděli, jak dlouho výpadek potrvá a nemohli jsme předvídat, kdy ISPsystem vydá novou aktualizaci.
U páté generace Billmanager se to zlepšilo, ale abychom získali přístup k potřebným funkcím, museli jsme nainstalovat beta verzi, která se již aktualizovala každý týden. Pokud se něco rozbilo, bylo nutné poskytnout přístup cizím vývojářům, aby to opravili.
Nepohodlné rozhraní panelu
Všechno bylo rozděleno na různé panely a spravováno z různých míst. Například klienti platili přes Billmanager, ale restartovat nebo přeinstalovat VDS museli v VMManageru. Naši zaměstnanci také museli přepínat mezi okny, aby pomohli klientovi, zkontrolovali zátěž na jeho serveru nebo zjistili, jaký OS používá.
Takové rozhraní bere čas — a náš i klientů. O žádném pohodlí jako u DigitalOcean v takové situaci nemůže být řeč.
Krátké životní cykly s častými aktualizacemi API
Vytvořili jsme vlastní pluginy – například plugin s dalšími způsoby plateb, které ve VMManageru nejsou.
V posledních letech měl VMManager relativně krátký životní cyklus a názvy proměnných nebo funkcí v API se v nových verzích mohly náhodně měnit – to narušovalo naše pluginy. Podpora starých verzí byla rychle ukončena a bylo nutné se aktualizovat.
Není možné provádět úpravy
Přesněji řečeno, možné to je, ale velmi neefektivně. Licenční omezení nedovolují provádět změny v zdrojovém kódu, lze pouze psát pluginy. Maximální počet pluginů – nějaké prvky menu, průvodce. ISPsystem je zaměřen na univerzálnost, a my jsme potřebovali specializovaná řešení.
Tak vzniklo rozhodnutí napsat vlastní panel. Stanovili jsme si cíle:
- Rychle reagovat na chyby, bugy a mít možnost je sami odstraňovat, aniž bychom nutili klienta čekat.
- Volně modifikovat rozhraní podle pracovních procesů a potřeb klienta.
- Zvýšit použitelnost čistým a srozumitelným designem.
A zahájili jsme vývoj.
Architektura nového panelu
Máme samostatný vývojový tým, takže panel jsme napsali sami.
Hlavní práci odvedli tři inženýři – technický ředitel Sergej navrhl architekturu a napsal serverového agenta, Alexej vytvořil billing a frontend sestavil náš frontend developer Artyš.
Krok 1. Serverový agent
Serverový agent je webový server na pythonu, který spravuje knihovnu , která zase spravuje .
Agent spravuje všechny služby na serveru: vytváření, zastavení, mazání VDS, instalace operačních systémů, změna parametrů a tak dále prostřednictvím knihovny libvirt. V době vydání tohoto článku to je více než čtyřicet různých funkcí, které doplňujeme v závislosti na úkolu a potřebách klienta.
Teoreticky by šlo libvirt spravovat přímo z billingu, ale to by vyžadovalo příliš mnoho dodatečného kódu, a rozhodli jsme se rozdělit tyto funkce mezi agentem a billingem – billing prostě posílá žádosti agentovi prostřednictvím JSON API.
Agent byl první věcí, kterou jsme vytvořili, protože nevyžadoval žádné rozhraní a bylo možné ho testovat přímo z konzole serveru.
Co nám serverový agent přinesl: Objevila se vrstva, která usnadňuje život všem – billing už nemusí předávat hromadu příkazů, stačí provést jeden požadavek. A agent udělá vše potřebné: například vyčlení místo na disku a operační paměť.
Krok 2. Billing
Pro našeho vývojáře Alexe to už nebyla první řídicí panel – Alex je v hostingu dlouho, takže měl obecně přehled o potřebách klientů a poskytovatelů hostingu.
Billing nazýváme mezi sebou „řídicím panelem“: zahrnuje nejen finance a služby, ale také jejich správu, podporu klientů a mnohé další.
Abychom přešli z softwaru ISPSystem, bylo nutné plně zachovat předchozí funkce pro klienty, přenést všechny finanční transakce uživatelů ze starého billingu do nového a také všechny služby a jejich vazby. Studovali jsme, co je v aktuálním produktu, pak řešení konkurentů, převážně DO a Vultr. Podívali jsme se na nedostatky a výhody, sesbírali jsme názory lidí, kteří pracovali se starými produkty od ISPsystem.
V novém billingu jsme použili dva stacky: klasický PHP, MySQL (a v budoucnu plánujeme přejít na PostgreSQL), Yii2 jako framework na backendu a VueJS na frontendu. Stacky pracují nezávisle na sobě, vyvíjejí je různí lidé, a komunikují pomocí JSON API. Pro vývoj tehdy i nyní používáme a od JetBrains a máme je rádi (kluci, zdravíme vás!)
Panel je navržen modulárně: moduly platebních systémů, modul registrátorů domén nebo například modul SSL certifikátů. Snadno je možné přidat novou funkci nebo odstranit starou. Architektonicky je integrovaný prostor pro rozšíření, včetně směrem k „hardware“.
Co jsme získali: řídicí panel, nad kterým máme plnou kontrolu. Nyní se chyby opravují za hodiny, nikoli týdny, a nové funkce se realizují na žádost klientů, nikoli na přání ISPSystem.
Krok 3. Rozhraní
Rozhraní je naše týmová práce.
Nejprve jsme se podívali, co bude, když uděláme nadstavbu nad API ISPsystem, aniž bychom radikálně měnili rozhraní. Výsledek nebyl nijak výrazný a rozhodli jsme se udělat vše od začátku.
Věřili jsme, že hlavní je udělat rozhraní logické, s čistým a minimalistickým designem, a pak získáme krásný panel. Rozložení prvků jsme diskutovali v Megaplanu a postupně se zrodilo to rozhraní, které uživatelé vidí v ovládacím panelu nyní.
Prvním vznikl design stránky fakturace, protože jsme už dělali pluginy pro platby pro ISPsystem.
Frontend
Panel jsme se rozhodli udělat jako SPA aplikaci — nenáročnou na zdroje a s rychlým načítáním dat. Náš frontendista Artysh se rozhodl psát ji na Vue — tehdy Vue právě přišel na trh. Předpokládali jsme, že framework se bude rychle rozvíjet, jako React, a že se komunita Vue rozroste a objeví se spousta knihoven. Vsadili jsme na Vue a nelitovali jsme — nyní je přidání nových funkcí na frontend, které už byly naprogramovány na backendu, otázkou chvíle. O frontendu panelu se dozvíte více v samostatném článku.
Propojení frontendu s backendem
Frontend jsme propojili s backendem přes push notifikace. Museli jsme se potrápit a napsat vlastní zpracovatel, ale nyní se aktualizace informací na stránce děje téměř okamžitě.
Co se podařilo: rozhraní panelu se stalo jednodušším. Učinili jsme ho responzivním a rychlé načítání umožňuje jeho používání i z mobilních zařízení na poslední chvíli před vzletem, aniž bychom museli instalovat samostatnou aplikaci pro práci s panelem.
Krok 4. Testování a migrační schéma
Když se všechno rozhýbalo a proběhly první testy, vyvstal problém migrace. Nejdřív jsme nainstalovali billing a začali testovat jeho spolupráci se serverovým agentem.
Poté jsme napsali jednoduchý skript, který přenáší databázi ze starého billing systému do nového.
Bylo nutné testovat a znovu kontrolovat doslova vše, protože data byla slita do jedné nové databáze ze tří starých: Billmanager, VMmanager a IPmanager. Snad nejkomplexnější částí, s níž jsme se setkali během vývoje nového panelu, byly testovací migrace.
Po všech kontrolách jsme uzavřeli starý billing. Finální migrace dat byla velmi nervy drásající okamžik, ale naštěstí se provedla během několika minut a bez výraznějších problémů. Objevily se drobné chyby, které jsme opravovali po dobu jednoho týdne. Nejvíce času strávilo testování toho, co se podařilo.
Poté jsme klientům poslali e-maily s adresou nového panelu a fakturace a provedli jsme přesměrování.
Nakonec: JE TO NA SVĚTĚ!
Šťastný konec
Už od prvních hodin provozu našeho softwaru jsme pocítili všechny výhody přechodu. Kód byl zcela náš a s pohodlnou architekturou, a rozhraní bylo čisté a logické.
První recenze po spuštění nového panelu
Spuštění přechodu jsme naplánovali na prosinec, těsně před Novým rokem 2017, kdy byla zátěž nejmenší, abychom klientům usnadnili přechod — téměř nikdo nepracuje těsně před svátky.
Hlavní výhodou, kterou jsme získali při přechodu na náš systém (kromě celkové spolehlivosti a pohodlí), byla možnost rychle přidávat funkce pro klíčové klienty — být pro ně tváří, nikoli zády.
Co dál?
Rosteme, roste množství dat, klientů, dat klientů. Na backend jsme museli přidat Memcached server a dva správce front s různými úkoly. Na frontendě máme kešování a vlastní fronty.
Samozřejmě, že jsme při vývoji a zkomplikování produktu zažili ještě pár dobrodružství, například když jsme přidávali HighLoad.
V dalším článku vám povíme, jak jsme spustili tarif Hi-CPU: o hardwaru, softwaru, jaké úkoly jsme řešili a co se nám podařilo.
Zdroj: habr.com
