open/ms-ai-architect
1
0
Fork 0
Code Issues Releases 4 Activity

feat(ultraplan-local): v1.6.0 — /ultraresearch-local deep research command

Browse source 
Add /ultraresearch-local for structured research combining local codebase
analysis with external knowledge via parallel agent swarms. Produces research
briefs with triangulation, confidence ratings, and source quality assessment.

New command: /ultraresearch-local with modes --quick, --local, --external, --fg.
New agents: research-orchestrator (opus), docs-researcher, community-researcher,
security-researcher, contrarian-researcher, gemini-bridge (all sonnet).
New template: research-brief-template.md.

Integration: --research flag in /ultraplan-local accepts pre-built research
briefs (up to 3), enriches the interview and exploration phases. Planning
orchestrator cross-references brief findings during synthesis.

Design principle: Context Engineering — right information to right agent at
right time. Research briefs are structured artifacts in the pipeline:
ultraresearch → brief → ultraplan --research → plan → ultraexecute.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Kjell Tore Guttormsen 2026-04-08 08:58:35 +02:00
commit baa2d0220b
488 changed files with 213221 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

265
skills/ms-ai-infrastructure/references/bcdr/rto-rpo-planning-ai-services.md Normal file
View file

@ -0,0 +1,265 @@
# RTO and RPO Planning for AI Services
**Last updated:** 2026-02
**Status:** GA
**Category:** Business Continuity & Disaster Recovery
---
## 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.
I norsk offentlig sektor er kravene til tilgjengelighet regulert gjennom flere rammeverk, inkludert Utredningsinstruksen, NSMs grunnprinsipper for IKT-sikkerhet og Digitaliseringsdirektoratets arkitekturprinsipper. Organisasjoner må dokumentere RTO og RPO for alle kritiske systemer som del av sin sikkerhetsstyring og internkontroll.
For AI-løsninger bringer disse kravene unike utfordringer: modelldata, treningsdata, embedding-indekser og konfigurasjoner må alle vurderes separat i en Business Impact Analysis (BIA). En chatbot med RAG-arkitektur har for eksempel separate RPO-krav for selve language model-endpointet, search-indeksen og kunnskapsdokumentene.
## Business Impact Analysis for RTO-bestemmelse
En Business Impact Analysis (BIA) er det første steget i å definere RTO for AI-systemer. BIA kartlegger forretningspåvirkningen av nedetid for hvert AI-komponent.
### Kritikalitetstier for AI-systemer
| Tier | Beskrivelse | RTO-mål | RPO-mål | Eksempel AI-bruk |
|------|-------------|---------|---------|------------------|
| Tier 0 — Mission Critical | Nedetid er uakseptabelt | < 1 min | 0 | Sanntids sikkerhetsovervåking med AI |
| Tier 1 — Business Critical | Kort nedetid tolererbar | < 15 min | < 5 min | Kundeservicebot i produksjon |
| Tier 2 — Business Operational | Timer akseptabelt | < 4 timer | < 1 time | Intern rapporteringsplattform med AI |
| Tier 3 — Administrative | Lengre nedetid OK | < 24 timer | < 24 timer | Trenings- og sandbox-miljøer |
### BIA-prosess for AI-komponenter
1. **Identifiser alle AI-avhengigheter**: Kartlegg komponentene i AI-løsningen (modell-endpoints, search-indekser, data-pipelines, embedding-stores)
2. **Vurder forretningspåvirkning per komponent**: Hva skjer hvis Azure OpenAI-endpointet er nede? Hva om AI Search-indeksen er korrupt?
3. **Kvantifiser finansiell påvirkning**: Beregn kostnad per time med nedetid
4. **Kartlegg avhengigheter**: Hvilke systemer avhenger av AI-komponentene?
5. **Definer akseptabel degradering**: Kan systemet tilby begrenset funksjonalitet uten AI?
### BIA-mal for AI-tjenester
```markdown
## Business Impact Analysis — [Tjenestenavn]
### Tjenestebeskrivelse
- **Funksjon:** [Hva gjør AI-tjenesten?]
- **Brukere:** [Antall brukere/systemer som avhenger av tjenesten]
- **Driftstid:** [Forventet tilgjengelighet, f.eks. 24/7 eller kontortid]
### Påvirkningsvurdering
| Nedetid | Finansiell påvirkning | Omdømmepåvirkning | Regulatorisk risiko |
|---------|----------------------|--------------------|--------------------|
| 0–1 time | [Lav/Middels/Høy] | [Lav/Middels/Høy] | [Lav/Middels/Høy] |
| 1–4 timer | [...] | [...] | [...] |
| 4–24 timer | [...] | [...] | [...] |
| > 24 timer | [...] | [...] | [...] |
### Konklusjon
- **Kritikalitetstier:** [0/1/2/3]
- **RTO-krav:** [X minutter/timer]
- **RPO-krav:** [X minutter/timer]
```
## Datatap-toleranse og RPO-beregning
RPO for AI-systemer krever spesiell oppmerksomhet fordi data har forskjellig verdi og regenereringstid.
### RPO-kategorier for AI-data
| Datatype | Typisk RPO | Regenereringstid | Beskyttelsesmekanisme |
|----------|-----------|-------------------|-----------------------|
| Treningsdata (datasett) | 24 timer | Dager til uker | Azure Blob Storage GRS/GZRS |
| Finjusterte modeller | 24 timer | Timer til dager | Model registry backup |
| Search-indekser (embeddings) | 1–4 timer | Timer | Dual-region indexing |
| Brukerdata/konversasjoner | 0–15 min | Ikke regenererbar | Cosmos DB multi-region writes |
| Konfigurasjoner og prompts | 0 | Minutter via IaC | Git + IaC deployment |
| Fine-tuning jobb-tilstand | 4–24 timer | Timer | Checkpoint-basert backup |
### Beregningsmodell for RPO
RPO beregnes basert på tre faktorer:
1. **Data change rate**: Hvor ofte endres dataene?
2. **Replication lag**: Hva er forsinkelsen mellom primær og sekundær region?
3. **Backup frequency**: Hvor ofte tas backup?
```
Effektiv RPO = max(Replication Lag, Backup Interval)
```
For Azure Storage med Geo Priority Replication er RPO for blobs garantert <= 15 minutter (99.0% av faktureringsperioden).
### Azure-tjenester og deres innebygde RPO
| Azure-tjeneste | Innebygd RPO | Konfigurasjon | Merknad |
|----------------|-------------|---------------|---------|
| Azure OpenAI | Ingen innebygd DR | Manuell multi-region | Stateless — redeploy i ny region |
| Azure AI Search | Ingen innebygd repl. | Manuell multi-region | Rebuild indeks fra kilde |
| Azure Cosmos DB | ~0 (multi-region writes) | Konfigurerbar | Automatisk geo-replikering |
| Azure Blob Storage (GRS) | ~15 min | Aktivér GRS/GZRS | Async replikering |
| Azure Blob Storage (GPR) | <= 15 min SLA | Aktivér Geo Priority Repl. | SLA-backed RPO |
| Azure SQL Database | ~5 sek (geo-repl.) | Active geo-replication | Async replikering |
| Azure Machine Learning | Ingen innebygd DR | Manuell multi-region | Separat storage per region |
## Mapping av krav til Azure-kapabiliteter
### Recovery-konfigurasjoner
| Konfigurasjonstype | RTO | RPO | Kostnad | Egnet for |
|--------------------|-----|-----|---------|-----------|
| Active-Active | ~0 | ~0 | Høyest | Tier 0: Mission Critical |
| Active-Passive (Warm) | Minutter | Minutter | Middels-Høy | Tier 1: Business Critical |
| Active-Passive (Cold) | Timer | Timer | Middels | Tier 2: Business Operational |
| Backup & Restore | Timer–Dager | Timer–Dager | Lavest | Tier 3: Administrative |
### Azure OpenAI BCDR-konfigurasjon
```python
# Eksempel: Multi-region Azure OpenAI med failover via Azure API Management
import openai
from azure.identity import DefaultAzureCredential
# Primær region
primary_client = openai.AzureOpenAI(
azure_endpoint="https://aoai-primary-norwayeast.openai.azure.com/",
api_version="2024-10-21",
azure_deployment="gpt-4o"
)
# Sekundær region (warm standby)
secondary_client = openai.AzureOpenAI(
azure_endpoint="https://aoai-secondary-swedencentral.openai.azure.com/",
api_version="2024-10-21",
azure_deployment="gpt-4o"
)
def call_with_failover(messages, max_retries=3):
"""Call Azure OpenAI with automatic failover to secondary region."""
try:
response = primary_client.chat.completions.create(
model="gpt-4o",
messages=messages,
timeout=30
)
return response
except Exception as e:
print(f"Primary region failed: {e}")
# Failover to secondary
response = secondary_client.chat.completions.create(
model="gpt-4o",
messages=messages,
timeout=30
)
return response
```
### Azure AI Search multi-region oppsett
```bash
# Deploy identisk search-tjeneste i to regioner
az search service create \
--name "search-primary-norwayeast" \
--resource-group "rg-ai-prod" \
--location "norwayeast" \
--sku "standard" \
--replica-count 3 \
--partition-count 2
az search service create \
--name "search-secondary-swedencentral" \
--resource-group "rg-ai-dr" \
--location "swedencentral" \
--sku "standard" \
--replica-count 2 \
--partition-count 2
# Bruk Azure Traffic Manager for routing
az network traffic-manager profile create \
--name "tm-search-failover" \
--resource-group "rg-networking" \
--routing-method Priority \
--unique-dns-name "ai-search-global"
```
## Norske regulatoriske krav
### Forvaltningsloven og Utredningsinstruksen
Norske offentlige organisasjoner må dokumentere:
- **Konsekvensanalyse**: Vurdering av konsekvenser ved bortfall av AI-tjenester
- **Alternativanalyse**: Evaluering av ulike BCDR-strategier med kost/nytte
- **Risiko- og sårbarhetsanalyse (ROS)**: Identifisering av trusler mot AI-systemers tilgjengelighet
### NSMs grunnprinsipper
NSM (Nasjonal sikkerhetsmyndighet) krever:
- Klassifisering av systemer etter kritikalitet
- Dokumenterte gjenopprettingsplaner
- Regelmessig testing av beredskapsplaner
- Loggføring og rapportering av hendelser
### Data Residency-krav
| Krav | Beskrivelse | Påvirkning på BCDR |
|------|-------------|-------------------|
| Schrems II | Data kan ikke overføres til usikre tredjeland | Begrens DR-regioner til EU/EØS |
| GDPR Art. 32 | Tilstrekkelig sikkerhetsnivå inkl. tilgjengelighet | Dokumentér RTO/RPO i DPIA |
| Forvaltningsloven §13 | Taushetsplikt | Kryptering i alle DR-regioner |
## Dokumentasjons-maler og governance
### RTO/RPO-dokumentasjonsmal
```markdown
# RTO/RPO Dokumentasjon — [Systemnavn]
## Versjon og godkjenning
- **Versjon:** [X.Y]
- **Sist oppdatert:** [Dato]
- **Godkjent av:** [Navn og rolle]
- **Neste revisjon:** [Dato]
## Systembeskrivelse
[Kort beskrivelse av AI-systemet og dets forretningsfunksjon]
## Komponentoversikt med RTO/RPO
| Komponent | Kritikalitet | RTO | RPO | DR-strategi | Ansvarlig |
|-----------|-------------|-----|-----|-------------|-----------|
| Azure OpenAI Endpoint | Høy | 15 min | N/A | Multi-region | Platform team |
| AI Search Index | Høy | 1 time | 4 timer | Dual indexing | Data team |
| Cosmos DB (state) | Kritisk | 0 | 0 | Multi-region writes | Platform team |
| Blob Storage (docs) | Middels | 4 timer | 15 min | GRS | Ops team |
## Testplan
- **Frekvens:** Kvartalsvis
- **Type:** Failover drill + tabletop
- **Suksesskriterier:** [Definer]
## Hendelsesklassifisering
[Ref. til incident response plan]
```
### Governance-prosess
1. **Årlig BIA-revisjon**: Oppdater kritikalitetsvurderinger
2. **Kvartalsvis testing**: Verifiser at RTO/RPO-mål oppnås
3. **Hendelsesdrevet oppdatering**: Revider etter reelle hendelser
4. **Endringsbasert vurdering**: Nye AI-komponenter trigger ny BIA
## Referanser
- [Business continuity and disaster recovery overview](https://learn.microsoft.com/en-us/azure/reliability/concept-business-continuity-high-availability-disaster-recovery) — Grunnleggende BCDR-konsepter og definisjoner
- [Develop a disaster recovery plan for multi-region deployments](https://learn.microsoft.com/en-us/azure/well-architected/design-guides/disaster-recovery) — WAF-veiledning for DR-planlegging
- [Recommendations for defining reliability targets](https://learn.microsoft.com/en-us/azure/well-architected/reliability/metrics) — SLO, RTO og RPO-definisjoner
- [BCDR considerations with Azure OpenAI](https://learn.microsoft.com/en-us/azure/ai-foundry/openai/how-to/business-continuity-disaster-recovery) — Azure OpenAI-spesifikk BCDR
- [Azure Storage redundancy](https://learn.microsoft.com/en-us/azure/storage/common/storage-redundancy) — GRS, GZRS og replikeringsalternativer
- [Azure Storage Geo Priority Replication](https://learn.microsoft.com/en-us/azure/storage/common/storage-redundancy-priority-replication) — SLA-backed RPO for blobs
- [Reliability in Azure AI Search](https://learn.microsoft.com/en-us/azure/reliability/reliability-ai-search) — Tilgjengelighet og DR for AI Search
## For Cosmo
- **Bruk denne referansen** når kunden trenger hjelp med å definere RTO og RPO for sine AI-systemer, eller når de planlegger BCDR-strategi.
- Start alltid med en Business Impact Analysis (BIA) før du foreslår tekniske løsninger — RTO/RPO er forretningsbeslutninger, ikke tekniske.
- Utfordre kunder som sier "alt er kritisk" — differensiert kritikalitet er nøkkelen til kostnadseffektiv BCDR.
- For norsk offentlig sektor: Påpek at DPIA (Data Protection Impact Assessment) bør inkludere tilgjengelighetsvurdering med RTO/RPO.
- Husk at Azure OpenAI er stateless — RTO handler om redeployment og DNS-oppdatering, ikke om datavederlag.