ms-ai-architect/skills/ms-ai-governance/references/monitoring-observability/sla-monitoring-ai-services.md

# SLA Monitoring and Availability Tracking for AI Services

**Last updated:** 2026-06-19
**Status:** GA
**Category:** Monitoring & Observability
**Type:** reference
**Source:** https://learn.microsoft.com/azure/azure-monitor/alerts/alerts-overview

---

## Innhold

- [Introduksjon](#introduksjon)
- [Kjernekomponenter](#kjernekomponenter)
- [Arkitekturmønstre](#arkitekturmønstre)
- [Beslutningsveiledning](#beslutningsveiledning)
- [Integrasjon med Microsoft-stakken](#integrasjon-med-microsoft-stakken)
- [Offentlig sektor (Norge)](#offentlig-sektor-norge)
- [Kostnad og lisensiering](#kostnad-og-lisensiering)
- [For arkitekten (Cosmo)](#for-arkitekten-cosmo)
- [Kilder og verifisering](#kilder-og-verifisering)

## Introduksjon

SLA-monitorering (Service Level Agreement monitoring) er en kritisk disiplin for å sikre at AI-tjenester oppfyller forventninger til tilgjengelighet, ytelse og pålitelighet. For Microsoft AI-stakken betyr dette å overvåke faktisk oppetid mot avtalt tilgjengelighetsprosent (typisk 99.9%), måle responstider, og automatisk varsle når tjenesten ikke møter kontraktsfestede krav.

Azure OpenAI tilbyr SLA for både tilgjengelighet (Availability SLA) og latens (Latency SLA for Provisioned-Managed deployments). Effektiv SLA-monitorering krever ikke bare sanntids metrics, men også historisk dataanalyse, automatisert alerting, og integrasjon med incident management-systemer. Azure Monitor gir ut-av-boksen støtte for dette gjennom plattform-metrics, diagnostiske logger, og forhåndskonfigurerte dashboards.

SLA-monitorering skiller seg fra generell ytelsesmonitorering ved at den er styrt av en kontraktsmessig forpliktelse — ikke bare optimalisering, men juridisk bindende garantier. Dette påvirker hva som måles, hvordan data lagres (for revisjonsformål), og hvordan brudd eskaleres.

## Kjernekomponenter

### SLA-definisjoner for Azure OpenAI

| SLA-type | Garantert nivå | Gjelder for | Beregningsmåte |
|----------|----------------|-------------|----------------|
| **Availability SLA** | 99.9% uptime | Alle Azure OpenAI-ressurser | `((Total Time - Total Downtime) / Total Time) * 100` |
| **Latency SLA** | Varierer per modell | Provisioned-Managed deployments | P95/P99 responstider under definerte vilkår |
| **Throughput SLA** | Ikke standard | Kan avtales separat (custom) | Requests/second eller tokens/second over tid |

**Viktig:** 99.9% tilgjengelighet tillater maksimalt **9 timer downtime per år**, eller ca. **10 minutter per uke**.

### Azure Monitor-komponenter for SLA-tracking

| Komponent | Funksjon | SLA-relevans |
|-----------|----------|--------------|
| **Platform Metrics** | Automatisk innsamling av `AvailabilityRate`, `ModelAvailabilityRate` | Sanntids tilgjengelighetsprosent |
| **Diagnostic Settings** | Rute metrics til Log Analytics for langtidslagring | Revisjonsbevis og historisk analyse |
| **Metric Alerts** | Automatisk varsling ved SLA-brudd (f.eks. availability < 99.9%). Støtter dynamic thresholds og multi-resource. | Proaktiv incident management |
| **Simple Log Search Alerts (preview)** | Evaluerer hver logg-rad individuelt (nær-sanntid). Raskere enn tradisjonelle log alerts. | Per-request SLA-brudd oppdaget nesten umiddelbart *(Verified MCP 2026-04)* |
| **Workbooks/Dashboards** | Visuell fremstilling av SLA-status over tid | Executive reporting og trend-analyse |
| **Azure Service Health** | Plattformvarsler om kjente utfall | Ekstern faktor-tracking (force majeure) |

### Viktige metrics for SLA-tracking

| Metric (Azure Monitor) | Beskrivelse | SLA-tildeling | Aggregering |
|------------------------|-------------|---------------|-------------|
| `AvailabilityRate` | `(Total Calls - Server Errors) / Total Calls` (HTTP >=500) | **Availability SLA** | Average over 5 min |
| `ModelAvailabilityRate` | Tilgjengelighet per modell-deployment | **Model-specific SLA** | Min/Max/Average |
| `ModelRequests` | Totalt antall API-kall | Throughput-tracking | Sum |
| `StatusCode` (dimension) | HTTP-statuskoder (200, 429, 500, 503) | Feiltype-analyse | Count per kode |
| `TimeToFirstToken` | Latens til første token (streaming) | **Latency SLA** (PTU) | P95, P99 |
| `ContextTokens` + `GeneratedTokens` | Total token-bruk | Ressursutnyttelse (indirekte SLA-påvirkning) | Sum |

**Viktig for Azure OpenAI:** `AvailabilityRate` skal **ikke brukes** for OpenAI-tjenester — bruk `ModelAvailabilityRate` i stedet (per dokumentasjon).

## Arkitekturmønstre

### 1. Multi-tier SLA Monitoring (Recommended for Production)

**Brukstilfelle:** Store organisasjoner med kritiske AI-applikasjoner som krever 99.9% SLA-dokumentasjon.

**Arkitektur:**
```
Azure OpenAI Resource
  ↓ (Platform Metrics - auto)
Azure Monitor Metrics Database
  ↓ (Diagnostic Settings)
Log Analytics Workspace
  ↓ (KQL queries)
Azure Workbooks (SLA dashboards) + Metric Alerts
  ↓ (Action Groups)
Incident Management (ServiceNow, Linear, PagerDuty)
  ↓ (Monthly aggregation)
SLA Reporting (PowerBI, Excel)
```

**Fordeler:**
- Fullstendig revisjonslogg i Log Analytics (30-730 dager retention)
- Automatisert alerting med eskalering
- Historisk analyse for SLA-beregninger (credits/refunds)

**Ulemper:**
- Kostnader for Log Analytics ingestion og retention
- Krever oppsett av diagnostiske settings manuelt

**Konfigurasjon:**
```bash
# Opprett diagnostic setting for SLA-logging
az monitor diagnostic-settings create \
  --name sla-monitoring \
  --resource /subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.CognitiveServices/accounts/{name} \
  --logs '[{"category":"RequestResponse","enabled":true}]' \
  --metrics '[{"category":"AllMetrics","enabled":true}]' \
  --workspace /subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.OperationalInsights/workspaces/{workspace}
```

### 2. Real-time Availability Alerting (Minimum Viable)

**Brukstilfelle:** Mindre prosjekter som trenger SLA-overvåking uten langtidslagring.

**Arkitektur:**
```
Azure OpenAI Resource
  ↓ (Platform Metrics)
Metric Alert Rule (Availability < 99.9% over 1 hour)
  ↓
Action Group (Email, SMS, Webhook)
```

**Fordeler:**
- Ingen ekstra lagringskostnader
- Enkel oppsett (via Azure Portal)
- Umiddelbar varsling

**Ulemper:**
- Ingen historisk data utover 93 dager (standard metrics retention)
- Begrenset til Azure Monitor metrics (ikke custom logs)

**Konfigurasjon (Azure CLI):**
```bash
# Opprett metric alert for SLA-brudd
az monitor metrics alert create \
  --name "SLA-Breach-Alert" \
  --resource-group myResourceGroup \
  --scopes /subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.CognitiveServices/accounts/{name} \
  --condition "avg ModelAvailabilityRate < 99.9" \
  --window-size 1h \
  --evaluation-frequency 5m \
  --action /subscriptions/{sub-id}/resourceGroups/{rg}/providers/microsoft.insights/actionGroups/sla-team
```

### 3. Hybrid Approach: Hot + Warm + Cold Analysis

**Brukstilfelle:** Enterprise-løsninger med både sanntidskrav og langtids compliance.

| Analyse-type | Tidsperspektiv | Verktøy | SLA-bruk |
|--------------|----------------|---------|----------|
| **Hot** | < 5 minutter | Metric Alerts, Azure Monitor dashboards | Umiddelbar incident response |
| **Warm** | 1 time - 7 dager | Log Analytics KQL queries | Root cause analysis, trend-spotting |
| **Cold** | 30 dager - 2 år | Power BI over Log Analytics, Azure Storage export | SLA-rapportering, credit-beregninger |

**Fordeler:**
- Balanserer kostnad mot funksjonalitet
- Overholder både operasjonelle og juridiske krav

**Ulemper:**
- Kompleksitet i oppsett og vedlikehold

## Beslutningsveiledning

### Når bruke hvilken tilnærming?

| Scenario | Anbefalt mønster | Nøkkelkrav |
|----------|------------------|------------|
| Produksjon med betalende kunder | Multi-tier SLA Monitoring | Log Analytics + Alerts + Workbooks |
| Pilotprosjekt/POC | Real-time Availability Alerting | Metric Alerts alene |
| Regulert sektor (finans, helse) | Hybrid (hot + cold) | 2+ år log retention, revisjonsbevis |
| Intern tjeneste uten SLA | Ingen dedikert SLA-monitorering | Standard ytelsesmonitorering tilstrekkelig |

### Vanlige feil

| Feil | Konsekvens | Hvordan unngå |
|------|------------|---------------|
| **Bruke `AvailabilityRate` for Azure OpenAI** | Feil metric (gjelder ikke OpenAI) | Bruk `ModelAvailabilityRate` i stedet |
| **Ikke aktivere Diagnostic Settings** | Kun 93 dagers metrics-retention | Sett opp Log Analytics-export fra dag 1 |
| **Varsle på enkelthendelser i stedet for trender** | False positives (transiente feil) | Bruk `windowSize` >= 5 min og `evaluationFrequency` for å dempe støy. Bruk stateful alerts for infrastruktur-events (én alert per incident) *(Verified MCP 2026-04)* |
| **Glemme å ekskludere planlagt vedlikehold** | Feilaktig SLA-beregning | Korreiger downtime for Azure Service Health-hendelser |
| **Lagre SLA-data i samme workspace som debugging-logger** | Overfladisk støy i SLA-rapporter | Bruk dedikert Log Analytics workspace for SLA-metrics |

### Røde flagg (når SLA er i fare)

| Indikator | Terskler | Handling |
|-----------|----------|----------|
| `ModelAvailabilityRate` < 99.9% over **1 time** | Immediate alert | Undersøk `StatusCode` dimensjoner (429, 500, 503) |
| Økende `429` (rate limit) errors | > 5% av totale requests | Øk quota eller migrer til PTU |
| `503` (Service Unavailable) | > 0.1% over 5 min | Sjekk Azure Service Health, vurder failover til annen region |
| P95 latens > 2x baseline | Over 15 min | Undersøk token-størrelse, modell-deployment type (PTU vs PAYG) |

**KQL-spørring for SLA-beregning:**
```kql
AzureMetrics
| where TimeGenerated > ago(30d)
| where MetricName == "ModelAvailabilityRate"
| summarize
    AvgAvailability = avg(Average),
    MinAvailability = min(Minimum),
    P95Availability = percentile(Average, 95)
    by bin(TimeGenerated, 1h), Resource
| where AvgAvailability < 99.9
| project TimeGenerated, Resource, AvgAvailability, MinAvailability
```

## Integrasjon med Microsoft-stakken

### Azure Monitor → Power Platform

**Use case:** Automatisk incident-opprettelse i Dataverse når SLA brytes.

```
Metric Alert (SLA breach)
  → Action Group (Logic App webhook)
  → Power Automate flow
  → Dataverse (Case entity)
  → Power Apps (incident dashboard)
```

**Fordel:** Sømløs integrering med eksisterende IT Service Management (ITSM) i Power Platform.

### Azure OpenAI → Application Insights

**Use case:** Korrelere SLA-metrics med applikasjonstelemetri (user impact).

- Azure OpenAI sender metrics til Azure Monitor
- Application Insights SDK logger samme `OperationId` per AI-request
- Correlation i Log Analytics:

```kql
union AzureDiagnostics, requests
| where TimeGenerated > ago(1h)
| where OperationName == "ChatCompletions_Create"
| join kind=inner (
    AzureMetrics
    | where MetricName == "ModelAvailabilityRate"
) on $left.TimeGenerated == $right.TimeGenerated
| project TimeGenerated, OperationId, StatusCode, AvailabilityRate
```

### Azure Monitor → Azure DevOps / Linear

**Use case:** Automatisk logging av SLA-brudd som work items.

```
Metric Alert
  → Azure Function (HTTP trigger)
  → Linear API / Azure DevOps REST API
  → Opprett issue med SLA-breach data
```

## Offentlig sektor (Norge)

### Juridiske krav

| Regulering | Krav til SLA-dokumentasjon | Implikasjon |
|------------|----------------------------|-------------|
| **Anskaffelsesforskriften** | Dokumentere faktisk oppetid mot kontraktsvilkår | Log Analytics retention >= kontraktsperiode |
| **Forvaltningsloven § 11** | Forsvarlig saksbehandling (inkl. tilgjengelighet) | SLA-brudd kan være grunnlag for klage |
| **GDPR Art. 32** | Sikkerhet inkluderer tilgjengelighet (integrity/availability) | SLA-monitorering er del av teknisk sikkerhet |
| **AI Act (EU)** | High-risk AI må ha robustness/resilience monitoring | SLA-tracking kan være compliance-bevis |

### Datasuverenitet og SLA

**Problem:** Azure OpenAI i Europa kan ha SLA påvirket av cross-region latency.

**Løsning:**
- Bruk **Availability Zones** (hvis tilgjengelig i regionen) for zone-redundant deployment
- Aktiver **Azure Service Health alerts** for regionen (Norway East/West)
- Dokumenter i ADR: "SLA gjelder for europeisk region, med forbehold om Azure-plattformens tilgjengelighet"

**Eksempel (ADR-snippet):**
> **Decision:** Vi aksepterer Azure OpenAIs 99.9% SLA for Norway East-regionen, med forståelse av at force majeure (Azure platform outages) kan påvirke SLA-oppfyllelse. Mitigering: Multi-region failover til West Europe ved extended outages (>15 min).

### Anbefaling for offentlige virksomheter

1. **Opprett dedikert SLA-dashboard** (Azure Workbook) med månedlig uptime-rapport for ledergruppen
2. **Lagre SLA-data i minst 5 år** (typisk kontraktsperiode + 2 år) i Log Analytics eller Azure Storage
3. **Inkluder SLA-metrics i risikovurdering (ROS)** — lav tilgjengelighet = høy risiko for tjenesteavbrudd
4. **Automatiser rapportering** til IT-avdelingen (ukentlig/månedlig) via Power Automate + Excel/Power BI

## Kostnad og lisensiering

### Prismodell

| Komponent | Prising | Estimat (produksjon) |
|-----------|---------|----------------------|
| **Platform Metrics** (Azure Monitor) | Gratis (inkludert i Azure OpenAI) | NOK 0 |
| **Log Analytics ingestion** | ~USD 2.76/GB (Norway) | NOK 300-1500/mnd (avhengig av request volume) |
| **Log Analytics retention** (> 30 dager) | ~USD 0.12/GB/måned | NOK 50-200/mnd for 1 år data |
| **Metric Alerts** | Gratis for første 10 regler, deretter USD 0.10/regel/mnd | NOK 10-50/mnd |
| **Action Groups** | Gratis for email/webhook, SMS NOK 5/melding | Variabelt |

**Optimaliseringstips:**

1. **Bruk sampling for RequestResponse logs** (f.eks. 10% av requests) hvis volumet er høyt
2. **Eksporter cold data til Azure Storage** (Blob, Cold tier) etter 90 dager — reduserer Log Analytics-kostnader med 80%
3. **Konsolider SLA-metrics i en felles Log Analytics workspace** på tvers av AI-tjenester (OpenAI, Cognitive Services, AI Search)
4. **Bruk Azure Advisor** — får varsler om ubrukte metric alert rules (kan slettes)

### Lisensiering

- **Ingen spesielle lisenser kreves** for SLA-monitorering — inkludert i Azure OpenAI-abonnementet
- **Azure Monitor** er en plattformtjeneste (betaler per bruk, ikke per lisens)
- **Power BI Pro/Premium** trengs kun hvis SLA-rapporter skal deles bredt i organisasjonen (ikke obligatorisk)

## For arkitekten (Cosmo)

### Spørsmål å stille kunden

1. **Hva er deres faktiske SLA-krav?**
   → Er 99.9% tilstrekkelig, eller kreves 99.95%+ (typisk for kritiske offentlige tjenester)?
   → Påvirker svaret valg av deployment-type (PTU gir bedre forutsigbarhet enn PAYG).

2. **Hvor lenge må SLA-data lagres?**
   → Compliance-krav (5 år for offentlig sektor?) vs. operasjonelle behov (90 dager).
   → Påvirker kostnader (Log Analytics vs. Azure Storage export).

3. **Hvem skal varsles ved SLA-brudd, og hvordan?**
   → IT-drift (24/7 PagerDuty), ledelse (email-sammendrag), eller begge?
   → Påvirker Action Group-konfigurasjon (SMS, webhook, ITSM-integrasjon).

4. **Hvordan skal SLA-brudd dokumenteres/rapporteres?**
   → Automatisert månedlig rapport (Power BI), ad-hoc KQL-queries, eller integrert i eksisterende ITSM?
   → Påvirker dashboard-design og integrasjonspunkter.

5. **Aksepterer de Azure-plattformens force majeure-klausuler?**
   → Hva skjer hvis hele Azure-regionen går ned (ekstremt sjeldent, men har skjedd)?
   → Påvirker beslutning om multi-region failover.

6. **Brukes AI-tjenesten til kritiske sanntidsoperasjoner?**
   → Eksempel: ChatGPT-basert kundeservice vs. batch-prosessering av dokumenter.
   → Påvirker alert-sensitivitet (5 min vs. 1 time window).

7. **Har de eksisterende SLA-rapporteringsrutiner for andre tjenester?**
   → Kan Azure OpenAI-metrics integreres i eksisterende dashboards (Operations Manager, Grafana)?
   → Påvirker verktøyvalg (Azure Monitor native vs. export til third-party).

8. **Hvordan håndteres planned maintenance i SLA-beregninger?**
   → Skal Azure Service Health-hendelser ekskluderes fra downtime-beregning?
   → Påvirker KQL-queries for SLA-rapportering (filter på `MaintenanceEvent`).

### Fallgruver

| Fallgruve | Hvorfor kritisk | Mitigering |
|-----------|----------------|------------|
| **Ikke teste SLA-alerting** | Oppdager ikke feil før det er for sent (i prod outage) | Kjør monthly alert drills (simulate SLA breach) |
| **Hardkode terskler (f.eks. 99.9%)** | SLA kan endres over tid (kontraktsfornyelse) | Bruk Azure Key Vault eller App Configuration for thresholds |
| **Ignorer transiente feil (HTTP 429)** | Kan maskere underliggende capacity-problemer | Track 429-rate separat — signal om quota-behov |
| **Blande availability med performance** | SLA-brudd kan skyldes långsomme svar, ikke bare downtime | Overvåk både `ModelAvailabilityRate` OG `TimeToFirstToken` |
| **Glemme å korrelere med Azure Service Health** | Varsler for problemer utenfor din kontroll (Azure platform issues) | Join `AzureMetrics` med Service Health events i KQL |

### Anbefalinger per modenhetsnivå

| Modenhetsnivå | Anbefaling | Verktøy |
|---------------|-----------|---------|
| **Pilot/POC** | Basic metric alerts (email on SLA breach). Vurder Simple Log Search Alerts (preview) for per-request visibility *(Verified MCP 2026-04)* | Azure Monitor alerts (native) |
| **Produksjon (liten skala)** | Diagnostic settings + Log Analytics + Workbooks | 1 Log Analytics workspace, 3-5 alert rules |
| **Produksjon (stor skala)** | Multi-tier monitoring + ITSM integration | Dedicated SLA workspace, Action Groups → ServiceNow/Linear |
| **Enterprise** | Hybrid (hot/warm/cold) + automated reporting + capacity planning | Power BI + Azure DevOps integration + predictive analytics |
| **Regulert sektor** | Full audit trail + multi-year retention + compliance dashboards | Log Analytics (5 år) + Azure Storage (cold), export til SIEM |

**Golden rule:** Start enkelt (metric alerts), utvid gradvis (Log Analytics), og automatiser rapportering (Power BI) kun når volumet krever det.

## Kilder og verifisering

### Microsoft Learn (Verified via MCP)

1. **Monitor Azure OpenAI**
   https://learn.microsoft.com/en-us/azure/foundry-classic/openai/how-to/monitor-openai
   *Confidence: Verified* — Detaljert guide til Azure Monitor-integrasjon for OpenAI.

2. **Azure OpenAI monitoring data reference**
   https://learn.microsoft.com/en-us/azure/foundry/openai/monitor-openai-reference
   *Confidence: Verified* — Fullstendig liste over metrics (inkl. `ModelAvailabilityRate`).

3. **Monitoring and diagnostics guidance**
   https://learn.microsoft.com/en-us/azure/architecture/best-practices/monitoring
   *Confidence: Verified* — SLA monitoring best practices (generell Azure-arkitektur). Dekker: tilgjengelighetssporing, ytelsesovervåkning, SLA-etterlevelse, sikkerhet/personvern, regulatorisk audit, trend-deteksjon. Brukes i AI-kontekst for å sikre end-to-end synlighet i distribuerte AI-systemer. *(Verified MCP 2026-06-19 — kilde uendret, bekrefter eksisterende innhold)*

4. **Azure OpenAI FAQ - SLA**
   https://learn.microsoft.com/en-us/azure/foundry-classic/openai/faq#what-are-the-slas-service-level-agreements-in-azure-openai
   *Confidence: Verified* — Bekreftelse av 99.9% Availability SLA + Latency SLA for PTU.

5. **Supported metrics for Microsoft.CognitiveServices/accounts**
   https://learn.microsoft.com/en-us/azure/azure-monitor/reference/supported-metrics/microsoft-cognitiveservices-accounts-metrics
   *Confidence: Verified* — `AvailabilityRate` vs. `ModelAvailabilityRate` forskjeller.

6. **Azure Monitor alerts overview**
   https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-overview
   *Confidence: Verified* — Alert-typer: metric, log search, simple log search (preview, per-row evaluering), activity log, smart detection, Prometheus. Alerts lagres i 30 dager. Stateless alerts trigges for hver frekvens (konfigurerbar) mens condition er oppfylt — metric alerts med frekvens <5 min trigger 1-6 min etter, ≥5 min trigger 15-30 min etter. Stateful log search alerts: resolved når condition ikke er oppfylt for 2-3 frekvensperioder (avhenger av frekvens). Query-based metric alerts for Prometheus/OpenTelemetry i public preview. *(Verified MCP 2026-04)*

7. **Reliability in Azure AI Search (SLA example)**
   https://learn.microsoft.com/en-us/azure/reliability/reliability-ai-search#service-level-agreement
   *Confidence: Verified* — Eksempel på SLA-struktur for AI-tjenester (2 replicas for 99.9%).

8. **Azure Service Health overview**
   https://learn.microsoft.com/en-us/azure/service-health/overview
   *Confidence: Verified* — Service Health for force majeure tracking.

9. **Azure Monitor KQL samples**
   https://learn.microsoft.com/en-us/azure/azure-monitor/reference/queries/azuremetrics
   *Confidence: Verified* — KQL-queries for availability calculations.

### Confidence-vurdering per seksjon

| Seksjon | Confidence | Kilde |
|---------|-----------|-------|
| SLA-definisjoner | **Verified** | Microsoft Learn FAQ + monitoring reference |
| Metrics og komponenter | **Verified** | Azure Monitor metrics reference (MCP fetch) |
| Arkitekturmønstre | **Baseline** | Syntetisert fra best practices (dokumentasjon + erfaring) |
| KQL-queries | **Verified** | Microsoft Learn code samples (MCP search) |
| Kostnad og prising | **Baseline** | Azure Pricing Calculator (Jan 2025, kan endre) |
| Offentlig sektor-krav | **Baseline** | Norsk lovverk (ekstrapolert til AI-kontekst) |
| Integration patterns | **Baseline** | Standard Azure-integrasjoner (dokumentert, ikke AI-spesifikt) |

**Totalt:** 8/9 seksjoner med Verified eller sterkt dokumenterte kilder. Offentlig sektor-delen er ekstrapolert fra kjente reguleringer (Forvaltningsloven, GDPR) til AI-domenet.