U direttore di l'Operazioni di u portale Banki.ru Andrey Nikolsky hà parlatu à a cunferenza di l'annu passatu nantu à i servizii orfani: cumu identificà un orfanu in l'infrastruttura, perchè i servizii orfani sò cattivi, chì fà cun elli, è chì fà si nunda ùn aiuta.
Sottu u cut hè una versione testu di u rapportu.
Salutami i culleghi ! Mi chjamu Andrey, dirigu l'operazioni in Banki.ru.
Avemu grandi servizii, questi sò tali servizii monolitichi, ci sò servizii in un sensu più classicu, è ci sò assai chjuchi. In a mo terminologia di i travagliadori-paesani, dicu chì se un serviziu hè simplice è chjucu, allora hè micro, è s'ellu ùn hè micca assai simplice è chjucu, allora hè solu un serviziu.
Pros di servizii
Passaraghju rapidamente nantu à i vantaghji di i servizii.
U primu hè a scala. Pudete fà rapidamente qualcosa nantu à u serviziu è cumincià a produzzione. Avete ricevutu u trafficu, avete clonatu u serviziu. Avete più trafficu, avete clonatu è vive cun ellu. Questu hè un bonu bonu, è, in principiu, quandu avemu principiatu, era cunsideratu u più impurtante per noi, perchè facemu tuttu questu.
Siconda, sviluppu isolatu, quandu avete parechje squadre di sviluppu, parechji sviluppatori diffirenti in ogni squadra, è ogni squadra sviluppa u so propiu serviziu.
Cù squadre ci hè una sfumatura. I sviluppatori sò diffirenti. È ci sò, per esempiu, . Prima aghju vistu questu cù Maxim Dorofeev. A volte, i fiocchi di neve sò in certi squadre è micca in altri. Questu rende i diversi servizii utilizati in tutta a cumpagnia un pocu irregolari.
Fighjate à a stampa: questu hè un bonu sviluppatore, hà grandi mani, pò fà assai. U prublema principali hè da induve vene sti mani.
I servizii permettenu di utilizà diverse lingue di prugrammazione chì sò più adattati per diverse attività. Qualchi serviziu hè in Go, qualcunu hè in Erlang, alcuni hè in Ruby, qualcosa hè in PHP, qualcosa hè in Python. In generale, pudete espansione assai largamente. Ci sò ancu sfumature quì.
L'architettura orientata à u serviziu hè principalmente di devops. Vale à dì, sè ùn avete micca l'automatizazione, ùn ci hè micca un prucessu di implementazione, se u cunfigurate manualmente, e vostre cunfigurazioni ponu cambià da l'istanza di serviziu à l'istanza, è duvete andà quì per fà qualcosa, allora site in l'infernu.
Per esempiu, avete 20 servizii è avete bisognu di implementà a manu, avete 20 console, è simultaneamente appughjà "enter" cum'è un ninja. Ùn hè micca assai bonu.
Sì avete un serviziu dopu a prova (se ci hè una prova, sicuru), è avete sempre bisognu di finisce cù un schedariu per ch'ellu travaglia in a pruduzzione, aghju ancu una mala nutizia per voi.
S'è vi cunfidendu i servizii specifici di Amazon è u travagliu in Russia, allora dui mesi fà avete ancu avutu "Tuttu in u focu, sò bè, tuttu hè cool".
Usemu Ansible per automatizà a implementazione, Puppet per a cunvergenza, Bamboo per automatizà a implementazione, è Confluence per descriverà in ogni modu tuttu.
Ùn aghju micca detta nantu à questu in dettu, perchè u rapportu hè più nantu à e pratiche di interazzione, è micca di l'implementazione tecnica.
Per esempiu, avemu avutu prublemi induve Puppet nantu à u servitore travaglia cù Ruby 2, ma qualchì applicazione hè scritta per Ruby 1.8, è ùn anu micca travagliatu inseme. Qualcosa va male quì. È quandu avete bisognu di eseguisce parechje versioni di Ruby in una macchina, di solitu cuminciate à avè prublemi.
Per esempiu, demu à ogni sviluppatore una piattaforma nantu à quale ci hè apprussimatamente tuttu ciò chì avemu, tutti i servizii chì ponu esse sviluppati, per ch'ellu hà un ambiente isolatu, pò rompe è custruisce cum'è ellu vole.
Succede chì avete bisognu di qualchì pacchettu speciale compilatu cù supportu per qualcosa quì. Hè abbastanza dura. Aghju intesu un rapportu induve l'imaghjini di Docker pesa 45 GB. In Linux, sicuru, hè più simplice, tuttu hè più chjucu quì, ma ancu, ùn ci sarà abbastanza spaziu.
Ebbè, ci sò dipendenze cunflitti, quandu un pezzu di u prugettu dipende da una biblioteca di una versione, un altru pezzu di u prugettu dipende da una altra versione, è e librerie ùn sò micca stallate inseme.
Avemu siti è servizii in PHP 5.6, avemu a vergogna di elli, ma chì pudemu fà? Questu hè u nostru unicu situ. Ci sò siti è servizii nantu à PHP 7, ci sò più di elli, ùn avemu micca vergogna di elli. È ogni sviluppatore hà a so propria basa induve hà felice di vede.
Se scrivite in una cumpagnia in una lingua, allora trè macchine virtuali per sviluppatore sona normale. Sì avete diverse lingue di prugrammazione, allora a situazione peghju.
Avete siti è servizii nantu à questu, nantu à questu, dopu un altru situ per Go, un situ per Ruby, è qualchì altru Redis à u latu. In u risultatu, tuttu questu si trasforma in un grande campu di supportu, è tuttu u tempu pò rompe.
Per quessa, avemu rimpiazzatu i benefizii di a lingua di prugrammazione cù l'usu di diversi frameworks, postu chì i frameworks PHP sò assai diffirenti, anu diverse capacità, diverse cumunità è supportu diffirenti. È pudete scrive un serviziu in modu chì avete digià qualcosa pronta per questu.
Ogni serviziu hà a so squadra
U nostru vantaghju principali, chì hè cristallizatu annantu à parechji anni, hè chì ogni serviziu hà a so squadra. Questu hè convenientu per un grande prughjettu, pudete risparmià tempu nantu à a documentazione, i gestori cunnosci bè u so prughjettu.
Pudete facilmente invià i travaglii da u supportu. Per esempiu, u serviziu d'assicuranza s'hè rottu. È subitu a squadra chì si tratta di l'assicuranza và à riparà.
I novi funziunalità sò stati creati rapidamente, perchè quandu avete un serviziu atomicu, pudete sbulicà rapidamente qualcosa in questu.
È quandu vi rompe u vostru serviziu, è questu inevitabbilmente succede, ùn avete micca affettatu i servizii di l'altri, è i sviluppatori di altre squadre ùn venenu micca currendu à voi cù bit è dicenu: "Ay-ay, ùn fate micca cusì".
Cum'è sempre, ci sò sfumature. Avemu squadre stabile, i dirigenti sò inchiodati à a squadra. Ci sò documenti chjaru, i gestori monitoranu da vicinu tuttu. Ogni squadra cù un manager hà parechji servizii, è ci hè un puntu specificu di cumpetenza.
Sì i squadre sò flottanti (avemu ancu qualchì volta aduprà questu), ci hè un bonu metudu chjamatu "mappa di stella".
Avete una lista di servizii è persone. Un asteriscu significa chì a persona hè un espertu in stu serviziu, un libru significa chì a persona studia stu serviziu. U compitu di a persona hè di cambià u librettu per un asteriscu. È s'ellu ùn ci hè nunda di scrittu davanti à u serviziu, i prublemi cumincianu, chì parleraghju più.
Cumu appare i servizii orfani ?
U primu prublema, u primu modu per uttene un serviziu orfanu in a vostra infrastruttura hè di sparà e persone. Qualchissia hà mai avutu una impresa chì rispetta i termini prima di e so attività sò valutate? A volte succede chì i termini sò stretti è ùn ci hè simplicemente micca abbastanza tempu per a documentazione. "Avemu bisognu di trasmette u serviziu à a pruduzzione, allora l'aghjunteremu".
Se a squadra hè chjuca, succede chì ci hè un sviluppatore chì scrive tuttu, u restu hè in l'ale. "Aghju scrittu l'architettura di basa, aghjustemu l'interfacce". Allora in un certu puntu u manager, per esempiu, parte. È durante stu periodu, quandu u manager hè partutu è un novu ùn hè micca statu ancu numinatu, i sviluppatori stessi decidenu induve u serviziu hè andatu è ciò chì succede quì. È cum'è sapemu (returnemu uni pochi di slides), in certi squadre ci sò persone di fiocchi di neve, à volte un capu di squadra di fiocchi di neve. Allora smette, è avemu un serviziu orfanu.
À u listessu tempu, i travaglii di supportu è di l'affari ùn spariscenu micca in u backlog. S'ellu ci era qualchì errore architetturale durante u sviluppu di u serviziu, finiscinu ancu in u backlog. U serviziu si deteriora lentamente.
Cumu identificà un orfanu?
Questa lista descrive bè a situazione. Quale hà amparatu qualcosa di a so infrastruttura?
Circa i travaglii documentati: ci hè un serviziu è, in generale, funziona, hà un manuale di duie pagine nantu à cumu travaglià cun ellu, ma nimu ùn sà cumu si travaglia in l'internu.
O, per esempiu, ci hè un tipu di shortener di ligame. Per esempiu, avemu attualmente trè shorteners di ligami in usu per diversi scopi in diversi servizii. Quessi sò solu e cunsequenze.
Avà seraghju u capitanu di l'evidente. Chì deve esse fattu? Prima, avemu bisognu di trasfiriri u serviziu à un altru manager, un altru squadra. Se u vostru capu di a squadra ùn hà micca abbandunà, allora in questa altra squadra, quandu avete capitu chì u serviziu hè cum'è un orfanu, avete bisognu di includà qualchissia chì capisce almenu qualcosa.
A cosa principal: duvete avè i prucessi di trasferimentu scritti in sangue. In u nostru casu, di solitu monitoraghju questu, perchè aghju bisognu di tuttu per travaglià. I gestori anu bisognu à esse furnitu rapidamente, è ciò chì succede dopu ùn hè più cusì impurtante per elli.
A prossima manera di fà un orfanu hè "A faremu in outsourcing, serà più veloce, è poi a trasmettemu à a squadra". Hè chjaru chì ognunu hà qualchi piani in a squadra, un turnu. Spessu un cliente di cummerciale pensa chì l'outsourcer farà a listessa cosa cum'è u dipartimentu tecnicu chì a cumpagnia hà. Ancu se i so motivatori sò diffirenti. Ci sò suluzioni tecnulugichi strani è suluzioni algoritmi strani in outsourcing.
Per esempiu, avemu avutu un serviziu chì avia Sphinx in parechji lochi inaspettati. Vi dicu dopu ciò ch'e aghju da fà.
L'outsourcers anu frameworks auto-scritti. Questu hè solu PHP nudu cù copia-incolla da un prughjettu precedente, induve pudete truvà ogni tipu di cose. I script di implementazione sò un grande svantaghju quandu avete bisognu di utilizà qualchi script Bash cumplessi per cambià parechje linee in un schedariu, è questi script di implementazione sò chjamati da un terzu script. In u risultatu, cambiate u sistema di implementazione, sceglite qualcosa altru, hop, ma u vostru serviziu ùn viaghja micca. Perchè ci era necessariu di mette 8 ligami più trà e diverse cartulare. O succede chì mille dischi funzionanu, ma centu mila ùn funzionanu più.
Continuaraghju à capitanu. Accetta un serviziu outsourcing hè una prucedura obligatoria. Qualchissia hà mai avutu un serviziu outsourcing ghjuntu è ùn esse accettatu in ogni locu? Questu ùn hè micca cusì populari, sicuru, cum'è un serviziu orfanu, ma ancu.
U serviziu deve esse verificatu, u serviziu deve esse rivedutu, e password deve esse cambiatu. Avemu avutu un casu quandu ci anu datu un serviziu, ci hè un pannellu di amministratore "se login == 'admin' && password == 'admin'...", hè scrittu ghjustu in u codice. Semu è pensemu, è a ghjente scrive questu in 2018?
A prova di capacità di almacenamiento hè ancu una cosa necessaria. Avete bisognu di guardà ciò chì succede nantu à centu mila dischi, ancu prima di mette stu serviziu in produzzione in qualchì locu.
Ùn deve esse micca vergogna à mandà un serviziu per migliurà. Quandu dite: "Ùn accetteremu micca stu serviziu, avemu 20 compiti, fate, allora accetteremu", questu hè normale. A vostra cuscenza ùn deve esse ferita da u fattu chì site un manager o chì l'affari perde soldi. Allora l'affari spenderà più.
Avemu avutu un casu quandu avemu decisu di esternalizà un prughjettu pilotu.
Hè statu consegnatu à tempu, è questu era l'unicu criteriu di qualità. Hè per quessa chì avemu fattu un altru prughjettu pilotu, chì ùn era mancu veramente un pilotu più. Questi servizii sò stati accettati, è per mezu amministrativi anu dettu: quì hè u vostru codice, quì hè a squadra, quì hè u vostru manager. I servizii sò in realtà digià cuminciatu à fà un prufittu. À u listessu tempu, in fattu, sò sempre orfani, nimu capisce cumu si travaglianu, è i gestori facenu u megliu per rinunzà i so compiti.
Ci hè un altru grande cuncettu - u sviluppu di guerrilla. Quandu qualchì dipartimentu, di solitu u dipartimentu di cummercializazione, vole pruvà una ipotesi è cumanda u serviziu tutale fora. U trafficu cumencia à versà in questu, chjudenu i ducumenti, firmanu documenti cù u cuntrattu, entranu in opera è dicenu: "Dudes, avemu un serviziu quì, hà digià trafficu, ci porta soldi, accettemu". Eramu cum'è "Oppa, cumu pò esse".
È un altru modu per uttene un serviziu orfanu: quandu qualchì squadra di colpu diventa sovraccaricata, a gestione dice: "Transferemu u serviziu di sta squadra à un altru squadra, hà una carica più chjuca". E poi trasferemu à un terzu squadra è cambià u manager. È à a fine avemu un orfanu di novu.
Chì ci hè u prublema cù l'orfani ?
Quale ùn sà micca, questu hè u battleship Wasa risuscitatu in Svezia, famosu per u fattu chì hè affundatu 5 minuti dopu à u lanciu. È u rè di Svezia, per via, ùn hà micca eseguitu nimu per questu. Hè stata custruita da duie generazioni di ingegneri chì ùn sapianu micca cumu custruisce tali navi. Effettu naturali.
A nave puderia esse affundata, per via, in una manera assai peghju, per esempiu, quandu u rè era digià cavalcatu nantu à ellu in qualchì locu in una tempesta. È cusì, affucò subitu, secondu Agile hè bonu per fallu prestu.
Se fallemu prima, ùn ci sò generalmente micca prublemi. Per esempiu, durante l'accettazione hè statu mandatu per rivisione. Ma se fallemu digià in a produzzione, quandu i soldi sò investiti, allora pò esse prublemi. Cunsequenze, cumu si chjamanu in l'affari.
Perchè i servizii orfani sò periculosi:
- U serviziu pò rompe di colpu.
- U serviziu piglia assai tempu per riparà o ùn hè micca riparatu in tuttu.
- Prublemi di sicurità.
- Prublemi cù migliurà è aghjurnamenti.
- Se un serviziu impurtante si rompe, a reputazione di a cumpagnia soffre.
Chì fà cù i servizii orfani?
Ripeteraghju ciò chì deve fà di novu. Prima, ci deve esse documentazione. 7 anni in Banki.ru m'hà amparatu chì i teste ùn deve micca piglià a parolla di i sviluppatori, è l'operazioni ùn deve micca piglià a parolla di tutti. Avemu bisognu di verificà.
Siconda, hè necessariu di scrive diagrammi d'interazzione, perchè succede chì i servizii chì ùn sò micca bè ricevuti cuntenenu dependenzii chì nimu hà dettu. Per esempiu, i sviluppatori stallanu u serviziu nantu à a so chjave per qualchi Yandex.Maps o Dadata. Avete scappatu di u limitu liberu, tuttu hè rottu, è ùn sapete micca ciò chì hè accadutu. Tutti tali rake deve esse discrittu: u serviziu usa Dadata, SMS, qualcosa altru.
In terzu, travaglià cù u debitu tecnicu. Quandu fate qualchì tipu di crutches o accettà un serviziu è dite chì qualcosa deve esse fattu, avete bisognu di assicurà chì hè fattu. Perchè tandu pò esce chì u picculu pirtusu ùn hè micca cusì chjucu, è vi cascarà.
Cù i travaglii di l'architettura, avemu avutu una storia di Sphinx. Unu di i servizii utilizati Sphinx per entre in listi. Solu una lista paginata, ma hè stata re-indexata ogni notte. Hè stata assemblata da dui indici: unu grande era indexatu ogni notte, è ci era ancu un picculu indexu chì era vittutu. Ogni ghjornu, cù una probabilità di 50% di bumbardamentu o micca, l'indici crash durante u calculu, è a nostra nutizia hà cessatu di aghjurnà nantu à a pagina principale. À u principiu, hà pigliatu 5 minuti per l'indici per esse re-indexatu, dopu l'indici hà crisciutu, è à un certu puntu hà cuminciatu à piglià 40 minuti per re-indexà. Quandu avemu tagliatu questu, avemu respiratu un suspiru di sollievu, perchè era chjaru chì un pocu di più tempu passava è u nostru indice serà re-indexatu à tempu pienu. Questu serà un fallimentu per u nostru portale, ùn ci hè micca nutizie per ottu ore - hè questu, l'affari hà firmatu.
Pianu di travaglià cù un serviziu orfanu
In fatti, questu hè assai difficiule di fà, perchè devops hè di cumunicazione. Vulete esse in boni termini cù i vostri culleghi, è quandu avete colpi à i vostri culleghi è amministratori nantu à a testa cù regulamenti, ponu avè sentimenti cunflitti versu quelli persone chì facenu questu.
In più di tutti questi punti, ci hè un altru impurtante: e persone specifiche deve esse rispunsevuli di ogni serviziu specificu, per ogni sezione specifica di a prucedura di implementazione. Quandu ùn ci hè micca persone è avete da attruverà altre persone per studià tutta sta materia, diventa difficiule.
Sì tuttu questu ùn hà micca aiutu, è u vostru serviziu orfanu hè sempre un orfanu, nimu ùn vole piglià, a documentazione ùn hè micca scritta, a squadra chì hè stata chjamata in stu serviziu rifiuta di fà nunda, ci hè un modu simplice - per rifarà. tuttu.
Questu hè, pigliate i requisiti per u serviziu di novu è scrive un novu serviziu, megliu, nantu à una piattaforma megliu, senza suluzioni tecnologiche strane. È migrate à ellu in battaglia.
Avemu avutu una situazione quandu avemu pigliatu un serviziu nantu à Yii 1 è capì chì ùn pudemu micca sviluppà più, perchè avemu scappatu di sviluppatori chì puderanu scrive bè in Yii 1. Tutti i sviluppatori scrivenu bè in Symfony XNUMX. Chì fà ? Avemu assignatu u tempu, attribuitu un squadra, attribuitu un manager, riscrivite u prughjettu è cambiatu u trafficu in modu fluidu.
Dopu questu, u vechju serviziu pò esse sguassatu. Questa hè a mo prucedura preferita, quandu avete bisognu di piglià è pulizziari qualchì serviziu da u sistema di gestione di cunfigurazione è dopu passà è vede chì tutte e vitture in produzzione sò state disattivate, perchè i sviluppatori ùn anu micca traccia. U repository resta in Git.
Questu hè tuttu ciò chì vulia parlà, sò prontu à discutiri, u tema hè holivar, assai anu natatu in questu.
I slides dicenu chì avete unificatu e lingue. Un esempiu era u ridimensionamentu di i ritratti. Hè veramente necessariu di limità strettamente à una lingua ? Perchè u ridimensionamentu di l'imaghjini in PHP, bè, puderia esse fattu in Golang.
In fatti, hè facultativu, cum'è tutte e pratiche. Forsi, in certi casi, hè ancu indesevule. Ma avete bisognu di capisce chì s'è vo avete un dipartimentu tecnicu in una cumpagnia di 50 persone, 45 d'elli sò specialisti PHP, altri 3 sò devops chì cunnosci Python, Ansible, Puppet è qualcosa cusì, è solu unu di elli scrive in certi. tipu di lingua Andate u serviziu di ridimensionamentu di l'imaghjini, allora quandu parte, a cumpetenza va cun ella. È à u listessu tempu, avete bisognu di circà un sviluppatore specificu di u mercatu chì cunnosce sta lingua, soprattuttu s'ellu hè raru. Questu hè, da un puntu di vista di l'urganizazione, questu hè problematicu. Da un puntu di vista di devops, ùn avete micca solu bisognu di clonà un inseme di playbooks pronti chì avete aduprà per implementà i servizii, ma duverete scrivite di novu.
Attualmente custruemu un serviziu nantu à Node.js, è questu serà solu una piattaforma vicinu per ogni sviluppatore cù una lingua separata. Ma avemu pusatu è pinsava chì u ghjocu valeva a candela. Questu hè, questu hè una quistione per voi à pusà è pensate.
Cumu seguite i vostri servizii? Cumu cullà è monitorà i logs?
Raccogliemu logs in Elasticsearch è i mette in Kibana, è secondu s'ellu hè pruduzzione o ambienti di prova, diverse cullettori sò usati quì. In un locu Lumberjack, in un altru un altru, ùn mi ricordu micca. È ci sò ancu certi lochi in certi servizii induve installemu Telegraf è sparà in un altru locu separatamente.
Cumu campà cù Puppet è Ansible in u stessu ambiente?
In fatti, avemu avà dui ambienti, unu hè Puppet, l'altru hè Ansible. Avemu travagliatu per ibridalli. Ansible hè un bonu quadru per a cunfigurazione iniziale, Puppet hè un cattivu quadru per a cunfigurazione iniziale perchè esige un travagliu praticu direttamente nantu à a piattaforma, è Puppet assicura a cunvergenza di cunfigurazione. Questu significa chì a piattaforma si mantene in un statu up-to-date, è in ordine per a macchina ansibilized per esse tenuta à a data, avete bisognu di eseguisce playbooks nantu à tuttu u tempu cù una certa frequenza. Hè a diffarenza.
Cumu mantene a cumpatibilità? Avete cunfigurazione sia in Ansible sia in Puppet?
Questu hè u nostru grande dulore, mantenemu a cumpatibilità cù e nostre mani è pensate à cumu passà da tuttu questu in qualchì locu avà. Risulta chì Puppet stende i pacchetti è mantene alcuni ligami quì, è Ansible, per esempiu, stende u codice è aghjusta l'ultime cunfigurazione di l'applicazione.
A presentazione era nantu à e diverse versioni di Ruby. Chì suluzione ?
Avemu scontru questu in un locu, è avemu da mantene in a nostra testa tuttu u tempu. Avemu solu disattivatu a parte chì curriava nantu à u Ruby chì era incompatibile cù l'applicazioni è a manteneva separata.
A cunferenza di questu annu si ferà u 7 di dicembre à Technopolis. Accettemu l'applicazioni per i rapporti finu à l'11 di nuvembre. noi s'è vo vulete parlà.
A iscrizzione per i participanti hè aperta, unisciti à noi !
Source: www.habr.com