Dela via

Mäta förbrukningen för varje klientorganisation

  • Artikel

Som lösningsleverantör är det viktigt att mäta förbrukningen för varje klientorganisation i din lösning för flera klienter. Genom att mäta förbrukningen för varje klientorganisation kan du se till att kostnaden för sålda varor (COGS) för att leverera tjänsten till varje klientorganisation är lönsam. På den här sidan ger vi vägledning till tekniska beslutsfattare om vikten av att mäta förbrukning och de metoder som du kan tänka dig för att mäta en klientorganisations förbrukning samt de kompromisser som ingår.

Det finns två huvudsakliga problem som driver behovet av att mäta varje klientorganisations förbrukning:

  • Du måste mäta den faktiska kostnaden för att betjäna varje klientorganisation. Detta är viktigt för att övervaka lönsamheten för lösningen för varje klientorganisation.
  • Du måste fastställa hur mycket som ska debiteras klientorganisationen när du använder förbrukningsbaserad prissättning.

Det kan dock vara svårt att mäta de faktiska resurser som används av en klientorganisation i en lösning med flera klienter. De flesta tjänster som kan användas som en del av en lösning med flera klienter särskiljer inte automatiskt eller delar upp användningen, baserat på vad du definierar en klientorganisation som ska vara. Tänk dig till exempel en tjänst som lagrar data för alla dina klienter i en enda relationsdatabas. Det är svårt att avgöra exakt hur mycket kapacitet varje klient använder för den relationsdatabasen, antingen när det gäller datalagring eller de beräkningsresurser som krävs för att betjäna frågor och begäranden.

För en lösning med en enda klientorganisation kan du däremot använda Microsoft Cost Management inom Azure Portal för att få en fullständig kostnadsuppdelning för alla Azure-resurser som förbrukas av den klientorganisationen.

När du står inför dessa utmaningar är det därför viktigt att tänka på hur förbrukningen ska mätas.

Kommentar

I vissa fall är det kommersiellt acceptabelt att ta en förlust på att leverera tjänster till en klientorganisation, till exempel när du kommer in på en ny marknad eller region. Det här är ett kommersiellt val. Även i dessa situationer är det fortfarande en bra idé att mäta förbrukningen för varje klientorganisation, så att du kan planera för framtiden.

Indikativa förbrukningsmått

Moderna program (som skapats för molnet) består vanligtvis av många olika tjänster, var och en med olika mått på förbrukning. Ett lagringskonto mäter till exempel förbrukningen baserat på mängden data som lagras, de data som överförs och antalet transaktioner. Azure App Service-förbrukningen mäts däremot med den mängd beräkningsresurser som allokeras över tid. Om du har en lösning som innehåller ett lagringskonto och App Service-resurser kan det vara mycket svårt att kombinera alla dessa mått för att beräkna den faktiska COGS-kostnaden (kostnaden för sålda varor).

Ofta är det enklare att använda en enda indikativ mätning för att representera förbrukningen i lösningen. Om en lösning med flera klienter till exempel delar en enda relationsdatabas kan data som lagras av en klientorganisation vara ett bra vägledande förbrukningsmått.

Även om du använder mängden data som lagras av en klientorganisation som ett vägledande förbrukningsmått kanske det inte är en verklig representation av förbrukningen för varje klientorganisation. Om en viss klientorganisation gör mycket mer läsningar eller kör mer rapportering från lösningen, men inte skriver mycket data, kan den klientorganisationen använda mycket mer beräkning än vad lagringskraven skulle indikera.

Dricks

Ibland bör du mäta och granska den faktiska förbrukningen i dina klienter för att skapa en baslinjemodell. Den här modellen hjälper dig att avgöra om de antaganden du gör om dina vägledande mått är korrekta.

Transaktionsmått

Ett annat sätt att mäta förbrukning är att identifiera en nyckeltransaktion som är representativ för cogs för lösningen. I en dokumenthanteringslösning kan det till exempel vara antalet dokument som skapats. Detta kan vara användbart om det finns en kärnfunktion eller funktion i ett system som är transaktionellt och om det enkelt kan mätas.

Den här metoden är vanligtvis enkel och kostnadseffektiv att implementera, eftersom det vanligtvis bara finns en enda punkt i ditt program som behöver registrera antalet transaktioner som inträffar.

Mått per begäran

I lösningar som främst är API-baserade kan det vara meningsfullt att använda ett förbrukningsmått som baseras på antalet API-begäranden som görs till lösningen. Detta kan ofta vara ganska enkelt att implementera, men det kräver att du använder API:er som det primära gränssnittet för systemet. Det kommer att finnas en ökad driftkostnad för att implementera ett mått per begäran, särskilt för tjänster med stora volymer, på grund av behovet av att registrera användningen av begäran (för gransknings- och faktureringsändamål).

Användarinriktade lösningar som består av ett ensidesprogram (SPA) eller ett mobilprogram som använder API:erna kanske inte passar för måttet per begäran. Det beror på att slutanvändaren inte förstår relationen mellan användningen av programmet och förbrukningen av API:er. Ditt program kan vara chattigt (det gör många API-begäranden) eller chunky (det gör för få API-begäranden) och användaren skulle inte märka någon skillnad. Men om du bara behöver en ungefärlig uppfattning om varje klientorganisations förbrukning kan det fortfarande vara ett rimligt val.

Varning

Se till att du lagrar mått för begäranden i ett tillförlitligt datalager som är utformat för detta ändamål. Även om Azure Application Insights till exempel kan spåra begäranden och till och med spåra klientorganisations-ID:t (med hjälp av egenskaper) är Application Insights inte utformat för att lagra alla telemetrier. Den tar bort data som en del av dess samplingsbeteende. För fakturerings- och mätningsändamål väljer du ett datalager som ger dig en hög noggrannhetsnivå.

Uppskatta förbrukning

När du mäter förbrukningen för en klientorganisation kan det vara enklare att ange en uppskattning av förbrukningen för klientorganisationen i stället för att försöka beräkna den exakta förbrukningsmängden. För en lösning med flera klienter som hanterar tusentals klienter i en enda distribution är det till exempel rimligt att beräkna att kostnaden för att betjäna klientorganisationen bara är en procentandel av kostnaden för Azure-resurserna.

Du kan överväga att uppskatta KSG:erna för en klientorganisation i följande fall:

  • Du använder inte förbrukningsbaserad prissättning.
  • Användningsmönstren och kostnaden för varje klientorganisation är liknande, oavsett storlek.
  • Varje klientorganisation förbrukar en låg procentandel (till exempel <2 %), av de totala resurserna i distributionen.
  • Kostnaden per klientorganisation är låg.

Du kan också välja att uppskatta förbrukningen i kombination med indikativa förbrukningsmått, transaktionsmått eller mått per begäran. För ett program som främst hanterar dokument ger procentandelen av den totala lagringen som används av en klientorganisation, för att lagra dess dokument, till exempel en tillräckligt nära representation av de faktiska KSG:erna. Detta kan vara en användbar metod, när det är svårt att mäta COGS eller när det skulle lägga till för mycket komplexitet i programmet.

Debitera dina kostnader

I vissa lösningar kan du debitera dina kunder KSG för deras klientorganisations resurser. Du kan till exempel använda Azure-resurstaggar för att allokera fakturerbara Azure-resurser till klientorganisationer. Du kan sedan fastställa kostnaden för varje klientorganisation för den uppsättning resurser som är dedikerade till dem, plus en vinstmarginal och åtgärdsmarginal.

Kommentar

Vissa Azure-tjänster stöder inte taggar. För dessa tjänster måste du tillskriva kostnaderna till en klientorganisation baserat på andra egenskaper, till exempel resursnamn, resursgrupp eller prenumeration.

Azure Cost Analysis kan användas för att analysera Azure-resurskostnader för lösningar för enskilda klientorganisationer som använder taggar, resursgrupper eller prenumerationer för att tillskriva kostnader.

Detta blir dock oöverkomligt komplext i de flesta moderna lösningar med flera klienter, på grund av utmaningen att exakt fastställa de exakta KSG:erna för att betjäna en enda klientorganisation. Den här metoden bör endast övervägas för mycket enkla lösningar, lösningar som har resursdistributioner med en klientorganisation eller anpassade klientspecifika tilläggsfunktioner i en större lösning.

Vissa Azure-tjänster tillhandahåller funktioner som tillåter andra metoder för kostnadstillskrivning i en miljö med flera klientorganisationer. Azure Kubernetes Service stöder till exempel flera nodpooler, där varje klientorganisation allokeras en nodpool med nodpooltaggar som används för att tillskriva kostnader.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudförfattare:

Övriga medarbetare:

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg

Överväg den uppdateringsdistributionsmodell som du ska använda.