Portalo Banki.ru operacijų direktorius Andrejus Nikolskis kalbėjo praėjusių metų konferencijoje apie našlaičių paslaugas: kaip atpažinti našlaitį infrastruktūroje, kodėl našlaičių paslaugos blogos, ką su jomis daryti ir ką daryti, jei niekas nepadeda.
Po pjūviu yra tekstinė ataskaitos versija.
Sveiki kolegos! Mano vardas Andrejus, vadovauju Banki.ru operacijoms.
Mes turime dideles paslaugas, tai tokios monolitinės paslaugos, yra paslaugų klasikine prasme, ir yra labai mažų. Savo darbininko-valstiečių terminologijoje aš sakau, kad jei paslauga yra paprasta ir maža, tai ji yra mikro, o jei ji nėra labai paprasta ir maža, tai yra tik paslauga.
Paslaugų pliusai
Greitai apžvelgsiu paslaugų privalumus.
Pirmasis yra mastelio keitimas. Galite greitai ką nors padaryti naudodami paslaugą ir pradėti gamybą. Sulaukėte srauto, klonavote paslaugą. Turite didesnį srautą, jį klonavote ir gyvenate su juo. Tai gera premija, ir iš principo, kai pradėjome, mums buvo svarbiausia, kodėl mes visa tai darome.
Antra, izoliuotas vystymas, kai turite kelias kūrimo komandas, kiekvienoje komandoje po kelis skirtingus kūrėjus ir kiekviena komanda kuria savo paslaugą.
Su komandomis yra niuansas. Kūrėjai yra skirtingi. Ir yra pvz. . Pirmą kartą tai pamačiau su Maksimu Dorofejevu. Kartais snaigės yra vienose komandose, o kitose ne. Dėl to įvairios įmonės naudojamos paslaugos šiek tiek nevienodos.
Pažiūrėkite į paveikslėlį: tai geras kūrėjas, jis turi dideles rankas, gali daug. Pagrindinė problema yra ta, iš kur atsiranda šios rankos.
Paslaugos suteikia galimybę naudoti įvairias programavimo kalbas, kurios labiau tinka įvairioms užduotims atlikti. Kai kurios paslaugos yra Go, kai kurios yra Erlang, kai kurios yra Ruby, kažkas yra PHP, kažkas yra Python. Apskritai galite plėstis labai plačiai. Čia taip pat yra niuansų.
Į paslaugas orientuota architektūra visų pirma susijusi su devopsais. Tai yra, jei neturite automatizavimo, nėra diegimo proceso, jei konfigūruosite jį rankiniu būdu, jūsų konfigūracijos gali keistis nuo paslaugos egzemplioriaus iki egzemplioriaus ir jūs turite eiti ten, kad ką nors padarytumėte, tada esate pragare.
Pavyzdžiui, turite 20 paslaugų ir turite įdiegti rankiniu būdu, turite 20 konsolių ir vienu metu spaudžiate „Enter“ kaip nindzė. Tai nėra labai gerai.
Jei turite paslaugą po testavimo (jei yra testavimas, žinoma), ir jums vis tiek reikia ją užbaigti su failu, kad jis veiktų gamyboje, taip pat turiu jums blogų naujienų.
Jei pasitikite konkrečiomis „Amazon“ paslaugomis ir dirbate Rusijoje, tai prieš du mėnesius taip pat buvo: „Viskas aplink dega, man viskas gerai, viskas puiku“.
Naudojame Ansible diegimui automatizuoti, Puppet konvergencijai, Bamboo diegimui automatizuoti ir Confluence, kad kažkaip apibūdintume visa tai.
Smulkiau apie tai nekalbėsiu, nes ataskaitoje daugiau kalbama apie sąveikos praktiką, o ne apie techninį įgyvendinimą.
Pavyzdžiui, turėjome problemų, kai serverio Puppet veikia su Ruby 2, bet kai kurios programos yra parašytos Ruby 1.8, ir jos neveikia kartu. Kažkas ten negerai. Ir kai viename kompiuteryje reikia paleisti kelias Ruby versijas, dažniausiai kyla problemų.
Pavyzdžiui, kiekvienam kūrėjui suteikiame platformą, kurioje yra maždaug viskas, ką turime, visos paslaugos, kurias galima sukurti, kad jis turėtų izoliuotą aplinką, galėtų ją sulaužyti ir kurti kaip nori.
Taip atsitinka, kad jums reikia kažkokio specialiai sudaryto paketo su kažko palaikymu. Tai gana sunku. Klausiausi reportažo, kur Docker vaizdas sveria 45 GB. „Linux“, žinoma, paprasčiau, ten viskas yra mažesnė, bet vis tiek vietos neužteks.
Na, yra prieštaringų priklausomybių, kai viena projekto dalis priklauso nuo vienos versijos bibliotekos, kita projekto dalis priklauso nuo kitos versijos, o bibliotekos nėra įdiegtos kartu.
Mes turime svetaines ir paslaugas PHP 5.6 versijos, mums dėl jų gėda, bet ką daryti? Tai mūsų viena svetainė. PHP 7 yra svetainių ir paslaugų, jų yra daugiau, mes jų nesigėdime. Ir kiekvienas kūrėjas turi savo bazę, kurioje su malonumu pjauna.
Jei rašote įmonėje viena kalba, trys virtualios mašinos vienam kūrėjui skamba normaliai. Jei turite skirtingas programavimo kalbas, situacija pablogės.
Turite svetainių ir paslaugų apie tai, šioje, tada kitą svetainę, skirtą „Go“, vieną svetainę „Ruby“ ir kai kurias kitas Redis. Dėl to visa tai virsta dideliu paramos lauku ir visą laiką kai kas gali sulūžti.
Todėl programavimo kalbos pranašumus pakeitėme skirtingų karkasų naudojimu, nes PHP karkasai yra gana skirtingi, turi skirtingas galimybes, skirtingas bendruomenes ir skirtingą palaikymą. Ir tu gali parašyti paslaugą, kad jau ką nors jai paruoštum.
Kiekviena tarnyba turi savo komandą
Pagrindinis mūsų privalumas, išsikristalizavęs per kelerius metus, – kiekviena tarnyba turi savo komandą. Tai patogu dideliam projektui, sutaupysite laiko dokumentacijai, vadovai gerai išmano savo projektą.
Galite lengvai pateikti užduotis iš palaikymo tarnybos. Pavyzdžiui, sugedo draudimo paslauga. Ir iškart su draudimu užsiimanti komanda eina taisyti.
Greitai kuriamos naujos funkcijos, nes turint vieną atominę paslaugą greitai galima ką nors įsukti.
O kai nutraukiate savo paslaugą, ir tai neišvengiamai atsitinka, jūs nepaveikėte kitų žmonių paslaugų, o kūrėjai, turintys bitų iš kitų komandų, nebėga prie jūsų ir nesako: „O, nedaryk to“.
Kaip visada, yra niuansų. Turime stabilias komandas, vadovai yra prikaustyti prie komandos. Yra aiškūs dokumentai, vadovai viską atidžiai stebi. Kiekviena komanda su vadovu turi keletą paslaugų, yra tam tikras kompetencijos taškas.
Jei komandos plūduriuoja (taip pat kartais naudojame), yra geras metodas, vadinamas „žvaigždžių žemėlapiu“.
Turite paslaugų ir žmonių sąrašą. Žvaigždutė reiškia, kad asmuo yra šios paslaugos ekspertas, knyga reiškia, kad asmuo studijuoja šią paslaugą. Žmogaus užduotis yra iškeisti knygą į žvaigždutę. Ir jei prieš tarnybą nieko neparašyta, tada prasideda problemos, apie kurias kalbėsiu toliau.
Kaip atsiranda našlaičių paslaugos?
Pirma problema, pirmasis būdas gauti našlaičių paslaugą savo infrastruktūroje yra atleisti žmones. Ar kas nors kada nors laikėsi verslo terminų prieš vertinant užduotis? Kartais nutinka taip, kad terminai įtempti, o dokumentams tiesiog pritrūksta laiko. "Turime perduoti paslaugą gamybai, tada mes ją pridėsime."
Jei kolektyvas mažas, būna, kad yra vienas kūrėjas, kuris viską rašo, likusieji yra ant sparnų. "Aš parašiau pagrindinę architektūrą, pridėkime sąsajas." Tada kažkuriuo metu, pavyzdžiui, vadovas išeina. O šiuo laikotarpiu, kai vadovas išėjo, o naujas dar nepaskirtas, kūrėjai patys nusprendžia, kur ta paslauga keliauja ir kas ten vyksta. Ir kaip žinome (grįžkime keliomis skaidrėmis), kai kuriose komandose yra snaigių žmonės, kartais vadovauja snaigių komanda. Tada jis pasitraukia, ir mes gauname našlaičių paslaugą.
Tuo pačiu metu užduotys iš paramos ir verslo neišnyksta; Jei kuriant paslaugą buvo kokių nors architektūrinių klaidų, jos taip pat patenka į atsilikimą. Paslauga pamažu prastėja.
Kaip atpažinti našlaitį?
Šis sąrašas gerai apibūdina situaciją. Kas ką nors sužinojo apie savo infrastruktūrą?
Apie dokumentais pagrįstus sprendimus: yra paslauga ir apskritai ji veikia, yra dviejų puslapių vadovas, kaip su juo dirbti, bet niekas nežino, kaip tai veikia viduje.
Arba, pavyzdžiui, yra koks nors nuorodų sutrumpinimas. Pavyzdžiui, šiuo metu skirtingose paslaugose skirtingiems tikslams naudojame tris nuorodų trumpiklius. Tai tik pasekmės.
Dabar aš būsiu akivaizdžių dalykų kapitonas. Ką reikėtų daryti? Pirmiausia turime perduoti paslaugą kitam vadovui, kitai komandai. Jei jūsų komandos vadovas dar nepasitraukė, tada į kitą komandą, kai suprantate, kad paslauga yra kaip našlaitis, turite įtraukti žmogų, kuris bent ką apie tai supranta.
Svarbiausia: perkėlimo procedūros turi būti surašytos krauju. Mūsų atveju dažniausiai tai stebiu, nes man viso to reikia, kad veiktų. Vadovams reikia, kad jis būtų pristatytas greitai, o tai, kas atsitiks vėliau, jiems nebe taip svarbu.
Kitas būdas padaryti našlaitį yra „Padarysime tai iš išorės, bus greičiau, o tada perduosime komandai“. Aišku, kad visi turi kažkokių planų komandoje, posūkį. Dažnai verslo klientas mano, kad užsakovas darys tą patį, ką turi įmonės techninis skyrius. Nors jų motyvatoriai skirtingi. Užsakomųjų paslaugų srityje yra keistų technologinių sprendimų ir keistų algoritminių sprendimų.
Pavyzdžiui, mes turėjome servisą, kuriame Sfinksas buvo įvairiose netikėtose vietose. Vėliau pasakysiu, ką turėjau daryti.
Užsakovai turi savarankiškai parašytas sistemas. Tai tik plikas PHP su kopijavimu ir įklijavimu iš ankstesnio projekto, kuriame galite rasti įvairiausių dalykų. Diegimo scenarijai yra didelis trūkumas, kai reikia naudoti sudėtingus „Bash“ scenarijus, kad pakeistumėte kelias eilutes tam tikrame faile, o šie diegimo scenarijai iškviečiami kokiu nors trečiuoju scenarijumi. Dėl to jūs pakeičiate diegimo sistemą, pasirenkate ką nors kita, šokinėjate, bet jūsų paslauga neveikia. Nes ten reikėjo įdėti dar 8 nuorodas tarp skirtingų aplankų. Arba būna, kad tūkstantis įrašų veikia, o šimtas tūkstančių nebeveikia.
Aš ir toliau dirbsiu kapitonu. Užsakomosios paslaugos priėmimas yra privaloma procedūra. Ar kam nors buvo atvežta išorinė paslauga ir niekur nebuvo priimtas? Tai, žinoma, nėra tokia populiari kaip našlaičių paslauga, bet vis tiek.
Reikia patikrinti paslaugą, peržiūrėti paslaugą, keisti slaptažodžius. Turėjome atvejį, kai mums suteikė paslaugą, yra administratoriaus skydelis „if login == 'admin' && password == 'admin'...“, tai parašyta tiesiai kode. Mes sėdime ir galvojame, o žmonės tai rašo 2018 m.?
Atminties talpos testavimas taip pat būtinas dalykas. Reikia pažiūrėti, kas atsitiks su šimtu tūkstančių įrašų, dar prieš kur nors pradėdami gaminti šią paslaugą.
Neturėtų būti gėda siųsti paslaugą tobulinti. Kai sakote: „Nepriimsime šios paslaugos, turime 20 užduočių, atlikite jas, tada priimsime“, tai normalu. Sąžinės neturėtų skaudėti dėl to, kad steigiate vadovą ar verslas švaisto pinigus. Tada verslas išleis daugiau.
Turėjome atvejį, kai nusprendėme bandomąjį projektą perduoti iš išorės.
Jis buvo pristatytas laiku, ir tai buvo vienintelis kokybės kriterijus. Štai kodėl mes sukūrėme kitą bandomąjį projektą, kuris jau net nebuvo bandomasis. Šios paslaugos buvo priimtos ir administracinėmis priemonėmis pasakė: čia jūsų kodas, čia komanda, čia jūsų vadovas. Paslaugos iš tikrųjų jau pradėjo nešti pelną. Tuo pačiu metu iš tikrųjų jie vis dar yra našlaičiai, niekas nesupranta, kaip jie dirba, o vadovai daro viską, kad išsižadėtų savo užduočių.
Yra dar viena puiki koncepcija – partizanų plėtra. Kai koks nors skyrius, dažniausiai rinkodaros skyrius, nori patikrinti hipotezę ir užsako visą paslaugą perduoti iš išorės. Į jį pradeda plūsti eismas, jie uždaro dokumentus, pasirašo dokumentus su rangovu, pradeda eksploatuoti ir sako: „Bendrai, mes čia turime servisą, jau turi eismą, atneša mums pinigų, priimkime“. Mes sakėme: „Oppa, kaip tai gali būti“.
Ir dar vienas būdas gauti našlaičių paslaugą: kai kuri nors komanda staiga tampa perkrauta, vadovybė sako: „Perkelkime šios komandos paslaugą kitai komandai, ji turi mažesnę apkrovą“. Tada mes perkelsime jį į trečią komandą ir pakeisime vadovą. Ir galiausiai vėl turime našlaitį.
Kokios problemos su našlaičiais?
Kas nežino, tai Švedijoje iškeltas karo laivas Wasa, garsėjantis tuo, kad nuskendo praėjus 5 minutėms po paleidimo. O Švedijos karalius, beje, niekam už tai neįvykdė mirties bausmės. Jį pastatė dvi inžinierių kartos, kurios nemokėjo statyti tokių laivų. Natūralus efektas.
Laivas galėjo nuskęsti, beje, daug blogiau, pavyzdžiui, kai karalius juo jau plaukė kur nors per audrą. Ir taip, jis nuskendo iš karto, anot Agile, gerai, kad nepavyks anksti.
Jei nepasiseka anksti, dažniausiai problemų nebūna. Pavyzdžiui, priėmimo metu jis buvo išsiųstas peržiūrėti. Bet jei nepavyks jau gamyboje, kai investuojami pinigai, tada gali kilti problemų. Pasekmės, kaip jos vadinamos versle.
Kodėl našlaičių paslaugos yra pavojingos:
- Paslauga gali staiga nutrūkti.
- Serviso remontas trunka ilgai arba visai neremontuojamas.
- Saugumo problemos.
- Problemos dėl patobulinimų ir atnaujinimų.
- Sugedus svarbiai paslaugai, nukenčia įmonės reputacija.
Ką daryti su našlaičių paslaugomis?
Dar kartą pakartosiu, ką daryti. Pirma, turi būti dokumentai. 7 metai Banki.ru mane išmokė, kad bandytojai neturėtų perimti kūrėjų žodžio, o operacijos – ne visų. Turime patikrinti.
Antra, būtina rašyti sąveikos diagramas, nes pasitaiko, kad nelabai gerai priimamos paslaugos turi priklausomybių, apie kurias niekas nesakė. Pavyzdžiui, kūrėjai įdiegė paslaugą savo rakte į kai kuriuos „Yandex.Maps“ arba „Dadata“. Išnaudojote laisvą limitą, viskas sulaužyta ir visiškai nežinote, kas atsitiko. Visi tokie grėbliai turi būti aprašyti: paslauga naudoja Dadata, SMS, dar kažką.
Trečia, darbas su technine skola. Kai darai kokius nors ramentus ar priimi paslaugą ir sakai, kad reikia kažką daryti, reikia įsitikinti, kad tai padaryta. Nes tada gali pasirodyti, kad ta maža skylutė ne tokia ir maža, ir tu pro ją iškrisi.
Su architektūrinėmis užduotimis turėjome istoriją apie Sfinksą. Viena iš paslaugų naudojo Sfinksą sąrašams įvesti. Tik puslapių sąrašas, bet kiekvieną vakarą jis buvo indeksuojamas iš naujo. Jis buvo surinktas iš dviejų indeksų: kas vakarą buvo indeksuojamas vienas didelis, taip pat prie jo buvo prisukamas mažas indeksas. Kiekvieną dieną su 50% tikimybe, kad sprogs arba ne, indeksas suduždavo skaičiavimo metu, o mūsų naujienos nustojo atnaujinamos pagrindiniame puslapyje. Iš pradžių indeksą perindeksuoti prireikė 5 minučių, paskui indeksas augo, o kažkuriuo momentu perindeksuoti pradėjo 40 minučių. Kai tai iškirpome, lengviau atsidusome, nes buvo aišku, kad praeis šiek tiek daugiau laiko ir mūsų indeksas bus perindeksuojamas visą darbo dieną. Tai bus mūsų portalo nesėkmė, aštuonias valandas nėra jokių naujienų - viskas, verslas sustojo.
Planuokite dirbti su našlaičių tarnyba
Tiesą sakant, tai padaryti labai sunku, nes devops yra susijęs su bendravimu. Norite palaikyti gerus santykius su kolegomis, o kai trenkiate kolegoms ir vadovams per galvą reglamentais, jie gali turėti prieštaringų jausmų tiems, kurie tai daro.
Be visų šių punktų, yra dar vienas svarbus dalykas: už kiekvieną konkrečią paslaugą, už kiekvieną konkrečią diegimo procedūros dalį turi būti atsakingi konkretūs žmonės. Kai nėra žmonių ir reikia pritraukti kitus žmones, kad išstudijuotų visą šį reikalą, pasidaro sunku.
Jei visa tai nepadėjo, o jūsų našlaičių paslauga vis dar yra našlaitė, niekas nenori jos imtis, dokumentai nesurašyti, komanda, kuri buvo iškviesta į šią paslaugą, atsisako nieko daryti, yra paprastas būdas - perdaryti viskas .
Tai yra, jūs iš naujo paimate reikalavimus paslaugai ir rašote naują paslaugą, geresnę, geresnėje platformoje, be keistų technologinių sprendimų. Ir jūs migruojate į jį mūšyje.
Turėjome situaciją, kai pasinaudojome paslauga „Yii 1“ ir supratome, kad negalime jos toliau plėtoti, nes pritrūkome kūrėjų, galinčių gerai rašyti „Yii 1“. Visi kūrėjai gerai rašo „Symfony XNUMX“. Ką daryti? Paskirstėme laiką, paskyrėme komandą, paskyrėme vadovą, perrašėme projektą ir sklandžiai į jį perjungėme srautą.
Po to seną paslaugą galima ištrinti. Tai mano mėgstamiausia procedūra, kai reikia paimti ir išvalyti iš konfigūracijos valdymo sistemos kokią nors paslaugą ir tada pereiti ir pamatyti, kad visi gaminami automobiliai išjungti, kad kūrėjams neliktų pėdsakų. Saugykla lieka Git.
Tai viskas, apie ką norėjau kalbėti, esu pasiruošęs diskutuoti, tema yra holivaras, daugelis joje plaukė.
Skaidrėse buvo rašoma, kad suvienijate kalbas. Pavyzdys buvo nuotraukų dydžio keitimas. Ar tikrai reikia griežtai apsiriboti viena kalba? Nes vaizdo dydžio keitimas PHP, na, iš tikrųjų gali būti atliktas Golang.
Tiesą sakant, tai neprivaloma, kaip ir visos praktikos. Galbūt kai kuriais atvejais tai net nepageidautina. Bet reikia suprasti, kad jei turi techninį skyrių 50 žmonių įmonėje, iš kurių 45 yra PHP specialistai, dar 3 devopai, kurie žino Python, Ansible, Puppet ir kažką panašaus, ir tik vienas iš jų rašo kai kuriuose. „Go“ vaizdo dydžio keitimo paslauga. Ir tuo pačiu reikės ieškoti konkrečiai rinkai skirto kūrėjo, kuris mokėtų šią kalbą, ypač jei ji yra reta. Tai yra, organizaciniu požiūriu tai yra problematiška. Devops požiūriu jums nereikės tik klonuoti paruoštą žaidimų knygelių rinkinį, kurį naudojate paslaugoms diegti, bet ir rašyti juos iš naujo.
Šiuo metu kuriame paslaugą Node.js, ir tai bus tik šalia esanti platforma kiekvienam kūrėjui su atskira kalba. Bet mes sėdėjome ir manėme, kad žaidimas vertas žvakės. Tai yra, jums reikia sėdėti ir galvoti apie tai.
Kaip stebite savo paslaugas? Kaip renkate ir stebite žurnalus?
Mes renkame rąstus Elasticsearch ir dedame į Kibaną, o priklausomai nuo to, ar tai gamybinė, ar bandomoji aplinka, ten naudojami skirtingi rinktuvai. Kažkur Medkirtis, kitur dar kažkas, nepamenu. Ir dar yra kai kurios vietos tam tikrose servisuose, kur įdiegiame Telegrafą ir dar kur nors atskirai filmuojame.
Kaip gyventi su Puppet ir Ansible toje pačioje aplinkoje?
Tiesą sakant, dabar turime dvi aplinkas: viena yra „Lėlės“, kita – „Ansible“. Mes stengiamės juos hibridizuoti. Ansible yra gera pradinės sąrankos sistema, lėlė yra bloga pradinės sąrankos sistema, nes reikia praktinio darbo tiesiogiai platformoje, o „Lėlės“ užtikrina konfigūracijos konvergenciją. Tai reiškia, kad platforma palaiko naujausią būseną, o norint, kad atnaujinta mašina būtų nuolat atnaujinama, turite nuolat leisti joje tam tikrus dažnius. Tai ir skiriasi.
Kaip palaikote suderinamumą? Ar turite konfigūracijų ir Ansible, ir Puppet?
Tai yra mūsų didelis skausmas, mes palaikome suderinamumą rankomis ir galvojame, kaip dabar kur nors nuo viso to judėti. Pasirodo, kad Puppet išleidžia paketus ir ten palaiko kai kurias nuorodas, o, pavyzdžiui, Ansible išleidžia kodą ir ten koreguoja naujausias programų konfigūracijas.
Pristatymas buvo apie skirtingas Ruby versijas. Koks sprendimas?
Su tuo susidūrėme vienoje vietoje ir turime nuolat tai laikyti savo galvose. Mes paprasčiausiai išjungėme Ruby dalį, kuri buvo nesuderinama su programomis, ir palikome ją atskirai.
Šių metų konferencija gruodžio 7 dieną vyks Technopolyje. Prašymus ataskaitoms gauti priimame iki lapkričio 11 d. mums, jei norite pasikalbėti.
Dalyvių registracija atidaryta, prisijunk!
Šaltinis: www.habr.com