Dela via

Arkitekturmetoder för kontrollplan i lösningar för flera klientorganisationer

  • Artikel

Kontrollplan är en viktig del av SaaS (Programvara som en tjänst) och lösningar för flera klienter, särskilt för att hantera en lösning i stor skala. Det finns vanligtvis två huvudkomponenter som utgör ett kontrollplan:

  • Klientkatalogen, som lagrar viktig information om dina klienter, till exempel:
    • Klientkonfiguration.
    • SKU:er som distribuerats för klientresurser.
    • Vilka distributionsstämplar som klienterna allokeras till.
  • Processer för att hantera ändringar i miljön, som utlöses av klientorganisationens livscykelhändelser. Till exempel registrering av klientorganisation, avregistrering av klientorganisation och allt nödvändigt regelbundet underhåll.

Ett kontrollplan är i sig ett program. Du måste tänka på ditt kontrollplan noggrant och utforma det med samma stränghet och omsorg som du använder med någon annan del av din lösning. Mer information om vad ett kontrollplan är, varför du bör använda det och överväganden för att utforma ett finns i Överväganden för kontrollplan för flera klienter.

Den här artikeln beskriver några metoder som du kan överväga för att utforma och skapa ett kontrollplan. Listan över metoder som beskrivs här är inte omfattande. Även om metoderna är giltiga finns det andra giltiga arkitekturer.

Metoder och mönster att tänka på

I följande tabell sammanfattas skillnaderna mellan några av de metoder som du kan överväga för ett kontrollplan. Manuella metoder, lågkod och anpassade metoder jämförs.

Att tänka på Manuell Låg kod Anpassat
Driftkostnader Högt Låg medelhög Låg
Frekvensen för livscykelhändelser som metoden är lämplig för Sällsynt Tillfälliga ofta Ofta
Tid och komplexitet att implementera Låg Medium Högt
Underhållsansvar för kontrollplan Låg Medium Högt
Testbarhet Låg Medium Högt
Risk för inkonsekvenser Högt Medellåg Låg

Manuella processer

Det är inte alltid viktigt att bygga ett helt automatiserat kontrollplan, särskilt när du börjar och bara har ett litet antal klienter.

Du kan behålla klientkatalogen någonstans centralt, till exempel i en Excel-arbetsbok eller en JSON-fil som lagras på en plats som ditt team kan komma åt. Oavsett format är det en bra idé att lagra informationen på ett strukturerat sätt så att du enkelt kan arbeta med data programmatiskt.

Kommentar

Ett manuellt kontrollplan är ett bra sätt att komma igång med att hantera ditt program för flera klienter, men det är bara lämpligt för ett litet antal klienter (mindre än 5–10). De administrativa kostnaderna och risken för inkonsekvenser ökar med varje klientorganisation som du registrerar manuellt. Du bör bara använda den här metoden om du bara har ett fåtal klienter och du inte behöver automatisk eller självbetjäningsregistrering.

För processer som klientregistrering och underhållsaktiviteter:

  • Skapa skript eller automatiserade pipelines där det är möjligt, även om du kör dem manuellt. Genom att använda skript eller pipelines ser du till att stegen körs konsekvent för varje klientorganisation.
  • För uppgifter som du inte kan skripta från början dokumenterar du processen noggrant och i detalj. Dokumentera hur och varför. Om någon slutar automatisera uppgiften i framtiden bör de ha en god förståelse för båda.

Följande diagram visar ett sätt att använda manuella processer för ett första kontrollplan:

Diagram som visar ett sätt att använda skript och andra manuella processer för ett kontrollplan.

Ladda ned en Visio-fil med den här arkitekturen.

Fördelar med en manuell metod

  • Lightweight: Dokumentation, skript och pipelines är enkla att utveckla och ändra. Detta gör dem lämpliga när du räknar ut dina processer eftersom du snabbt kan iterera och utveckla dem.
  • Låg kostnad: Det är billigt att underhålla och köra en manuell metod.
  • Validerar din process: Även om du så småningom tänker använda en mer automatiserad metod är det ett bra sätt att verifiera din underhållsstrategi innan du lägger tid på att utveckla en mer robust automatisering.

Nackdelar med en manuell metod

  • Brist på kontroll: Den här metoden förlitar sig på att alla inblandade gör rätt. Någon kan avvika från de föreskrivna processerna, antingen oavsiktligt eller avsiktligt. Varje processvariation ökar risken för inkonsekvens i din miljö, vilket gör den pågående hanteringen mycket svårare.
  • Utmaningar med åtkomstkontroll: När du använder den här metoden behöver du vanligtvis bevilja omfattande, mycket tillåtande åtkomst till alla som använder din lösning, vilket gör det svårt att följa bästa praxis för åtkomstsegmentering.
  • Skalbarhet: Det arbete som krävs för att köra manuella processer skalar med det antal klienter som du behöver hantera.
  • Testbarhet: Manuella processer är svåra att validera och testa.

När du ska överväga att flytta från en manuell metod

  • När ditt team inte kan hänga med i mängden arbete de behöver göra för att underhålla programmet. Till exempel när antalet klienter skalar bortom en kritisk punkt, vilket för de flesta team är mellan 5 och 10 klienter.
  • När du förväntar dig en ökning av klientorganisationen utöver ett kritiskt antal klienter och du behöver förbereda dig för arbetet med att administrera det antalet klienter.
  • När du behöver minska risken för inkonsekvenser. Du kan till exempel observera att vissa misstag inträffar eftersom någon inte följer processerna korrekt, eller för att det finns för mycket tvetydighet i processerna. Risken för inkonsekvens ökar vanligtvis när fler klienter registreras manuellt och när ditt team växer.

Kontrollplan med låg kod

Ett kontrollplan med låg kod eller ingen kod bygger på en plattform som är utformad för att automatisera affärsprocesser och spåra information. Det finns många plattformar som gör att du kan utföra dessa uppgifter utan att skriva anpassad kod.

Microsoft Power Platform är ett exempel på en av dessa plattformar. Om du använder Power Platform kan du behålla klientkatalogen i Dynamics 365, Dataverse eller Microsoft 365. Du kan också överväga att behålla samma klientkatalog som du använder för dina manuella processer, om du inte helt vill åta dig att automatisera allt först.

För registrering och underhåll av klientorganisationer kan du använda Power Automate för att köra arbetsflöden som utför klienthantering, konfigurera klienter, utlösa pipelines eller API-anrop och så vidare. Du kan använda Power Automate för att hålla utkik efter ändringar i klientkatalogen om data finns någonstans som är tillgängliga för Power Automate. Om du använder en manuell klientkatalog kan Power Automate-arbetsflöden också utlösas manuellt. Du kan välja att inkludera manuella godkännandesteg i dina arbetsflöden om du behöver någon från ditt team för att verifiera något eller utföra ytterligare steg som inte kan automatiseras helt.

Med den här metoden kan du också tillhandahålla självbetjäningsregistrering till dina kunder genom att låta webbappen lägga till poster direkt i klientkatalogen utan mänsklig inblandning.

Följande diagram visar hur du kan skapa ett kontrollplan med självbetjäningsregistrering med hjälp av Microsoft Power Platform:

Diagram som visar ett sätt att använda Power Automate och Dataverse som ett kontrollplan med låg kod.

Ladda ned en Visio-fil med den här arkitekturen.

Fördelar med en lågkodsmetod

  • Enkelt: Det är ofta snabbt och billigt att skapa en uppsättning arbetsflöden med låg kod och ansluta dem till de omgivande systemen.
  • Använder plattformsverktyg: Du kan använda inbyggda plattformsfunktioner för att lagra data, skapa administrativa portaler som ditt team kan använda och övervaka arbetsflödena när de körs. Genom att använda inbyggda plattformsfunktioner undviker du att skapa många komponenter själv.
  • Anpassningsbar: Om du behöver mer anpassning kan du vanligtvis utöka dina arbetsflöden med anpassad kod och processer. Du kan till exempel använda Power Automate för att utlösa ett distributionsarbetsflöde i GitHub Actions, eller så kan du anropa Azure Functions för att köra din egen kod. Detta bidrar också till att underlätta ett gradvis genomförande.
  • Låg omkostnad: Tjänster med låg kod hanteras vanligtvis helt och hållet, så du behöver inte hantera infrastrukturen.

Nackdelar med en lågkodsmetod

  • Nödvändig expertis: Om du vill använda lågkodsplattformar för att skapa processer och effektivt använda dessa plattformar behöver du vanligtvis proprietär kunskap. Många organisationer använder redan dessa verktyg, så ditt team kanske redan har den expertis som krävs, men det kanske inte gör det. Du bör fundera på om du behöver träna ditt team för att kunna använda dessa plattformar på ett effektivt sätt.
  • Hantering: Det kan vara svårt att hantera hantering av stora mängder konfiguration med låg kod.
  • Testbarhet: Överväg hur du testar och höjer upp ändringar i kontrollplanet. På en hanterad plattform är det svårare att skapa en typisk DevOps-process för att testa och främja ändringar, eftersom ändringar normalt görs via konfiguration, inte via kod.
  • Design: Tänk noga på hur du uppfyller icke-funktionella krav som säkerhet och tillförlitlighet. Dessa krav hanteras ofta för dig på en plattform med låg kod.

När du ska överväga att flytta från en lågkodsmetod

  • Så småningom kan dina krav bli så komplexa att du inte kan integrera dem på ett förnuftigt sätt i en lösning med låg kod. När du behöver kringgå verktygsbegränsningar för att uppfylla dina behov är det förmodligen klokt att gå bort från en hanterad lösning och mot ett anpassat kontrollplan.

Anpassat kontrollplan

Du kan också skapa ett eget helt anpassat kontrollplan. Det här alternativet ger mest flexibilitet och kraft, men det kräver också mest arbete. Klientkatalogen lagras vanligtvis i en databas. Du arbetar inte direkt med katalogen i det här fallet, utan hanterar den i stället via ett administrativt gränssnitt, vilket kan vara ett anpassat program eller ett system som organisationens CRM-program (Customer Relationship Management).

Du skapar vanligtvis en uppsättning kontrollplanskomponenter som är utformade kring alla dina administrativa klientfunktioner. Dessa komponenter kan innehålla en administrativ portal eller annat användargränssnitt, ett API och bakgrundsbearbetningskomponenter. Om du behöver göra saker som att distribuera kod eller infrastruktur när klientorganisationens livscykelhändelser inträffar kan distributionspipelines också utgöra kontrollplanet.

Se till att alla tidskrävande bearbetningar använder lämpliga verktyg. Du kan till exempel använda Durable Functions eller Azure Logic Apps för komponenter som samordnar klientregistrering eller distributioner, eller för komponenter som behöver kommunicera med externa system.

Precis som med metoden med låg kod kan du med den här metoden tillhandahålla självbetjäningsregistrering till dina kunder genom att låta webbappen lägga till poster direkt i klientkatalogen utan mänsklig inblandning.

Följande diagram visar ett sätt att skapa ett grundläggande anpassat kontrollplan som tillhandahåller självbetjäningsregistrering:

Diagram som illustrerar ett kontrollplan som skapats med Durable Functions, en SQL-databas och en Service Bus.

Ladda ned en Visio-fil med den här arkitekturen.

Fördelar med en anpassad metod

  • Fullständig flexibilitet och anpassning: Du har fullständig kontroll över vad kontrollplanet gör och kan ändra det om dina krav ändras.
  • Testbarhet: Du kan använda en SDLC (Standard Software Development Lifecycle) för ditt kontrollplansprogram och implementera normala metoder för testning och distributioner, precis som för dina huvudprogram.

Nackdelar med en anpassad metod

  • Underhållsansvar: Den här metoden kräver mer underhållskostnader eftersom du behöver skapa allt själv. Ett kontrollplan är lika viktigt som alla andra delar av ditt program. Du måste vara noga med att utveckla, testa och använda kontrollplanet för att säkerställa att det är tillförlitligt och säkert.

Hybridmetoder

Du kan också överväga att använda en hybridmetod. Du kan använda en kombination av manuella och automatiserade system, eller så kan du använda en hanterad plattform som Microsoft Power Platform och utöka den med anpassade program. Överväg att implementera en hybridmetod om du behöver anpassningsbarheten för ett anpassat kontrollplan, men inte nödvändigtvis vill skapa och underhålla ett helt anpassat system. Tänk på att dina automatiserade anpassningar av dina manuella processer eller din hanterade plattform kan bli lika komplexa som ett fullständigt anpassat system. Tipping point skiljer sig åt för varje organisation, men om din hybridmetod är besvärlig att underhålla bör du överväga att flytta till ett helt anpassat system.

Gradvis implementering

Även om du vet att du vill automatisera kontrollplanet så behöver du inte nödvändigtvis börja med den metoden. En vanlig metod under de inledande stegen för att skapa ditt program är att börja med ett manuellt kontrollplan. När programmet fortsätter och registrerar fler klienter bör du börja identifiera flaskhalsar och automatisera dem efter behov och gå över till en hybridmetod. När du automatiserar mer kan du så småningom ha ett helt automatiserat kontrollplan.

Antimönster att undvika

  • Förlitar sig på manuella processer för länge. Även om det är rimligt att använda manuella processer när du börjar eller när du har ett lågt antal klienter och kräver ganska enkel hantering, måste du planera hur du skalar till en automatiserad lösning när du växer. Om du behöver anställa ytterligare teammedlemmar för att hålla koll på behovet av dina manuella processer är det ett gott tecken på att du bör börja automatisera delar av kontrollplanet.
  • Använda olämpliga verktyg för långvariga arbetsflöden. Undvik till exempel att använda azure-standardfunktioner, synkrona API-anrop eller andra verktyg som har en körningstidsgräns för att utföra långvariga åtgärder som Azure Resource Manager-distributioner eller orkestreringar i flera steg. Använd i stället verktyg som Azure Logic Apps, Durable Functions och andra verktyg som kan utföra långvariga arbetsflöden eller åtgärdssekvenser. Mer information finns i Prestanda och tillförlitlighet för Azure Functions och Asynkront mönster för begäran-svar.

Deltagare

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

Huvudsakliga författare:

Övriga medarbetare:

Nästa steg