Belajar Data Center Engineer - Automation Data Center

#Pendahuluan

Setelah di episode 21 kita menyelami era AI DC, sekarang kita belajar cara mengelola skala itu tanpa menambah kepala: automation. Fasilitas dengan ribuan device tidak bisa dikelola manual — bahkan tim besar pun akan kalah oleh drift konfigurasi dan human error. Automation bukan soal keren; ia soal konsistensi yang tak mungkin dicapai tangan manusia.

Kita susun strateginya bertahap: target yang bernilai dulu, tooling standar industri (Ansible, Python API), prinsip aman (idempotensi, dry-run), lalu konsep digital twin yang menjadi tren fasilitas modern.

#Memilih Target Automation yang Bernilai

Jangan mengotomasi semuanya sekali jalan. Urutkan berdasarkan rumus sederhana: frekuensi x risiko human error:

Aturan praktis: pekerjaan yang dilakukan lebih dari 4x setahun dengan langkah identik adalah kandidat kuat. Pekerjaan sekali-setahun kompleks sering lebih aman tetap manual dengan MOP — automation-nya malah jadi risiko baru.

#Praktik 1: Playbook Ansible Health Check

Ansible adalah standar de facto automation infrastruktur karena agentless (SSH saja). Contoh playbook mengumpulkan sensor suhu semua server via IPMI:

---
- name: Kumpulkan sensor BMC semua server
  hosts: dc_servers
  gather_facts: false
  vars:
    bmc_user: "{{ vault_bmc_user }}"
    bmc_pass: "{{ vault_bmc_pass }}"
  tasks:
    - name: Baca sensor suhu via IPMI
      ansible.builtin.command:
        cmd: >
          ipmitool -I lanplus -H {{ hostvars[inventory_hostname]['bmc_ip'] }}
          -U {{ bmc_user }} -P {{ bmc_pass }} sdr type temperature
      register: ipmi_temp
      changed_when: false
      failed_when: false
 
    - name: Simpan hasil per-host
      ansible.builtin.copy:
        content: "{{ ipmi_temp.stdout | default('GAGAL') }}"
        dest: "/var/log/dc-health/{{ inventory_hostname }}.txt"
      delegate_to: localhost
      become: false

Jalankan dan tinjau hasilnya:

ansible-playbook -i inventory/prod playbooks/bmc-health.yml --limit hall2
grep -L "ok" /var/log/dc-health/*.txt   # host bermasalah = tanpa 'ok'

Detail desain yang penting:

• vault_* — kredensial via Ansible Vault, bukan plaintext di repo.
• changed_when: false — task read-only tidak dianggap "mengubah".
• failed_when: false — satu BMC mati tidak membunuh seluruh run; hasilnya ditandai GAGAL untuk ditinjau.

#Praktik 2: Integrasi NetBox via Python API

CMDB yang tidak diaudit akan busuk. Skrip rekonsiliasi sederhana: bandingkan device fisik yang dikenal NetBox vs jawaban live dari network:

import requests
 
NETBOX = "http://localhost:8000/api"
HEADERS = {"Authorization": "Token 0123456789abcdef"}
 
def netbox_switches():
    r = requests.get(f"{NETBOX}/dcim/devices/?role=tor-switch",
                     headers=HEADERS, timeout=10)
    return {d["name"] for d in r.json()["results"]}
 
def live_neighbors(jump_host):
    """Ambil LLDP neighbors dari jump host (contoh stub lab)."""
    out = requests.get(f"{jump_host}/lldp.json", timeout=5)
    return {n["name"] for n in out.json()["neighbors"]}
 
def main():
    documented = netbox_switches()
    seen = live_neighbors("http://10.10.40.9")
    ghost = seen - documented      # ada di lapangan, tak tercatat
    stale = documented - seen      # tercatat, tapi tak terlihat hidup
    print("Perlu ditambahkan :", sorted(ghost) or "-")
    print("Perlu diverifikasi:", sorted(stale) or "-")
 
if __name__ == "__main__":
    main()

Pola ini — bandingkan sumber kebenaran vs realitas — bisa dipakai untuk VLAN, DNS record, firewall rule, sampai lisensi. Rekonsiliasi otomatis mingguan menjaga NetBox layak dipercaya, dan NetBox yang layak dipercaya adalah bahan bakar semua automation berikutnya.

#Guardrails: Otomasi yang Aman

Automation yang buruk lebih cepat merusak daripada manusia. Pasang pagar-pagar ini sejak awal:

1. Idempotent        : jalankan 2x, hasil sama - state-based, bukan script prosedural
2. Dry-run default   : --check / plan dulu, apply dengan persetujuan
3. Blast radius       : --limit per-grup; jangan pernah all sekaligus di produksi
4. Audit trail        : semua run tercatat (siapa, kapan, output)
5. Break-glass        : prosedur manual tersedia jika automation gagal

Contoh disiplin Ansible yang benar:

ansible-playbook playbooks/ntp-baseline.yml --check --diff   # lihat dampak
ansible-playbook playbooks/ntp-baseline.yml --limit spine   # kelompok kecil dulu
ansible-playbook playbooks/ntp-baseline.yml --limit leaf    # lanjut bertahap

--check --diff menunjukkan apa yang AKAN berubah tanpa mengubah apa pun — biasakan melihatnya sebelum setiap deploy.

#Digital Twin: Simulasi Sebelum Eksekusi

Tren matang di fasilitas modern: digital twin — model virtual fasilitas untuk menguji keputusan tanpa risiko. Dua bentuk utama:

1. Thermal/CFD twin — simulasi aliran udara/air: "rack AI 80 kW di baris C bikin hotspot mana?" dijawab di software CFD sebelum rack dibeli.
2. Operational twin — replika data live (power, cooling, kapasitas) yang bisa diuji skenario: matikan UPS A virtual, bagaimana beban pindah? Tambah 20 rack tahun depan, chiller sanggup?

Nilai twin bukan grafik 3D-nya — melainkan kemampuan menjawab what-if dengan angka, bukan debat opini. Mulai versi minimalnya hari ini: spreadsheet model kapasitas (episode 12) + data metering live sudah adalah twin generasi pertama.

#Common Pitfalls Automation

• Mengotomasi chaos — mengotomasi proses yang belum stabil hanya mempercepat kekacauan; rapikan proses dulu (episode 11, 20).
• Credential di plaintext — BMC password di git publik adalah insiden menunggu tanggal; vault/secret manager wajib.
• Tanpa pemilik — playbook siapa pun milik siapa pun = tak ada yang berani ubah atau berani hapus.
• Otomasi sebagai single brain — satu orang hafal semua pipeline; dokumentasi + code review menjaga pengetahuan tetap organisasi.

#Penutup

Inti yang harus dibawa pulang:

• Pilih target dengan frekuensi x risiko; mulai read-only (backup config, audit inventaris) untuk membangun kepercayaan.
• Ansible (agentless, idempotent) untuk orkestrasi; Python API untuk rekonsiliasi CMDB vs realitas.
• Guardrails non-negotiable: idempotensi, dry-run default, blast radius terbatas, audit trail, break-glass.
• Digital twin = menjawab what-if dengan angka; versi pertamanya bisa dimulai dari model kapasitas + metering.

Di episode 23 selanjutnya kita naik ke arsitektur abstraksi penuh: software-defined data center — empat pilar SDDC (compute, storage, network, orchestration), Ceph sebagai storage defined, EVPN sebagai SDN praktis, OpenStack dan Kubernetes dalam peta besar, plus trade-off jujur kompleksitas versus fleksibilitas. Sampai jumpa di episode 23!