Direktor operacija portala Banki.ru Andrej Nikolski govorio je na prošlogodišnjoj konferenciji o uslugama siročadi: kako identificirati siroče u infrastrukturi, zašto su usluge siročad loše, šta učiniti s njima i šta učiniti ako ništa ne pomogne.
Ispod reza je tekstualna verzija izvještaja.
Zdravo kolege! Zovem se Andrej, vodim operacije u Banki.ru.
Imamo velike servise, to su takve monolitne usluge, postoje usluge u klasičnijem smislu, a ima i vrlo malih. U svojoj radničko-seljačkoj terminologiji kažem da 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. Primili ste saobraćaj, klonirali ste uslugu. Imate više prometa, klonirali ste ga i živite s tim. Ovo je dobar bonus i, u principu, kada smo počinjali, smatralo se da nam je najvažnije zašto sve ovo radimo.
Drugo, izolirani razvoj, kada imate nekoliko razvojnih timova, nekoliko različitih programera u svakom timu, i svaki tim razvija vlastitu uslugu.
Kod timova postoji nijansa. Programeri su različiti. A postoje npr. . Prvi put sam ovo video kod Maksima Dorofejeva. Ponekad su ljudi sa pahuljicama u nekim timovima, a ne u drugim. To čini različite usluge koje se koriste u cijeloj kompaniji pomalo neujednačenim.
Pogledajte sliku: ovo je dobar programer, ima velike ruke, može mnogo. Glavni problem je odakle dolaze ove ruke.
Usluge omogućavaju korištenje različitih programskih jezika koji su pogodniji za različite zadatke. Neki servisi su u Go, neki u Erlangu, neki u Rubyju, nešto u PHP-u, nešto u Pythonu. Općenito, možete se vrlo široko proširiti. I ovdje ima nijansi.
Servisno orijentisana arhitektura se prvenstveno odnosi na devops. Odnosno, ako nemate automatizaciju, nema procesa implementacije, ako ga konfigurirate ručno, vaše konfiguracije se mogu mijenjati od instance usluge do instance, i morate otići tamo da nešto učinite, onda ste u paklu.
Na primjer, imate 20 servisa i morate ih implementirati ručno, imate 20 konzola i istovremeno pritiskate “enter” kao nindža. Nije baš dobro.
Ako imate servis nakon testiranja (ako postoji testiranje, naravno), a još ga trebate završiti sa fajlom da bi radio u produkciji, imam i loše vijesti za vas.
Ako se oslanjate na određene Amazonove usluge i radite u Rusiji, onda ste prije dva mjeseca imali i „Sve okolo gori, dobro sam, sve je u redu“.
Koristimo Ansible za automatizaciju implementacije, Puppet za konvergenciju, Bamboo za automatizaciju implementacije i Confluence da nekako sve to opišemo.
Neću se detaljnije zadržavati na ovome, jer je izvještaj više o praksi interakcije, a ne o tehničkoj implementaciji.
Na primjer, imali smo problema gdje Puppet na serveru radi sa Ruby 2, ali neke aplikacije su napisane za Ruby 1.8, a one ne rade zajedno. Tu nešto krene po zlu. A kada trebate pokrenuti više verzija Ruby-a na jednoj mašini, obično počinjete da imate problema.
Na primjer, svakom developeru damo platformu na kojoj se nalazi otprilike sve što mi imamo, svi servisi koji se mogu razviti, tako da on ima izolirano okruženje, može ga razbiti i izgraditi kako želi.
Dešava se da vam treba neki posebno kompajlirani paket sa podrškom za nešto tamo. Prilično je teško. Slušao sam izvještaj u kojem Docker slika ima 45 GB. U Linuxu je, naravno, jednostavnije, tamo je sve manje, ali ipak neće biti dovoljno prostora.
Pa, postoje konfliktne zavisnosti, kada jedan deo projekta zavisi od biblioteke jedne verzije, drugi deo projekta zavisi od druge verzije, a biblioteke se uopšte ne instaliraju zajedno.
Imamo sajtove i servise u PHP 5.6, stidimo ih se, ali šta da radimo? Ovo je naša jedna stranica. Postoje sajtovi i servisi na PHP 7, ima ih više, ne stidimo ih se. I svaki programer ima svoju bazu u kojoj rado pili.
Ako pišete u kompaniji na jednom jeziku, tri virtuelne mašine po programeru zvuči normalno. Ako imate različite programske jezike, onda se situacija pogoršava.
Imate sajtove i servise na ovom, na ovome, zatim još jednu lokaciju za Go, jednu lokaciju za Ruby i još neki Redis sa strane. Kao rezultat, sve se to pretvara u veliko polje za podršku, a cijelo vrijeme se nešto od toga može slomiti.
Stoga smo prednosti programskog jezika zamenili upotrebom različitih okvira, pošto su PHP okviri prilično različiti, imaju različite mogućnosti, različite zajednice i različitu 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 iskristalisala kroz nekoliko godina, je što svaki servis ima svoj tim. Ovo je zgodno za veliki projekat, možete uštedjeti vrijeme na dokumentaciji, menadžeri dobro poznaju svoj projekt.
Možete lako poslati zadatke iz podrške. Na primjer, pokvarila se služba osiguranja. I odmah ekipa koja se bavi osiguranjem ide da to popravi.
Nove funkcije se stvaraju brzo, jer kada imate jedan atomski servis, možete brzo nešto uvrnuti u njega.
A kada pokvarite svoj servis, a to se neminovno dešava, niste uticali na tuđe usluge, a programeri iz drugih timova vam ne pritrčavaju sa komadićima i kažu: „Aj-aj, nemoj to da radiš“.
Kao i uvek, ima nijansi. Imamo stabilne timove, menadžeri su prikovani za tim. Postoje jasni dokumenti, menadžeri sve pomno prate. Svaki tim sa menadžerom ima nekoliko usluga, a postoji i određena tačka kompetencije.
Ako timovi plutaju (mi ponekad koristimo i ovo), postoji dobra metoda koja se zove “star mapa”.
Imate listu 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 da promijeni knjižicu za zvjezdicu. A ako ništa ne piše ispred servisa, onda počinju problemi o kojima ću dalje.
Kako se pojavljuju usluge siročadi?
Prvi problem, prvi način da dobijete uslugu siročad u vašoj infrastrukturi je otpuštanje ljudi. Da li je neko ikada imao posao da ispunjava rokove prije nego što su zadaci ocijenjeni? Ponekad se desi da su rokovi tijesni i jednostavno nema dovoljno vremena za dokumentaciju. "Moramo predati uslugu proizvodnji, a onda ćemo je dodati."
Ako je tim mali, dešava se da postoji jedan programer koji sve piše, ostali su u krilima. “Napisao sam osnovnu arhitekturu, dodajmo interfejse.” Onda u nekom trenutku menadžer, na primjer, odlazi. I tokom ovog perioda, kada je menadžer otišao, a novi još nije imenovan, programeri sami odlučuju kuda ide usluga i šta se tamo dešava. A kao što znamo (vratimo se nekoliko slajdova), u nekim timovima postoje ljudi pahuljica, ponekad i vođa tima pahulja. Onda on daje otkaz, a mi dobijamo uslugu siročadi.
Istovremeno, zadaci iz podrške i iz poslovanja ne nestaju, oni završavaju u zaostatku. Ako je bilo arhitektonskih grešaka tokom razvoja usluge, one također završavaju u zaostatku. Usluga se polako pogoršava.
Kako prepoznati siroče?
Ova lista dobro opisuje situaciju. Ko je išta naučio o njihovoj infrastrukturi?
O dokumentovanim zaobilaznicama: postoji usluga i, generalno, radi, ima priručnik od dvije stranice o tome kako se radi s njim, ali niko ne zna kako radi unutra.
Ili, na primjer, postoji neka vrsta skraćivača linkova. Na primjer, trenutno imamo tri skraćivača linkova koji se koriste za različite svrhe u različitim uslugama. Ovo su samo posledice.
Sada ću biti kapetan očiglednog. Šta treba učiniti? Prvo, trebamo prenijeti uslugu drugom menadžeru, drugom timu. Ako vaš timski vođa još nije dao otkaz, onda u ovaj drugi tim, kada shvatite da je usluga kao siroče, morate uključiti nekoga ko se barem nešto razumije u to.
Glavna stvar: morate imati krvlju ispisane procedure prijenosa. U našem slučaju to obično pratim, jer mi sve to treba da radi. Menadžerima je potrebno da se brzo isporuči, a ono što će se kasnije desiti za njih im više nije toliko važno.
Sljedeći način da napravite siroče je „Mi ćemo to učiniti vanjskim poduzećima, biće brže, a onda ćemo to predati timu“. Jasno je da svi imaju neke planove u timu, zaokret. Često poslovni kupac misli da će vanjski izvođač raditi isto što i tehničko odjeljenje koje kompanija ima. Iako su im motivatori različiti. U outsourcingu postoje čudna tehnološka rješenja i čudna algoritamska rješenja.
Na primjer, imali smo servis koji je imao Sfingu na raznim neočekivanim mjestima. Reći ću ti kasnije šta sam morao da uradim.
Autsorseri imaju okvire koji su sami napisali. Ovo je samo goli PHP sa copy-paste iz prethodnog projekta, gde možete pronaći razne stvari. Skripte za implementaciju su veliki nedostatak kada trebate koristiti neke složene Bash skripte da promijenite nekoliko redova u nekom fajlu, a te skripte za implementaciju poziva neka treća skripta. Kao rezultat toga, promijenite sistem implementacije, odaberete nešto drugo, skočite, ali vaša usluga ne radi. Jer tamo je bilo potrebno staviti još 8 linkova između različitih foldera. Ili se desi da hiljadu zapisa radi, a sto hiljada više ne radi.
Nastaviću kao kapetan. Prihvatanje eksterne usluge je obavezan postupak. Da li je nekome ikada stigla eksterna usluga, a da nije nigdje primljen? Ovo, naravno, nije toliko popularno kao usluga siročad, ali ipak.
Servis treba provjeriti, servis pregledati, lozinke promijeniti. Imali smo slučaj kada su nam dali uslugu, postoji admin panel “if login == 'admin' && password == 'admin'...”, to piše direktno u kodu. Sjedimo i razmišljamo, a ljudi ovo pišu u 2018?
Testiranje kapaciteta skladištenja je takođe neophodna stvar. Treba pogledati šta će se dogoditi na sto hiljada ploča, čak i prije nego što ovu uslugu negdje pustite u proizvodnju.
Ne bi trebalo biti sramota poslati uslugu radi poboljšanja. Kada kažete: „Nećemo prihvatiti ovu uslugu, imamo 20 zadataka, uradite ih, pa ćemo prihvatiti“, to je normalno. Vašu savjest ne bi trebalo povrijediti činjenica da postavljate menadžera ili da posao rasipa novac. Poslovanje će tada trošiti više.
Imali smo slučaj kada smo odlučili da eksternalizujemo pilot projekat.
Isporučeno je na vrijeme i to je bio jedini kriterij kvaliteta. Zato smo napravili još jedan pilot projekat, koji zapravo više nije bio ni pilot. Ove usluge su prihvaćene, a administrativnim putem su rekli, evo ti šifre, evo tima, evo ti menadžera. Usluge su zapravo već počele da zarađuju. Istovremeno, oni su, zapravo, još uvijek siročad, niko ne razumije kako rade, a menadžeri daju sve od sebe da se odreknu svojih zadataka.
Postoji još jedan sjajan koncept - razvoj gerile. Kada neki odjel, obično odjel marketinga, želi testirati hipotezu i naručiti cjelokupnu uslugu vanjskim suradnicima. Saobraćaj počinje da se uliva u njega, zatvaraju dokumente, potpisuju dokumente sa izvođačem radova, puštaju u rad i kažu: „Druže, imamo tu službu, već ima saobraćaja, donosi nam novac, hajde da prihvatimo“. Bili smo kao, "Opa, kako je to moguće."
I još jedan način da dobijete uslugu siroče: kada se neki tim iznenada nađe opterećen, uprava kaže: „Prebacimo uslugu ovog tima na drugi tim, on ima manje opterećenje.“ A onda ćemo to prebaciti u treći tim i promijeniti menadžera. I na kraju opet imamo siroče.
Šta je problem sa siročadi?
Ko ne zna, ovo je bojni brod Wasa podignut u Švedskoj, poznat po tome što je potonuo 5 minuta nakon porinuća. A kralj Švedske, inače, nije nikoga pogubio zbog toga. Izgradile su ga dvije generacije inženjera koji nisu znali kako da naprave takve brodove. Prirodni efekat.
Brod je mogao potonuti, inače, i na mnogo gori način, na primjer, kada se kralj već vozio na njemu negdje u oluji. I tako, on se odmah utopio, prema Agile-u je dobro propasti rano.
Ako ne uspijemo rano, obično nema problema. Na primjer, tokom prihvatanja poslat je na reviziju. Ali ako zakažemo već u proizvodnji, kada se uloži novac, onda može doći do problema. Posljedice, kako ih u poslu zovu.
Zašto su usluge siročadi opasne:
- Usluga se može iznenada prekinuti.
- Servisu je potrebno dosta vremena za popravku ili se uopće ne popravlja.
- Sigurnosni problemi.
- Problemi sa poboljšanjima i ažuriranjima.
- Ako se važna usluga pokvari, reputacija kompanije pati.
Šta učiniti sa uslugama siročadi?
Ponovit ću šta da radim ponovo. Prvo, mora postojati dokumentacija. 7 godina u Banki.ru me naučilo da testeri ne bi trebali vjerovati programerima, a operacije ne bi trebale vjerovati svima. Moramo provjeriti.
Drugo, potrebno je pisati dijagrame interakcije, jer se dešava da servisi koji nisu baš dobro primljeni sadrže zavisnosti o kojima niko nije rekao. Na primjer, programeri su instalirali uslugu na svoj ključ neke Yandex.Mape ili Data. Istekao si slobodan limit, sve je pokvareno, a ti uopće ne znaš šta se dogodilo. Sve takve grablje moraju biti opisane: servis koristi podatke, SMS, nešto drugo.
Treće, rad sa tehničkim dugom. Kada radite neku vrstu štaka ili prihvatite uslugu i kažete da nešto treba da se uradi, morate biti sigurni da je to učinjeno. Jer tada se može ispostaviti 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 lista. Samo lista sa stranicama, ali je ponovo indeksirana svake večeri. Sastavljen je od dva indeksa: jedan veliki indeksirao se svake večeri, a postojao je i mali indeks koji je bio pričvršćen na njega. Svaki dan, sa 50% vjerovatnoćom bombardovanja ili ne, indeks je padao tokom izračunavanja, a naše vijesti su prestajale da se ažuriraju na glavnoj stranici. Prvo je bilo potrebno 5 minuta da se indeks ponovo indeksira, zatim je indeks rastao, a u nekom trenutku je za ponovno indeksiranje počelo trebati 40 minuta. Kada smo ovo prekinuli, odahnuli smo, jer je bilo jasno da će proći još malo vremena i naš indeks će biti ponovo indeksiran u punom radnom vremenu. Ovo će biti promašaj za naš portal, osam sati nema vijesti - to je to, posao je stao.
Planirajte rad sa službom za siročad
Zapravo, to je vrlo teško učiniti, jer se devops odnosi na komunikaciju. Želite da budete u dobrim odnosima sa svojim kolegama, a kada svojim kolegama i menadžerima udarite preko glave propisima, oni mogu imati oprečna osećanja prema ljudima koji to rade.
Pored svih ovih tačaka, postoji još jedna važna stvar: određeni ljudi moraju biti odgovorni za svaku konkretnu uslugu, za svaki određeni dio procedure raspoređivanja. Kada nema ljudi, a morate privući neke druge ljude da prouče cijelu ovu stvar, postaje teško.
Ako sve ovo nije pomoglo, a vaš servis siroče je i dalje siroče, niko to ne želi da preuzme, dokumentacija nije napisana, tim koji je pozvan u ovaj servis odbija ništa, postoji jednostavan način - ponoviti sve .
Odnosno, ponovo preuzimate zahtjeve za uslugu i pišete novu uslugu, bolju, na boljoj platformi, bez čudnih tehnoloških rješenja. I migriraš na to u borbi.
Imali smo situaciju kada smo uzeli servis na Yii 1 i shvatili da ga 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. sta da radim? Dodijelili smo vrijeme, dodijelili tim, dodijelili menadžera, prepisali projekat i glatko prebacili promet na njega.
Nakon toga, stari servis se može izbrisati. Ovo je moj omiljeni postupak, kada treba da uzmete i očistite neki servis iz sistema za upravljanje konfiguracijom i onda prođete i vidite da su svi automobili u proizvodnji onemogućeni, tako da programerima ne ostane nikakav trag. Repozitorijum ostaje u Gitu.
Ovo je sve o čemu sam želeo da pričam, spreman sam za diskusiju, tema je holivar, mnogi su u njoj plivali.
Slajdovi su rekli da ste ujedinili jezike. Primjer je bilo mijenjanje veličine slika. Da li je zaista potrebno to strogo ograničiti na jedan jezik? Zato što bi se promena veličine slike u PHP-u zapravo mogla uraditi u Golangu.
U stvari, to je opciono, kao i sve prakse. Možda je u nekim slučajevima čak i nepoželjno. Ali morate shvatiti da ako imate tehničko odjeljenje u kompaniji od 50 ljudi, njih 45 su PHP specijalisti, još 3 su devopovi koji znaju Python, Ansible, Puppet i tako nešto, a samo jedan od njih piše u nekom neka vrsta usluge Go slike za promjenu veličine, a onda kada ode, stručnost ide uz to. A u isto vrijeme, morat ćete potražiti programera specifičnog za tržište koji zna ovaj jezik, posebno ako je rijedak. Odnosno, sa organizacione tačke gledišta, ovo je problematično. Sa devops tačke gledišta, nećete morati samo da klonirate neki gotov set priručnika koji koristite za implementaciju usluga, već ćete morati da ih pišete iznova.
Trenutno gradimo uslugu na Node.js, a ovo će biti samo platforma u blizini za svakog programera sa zasebnim jezikom. Ali sjedili smo i mislili da je igra vrijedna svijeće. Odnosno, ovo je pitanje za vas da sednete i razmislite.
Kako nadgledate svoje usluge? Kako prikupljate i pratite dnevnike?
Sakupljamo logove u Elasticsearch-u i stavljamo ih u Kibanu, a ovisno o tome da li se radi o proizvodnom ili testnom okruženju, tamo se koriste različiti kolektori. Negdje Drvosječa, negdje nešto drugo, ne sjećam se. I još uvijek postoje mjesta u pojedinim servisima gdje instaliramo Telegraf i snimamo negdje drugdje zasebno.
Kako živjeti sa Puppet-om i Ansible-om u istom okruženju?
U stvari, sada imamo dva okruženja, jedno je Puppet, drugo je Ansible. Radimo na njihovoj hibridizaciji. Ansible je dobar okvir za početno podešavanje, Puppet je loš okvir za početno podešavanje jer zahtijeva praktični rad direktno na platformi, a Puppet osigurava konvergenciju konfiguracije. To znači da se platforma održava u ažurnom stanju, a da bi ansibilizirana mašina bila ažurirana, potrebno je da na njoj stalno s određenom frekvencijom pokrećete playbookove. To je razlika.
Kako održavate kompatibilnost? Imate li konfiguracije u Ansibleu i Puppetu?
To je naša velika muka, održavamo kompatibilnost s rukama i razmišljamo kako da od svega toga sada negdje odemo dalje. Ispostavilo se da Puppet razvija pakete i tamo održava neke veze, a Ansible, na primjer, izbacuje kod i prilagođava najnovije konfiguracije aplikacije.
Prezentacija je bila o različitim verzijama Ruby-a. Koje rješenje?
S tim smo se susreli na jednom mjestu i to moramo stalno držati u glavi. Jednostavno smo isključili dio koji je radio na Ruby-u koji nije kompatibilan s aplikacijama i držali ga odvojenim.
Ovogodišnja konferencija održat će se 7. decembra u Technopolisu. Prijave za izvještaje primamo do 11. novembra. nas ako želite da govorite.
Prijave za učesnike su otvorene, pridružite nam se!
izvor: www.habr.com