Så använder du DevOps-mätvärden för att skala upp ditt företag

Den här artikeln utforskar viktiga DevOps-mätvärden och hur du mäter dem för att fastställa relevanta resultatindikatorer. Därefter tar vi reda på hur du använder dessa mätvärden för att effektivt skala verksamheten.

De 5 pelarna för processmognad

DevOps kombinerar och automatiserar processer, metoder och verktyg som används inom programvaruutveckling och drift för att öka kvaliteten och hastigheten i utvecklingslivscykler.

Implementering av affärsprocesser har fem viktiga pelare, som kallas förmågemognadsmodellen (CMM). Den här modellen fokuserar på fem mognadsnivåer för implementering och kontinuerlig förbättring av tjänste- eller produktutveckling i din affärsmodell.

De fem pelarna har många variationer, men initial, repeterbar, definierad, kapabel och effektiv är de ursprungliga stadierna. Ett alternativ är kultur, automatisering, mätning, delning och återkoppling. Varje stadium har samma innebörd; det är bara benämningarna som har utvecklats.

Här är ett exempel på de fem pelarna för processmognad, med korta beskrivningar av varje pelare:

Det finns flera mätvärden och ramverk som kan användas för att implementera och mäta framgången med DevOps i ditt team. Låt oss utforska dessa i det här avsnittet.

Principbaserade DevOps-ramverk

Det finns tre huvudsakliga principbaserade ramverk inom DevOps. Principbaserat syftar på ett praktiskt tillvägagångssätt med breda riktlinjer, i motsats till ett regelbaserat tillvägagångssätt med föreskrivna steg.

Accelerate-ramverket

Författarna Dr. Nicole Forsgren, Jez Humble och Gene Kim undersöker vad som skiljer högpresterande teknikföretag från andra i sin bok ”Accelerate: Vetenskapen bakom lean-programvara och DevOps: Att bygga och skala högpresterande teknikorganisationer”.

Det är i den här boken som Accelerate-ramverket för DevOps har sitt ursprung. Ramverket fokuserar på tekniska metoder och ledningsmetoder i DevOps-team för högpresterande teknikorganisationer. Du kan se det som en studie av bästa praxis för ett DevOps-team.

De tre viktigaste fokusområdena inom tekniska metoder är:

• Kontinuerlig leverans: Kontinuerlig leverans omfattar områden som versionshantering, kontinuerlig integration, distribution och testautomatisering samt hantering av testdata. Även om kontinuerlig leverans är en princip i sig används den som ett samlingsbegrepp inom Accelerate-ramverket. Anledningen till detta är att DevOps-team på högsta nivå genomför dessa delar samtidigt i stället för isolerade från varandra.
• Arkitektur: Högpresterande DevOps-team visade sig utföra merparten av testerna utan behov av en integrerad miljö, distribuera nya applikationer oberoende av de applikationer de är beroende av samt prioritera testning och distribuerbarhet framför den senaste tekniken.
• Produkt och process: Kundfeedback efterfrågas regelbundet under hela utvecklingen, samtidigt som teamen arbetar i små batcher, experimenterar och kontinuerligt optimerar processerna. Detta visade sig skapa värde, åtgärda buggar snabbt och möjliggöra en återkopplingsslinga från kunderna.

Det finns två viktiga fokusområden inom ledningsmetoder. Dessa är:

• Lean-ledning och övervakning: Accelerate-ramverket visade att minimala godkännandeprocesser förbättrar prestandan vid programvaruleveranser jämfört med team som behöver godkännande från tredje part. Övervakningskapacitet med begränsningar för pågående arbete och visuella verktyg för projektledning förbättrar också prestandan.
• Kultur: Ramverket lägger stor vikt vid betydelsen av att skapa rätt arbetsmiljö för bättre DevOps-prestanda. Samarbete och lärande är två viktiga ingredienser, tillsammans med ett stödjande och uppmuntrande förhållningssätt till lagarbete. Dessa team bör få stöd av ett transformerande ledarskap. Personer i denna position tenderar att vara motiverande och intellektuellt stimulerande samt att uppmärksamma teamets prestationer.

”Ledtid för ändringar” är ett DevOps-mått som vi utforskar mer i detalj nedan. Det mäter hur lång tid en kodändring tar från att en utvecklare checkar in den tills den har distribuerats till produktion. Genom att tillämpa detta mått inom Accelerate-ramverket kan du mäta och förbättra hastigheten och effektiviteten i programvaruleveransprocessen, vilket leder till snabbare och mer tillförlitliga distributioner.

Ramverket med tre vägar

Ramverket med tre vägar introducerades i Phoenix-projektet, skrivet av Gene Kim, Kevin Behr och George Spafford, och förekommer i DevOps-handboken. Det förbättrar DevOps-resultaten genom att fokusera på principerna flöde, återkoppling och kontinuerligt lärande.

Här är en översikt över ramverket med tre vägar:

• Den första vägen: flödestänkande:

Den första vägen handlar om att uppnå ett oavbrutet arbetsflöde från utveckling till drift och att snabbt och tillförlitligt leverera värde till kunderna.

”Ledtid till produktion” är ett mått du kan använda här genom att mäta tiden det tar för en kodändring att gå från den första incheckningen till att den distribueras i produktionsmiljön. Målet är att minska ledtiden genom att optimera leveranspipeline, automatisera processer och minimera manuella ingripanden.

• Den andra vägen: förstärk återkopplingslooparna

Den andra vägen etablerar snabba och effektiva återkopplingsloopar genom hela programvaruleveransprocessen för att möjliggöra kontinuerligt lärande, förbättring och kvalitetssäkring.

Med hjälp av måttet ”genomsnittlig tid till upptäckt (MTTD)” beräknar du den genomsnittliga tid det tar att upptäcka ett problem eller en avvikelse efter att en kodändring har distribuerats till produktion. Fokusera på att minska MTTD genom att förbättra övervakning, larmsystem och återkopplingsloopar för att snabbt identifiera och åtgärda problem.

• Den tredje vägen: en kultur av kontinuerligt experimenterande och lärande

Den tredje och sista vägen uppmuntrar till en kultur av kontinuerligt lärande, experimenterande och risktagande för att driva innovation, anpassningsförmåga och organisatorisk tillväxt.

Måttet ”ändringsfelgrad” är idealiskt att tillämpa här. Du följer andelen kodändringar som leder till fel eller problem efter distributionen. Skapa en experimentkultur genom att skapa en trygg miljö för testning, lära av misslyckanden och kontinuerligt förbättra processerna för att minska ändringsfelgraden.

CALMS-ramverket

CALMS-ramverket omfattar principerna kultur, automatisering, lean, mätning och delning. Det är ett idealiskt alternativ för team som vill övergå till ett DevOps-arbetssätt för programvaruutveckling och eliminera arbete i separata silor mellan utvecklings- och driftteamen.

Du har redan hört talas om skaparen av CALMS-ramverket, eftersom han var medförfattare till Accelerate och DevOps-handboken, där Accelerate- respektive ramverket med tre vägar beskrivs. Jez Humble skapade CALMS-ramverket som en lämplighetsbedömning av huruvida företag är organiserade och redo att införa DevOps-processer.

I likhet med CMM, men specifikt för administration av DevOps, kan du använda CALMS-ramverket för att testa om ditt företag är redo.

Det här är de fem pelarna att följa:

• Kultur: Dina utvecklings- och driftteam har arbetat inom sina egna grupper, var och en med sina egna processer och kommunikationsstilar. Du måste främja en känsla av gemensamt ansvar för att säkerställa en DevOps-redo kultur.
• Automatisering: DevOps handlar om att effektivisera processer, öka hastigheten och förbättra effektiviteten. Nyckeln? Automatisering. Dina team behöver förbereda sig på att automatisera manuella uppgifter och procedurer där det är möjligt. Detta steg stöder kontinuerligt byggande, testning, distribution och övervakning av programvaruversioner som utgör DevOps-livscykeln.
• Lean: Principerna för lean-metoden, ett arbetssätt för affärs- och projektledning, används för att minimera slöseri och optimera värdeflöden. Du måste hålla arbetskapaciteten realistisk och visualisera projektstatusar för att snabba upp processerna.
• Mätning: Ditt företag kan vara redo att införa DevOps om du har kommit så här långt och dina team är engagerade i att samla in och analysera data för att förbättra processerna.
• Delning: Utöver en kultur av gemensamt ansvar behöver dina team vara öppna och villiga att dela data och information, så att alla arbetar mot samma gemensamma mål i stället för att konkurrera. Denna sista bedömningspunkt säkerställer smidiga överlämningar och snabb tillväxt.

Get Free Access

Get regular tech leadership wisdom for delivering better software and systems.

Create Free Account

Have an account? Log In

Utmaningar vid implementering av DevOps

En av de största utmaningarna med att implementera DevOps är motståndet mot kulturförändringar. Ni har två team, vart och ett med sina egna processer, verktyg och kommunikationsstilar. Att omvandla dem till en sammanhållen enhet med gemensamma mål, ansvarsområden och mätvärden är en betydande förändring. Att upprätthålla en hög arbetsmoral och ett transparent förhållningssätt till varje steg i implementeringsprocessen är avgörande för att säkerställa en smidig övergång. Kostnaden för nya verktyg och metoder behöver också beaktas.

Om ert team föredrar att följa regelbaserade ramverk kan det vara en stor omställning att börja arbeta med principbaserade ramverk. Arbetet är snabbfotat och utvecklas ofta tillsammans med teamet, så det kan vara komplext att navigera för medarbetare som har använt traditionella metoder i många år eller för nya teammedlemmar som ska hitta sin plats i den dynamiska miljön.

Slutligen kan det kontinuerliga arbetsflödet orsaka olika sårbarheter, där programvaruversioner distribueras utan datakryptering eller autentisering och med buffertspill. Detta kan utsätta DevOps-team för säkerhetsrisker och intrång, så det är viktigt att skärpa processerna kring detta medan ert DevOps-team mognar. Det är också därför implementeringen inte bör påbörjas förrän CALMS-ramverket har använts för att bedöma om ni är redo.

Varför är DevOps-mätvärden viktiga?

Som framgick ovan kan gemensamma mål och mätvärden vara en utmaning för team som inför DevOps i en verksamhet. Utan DevOps-mätvärden skulle det inte finnas någon testning eller mätning och inga förbättringar av utvecklingen. Det skulle bara vara upprepningar av samma programvara baserade på gissningar och idéer, som skickas ut i tomma intet, varefter man försöker med något nytt. Utan återkoppling eller mätvärden för produktframgång för att förstå hur något presterar finns det ingen riktning.

Finansavdelningar vill till exempel hålla kostnaderna så låga som möjligt, medan utvecklare vill hålla prestandan så hög som möjligt. Dessa två mål kanske inte överensstämmer om inte riskerna har bedömts och teamen förstår varandras målsättningar.

Där era utvecklare kanske väljer att leverera en ofullständig produkt och hantera det senare, leder kostnaden för denna påverkan till teknisk skuld. Genom att implementera DevOps kan målen och strategierna för båda teamen samordnas, och ni kan hjälpa era utvecklare att förstå kostnadseffekten av deras tekniska beslut.

Detta är bara en liten del av DevOps och betydelsen av gemensamma mätvärden.

Förstå DevOps-mätvärden

Att implementera DevOps och förstå principbaserade ramverk är en sak, men det är med DevOps-mätvärden som ni verkligen börjar se fördelarna med detta samarbetsinriktade förhållningssätt till programvaruutvecklingens livscykel. Precis som med de flesta affärsstrategier finns det oändligt många mätvärden ni kan välja att mäta för att främja tillväxt, beroende på bransch, målgrupp och mål.

Google Clouds team för forskning och utvärdering av DevOps (DORA) är det längst verksamma forskarteamet av sitt slag. Ursprungligen identifierade de fyra nyckelmätvärden för att mäta prestationen hos de ”elitteam” som arbetade med DevOps. Sedan dess har ett femte nyckelmätvärde lagts till, och deras klusteranalys identifierar nu endast tre nivåer av DevOps-team: hög, medelhög och låg, där ”elit” tillhör det förflutna.

De fyra viktigaste DORA-mätvärdena

Här är en närmare titt på de fyra DORA-mätvärdena:

1. Distributionsfrekvens (DF)

DF mäter hur ofta ni framgångsrikt lanserar i produktion. Detta mätvärde handlar om konsekvens och är en utmärkt indikation på att målen uppnås.

Team i kategorin ”elit” skulle konsekvent distribuera till produktion flera gånger dagligen, medan lågpresterande team skulle ligga närmare en gång var sjätte månad.

Att förbättra DF är så enkelt som att lansera flera mindre uppdateringar. Den främsta fördelen med detta är att synliggöra eventuella processhinder, flaskhalsar eller komplexa projekt som kräver uppmärksamhet. Större team kan föredra att distribuera med regelbundna intervall genom att bygga agila releasetåg; detta bidrar till att minska överväldigandet som följer av ett extremt tempo och många involverade personer.

2. Ledtid för ändringar (LTC)

LTC avser den tid det tar för en kodändring att nå produktion. Detta mätvärde är en bra indikator på teamets reaktionsförmåga och smidighet, eftersom det mäter hur snabbt teamet kan agera på användarnas behov och efterfrågan.

Den äldre ”elitstandarden” skulle sikta på mindre än en dag för LTC, medan team med lägre prestanda kan behöva mer än sex månader. Att prestera i den lägre delen av skalan för LTC beror sannolikt på ineffektiva processer.

Du kan förbättra detta mätvärde genom att förbättra automatiseringsprocesserna, särskilt testningen. Genom att förbättra din pipeline för kontinuerlig integration och kontinuerlig leverans (CI/CD) kan du få ut uppdateringar i produktion snabbare. En risk att vara uppmärksam på här är dock hållbarheten. Om ditt team inte kan upprätthålla den förbättrade takten kan du drabbas av en dålig användarupplevelse och potentiella säkerhetssårbarheter.

3. Frekvens för ändringsfel (CFR)

CFR är andelen distributioner som orsakar ett fel i produktionen. Felet kan innebära driftstopp, återställningar eller försämrad tjänst. Detta mätvärde visar hur effektivt ditt team är när det distribuerar ändringar.

Riktvärdena för elitprestanda är 0–15 %, medan hög, medelhög och låg prestanda alla ligger inom 16–30 %.

Att förbättra CFR handlar om kvalitet framför kvantitet. Företag släpper olika många ändringar och har därför också olika många fel. Ändringar av högsta kvalitet leder dock till färre fel, oavsett om de distribuerar ändringar två gånger om året eller två gånger om dagen.

4. Genomsnittlig tid till återställning (MTTR)

MTTR är den tid det tar för ditt team att återställa tjänsten efter ett fel eller en störning. Detta mätvärde mäter inte bara teamets smidighet, utan är också ett bra mått på stabiliteten i din programvara.

Om du siktar på elitnivå behöver du sikta på en MTTR på mindre än en timme. Team med låg prestanda kan behöva mer än sex månader.

Du kan förbättra MTTR genom att fokusera på mindre och snabba releaser, vilket gör fel enklare att hitta och åtgärda. Du kan också utforska funktionsflaggor för att ge teamet mer kontroll – särskilt om de är experimentella.

Det finns ytterligare ett mätvärde att gå igenom.

5. Tillförlitlighet

Det femte mätvärdet är tillförlitlighet. Detta mätvärde upptäcktes senare av DORA-teamet (2021), eftersom tillgänglighet tidigare hade mätts som ett riktvärde för tillförlitlig programvara. Man beslutade dock att tillförlitlighet bättre omfattar tillgänglighet, fördröjning, prestanda och skalbarhet. Det innebär i praktiken att mätning av driftsmässig prestanda inkluderas tillsammans med utvecklingen.

Andra anmärkningsvärda DevOps-mätvärden

• Cykeltid: Cykeltid är den totala tiden från det att en uppgift påbörjas tills den levereras slutgiltigt. På ytan följer den teamets arbetstakt. Du kan dock analysera detta mätvärde djupare för att hitta flaskhalsar som långa köbildningstider och pull requests som tar lång tid att slutföra.
• Genomsnittlig tid mellan fel (MTBF): MTBF mäter den genomsnittliga tiden mellan systemfel, driftstopp eller incidenter. Detta mätvärde utvärderar tillförlitligheten och stabiliteten i dina programvarusystem och belyser effektiviteten i strategierna för förebyggande underhåll och felhantering.
• Genomsnittlig tid till upptäckt (MTTD): Detta är den genomsnittliga tiden det tar för ditt team att uppmärksamma ett fel. Ett lågt MTTD visar på effektiva system för övervakning och aviseringar, vilket möjliggör snabb incidenthantering och lösning.
• Tid till begränsning (TTM): TTM är den tid det tar att åtgärda ett problem efter att det har upptäckts. Detta mätvärde hjälper till att bedöma processerna för incidenthantering och lösning och visar hur effektivt dina team hanterar och återhämtar sig från problem.
• Ledtid för ändringar (CLT): CLT ger ett riktvärde för processen att implementera ändringar från början till slut, inklusive utveckling, testning, granskning och distribution. En kortare CLT innebär snabbare leveranscykler och ökad smidighet.
• Andel fel som släpps igenom: Andelen fel som släpps igenom anger hur många buggar som missas under testningen och släpps till produktionen – hur många som har ”sluppit igenom”. Detta mätvärde är idealiskt om du vill följa förbättringar av testnings- och automatiseringsprocesserna.

Så ställer du in KPI:er med DevOps-mätvärden

Nu när du har en god förståelse för vilka mätvärden du kan använda för att implementera och optimera DevOps i din verksamhet vill du utforska nyckelprestationsindikatorer (KPI:er) för att fastställa mål och riktvärden för ditt team.

Mätvärden jämfört med KPI:er

Du kanske undrar vad skillnaden är mellan mätvärden och KPI:er. Ett mätvärde är det du mäter. Det är ett kvantifierbart mått som ger data om en specifik prestationsaspekt. Alla mätvärden är inte nödvändigtvis kopplade till specifika mål eller målsättningar.

KPI:er är däremot en typ av mätvärde som strategiskt väljs ut och definieras för att återspegla de mest kritiska aspekterna av prestation och framsteg mot strategiska mål. KPI:er är vanligtvis kopplade till mål och har ofta tillhörande målvärden, tröskelvärden eller riktmärken som måste uppnås.

Fastställa KPI:er för ditt DevOps-team

Det första steget när du fastställer KPI:er för ditt DevOps-team är att koppla DevOps-mätvärden till din affärsstrategi och dina mål. Genom att prioritera de viktigaste mätvärdena att följa upp kan du börja fastställa målvärden och riktmärken för kontinuerlig förbättring. När du väljer rätt mätvärden behöver du ta hänsyn till företagets storlek, produkt och marknad. Fokusera på det som ger de mest användbara insikterna och undvik den vanliga fallgropen att använda för många mätvärden.

Att övervaka dina KPI:er är lika viktigt som att fastställa dem. Utforska verktyg för datavisualisering för att ge ditt team realtidsdata i intuitiva instrumentpaneler. Detta säkerställer full insyn, skapar ansvar och gör det möjligt för alla att arbeta tillsammans mot gemensamma mål, förena utvecklings- och driftteamen samt stödja införandet och mognaden av DevOps.

Om vi utgår från DORA:s kärnmätvärden kan vi se riktmärkena för varje mätvärde baserat på team med elitnivå samt hög, medelhög och låg prestation. Den här tabellen kan hjälpa dig att fastställa KPI:er för den egna verksamheten, beroende på vad du definierar som en prioritet.

När du fastställer dina KPI:er är det bäst att noggrant ta hänsyn till ditt team och din verksamhet utan att jämföra dem med andra företag. Om vi tar CFR som exempel är riktmärket detsamma för hög, medelhög och låg prestation. Detta beror i hög grad på din driftsättningsfrekvens, men kan också påverka den i motsatt riktning. Om ditt team lägger all sin tid på att åtgärda fel får de mindre tid över till att utveckla och släppa uppdateringar. KPI:er kan också förändras när ditt DevOps-team mognar. Robusta automatiserings- och testprocesser bör automatiskt innebära att du kan höja ribban för dina målvärden.

Så använder du DevOps-mätvärden för att skala upp

Med en global DevOps-marknad som förväntas nå 24.71 miljarder dollar år 2027 (en sammansatt årlig tillväxttakt på 22.9 %, baserat på marknadsstorleken på 10.84 miljarder dollar 2023) kan du se detta som ett tecken om du letar efter rätt tidpunkt att börja införa DevOps i din verksamhet.

DevOps påskyndar inte bara utvecklingen och minskar tiden till marknaden, utan förbättrar också samarbetet genom att eliminera silos, höjer kvaliteten genom kontinuerlig testning och återkopplingsloopar samt använder resurser effektivt, vilket sparar pengar. Slutligen är det enkelt att skala upp och stöder företagstillväxt till nya nivåer, där 83 % av IT-beslutsfattarna fick tillgång till högre affärsvärde genom att införa DevOps under 2021.

Prestationsmätning och kontinuerlig förbättring

Att övervaka prestandan är nyckeln till att skala upp en verksamhet som använder DevOps. Det är ett snabbt arbetssätt med ett kontinuerligt produktionsflöde, så mätning och rapportering bör ske lika ofta. DevOps-mätvärden gör det möjligt att följa upp prestandan i utvecklings- och leveransprocesserna. Genom att kvantifiera viktiga aspekter som driftsättningsfrekvens, ledtid och ändringsfelgrad kan du identifiera flaskhalsar, ineffektivitet och förbättringsområden. Detta gör det möjligt att optimera arbetsflöden och processer regelbundet.

Genom att följa upp mätvärden som ändringsfelgrad och genomsnittlig återställningstid kan du identifiera trender som gör det möjligt att upptäcka problem tidigt. Detta proaktiva arbetssätt innebär att du kan vidta korrigerande åtgärder och minimera påverkan på kunderna, vilket ger tillförlitlighet – ytterligare en viktig ingrediens för att skala upp med hög kvalitet.

Slutligen bidrar användningen av DevOps-mätvärden till att utveckla ditt DevOps-team genom att skapa en kultur av kontinuerlig förbättring. Återkopplingsloopar främjar lärande och utveckling; det måste alltid finnas utrymme för att experimentera med olika metoder.

Vilka DevOps-mätvärden stöder företagstillväxt?

När du fastställer KPI:er bör de flesta mätvärden bedömas utifrån ditt team och dess tillväxtförutsättningar, snarare än jämföras med andra företag och grupper på olika mognadsnivåer.

En låg LTC kan till exempel visa att ditt team är effektivt, men om de inte kan upprätthålla tempot är det inte hållbart och kan så småningom påverka användarupplevelsen. Detta mätvärde bör mätas över tid i stället för att fastställa ett KPI som motsvarar ett högpresterande eller till och med elitmässigt, moget DevOps-team. Att fastställa KPI:er för att minska LTC månad för månad, kvartal för kvartal eller år för år visar på tillväxt inom ditt team och företag.

CFR är ett värdefullt mätvärde eftersom alla inte har samma antal fel eller problem, men genom att ange detta i procent kan du mäta hur framgångsrika dina utrullningar är. Ditt team kan ha mycket få fel om ni släpper ändringar sällan, men om varje lansering orsakar ett problem blir CFR mycket hög. Om du följer CI/CD-metoder kan du se ett högre antal fel, men om din CFR är låg har du en fördel eftersom du har snabbhet och kvalitet som stöd för tillväxt. MTTR bör också mätas över tid för att säkerställa en stadig utveckling.

DORA fann att team på alla nivåer av utvecklingsprestanda uppnådde bättre resultat när de fokuserade på operativ prestanda. Det kan innebära att fastställa KPI:er för incidentrapporter eller öppna ärenden, applikationens drifttid och tillgänglighet.

Ett stort antal öppna ärenden kan tyda på ett problem med kundnöjdheten, men att sträva efter en minskning över tid speglar utveckling inom detta område. Du kan gå djupare och mäta svarstider och kötid för att påskynda förbättringen av detta mätvärde.

Det enda mätvärde som helt kombinerar utveckling och drift som ett DevOps-team är cykeltiden. Detta skapar utrymme för att bygga en kultur av återkoppling och tillväxt. När andra mätvärden förbättras och automatiseringen mognar bör du förvänta dig att cykeltiden minskar. Om din kundservice håller hög nivå och utvecklingsfelen är få har du hittat en vinnande kombination för att skala upp verksamheten.

Anamma en mätetalstyrd kultur för långsiktig framgång

Vi har upptäckt hur datadrivet beslutsfattande kan implementeras genom att följa upp och mäta lämpliga DevOps-mätvärden. Rätt tillvägagångssätt kan förbättra teamets prestation, processeffektiviteten och kundnöjdheten.

Även om alla DevOps-ramverk kretsar kring kultur, samarbete och kontinuerliga förbättringar kommer det att stödja ditt företag att skala mest effektivt att identifiera vilket ramverk och vilka mätvärden som passar din tillväxtstrategi.

Kom ihåg att prenumerera på vårt nyhetsbrev för att hålla dig uppdaterad om det senaste från våra branschexperter.