# 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

```markdown
# 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

```markdown
# 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
```bash
# 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
```bash
# 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
```bash
# 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
```bash
# 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
```bash
# 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
```bash
# 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
```bash
# 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
```bash
# 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.