Post-Mortem & Incident Runbook: Mengamankan Cron Job di Lingkungan Distributed Kubernetes

1. Alarm Tengah Malam: Saat Layanan Produksi Mulai Tumbang

Pukul 02:43 WIB. Ponsel saya bergetar liar dengan nada alarm prioritas tertinggi dari PagerDuty. Layar menampilkan metrik merah menyala: latensi API gateway melonjak dari 45 milidetik menjadi 4.200 milidetik, error rate HTTP 502 Bad Gateway merangkak naik melewati ambang batas 15%, dan koneksi ke database utama kita, MySQL, hampir kehabisan pool koneksi (Max Connections Reached). Sebagai Principal Systems Architect yang baru saja memejamkan mata dua jam setelah migrasi klaster Kubernetes, malam itu langsung berubah menjadi mimpi buruk infrastruktur.

Masalah ini bermula dari peluncuran fitur penagihan bulanan baru yang ditenagai oleh layanan backend Node.js dan PHP-FPM, yang dipicu secara terjadwal. Di lingkungan server monolitik lama, kita terbiasa menggunakan crontab biasa di sistem operasi Linux yang berjalan damai di satu mesin. Namun, dalam ekosistem Kubernetes modern di mana kita menjalankan 5 replika pod dari deployment backend yang sama, skrip cron tersebut tidak lagi berjalan sendirian. Ia dieksekusi secara serentak oleh setiap pod secara independen pada detik yang sama.

Bayangkan lima kontainer terpisah yang tiba-tiba bersamaan mengeksekusi skrip migrasi data berat, memanggil endpoint API eksternal, dan menulis ribuan record ke database relational. Ini bukan sekadar otomatisasi; ini adalah serangan DDoS internal yang terorganisir rapi oleh scheduler kita sendiri. Dan cerita investigasi ini membawa kita langsung ke dalam tumpukan log mentah yang merekam kekacauan tersebut.

2. Jejak Digital: Menelusuri Anomali Log & Lonjakan Metrik

Dengan mata setengah terbuka, saya membuka terminal dan langsung melompat ke dashboard Grafana dan meluncurkan perintah kubectl untuk mengintip apa yang sedang terjadi di dalam pod backend kita.

# Memeriksa log pod backend yang baru saja restart karena OOMKilled
kubectl logs -n production -l app=billing-backend --tail=100 --prefix=true

Log yang keluar memperlihatkan pemandangan yang mengerikan. Lima pod berbeda mencetak baris yang hampir identik secara persis pada timestamp 02:42:00:

[2026-03-30T02:42:00Z] INFO: Starting monthly invoice generation worker... [2026-03-30T02:42:00Z] ERROR: Database connection pool exhausted. Retrying in 500ms...

[!WARNING] Kubernetes CronJob resource secara default tidak menjamin eksekusi tunggal (single-execution) di lingkungan terdistribusi jika policy concurrencyPolicy tidak diatur secara ketat, atau lebih parahnya, jika penjadwalan dikendalikan langsung oleh kode aplikasi di dalam masing-masing pod.

Di dashboard Prometheus, grafik CPU usage pada database MySQL melompat dari 30% langsung menabrak angka 100%. Tabel transaksi utama terkunci karena kelima instance aplikasi mencoba melakukan operasi INSERT ... ON DUPLICATE KEY UPDATE pada baris data yang sama secara bersamaan. Terjadilah row-level locking contention yang masif, membuat antrean worker Redis membengkak hingga puluhan ribu pesan menumpuk.

Kita butuh solusi cepat untuk memadamkan api ini sebelum pagi menjelang dan jutaan pengguna aktif mulai membuka aplikasi. Akar masalahnya sudah jelas di depan mata, dan saatnya kita membedahnya secara teknis.

3. Membongkar Biang Kerok: Akar Masalah yang Sebenarnya

Mengapa hal ini bisa terjadi? Jawabannya terletak pada kesalahpahaman umum saat memindahkan arsitektur aplikasi tradisional ke dalam orkestrator kontainer seperti Kubernetes.

Secara historis, para developer menanamkan pustaka penjadwal di dalam kode aplikasi web (misalnya menggunakan paket node-cron di Node.js atau Laravel Task Scheduler di PHP). Ketika aplikasi tersebut hanya berjalan di satu VPS atau server fisik, pendekatan ini aman-aman saja. Namun, begitu dideploy ke Kubernetes dengan konfigurasi replicas: 5, arsitektur tersebut berubah menjadi lima buah jam dinding yang diset pada waktu yang sama persis, tanpa ada komunikasi di antara mereka.

Mari kita bandingkan pendekatan arsitektural yang salah versus yang benar:

Untuk mengatasi masalah ini secara permanen, kita tidak bisa hanya mengandalkan konfigurasi YAML Kubernetes semata, melainkan kita harus menerapkan pola Distributed Locking menggunakan Redis sebagai arbiter terpusat sebelum skrip cron mengeksekusi logika bisnis utamanya.

4. Tindakan Darurat: Menghidupkan Kembali Layanan dalam Menit Ini

Sebelum merombak total kode aplikasi, kita harus menghentikan pendarahan di sistem produksi saat ini. Berikut adalah langkah darurat yang saya eksekusi langsung dari terminal untuk meredakan beban klaster dalam waktu kurang dari 60 detik:

# 1. Segera suspend CronJob bermasalah di Kubernetes untuk menghentikan pendarahan baru
kubectl patch cronjob billing-processor -n production -p '{"spec" : {"suspend" : true}}'

# 2. Paksa restart deployment backend untuk membersihkan antrean koneksi database yang menggantung
kubectl rollout restart deployment/billing-backend -n production

# 3. Masuk ke terminal Redis cluster untuk membersihkan kunci lock usang jika ada
redis-cli -h redis.production.svc.cluster.local -a "SuperSecretRedisPassword" FLUSHDB

[!IMPORTANT] Jangan pernah langsung melakukan kubectl delete pada pod yang sedang mengalami beban tinggi karena hal tersebut justru akan memicu Kubernetes untuk menjadwalkan pod pengganti secara instan, yang malah akan menambah lonjakan koneksi baru ke database.

Setelah sistem kembali stabil dan metrik kembali hijau, saatnya kita merancang pertahanan jangka panjang agar insiden serupa tidak pernah terulang kembali melalui implementasi kode yang kokoh.

5. Kebijakan Retrospektif: Menambal Celah agar Tak Pernah Terulang

Untuk memastikan hanya ada satu instance yang mengeksekusi pekerjaan berat tersebut di seluruh klaster Kubernetes, kita mengimplementasikan algoritma Distributed Lock menggunakan Redis (mengadopsi konsep Redlock sederhana dengan SET key value NX PX).

Berikut adalah contoh implementasi kode Node.js yang aman untuk membungkus cron job kita:

const Redis = require('ioredis');
const redis = new Redis(process.env.REDIS_URL);

async function runCronJobWithLock(jobName, taskFunction, ttlMs = 60000) {
    const lockKey = `lock:cron:${jobName}`;
    const lockValue = Math.random().toString(36).substring(7);
    
    // Coba dapatkan kunci eksklusif dengan timeout (NX = Only if Not Exist, PX = Milliseconds expiration)
    const acquired = await redis.set(lockKey, lockValue, 'PX', ttlMs, 'NX');
    
    if (!acquired) {
        console.log(`[Cron] Job ${jobName} sedang dikerjakan oleh pod lain. Melewati eksekusi.`);
        return;
    }

    try {
        console.log(`[Cron] Berhasil mengunci lock untuk ${jobName}. Memulai eksekusi...`);
        await taskFunction();
    } catch (error) {
        console.error(`[Cron] Gagal mengeksekusi job ${jobName}:`, error);
    } finally {
        // Gunakan Lua script untuk memastikan kita hanya menghapus kunci milik kita sendiri
        const luaScript = `
            if redis.call("get", KEYS[1]) == ARGV[1] then
                return redis.call("del", KEYS[1])
            else
                return 0
            end
        `;
        await redis.eval(luaScript, 1, lockKey, lockValue);
        console.log(`[Cron] Lock dilepaskan untuk ${jobName}.`);
    }
}

// Contoh pemanggilan di dalam worker terjadwal
runCronJobWithLock('monthly-billing', async () => {
    // Logika bisnis utama penagihan di sini
    await processInvoices();
});

Dengan pendekatan ini, meskipun Kubernetes menjalankan skrip dari 5 pod berbeda secara bersamaan, hanya pod pertama yang berhasil mendapatkan lock Redis, sementara 4 pod lainnya akan keluar dengan aman tanpa mengganggu basis data.

6. Pasang Alarm: Otomasi Deteksi Dini untuk Tim On-Call

Arsitektur yang tangguh belum lengkap tanpa sistem observabilitas yang proaktif. Kita harus memastikan bahwa jika sebuah cron job gagal mendapatkan lock atau mengalami error saat eksekusi, tim on-call langsung mengetahuinya sebelum pengguna melapor.

Kita memasang aturan Prometheus Alertmanager untuk memantau metrik kegagalan cron:

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: cron-job-alerts
  namespace: production
spec:
  groups:
  - name: CronJobAlerts
    rules:
    - alert: CronJobExecutionFailed
      expr: increase(cron_job_failures_total[5m]) > 0
      for: 0m
      labels:
        severity: critical
      annotations:
        summary: "Cron job gagal dieksekusi di klaster produksi"
        description: "Job {{ $labels.job_name }} mengalami kegagalan beruntun atau gagal mengakuisisi distributed lock Redis."
    - alert: RedisLockContentionHigh
      expr: rate(redis_lock_acquisition_failures_total[5m]) > 2
      for: 2m
      labels:
        severity: warning
      annotations:
        summary: "Lonjakan perebutan Distributed Lock Redis"
        description: "Terlalu banyak pod Kubernetes yang mencoba merebut lock cron secara bersamaan. Periksa konfigurasi replika."

Melalui kombinasi penanganan Distributed Locking berbasis Redis, pembersihan skrip darurat, dan aturan pemantauan yang ketat ini, infrastruktur Kubernetes kita kini jauh lebih tahan banting terhadap ancaman race condition tersembunyi. Tidur malam tim on-call pun kembali tenang, terbebas dari horor lonjakan latensi tengah malam.