Directorul de operațiuni al portalului Banki.ru Andrey Nikolsky a vorbit la conferința de anul trecut despre serviciile orfane: cum să identifici un orfan în infrastructură, de ce serviciile orfane sunt proaste, ce să faci cu ele și ce să faci dacă nimic nu ajută.
Sub tăietură este o versiune text a raportului.
Salut colegi! Numele meu este Andrey, conduc operațiunile la Banki.ru.
Avem servicii mari, acestea sunt servicii atât de monolitice, sunt servicii în sens mai clasic, și sunt foarte mici. În terminologia mea muncitor-țărănească, spun că dacă un serviciu este simplu și mic, atunci este micro, iar dacă nu este foarte simplu și mic, atunci este doar un serviciu.
Avantajele serviciilor
Voi trece rapid peste avantajele serviciilor.
Primul este scalarea. Puteți face rapid ceva cu serviciul și puteți începe producția. Ați primit trafic, ați clonat serviciul. Ai mai mult trafic, l-ai clonat și trăiești cu el. Acesta este un bonus bun și, în principiu, când am început, era considerat cel mai important lucru pentru noi, de ce facem toate acestea.
În al doilea rând, dezvoltarea izolată, când ai mai multe echipe de dezvoltare, mai mulți dezvoltatori diferiți în fiecare echipă, iar fiecare echipă își dezvoltă propriul serviciu.
Cu echipele există o nuanță. Dezvoltatorii sunt diferiți. Și există, de exemplu, . Am văzut asta prima dată cu Maxim Dorofeev. Uneori, oamenii fulgi de nea sunt în unele echipe și nu în altele. Acest lucru face ca diferitele servicii utilizate în cadrul companiei să fie puțin neuniforme.
Uită-te la imagine: acesta este un dezvoltator bun, are mâini mari, poate face multe. Problema principală este de unde provin aceste mâini.
Serviciile fac posibilă utilizarea diferitelor limbaje de programare care sunt mai potrivite pentru diferite sarcini. Unele servicii sunt în Go, altele în Erlang, altele în Ruby, ceva în PHP, ceva în Python. În general, vă puteți extinde foarte mult. Există și nuanțe aici.
Arhitectura orientată spre servicii se referă în primul rând la devop-uri. Adică, dacă nu ai automatizare, nu există un proces de implementare, dacă îl configurezi manual, configurațiile tale se pot schimba de la o instanță de serviciu la o instanță și trebuie să mergi acolo pentru a face ceva, atunci ești în iad.
De exemplu, aveți 20 de servicii și trebuie să implementați manual, aveți 20 de console și apăsați simultan pe „enter” ca un ninja. Nu e foarte bine.
Dacă ai un serviciu după testare (dacă există testare, desigur), și tot trebuie să-l termini cu un fișier ca să funcționeze în producție, am și vești proaste pentru tine.
Dacă te bazezi pe anumite servicii Amazon și lucrezi în Rusia, atunci acum două luni aveai și „Totul în jur este în flăcări, sunt bine, totul este cool”.
Folosim Ansible pentru a automatiza implementarea, Puppet pentru convergență, Bamboo pentru a automatiza implementarea și Confluence pentru a descrie cumva totul.
Nu mă voi opri în detaliu asupra acestui lucru, deoarece raportul este mai mult despre practici de interacțiune, și nu despre implementarea tehnică.
De exemplu, am avut probleme când Puppet pe server funcționează cu Ruby 2, dar unele aplicații sunt scrise pentru Ruby 1.8 și nu funcționează împreună. Ceva nu merge bine acolo. Și când trebuie să rulați mai multe versiuni de Ruby pe o singură mașină, de obicei începeți să aveți probleme.
De exemplu, oferim fiecărui dezvoltator o platformă pe care se află aproximativ tot ce avem, toate serviciile care pot fi dezvoltate, astfel încât să aibă un mediu izolat, să-l poată sparge și să-l construiască așa cum dorește.
Se întâmplă că aveți nevoie de un pachet special compilat cu suport pentru ceva acolo. Este destul de dur. Am ascultat un reportaj în care imaginea Docker cântărește 45 GB. În Linux, desigur, este mai simplu, totul este mai mic acolo, dar totuși, nu va fi suficient spațiu.
Ei bine, există dependențe conflictuale, când o parte a proiectului depinde de o bibliotecă a unei versiuni, o altă parte a proiectului depinde de o altă versiune, iar bibliotecile nu sunt instalate deloc împreună.
Avem site-uri și servicii în PHP 5.6, ne este rușine de ele, dar ce putem face? Acesta este site-ul nostru. Sunt site-uri și servicii pe PHP 7, sunt mai multe, nu ne este rușine de ele. Și fiecare dezvoltator are propria sa bază unde vede fericit.
Dacă scrieți într-o companie într-o singură limbă, atunci trei mașini virtuale per dezvoltator sună normal. Dacă aveți limbaje de programare diferite, atunci situația se înrăutățește.
Aveți site-uri și servicii pe aceasta, pe aceasta, apoi un alt site pentru Go, un site pentru Ruby și alte Redis pe partea laterală. Ca rezultat, toate acestea se transformă într-un câmp mare de sprijin și tot timpul o parte din el se poate sparge.
Prin urmare, am înlocuit beneficiile limbajului de programare cu utilizarea diferitelor cadre, deoarece cadrele PHP sunt destul de diferite, au capacități diferite, comunități diferite și suport diferit. Și puteți scrie un serviciu, astfel încât să aveți deja ceva pregătit pentru el.
Fiecare serviciu are propria echipă
Principalul nostru avantaj, care s-a cristalizat de-a lungul mai multor ani, este că fiecare serviciu are propria echipă. Acest lucru este convenabil pentru un proiect mare, puteți economisi timp pe documentație, managerii își cunosc bine proiectul.
Puteți trimite cu ușurință sarcini de la asistență. De exemplu, serviciul de asigurări s-a defectat. Și imediat echipa care se ocupă de asigurări merge să o repare.
Noile funcții sunt create rapid, deoarece atunci când aveți un serviciu atomic, puteți înșuruba rapid ceva în el.
Și când îți întrerupi serviciul, iar acest lucru se întâmplă inevitabil, nu ai afectat serviciile altora, iar dezvoltatorii cu fragmente de la alte echipe nu vin la tine și spun: „Oh, nu face asta”.
Ca întotdeauna, există nuanțe. Avem echipe stabile, managerii sunt bătuți în cuie la echipă. Sunt documente clare, managerii monitorizează totul îndeaproape. Fiecare echipă cu un manager are mai multe servicii și există un punct de competență specific.
Dacă echipele plutesc (uneori folosim și asta), există o metodă bună numită „harta stelară”.
Ai o listă de servicii și oameni. Un asterisc înseamnă că persoana respectivă este expertă în acest serviciu, o carte înseamnă că persoana respectivă studiază acest serviciu. Sarcina persoanei este să schimbe broșura cu un asterisc. Și dacă nu este scris nimic în fața serviciului, atunci încep probleme, despre care voi vorbi în continuare.
Cum apar serviciile orfane?
Prima problemă, prima modalitate de a obține un serviciu orfan în infrastructura dvs. este să concediați oameni. A avut cineva vreodată ca o companie să respecte termenele limită înainte ca sarcinile să fie evaluate? Uneori se întâmplă ca termenele să fie strânse și pur și simplu nu există suficient timp pentru documentare. „Trebuie să predăm serviciul producției, apoi îl vom adăuga.”
Dacă echipa este mică, se întâmplă să fie un dezvoltator care scrie totul, restul sunt în aripi. „Am scris arhitectura de bază, să adăugăm interfețele.” Apoi, la un moment dat, managerul, de exemplu, pleacă. Și în această perioadă, când managerul a plecat și încă nu a fost numit unul nou, dezvoltatorii înșiși decid încotro merge serviciul și ce se întâmplă acolo. Și după cum știm (să revenim la câteva diapozitive), în unele echipe există oameni fulgi de nea, uneori un lider de echipă cu fulgi de nea. Apoi renunță și primim un serviciu pentru orfani.
În același timp, sarcinile din suport și din business nu dispar, ajung în așteptare. Dacă au existat erori de arhitectură în timpul dezvoltării serviciului, acestea ajung și în restanță. Serviciul se deteriorează încet.
Cum să identifici un orfan?
Această listă descrie bine situația. Cine a aflat ceva despre infrastructura lor?
Despre soluții documentate: există un serviciu și, în general, funcționează, are un manual de două pagini despre cum să lucrezi cu el, dar nimeni nu știe cum funcționează în interior.
Sau, de exemplu, există un fel de scurtator de legături. De exemplu, avem în prezent trei dispozitive de scurtare a legăturilor utilizate în scopuri diferite în diferite servicii. Acestea sunt doar consecințele.
Acum voi fi căpitanul evidentului. Ce ar trebui făcut? În primul rând, trebuie să transferăm serviciul unui alt manager, unei alte echipe. Dacă liderul echipei nu a renunțat încă, atunci în această altă echipă, când înțelegeți că serviciul este ca un orfan, trebuie să includeți pe cineva care înțelege măcar ceva despre el.
Principalul lucru: trebuie să aveți procedurile de transfer scrise în sânge. În cazul nostru, de obicei monitorizez acest lucru, pentru că am nevoie ca totul să funcționeze. Managerii au nevoie ca acesta să fie livrat rapid, iar ceea ce se întâmplă mai târziu nu mai este atât de important pentru ei.
Următoarea modalitate de a face un orfan este „O vom face externalizat, va fi mai rapid și apoi o vom preda echipei”. Este clar că toată lumea are niște planuri în echipă, o tură. Adesea, un client business crede că externalizatorul va face același lucru ca și departamentul tehnic pe care îl are compania. Deși motivatorii lor sunt diferiți. Există soluții tehnologice ciudate și soluții algoritmice ciudate în externalizare.
De exemplu, am avut un serviciu care avea Sfinx în diferite locuri neașteptate. Vă spun mai târziu ce a trebuit să fac.
Externalizatorii au cadre auto-scrise. Acesta este doar PHP simplu cu copy-paste dintr-un proiect anterior, unde puteți găsi tot felul de lucruri. Scripturile de implementare sunt un mare dezavantaj atunci când trebuie să utilizați niște scripturi Bash complexe pentru a modifica mai multe linii dintr-un fișier, iar aceste scripturi de implementare sunt numite de un al treilea script. Ca rezultat, schimbați sistemul de implementare, alegeți altceva, hop, dar serviciul dvs. nu funcționează. Pentru că acolo a fost necesar să se pună încă 8 link-uri între diferite foldere. Sau se întâmplă ca o mie de înregistrări să funcționeze, dar o sută de mii să nu mai funcționeze.
Voi continua să fiu căpitan. Acceptarea unui serviciu externalizat este o procedură obligatorie. A primit cineva vreodată un serviciu externalizat și nu a fost acceptat nicăieri? Acesta nu este la fel de popular, desigur, ca un serviciu orfan, dar totuși.
Serviciul trebuie verificat, serviciul trebuie revizuit, parolele trebuie schimbate. Am avut un caz când ne-au oferit un serviciu, există un panou de administrare „dacă se autentifică == ‘admin’ && parola == ‘admin’...”, este scris chiar în cod. Stăm și ne gândim, iar oamenii scriu asta în 2018?
Testarea capacității de stocare este, de asemenea, un lucru necesar. Trebuie să te uiți la ce se va întâmpla cu o sută de mii de înregistrări, chiar înainte de a pune acest serviciu în producție undeva.
Nu ar trebui să fie rușine să trimiteți un serviciu pentru îmbunătățire. Când spui: „Nu vom accepta acest serviciu, avem 20 de sarcini, fă-le, apoi vom accepta”, este normal. Conștiința ta nu ar trebui să fie rănită de faptul că îți înființezi un manager sau că afacerea irosește bani. Afacerea va cheltui apoi mai mult.
Am avut un caz când am decis să externalizăm un proiect pilot.
A fost livrat la timp, iar acesta a fost singurul criteriu de calitate. De aceea am realizat un alt proiect pilot, care nu mai era chiar un pilot. Aceste servicii au fost acceptate și prin mijloace administrative au spus, iată codul tău, aici este echipa, aici este managerul tău. Serviciile au început deja să facă profit. În același timp, de fapt, ei sunt încă orfani, nimeni nu înțelege cum lucrează, iar managerii fac tot posibilul să-și renegați sarcinile.
Există un alt concept grozav - dezvoltarea de gherilă. Când un anumit departament, de obicei departamentul de marketing, dorește să testeze o ipoteză și comandă externalizarea întregului serviciu. Traficul începe să curgă în el, închid actele, semnează documente cu antreprenorul, intră în funcțiune și spun: „Băieți, avem un service aici, are deja trafic, ne aduce bani, să-l acceptăm”. Ne-am spus: „Oppa, cum se poate?”
Și o altă modalitate de a obține un serviciu orfan: când o echipă se găsește brusc încărcată, conducerea spune: „Să transferăm serviciul acestei echipe unei alte echipe, are o sarcină mai mică.” Și apoi îl vom transfera la o a treia echipă și vom schimba managerul. Și până la urmă avem din nou un orfan.
Care este problema orfanilor?
Cine nu știe, acesta este cuirasatul Wasa ridicat în Suedia, renumit pentru faptul că s-a scufundat la 5 minute de la lansare. Și regele Suediei, apropo, nu a executat pe nimeni pentru asta. A fost construit de două generații de ingineri care nu știau să construiască astfel de nave. Efect natural.
Nava s-ar fi putut scufunda, apropo, într-un mod mult mai rău, de exemplu, când regele deja călărea pe ea undeva în furtună. Și așa, s-a înecat imediat, conform lui Agile, este bine să eșuezi devreme.
Dacă eșuăm devreme, de obicei nu există probleme. De exemplu, în timpul acceptării a fost trimis spre revizuire. Dar dacă eșuăm deja în producție, atunci când banii sunt investiți, atunci pot apărea probleme. Consecințele, așa cum se numesc în afaceri.
De ce serviciile orfane sunt periculoase:
- Serviciul se poate întrerupe brusc.
- Repararea serviciului durează mult sau nu este reparată deloc.
- Probleme de siguranță.
- Probleme cu îmbunătățirile și actualizările.
- Dacă un serviciu important se defectează, reputația companiei are de suferit.
Ce să faci cu serviciile orfane?
Voi repeta din nou ce să fac. În primul rând, trebuie să existe documente. 7 ani la Banki.ru m-au învățat că testerii nu trebuie să ia cuvântul dezvoltatorilor, iar operațiunile nu trebuie să ia cuvântul tuturor. Trebuie să verificăm.
În al doilea rând, este necesar să scrieți diagrame de interacțiune, deoarece se întâmplă ca serviciile care nu sunt foarte bine primite să conțină dependențe despre care nimeni nu a spus. De exemplu, dezvoltatorii au instalat serviciul pe cheia lor pentru unele Yandex.Maps sau Dadata. Ai epuizat limita liberă, totul este stricat și nu știi deloc ce s-a întâmplat. Toate astfel de rake-uri trebuie descrise: serviciul folosește Dadata, SMS, altceva.
În al treilea rând, lucrul cu datoria tehnică. Când faci un fel de cârje sau accepti un serviciu și spui că trebuie făcut ceva, trebuie să te asiguri că este făcut. Pentru că atunci se poate dovedi că gaura mică nu este atât de mică și vei cădea prin ea.
Cu sarcini arhitecturale, am avut o poveste despre Sfinx. Unul dintre servicii a folosit Sphinx pentru a intra în liste. Doar o listă paginată, dar a fost reindexată în fiecare seară. A fost asamblat din doi indexuri: unul mare era indexat în fiecare noapte și mai era și un index mic care era înșurubat de el. În fiecare zi, cu o probabilitate de 50% de bombardare sau nu, indexul s-a prăbușit în timpul calculului, iar știrile noastre au încetat să se actualizeze pe pagina principală. La început a durat 5 minute pentru ca indicele să fie reindexat, apoi indicele a crescut, iar la un moment dat a început să dureze 40 de minute pentru a fi reindexat. Când am tăiat asta, am răsuflat ușurați, pentru că era clar că va trece puțin mai mult timp și indicele nostru va fi reindexat cu normă întreagă. Acesta va fi un eșec pentru portalul nostru, nu există știri timp de opt ore - asta este, afacerile s-au oprit.
Planificați lucrul cu un serviciu orfan
De fapt, acest lucru este foarte greu de făcut, deoarece devops-ul este despre comunicare. Vrei să fii în relații bune cu colegii tăi, iar atunci când îi lovești pe colegi și manageri peste cap cu reglementări, aceștia pot avea sentimente contradictorii față de acei oameni care fac asta.
Pe lângă toate aceste puncte, mai este un lucru important: anumite persoane trebuie să fie responsabile pentru fiecare serviciu specific, pentru fiecare secțiune specifică a procedurii de implementare. Când nu există oameni și trebuie să atragi alți oameni, să studiezi toată această chestiune, devine dificil.
Dacă toate acestea nu au ajutat, iar serviciul tău orfan este încă orfan, nimeni nu vrea să-l asume, documentația nu este scrisă, echipa care a fost chemată în acest serviciu refuză să facă nimic, există o modalitate simplă - de a reface Tot .
Adică iei din nou cerințele pentru serviciu și scrii un serviciu nou, mai bun, pe o platformă mai bună, fără soluții tehnologice ciudate. Și migrezi la el în luptă.
Am avut o situație când am luat un serviciu pe Yii 1 și ne-am dat seama că nu îl mai putem dezvolta, pentru că am rămas fără dezvoltatori care să scrie bine pe Yii 1. Toți dezvoltatorii scriu bine pe Symfony XNUMX. Ce să fac? Am alocat timp, am alocat o echipă, am alocat un manager, am rescris proiectul și am schimbat fără probleme traficul către acesta.
După aceasta, vechiul serviciu poate fi șters. Aceasta este procedura mea preferată, când trebuie să luați și să curățați un serviciu din sistemul de management al configurației și apoi să treceți și să vedeți că toate mașinile din producție au fost dezactivate, astfel încât dezvoltatorii să nu rămână urme. Depozitul rămâne în Git.
Despre asta am vrut să vorbesc, sunt gata să discut, subiectul este holivar, mulți au înotat în el.
Slide-urile spuneau că ați unificat limbile. Un exemplu a fost redimensionarea imaginilor. Este cu adevărat necesar să o limităm strict la o singură limbă? Deoarece redimensionarea imaginii în PHP, ei bine, ar putea fi de fapt făcută în Golang.
De fapt, este opțional, ca toate practicile. Poate că, în unele cazuri, este chiar nedorit. Dar trebuie să înțelegi că dacă ai un departament tehnic într-o companie de 50 de oameni, 45 dintre ei sunt specialiști PHP, alți 3 sunt devopi care știu Python, Ansible, Puppet și așa ceva, și doar unul dintre ei scrie în unele un fel de limbaj. un serviciu de redimensionare a imaginii Go, apoi, când pleacă, expertiza merge cu el. Și, în același timp, va trebui să căutați un dezvoltator specific pieței care cunoaște acest limbaj, mai ales dacă este rar. Adică, din punct de vedere organizațional, acest lucru este problematic. Din punct de vedere devops, nu va trebui doar să clonați un set gata făcut de manuale pe care le utilizați pentru a implementa serviciile, ci va trebui să le scrieți din nou.
În prezent, construim un serviciu pe Node.js, iar acesta va fi doar o platformă în apropiere pentru fiecare dezvoltator cu o limbă separată. Dar am stat și ne-am gândit că jocul merită lumânarea. Adică, aceasta este o întrebare la care să stai și să te gândești.
Cum vă monitorizați serviciile? Cum colectați și monitorizați jurnalele?
Colectăm jurnalele în Elasticsearch și le punem în Kibana și, în funcție de medii de producție sau de testare, acolo sunt folosiți diferiți colectori. Undeva Lumberjack, undeva altundeva altceva, nu-mi amintesc. Și mai sunt niște locuri în anumite servicii unde instalăm Telegraf și filmăm în altă parte separat.
Cum să trăiești cu Puppet și Ansible în același mediu?
De fapt, acum avem două medii, unul este Puppet, celălalt este Ansible. Lucrăm pentru a le hibridiza. Ansible este un cadru bun pentru configurarea inițială, Puppet este un cadru prost pentru configurarea inițială, deoarece necesită lucru manual direct pe platformă, iar Puppet asigură convergența configurației. Acest lucru înseamnă că platforma se menține într-o stare actualizată și, pentru ca mașina ansibilizată să fie ținută la zi, trebuie să rulezi manuale de joc pe ea tot timpul cu o anumită frecvență. Asta e diferența.
Cum mențineți compatibilitatea? Aveți configurații atât în Ansible, cât și în Puppet?
Aceasta este marea noastră durere, menținem compatibilitatea cu mâinile noastre și ne gândim cum să trecem de la toate acestea undeva acum. Se pare că Puppet lansează pachete și menține unele legături acolo, iar Ansible, de exemplu, lansează codul și ajustează cele mai recente configurații ale aplicației acolo.
Prezentarea a fost despre diferite versiuni de Ruby. Ce solutie?
Am întâlnit asta într-un singur loc și trebuie să-l păstrăm în cap tot timpul. Pur și simplu am oprit partea care rula pe Ruby care era incompatibilă cu aplicațiile și am păstrat-o separată.
Conferința de anul acesta va avea loc pe 7 decembrie la Technopolis. Acceptăm cereri pentru rapoarte până pe 11 noiembrie. noi dacă vrei să vorbești.
Înregistrările pentru participanți sunt deschise, alăturați-vă nouă!
Sursa: www.habr.com