Lessons Learned #

Artikel terakhir dalam series ini bukan tentang fitur atau teknik baru — tapi tentang pelajaran yang hanya bisa dipelajari dari pengalaman mengoperasikan infrastruktur nyata dengan Ansible. Banyak di antaranya terasa obvious setelah terjadi, tapi tidak terlihat sebelumnya. Artikel ini merangkum pola yang paling berharga: bukan dari dokumentasi resmi, tapi dari insiden, percobaan yang gagal, dan keputusan yang akhirnya terbukti benar atau salah.

Pelajaran 1: –check Bukan Substitusi untuk Staging #

Skenario yang sering terjadi:
  "Kita sudah jalankan --check dan tidak ada perubahan yang unexpected.
   Kita bisa langsung deploy ke production."

Yang terjadi kemudian:
  Deployment production gagal dengan error yang tidak pernah muncul di --check,
  karena --check tidak bisa mendeteksi kondisi runtime seperti:
  - Service yang tidak merespons
  - Disk yang penuh tepat saat task dijalankan
  - Race condition antara dua task
  - Versi library yang berbeda antara staging dan production

Pelajaran: --check sangat berguna untuk memverifikasi bahwa tidak ada perubahan yang tidak diinginkan. Tapi ia bukan pengganti staging. Selalu deploy ke staging sebelum production.

Pelajaran 2: Idempotency yang Rusak Selalu Muncul di Waktu yang Paling Buruk #

# Playbook yang "bekerja" tapi tidak idempoten:
- name: Tambahkan konfigurasi ke file
  shell: echo "{{ config_line }}" >> /etc/app/config
  # Bekerja baik di run pertama.
  # Di run kedua: duplikasi konfigurasi, aplikasi crash.
  # Di run kesepuluh: 10 baris duplikat, masalah yang sangat sulit di-debug.

Pelajaran: Idempotency bukan hanya best practice — ia adalah properti yang mencegah kegagalan yang sulit di-debug di production. Test idempotency secara eksplisit: jalankan playbook dua kali, verifikasi tidak ada changed di run kedua.

Pelajaran 3: Vault Password yang Hilang adalah Bencana #

Skenario:
  Tim menggunakan Ansible Vault untuk semua secret.
  Engineer yang tahu vault password keluar dari perusahaan.
  Vault password disimpan di "suatu tempat yang aman" yang tidak ada yang tahu.
  Sekarang tidak ada yang bisa decrypt secret yang diperlukan untuk deployment.

Pelajaran: Vault password adalah secret yang paling penting. Ia harus:

• Disimpan di minimal 2 tempat yang berbeda (password manager perusahaan + HSM/secret manager)
• Accessible oleh minimal 2 orang di setiap shift on-call
• Di-rotate secara berkala dengan prosedur yang terdokumentasi
• TIDAK hanya ada di laptop satu orang

Pelajaran 4: “Kita Akan Refactor Nanti” Jarang Terjadi #

Hutang teknikal Ansible yang paling umum:
  - Playbook monolitik yang "sementara" dipakai selama 2 tahun
  - Role yang di-copy-paste antar project alih-alih dibuat shared
  - Variabel yang di-hardcode "untuk sekarang"
  - Test yang "akan ditulis besok"

Pattern yang terjadi:
  Setiap kali ada tekanan untuk deploy cepat, corner cut.
  Corner cut menjadi hutang teknikal.
  Hutang teknikal menumpuk sampai refactoring tidak mungkin lagi.

Pelajaran: Lakukan refactoring dalam PR yang sama dengan fitur yang menambahkan kebutuhannya. “Boy Scout Rule” untuk infrastruktur: tinggalkan kode sedikit lebih baik dari sebelum kamu menyentuhnya.

Pelajaran 5: Komunikasi lebih Penting dari Teknik #

Scenario A: Deployment sempurna secara teknikal tapi gagal secara organisasional
  - Tidak ada yang tahu deployment sedang terjadi
  - Tim support menerima puluhan tiket tentang "gangguan"
  - Management panik
  - Bahkan jika tidak ada downtime, insiden ini terasa seperti kegagalan

Scenario B: Deployment dengan komunikasi yang baik
  - Semua stakeholder diberitahu sebelumnya
  - Progress diupdate di channel yang tepat
  - Tim support tahu bahwa ada deployment dan apa yang berubah
  - Bahkan jika ada downtime singkat, tidak ada kejutan

Pelajaran: Notifikasi deployment, dokumentasi perubahan, dan komunikasi proaktif seringkali lebih penting dari kesempurnaan teknikal. Tim yang berkomunikasi baik bisa mengatasi insiden teknikal; tim yang tidak berkomunikasi bisa gagal bahkan dengan deployment yang sempurna.

Pelajaran 6: Test Restore, Bukan Hanya Backup #

Skenario yang terlalu sering terjadi:
  - Backup database berjalan setiap malam selama 2 tahun
  - Disaster terjadi, perlu restore
  - Backup files ada, tapi prosedur restore tidak pernah ditest
  - File backup ternyata corrupt (atau format-nya berubah)
  - Atau: engineer yang tahu cara restore sedang liburan
  - Atau: restore butuh 8 jam padahal RTO 2 jam

Pelajaran: Backup yang tidak pernah di-restore bukanlah backup. Buat jadwal Chaos Day atau Disaster Recovery Drill minimal setiap kuartal — simulasikan kegagalan nyata dan verifikasi bahwa prosedur recovery benar-benar bekerja.

Prinsip yang Bertahan #

Setelah semua pelajaran ini, beberapa prinsip terbukti selalu benar:

1. Sederhana lebih baik dari kompleks
   Solusi sederhana yang semua orang mengerti lebih baik dari
   solusi elegan yang hanya satu orang yang bisa maintain.

2. Ukur sebelum optimasi
   Jangan menebak di mana bottleneck — gunakan profile_tasks.
   Jangan menebak apa yang gagal — gunakan logging yang baik.

3. Automasi yang bertahap lebih baik dari big bang
   Otomasi satu komponen dengan baik, verifikasi, baru lanjut ke berikutnya.
   Big bang "otomasi semua sekaligus" hampir selalu gagal.

4. Infrastruktur as Code hanya berguna jika kodenya bisa dijalankan
   Playbook yang sudah usang dan tidak pernah ditest sama buruknya
   dengan tidak ada playbook sama sekali. Update secara berkala.

5. Orang lebih penting dari alat
   Ansible, Terraform, Kubernetes — semua hanya alat.
   Tim yang baik bisa membangun infrastruktur yang andal dengan alat sederhana.
   Tim yang buruk akan membuat masalah dengan alat yang paling canggih sekalipun.

Ringkasan #

• --check bukan pengganti staging — ia memverifikasi tidak ada perubahan yang tidak diinginkan, tapi tidak bisa mensimulasikan kondisi runtime production.
• Idempotency yang rusak muncul di waktu yang paling buruk — test selalu dengan menjalankan playbook dua kali, zero changed di run kedua adalah standar minimum.
• Vault password adalah secret paling penting — simpan di minimal dua tempat, accessible oleh minimal dua orang, dan test prosedur recovery-nya.
• Refactor sekarang, bukan nanti — hutang teknikal yang tidak dibayar menumpuk secara eksponensial sampai tidak bisa lagi dibayar.
• Komunikasi seringkali lebih penting dari teknik — notifikasi deployment, dokumentasi perubahan, dan update proaktif mencegah insiden sosial bahkan saat tidak ada insiden teknikal.
• Test restore, bukan hanya backup — prosedur recovery yang tidak pernah ditest sama dengan tidak ada prosedur recovery.