running-demo

Running the Demo

This skill drives the full demo using Playwright MCP for browser control. Execute each step — don't just describe them.

Setup

# AKS is a private cluster — kubectl from your local workstation won't work without VPN/jumpbox.
# Use `Invoke-AksCommand` (wraps `az aks command invoke` for human-operator polling/diagnostics).
# The SRE Agent uses the built-in RunKubectl* system tools; this helper is for human operators.
. .\scripts\_aks-helpers.ps1
$rg  = (azd env get-value RESOURCE_GROUP)
$aks = (azd env get-value AKS_CLUSTER_NAME)
$pg  = (az postgres flexible-server list -g $rg --query '[0].name' -o tsv)
$r = Invoke-AksCommand -ResourceGroup $rg -ClusterName $aks `
    -Command "kubectl get svc -n ingress-nginx ingress-nginx-controller -o jsonpath='{.status.loadBalancer.ingress[0].ip}'" -Quiet
$ip = ($r.logs -replace '[^\d\.]','').Trim()
$storeUrl = "http://$ip"
$agentUrl = (azd env get-value AGENT_PORTAL_URL)  # deep-links to this agent's blade — sign in if prompted

When observing or prompting the SRE Agent, use its built-in RunKubectlReadCommand and RunKubectlWriteCommand tools for Kubernetes.

Scenario 1: Database Outage

Step 1: Show healthy state

1. Use Playwright MCP to navigate to $storeUrl
2. Take a screenshot — show products loading, status bar says "ALL SYSTEMS OPERATIONAL"
3. Navigate to $storeUrl/api/health — show "status":"healthy","db_connected":true

Step 2: Break it

.\.github\skills\running-demo\scripts\break-sql.ps1

Wait 30 seconds for the app to notice.

Step 3: Show the break in the browser

1. Navigate to $storeUrl — should show "SERVICE DISRUPTION" overlay
2. Take a screenshot — this is the degraded UI the audience should see
3. Navigate to $storeUrl/api/health — show "status":"unhealthy","db_connected":false

Step 4: Watch the SRE Agent

1. Navigate to $agentUrl — the agent portal
2. Look for a new incident thread (postgres-unreachable scheduled-query alert, routed to the zava-database response plan)
3. The agent should investigate and run az postgres flexible-server start
4. Poll PostgreSQL state every 60s — let the agent do its thing, do NOT run the fix script:

   az postgres flexible-server show -g $rg -n $pg --query state -o tsv
   

5. Wait until state = "Ready" (typically 3-5 min)
6. There's now one postgres-unreachable alert for both DB scenarios, with the zava-database response plan merge disabled (the agent won't fold a second incident into the first thread). Both scenarios share that single rule, so Azure Monitor won't emit a fresh alert instance while the previous one is still Fired/Acknowledged. To keep back-to-back runs clean, the database-incidents runbook has the agent close the postgres-unreachable alert as its final step once recovery is verified — so by the time you start Scenario 2 it should already be resolved and the new break dispatches fresh. (Fallback if the agent didn't close it: autoMitigate resolves it ~15-30 min after recovery, or close it yourself in the portal Alerts blade.) The agent diagnoses each from ARM state (Stopped → restart; Ready but unreachable → NetworkPolicy/NSG).