Direktør for driften af Banki.ru-portalen Andrey Nikolsky talte ved sidste års konference om forældreløse tjenester: hvordan man identificerer et forældreløst barn i infrastrukturen, hvorfor forældreløse tjenester er dårlige, hvad man skal gøre med dem, og hvad man skal gøre, hvis intet hjælper.
Under klippet er en tekstversion af rapporten.
Hej kolleger! Mit navn er Andrey, jeg leder driften hos Banki.ru.
Vi har store tjenester, det er sådanne monolitiske tjenester, der er tjenester i mere klassisk forstand, og der er meget små. I min arbejder-bonde-terminologi siger jeg, at hvis en tjeneste er enkel og lille, så er den mikro, og hvis den ikke er meget enkel og lille, så er den bare en tjeneste.
Fordele ved tjenester
Jeg vil hurtigt gennemgå fordelene ved tjenesterne.
Den første er skalering. Du kan hurtigt gøre noget ved servicen og starte produktionen. Du har modtaget trafik, du har klonet tjenesten. Du har mere trafik, du har klonet det og lever med det. Det er en god bonus, og i princippet, da vi startede, blev det betragtet som det vigtigste for os, hvorfor vi gør alt dette.
For det andet isoleret udvikling, når man har flere udviklingsteams, flere forskellige udviklere i hvert team, og hvert team udvikler sin egen service.
Med hold er der en nuance. Udviklere er forskellige. Og der er f.eks. . Jeg så dette første gang med Maxim Dorofeev. Nogle gange er snefnugfolk på nogle hold og ikke på andre. Dette gør de forskellige tjenester, der bruges på tværs af virksomheden, lidt ujævne.
Se på billedet: dette er en god udvikler, han har store hænder, han kan meget. Hovedproblemet er, hvor disse hænder kommer fra.
Tjenester gør det muligt at bruge forskellige programmeringssprog, der er mere egnede til forskellige opgaver. Nogle tjenester er i Go, nogle er i Erlang, nogle er i Ruby, noget er i PHP, noget er i Python. Generelt kan du udvide meget bredt. Der er også nuancer her.
Serviceorienteret arkitektur handler primært om devops. Det vil sige, at hvis du ikke har automatisering, er der ingen implementeringsproces, hvis du konfigurerer den manuelt, dine konfigurationer kan ændre sig fra serviceinstans til instans, og du skal gå der for at gøre noget, så er du i helvede.
For eksempel har du 20 tjenester, og du skal implementere i hånden, du har 20 konsoller, og du trykker samtidigt på "enter" som en ninja. Det er ikke særlig godt.
Hvis du har en service efter test (hvis der selvfølgelig er test), og du stadig mangler at afslutte den med en fil, så den fungerer i produktionen, har jeg også dårlige nyheder til dig.
Hvis du er afhængig af specifikke Amazon-tjenester og arbejder i Rusland, så havde du for to måneder siden også "Alt omkring brænder, jeg har det fint, alt er cool."
Vi bruger Ansible til at automatisere implementering, Puppet for convergence, Bamboo til at automatisere implementering og Confluence til på en eller anden måde at beskrive det hele.
Jeg vil ikke dvæle ved dette i detaljer, for rapporten handler mere om interaktionspraksis og ikke om teknisk implementering.
For eksempel har vi haft problemer, hvor Puppet på serveren arbejder med Ruby 2, men nogle applikationer er skrevet til Ruby 1.8, og de fungerer ikke sammen. Der går noget galt. Og når du skal køre flere versioner af Ruby på én maskine, begynder du normalt at få problemer.
For eksempel giver vi hver udvikler en platform, hvorpå der er omtrent alt, hvad vi har, alle de tjenester, der kan udvikles, så han har et isoleret miljø, han kan bryde det og bygge det, som han vil.
Det sker, at du har brug for en speciel kompileret pakke med støtte til noget der. Det er ret hårdt. Jeg lyttede til en rapport, hvor Docker-billedet vejer 45 GB. I Linux er det selvfølgelig enklere, alt er mindre der, men stadig vil der ikke være plads nok.
Nå, der er modstridende afhængigheder, når et stykke af projektet afhænger af et bibliotek af en version, afhænger et andet stykke af projektet af en anden version, og bibliotekerne er slet ikke installeret sammen.
Vi har websteder og tjenester i PHP 5.6, vi skammer os over dem, men hvad kan vi gøre? Dette er vores ene side. Der er websteder og tjenester på PHP 7, der er flere af dem, vi skammer os ikke over dem. Og hver udvikler har sin egen base, hvor han med glæde saver.
Hvis du skriver i en virksomhed på ét sprog, så lyder tre virtuelle maskiner pr. udvikler normalt. Hvis du har forskellige programmeringssprog, så bliver situationen værre.
Du har websteder og tjenester på dette, på dette, så et andet websted for Go, et websted for Ruby og nogle andre Redis på siden. Som et resultat bliver alt dette til et stort felt for støtte, og hele tiden kan noget af det gå i stykker.
Derfor erstattede vi fordelene ved programmeringssproget med brugen af forskellige frameworks, da PHP frameworks er ret forskellige, de har forskellige muligheder, forskellige fællesskaber og forskellig support. Og du kan skrive en service, så du allerede har noget klar til den.
Hver tjeneste har sit eget team
Vores største fordel, som har udkrystalliseret sig over flere år, er, at hver service har sit eget team. Dette er praktisk til et stort projekt, du kan spare tid på dokumentation, ledere kender deres projekt godt.
Du kan nemt sende opgaver fra support. For eksempel brød forsikringstjenesten sammen. Og straks går holdet, der beskæftiger sig med forsikring, for at ordne det.
Nye funktioner bliver hurtigt skabt, for når man har én atomtjeneste, kan man hurtigt skrue noget ind i den.
Og når du bryder din tjeneste, og dette uundgåeligt sker, påvirkede du ikke andres tjenester, og udviklere med bits fra andre teams kommer ikke løbende hen til dig og siger: "Åh, gør det ikke."
Som altid er der nuancer. Vi har stabile hold, ledere er naglet til holdet. Der er klare dokumenter, ledere overvåger alt nøje. Hvert team med en leder har flere services, og der er et specifikt kompetencepunkt.
Hvis holdene flyder (det bruger vi også nogle gange), er der en god metode kaldet "stjernekortet".
Du har en liste over tjenester og personer. En stjerne betyder, at personen er ekspert i denne tjeneste, en bog betyder, at personen studerer denne tjeneste. Personens opgave er at ændre hæftet til en stjerne. Og hvis der ikke er skrevet noget foran tjenesten, begynder problemerne, som jeg vil tale om yderligere.
Hvordan fremstår forældreløse tjenester?
Det første problem, den første måde at få en forældreløs service i din infrastruktur er at fyre folk. Har nogen nogensinde fået en virksomhed til at overholde deadlines, før opgaverne blev vurderet? Nogle gange sker det, at deadlines er stramme, og der simpelthen ikke er tid nok til dokumentation. "Vi skal overdrage servicen til produktionen, så tilføjer vi den."
Hvis holdet er lille, sker det, at der er én udvikler, der skriver alt, resten er i kulissen. "Jeg skrev den grundlæggende arkitektur, lad os tilføje grænsefladerne." Så på et tidspunkt går lederen for eksempel. Og i denne periode, hvor lederen er gået, og en ny endnu ikke er udpeget, bestemmer udviklerne selv, hvor tjenesten skal hen, og hvad der sker der. Og som vi ved (lad os gå et par dias tilbage), er der i nogle hold snefnug-folk, nogle gange en snefnug-holdleder. Så siger han op, og vi får en forældreløs gudstjeneste.
Samtidig forsvinder opgaver fra support og fra erhvervslivet ikke, de ender i efterslæbet. Hvis der var arkitektoniske fejl under udviklingen af tjenesten, ender de også i efterslæbet. Servicen forringes langsomt.
Hvordan identificerer man en forældreløs?
Denne liste beskriver situationen godt. Hvem lærte noget om deres infrastruktur?
Om dokumenterede work-arounds: der er en tjeneste, og den virker generelt, den har en to-siders manual om, hvordan man arbejder med den, men ingen ved, hvordan den fungerer indeni.
Eller der er for eksempel en form for linkforkorter. For eksempel har vi i øjeblikket tre linkforkortere i brug til forskellige formål i forskellige tjenester. Det er kun konsekvenserne.
Nu vil jeg være kaptajn for det åbenlyse. Hvad skal der gøres? Først skal vi overføre tjenesten til en anden manager, et andet team. Hvis din teamleder endnu ikke er stoppet, så i dette andet team, når du forstår, at tjenesten er som en forældreløs, skal du inkludere en person, der forstår i det mindste noget om det.
Det vigtigste: du skal have overførselsprocedurerne skrevet i blod. I vores tilfælde overvåger jeg normalt dette, fordi jeg har brug for, at det hele fungerer. Ledere har brug for, at det bliver leveret hurtigt, og hvad der senere sker med det, er ikke længere så vigtigt for dem.
Den næste måde at gøre en forældreløs på er "Vi vil gøre det outsourcet, det vil være hurtigere, og så overdrager vi det til holdet." Det er klart, at alle har nogle planer i holdet, en tur. Ofte tror en erhvervskunde, at outsourceren vil gøre det samme som den tekniske afdeling, som virksomheden har. Selvom deres motivationsfaktorer er forskellige. Der er mærkelige teknologiske løsninger og mærkelige algoritmiske løsninger i outsourcing.
For eksempel havde vi en tjeneste, der havde Sphinx forskellige uventede steder. Jeg fortæller dig senere, hvad jeg skulle gøre.
Outsourcere har selvskrevne rammer. Dette er blot bare PHP med copy-paste fra et tidligere projekt, hvor du kan finde alle mulige ting. Implementeringsscripts er en stor ulempe, når du skal bruge nogle komplekse Bash-scripts til at ændre flere linjer i en fil, og disse implementeringsscripts kaldes af et tredje script. Som et resultat ændrer du implementeringssystemet, vælger noget andet, hop, men din tjeneste virker ikke. For der var det nødvendigt at lægge 8 links mere mellem forskellige mapper. Eller det sker, at tusind plader virker, men hundrede tusinde ikke længere virker.
Jeg fortsætter som kaptajn. At acceptere en outsourcet service er en obligatorisk procedure. Er der nogen, der nogensinde har fået en outsourcet service til at ankomme og ikke blive accepteret nogen steder? Dette er selvfølgelig ikke så populært som en forældreløs tjeneste, men alligevel.
Tjenesten skal tjekkes, tjenesten skal gennemgås, adgangskoder skal ændres. Vi havde en sag, da de gav os en service, der er et admin panel "hvis login == 'admin' && password == 'admin'...", det er skrevet lige i koden. Vi sidder og tænker, og folk skriver det her i 2018?
Test af lagerkapacitet er også en nødvendig ting. Du skal se på, hvad der vil ske på hundrede tusinde plader, selv før du sætter denne service i produktion et sted.
Der burde ikke være nogen skam i at sende en service til forbedring. Når du siger: "Vi vil ikke acceptere denne service, vi har 20 opgaver, gør dem, så vil vi acceptere," er det normalt. Din samvittighed skal ikke blive såret af, at du sætter en leder, eller at virksomheden spilder penge. Virksomheden vil så bruge mere.
Vi havde en sag, da vi besluttede at outsource et pilotprojekt.
Det blev leveret til tiden, og det var det eneste kvalitetskriterium. Derfor lavede vi endnu et pilotprojekt, som ikke engang egentlig var et pilotprojekt længere. Disse tjenester blev accepteret, og gennem administrative midler sagde de, her er din kode, her er holdet, her er din leder. Tjenesterne er faktisk allerede begyndt at give overskud. Samtidig er de faktisk stadig forældreløse, ingen forstår, hvordan de arbejder, og ledere gør deres bedste for at fornægte deres opgaver.
Der er et andet fantastisk koncept - guerillaudvikling. Når en afdeling, normalt marketingafdelingen, ønsker at teste en hypotese og bestiller hele tjenesten outsourcet. Trafikken begynder at strømme ind i det, de lukker dokumenterne, underskriver dokumenter med entreprenøren, kommer i drift og siger: "Dudes, vi har en service her, den har allerede trafik, den bringer os penge, lad os acceptere det." Vi tænkte: "Oppa, hvordan kan det være."
Og en anden måde at få en forældreløs service på: Når et team pludselig finder sig selv lastet, siger ledelsen: "Lad os overføre dette teams service til et andet team, det har en mindre belastning." Og så overfører vi det til et tredje hold og skifter manager. Og til sidst har vi fået et forældreløst barn igen.
Hvad er problemet med forældreløse børn?
Hvem ved ikke, dette er slagskibet Wasa rejst i Sverige, berømt for det faktum, at det sank 5 minutter efter søsætning. Og kongen af Sverige henrettede i øvrigt ingen for dette. Det blev bygget af to generationer af ingeniører, der ikke vidste, hvordan man bygger sådanne skibe. Naturlig effekt.
Skibet kunne i øvrigt være sunket på en meget værre måde, for eksempel når kongen allerede red på det et sted i en storm. Og så druknede han med det samme, ifølge Agile er det godt at fejle tidligt.
Hvis vi fejler tidligt, er der normalt ingen problemer. For eksempel blev det under accepten sendt til revision. Men hvis vi svigter allerede i produktionen, når der investeres penge, så kan der være problemer. Konsekvenser, som det hedder i erhvervslivet.
Hvorfor forældreløse tjenester er farlige:
- Tjenesten kan pludselig bryde.
- Servicen tager lang tid at reparere eller repareres slet ikke.
- Sikkerhedsproblemer.
- Problemer med forbedringer og opdateringer.
- Hvis en vigtig service bryder sammen, lider virksomhedens omdømme.
Hvad skal man gøre med forældreløse tjenester?
Jeg gentager, hvad jeg skal gøre igen. For det første skal der være dokumentation. 7 år på Banki.ru lærte mig, at testere ikke bør tage ord fra udviklerne, og operationer bør ikke tage ordet af alle. Vi skal tjekke.
For det andet er det nødvendigt at skrive interaktionsdiagrammer, fordi det sker, at tjenester, der ikke bliver særligt godt modtaget, indeholder afhængigheder, som ingen sagde om. For eksempel installerede udviklerne tjenesten på deres nøgle til nogle Yandex.Maps eller Dadata. Du er løbet tør for fri grænse, alt er brudt, og du ved slet ikke, hvad der skete. Alle sådanne rakes skal beskrives: tjenesten bruger Dadata, SMS, noget andet.
For det tredje arbejde med teknisk gæld. Når du laver en form for krykker eller tager imod en service og siger, at noget skal gøres, skal du sørge for, at det bliver gjort. For så kan det vise sig, at det lille hul ikke er så lille, og du falder igennem det.
Med arkitektopgaver havde vi en historie om Sfinx. En af tjenesterne brugte Sphinx til at indtaste lister. Bare en pagineret liste, men den blev genindekseret hver aften. Det blev samlet af to indekser: et stort indeks blev indekseret hver nat, og der var også et lille indeks, der var skruet fast på det. Hver dag, med 50 % sandsynlighed for enten bombning eller ej, styrtede indekset ned under beregningen, og vores nyheder holdt op med at opdatere på hovedsiden. Først tog det 5 minutter for indekset at blive genindekseret, derefter voksede indekset, og på et tidspunkt begyndte det at tage 40 minutter at genindeksere. Da vi klippede dette ud, åndede vi lettet op, for det var tydeligt, at der ville gå lidt mere tid, og vores indeks ville blive genindekseret på fuld tid. Dette vil være en fiasko for vores portal, der er ingen nyheder i otte timer - det er det, forretningen er stoppet.
Plan for at arbejde med en forældreløs tjeneste
Det er faktisk meget svært at gøre, fordi devops handler om kommunikation. Du vil gerne være på god fod med dine kolleger, og når du slår dine kollegaer og ledere oven i hovedet med regler, kan de have modstridende følelser over for de mennesker, der gør dette.
Ud over alle disse punkter er der en anden vigtig ting: specifikke personer skal være ansvarlige for hver specifik tjeneste, for hver specifik del af udsendelsesproceduren. Når der ikke er nogen mennesker, og du skal tiltrække nogle andre mennesker til at studere hele denne sag, bliver det svært.
Hvis alt dette ikke hjalp, og din forældreløse tjeneste stadig er en forældreløs, er der ingen, der ønsker at påtage sig det, dokumentation er ikke skrevet, holdet, der blev kaldt ind i denne tjeneste, nægter at gøre noget, der er en enkel måde - at lave om alt.
Det vil sige, at du tager kravene til servicen på ny og skriver en ny service, bedre, på en bedre platform, uden mærkelige teknologiske løsninger. Og du migrerer til det i kamp.
Vi havde en situation, da vi tog en tjeneste på Yii 1 og indså, at vi ikke kunne udvikle den yderligere, fordi vi løb tør for udviklere, der kunne skrive godt på Yii 1. Alle udviklere skriver godt på Symfony XNUMX. Hvad skal man gøre? Vi tildelte tid, tildelte et team, tildelte en leder, omskrev projektet og skiftede problemfrit trafik til det.
Herefter kan den gamle tjeneste slettes. Dette er min yndlingsprocedure, når du skal tage og rense noget service fra konfigurationsstyringssystemet og derefter gå igennem og se, at alle biler i produktionen er blevet deaktiveret, så udviklerne ikke har nogen spor tilbage. Depotet forbliver i Git.
Det er alt, jeg ville tale om, jeg er klar til at diskutere, emnet er holivar, mange har svømmet i det.
Diasene sagde, at I forenede sprog. Et eksempel var ændring af størrelsen af billeder. Er det virkelig nødvendigt strengt at begrænse det til ét sprog? Fordi billedstørrelse i PHP, ja, faktisk kunne gøres i Golang.
Faktisk er det valgfrit, ligesom al praksis. Måske er det i nogle tilfælde endda uønsket. Men du skal forstå, at hvis du har en teknisk afdeling i et firma på 50 personer, er 45 af dem PHP-specialister, yderligere 3 er devops, der kender Python, Ansible, Puppet og sådan noget, og kun én af dem skriver i nogle en slags sprog.en eller anden Go image resizing service, så når den forlader, følger ekspertisen med det. Og samtidig skal du lede efter en markedsspecifik udvikler, der kan dette sprog, især hvis det er sjældent. Det vil sige, at dette fra et organisatorisk synspunkt er problematisk. Fra et devops-synspunkt skal du ikke bare klone nogle færdiglavede spillebøger, som du bruger til at implementere tjenester, men du bliver nødt til at skrive dem igen.
Vi er i øjeblikket ved at bygge en tjeneste på Node.js, og dette vil kun være en platform i nærheden for hver udvikler med et separat sprog. Men vi sad og tænkte, at spillet var lyset værd. Det vil sige, at det her er et spørgsmål, du skal sidde og tænke over.
Hvordan overvåger du dine tjenester? Hvordan indsamler og overvåger du logs?
Vi samler logs i Elasticsearch og lægger dem i Kibana, og alt efter om det er produktions- eller testmiljøer, bruges forskellige samlere der. Et sted Lumberjack, et andet sted noget andet, husker jeg ikke. Og der er stadig nogle steder i visse tjenester, hvor vi installerer Telegraf og skyder et andet sted separat.
Hvordan lever man med Puppet og Ansible i samme miljø?
Faktisk har vi nu to miljøer, det ene er Puppet, det andet er Ansible. Vi arbejder på at hybridisere dem. Ansible er en god ramme til indledende opsætning, Puppet er en dårlig ramme til indledende opsætning, fordi den kræver praktisk arbejde direkte på platformen, og Puppet sikrer konfigurationskonvergens. Det betyder, at platformen vedligeholder sig selv i en opdateret tilstand, og for at den ansibiliserede maskine kan holdes opdateret, skal du køre playbooks på den hele tiden med en vis hyppighed. Det er forskellen.
Hvordan opretholder du kompatibilitet? Har du konfigurationer i både Ansible og Puppet?
Dette er vores store smerte, vi opretholder kompatibilitet med vores hænder og tænker på, hvordan vi kommer videre fra alt dette et eller andet sted nu. Det viser sig, at Puppet ruller pakker ud og vedligeholder nogle links der, og Ansible ruller for eksempel koden ud og justerer de seneste applikationskonfigurationer der.
Præsentationen handlede om forskellige versioner af Ruby. Hvilken løsning?
Det stødte vi på ét sted, og vi skal hele tiden have det i hovedet. Vi slukkede simpelthen den del, der kørte på Rubyen, der var inkompatibel med applikationerne, og holdt den adskilt.
Årets konference finder sted den 7. december på Technopolis. Vi modtager ansøgninger om rapporter indtil den 11. november. os, hvis du vil tale.
Tilmelding til deltagere er åben, vær med!
Kilde: www.habr.com