ktg-plugin-marketplace/plugins/ms-ai-architect/skills/ms-ai-infrastructure/references/bcdr/service-level-documentation-dr.md

Service Level Documentation and DR Runbooks

Last updated: 2026-02 Status: GA Category: Business Continuity & Disaster Recovery

---

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.

For AI-systemer er dokumentasjon spesielt viktig fordi gjenopprettingsprosedyrer ofte involverer flere Azure-tjenester med ulike oppstartstider og avhengigheter. En RAG-løsning krever for eksempel at Cosmos DB er tilgjengelig før App Service, som igjen må vente på at AI Search-indeksen er synkronisert, før Azure OpenAI-kall kan brukes meningsfullt.

Azure Well-Architected Framework understreker at en DR-plan må inkludere tre essensielle komponenter: en klar runbook, en veldefinert kommunikasjonsplan, og en strukturert eskaleringsvei. For norsk offentlig sektor bør disse dokumentene følge organisasjonens ITIL-rammeverk og NSMs krav til beredskapsplanlegging.

Service Level Agreement-maler

SLA-dokument for AI-tjeneste

# Service Level Agreement
## [AI-tjeneste navn]

### 1. Tjenestebeskrivelse
| Felt | Verdi |
|------|-------|
| Tjenestenavn | [Navn] |
| Tjenesteeier | [Avdeling/person] |
| Versjon | [X.Y] |
| Gyldig fra | [Dato] |
| Neste revisjon | [Dato] |

### 2. Tjenestenivåmål (SLO)

#### 2.1 Tilgjengelighet
| Mål | Verdi | Måleperiode | Ekskluderinger |
|-----|-------|-------------|----------------|
| Tilgjengelighet | 99.9% | Månedlig | Planlagt vedlikehold |
| Oppetid (beregnet) | ~43.8 min nedetid/mnd | — | — |

#### 2.2 Ytelse
| Mål | Verdi | Målepunkt |
|-----|-------|-----------|
| Chat response time (P95) | < 5 sekunder | End-to-end |
| Search query time (P95) | < 500 ms | API-nivå |
| Throughput | > 100 samtidige brukere | Applikasjonsnivå |

#### 2.3 Gjenoppretting
| Mål | Verdi | Merknad |
|-----|-------|---------|
| RTO | 15 minutter | Fra deteksjon til gjenopprettet |
| RPO | 5 minutter | Maks akseptabelt datatap |
| MTTR | < 30 minutter | Gjennomsnittlig gjenopprettingstid |

### 3. Ansvar og eskalering
| Rolle | Ansvarlig | Telefon | Epost |
|-------|-----------|---------|-------|
| Tjenesteeier | [Navn] | [Tlf] | [Epost] |
| Teknisk ansvarlig | [Navn] | [Tlf] | [Epost] |
| DR-koordinator | [Navn] | [Tlf] | [Epost] |
| Backup kontakt | [Navn] | [Tlf] | [Epost] |

### 4. Vedlikehold og unntak
- Planlagt vedlikehold: Tirsdager 02:00–04:00 CET
- Varsling: Minimum 72 timer i forkant
- Nødvedlikehold: Varsling så snart som mulig

### 5. Rapportering
- Månedlig SLA-rapport til tjenesteeier
- Kvartalsvis trendrapport til ledelsen
- Umiddelbar hendelsesrapport ved SLA-brudd

RTO og RPO dokumentasjonsstandarder

Detaljert RTO/RPO-dokumentasjon

# RTO/RPO Spesifikasjon — AI Platform

## Komponentoversikt med gjenopprettingsmål

| ID | Komponent | Kritikalitet | RTO | RPO | DR-strategi | Region |
|----|-----------|-------------|-----|-----|-------------|--------|
| C01 | Azure OpenAI | Høy | 5 min | N/A | Multi-region failover | NE→SC |
| C02 | Azure AI Search | Høy | 15 min | 30 min | Dual-indexing | NE→SC |
| C03 | Cosmos DB | Kritisk | ~0 | ~0 | Multi-region writes | NE+SC |
| C04 | App Service | Høy | 5 min | N/A | Multi-region + TM | NE→SC |
| C05 | Azure Key Vault | Kritisk | Auto | Auto | MS-managed failover | NE→SC |
| C06 | Blob Storage (docs) | Middels | 15 min | 15 min | GZRS | NE→SC |
| C07 | Redis Cache | Middels | 10 min | 5 min | Geo-replication | NE→SC |
| C08 | App Configuration | Lav | 5 min | ~0 | Geo-replication | NE→SC |

## Avhengighetsrekkefølge for gjenoppretting

```mermaid
graph LR
    KV[Key Vault C05] --> DB[Cosmos DB C03]
    KV --> Redis[Redis C07]
    DB --> App[App Service C04]
    Redis --> App
    Config[App Config C08] --> App
    Storage[Blob Storage C06] --> Search[AI Search C02]
    Search --> App
    App --> AOAI[Azure OpenAI C01]

Gjenopprettingsrekkefølge

1. Key Vault (automatisk failover)
2. Cosmos DB (automatisk multi-region)
3. Redis Cache (geo-replication failover)
4. App Configuration (geo-replication failover)
5. Blob Storage (GRS failover if needed)
6. AI Search (start indexer i sekundær region)
7. App Service (deploy/scale i sekundær region)
8. Azure OpenAI (verifiser sekundært endpoint)
9. Traffic Manager (oppdater routing)

## Disaster Recovery Runbooks og Playbooks

### Master DR Runbook

```markdown
# DR Runbook — AI Platform

## Forutsetninger
- Tilgang til Azure Portal med Owner-rolle på rg-ai-dr
- Azure CLI installert og autentisert
- Tilgang til organisasjonens incident management system
- Kontaktliste for eskalering tilgjengelig

## Fase 1: Deteksjon og Vurdering (0–5 minutter)

### Steg 1.1: Verifiser hendelsen
- [ ] Sjekk Azure Service Health: https://status.azure.com
- [ ] Sjekk intern monitoring: [Dashboard URL]
- [ ] Verifiser med automatisk helsesjekk:
  ```bash
  curl -s https://ai-app-prod.azurewebsites.net/health/deep | jq .

Steg 1.2: Klassifiser hendelsen

Scenario	Alvorlighetsgrad	Aksjon
Enkelt komponent nede	P2	Standard feilsøking
Regional degradering	P1	Vurder partial failover
Full regional outage	P0	Initier full DR

Steg 1.3: Deklarer hendelse

• Opprett incident i [ITSM-system]
• Varsle DR-koordinator
• Aktiver kommunikasjonsplan

---

Fase 2: Failover-initiering (5–10 minutter)

Steg 2.1: Verifiser DR-region readiness

# Sjekk at DR-ressurser er tilgjengelige
az resource list \
  --resource-group "rg-ai-dr" \
  --query "[].{Name:name, Type:type, Location:location}" \
  --output table

# Sjekk Cosmos DB replikering
az cosmosdb show \
  --name "cosmos-ai-state" \
  --resource-group "rg-ai-prod" \
  --query "readLocations[].{Region:locationName, State:failoverPriority}" \
  --output table

Steg 2.2: Scale up DR-ressurser

# Scale AI Search til produksjonsnivå
az search service update \
  --name "search-secondary-swedencentral" \
  --resource-group "rg-ai-dr" \
  --replica-count 3

# Scale App Service
az appservice plan update \
  --name "asp-ai-dr" \
  --resource-group "rg-ai-dr" \
  --sku P3v3

# Verifiser OpenAI-endpoint i DR-region
curl -s -H "api-key: $AOAI_DR_KEY" \
  "https://aoai-secondary-swedencentral.openai.azure.com/openai/deployments/gpt-4o/chat/completions?api-version=2024-10-21" \
  -d '{"messages":[{"role":"user","content":"test"}]}' | jq .status

Steg 2.3: Oppdater Traffic Manager

# Switch til sekundær region
az network traffic-manager endpoint update \
  --resource-group "rg-networking" \
  --profile-name "tm-ai-platform" \
  --name "primary-norwayeast" \
  --type azureEndpoints \
  --endpoint-status Disabled

az network traffic-manager endpoint update \
  --resource-group "rg-networking" \
  --profile-name "tm-ai-platform" \
  --name "secondary-swedencentral" \
  --type azureEndpoints \
  --endpoint-status Enabled

---

Fase 3: Verifikasjon (10–15 minutter)

Steg 3.1: Funksjonell testing

• Test health endpoint: curl https://ai-app-dr.azurewebsites.net/health/deep
• Test chat-funksjonalitet manuelt
• Test search-funksjonalitet
• Verifiser brukerautentisering

Steg 3.2: Data-integritet

• Sjekk Cosmos DB datakonsistens
• Verifiser AI Search indeksstatus
• Kontroller at siste data er tilgjengelig

Steg 3.3: Ytelsesverifisering

• Kjør syntetisk lasttest (lav belastning)
• Verifiser at responstider er akseptable
• Sjekk at auto-scaling fungerer

---

Fase 4: Stabilisering og Kommunikasjon

Steg 4.1: Oppdater interessenter

• Send statusoppdatering til alle berørte
• Oppdater statusside
• Informer kundeservice

Steg 4.2: Overvåking

• Sett opp forsterket overvåking i DR-region
• Konfigurer alerts med lavere terskler
• Start kontinuerlig helsesjekk

---

Fase 5: Failback (når primær region er tilgjengelig)

Steg 5.1: Verifiser primær region

• Bekreft at Azure Service Health viser "Resolved"
• Test primær region infrastruktur
• Verifiser data-synkronisering

Steg 5.2: Planlegg failback

• Velg lavtrafikk-vindu for failback
• Kommuniser plan til interessenter
• Forbered failback-runbook

Steg 5.3: Utfør failback

# Re-aktiver primær region
az network traffic-manager endpoint update \
  --resource-group "rg-networking" \
  --profile-name "tm-ai-platform" \
  --name "primary-norwayeast" \
  --type azureEndpoints \
  --endpoint-status Enabled

# Gradvis shift trafikk tilbake (weighted routing)
# eller oppdater priority

Steg 5.4: Nedskaler DR-region

# Etter verifisert failback, nedskaler DR
az search service update \
  --name "search-secondary-swedencentral" \
  --resource-group "rg-ai-dr" \
  --replica-count 2

az appservice plan update \
  --name "asp-ai-dr" \
  --resource-group "rg-ai-dr" \
  --sku P2v3

---

Fase 6: Post-Incident

• Gjennomfør post-mortem innen 5 virkedager
• Oppdater runbooks basert på erfaringer
• Logg faktisk RTO/RPO vs. mål
• Oppdater BCDR-dokumentasjon

## Trinn-for-trinn gjenopprettingsprosedyrer

### Spesifikk prosedyre: Azure AI Search Index Rebuild

```markdown
# Prosedyre: Rebuild AI Search Index i DR-region

## Når brukes denne?
- AI Search primær region er utilgjengelig
- Search indeks i DR-region er utdatert (> RPO)
- Corrupted index detected

## Forutsetninger
- Kildedokumenter tilgjengelig i DR-region (Blob Storage GZRS)
- Search service i DR-region er kjørende
- Skillset og indexer-definisjoner lagret i IaC (Git)

## Prosedyre

### 1. Verifiser at indeksdefinisjoner er tilgjengelige
```bash
# Hent indeksdefinisjon fra IaC-repo
git clone https://github.com/org/ai-infrastructure.git
cd ai-infrastructure/search-indexes/
cat knowledge-base-index.json | jq .name

2. Opprett/oppdater indeks i DR-region

# Opprett indeks
curl -X PUT \
  "https://search-secondary-swedencentral.search.windows.net/indexes/knowledge-base?api-version=2024-07-01" \
  -H "api-key: $SEARCH_DR_KEY" \
  -H "Content-Type: application/json" \
  -d @knowledge-base-index.json

# Opprett datasource
curl -X PUT \
  "https://search-secondary-swedencentral.search.windows.net/datasources/blob-source?api-version=2024-07-01" \
  -H "api-key: $SEARCH_DR_KEY" \
  -H "Content-Type: application/json" \
  -d @blob-datasource-dr.json

# Opprett skillset (hvis AI enrichment brukes)
curl -X PUT \
  "https://search-secondary-swedencentral.search.windows.net/skillsets/embedding-skillset?api-version=2024-07-01" \
  -H "api-key: $SEARCH_DR_KEY" \
  -H "Content-Type: application/json" \
  -d @embedding-skillset.json

3. Start full re-indeksering

# Opprett og kjør indexer
curl -X PUT \
  "https://search-secondary-swedencentral.search.windows.net/indexers/blob-indexer?api-version=2024-07-01" \
  -H "api-key: $SEARCH_DR_KEY" \
  -H "Content-Type: application/json" \
  -d @blob-indexer.json

# Overvåk indexer-status
watch -n 10 'curl -s \
  "https://search-secondary-swedencentral.search.windows.net/indexers/blob-indexer/status?api-version=2024-07-01" \
  -H "api-key: $SEARCH_DR_KEY" | jq ".lastResult.status, .lastResult.itemsProcessed"'

4. Verifiser indekskvalitet

# Sjekk dokumenttelling
curl -s "https://search-secondary-swedencentral.search.windows.net/indexes/knowledge-base/docs/\$count?api-version=2024-07-01" \
  -H "api-key: $SEARCH_DR_KEY"

# Test en søkespørring
curl -s "https://search-secondary-swedencentral.search.windows.net/indexes/knowledge-base/docs/search?api-version=2024-07-01" \
  -H "api-key: $SEARCH_DR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"search": "test query", "top": 5}' | jq '.value | length'

5. Forventet tidsbruk

Indeksstørrelse	Estimert tid	Merknad
< 10,000 docs	10–20 min	Inkl. embedding-generering
10,000–100,000	30–60 min	Avhenger av skillset
> 100,000	1–4 timer	Vurder parallel indexing

## Eierskap og eskaleringsmatrise

### RACI-matrise for DR

| Aktivitet | Platform Team | AI Team | Security | Management | Microsoft |
|-----------|:------------:|:-------:|:--------:|:----------:|:---------:|
| Deteksjon | R | I | I | I | C |
| Beslutning om failover | A | C | C | I | — |
| Teknisk failover | R | C | I | I | C |
| Kommunikasjon (intern) | I | I | I | R/A | — |
| Kommunikasjon (ekstern) | I | I | I | R/A | — |
| Verifisering | R | R | C | I | — |
| Failback-planlegging | R | C | C | A | C |
| Post-mortem | R | R | C | A | — |

*R = Responsible, A = Accountable, C = Consulted, I = Informed*

## Referanser

- [Document your DR plan](https://learn.microsoft.com/en-us/azure/well-architected/design-guides/disaster-recovery#document-your-dr-plan) — WAF DR-dokumentasjon
- [DR communication plan](https://learn.microsoft.com/en-us/azure/well-architected/design-guides/disaster-recovery#document-your-dr-plan) — Kommunikasjonsplan
- [Test regularly and improve the plan](https://learn.microsoft.com/en-us/azure/well-architected/design-guides/disaster-recovery#test-regularly-and-improve-the-plan) — Testing av DR-plan
- [Create an effective incident management plan](https://learn.microsoft.com/en-us/azure/well-architected/design-guides/incident-management) — Incident management
- [Recommendations for defining reliability targets](https://learn.microsoft.com/en-us/azure/well-architected/reliability/metrics) — SLO-definisjoner
- [Reliability in Azure AI Search](https://learn.microsoft.com/en-us/azure/reliability/reliability-ai-search) — AI Search DR

## For Cosmo

- **Bruk denne referansen** når kunden trenger maler for SLA-dokumentasjon, DR-runbooks eller eskaleringsprosedyrer for AI-systemer.
- DR-runbooks MÅ være executable — hvert steg skal ha konkrete kommandoer, ikke bare beskrivelser.
- Versjonér runbooks i Git som kode — de endres like ofte som infrastrukturen.
- Gjenopprettingsrekkefølge er kritisk — dokumentér avhengigheter eksplisitt og test at rekkefølgen fungerer.
- For norsk offentlig sektor: RACI-matrise bør inkludere personvernombud (DPO) for hendelser som involverer persondata.