Belajar IT Support - IT Service Management (ITIL)

#Pendahuluan

Setelah di episode 22 kalian mendukung aplikasi yang servernya di awan, sekarang kita bingkai seluruh kemampuan itu dalam kerangka standar dunia: ITIL (IT Infrastructure Library) — kini bagian dari ITIL 4 di bawah payung ITSM (IT Service Management). Kalau episode-episode sebelumnya memberi kalian keterampilan, episode ini memberi bahasa bersama yang dipakai perusahaan besar untuk mendeskripsikan pekerjaan itu.

Mengapa ITIL penting bagi support? Karena istilah-istilahnya muncul di hampir setiap lowongan dan interview (incident management, change request, SLA), karena perusahaan enterprise menilai calon dari pemahaman proses ini, dan — yang paling praktis — karena kerangkanya benar-benar membuat hidup lebih tenang: saat insiden datang, tim dengan proses jelas bergerak seperti orkestra; tanpa proses, seperti pasar malam.

#Incident Management: Memulihkan Layanan Cepat

Incident adalah gangguan atau penurunan kualitas layanan — sesuatu yang sudah rusak. Fokus utamanya satu: pulihkan layanan secepatnya, bukan mencari akar masalah.

Alur incident yang sehat:

Deteksi -> Log & kategorikan -> Prioritaskan (ep 2) ->
Diagnosis awal (Tier 1) -> Eskalasi bila perlu ->
Workaround? berikan! -> Pulih -> Tutup + dokumentasi

Konsep kunci yang sering salah dipahami:

1. Workaround itu sah dan dianjurkan. Server lambat karena disk penuh? Bersihkan log dulu agar operasional jalan — penyebab struktural dibedah belakangan.
2. Major incident punya jalur khusus: war room komunikasi, update berkala ke stakeholder, satu commander. Tiket email server mati ≠ ditangani santai seperti tiket mouse rusak.
3. Komunikasi adalah separuh pekerjaan: user memaafkan downtime panjang kalau diberi kabar rutin; mereka tidak memaafkan keheningan.

#Problem Management: Membunuh Penyebabnya

Problem adalah penyebab (atau potensi penyebab) dari satu/lebih incident. Jika incident management menyembuhkan demam, problem management mencari infeksinya.

Siklusnya: identifikasi pola → analisis akar masalah (RCA, root cause analysis) → solusi permanen → dokumentasi sebagai known error beserta workaround-nya.

Contoh nyata yang menyatukan keduanya:

Minggu 1 : PC HRD-01 BSOD        -> INCIDENT, driver digulirkan balik, pulih
Minggu 2 : PC FIN-03 BSOD serupa -> INCIDENT kedua, pola mulai terlihat
Analisis : PROBLEM dibuka -> RCA: update driver GPU vendor X vs Windows
           build baru = konflik
Solusi   : blokir versi driver via Intune (known error + fix resmi)
Hasil    : nol BSOD lanjutan -> nilai problem management terbukti

Teknik RCA sederhana yang cukup untuk Tier 1-2 adalah 5 Whys: tanya "kenapa" lima kali sampai temuan tak bisa lagi disalahkan pada hal di atasnya.

#Change Management: Mengubah Tanpa Mengejutkan

Change adalah modifikasi apa pun pada lingkungan produksi: upgrade firmware switch, ubah GPO, ganti IP printer, deploy policy baru. Prinsip intinya: perubahan tanpa kendali = sumber insiden terbesar sejarah IT.

Jenis-jenis change:

Anatomi change record yang baik:

Apa      : ganti firmware switch Lantai 2
Kenapa   : bug multicast drop (link problem INC-88)
Kapan    : Sabtu 22.00-23.30 (window maintenance)
Risiko   : LAN lantai 2 putus selama window
Rollback : simpan config lama; prosedur restore 10 menit
Uji      : ping gateway + VoIP call test + user pilot 3 orang
Komunikasi: pengumuman H-2 ke semua staf lantai 2

Dua kata paling bernilai di situ: rollback plan dan maintenance window. Change tanpa rencana mundur bukan perubahan — itu taruhan.

#Service Request: Permintaan, Bukan Keluhan

Service request adalah permintaan standar yang tidak ada gangguannya: minta software, akses folder, laptop baru, kartu nama. Ia dikerjakan lewat request catalog dengan form terstruktur + approval flow:

1. User isi form ("Request: Adobe Acrobat untuk divisi Design").
2. Sistem merouting approval ke atasan/pemilik anggaran otomatis.
3. Disetujui → teknisi eksekusi sesuai runbook → auto-close.

Manfaat besar request catalog: data volume permintaan → dasar standardisasi & otomasi (episode 16), plus jejak audit akses yang rapi (episode 20).

#CMDB: Peta Hubungan Konfigurasi

CMDB (Configuration Management Database) menyimpan configuration items (CI) dan hubungan antarmereka: aplikasi ERP berjalan di server X, yang butuh switch Y, yang dilayani oleh PSU dari UPS Z.

Versi pragmatisnya untuk tim kecil: asset register (episode 12) + kolom "tergantung pada". Nilainya terasa saat insiden: switch mati → CMDB langsung menjawab "layanan apa saja yang ikut lumpuh?" — tanpa CMDB, kalian menemukannya dengan cara yang menyakitkan.

#KPI Layanan yang Sehat

Angka yang dipakai manajemen menilai layanan (dan yang akan kalian kelola suatu hari):

#ITIL Pragmatis untuk Tim Kecil

Perusahaan kecil tidak butuh birokrasi ITIL penuh — butuh tulang punggungnya:

1. Mulai dari ticketing yang disiplin dengan kategori incident vs request (episode 9).
2. Pisahkan alur request lewat catalog + approval.
3. Terapkan change record ringkas untuk semua sentuhan produksi — bahkan satu halaman.
4. Buka problem ticket saat pola muncul; catat known error di KB (episode 17).
5. Review bulanan: top insiden, backlog, change yang gagal — 60 menit yang mengubah tim.

#Penutup

Inti yang harus dibawa pulang:

• Incident = pulihkan cepat (workaround sah); problem = bunuh akar masalah via RCA; change = modulasi risiko dengan rollback plan; request = katalog + approval.
• Known error database + KB membuat tim belajar dari tiap insiden, bukan sekadar bertahan hidup.
• CMDB pragmatis = asset register + relasi dependensi; nilainya muncul tepat saat krisis.
• KPI dibaca dengan konteks — angka yang dikejar buta merusak perilaku tim.
• Adopsi ITIL bertahap: ticketing tertib → catalog → change record ringkas → problem review bulanan.

Di episode 24 selanjutnya kita asah kemampuan diagnosis tingkat lanjut: advanced troubleshooting — membaca Event Viewer secara sistematis, teknik log analysis, Reliability Monitor, clean boot dan safe mode, isolasi profil user yang korup, serta menyusun RCA report yang membuat eskalasi kalian diterima dengan hormat. Sampai jumpa!