Memahami Severity Level untuk Support IT

Severity level membantu pelanggan dan tim support memakai bahasa prioritas yang sama saat sebuah layanan bermasalah. Tujuannya sederhana: semua pihak memahami dampak bisnis, urgensi respons, dan keputusan operasional yang perlu diambil lebih dulu.

Dalam konteks support IT, severity bukan sekadar label teknis. Severity adalah ukuran dampak insiden terhadap layanan, data, pengguna, dan kemampuan organisasi untuk tetap bekerja. Karena itu penentuan severity perlu melihat kondisi sistem produksi, jumlah pengguna terdampak, ketersediaan workaround, risiko kehilangan data, dan fungsi bisnis yang berhenti.

Kenapa severity level perlu disepakati

Tanpa klasifikasi yang jelas, semua masalah terasa mendesak. Akibatnya tim support sulit menentukan urutan kerja, pelanggan sulit melihat ekspektasi respons, dan incident commander sulit memisahkan gangguan kritikal dari bug minor.

• Prioritas kerja lebih jelas: tim bisa fokus ke gangguan yang paling berisiko terhadap operasi bisnis.
• Ekspektasi respons lebih sehat: pelanggan dan support punya rujukan yang sama ketika membahas urgensi.
• Eskalasi lebih cepat: issue kritikal tidak tenggelam di antara request minor.
• Dokumentasi insiden lebih konsisten: laporan post-incident bisa menjelaskan dampak, keputusan, dan perubahan status severity.

Severity 1 (Urgent)

Severity 1 adalah kondisi kritikal pada sistem produksi atau layanan mission critical. Biasanya layanan sedang down, fungsi utama berhenti, risiko terhadap data besar, dan tidak ada workaround yang bisa dipakai dalam waktu dekat.

Contoh praktisnya: pengguna tidak bisa mengakses sistem utama, email tidak bisa dikirim atau diterima secara luas, web server produksi mati, service kritikal tidak bisa distabilkan, atau restart tidak memulihkan fungsi layanan.

Jika workaround yang efektif sudah ditemukan, atau informasi penting untuk troubleshooting tidak bisa segera diberikan, severity dapat dievaluasi ulang. Dalam banyak kasus, insiden yang awalnya Severity 1 bisa turun menjadi Severity 2 setelah dampak kritikal berhasil dikendalikan.

Severity 2 (High)

Severity 2 berarti fungsi utama terganggu sebagian, tetapi operasi masih bisa berjalan dalam batas tertentu. Dampaknya tetap serius, terutama jika dibiarkan terlalu lama, tetapi ada workaround sementara atau ruang operasional untuk menjaga layanan tetap digunakan.

• Fungsi major tidak bekerja penuh atau bekerja tidak konsisten.
• Produktivitas pengguna terganggu, tetapi layanan belum sepenuhnya berhenti.
• Workaround tersedia dan bisa dipakai dalam waktu singkat.
• Dampak tidak seluas Severity 1, tetapi tetap membutuhkan prioritas tinggi.

Perbedaan pentingnya ada pada kendali sementara. Pada Severity 1, tim belum punya jalan aman untuk menahan dampak. Pada Severity 2, ada cara sementara untuk membuat operasi tetap berjalan sambil akar masalah ditangani.

Severity 3 (Medium)

Severity 3 digunakan untuk issue parsial, non-kritikal, atau gangguan pada fungsi minor. Beberapa komponen mungkin tidak berjalan normal, tetapi fungsi utama layanan tetap bisa dipakai oleh pengguna.

1. Bug minor atau perilaku aplikasi yang tidak ideal.
2. Fungsi minor tidak berjalan, tetapi ada workaround yang memadai.
3. Gangguan hanya memengaruhi sebagian kecil pengguna atau skenario tertentu.
4. Masalah tidak menghentikan operasi bisnis utama.

Severity 3 tetap perlu dicatat dan diselesaikan. Bedanya, pengerjaan dapat dijadwalkan dengan lebih terencana karena risikonya tidak langsung menghentikan layanan utama.

Bagaimana severity bisa berubah

Severity bukan status permanen. Ia bisa naik atau turun ketika fakta baru muncul. Sebuah issue dapat naik prioritas jika dampak meluas, risiko data meningkat, atau workaround gagal. Sebaliknya, severity dapat turun jika layanan sudah stabil, workaround bekerja, atau dampak sudah terbatas.

Informasi yang membantu triage

Agar penentuan severity cepat dan akurat, pelanggan sebaiknya menyiapkan informasi dasar saat melaporkan issue.

• Waktu mulai kejadian dan apakah masih berlangsung.
• Layanan, domain, server, atau aplikasi yang terdampak.
• Jumlah pengguna terdampak dan contoh akun atau unit kerja.
• Pesan error, screenshot, log, bounce message, atau gejala yang terlihat.
• Perubahan terakhir sebelum kejadian, misalnya patch, konfigurasi DNS, firewall, storage, sertifikat, atau network.
• Workaround yang sudah dicoba dan hasilnya.

Prioritas operasional JABETTO

Dalam operasi support, JABETTO memprioritaskan pemulihan layanan dan pengendalian dampak terlebih dahulu. Root cause analysis tetap penting, tetapi pada insiden kritikal langkah awal biasanya adalah menjaga sistem tetap tersedia, mencegah kehilangan data, dan membuat komunikasi insiden tetap jelas.

1. Kendalikan dampak terbesar lebih dulu.
2. Pastikan jalur komunikasi dan PIC pelanggan aktif.
3. Kumpulkan fakta teknis yang cukup untuk diagnosis.
4. Terapkan workaround jika itu menurunkan risiko bisnis.
5. Lanjutkan perbaikan permanen setelah layanan cukup stabil.
6. Dokumentasikan perubahan severity, tindakan, dan hasil validasi.

Sumber dan konteks migrasi

Artikel ini memperbarui konten lama JABETTO tentang severity level di /news/memahami-severity-level/. Struktur Severity 1, Severity 2, dan Severity 3 tetap dipertahankan, tetapi bahasanya disegarkan agar lebih mudah dipakai sebagai rujukan support, incident triage, dan komunikasi operasional.