{"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\/sv\/blog\/administrirovanie\/servisy-siroty-obratnaya-storona-mikro-servisnoj-arhitektury","title":{"rendered":"\u00d6verblivna tj\u00e4nster: den baksidan av (mikro)tj\u00e4nstearkitektur","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Portalchefen f\u00f6r Banki.ru, Andrey Nikolsky, delade med sig av insikter under f\u00f6rra \u00e5rets konferens. DevOpsDays Moskva<\/a><\/noindex> om f\u00f6r\u00e4ldral\u00f6sa tj\u00e4nster: hur man identifierar en f\u00f6r\u00e4ldral\u00f6s i infrastrukturen, varf\u00f6r f\u00f6r\u00e4ldral\u00f6sa tj\u00e4nster \u00e4r problematiska, vad man kan g\u00f6ra med dem, och hur man ska agera om inget hj\u00e4lper.<\/p>\n

Under detta finns den textuella versionen av f\u00f6redraget. <\/p>\n

\r\n \"Spela\r\n
<\/div>\r\n <\/div><\/center><\/a><\/noindex>
\nHej kollegor! Jag heter Andrey och jag ansvarar f\u00f6r driften p\u00e5 Banki.ru.<\/p>\n

Vi har stora tj\u00e4nster, som monolitiska tj\u00e4nster, det finns tj\u00e4nster i en mer klassisk mening, och s\u00e5 finns det v\u00e4ldigt sm\u00e5. I min arbetsvardag skulle jag s\u00e4ga att om en tj\u00e4nst \u00e4r enkel och liten, s\u00e5 \u00e4r det en mikro-tj\u00e4nst, och om den inte \u00e4r s\u00e4rskilt enkel och inte liten, s\u00e5 \u00e4r det bara en tj\u00e4nst. <\/p>\n

F\u00f6rdelar med tj\u00e4nster<\/b><\/h3>\n

\nJag kommer snabbt att g\u00e5 igenom f\u00f6rdelarna med tj\u00e4nster. <\/p>\n

\"\u00d6verblivna
\n
\nF\u00f6rst och fr\u00e4mst \u2014 skalbarhet. Du kan snabbt g\u00f6ra n\u00e5got p\u00e5 tj\u00e4nsten och starta i produktion. Om du f\u00e5r trafik, kan du klona tj\u00e4nsten. F\u00e5 ytterligare trafik, klona en g\u00e5ng till och leva med det. Det \u00e4r en bra bonus och n\u00e4r vi b\u00f6rjade ans\u00e5gs det vara det viktigaste sk\u00e4let till varf\u00f6r vi \u00f6verhuvudtaget gjorde detta.<\/p>\n

\"\u00d6verblivna
\n
\nF\u00f6r det andra, isolerad utveckling, d\u00e4r du har flera utvecklingsteam, flera olika utvecklare i varje team, och varje team utvecklar en egen tj\u00e4nst.<\/p>\n

Men det finns en nyans med teamen. Utvecklare \u00e4r olika. Och det finns till exempel sn\u00f6flingor.<\/a><\/noindex>Jag s\u00e5g detta f\u00f6r f\u00f6rsta g\u00e5ngen hos Maxim Dorofeev. Ibland finns det sn\u00f6flingor i vissa team, och i andra team finns det inte. Det g\u00f6r att olika tj\u00e4nster som anv\u00e4nds inom f\u00f6retaget blir n\u00e5got oj\u00e4mna. <\/p>\n

\"\u00d6verblivna
\n
\nTitta p\u00e5 bilden: det h\u00e4r \u00e4r en bra utvecklare, han har stora h\u00e4nder och kan g\u00f6ra mycket. Det stora problemet \u00e4r varifr\u00e5n dessa h\u00e4nder kommer. <\/p>\n

\"\u00d6verblivna
\n
\nTj\u00e4nster ger m\u00f6jlighet att anv\u00e4nda olika programmeringsspr\u00e5k, som \u00e4r b\u00e4ttre anpassade f\u00f6r olika uppgifter. N\u00e5gon tj\u00e4nst p\u00e5 Go, n\u00e5gon p\u00e5 Erlang, n\u00e5gon p\u00e5 Ruby, n\u00e5got p\u00e5 PHP, n\u00e5got p\u00e5 Python. Generellt kan man verkligen bredda sig. Det finns ocks\u00e5 nyanser h\u00e4r.<\/p>\n

\"\u00d6verblivna
\n
\nTj\u00e4nstebaserad arkitektur handlar framf\u00f6r allt om devops. Det vill s\u00e4ga om du inte har automatisering, inget deploymentsystem, om du konfigurerar manuellt, kan dina konfigurationer variera fr\u00e5n instans till instans, och du m\u00e5ste g\u00e5 \u00e5t dem f\u00f6r att g\u00f6ra n\u00e5got, d\u00e5 \u00e4r du i helvetet. <\/p>\n

Till exempel, om du har 20 tj\u00e4nster och beh\u00f6ver deploya manuellt, har du 20 konsoler och trycker p\u00e5 \"enter\" samtidigt som en ninja. Det \u00e4r inte optimalt. <\/p>\n

Om du har en tj\u00e4nst efter testning (om det finns testning f\u00f6rst\u00e5s) och beh\u00f6ver fortfarande finjustera den s\u00e5 att den fungerar i produktion, har jag ocks\u00e5 d\u00e5liga nyheter f\u00f6r dig. <\/p>\n

Om du \u00e4r beroende av specifika tj\u00e4nster fr\u00e5n Amazon och samtidigt arbetar i Ryssland, hade du f\u00f6r tv\u00e5 m\u00e5nader sedan ocks\u00e5 \"Allt brinner, jag \u00e4r okej, allt \u00e4r toppen\".<\/p>\n

\"\u00d6verblivna
\n
\nVi anv\u00e4nder Ansible f\u00f6r att automatisera deployment, Puppet f\u00f6r konvergens, Bamboo f\u00f6r att automatisera deployment, och Confluence f\u00f6r att dokumentera allt detta.<\/p>\n

Jag kommer inte att g\u00e5 in p\u00e5 detalj h\u00e4r, eftersom presentationen snarare handlar om interaktionspraxis \u00e4n om teknisk implementation. <\/p>\n

\"\u00d6verblivna
\n
\nVi har till exempel haft problem med att Puppet p\u00e5 servern k\u00f6r med Ruby 2, medan en viss applikation \u00e4r skriven f\u00f6r Ruby 1.8, och de fungerar inte tillsammans. Det uppst\u00e5r n\u00e5got fel d\u00e4r. Och n\u00e4r du beh\u00f6ver h\u00e5lla flera versioner av Ruby p\u00e5 samma maskin, uppst\u00e5r vanligtvis problem. <\/p>\n

Vi ger till exempel varje utvecklare en plattform d\u00e4r det finns n\u00e4stan allt vi har, alla tj\u00e4nster som kan utvecklas, s\u00e5 att de har en isolerad milj\u00f6, d\u00e4r de kan f\u00f6rst\u00f6ra och bygga som de vill. <\/p>\n

Ibland beh\u00f6vs ett specialkompilerat paket med st\u00f6d f\u00f6r n\u00e5got s\u00e4rskilt. Det \u00e4r ganska strikt. Jag h\u00f6rde en presentation d\u00e4r en Docker-image v\u00e4gde 45 GB. I Linux \u00e4r det f\u00f6rst\u00e5s enklare, d\u00e4r \u00e4r allt mindre, men \u00e4nd\u00e5, det finns inget utrymme kvar. <\/p>\n

Och det uppst\u00e5r motstridiga beroenden, n\u00e4r en del av projektet \u00e4r beroende av ett bibliotek av en version, medan en annan del \u00e4r beroende av en annan version, och biblioteken kan \u00f6verhuvudtaget inte installeras tillsammans. <\/p>\n

\"\u00d6verblivna
\n
\nVi har webbplatser och tj\u00e4nster p\u00e5 PHP 5.6, vi sk\u00e4ms \u00f6ver dem, men vad g\u00f6r man. Det \u00e4r v\u00e5r plattform. Det finns webbplatser och tj\u00e4nster p\u00e5 PHP 7, de \u00e4r fler, och vi sk\u00e4ms inte f\u00f6r dem. Varje utvecklare har sin egen databas d\u00e4r de gladeligen kan koda. <\/p>\n

Om ni skriver p\u00e5 samma spr\u00e5k i f\u00f6retaget l\u00e5ter tre virtuella maskiner per utvecklare normalt. Om ni har olika programmeringsspr\u00e5k blir situationen s\u00e4mre.<\/p>\n

\"\u00d6verblivna
\n
\nDu har webbplatser och tj\u00e4nster h\u00e4r, h\u00e4r, och sedan en plattform f\u00f6r Go, en plattform f\u00f6r Ruby, och kanske n\u00e5gon Redis vid sidan av. Slutligen blir allt detta ett stort f\u00e4lt f\u00f6r support, och n\u00e5got av detta kan alltid g\u00e5 s\u00f6nder.<\/p>\n

\"\u00d6verblivna
\n
\nD\u00e4rf\u00f6r har vi bytt ut programmeringsspr\u00e5kets godbitar mot anv\u00e4ndning av olika ramverk, eftersom ramverken p\u00e5 PHP \u00e4r tillr\u00e4ckligt olika, de har olika m\u00f6jligheter, olika gemenskaper, och olika st\u00f6d. Man kan skriva tj\u00e4nster s\u00e5 att man redan har n\u00e5got redo f\u00f6r dem. <\/p>\n

Varje tj\u00e4nst har sitt eget team<\/b><\/h3>\n

\n\"\u00d6verblivna
\n
\nV\u00e5r st\u00f6rsta f\u00f6rdel, som har kristalliserats fram under flera \u00e5r, \u00e4r att varje tj\u00e4nst har sitt eget team. Detta \u00e4r praktiskt f\u00f6r ett stort projekt, man kan spara tid p\u00e5 dokumentation, cheferna k\u00e4nner v\u00e4l sitt projekt. <\/p>\n

Supportuppgifter kan enkelt \u00f6verl\u00e5tas. Till exempel, om f\u00f6rs\u00e4kringsservicen g\u00e5r s\u00f6nder. Och genast g\u00e5r teamet som hanterar f\u00f6rs\u00e4kringen f\u00f6r att laga den. <\/p>\n

Nya funktioner skapas snabbt, eftersom n\u00e4r du har en viss atom\u00e4r tj\u00e4nst kan du snabbt implementera n\u00e5got nytt. <\/p>\n

Och n\u00e4r du har gjort din tj\u00e4nst trasig, vilket oundvikligen h\u00e4nder, p\u00e5verkar det inte andras tj\u00e4nster, och utvecklarna kommer inte rusande med klubbor fr\u00e5n andra team och s\u00e4ger: 'Aj-aj, g\u00f6r inte s\u00e5'. <\/p>\n

\"\u00d6verblivna
\n
\nSom alltid finns det nyanser. Vi har stabila team, och teamens chefer \u00e4r fast f\u00f6rankrade. Det finns tydliga dokument, och cheferna \u00f6vervakar allt noggrant. Varje team har flera tj\u00e4nster med sin chef, och det finns en specifik kompetenspunkt. <\/p>\n

Om teamen \u00e4r flytande (detta anv\u00e4nds ocks\u00e5 ibland hos oss), finns en bra metod som kallas 'stj\u00e4rnkarta'.<\/p>\n

\"\u00d6verblivna
\n
\nDu har en lista \u00f6ver tj\u00e4nster och personer. En stj\u00e4rna betyder att personen \u00e4r expert p\u00e5 den tj\u00e4nsten, en bok betyder att personen studerar denna tj\u00e4nst. M\u00e5let f\u00f6r personen \u00e4r att byta boken mot en stj\u00e4rna. Och om det inte st\u00e5r n\u00e5got mot tj\u00e4nsten, d\u00e5 b\u00f6rjar problemen som jag kommer att ber\u00e4tta mer om. <\/p>\n

Hur uppst\u00e5r f\u00f6r\u00e4ldral\u00f6sa tj\u00e4nster?<\/b><\/h3>\n

\n\"\u00d6verblivna
\n
\nDet f\u00f6rsta problemet, den f\u00f6rsta metoden f\u00f6r att f\u00e5 en tj\u00e4nst i din infrastruktur som blivit en f\u00f6r\u00e4ldral\u00f6s tj\u00e4nst, \u00e4r upps\u00e4gningar av personer. Har n\u00e5gon n\u00e5gonsin varit med om att det kommer tidsgr\u00e4nser fr\u00e5n aff\u00e4rssidan innan man har utv\u00e4rderat uppgifterna? Ibland finns det strikta tidsgr\u00e4nser och det finns helt enkelt inte tid f\u00f6r dokumentation. \"Vi m\u00e5ste sl\u00e4ppa tj\u00e4nsten i produktion, s\u00e5 f\u00e5r vi skriva mer senare.\" <\/p>\n

Om teamet \u00e4r litet kan det h\u00e4nda att det bara finns en utvecklare som skriver allt, medan resten av teamet bara st\u00f6der. \"Jag har skrivit den grundl\u00e4ggande arkitekturen, du kan l\u00e4gga till gr\u00e4nssnitt.\" Sen, vid n\u00e5got tillf\u00e4lle, till exempel n\u00e4r chefen slutar. Och under den perioden n\u00e4r chefen har slutat och ingen ny har utn\u00e4mnts, best\u00e4mmer utvecklarna sj\u00e4lva vart tj\u00e4nsten \u00e4r p\u00e5 v\u00e4g och vad som sker. Och som vi vet (l\u00e5t oss g\u00e5 tillbaka n\u00e5gra sidor) finns det i vissa team personer som \u00e4r som sn\u00f6flingor, ibland en sn\u00f6flinge-teamledare. Sen slutar de, och vi har en f\u00f6r\u00e4ldral\u00f6s tj\u00e4nst. <\/p>\n

\"\u00d6verblivna
\n
\nSamtidigt f\u00f6rsvinner inte uppgifterna fr\u00e5n supporten och aff\u00e4ren, de samlas i backloggen. Om det fanns n\u00e5gra arkitektoniska misstag vid utvecklingen av tj\u00e4nsten, s\u00e5 kvarst\u00e5r de ocks\u00e5 i backloggen. Tj\u00e4nsten degraderas sakta. <\/p>\n

Hur identifierar man en f\u00f6r\u00e4ldral\u00f6s tj\u00e4nst?<\/b> <\/h3>\n

\nDen h\u00e4r listan beskriver situationen ganska bra. Vem har k\u00e4nt igen n\u00e5got i sin infrastruktur?<\/p>\n

\"\u00d6verblivna
\n
\nOm dokumenterade workarounds: det finns en tj\u00e4nst och, i stort sett, fungerar den, den har en manual p\u00e5 tv\u00e5 sidor om hur man arbetar med den, men hur den fungerar inuti, vet ingen. <\/p>\n

Eller, till exempel, det finns n\u00e5gon form av l\u00e4nkf\u00f6rkortare. Just nu har vi tre olika l\u00e4nkf\u00f6rkortare f\u00f6r olika syften i olika tj\u00e4nster. Det \u00e4r f\u00f6ljderna av detta. <\/p>\n

\"\u00d6verblivna
\n
\nNu ska jag vara kapten uppenbarhet. Vad beh\u00f6ver man g\u00f6ra? F\u00f6r det f\u00f6rsta m\u00e5ste tj\u00e4nsten \u00f6verl\u00e4mnas till en annan chef, ett annat team. Om er teamledare inte har slutat \u00e4nnu, b\u00f6r ni inkludera n\u00e5gon i det andra teamet som \u00e5tminstone f\u00f6rst\u00e5r n\u00e5got av tj\u00e4nsten n\u00e4r ni inser att den b\u00f6rjar likna en f\u00f6r\u00e4ldral\u00f6s tj\u00e4nst. <\/p>\n

Den viktigaste saken: ni m\u00e5ste ha skrivna procedurer f\u00f6r \u00f6verl\u00e4mning. I v\u00e5rt fall brukar jag h\u00e5lla koll p\u00e5 detta, f\u00f6r jag vill att allt ska fungera. Cheferna vill att det ska \u00f6verl\u00e4mnas snabbt, och vad som h\u00e4nder sedan \u00e4r inte s\u00e5 viktigt f\u00f6r dem. <\/p>\n

\"\u00d6verblivna
\n
\nEtt annat s\u00e4tt att skapa en \"f\u00f6r\u00e4ldral\u00f6s\" \u00e4r att s\u00e4ga \"Vi g\u00f6r det p\u00e5 outsourcing, s\u00e5 g\u00e5r det snabbare, och sedan \u00f6verl\u00e4mnar vi det till teamet\". Det \u00e4r klart att alla har n\u00e5gon typ av planer i sitt team och k\u00f6. Ofta tror aff\u00e4rskunden att outsourcere g\u00f6r det p\u00e5 samma s\u00e4tt som teknikavdelningen i f\u00f6retaget. Men incitamenten f\u00f6r dem \u00e4r olika. Det kan finnas m\u00e4rkliga tekniska l\u00f6sningar och konstiga algoritmiska l\u00f6sningar p\u00e5 outsourcing.<\/p>\n

\"\u00d6verblivna
\n
\nTill exempel hade vi en tj\u00e4nst d\u00e4r Sphinx fanns p\u00e5 olika ov\u00e4ntade st\u00e4llen. Jag ber\u00e4ttar senare vad vi var tvungna att g\u00f6ra. <\/p>\n

Outsourcere kan anv\u00e4nda eget skrivna ramverk. Det \u00e4r helt enkelt ren PHP med kopierat inneh\u00e5ll fr\u00e5n ett tidigare projekt, d\u00e4r man kan hitta allt m\u00f6jligt. Stora l\u00f6sningar i deploy-skript, n\u00e4r man beh\u00f6ver anv\u00e4nda komplicerade Bash-skript f\u00f6r att \u00e4ndra n\u00e5gra rader i n\u00e5gon fil, d\u00e4r dessa deploy-skript anropas av n\u00e5got tredje skript. I slut\u00e4ndan byter du ut systemet f\u00f6r distribution, och pl\u00f6tsligt fungerar inte din tj\u00e4nst l\u00e4ngre. F\u00f6r d\u00e4r beh\u00f6vde du \u00e4ven s\u00e4tta 8 l\u00e4nkar mellan olika mappar. Eller s\u00e5 fungerar tusen poster, men hundratusen g\u00f6r det inte. <\/p>\n

Jag forts\u00e4tter att styra. Acceptans av tj\u00e4nsten fr\u00e5n outsourcing \u00e4r en obligatorisk procedur. Har n\u00e5gon varit med om att en tj\u00e4nst fr\u00e5n outsourcing anl\u00e4nder men inte accepteras? Det \u00e4r inte s\u00e5 popul\u00e4rt som en f\u00f6r\u00e4ldral\u00f6s tj\u00e4nst, men det f\u00f6rekommer \u00e4nd\u00e5. <\/p>\n

\"\u00d6verblivna
\n
\nTj\u00e4nsten m\u00e5ste kontrolleras, tj\u00e4nsten m\u00e5ste utv\u00e4rderas, l\u00f6senord m\u00e5ste bytas. Vi hade ett fall d\u00e4r n\u00e5gon gav oss en tj\u00e4nst, d\u00e4r administrat\u00f6rsgr\u00e4nssnittet var skrivet \"if login == 'admin' && password == 'admin'...\" i koden. Vi sitter och t\u00e4nker, och detta skriver folk 2018?<\/p>\n

Test av lagringskapacitet \u00e4r ocks\u00e5 viktigt. Det \u00e4r n\u00f6dv\u00e4ndigt att se vad som h\u00e4nder med hundratusentals poster innan du sl\u00e4pper tj\u00e4nsten i produktion. <\/p>\n

\"\u00d6verblivna
\n
\nAtt skicka tj\u00e4nsten f\u00f6r vidareutveckling b\u00f6r inte vara n\u00e5got att sk\u00e4mmas f\u00f6r. N\u00e4r du s\u00e4ger: \"Vi kommer inte att acceptera den h\u00e4r tj\u00e4nsten, vi har 20 uppgifter, g\u00f6r dem s\u00e5 accepterar vi\", \u00e4r det okej. Du ska inte beh\u00f6va ha d\u00e5ligt samvete \u00f6ver att du s\u00e4tter managern i en sv\u00e5r situation eller att aff\u00e4ren spenderar pengar. Aff\u00e4ren kommer att kosta mer senare.<\/p>\n

Vi hade ett fall d\u00e4r vi best\u00e4mde oss f\u00f6r att g\u00f6ra ett pilotprojekt p\u00e5 outsourcing.<\/p>\n

\"\u00d6verblivna
\n
\nDet blev utl\u00e4mnat i tid, och det var den enda kvalitetskriteriet. D\u00e4rf\u00f6r gjorde vi \u00e4nnu ett pilotprojekt, som inte ens var riktigt pilotprojekt. Dessa tj\u00e4nster godk\u00e4ndes, genom administrativa medel sa de, h\u00e4r \u00e4r er kod, h\u00e4r \u00e4r ert team, h\u00e4r \u00e4r er chef. Tj\u00e4nsterna b\u00f6rjade verkligen generera vinst. Samtidigt f\u00f6rblev de i praktiken fortfarande f\u00f6r\u00e4ldral\u00f6sa, ingen f\u00f6rst\u00e5r hur de fungerar, och cheferna skyller ifr\u00e5n sig p\u00e5 deras uppgifter. <\/p>\n

\"\u00d6verblivna
\n
\nDet finns ocks\u00e5 ett utm\u00e4rkt begrepp - guerillautveckling. N\u00e4r en avdelning, vanligtvis marknadsavdelningen, vill testa en hypotes och best\u00e4ller en tj\u00e4nst helt p\u00e5 outsourcing. Trafiken b\u00f6rjar str\u00f6mma in, de st\u00e4nger dokumenten, signerar handlingar med entrepren\u00f6ren, g\u00e5r i drift och s\u00e4ger: \"Grabbar, vi har en tj\u00e4nst, det finns redan trafik p\u00e5 den, den ger oss pengar, l\u00e5t oss acceptera den.\" Vi s\u00e4ger: \"Oj, hur blev det s\u00e5?\".<\/p>\n

\"\u00d6verblivna
\n
\nOch \u00e4nnu ett s\u00e4tt att f\u00e5 en f\u00f6r\u00e4ldral\u00f6s tj\u00e4nst: n\u00e4r ett team pl\u00f6tsligt \u00e4r \u00f6verbelastat, s\u00e4ger ledningen: \"L\u00e5t oss \u00f6verf\u00f6ra tj\u00e4nsten fr\u00e5n detta team till ett annat team med mindre belastning.\" Och sedan \u00f6verf\u00f6r vi det till ett tredje team, och byter chefen. Och i slut\u00e4ndan har vi \u00e5terigen en f\u00f6r\u00e4ldral\u00f6s.<\/p>\n

Vad \u00e4r problemet med de f\u00f6r\u00e4ldral\u00f6sa?<\/b><\/h3>\n

\n\"\u00d6verblivna
\n
\nF\u00f6r den som inte vet, det handlar om det i Sverige upph\u00f6jda linjeskeppet Wasa, ber\u00f6mt f\u00f6r att det sj\u00f6nk fem minuter efter sj\u00f6s\u00e4ttningen. Och Sveriges kung, f\u00f6r \u00f6vrigt, avr\u00e4ttade ingen f\u00f6r det. Det byggdes av tv\u00e5 generationer ingenj\u00f6rer som inte visste hur man byggde s\u00e5dana fartyg. En logisk effekt.<\/p>\n

Skeppet kunde f\u00f6r \u00f6vrigt ha sjunkit mycket v\u00e4rre, till exempel n\u00e4r kungen redan hade \u00e5kt n\u00e5gonstans i en storm. Men s\u00e5 sj\u00f6nk det direkt, enligt agilt t\u00e4nkande \u00e4r det bra \u2013 att misslyckas tidigt. <\/p>\n

Om vi misslyckas tidigt brukar det s\u00e4llan vara n\u00e5gra problem. Till exempel, vid godk\u00e4nnande skickades det f\u00f6r f\u00f6rb\u00e4ttring. Men om vi redan har misslyckats i produktionen, n\u00e4r pengar har investerats, kan det bli problem. Konsekvenser, som man s\u00e4ger i aff\u00e4rer.<\/p>\n

Vad \u00e4r farorna med f\u00f6r\u00e4ldral\u00f6sa tj\u00e4nster:<\/p>\n