Andrey Nikolsky, bedryfsdirekteur van die Banki.ru-portaal, het op verlede jaar se konferensie gepraat oor weesdienste: hoe om 'n weeskind in die infrastruktuur te identifiseer, hoekom weesdienste sleg is, wat om daarmee te doen, en wat om te doen as niks help nie.
Onder die snit is die teksweergawe van die verslag.
Hallo kollegas! My naam is Andrey, ek bestuur bedrywighede by Banki.ru.
Ons het groot dienste, dit is sulke monolitiese dienste, daar is dienste in 'n meer klassieke sin, daar is baie klein dienste. In my arbeider-boer-terminologie sê ek dat as die diens eenvoudig en klein is, dan is dit mikro, en as dit nie baie eenvoudig en nie klein is nie, dan is dit net 'n diens.
Dienste voordele
Ek sal vinnig kyk na die voordele van dienste.
Die eerste is skaal. Jy kan vinnig iets op die diens maak en produksie begin. Jy het verkeer ontvang, jy het die diens gekloon. Meer verkeer het aangekom, jy het gekloon en leef daarmee saam. Dit is 'n goeie bonus, en in beginsel, toe ons begin het, is dit vir ons as die belangrikste beskou, hoekom ons dit alles doen.
Tweedens, geïsoleerde ontwikkeling, wanneer jy verskeie ontwikkelingspanne het, verskeie verskillende ontwikkelaars in elke span, en elke span werk aan een of ander diens.
Met opdragte is daar 'n nuanse. Ontwikkelaars is anders. En daar is bv. . Ek het dit die eerste keer by Maxim Dorofeev gesien. Soms is sneeuvlokmense in sommige spanne en sommige nie. Dit maak die verskillende dienste wat in die maatskappy gebruik word 'n bietjie ongelyk.
Kyk na die prentjie: dit is 'n goeie ontwikkelaar, hy het groot hande, hy kan baie doen. Die grootste probleem is waar hierdie hande vandaan groei.
Dienste maak dit moontlik om verskillende programmeertale te gebruik wat meer geskik is vir verskillende take. Sommige diens in Go, sommige in Erlang, sommige in Ruby, sommige in PHP, sommige in Python. Oor die algemeen kan jy baie wyd omdraai. Ook hier is daar nuanses.
Diensgeoriënteerde argitektuur gaan hoofsaaklik oor devops. Dit wil sê, as jy nie outomatisering het nie, is daar geen ontplooiingsproses nie, as jy dit handmatig opstel, kan jou konfigurasies van diensinstansie tot instansie verander, en jy moet soontoe gaan om iets te doen, dan is jy in die hel.
Byvoorbeeld, jy het 20 dienste, en jy moet met die hand ontplooi, jy het 20 konsoles, en jy druk Enter terselfdertyd, soos 'n ninja. Dit is nie baie goed nie.
As jy 'n diens het na toetsing (as daar natuurlik getoets word), en jy moet dit nog met 'n lêer klaarmaak sodat dit in produksie werk, het ek ook slegte nuus vir jou.
As jy staatmaak op spesifieke Amazon-dienste en in Rusland werk, dan het jy twee maande gelede ook "Alles is aan die brand, ek is fine, alles is cool."
Ons gebruik Ansible vir ontplooiingsoutomatisering, Puppet vir konvergensie, Bamboo vir ontplooiingsoutomatisering, Confluence om dit alles op een of ander manier te beskryf.
Ek sal nie in detail hieroor uitwei nie, want die verslag gaan meer oor interaksiepraktyke, en nie oor tegniese implementering nie.
Ons het byvoorbeeld probleme gehad dat Puppet op die bediener met Ruby 2 werk, en sommige toepassings is onder Ruby 1.8 geskryf, en hulle werk nie saam nie. Daar is 'n soort gogga aan die gang. En wanneer jy verskeie weergawes van Ruby op dieselfde masjien moet hou, loop jy gewoonlik probleme op.
Ons gee byvoorbeeld vir elke ontwikkelaar 'n platform wat omtrent alles het wat ons het, al die dienste wat ontwikkel kan word sodat hy 'n geïsoleerde omgewing het, hy kan dit breek en bou soos hy wil.
Soms het jy 'n spesiaal saamgestelde pakket nodig met ondersteuning vir iets daar. Dit is taai genoeg. Ek het na 'n verslag geluister waar die docker-beeld 45 GB weeg. In Linux is dit natuurlik eenvoudiger, alles is kleiner daar, maar steeds sal daar nie genoeg plekke wees nie.
Wel, daar is botsende afhanklikhede, wanneer jy een stuk van die projek het, hang af van die biblioteek van een weergawe, 'n ander stuk van die projek hang af van 'n ander weergawe, en die biblioteke is glad nie saamgestel nie.
Ons het werwe en dienste op PHP 5.6, ons is skaam vir hulle, maar wat kan ons doen. Dit is ons een platform. Daar is werwe en dienste op PHP 7, daar is meer van hulle, ons is nie skaam vir hulle nie. En elke ontwikkelaar het sy eie basis, waar hy gelukkig saag.
As jy in 'n maatskappy in een taal skryf, dan klink drie virtuele masjiene per ontwikkelaar normaal. As jy verskillende programmeertale het, word die situasie erger.
U het werwe en dienste hieroor, hierop, dan 'n ander webwerf vir Go, een webwerf vir Ruby, nog 'n paar Redis aan die kant. As gevolg hiervan verander dit alles in 'n groot veld vir ondersteuning, en die hele tyd kan iets hiervan breek.
Daarom het ons die goedjies van die programmeertaal vervang met die gebruik van verskillende raamwerke, aangesien PHP-raamwerke heeltemal verskil, hulle het verskillende vermoëns, verskillende gemeenskappe, verskillende ondersteuning. En jy kan 'n diens skryf sodat jy reeds iets daarvoor gereed het.
Elke diens het sy eie span
Ons grootste voordeel, wat oor etlike jare uitgekristalliseer het, is dat elke diens sy eie span het. Dit is gerieflik vir 'n groot projek, jy kan tyd bespaar op dokumentasie, bestuurders ken hul projek goed.
Take van ondersteuning kan perfek gegooi word. Die versekeringsdiens het byvoorbeeld onklaar geraak. En dadelik gaan die span wat met versekering handel, dit herstel.
Nuwe kenmerke word vinnig gemaak, want wanneer jy een of ander atoomdiens het, kan jy vinnig iets daarin skroef.
En wanneer jy jou diens breek, en dit gebeur onvermydelik, het jy nie ander mense se dienste seergemaak nie, en ontwikkelaars met stukkies van ander spanne kom nie na jou gehardloop en sê: "Ay-ay, moenie dit doen nie."
Soos altyd is daar nuanses. Ons het stabiele spanne, bestuurders is vasgenael aan die span. Daar is duidelike dokumente, bestuurders monitor dit alles noukeurig. Elke span met 'n bestuurder het verskeie dienste, en daar is 'n spesifieke punt van bevoegdheid.
As die opdragte sweef (dit word ook soms deur ons gebruik), is daar 'n goeie metode genaamd die "sterkaart".
Jy het 'n lys van dienste en mense. 'n Sterretjie beteken dat 'n persoon 'n deskundige in hierdie diens is, 'n boek beteken dat 'n persoon hierdie diens bestudeer. Die taak van 'n persoon is om die boek vir 'n asterisk te verander. En as niks oorkant die diens geskryf is nie, begin probleme, waaroor ek sal voortgaan om te praat.
Hoe verskyn weesdienste?
Die eerste probleem, die eerste manier om 'n weesdiens in jou infrastruktuur te kry, is die afdanking van mense. Het iemand ervaar wanneer spertye van 'n besigheid af kom voordat take beraam is? Soms gebeur dit dat sperdatums kort is en daar eenvoudig nie genoeg tyd is vir dokumentasie nie. "Ons moet die diens aan produksie oorgee, dan sal ons dit byvoeg."
As die span klein is, gebeur dit dat dit een ontwikkelaar het wat alles skryf, die res is in die vlerke. "Ek het die hoofargitektuur geskryf, jy gee vir my die koppelvlakke." Dan gaan die bestuurder byvoorbeeld op 'n stadium. En gedurende hierdie tydperk, toe die bestuurder weg is, en 'n nuwe een is nog nie aangestel nie, besluit die ontwikkelaars self waarheen die diens beweeg, wat daar gebeur. En soos ons weet (kom ons gaan terug 'n paar skyfies), sommige spanne het sneeuvlok mense, soms 'n span lei sneeuvlok. Dan gee hy op, en ons kry 'n diensweeskind.
Terselfdertyd gaan take van ondersteuning en besigheid nie weg nie, dit vestig in die agterstand. As daar argitektoniese foute tydens die ontwikkeling van die diens was, vestig dit ook in die agterstand. Die diens is stadig besig om te verneder.
Hoe om 'n weeskind te identifiseer?
Hierdie lys beskryf die situasie goed. Het iemand iets oor infrastruktuur geleer?
Oor gedokumenteerde oplossings: daar is 'n diens en oor die algemeen werk dit, dit het 'n handleiding van twee bladsye oor hoe om daarmee te werk, maar niemand weet hoe dit binne werk nie.
Of daar is byvoorbeeld 'n soort skakelverkorter. Ons het byvoorbeeld tans drie skakelverkorters wat vir verskillende doeleindes in verskillende dienste gebruik word. Dit is net die gevolge.
Nou sal ek die kaptein van die ooglopende wees. Wat moet gedoen word? Eerstens moet u die diens na 'n ander bestuurder, 'n ander span, oordra. As jou spanleier nog nie opgehou het nie, wanneer jy verstaan dat die diens soos 'n weeskind is, moet jy iemand wat ten minste iets daarvan verstaan by hierdie ander span insluit.
Die belangrikste ding: jy moet oordragprosedures in bloed geskryf hê. In ons geval volg ek dit gewoonlik, want ek het dit nodig om te werk. Bestuurders moet dit vinnig oorhandig word, en wat later daarmee gaan gebeur, is nie vir hulle so belangrik nie.
Die volgende manier om 'n weeskind te maak is "Kom ons doen dit uitgekontrakteer, dit sal vinniger wees, en dan sal ons dit na die span oordra." Dit is duidelik dat almal 'n paar planne in die span het, draai. Dikwels dink 'n besigheidskliënt dat die uitkontrakter dieselfde sal doen as die tegniese afdeling wat die maatskappy het. Alhoewel hul motiverings verskil. Daar is vreemde tegnologiese oplossings en vreemde algoritmiese oplossings in uitkontraktering.
Ons het byvoorbeeld 'n diens gehad wat Sphinx op verskeie onverwagte plekke gehad het. Ek sal jou later vertel wat ek moes doen.
Uitkontrakteerders het selfgeskrewe raamwerke. Dit is eenvoudig PHP-kopie-geplak van 'n vorige projek waar jy alles kan vind. Groot krukke in ontplooiingsskrifte, wanneer u verskeie reëls in een of ander lêer met 'n paar komplekse Bash-skrifte moet verander, terwyl hierdie ontplooiingsskrifte deur 'n derde skrif geroep word. As gevolg hiervan verander jy die ontplooiingstelsel, kies iets anders, hop, maar die diens werk nie vir jou nie. Want daar was dit nodig om nog 8 skakels tussen verskillende pappas te sit. Of dit gebeur dat 'n duisend rekords werk, maar 'n honderdduisend is nie meer daar nie.
Ek sal aanhou om kaptein te wees. Aanvaarding van diens deur uitkontraktering is 'n verpligte prosedure. Wie het al ervaar dat 'n uitgekontrakteerde diens opdaag, maar dit word nêrens aanvaar nie? Dit is natuurlik nie so gewild soos ’n weesdiens nie, maar tog.
Die diens moet nagegaan word, die diens moet hersien word, wagwoorde moet verander word. Ons het 'n geval gehad toe 'n diens na ons gegooi is, daar is 'n adminpaneel "as login == 'admin' && wagwoord == 'admin'...", dit is reg in die kode geskryf. Ons sit en dink, en mense skryf dit in 2018?
Om die hoeveelheid berging te toets, is ook 'n noodsaaklike ding. Jy moet kyk wat sal gebeur op honderdduisend rekords, selfs voordat jy hierdie diens iewers in produksie plaas.
Om 'n diens vir hersiening te stuur, behoort nie 'n skande te wees nie. As jy sê: "Ons sal nie hierdie diens aanvaar nie, ons het 20 take, doen dit, dan sal ons dit aanvaar," is dit normaal. Die gewete moet nie skade doen dat jy 'n bestuurder op die been bring of dat 'n besigheid geld sal spandeer nie. Die besigheid sal meer spandeer.
Ons het 'n saak gehad toe ons besluit het om 'n loodsprojek uit te kontrakteer.
Dit is betyds oorhandig, en dit was die enigste kwaliteitmaatstaf. Daarom het ons nog 'n loodsprojek gemaak, nie eers heeltemal 'n loodsprojek nie. Hulle het hierdie dienste aanvaar, hulle het op administratiewe wyse gesê, hier is jou kode, hier is die span, hier is jou bestuurder. Die dienste het reeds wins begin maak. Terselfdertyd is hulle eintlik nog weeskinders, niemand verstaan hoe hulle werk nie, en bestuurders ontken op elke moontlike manier hul take.
Daar is nog 'n wonderlike konsep - guerrilla-ontwikkeling. Wanneer een of ander departement, as 'n reël, 'n bemarkingsafdeling is, wil hulle 'n hipotese toets en 'n diens bestel wat heeltemal uitgekontrakteer is. Verkeer begin daarin stroom, hulle maak die dokumente toe, teken handelinge met die kontrakteur, kom in werking en sê: “Dudes, ons het 'n diens hier, dit het reeds verkeer, dit bring vir ons geld, kom ons aanvaar dit.” Ons is soos, "Oppa, hoekom."
En nog 'n manier om 'n weesdiens te kry: wanneer die een of ander span skielik gelaai blyk te wees, sê die bestuur: "Kom ons dra die diens van hierdie span oor na 'n ander span, dit het 'n kleiner vrag." En dan sal ons dit na die derde span oordra, en ons sal die bestuurder verander. En op die ou end het ons weer 'n weeskind.
Wat is die probleem met weeskinders?
Wie weet nie, dit is die slagskip Wasa wat in Swede grootgemaak is, bekend vir die feit dat sy 5 minute na die lansering verdrink het. En die koning van Swede het terloops niemand hiervoor tereggestel nie. Dit is gebou deur twee generasies ingenieurs wat nie geweet het hoe om sulke skepe te bou nie. Gereelde effek.
Die skip kan terloops baie erger sink, byvoorbeeld wanneer die koning reeds iewers in 'n storm daarop sou ry. En so, hy het dadelik verdrink, volgens rats is dit goed om vroeg te misluk.
As ons vroeg misluk, is daar gewoonlik geen probleem nie. Byvoorbeeld, ten tyde van aanvaarding, is hulle gestuur vir hersiening. En as ons reeds in produksie misluk het, toe die geld belê is, dan kan daar probleme wees. Gevolge, soos dit in besigheid genoem word.
Waarom weesdienste gevaarlik is:
- Die diens kan skielik breek.
- Diens word lankal herstel of glad nie herstel nie.
- Veiligheidsprobleme.
- Probleme met verbeterings en opdaterings.
- As 'n belangrike diens onklaar raak, ly die maatskappy se reputasie daaronder.
Wat om te doen met weesdienste?
Weereens herhaal ek wat om te doen. Eerstens moet daar dokumentasie wees. 7 jaar in Banki.ru het my geleer dat toetsers nie die woord van die ontwikkelaars moet neem nie, en die operasie moet nie die woord van almal aanvaar nie. Ons moet kyk.
Tweedens moet jy interaksiediagramme skryf, want dit gebeur dat dienste wat nie goed ontvang word nie afhanklikhede bevat waaroor niemand gesê het nie. Byvoorbeeld, die ontwikkelaars plaas die diens op hul sleutel tot sommige Yandex.Maps of na Dadata. Jy het nie meer vrye limiet gehad nie, alles is gebreek en jy weet glad nie wat gebeur het nie. Alle sulke harke moet beskryf word: die diens gebruik Dadata, Sms, iets anders.
Derdens, werk met tegniese skuld. Wanneer jy 'n soort krukke maak of 'n diens aanvaar en sê dat iets gedoen moet word, moet jy seker maak dat hulle dit doen. Want dan kan dit blyk dat die gaatjie nie so klein is nie, en jy sal daarin val.
Met argitektoniese take het ons 'n storie oor Sfinx gehad. In een van die dienste is Sphinx gebruik om lyste in te voer. Net 'n lys met paginering, maar dit is elke aand herindekseer. Dit is saamgestel uit twee indekse: een is elke aand deur 'n groot een geïndekseer, en daar was ook 'n klein indeks wat daaraan geheg was. Elke dag, met 'n waarskynlikheid van 50%, hetsy bombardering of nie, het die indeks gesukkel tydens die berekening, en die nuus het opgehou om op ons hoofblad by te werk. Eers was dit 5 minute terwyl die indeks herindekseer het, toe het die indeks gegroei, en op 'n stadium het dit vir 40 minute begin herindekseer. Toe ons dit uitsien, het ons 'n sug van verligting geslaak, want dit was duidelik dat 'n bietjie meer tyd sou verbygaan, en ons indeks sou voltyds herindekseer word. Dit sal 'n mislukking wees vir ons portaal, agt uur geen nuus nie - dit is dit, die besigheid het gestyg.
Weeskinddiensplan
Trouens, dit is baie moeilik om dit te doen, want devops gaan oor kommunikasie. Jy wil op goeie voet met jou kollegas wees, en wanneer jy kollegas en bestuurders met regulasies op die kop slaan, kan hulle botsende gevoelens ervaar teenoor daardie mense wat dit doen.
Benewens al hierdie punte is daar nog 'n belangrike ding: spesifieke mense moet verantwoordelik wees vir elke spesifieke diens, vir elke spesifieke afdeling van die ontplooiingsprosedure. Wanneer daar geen mense is nie en jy moet ander mense betrek, word dit moeilik om die hele ding te bestudeer.
As dit alles nie gehelp het nie, en jou weesdiens is steeds 'n weeskind, niemand wil dit na homself neem nie, die dokumentasie is nie geskryf nie, die span wat na hierdie diens geroep is weier om iets te doen, daar is 'n eenvoudige manier - om alles oor te doen.
Dit wil sê, jy neem weer die vereistes vir die diens en skryf 'n nuwe diens, beter, op 'n beter platform, sonder vreemde tegnologiese oplossings. En migreer daarna in die geveg.
Ons het 'n situasie gehad toe ons 'n diens op Yii 1 geneem het en besef het dat ons dit nie verder kon ontwikkel nie, want ons het nie meer ontwikkelaars gehad wat goed op Yii 1 kan skryf nie. Alle ontwikkelaars skryf goed op die derde Symfony. Wat om te doen? Ons het tyd toegewys, 'n span toegewys, 'n bestuurder toegewys, die projek herskryf en verkeer glad daarna oorgeskakel.
Daarna kan die ou diens uitgevee word. Dit is my gunsteling prosedure wanneer jy een of ander diens van die konfigurasiebestuurstelsel moet neem en skoonmaak en dan deurgaan om te sien dat al die motors in produksie gekanselleer word sodat die ontwikkelaars geen spore laat nie. Die bewaarplek in die git bly.
Dit is al waaroor ek wou praat, ek is gereed om te bespreek, die onderwerp is warm, baie het daarin geswem.
Die skyfies het gegaan oor die feit dat jy die tale verenig het. 'n Voorbeeld was beeldverandering. Is dit regtig nodig om streng tot een taal? Omdat die grootte van die beeld in PHP, wel, regtig in Golang gedoen kan word.
Trouens, dit is opsioneel, soos alle praktyke. Miskien, in sommige gevalle, selfs ongewens. Maar jy moet verstaan dat as jy 50 mense in die tegniese afdeling in jou maatskappy het, 45 van hulle PHP-spesialiste is, nog 3 is devops wat Python, Ansible, Puppet en so iets kan gebruik, en net een van hulle skryf in sommige van die Go-beeldveranderende diens, en wanneer dit vertrek, gaan die kundigheid daarmee weg. En om dit te doen, sal jy 'n markspesifieke ontwikkelaar moet soek wat hierdie taal ken, veral as dit skaars is. Dit wil sê, vanuit 'n organisatoriese oogpunt is dit problematies. Vanuit 'n devops-oogpunt sal jy nie net 'n paar klaargemaakte stel speelboeke moet kloon wat jy gebruik om dienste te ontplooi nie, maar jy sal dit weer moet skryf.
Ons sien nou 'n diens op Node.js, en dit sal net 'n platform naby wees vir elke ontwikkelaar met 'n aparte taal. Maar ons het gesit en dink die speletjie is die kers werd. Dit wil sê, die vraag hier is om te sit en dink.
Hoe monitor jy jou dienste? Hoe versamel en volg jy logs?
Ons versamel logs in Elasticsearch en sit dit in Kibana, en afhangend of dit produksie- of toetsomgewings is, word verskillende versamelaars daar gebruik. Iewers Houtkapper, iewers anders, onthou ek nie. En daar is nog 'n paar plekke in sekere dienste waar ons Telegraf installeer en afsonderlik iewers anders skiet.
Hoe om saam met Puppet en Ansible in dieselfde omgewing te leef?
Trouens, ons het nou twee omgewings, een is Puppet, die ander is Ansible. Ons werk daaraan om hulle te verbaster. Ansible is 'n goeie omgewing vir aanvanklike opstelling, Puppet is 'n slegte ding vir aanvanklike opstelling omdat dit handwerk direk met die webwerf vereis, en Puppet verseker konfigurasiekonvergensie. Dit beteken dat die platform homself op datum hou, en om die moontlike masjien op datum te hou, moet jy heeltyd speelboeke daarop laat loop met 'n mate van frekwensie. Hier is so 'n verskil.
Hoe handhaaf jy verenigbaarheid? Het jy konfigurasies in beide Ansible en Puppet?
Dit is ons groot pyn, ons ondersteun verenigbaarheid met ons hande en dink hoe om nou van al hierdie iewers heen te beweeg. Dit blyk dat Puppet pakkette rol en 'n paar skakels daar onderhou, en Ansible, byvoorbeeld, rol die kode en pas nuwe toepassingkonfigurasies daar aan.
Die aanbieding het gehandel oor verskillende weergawes van Ruby. Watter oplossing?
Ons het dit op een plek teëgekom, en ons moet dit heeltyd in ons koppe hou. Ons het eenvoudig die deel wat op die Ruby loop wat nie met toepassings versoenbaar was nie, afgeskakel en dit apart gehou.
Vanjaar se konferensie word op 7 Desember by Technopolis gehou. Tot 11 November aanvaar ons aansoeke vir verslae. ons as jy wil praat.
Registrasie vir deelnemers is oop, sluit by ons aan!
Bron: will.com