Att jämföra leverantörer på papper är alltid enklare än att leva med deras tjänster i produktion. När valet står mellan två namn som ofta dyker upp i samma upphandling, STV och Mividas, hänger mycket på hur de hanterar tre frågor som avgör vardagen för din driftorganisation: serviceavtal, tillgänglighet och redundans. Det är sällan marknadsbladet ger hela bilden. Det gör däremot hur snabbt du får hjälp vid en störning klockan 02.15, hur väl ändringsfönster planeras samt vad som faktiskt händer när en region går ner, en fiber klipps eller en liten men kritisk komponent blir överbelastad.
Jag har sett både små och stora organisationer göra kloka val och mindre kloka misstag här. Det som väger tyngst är sällan vilken logotyp som sitter på rackdörren, utan hur tydligt, mätbart och testat leveransen är. Den här texten tar sikte på att hjälpa dig ställa rätt frågor och värdera svaren, oavsett om diskussionen råkar heta Mividas vs STV, STV vs Mividas eller något annat. I bruset kring varumärken förekommer ibland stavningen Mivida, men i de flesta fall syftar man på Mividas. Håll blicken på sakfrågorna, inte på etiketterna.
När ett SLA blir mer än en procentsats
Ett SLA uppfattas ofta som en siffra i en broschyr. 99,9 procent låter bra, 99,99 låter bättre. I praktiken behöver du titta på hur siffran definieras, mäts och kompenseras. Skillnaden mellan en robust, verifierbar 99,9 och en fluffig 99,99 med många undantag är större än en decimal.
Börja med definitionen av tillgänglighet. Räknas kundens ände av slingan med, eller bara leverantörens kärna? Är kundporten med i SLA, eller slutar ansvaret vid en nod i deras nät? Mätpunkten betyder allt den dag det smäller. Om STV säger att de mäter på gränssnittet i din fastighet och Mividas mäter i sin core blir slutsatsen en annan. Det ena är inte automatiskt bättre, men konsekvensen för incidenthantering och ansvarsfördelning är stor.
Fortsätt med tidsfönstret. En årsberäkning kan ge intryck av få minuter i månaden, men flera korta avbrott under arbetstid kan kosta betydligt mer än ett längre under en helg. Vissa leverantörer exkluderar planerat underhåll från SLA, andra begränsar hur ofta sådant får ske eller kräver att det läggs utanför definierade produktionsfönster. Jag brukar fråga efter statistik på antalet och längden av planerade underhåll det senaste året, inte bara löftet om hur många som planeras kommande kvartal.
Servicekrediter lockar i säljpitchen men avlastar inte operations när systemet ligger. Kolla taket för krediter, kumulering, och om krediter utgår även vid flera korta incidenter under en månad. Titta särskilt efter så kallade carve outs, till exempel force majeure, tredjepartsfel eller DDoS. Listan behöver finnas, men när den blir lång nog att täcka de vanligaste felen förlorar SLA:t sitt affärsvärde.
Slutligen, reaktionstider. Differensen mellan en reaktiv support som svarar inom en timme och en som har proaktiv övervakning, larmar före dig och påbörjar mitigation omedelbart avgör hur långt ett avbrott hinner eskalera. När jag jämför två leverantörer låter jag dem visa riktiga incidentrapporter, med tidsstämplar för upptäckt, diagnos, åtgärd och återställning. Det är ofta mer avslöjande än själva SLA-dokumentet.
Tillgänglighet i arkitekturen, inte bara i texten
Tillgänglighet kommer ur designval. Ett nät eller en plattform som är byggd för att tåla fel beter sig annorlunda än ett system som förlitar sig på att inget går snett. De flesta leverantörer talar om N+1, georedundans eller aktiv redundans, men begreppen kan betyda olika saker i praktiken.
Fråga hur kontrollplanet och dataplanet separeras. Ett klassiskt scenario är att dataplanet fortsätter men att kontrollplanet hänger, vilket gör att ny trafik, sessioner eller policyändringar fastnar. En annan vanlig svaghet är single-tenant komponenter som blir flaskhalsar vid lasttoppar, till exempel en autentiseringstjänst som inte skalar lika linjärt som resten. Du vill veta om lastbalansering sker på L4 eller L7, hur state hanteras mellan noder och om ögonblickliga fel, flapping eller asymmetrisk routing kan uppstå under failover.
Geografi spelar in. Multi-site kan vara allt från två rack i samma hall till två regioner i olika länder med oberoende kraft och transport. Det låter lika självklart som det är lätt att slira på i formuleringar. Be om nätkartor, inte bara av kärnan utan hela vägen till din anslutningspunkt. Jag har suttit i incidentrum där en leverantör med två hallar i samma stad åkte på samma strömavbrott när ett regionalt nätstörningsscenario slog till. Deras SLA var formellt intakt, men kundens verksamhet var nere i fem timmar.
Tidszoner och säsongsvariationer spelar också roll. Vissa team är bemannade bättre kontorstid, andra i 24x7 rotation. Du märker det när patchfönster måste läggas nattetid lokal tid och en global leverantör kör rutiner klockan 02.00 CET för att de ligger i linje med 17.00 i en annan region. Rätt bemanning och rätt processer väger ofta tyngre än flashig teknik.
Redundans som är testad, inte bara beskriven
Det finns två sorters redundans. Den som fungerar på whiteboarden och den som klarar verkligheten. Aktiv aktiv ger i regel snabbare felåterställning men är mer känslig för split brain och replikationsproblem. Aktiv passiv är enklare men kräver tydlig dirigeringslogik, annars fastnar trafiken mellan två världar. Vilket som är bäst beror på din applikationsprofil och hur leverantören implementerat sin styrning.
Titta på RPO och RTO på datalager, konfiguration och sessioner. En låg RTO på trafik betyder lite om ett bakomliggande state-databas tar minuter att komma upp, eller om licens- och policytjänster saknar lika bra redundans. Här faller många miljöer vid praktiska tester. Jag har sett failover som tar tre minuter, men där tillståndsdata för policy först konsolideras efter ytterligare sju. Resultatet blir selektiva fel, inte totala, vilket är svårare att upptäcka och åtgärda under press.
Instrumenteringen är avgörande. En driftorganisation som snabbt ser var felkedjan brustit reparerar snabbare. Det behövs mätare på varje lager, larm på rätt trösklar och framför allt runbooks som stämmer med verkligheten. Be leverantören demonstrera sin observability, inklusive hur de korrelerar händelser och väljer åtgärd.
STV vs Mividas i praktiken, hur man jämför på rätt sätt
Varje gång jag sett en bra jämförelse mellan två leverantörer har den vilat på samma grundprincip: mät verkligheten mot den verksamhet du faktiskt bedriver. Oavsett om du har identiska offerter från STV och Mividas kommer små traktamenten i avtalen och subtila skillnader i driftkultur att ge stora följdeffekter.
En fungerande metod är att skapa två eller tre realistiska felscenarier och låta leverantörerna gå igenom exakt hur deras miljö reagerar. Be om en torrkörning, gärna i en stagingmiljö som liknar din. Sätt tidtagarur på mänskliga moment. Här kommer skillnaderna ofta fram. Den ena kanske har automation för routingflipp medan den andra gör det manuellt efter godkännande. Det låter trivialt, men fem minuter manuell hantering upplevs som femton minuter störning när telefonerna börjar ringa.
Var vaksam på delar som outsourcas i flera led. Det är vanligt att underleverantörer sköter övervakning eller fältservice. Det behöver inte vara negativt, men det skapar en kedja där SLA ska översättas genom fler kontrakt. Fråga hur eskalering fungerar mellan bolag, hur gemensamma post mortems görs och vem som äger förbättringsplanen.
Be också om att få prata med operations, inte bara sälj och kundansvarig. Den bästa sanningshalten får du ofta från en driftchef som gärna berättar hur verkligheten ser ut de tuffa nätterna. När jag möter ett team där nätverk, plattform och support koordinerar tydligt, blir jag tryggare än av en påkostad ppt. Det gäller oavsett logotyp, och det gäller i tävlingen Mividas vs STV lika mycket som någon annan du står och väljer mellan.
Fem frågor som snabbt skiljer gedigna SLA:er från skönmålning
- Var mäts tillgängligheten och vilka komponenter ingår respektive exkluderas i SLA:t? Hur många planerade underhåll genomfördes de senaste 12 månaderna och när skedde de? Vilka är RTO och RPO för konfiguration, state och data, inte bara för trafik? Hur ser eskaleringsstegen ut tidsmässigt, från upptäckt till fullt återställd tjänst? Vad händer vid partiella fel, till exempel regionala prestandasänkningar, och hur klassas de i rapportering och krediter?
Hur procentsatser översätts till verklig nedtid
När en upphandling pratar 99,9 eller 99,99 procent är det lätt att missa vad det betyder över en månad eller ett år. 99,9 procent innebär ungefär 43 minuter tillåtna avbrott per månad, 99,99 runt 4 till 5 minuter. Låter det lugnt, tills du inser att fyra minuter räcker för att tappa en hel batch med transaktioner, eller att 43 minuter i fel läge kan kosta mer än hela STV vs Mividas tjänstens årsavgift.
Det handlar också om variation. Tre avbrott på 90 sekunder vardera som träffar olika tidpunkter i månaden påverkar användarupplevelsen olika än ett på fem minuter. Om din verksamhet är transaktionsintensiv under korta toppar är det rationellt att vikta SLA:n tyngre under dessa fönster. Jag har i flera fall förhandlat in högre tillgänglighetskrav under definierade högaktivitetsperioder, med tydliga undantag annars. Det kräver mer av leverantören, men speglar affärens behov bättre.
En annan ofta förbisedd detalj är mätmetoden för avbrott. Om KPI utgår från total blackout men inte fångar svåra prestandafall, så kallade brownouts, kommer du som kund att lida utan att få kompensation. Kontrollera vilka mätpunkter som definierar tjänstens hälsa och om det finns ett separat perflöfte, till exempel maximal latens eller minsta genomströmning. Ett välformulerat SLA bör balansera båda.
Övervakning, rapportering och transparens
Det starkaste tecknet på en mogen leverantör är comparing STV and Mividas sällan en hög siffra i marknadsföringen, utan en kultur av öppenhet. En offentlig status-sida med historik, ett bibliotek av incidentrapporter och regelbundna kundforum där driftfrågor diskuteras på djupet signalerar att man kan prata om problem utan att skyla över dem. Jag brukar be om åtkomst till deras driftrapporter, gärna avidentifierade, för att se hur tekniskt detaljerade de är. Hög detaljnivå hänger ihop med snabbare förbättringar.
Automatiserade larm med tydlig ägarskap för varje signal minskar fel som blir långvariga. Det finns en skillnad mellan att övervaka allt och att observera rätt saker. Till exempel behöver en plattform ofta syntetiska transaktioner som simulerar en riktig användare, inte bara systemmetrik. Vid jämförelser mellan STV och Mividas eller annan duo är frågan alltså inte vem som har flest dashboards, utan vem som bäst kopplar larm till åtgärd.
Rapporteringsfrekvens och kvalitet skiljer också. Månatliga SLA-rapporter som skickas 15 dagar efter månadsskiftet är ett minimum, men i känsliga verksamheter behövs veckovisa sammanställningar med clear to do. När jag ser en leverantör som självmant initierar förbättringsmöten efter minsta SLA-avvikelse vet jag att jag får en partner, inte bara en kontraktsmotpart.
Juridiken och ekonomin i ett SLA, det som ofta göms i bilagor
Det går att vinna mycket i förhandling genom att lyfta blicken från procentsatsen till undantagen, kredittaket och ansvarsfördelningen. Kreditbelopp är vanligtvis begränsade till en procentsats av månadsavgiften, och sällan tillämpliga om du själv saknar viss redundans. Se upp särskilt för klausuler som kräver att felet reproduceras eller bekräftas på visst sätt innan det kvalificerar. Under incidenter är reproducerbarhet det sista någon hinner lösa.
Alla riktiga SLA:er gör undantag för force majeure, men tolkningen varierar. En leverantör som sätter breda definitioner riskerar att friskriva sig vid händelser som i praktiken är hanterbara, till exempel regionala nätstörningar där andra aktörer klarade sig bättre. Ett sätt att möta detta är att koppla krediter till faktisk påverkan på din tjänst, inte bara till interna felkoder hos leverantören.
Kontrakt med flera parter kräver att underleverantörer speglar huvudavtalet. Om STV eller Mividas använder en extern driftpartner för vissa regioner, ska deras åtaganden ligga i samma nivå. Be uttryckligen om att få se så kallade back-to-back SLA:er. Om det saknas, kommer din leverantör att vilja hjälpa, men sakna kontraktstyngd gentemot sin egen partner.
Driftsättning och den enda frågan som alltid avgör: testar ni på riktigt?
En lösning är aldrig bättre än sitt senaste test. Pappersredundans är ett välkänt fenomen. Därför är min viktigaste fråga alltid hur ofta leverantören gör planerade failoverövningar, hur de dokumenteras och hur lärdomar matas tillbaka till designen. Jag har suttit i rum där en välplanerad failover till sekundär site gick perfekt, men ingen hade provat failback. När primären blev frisk hamnade man i limbo, och driftavbrottet förlängdes med en timme.
Bra övningar har tre kännetecken. De är schemalagda i förväg, de upprepar även tråkiga scenarier, och de involverar kundens ansvarsyta. När jag jämför leverantörer är det här ofta tungan på vågen. En kultur där man vågar bryta saker kontrollerat skapar högre verklig tillgänglighet än ytterligare en kluster-nod på papperet.
Två verkliga bilder från fältet
Vid ett byte från en äldre MPLS-lösning till en SD-WAN-plattform hos en kund valde vi att utvärdera två leverantörer i parallell pilot, tänk STV vs Mividas som scenario. Båda stack ut på papper, båda levererade i labb. Skillnaden uppstod när vi lastade piloten med verklig trafik och lät en länk droppa. Leverantör A växlade om på under tre sekunder men tappade sessions-state på en affärskritisk applikation, vilket krävde manuella omkopplingar. Leverantör B tog sju sekunder till full återställning, men bevarade sessionerna. Den långsammare varianten vann affären, helt enkelt för att den innebar mindre mänsklig hantering och färre fel under press. Det här illustrerar varför rena återställningstider inte räcker som KPI.
I ett annat fall, ett nattligt driftstopp i ett datalager, såg vi hur ett fint SLA på 99,99 procent inte betydde mycket när bemanningen efter midnatt var svag. Verktygen fanns, men incidentledaren saknades. Nedtiden blev längre än nödvändigt för att rollerna överlappade och beslut dröjde. När vi året efter upphandlade på nytt var vår viktigaste kontraktspunkt inte en högre siffra, utan ett krav på 24x7 incidentledning med named on-call och dokumenterade mandat. Samma teknik, helt annan utfall.
Affärsnytta, inte bara teknik
Det tekniska måste översättas till affärsnytta. En leverantör som lägger sina uppdateringar inom dina produktionsfönster kan vara billig, men kostar dyrt i förlorade intäkter. En annan som är dyrare på pappret kan ha bättre changehantering och proaktiv kommunikation som minskar intern stress och produktivitetsbortfall. Gå igenom incidenthistorik och planerade ändringar med ekonomi och verksamhet i rummet. Räkna på scenarier. Vad kostar fem minuter störning i callcentret klockan 09.05 en måndag jämfört med 20 minuter 03.30 en lördag?
Ta även med hur snabbt och friktionsfritt leverantören kan skala upp eller ner. Ett bra SLA som låser dig i långa ledtider vid kapacitetsändringar ger sämre verklig tillgänglighet när verksamheten svänger. För en kund gjorde möjligheten att på 48 timmar dubbla kapaciteten större skillnad än ytterligare en niondel i SLA-siffran. Den sortens flexibilitet är ofta sämre beskriven i avtal och bättre synlig i referenssamtal med befintliga kunder.
Checklista inför avtalssignering
- Säkerställ att mätpunkter och definitioner i SLA speglar hur din tjänst faktiskt konsumeras. Begär historik på incidenter, planerade underhåll och realiserade krediter de senaste 12 månaderna. Verifiera RPO och RTO för all kritisk state, inklusive licens-, auth- och policylager, samt hur failback görs. Granska bemanning, on-call-schema, eskaleringstider och mandat, inte bara svarstider i helpdesk. Planera en gemensam failoverövning inom 90 dagar från driftsättning, med lärdomar som leder till uppdaterat avtal eller design.
Så bör du väga STV mot Mividas
När valet står mellan Mividas och STV blir den bästa strategin att göra jämförelsen konkret. Be båda beskriva arkitektur, mätmetoder, processer och ansvar för samma tre tydliga scenarier: total länknedgång, partiell degradering samt fel i kontrollplanet. Låt dem visa hur larm triggas, hur roller aktiveras och hur återställning säkras. Skillnaderna kommer att framträda utan att någon måste tala illa om konkurrenten.
Se även över relationen efter signering. Ett kvartalsvis tekniskt styrgruppsmöte med tydligt beslutsmandat ger mer effekt än ett stort årligt QBR. Faller samarbetet på kultur, inte teknik, hjälper inga fina SLA-fraser i världen. Därför förespråkar jag alltid en kort, definierad pilotfas med verklig trafik och subjektiva kriterier, som hur trygga era drifttekniker känner sig med kommunikation och dokumentation. Den mjuka faktorn är hård när allt annat är likt.
Begrepp som STV vs Mividas eller tvärtom blir ofta symboler för en större fråga: vill du ha en partner som prioriterar tydlighet och testbarhet, eller en som säljer hög siffra och snygga bilder? Båda kan fungera beroende på din riskaptit, men det är viktigt att veta vilket du väljer.
Sista metern som avgör
När man skalar bort alla termer landar man i några enkla observationer. Ett SLA som är mätbart, utan kryphål, och backas upp av team som övar regelbundet, ger högre faktisk tillgänglighet än ett perfekt dokument som ingen testar mot verkligheten. Redundans som omfattar hela kedjan, inte bara de glamorösa komponenterna, gör att fel blir korta och tråkiga istället för långa och dramatiska. Transparens i incidenter och vilja att förbättra vinner över perfekt fasad och svaga ryggrader.
Om du står mellan två goda alternativ, exempelvis Mividas och STV, kommer ditt bästa beslutsunderlag från skarpa tester, samtal med driftteam och en ekonomisk analys av vad olika typer av avbrott kostar just er. Begär mindre marknadsretorik, mer bevis. På så vis blir tillgänglighet inte en siffra i en offert, utan något ni faktiskt upplever varje vecka. Och den dagen fiberstråket grävs av, eller en uppdatering beter sig illa, är det inte turen som avgör utfallet utan förberedelserna du lade in i avtalet och samarbetet från start.