Driftsdirektør for Banki.ru-portalen Andrey Nikolsky talte på fjorårets konferanse om foreldreløse tjenester: hvordan identifisere en foreldreløs i infrastrukturen, hvorfor foreldreløse tjenester er dårlige, hva du skal gjøre med dem, og hva du skal gjøre hvis ingenting hjelper.
Under snittet er en tekstversjon av rapporten.
Hei kollegaer! Mitt navn er Andrey, jeg leder driften på Banki.ru.
Vi har store tjenester, dette er slike monolittiske tjenester, det er tjenester i mer klassisk forstand, og det er veldig små. I min arbeider-bonde-terminologi sier jeg at hvis en tjeneste er enkel og liten, så er den mikro, og hvis den ikke er veldig enkel og liten, så er den bare en tjeneste.
Fordeler med tjenester
Jeg skal raskt gå gjennom fordelene med tjenestene.
Den første er skalering. Du kan raskt gjøre noe på tjenesten og starte produksjonen. Du har mottatt trafikk, du har klonet tjenesten. Du har mer trafikk, du har klonet den og lever med den. Dette er en god bonus, og i prinsippet, da vi startet, ble det ansett som det viktigste for oss, hvorfor vi gjør alt dette.
For det andre isolert utvikling, når man har flere utviklingsteam, flere ulike utviklere i hvert team, og hvert team utvikler sin egen tjeneste.
Med lag er det en nyanse. Utviklere er forskjellige. Og det er f.eks. . Jeg så dette første gang med Maxim Dorofeev. Noen ganger er snøfnuggfolk på noen lag og ikke på andre. Dette gjør de ulike tjenestene som brukes på tvers av selskapet litt ujevne.
Se på bildet: dette er en god utvikler, han har store hender, han kan gjøre mye. Hovedproblemet er hvor disse hendene kommer fra.
Tjenester gjør det mulig å bruke ulike programmeringsspråk som er mer egnet for ulike oppgaver. Noen tjenester er i Go, noen er i Erlang, noen er i Ruby, noe er i PHP, noe er i Python. Generelt kan du utvide veldig mye. Det er nyanser her også.
Tjenesteorientert arkitektur handler først og fremst om devops. Det vil si, hvis du ikke har automatisering, er det ingen distribusjonsprosess, hvis du konfigurerer den manuelt, kan konfigurasjonene dine endres fra tjenesteforekomst til forekomst, og du må gå dit for å gjøre noe, så er du i helvete.
For eksempel, du har 20 tjenester og du må distribuere for hånd, du har 20 konsoller, og du trykker på "enter" samtidig som en ninja. Det er ikke veldig bra.
Hvis du har en tjeneste etter testing (hvis det er testing, selvfølgelig), og du fortsatt trenger å fullføre den med en fil slik at den fungerer i produksjonen, har jeg også dårlige nyheter til deg.
Hvis du er avhengig av spesifikke Amazon-tjenester og jobber i Russland, så hadde du for to måneder siden også "Alt rundt brenner, jeg har det bra, alt er kult."
Vi bruker Ansible for å automatisere distribusjon, Puppet for convergence, Bamboo for å automatisere distribusjon, og Confluence for å beskrive det hele på en eller annen måte.
Jeg skal ikke dvele ved dette i detalj, fordi rapporten handler mer om samhandlingspraksis, og ikke om teknisk implementering.
For eksempel har vi hatt problemer der Puppet på serveren fungerer med Ruby 2, men noen applikasjoner er skrevet for Ruby 1.8, og de fungerer ikke sammen. Noe går galt der. Og når du trenger å kjøre flere versjoner av Ruby på én maskin, begynner du vanligvis å få problemer.
For eksempel gir vi hver utvikler en plattform der det er omtrent alt vi har, alle tjenestene som kan utvikles, slik at han har et isolert miljø, han kan bryte det og bygge det som han vil.
Det hender at du trenger en spesialkompilert pakke med støtte for noe der. Det er ganske tøft. Jeg lyttet til en rapport der Docker-bildet veier 45 GB. I Linux er det selvfølgelig enklere, alt er mindre der, men likevel vil det ikke være nok plass.
Vel, det er motstridende avhengigheter, når en del av prosjektet avhenger av et bibliotek av én versjon, avhenger en annen del av prosjektet av en annen versjon, og bibliotekene er ikke installert sammen i det hele tatt.
Vi har nettsteder og tjenester i PHP 5.6, vi skammer oss over dem, men hva kan vi gjøre? Dette er vår ene side. Det er nettsteder og tjenester på PHP 7, det er flere av dem, vi skammer oss ikke over dem. Og hver utvikler har sin egen base hvor han med glede sager.
Hvis du skriver i et selskap på ett språk, høres tre virtuelle maskiner per utvikler normalt ut. Hvis du har forskjellige programmeringsspråk, blir situasjonen verre.
Du har nettsteder og tjenester på dette, på dette, så et annet nettsted for Go, ett nettsted for Ruby, og noen andre Redis på siden. Som et resultat blir alt dette til et stort felt for støtte, og hele tiden kan noe av det gå i stykker.
Derfor byttet vi ut fordelene med programmeringsspråket med bruk av forskjellige rammeverk, siden PHP-rammeverk er ganske forskjellige, de har forskjellige muligheter, forskjellige fellesskap og forskjellig støtte. Og du kan skrive en tjeneste slik at du allerede har noe klart for den.
Hver tjeneste har sitt eget team
Vår største fordel, som har utkrystallisert seg over flere år, er at hver tjeneste har sitt eget team. Dette er praktisk for et stort prosjekt, du kan spare tid på dokumentasjon, ledere kjenner prosjektet sitt godt.
Du kan enkelt sende inn oppgaver fra support. For eksempel brøt forsikringstjenesten sammen. Og umiddelbart går teamet som driver med forsikring for å fikse det.
Nye funksjoner lages raskt, for når du har én atomtjeneste kan du raskt skru noe inn i den.
Og når du bryter tjenesten din, og dette uunngåelig skjer, påvirket du ikke andres tjenester, og utviklere med biter fra andre team kommer ikke løpende til deg og sier: "Å, ikke gjør det."
Som alltid er det nyanser. Vi har stabile lag, ledere er spikret til laget. Det er klare dokumenter, ledere følger nøye med på alt. Hvert team med en leder har flere tjenester, og det er et spesifikt kompetansepunkt.
Hvis lagene flyter (vi bruker også noen ganger dette), er det en god metode som kalles "stjernekartet".
Du har en liste over tjenester og personer. En stjerne betyr at personen er ekspert på denne tjenesten, en bok betyr at personen studerer denne tjenesten. Personens oppgave er å bytte boken mot en stjerne. Og hvis ingenting er skrevet foran tjenesten, begynner problemer, som jeg vil snakke om videre.
Hvordan vises foreldreløse tjenester?
Det første problemet, den første måten å få en foreldreløs tjeneste i infrastrukturen din, er å sparke folk. Har noen noen gang fått en bedrift til å overholde tidsfrister før oppgavene ble vurdert? Noen ganger hender det at tidsfrister er stramme og det rett og slett ikke er nok tid til dokumentasjon. "Vi må overlate tjenesten til produksjonen, så legger vi den til."
Hvis teamet er lite, hender det at det er én utvikler som skriver alt, resten er i kulissene. "Jeg skrev den grunnleggende arkitekturen, la oss legge til grensesnittene." Så på et tidspunkt går lederen for eksempel. Og i denne perioden, når lederen har sluttet og en ny ennå ikke er utnevnt, bestemmer utviklerne selv hvor tjenesten skal og hva som skjer der. Og som vi vet (la oss gå tilbake noen lysbilder), i noen lag er det snøfnuggmennesker, noen ganger et snøfnuggteam som leder. Så slutter han, og vi får en foreldreløsgudstjeneste.
Samtidig forsvinner ikke oppgaver fra support og fra næringslivet de havner i etterslepet. Hvis det var noen arkitektoniske feil under utviklingen av tjenesten, havner de også i etterslepet. Tjenesten blir sakte dårligere.
Hvordan identifisere en foreldreløs?
Denne listen beskriver situasjonen godt. Hvem har lært noe om infrastrukturen deres?
Om dokumenterte løsninger: det er en tjeneste, og den fungerer generelt sett, den har en to-siders manual om hvordan du jobber med den, men ingen vet hvordan den fungerer på innsiden.
Eller det er for eksempel en slags lenkeforkorter. For eksempel har vi i dag tre lenkeforkortere i bruk til ulike formål i ulike tjenester. Dette er bare konsekvensene.
Nå skal jeg være kaptein for det åpenbare. Hva bør gjøres? Først må vi overføre tjenesten til en annen leder, et annet team. Hvis teamlederen din ennå ikke har sluttet, så i dette andre teamet, når du forstår at tjenesten er som en foreldreløs, må du inkludere noen som forstår i det minste noe om det.
Det viktigste: du må ha overføringsprosedyrene skrevet i blod. I vårt tilfelle overvåker jeg vanligvis dette, fordi jeg trenger at alt fungerer. Ledere trenger at den leveres raskt, og hva som skjer med den senere er ikke lenger så viktig for dem.
Den neste måten å gjøre en foreldreløs på er "Vi vil gjøre det outsourcet, det vil være raskere, og så vil vi overlevere det til teamet." Det er tydelig at alle har noen planer i laget, en tur. Ofte tror en bedriftskunde at outsourcer vil gjøre det samme som den tekniske avdelingen som bedriften har. Selv om motivatorene deres er forskjellige. Det er merkelige teknologiske løsninger og merkelige algoritmiske løsninger innen outsourcing.
For eksempel hadde vi en tjeneste som hadde Sphinx på forskjellige uventede steder. Jeg skal fortelle deg senere hva jeg måtte gjøre.
Utkontraktører har selvskrevne rammer. Dette er bare PHP med copy-paste fra et tidligere prosjekt, hvor du kan finne alt mulig. Distribusjonsskript er en stor ulempe når du trenger å bruke noen komplekse Bash-skript for å endre flere linjer i en fil, og disse distribusjonsskriptene kalles opp av et tredje skript. Som et resultat endrer du distribusjonssystemet, velger noe annet, hopp, men tjenesten din fungerer ikke. For der var det nødvendig å legge 8 flere linker mellom forskjellige mapper. Eller det hender at tusen plater fungerer, men hundre tusen fungerer ikke lenger.
Jeg vil fortsette som kaptein. Å godta en utkontraktert tjeneste er en obligatorisk prosedyre. Har noen noen gang fått en outsourcet tjeneste ankommet og ikke blitt akseptert noe sted? Dette er selvfølgelig ikke like populært som en foreldreløs tjeneste, men likevel.
Tjenesten må sjekkes, tjenesten må gjennomgås, passord må endres. Vi hadde en sak da de ga oss en tjeneste, det er et adminpanel "hvis login == 'admin' && passord == 'admin'...", det er skrevet rett i koden. Vi sitter og tenker, og folk skriver dette i 2018?
Testing av lagringskapasitet er også en nødvendig ting. Du må se på hva som vil skje på hundre tusen plater, selv før du setter denne tjenesten i produksjon et sted.
Det burde ikke være noen skam å sende en tjeneste for forbedring. Når du sier: "Vi vil ikke akseptere denne tjenesten, vi har 20 oppgaver, gjør dem, så vil vi godta," dette er normalt. Samvittigheten din bør ikke bli såret av at du setter opp en leder eller at virksomheten kaster bort penger. Virksomheten vil da bruke mer.
Vi hadde en sak da vi bestemte oss for å sette ut et pilotprosjekt.
Den ble levert til rett tid, og dette var det eneste kvalitetskriteriet. Det er derfor vi laget et nytt pilotprosjekt, som egentlig ikke var en pilot lenger. Disse tjenestene ble akseptert, og gjennom administrative midler sa de, her er koden din, her er teamet, her er lederen din. Tjenestene har faktisk allerede begynt å gi overskudd. Samtidig er de faktisk fortsatt foreldreløse, ingen forstår hvordan de jobber, og ledere gjør sitt beste for å fornekte oppgavene sine.
Det er et annet flott konsept - geriljautvikling. Når en avdeling, vanligvis markedsavdelingen, ønsker å teste en hypotese og bestiller hele tjenesten outsourcet. Trafikken begynner å strømme inn i det, de lukker dokumentene, signerer dokumenter med entreprenøren, kommer i drift og sier: "Dudes, vi har en tjeneste her, den har allerede trafikk, den gir oss penger, la oss godta det." Vi sa: "Oppa, hvordan kan det være."
Og en annen måte å få en foreldreløs tjeneste på: når et team plutselig blir overbelastet, sier ledelsen: "La oss overføre tjenesten til dette teamet til et annet team, det har en mindre belastning." Og så overfører vi det til et tredje lag og skifter manager. Og til slutt har vi et foreldreløst barn igjen.
Hva er problemet med foreldreløse barn?
Hvem vet ikke, dette er slagskipet Wasa reist i Sverige, kjent for det faktum at det sank 5 minutter etter lansering. Og kongen av Sverige henrettet forresten ingen for dette. Den ble bygget av to generasjoner ingeniører som ikke visste hvordan de skulle bygge slike skip. Naturlig effekt.
Skipet kunne forresten ha sunket på en mye verre måte, for eksempel når kongen allerede red på det et sted i storm. Og så druknet han med en gang, ifølge Agile er det godt å feile tidlig.
Hvis vi feiler tidlig, er det vanligvis ingen problemer. For eksempel, under aksept ble den sendt til revisjon. Men hvis vi svikter allerede i produksjonen, når det investeres penger, kan det oppstå problemer. Konsekvenser, som det heter i næringslivet.
Hvorfor foreldreløse tjenester er farlige:
- Tjenesten kan bryte plutselig.
- Tjenesten tar lang tid å reparere eller repareres ikke i det hele tatt.
- Sikkerhetsproblemer.
- Problemer med forbedringer og oppdateringer.
- Hvis en viktig tjeneste går i stykker, lider selskapets omdømme.
Hva skal man gjøre med foreldreløse tjenester?
Jeg skal gjenta hva jeg skal gjøre igjen. Først må det foreligge dokumentasjon. 7 år på Banki.ru lærte meg at testere ikke skulle ta utviklernes ord, og driften skulle ikke ta ordet til alle. Vi må sjekke.
For det andre er det nødvendig å skrive interaksjonsdiagrammer, fordi det hender at tjenester som ikke blir særlig godt mottatt inneholder avhengigheter som ingen sa om. For eksempel installerte utviklerne tjenesten på nøkkelen deres til noen Yandex.Maps eller Dadata. Du har gått tom for gratisgrense, alt er ødelagt, og du vet ikke hva som har skjedd i det hele tatt. Alle slike rakes må beskrives: tjenesten bruker Dadata, SMS, noe annet.
For det tredje arbeider med teknisk gjeld. Når du gjør en slags krykker eller aksepterer en tjeneste og sier at noe må gjøres, må du sørge for at det blir gjort. For da kan det vise seg at det lille hullet ikke er så lite, og du vil falle gjennom det.
Med arkitektoppgaver hadde vi en historie om Sfinx. En av tjenestene brukte Sphinx for å legge inn lister. Bare en paginert liste, men den ble indeksert på nytt hver kveld. Den ble satt sammen av to indekser: en stor ble indeksert hver natt, og det var også en liten indeks som ble skrudd fast på den. Hver dag, med 50 % sannsynlighet for enten bombing eller ikke, krasjet indeksen under beregningen, og nyhetene våre sluttet å oppdateres på hovedsiden. Først tok det 5 minutter før indeksen ble indeksert på nytt, så vokste indeksen, og på et tidspunkt begynte det å ta 40 minutter å indeksere på nytt. Da vi kuttet ut dette, pustet vi lettet ut, for det var klart at det ville gå litt mer tid og indeksen vår ville bli indeksert på nytt på heltid. Dette vil være en fiasko for portalen vår, det er ingen nyheter på åtte timer - det er det, virksomheten har stoppet.
Plan for å jobbe med en foreldreløs tjeneste
Faktisk er dette veldig vanskelig å gjøre, fordi devops handler om kommunikasjon. Du ønsker å være på god fot med kollegene dine, og når du slår kollegaer og ledere over hodet med regelverk, kan de ha motstridende følelser overfor de som gjør dette.
I tillegg til alle disse punktene er det en annen viktig ting: spesifikke personer må være ansvarlige for hver spesifikke tjeneste, for hver spesifikke del av distribusjonsprosedyren. Når det ikke er folk og du må tiltrekke deg noen andre for å studere hele denne saken, blir det vanskelig.
Hvis alt dette ikke hjalp, og foreldreløse tjenesten din fortsatt er en foreldreløs, vil ingen ta det på seg, dokumentasjon er ikke skrevet, teamet som ble kalt inn i denne tjenesten nekter å gjøre noe, det er en enkel måte - å gjøre om alt .
Det vil si at du tar kravene til tjenesten på nytt og skriver en ny tjeneste, bedre, på en bedre plattform, uten rare teknologiske løsninger. Og du migrerer til det i kamp.
Vi hadde en situasjon da vi tok en tjeneste på Yii 1 og innså at vi ikke kunne utvikle den videre, fordi vi gikk tom for utviklere som kunne skrive godt på Yii 1. Alle utviklere skriver bra på Symfony XNUMX. Hva å gjøre? Vi tildelte tid, tildelte et team, tildelte en leder, omskrev prosjektet og byttet trafikk til det jevnt.
Etter dette kan den gamle tjenesten slettes. Dette er min favorittprosedyre, når du skal ta og rydde ut en tjeneste fra konfigurasjonsstyringssystemet og deretter gå gjennom og se at alle bilene i produksjon er deaktivert, slik at utviklerne ikke har noen spor igjen. Depotet forblir i Git.
Dette er alt jeg ønsket å snakke om, jeg er klar til å diskutere, temaet er holivar, mange har svømt i det.
Lysbildene sa at du forente språk. Et eksempel var endring av størrelse på bilder. Er det virkelig nødvendig å strengt begrense det til ett språk? Fordi bildestørrelse i PHP, vel, kan faktisk gjøres i Golang.
Faktisk er det valgfritt, som all praksis. Kanskje, i noen tilfeller, er det til og med uønsket. Men du må forstå at hvis du har en teknisk avdeling i et selskap på 50 personer, er 45 av dem PHP-spesialister, ytterligere 3 er devops som kan Python, Ansible, Puppet og noe sånt, og bare en av dem skriver i noen et slags språk en tjeneste for å endre størrelse på bilder, og når den forlater, følger ekspertisen med. Og samtidig må du se etter en markedsspesifikk utvikler som kan dette språket, spesielt hvis det er sjeldent. Det vil si at fra et organisatorisk synspunkt er dette problematisk. Fra et devops-synspunkt trenger du ikke bare å klone noen ferdiglagde spillebøker som du bruker til å distribuere tjenester, men du må skrive dem på nytt.
Vi bygger for tiden en tjeneste på Node.js, og dette vil kun være en plattform i nærheten for hver utvikler med et eget språk. Men vi satt og tenkte at spillet var verdt lyset. Det vil si at dette er et spørsmål du kan sitte og tenke på.
Hvordan overvåker du tjenestene dine? Hvordan samler du inn og overvåker logger?
Vi samler logger i Elasticsearch og legger dem i Kibana, og avhengig av om det er produksjons- eller testmiljøer, brukes ulike samlere der. Et sted Lumberjack, et annet sted noe annet, husker jeg ikke. Og det er fortsatt noen steder i visse tjenester hvor vi installerer Telegraf og skyter et annet sted separat.
Hvordan leve med Puppet og Ansible i samme miljø?
Faktisk har vi nå to miljøer, det ene er Puppet, det andre er Ansible. Vi jobber med å hybridisere dem. Ansible er et godt rammeverk for innledende oppsett, Puppet er et dårlig rammeverk for innledende oppsett fordi det krever praktisk arbeid direkte på plattformen, og Puppet sikrer konfigurasjonskonvergens. Dette betyr at plattformen opprettholder seg selv i en oppdatert tilstand, og for at den ansibiliserte maskinen skal holdes oppdatert, må du kjøre spillebøker på den hele tiden med en viss frekvens. Det er forskjellen.
Hvordan opprettholder du kompatibiliteten? Har du konfigurasjoner i både Ansible og Puppet?
Dette er vår store smerte, vi opprettholder kompatibilitet med hendene våre og tenker på hvordan vi kan gå videre fra alt dette et sted nå. Det viser seg at Puppet ruller ut pakker og vedlikeholder noen lenker der, og Ansible ruller for eksempel ut koden og justerer de siste applikasjonskonfigurasjonene der.
Presentasjonen handlet om ulike versjoner av Ruby. Hvilken løsning?
Vi møtte dette på ett sted, og vi må ha det i hodet hele tiden. Vi slo ganske enkelt av delen som kjørte på Rubyen som var inkompatibel med applikasjonene og holdt den adskilt.
Årets konferanse finner sted 7. desember på Technopolis. Vi tar i mot søknader om rapporter frem til 11. november. oss hvis du vil snakke.
Påmeldingen for deltakere er åpen, bli med!
Kilde: www.habr.com