IT Desteği Doğru Şekilde Yapılır: Pratik Saha Rehberi

Çoğu IT destek işi hız üzerinden değerlendirilir, ancak yöntem olmayan hız aynı sorunu başka bir yere taşır. Beş dakikada kapanan ve üç gün sonra yeniden açılan bir bilet, yirmi dakika süren ve gerçekten düzeltilen bir biletten daha maliyetlidir. Bu rehber bilet kapatayanlar ile sorun çözenler arasındaki farkı yaratır.

Tahmin değil, gerçek bir alış işlemiyle başlayın

Bir makineye dokunmadan önce, kullanıcıya sorunu kendi sözcükleriyle açıklatın, sonra üç takip sorusu sorun: ne zaman başladı, son zamanlarda ne değişti ve her zaman mı yoksa ara sıra mı oluyor. "İnternet yavaş" DNS çözümlemesi, doygun Wi-Fi kanalı, arızalı NIC ya da kırk sekme açık tarayıcı anlamına gelebilir. Varsa tam hata metnini yazın. Ekran görüntüleri açıklamayı her zaman yener — kullanıcıdan herhangi bir şey denemesini istemeden önce bir tane isteyin.

"Yeniden başlatmayı denedin mi" deme dürtüsüne direnin. Yeterince sık çalışır, bu nedenle insanlar varsayılan olarak buna gider, ancak alış işlemini atlarsanız desenleri kaçırırsınız. Aynı switch üzerinde üç kişi aynı saatte aynı yavaşlığı bildirirse, bu kötü sürücüsü olan bir dizüstü bilgisayardan farklı bir bilettir.

Düzeltmeden önce tekrarlayın

Bir sorunu tekrarlayamazsa, düzelttiğinizi doğrulayamazsınız. Kullanıcıdan ekran paylaşımında tam adımları yapmasını isteyin ya da uzak araçlar izin veriyorsa makinelerinde bunu kendiniz yapın. Windows üzerinde ipconfig /all ya da Linux üzerinde ip a ile temel ağ sağlığını kontrol edin, bildirilen zaman etrafındaki uygulama ve sistem hataları için Event Viewer (eventvwr.msc) bakın ve Linux kutuları için journalctl -xe --since "1 hour ago" ile aynı pencereyi kontrol edin.

Uygulama çökmesi için tam yapı numarasını ve işletim sistemi sürümünü alın. "Çöktü" size hiçbir şey söylemez; "Outlook 16.0.17726, .ics eki olan takvim daveti açarken çöküyor" nereye bakacağınızı söyler. Bunu yerel olarak varsaymadan önce satıcı sürüm notlarındaki bilinen sorunlarla karşılaştırın.

En çok bağıranlara göre değil, etkiye göre sınıflandırın

Tek bir kullanıcının e-postadan kilitlenmesi elverişsiz. Paylaşılan dosya sunucusunun kırk kişi için erişilememesi bir kesintisidir. Basit bir önem ölçeği oluşturun — P1 birden çok kullanıcıyı veya kritik sistemleri etkileyen kesintiler, P2 tek kullanıcılı engeller, P3 bozuk ama çalışan, P4 kozmetik veya kolaylık istekleri gibi bir şey — ve bir yöneticiyi etkileyen şeyini ilk sırada istediğinin baskısı altında bile tutarlı bir şekilde uygulayın.

Önem kararını bilette belgeleyin. Bu, birisi neden P3'ü iki gün beklettiniz ve üç P1'i hallettiniz diye sorduğunda sizi korur.

Semptomları değil, kök nedeni düzeltin

Çöken bir hizmeti yeniden başlatmak zaman kazandırır, çözüm değil. Yazıcı kuyruğu günde ölürse, yeniden başlatmadan önce gerçek hata için Get-WinEvent -LogName Application -MaxEvents 50 kontrol edin. Kullanıcının parolası beklenmedik şekilde süresi dolarsa, yalnızca sıfırlamak ve devam etmek yerine kendi OU'larına uygulanan grup ilkesini kontrol edin.

Recurring düzeltmelerin kişisel bir günlüğünü tutun. Kendinizi aynı PowerShell komutunu ya da aynı kayıt defteri düzeltmesini üç kez yazarken bulursanız, bu bir betiğe ya da belgelenmiş bir runbook'a ait olduğunun işaretidir, başınızda değil.

Başkasının onu okuyacağını fark ederek belgeleyin

Her bilet çözümü şunu cevaplamalı: gerçek neden ne, düzeltme ne ve bu yeniden olursa ilk ne kontrol edersiniz. Bir çözüm notu olarak "Düzeltildi" sonraki teknisyene, altı ay sonraki gelecek sizin kişinize bu bilet hakkında hiçbir anınız olmadan değersizdir.

İyi bir çözüm notu şöyle görünür: "Kök neden: VLAN 20 üzerindeki DHCP kapsamı tükendi, yeni cihazlar APIPA adresleri aldı. Düzeltme: kapsam /24'ten /23'e genişletildi, yazıcı rezervasyonu eklendi. Doğrulama: DHCP kiralama sayısını aylık kontrol edin, uyarı eşiği %90'da ayarlandı." Üçüncü cümle çoğu teknisyenin atladığı, tekrar bileti önleyen olup.

Sadece iletme değil, bağlamla eskalasyon yapın

Bir bilet tier 2'ye ya da satıcıya gittiğinde, zaten çıkardığınız şeyi ekleyin. "Kablolama kontrol edildi, port değiştirildi, VLAN yapılandırması onaylandı, hala bağlantı ışığı yok" sonraki kişinin ilk yirmi dakikanızı yeniden yapmaktan kurtarır. "Kullanıcı bozuk olduğunu söylüyor, lütfen tavsiyelendir" gibi belirsiz eskalasyonlar gecikmeyi kaldırmak yerine taşır.

Döngüyü kullanıcıyla kapatın

Kullanıcıya sadece "düzeltildi" değil, düz dilde ne olduğunu söyleyin. İnsanlar destek hakkında ne olduğunu anladığında daha çok güven duyarlar ve aynı kişinin bir ay sonra aynı bileti açmasını keser çünkü bağlantılı olduğunu anlamaz.

Bunun teknik tarafında daha derine gitmek istiyorsanız — ağ temelleri, Windows olay günlükleri ya da kendi tanı araçlarınızı betikleme — Korra Studio'nun Ağ, Sistemler ve Betik oluşturma kısımları sonra çalışmaya değer.