AKS-Nachtstörungs-Runbook für IT-Leitungen in Pflegeeinrichtungen

Um 23:40 Uhr ruft die Nachtverantwortliche an: Die Buchungsseite der Pflegeeinrichtung öffnet sich, aber ein Pflegeeintrag lässt sich nicht speichern. Eine Azure-E-Mail liegt vor, doch in der Übergabe fehlen Zielressource, Schweregrad und der Zustand der Warnung. Im Entwurf an den IT-Dienstleister steht sogar der Name einer betreuten Person. Die Betriebs- und IT-Leitung muss gleichzeitig die verzögerte Untersuchung und die weitere Verbreitung personenbezogener Daten stoppen.

Dieser Artikel richtet sich an die verantwortliche Person für die Buchungs- und Pflegeanwendung der Einrichtung in Azure einschließlich der nächtlichen Eskalation. Er ist keine Anleitung für Pflegekräfte. Ziel ist ein Runbook mit einer gemeinsamen Incident-Zeitleiste, das betriebliche Entscheidungen der Einrichtung von der technischen AKS-Untersuchung trennt.

Azure Kubernetes Service (AKS) ist der verwaltete Kubernetes-Dienst in Azure für Bereitstellung und Betrieb containerisierter Anwendungen. Kubernetes plant, startet und skaliert Gruppen von Containern; Azure übernimmt den Betriebsaufwand der AKS-Steuerungsebene. Azure entscheidet jedoch weder über die Auswirkung auf die Einrichtung noch untersucht es automatisch jeden Workload oder legt die nächtliche Kontaktfolge fest.

Kernaussagen

• Azure severity darf nicht direkt zum Störungsgrad der Einrichtung werden; Buchung, Pflegedokumentation, Übergabe und Sicherheit werden getrennt bewertet.
• Vor Claude Code wird das Common-Alert-Schema-JSON bereinigt und lokal auf Pflichtfelder sowie direkte personenbezogene Daten geprüft.
• Aufgaben von Claude Code, Entscheidungen des Azure/IT-Betriebs und Entscheidungen der Pflegeeinrichtung bleiben getrennt.
• Ohne Azure-Zugangsdaten ist dies ein Test des Übergabevertrags, kein AKS- oder Zustellungstest.
• Der ROI wird aus Zeitstempeln, Ablehnungen und Arbeitsminuten vergleichbarer Incidents gemessen, nicht mit erfundenen Verbesserungswerten.

Die Nachtstörung als einen Übergabe-Arbeitsablauf führen

Telefonate, Azure-Benachrichtigungen, betroffene Seiten und Kontaktlisten erzeugen unterschiedliche Darstellungen, wenn sie in getrennten Notizen liegen. Die erste Tabelle enthält betriebliche Fakten: „Buchungssuche funktioniert“, „Pflegeeintrag wird nicht gespeichert“, „Papierdokumentation aktiv“ und „nächste Aktualisierung 00:10 Uhr“. Pod-, Node- und Deployment-Zustände folgen als technische Belege.

Azure Monitor ist Microsofts einheitlicher Observability-Dienst zum Erfassen, Analysieren und Verarbeiten von Metriken, Protokollen, Traces und Ereignissen aus Cloud- und Hybridumgebungen. Das Azure Monitor Common Alert Schema, auf Deutsch gemeinsames Warnungsschema, ist die standardisierte JSON-Struktur für unterschiedliche Azure-Monitor-Warnungen. data.essentials enthält gemeinsame Metadaten wie den Schweregrad, data.alertContext liefert signalabhängigen Untersuchungskontext.

Microsoft Learn dokumentiert für severity die Werte Sev0 bis Sev4, für signalType Metric, Log oder Activity Log und für monitorCondition Fired oder Resolved. alertTargetIDs ist die Liste betroffener Azure-Resource-Manager-IDs. Diese Felder helfen bei der Weiterleitung, entscheiden aber nicht über Bewohnersicherheit, Papierbetrieb oder die betriebliche Wiederherstellung.

Am 23. Juli 2026 wurden diese Primärquellen geprüft: Was ist AKS?, Azure Monitor Übersicht, Common Alert Schema, AKS überwachen und Service Health-Warnungen. Ergänzend helfen der Kubernetes-Deployment-Leitfaden und die Claude-Code-Sicherheitscheckliste.

flowchart TD
  A["Azure-Monitor-Warnung empfangen"] --> B["Bereinigtes JSON-Fixture speichern"]
  B --> C{"Lokaler Validator erfolgreich?"}
  C -- "Nein" --> D["Personendaten entfernen oder Pflichtfelder ergänzen"]
  D --> B
  C -- "Ja" --> E["Claude Code strukturiert die Übergabe"]
  E --> F["Azure/IT entscheidet technische Untersuchung"]
  E --> G["Pflegeeinrichtung entscheidet Betriebskontinuität"]
  F --> H["Belege zum nächsten Aktualisierungszeitpunkt vereinen"]
  G --> H
  H --> I{"Beide Abschlussbedingungen erfüllt?"}
  I -- "Nein" --> H
  I -- "Ja" --> J["Nachbesprechung dokumentieren"]

Service Health ist eine weitere Belegquelle für Benachrichtigungen zu konfigurierten Abonnements, Diensten, Regionen und Ereignistypen. Eine leere Ansicht beweist keinen gesunden Anwendungszustand. Ebenso beendet eine AKS-Warnung mit Resolved weder die Nachpflege von Papierunterlagen noch die Buchungsprüfung.

Was Claude Code übernimmt und was Menschen entscheiden

Die Übergabetabelle nennt Eingaben, Ausgaben, Verbote und Freigaben. Wird Claude Code zum Wiederherstellungsverantwortlichen erklärt, landen unbelegte Diagnosen und Änderungsbefehle in derselben Unterhaltung. Hier ordnet es nur freigegebene Belege.

Aufgaben von Claude Code

• severity, signalType, monitorCondition, alertTargetIDs und Zeitangaben aus einem bereits geprüften Fixture extrahieren.
• Bestätigte Fakten, Unbekanntes und ausstehende menschliche Entscheidungen trennen; fehlende Aktualisierungszeit melden.
• Unter einer incident ID getrennte Texte für Einrichtung und IT-Dienstleister erstellen.
• Beobachtungsbefehle vorschlagen, aber nicht ausführen, und erforderliche Belege und Rechte nennen.

Entscheidungen des Azure/IT-Betriebs

• Reihenfolge für Warnungsregel, Ziel, Monitoring, letzte Änderungen und AKS-Telemetrie festlegen.
• Weitere Belege aus Azure Portal, Container insights, Log Analytics oder einem autorisierten Terminal anfordern.
• Neustart, Skalierung, Rollback und technische Eskalation freigeben oder ablehnen.
• Entscheiden, ob Resolved als technischer Wiederherstellungsbeleg genügt oder weiter überwacht wird.

Entscheidungen der Pflegeeinrichtung

• Buchungen pausieren, Pflegedokumentation auf Papier umstellen oder einen Ablauf priorisieren.
• Sicherheitskontrollen, Übergabe, spätere Eingabe und Kommunikation mit Angehörigen oder Dritten steuern.
• Freigeben, welche Informationen geteilt werden, wann das nächste Update erfolgt und wann der Betrieb wiederhergestellt ist.
• Zuständigkeit für fehlende Einträge oder doppelte Buchungen nach der technischen Wiederherstellung bestimmen.

Dies ist keine individuelle Rechtsberatung. Einordnung, Aufbewahrung, Weitergabe und Meldung personenbezogener Daten richten sich nach Regeln, Verträgen und zuständigen Stellen der Einrichtung.

Drei Anwendungsfälle

Anwendungsfall 1: Ausfall der Buchungs-API nachts übergeben

• Eingabe: bereinigtes Common-Alert-Schema-Fixture, Seitenprüfung, Incident-Zeit und nächster Updatezeitpunkt.
• Ausgabe: Kontaktblatt mit getrennten Azure-Ziel-IDs und Betriebsauswirkungen, offenen Punkten und Dienstleisterauftrag.
• Menschliche Prüfung: Azure/IT genehmigt die Untersuchung; die Einrichtung genehmigt Ersatzkanal und Dublettenprüfung.

Sev1 allein rechtfertigt nicht die Schließung aller Buchungskanäle. Lesefehler und doppelte Schreibvorgänge erfordern andere Maßnahmen. Claude Code trennt beobachtete Fakten und ausstehende Freigaben, ohne zu entscheiden.

Anwendungsfall 2: Verzögerte Pflegeeinträge eskalieren

• Eingabe: gültiges Fixture, betroffene Funktion, bereinigte Anzahl, Zeitraum und Hinweis auf letzte Bereitstellung.
• Ausgabe: technische Notiz mit Routingfeldern, datensparsamen Reproduktionsbedingungen und fehlenden Belegen.
• Menschliche Prüfung: Azure/IT entscheidet über Logs und Rollback; die Einrichtung über Papier und Nachpflege.

Screenshots oder Logs mit Namen betreuter Personen gehen nicht an Claude Code. Der Validator blockiert explizite Identitätsschlüssel, E-Mail-Adressen und Telefonnummern, erkennt aber nicht jeden unbeschrifteten Namen, jedes Bild oder codierte Kennzeichen. Die Sichtprüfung bleibt eine menschliche Freigabe.

Anwendungsfall 3: Betrieb nach Resolved abschließen

• Eingabe: Fixture mit monitorCondition: "Resolved", Verbindungstest, offene Einträge, Dublettenprüfung und Kontaktverlauf.
• Ausgabe: getrennte technische und betriebliche Abschlusschecklisten, Restarbeiten und Frühdienst-Verantwortung.
• Menschliche Prüfung: Azure/IT beendet das Monitoring; die Einrichtung erklärt nach Abgleich die Wiederherstellung.

Im Common Alert Schema bedeutet Resolved, dass die auslösende Bedingung nicht mehr besteht. Papiernachpflege und Rückrufe sind damit nicht bestätigt. Zwei Abschlussbedingungen verhindern, dass technische Erholung betriebliche Arbeit verdeckt.

Direkt ausführbarer Übergabe-Validator

Der folgende Validator nutzt nur Node.js-Standardbibliotheken und liest den angegebenen lokalen JSON-Pfad. Er meldet sich nicht bei Azure an und ruft weder AKS, Azure Monitor noch kubectl auf. Geprüft werden nur die dokumentierte Common-Alert-Schema-Form und der Bereinigungsvertrag dieses Runbooks.

// validate-azure-alert-handoff.mjs
import { readFileSync } from "node:fs";

const REQUIRED = ["severity", "signalType", "monitorCondition", "alertTargetIDs"];
const ALLOWED = {
  severity: new Set(["Sev0", "Sev1", "Sev2", "Sev3", "Sev4"]),
  signalType: new Set(["Metric", "Log", "Activity Log"]),
  monitorCondition: new Set(["Fired", "Resolved"]),
};
const DIRECT_PERSONAL_DATA_KEYS = new Set([
  "residentname", "patientname", "carerecipientname", "serviceusername",
  "staffname", "employeename", "familyname", "guardianname",
  "phone", "phonenumber", "telephone", "mobile",
  "email", "emailaddress", "streetaddress", "postaladdress",
  "dateofbirth", "birthdate", "medicalrecordid", "carerecordid",
  "residentid", "patientid",
]);
const EMAIL = /\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}\b/i;
const PHONE = /(?:^|[^A-Za-z0-9])(?:\+\d{1,3}[ .-]?)?(?:\(\d{2,4}\)|\d{2,4})[ .-]\d{2,4}[ .-]\d{3,4}(?:$|[^A-Za-z0-9])/;
const LABELED_NAME = /(?:resident|patient|care recipient|staff|employee|family|guardian|利用者|入居者|患者|職員|家族)(?:\s+name|氏名|名)\s*[:=：]\s*\S+/iu;
const ARM_RESOURCE_ID_PATH = /^\$\.data\.essentials\.(?:alertId|alertRuleId|alertTargetIDs\[\d+\])$/;

function normalizeKey(key) {
  return key.replace(/[^a-z0-9]/gi, "").toLowerCase();
}

function findDirectPersonalData(value, path = "$", findings = []) {
  if (Array.isArray(value)) {
    value.forEach((item, index) => findDirectPersonalData(item, `${path}[${index}]`, findings));
    return findings;
  }
  if (value && typeof value === "object") {
    for (const [key, child] of Object.entries(value)) {
      const childPath = `${path}.${key}`;
      if (DIRECT_PERSONAL_DATA_KEYS.has(normalizeKey(key))) {
        findings.push(`${childPath} uses a prohibited direct-personal-data key`);
      }
      findDirectPersonalData(child, childPath, findings);
    }
    return findings;
  }
  if (typeof value === "string") {
    if (EMAIL.test(value)) findings.push(`${path} contains an email address`);
    if (!ARM_RESOURCE_ID_PATH.test(path) && PHONE.test(value)) {
      findings.push(`${path} contains a phone number`);
    }
    if (LABELED_NAME.test(value)) findings.push(`${path} contains a labeled person name`);
  }
  return findings;
}

export function validate(payload) {
  const errors = [];
  if (!payload || typeof payload !== "object" || Array.isArray(payload)) {
    throw new Error("payload must be a JSON object");
  }
  if (payload.schemaId !== "azureMonitorCommonAlertSchema") {
    errors.push('schemaId must be "azureMonitorCommonAlertSchema"');
  }

  const essentials = payload.data?.essentials;
  if (!essentials || typeof essentials !== "object" || Array.isArray(essentials)) {
    errors.push("data.essentials must be an object");
  } else {
    for (const field of REQUIRED) {
      if (!(field in essentials)) errors.push(`missing data.essentials.${field}`);
    }
    for (const [field, allowed] of Object.entries(ALLOWED)) {
      if (field in essentials && !allowed.has(essentials[field])) {
        errors.push(`data.essentials.${field} has an undocumented value`);
      }
    }
    if ("alertTargetIDs" in essentials) {
      if (!Array.isArray(essentials.alertTargetIDs) ||
          essentials.alertTargetIDs.length === 0 ||
          essentials.alertTargetIDs.some((id) => typeof id !== "string" || id.trim() === "")) {
        errors.push("data.essentials.alertTargetIDs must be a non-empty string array");
      }
    }
  }

  errors.push(...findDirectPersonalData(payload));
  if (errors.length > 0) throw new Error(errors.join("; "));
  return true;
}

function loadJson(filePath) {
  return JSON.parse(readFileSync(filePath, "utf8"));
}

function runSelfTest() {
  const base = loadJson("sanitized-alert.json");
  validate(base);
  const cases = [
    ["direct personal data", (p) => { p.data.customProperties.residentName = "Example Resident"; }],
    ["missing severity", (p) => { delete p.data.essentials.severity; }],
    ["missing signalType", (p) => { delete p.data.essentials.signalType; }],
    ["missing monitorCondition", (p) => { delete p.data.essentials.monitorCondition; }],
    ["missing alertTargetIDs", (p) => { delete p.data.essentials.alertTargetIDs; }],
  ];
  let rejected = 0;
  for (const [label, mutate] of cases) {
    const candidate = structuredClone(base);
    mutate(candidate);
    try {
      validate(candidate);
      console.error(`FAIL self-test: accepted ${label}`);
      process.exitCode = 1;
    } catch {
      console.log(`PASS self-test: rejected ${label}`);
      rejected += 1;
    }
  }
  if (!process.exitCode) console.log(`PASS self-test: ${rejected} rejection cases`);
}

if (process.argv[2] === "--self-test") {
  runSelfTest();
} else {
  const filePath = process.argv[2];
  if (!filePath) {
    console.error("Usage: node validate-azure-alert-handoff.mjs <fixture.json> | --self-test");
    process.exit(2);
  }
  try {
    validate(loadJson(filePath));
    console.log(`PASS fixture: ${filePath}`);
  } catch (error) {
    console.error(`FAIL fixture: ${error.message}`);
    process.exit(1);
  }
}

Speichern Sie das vollständige Fixture als sanitized-alert.json neben dem Validator. IDs, Zeiten und Regelnamen sind Testdaten, keine gemessenen Incident-Ergebnisse. customProperties ist ein dokumentierter Erweiterungspunkt und macht hier die Bereinigungsaussage sichtbar.

{
  "schemaId": "azureMonitorCommonAlertSchema",
  "data": {
    "essentials": {
      "alertId": "/subscriptions/00000000-0000-4000-8000-000000000000/providers/Microsoft.AlertsManagement/alerts/11111111-1111-4111-8111-111111111111",
      "alertRule": "care-api-availability",
      "alertRuleId": "/subscriptions/00000000-0000-4000-8000-000000000000/resourceGroups/rg-care-prod/providers/microsoft.insights/metricAlerts/care-api-availability",
      "severity": "Sev1",
      "signalType": "Metric",
      "monitorCondition": "Fired",
      "monitoringService": "Platform",
      "alertTargetIDs": [
        "/subscriptions/00000000-0000-4000-8000-000000000000/resourceGroups/rg-care-prod/providers/Microsoft.ContainerService/managedClusters/aks-care-prod"
      ],
      "configurationItems": [
        "aks-care-prod"
      ],
      "originAlertId": "sanitized-night-incident-001",
      "firedDateTime": "2026-07-23T14:40:00Z",
      "description": "The production booking and care-record API crossed its approved availability threshold.",
      "essentialsVersion": "1.0",
      "alertContextVersion": "1.0"
    },
    "alertContext": {
      "properties": null
    },
    "customProperties": {
      "environment": "production",
      "service": "booking-care-api",
      "sanitized": "true",
      "runbook": "night-incident-v1"
    }
  }
}

Führen Sie diese Befehle unverändert mit Node.js 17 oder neuer aus. Der erste liest das gültige Fixture. Der zweite beweist die Ablehnung direkter personenbezogener Daten und jedes der vier fehlenden Pflichtfelder.

node validate-azure-alert-handoff.mjs sanitized-alert.json
node validate-azure-alert-handoff.mjs --self-test

Dies ist die am 23. Juli 2026 mit dem veröffentlichten Code und Fixture erzeugte exakte Ausgabe, keine Schätzung.

PASS fixture: sanitized-alert.json
PASS self-test: rejected direct personal data
PASS self-test: rejected missing severity
PASS self-test: rejected missing signalType
PASS self-test: rejected missing monitorCondition
PASS self-test: rejected missing alertTargetIDs
PASS self-test: 5 rejection cases

Ein Erfolg beweist weder Azure-Konfiguration, echte Warnungszustellung, AKS-Zustand noch Wiederherstellung. Ein Verbindungstest benötigt aktiviertes Common Alert Schema in der Action Group, Empfänger, Zugangsdaten, Netzwerk, Rechte und Testwarnung. Hier wurden keine Zugangsdaten verwendet; getestet wurde nur der dokumentierte Übergabevertrag.

Fallstricke: Ein festes Objekt ist kein Betriebstest

Erster Fehler: Ein eingebettetes Objekt wird validiert und als Implementierung bezeichnet. Datei-Lesen, ungültiges JSON, fehlende Felder und Fehler-Exit laufen nie. Die Korrektur ist ein lokales Fixture mit Erfolgs- und Fehlerbefehlen in jeder Runbook-Prüfung.

Zweiter Fehler: Ein erfolgreicher Validator wird AKS-Verbindungstest genannt. Eingabevertrag und Cloud-Zugriff tragen dann denselben Testnamen. Protokollieren Sie „handoff contract passed“ und trennen Sie Zustellung, Monitoring und AKS-Belege.

Dritter Fehler: Sev0 bis Sev4 werden direkt zu Pflegesicherheitsstufen. Azure-Schweregrad und Einrichtungswirkung sind unterschiedliche Skalen. Genehmigen Sie Schweregrad, Buchung, Dokumentation, Sicherheit und Papierbetrieb separat.

Vierter Fehler: Resolved wird automatisch als Abschluss verteilt. Die Warnungsbedingung kann weg sein, während Einträge fehlen. Die incident ID bleibt bis zu beiden Abschlüssen offen.

Fünfter Fehler: Der Validator gilt als Garantie gegen Personendaten. Muster erkennen nicht jedes Bild, undurchsichtige Kennzeichen oder unbeschriftete Namen. Eingaben minimieren, Freitext und Anhänge prüfen und Informationsregeln anwenden.

ROI mit vergleichbaren Incidents messen

Die ROI-Tabelle entsteht aus incident ID, Zeitstempeln und Arbeitsminuten. Verglichen werden ähnliche Schweregradbereiche, Nachtzeiträume und Auswirkungen. Bei wenigen Fällen werden einzelne Abläufe gezeigt statt einer belastungsschwachen Quote.

Kennzahl	Erfassung	Frage
IT-Übergabezeit	Erste Warnung bis IT ein gültiges Fixture erhält	Wie viel Wartezeit entsteht durch Vertragsfehler?
Auswirkungsbestätigung	Warnung bis Buchung, Einträge und Übergabe freigegeben sind	Wie viele Rückfragen gibt es zwischen Technik und Betrieb?
Fixture-Ablehnungsquote	Fehlgeschlagene Einsendungen ÷ alle Einsendungen	Werden Pflichtfelder und Bereinigung zur Routine?
Annahme beim ersten Versuch	Eskalationen ohne Rückfrage ÷ alle Eskalationen	Reicht die Übergabe zur Untersuchung?
Manuelle Arbeitszeit	Minuten je Rolle für Übertragen, Prüfen und Nacherfassen	Welche Nacht- und Morgenarbeit bleibt?

Für einen Geldwert werden gesparte Minuten mit genehmigten Vollkosten multipliziert, anerkannte vermiedene Nacharbeit addiert und Kosten für Entwurf, Prüfung, Übung und Wartung abgezogen. Der Nettovorteil wird durch die Investition geteilt. Fehlen Basiswert, Zeitraum oder Ausschlüsse, berichten Sie Zeit- und Ablehnungstrends statt ROI.

Häufige Fragen

F. Verbindet sich der Validator mit Azure Monitor oder AKS?

A. Nein. Er liest nur lokales JSON und beweist weder Zustellung noch Zugangsdaten oder Clusterzustand.

F. Warum sind vier essentials-Felder Pflicht?

A. Nächtliches Routing benötigt Schweregrad, Signalart, Zustand und Ziele. Nicht jedes Schemafeld wird privat verpflichtend.

F. Beweist ein Erfolg, dass keine Personendaten enthalten sind?

A. Nein. Explizite Schlüssel, E-Mails, Telefone und beschriftete Namen werden abgelehnt; Bilder und unbeschrifteter Freitext erfordern Prüfung.

F. Soll Claude Code Azure-Änderungen ausführen?

A. Nicht in diesem Runbook. Azure/IT prüft Rechte, Auswirkung, Rollback und Freigabe und nutzt das vorhandene Verfahren.

F. Beweist eine leere Service-Health-Ansicht einen gesunden AKS-Zustand?

A. Nein. Sie zeigt konfigurierte Kriterien und muss mit Anwendung, Workloads, Netzwerk und Monitoring kombiniert werden.

Beratungs-CTA: incident runbook review

Fordern Sie auf der Seite ClaudeCodeLab Schulung und Beratung eine „incident runbook review“ für den nächtlichen Buchungs- oder Pflegedokumentationsablauf an. Das Ergebnis umfasst kommentiertes aktuelles Runbook, Common-Alert-Schema-Übergabevertrag, Entscheidungstabelle für drei Rollen, Testablauf und offene Risiken. Bringen Sie nur ein bereinigtes Warnungsbeispiel, die Kontaktliste und eine aktuelle Zeitleiste ohne Zugangsdaten oder Personendaten mit.

Tatsächlich getestetes Ergebnis

Am 23. Juli 2026 wurden validate-azure-alert-handoff.mjs und sanitized-alert.json in einen temporären Ordner extrahiert und die beiden gezeigten Node.js-Befehle ausgeführt. Das gültige Fixture endete mit Code 0. Der Selbsttest lehnte direkte Personendaten sowie fehlende Werte für severity, signalType, monitorCondition und alertTargetIDs ab, insgesamt fünf Fälle. Repository-Prüfungen decken außerdem frontmatter, interne Links, offizielle URLs, Codeblöcke und den gemeinsamen Slug in zehn Sprachen ab. Es wurden keine Azure-Zugangsdaten genutzt; echter AKS-Zugriff, Action Group und Zustellung bleiben ungetestet. Bereinigen Sie zuerst ein Warnungsbeispiel der Einrichtung und führen Sie diese beiden Befehle als ersten Runbook-Test aus.