Observabilitas, Rollback, dan Tindakan Insiden untuk Deployment Bun haruslah konkret: terukur data operasional, trigger rollback yang dapat dipercaya, serta langkah pasca-insiden yang bisa langsung dijalankan. Artikel ini menjelaskan cara menggabungkan metrik dan log, health check berbasis otomatisasi rollback, mitigasi lewat feature flag, serta checklist postmortem untuk pipeline Bun.

1. Observabilitas sebagai Dasar Diagnostik

Fokus utama observabilitas adalah menjawab: apa yang sedang terjadi di deployment Bun dan bagaimana saya tahu sesuatu tidak normal? Untuk itu, gabungkan metrik utama dan log terstruktur sebelum proses deploy.

Metrik yang wajib dimonitor

  • Latency permintaan (p50/p95/p99) di endpoint utama.
  • Error rate berdasarkan status HTTP >=500.
  • Resource usage Bun worker (CPU, heap, event loop delay).
  • Health check success ratio setelah deploy, karena inilah pemicu rollback.

Contoh integrasi sederhana menggunakan ekspor Prometheus dari middleware Bun:

import { Histogram, register } from 'prom-client';
import { serve } from 'bun';

const latencyHistogram = new Histogram({
  name: 'bun_request_latency_seconds',
  help: 'Latency request Bun',
  buckets: [0.01, 0.05, 0.2, 0.5, 1]
});

serve({
  fetch(req) {
    const start = process.hrtime();
    return handleRequest(req).finally(() => {
      const elapsed = process.hrtime(start);
      latencyHistogram.observe(elapsed[0] + elapsed[1] / 1e9);
    });
  },
  port: 3000
});

serve({
  fetch: (_, res) => handlerMetrics(req, res),
  port: 9091
});

Endpoint /metrics dapat dijangkau Prometheus untuk alerting. Jangan lupa menyertakan log terstruktur JSON dengan field seperti request_id, duration_ms, dan status, sehingga tool log seperti Loki bisa langsung mengelompokkan insiden.

Monitoring log yang mencerminkan fungsi internal

Gunakan middleware logging sederhana di Bun untuk menyisipkan konteks:

function logRequest(req, res, next) {
  const context = {
    timestamp: new Date().toISOString(),
    path: req.url,
    method: req.method,
    request_id: req.headers.get('x-request-id') ?? crypto.randomUUID()
  };
  console.log(JSON.stringify({ ...context, message: 'request-start' }));
  return next().finally(() => {
    console.log(JSON.stringify({ ...context, status: res.status, message: 'request-end' }));
  });
}

Log ini memudahkan korelasi antara alert Prometheus dengan jejak log dalam Dashboards.

2. Mekanisme Rollback Berbasis Health Check

Rollback otomatis paling efektif jika berbasis kriteria health check yang dijalankan setelah deploy selesai. Pipeline CI/CD (misal GitHub Actions) harus menunggu pelaporan health check lalu memutuskan melanjutkan atau rollback.

Contoh skrip health check

import fetch from 'node-fetch';

async function checkHealth(url) {
  const resp = await fetch(url);
  if (!resp.ok) throw new Error(`Health check gagal ${resp.status}`);
  const body = await resp.json();
  if (!body.ready || body.errors > 0) throw new Error('Health check returned unhealthy');
}

await checkHealth('https://app.example.com/health');

Pipeline dapat memanggil skrip ini lima kali secara berkala. Jika salah satu gagal, jalankan rollback otomatis menukar versi deployment dan kembali ke release stabil (misal menggunakan kubectl rollout undo atau mengganti Git ref di CD).

Gunakan pendekatan promotion gate pada pipeline:

  1. Deploy ke lingkungan staging.
  2. Jalankan health check + metrik (latency, error rate, heap).
  3. Jika semua normal, promosikan ke production.
  4. Jika health check gagal, otomatis rollback dan kirim notifikasi.

Rollback jarang berhasil tanpa observabilitas—pastikan pipeline menyimpan log hasil health check dan snapshot metrik agar tim bisa analisis root cause.

3. Penggunaan Feature Flag sebagai Mitigasi

Feature flag membantu tim menonaktifkan fungsi bermasalah tanpa rollback seluruh release. Di pipeline Bun, gunakan flag di konfigurasi runtime atau sistem distribusi seperti LaunchDarkly, Unleash, atau alternatif self-hosted.

Prinsipnya:

  • Setiap fitur baru di-build behind flag.
  • Deploy selalu dalam keadaan flag off untuk stabilitas.
  • Secara bertahap nyalakan flag di subset pengguna/region.

Jika metrik error spike setelah menyalakan flag, tim cukup mematikan flag, logika utama tetap berjalan, dan deploy tidak perlu rollback.

Pastikan konfigurasi flag diuji di pipeline, misalnya membuat deploy pipeline step yang mengubah flag state lewat API dan memverifikasi respons. Ini mencegah flag stuck di state yang tidak diinginkan.

4. Pencegahan Tambahan: Canary Deployment dan Runbook Cepat

Canary deployment mengurangi risiko dengan hanya menempatkan versi baru ke subset pod/pod server. Hal ini memungkinkan metrik early warning sebelum meluas ke seluruh cluster.

Strategi canary:

  • Deploy versi baru hanya ke 10% trafik.
  • Monitor error rate dan latensi khusus canary.
  • Jika indikator sehat, naikkan secara bertahap.
  • Jika tidak, hentikan promosi dan rollback canary saja.

Perkuat dengan runbook cepat untuk insiden ringan. Contoh runbook:

  • Langkah 1: Cek status health check pipeline.
  • Langkah 2: Konfirmasi apakah feature flag yang baru aktif.
  • Langkah 3: Lihat log error paling atas di observability dashboard.
  • Langkah 4: Jika semua gagal, lakukan rollback otomatis atau manual sesuai prosedur.

5. Checklist Postmortem Tim DevOps Bun

Setelah insiden resolved, postmortem harus singkat namun mencakup akar penyebab dan tindakan preventif. Checklist sederhana:

  1. Deskripsi insiden: apa yang terjadi, kapan, siapa yang terlibat.
  2. Signal deteksi: alert mana yang memicu respon.
  3. Timeline: langkah-langkah yang diambil sampai rollback berhasil.
  4. Root cause: misconfig atau bug apa yang menyebabkan kegagalan.
  5. Tindakan mitigasi: update pipeline, instrumentation, atau runbook.
  6. Lessons learned: apakah feature flag, observability, ataupun canary deployment membantu atau perlu diperbaiki.

Dokumentasikan hasilnya dalam repository tim atau wiki agar referensi tersedia di masa depan.

Kesimpulan

Pipeline deployment Bun yang handal menggabungkan observabilitas terukur, rollback otomatis berdasarkan health check, mitigasi melalui feature flag, strategi canary, serta runbook plus checklist postmortem yang jelas. Dengan mengimplementasikan kombinasi ini, tim DevOps Bun dapat bereaksi cepat terhadap insiden sekaligus memahami akar masalah untuk perbaikan berkelanjutan.