Care facility IT lead के लिए AKS night incident runbook

रात 11:40 बजे care facility की night manager का फोन आता है: booking screen खुल रही है, लेकिन care record save नहीं हो रहा. Azure का email मौजूद है, फिर भी handoff में target resource, severity और alert अभी firing है या resolve हो चुका है, यह नहीं लिखा. IT vendor को भेजे जाने वाले draft में resident का नाम भी बचा है. Operations और IT lead को investigation delay और personal data के आगे फैलने, दोनों को रोकना है.

यह लेख उस व्यक्ति के लिए है जो Azure पर facility की booking और care application तथा उसके overnight escalation का उत्तरदायी है. यह frontline care staff का manual नहीं है. लक्ष्य एक ऐसा runbook है जिसमें incident timeline एक रहे, लेकिन facility continuity और AKS technical investigation के निर्णय अलग लोग लें.

Azure Kubernetes Service (AKS), Azure पर container applications deploy और manage करने के लिए managed Kubernetes service है. Kubernetes containers के समूह को schedule, restart और scale करता है; Azure AKS control plane का operational overhead संभालता है. फिर भी Azure facility का business impact तय नहीं करता, हर workload की जांच अपने आप नहीं करता और रात की contact order नहीं बनाता.

मुख्य बातें

• Azure severity को सीधे facility incident level न बनाएं; booking, records, handover और safety impact अलग जांचें.
• Claude Code से पहले Common Alert Schema JSON sanitize करें, फिर required fields और direct personal data को local validator से जांचें.
• Claude Code tasks, Azure/IT operator decisions और care-facility incident decisions अलग रखें.
• Azure credentials के बिना इसे handoff-contract test कहें, AKS या alert-delivery test नहीं.
• ROI के लिए comparable incidents के timestamps, rejection count और role-wise minutes लें; काल्पनिक improvement rate न लिखें.

Night incident को एक handoff कार्यप्रवाह बनाएं

Phone call, Azure notification, affected screen और contact table अलग notes में हों तो 11:40 बजे की घटना के कई version बन जाते हैं. पहली sheet में business facts लिखें: “booking search works”, “care-record save fails”, “paper record active”, और “next update 00:10”. Pod, Node और Deployment state इनके बाद technical evidence के रूप में आए.

Azure Monitor, Microsoft की unified observability service है जो cloud और hybrid environments से metrics, logs, traces और events collect, analyze और action के लिए उपलब्ध करती है. Azure Monitor Common Alert Schema अलग-अलग Azure Monitor alert notifications लेने के लिए standardized JSON structure है. data.essentials में severity जैसी common metadata और data.alertContext में signal-specific investigation context रहता है.

Microsoft Learn के अनुसार severity के values Sev0 से Sev4, signalType के values Metric, Log या Activity Log, और monitorCondition के values Fired या Resolved हैं. alertTargetIDs alert से प्रभावित Azure Resource Manager IDs की list है. ये fields handoff route कर सकते हैं, लेकिन resident safety, paper fallback या facility recovery अपने आप तय नहीं कर सकते.

23 जुलाई 2026 को देखे गए primary sources हैं: AKS क्या है, Azure Monitor overview, Common Alert Schema, AKS monitoring, और Service Health alerts. संबंधित internal सामग्री के लिए Kubernetes deployment guide और Claude Code security checklist देखें.

flowchart TD
  A["Azure Monitor alert मिला"] --> B["Sanitized JSON fixture save करें"]
  B --> C{"Local validator pass हुआ?"}
  C -- "नहीं" --> D["Personal data हटाएं या required fields भरें"]
  D --> B
  C -- "हां" --> E["Claude Code handoff व्यवस्थित करे"]
  E --> F["Azure/IT technical investigation तय करे"]
  E --> G["Care facility continuity तय करे"]
  F --> H["Next update पर evidence जोड़ें"]
  G --> H
  H --> I{"दोनों closure conditions पूरी?"}
  I -- "नहीं" --> H
  I -- "हां" --> J["Post-incident review record करें"]

Service Health configured subscriptions, services, regions और event types से जुड़ी notifications का दूसरा evidence source है. खाली view application health का प्रमाण नहीं है. उसी तरह AKS alert का Resolved होना paper records की re-entry या booking reconciliation पूरा नहीं करता.

Claude Code का काम और मनुष्यों के निर्णय

Handoff table में inputs, outputs, prohibitions और approvers होने चाहिए. Claude Code को recovery owner बनाने पर unsupported diagnosis और change commands एक ही conversation में मिल जाते हैं. यहां वह केवल approved evidence organize करता है.

Claude Code tasks

• पहले से valid fixture से severity, signalType, monitorCondition, alertTargetIDs और timestamps निकालना.
• Confirmed facts, unknowns और pending human decisions अलग करना; missing next-update time बताना.
• एक incident ID के नीचे facility note और IT vendor technical note अलग बनाना.
• Observation commands suggest करना, execute नहीं करना, और required evidence तथा permissions लिखना.

Azure/IT operator decisions

• Alert rule, target, monitoring configuration, recent change और AKS telemetry देखने का क्रम तय करना.
• Azure Portal, Container insights, Log Analytics या authorized terminal से और evidence लेना या नहीं.
• Restart, scaling, rollback और technical escalation approve या reject करना.
• Resolved technical recovery के लिए पर्याप्त है या monitoring जारी रहेगी, यह तय करना.

Care-facility incident decisions

• Booking रोकना, care records paper पर ले जाना या किसी workflow को priority देना.
• Safety checks, handover, later entry और family या external-party communication निर्देशित करना.
• Share की जाने वाली information, अगला internal update और business recovery declaration approve करना.
• Technical recovery के बाद missing records या duplicate bookings कौन reconcile करेगा, यह तय करना.

यह individualized legal advice नहीं है. Personal-data classification, retention, disclosure और incident reporting facility policies, contracts और accountable teams के अनुसार होना चाहिए.

तीन उपयोग के मामले

उपयोग मामला 1: Booking API failure का overnight handoff

• Input: sanitized Common Alert Schema fixture, booking-screen check, incident time और next-update time.
• Output: Azure target IDs और facility impact अलग करने वाली contact sheet, unknowns और vendor request.
• Human review: Azure/IT investigation approve करे; facility lead booking fallback और duplicate check approve करे.

केवल Sev1 होने से सभी booking channels बंद नहीं किए जाते. Read failure और duplicate-write risk के facility actions अलग हैं. Claude Code observed facts और pending approvals अलग करता है, निर्णय नहीं लेता.

उपयोग मामला 2: Care-record save delay को escalate करना

• Input: passing fixture, affected feature, sanitized count, time range और recent release status.
• Output: routing fields वाला technical memo, direct personal data के बिना reproduction conditions, missing evidence.
• Human review: Azure/IT logs और rollback तय करे; facility lead paper records और later reconciliation संभाले.

Resident name वाली screenshot या log Claude Code को न दें. Validator explicit identity keys, emails और phone numbers रोकता है, पर हर unlabeled name, image या encoded identifier नहीं पहचानता. Visual review human approval में रहे.

उपयोग मामला 3: Resolved के बाद business recovery बंद करना

• Input: monitorCondition: "Resolved" fixture, connectivity check, outstanding records, duplicate booking check और contact history.
• Output: अलग technical और business closure checklists, remaining work और morning owner.
• Human review: Azure/IT monitoring close करे; facility lead records और bookings reconcile होने पर business recovery घोषित करे.

Common Alert Schema में Resolved का अर्थ alert trigger करने वाली condition का clear होना है. इसका अर्थ paper data entry या callbacks पूरा होना नहीं है. दो closure conditions technical recovery के पीछे operational work छिपने से रोकती हैं.

कॉपी-पेस्ट करके चलने वाला हस्तांतरण validator

नीचे का validator केवल Node.js standard library इस्तेमाल करता है और command line में दिया local JSON path पढ़ता है. यह Azure में sign in नहीं करता और AKS, Azure Monitor या kubectl call नहीं करता. यह documented Common Alert Schema shape और इस runbook का sanitization contract ही test करता है.

// 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);
  }
}

पूरा fixture sanitized-alert.json नाम से validator के साथ save करें. IDs, timestamps और rule names test data हैं, actual incident result नहीं. customProperties documented extension point है; यहां reviewer के लिए sanitization assertion दिखाता है.

{
  "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"
    }
  }
}

Node.js 17 या बाद के version में ये exact commands चलाएं. पहला valid fixture पढ़ता है. दूसरा साबित करता है कि direct personal data और चारों required fields की अलग-अलग कमी reject होती है.

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

यह expected output नहीं, 23 जुलाई 2026 को published code और fixture से मिला exact output है.

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

Pass होने से Azure configuration, real alert delivery, AKS health या recovery procedure प्रमाणित नहीं होते. Connected test के लिए Action Group पर Common Alert Schema enabled होना, receiver, Azure credentials, network, permissions और test alert चाहिए. यहां credentials नहीं थे, इसलिए केवल documented handoff contract test हुआ.

जोखिम: Fixed object pass को operations test न कहें

पहली गलती script में embedded object validate करके implementation complete कहना है. File reading, malformed JSON, missing fields और rejection exit कभी नहीं चलते. सुधार यह है कि हर runbook review में local fixture पढ़ें और success तथा failure दोनों commands चलाएं.

दूसरी गलती validator success को AKS connectivity test कहना है. Input contract और cloud access को एक test name देना इसका कारण है. Result को “handoff contract passed” लिखें और delivery, monitoring तथा AKS evidence अलग रखें.

तीसरी गलती Sev0 से Sev4 को सीधे care-safety levels बनाना है. Azure severity और facility impact अलग scales हैं. Azure severity, booking impact, record impact, resident safety और paper fallback अलग approve करें.

चौथी गलती Resolved को automatic incident closure भेजना है. Alert condition clear हो सकती है, पर missing records बाकी रह सकते हैं. Technical और facility closure पूरा होने तक incident ID खुला रखें.

पांचवीं गलती validator को personal-data guarantee समझना है. Key और text patterns हर image, opaque identifier या unlabeled name नहीं पहचानते. Input कम रखें, free text तथा attachments human review से गुजारें और facility governance लागू करें.

Comparable incidents से ROI मापें

ROI table incident ID, timestamps और labor minutes से बनाएं. समान severity band, overnight window और impact scope वाले incidents compare करें. घटनाएं कम हों तो rate claim करने के बजाय हर timeline दिखाएं.

Metric	Record करने का तरीका	सवाल
IT handoff time	First alert से IT को passing fixture मिलने तक	Contract defects से कितनी waiting हुई?
Impact confirmation time	Alert से booking, records और handover scope approval तक	Technical और operational teams में कितने rounds हुए?
Fixture rejection rate	Failed validator submissions ÷ all submissions	Required fields और sanitization routine बने?
First-pass escalation acceptance	बिना clarification शुरू cases ÷ all escalations	Handoff investigation के लिए पूरा है?
Manual labor time	Transcription, checks और re-entry के role-wise minutes	रात और सुबह कितना work बाकी है?

Financial value के लिए saved minutes को facility-approved loaded labor rates से multiply करें, approved avoided rework जोड़ें और runbook design, review, exercise तथा maintenance cost घटाएं. Net benefit को investment cost से divide करें. Baseline, period और exclusions न हों तो time और rejection trends report करें, उसे ROI न कहें.

अक्सर पूछे जाने वाले सवाल

Q. क्या validator Azure Monitor या AKS से connect होता है?

A. नहीं. यह local JSON पढ़ता है और delivery, credentials या cluster state प्रमाणित नहीं करता.

Q. चार essentials fields required क्यों हैं?

A. Overnight routing के लिए severity, signal type, firing/resolved state और targets चाहिए. Schema के हर field को private mandatory field नहीं बनाया गया.

Q. Pass होने से personal data न होने का प्रमाण मिलता है?

A. नहीं. Explicit keys, emails, phones और labeled names reject होते हैं; images और unlabeled free text human review मांगते हैं.

Q. क्या Claude Code Azure change commands चलाए?

A. इस runbook में नहीं. Azure/IT permissions, impact, rollback और approval review करके existing change procedure चलाए.

Q. खाली Service Health view से AKS healthy साबित होता है?

A. नहीं. वह configured criteria दिखाता है; application, workload, network और monitoring evidence भी चाहिए.

परामर्श का अगला कदम: रात्रि incident runbook समीक्षा

ClaudeCodeLab training और consultation पर overnight booking या care-record workflow के लिए “incident runbook review” मांगें. Deliverable में current runbook comments, Common Alert Schema handoff contract, तीन-role decision table, test procedure और unresolved-risk list शामिल हैं. केवल sanitized alert example, contact table और एक recent timeline लाएं; credentials और personal data हटाएं.

वास्तव में test किया गया परिणाम

23 जुलाई 2026 को published validate-azure-alert-handoff.mjs और sanitized-alert.json temporary folder में निकाले गए और दिखाए गए दोनों Node.js commands चलाए गए. Valid fixture exit code 0 से pass हुआ. Self-test ने direct personal data तथा missing severity, signalType, monitorCondition, alertTargetIDs सहित पांच rejection cases रोके. Repository checks frontmatter, internal links, official URLs, code fences और दस locales का shared slug भी देखते हैं. Azure credentials इस्तेमाल नहीं हुए, इसलिए real AKS access, Action Group configuration और alert delivery untested हैं. अगला कदम facility के एक alert example को sanitize करके इन दोनों commands को runbook review की पहली check बनाना है.