Na lanski konferenci je spregovoril direktor operacij portala Banki.ru Andrej Nikolski o orphan storitvah: kako prepoznati orphan storitve v infrastrukturi, zakaj so orphan storitve slabe, kaj storiti z njimi in kaj storiti, če nič ne pomaga.
Pod rezom je besedilna verzija poročila.
Pozdravljeni kolegi! Moje ime je Andrey, sem vodja operacij pri Banki.ru.
Imamo velike servise, to so tako monolitni servisi, so servisi v bolj klasičnem smislu in so zelo majhni. Jaz v svoji delavsko-kmečki terminologiji pravim, da če je storitev enostavna in majhna, potem je mikro, če pa ni zelo enostavna in majhna, potem je pač storitev.
Prednosti storitev
Na hitro bom pregledal prednosti storitev.
Prvi je skaliranje. Hitro lahko kaj narediš na servisu in začneš s proizvodnjo. Prejeli ste promet, klonirali ste storitev. Imaš več prometa, kloniral si ga in živiš z njim. To je dober bonus in načeloma, ko smo začeli, se nam je zdelo najpomembnejše, zakaj vse to počnemo.
Drugič, izoliran razvoj, ko imate več razvojnih ekip, več različnih razvijalcev v vsaki ekipi in vsaka ekipa razvija svojo storitev.
Pri ekipah obstaja odtenek. Razvijalci so različni. In obstajajo npr. . To sem prvič videl pri Maximu Dorofeevu. Včasih so ljudje snežinke v nekaterih ekipah, v drugih pa ne. Zaradi tega so različne storitve, ki se uporabljajo v podjetju, nekoliko neenakomerne.
Poglejte sliko: to je dober razvijalec, ima velike roke, zmore veliko. Glavni problem je, od kod prihajajo te roke.
Storitve omogočajo uporabo različnih programskih jezikov, ki so primernejši za različna opravila. Nekatere storitve so v Go, nekatere v Erlangu, nekatere v Rubyju, nekaj v PHP, nekaj v Pythonu. Na splošno se lahko razširite zelo široko. Tudi tukaj so nianse.
Storitveno usmerjena arhitektura se nanaša predvsem na devops. To pomeni, da če nimate avtomatizacije, ni postopka uvajanja, če ga konfigurirate ročno, se lahko vaše konfiguracije spreminjajo od primerka storitve do primerka in morate iti tja, da nekaj naredite, potem ste v peklu.
Na primer, imate 20 storitev in jih morate namestiti ročno, imate 20 konzol in hkrati pritisnete "enter" kot ninja. Ni zelo dobro.
Če imate storitev po testiranju (če je seveda testiranje) in jo morate še dodelati z datoteko, da deluje v produkciji, imam za vas tudi slabo novico.
Če se zanašate na posebne storitve Amazon in delate v Rusiji, potem ste pred dvema mesecema imeli tudi "Vse okoli gori, jaz sem v redu, vse je kul."
Ansible uporabljamo za avtomatizacijo uvajanja, Puppet za konvergenco, Bamboo za avtomatizacijo uvajanja in Confluence, da nekako opišemo vse.
O tem se ne bom podrobneje ukvarjal, ker poročilo bolj govori o interakcijskih praksah in ne o tehnični izvedbi.
Na primer, imeli smo težave, ko Puppet na strežniku deluje z Ruby 2, vendar je neka aplikacija napisana za Ruby 1.8 in ne delujeta skupaj. Nekaj gre narobe. In ko morate zagnati več različic Rubyja na enem računalniku, običajno začnete imeti težave.
Vsakemu razvijalcu damo na primer platformo, na kateri je približno vse, kar imamo, vse storitve, ki jih je mogoče razvijati, da ima izolirano okolje, ga lahko razbija in gradi, kot hoče.
Zgodi se, da potrebujete kakšen posebej sestavljen paket s podporo za nekaj tam. Precej težko je. Poslušal sem poročilo, kjer Dockerjeva slika tehta 45 GB. V Linuxu je seveda preprostejše, tam je vse manjše, a vseeno ne bo dovolj prostora.
No, obstajajo nasprotujoče si odvisnosti, ko je en del projekta odvisen od knjižnice ene različice, drugi del projekta je odvisen od druge različice in knjižnici sploh nista nameščeni skupaj.
Imamo strani in storitve v PHP 5.6, sramujemo se jih, a kaj lahko? To je naše eno spletno mesto. Obstajajo strani in storitve na PHP 7, več jih je, ne sramujemo se jih. In vsak razvijalec ima svojo bazo, kjer z veseljem žaga.
Če pišete v podjetju v enem jeziku, potem trije virtualni stroji na razvijalca zvenijo normalno. Če imate različne programske jezike, se situacija poslabša.
Imate spletna mesta in storitve na tem, na tem, nato še eno mesto za Go, eno mesto za Ruby in nekaj drugih Redisov ob strani. Posledično se vse to spremeni v veliko polje za oporo in ves čas se nekaj od tega lahko zlomi.
Zato smo prednosti programskega jezika nadomestili z uporabo različnih ogrodij, saj so ogrodja PHP precej različna, imajo drugačne zmogljivosti, drugačne skupnosti in drugačno podporo. In storitev lahko napišete tako, da že imate nekaj pripravljeno zanjo.
Vsaka služba ima svojo ekipo
Naša glavna prednost, ki se je izkristalizirala v nekaj letih, je, da ima vsaka služba svojo ekipo. To je priročno za velik projekt, lahko prihranite čas pri dokumentaciji, vodje dobro poznajo svoj projekt.
Naloge lahko preprosto oddate iz podpore. Pokvarila se je na primer zavarovalnica. In takoj gre ekipa, ki se ukvarja z zavarovanji, to popravljat.
Nove funkcije nastajajo hitro, saj ko imaš en atomski servis, lahko hitro kaj zašraufaš vanj.
In ko prekinete svojo storitev, in to se neizogibno zgodi, niste vplivali na storitve drugih ljudi in razvijalci iz drugih ekip ne pridejo k vam z delčki in rečejo: "Aj-aj, ne počni tega."
Kot vedno obstajajo nianse. Imamo stabilne ekipe, menedžerji so prikovani na ekipo. Obstajajo jasni dokumenti, menedžerji pozorno spremljajo vse. Vsak tim z vodjo ima več služb in obstaja določena točka kompetence.
Če so ekipe lebdeče (tudi to včasih uporabljamo), obstaja dobra metoda, imenovana "zvezdni zemljevid".
Imate seznam storitev in ljudi. Zvezdica pomeni, da je oseba strokovnjak za to storitev, knjiga pomeni, da oseba študira to storitev. Naloga osebe je zamenjati knjižico za zvezdico. In če nič ne piše pred storitvijo, se začnejo težave, o katerih bom govoril naprej.
Kako se pojavijo storitve sirote?
Prva težava, prvi način, da v svojo infrastrukturo dobite storitev siroto, je odpustiti ljudi. Je komu že kdaj uspelo, da je podjetje izpolnilo roke, preden so bile naloge ocenjene? Včasih se zgodi, da so roki kratki in preprosto ni dovolj časa za dokumentacijo. "Storitev moramo predati proizvodnji, nato jo bomo dodali."
Če je ekipa majhna, se zgodi, da je en razvijalec, ki vse napiše, ostali so v teku. "Napisal sem osnovno arhitekturo, dodajmo vmesnike." Potem na neki točki menedžer na primer odide. In v tem obdobju, ko je upravitelj odšel in novi še ni bil imenovan, se razvijalci sami odločijo, kam gre storitev in kaj se tam dogaja. In kot vemo (vrnimo se nekaj diapozitivov nazaj), so v nekaterih ekipah ljudje snežinke, včasih vodja ekipe snežinke. Potem odneha in dobimo službo za sirote.
Hkrati naloge iz podpore in iz poslovanja ne izginejo; Če je med razvojem storitve prišlo do arhitekturnih napak, se tudi te znajdejo v zaostanku. Storitev se počasi slabša.
Kako prepoznati siroto?
Ta seznam dobro opisuje situacijo. Kdo se je kaj naučil o njihovi infrastrukturi?
O dokumentiranih obhodih: obstaja storitev in na splošno deluje, ima dve strani priročnika, kako delati z njo, vendar nihče ne ve, kako deluje notri.
Ali pa na primer obstaja nekakšen skrajševalec povezav. Na primer, trenutno imamo v uporabi tri skrajševalce povezav za različne namene v različnih storitvah. To so samo posledice.
Zdaj bom kapitan očitnega. Kaj je treba narediti? Najprej moramo storitev prenesti na drugega vodjo, drugo ekipo. Če vaš vodja ekipe še ni odnehal, potem morate v to drugo ekipo, ko razumete, da je storitev kot sirota, vključiti nekoga, ki se vsaj nekaj razume nanjo.
Glavno: postopke premestitve moraš imeti napisane s krvjo. Pri nas to običajno spremljam, ker moram vse skupaj delovati. Menedžerji potrebujejo, da je dostavljen hitro, in kaj se z njim zgodi kasneje, jim ni več tako pomembno.
Naslednji način za izdelavo sirote je "To bomo storili zunanjim izvajalcem, to bo hitreje, nato pa bomo to predali ekipi." Jasno je, da imajo vsi v ekipi neke načrte, preobrat. Pogosto poslovna stranka misli, da bo zunanji izvajalec delal isto kot tehnični oddelek, ki ga ima podjetje. Čeprav so njihovi motivatorji različni. Pri zunanjem izvajanju obstajajo čudne tehnološke rešitve in čudne algoritemske rešitve.
Na primer, imeli smo storitev, ki je imela Sphinx na različnih nepričakovanih mestih. Pozneje ti bom povedal, kaj sem moral narediti.
Zunanji izvajalci imajo okvire, ki so jih napisali sami. To je samo goli PHP s kopiranjem in lepljenjem iz prejšnjega projekta, kjer lahko najdete vse mogoče stvari. Skripti za uvajanje so velika pomanjkljivost, ko morate uporabiti nekaj zapletenih skriptov Bash, da spremenite več vrstic v neki datoteki, te skripte za uvajanje pa kliče nek tretji skript. Posledično spremenite sistem uvajanja, izberete nekaj drugega, hop, vendar vaša storitev ne deluje. Ker tam je bilo treba postaviti še 8 povezav med različne mape. Ali pa se zgodi, da tisoč zapisov deluje, sto tisoč pa ne deluje več.
Še naprej bom kapetan. Sprejem zunanje storitve je obvezen postopek. Se je že komu zgodilo, da je zunanji servis prišel in ga nikjer niso sprejeli? To seveda ni tako priljubljeno kot storitev sirota, a vseeno.
Storitev je treba preveriti, storitev je treba pregledati, gesla je treba spremeniti. Imeli smo primer, ko so nam dali storitev, tam je skrbniška plošča “if login == 'admin' && password == 'admin'...”, piše kar v kodi. Sedimo in razmišljamo, ljudje pa to pišejo v letu 2018?
Testiranje zmogljivosti shranjevanja je tudi nujna stvar. Morate pogledati, kaj se bo zgodilo na sto tisoč zapisih, še preden to storitev nekje spravite v produkcijo.
Ne bi smelo biti sram poslati storitev v izboljšavo. Ko rečete: "Ne bomo sprejeli te storitve, imamo 20 nalog, naredite jih, potem bomo sprejeli," je to normalno. Naj vas ne boli vest, da postavljate upravnika ali da podjetje zapravlja denar. Podjetje bo potem porabilo več.
Imeli smo primer, ko smo se odločili za zunanji izvajalec pilotnega projekta.
Dostavljeno je bilo pravočasno in to je bilo edino merilo kakovosti. Zato smo naredili še en pilotni projekt, ki sploh ni bil več pravi pilot. Te storitve so bile sprejete in z administrativnimi sredstvi so rekli, tukaj je vaša koda, tukaj je ekipa, tukaj je vaš vodja. Storitve so pravzaprav že začele prinašati dobiček. Hkrati pa so pravzaprav še vedno sirote, nihče ne razume, kako delujejo, menedžerji pa se po svojih najboljših močeh odpovedujejo njihovim nalogam.
Obstaja še en odličen koncept - gverilski razvoj. Ko nek oddelek, običajno marketing, želi preveriti hipotezo in naroči celotno storitev zunanjim izvajalcem. Vanjo se začne stekati promet, zaprejo dokumente, podpišejo dokumente z izvajalcem, pridejo v obratovanje in rečejo: »Stari, tukaj imamo servis, promet že ima, prinaša nam denar, dajmo to sprejeti.« Rekli smo si: "Opa, kako je to mogoče."
In še en način za pridobitev storitve sirote: ko neka ekipa nenadoma postane preobremenjena, vodstvo reče: "Prenesimo storitev te ekipe na drugo ekipo, ima manjšo obremenitev." In potem ga bomo prenesli na tretjo ekipo in zamenjali menedžerja. In na koncu imamo spet siroto.
Kaj je problem s sirotami?
Kdo ne ve, to je na Švedskem dvignjena bojna ladja Wasa, znana po tem, da je potonila 5 minut po izstrelitvi. In mimogrede, švedski kralj zaradi tega ni nikogar usmrtil. Gradili sta jo dve generaciji inženirjev, ki takšnih ladij nista znali graditi. Naravni učinek.
Ladja bi se mimogrede lahko potopila na veliko hujši način, na primer, ko se je kralj na njej že vozil nekje v neurju. In tako, takoj se je utopil, po mnenju Agila je dobro zgodaj propasti.
Če nam spodleti zgodaj, običajno ni težav. Na primer, med sprejemom je bil poslan v revizijo. Če pa nam spodleti že v proizvodnji, ko se vloži denar, potem lahko pride do težav. Posledice, kot se temu reče v poslu.
Zakaj so storitve sirote nevarne:
- Storitev se lahko nenadoma prekine.
- Servis se popravlja dolgo ali pa se sploh ne popravi.
- Varnostne težave.
- Težave z izboljšavami in posodobitvami.
- Če se pomembna storitev pokvari, trpi ugled podjetja.
Kaj storiti s storitvami sirote?
Še enkrat bom ponovil, kaj storiti. Najprej mora obstajati dokumentacija. 7 let pri Banki.ru me je naučilo, da preizkuševalci ne smejo verjeti na besedo razvijalcem in da operacije ne smejo verjeti vsem na besedo. Moramo preveriti.
Drugič, treba je napisati interakcijske diagrame, saj se zgodi, da storitve, ki niso preveč dobro sprejete, vsebujejo odvisnosti, o katerih nihče ni govoril. Na primer, razvijalci so storitev namestili na svoj ključ do nekaterih Yandex.Maps ali Dadata. Zmanjkalo vam je brezplačnega limita, vse je pokvarjeno in sploh ne veste, kaj se je zgodilo. Vse take grablje je treba opisati: storitev uporablja Dadata, SMS, kaj drugega.
Tretjič, delo s tehničnim dolgom. Ko narediš neke vrste bergle ali sprejmeš storitev in rečeš, da je treba nekaj narediti, moraš poskrbeti, da je to narejeno. Ker potem se lahko izkaže, da majhna luknja ni tako majhna, in boste padli skoznjo.
Pri arhitekturnih nalogah smo imeli zgodbo o Sfingi. Ena od storitev je za vnos seznamov uporabljala Sphinx. Samo paginiran seznam, vendar je bil vsak večer ponovno indeksiran. Sestavljen je bil iz dveh indeksov: enega velikega so indeksirali vsak večer, nanj pa je bil privit tudi mali indeks. Vsak dan, s 50% verjetnostjo bombardiranja ali ne, se je indeks med izračunom sesul in naše novice so se nehale posodabljati na glavni strani. Sprva je trajalo 5 minut, da se je indeks ponovno indeksiral, nato je indeks rasel in na neki točki je ponovno indeksiranje začelo trajati 40 minut. Ko smo to izločili, smo si oddahnili, saj je bilo jasno, da bo minilo še malo časa in bo naš indeks ponovno indeksiran v celoti. To bo za naš portal neuspeh, osem ur ni novic - to je to, posel je zastal.
Načrt za delo s storitvijo siroto
Pravzaprav je to zelo težko narediti, saj gre pri devopsu za komunikacijo. S svojimi sodelavci želite biti v dobrih odnosih in ko svoje kolege in vodje udarite po glavi s predpisi, imajo lahko nasprotujoča si čustva do tistih ljudi, ki to počnejo.
Poleg vseh teh točk je pomembna še ena stvar: za vsako posamezno storitev, za vsak posamezen del postopka uvajanja morajo biti odgovorni točno določeni ljudje. Ko ni ljudi in moraš pritegniti druge ljudi, da preučijo celotno zadevo, postane težko.
Če vse to ni pomagalo in je vaša storitev sirota še vedno sirota, nihče je noče prevzeti, dokumentacija ni napisana, ekipa, ki je bila poklicana v to storitev, noče storiti ničesar, obstaja preprost način - ponoviti vse .
Se pravi, zahteve za storitev vzameš na novo in napišeš novo storitev, boljšo, na boljši platformi, brez čudnih tehnoloških rešitev. In vanj se preselite v bitki.
Imeli smo situacijo, ko smo vzeli storitev na Yii 1 in ugotovili, da je ne moremo razvijati naprej, ker nam je zmanjkalo razvijalcev, ki bi lahko dobro pisali na Yii 1. Vsi razvijalci dobro pišejo na Symfony XNUMX. Kaj storiti? Razporedili smo čas, dodelili ekipo, dodelili vodjo, prepisali projekt in nemoteno preusmerili promet nanj.
Po tem lahko staro storitev izbrišete. To je moj najljubši postopek, ko morate vzeti in počistiti neko storitev iz sistema za upravljanje konfiguracije in nato iti skozi in videti, da so bili vsi avtomobili v proizvodnji onemogočeni, tako da razvijalci nimajo nobenih sledi. Repozitorij ostane v Gitu.
To je vse, o čemer sem želel govoriti, pripravljen sem razpravljati, tema je holivar, mnogi so plavali v njej.
Na diapozitivih je pisalo, da ste poenotili jezike. Primer je bilo spreminjanje velikosti slik. Ali ga je res treba strogo omejiti na en jezik? Kajti spreminjanje velikosti slik v PHP, no, dejansko bi bilo mogoče narediti v Golangu.
Pravzaprav je neobvezna, tako kot vse prakse. Morda je v nekaterih primerih celo nezaželeno. Vendar morate razumeti, da če imate tehnični oddelek v podjetju s 50 ljudmi, je 45 od njih strokovnjakov za PHP, drugi 3 so devopsi, ki poznajo Python, Ansible, Puppet in kaj podobnega, in samo eden od njih piše v nekem vrsta jezika. Go storitev spreminjanja velikosti slik, potem ko odide, gre z njo strokovno znanje. Hkrati pa boste morali poiskati razvijalca za določen trg, ki pozna ta jezik, še posebej, če je redek. Se pravi, z organizacijskega vidika je to problematično. Z vidika devops vam ne bo treba samo klonirati nekega že pripravljenega nabora priročnikov, ki jih uporabljate za uvajanje storitev, ampak jih boste morali napisati znova.
Trenutno gradimo storitev na Node.js in to bo le platforma v bližini za vsakega razvijalca z ločenim jezikom. Vendar smo sedeli in mislili, da je igra vredna sveče. Se pravi, to je vprašanje za vas, da sedite in razmislite.
Kako spremljate svoje storitve? Kako zbirate in spremljate dnevnike?
Dnevnike zbiramo v Elasticsearch in jih damo v Kibano, tam pa se uporabljajo različni zbiralniki, odvisno od tega, ali gre za produkcijska ali testna okolja. Nekje Drvar, drugje kaj drugega, se ne spomnim. In še vedno je nekaj mest v določenih storitvah, kjer namestimo Telegraf in snemamo drugje ločeno.
Kako živeti s Puppetom in Ansibleom v istem okolju?
Pravzaprav imamo zdaj dve okolji, eno je Puppet, drugo je Ansible. Prizadevamo si za njihovo hibridizacijo. Ansible je dobro ogrodje za začetno nastavitev, Puppet je slabo ogrodje za začetno nastavitev, ker zahteva praktično delo neposredno na platformi, Puppet pa zagotavlja konvergenco konfiguracije. To pomeni, da se platforma vzdržuje v posodobljenem stanju in da bo ansibiliziran stroj posodobljen, morate na njem ves čas izvajati knjige iger z določeno pogostostjo. To je razlika.
Kako ohranjate združljivost? Ali imate konfiguracije v Ansible in Puppet?
To je naša velika bolečina, kompatibilnost ohranjamo z rokami in razmišljamo, kako bi zdaj od vsega tega nekje naprej. Izkazalo se je, da Puppet uvaja pakete in tam vzdržuje nekatere povezave, Ansible pa na primer uvaja kodo in tam prilagaja najnovejše konfiguracije aplikacij.
Predstavitev je govorila o različnih različicah Rubyja. Kakšna rešitev?
S tem smo se srečali na enem mestu in to moramo ves čas imeti v glavi. Preprosto smo izklopili del, ki je deloval na Rubyju in ni bil združljiv z aplikacijami, in ga ohranili ločenega.
Letošnja konferenca bo 7. decembra v Tehnopolisu. Prijave na poročila sprejemamo do 11. novembra. nas, če želite govoriti.
Prijave za udeležence so odprte, pridruži se nam!
Vir: www.habr.com