Belajar Data Center Engineer - Incident & Change Management DC

#Pendahuluan

Setelah di episode 19 kita mengatur relasi vendor, episode ini merapikan dua proses yang paling sering menjadi penyebab outage justru di fasilitas paling canggih sekalipun: change management (perubahan yang tak terkendali) dan incident management (respons yang kacau saat kejadian). Data Uptime Institute bertahun-tahun konsisten: mayoritas outage melibatkan kesalahan proses/manusia — bukan komponen.

Kita susun kerangka keduanya mengacu pada pola ITIL 4 (bahasa bersama industri), lengkap dengan template yang bisa langsung dipakai tim kalian.

#Change Management: Mengubah Tanpa Merusak

Perubahan adalah sumber hidup DC sekaligus penyebab matinya. ITIL membagi tiga:

#CAB dan Freeze Window

CAB (Change Advisory Board) bukan birokrasi — ia forum singkat menilai risiko: apa dampaknya, apa rollback-nya, kapan waktu amannya. Untuk DC, aturan jadwalnya penting:

Freeze window (larangan normal-change):
- Musim puncak bisnis (campaign, closing tahunan)
- Event besar pelanggan
- Setelah perubahan besar (periode stabilisasi)
Emergency change tetap boleh - tapi wajib retro-review CAB.

#Template Change Request

# CR-2026-0142 : Migrasi feed A rack R07 ke busway baru
 
Tipe        : Normal            Risiko : Sedang-Tinggi
Pelaksana   : [engineer] + verifier     Durasi : 3 jam
Window      : Sabtu 01:00-04:00 WIB (traffic minimum)
 
## Deskripsi dan Alasan
Busway lama akan diganti (EOL). Migrasi feed A R07
sementara ke busway cadangan; beban dual-corded
lanjut lewat feed B selama pekerjaan.
 
## Dampak Bila Berhasil / Gagal
Berhasil : EOL terselesaikan tanpa downtime.
Gagal    : Beban single-corded; server non-redundant.
 
## Prasyarat
[ ] Verifikasi semua device R07 dual-corded (audit ep.3)
[ ] Feed B load < 70% kapasitas
[ ] Spare busway tap-box siap
 
## Rollback
Kembalikan tap ke posisi lama (15 menit).
No-return point: setelah busway lama dilepas fisik -
setelah titik ini rollback = rencana C (genset portabel).
 
## Verifikasi Sukses
Semua server kembali dual-powered; PDU A load normal;
tidak ada alert baru 60 menit pasca-kerja.

Perhatikan bagian no-return point — momen ketika "membatalkan" sudah lebih berbahaya daripada maju. Menyepakatinya sebelum kerja mencegah keputusan panik di tengah jalan.

#Incident Management: Saat Alarm Berbunyi

Saat insiden, kecepatan lahir dari struktur, bukan adrenalin. Klasifikasi dulu:

Alur P1 yang disiplin:

Prinsip emas P1: mitigate first, root cause later. Saat hall panas, tujuannya memulihkan pendinginan — analisis kenapa CDU gagal dilakukan SETELAH situasi tenang. Tetapkan juga satu peran incident commander per P1: orang yang memutuskan, membagi tugas, dan menjaga timeline — bukan selalu teknisi tercepat.

#Komunikasi Berkala

Insiden tanpa kabar menghasilkan korban kedua: kepercayaan. Pola umumnya:

Update tiap 30-60 menit (P1):
- Status    : masih investigasi / mitigasi berjalan / pulih
- Dampak    : layanan apa terkena, skala apa
- Langkah   : sedang melakukan X
- Berikutnya: update jam HH:MM
 
Aturan: tanpa spekulasi penyebab ke stakeholder eksternal;
fakta dulu, teori untuk internal.

#Blameless Postmortem

Dalam 3-5 hari kerja pasca-P1/P2, tulis postmortem. Kata kuncinya blameless: fokus pada sistem yang memungkinkan kesalahan, bukan orang yang salah — kalau hasilnya selalu menyalahkan manusia, insiden berikutnya hanya akan disembunyikan lebih rapi.

# Postmortem INC-2026-0087 : UPS B pindah ke bypass
 
Sev: P2                     Durasi risiko: 47 menit
Status: RESOLVED            Penulis: [nama]
 
## Timeline (UTC+7)
21:03 alarm input-freq abnormal UPS B
21:05 on-call acknowledge; verifikasi panel
21:12 UPS B transfer internal ke bypass mode
21:18 vendor dihubungi (target response P2 ok)
21:50 stabilisasi selesai; UPS kembali online mode
 
## Dampak
Redundansi power hall-2 hilang 47 menit; tidak ada
gangguan layanan (feed A menanggung penuh).
 
## Akar Masalah (bukan penyalahan)
Sensor input board firmware bug versi x.y memicu
false-positive frekuensi; kondisi dikenal vendor via
bulletin yang belum terpantau.
 
## Mengapa Terlewat?
Firmware bulletin vendor tidak punya pemilik proses
pengamatan. Gap sistemik, bukan kelalaian individu.
 
## Action Items
| # | Aksi                                   | Owner    | Due     |
|---|----------------------------------------|----------|---------|
| 1 | Proses review bulletin vendor bulanan  | Ops lead | 2026-09 |
| 2 | Upgrade firmware UPS B                 | Vendor   | 2026-09 |
| 3 | Tambah alert bypass-mode ke critical   | Eng      | 2026-08 |

Bagian "Mengapa Terlewat?" adalah inti nilai postmortem: ia mengubah insiden menjadi perbaikan sistem. Action items tanpa owner dan due date hanyalah harapan.

#Common Pitfalls Process

• CAB jadi bottleneck — rapat mingguan panjang untuk semua change; pisahkan standard changes (pre-approved) dan batasi CAB untuk risiko nyata.
• Emergency change tanpa retro-review — celah klasik untuk melewati proses selamanya.
• Insiden tanpa commander — banyak orang beraksi, tidak ada yang memutuskan; tetapkan incident commander per P1.
• Postmortem ditunda sampai lupa — tulis dalam 72 jam saat ingatan segar dan log masih mudah diekspor.

#Penutup

Inti yang harus dibawa pulang:

• Tiga tipe change (standard/normal/emergency) dengan jalur approval berbeda; freeze window melindungi masa sensitif.
• CR yang baik punya dampak, prasyarat, rollback eksplisit, no-return point, dan verifikasi sukses — dipasangkan dengan MOP.
• Insiden diklasifikasi objektif (P1-P4), direspons terstruktur (commander, mitigate-first), dikomunikasikan berkala tanpa spekulasi.
• Postmortem blameless dengan timeline, akar masalah sistemik, dan action items ber-owner menjadikan setiap insiden investasi.

Di episode 21 selanjutnya kita masuk bab paling menentukan masa depan profesi ini: AI & GPU data centers — mengapa rak AI mencapai 100+ kW, anatomi liquid cooling direct-to-chip dan CDU, fabric jaringan GPU rail-optimized 400/800G, tantangan distribusi daya high-density, serta checklist desain AI-ready untuk menilai kesiapan fasilitas. Sampai jumpa di episode 21!