Belajar System Administrator - Documentation & Runbook

#Pendahuluan

Di episode 0 kalian ditanamkan satu kebiasaan: dokumentasi. Episode 25 adalah momen kebenarannya — karena sekarang kalian memiliki banyak hal untuk didokumentasikan: server, konfigurasi, runbook DR, otomasi, dan keputusan teknis. Ini bagian yang membedakan sysadmin yang dikagumi dari yang "tidak bisa digantikan".

Dokumentasi bukan pekerjaan tambahan — ia adalah produk dari pekerjaan kalian. Knowledge base yang baik mengubah organisasi dari bergantung pada satu orang menjadi bergantung pada sistem. Dan sebagai bonus, dokumentasi adalah investasi untuk diri kalian sendiri: enam bulan ke depan, kalian adalah "orang asing" yang paling bersyukur atas catatan kalian hari ini.

#Knowledge Base: Memori Organisasi

Knowledge base (KB) adalah kumpulan artikel yang menjawab "bagaimana" dan "mengapa": prosedur, keputusan arsitektur, troubleshooting umum. Ini memori bersama yang menyelamatkan setiap orang dari memecahkan masalah yang sama dua kali.

Struktur KB yang sehat:

struktur knowledge base

knowledge-base/
├── onboarding/            # cara akses, tools, akun
├── infrastructure/        # peta & inventory (episode 2)
├── services/              # cara kerja setiap layanan
├── troubleshooting/       # masalah umum + solusinya
├── runbooks/              # prosedur operasional (episode 23)
└── decisions/             # keputusan arsitektur & alasannya

Satu aturan emas yang harus dipegang: dokumentasi adalah kode hidup — ia harus diperbarui bersama sistem yang didokumentasikan, bukan sekali dan dibiarkan basi. Dari episode 2, inventory yang basi = berbahaya.

#Template Artikel Troubleshooting

Setiap entry troubleshooting di KB sebaiknya memiliki struktur yang sama:

KB: troubleshoot-nginx-502.md

# Nginx 502 Bad Gateway
 
Gejala : browser menampilkan 502 untuk aplikasi web
Langkah: 
  1. systemctl status nginx - periksa proxy aktif?
  2. cek aplikasi: curl localhost:3000 - apakah backend hidup?
  3. journalctl -u nginx --since "1 hour ago" - cari upstream error
Penyebab umum: backend mati / port salah / timeout
Solusi   : restart backend lalu verifikasi

Struktur Gejala → Langkah → Penyebab → Solusi memudahkan orang lain memakai KB — termasuk kalian di tengah malam saat otak sudah lelah.

#Runbook: Jembatan antara KB dan Krisis

Dari episode 23, kalian sudah menulis runbook DR. Runbook sebenarnya lebih luas: setiap prosedur berulang dan setiap respons insiden layak punya runbook. Perbedaan dengan KB biasa: runbook ditulis untuk dieksekusi saat kondisi tertekan — langkah bernomor, jelas, tanpa teka-teki.

Dokumen	Ditulis saat	Pembaca	Gaya
KB article	Santai	Orang penasaran	Penjelasan & alasan
Runbook	Kritis / berkala	Orang panik	Langkah bernomor, langsung eksekusi

Contoh runbook non-DR yang akan kalian pakai terus:

runbooks/new-user-linux.md

# Onboarding User Linux
1. useradd -m -s /bin/bash <user>
2. usermod -aG <group> <user>
3. buat home dir & set permission
4. verifikasi: id <user>, ls -l /home/<user>
5. catat di inventory

#SLA dan Manajemen Tiket (Dasar ITIL)

Seorang sysadmin bekerja dalam sistem layanan. ITIL adalah kerangka kerja manajemen layanan IT yang paling dikenal, dan intinya yang perlu kalian pahami:

#SLA: Kesepakatan Layanan

SLA (Service Level Agreement) adalah janji terukur: seberapa cepat merespons, seberapa cepat menyelesaikan. Dua metrik yang selalu ada:

Metrik	Contoh SLA
Response time	Merespons tiket dalam 1 jam kerja
Resolution time	Menyelesaikan dalam 8 jam kerja

SLA inilah yang mengubah pekerjaan kalian dari "orang yang memperbaiki" menjadi "orang yang terikat janji terukur" — dan dari episode 22-23, janji ini harus realistis terhadap kemampuan infrastruktur (HA, RTO, RPO).

#Siklus Hidup Tiket

100%

Prioritas tiket biasanya mengikuti matriks dampak × urgensi:

	Urgensi Tinggi	Urgensi Rendah
Dampak besar	Critical (langsung)	High (hari ini)
Dampak kecil	Medium (hari ini)	Low (bertahap)

Tip

Tiket yang diselesaikan tanpa didokumentasikan adalah pengetahuan yang hilang. Biasakan: setiap resolusi layak menjadi satu entri KB — baik itu masalah baru atau konfirmasi prosedur yang sudah ada. Dari sinilah knowledge base tumbuh tanpa kalian "meluangkan waktu khusus untuk menulis".

Important

SLA yang tidak realistis lebih buruk daripada tidak ada SLA: ia melahirkan ekspektasi yang mustahil, tiket yang terus naik, dan kredibilitas yang merosot. SLA harus dibangun dari data nyata (berapa lama insiden benar-benar selesai, dari episode 11-19) dan dinegosiasikan dengan bisnis — bukan diimpor dari internet.

#Praktik: Dokumentasi Environment

Latihan terpadu — bangun dokumentasi untuk lab kalian:

Bangun dokumentasi lab

# 1. Buat struktur
mkdir -p ~/lab-docs/{infrastructure,services,runbooks,troubleshooting}
# 2. Isi dari inventory yang sudah dibuat di episode 2
# 3. Tulis 1 runbook: restart stack (nginx + app + db)
# 4. Tulis 1 KB entry: masalah yang pernah kalian pecahkan di series ini
# 5. Catat keputusan: kenapa pilih ext4, LVM, restic, dll
# 6. Jadwalkan review bulanan (kalender/reminder)

Poin terakhir tidak boleh diabaikan: dokumentasi yang tidak pernah di-review akan lapuk. Jadwalkan review — dan perbarui setiap kali sistem berubah.

#Penutup

Inti yang harus dibawa pulang dari episode 25:

Knowledge base = memori organisasi; tulis saat menyelesaikan masalah, bukan "nanti".
Runbook = prosedur untuk kondisi tertekan — langkah bernomor, langsung eksekusi.
SLA = janji terukur (response & resolution time), dibangun dari data nyata dan dinegosiasikan.
Tiket mengikuti siklus: triage → investigasi → resolusi → penutupan → dokumentasi.
Dokumentasi adalah kode hidup: di-review, diperbarui, dan dipakai — atau ia membusuk.

Di episode 26 selanjutnya kita akan membahas Ekosistem & Tren Modern 2026 — cloud-first & hybrid sebagai standar, IaC menggantikan konfigurasi manual, containers mendefinisikan ulang deployment, AI mengotomasi task rutin, dan cybersecurity sebagai ekspektasi wajib. Waktunya melihat ke mana profesi ini bergerak!