Direktor operacija portala Banki.ru Andrey Nikolsky govorio je na prošlogodišnjoj konferenciji o orphan uslugama: kako identificirati orphan usluge u infrastrukturi, zašto su orphan usluge loše, što učiniti s njima i što učiniti ako ništa ne pomaže.
Ispod reza nalazi se tekstualna verzija izvješća.
Pozdrav kolege! Moje ime je Andrey, vodim operacije u Banki.ru.
Imamo velike servise, to su tako monolitni servisi, ima servisa u nekom klasičnijem smislu, a ima i vrlo malih. Svojom radničko-seljačkom terminologijom kažem ako je usluga jednostavna i mala, onda je mikro, a ako nije baš jednostavna i mala, onda je samo usluga.
Prednosti usluga
Brzo ću proći kroz prednosti usluga.
Prvi je skaliranje. Možete brzo napraviti nešto na servisu i pokrenuti proizvodnju. Dobili ste promet, klonirali ste uslugu. Imate više prometa, klonirali ste ga i živite s njim. To je dobar bonus i, u principu, kad smo počinjali, smatralo nam se najvažnijim zašto sve ovo radimo.
Drugo, izolirani razvoj, kada imate nekoliko razvojnih timova, nekoliko različitih programera u svakom timu, a svaki tim razvija vlastitu uslugu.
Kod timova postoji nijansa. Programeri su različiti. A tu su npr. . Prvi put sam to vidio kod Maxima Dorofejeva. Ponekad su ljudi kao pahuljice u nekim timovima, a u drugima ne. Zbog toga su različite usluge koje se koriste u tvrtki pomalo neujednačene.
Pogledajte sliku: ovo je dobar programer, ima velike ruke, može puno. Glavni problem je odakle dolaze te ruke.
Usluge omogućuju korištenje različitih programskih jezika koji su prikladniji za različite zadatke. Neki servisi su u Gou, neki u Erlangu, neki u Rubyju, nešto u PHP-u, nešto u Pythonu. Općenito, možete se proširiti vrlo široko. I ovdje postoje nijanse.
Servisno orijentirana arhitektura prvenstveno se odnosi na devops. Odnosno, ako nemate automatizaciju, nema procesa implementacije, ako konfigurirate ručno, vaše se konfiguracije mogu mijenjati od instance usluge do instance, a vi morate ići tamo da nešto učinite, onda ste u paklu.
Na primjer, imate 20 servisa i morate ručno implementirati, imate 20 konzola, a istovremeno pritiskate “enter” kao nindža. Nije baš dobro.
Ako imate servis nakon testiranja (ako postoji testiranje, naravno), a još ga trebate doraditi s datotekom kako bi radio u produkciji, također imam loše vijesti za vas.
Ako se oslanjate na specifične usluge Amazona i radite u Rusiji, onda ste prije dva mjeseca također imali "Sve okolo gori, ja sam dobro, sve je cool."
Koristimo Ansible za automatizaciju implementacije, Puppet za konvergenciju, Bamboo za automatizaciju implementacije i Confluence da nekako sve to opišemo.
O tome se neću detaljnije zadržavati jer se izvješće više odnosi na praksu interakcije, a ne na tehničku implementaciju.
Na primjer, imali smo problema kada Puppet na poslužitelju radi s Ruby 2, ali neka je aplikacija napisana za Ruby 1.8 i ne rade zajedno. Nešto tu nije u redu. A kada trebate pokrenuti više verzija Rubyja na jednom računalu, obično počnete imati problema.
Recimo, svakom developeru damo platformu na kojoj je otprilike sve što mi imamo, svi servisi koji se mogu razvijati, tako da ima izolirano okruženje, može ga razbijati i graditi kako hoće.
Dešava se da trebate neki posebno kompilirani paket s podrškom za nešto tamo. Prilično je teško. Slušao sam izvještaj u kojem Docker slika teži 45 GB. U Linuxu je, naravno, jednostavnije, tamo je sve manje, ali ipak neće biti dovoljno prostora.
Pa, postoje sukobljene ovisnosti, kada jedan dio projekta ovisi o biblioteci jedne verzije, drugi dio projekta ovisi o drugoj verziji, a biblioteke uopće nisu instalirane zajedno.
Imamo stranice i usluge u PHP 5.6, sramimo ih se, ali što možemo? Ovo je naša jedina stranica. Ima stranica i servisa na PHP 7, ima ih još, ne sramimo ih se. I svaki programer ima svoju bazu u kojoj rado pili.
Ako u tvrtki pišete na jednom jeziku, onda tri virtualna stroja po programeru zvuči normalno. Ako imate različite programske jezike, onda se situacija pogoršava.
Imate stranice i usluge na ovom, na ovom, zatim još jedno mjesto za Go, jedno mjesto za Ruby i neki drugi Redis sa strane. Kao rezultat, sve se to pretvara u veliko polje za potporu, a cijelo vrijeme se nešto od toga može slomiti.
Stoga smo prednosti programskog jezika zamijenili upotrebom različitih okvira, budući da su PHP okviri prilično različiti, imaju drugačije mogućnosti, različite zajednice i drugačiju podršku. A možete napisati uslugu tako da već imate nešto spremno za nju.
Svaka služba ima svoj tim
Naša glavna prednost, koja se iskristalizirala kroz nekoliko godina, je što svaka služba ima svoj tim. Ovo je zgodno za veliki projekt, možete uštedjeti vrijeme na dokumentaciji, menadžeri dobro poznaju svoj projekt.
Možete jednostavno poslati zadatke iz podrške. Na primjer, pokvarila se služba osiguranja. I odmah ekipa koja se bavi osiguranjem ide to popraviti.
Nove značajke se brzo stvaraju, jer kada imate jednu atomičnu uslugu, možete brzo nešto zeznuti u nju.
A kada prekinete svoju uslugu, a to se neizbježno događa, niste utjecali na usluge drugih ljudi, a programeri iz drugih timova vam ne dotrče s komadićima i kažu: "Aj-aj, nemoj to raditi."
Kao i uvijek, postoje nijanse. Imamo stabilne momčadi, menadžeri su prikovani za momčad. Postoje jasni dokumenti, menadžeri sve pomno prate. Svaki tim s voditeljem ima nekoliko službi, a postoji i određena točka kompetencije.
Ako su timovi plutajući (ovo ponekad koristimo), postoji dobra metoda koja se zove "zvjezdana karta".
Imate popis usluga i ljudi. Zvjezdica znači da je osoba stručnjak za ovu uslugu, knjiga znači da osoba studira ovu uslugu. Zadatak osobe je promijeniti knjižicu za zvjezdicu. A ako ništa nije napisano ispred usluge, tada počinju problemi, o kojima ću dalje govoriti.
Kako se pojavljuju usluge siročadi?
Prvi problem, prvi način da dobijete uslugu siroče u svojoj infrastrukturi je otpuštanje ljudi. Je li ikome ikada poduzeće poštivalo rokove prije nego što su zadaci ocijenjeni? Ponekad se dogodi da su rokovi tijesni i jednostavno nema dovoljno vremena za dokumentaciju. "Moramo predati uslugu proizvodnji, a zatim ćemo je dodati."
Ako je tim mali, dogodi se da postoji jedan programer koji sve napiše, ostali su na čekanju. "Napisao sam osnovnu arhitekturu, dodajmo sučelja." Onda u nekom trenutku menadžer, na primjer, ode. I tijekom tog razdoblja, kada je upravitelj otišao, a novi još nije imenovan, programeri sami odlučuju kamo ide usluga i što se tamo događa. A kao što znamo (vratimo se nekoliko slajdova unatrag), u nekim timovima postoje ljudi pahuljice, ponekad vođa tima pahuljica. Onda on da otkaz, a mi dobijemo službu za siročad.
Istovremeno, zadaci iz podrške i iz poslovanja ne nestaju, oni završavaju u zaostatku. Ako je tijekom razvoja usluge bilo arhitektonskih grešaka, one također završavaju u zaostatku. Usluga polako propada.
Kako prepoznati siroče?
Ovaj popis dobro opisuje situaciju. Tko je išta naučio o njihovoj infrastrukturi?
O dokumentiranim zaobilaznim rješenjima: postoji servis i, općenito, radi, ima priručnik na dvije stranice o tome kako raditi s njim, ali nitko ne zna kako radi unutra.
Ili, na primjer, postoji neka vrsta skraćivača veza. Na primjer, trenutno imamo tri skraćivača veza u upotrebi za različite svrhe u različitim uslugama. Ovo su samo posljedice.
Sada ću ja biti kapetan očitog. Što treba učiniti? Prvo, moramo prenijeti uslugu na drugog menadžera, drugi tim. Ako vaš teamlead još nije odustao, onda u ovaj drugi tim, kad shvatite da je služba kao siroče, trebate uključiti nekoga tko se u nju bar nešto razumije.
Glavna stvar: procedure prijenosa morate imati napisane krvlju. U našem slučaju, ja to obično pratim, jer mi je potrebno da sve to radi. Menadžerima je potrebno da se to brzo isporuči, a što će se kasnije dogoditi s njim više im nije toliko važno.
Sljedeći način da napravite siročeta je "Učinit ćemo to vanjskim izvođačima, bit će brže, a onda ćemo to predati timu." Jasno je da svatko ima neke planove u momčadi, zaokret. Često poslovni kupac misli da će vanjski naručitelj raditi isto što i tehnički odjel koji tvrtka ima. Iako su im motivatori različiti. U outsourcingu postoje čudna tehnološka rješenja i čudna algoritamska rješenja.
Na primjer, imali smo uslugu koja je imala Sphinx na raznim neočekivanim mjestima. Kasnije ću ti reći što sam morao učiniti.
Vanjski izvođači imaju okvire koje su sami napisali. Ovo je samo goli PHP s copy-pasteom iz prethodnog projekta, gdje možete pronaći svašta. Skripte za implementaciju veliki su nedostatak kada trebate koristiti neke složene Bash skripte za promjenu nekoliko redaka u nekoj datoteci, a te skripte za implementaciju poziva neka treća skripta. Kao rezultat toga, promijenite sustav implementacije, odaberete nešto drugo, hop, ali vaša usluga ne radi. Jer tamo je bilo potrebno staviti još 8 poveznica između različitih mapa. Ili se dogodi da tisuću ploča radi, a sto tisuća više ne radi.
I dalje ću biti kapetan. Prihvaćanje vanjske usluge obavezan je postupak. Je li ikome ikad stigla vanjska služba i nigdje je nisu primili? Ovo, naravno, nije toliko popularno kao usluga siročadi, ali ipak.
Servis treba provjeriti, servis treba pregledati, lozinke treba promijeniti. Imali smo slučaj kada su nam dali uslugu, postoji administratorska ploča “if login == 'admin' && password == 'admin'...”, piše točno u kodu. Sjedimo i razmišljamo, a ljudi ovo pišu u 2018. godini?
Ispitivanje skladišnog kapaciteta također je neophodna stvar. Trebate pogledati što će se dogoditi na sto tisuća zapisa, čak i prije nego što ovu uslugu negdje pustite u produkciju.
Ne bi trebalo biti sramota poslati uslugu na poboljšanje. Kada kažete: “Nećemo prihvatiti ovu uslugu, imamo 20 zadataka, obavite ih, onda ćemo prihvatiti”, to je normalno. Ne treba vas gristi savjest što postavljate upravitelja ili što posao baca novac. Posao će tada trošiti više.
Imali smo slučaj kada smo pilot projekt odlučili prepustiti vanjskim suradnicima.
Isporučen je na vrijeme i to je bio jedini kriterij kvalitete. Zato smo napravili još jedan pilot projekt, koji zapravo više i nije bio pilot. Te usluge su prihvaćene, administrativnim putem su rekli, evo vam šifra, evo tima, evo vam menadžera. Usluge su zapravo već počele donositi profit. U isto vrijeme, zapravo, oni su još uvijek siročad, nitko ne razumije kako rade, a menadžeri se svim silama odriču svojih zadataka.
Postoji još jedan sjajan koncept - gerilski razvoj. Kada neki odjel, obično odjel marketinga, želi testirati hipotezu i naruči cjelokupnu uslugu outsourcingu. U njega se počne slijevati promet, oni zatvore dokumente, potpišu dokumente s izvođačem, uđu u pogon i kažu: “Ljudi, imamo servis ovdje, već ima promet, donosi nam novac, ajmo to prihvatiti.” Rekli smo, "Opa, kako to može biti."
I još jedan način da dobijete uslugu siroče: kada se neki tim iznenada nađe opterećen, uprava kaže: "Prenesimo uslugu ovog tima na drugi tim, ima manje opterećenja." A onda ćemo to prebaciti u treću momčad i promijeniti menadžera. I na kraju opet imamo siroče.
Koji je problem sa siročadi?
Tko ne zna, ovo je bojni brod Wasa podignut u Švedskoj, poznat po tome što je potonuo 5 minuta nakon porinuća. A švedski kralj, usput, nije nikoga pogubio zbog toga. Gradile su ga dvije generacije inženjera koji nisu znali graditi takve brodove. Prirodni učinak.
Lađa je, inače, mogla potonuti i na puno gori način, na primjer, kad se kralj već vozio na njoj negdje po oluji. I tako, odmah se utopio, prema Agileu dobro je rano propasti.
Ako rano ne uspijemo, obično nema problema. Na primjer, tijekom prihvaćanja poslan je na reviziju. Ali ako podbacimo već u proizvodnji, kad je novac uložen, onda može biti problema. Posljedice, kako se u poslu zovu.
Zašto su usluge siročadi opasne:
- Usluga se može iznenada prekinuti.
- Servis se dugo popravlja ili se uopće ne popravlja.
- Sigurnosni problemi.
- Problemi s poboljšanjima i ažuriranjima.
- Ako se neka važna usluga pokvari, trpi ugled tvrtke.
Što učiniti s uslugama siročadi?
Ponovit ću što treba učiniti. Prvo, mora postojati dokumentacija. 7 godina na Banki.ru naučilo me da testeri ne smiju vjerovati programerima na riječ, a da operacije ne smiju vjerovati svima na riječ. Moramo provjeriti.
Drugo, potrebno je napisati dijagrame interakcije, jer se događa da servisi koji nisu baš dobro prihvaćeni sadrže ovisnosti o kojima nitko nije govorio. Na primjer, programeri su instalirali uslugu na svoj ključ za neke Yandex.Maps ili Dadata. Ponestalo vam je besplatnog limita, sve je pokvareno, a vi uopće ne znate što se dogodilo. Sve takve grablje moraju biti opisane: usluga koristi Dadata, SMS, nešto drugo.
Treće, rad s tehničkim dugom. Kad radite nekakve štake ili prihvatite uslugu i kažete da nešto treba učiniti, morate se pobrinuti da se to i učini. Jer tada se može pokazati da mala rupa i nije tako mala, pa ćete propasti kroz nju.
Uz arhitektonske zadatke imali smo priču o Sfingi. Jedan od servisa koristio je Sphinx za unos popisa. Samo paginiran popis, ali se ponovno indeksirao svake večeri. Sastavljen je od dva indeksa: jedan veliki se indeksirao svake večeri, a tu je bio i mali indeks koji je bio pričvršćen na njega. Svaki dan, s 50% vjerojatnosti bombardiranja ili ne, indeks se srušio tijekom izračuna, a naše vijesti su se prestale ažurirati na glavnoj stranici. Isprva je bilo potrebno 5 minuta da se ponovno indeksira, zatim je indeks rastao, au nekom trenutku počelo je trajati 40 minuta za ponovno indeksiranje. Kad smo ovo izbacili, odahnuli smo, jer je bilo jasno da će proći još malo vremena i da će naš indeks biti reindeksiran puno radno vrijeme. Ovo će biti promašaj za naš portal, osam sati nema vijesti – to je to, posao je stao.
Plan rada s uslugom siročadi
Zapravo, to je vrlo teško učiniti, jer devops je komunikacija. Želite biti u dobrim odnosima sa svojim kolegama, a kada se kolegama i menadžerima lupite po glavi propisima, oni mogu imati proturječne osjećaje prema ljudima koji to rade.
Uz sve ove točke, postoji još jedna važna stvar: za svaku pojedinu uslugu, za svaki pojedini dio postupka raspoređivanja moraju biti odgovorni određeni ljudi. Kada nema ljudi i morate privući neke druge ljude da proučavaju cijelu tu stvar, to postaje teško.
Ako sve ovo nije pomoglo, a vaša orphan usluga je i dalje siroče, nitko je ne želi preuzeti, dokumentacija nije napisana, tim koji je pozvan u ovu uslugu odbija učiniti bilo što, postoji jednostavan način - ponoviti sve .
Odnosno, iznova uzmete zahtjeve za uslugu i napišete novu uslugu, bolju, na boljoj platformi, bez čudnih tehnoloških rješenja. I migrirate na njega u borbi.
Imali smo situaciju kada smo uzeli uslugu na Yii 1 i shvatili da je ne možemo dalje razvijati, jer nam je ponestalo programera koji bi mogli dobro pisati na Yii 1. Svi programeri dobro pišu na Symfony XNUMX. Što uraditi? Dodijelili smo vrijeme, dodijelili tim, dodijelili menadžera, prepisali projekt i glatko prebacili promet na njega.
Nakon toga, stara usluga se može izbrisati. Ovo mi je najdraži postupak, kada trebate uzeti i očistiti neki servis iz sustava za upravljanje konfiguracijom i onda proći i vidjeti da su svi automobili u proizvodnji onemogućeni, tako da programerima ne ostanu nikakvi tragovi. Repozitorij ostaje u Gitu.
Ovo je sve o čemu sam htio razgovarati, spreman sam razgovarati, tema je holivar, mnogi su plivali u njoj.
Slajdovi govore da ste ujedinili jezike. Primjer je bilo mijenjanje veličine slika. Je li ga doista potrebno striktno ograničiti na jedan jezik? Budući da se promjena veličine slike u PHP-u zapravo može učiniti u Golangu.
Zapravo, to je izborno, kao i sve prakse. Možda je u nekim slučajevima čak i nepoželjno. Ali morate shvatiti da ako imate tehnički odjel u tvrtki od 50 ljudi, 45 od njih su PHP stručnjaci, još 3 su devops koji znaju Python, Ansible, Puppet i nešto slično, a samo jedan od njih piše na nekom neka vrsta jezika. neka Go usluga za promjenu veličine slike, a kad ode, stručnost ide s njom. U isto vrijeme, morat ćete potražiti programera prilagođenog tržištu koji poznaje ovaj jezik, pogotovo ako je rijedak. Odnosno, organizacijski gledano, ovo je problematično. S devops točke gledišta, nećete trebati samo klonirati neki gotov skup priručnika koje koristite za implementaciju usluga, već ćete ih morati napisati iznova.
Trenutno gradimo uslugu na Node.js, a to će biti samo platforma u blizini za svakog programera sa zasebnim jezikom. Ali sjedili smo i mislili da je igra bila vrijedna svijeće. Odnosno, ovo je pitanje za vas da sjednete i razmislite.
Kako nadzirete svoje usluge? Kako prikupljate i pratite zapisnike?
Prikupljamo logove u Elasticsearchu i stavljamo ih u Kibanu, a ovisno o tome radi li se o proizvodnim ili testnim okruženjima, tamo se koriste različiti kolektori. Negdje Drvosječa, negdje drugo nešto drugo, ne sjećam se. I još uvijek postoje neka mjesta u određenim servisima gdje instaliramo Telegraf i snimamo negdje drugdje zasebno.
Kako živjeti s Puppetom i Ansibleom u istom okruženju?
Zapravo, sada imamo dva okruženja, jedno je Puppet, drugo je Ansible. Radimo na njihovoj hibridizaciji. Ansible je dobar okvir za početno postavljanje, Puppet je loš okvir za početno postavljanje jer zahtijeva praktičan rad izravno na platformi, a Puppet osigurava konvergenciju konfiguracije. To znači da se platforma održava u ažurnom stanju, a kako bi ansibilizirani stroj bio ažuran, morate na njemu stalno pokretati knjige s igrama s određenom učestalošću. To je razlika.
Kako održavate kompatibilnost? Imate li konfiguracije i za Ansible i za Puppet?
To je naša velika boljka, rukama održavamo kompatibilnost i razmišljamo kako sada negdje krenuti iz svega ovoga. Ispada da Puppet izbacuje pakete i tamo održava neke veze, a Ansible, na primjer, izbacuje kod i tamo prilagođava najnovije konfiguracije aplikacije.
Prezentacija je bila o različitim verzijama Rubyja. Koje rješenje?
S tim smo se susreli na jednom mjestu, a to stalno moramo imati u glavi. Jednostavno smo isključili dio koji je radio na Rubyju koji nije bio kompatibilan s aplikacijama i držali ga odvojenim.
Ovogodišnja konferencija održat će se 7. prosinca u Technopolisu. Prijave za izvješća primamo do 11. studenog. nas ako želite govoriti.
Prijave za sudionike su otvorene, pridružite nam se!
Izvor: www.habr.com