Direkteur fan operaasjes fan it Banki.ru-portaal Andrey Nikolsky spruts op 'e konferinsje fan ferline jier oer weestsjinsten: hoe't jo in wees yn 'e ynfrastruktuer identifisearje, wêrom't weestsjinsten min binne, wat dermei te dwaan, en wat te dwaan as neat helpt.
Under de besuniging stiet in tekstferzje fan it rapport.
Hallo kollega's! Myn namme is Andrey, ik haad operaasjes by Banki.ru.
Wy hawwe grutte tsjinsten, dit binne sokke monolityske tsjinsten, d'r binne tsjinsten yn in mear klassike betsjutting, en d'r binne heul lytse. Yn myn arbeider-boer-terminology sis ik dat as in tsjinst ienfâldich en lyts is, dan is it mikro, en as it net heul ienfâldich en lyts is, dan is it gewoan in tsjinst.
Pros fan tsjinsten
Ik sil gau oer de foardielen fan 'e tsjinsten gean.
De earste is skaalfergrutting. Jo kinne fluch wat dwaan op 'e tsjinst en begjinne produksje. Jo hawwe ferkear ûntfongen, jo hawwe de tsjinst klonen. Jo hawwe mear ferkear, jo hawwe it klonen en libje mei it. Dit is in goede bonus, en, yn prinsipe, doe't wy begûn, it waard beskôge as it wichtichste ding foar ús, wêrom wy dogge dit alles.
Twads, isolearre ûntwikkeling, as jo ferskate ûntwikkelingsteams hawwe, ferskate ferskillende ûntwikkelders yn elk team, en elk team ûntwikkelet syn eigen tsjinst.
By teams is der in nuânse. Untwikkelders binne oars. En der binne bgl. . Ik seach dit earst mei Maxim Dorofeev. Soms binne snowflake minsken op guon teams en net op oaren. Dit makket de ferskate tsjinsten dy't oer it bedriuw brûkt wurde in bytsje unjildich.
Sjoch nei de foto: dit is in goede ûntwikkelder, hy hat grutte hannen, hy kin in protte. It wichtichste probleem is wêr't dizze hannen wei komme.
Tsjinsten meitsje it mooglik om ferskate programmeartalen te brûken dy't mear geskikt binne foar ferskate taken. Guon tsjinst is yn Go, guon is yn Erlang, guon is yn Ruby, wat is yn PHP, wat is yn Python. Yn 't algemien kinne jo heul wiid útwreidzje. Ek hjir binne nuânses.
Service-rjochte arsjitektuer giet foaral oer devops. Dat is, as jo gjin automatisearring hawwe, is d'r gjin ynsetproses, as jo it manuell ynstelle, kinne jo konfiguraasjes feroarje fan tsjinsteksimplaar nei eksimplaar, en jo moatte der hinne gean om wat te dwaan, dan binne jo yn 'e hel.
Jo hawwe bygelyks 20 tsjinsten en jo moatte mei de hân ynsette, jo hawwe 20 konsoles, en jo drukke tagelyk op "enter" as in ninja. It is net hiel goed.
As jo in tsjinst nei testen (as der testen is, fansels), en jo moatte noch ôfmeitsje it mei in triem, sadat it wurket yn produksje, Ik haw ek min nijs foar dy.
As jo fertrouwe op spesifike Amazon-tsjinsten en wurkje yn Ruslân, dan hawwe jo twa moanne lyn ek "Alles omhinne stiet yn 'e brân, ik bin goed, alles is cool."
Wy brûke Ansible om ynset te automatisearjen, Puppet foar konverginsje, Bamboo om ynset te automatisearjen, en Confluence om it allegear op ien of oare manier te beskriuwen.
Ik sil hjir net yn detail op yngean, om't it rapport mear oer ynteraksjepraktiken giet, en net oer technyske ymplemintaasje.
Bygelyks, wy hawwe hie problemen dêr't Puppet op de tsjinner wurket mei Ruby 2, mar guon applikaasje is skreaun foar Ruby 1.8, en se wurkje net tegearre. Dêr giet wat mis. En as jo meardere ferzjes fan Ruby op ien masine moatte útfiere, begjinne jo gewoanlik problemen te hawwen.
Bygelyks, wy jouwe elke ûntwikkelder in platfoarm wêrop d'r sawat alles is dat wy hawwe, alle tsjinsten dy't kinne wurde ûntwikkele, sadat hy in isolearre omjouwing hat, hy kin it brekke en it bouwe lykas hy wol.
It bart dat jo nedich wat spesjaal gearstald pakket mei stipe foar wat dêr. It is nochal taai. Ik harke nei in rapport wêr't de Docker-ôfbylding 45 GB weaget. Yn Linux is it fansels ienfâldiger, alles is dêr lytser, mar dochs sil d'r net genôch romte wêze.
No, der binne tsjinstridige ôfhinklikens, as ien stik fan it projekt hinget ôf fan in bibleteek fan ien ferzje, in oar stik fan it projekt hinget ôf fan in oare ferzje, en de bibleteken wurde net ynstallearre tegearre op alle.
Wy hawwe siden en tsjinsten yn PHP 5.6, wy skamje ús foar harren, mar wat kinne wy dwaan? Dit is ús iene side. D'r binne siden en tsjinsten op PHP 7, d'r binne mear fan har, wy skamje ús net foar har. En elke ûntwikkelder hat syn eigen basis dêr't er lokkich seach.
As jo yn in bedriuw yn ien taal skriuwe, dan klinkt trije firtuele masines per ûntwikkelder normaal. As jo ferskillende programmeartalen hawwe, dan wurdt de situaasje slimmer.
Jo hawwe siden en tsjinsten op dit, op dit, dan in oare side foar Go, ien side foar Ruby, en wat oare Redis oan 'e kant. As gefolch, dit alles feroaret yn in grut fjild foar stipe, en de hiele tiid kin guon fan it brekke.
Dêrom hawwe wy de foardielen fan 'e programmeartaal ferfongen troch it brûken fan ferskate kaders, om't PHP-ramten hiel oars binne, se hawwe ferskate mooglikheden, ferskate mienskippen en ferskate stipe. En jo kinne in tsjinst skriuwe sadat jo der al wat foar klear hawwe.
Elke tsjinst hat syn eigen team
Us wichtichste foardiel, dat oer ferskate jierren útkristallisearre is, is dat elke tsjinst in eigen team hat. Dit is handich foar in grut projekt, jo kinne tiid besparje op dokumintaasje, managers kenne har projekt goed.
Jo kinne maklik taken yntsjinje fan stipe. Sa is de fersekeringstsjinst útbrutsen. En daliks giet it team dat mei fersekering dwaande hâldt om it te reparearjen.
Nije funksjes wurde fluch oanmakke, want as jo ien atoomtsjinst hawwe, kinne jo der gau wat yn skroefje.
En as jo jo tsjinst brekke, en dit bart ûnûntkomber, hawwe jo gjin ynfloed op de tsjinsten fan oare minsken, en ûntwikkelders fan oare teams komme net mei bits nei jo rinnen en sizze: "Ay-ay, doch dat net."
Lykas altyd binne d'r nuânses. Wy hawwe stabile teams, managers binne oan it team spikere. D'r binne dúdlike dokuminten, managers folgje alles goed yn 'e gaten. Elk team mei in manager hat ferskate tsjinsten, en der is in spesifyk punt fan kompetinsje.
As de teams driuwe (wy brûke dit ek soms), is der in goede metoade neamd de "stjerkaart".
Jo hawwe in list mei tsjinsten en minsken. In asterisk betsjut dat de persoan in ekspert is yn dizze tsjinst, in boek betsjut dat de persoan dizze tsjinst studearret. De taak fan de persoan is om it boekje te feroarjen foar in asterisk. En as neat is skreaun foar de tsjinst, dan begjinne problemen, dêr't ik sil prate oer fierder.
Hoe ferskine weestsjinsten?
It earste probleem, de earste manier om in weestsjinst yn jo ynfrastruktuer te krijen is om minsken te ûntslaan. Hat immen oait in bedriuw oan deadlines hân foardat taken waarden beoardiele? Soms bart it dat deadlines krap binne en d'r gewoan net genôch tiid is foar dokumintaasje. "Wy moatte de tsjinst oerjaan oan produksje, dan sille wy it tafoegje."
As it team lyts is, bart it dat der ien ûntwikkelder is dy't alles skriuwt, de rest is yn 'e wjukken. "Ik skreau de basisarsjitektuer, litte wy de ynterfaces tafoegje." Dan op in stuit giet de manager bygelyks fuort. En yn dizze perioade, as de manager fuort is en in nije noch net beneamd is, beslute de ûntwikkelders sels wêr't de tsjinst giet en wat der bart. En sa't wy witte (lit ús gean werom in pear dia's), yn guon teams binne der snieflokken minsken, soms in snowflake team lead. Dan hâldt er op, en krije wy in weestsjinst.
Tagelyk ferdwine taken fan stipe en út it bedriuwslibben net, se komme yn de efterstân. As der by de ûntwikkeling fan de tsjinst arsjitektoanyske flaters wiene, komme se ek yn de efterstân. De tsjinst wurdt stadichoan minder.
Hoe kinne jo in wees identifisearje?
Dizze list beskriuwt de situaasje goed. Wa learde wat oer har ynfrastruktuer?
Oer dokumintearre work-arounds: d'r is in tsjinst en, yn 't algemien, wurket it, it hat in twa-pagina hantlieding oer hoe't jo dermei wurkje, mar gjinien wit hoe't it binnen wurket.
Of, bygelyks, is d'r in soarte fan keppelferkoarter. Bygelyks, wy hawwe op it stuit trije keppelingsferkoarters yn gebrûk foar ferskate doelen yn ferskate tsjinsten. Dit binne gewoan de gefolgen.
No sil ik de kaptein wêze fan 'e fanselssprekkende. Wat moat dien wurde? Earst moatte wy de tsjinst oerdrage oan in oare manager, in oar team. As jo teamleader noch net opgien is, dan moatte jo yn dit oare team, as jo begripe dat de tsjinst as in wees is, ien opnimme dy't der op syn minst wat fan begrypt.
It wichtichste ding: jo moatte de oerdrachtprosedueres yn bloed skreaun hawwe. Yn ús gefal kontrolearje ik dit normaal, om't ik it allegear nedich is om te wurkjen. Behearders hawwe it nedich dat it fluch levere wurdt, en wat der letter mei bart, is foar harren net mear sa wichtich.
De folgjende manier om in wees te meitsjen is "Wy sille it útbestege dwaan, it sil rapper wêze, en dan jouwe wy it oer oan it team." It is dúdlik dat elkenien wat plannen hat yn it team, in beurt. Faak tinkt in saaklike klant dat de outsourcer itselde sil dwaan as de technyske ôfdieling dy't it bedriuw hat. Hoewol't har motivators binne oars. D'r binne frjemde technologyske oplossingen en frjemde algoritmyske oplossingen yn útsourcing.
Bygelyks, wy hiene in tsjinst dy't hie Sphinx op ferskate ûnferwachte plakken. Ik sil dy letter fertelle wat ik dwaan moast.
Outsourcers hawwe sels skreaune kaders. Dit is gewoan keale PHP mei copy-paste fan in earder projekt, wêr't jo allerhanne dingen kinne fine. Ynsetskripts binne in grut nadeel as jo wat komplekse Bash-skripts moatte brûke om ferskate rigels yn guon bestân te feroarjen, en dizze ynsetskripts wurde neamd troch guon tredde skripts. As resultaat feroarje jo it ynsetsysteem, kies wat oars, hop, mar jo tsjinst wurket net. Want dêr wie it nedich om noch 8 keppelings te setten tusken ferskate mappen. Of it komt foar dat tûzen platen wurkje, mar hûnderttûzen net mear wurkje.
Ik sil trochgean as kaptein. It akseptearjen fan in útbestege tsjinst is in ferplichte proseduere. Hat immen oait in útbestege tsjinst oankommen en net oeral akseptearre? Dit is net sa populêr, fansels, as in weestsjinst, mar dochs.
De tsjinst moat wurde kontrolearre, de tsjinst moat wurde hifke, wachtwurden moatte wurde feroare. Wy hienen in saak doe't se ús in tsjinst joegen, d'r is in adminpaniel "as login == 'admin' && wachtwurd == 'admin' ...", it is rjocht yn 'e koade skreaun. Wy sitte en tinke, en minsken skriuwe dit yn 2018?
It testen fan opslachkapasiteit is ek in needsaaklik ding. Jo moatte sjen nei wat sil barre op hûndert tûzen records, noch foardat jo sette dizze tsjinst earne yn produksje.
D'r moat gjin skamte wêze om in tsjinst foar ferbettering te stjoeren. As jo sizze: "Wy sille dizze tsjinst net akseptearje, wy hawwe 20 taken, doch se, dan sille wy akseptearje," is dit normaal. Jo gewisse moat net sear wurde troch it feit dat jo in manager ynstelle of dat it bedriuw jild fergriemt. It bedriuw sil dan mear útjaan.
Wy hiene in saak doe't wy besletten in proefprojekt út te besteegjen.
It waard levere op tiid, en dit wie de ienige kwaliteit kritearium. Dêrom hawwe wy noch in proefprojekt makke, dat net iens mear in proef wie. Dizze tsjinsten waarden akseptearre, en troch bestjoerlike middels seine se, hjir is jo koade, hjir is it team, hjir is jo manager. De tsjinsten binne eins al begûn te meitsjen winst. Tagelyk binne se trouwens noch weesbern, gjinien begrypt hoe't se wurkje, en managers dogge har bêst om har taken te ûntkennen.
D'r is in oar geweldich konsept - guerrillaûntwikkeling. As guon ôfdieling, meastal de marketing ôfdieling, wol te testen in hypoteze en oarders de hiele tsjinst útbestege. Ferkear begjint deryn te streamen, se slute de dokuminten, tekenje dokuminten mei de oannimmer, komme yn wurking en sizze: "Dudes, wy hawwe hjir in tsjinst, it hat al ferkear, it bringt ús jild, litte wy it akseptearje." Wy wiene as, "Oppa, hoe kin dat wêze."
En in oare manier om in weestsjinst te krijen: as ien team ynienen laden fynt, seit it management: "Litte wy de tsjinst fan dit team oerdrage oan in oar team, it hat in lytsere lading." En dan sille wy it oermeitsje nei in tredde team en de manager feroarje. En op it lêst ha wy wer in wees.
Wat is it probleem mei weesbern?
Wa wit net, dit is it slachskip Wasa grutbrocht yn Sweden, ferneamd om it feit dat it sonk 5 minuten nei lansearring. En de kening fan Sweden hat trouwens gjinien dêrfoar eksekutearre. It waard boud troch twa generaasjes yngenieurs dy't net wisten hoe't se sokke skippen bouwe. Natuerlik effekt.
It skip hie trouwens folle slimmer sinke kinnen, bygelyks doe't de kening der al earne op ried yn in stoarm. En sa, hy ferdronken fuort, neffens Agile is it goed om betiid te mislearjen.
As wy betiid mislearje, binne d'r meastentiids gjin problemen. Bygelyks, tidens akseptaasje waard it stjoerd foar revyzje. Mar as wy mislearje al yn produksje, as jild wurdt ynvestearre, dan kinne der problemen. Gefolgen, sa't se neamd wurde yn it bedriuwslibben.
Wêrom weestsjinsten gefaarlik binne:
- De tsjinst kin ynienen brekke.
- De tsjinst duorret lang om te reparearjen of wurdt hielendal net reparearre.
- Feiligensproblemen.
- Problemen mei ferbetterings en updates.
- As in wichtige tsjinst brekt, lijt de reputaasje fan it bedriuw.
Wat te dwaan mei weestsjinsten?
Ik sil werhelje wat te dwaan. Earst moat der dokumintaasje wêze. 7 jier by Banki.ru learde my dat testers net it wurd fan 'e ûntwikkelders moatte nimme, en operaasjes moatte it wurd fan elkenien net nimme. Wy moatte kontrolearje.
Twadder is it nedich om ynteraksjediagrammen te skriuwen, om't it bart dat tsjinsten dy't net heul goed ûntfongen binne ôfhinklikens befetsje dy't gjinien oer sei. Bygelyks, de ûntwikkelders ynstalleare de tsjinst op har kaai foar guon Yandex.Maps of Dadata. Jo hawwe rûn út frije limyt, alles is brutsen, en do witst net wat der bard at all. Alle sokke rakes moatte wurde beskreaun: de tsjinst brûkt Dadata, SMS, wat oars.
Tredde, wurkje mei technyske skuld. As jo in soarte fan krukken dogge of in tsjinst akseptearje en sizze dat der wat dien wurde moat, moatte jo derfoar soargje dat it dien wurdt. Want dan kin bliken dat it lytse gat is net sa lyts, en do silst falle troch it.
Mei arsjitektoanyske taken hienen wy in ferhaal oer Sphinx. Ien fan 'e tsjinsten brûkt Sphinx te fieren listen. Krekt in paginearre list, mar it waard opnij yndeksearre eltse nacht. It waard gearstald út twa yndeksen: ien grutte waard yndeksearre eltse nacht, en der wie ek in lytse yndeks dat waard geschroefd oan it. Elke dei, mei in kâns fan 50% fan bombardeminten of net, ferûngelokke de yndeks tidens de berekkening, en ús nijs stoppe mei bywurkjen op 'e haadside. Earst duorre it 5 minuten foar't de yndeks opnij yndeksearre waard, doe groeide de yndeks, en op in stuit begon it 40 minuten te nimmen om opnij te yndeksearjen. Doe't wy dit útsnijden, sloegen wy opluchting út, want it wie dúdlik dat der wat mear tiid foarby soe en ús yndeks wer foltiids yndeksearre wurde soe. Dit sil in mislearring wêze foar ús portal, d'r is acht oeren gjin nijs - dat is it, it bedriuw is stoppe.
Plan foar it wurkjen mei in weestsjinst
Eins is dit heul lestich om te dwaan, om't devops oer kommunikaasje giet. Jo wolle goed wêze mei jo kollega's, en as jo jo kollega's en managers mei regeljouwing oer de holle slaan, kinne se tsjinstridige gefoelens hawwe foar de minsken dy't dit dogge.
Neist al dizze punten is der noch in wichtich ding: spesifike minsken moatte ferantwurdlik wêze foar elke spesifike tsjinst, foar elke spesifike paragraaf fan 'e ynsetproseduere. As der gjin minsken binne en jo moatte wat oare minsken oanlûke om dizze hiele saak te bestudearjen, wurdt it dreech.
As dit alles net holp, en jo weestsjinst is noch altyd in wees, gjinien wol it oannimme, dokumintaasje is net skreaun, it team dat yn dizze tsjinst oproppen is wegeret neat te dwaan, d'r is in ienfâldige manier - om opnij te meitsjen alles.
Dat is, jo nimme de easken foar de tsjinst op 'e nij en skriuwe in nije tsjinst, better, op in better platfoarm, sûnder frjemde technologyske oplossings. En jo migrearje nei it yn 'e striid.
Wy hienen in situaasje doe't wy namen in tsjinst op Yii 1 en realisearre dat wy koenen net ûntwikkelje it fierder, om't wy rûnen út fan ûntwikkelders dy't koe skriuwe goed op Yii 1. Alle ûntwikkelders skriuwe goed op Symfony XNUMX. Wat te dwaan? Wy hawwe tiid tawiisd, in team tawiisd, in manager tawiisd, it projekt opnij skreaun en it ferkear der soepel nei oerskeakele.
Hjirnei kin de âlde tsjinst wiske wurde. Dit is myn favorite proseduere, as jo wat tsjinst moatte nimme en skjinmeitsje fan it konfiguraasjebehearsysteem en dan troch gean en sjen dat alle auto's yn produksje binne útskeakele, sadat de ûntwikkelders gjin spoaren hawwe. De repository bliuwt yn Git.
Dit is alles wêr't ik oer prate woe, ik bin ree om te besprekken, it ûnderwerp is holivar, in protte hawwe deryn swommen.
De dia's seine dat jo talen ferienige hawwe. In foarbyld wie it feroarjen fan grutte fan ôfbyldings. Is it echt nedich om it strikt te beheinen ta ien taal? Om't ôfbylding feroarje yn PHP, goed, koe eins dien wurde yn Golang.
Yn feite is it opsjoneel, lykas alle praktiken. Miskien, yn guon gefallen, is it sels net winske. Mar jo moatte begripe dat as jo in technyske ôfdieling hawwe yn in bedriuw fan 50 minsken, 45 fan harren binne PHP-spesjalisten, in oare 3 binne devops dy't Python, Ansible, Puppet en soksawat witte, en mar ien fan har skriuwt yn guon soarte fan taal. guon Go image resizing tsjinst, en as it fuort giet, giet de ekspertize derby. En tagelyk moatte jo sykje nei in merkspesifike ûntwikkelder dy't dizze taal ken, foaral as it seldsum is. Dat is, út in organisatoarysk eachpunt is dit problematysk. Fanút it eachpunt fan devops moatte jo net allinich wat klear makke set spielboeken klonearje dy't jo brûke om tsjinsten yn te setten, mar jo moatte se opnij skriuwe.
Wy bouwe op it stuit in tsjinst op Node.js, en dit sil gewoan in platfoarm yn 'e buert wêze foar elke ûntwikkelder mei in aparte taal. Mar wy sieten en tochten dat it spul de kears wurdich wie. Dat is, dit is in fraach foar jo om te sitten en nei te tinken.
Hoe kontrolearje jo jo tsjinsten? Hoe sammelje en kontrolearje jo logs?
Wy sammelje logs yn Elasticsearch en sette se yn Kibana, en ôfhinklik fan oft it produksje- of testomjouwings is, wurde dêr ferskate samlers brûkt. Earne Lumberjack, earne oars wat oars, wit ik net. En der binne noch guon plakken yn bepaalde tsjinsten dêr't wy ynstallearje Telegraf en sjitte earne oars apart.
Hoe libje mei Puppet en Ansible yn deselde omjouwing?
Yn feite hawwe wy no twa omjouwings, ien is Puppet, de oare is Ansible. Wy wurkje om se te hybridisearjen. Ansible is in goed ramt foar inisjele opset, Puppet is in min ramt foar initial opset, om't it praktysk wurk direkt op it platfoarm fereasket, en Puppet soarget foar konfiguraasjekonverginsje. Dit betsjut dat it platfoarm himsels yn in aktuele steat hâldt, en om de ansibilisearre masine by de tiid te hâlden, moatte jo der altyd mei wat frekwinsje playbooks op rinne. Dat is it ferskil.
Hoe behâlde jo kompatibiliteit? Hawwe jo konfiguraasjes yn sawol Ansible as Puppet?
Dit is ús grutte pine, wy behâlde kompatibiliteit mei ús hannen en tinke oer hoe't jo no earne fierder kinne fan dit alles. It docht bliken dat Puppet rôlet út pakketten en ûnderhâldt guon keppelings dêr, en Ansible, bygelyks, rôlet út de koade en past de nijste applikaasje configs dêr.
De presintaasje gie oer ferskate ferzjes fan Ruby. Hokker oplossing?
Wy binne dit op ien plak tsjinkaam, en wy moatte it altyd yn 'e holle hâlde. Wy hawwe gewoan it diel útskeakele dat rûn op 'e Ruby dy't net kompatibel wie mei de applikaasjes en hâlden it apart.
Dit jier konferinsje sil plakfine op 7 desimber by Technopolis. Wy akseptearje oanfragen foar rapporten oant 11 novimber. ús as jo prate wolle.
Oanmelde foar dielnimmers is iepen, doch mei!
Boarne: www.habr.com