Runbook Insiden Malam AKS untuk Pemimpin TI Fasilitas Perawatan

Pukul 23.40, penanggung jawab malam menelepon: layar pemesanan fasilitas perawatan bisa dibuka, tetapi catatan perawatan gagal disimpan. Email Azure sudah ada, namun handoff tidak mencantumkan resource target, severity, atau apakah alert masih aktif. Draf eskalasi ke vendor TI bahkan memuat nama penghuni. Pemimpin operasi dan TI harus menghentikan keterlambatan investigasi sekaligus penyebaran lanjutan data pribadi.

Artikel ini ditujukan kepada orang yang bertanggung jawab atas aplikasi pemesanan dan perawatan fasilitas di Azure, termasuk rancangan eskalasi malamnya. Ini bukan panduan bagi staf perawatan lini depan. Tujuannya adalah satu runbook dengan timeline incident yang sama, tetapi keputusan kelangsungan operasional dipisahkan dari investigasi AKS.

Azure Kubernetes Service (AKS) adalah layanan Kubernetes terkelola di Azure untuk men-deploy dan mengelola aplikasi dalam container. Kubernetes menjadwalkan, memulai ulang, dan melakukan scaling kelompok container; Azure menangani beban operasi control plane AKS. Namun, Azure tidak menentukan dampak bisnis fasilitas, tidak menyelidiki setiap workload secara otomatis, dan tidak menyusun urutan kontak malam.

Poin utama

• Jangan langsung mengubah severity Azure menjadi level insiden fasilitas; nilai dampak pemesanan, catatan, handover, dan keselamatan secara terpisah.
• Sebelum Claude Code membaca data, sanitasi JSON Common Alert Schema lalu validasi field wajib dan data pribadi langsung secara lokal.
• Pisahkan tugas Claude Code, keputusan operator Azure/TI, dan keputusan penanggung jawab insiden fasilitas.
• Tanpa kredensial Azure, sebut hasil ini tes kontrak handoff, bukan tes AKS atau pengiriman alert.
• Ukur ROI dari timestamp, penolakan, dan menit kerja insiden yang sebanding, tanpa persentase rekaan.

Menjadikan insiden malam satu alur kerja handoff

Telepon, notifikasi Azure, layar terdampak, dan tabel kontak akan menghasilkan cerita berbeda jika berada di catatan terpisah. Tabel pertama harus berisi fakta bisnis: “pencarian pemesanan berfungsi”, “penyimpanan catatan gagal”, “pencatatan kertas aktif”, dan “pembaruan berikutnya 00.10”. Status Pod, Node, dan Deployment ditempatkan sesudahnya sebagai bukti teknis.

Azure Monitor adalah layanan observabilitas terpadu Microsoft untuk mengumpulkan, menganalisis, dan menindaklanjuti metrik, log, trace, dan event dari lingkungan cloud serta hybrid. Azure Monitor Common Alert Schema, atau skema alert umum, adalah struktur JSON standar untuk menerima berbagai notifikasi Azure Monitor. data.essentials berisi metadata umum seperti severity, sedangkan data.alertContext berubah sesuai jenis sinyal dan mendukung investigasi.

Microsoft Learn mendokumentasikan nilai severity dari Sev0 sampai Sev4, signalType sebagai Metric, Log, atau Activity Log, serta monitorCondition sebagai Fired atau Resolved. alertTargetIDs adalah daftar ID Azure Resource Manager yang menjadi target. Field ini membantu routing handoff, tetapi tidak menentukan keselamatan penghuni, fallback kertas, atau deklarasi pemulihan fasilitas.

Sumber primer yang diverifikasi pada 23 Juli 2026 adalah Apa itu AKS, Gambaran umum Azure Monitor, Common Alert Schema, Memantau AKS, dan Alert Service Health. Bahan internal terkait tersedia di panduan deployment Kubernetes dan checklist keamanan Claude Code.

flowchart TD
  A["Terima alert Azure Monitor"] --> B["Simpan fixture JSON yang disanitasi"]
  B --> C{"Validator lokal lulus?"}
  C -- "Tidak" --> D["Hapus data pribadi atau lengkapi field"]
  D --> B
  C -- "Ya" --> E["Claude Code merapikan handoff"]
  E --> F["Azure/TI memutuskan investigasi teknis"]
  E --> G["Fasilitas memutuskan kelangsungan operasi"]
  F --> H["Gabungkan bukti pada pembaruan berikutnya"]
  G --> H
  H --> I{"Dua syarat penutupan terpenuhi?"}
  I -- "Tidak" --> H
  I -- "Ya" --> J["Catat review pascainsiden"]

Service Health adalah sumber bukti lain untuk notifikasi yang cocok dengan subscription, layanan, region, dan jenis event yang dikonfigurasi. Tampilan kosong tidak membuktikan aplikasi sehat. Demikian pula, alert AKS berstatus Resolved tidak menyelesaikan input ulang catatan kertas atau pemeriksaan pemesanan.

Yang ditangani Claude Code dan yang diputuskan manusia

Tabel handoff harus menyebut input, output, larangan, dan pemberi persetujuan. Menjadikan Claude Code pemilik pemulihan akan mencampur diagnosis tanpa bukti dan perintah perubahan dalam percakapan yang sama. Di sini perannya hanya menata bukti yang sudah disetujui.

Tugas Claude Code

• Mengekstrak severity, signalType, monitorCondition, alertTargetIDs, dan waktu dari fixture yang sudah lulus.
• Memisahkan fakta terkonfirmasi, hal yang belum diketahui, dan keputusan manusia yang tertunda; menandai waktu pembaruan yang hilang.
• Menyusun catatan fasilitas dan catatan teknis vendor secara terpisah di bawah incident ID yang sama.
• Menyarankan perintah observasi tanpa menjalankannya serta menulis bukti dan izin yang diperlukan.

Keputusan operator Azure/TI

• Menentukan urutan pemeriksaan alert rule, target, konfigurasi monitoring, perubahan terbaru, dan telemetri AKS.
• Memutuskan pengambilan bukti tambahan melalui Azure Portal, Container insights, Log Analytics, atau terminal berizin.
• Menyetujui atau menolak restart, scaling, rollback, dan eskalasi teknis.
• Menentukan apakah Resolved cukup sebagai bukti pemulihan teknis atau monitoring dilanjutkan.

Keputusan penanggung jawab insiden fasilitas

• Menghentikan pemesanan, beralih ke catatan kertas, atau memprioritaskan alur perawatan tertentu.
• Mengarahkan pemeriksaan keselamatan, handover, input susulan, dan komunikasi dengan keluarga atau pihak luar.
• Menyetujui informasi yang boleh dibagikan, pembaruan internal berikutnya, dan deklarasi pemulihan bisnis.
• Menetapkan siapa yang merekonsiliasi catatan hilang atau pemesanan ganda setelah pemulihan teknis.

Ini bukan nasihat hukum individual. Klasifikasi, retensi, pengungkapan, dan pelaporan data pribadi harus mengikuti kebijakan, kontrak, serta fungsi yang bertanggung jawab di fasilitas.

Tiga kasus penggunaan

Kasus penggunaan 1: Handoff kegagalan API pemesanan pada malam hari

• Input: fixture Common Alert Schema tersanitasi, pemeriksaan layar, waktu incident, dan waktu pembaruan berikutnya.
• Output: satu lembar yang memisahkan ID target Azure dari dampak fasilitas, hal belum diketahui, dan permintaan vendor.
• Review manusia: Azure/TI menyetujui investigasi; fasilitas menyetujui kanal cadangan dan pemeriksaan duplikasi.

Sev1 saja tidak membenarkan penutupan semua kanal pemesanan. Kegagalan baca dan risiko penulisan ganda memerlukan tindakan berbeda. Claude Code memisahkan observasi dari persetujuan yang tertunda, bukan mengambil keputusan.

Kasus penggunaan 2: Eskalasi keterlambatan penyimpanan catatan

• Input: fixture yang lulus, fitur terdampak, jumlah tersanitasi, rentang waktu, dan status release terbaru.
• Output: memo teknis dengan field routing, kondisi reproduksi tanpa data langsung, dan daftar bukti kurang.
• Review manusia: Azure/TI memutuskan log dan rollback; fasilitas menangani kertas dan rekonsiliasi.

Jangan kirim screenshot atau log yang memuat nama penghuni ke Claude Code. Validator memblokir key identitas eksplisit, email, dan nomor telepon, tetapi tidak mengenali setiap nama tanpa label, gambar, atau identifier terenkode. Review visual tetap menjadi persetujuan manusia.

Kasus penggunaan 3: Menutup pemulihan bisnis setelah Resolved

• Input: fixture dengan monitorCondition: "Resolved", pemeriksaan koneksi, catatan tertunda, duplikasi, dan riwayat kontak.
• Output: checklist penutupan teknis dan bisnis yang terpisah, pekerjaan tersisa, dan penanggung jawab pagi.
• Review manusia: Azure/TI menutup monitoring; fasilitas mendeklarasikan pemulihan setelah rekonsiliasi.

Dalam Common Alert Schema, Resolved berarti kondisi yang memicu alert sudah hilang. Status itu tidak mengonfirmasi input catatan kertas atau selesainya panggilan balik. Dua syarat penutupan mencegah pemulihan teknis menyembunyikan pekerjaan operasional.

Validator handoff siap salin dan jalankan

Validator berikut hanya menggunakan pustaka standar Node.js dan membaca path JSON lokal dari command line. Kode tidak login ke Azure dan tidak memanggil AKS, Azure Monitor, atau kubectl. Yang diuji hanya bentuk Common Alert Schema terdokumentasi dan kontrak sanitasi runbook ini.

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

Simpan fixture lengkap sebagai sanitized-alert.json di samping validator. ID, waktu, dan nama rule adalah data uji, bukan hasil incident nyata. customProperties adalah titik ekstensi yang didokumentasikan; di sini field tersebut membuat pernyataan sanitasi terlihat oleh reviewer.

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

Jalankan perintah persis berikut dengan Node.js 17 atau yang lebih baru. Perintah pertama membaca fixture valid. Perintah kedua membuktikan penolakan data pribadi langsung dan masing-masing dari empat field wajib yang hilang.

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

Berikut output persis dari kode dan fixture yang diterbitkan pada 23 Juli 2026, bukan perkiraan.

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

Kelulusan tidak membuktikan konfigurasi Azure, pengiriman nyata, kesehatan AKS, atau prosedur pemulihan. Tes terhubung memerlukan Common Alert Schema aktif pada Action Group, receiver, kredensial, jaringan, izin, dan alert uji. Tidak ada kredensial yang digunakan di sini; hanya kontrak handoff terdokumentasi yang diuji.

Jebakan: objek tetap bukan tes operasional

Kesalahan pertama adalah memvalidasi objek yang tertanam di script lalu mengklaim implementasi selesai. Pembacaan file, JSON rusak, field hilang, dan exit penolakan tidak pernah diuji. Perbaikannya adalah membaca fixture lokal dan menjalankan kasus sukses serta gagal dalam setiap review runbook.

Kesalahan kedua adalah menyebut validator lulus sebagai tes konektivitas AKS. Penyebabnya penggunaan satu nama untuk kontrak input dan akses cloud. Catat “handoff contract passed” lalu pisahkan bukti delivery, monitoring, dan AKS.

Kesalahan ketiga adalah memetakan Sev0 sampai Sev4 langsung ke tingkat keselamatan perawatan. Severity Azure dan dampak fasilitas adalah skala berbeda. Setujui severity, dampak pemesanan, dampak catatan, keselamatan, dan fallback kertas secara terpisah.

Kesalahan keempat adalah mengumumkan Resolved otomatis sebagai penutupan. Kondisi alert bisa hilang ketika catatan masih tertunda. Biarkan incident ID terbuka sampai penutupan teknis dan fasilitas selesai.

Kesalahan kelima adalah memakai validator sebagai jaminan bebas data pribadi. Pola tidak menemukan semua gambar, identifier buram, atau nama tanpa label. Minimalkan input, review teks bebas dan lampiran, lalu ikuti tata kelola informasi fasilitas.

Mengukur ROI dari insiden yang sebanding

Buat tabel ROI dari incident ID, timestamp, dan menit kerja. Bandingkan rentang severity, waktu malam, dan cakupan dampak yang serupa. Jika kasus sedikit, tampilkan timeline individual alih-alih mengklaim sebuah rasio.

Metrik	Cara mencatat	Pertanyaan
Waktu handoff TI	Alert pertama sampai TI menerima fixture valid	Berapa waktu tunggu akibat cacat kontrak?
Waktu konfirmasi dampak	Alert sampai cakupan pemesanan, catatan, dan handover disetujui	Berapa banyak bolak-balik teknis dan operasi?
Rasio penolakan fixture	Submission gagal ÷ seluruh submission	Apakah field dan sanitasi menjadi kebiasaan?
Penerimaan eskalasi pertama	Kasus dimulai tanpa pertanyaan ÷ seluruh kasus	Apakah handoff cukup untuk investigasi?
Waktu kerja manual	Menit per peran untuk menyalin, memeriksa, dan input ulang	Pekerjaan malam dan pagi apa yang tersisa?

Untuk nilai finansial, kalikan menit yang dihemat dengan biaya tenaga kerja penuh yang disetujui, tambahkan rework terhindar yang diakui, lalu kurangi biaya desain, review, latihan, dan pemeliharaan. Bagi manfaat bersih dengan investasi. Tanpa baseline, periode, dan pengecualian, laporkan tren waktu dan penolakan tanpa menyebutnya ROI.

Pertanyaan umum

T. Apakah validator ini terhubung ke Azure Monitor atau AKS?

J. Tidak. Ia hanya membaca JSON lokal dan tidak membuktikan delivery, kredensial, atau status cluster.

T. Mengapa empat field essentials wajib?

J. Routing malam memerlukan severity, jenis sinyal, status aktif atau selesai, dan target. Tidak semua field schema dijadikan wajib.

T. Apakah lulus membuktikan tidak ada data pribadi?

J. Tidak. Key eksplisit, email, telepon, dan nama berlabel ditolak; gambar dan teks tanpa label tetap perlu review manusia.

T. Haruskah Claude Code menjalankan perubahan Azure?

J. Tidak dalam runbook ini. Azure/TI memeriksa izin, dampak, rollback, dan persetujuan, lalu memakai prosedur perubahan yang ada.

T. Apakah Service Health kosong membuktikan AKS sehat?

J. Tidak. Ia mencerminkan kriteria konfigurasi dan harus digabung dengan bukti aplikasi, workload, jaringan, dan monitoring.

CTA konsultasi: incident runbook review

Di halaman pelatihan dan konsultasi ClaudeCodeLab, minta “incident runbook review” untuk alur malam pemesanan atau catatan perawatan. Hasilnya adalah komentar pada runbook saat ini, kontrak handoff Common Alert Schema, tabel keputusan tiga peran, prosedur tes, dan daftar risiko tersisa. Bawa hanya contoh alert tersanitasi, tabel kontak, dan satu timeline terbaru tanpa kredensial atau data pribadi.

Hasil yang benar-benar diuji

Pada 23 Juli 2026, validate-azure-alert-handoff.mjs dan sanitized-alert.json yang diterbitkan diekstrak ke folder sementara, lalu dua perintah Node.js yang ditampilkan dijalankan. Fixture valid selesai dengan exit code 0. Self-test menolak data pribadi langsung serta ketiadaan severity, signalType, monitorCondition, dan alertTargetIDs, total lima kasus. Pemeriksaan repository juga mencakup frontmatter, link internal, URL resmi, code fence, dan slug yang sama pada sepuluh bahasa. Kredensial Azure tidak digunakan, sehingga akses AKS nyata, Action Group, dan delivery alert belum diuji. Mulailah dengan menyusun satu contoh alert fasilitas yang tersanitasi lalu jalankan dua perintah ini sebagai pemeriksaan pertama.