{"id":38981,"date":"2019-10-31T22:27:10","date_gmt":"2019-10-31T19:27:10","guid":{"rendered":"https:\/\/prohoster.info\/blog\/servisy-siroty-obratnaya-storona-mikro-servisnoj-arhitektury\/"},"modified":"2019-10-31T22:27:10","modified_gmt":"2019-10-31T19:27:10","slug":"servisy-siroty-obratnaya-storona-mikro-servisnoj-arhitektury","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/servisy-siroty-obratnaya-storona-mikro-servisnoj-arhitektury","title":{"rendered":"For\u00e6ldrel\u00f8se services: den m\u00f8rke side af (mikro)servicearkitektur","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Direkt\u00f8r for driften af portalen Banki.ru, Andrey Nikolsky, talte p\u00e5 sidste \u00e5rs konference DevOpsDays Moskva<\/a><\/noindex> om for\u00e6ldrel\u00f8se tjenester: hvordan man identificerer en for\u00e6ldrel\u00f8s i infrastrukturen, hvad der er d\u00e5rligt ved for\u00e6ldrel\u00f8se tjenester, hvad man skal g\u00f8re med dem, og hvordan man skal h\u00e5ndtere det, hvis intet hj\u00e6lper.<\/p>\n

Under cut'en er der den tekstuelle version af rapporten. <\/p>\n

\r\n \"Afspil\r\n
<\/div>\r\n <\/div><\/center><\/a><\/noindex>
\nHej kolleger! Mit navn er Andrey, jeg leder driften i selskabet Banki.ru.<\/p>\n

Vi har store tjenester, det er s\u00e5danne monolit-tjenester, der er tjenester i en mere klassisk forstand, og der er helt sm\u00e5. I min arbejds- og landmandsterminologi siger jeg, at hvis tjenesten er simpel og lille, s\u00e5 er den mikro, og hvis den ikke er s\u00e6rlig simpel og ikke lille, s\u00e5 er det bare en tjeneste. <\/p>\n

Fordele ved tjenester<\/b><\/h3>\n

\nJeg vil hurtigt gennemg\u00e5 fordelene ved tjenester. <\/p>\n

\"For\u00e6ldrel\u00f8se
\n
\nFor det f\u00f8rste \u2014 skalering. Du kan hurtigt g\u00f8re noget p\u00e5 tjenesten og lancere det i produktion. Du f\u00e5r trafik, du kloner tjenesten. Du f\u00e5r mere trafik, du kloner igen, og s\u00e5 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.<\/p>\n

\"For\u00e6ldrel\u00f8se
\n
\nFor det andet, isoleret udvikling, n\u00e5r du har flere udviklingsteams, forskellige udviklere i hvert team, og hvert team arbejder p\u00e5 deres egen tjeneste.<\/p>\n

Der opst\u00e5r et problem med teams. Udviklere kan v\u00e6re forskellige. Og der findes for eksempel snefnug-mennesker<\/a><\/noindex>. Jeg s\u00e5 det f\u00f8rste gang hos Maksim Dorofeev. Nogle gange er der snefnug-mennesker i nogle teams, og i andre er der ikke. Dette g\u00f8r, at de forskellige tjenester, der bruges i selskabet, er lidt uensartede. <\/p>\n

\"For\u00e6ldrel\u00f8se
\n
\nSe p\u00e5 billedet: det er en god udvikler, han har store h\u00e6nder, han kan g\u00f8re meget. Hovedproblemet er, hvor disse h\u00e6nder kommer fra. <\/p>\n

\"For\u00e6ldrel\u00f8se
\n
\nTjenester giver mulighed for at bruge forskellige programmeringssprog, der er bedre egnet til forskellige opgaver. En tjeneste p\u00e5 Go, en anden p\u00e5 Erlang, en p\u00e5 Ruby, noget p\u00e5 PHP, noget p\u00e5 Python. Generelt kan man brede sig meget. Her er der ogs\u00e5 nuancer.<\/p>\n

\"For\u00e6ldrel\u00f8se
\n
\nServiceorienteret arkitektur handler f\u00f8rst 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\u00e5 er du i helvede. <\/p>\n

For eksempel, hvis du har 20 tjenester, og du skal implementere dem manuelt, s\u00e5 har du 20 konsoller, og du trykker samtidig p\u00e5 \"enter\" som en ninja. Det er ikke s\u00e6rlig godt. <\/p>\n

Hvis du har en tjeneste efter testning (hvis der selvf\u00f8lgelig er testning), og der er behov for lidt finjustering for at f\u00e5 den til at fungere i produktion, har jeg ogs\u00e5 d\u00e5rlige nyheder til dig. <\/p>\n

Hvis du er afh\u00e6ngig af specifikke Amazon-tjenester og arbejder i Rusland, s\u00e5 havde du for to m\u00e5neder siden ogs\u00e5 \"Alt br\u00e6nder omkring mig, jeg har det fint, alt er fantastisk\".<\/p>\n

\"For\u00e6ldrel\u00f8se
\n
\nVi bruger Ansible til at automatisere deployment, Puppet til konvergens, Bamboo til automatisering af implementering, Confluence til at beskrive det hele p\u00e5 en eller anden m\u00e5de.<\/p>\n

Jeg vil ikke g\u00e5 i detaljer med det, fordi pr\u00e6sentationen handler mere om interaktionspraksis end om den tekniske implementering. <\/p>\n

\"For\u00e6ldrel\u00f8se
\n
\nVi har haft for eksempel problemer med, at Puppet p\u00e5 serveren k\u00f8rer med Ruby 2, mens en applikation er skrevet til Ruby 1.8, og de fungerer ikke sammen. Der opst\u00e5r et eller andet problem. Og n\u00e5r du skal have flere versioner af Ruby p\u00e5 \u00e9n maskine, begynder du normalt at f\u00e5 problemer. <\/p>\n

For eksempel giver vi hver udvikler en platform, der har cirka alt, hvad vi har, alle tjenester, der kan udvikles, s\u00e5 de har et isoleret milj\u00f8, hvor de kan \u00f8del\u00e6gge det og bygge det, som de \u00f8nsker. <\/p>\n

Nogle gange har man brug for en specielt kompilering pakke med underst\u00f8ttelse af noget. Det er ret strengt. Jeg h\u00f8rte en pr\u00e6sentation, hvor en Docker-billede vejer 45 GB. P\u00e5 Linux er det selvf\u00f8lgelig lettere, der er mindre, men derudover vil der ikke v\u00e6re plads nok. <\/p>\n

Og s\u00e5 er der modstridende afh\u00e6ngigheder, n\u00e5r en del af projektet afh\u00e6nger af \u00e9n version af et bibliotek, mens en anden del afh\u00e6nger af en anden version, og bibliotekerne kan slet ikke installeres sammen. <\/p>\n

\"For\u00e6ldrel\u00f8se
\n
\nVi har websites og tjenester p\u00e5 PHP 5.6, vi skammer os over dem, men hvad skal vi g\u00f8re. Det er p\u00e5 \u00e9n platform. Der er websites og tjenester p\u00e5 PHP 7, og de er flere, dem skammer vi os ikke over. Og hver udvikler har sin egen database, hvor de gladeligt arbejder. <\/p>\n

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\u00e6rre.<\/p>\n

\"For\u00e6ldrel\u00f8se
\n
\nDu f\u00e5r hjemmesider og tjenester, og s\u00e5 en platform til Go, en platform til Ruby, og m\u00e5ske endnu en Redis ved siden af. I sidste ende bliver det til et stort supportomr\u00e5de, hvor noget altid kan g\u00e5 i stykker.<\/p>\n

\"For\u00e6ldrel\u00f8se
\n
\nDerfor har vi erstattet programmeringssprogsfunktionerne med forskellige rammer, da PHP-rammerne er meget forskellige og har forskellige muligheder, forskellige f\u00e6llesskaber og forskellig support. Man kan skrive en tjeneste, s\u00e5 man allerede har noget klar dertil. <\/p>\n

Hver tjeneste har sit eget team<\/b><\/h3>\n

\n\"For\u00e6ldrel\u00f8se
\n
\nVores st\u00f8rste fordel, som har krystallisert sig over flere \u00e5r, er, at hver tjeneste har sit eget team. Det er bekvemt for store projekter, da man kan spare tid p\u00e5 dokumentationen, og managerne kender deres projekt godt. <\/p>\n

Opgaver fra support kan nemt kastes ind. For eksempel, hvis en forsikringstjeneste g\u00e5r ned. S\u00e5 g\u00e5r teamet, der besk\u00e6ftiger sig med forsikring, straks ind for at rette det. <\/p>\n

Nye funktioner bliver hurtigt lavet, fordi n\u00e5r du har en atomar tjeneste, kan man hurtigt f\u00e5 noget til at passe ind. <\/p>\n

Og n\u00e5r du har brudt din tjeneste, hvilket uundg\u00e5eligt vil ske, rammer det ikke andre tjenester, og udviklerne fra andre teams kommer ikke til dig med k\u00f8ller og siger: \u00ab\u00c5h, nej, lad v\u00e6re med det\u00bb. <\/p>\n

\"For\u00e6ldrel\u00f8se
\n
\nSom altid er der nuancer. Vi har stabile teams, og teammanagerne er godt forankrede. Der er klare dokumenter, og managerne holder godt \u00f8je med alt dette. Hver teamleder har flere tjenester, og der er specifik kompetence. <\/p>\n

Hvis teams er flydende (det bruges ogs\u00e5 hos os nogle gange), er der en god metode kaldet \u00abstjernekortet\u00bb.<\/p>\n

\"For\u00e6ldrel\u00f8se
\n
\nDu har en liste over tjenester og personer. En stjerne betyder, at en person er ekspert p\u00e5 denne tjeneste, en bog betyder, at en person studerer denne tjeneste. M\u00e5lene for personen er at bytte bogen til en stjerne. Hvis der ikke st\u00e5r noget imod en tjeneste, begynder problemerne, som jeg vil tale videre om. <\/p>\n

Hvordan opst\u00e5r for\u00e6ldrel\u00f8se tjenester?<\/b><\/h3>\n

\n\"For\u00e6ldrel\u00f8se
\n
\nDet f\u00f8rste problem, f\u00f8rste m\u00e5de at f\u00e5 en service-forladthed i sin infrastruktur p\u00e5, er fyringer af medarbejdere. Har nogen nogensinde oplevet, at deadlines fra forretningen kommer, f\u00f8r opgaverne er vurderet? Nogle gange er deadlines stramme, og der er simpelthen ikke tid til dokumentationen. \"Vi skal have servicen i produktion, s\u00e5 skriver vi resten senere.\" <\/p>\n

Hvis teamet er lille, kan der v\u00e6re \u00e9n udvikler, der skriver det hele, mens de andre er hj\u00e6lpere. \"Jeg har skrevet hovedarkitekturen, s\u00e5 lad os f\u00e5 nogle gr\u00e6nseflader p\u00e5 plads.\" S\u00e5 p\u00e5 et tidspunkt forlader lederen, for eksempel, teamet. I den periode, hvor lederen er v\u00e6k, 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\u00e5 en snefnug. S\u00e5 forlader han, og vi ender med en service-forladthed. <\/p>\n

\"For\u00e6ldrel\u00f8se
\n
\nImidlertid 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\u00e5 i backloggen. Servicen forringes langsomt. <\/p>\n

Hvordan identificerer man en forladthed?<\/b> <\/h3>\n

\nDenne liste beskriver situationen ret godt. Hvem kan genkende sig selv i sin infrastruktur?<\/p>\n

\"For\u00e6ldrel\u00f8se
\n
\nOm dokumenterede work-arounds: der er en service, og generelt fungerer den, den har en manual p\u00e5 to sider om, hvordan man arbejder med den, men hvordan den fungerer internt, ved ingen. <\/p>\n

Eller for eksempel, der findes en forkortelseslink. I \u00f8jeblikket har vi brug for tre forskellige forkortelseslink til forskellige form\u00e5l i forskellige tjenester. Det er netop konsekvenserne af det. <\/p>\n

\"For\u00e6ldrel\u00f8se
\n
\nNu skal jeg v\u00e6re kaptajn \u00e5benbarhed. Hvad skal der g\u00f8res? For det f\u00f8rste 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\u00e5else for servicen, n\u00e5r man indser, at servicen ligner en forladthed. <\/p>\n

Hovedsagen er: du skal have procedurer for overdragelse, skrevet i blod. I vores tilf\u00e6lde er det normalt mig, der holder \u00f8je med dette, fordi jeg har brug for, at det fungerer. Ledere \u00f8nsker, at det skal overdrages hurtigt, og hvad der s\u00e5 sker, er ikke s\u00e5 vigtigt for dem. <\/p>\n

\"For\u00e6ldrel\u00f8se
\n
\nDen n\u00e6ste m\u00e5de at h\u00e5ndtere et projekt p\u00e5 er at sige: \u201eLad os udlicitere det, s\u00e5 g\u00e5r det hurtigere, og s\u00e5 overdrager vi det til teamet\u201d. Det er klart, at alle har nogle planer i teamet og en r\u00e6kkef\u00f8lge. Ofte t\u00e6nker forretningskunden, at outsource-virksomheden vil g\u00f8re det p\u00e5 samme m\u00e5de som den interne IT-afdeling. Selvom deres motiver er forskellige. Der kan komme m\u00e6rkelige teknologiske l\u00f8sninger og underlige algoritmiske l\u00f8sninger ved udlicitering.<\/p>\n

\"For\u00e6ldrel\u00f8se
\n
\nFor eksempel havde vi en service, hvor Sphinx var placeret p\u00e5 forskellige uventede steder. Jeg vil senere fort\u00e6lle, hvad vi var n\u00f8dt til at g\u00f8re. <\/p>\n

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 \u00e6ndre et par linjer i en fil, mens disse deploy-scripts kaldes af et andet script. I sidste ende \u00e6ndrer man deployment-systemet, v\u00e6lger noget andet, og pludselig fungerer servicen ikke mere. Fordi der skulle v\u00e6re 8 links mellem forskellige mapper. Eller det kan ske, at 1000 poster fungerer, men 100.000 g\u00f8r ikke. <\/p>\n

Jeg forts\u00e6tter med at lede. Accept af service fra outsourcing er en procedure, der er obligatorisk. Har nogen fors\u00f8gt at modtage en service fra outsourcing, men det bliver ikke accepteret? Det er selvf\u00f8lgelig ikke s\u00e5 popul\u00e6rt som et projekt uden ejer, men stadig. <\/p>\n

\"For\u00e6ldrel\u00f8se
\n
\nTjenesten skal kontrolleres, tjenesten skal anmeldes, adgangskoder skal \u00e6ndres. Vi havde en situation, hvor vi fik en tjeneste med en adminpanel som \"if login == 'admin' && password == 'admin'\u2026\", direkte skrevet i koden. Vi sidder og t\u00e6nker, og det er noget, folk skriver i 2018?<\/p>\n

Test af lagerkapacitet er ogs\u00e5 n\u00f8dvendigt. Man skal se, hvad der sker med 100.000 poster, inden man sender servicen i produktion. <\/p>\n

\"For\u00e6ldrel\u00f8se
\n
\nDet skal ikke v\u00e6re pinligt at sende servicen til forbedringer. N\u00e5r du siger: \u201eVi vil ikke acceptere denne service, vi har 20 opgaver, g\u00f8r dem, s\u00e5 accepterer vi det\u201d, s\u00e5 er det helt normalt. Samvittigheden b\u00f8r ikke plage dig over, at du s\u00e6tter en manager i en sv\u00e6r situation, eller at virksomheden bruger penge. Virksomheden vil senere bruge meget mere.<\/p>\n

Vi havde et tilf\u00e6lde, hvor vi besluttede at lave et pilotprojekt p\u00e5 outsourcing.<\/p>\n

\"For\u00e6ldrel\u00f8se
\n
\nDet 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\u00e6gter. Alligevel forblev de i virkeligheden stadig forladte, ingen forst\u00e5r, hvordan de fungerer, og managerne giver sig selv frie h\u00e6nder i forhold til deres opgaver. <\/p>\n

\"For\u00e6ldrel\u00f8se
\n
\nDer er ogs\u00e5 et fantastisk koncept \u2014 guerillaprogrammering. N\u00e5r en eller anden afdeling, som regel marketingafdelingen, \u00f8nsker at teste en hypotese og bestiller tjenesten helt i outsourcing. Den modtager trafik, de lukker dokumenter, underskriver kontrakter med entrepren\u00f8ren, g\u00e5r i drift og siger: \u00abHey, vi har en tjeneste her, den har allerede trafik, den genererer penge for os, lad os tage den i brug\u00bb. Vi er s\u00e5dan: \u00abWhoa, hvordan kan det v\u00e6re\u00bb.<\/p>\n

\"For\u00e6ldrel\u00f8se
\n
\nOg en anden m\u00e5de at f\u00e5 en forladt tjeneste p\u00e5: n\u00e5r et team pludselig bliver overbelastet, siger ledelsen: \u00abLad os overf\u00f8re denne tjeneste fra dette team til et andet team med mindre belastning\u00bb. Og s\u00e5 overf\u00f8rer vi den til et tredje team og skifter manager. Og i sidste ende har vi igen et forladt projekt.<\/p>\n

Hvad er problemet med de forladte tjenester?<\/b><\/h3>\n

\n\"For\u00e6ldrel\u00f8se
\n
\nFor dem, der ikke ved det, er dette den fors\u00e6nkede svenske slagskib Wasa, ber\u00f8mt for at det sank fem minutter efter sj\u00f8s\u00e6tningen. Og den svenske konge henrettede forresten ingen for det. Det blev bygget af to generationer ingeni\u00f8rer, der ikke vidste, hvordan man bygger s\u00e5danne skibe. En lovm\u00e6ssig effekt.<\/p>\n

Skibet kunne i \u00f8vrigt v\u00e6re sunket meget v\u00e6rre, for eksempel hvis kongen allerede var om bord p\u00e5 vej ind i en storm. Men det sank straks, og if\u00f8lge agile principper er det godt \u2014 fejle tidligt. <\/p>\n

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\u00e5r pengene er investeret, kan der opst\u00e5 problemer. Konsekvenserne, som de kalder det i erhvervslivet.<\/p>\n

Hvad er farerne ved forladte tjenester:<\/p>\n