Direktør for driften af portalen Banki.ru, Andrey Nikolsky, talte på sidste års konference om forældreløse tjenester: hvordan man identificerer en forældreløs i infrastrukturen, hvad der er dårligt ved forældreløse tjenester, hvad man skal gøre med dem, og hvordan man skal håndtere det, hvis intet hjælper.
Under cut'en er der den tekstuelle version af rapporten.
Hej kolleger! Mit navn er Andrey, jeg leder driften i selskabet Banki.ru.
Vi har store tjenester, det er sådanne monolit-tjenester, der er tjenester i en mere klassisk forstand, og der er helt små. I min arbejds- og landmandsterminologi siger jeg, at hvis tjenesten er simpel og lille, så er den mikro, og hvis den ikke er særlig simpel og ikke lille, så er det bare en tjeneste.
Fordele ved tjenester
Jeg vil hurtigt gennemgå fordelene ved tjenester.
For det første — skalering. Du kan hurtigt gøre noget på tjenesten og lancere det i produktion. Du får trafik, du kloner tjenesten. Du får mere trafik, du kloner igen, og så lever du med det. Det er et godt bonuspoint, og i princippet, da vi startedede, blev det betragtet som det vigtigste, hvorfor vi overhovedet laver alt dette.
For det andet, isoleret udvikling, når du har flere udviklingsteams, forskellige udviklere i hvert team, og hvert team arbejder på deres egen tjeneste.
Der opstår et problem med teams. Udviklere kan være forskellige. Og der findes for eksempel . Jeg så det første gang hos Maksim Dorofeev. Nogle gange er der snefnug-mennesker i nogle teams, og i andre er der ikke. Dette gør, at de forskellige tjenester, der bruges i selskabet, er lidt uensartede.
Se på billedet: det er en god udvikler, han har store hænder, han kan gøre meget. Hovedproblemet er, hvor disse hænder kommer fra.
Tjenester giver mulighed for at bruge forskellige programmeringssprog, der er bedre egnet til forskellige opgaver. En tjeneste på Go, en anden på Erlang, en på Ruby, noget på PHP, noget på Python. Generelt kan man brede sig meget. Her er der også nuancer.
Serviceorienteret arkitektur handler først og fremmest om devops. Det vil sige, hvis du ikke har automatisering, ikke har en deploy-process, hvis du konfigurerer manuelt, kan dine konfigurationer variere fra instans til instans, og du skal ind for at lave noget, så er du i helvede.
For eksempel, hvis du har 20 tjenester, og du skal implementere dem manuelt, så har du 20 konsoller, og du trykker samtidig på "enter" som en ninja. Det er ikke særlig godt.
Hvis du har en tjeneste efter testning (hvis der selvfølgelig er testning), og der er behov for lidt finjustering for at få den til at fungere i produktion, 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 brænder omkring mig, jeg har det fint, alt er fantastisk".
Vi bruger Ansible til at automatisere deployment, Puppet til konvergens, Bamboo til automatisering af implementering, Confluence til at beskrive det hele på en eller anden måde.
Jeg vil ikke gå i detaljer med det, fordi præsentationen handler mere om interaktionspraksis end om den tekniske implementering.
Vi har haft for eksempel problemer med, at Puppet på serveren kører med Ruby 2, mens en applikation er skrevet til Ruby 1.8, og de fungerer ikke sammen. Der opstår et eller andet problem. Og når du skal have flere versioner af Ruby på én maskine, begynder du normalt at få problemer.
For eksempel giver vi hver udvikler en platform, der har cirka alt, hvad vi har, alle tjenester, der kan udvikles, så de har et isoleret miljø, hvor de kan ødelægge det og bygge det, som de ønsker.
Nogle gange har man brug for en specielt kompilering pakke med understøttelse af noget. Det er ret strengt. Jeg hørte en præsentation, hvor en Docker-billede vejer 45 GB. På Linux er det selvfølgelig lettere, der er mindre, men derudover vil der ikke være plads nok.
Og så er der modstridende afhængigheder, når en del af projektet afhænger af én version af et bibliotek, mens en anden del afhænger af en anden version, og bibliotekerne kan slet ikke installeres sammen.
Vi har websites og tjenester på PHP 5.6, vi skammer os over dem, men hvad skal vi gøre. Det er på én platform. Der er websites og tjenester på PHP 7, og de er flere, dem skammer vi os ikke over. Og hver udvikler har sin egen database, hvor de gladeligt arbejder.
Hvis du arbejder i en virksomhed med et programmeringssprog, virker tre virtuelle maskiner pr. udvikler som noget normalt. Hvis du har forskellige programmeringssprog, bliver situationen værre.
Du får hjemmesider og tjenester, og så en platform til Go, en platform til Ruby, og måske endnu en Redis ved siden af. I sidste ende bliver det til et stort supportområde, hvor noget altid kan gå i stykker.
Derfor har vi erstattet programmeringssprogsfunktionerne med forskellige rammer, da PHP-rammerne er meget forskellige og har forskellige muligheder, forskellige fællesskaber og forskellig support. Man kan skrive en tjeneste, så man allerede har noget klar dertil.
Hver tjeneste har sit eget team
Vores største fordel, som har krystallisert sig over flere år, er, at hver tjeneste har sit eget team. Det er bekvemt for store projekter, da man kan spare tid på dokumentationen, og managerne kender deres projekt godt.
Opgaver fra support kan nemt kastes ind. For eksempel, hvis en forsikringstjeneste går ned. Så går teamet, der beskæftiger sig med forsikring, straks ind for at rette det.
Nye funktioner bliver hurtigt lavet, fordi når du har en atomar tjeneste, kan man hurtigt få noget til at passe ind.
Og når du har brudt din tjeneste, hvilket uundgåeligt vil ske, rammer det ikke andre tjenester, og udviklerne fra andre teams kommer ikke til dig med køller og siger: «Åh, nej, lad være med det».
Som altid er der nuancer. Vi har stabile teams, og teammanagerne er godt forankrede. Der er klare dokumenter, og managerne holder godt øje med alt dette. Hver teamleder har flere tjenester, og der er specifik kompetence.
Hvis teams er flydende (det bruges også hos os nogle gange), er der en god metode kaldet «stjernekortet».
Du har en liste over tjenester og personer. En stjerne betyder, at en person er ekspert på denne tjeneste, en bog betyder, at en person studerer denne tjeneste. Målene for personen er at bytte bogen til en stjerne. Hvis der ikke står noget imod en tjeneste, begynder problemerne, som jeg vil tale videre om.
Hvordan opstår forældreløse tjenester?
Det første problem, første måde at få en service-forladthed i sin infrastruktur på, er fyringer af medarbejdere. Har nogen nogensinde oplevet, at deadlines fra forretningen kommer, før opgaverne er vurderet? Nogle gange er deadlines stramme, og der er simpelthen ikke tid til dokumentationen. "Vi skal have servicen i produktion, så skriver vi resten senere."
Hvis teamet er lille, kan der være én udvikler, der skriver det hele, mens de andre er hjælpere. "Jeg har skrevet hovedarkitekturen, så lad os få nogle grænseflader på plads." Så på et tidspunkt forlader lederen, for eksempel, teamet. I den periode, hvor lederen er væk, og der endnu ikke er ansat en ny, beslutter udviklerne selv, hvor servicen skal hen, hvad der sker. Og som vi ved (lad os vende tilbage til nogle slides tilbage), i nogle teams er der snefnugsfolk, nogle gange er snefnug-lederen også en snefnug. Så forlader han, og vi ender med en service-forladthed.
Imidlertid forsvinder ikke opgaverne fra support og forretning, de samler sig i backloggen. Hvis der under udviklingen af servicen var arkitektoniske fejl, samler de sig også i backloggen. Servicen forringes langsomt.
Hvordan identificerer man en forladthed?
Denne liste beskriver situationen ret godt. Hvem kan genkende sig selv i sin infrastruktur?
Om dokumenterede work-arounds: der er en service, og generelt fungerer den, den har en manual på to sider om, hvordan man arbejder med den, men hvordan den fungerer internt, ved ingen.
Eller for eksempel, der findes en forkortelseslink. I øjeblikket har vi brug for tre forskellige forkortelseslink til forskellige formål i forskellige tjenester. Det er netop konsekvenserne af det.
Nu skal jeg være kaptajn åbenbarhed. Hvad skal der gøres? For det første skal servicen overdrages til en anden leder, et andet team. Hvis din teamleder ikke allerede har forladt, skal der inkluderes nogen i det andet team, der i det mindste har en forståelse for servicen, når man indser, at servicen ligner en forladthed.
Hovedsagen er: du skal have procedurer for overdragelse, skrevet i blod. I vores tilfælde er det normalt mig, der holder øje med dette, fordi jeg har brug for, at det fungerer. Ledere ønsker, at det skal overdrages hurtigt, og hvad der så sker, er ikke så vigtigt for dem.
Den næste måde at håndtere et projekt på er at sige: „Lad os udlicitere det, så går det hurtigere, og så overdrager vi det til teamet”. Det er klart, at alle har nogle planer i teamet og en rækkefølge. Ofte tænker forretningskunden, at outsource-virksomheden vil gøre det på samme måde som den interne IT-afdeling. Selvom deres motiver er forskellige. Der kan komme mærkelige teknologiske løsninger og underlige algoritmiske løsninger ved udlicitering.
For eksempel havde vi en service, hvor Sphinx var placeret på forskellige uventede steder. Jeg vil senere fortælle, hvad vi var nødt til at gøre.
Outsourcere har deres egne frameworks. Det er bare ren PHP med copy-paste fra et tidligere projekt, hvor man kan finde alt muligt. Store problemer i deploy-scripts, hvor man med komplicerede Bash-scripts skal ændre et par linjer i en fil, mens disse deploy-scripts kaldes af et andet script. I sidste ende ændrer man deployment-systemet, vælger noget andet, og pludselig fungerer servicen ikke mere. Fordi der skulle være 8 links mellem forskellige mapper. Eller det kan ske, at 1000 poster fungerer, men 100.000 gør ikke.
Jeg fortsætter med at lede. Accept af service fra outsourcing er en procedure, der er obligatorisk. Har nogen forsøgt at modtage en service fra outsourcing, men det bliver ikke accepteret? Det er selvfølgelig ikke så populært som et projekt uden ejer, men stadig.
Servicen skal kontrolleres, servicen skal revideres, og adgangskoder skal ændres. Vi havde en situation, hvor vi fik en service, hvor admin-panelet havde „if login == ‘admin’ && password == ‘admin’…”, direkte skrevet i koden. Vi sad og tænkte, er dette virkelig noget, mennesker skriver i 2018?
Test af lagerkapacitet er også nødvendigt. Man skal se, hvad der sker med 100.000 poster, inden man sender servicen i produktion.
Det skal ikke være pinligt at sende servicen til forbedringer. Når du siger: „Vi vil ikke acceptere denne service, vi har 20 opgaver, gør dem, så accepterer vi det”, så er det helt normalt. Samvittigheden bør ikke plage dig over, at du sætter en manager i en svær situation, eller at virksomheden bruger penge. Virksomheden vil senere bruge meget mere.
Vi havde et tilfælde, hvor vi besluttede at lave et pilotprojekt på outsourcing.
Det blev afleveret til tiden, og det var det eneste kvalitetskriterium. Derfor lavede de endnu et pilotprojekt, som knap engang var et pilotprojekt. Disse tjenester blev accepteret, og med administrative midler sagde de, her er jeres kode, her er teamet, her er jeres manager. Tjenesterne begyndte faktisk allerede at generere indtægter. Alligevel forblev de i virkeligheden stadig forladte, ingen forstår, hvordan de fungerer, og managerne giver sig selv frie hænder i forhold til deres opgaver.
Der er også et fantastisk koncept — guerillaprogrammering. Når en eller anden afdeling, som regel marketingafdelingen, ønsker at teste en hypotese og bestiller tjenesten helt i outsourcing. Den modtager trafik, de lukker dokumenter, underskriver kontrakter med entreprenøren, går i drift og siger: «Hey, vi har en tjeneste her, den har allerede trafik, den genererer penge for os, lad os tage den i brug». Vi er sådan: «Whoa, hvordan kan det være».
Og en anden måde at få en forladt tjeneste på: når et team pludselig bliver overbelastet, siger ledelsen: «Lad os overføre denne tjeneste fra dette team til et andet team med mindre belastning». Og så overfører vi den til et tredje team og skifter manager. Og i sidste ende har vi igen et forladt projekt.
Hvad er problemet med de forladte tjenester?
For dem, der ikke ved det, er dette den forsænkede svenske slagskib Wasa, berømt for at det sank fem minutter efter sjøsætningen. Og den svenske konge henrettede forresten ingen for det. Det blev bygget af to generationer ingeniører, der ikke vidste, hvordan man bygger sådanne skibe. En lovmæssig effekt.
Skibet kunne i øvrigt være sunket meget værre, for eksempel hvis kongen allerede var om bord på vej ind i en storm. Men det sank straks, og ifølge agile principper er det godt — fejle tidligt.
Hvis vi fejler tidligt, er der som regel ikke problemer. For eksempel, under acceptansprocessen bliver det sendt til forbedring. Men hvis vi fejler allerede i produktionen, når pengene er investeret, kan der opstå problemer. Konsekvenserne, som de kalder det i erhvervslivet.
Hvad er farerne ved forladte tjenester:
- Tjenesten kan pludselig gå ned.
- Tjenesten kan tage lang tid at reparere eller slet ikke blive repareret.
- Problemer med sikkerheden.
- Problemer med forbedringer og opdateringer.
- Hvis en vigtig tjeneste går ned, lider virksomhedens omdømme.
Hvad skal man gøre med forladte tjenester?
Lad mig gentage, hvad man skal gøre. For det første skal der være dokumentation. 7 år i Banki.ru lærte mig, at testere ikke bør tro på udviklerne, og driftsafdelingen skal ikke tage nogen på ordet. Man skal tjekke.
For det andet skal man skrive interaktionsskemaer, fordi der er situationer, hvor tjenester, der ikke er taget særlig godt imod, indeholder afhængigheder, som ingen har nævnt. For eksempel har udviklerne knyttet en tjeneste til deres nøgle til Yandex Maps eller Dadata. Hvis dit gratis kvote er opbrugt, går alt i stykker, og du ved ikke, hvad der overhovedet skete. Alle sådanne problemer skal være beskrevet: tjenesten bruger Dadata, Sms, eller noget andet.
For det tredje, arbejde med teknisk gæld. Når du laver vingesus eller tager en tjeneste og siger, at noget skal gøres, så skal du sørge for, at det bliver gjort. Fordi det senere kan vise sig, at et lille hul ikke er så lille, og at du falder ned i det.
Vi har haft en historie med arkitekturmæssige opgaver, relateret til Sphinx. I en af tjenesterne blev Sphinx brugt til at indtaste lister. Bare en liste med paginering, men den blev genindekseret hver nat. Den var bygget fra to indekser: en stor, der blev indekseret hver nat, og en lille indeks, der blev knyttet til den. Hver dag, med 50% sandsynlighed, ville det enten gå galt eller ej, ved udrulning blev indekset ødelagt, og vores nyheder stoppede med at opdatere på forsiden. I starten tog det 5 minutter, indtil indekset blev genindekseret, så voksede indekset, og på et tidspunkt begyndte det at tage 40 minutter. Da vi fjernede det, sukkede vi lettet, fordi det var klart, at der ville gå lidt tid, før vores indeks ville blive genindekseret i en hel arbejdsdag. Det ville være en fiasko for vores portal, otte timer uden nyheder — det ville stoppe forretningen.
Handlingsplan for forældreløs tjeneste
Det er faktisk meget svært at gøre, fordi devops handler om kommunikation. Man ønsker at have gode relationer til sine kolleger, og når man slår dem i hovedet med procedurer, kan de have blandede følelser om dem, der gør sådan.
Udover alle disse punkter er der en vigtig ting: Der skal være specifikke personer ansvarlige for hver enkelt service og hvert enkelt trin i deploy-proceduren. Når der ikke er folk til stede, og man er nødt til at involvere andre, bliver det besværligt at lære alt dette.
Hvis alt dette ikke har hjulpet, og din forældreløse service stadig er ensom, ingen ønsker at tage den til sig, dokumentationen ikke bliver skrevet, og teamet, der er blevet tilkaldt til denne service, nægter at gøre noget, er der en simpel løsning — lav det hele om.
Det vil sige, at du tager kravene til servicen på ny og skriver en ny service, der er bedre, på en bedre platform, uden underlige teknologiske løsninger. Og migrerer til den i drift.
Vi havde en situation, hvor vi tog en service på Yii 1 og indså, at vi ikke kunne videreudvikle den, fordi vi ikke havde udviklere tilbage, der kunne skrive godt på Yii 1. Alle udviklere kan godt skrive på Symfony 3. Hvad gør man? Vi afsatte tid, samlede et team, udpegede en leder, rewriteede projektet og skiftede blidt trafik til det.
Efter dette kan den gamle service slettes. Det er min yndlingsprocedure, når man skal tage et eller andet service fra konfigurationsstyringssystemet og så gå ind og sikre, at alle instanser i produktionen er lukket ned, så der ikke er nogen spor tilbage for udviklerne. Repositoriet i Git forbliver.
Det er alt, hvad jeg ønskede at fortælle, jeg er klar til at diskutere, emnet er noget kontroversielt, og mange har deres meninger.
På slides var der nævnt, at I havde unificeret sprog. Et eksempel var resizing af billeder. Men er det virkelig nødvendigt at stramme det op til ét sprog? Fordi resizing af billeder på PHP, kunne man faktisk også gøre på Golang.
Det er faktisk ikke nødvendigt, ligesom alle andre praksisser. I visse tilfælde kan det endda være uønsket. Men det er vigtigt at forstå, at hvis der er 50 personer i din virksomheds techafdeling, hvoraf 45 er PHP-udviklere, 3 er devops, der kan Python, Ansible, Puppet og så videre, og kun én af dem skriver en Go-service til resizing af billeder, så når han går, forlader ekspertisen virksomheden sammen med ham. Og samtidig skal du finde en specifik udvikler på markedet, der kender dette sprog, især hvis det er sjældent. Så set fra en organisatorisk synsvinkel, er det problematisk. Set fra en devops-synsvinkel, skal du ikke bare klone et sæt eksisterende playbooks, men du skal skrive dem fra bunden.
Vi arbejder lige nu på en service i Node.js, og det vil være en platform ved siden af for hver udvikler med deres eget sprog. Men vi har overvejet, om det er værd at gøre. Det er i bund og grund et spørgsmål om at tænke over det.
Hvordan monitorerer I jeres services? Hvordan indsamler og sporer I logs?
Vi indsamler logs i Elasticsearch og placerer dem i Kibana, afhængig af om det er produktions- eller testmiljøer, bruges der forskellige collectors. Nogle gange bruger vi Lumberjack, andre tider noget andet, jeg kan ikke huske det. Og der er også visse steder i specifikke services, hvor vi sætter Telegraf op og sender data et andet sted hen.
Hvordan lever man med Puppet og Ansible i samme miljø?
Faktisk har vi nu to miljøer, et med Puppet og et med Ansible. Vi arbejder på at hybridisere dem. Ansible er et godt miljø til den indledende opsætning, Puppet er ikke så godt til initial opsætning, fordi det kræver, at man arbejder direkte med platformen, og Puppet sikrer konvergens af konfigurationen. Det betyder, at platformen selv opretholder sig i en aktuel tilstand, mens for at en Ansible-konfigureret maskine forbliver ajourført, skal playbooks køres med jævne mellemrum. Det er forskellen.
Hvordan opretholder I kompatibilitet? Har I konfigurationer både i Ansible og Puppet?
Dette er vores store smerte, vi opretholder kompatibilitet manuelt og overvejer, hvordan vi skal overgå fra alt dette. Vi ender med, at Puppet installerer pakker og opretholder nogle links, mens Ansible for eksempel installerer koden og opdaterer de nyeste konfigurationer af applikationer der.
I præsentationen blev der talt om forskellige versioner af Ruby. Hvad er løsningen?
Vi er stødt på dette et sted, og vi bliver nødt til hele tiden at have det i baghovedet. Vi slukkede bare den del, der kørte på den Ruby, som var inkompatibel med applikationerne, og holdt den adskilt.
I år finder konferencen sted den 7. december i "Teknopolis". Vi modtager ansøgninger til foredrag indtil den 11. november. os, hvis du ønsker at deltage som taler.
Registreringen for deltagere er åben, kom og vær med!
Kilde: habr.com
