Na minuloročnej konferencii vystúpil riaditeľ prevádzky portálu Banki.ru Andrey Nikolsky o osirotených službách: ako identifikovať sirotu v infraštruktúre, prečo sú osirotené služby zlé, čo s nimi robiť a čo robiť, ak nič nepomôže.
Pod strihom je textová verzia správy.
Ahojte kolegovia! Moje meno je Andrey, vediem operácie v Banki.ru.
Máme veľké služby, sú to také monolitické služby, sú služby v klasickejšom zmysle a sú veľmi malé. V mojej robotnícko-roľníckej terminológii hovorím, že ak je služba jednoduchá a malá, tak je mikro, a ak nie je veľmi jednoduchá a malá, tak je to len služba.
Výhody služieb
Rýchlo prejdem výhody služieb.
Prvým je škálovanie. Môžete rýchlo urobiť niečo v službe a spustiť výrobu. Prijali ste prenos, naklonovali ste službu. Máte väčšiu návštevnosť, naklonovali ste ju a žijete s ňou. To je dobrý bonus a v zásade, keď sme začínali, bolo to pre nás najdôležitejšie, prečo to všetko robíme.
Po druhé, izolovaný vývoj, keď máte niekoľko vývojových tímov, niekoľko rôznych vývojárov v každom tíme a každý tím vyvíja svoju vlastnú službu.
S tímami je tu nuansa. Vývojári sú rôzni. A sú tam napr. . Prvýkrát som to videl s Maximom Dorofeevom. Ľudia zo snehových vločiek sú niekedy v niektorých tímoch a v iných nie. Vďaka tomu sú rôzne služby používané v rámci spoločnosti trochu nerovnomerné.
Pozrite sa na obrázok: je to dobrý vývojár, má veľké ruky, dokáže veľa. Hlavným problémom je, odkiaľ tieto ruky pochádzajú.
Služby umožňujú používať rôzne programovacie jazyky, ktoré sú vhodnejšie pre rôzne úlohy. Niektoré služby sú v Go, niektoré v Erlangu, iné v Ruby, niečo v PHP, niečo v Pythone. Vo všeobecnosti môžete expandovať veľmi široko. Aj tu sú nuansy.
Architektúra orientovaná na služby je primárne o devops. To znamená, že ak nemáte automatizáciu, neexistuje žiadny proces nasadenia, ak ho nakonfigurujete manuálne, vaše konfigurácie sa môžu meniť od inštancie služby k inštancii a musíte tam ísť, aby ste niečo urobili, potom ste v pekle.
Napríklad máte 20 služieb a potrebujete ich nasadiť ručne, máte 20 konzol a súčasne stlačíte „enter“ ako ninja. Nie je to veľmi dobré.
Ak máte službu po testovaní (ak je testovanie, samozrejme), a potrebujete ju ešte dokončiť súborom, aby fungovala vo výrobe, mám pre vás aj zlú správu.
Ak sa spoliehate na konkrétne služby Amazonu a pracujete v Rusku, potom ste pred dvoma mesiacmi mali aj „Všetko okolo je v plameňoch, mám sa dobre, všetko je v pohode“.
Používame Ansible na automatizáciu nasadenia, Puppet na konvergenciu, Bamboo na automatizáciu nasadenia a Confluence na to, aby sme to všetko nejako opísali.
Nebudem sa tým podrobne zaoberať, pretože správa je skôr o interakčných praktikách a nie o technickej implementácii.
Napríklad sme mali problémy, keď Puppet na serveri funguje s Ruby 2, ale niektoré aplikácie sú napísané pre Ruby 1.8 a nefungujú spolu. Niečo sa tam pokazí. A keď potrebujete spustiť viacero verzií Ruby na jednom počítači, zvyčajne začnete mať problémy.
Napríklad každému vývojárovi dáme platformu, na ktorej je približne všetko, čo máme, všetky služby, ktoré sa dajú vyvíjať, aby mal izolované prostredie, mohol si ho rozbiť a postaviť, ako chce.
Stáva sa, že potrebujete nejaký špeciálne zostavený balík s podporou pre niečo tam. Je to dosť ťažké. Počúval som správu, kde obrázok Docker váži 45 GB. V Linuxe je to, samozrejme, jednoduchšie, všetko je tam menšie, no aj tak tam nebude dosť miesta.
Existujú protichodné závislosti, keď jedna časť projektu závisí od knižnice jednej verzie, ďalšia časť projektu závisí od inej verzie a knižnice nie sú vôbec nainštalované spolu.
Máme stránky a služby v PHP 5.6, hanbíme sa za ne, ale čo narobíme? Toto je naša jediná stránka. Na PHP 7 sú stránky a služby, je ich viac, nehanbíme sa za ne. A každý vývojár má svoju základňu, kde s radosťou píli.
Ak píšete v spoločnosti v jednom jazyku, potom tri virtuálne stroje na vývojára znie normálne. Ak máte rôzne programovacie jazyky, situácia sa zhorší.
Máte stránky a služby na tomto, na tomto, potom na ďalšom webe pre Go, na jednom webe pre Ruby a na boku nejaké ďalšie Redis. Výsledkom je, že toto všetko sa zmení na veľké pole podpory a stále sa môže niečo z toho zlomiť.
Preto sme výhody programovacieho jazyka nahradili používaním rôznych frameworkov, keďže PHP frameworky sú dosť odlišné, majú iné schopnosti, rôzne komunity a rôznu podporu. A môžete si napísať službu, aby ste už na ňu mali niečo pripravené.
Každá služba má svoj vlastný tím
Našou hlavnou výhodou, ktorá sa vykryštalizovala niekoľko rokov, je, že každá služba má svoj tím. To je výhodné pri veľkom projekte, ušetríte čas na dokumentácii, manažéri dobre poznajú svoj projekt.
Úlohy môžete jednoducho odosielať z podpory. Pokazila sa napríklad poisťovacia služba. A hneď to ide opravovať tím, ktorý sa zaoberá poistením.
Nové funkcie vznikajú rýchlo, pretože keď máte jednu atomickú službu, rýchlo do nej niečo naskrutkujete.
A keď prerušíte svoju službu, a to sa nevyhnutne stane, neovplyvníte služby iných ľudí a vývojári z iných tímov za vami neprídu s kúskami a nepovedia: „Áno, nerob to.“
Ako vždy, existujú nuansy. Máme stabilné tímy, manažéri sú prikovaní k mužstvu. Existujú jasné dokumenty, manažéri všetko pozorne sledujú. Každý tím s manažérom má niekoľko služieb a existuje špecifický bod kompetencie.
Ak sú tímy plávajúce (tiež to niekedy používame), existuje dobrá metóda nazývaná „hviezdna mapa“.
Máte zoznam služieb a ľudí. Hviezdička znamená, že osoba je odborníkom na túto službu, kniha znamená, že túto službu študuje. Úlohou osoby je zmeniť brožúru za hviezdičku. A ak pred službou nie je nič napísané, začnú problémy, o ktorých budem hovoriť ďalej.
Ako sa sirotské služby zobrazujú?
Prvý problém, prvý spôsob, ako získať osirotenú službu vo vašej infraštruktúre, je prepustiť ľudí. Už sa niekomu stalo, že firma dodržiavala termíny pred hodnotením úloh? Niekedy sa stáva, že termíny sú tesné a na dokumentáciu jednoducho nie je dostatok času. "Musíme odovzdať službu do výroby, potom ju pridáme."
Ak je tím malý, stáva sa, že je tam jeden vývojár, ktorý všetko píše, zvyšok je v krídlach. "Napísal som základnú architektúru, poďme pridať rozhrania." Potom v určitom momente odíde napríklad manažér. A počas tohto obdobia, keď manažér odišiel a nový ešte nebol vymenovaný, samotní vývojári rozhodujú o tom, kam služba smeruje a čo sa tam deje. A ako vieme (vráťme sa o pár snímok späť), niektoré tímy majú ľudí zo snehových vločiek, niekedy aj vedúceho tímu snehových vločiek. Potom odíde a dostaneme službu pre siroty.
Zároveň nemiznú úlohy z podpory a obchodu; Ak sa počas vývoja služby vyskytli nejaké architektonické chyby, končia tiež v backlogu. Služba sa pomaly zhoršuje.
Ako identifikovať sirotu?
Tento zoznam dobre popisuje situáciu. Kto sa dozvedel niečo o ich infraštruktúre?
O zdokumentovaných riešeniach: existuje služba a vo všeobecnosti funguje, má dvojstranový manuál, ako s ňou pracovať, ale nikto nevie, ako to vo vnútri funguje.
Alebo napríklad existuje nejaký skracovač odkazov. V súčasnosti napríklad používame tri skracovače odkazov na rôzne účely v rôznych službách. Toto sú len dôsledky.
Teraz budem kapitánom jasného. Čo treba urobiť? Najprv musíme preniesť službu na iného manažéra, iný tím. Ak váš vedúci tímu ešte neskončil, potom v tomto inom tíme, keď pochopíte, že služba je ako sirota, musíte zahrnúť niekoho, kto tomu aspoň niečo rozumie.
Hlavná vec: musíte mať postupy prenosu napísané krvou. V našom prípade to väčšinou sledujem, pretože potrebujem, aby to všetko fungovalo. Manažéri to potrebujú rýchlo dodať a to, čo sa s tým stane neskôr, už pre nich nie je také dôležité.
Ďalší spôsob, ako urobiť sirotu, je „Urobíme to externe, bude to rýchlejšie a potom to odovzdáme tímu.“ Je jasné, že každý má v tíme nejaké plány, obrat. Firemný zákazník si často myslí, že outsourcing urobí to isté ako technické oddelenie, ktoré má spoločnosť. Aj keď ich motivátory sú rôzne. V outsourcingu existujú zvláštne technologické riešenia a podivné algoritmické riešenia.
Mali sme napríklad službu, ktorá mala Sfingu na rôznych nečakaných miestach. Neskôr vám poviem, čo som musel urobiť.
Outsourcingovia majú vlastné rámce. Toto je len holé PHP s copy-paste z predchádzajúceho projektu, kde môžete nájsť všeličo. Skripty nasadenia sú veľkou nevýhodou, keď potrebujete použiť nejaké zložité skripty Bash na zmenu niekoľkých riadkov v nejakom súbore a tieto skripty nasadenia sú volané nejakým tretím skriptom. V dôsledku toho zmeníte systém nasadenia, vyberiete niečo iné, preskočíte, ale vaša služba nefunguje. Pretože tam bolo potrebné dať 8 ďalších odkazov medzi rôzne zložky. Alebo sa stane, že tisíc záznamov funguje, ale stotisíc už nefunguje.
Budem pokračovať ako kapitán. Prijatie externej služby je povinný postup. Už sa niekomu stalo, že prišla externá služba a nikde ju neprijali? Nie je to, samozrejme, také populárne ako služba siroty, ale stále.
Službu je potrebné skontrolovať, službu skontrolovať, zmeniť heslá. Mali sme prípad, keď nám dali službu, je tam admin panel “ak sa prihlási == 'admin' && heslo == 'admin'...”, je to napísané priamo v kóde. Sedíme a premýšľame a ľudia to píšu v roku 2018?
Nevyhnutnou vecou je aj testovanie úložnej kapacity. Treba sa pozrieť na to, čo sa stane na stotisíc záznamoch, ešte predtým, ako túto službu niekde uvediete do výroby.
Poslať službu na zlepšenie by nemala byť hanba. Keď poviete: „Neprijmeme túto službu, máme 20 úloh, urobte ich a potom prijmeme,“ je to normálne. Svedomie by vás nemalo bolieť ani z toho, že si zakladáte manažéra, alebo že podnik plytvá peniazmi. Podnik potom bude míňať viac.
Mali sme prípad, keď sme sa rozhodli zadať pilotný projekt externe.
Bolo doručené načas a toto bolo jediné kritérium kvality. Preto sme urobili ďalší pilotný projekt, ktorý už vlastne ani pilotom nebol. Tieto služby boli prijaté a prostredníctvom administratívnych prostriedkov povedali, tu je váš kód, tu je tím, tu je váš manažér. Služby už vlastne začali prinášať zisk. Zároveň sú v skutočnosti stále siroty, nikto nerozumie tomu, ako fungujú, a manažéri robia všetko pre to, aby sa vzdali svojich úloh.
Existuje ďalší skvelý koncept – guerilla development. Keď niektoré oddelenie, zvyčajne marketingové oddelenie, chce otestovať hypotézu a objedná celú službu externe. Začne sa do toho hrnúť premávka, uzavrú dokumenty, podpíšu dokumenty s dodávateľom, vstúpia do prevádzky a povedia: „Chlapi, máme tu službu, už má premávku, prináša nám peniaze, prijmime to.“ Hovorili sme si: "Oppa, ako to môže byť?"
A ďalší spôsob, ako získať osirotenú službu: keď je niektorý tím náhle preťažený, vedenie povie: „Prenesme službu tohto tímu do iného tímu, má menšiu záťaž.“ A potom to prenesieme do tretieho tímu a zmeníme manažéra. A na záver tu máme opäť sirotu.
Aký je problém so sirotami?
Kto nevie, toto je bojová loď Wasa vychovaná vo Švédsku, známa tým, že sa potopila 5 minút po štarte. A švédsky kráľ, mimochodom, za to nikoho nepopravil. Postavili ju dve generácie inžinierov, ktorí nevedeli, ako takéto lode postaviť. Prirodzený efekt.
Loď sa mohla potopiť, mimochodom, aj oveľa horším spôsobom, napríklad keď sa na nej kráľ už viezol niekde v búrke. A tak sa hneď utopil, podľa Agile je dobré zlyhať skôr.
Ak zlyháme skôr, zvyčajne nie sú žiadne problémy. Napríklad pri preberaní bol odoslaný na revíziu. Ale ak zlyháme už vo výrobe, keď sa investujú peniaze, potom môžu nastať problémy. Následky, ako sa im v biznise hovorí.
Prečo sú osirotené služby nebezpečné:
- Služba sa môže náhle prerušiť.
- Oprava služby trvá dlho alebo sa neopraví vôbec.
- Bezpečnostné problémy.
- Problémy s vylepšeniami a aktualizáciami.
- Ak dôjde k poruche dôležitej služby, utrpí to povesť spoločnosti.
Čo robiť so službami pre siroty?
Ešte raz zopakujem, čo robiť. Po prvé, musí existovať dokumentácia. 7 rokov v Banki.ru ma naučilo, že testeri by nemali brať slovo vývojárov a operácie by nemali brať slovo každému. Musíme skontrolovať.
Po druhé, je potrebné písať interakčné diagramy, pretože sa stáva, že služby, ktoré nie sú veľmi dobre prijímané, obsahujú závislosti, o ktorých nikto nehovoril. Napríklad vývojári nainštalovali službu na svoj kľúč do niektorých Yandex.Maps alebo Dadata. Vyčerpali ste bezplatný limit, všetko je pokazené a vy vôbec neviete, čo sa stalo. Všetky takéto hrable by mali byť popísané: služba používa Dadata, SMS, niečo iné.
Po tretie, práca s technickým dlhom. Keď robíte nejaké barličky alebo prijímate službu a hovoríte, že treba niečo urobiť, musíte sa uistiť, že sa to robí. Pretože potom sa môže ukázať, že ten malý otvor nie je až taký malý a prepadnete sa ním.
S architektonickými úlohami sme mali príbeh o Sfinge. Jedna zo služieb využívala Sphinx na zadávanie zoznamov. Len stránkovaný zoznam, ale každý večer bol preindexovaný. Bol zostavený z dvoch indexov: každý večer sa indexoval jeden veľký a bol tam aj malý index, ktorý bol k nemu priskrutkovaný. Každý deň, s 50% pravdepodobnosťou buď bombardovania, alebo nie, index počas výpočtu spadol a naše správy sa prestali aktualizovať na hlavnej stránke. Najprv trvalo 5 minút, kým sa index preindexoval, potom index rástol a v určitom okamihu sa začal preindexovať na 40 minút. Keď sme toto vystrihli, vydýchli sme si, pretože bolo jasné, že prejde ešte trochu času a náš index bude preindexovaný na plný úväzok. Pre náš portál to bude neúspech, osem hodín nie sú žiadne správy – to je všetko, obchod sa zastavil.
Naplánujte si prácu so službou pre siroty
V skutočnosti je to veľmi ťažké, pretože devops je o komunikácii. Chcete byť zadobre so svojimi kolegami, a keď svojich kolegov a manažérov udriete cez hlavu nariadeniami, môžu mať protichodné pocity voči ľuďom, ktorí to robia.
Okrem všetkých týchto bodov je tu ešte jedna dôležitá vec: konkrétni ľudia musia byť zodpovední za každú konkrétnu službu, za každú konkrétnu časť postupu nasadenia. Keď nie sú žiadni ľudia a musíte prilákať ďalších ľudí, študovať celú túto záležitosť je ťažké.
Ak toto všetko nepomohlo a vaša sirotská služba je stále sirotou, nikto ju nechce prevziať, dokumentácia nie je spísaná, tím, ktorý bol povolaný do tejto služby, odmieta čokoľvek urobiť, existuje jednoduchý spôsob - prerobiť všetko .
To znamená, že vezmete požiadavky na službu nanovo a napíšete novú službu, lepšiu, na lepšej platforme, bez podivných technologických riešení. A vy migrujete k nemu v boji.
Mali sme situáciu, keď sme vzali službu na Yii 1 a uvedomili sme si, že ju nemôžeme ďalej rozvíjať, pretože nám došli vývojári, ktorí by vedeli dobre písať na Yii 1. Všetci vývojári píšu dobre na Symfony XNUMX. Čo robiť? Pridelili sme čas, pridelili tím, pridelili manažéra, prepísali projekt a plynule sme doň prepli návštevnosť.
Potom je možné starú službu odstrániť. Toto je môj obľúbený postup, keď potrebujete zobrať a vyčistiť nejakú službu zo systému správy konfigurácie a potom prejsť a vidieť, že všetky autá vo výrobe sú deaktivované, aby po vývojároch nezostali žiadne stopy. Úložisko zostáva v Git.
Toto je všetko, o čom som chcel hovoriť, som pripravený diskutovať, téma je holivar, mnohí v tom plávali.
Na snímkach sa uvádzalo, že ste zjednotili jazyky. Príkladom bola zmena veľkosti obrázkov. Je naozaj potrebné striktne to obmedziť na jeden jazyk? Pretože zmena veľkosti obrázka v PHP by sa v skutočnosti dala vykonať v Golangu.
V skutočnosti je to voliteľné, ako všetky postupy. Možno je to v niektorých prípadoch dokonca nežiaduce. Ale musíte pochopiť, že ak máte technické oddelenie vo firme s 50 ľuďmi, 45 z nich sú špecialisti na PHP, ďalší 3 sú devopi, ktorí vedia Python, Ansible, Puppet a niečo podobné, a len jeden z nich píše v niektorých služby na zmenu veľkosti obrázkov Go, a keď odíde, ide s ním aj odbornosť. A zároveň budete musieť hľadať vývojára špecifického pre daný trh, ktorý ovláda tento jazyk, najmä ak je to zriedkavé. To znamená, že z organizačného hľadiska je to problematické. Z pohľadu devopsu nebudete musieť len naklonovať nejakú hotovú sadu playbookov, ktoré použijete na nasadenie služieb, ale budete ich musieť napísať celé odznova.
V súčasnosti budujeme službu na Node.js a toto bude len platforma v blízkosti pre každého vývojára so samostatným jazykom. Ale sedeli sme a mysleli si, že hra stojí za sviečku. To znamená, že toto je otázka, aby ste si sadli a premýšľali.
Ako monitorujete svoje služby? Ako zbierate a monitorujete denníky?
Logy zbierame v Elasticsearch a dávame ich do Kibana a podľa toho, či ide o produkčné alebo testovacie prostredia, tam sa používajú rôzne zberače. Niekde Drevorubač, inde niečo iné, nepamätám si. A stále existujú miesta v určitých službách, kde nainštalujeme Telegraf a natáčame niekde inde samostatne.
Ako žiť s Puppet a Ansible v rovnakom prostredí?
V skutočnosti máme teraz dve prostredia, jedno je Puppet, druhé je Ansible. Pracujeme na ich hybridizácii. Ansible je dobrý rámec pre počiatočné nastavenie, Puppet je zlý rámec pre počiatočné nastavenie, pretože vyžaduje praktickú prácu priamo na platforme a Puppet zabezpečuje konvergenciu konfigurácie. To znamená, že platforma sa udržiava v aktuálnom stave a aby bol ansibilizovaný stroj stále aktuálny, musíte na ňom neustále spúšťať playbooky s určitou frekvenciou. To je ten rozdiel.
Ako udržiavate kompatibilitu? Máte konfigurácie v Ansible aj Puppet?
To je naša veľká bolesť, udržiavame si kompatibilitu s rukami a rozmýšľame, ako sa z toho všetkého teraz niekam posunúť ďalej. Ukazuje sa, že Puppet zavádza balíčky a udržiava tam nejaké odkazy a Ansible napríklad zavádza kód a upravuje tam najnovšie konfigurácie aplikácií.
Prezentácia bola o rôznych verziách Ruby. Aké riešenie?
Stretli sme sa s tým na jednom mieste a musíme to mať neustále v hlave. Jednoducho sme vypli časť, ktorá bežala na Ruby a ktorá nebola kompatibilná s aplikáciami, a ponechali sme ju oddelenú.
Tohtoročná konferencia sa uskutoční 7. decembra v Technopolise. Prihlášky na reportáže prijímame do 11. novembra. nás, ak by ste chceli hovoriť.
Registrácia pre účastníkov je spustená, pridajte sa k nám!
Zdroj: hab.com