IT Support Done Right: A Practical Field Guide

Sebagian besar pekerjaan IT support dinilai berdasarkan kecepatan, tetapi kecepatan tanpa metode hanya memindahkan masalah yang sama ke tempat lain. Tiket yang ditutup dalam lima menit tetapi dibuka kembali dalam tiga hari lebih mahal daripada tiket yang memakan waktu dua puluh menit dan benar-benar diperbaiki. Panduan ini mencakup kebiasaan yang membedakan seseorang yang menutup tiket dari seseorang yang menyelesaikan masalah.

Mulai dengan intake yang nyata, bukan tebakan

Sebelum menyentuh mesin, minta pengguna mendeskripsikan masalah dengan kata-kata mereka sendiri, lalu ajukan tiga pertanyaan lanjutan: kapan mulai, apa yang berubah baru-baru ini, dan apakah terjadi setiap waktu atau intermiten. "Internet saya lambat" bisa berarti resolusi DNS, saluran Wi-Fi jenuh, NIC yang gagal, atau browser dengan empat puluh tab terbuka. Tulis teks error yang tepat jika ada. Screenshot lebih baik daripada deskripsi — minta satu sebelum meminta pengguna mencoba apa pun.

Tahan keinginan untuk langsung melompat ke "apakah Anda sudah mencoba memulai ulang." Ini bekerja cukup sering sehingga orang default ke sana, tetapi jika Anda melewatkan intake Anda akan melewatkan pola. Jika tiga orang pada switch yang sama melaporkan kelambatan yang sama dalam jam yang sama, itu tiket berbeda daripada satu laptop dengan driver yang buruk.

Reproduksi sebelum Anda memperbaiki

Jika Anda tidak dapat mereproduksi masalah, Anda tidak dapat mengonfirmasi bahwa Anda memperbaikinya. Minta pengguna menjalani langkah-langkah yang tepat pada screen share, atau lakukan sendiri di mesin mereka jika alat remote memungkinkan. Periksa ipconfig /all di Windows atau ip a di Linux untuk sanity jaringan dasar, lihat Event Viewer (eventvwr.msc) untuk kesalahan aplikasi dan sistem sekitar waktu yang dilaporkan, dan periksa journalctl -xe --since "1 hour ago" di kotak Linux untuk jendela yang sama.

Untuk crash aplikasi, dapatkan nomor build dan versi OS yang tepat. "Crash" tidak memberitahu Anda apa pun; "Outlook 16.0.17726 crash saat membuka undangan kalender dengan lampiran .ics" memberitahu Anda di mana mencari. Referensi silang terhadap masalah yang diketahui di catatan rilis vendor sebelum mengasumsikan itu lokal.

Triase berdasarkan dampak, bukan siapa yang berteriak paling keras

Satu pengguna terkunci dari email tidak nyaman. Server file bersama yang tidak dapat diakses oleh empat puluh orang adalah gangguan. Buat skala keparahan sederhana — sesuatu seperti P1 untuk gangguan yang mempengaruhi banyak pengguna atau sistem kritis, P2 untuk pemblokir pengguna tunggal, P3 untuk degraded-but-working, P4 untuk permintaan kosmetik atau kenyamanan — dan terapkan secara konsisten, bahkan di bawah tekanan dari manajer yang ingin miliknya duluan.

Dokumentasikan keputusan keparahan di tiket itu sendiri. Ini melindungi Anda nanti ketika seseorang bertanya mengapa P3 mereka duduk selama dua hari sementara Anda menangani tiga P1s.

Perbaiki akar penyebab, bukan gejala

Memulai ulang layanan yang terus crash menghemat waktu, bukan solusi. Jika print spooler mati setiap hari, periksa Get-WinEvent -LogName Application -MaxEvents 50 untuk error sebenarnya sebelum memulai ulangnya lagi. Jika password pengguna terus kedaluwarsa secara tidak terduga, periksa group policy yang diterapkan pada OU mereka daripada hanya mengatur ulang dan melanjutkan.

Simpan log pribadi perbaikan berulang. Jika Anda menemukan diri Anda mengetik perintah PowerShell yang sama atau perbaikan registry yang sama tiga kali, itu tanda itu harus dalam script atau runbook terdokumentasi, bukan di kepala Anda.

Dokumentasi seolah-olah orang lain akan membacanya

Setiap resolusi tiket harus menjawab: apa penyebab sebenarnya, apa perbaikannya, dan apa yang akan Anda periksa terlebih dahulu jika ini terjadi lagi. "Fixed" sebagai catatan resolusi tidak berguna bagi teknisi berikutnya, termasuk Anda di masa depan enam bulan dari sekarang tanpa ingatan tiket ini.

Nota resolusi yang bagus terlihat seperti: "Root cause: DHCP scope pada VLAN 20 habis, perangkat baru mendapat alamat APIPA. Fix: diperluas scope dari /24 ke /23, reservasi untuk printer ditambahkan. Verify: periksa DHCP lease count bulanan, threshold alert diatur di 90%." Kalimat ketiga itu adalah yang paling banyak teknisi lewatkan, dan itulah yang mencegah tiket berulang.

Eskalasi dengan konteks, bukan hanya forward

Ketika tiket masuk ke tier 2 atau vendor, sertakan apa yang sudah Anda singkirkan. "Periksa kabel, tukar port, konfirmkan VLAN config, masih tidak ada link light" menghemat waktu orang berikutnya dari mengulang dua puluh menit pertama Anda. Eskalasi yang tidak jelas seperti "pengguna mengatakan itu rusak, harap sarankan" hanya memindahkan penundaan daripada menghilangkannya.

Tutup loop dengan pengguna

Beri tahu pengguna apa yang salah dalam bahasa sederhana, bukan hanya "fixed." Orang mempercayai support lebih banyak ketika mereka memahami apa yang terjadi, dan itu mengurangi orang yang sama mengajukan tiket yang sama bulan depan karena mereka tidak menyadari itu terhubung.

Jika Anda ingin mendalami aspek teknis dari semua ini — networking fundamentals, Windows event logs, atau scripting alat diagnostik Anda sendiri — Korra Studio memiliki segmen pada Networking, Systems, dan Scripting yang patut dikerjakan selanjutnya.