feat(ms-ai-architect): Spor 1 — Port-1-substrat migrert på 4 ikke-advisor-skills (243 Source + 327 Type + 325 TOC + stale-verified poison fjernet) [skip-docs]
Steg 9 (R4): unified migrate-corpus.mjs --write over engineering/governance/ infrastructure/security. 327 filer mutert, verified=null, prosa byte-identisk (fra første ## seksjon), advisor urørt (0 endringer). To applier-fixes oppdaget under kjøring (TDD, RED→GREEN): - insertHeaderFields: anker faller nå tilbake når en meta-linje selv passerer 500B (2 filer pakket et avsnitt i **Status:** → Type/Source landet utenfor scan-vinduet, applierens post-write-assertion fanget + restaurerte). - normalizeStaleVerified: fjerner nå ALLE stale non-date **Verified:** i 500B-vinduet, inkl. stray body-dup rett under --- (9 mlops-genaiops-filer var ellers falskt "verified"/fresh, droppet fra worklist). Operatør-godkjent utvidelse av carve-out; kun stray metadata-linjer, aldri prosa. test-transform-criterion: precondition oppdatert til post-migrasjons-sannhet (fila bærer nå Source). Suite 728/728 grønn.
This commit is contained in:
parent
ed92d65385
commit
ddce43d8b2
330 changed files with 4643 additions and 83 deletions
|
|
@ -3,9 +3,23 @@
|
|||
**Last updated:** 2026-06-24
|
||||
**Status:** GA
|
||||
**Category:** Business Continuity & Disaster Recovery
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/security/benchmark/azure/baselines/azure-ai-foundry-security-baseline
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Prosjektdata-backup og replikering](#prosjektdata-backup-og-replikering)
|
||||
- [Modellversjonskontroll og gjenoppretting](#modellversjonskontroll-og-gjenoppretting)
|
||||
- [Configuration as Code for reproduserbarhet](#configuration-as-code-for-reproduserbarhet)
|
||||
- [RTO og RPO-definisjoner for AI-prosjekter](#rto-og-rpo-definisjoner-for-ai-prosjekter)
|
||||
- [Testing og validering av DR-prosedyrer](#testing-og-validering-av-dr-prosedyrer)
|
||||
- [Gjenopprettingsprosedyre ved regionalt utfall](#gjenopprettingsprosedyre-ved-regionalt-utfall)
|
||||
- [Referanser](#referanser)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Microsoft Foundry (tidligere Azure AI Studio / Azure AI Foundry) er Microsofts sentrale plattform for utvikling, evaluering og deployering av AI-modeller og agenter. Plattformen tilbyr imidlertid ikke automatisk failover eller disaster recovery ut av boksen -- dette er eksplisitt dokumentert av Microsoft. Det betyr at organisasjoner i norsk offentlig sektor som bygger forretningskritiske AI-loesninger pa AI Foundry, ma planlegge og implementere sin egen DR-strategi.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,24 @@
|
|||
**Last updated:** 2026-06-24
|
||||
**Status:** GA
|
||||
**Category:** Business Continuity & Disaster Recovery
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/backup/backup-overview
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Inkrementell versus full backup](#inkrementell-versus-full-backup)
|
||||
- [Point-in-time Recovery for datasett](#point-in-time-recovery-for-datasett)
|
||||
- [Snapshot-administrasjon og retensjon](#snapshot-administrasjon-og-retensjon)
|
||||
- [Off-region backup-lagring](#off-region-backup-lagring)
|
||||
- [Automatisering og planlegging av backups](#automatisering-og-planlegging-av-backups)
|
||||
- [Kostnadsstyring for backup](#kostnadsstyring-for-backup)
|
||||
- [Sjekkliste for backup-strategi](#sjekkliste-for-backup-strategi)
|
||||
- [Referanser](#referanser)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Backup- og gjenopprettingsstrategier for AI-arbeidsbelastninger skiller seg vesentlig fra tradisjonelle applikasjoner. En AI-loesning bestar ikke bare av applikasjonskode og databaser, men ogsaa av trenede modeller, datasett, fine-tuning-artefakter, embedding-indekser, agentdefinisjoner, samtalelogger og pipeline-konfigurasjoner. Hvert av disse elementene har ulike krav til backup-frekvens, retensjonstid og gjenopprettingsmetode. Et tap av treningsdata kan bety uker med tapt arbeid, mens et tap av embedding-indekser kan gjenopprettes ved reindeksering fra kildedata.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,22 @@
|
|||
**Last updated:** 2026-02
|
||||
**Status:** GA
|
||||
**Category:** Business Continuity & Disaster Recovery
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/well-architected/design-guides/disaster-recovery
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Dimensjonering av DR-miljø for toppbelastning](#dimensjonering-av-dr-miljø-for-toppbelastning)
|
||||
- [Surge capacity og burst-håndtering](#surge-capacity-og-burst-håndtering)
|
||||
- [Kostnadsoptimalisering for standby-ressurser](#kostnadsoptimalisering-for-standby-ressurser)
|
||||
- [Skaleringsregler og auto-scaling](#skaleringsregler-og-auto-scaling)
|
||||
- [Kapasitetsreservasjonsstrategier](#kapasitetsreservasjonsstrategier)
|
||||
- [Referanser](#referanser)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Kapasitetsplanlegging for Disaster Recovery-konfigurasjoner handler om å dimensjonere reserveressurser riktig slik at AI-systemer kan gjenopprettes innenfor definerte RTO- og RPO-mål. For AI-arbeidsbelastninger er dette spesielt utfordrende fordi ressurskravene er høye (GPU-compute, store indekser, høy throughput) og kostnadene eskalerer raskt ved full duplisering.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,22 @@
|
|||
**Last updated:** 2026-02
|
||||
**Status:** GA
|
||||
**Category:** Business Continuity & Disaster Recovery
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/chaos-studio/chaos-studio-overview
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Feilinjeksjonsstrategier for AI-tjenester](#feilinjeksjonsstrategier-for-ai-tjenester)
|
||||
- [Nettverkspartisjonssimulering](#nettverkspartisjonssimulering)
|
||||
- [Last- og stresstesting](#last--og-stresstesting)
|
||||
- [Recovery time-måling og validering](#recovery-time-måling-og-validering)
|
||||
- [Verktøy og plattformer for chaos engineering](#verktøy-og-plattformer-for-chaos-engineering)
|
||||
- [Referanser](#referanser)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Chaos engineering er praksisen med å bevisst injisere feil i et system for å teste dets resiliens og avdekke svakheter før de forårsaker produksjonshendelser. For AI-systemer er dette spesielt verdifullt fordi AI-workloads har komplekse avhengighetskjeder (modell-endpoints, search-indekser, embedding-pipelines, datastores) der en feil i ett komponent kan kaskadere uforutsigbart.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,22 @@
|
|||
**Last updated:** 2026-06-24
|
||||
**Status:** GA
|
||||
**Category:** Business Continuity & Disaster Recovery
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/compliance
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Forvaltningslovens krav til kontinuitet](#forvaltningslovens-krav-til-kontinuitet)
|
||||
- [GDPR og data residency-krav](#gdpr-og-data-residency-krav)
|
||||
- [NSMs sikkerhetsveiledninger for kritisk infrastruktur](#nsms-sikkerhetsveiledninger-for-kritisk-infrastruktur)
|
||||
- [Sektorspesifikke reguleringer](#sektorspesifikke-reguleringer)
|
||||
- [Audit og dokumentasjonskrav](#audit-og-dokumentasjonskrav)
|
||||
- [Referanser](#referanser)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Norske offentlige organisasjoner som bruker AI-tjenester i Azure er underlagt et komplekst regulatorisk landskap for Business Continuity and Disaster Recovery. Kravene kommer fra nasjonale lover (Forvaltningsloven, Sikkerhetsloven), EU-forordninger (GDPR, AI Act), sektorkrav (NSM, Digdir) og internasjonale standarder (ISO 22301, ISO 27001).
|
||||
|
|
|
|||
|
|
@ -3,9 +3,22 @@
|
|||
**Last updated:** 2026-04
|
||||
**Status:** GA
|
||||
**Category:** Business Continuity & Disaster Recovery
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/cost-management-billing/cost-management-billing-overview
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Total Cost of Ownership-beregning](#total-cost-of-ownership-beregning)
|
||||
- [RTO/RPO vs. kostnads trade-off analyse](#rtorpo-vs-kostnads-trade-off-analyse)
|
||||
- [Reserved Capacity vs. On-Demand prising](#reserved-capacity-vs-on-demand-prising)
|
||||
- [Cross-region bandwidth-kostnader](#cross-region-bandwidth-kostnader)
|
||||
- [Kostnadsoptimalisering og Reserved Instances](#kostnadsoptimalisering-og-reserved-instances)
|
||||
- [Referanser](#referanser)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Kostnadsanalyse av BCDR-løsninger for AI-systemer er avgjørende for å sikre at organisasjonen investerer riktig i resiliens. DR-kostnader kan utgjøre alt fra 2% til 100% av primære driftskostnader, avhengig av valgt strategi. For AI-workloads er kostnadene spesielt høye fordi tjenester som Azure OpenAI (Provisioned Throughput), AI Search og GPU-compute er dyre.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,22 @@
|
|||
**Last updated:** 2026-06-24
|
||||
**Status:** GA
|
||||
**Category:** Business Continuity & Disaster Recovery
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/reliability/concept-redundancy-replication-backup
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Synkron vs. asynkron replikering](#synkron-vs-asynkron-replikering)
|
||||
- [Active-Active og Active-Passive mønstre](#active-active-og-active-passive-mønstre)
|
||||
- [Konsistensmodeller og eventual consistency](#konsistensmodeller-og-eventual-consistency)
|
||||
- [Konfliktløsningsstrategier](#konfliktløsningsstrategier)
|
||||
- [Monitoring av replikasjonsforsinkelse og helse](#monitoring-av-replikasjonsforsinkelse-og-helse)
|
||||
- [Referanser](#referanser)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Datareplikering er fundamentet for Business Continuity i AI-systemer. AI-arbeidsbelastninger har spesielle krav til datakonsistens, latens og tilgjengelighet som gjør valg av replikasjonsmekanisme særlig viktig. En RAG-løsning må for eksempel replikere både search-indekser, embedding-vektorer, kildedokumenter og konversasjonshistorikk — hver med ulike konsistens- og latensbehov.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,22 @@
|
|||
**Last updated:** 2026-02
|
||||
**Status:** GA
|
||||
**Category:** Business Continuity & Disaster Recovery
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/chaos-studio/chaos-studio-overview
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Planlagte failover-testscenarier](#planlagte-failover-testscenarier)
|
||||
- [Validering og overvaking under failover](#validering-og-overvaking-under-failover)
|
||||
- [Suksesskriterier og akseptanseterskel](#suksesskriterier-og-akseptanseterskel)
|
||||
- [Dokumentasjon og laerdommer](#dokumentasjon-og-laerdommer)
|
||||
- [Regelmessig testplanlegging og frekvens](#regelmessig-testplanlegging-og-frekvens)
|
||||
- [Referanser](#referanser)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Failover-testing er en kritisk men ofte forsoemmt del av disaster recovery for AI-tjenester. En DR-plan som ikke er testet er i praksis ingen plan -- den gir en falsk trygghet som kan forsterke konsekvensene av et reelt utfall. Microsoft anbefaler eksplisitt a gjennomfoere regelmessige failover-drills for a validere at resiliens-mekanismer fungerer som forventet, og at teamet er i stand til a haandtere en krise effektivt.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,22 @@
|
|||
**Last updated:** 2026-06-24
|
||||
**Status:** GA
|
||||
**Category:** Business Continuity & Disaster Recovery
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/frontdoor/front-door-overview
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Indeksreplikering på tvers av regioner](#indeksreplikering-på-tvers-av-regioner)
|
||||
- [Replikatelling og dimensjonering for tilgjengelighet](#replikatelling-og-dimensjonering-for-tilgjengelighet)
|
||||
- [Failover- og routingstrategier](#failover--og-routingstrategier)
|
||||
- [Holde indekser synkroniserte](#holde-indekser-synkroniserte)
|
||||
- [Query-ytelse i multi-region oppsett](#query-ytelse-i-multi-region-oppsett)
|
||||
- [Referanser](#referanser)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Azure AI Search er en regional tjeneste uten innebygd geo-replikering eller automatisk failover. Hvis regionen blir utilgjengelig, blir også search-tjenesten utilgjengelig. For AI-løsninger med RAG-arkitektur (Retrieval-Augmented Generation) er dette en kritisk svakhet fordi search-indeksen er hjørnesteinen i hele kunnskapsgjenfinningen.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,22 @@
|
|||
**Last updated:** 2026-06-24
|
||||
**Status:** GA
|
||||
**Category:** Business Continuity & Disaster Recovery
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/azure-monitor/alerts/alerts-overview
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [AI-spesifikke hendelsesklassifiseringer](#ai-spesifikke-hendelsesklassifiseringer)
|
||||
- [Deteksjon og alerting-strategier](#deteksjon-og-alerting-strategier)
|
||||
- [Eskalerings-prosedyrer og runbooks](#eskalerings-prosedyrer-og-runbooks)
|
||||
- [Kommunikasjonsplaner for interessenter](#kommunikasjonsplaner-for-interessenter)
|
||||
- [Post-incident review og forbedring](#post-incident-review-og-forbedring)
|
||||
- [Referanser](#referanser)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Incident response for AI-systemer krever spesialiserte prosedyrer som adresserer unike feilmodi som ikke finnes i tradisjonelle IT-systemer. AI-spesifikke hendelser inkluderer modell-degradering, prompt injection-angrep, hallusinasjonsspikes, embedding-drift, og utilgjengelige inference-endepunkter. Disse hendelsene kan ha subtile symptomer som er vanskelige å oppdage med tradisjonell overvåking.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,23 @@
|
|||
**Last updated:** 2026-06-19
|
||||
**Status:** GA
|
||||
**Category:** Business Continuity & Disaster Recovery
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/azure-monitor/alerts/alerts-overview
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Health check-endepunkter og heartbeats](#health-check-endepunkter-og-heartbeats)
|
||||
- [Latens og feilrate-overvåking](#latens-og-feilrate-overvåking)
|
||||
- [Custom metrics for AI-tjenestehelse](#custom-metrics-for-ai-tjenestehelse)
|
||||
- [Alert-regler og eskaleringspolicyer](#alert-regler-og-eskaleringspolicyer)
|
||||
- [Integrasjon med incident management-systemer](#integrasjon-med-incident-management-systemer)
|
||||
- [Application Insights for AI-agenter i BCDR-kontekst *(Verified MCP 2026-06-19)*](#application-insights-for-ai-agenter-i-bcdr-kontekst-verified-mcp-2026-06-19)
|
||||
- [Referanser](#referanser)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Rask og pålitelig deteksjon av feil er avgjørende for å minimere nedetid i AI-systemer. Failover-deteksjon handler om å oppdage at en tjeneste eller region har feilet, og å initiere gjenopprettingsprosessen så raskt som mulig. For AI-workloads er dette spesielt viktig fordi forsinkede svar eller manglende tilgjengelighet direkte påvirker brukeropplevelsen.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,23 @@
|
|||
**Last updated:** 2026-06-24
|
||||
**Status:** GA
|
||||
**Category:** Business Continuity & Disaster Recovery
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/foundry/foundry-models/concepts/models-sold-directly-by-azure
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Regionvalg for Norge og EU](#regionvalg-for-norge-og-eu)
|
||||
- [Lastbalansering mellom OpenAI-endepunkter](#lastbalansering-mellom-openai-endepunkter)
|
||||
- [Latensoptimalisering og Proximity Routing](#latensoptimalisering-og-proximity-routing)
|
||||
- [Kvoteadministrasjon per region](#kvoteadministrasjon-per-region)
|
||||
- [Kostnadsmodell for multi-region](#kostnadsmodell-for-multi-region)
|
||||
- [Implementeringssjekkliste](#implementeringssjekkliste)
|
||||
- [Referanser](#referanser)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Azure OpenAI-tjenester er tilgjengelige i flere Azure-regioner, og når en ressurs opprettes, knyttes den permanent til den valgte regionen. For virksomhetskritiske AI-applikasjoner i norsk offentlig sektor er det avgjorende a planlegge for regional redundans. Et regionalt utfall -- selv om det er sjeldent -- kan lamme AI-drevne tjenester som chatboter, dokumentanalyse og beslutningsstotte dersom all trafikk er avhengig av et enkelt endepunkt. Multi-region-deployering loeser dette ved a spre arbeidsbelastningen over flere Azure-regioner med intelligent lastbalansering og automatisk failover.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,22 @@
|
|||
**Last updated:** 2026-06-24
|
||||
**Status:** GA
|
||||
**Category:** Business Continuity & Disaster Recovery
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/ddos-protection/ddos-protection-overview
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Redundante nettverksstier og tilkoblinger](#redundante-nettverksstier-og-tilkoblinger)
|
||||
- [Circuit Breaker-mønster for API-kall](#circuit-breaker-mønster-for-api-kall)
|
||||
- [Graceful degradation av AI-tjenester](#graceful-degradation-av-ai-tjenester)
|
||||
- [Private endepunkter og nettverksisolering](#private-endepunkter-og-nettverksisolering)
|
||||
- [DDoS-beskyttelse og trafikkfiltrering](#ddos-beskyttelse-og-trafikkfiltrering)
|
||||
- [Referanser](#referanser)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Nettverksresiliens er en kritisk komponent i BCDR for AI-arbeidsbelastninger. AI-systemer er avhengige av pålitelig nettverkskommunikasjon mellom flere tjenester: applikasjonslaget, Azure OpenAI-endepunkter, AI Search-tjenester, embeddings-APIer og datastores. En nettverksforstyrrelse i ett punkt kan kaskadere og ta ned hele AI-løsningen.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,22 @@
|
|||
**Last updated:** 2026-06-24
|
||||
**Status:** GA
|
||||
**Category:** Business Continuity & Disaster Recovery
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/reliability/concept-business-continuity-high-availability-disaster-recovery
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Business Impact Analysis for RTO-bestemmelse](#business-impact-analysis-for-rto-bestemmelse)
|
||||
- [Datatap-toleranse og RPO-beregning](#datatap-toleranse-og-rpo-beregning)
|
||||
- [Mapping av krav til Azure-kapabiliteter](#mapping-av-krav-til-azure-kapabiliteter)
|
||||
- [Norske regulatoriske krav](#norske-regulatoriske-krav)
|
||||
- [Dokumentasjons-maler og governance](#dokumentasjons-maler-og-governance)
|
||||
- [Referanser](#referanser)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Recovery Time Objective (RTO) og Recovery Point Objective (RPO) er de to mest kritiske metrikkene i enhver BCDR-strategi for AI-systemer. RTO definerer hvor raskt et system må gjenopprettes etter en forstyrrelse, mens RPO definerer hvor mye datatap som er akseptabelt. For AI-tjenester som Azure OpenAI, Azure AI Search og Azure Machine Learning er disse metrikkene spesielt viktige fordi nedetid direkte påvirker brukeropplevelsen og forretningsbeslutninger.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,22 @@
|
|||
**Last updated:** 2026-02
|
||||
**Status:** GA
|
||||
**Category:** Business Continuity & Disaster Recovery
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/reliability/reliability-ai-search
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Service Level Agreement-maler](#service-level-agreement-maler)
|
||||
- [RTO og RPO dokumentasjonsstandarder](#rto-og-rpo-dokumentasjonsstandarder)
|
||||
- [Disaster Recovery Runbooks og Playbooks](#disaster-recovery-runbooks-og-playbooks)
|
||||
- [Trinn-for-trinn gjenopprettingsprosedyrer](#trinn-for-trinn-gjenopprettingsprosedyrer)
|
||||
- [Eierskap og eskaleringsmatrise](#eierskap-og-eskaleringsmatrise)
|
||||
- [Referanser](#referanser)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Service Level Agreements (SLA), runbooks og operasjonelle prosedyrer er bindeleddet mellom BCDR-strategi og faktisk gjenopprettingsevne. Uten presis dokumentasjon av SLA-mål, detaljerte trinn-for-trinn runbooks og tydelig ansvarsfordeling, vil selv den best designede DR-arkitekturen feile under en reell hendelse.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,22 @@
|
|||
**Last updated:** 2026-06-24
|
||||
**Status:** GA
|
||||
**Category:** Business Continuity & Disaster Recovery
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/architecture/patterns/retry
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Distribuerte state management-mønstre](#distribuerte-state-management-mønstre)
|
||||
- [Sesjonsstilstandsreplikering og synkronisering](#sesjonsstilstandsreplikering-og-synkronisering)
|
||||
- [Håndtering av in-flight requests under failover](#håndtering-av-in-flight-requests-under-failover)
|
||||
- [Idempotens og request retry-strategier](#idempotens-og-request-retry-strategier)
|
||||
- [State validering og verifikasjonsprosedyrer](#state-validering-og-verifikasjonsprosedyrer)
|
||||
- [Referanser](#referanser)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Håndtering av applikasjonstilstand (state) under failover-scenarioer er en av de mest utfordrende aspektene ved BCDR for AI-systemer. AI-applikasjoner har typisk flere typer state som må ivaretas: brukersesjoner, konversasjonshistorikk, mellomresultater fra langvarige operasjoner (fine-tuning, batch-indeksering), og applikasjonskonfigurasjon.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue