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

419
skills/ms-ai-infrastructure/references/bcdr/service-level-documentation-dr.md Normal file
View file

@ -0,0 +1,419 @@
# 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.