Runbook deploy & rollback saat upgrade server pakai hardware campuran perlu dirancang berbeda dari rollout biasa. Masalah utamanya bukan hanya apakah aplikasi dapat berjalan, tetapi apakah performa, latensi, error rate, dan stabilitas akan berubah diam-diam karena karakteristik server baru tidak identik dengan pool lama.

Dalam lingkungan yang memakai hardware campuran atau komponen lama yang dipakai ulang, risiko terbesar biasanya datang dari drift performa, perbedaan jalur I/O, variasi memori, NUMA behavior, firmware, serta kompatibilitas driver dan kernel. Karena itu, deployment aman harus berbasis canary per pool server, observability yang memisahkan metrik berdasarkan kelas hardware, dan rollback yang bisa dipicu cepat tanpa menunggu outage penuh.

Masalah utama pada upgrade server dengan hardware campuran

Pada infrastruktur homogen, asumsi umum adalah satu node mewakili node lain. Asumsi ini tidak berlaku ketika sebagian server memakai komponen berbeda, komponen lama yang dipakai ulang, atau kombinasi board, memori, storage, dan NIC yang tidak identik.

Yang sering terjadi adalah aplikasi secara fungsional tetap sehat, tetapi kualitas layanannya berubah:

  • Latency tail memburuk pada p95/p99 walau median masih stabil.
  • GC, page fault, atau memory pressure naik hanya pada pool tertentu.
  • Disk I/O wait meningkat karena jalur storage berbeda.
  • Packet loss, retransmit, atau NIC queue issue muncul hanya di node baru.
  • Throughput per core turun karena karakteristik CPU atau memory subsystem berbeda.
  • Incident intermiten sulit direproduksi karena hanya muncul pada subset server.

Karena itu, rollout tidak boleh diperlakukan sebagai satu event global. Yang lebih aman adalah menganggap tiap kombinasi hardware sebagai risk domain tersendiri.

Prinsip desain rollout yang aman

1. Kelompokkan server berdasarkan pool hardware

Jangan hanya membedakan server berdasarkan region atau role aplikasi. Tambahkan pengelompokan berdasarkan karakteristik yang relevan terhadap performa dan kompatibilitas, misalnya:

  • Generasi CPU atau family tertentu
  • Tipe/kapasitas memori atau modul hasil reuse
  • Jenis storage
  • Tipe NIC
  • Firmware/BIOS baseline
  • Kernel, driver, atau image host

Secara praktis, setiap node sebaiknya memiliki label seperti:

hardware.pool=legacy-ram-bridge
hardware.cpu_class=genA
hardware.storage_class=nvme-v1
hardware.nic_class=25g-a
host.image=baseline-2026-07

Label ini penting agar metrik, alert, dan keputusan rollout bisa dipisahkan per pool, bukan tercampur secara global.

2. Pisahkan risiko software dan risiko hardware

Jika Anda mendorong versi aplikasi baru bersamaan dengan masuknya server hardware campuran, diagnosis akan sulit. Idealnya, lakukan salah satu dari dua pola berikut:

  1. Masukkan hardware baru dengan software lama lebih dulu untuk memvalidasi stabilitas platform.
  2. Deploy software baru ke hardware lama lebih dulu untuk memvalidasi aplikasi.

Bila keduanya harus berjalan bersamaan, canary harus dibagi dua dimensi: versi aplikasi dan pool hardware.

3. Hindari rollout serentak lintas pool

Rollback lebih mudah jika blast radius kecil. Praktiknya:

  • Canary 1-2 node per pool
  • Naik ke persentase kecil traffic per pool
  • Tahan observasi lebih lama pada pool berisiko tinggi
  • Promosi pool satu per satu, bukan seluruh fleet sekaligus

Tujuannya bukan rollout tercepat, tetapi rollback termurah saat ada sinyal buruk.

Desain canary per pool server

Canary yang baik harus mampu menjawab dua pertanyaan:

  1. Apakah versi aplikasi ini aman?
  2. Apakah aman jika berjalan di pool hardware tertentu?

Strategi canary yang direkomendasikan

  • Baseline pool lama: versi lama di hardware lama.
  • Control on new pool: versi lama di hardware campuran.
  • Experiment on old pool: versi baru di hardware lama.
  • Experiment on new pool: versi baru di hardware campuran.

Dengan pembagian ini, Anda bisa membedakan apakah masalah muncul karena software, hardware, atau interaksi keduanya.

Contoh tahapan rollout

  1. Tambahkan 1 node dari pool hardware campuran ke environment produksi dengan versi aplikasi lama.
  2. Bandingkan metrik node itu terhadap baseline pool lama.
  3. Jika stabil, deploy versi aplikasi baru ke 1 node pada pool lama dan 1 node pada pool campuran.
  4. Routing traffic kecil dan terkontrol, misalnya hanya sebagian request non-kritis atau subset shard.
  5. Tunggu jendela observasi yang cukup untuk melihat pola latensi tail, error, dan pressure sistem.
  6. Naikkan kapasitas per pool secara bertahap.

Untuk layanan stateful seperti database, cache, atau queue worker, canary harus lebih konservatif. Jangan langsung menjadikan node hardware baru sebagai leader, primary, atau penanggung jawab partisi panas sebelum metrik stabil.

Contoh label dan routing di Kubernetes

Jika workload berjalan di Kubernetes, label node dan affinity dapat membantu memastikan rollout benar-benar terpisah per pool.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-canary-mixed-hw
spec:
  replicas: 2
  selector:
    matchLabels:
      app: api
      track: canary-mixed
  template:
    metadata:
      labels:
        app: api
        track: canary-mixed
    spec:
      nodeSelector:
        hardware.pool: legacy-ram-bridge
      containers:
        - name: api
          image: registry.example.com/api:release-2026-07
          ports:
            - containerPort: 8080

Ini bukan solusi lengkap, tetapi menunjukkan prinsip penting: jangan biarkan scheduler menyebarkan canary secara acak ke seluruh variasi hardware.

Metrik observability yang wajib dipantau

Dalam konteks hardware campuran, agregat global sering menipu. Anda harus bisa memotong metrik berdasarkan service, version, dan hardware pool.

Metrik aplikasi

  • Request rate per pool
  • Error rate per endpoint dan per pool
  • Latency p50, p95, p99 per pool
  • Timeout rate
  • Retry rate dan circuit breaker open rate
  • Queue depth, job age, consumer lag
  • Connection pool saturation ke database, cache, atau upstream

Kenapa penting? Karena masalah hardware sering tidak langsung memunculkan 5xx, tetapi lebih dulu menaikkan latency tail, timeout, dan retry storm.

Metrik sistem operasi dan host

  • CPU utilization dan steal time bila relevan
  • Load average dibanding kapasitas core
  • Memory available, page fault, reclaim, swap activity
  • I/O wait, disk latency, queue depth, read/write error
  • NIC errors, packet drop, retransmit, saturation
  • Kernel log anomaly seperti reset device, corrected error, DMA issue, atau timeout driver

Hardware reuse atau konfigurasi jembatan antar komponen dapat menambah overhead atau pola bottleneck yang tidak terlihat di level aplikasi saja.

Metrik runtime

Untuk runtime seperti JVM, Go, Node.js, atau Python, pantau metrik yang menunjukkan efek tidak langsung dari perbedaan hardware:

  • GC pause atau frekuensi GC
  • Heap growth dan allocation rate
  • Thread pool starvation
  • Event loop lag
  • File descriptor pressure

Contohnya, memory latency yang lebih buruk bisa memengaruhi alokasi dan GC, meskipun aplikasi tidak crash.

Metrik data layer

  • Database query latency per client pool
  • Connection error dan reconnect rate
  • Replication lag
  • Cache miss anomaly akibat timeout atau eviction

Masalah di server aplikasi sering terlihat pertama kali sebagai lonjakan query lambat, penumpukan queue, atau pool koneksi yang habis.

Indikator cepat untuk trigger rollback

Rollback tidak harus menunggu outage total. Pada rollout hardware campuran, tim perlu mendefinisikan indikator cepat yang sederhana, objektif, dan bisa dieksekusi dalam hitungan menit.

Trigger rollback yang layak dipakai

  • Latensi p95/p99 pada pool canary naik konsisten terhadap baseline dan tidak pulih dalam jendela observasi singkat.
  • Error rate atau timeout rate pada pool canary naik, walau agregat global masih terlihat normal.
  • Retry rate meningkat dan mulai memengaruhi upstream.
  • Host-level metric menunjukkan I/O wait, memory pressure, atau NIC error yang tidak ada pada baseline.
  • Kernel log atau dmesg menunjukkan anomali perangkat berulang setelah node menerima traffic produksi.
  • SLO layanan mulai terancam jika rollout diteruskan.

Hindari rollback berbasis intuisi semata. Tetapkan syaratnya sebelum deploy dimulai, misalnya:

- rollback jika timeout rate pool canary lebih tinggi dari baseline secara konsisten
- rollback jika p99 hanya memburuk pada hardware.pool=legacy-ram-bridge
- rollback jika queue lag terus tumbuh selama traffic tetap
- rollback jika ada error host berulang yang mengindikasikan masalah kompatibilitas

Catatan: Angka ambang spesifik sebaiknya disesuaikan dengan SLO, baseline historis, dan sensitivitas layanan Anda. Jangan menyalin threshold dari sistem lain tanpa kalibrasi.

Runbook deploy aman langkah demi langkah

Pra-deploy

  1. Inventaris pool hardware
    Pastikan semua node memiliki label pool yang konsisten dan terverifikasi.
  2. Validasi baseline host
    Periksa firmware, driver, kernel, BIOS setting penting, dan image host agar tidak ada variasi tak terdokumentasi.
  3. Jalankan smoke test host
    Cek memory, disk, NIC, dan log kernel sebelum node menerima workload produksi.
  4. Pastikan dashboard per pool tersedia
    Minimal ada dashboard untuk latency, error, CPU, memory, I/O, network, dan kernel anomaly.
  5. Definisikan rollback owner
    Satu orang berwenang memutuskan rollback untuk menghindari kebingungan saat sinyal mulai buruk.
  6. Freeze perubahan lain
    Hindari deployment besar lain, tuning database, atau perubahan jaringan pada waktu yang sama.

Saat deploy

  1. Deploy ke control node pada pool hardware campuran dengan versi aplikasi lama.
  2. Observasi metrik host dan aplikasi.
  3. Deploy canary versi baru ke pool lama dan pool campuran.
  4. Aktifkan traffic kecil yang bisa dipisahkan.
  5. Bandingkan metrik terhadap baseline dan control, bukan hanya terhadap agregat global.
  6. Jika stabil, naikkan kapasitas per pool bertahap.
  7. Hentikan promosi otomatis jika ada deviasi nyata pada salah satu pool.

Pasca-deploy

  1. Review metrik 1-2 siklus beban normal, bukan hanya 5 menit pertama.
  2. Catat deviasi kecil walau belum layak insiden.
  3. Perbarui profil kapasitas tiap pool jika throughput nyata berbeda.
  4. Simpan hasil validasi untuk rollout berikutnya.

Contoh otomatisasi pemeriksaan cepat

Di bawah ini contoh sederhana skrip shell untuk mengumpulkan indikator host saat canary dievaluasi. Ini bukan pengganti observability penuh, tetapi berguna untuk triage cepat.

#!/usr/bin/env bash
set -euo pipefail

echo "== uname =="
uname -a

echo "== uptime =="
uptime

echo "== memory =="
free -m

echo "== vmstat =="
vmstat 1 5

echo "== disk =="
iostat -xz 1 3 || true

echo "== network =="
ss -s
ip -s link || true

echo "== kernel warnings =="
dmesg --level=err,warn | tail -n 50 || true

Skrip ini membantu menjawab pertanyaan dasar: apakah node canary menunjukkan tanda pressure sistem, masalah I/O, atau error perangkat yang tidak terlihat di dashboard aplikasi.

Contoh runbook insiden singkat

Berikut contoh runbook operasional yang ringkas dan bisa dipakai saat rollout bermasalah.

Judul insiden

Degradasi latensi setelah deploy ke pool hardware campuran

Kondisi pemicu

  • p99 latency naik pada node dengan label hardware.pool=legacy-ram-bridge
  • timeout rate meningkat
  • queue lag mulai tumbuh

Tindakan 0-5 menit

  1. Pause rollout otomatis.
  2. Alihkan traffic dari canary pool bermasalah.
  3. Bandingkan metrik canary dengan control node pada pool yang sama dan baseline pool lama.
  4. Cek dashboard host dan kernel log.

Tindakan 5-15 menit

  1. Jika deviasi konsisten, lakukan rollback versi aplikasi pada pool tersebut atau keluarkan node dari rotasi.
  2. Jika masalah hanya ada pada hardware pool baru, pertahankan versi baru di pool lama dan isolasi pool baru.
  3. Jika masalah ada di semua pool, rollback aplikasi secara lebih luas.

Kriteria eskalasi

  • Error host berulang
  • Timeout menyebar ke upstream/downstream
  • SLO layanan terancam
  • Belum ditemukan pembeda jelas antara isu software dan hardware dalam batas waktu triage

Keluaran yang harus dicatat

  • Waktu mulai gejala
  • Pool hardware yang terdampak
  • Versi aplikasi dan image host
  • Metrik yang berubah pertama kali
  • Keputusan rollback dan alasan

Format postmortem ringan

Postmortem tidak harus panjang. Yang penting adalah bisa dipakai memperbaiki rollout berikutnya.

Judul:
Rollback deploy pada pool hardware campuran karena drift latency

Ringkasan:
Deploy versi X aman di pool lama, tetapi menyebabkan kenaikan p99 dan timeout pada pool hardware Y.

Dampak:
- layanan terdampak
- durasi
- cakupan traffic

Timeline:
- T0 deploy control node
- T1 canary aktif
- T2 p99 naik pada pool Y
- T3 rollout dipause
- T4 rollback / node di-drain

Deteksi:
- metrik pertama yang memicu investigasi
- alert yang aktif atau justru tidak aktif

Akar masalah sementara / final:
- incompatibility path I/O / memory behavior / driver issue / capacity mismatch

Yang berjalan baik:
- canary per pool membatasi blast radius
- rollback cepat berhasil

Yang kurang:
- threshold rollback belum tajam
- dashboard per pool belum lengkap

Action items:
- tambah label hardware wajib
- tambah alert berbasis pool
- tambah soak test host
- update kapasitas per pool

Tindakan pencegahan agar perubahan hardware tidak merusak stabilitas aplikasi

1. Jadikan hardware sebagai dimensi konfigurasi yang eksplisit

Jika kapasitas antar pool berbeda, jangan paksa semua node menerima beban yang sama. Sesuaikan:

  • limit concurrency
  • jumlah worker
  • ukuran connection pool
  • rate limit per node
  • penempatan shard atau partisi panas

Kesalahan umum adalah menganggap semua node identik, lalu menyalin konfigurasi worker dan concurrency tanpa melihat karakteristik memory atau I/O.

2. Lakukan soak test sebelum produksi penuh

Smoke test singkat sering tidak cukup. Jalankan beban representatif cukup lama untuk melihat:

  • memory leak yang hanya muncul di kondisi tertentu
  • GC pause berkala
  • driver reset intermiten
  • thermal atau throttling
  • queue buildup yang lambat

3. Bedakan alert global dan alert per pool

Alert global penting untuk ketersediaan layanan, tetapi alert per pool penting untuk mendeteksi regresi dini. Tanpa pemisahan ini, masalah pada 5% node bisa tertutup oleh 95% node sehat.

4. Simpan profil performa per pool

Setelah rollout, dokumentasikan kapasitas nyata tiap pool. Misalnya, jika satu pool konsisten memiliki latensi tail lebih tinggi di beban tertentu, scheduler atau autoscaler harus memperhitungkannya.

5. Jangan promosi node baru ke role sensitif terlalu cepat

Pada sistem database, messaging, atau stateful cache, hindari langsung menjadikan node hardware baru sebagai leader, primary, atau node dengan traffic tulis dominan. Biarkan node membuktikan stabilitas lebih dulu.

6. Tautkan data aset dengan observability

Data inventaris hardware sebaiknya terhubung ke metrik dan incident review. Jika tim harus mencari manual serial, tipe NIC, atau firmware saat insiden berlangsung, investigasi akan melambat.

Kesalahan umum yang perlu dihindari

  • Mengandalkan rata-rata latency dan mengabaikan p95/p99.
  • Melihat metrik agregat saja tanpa pemisahan per hardware pool.
  • Deploy aplikasi baru dan perubahan host besar sekaligus tanpa control group.
  • Mendorong traffic penuh terlalu cepat karena canary awal terlihat normal.
  • Tidak mengamati log kernel dan metrik host karena fokus hanya ke dashboard aplikasi.
  • Tidak punya kriteria rollback sebelum deploy, sehingga keputusan terlambat dan emosional.

Penutup

Runbook deploy & rollback saat upgrade server pakai hardware campuran harus berangkat dari asumsi bahwa tidak semua node berperilaku sama, meskipun spesifikasi kasarnya terlihat mirip. Kunci utamanya adalah mengisolasi risiko per pool, menjalankan canary yang bisa membedakan isu software dari isu hardware, memantau metrik aplikasi dan host secara terpisah, serta menyiapkan rollback cepat berdasarkan indikator objektif.

Jika dilakukan dengan disiplin, tim DevOps bisa memanfaatkan hardware campuran atau komponen hasil reuse tanpa membiarkan variasi platform diam-diam merusak stabilitas aplikasi produksi.