Not
Åtkomst till denna sida kräver auktorisation. Du kan prova att logga in eller byta katalog.
Åtkomst till denna sida kräver auktorisation. Du kan prova att byta katalog.
En molnbaserad lösning skapar ett nytt affärsvärde genom att skapa nya arbetsbelastningar (program) eller lägga till nya funktioner i befintliga arbetsbelastningar. Oavsett om du utvecklar ett helt nytt program eller lägger till nya funktioner i ett befintligt system är molnbaserad utveckling en resa genom planering, utveckling, distribution och optimering av dina arbetsbelastningar. Det här ramverket ger vägledning från slutpunkt till slutpunkt för att säkerställa att ditt molnbaserade program är i linje med affärsmål, väldefinierade och levereras med minimal risk.
Förutsättningar:Azure-landningszon
Definiera affärsmål för molnbaserade lösningar
Börja med tydliga affärsmål. Definiera de specifika resultat som din molnbaserade lösning bör uppnå, till exempel att aktivera en ny digital produkt, komma in på en ny marknad, förbättra kundupplevelsen eller minska driftskostnaderna. Använd mätbara indikatorer som intäktstillväxt, minskning av time-to-market eller antal supportärenden för att kvantifiera framgång. För nya funktioner definierar du mål som att förbättra kundupplevelsen, minska driftskostnaderna eller öka systemets skalbarhet.
Identifiera begränsningar och framgångsvillkor. Dokumentera eventuella affärsbegränsningar, till exempel budget, efterlevnad eller leveranstidslinje. Definiera hur framgång ser ut för varje mål. Till exempel "starta en ny kundportal efter Q4" eller "minska svarstiden för utcheckning med 40%" Dessa kriterier vägleder prioritering och hjälper till att utvärdera kompromisser under planeringen.
Verifiera intressenternas samstämmighet. Bekräfta att alla intressenter (affärs- och teknik) är överens om målen, begränsningarna och hur framgång ser ut. Denna anpassning kan omfatta workshops eller formella signeringar. Tidig anpassning förhindrar senare felkommunikation och undviker kostsamma omarbetningar, vilket säkerställer att alla delar samma förväntningar från början.
Definiera krav för molnbaserade lösningar
Funktionskrav för dokument. Dokumentera de funktioner och funktioner som systemet måste tillhandahålla för att uppfylla användarnas behov. Varje krav bör kopplas tillbaka till ett affärsmål, vilket säkerställer att utvecklingsinsatsen direkt stöder önskade resultat. Använd intervjuer med intressenter och affärsstrategidokument för att identifiera värdefulla resultat. Prioritera funktioner baserat på affärsvärde och teknisk genomförbarhet. Spåra varje krav till ett mätbart affärsmål för att motivera dess inkludering.
Upprätta icke-funktionella krav. Icke-funktionella krav definierar tekniska krav för att uppfylla funktionella krav och styrning. Upprätta de kvalitetsattribut och tekniska mål som behövs för att stödja dessa funktioner. Definiera måltillförlitlighetsmått som servicenivåmål (SLO) för drifttid, mål för återställningspunkter (RPOs) och mål för återställningstid (RTO). Upprätta en säkerhetsbaslinje. Skapa kostnadsmodell. Ange prestandamål.
Kontrollera omfattningen av molnbaserade lösningar. Definiera tydligt vad som är inom omfång jämfört med utanför omfånget för den första versionen. Det är frestande att inkludera fler "bra att ha"-funktioner, men omfattningsglidning kan äventyra tidslinjer och budgetar. Dokumentera gränserna för din lösning och implementera en ändringskontrollprocess för alla nya begäranden. Godkänn endast ändringar som har direkt stöd för de definierade målen och som kan levereras utan att undergräva schemat eller budgeten. Skjut upp idéer med lägre prioritet till en framtida eftersläpning. Genom att hantera omfånget noggrant fokuserar teamet på att leverera de mest värdefulla funktionerna först inom begränsningarna.
Planera de molnbaserade arkitekturerna
En välplanerad arkitektur är viktig för att uppfylla dina mål och krav. Varje större arkitektoniskt beslut innebär kompromisser i skalbarhet, komplexitet, kostnad och flexibilitet. Följande steg och beslutspunkter hjälper dig att skapa en molnbaserad design som är anpassad efter bästa praxis:
Utforska verifierade molnbaserade arkitekturer
Granska grunderna i arkitekturen och metodtipsen. Granska verifierade referensarkitekturer och grunderna från Azure Architecture Center innan du uppfinner en arkitektur från grunden. Välbekanta arkitekturformat inkluderar att utforska verifierade referensarkitekturer för vanliga arbetsbelastningar. Dessa arkitekturer hjälper till att påskynda designbeslut och minska risken.
Välj ett lämpligt arkitekturformat. Välj en arkitekturstil baserat på arbetsbelastningens egenskaper och teamfunktioner. Arkitekturformat omfattar N-nivå (monolitisk), mikrotjänster, händelsedrivna (meddelandebaserade), web-queue-worker. Om du till exempel behöver snabb utveckling för ett relativt enkelt program kan en välstrukturerad monolit på N-nivå räcka. För ett storskaligt eller snabbt växande program med distinkta domäner erbjuder mikrotjänster eller händelsedrivna metoder flexibilitet (på bekostnad av komplexitet). I praktiken får många system en hybridstil. Det finns till exempel en mikrotjänstkärna med vissa delade tjänster eller ett händelsedrivet undersystem. Nyckeln är att förstå kompromisserna för varje stil och välja den metod som bäst uppfyller dina krav på skalbarhet, motståndskraft och flexibilitet.
Tillämpa metodtips för design. Oavsett vilken stil du väljer följer du grunderna i molnarkitekturen och bästa praxis. Azure Architecture Center innehåller en katalog med molndesignmönster (Retry, Circuit Breaker, CQRS) som hanterar vanliga utmaningar i distribuerade arbetsbelastningar. Genom att integrera dessa mönster i din design kan du förbättra tillförlitligheten och prestandan.
Integrera de fem pelarna i designbeslut. Använd Well-Architected Framework för att vägleda beslut om tillförlitlighet, säkerhet, prestandaeffektivitet, kostnadsoptimering och driftseffektivitet. Dessa fem pelare bör ligga till grund för alla designbeslut. När du till exempel väljer en databas bör du överväga tillförlitlighet (redundans, säkerhetskopiering), prestanda och kostnad tillsammans för att hitta rätt balans. Dokument där du gör kompromisser mellan pelare, till exempel mer kostnad för högre prestanda. Dessa anteckningar är värdefulla för framtida styrning och granskningar.
Planera integreringar med befintliga system
Inventera alla beroende system och tjänster. Nya molnnativa lösningar fungerar sällan i isolering, såvida du inte är ett tidigt startupföretag. Fundera på hur din nya arbetsbelastning eller funktion passar in i miljön. Mappa ut dataflöden och säkerställa kompatibilitet med standarder. Skapa en omfattande lista över alla system som din arbetsbelastning interagerar med. Den här listan innehåller interna API:er, databaser, identitetsprovidrar (Microsoft Entra ID), övervakningsverktyg, CI/CD-pipelines och lokala system som nås via VPN eller ExpressRoute. Använd arkitekturdiagram och beroendekartor för att visualisera dessa relationer.
Klassificera integreringstyper och protokoll. Kategorisera varje integreringsplats efter typ (autentisering, datautbyte, meddelanden) och protokoll (REST, gRPC, ODBC, SAML, OAuth2). Den här klassificeringen hjälper dig att identifiera kompatibilitetskrav och potentiella flaskhalsar.
Verifiera identitets- och åtkomstintegrering. Se till att din lösning integreras med organisationens identitetsprovider. Använd till exempel Microsoft Entra-ID för autentisering och auktorisering i stället för att introducera ett nytt identitetssystem. Bekräfta stöd för enkel inloggning (SSO), rollbaserad åtkomstkontroll (RBAC) och principer för villkorlig åtkomst.
Utvärdera nätverksanslutning och säkerhet. Granska hur din arbetsbelastning ansluter till andra system. Verifiera brandväggsregler, DNS-upplösning och routningsvägar. För hybridscenarier bekräftar du att ExpressRoute- eller VPN-konfigurationer finns på plats och testas. Använd Azure Network Watcher för att övervaka och felsöka anslutningar.
Kontrollera kompatibilitet och efterlevnad för dataflöden. Mappa ut dataflöden mellan system. Bekräfta dataformat, scheman och transformeringskrav. Se till att datahemvist, kryptering och kvarhållningsprinciper följs.
Testa integreringspunkter tidigt och kontinuerligt. Utför integreringstestning under tidiga utvecklingsstadier. Använd "mocks" eller "stubs" för otillgängliga system. Automatisera dessa tester i CI/CD-pipelinen med hjälp av verktyg som Azure DevOps eller GitHub Actions. Övervaka svarstid, dataflöde och felfrekvenser. Du vill till exempel undvika ett API som din app är beroende av att den inte stöder den nödvändiga belastningen eller att en nätverksbrandvägg blockerar din tjänst.
Dokumentintegreringskontrakt och serviceavtal. Definiera och dokumentera det förväntade beteendet, tillgängligheten och prestandan för varje integrationsplats. Inkludera logik för återförsök, timeout-inställningar och återställningsmekanismer. Anpassa efter service-nivåavtal (SLA) för beroende system.
Välj lämpliga Azure-tjänster och tjänstnivåer
Använd beslutsguider för att välja tjänster som matchar arbetsbelastningskraven. Azure har flera alternativ för att köra programkoden, var och en med fördelar och nackdelar. Granska översikten över teknikval för att identifiera tjänster som överensstämmer med dina funktionella och icke-funktionella krav. Prioritera PaaS-alternativ (platform-as-a-service) eftersom dessa tjänster minskar driftkostnaderna genom att hantera infrastrukturhantering, korrigering och skalning automatiskt.
Definiera användningsmönster och prestandakrav för att välja tjänstnivåer. Valet av tjänstnivå påverkar både kostnad och kapacitet. Dokumentera förväntade transaktionsvolymer, samtidiga användarbelastningar, lagringskrav och prestandamål som svarstider och dataflöde. Använd dessa mått för att välja en inledande tjänstnivå (SKU) som uppfyller baslinjekraven utan betydande överetablering. Planera att justera nivåer baserat på faktiska användningsmönster efter distributionen.
Verifiera funktionskompatibilitet mellan valda tjänstnivåer. Viktiga funktioner som avancerade säkerhetsfunktioner, alternativ för hög tillgänglighet eller integrerings-API:er varierar beroende på tjänstnivå. Skapa en funktionsmatris som mappar nödvändiga funktioner till tillgängliga SKU:er. Se till att den valda nivån stöder alla nödvändiga funktioner för att undvika kostsamma migreringar eller arkitektoniska ändringar senare. Referera till tjänstspecifik dokumentation för att bekräfta funktionstillgänglighet och begränsningar.
Välj hur många regioner som ska användas
Utvärdera kompromisser med distributioner i flera regioner. Arkitekturer med en region är enklare och billigare, men ett regionalt avbrott skulle leda till att din app blir sämre. Distributioner i flera regioner kan uppnå högre tillgänglighet (en region kan misslyckas och användare hanteras från en annan) och kan också förbättra prestanda genom att betjäna användare från närmaste region. Kompromissen är ökad komplexitet i distribution och datasynkronisering. Du måste hantera datareplikering mellan regioner med potentiella konsekvensproblem, global trafikroutning och högre kostnader. Låt dina tillförlitlighetskrav driva det här beslutet.
Använd tillförlitlighetsmål för att vägleda regional strategi. Definiera servicenivåmål (SLO), mål för återställningspunkter (RPO) och mål för återställningstid (RTO) för att fastställa regionala krav.
Bekräfta efterlevnaden av reglerna för datahemvist. Arbeta med juridiska team och efterlevnadsteam för att säkerställa att regionala val uppfyller regelkraven.
Dokumentarkitekturer
Skapa ett detaljerat arkitekturdiagram och designdokument. Dokumentationen stöder implementering, granskning och framtida underhåll. Inkludera valda Azure-tjänster, SKU:er, dataflöden och användarinteraktioner. Se till att diagrammet ger en tydlig visuell representation av arkitekturen för att stödja implementering och granskningar.
Registrera viktiga designbeslut och kompromisser. Dokumentera logiken bakom arkitekturval, inklusive icke-funktionella krav som tillförlitlighet, säkerhet och prestanda. Markera eventuella kompromisser som görs för att balansera konkurrerande prioriteringar.
Planera den molnbaserade distributionsstrategin
När du distribuerar den molnbaserade lösningen till produktion följer du en planerad strategi i stället för en ad hoc-push. En solid distributionsplan minimerar effekterna på användarna och ger sätt att återställa om något går fel.
Planera utveckling och distributionsmetoder
Metoder för utveckling och distribution säkerställer konsekvent leverans och driftsberedskap i olika miljöer. Dessa metoder minskar distributionsrisken och förbättrar teamsamordningen.
Upprätta DevOps-metoder för distributionsautomatisering. DevOps-metoder anpassar utvecklings- och driftteamen genom automatisering, versionskontroll och CI/CD-pipelines. Använd verktyg som Azure DevOps eller GitHub Actions för att automatisera arbetsflöden för att skapa, testa och distribuera. Den här metoden minskar manuella fel, påskyndar versionscykler och ger konsekventa distributionsprocesser i olika miljöer.
Planera driftberedskap för att stödja distributionsaktiviteter. Driftberedskap omfattar övervaknings-, aviserings- och incidenthanteringsprocedurer för distributionsscenarier. Dokumentera implementeringsplansböcker och automationsskript som omfattar återgångsprocedurer, systemkontroller och felsökningssteg. Lagra dessa resurser på en central plats, till exempel Azure DevOps Wiki eller GitHub för att säkerställa tillgänglighet under distributionsaktiviteter.
Definiera utvecklingsmetoder som stöder tillförlitliga distributioner. Använd kodningsstandarder, peer-granskningar och automatiserad testning för att säkerställa kodkvalitet och distributionsberedskap. Integrera dessa metoder i din CI/CD-pipeline för att upprätthålla kvalitetsgrindar före implementeringen. Inkludera distributionsspecifika tester som integreringstester, röktester och prestandaverifiering för att verifiera systemets beredskap för produktion.
Planera distribution för nya arbetsbelastningar
Använd progressiv exponering för att begränsa påverkan. För ett nytt program (greenfield) utan befintliga användare bör du göra en mjuk start. Distribuera till produktion men exponera den endast för interna användare eller en pilotgrupp från början. Den här metoden är en kanariedistribution för en ny arbetsbelastning. Om det verkligen är helt nytt och isolerat är en engångsdistribution till full produktion möjlig, men progressiv exponering rekommenderas fortfarande för att fånga eventuella problem på ett kontrollerat sätt. Släpp inte loss systemet på 100% användare på dag ett utan någon verklig validering först. Mer information finns i WAF – Anta en progressiv exponeringsmodell.
Dokumentera operativa procedurer och eskaleringsvägar. Skapa tydlig dokumentation för att starta om tjänster, komma åt loggar, hantera vanliga problem och eskalera incidenter. Lagra den här dokumentationen på en delad lagringsplats som SharePoint eller GitHub för att säkerställa tillgänglighet för supportteam.
Planera distribution för nya funktioner
Planera för ny funktionsintegrering med hjälp av ändringshantering. Följ organisationens ändringshanteringsprocess för att styra och dokumentera produktionsändringar. Definiera återställningsprocedurer, till exempel återställa programversioner eller återställa databassäkerhetskopior. Skydda intressenternas godkännande före distributionen för att säkerställa att de överensstämmer med affärsmålen. Mer information finns i Hantera ändringar i CAF.
Använd uppdateringar på plats för mindre eller bakåtkompatibla ändringar. Distribuera uppdateringar direkt till produktionsmiljön med löpande uppdateringar eller funktionsflaggor. Börja med en liten andel användare eller instanser. Övervaka systemmått och loggar för att verifiera stabiliteten före fullständig distribution.
Använd parallella (blågröna) distributioner för större eller högriskändringar. Distribuera den nya versionen i en separat miljö. Dirigera en liten del av livetrafik till den nya versionen för att verifiera beteendet. Om det lyckas flyttar du all trafik till den nya versionen. Om det uppstår problem återställer du trafiken till den ursprungliga versionen för att säkerställa kontinuitet.
Planera för driftsöverlämning för nya arbetsbelastningar. Identifiera det team som ansvarar för drift och stöd för lösningen efter distributionen. Definiera supportmodellen (jour- eller kontorstidssupport 24/7) och se till att alla intressenter förstår sina roller.
Definiera ägarskap och supportansvar. Bekräfta att driftteamet är redo att stödja den nya funktionen. Uppdatera dokumentationen och eskaleringsvägarna för att återspegla nya ansvarsområden och säkerställa snabba incidenthanteringar.
Definiera återställningsplan för molnbaserade lösningar
En återställningsplan gör det möjligt för team att snabbt ångra ändringar när en distribution misslyckas eller medför risker. En väldefinierad plan minimerar driftstopp, begränsar affärspåverkan och upprätthåller systemets tillförlitlighet. Upprätta alltid återställningsvillkor och procedurer innan du påbörjar migrering eller distribution.
Definiera misslyckad distribution. Samarbeta med affärsintressenter, arbetsbelastningsägare och driftsteam för att avgöra vad som räknas som en misslyckad distribution. Exempel är misslyckade hälsokontroller, dåliga prestanda, säkerhetsproblem eller mått för ouppfyllda resultat. Den här definitionen säkerställer att återställningsbesluten överensstämmer med organisationens risktolerans. Inkludera specifika villkor som utlöser en återställning i distributionsplanen, till exempel gränser för cpu-användning, tröskelvärden för svarstid eller felfrekvenser. Den här utvärderingen gör återställningsbeslut tydliga och konsekventa under incidenter.
Automatisera "rollback"-steg i CI/CD-pipelines. Använd verktyg som Azure Pipelines eller GitHub Actions för att automatisera återställningsprocesser. Konfigurera till exempel pipelines för att distribuera om en tidigare version om integritetskontroller misslyckas.
Skapa arbetsbelastningsspecifika återställningsinstruktioner. Utveckla återställningssteg som matchar din arbetsbelastningstyp, miljö och distributionsmetod. Infrastruktur som kod-lösningar kräver till exempel att tidigare mallar återappliceras. Applikationsåterställningar innebär återdistribuering av en tidigare containeravbildning. Bifoga återställningsskript, konfigurationsögonblicksbilder och mallar för infrastruktur som kod till din återställningsplan. Dessa resurser möjliggör snabbt genomförande och minskar beroendet av manuella åtgärder.
Testa återställningsprocedurer för att återgå till tidigare tillstånd. Simulera distributionsfel i en förproduktionsmiljö för att verifiera återställningsprocessens effektivitet. Identifiera och lösa luckor i automatisering, behörigheter eller beroenden. Bekräfta att återgången återställer systemet till ett stabilt och beprövat fungerande tillstånd.
Förbättra återställningsstrategier Efter varje distributions- eller återställningshändelse utför du en retrospektiv för att utvärdera vad som fungerade och vad som inte fungerade. Uppdatera återställningskriterier, procedurer och automatisering baserat på lärdomar, arkitekturändringar eller nya verktyg. Underhåll dokumentationen för att säkerställa att återställningsstrategier förblir aktuella och effektiva.