Ahoj! Jsme "hostingové technologie" a zahájili jsme před 5 lety — první vds hosting vytvořený speciálně pro vývojáře. Snažíme se, aby to bylo pohodlné, jako DigitalOcean, ale s ruskou podporou, platebními metodami a servery v Rusku. DigitalOcean však není jen spolehlivost a cena, je to také služba.
Software od ISPsystem se ukázal jako lano, které nám svazovalo ruce na cestě ke skvělé službě. Před třemi lety jsme používali Billmanager billing a ovládací panel serveru VMmanager a rychle jsme si uvědomili, že je téměř nemožné poskytovat dobré služby bez našeho vlastního ovládacího panelu.
Jak ISPsystem zabil pohodlí
Chyby
Sami jsme nedokázali chybu opravit – pokaždé jsme museli napsat na podporu někoho jiného a čekat. Řešení jakéhokoli problému vyžadovalo reakci třetí strany.
Podpora systému ISP reagovala normálně, ale opravy přišly až po několika vydáních, a pak ne vždy a ne všechny. Někdy byly kritické chyby opravovány několik týdnů. Museli jsme zákazníky uklidnit, omluvit se a počkat, až ISPsystem chybu opraví.
Hrozba výpadku
Aktualizace by mohly způsobit nepředvídatelné prostoje, které vyvolaly nové chyby.
Každá aktualizace byla loterie: musel jsem zakrýt účtování a obětovat bohům aktualizací - aktualizace několikrát způsobila výpadky na 10-15 minut. Naši administrátoři v tuto chvíli seděli na očích – nikdy jsme nevěděli, jak dlouho bude výpadek trvat, a nemohli jsme předvídat, kdy se ISP systém rozhodne vydat novou aktualizaci.
Na páté generaci se Billmanager zlepšil, ale abych získal přístup k potřebným funkcím, musel jsem nainstalovat beta verzi, která už byla aktualizována každý týden. Pokud se něco pokazilo, musel jsem dát přístup dalším vývojářům, aby mohli něco opravit.
Nepohodlné rozhraní panelu
Vše bylo rozděleno do různých panelů a řízeno z různých míst. Klienti například platili přes Billmanager a museli restartovat nebo přeinstalovat VDS ve VMManager. Naši zaměstnanci také museli přepínat mezi okny, aby pomohli klientovi, zkontrolovali zatížení jeho serveru nebo viděli, jaký OS používá.
Takové rozhraní vyžaduje čas – jak nám, tak našim klientům. V takové situaci nemůže být řeč o žádném pohodlí, jaké má DigitalOcean.
Krátké životní cykly s častými aktualizacemi API
Napsali jsme vlastní pluginy – například plugin s dalšími platebními metodami, které nejsou ve VMManageru.
VMManager měl v posledních letech relativně krátký životní cyklus a v nových verzích se názvy proměnných nebo funkcí v API mohly libovolně měnit – to nám rozbilo pluginy. Podpora starších verzí byla rychle ukončena a musela být aktualizována.
Nelze upravit
Přesněji je to možné, ale krajně neefektivní. Licenční omezení vám neumožňují provádět změny ve zdrojovém kódu, můžete psát pouze pluginy. Maximum pluginů – některé položky nabídky, průvodce krok za krokem. ISPsystem jsou navrženy pro všestrannost, ale potřebovali jsme specializovaná řešení.
Bylo tedy zralé rozhodnutí napsat svůj vlastní panel. Stanovili jsme si cíle:
- Rychle reagujte na chyby, chyby a buďte schopni je sami opravit, aniž byste museli klienta čekat.
- Volně upravujte rozhraní pro pracovní postupy a potřeby klientů.
- Zvyšte použitelnost pomocí čistého a srozumitelného designu.
A začali jsme s vývojem.
Nová architektura panelů
Máme soběstačný vývojářský tým, takže jsme panel napsali sami.
Hlavní práci odvedli tři inženýři – technický ředitel Sergej přišel s architekturou a napsal serverového agenta, Alexey provedl fakturaci a front-end sestavil náš front-ender Artysh.
Krok 1: Server Agent
Serverový agent je webový server pythonu, který spravuje knihovnu , která zase řídí .
Agent spravuje všechny služby na serveru: vytváření, zastavování, mazání vds, instalaci operačních systémů, změnu parametrů a tak dále prostřednictvím knihovny libvirt. V době vydání článku se jedná o více než čtyřicet různých funkcí, které doplňujeme v závislosti na zadání a potřebách klienta.
Teoreticky by libvirt mohl být řízen přímo z fakturace, ale to vyžadovalo příliš mnoho dalšího kódu a rozhodli jsme se tyto funkce oddělit mezi agentem a fakturací – fakturace jednoduše odesílá požadavky na agenta prostřednictvím JSON API.
Agent je první věc, kterou jsme udělali, protože nevyžadoval žádné rozhraní a bylo možné jej otestovat přímo z konzole serveru.
Co nám dal agent serveru: objevila se vrstva, která všem zjednodušuje život – účtování nepotřebuje posílat celou hromadu příkazů, ale pouze zadávat požadavek. A agent udělá vše, co je potřeba: například přidělí místo na disku a RAM.
Krok 2. Fakturace
Pro našeho vývojáře Alexe to nebyl první ovládací panel – Alex je na hostingu dlouho, takže obecně rozuměl tomu, co klient potřebuje a co potřebuje hostitel.
Účtování mezi sebou nazýváme „ovládací panel“: obsahuje nejen peníze a služby, ale také jejich správu, zákaznickou podporu a mnoho dalšího.
Pro přechod ze softwaru ISPSystem bylo nutné pro zákazníky plně zachovat předchozí funkcionalitu, převést veškeré finanční úkony uživatelů ze starého vyúčtování do nového a také veškeré služby a propojení mezi nimi. Studovali jsme, co je v aktuálním produktu, dále řešení konkurence, hlavně DO a Vultr. Podívali jsme se na nevýhody a výhody, sbírali zpětnou vazbu od lidí, kteří pracovali se starými produkty od ISPsystem.
Nové účtování využívalo dva zásobníky: klasické PHP, MySQL (a do budoucna se plánuje přechod na PostgreSQL), Yii2 jako framework na backendu a VueJS na frontě. Stacky fungují nezávisle na sobě, jsou vyvíjeny různými lidmi a komunikují pomocí JSON API. Pro vývoj tehdy a nyní používáme и od JetBrains a vroucně je miluji (ahoj kluci!)
Panel je koncipován na modulární bázi: moduly platebního systému, modul registrátora domény nebo např. modul SSL certifikátu. Můžete snadno přidat novou funkci nebo odstranit starou. Základy pro expanzi jsou položeny architektonicky, a to i v opačném směru, „směrem k hardwaru“.
Co máme: ovládací panel, nad kterým máme plnou kontrolu. Nyní jsou chyby opraveny během hodin, nikoli týdnů, a nové funkce jsou implementovány na žádost zákazníků, nikoli na žádost ISPSystem.
Krok 3 Rozhraní
Rozhraní je duchovním dítětem našeho týmu.
Nejprve jsme se podívali na to, co by se stalo, kdybychom vytvořili doplněk přes ISPsystem API, aniž bychom zásadně něco změnili v rozhraní. Dopadlo to tak a tak a rozhodli jsme se udělat vše od nuly.
Věřili jsme, že hlavní věcí je udělat rozhraní logické, s čistým a minimalistickým designem, a pak dostaneme krásný panel. Umístění prvků bylo probráno v Megaplanu a postupně se bude rodit rozhraní, které nyní uživatelé vidí v ovládacím panelu.
Jako první se objevil design fakturační stránky, protože jsme již udělali platební pluginy pro ISPsystem.
Frontend
Rozhodli se udělat z panelu SPA aplikaci – nenáročnou na zdroje a s rychlým načítáním dat. Náš front-ender Artysh se rozhodl to napsat na Vue — v té době se Vue právě objevilo. Předpokládali jsme, že se framework bude dynamicky vyvíjet, podobně jako React, po nějaké době se komunita Vue rozroste a objeví se moře knihoven. Vsadili jsme na Vue a nelitovali jsme – nyní zabere jen málo času, než přidat nové funkce dopředu, které již byly naprogramovány na backendu. Více o front-end panelu vám řekneme v samostatném článku.
Připojení frontendu k backendu
Frontend byl připojen k backendu pomocí push notifikací. Musel jsem tvrdě pracovat a napsat svůj vlastní handler, ale nyní se informace na stránce aktualizují téměř okamžitě.
Co se stalo: Rozhraní panelu se zjednodušilo. Udělali jsme jej adaptivní a rychlé načítání vám umožní jej používat i z mobilních telefonů v posledních minutách před vzletem, aniž byste museli instalovat samostatnou aplikaci pro práci s panelem.
Krok 4. Schéma testování a migrace
Když se vše rozběhlo a prošly první testy, vyvstala otázka migrace. Nejprve jsme nainstalovali billing a začali testovat jeho fungování se serverovým agentem.
Poté jsme napsali jednoduchý skript, který přenese databázi ze staré fakturace do nové.
Musel jsem otestovat a překontrolovat doslova vše, protože data byla sloučena do jedné nové databáze ze tří starých: Billmanager, VMmanager a manažerův IPmanager. Možná jsou testovací migrace to nejtěžší, co jsme v procesu vývoje nového panelu potkali.
Po opětovné kontrole jsme staré vyúčtování uzavřeli. Finální migrace dat byla velmi znepokojivým okamžikem, ale díky bohu byla dokončena během několika minut a bez znatelných problémů. Během týdne jsme opravili drobné chyby. Většinu času jsme strávili testováním toho, co se stalo.
Poté jsme klientům rozeslali dopisy s adresou nového panelu a fakturací a provedli přesměrování.
V souhrnu: JE TO ŽIVÉ!
Šťastný konec
Od prvních hodin práce s naším softwarem jsme cítili všechny radosti 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
Proces přechodu jsme spustili v prosinci, v předvečer Nového roku 2017, kdy bylo zatížení nejméně, abychom zákazníkům přechod usnadnili – v předvečer svátků téměř nikdo nepracuje.
To hlavní, co jsme při přechodu na náš systém získali (kromě obecné spolehlivosti a pohodlí), je schopnost rychle přidat funkcionalitu pro klíčové zákazníky – být jejich tváří, ne zadkem.
Co bude dál?
Rosteme, roste množství dat, zákazníků, zákaznických dat. Musel jsem do backendu přidat server Memcached a dva správce front s různými úkoly. Frontend má ukládání do mezipaměti a vlastní fronty.
Samozřejmě jsme stále zažívali dobrodružství, jak se produkt vyvíjel a stal se složitějším, například když jsme přidali HighLoad.
V příštím článku vám řekneme, jak byl tarif Hi-CPU spuštěn: o hardwaru, softwaru, jaké úkoly jsme řešili a co jsme dělali.
Zdroj: www.habr.com