Na loňské konferenci vystoupil ředitel provozu portálu Banki.ru Andrey Nikolsky o osiřelých službách: jak identifikovat sirotka v infrastruktuře, proč jsou osiřelé služby špatné, co s nimi dělat a co dělat, když nic nepomůže.
Pod řezem je textová verze zprávy.
Ahoj kolegové! Jmenuji se Andrey a vedu operace na Banki.ru.
Máme velké služby, jsou to takové monolitické služby, jsou služby v klasičtějším pojetí a jsou velmi malé. Ve své dělnicko-rolnické terminologii říkám, že když je služba jednoduchá a malá, tak je mikro, a když není moc jednoduchá a malá, tak je to jen služba.
Klady služeb
Rychle projdu výhody služeb.
První je škálování. Můžete rychle něco udělat na službě a spustit výrobu. Přijali jste provoz, naklonovali jste službu. Máte větší provoz, naklonovali jste ho a žijete s ním. To je dobrý bonus a v zásadě, když jsme začínali, bylo to pro nás považováno za nejdůležitější, proč to všechno děláme.
Za druhé, izolovaný vývoj, kdy máte několik vývojových týmů, několik různých vývojářů v každém týmu a každý tým vyvíjí svou vlastní službu.
S týmy existuje nuance. Vývojáři jsou různí. A jsou tam např. . Poprvé jsem to viděl u Maxima Dorofeeva. Někdy jsou lidé sněhových vloček v některých týmech a v jiných ne. Díky tomu jsou různé služby používané napříč společností poněkud nerovnoměrné.
Podívejte se na obrázek: je to dobrý vývojář, má velké ruce, umí toho hodně. Hlavním problémem je, odkud tyto ruce pocházejí.
Služby umožňují používat různé programovací jazyky, které jsou vhodnější pro různé úkoly. Některé služby jsou v Go, některé v Erlangu, některé v Ruby, něco v PHP, něco v Pythonu. Obecně můžete expandovat velmi široce. I zde jsou nuance.
Architektura orientovaná na služby je primárně o devops. To znamená, že pokud nemáte automatizaci, neexistuje žádný proces nasazení, pokud jej nakonfigurujete ručně, vaše konfigurace se mohou měnit od instance služby k instanci a musíte tam něco udělat, pak jste v pekle.
Například máte 20 služeb a potřebujete je nasadit ručně, máte 20 konzolí a současně stisknete „enter“ jako ninja. Není to moc dobré.
Pokud máte službu po testování (pokud je samozřejmě testování) a potřebujete ji ještě dodělat souborem, aby fungovala ve výrobě, mám pro vás také špatnou zprávu.
Pokud spoléháte na konkrétní služby Amazonu a pracujete v Rusku, pak jste před dvěma měsíci měli také „Vše kolem hoří, mám se dobře, všechno je v pohodě“.
Používáme Ansible k automatizaci nasazení, Puppet pro konvergenci, Bamboo k automatizaci nasazení a Confluence, abychom to všechno nějak popsali.
Nebudu se tím podrobně zabývat, protože zpráva je spíše o interakčních praktikách, nikoli o technické implementaci.
Měli jsme například problémy, kdy Puppet na serveru funguje s Ruby 2, ale některá aplikace je napsána pro Ruby 1.8 a nefungují společně. Něco se tam pokazí. A když potřebujete spustit více verzí Ruby na jednom počítači, obvykle začnete mít problémy.
Například každému vývojáři dáme platformu, na které je přibližně vše, co máme, všechny služby, které se dají vyvíjet, aby měl izolované prostředí, mohl si ho rozbít a stavět, jak chce.
Stává se, že potřebujete nějaký speciálně zkompilovaný balíček s podporou pro něco tam. Je to docela těžké. Poslouchal jsem zprávu, kde obraz Dockeru váží 45 GB. V Linuxu je to samozřejmě jednodušší, všechno je tam menší, ale stejně tam nebude dost místa.
Existují konfliktní závislosti, kdy jedna část projektu závisí na knihovně jedné verze, další část projektu závisí na jiné verzi a knihovny nejsou vůbec nainstalovány společně.
Máme stránky a služby v PHP 5.6, stydíme se za ně, ale co naděláme? Toto je naše jediná stránka. Na PHP 7 jsou stránky a služby, je jich víc, nestydíme se za ně. A každý vývojář má svou vlastní základnu, kde s radostí piluje.
Pokud ve společnosti píšete v jednom jazyce, pak tři virtuální stroje na vývojáře zní normálně. Pokud máte různé programovací jazyky, pak se situace zhorší.
Máte stránky a služby na tomto, na tomto, pak na jiném webu pro Go, jeden web pro Ruby a nějaké další Redis na straně. To vše se ve výsledku změní na velké pole pro podporu a neustále se něco z toho může rozbít.
Proto jsme výhody programovacího jazyka nahradili použitím různých frameworků, jelikož PHP frameworky jsou zcela odlišné, mají různé schopnosti, různé komunity a různou podporu. A můžete si napsat službu, abyste na ni už měli něco připraveného.
Každá služba má svůj vlastní tým
Naší hlavní výhodou, která se vykrystalizovala během několika let, je, že každá služba má svůj tým. To se hodí pro velký projekt, ušetříte čas na dokumentaci, manažeři svůj projekt dobře znají.
Úkoly můžete snadno odesílat z podpory. Porouchala se například pojišťovací služba. A hned to jde opravit tým, který se zabývá pojištěním.
Nové funkce vznikají rychle, protože když máte jednu atomickou službu, můžete do ní rychle něco našroubovat.
A když přerušíte svou službu, a to se nevyhnutelně stane, neovlivníte tím služby jiných lidí a vývojáři z jiných týmů za vámi neběží s drobnostmi a neříkají: „Ay-ay, nedělejte to.“
Jako vždy existují nuance. Máme stabilní týmy, manažeři jsou k týmu jako přibití. Existují jasné dokumenty, manažeři vše bedlivě sledují. Každý tým s manažerem má několik služeb a existuje specifický bod kompetence.
Pokud jsou týmy plovoucí (také to někdy používáme), existuje dobrá metoda zvaná „hvězdná mapa“.
Máte seznam služeb a lidí. Hvězdička znamená, že daný člověk je odborníkem na tuto službu, kniha znamená, že daný člověk tuto službu studuje. Úkolem osoby je vyměnit brožuru za hvězdičku. A pokud před službou není nic napsáno, začnou problémy, o kterých budu mluvit dále.
Jak se osiřelé služby objevují?
První problém, první způsob, jak získat osiřelou službu ve vaší infrastruktuře, je propustit lidi. Už se někdy někomu stalo, že firma dodržela termíny před vyhodnocením úkolů? Někdy se stává, že termíny jsou napjaté a na dokumentaci prostě není dost času. "Musíme předat službu do výroby, pak ji přidáme."
Pokud je tým malý, stává se, že je jeden vývojář, který vše píše, zbytek je v křídlech. "Napsal jsem základní architekturu, pojďme přidat rozhraní." Pak v určité chvíli odejde například manažer. A během tohoto období, kdy manažer odešel a nový ještě nebyl jmenován, sami vývojáři rozhodují o tom, kam služba směřuje a co se tam děje. A jak víme (vraťme se o pár snímků zpět), v některých týmech jsou lidé ze sněhových vloček, někdy vede tým sněhových vloček. Pak skončí a dostaneme službu pro sirotky.
Úkoly z podpory a obchodu přitom nezmizí; Pokud se během vývoje služby vyskytly nějaké architektonické chyby, skončí také v backlogu. Služba se pomalu zhoršuje.
Jak identifikovat sirotka?
Tento seznam dobře popisuje situaci. Kdo se dozvěděl něco o jejich infrastruktuře?
O zdokumentovaných řešeních: existuje služba a obecně funguje, má dvoustránkový manuál, jak s ní pracovat, ale nikdo neví, jak to uvnitř funguje.
Nebo například existuje nějaký zkracovač odkazů. V současné době například používáme tři zkracovače odkazů pro různé účely v různých službách. To jsou jen důsledky.
Teď budu kapitánem zjevného. co je třeba udělat? Nejprve musíme službu převést na jiného manažera, jiný tým. Pokud váš vedoucí týmu ještě neodešel, pak v tomto druhém týmu, když pochopíte, že služba je jako sirotek, musíte zahrnout někoho, kdo tomu alespoň něco rozumí.
Hlavní věc: musíte mít postupy převodu napsané krví. V našem případě to většinou sleduji, protože potřebuji, aby to všechno fungovalo. Manažeři potřebují, aby to bylo doručeno rychle, a co se s tím stane později, už pro ně není tak důležité.
Další způsob, jak udělat sirotka, je „Uděláme to externě, bude to rychlejší a pak to předáme týmu.“ Je jasné, že každý má v týmu nějaké plány, obrat. Firemní zákazník si často myslí, že outsourcing udělá totéž, co technické oddělení, které má společnost. I když jejich motivace jsou různé. V outsourcingu existují podivná technologická řešení a podivná algoritmická řešení.
Měli jsme například službu, která měla Sfingu na různých nečekaných místech. Později vám řeknu, co jsem musel udělat.
Outsourcingové mají vlastní rámce. Toto je jen holé PHP s copy-paste z předchozího projektu, kde můžete najít nejrůznější věci. Skripty nasazení jsou velkou nevýhodou, když potřebujete použít nějaké složité skripty Bash ke změně několika řádků v nějakém souboru, a tyto skripty nasazení jsou volány nějakým třetím skriptem. V důsledku toho změníte systém nasazení, vyberete něco jiného, skočíte, ale vaše služba nefunguje. Protože tam bylo potřeba dát 8 dalších odkazů mezi různé složky. Nebo se stane, že tisíc záznamů funguje, ale sto tisíc už nefunguje.
Budu pokračovat jako kapitán. Přijetí outsourcované služby je povinný postup. Už se někdy stalo, že někomu přišla outsourcovaná služba a nikde nebyla přijata? Není to samozřejmě tak populární jako služba pro sirotky, ale přesto.
Službu je třeba zkontrolovat, službu zkontrolovat, změnit hesla. Měli jsme případ, kdy nám dali službu, je tam admin panel „if login == 'admin' && password == 'admin'...“, je to napsané přímo v kódu. Sedíme a přemýšlíme a lidé to píší v roce 2018?
Nezbytnou věcí je také testování kapacity úložiště. Je třeba se podívat na to, co se stane na sto tisících záznamech, ještě než tuto službu někde zavedete do výroby.
Neměla by být ostuda poslat službu ke zlepšení. Když řeknete: „Nepřijmeme tuto službu, máme 20 úkolů, udělejte je a pak přijmeme,“ je to normální. Svědomí by vás nemělo bolet z toho, že zařizujete manažera nebo že podnik rozhazuje peníze. Podnik pak utratí více.
Měli jsme případ, kdy jsme se rozhodli outsourcovat pilotní projekt.
Bylo doručeno včas a toto bylo jediné kritérium kvality. Proto jsme udělali další pilotní projekt, který už vlastně ani nebyl pilotní. Tyto služby byly přijaty a prostřednictvím administrativních prostředků řekli, zde je váš kód, zde je tým, zde je váš manažer. Služby už vlastně začaly vydělávat. Přitom jsou ve skutečnosti stále sirotci, nikdo nechápe, jak fungují, a manažeři se ze všech sil svých úkolů zříkají.
Existuje další skvělý koncept – guerilla development. Když některé oddělení, obvykle marketingové oddělení, chce otestovat hypotézu a objedná celou službu externě. Začne se do toho hrnout provoz, uzavřou dokumenty, podepíší dokumenty se zhotovitelem, vstoupí do provozu a řeknou: „Hoši, my tady máme službu, ta už má provoz, přináší nám peníze, přijměme to.“ Říkali jsme si: "Oppa, jak je to možné."
A další způsob, jak získat osiřelou službu: když se některý tým náhle přetíží, vedení řekne: „Převeďme službu tohoto týmu na jiný tým, má menší zátěž.“ A pak to převedeme do třetího týmu a vyměníme manažera. A nakonec tu máme zase sirotka.
Jaký je problém se sirotky?
Kdo neví, tohle je bitevní loď Wasa, vychovaná ve Švédsku, známá tím, že se potopila 5 minut po startu. A švédský král za to mimochodem nikoho nepopravil. Postavily ho dvě generace inženýrů, kteří nevěděli, jak takové lodě postavit. Přirozený efekt.
Loď se mohla potopit mimochodem i mnohem horším způsobem, třeba když na ní král jel už někde v bouři. A tak se hned utopil, podle Agile je dobré selhat brzy.
Pokud selžeme brzy, obvykle nejsou žádné problémy. Například při přejímce byl odeslán k revizi. Ale pokud selžeme již ve výrobě, když byly investovány peníze, pak mohou nastat problémy. Následky, jak se jim v podnikání říká.
Proč jsou osiřelé služby nebezpečné:
- Služba se může náhle přerušit.
- Oprava služby trvá dlouho nebo není opravena vůbec.
- Bezpečnostní problémy.
- Problémy s vylepšeními a aktualizacemi.
- Pokud dojde k poruše důležité služby, utrpí pověst společnosti.
Co dělat s osiřelými službami?
Znovu zopakuji, co dělat. Nejprve musí existovat dokumentace. 7 let na Banki.ru mě naučilo, že testeři by neměli brát slovo vývojářům a operace by neměly brát slovo všem. Musíme zkontrolovat.
Za druhé je nutné psát interakční diagramy, protože se stává, že služby, které nejsou příliš dobře přijímány, obsahují závislosti, o kterých nikdo neřekl. Vývojáři například nainstalovali službu na svůj klíč k některým Yandex.Maps nebo Dadata. Vyčerpali jste volný limit, všechno je rozbité a vy vůbec nevíte, co se stalo. Všechny takové rake by měly být popsány: služba používá Dadata, SMS, něco jiného.
Za třetí, práce s technickým dluhem. Když děláte nějaké berličky nebo přijímáte službu a říkáte, že je třeba něco udělat, musíte se ujistit, že je to hotovo. Protože pak se může ukázat, že ta malá dírka není tak malá, a propadnete jí.
S architektonickými úkoly jsme měli příběh o Sfingě. Jedna ze služeb používala Sphinx k zadávání seznamů. Jen stránkovaný seznam, ale každý večer byl znovu indexován. Skládal se ze dvou indexů: každý večer se indexoval jeden velký a byl tam také malý index, který byl k němu přišroubován. Každý den, s 50% pravděpodobností buď bombardování nebo ne, index během výpočtu havaroval a naše zprávy se přestaly aktualizovat na hlavní stránce. Nejprve trvalo 5 minut, než byl index znovu indexován, pak index rostl a v určitém okamžiku začalo opětovné indexování trvat 40 minut. Když jsme toto vystřihli, oddechli jsme si, protože bylo jasné, že uplyne ještě trochu času a náš index bude znovu indexován na plný úvazek. To bude pro náš portál neúspěch, osm hodin nejsou žádné zprávy – to je vše, obchod se zastavil.
Naplánujte si práci s osiřelou službou
Ve skutečnosti je to velmi obtížné, protože devops je o komunikaci. Chcete být se svými kolegy zadobře, a když své kolegy a manažery praštíte přes hlavu nařízeními, mohou mít protichůdné pocity vůči lidem, kteří to dělají.
Kromě všech těchto bodů je tu ještě jedna důležitá věc: za každou konkrétní službu, za každý konkrétní úsek postupu nasazení musí být zodpovědní konkrétní lidé. Když nejsou žádní lidé a musíte přitahovat nějaké další lidi, studovat celou tuto záležitost je obtížné.
Pokud toto vše nepomohlo a vaše osiřelá služba je stále sirotkem, nikdo ji nechce převzít, dokumentace není sepsána, tým, který byl do této služby povolán, odmítá cokoliv udělat, existuje jednoduchý způsob - předělat všechno .
To znamená, že vezmete požadavky na službu nově a napíšete novou službu, lepší, na lepší platformě, bez podivných technologických řešení. A vy k němu migrujete v bitvě.
Měli jsme situaci, kdy jsme vzali službu na Yii 1 a uvědomili jsme si, že ji nemůžeme dále rozvíjet, protože nám došli vývojáři, kteří uměli dobře psát na Yii 1. Všichni vývojáři píší dobře na Symfony XNUMX. Co dělat? Přidělili jsme čas, přidělili tým, přidělili manažera, přepsali projekt a plynule do něj přepnuli provoz.
Poté lze starou službu smazat. To je můj oblíbený postup, kdy potřebujete vzít a vyčistit nějakou službu ze systému správy konfigurace a pak projít a zjistit, že všechna auta ve výrobě byla deaktivována, aby po vývojářích nezůstaly žádné stopy. Úložiště zůstává v Gitu.
To je vše, o čem jsem chtěl mluvit, jsem připraven diskutovat, téma je holivar, mnozí v tom plavali.
Na snímcích bylo uvedeno, že jste sjednotili jazyky. Příkladem byla změna velikosti obrázků. Je opravdu nutné to striktně omezit na jeden jazyk? Protože změna velikosti obrázku v PHP by mohla být ve skutečnosti provedena v Golangu.
Ve skutečnosti je to volitelné, jako všechny praktiky. Možná je to v některých případech dokonce nežádoucí. Ale musíte pochopit, že pokud máte technické oddělení ve firmě o 50 lidech, 45 z nich jsou specialisté na PHP, další 3 jsou devops, kteří znají Python, Ansible, Puppet a něco podobného, a jen jeden z nich píše v některých služby pro změnu velikosti obrázků Go, a když odejde, jde s ní i odbornost. A zároveň budete muset hledat vývojáře specifického pro daný trh, který tento jazyk zná, zvláště pokud je vzácný. Čili z organizačního hlediska je to problematické. Z pohledu devopsu nebudete muset jen naklonovat nějakou hotovou sadu playbooků, které používáte k nasazení služeb, ale budete je muset psát celé znovu.
V současné době budujeme službu na Node.js a bude to jen platforma poblíž pro každého vývojáře se samostatným jazykem. Ale seděli jsme a říkali si, že ta hra stojí za svíčku. To znamená, že je to otázka pro vás, abyste si sedli a přemýšleli.
Jak své služby sledujete? Jak shromažďujete a monitorujete protokoly?
Logy sbíráme v Elasticsearch a dáváme je do Kibana a tam se podle toho, jestli jde o produkční nebo testovací prostředí, používají různé sběrače. Někde dřevorubec, jinde něco jiného, nevzpomínám si. A stále existují místa v určitých službách, kde Telegraf nainstalujeme a natáčíme někde jinde samostatně.
Jak žít s Puppet a Ansible ve stejném prostředí?
Ve skutečnosti teď máme dvě prostředí, jedno je Puppet a druhé Ansible. Pracujeme na jejich hybridizaci. Ansible je dobrý rámec pro počáteční nastavení, Puppet je špatný rámec pro počáteční nastavení, protože vyžaduje praktickou práci přímo na platformě a Puppet zajišťuje konvergenci konfigurace. To znamená, že platforma se sama udržuje v aktuálním stavu, a aby byl ansibilizovaný stroj stále aktuální, musíte na něm neustále spouštět playbooky s nějakou frekvencí. To je ten rozdíl.
Jak udržujete kompatibilitu? Máte konfigurace v Ansible i Puppet?
To je naše velká bolest, zachováváme si kompatibilitu s rukama a přemýšlíme, jak se z toho všeho teď někam posunout. Ukázalo se, že Puppet rozbaluje balíčky a udržuje tam nějaké odkazy a Ansible tam například spouští kód a upravuje nejnovější konfigurace aplikací.
Prezentace byla o různých verzích Ruby. jaké řešení?
S tím jsme se setkali na jednom místě a musíme to mít neustále v hlavě. Jednoduše jsme vypnuli část, která běžela na Ruby a která byla nekompatibilní s aplikacemi, a nechali ji oddělenou.
Letošní konference se uskuteční 7. prosince v Technopolis. Přihlášky na reportáže přijímáme do 11. listopadu. nás, pokud byste chtěli mluvit.
Registrace účastníků je spuštěna, přidejte se k nám!
Zdroj: www.habr.com