{"id":38747,"date":"2019-10-31T22:25:42","date_gmt":"2019-10-31T19:25:42","guid":{"rendered":"https:\/\/prohoster.info\/blog\/infrastructure-as-code-kak-poborot-problemy-s-pomoshhyu-xp\/"},"modified":"2019-10-31T22:25:42","modified_gmt":"2019-10-31T19:25:42","slug":"infrastructure-as-code-kak-poborot-problemy-s-pomoshhyu-xp","status":"publish","type":"post","link":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/infrastructure-as-code-kak-poborot-problemy-s-pomoshhyu-xp","title":{"rendered":"Infrastructure as Code: hvordan overvinne problemer med XP","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Hei, Habr! Tidligere har jeg klaget over livet i paradigmet Infrastructure as Code uten \u00e5 foresl\u00e5 l\u00f8sninger p\u00e5 situasjonen. I dag er jeg tilbake for \u00e5 fortelle hvilke tiln\u00e6rminger og praksiser som kan hjelpe oss \u00e5 komme ut av avgrunnen av fortvilelse og styre situasjonen i riktig retning. <\/p>\n<p><img decoding=\"async\" alt=\"Infrastructure as Code: hvordan overvinne problemer med XP\" src=\"\/wp-content\/uploads\/2019\/10\/e23fbf20980e731ae1cdb4719c97eb00.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nI den forrige artikkelen <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/dodopizzaio\/blog\/465137\/\">\u00abInfrastructure as Code: f\u00f8rste bekjentskap\u00bb<\/a><\/noindex> Jeg delte mine inntrykk av dette feltet, pr\u00f8vde \u00e5 reflektere over den n\u00e5v\u00e6rende situasjonen og til og med antydet at standardpraksiser kjent for utviklere kan v\u00e6re til hjelp. Det kan ha sett ut som jeg klaget mye over livet, men det var ingen forslag til hvordan man kunne komme ut av situasjonen. <\/p>\n<h2>Hvem er vi, hvor er vi, og hvilke problemer har vi<\/h2>\n<p>\nN\u00e5 er vi i SRE Onboarding Team, som best\u00e5r av seks programmerere og tre infrastrukturingeni\u00f8rer. Alle pr\u00f8ver \u00e5 skrive Infrastructure as Code (IaC). Vi gj\u00f8r det fordi vi i utgangspunktet kan skrive kode og har en bakgrunn som \u00abover middels\u00bb utviklere. <\/p>\n<ul>\n<li>Vi har en rekke fordeler: en viss bakgrunn, kunnskap om praksiser, evnen til \u00e5 skrive kode, og \u00f8nsket om \u00e5 l\u00e6re noe nytt. <\/li>\n<li>Og det er en s\u00e5rbar del, som ogs\u00e5 er en ulempe: mangel p\u00e5 kunnskap om infrastrukturens materie. <\/li>\n<\/ul>\n<p>\n<b class=\"spoiler_title\">Teknologibunken vi bruker i v\u00e5r IaC.<\/b><\/p>\n<ul>\n<li>Terraform for \u00e5 opprette ressurser.<\/li>\n<li>Packer for \u00e5 bygge bilder. Dette er Windows, CentOS 7 bilder.<\/li>\n<li>Jsonnet for \u00e5 lage kraftige bygg i drone.io, samt for \u00e5 generere packer json og v\u00e5re Terraform-moduler.<\/li>\n<li>Azure.<\/li>\n<li>Ansible for \u00e5 forberede bildene.<\/li>\n<li>Python for hjelpeservere, samt provisjoneringsskripter.<\/li>\n<li>Og alt dette i VSCode med plugins delt mellom teammedlemmene.<\/li>\n<\/ul>\n<p>Min konklusjon var slik: jeg pr\u00f8vde \u00e5 p\u00e5f\u00f8re (f\u00f8rst og fremst meg selv) optimisme, \u00f8nsket \u00e5 si at vi vil pr\u00f8ve kjente tiln\u00e6rminger og praksiser for \u00e5 takle utfordringer og vanskeligheter i dette feltet. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/dodopizzaio\/blog\/465137\/\">den forrige artikkelen<\/a><\/noindex> Akkurat n\u00e5 kjemper vi med slike problemer i IaC: <\/p>\n<p>Ufullkommenhet av verkt\u00f8y og utviklingsmidler.<\/p>\n<ul>\n<li>Langsom deployering. Infrastruktur er en del av den virkelige verden, som kan v\u00e6re treg.<\/li>\n<li>Mangel p\u00e5 tiln\u00e6rminger og praksiser.<\/li>\n<li>Vi er nybegynnere og vet lite.<\/li>\n<li>Ekstrem programmering (XP) skyndter seg til unnsetning.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Ekstrem programmering (XP) skyndter seg til unnsetning.<\/h2>\n<p>\nAlle utviklere er godt kjent med ekstrem programmering (XP) og de praksisene som f\u00f8lger med. Mange av oss har jobbet med denne tiln\u00e6rmingen, og den har v\u00e6rt vellykket. S\u00e5 hvorfor ikke benytte prinsippene og praksisene som er lagt der for \u00e5 overvinne infrastrukturen? Vi har bestemt oss for \u00e5 anvende denne tiln\u00e6rmingen og se hva som kommer ut av det.<\/p>\n<p><b class=\"spoiler_title\">Vurdering av anvendbarheten av XP-tiln\u00e6rmingen til ditt omr\u00e5de<\/b>Her er en beskrivelse av milj\u00f8et der XP passer godt, og hvordan det relaterer til oss: <\/p>\n<p>1. Dynamisk skiftende programvarekrav. Vi hadde klart for oss hva det endelige m\u00e5let var. Men detaljene kan varieres. Vi bestemmer selv retningen vi skal ta, s\u00e5 kravene endres fra tid til annen (for det meste av oss selv). N\u00e5r det gjelder SRE-teamet som b\u00e5de gj\u00f8r automatisering og setter begrensningene for kravene og omfanget av arbeidet, passer dette punktet godt. <\/p>\n<p>2. Risikoer for\u00e5rsaket av faste tidsprosjekter som bruker ny teknologi. Vi kan st\u00e5 overfor risikoer n\u00e5r vi bruker noe vi ikke kjenner til. Og det er 100% v\u00e5rt tilfelle. Hele prosjektet v\u00e5rt er basert p\u00e5 teknologier vi ikke var helt kjent med. Dette er generelt et konstant problem, ettersom det stadig dukker opp mange nye teknologier innen infrastruktur. <\/p>\n<p>3,4. Liten, co-lokalisert utvidet utviklingsteam. Teknologien du bruker, muliggj\u00f8r automatiserte enhets- og funksjonstester. Disse to punktene passer ikke helt for oss. For det f\u00f8rste er vi ikke et co-lokalisert team, og for det andre er vi ni personer, som kan betraktes som et stort team. Selv om mange definisjoner av \u00abstor\u00bb team sier at en stor gruppe er 14+ personer. <\/p>\n<p>La oss se p\u00e5 noen praksiser fra XP og hvordan de p\u00e5virker hastigheten og kvaliteten p\u00e5 tilbakemeldingene.<\/p>\n<h4>Prinsippet om tilbakemeldingssyklusen i XP<\/h4>\n<p>\nEtter min forst\u00e5else er tilbakemelding et svar p\u00e5 sp\u00f8rsm\u00e5let, gj\u00f8r jeg dette riktig, er vi p\u00e5 rett vei? I XP finnes det et guddommelig diagram om dette: tidsbasert tilbakemeldingssyklus. Det interessante er at jo lavere vi befinner oss, jo raskere f\u00e5r vi muligheten til \u00e5 f\u00e5 tilbakemelding for \u00e5 svare p\u00e5 n\u00f8dvendige sp\u00f8rsm\u00e5l. <\/p>\n<p><img decoding=\"async\" alt=\"Infrastructure as Code: hvordan overvinne problemer med XP\" src=\"\/wp-content\/uploads\/2019\/10\/e381fb2d7937cbd1978fd6740e63e790.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDette er et ganske interessant tema for diskusjon, for i IT-industrien er det mulig \u00e5 f\u00e5 tilbakemelding raskt. Tenk deg hvor vanskelig det ville v\u00e6re \u00e5 jobbe med et prosjekt i et halvt \u00e5r og s\u00e5 f\u00f8rst finne ut at det i begynnelsen ble lagt en feil. Dette skjer b\u00e5de i design og i bygging av komplekse systemer. <\/p>\n<p>I v\u00e5rt tilfelle hjelper IaC oss med tilbakemelding. Jeg gj\u00f8r straks en liten justering i skjemaet ovenfor: utgivelsesplanen har ikke en m\u00e5nedlig syklus, men skjer flere ganger om dagen. Til denne syklusen er det knyttet noen praksiser som vi vil se n\u00e6rmere p\u00e5.<\/p>\n<blockquote><p>Viktig: tilbakemelding kan bli l\u00f8sningen p\u00e5 alle de nevnte problemene. Sammen med XP-praksiser kan den trekke oss ut av avgrunnen av fortvilelse.<\/p><\/blockquote>\n<p><\/p>\n<h2>Hvordan trekke seg selv ut av avgrunnen av fortvilelse: tre praksiser<\/h2>\n<p><\/p>\n<h4>Tester <\/h4>\n<p>\nTester nevnes to ganger i XP-tilbakemeldingssyklusen. Dette er ikke tilfeldig. De er ekstremt viktige for hele teknikken med ekstrem programmering. <\/p>\n<p>Det antas at du har enhetstester og akseptansetester. Den f\u00f8rste gir deg tilbakemelding etter noen minutter, den andre etter noen dager, derfor tar det lengre tid \u00e5 skrive dem, og de kj\u00f8res sjeldnere. <\/p>\n<p>Det finnes en klassisk testpyramide som viser at det b\u00f8r v\u00e6re flere av visse tester. <\/p>\n<p><img decoding=\"async\" alt=\"Infrastructure as Code: hvordan overvinne problemer med XP\" src=\"\/wp-content\/uploads\/2019\/10\/29f3217f11b67378c9c0c3f14fab9d61.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHvordan er dette skjemaet anvendelig for oss i IaC-prosjektet? Faktisk\u2026 ikke i det hele tatt. <\/p>\n<ul>\n<li>Selv om det b\u00f8r v\u00e6re mange enhetstester, kan det ikke v\u00e6re for mange. Enten tester de noe veldig indirekte. Faktisk kan vi si at vi ikke skriver dem i det hele tatt. Men her er noen anvendelser for slike tester som vi likevel har f\u00e5tt gjort:\n<ol>\n<li>Testing av kode i jsonnet. Dette er for eksempel v\u00e5r byggpipeline i drone, som er ganske komplisert. Kode i jsonnet dekkes godt av tester. <br \/>\n Vi bruker denne <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/yugui\/jsonnetunit\">Unit testing framework for Jsonnet<\/a><\/noindex>. <\/li>\n<li> Tester p\u00e5 skripter som kj\u00f8res ved oppstart av ressursen. Skriptene er skrevet i Python, og dermed kan testene p\u00e5 dem ogs\u00e5 skrives.<\/li>\n<\/ol>\n<\/li>\n<li>Potensielt er det mulig \u00e5 sjekke konfigurasjonen i testene, men det gj\u00f8r vi ikke. Det er ogs\u00e5 mulig \u00e5 sette opp validering av konfigurasjonsregler for ressurser gjennom <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/wata727\/tflint\">tflint<\/a><\/noindex>. Men for Terraform er det bare for grunnleggende sjekker, men mange sjekkscenarier er skrevet for AWS. Og vi bruker Azure, s\u00e5 dette passer igjen ikke.<\/li>\n<li>Komponentintegrasjonstester: her avhenger det av hvordan du klassifiserer dem og hvor du plasserer dem. Men de fungerer egentlig.\n<p>Slik ser integrasjonstestene ut. <\/p>\n<p><img decoding=\"async\" alt=\"Infrastructure as Code: hvordan overvinne problemer med XP\" src=\"\/wp-content\/uploads\/2019\/10\/b4771e9e5d329ffb2ba565ead7fdddfd.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDette er et eksempel ved bygging av bilder i Drone CI. For \u00e5 komme til dem m\u00e5 man vente i 30 minutter mens Packer-bildet bygges, deretter ytterligere 15 minutter mens de fullf\u00f8res. Men de finnes! <\/p>\n<p><b class=\"spoiler_title\">Algoritmen for \u00e5 sjekke bilder<\/b> <\/p>\n<ol>\n<li>F\u00f8rst m\u00e5 Packer forberede bildet helt.<\/li>\n<li>Ved siden av testen er det Terraform med lokal tilstand, som vi bruker til \u00e5 rulle ut dette bildet. <\/li>\n<li>Under utrullingen brukes en liten modul som ligger ved siden av for enklere arbeid med bildet. <\/li>\n<li>N\u00e5r VM-en er rullet ut fra bildet, kan vi begynne med sjekkene. Hovedsakelig utf\u00f8res sjekkene p\u00e5 maskinen. Vi tester hvordan skriptene fungerte ved oppstart, og hvordan tjenestene fungerer. For dette logger vi inn p\u00e5 den nylig opprettede maskinen via ssh eller winrm for \u00e5 sjekke konfigurasjonsstatusen eller om tjenestene har startet.<\/li>\n<\/ol>\n<p>\n <\/li>\n<li>Situasjonen er lik med integrasjonstester og i modulene for Terraform. Her er en kort tabell som forklarer egenskapene til slike tester.\n<p><img decoding=\"async\" alt=\"Infrastructure as Code: hvordan overvinne problemer med XP\" src=\"\/wp-content\/uploads\/2019\/10\/e2624fb97831701e374a7e8e7fe39a16.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTilbakemelding p\u00e5 pipelinen tar omtrent 40 minutter. Alt g\u00e5r veldig sakte. Det kan brukes til regresjonstesting, men for ny utvikling er det helt urealistisk. Hvis man forbereder seg skikkelig, setter opp kj\u00f8ringer og skripter, kan man kanskje redusere det til 10 minutter. Men det er fortsatt ikke enhetstester, som kan kj\u00f8re 100 tester p\u00e5 5 sekunder. <\/li>\n<\/ul>\n<p>\nMangelen p\u00e5 enhetstester ved bygging av bilder eller Terraform-moduler gj\u00f8r at arbeidet m\u00e5 overlates til separate tjenester, som kan kontaktes via REST, eller til Python-skripter.<\/p>\n<p>For eksempel m\u00e5tte vi gj\u00f8re det slik at n\u00e5r den virtuelle maskinen startet, registrerte den seg i tjenesten <noindex><a rel=\"nofollow\" href=\"https:\/\/www.scaleft.com\/\">ScaleFT<\/a><\/noindex>, og da virtuelle maskinen ble \u00f8delagt, fjernet den seg selv.<\/p>\n<p>Siden ScaleFT er en tjeneste, m\u00e5 vi jobbe med den gjennom API-et. Det ble skrevet en innpakning som vi kan bruke til \u00e5 si: \u00abG\u00e5 inn og fjern dette, dette\u00bb. Den lagrer alle n\u00f8dvendige innstillinger og tilgang. <\/p>\n<p>Vi kan n\u00e5 skrive ordentlige tester for dette, siden det ikke skiller seg fra vanlig programvare: vi lager en mock av et API, du kontakter det, og ser hva som skjer. <\/p>\n<p><img decoding=\"async\" alt=\"Infrastructure as Code: hvordan overvinne problemer med XP\" src=\"\/wp-content\/uploads\/2019\/10\/dc17aaa64038acb080669d31fe8ecfe0.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<blockquote><p>Resultater fra testene: Enhetstesting, som burde gi OS feedback p\u00e5 ett minutt, gir ikke dette. H\u00f8yere niv\u00e5er av testing gir resultater, men dekker bare en del av problemene. <\/p><\/blockquote>\n<h4>Parprogrammering<\/h4>\n<p>\nTester er selvf\u00f8lgelig bra. Du kan skrive mange av dem, de kan v\u00e6re av forskjellige typer. De vil fungere p\u00e5 sine niv\u00e5er og gi oss tilbakemelding. Men problemet med d\u00e5rlige enhetstester, som gir det raskeste OS, vedvarer. Samtidig \u00f8nsker man et raskt OS, det er lett og behagelig \u00e5 jobbe med. Ikke \u00e5 snakke om kvaliteten p\u00e5 l\u00f8sningen som oppn\u00e5s. Heldigvis finnes det teknikker som gir enda raskere tilbakemelding enn modul\u00e6re tester. Det er pareprogrammering.<\/p>\n<p>N\u00e5r du skriver kode, vil du ha tilbakemelding om kvaliteten s\u00e5 raskt som mulig. Ja, du kan skrive alt i en funktionsgren (for ikke \u00e5 \u00f8delegge noe for noen), lage en pull request p\u00e5 GitHub, tildele den til noen med relevant mening, og vente p\u00e5 svar. <\/p>\n<p>Men ventetiden kan bli lang. Folk er travle, og svaret, selv om det kommer, kan ha lav kvalitet. La oss anta at svaret kom umiddelbart, og gjennomgangen umiddelbart forsto hele hensikten, men svaret kommer fortsatt med forsinkelse, i ettertid. Og man \u00f8nsker det tidligere. Det er nettopp derfor pareprogrammering er rettet mot \u2013 for \u00e5 f\u00e5 tilbakemelding umiddelbart, i l\u00f8pet av skriveprosessen.<\/p>\n<p>Her presenterer jeg stilene for pareprogrammering og deres anvendelighet i arbeidet med IaC: <\/p>\n<p><b>1. Klassisk, Erfaren + erfaren, bytte etter et tidsintervall.<\/b> To roller \u2013 driver og navigator. To personer. De jobber med samme kode og bytter roller etter en bestemt tid som er forh\u00e5ndsbestemt. <\/p>\n<p>La oss se p\u00e5 kompatibiliteten mellom v\u00e5re problemer og stilen: <\/p>\n<ul>\n<li>Problem: ufullkommenhet i verkt\u00f8yene for kodeutvikling. <br \/>\nNegativ innvirkning: lengre utvikling, vi bremser, arbeidsrytmen g\u00e5r i stykker.<br \/>\n Hvordan vi takler det: vi bruker andre verkt\u00f8y, felles IDE og l\u00e6rer hurtigtaster.<\/li>\n<li> Problem: langsom distribusjon. <br \/>\nNegativ innvirkning: \u00f8ker tiden det tar \u00e5 lage en fungerende del av koden. Vi kjeder oss mens vi venter, hendene fristes til \u00e5 gj\u00f8re noe annet mens vi venter. <br \/>\nHvordan vi takler det: vi har ikke l\u00f8st det.<\/li>\n<li> Problem: mangel p\u00e5 tiln\u00e6rminger og praksiser. <br \/>\nNegativ innvirkning: ingen kunnskap om hva som er bra eller d\u00e5rlig. Forlenger tilbakemeldingstiden. <br \/>\nHvordan vi takler det: utveksling av meninger og praksiser i paret nesten l\u00f8ser problemet.<\/li>\n<\/ul>\n<p>\nHovudproblemet med \u00e5 bruke denne stilen i IaC er den ujevne arbeidsflyten. I tradisjonell programvareutvikling har en veldig jevn flyt. Du kan bruke fem minutter p\u00e5 \u00e5 skrive N. Bruke ti minutter p\u00e5 \u00e5 skrive 2N, og 15 minutter p\u00e5 \u00e5 skrive 3N. Her kan du bruke fem minutter p\u00e5 \u00e5 skrive N, og deretter bruke enda 30 minutter og skrive en tidel av N. Her vet du ingenting, du st\u00e5r fast, det stopper opp. \u00c5 finne l\u00f8sninger tar tid og avleder fra selve programmeringen. <\/p>\n<blockquote><p>Konklusjon: I sin rene form passer det ikke for oss.<\/p><\/blockquote>\n<p><b>2. Ping-pong. Denne tiln\u00e6rmingen inneb\u00e6rer at \u00e9n deltaker skriver testen, mens en annen lager implementeringen for den.<\/b> Med tanke p\u00e5 at alt med enhetstester er komplisert, og man m\u00e5 bruke mye tid p\u00e5 \u00e5 skrive integrasjonstester, forsvinner all enkelhet i ping-pong. <\/p>\n<p>Jeg kan si at vi har pr\u00f8vd \u00e5 dele ansvaret for \u00e5 utforme testscenarier og implementere koden for dem. \u00c9n deltaker fant p\u00e5 scenariet, og i denne delen av arbeidet var han ansvarlig, og han hadde det siste ordet. Den andre var ansvarlig for implementeringen. Dette fungerte bra. Kvaliteten p\u00e5 scenariene \u00f8kte med denne tiln\u00e6rmingen. <\/p>\n<blockquote><p>Konklusjon: dessverre tillater arbeidsflyten ikke \u00e5 bruke ping-pong som en praksis for parprogrammering i IaC.<\/p><\/blockquote>\n<p>\n <b>3. Strong Style.<\/b> <noindex><a rel=\"nofollow\" href=\"http:\/\/llewellynfalco.blogspot.com\/2014\/06\/llewellyns-strong-style-pairing.html\">En komplisert praksis. Ideen er at \u00e9n deltaker blir en styrende navigator, mens den andre tar rollen som utf\u00f8rende driver. Beslutningsretten tilh\u00f8rer utelukkende navigatoren. Driveren skriver bare og kan med ord p\u00e5virke hva som skjer. Rollene forblir uendret over lengre tid.<\/a><\/noindex>Godt egnet for l\u00e6ring, men krever sterke soft skills. Her stoppet vi ogs\u00e5. Teknikken var vanskelig \u00e5 f\u00f8lge. Og det handler ikke engang om infrastrukturen. <\/p>\n<p>Konklusjon: potensielt kan det brukes, vi gir ikke opp fors\u00f8ket. <\/p>\n<blockquote><p>4. Mobbing, swarming og alle kjente, men ikke nevnte stiler<\/p><\/blockquote>\n<p>\n<b>vurderes ikke, siden vi ikke har pr\u00f8vd dem og ikke kan si noe om dem i konteksten av v\u00e5rt arbeid.<\/b> Generelle oppsummeringer om bruk av parprogrammering:<\/p>\n<blockquote><p>Vi har en ujevn arbeidsflyt som skaper forstyrrelser.<\/p>\n<ul>\n<li>Vi har st\u00f8tt p\u00e5 utilstrekkelige soft skills. Og fagfeltet bidrar ikke til \u00e5 overvinne disse manglene.<\/li>\n<li>Langvarige tester og problemer med verkt\u00f8yene gj\u00f8r parprogrammering vanskelig.<\/li>\n<li>D\u00e5rlig st\u00f8tte i omgivelser og verkt\u00f8y gj\u00f8r utviklingsprosessen treig.<\/li>\n<\/ul>\n<\/blockquote>\n<p><b>5. Til tross for dette var det ogs\u00e5 suksesser. Vi utviklet v\u00e5r egen metode kalt \u00abSammenkomst \u2013 adskillelse\u00bb.<\/b> Jeg skal kort beskrive hvordan den fungerer. <\/p>\n<p>Vi har faste partnere i flere dager (mindre enn en uke). Vi l\u00f8ser en oppgave sammen. En stund sitter vi sammen: en skriver, den andre sitter og observerer, som et supportteam. Deretter separerer vi oss en stund, hver gj\u00f8r sine egne ting, s\u00e5 m\u00f8tes vi igjen, synkroniserer oss raskt, jobber sammen og s\u00e5 skilles vi igjen. <\/p>\n<h4>Planlegging og kommunikasjon<\/h4>\n<p>\nDen siste blokken med praksiser hvor vi l\u00f8ser OS-problemer er organisering av arbeidet med oppgavene selv. Her inng\u00e5r ogs\u00e5 erfaringsutveksling som skjer uten pararbeid. La oss se p\u00e5 tre praksiser:<\/p>\n<p><b>1. Oppgaver gjennom m\u00e5ltreet.<\/b> Den generelle prosjektledelsen har vi organisert gjennom et tre som strekker seg uendelig inn i fremtiden. Teknisk sett f\u00f8res dette i Miro. Det er \u00e9n oppgave \u2013 den er et mellomliggende m\u00e5l. Fra den g\u00e5r det enten mindre m\u00e5l eller grupper av oppgaver. Fra dem g\u00e5r det egen oppgaver. Alle oppgaver opprettes og f\u00f8res p\u00e5 denne tavlen. <\/p>\n<p><img decoding=\"async\" alt=\"Infrastructure as Code: hvordan overvinne problemer med XP\" src=\"\/wp-content\/uploads\/2019\/10\/fe601e959f0055de4f7f4c39ae713c31.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDenne ordningen gir ogs\u00e5 tilbakemelding, som skjer en gang om dagen n\u00e5r vi synkroniserer oss i m\u00f8ter. \u00c5 ha en felles plan, som er strukturert og helt \u00e5pen, gj\u00f8r at alle er oppdatert p\u00e5 hva som skjer og hvor langt vi har kommet i fremdriften. <\/p>\n<p>Fordeler med visuell oversikt av oppgaver:<\/p>\n<ul>\n<li>\u00c5rsakssammenheng. Hver oppgave f\u00f8rer til et overordnet m\u00e5l. Oppgavene grupperes etter mindre m\u00e5l. Domenen for infrastruktur er i seg selv ganske teknisk. Det er ikke alltid helt klart hvilket konkret innvirkning, for eksempel, \u00e5 skrive en h\u00e5ndbok for migrering til en annen nginx, har p\u00e5 bedriften. \u00c5 ha et m\u00e5lkort ved siden av gj\u00f8r dette mer forst\u00e5elig.<br \/>\n <img decoding=\"async\" alt=\"Infrastructure as Code: hvordan overvinne problemer med XP\" src=\"\/wp-content\/uploads\/2019\/10\/fc4da9d277f7dc186a5710cf2be4419c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n \u00c5rsakssammenheng er en viktig egenskap ved oppgaver. Den svarer direkte p\u00e5 sp\u00f8rsm\u00e5let: \u00abGj\u00f8r jeg det riktige?\u00bb <\/li>\n<li>Parallellitet. Vi er ni personer, og det er fysisk umulig \u00e5 kaste seg over \u00e9n oppgave samtidig. Det er ikke alltid nok oppgaver fra ett omr\u00e5de. Vi m\u00e5 n\u00f8dvendigvis parallellisere arbeidet mellom sm\u00e5 arbeidsgrupper. P\u00e5 denne m\u00e5ten jobber gruppene en stund med sin oppgave, og de kan bli styrket av noen andre. Personer kan noen ganger forlate denne arbeidsgruppen. Noen tar ferie, noen holder en presentasjon p\u00e5 DevOps-konferansen, noen skriver en artikkel p\u00e5 Habr. Det blir veldig viktig \u00e5 vite hvilke m\u00e5l og oppgaver som kan gj\u00f8res parallelt. <\/li>\n<\/ul>\n<p>\n<b>2. Rotasjon av ledere for morgenm\u00f8tene.<\/b> Det oppstod et problem i standup-m\u00f8tene - mange oppgaver blir gjort parallelt. Noen ganger er oppgavene svakt knyttet til hverandre og det er ikke klart hvem som gj\u00f8r hva. Men meningen til enda et teammedlem er veldig viktig. Dette er tilleggsinformasjon som kan endre utfallet av oppgavel\u00f8sningen. Selv om det vanligvis er noen i par med deg, er konsultasjoner og tips aldri overfl\u00f8dige. <\/p>\n<p>For \u00e5 forbedre denne situasjonen har vi tatt i bruk teknikken \"Skifte av leder for standup\". N\u00e5 roterer de etter en bestemt liste, og dette har en effekt. N\u00e5r det blir din tur, blir du tvunget til \u00e5 dykke inn og forst\u00e5 hva som skjer for \u00e5 kunne lede scrum-m\u00f8tet godt. <\/p>\n<p><img decoding=\"async\" alt=\"Infrastructure as Code: hvordan overvinne problemer med XP\" src=\"\/wp-content\/uploads\/2019\/10\/622973a654ecd3e27a7a366596814ffc.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>3. Internt demo.<\/b> Hjelp til oppgavel\u00f8sning fra parprogrammering, visualisering p\u00e5 oppgavetreet og hjelp p\u00e5 scrum-m\u00f8tene om morgenen \u2013 det er bra, men ikke perfekt. I par er man begrenset av ens egne kunnskaper. Oppgavetreet hjelper til med \u00e5 forst\u00e5 globalt hvem som gj\u00f8r hva. Lederen og kolleger p\u00e5 morgenm\u00f8tet vil ikke dykke dypt inn i problemene dine. De kan definitivt g\u00e5 glipp av noe. <\/p>\n<p>L\u00f8sningen ble funnet i \u00e5 demonstrere gjort arbeid for hverandre og deretter diskutere det. Vi samles en gang i uken i en time og viser detaljer om l\u00f8sningene p\u00e5 oppgavene vi har gjort den siste uken. <\/p>\n<p>Under demonstrasjonen m\u00e5 man avdekke detaljene i oppgaven og s\u00f8rge for \u00e5 vise hvordan den fungerer. <\/p>\n<p><b class=\"spoiler_title\">Foredraget kan ledes etter en sjekkliste.<\/b>1. Sett i kontekst. Hvor kom oppgaven fra, hvorfor var dette n\u00f8dvendig?<\/p>\n<p>2. Hvordan ble oppgaven l\u00f8st f\u00f8r? For eksempel var det n\u00f8dvendig med masse musklikk, eller var det umulig \u00e5 gj\u00f8re noe som helst.<\/p>\n<p>3. Hvordan forbedrer vi dette. For eksempel: \"Se, n\u00e5 er det et skript, her er readme.\"<\/p>\n<p>4. Vis hva det er som skjer. Det er \u00f8nskelig \u00e5 demonstrere et brukerscenario direkte. Jeg vil ha X, gj\u00f8r Y, ser Z (eller Y). For eksempel, jeg deployer NGINX, checker URL-en, f\u00e5r 200 OK. Hvis handlingen tar lang tid, forbered p\u00e5 forh\u00e5nd, s\u00e5 vi kan vise det senere. Det er best om det ikke er noe som bryter sammen en time f\u00f8r demoen.<\/p>\n<p>5. Forklar hvor godt problemet er l\u00f8st, hvilke vanskeligheter som gjenst\u00e5r, hva som ikke er fullf\u00f8rt, og hvilke forbedringer som kan bli gjort videre. For eksempel, n\u00e5 er det CLI, senere vil det v\u00e6re full automatisering i CI.<\/p>\n<p>Hver taler b\u00f8r fors\u00f8ke \u00e5 holde seg innen 5-10 minutter. Hvis ditt innlegg helt \u00e5penbart er viktig og vil ta lengre tid, avtal dette p\u00e5 forh\u00e5nd i sre-takeover-kanalen.<\/p>\n<p>Etter den fysiske delen er det viktig \u00e5 ha en diskusjon i tr\u00e5den. Her dukker v\u00e5r n\u00f8dvendige tilbakemelding p\u00e5 oppgavene opp. <\/p>\n<p><img decoding=\"async\" alt=\"Infrastructure as Code: hvordan overvinne problemer med XP\" src=\"\/wp-content\/uploads\/2019\/10\/77da888d24b52c7eea7e65d2400e152c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nTil slutt vil det bli gjennomf\u00f8rt en unders\u00f8kelse for \u00e5 vurdere nytteverdien av det som har skjedd. Dette er tilbakemelding p\u00e5 selve presentasjonen og viktigheten av oppgaven.<\/p>\n<p><img decoding=\"async\" alt=\"Infrastructure as Code: hvordan overvinne problemer med XP\" src=\"\/wp-content\/uploads\/2019\/10\/7642cd87050171cc4a6bf278329dd283.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Lange konklusjoner og hva s\u00e5.<\/h2>\n<p>\nDet kan virke som tonen i artikkelen er litt pessimistisk. Det er ikke tilfellet. To grunnleggende niv\u00e5er av tilbakemelding, nemlig tester og parprogrammering, fungerer. Ikke like perfekt som i tradisjonell utvikling, men den positive effekten er der. <\/p>\n<p>Tester, i sin n\u00e5v\u00e6rende form, gir bare delvis dekning av koden. Mange konfigurasjonsfunksjoner viser seg \u00e5 v\u00e6re up\u00e5virket. Deres innvirkning p\u00e5 det direkte arbeidet ved skriving av kode er lav. Men effekten av integrasjonstester er der, og det er disse som tillater oss \u00e5 gjennomf\u00f8re refaktoreringer uten frykt. Dette er en stor prestasjon. Ogs\u00e5 med skiftet fokus mot utvikling i h\u00f8yere programmeringsspr\u00e5k (vi bruker Python, Go) forsvinner problemet. Man trenger ikke mange sjekker p\u00e5 'limet', det holder med generell integrasjon.<\/p>\n<p>Pararbeid er mer avhengig av de spesifikke menneskene. Det er faktoren av oppgaven og v\u00e5re myke ferdigheter. Med noen fungerer det veldig bra, med andre mindre bra. Det er definitivt en fordel. Det er klart at selv ved utilstrekkelig overholdelse av reglene for pararbeid, p\u00e5virker det positive resultatet kvaliteten. Personlig synes jeg det er enklere og hyggeligere \u00e5 jobbe i par.<\/p>\n<p>Mer h\u00f8y-niv\u00e5 m\u00e5ter \u00e5 p\u00e5virke OS \u2013 planlegging og arbeid med oppgaver gir absolutt resultater: kvalitetsutveksling av kunnskap og forbedring av utviklingskvalitet. <\/p>\n<h4>Korte konklusjoner p\u00e5 \u00e9n linje <\/h4>\n<p><\/p>\n<ul>\n<li>XP-praksis fungerer i IaC, men med lavere effektivitet.<\/li>\n<li>Styrk det som fungerer.<\/li>\n<li>Lag dine egne kompenserende mekanismer og praksiser.<\/li>\n<\/ul>\n<p>Kilde: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/dodopizzaio\/blog\/470620\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0420\u0430\u043d\u044c\u0448\u0435 \u044f \u0436\u0430\u043b\u043e\u0432\u0430\u043b\u0441\u044f \u043d\u0430 \u0436\u0438\u0437\u043d\u044c \u0432 \u043f\u0430\u0440\u0430\u0434\u0438\u0433\u043c\u0435 Infrastructure as code \u0438 \u043d\u0438\u0447\u0435\u0433\u043e \u043d\u0435 \u043f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u043b \u0434\u043b\u044f \u0440\u0435\u0448\u0435\u043d\u0438\u044f \u0441\u043b\u043e\u0436\u0438\u0432\u0448\u0435\u0439\u0441\u044f \u0441\u0438\u0442\u0443\u0430\u0446\u0438\u0438. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u044f \u0432\u0435\u0440\u043d\u0443\u043b\u0441\u044f, \u0447\u0442\u043e\u0431\u044b \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c, \u043a\u0430\u043a\u0438\u0435 \u043f\u043e\u0434\u0445\u043e\u0434\u044b \u0438 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0438 \u043f\u043e\u043c\u043e\u0433\u0443\u0442 \u0432\u044b\u0440\u0432\u0430\u0442\u044c\u0441\u044f \u0438\u0437 \u0431\u0435\u0437\u0434\u043d\u044b \u043e\u0442\u0447\u0430\u044f\u043d\u0438\u044f \u0438 \u0432\u044b\u0440\u0443\u043b\u0438\u0442\u044c \u0441\u0438\u0442\u0443\u0430\u0446\u0438\u044e \u0432 \u043f\u0440\u0430\u0432\u0438\u043b\u044c\u043d\u043e\u0435 \u0440\u0443\u0441\u043b\u043e. \u0412 \u043f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0435\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u00abInfrastructure as code: \u043f\u0435\u0440\u0432\u043e\u0435 \u0437\u043d\u0430\u043a\u043e\u043c\u0441\u0442\u0432\u043e\u00bb \u044f \u0434\u0435\u043b\u0438\u043b\u0441\u044f \u0441\u0432\u043e\u0438\u043c \u0432\u043f\u0435\u0447\u0430\u0442\u043b\u0435\u043d\u0438\u0435\u043c \u043e\u0442 \u044d\u0442\u043e\u0439 \u0441\u0444\u0435\u0440\u044b, [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":29066,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-38747","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.5 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0420\u0430\u043d\u044c\u0448\u0435 \u044f \u0436\u0430\u043b\u043e\u0432\u0430\u043b\u0441\u044f \u043d\u0430 \u0436\u0438\u0437\u043d\u044c \u0432 \u043f\u0430\u0440\u0430\u0434\u0438\u0433\u043c\u0435 Infrastructure as code \u0438 \u043d\u0438\u0447\u0435\u0433\u043e \u043d\u0435 \u043f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u043b \u0434\u043b\u044f \u0440\u0435\u0448\u0435\u043d\u0438\u044f \u0441\u043b\u043e\u0436\u0438\u0432\u0448\u0435\u0439\u0441\u044f \u0441\u0438\u0442\u0443\u0430\u0446\u0438\u0438.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/infrastructure-as-code-kak-poborot-problemy-s-pomoshhyu-xp\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.5\" \/>\n\t\t<meta property=\"og:locale\" content=\"nn_NO\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Infrastructure as Code: \u043a\u0430\u043a \u043f\u043e\u0431\u043e\u0440\u043e\u0442\u044c \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u044b \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e XP | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0420\u0430\u043d\u044c\u0448\u0435 \u044f \u0436\u0430\u043b\u043e\u0432\u0430\u043b\u0441\u044f \u043d\u0430 \u0436\u0438\u0437\u043d\u044c \u0432 \u043f\u0430\u0440\u0430\u0434\u0438\u0433\u043c\u0435 Infrastructure as code \u0438 \u043d\u0438\u0447\u0435\u0433\u043e \u043d\u0435 \u043f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u043b \u0434\u043b\u044f \u0440\u0435\u0448\u0435\u043d\u0438\u044f \u0441\u043b\u043e\u0436\u0438\u0432\u0448\u0435\u0439\u0441\u044f \u0441\u0438\u0442\u0443\u0430\u0446\u0438\u0438.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/infrastructure-as-code-kak-poborot-problemy-s-pomoshhyu-xp\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:25:42+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:25:42+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Infrastructure as Code: hvordan takle problemer ved hjelp av XP | ProHoster","description":"Hei, Habr! Jeg klaget tidligere p\u00e5 livet i paradigmet Infrastructure as Code og tilb\u00f8d ikke noen l\u00f8sninger p\u00e5 situasjonen.","canonical_url":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/infrastructure-as-code-kak-poborot-problemy-s-pomoshhyu-xp","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nn_NO","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Infrastructure as Code: \u043a\u0430\u043a \u043f\u043e\u0431\u043e\u0440\u043e\u0442\u044c \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u044b \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e XP | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0420\u0430\u043d\u044c\u0448\u0435 \u044f \u0436\u0430\u043b\u043e\u0432\u0430\u043b\u0441\u044f \u043d\u0430 \u0436\u0438\u0437\u043d\u044c \u0432 \u043f\u0430\u0440\u0430\u0434\u0438\u0433\u043c\u0435 Infrastructure as code \u0438 \u043d\u0438\u0447\u0435\u0433\u043e \u043d\u0435 \u043f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u043b \u0434\u043b\u044f \u0440\u0435\u0448\u0435\u043d\u0438\u044f \u0441\u043b\u043e\u0436\u0438\u0432\u0448\u0435\u0439\u0441\u044f \u0441\u0438\u0442\u0443\u0430\u0446\u0438\u0438.","og:url":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/infrastructure-as-code-kak-poborot-problemy-s-pomoshhyu-xp","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:25:42+00:00","article:modified_time":"2019-10-31T19:25:42+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"38747","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 23:16:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:04:30","updated":"2026-01-23 23:16:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts\/38747","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/comments?post=38747"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts\/38747\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media\/29066"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media?parent=38747"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/categories?post=38747"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/tags?post=38747"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}