GLPI Helpdesk: Ticket Sistemi ve SLA Yönetimi

GLPI helpdesk modülü, kuruma gelen destek taleplerini kayıt altına alan, önceliklendiren ve çözüm sürecini takip eden bir yardım masası sistemidir. Ticket adı verilen kayıtlar üzerinden çalışır: her talep açılır, bir teknisyene atanır, çözülür ve kapatılır. SLA tanımları ise bu döngüye süre koyar, yani hangi talebe ne kadar sürede dönüleceğini taahhüt eder.

GLPI Agent ile envanteri kurduğumuzda kadastro benzetmesini kullanmıştık: envanter, neyin nerede olduğunu ölçen ve kaydeden defterdir. Yardım masası ise başka bir defterdir. Bir şey bozulduğu anda sorulan soru değişir çünkü: artık “bu cihaz kimde” değil, “ne oldu, kim baktı, ne zaman çözüldü” sorulur. Birincisi varlığı, ikincisi o varlığın başına geleni tutar.

Bu ikinci defterin çalışma biçimi hastane acil servisine benzer. Gelen herkes sırayla değil, aciliyetine göre görülür; kimin önce alınacağına triyaj karar verir ve her vaka için bir müdahale süresi hedefi vardır. Bu rehber, o triyaj masasını GLPI üzerinde kurmayı anlatıyor.

Rehber, kurulmuş ve giriş yapılabilen bir GLPI sunucusunu varsayar. Sunucu henüz hazır değilse GLPI kurulumu rehberinden, altındaki işletim sistemi katmanı için de Ubuntu Server kurulumu rehberinden başlayın. Kullanıcı, profil ve yetki tarafı ise GLPI yönetimi rehberinde ele alınıyor.

Ticket yapısını zaten kurduysanız doğrudan SLA tanımlamaya, talep akışını kurgulayacaksanız ticket oluşturma yöntemlerine geçebilirsiniz.

GLPI Ticket Sistemine Giriş

Ticket, bir destek talebinin sistemdeki karşılığıdır ve açıldığı andan kapandığı ana kadar tek bir kayıt üzerinden izlenir. GLPI’da her ticket’ın bir numarası, bir talep edeni, bir kategorisi, bir önceliği ve bir sorumlusu vardır; bunların hepsi talep hayattayken değişebilir ama hiçbiri kaybolmaz.

Yaşam döngüsü dört durakta ilerler. Açılış, talebin sisteme girdiği andır ve kaynak fark etmez: kullanıcı portalden açar, teknisyen telefonla gelen talebi kaydeder ya da e-posta otomatik ticket’a dönüşür. Atama, talebin bir teknisyene ya da gruba bağlandığı andır; bu ana kadar geçen süre yardım masasının en kritik ölçüsüdür, çünkü kullanıcı için “kimse ilgilenmiyor” hissi tam burada oluşur. Çözüm, işin yapıldığı ve teknisyenin çözümü kaydettiği aşamadır. Kapatma ise talebin resmen bittiği, çoğu kurumda talep edenin onayına bağlanan son adımdır.

Acil serviste bir hastanın kaydı açılır, triyajda önceliklendirilir, bir hekime yönlendirilir ve tedavi bittiğinde taburcu edilir. Yardım masasının farkı yalnız kayıt tutmasıdır: hasta taburcu edildikten sonra dosya kapanmaz, cihazın geçmişinde durur ve bir sonraki arızada kimse sıfırdan başlamaz.

Ticket açarken doldurulan alanlardan biri de türdür ve iki seçenek sunar. Olay (Incident) bozulmuş bir şeyi ifade eder: çalışan bir hizmet durmuş ya da kalitesi düşmüştür, amaç onu eski haline döndürmektir. Talep (Request) ise bozulan bir şeyin olmadığı, yeni bir şeyin istendiği durumdur: yazılım kurulumu, erişim yetkisi, yeni donanım.

Ayrım kayıt tutma hevesinden değil, ölçmenin anlamlı kalmasından doğuyor. İkisi aynı havuzda toplandığında “ortalama çözüm süresi” diye bir sayı çıkar ama hiçbir şey ifade etmez, çünkü on dakikada biten bir parola sıfırlama ile üç gün süren bir donanım değişimi aynı ortalamaya girer. Ayrıca arıza sayısındaki artış altyapı sorununa işaret ederken, talep sayısındaki artış çoğu zaman kurumun büyüdüğünü gösterir; ikisi karışırsa hiçbiri okunamaz.

Ticket Kategorileri Oluşturma

Kategori, talebin ne tür bir iş olduğunu söyleyen etikettir ve raporlamanın tamamı buna dayanır. GLPI’da kategoriler Kurulum > Açılır Listeler > ITIL Kategorileri (Setup > Dropdowns > ITIL categories) altında tanımlanır ve iç içe geçmiş bir ağaç yapısı kurulabilir: Donanım altında Yazıcı, Laptop, Monitör gibi alt kategoriler açılır.

Kategori kurgusunda en sık yapılan hata, baştan çok ayrıntıya inmektir. Otuz kategoriyle başlayan bir kurulum, altı ay sonra teknisyenlerin çoğunu boş bıraktığı ya da hepsini Diğer seçtiği bir listeye döner. Dört ile altı ana kategoriyle başlayın; hangi alt kırılımların gerçekten gerektiğini üç aylık rapor zaten size söyler.

Başlangıç için işe yarayan bir set şudur: Donanım Arızası, Yazılım Sorunu, Erişim Talebi, Ağ Sorunu. Bu dördü, bir BT biriminin aldığı talebin büyük çoğunluğunu karşılar ve birbirine karışmaz. Lab ortamımızda da bu dörtlüyle başladık ve rehberin geri kalanındaki örnekler bu kategoriler üzerinden ilerliyor. Beşinci kategori olarak Talep ve Bilgi eklenebilir; arıza olmayan, “şu programı kurar mısınız” türü istekler oraya düşer ve arıza istatistiğini bozmaz.

Triyaj masasında hastalar da önce kabaca ayrılır: travma, dahiliye, kardiyoloji. Kimse gelir gelmez kesin teşhis yazmaz, çünkü kesin teşhis muayenenin işidir. Kategori de öyle: talebin nereye ait olduğunu söyler, ne olduğunu değil.

Kategori ağacını kurarken iki teknik ayrıntı işinizi kolaylaştırır. Birincisi, kategorinin görünürlüğüdür: GLPI’da her kategori için talep edenlerin görüp göremeyeceği ayrı ayrı belirlenir. Kullanıcıya yalnız anlayacağı kategorileri gösterin; Sunucu veya Veritabanı gibi teknik kırılımlar teknisyen tarafında kalsın. İkincisi, kategoriye varsayılan atama bağlanabilmesidir; ağ sorunları otomatik olarak ağ ekibine düşer ve talep havada kalmaz.

Kategoriyi sonradan değiştirmek mümkündür ama raporlama açısından bedeli vardır: geçmiş talepler eski kategoriyle kayıtlı kalır, yani üç aylık karşılaştırma bozulur. Bu yüzden ilk kurulumda az sayıda kategoriyle başlamak, sonradan bölmekten daha ucuzdur. Bölmek yeni kategori açmak demektir ve eski kayıtlar olduğu yerde durur.

Öncelik Seviyeleri ve Aciliyet Matrisi

GLPI’da öncelik doğrudan seçilmez, iki girdiden hesaplanır: Aciliyet (talep eden için ne kadar acil) ve Etki (kaç kişiyi etkiliyor). Bu ikisinin kesişimi önceliği belirler ve matris Yönetim > Varlıklar yapılandırmasında düzenlenebilir.

Ayrımın pratikteki değeri şudur: aciliyet özneldir, etki nesneldir. Talebi açan herkes kendi işini acil görür, bu insani ve tartışılacak bir şey değildir. Ama kaç kişinin etkilendiği tartışmaya kapalıdır. Öncelik bu ikisinin çarpımı olduğunda, “benim işim daha acil” konuşması yerini “kaç kişi etkileniyor” sorusuna bırakır.

GLPI her iki alanı da beş kademede tutar: Çok düşük, Düşük, Orta, Yüksek, Çok yüksek. Kesişimler matriste tanımlıdır ve önceliği sistem hesaplar; alan formda salt okunur değildir ama elle değiştirmek matrisin amacını ortadan kaldırır.

Lab ortamımızda Çok yüksek aciliyet ile Düşük etki seçildiğinde önceliğin Orta olarak hesaplandığını doğruladık; tablodaki karşılık da budur. Mantık okunduğunda kendini gösteriyor: tek bir kullanıcının yavaş çalışan bilgisayarı, ne kadar acil bildirilirse bildirilsin, tüm kurumun erişemediği dosya sunucusuyla aynı kutuya düşmüyor. Acil serviste de göğüs ağrısıyla gelen hasta kesik parmakla gelenin önüne geçer; sıra numarası değil, durumun ağırlığı belirler.

Ticket Oluşturma Yöntemleri

Bir yardım masasının başarısı, talebin sisteme ne kadar kolay girdiğiyle ölçülür. Kayıt zorlaştıkça insanlar eski alışkanlığa döner, yani koridorda yakalayıp sözlü söyler; o talep de hiçbir yerde görünmez. Bu yüzden GLPI üç ayrı giriş kapısı sunar ve üçünün de açık olması gerekir.

Acil servisin de tek girişi yoktur: kendi imkânıyla gelen hasta ön kabule uğrar, ambulansla gelen doğrudan içeri alınır, sevkle gelenin evrağı önden ulaşır. Kapılar farklıdır ama hepsi aynı kayıt sistemine bağlanır.

Üç kapı arasındaki fark, talebin sisteme ne kadar eksiksiz girdiğidir. Portalden açılan talep, kullanıcının doldurduğu alanlar kadar bilgi taşır. E-postayla gelen talep genellikle serbest metindir; kategorisi ve etkisi sonradan doldurulur. Telefonla gelen talep ise sisteme ancak teknisyen kaydettiği kadar girer, yani en çok kayıp verdiği yer burasıdır.

Bu yüzden kurulumun ilk aylarında ölçülmesi gereken şey çözüm süresi değil, kaç talebin sisteme hiç girmediğidir. Bunu doğrudan ölçemezsiniz ama dolaylı bir göstergesi vardır: ekibin fiilen çalıştığı saat ile kayıtlı taleplerin toplam süresi arasındaki fark açıksa, o fark kayıt dışı işi gösterir.

Arayüzden Manuel Ticket Açma

Manuel açma, hem teknisyenin hem son kullanıcının kullandığı temel yöntemdir ve iki farklı arayüzü vardır. Teknisyen tarafında yol Yardım Masası > Talepler (Assistance > Tickets) üzerinden geçer ve tam form açılır; kategori, etki, atama, öğe ve hizmet seviyesi alanları buradadır. Kullanıcı ise self-service arayüzünde sadeleştirilmiş bir form görür: talebin başlığı, açıklaması ve aciliyeti.

Formda doldurulması en çok atlanan ama en değerli alan, sağ paneldeki Öğeler (Items) bölümüdür. Talep bir cihaza bağlandığında, o cihazın envanter kaydı ticket’ın içinden erişilebilir hale gelir: donanımı, kurulu yazılımları, kullanıcısı ve daha önce hangi taleplerle geldiği. Envanteri kurmuş olmanın yardım masasına yaptığı katkı tam olarak budur, iki defter burada birleşir. Bu bağın 1.500 cihazlık bir kurumda ne anlama geldiğini GLPI envanter sistemi vaka çalışmasında anlatıyoruz.

Bölüm iki yol sunar. Cihazlarım (My devices), talebi açan kullanıcıya zimmetli cihazları listeler ve son kullanıcı portalinde işe yarayan yol budur. Teknisyen başkası adına kayıt açıyorsa Tam arama (Or complete search) seçeneğini kullanır; burada önce tür seçilir (Computer, Printer, NetworkEquipment), ardından o türe ait envanter listesi açılır ve cihaz oradan seçilir. Doğrudan bir arama kutusuna cihaz adı yazılmaz, bu ilk kez yapanları şaşırtır.

Alanı ticket açarken bulamazsanız telaşlanmayın; talebi kaydettikten sonra detay sayfasındaki Öğeler sekmesinden de bağlayabilirsiniz, ikisi de aynı kaydı üretir.

Bu bölümün arayüzü ilk bakışta yanıltıcıdır. TTO ve TTR etiketlerinin altında birer tarih kutusu görürsünüz ve SLA seçmek için bir liste ararsınız, ama liste görünmez. Tarih kutusu SLA seçmek için değil, son tarihi elle girmek içindir. SLA’yı bağlamak için kutunun yanındaki kronometre simgesine tıklamanız gerekir; simge bir onay penceresi açar, onayladıktan sonra seçim listesi görünür hale gelir.

Listeler türe göre filtrelenir: TTO satırında yalnız Time to own türündeki kayıtlar, TTR satırında yalnız Time to resolve olanlar çıkar. Süreleri iki ayrı kayıt olarak tanımlamış olmanızın karşılığı burada ortaya çıkar; tek kayıtla ilerlenseydi bu listelerden biri boş kalırdı.

Aynı bölümdeki Internal TTO ve Internal TTR alanları ise SLA’ya değil OLA’ya, yani ekipler arası iç anlaşmaya aittir. Tek ekipli kurumlarda boş bırakılır.

Talebi kaydetmeden önce Aktörler (Actors) bölümünü de doldurun. Talep edeni belirtmeyen bir ticket sahipsiz kalır: kapanış bildirimi gidecek kimse olmaz ve rapor tarafında hangi kullanıcının ne kadar talep açtığı görünmez. Teknisyen başkası adına kayıt açıyorsa bu alan, telefonla gelen talebin gerçek sahibini sisteme yazan tek yerdir.

Bir hastanın dosyasına bakmadan tedaviye başlamak ile geçmiş tahlillerini görerek başlamak arasındaki fark budur. Üçüncü kez aynı şikâyetle gelen hasta, tek tek bakıldığında üç ayrı vakadır; dosya birleştirildiğinde kronik bir durum olduğu görülür.

Formda dikkat edilecek diğer alanlar şunlardır. Başlık alanı arama sonuçlarında görünen tek şeydir; “sorun var” diye açılmış bir talep, iki hafta sonra kimsenin bulamayacağı bir kayıttır. Açıklama alanına yalnız şikâyet değil, denenenler de yazılmalıdır, çünkü talep başka bir teknisyene devredildiğinde tek bilgi kaynağı orasıdır. Atanan alanı boş bırakıldığında talep havada kalır; GLPI’da atanmamış talepleri otomatik olarak bir gruba yönlendiren kurallar tanımlamak, bu boşluğu kapatmanın en pratik yoludur.

Sık tekrarlanan talepler için şablon kullanmak da mümkündür. Yeni personel açılışı, yazıcı kurulumu veya erişim yetkilendirmesi gibi standart işlerde şablon, kategori ve öncelik alanlarını önceden doldurur; teknisyen yalnız kişiye özel bilgileri girer. Aynı işi yirmi kez yazmak yerine bir kez tanımlamak, kayıt disiplininin sürdürülebilir olmasını sağlar.

E-posta ile Otomatik Ticket (Mail-to-Ticket)

Mail-to-ticket, belirlenen bir posta kutusuna gelen e-postaların otomatik olarak ticket’a dönüşmesini sağlar. Kullanıcı alışık olduğu adrese yazmaya devam eder, sistem arka planda kaydı açar, numara verir ve gönderene bildirim döner. Yapılandırma Yönetim > Alıcılar bölümünde bir posta hesabına IMAP veya POP3 erişimi tanımlanarak yapılır.

Bu yöntemin asıl değeri geçiş dönemindedir. Yeni bir sistem kurduğunuzda en büyük direnç, insanlardan alışkanlıklarını değiştirmelerini istemekten doğar. Mail-to-ticket bu isteği ortadan kaldırır: kullanıcı davranışını hiç değiştirmez, ama talep artık kayıt altına girer. Kayıt disiplini yerleştikten sonra portale geçiş çok daha kolay olur.

Dikkat edilecek iki nokta var. Birincisi, gelen her e-postanın ticket olmadığıdır; otomatik bildirimler, bülten ve spam aynı kutuya düşerse yardım masası çöp kayıtla dolar, bu yüzden bu iş için ayrı bir adres kullanın. İkincisi, e-postayla açılan taleplerde kategori ve etki alanları boş gelir; teknisyenin ilk işi bunları doldurmaktır, aksi halde raporlama tarafında bu talepler görünmez olur.

Telefon ve Şahsen Talepler İçin Ticket

Telefonla veya yüz yüze gelen talepler, yardım masasının en çok kayıp verdiği yerdir. Teknisyen sorunu zaten çözmüştür, kaydetmek fazladan iş gibi görünür ve o talep hiçbir yere yazılmaz. Ay sonunda çıkan rapor gerçek yükün yarısını gösterir; ekibin ne kadar çalıştığı görünmez olur, yeni personel talebi de dayanaksız kalır.

Çözüm, teknisyenin talebi başkası adına açabilmesidir. GLPI’da ticket açarken talep eden alanı teknisyenden bağımsızdır; kaydı siz açar, talep edeni ilgili kullanıcı olarak seçersiniz. Böylece kullanıcı hiçbir şey yapmadan talep sisteme girer ve kapanış bildirimini alır.

Pratik kural şudur: beş dakikadan uzun süren her müdahale kaydedilir. Bu eşik keyfi görünebilir ama işe yarar, çünkü tartışmayı bitirir. Kayıt tutmanın amacı teknisyeni denetlemek değil, işin görünür olmasıdır; görünmeyen iş, bütçe ve kadro konuşmalarında yok sayılır.

Kaydın ne zaman girildiği de önemlidir. İş bittikten günler sonra toplu girilen talepler, süre ölçümlerini anlamsızlaştırır: açılış ve kapanış aynı dakikaya düştüğü için ortalama çözüm süresi gerçek dışı biçimde iyi görünür, SLA raporu da hiçbir şey ölçmez. Talep alındığı anda açılmalı, çözüldüğünde kapatılmalıdır. Bu mümkün olmuyorsa sorun disiplinde değil, kaydın fazla zahmetli olmasındadır; formu sadeleştirin.

Telefonla gelen taleplerde bir alışkanlık daha kazandırmak gerekir: kullanıcıya talep numarasını söylemek. Numara verildiğinde iki şey olur. Kullanıcı talebinin kayda geçtiğini bilir, yani aynı işi tekrar anlatmak için ertesi gün aramaz. İkincisi, o numara üzerinden geri dönüş yapıldığında sistemin işlediğini görür ve bir sonraki talebi portalden açma ihtimali artar.

SLA (Hizmet Seviyesi Sözleşmesi) Tanımlama

SLA, bir talebe ne kadar sürede dönüleceğinin ve ne kadar sürede çözüleceğinin yazılı taahhüdüdür. GLPI’da SLA tanımları doğrudan açılmaz; önce bunları kapsayan bir Hizmet Seviyesi (SLM) kaydı oluşturulur, SLA’lar onun altına eklenir. Yapılandırma Kurulum > Hizmet Seviyeleri (Setup > Service levels) bölümünde yapılır.

Hizmet seviyesi kaydı iki alan ister: bir ad ve bir takvim. Ad, altına ekleyeceğiniz SLA’ları gruplayan başlıktır; kurumun tamamı için tek bir seviye çoğu zaman yeterlidir. Takvim ise sürelerin hangi saatlerde işleyeceğini belirler ve varsayılan olarak 24/7 gelir.

Bu hatayı lab ortamımızda birebir yaşadık ve teşhis etmesi kolay olmadı; beyaz ekranın sebebini ancak sunucudaki PHP hata günlüğünde görebildik. Takvim atamanın davranışsal gerekçesi zaten vardı: mesai saatleri tanımlı değilse süreler gece boyunca ve hafta sonu da akar, cuma akşamı açılan bir talep pazartesi sabahı çoktan ihlal edilmiş görünür. Şimdi buna teknik bir gerekçe de eklendi.

Takvimi atadıktan sonra ikinci bir hatayla karşılaştık ve o ancak sürüm yükseltmesiyle çözüldü: GLPI, tamsayı olan bir sütuna boş metin göndermeye çalışıyor ve MariaDB katı kipte (STRICT_TRANS_TABLES) bunu reddediyor. Belirti yine aynı, yani beyaz ekran; bu kez iz sql-errors.log dosyasında. Kurulumu 10.0.12’den 10.0.26’ya yükselttiğimizde iki sorun da ortadan kalktı.

Buradan çıkan genel ders şu: GLPI kurulumlarında yama sürümlerini takip etmek kozmetik bir iş değil. Yaşadığımız iki hatanın ikisi de güncel PHP ve MariaDB sürümleriyle eski bir GLPI’nin yan yana gelmesinden doğuyordu; ikisi de arayüzde hiçbir ipucu vermiyordu.

Süreler, hizmet seviyesinin altında ayrı kayıtlar olarak tutulur ve her kaydın bir türü vardır. Yani yanıt süresi ile çözüm süresi tek bir formda birlikte girilmez; ikisi iki ayrı SLA kaydıdır. Türü Time to own olan kayıt talebin sahiplenilme süresini, Time to resolve olan kayıt çözülme süresini tanımlar. Süre alanı da iki parçalıdır: bir sayı ve bir birim; birim varsayılan olarak dakika gelirse 2 yazmak iki saat değil iki dakika demeye gelir.

SLA’nın gerçek işlevi ölçmek değil, önceliklendirmeyi kişisel inisiyatiften çıkarmaktır. Süre tanımı olmayan bir yardım masasında hangi işin önce yapılacağına, o an kimin daha ısrarcı olduğuna bakılarak karar verilir; en yüksek sesle isteyen en hızlı hizmeti alır. Süre konduğunda sıralama kuralın işi haline gelir.

Acil serviste de her triyaj kategorisinin bir hedef müdahale süresi vardır: kırmızı alan hemen, sarı alan belirli dakikalar içinde, yeşil alan sıraya göre. Bu süreler hastanın önemini değil, beklemenin taşıdığı riski ifade eder.

GLPI iki ayrı taahhüt türü tanır ve karıştırılmaları yaygındır. SLA, talep edene verilen sözdür: kullanıcı bu süreleri görür ve bunlara göre beklenti kurar. OLA (Operational Level Agreement) ise ekipler arası iç anlaşmadır; birinci seviye desteğin ikinci seviyeye devrettiği bir talebin ne kadar sürede geri döneceğini tanımlar. Küçük ekiplerde OLA’ya gerek yoktur, ama destek katmanlara ayrıldığında iç gecikmelerin nerede oluştuğunu ancak OLA gösterir.

Süreleri belirlerken önceliğe göre farklılaştırın. Tek bir süre tanımlamak, çok yüksek öncelikli bir kesintiyle sıradan bir yazılım talebini aynı kefeye koyar ve önceliklendirmenin anlamını ortadan kaldırır. GLPI’da her öncelik seviyesi için ayrı SLA tanımlanabilir; matrisi kurduysanız zaten elinizde beş seviye vardır.

Yanıt Süresi (Time to Own) Tanımlama

Yanıt süresi, talebin açılmasından bir teknisyene atanmasına kadar geçen azami süredir ve GLPI’da Time to own olarak tanımlanır. Kullanıcı deneyimi açısından en belirleyici ölçü budur, çünkü bekleyen insan için sessizlik, çözümün gecikmesinden daha rahatsız edicidir.

Süreyi belirlerken ekibin gerçek kapasitesine bakın. İki kişilik bir BT biriminde otuz dakikalık yanıt taahhüdü, aynı anda gelen üçüncü talepte tutmaz. Tutturulamayan bir SLA, birkaç ay içinde herkesin görmezden geldiği kırmızı bir uyarıya dönüşür ve o noktadan sonra hiçbir şey ölçmez. Orta ölçekli bir kurumda yüksek öncelikli talepler için iki saat, normal talepler için dört saat gerçekçi bir başlangıçtır.

Lab ortamımızda yanıt süresini 2 saat olarak tanımladık. Saat 13:50’de açtığımız talebin yanıt son tarihi 15:50 olarak hesaplandı; çözüm süresinin aksine bu tarih aynı gün içinde kaldı, çünkü iki saat mesai bitimine sığıyordu. Aynı talep saat 19:30’da açılsaydı yanıt tarihi ertesi iş gününe sarkacaktı.

Yanıt süresini tutturmanın en pratik yolu, atamayı kişiye değil gruba yapmaktır. Talep doğrudan bir teknisyene atanırsa, o kişi izinliyse veya sahadaysa saat işlemeye devam eder ve kimse fark etmez. Gruba atanan talep ise ekipteki herkesin ekranında görünür; müsait olan sahiplenir. GLPI’da kategoriye göre otomatik grup ataması tanımlamak da mümkündür: ağ sorunları doğrudan ağ ekibine, erişim talepleri sistem ekibine düşer.

Bir noktayı baştan netleştirin: yanıt süresi sorunun çözülmesi değil, sahiplenilmesi demektir. Bu ayrım kullanıcıya da anlatılmalıdır, aksi halde iki saatte dönüş alan ama sorunu çözülmeyen kullanıcı SLA’nın tutmadığını düşünür. Acil serviste de triyaj hemşiresinin hastayı değerlendirmesi tedavinin başladığı anlamına gelmez; sıraya girdiği anlamına gelir ve bu bilgi bile beklemeyi katlanılır kılar.

Çözüm Süresi (Time to Resolve) Tanımlama

Çözüm süresi, talebin açılmasından çözülmesine kadar geçen azami süredir ve Time to resolve olarak tanımlanır. Yanıt süresinden farkı, artık ekibin ne kadar hızlı fark ettiğini değil, işi ne kadar sürede bitirdiğini ölçmesidir.

Bu sürenin belirlenmesinde en sık yapılan hata, kurum dışı bağımlılıkları hesaba katmamaktır. Yedek parça bekleyen bir laptop, tedarikçiden dönüş bekleyen bir lisans talebi ya da kullanıcının müsait olmadığı bir kurulum, teknisyenin elinde olmayan sebeplerle uzar. GLPI’da talebi Beklemede durumuna almak SLA saatini durdurur; bu durumu doğru kullanmak, SLA’nın adil kalmasını sağlayan şeydir.

Çalışma takvimi tanımlamak da aynı sebeple önemlidir. Takvim tanımlanmazsa süreler kesintisiz akar ve cuma akşam beşte açılan bir talep, pazartesi sabahı çoktan ihlal edilmiş görünür. Kurumun mesai saatleri Kurulum > Açılır Listeler > Takvimler altında tanımlanır ve hizmet seviyesine bağlanır. Resmi tatilleri de aynı takvime işlemeyi unutmayın; yılda birkaç kez oluşan bu günler, işlenmediğinde ihlal oranını yapay olarak yukarı çeker.

Takvimin ne yaptığını lab ortamımızda somut olarak ölçtük. Çözüm süresini 8 saat olarak tanımladık ve mesaisi 08:00-20:00 arası, hafta içi çalışan bir takvime bağladık. Cuma günü saat 13:50’de bir talep açtığımızda GLPI çözüm tarihini Pazartesi 09:50 olarak hesapladı. Aradaki mantık şu: cuma gününden 6 saat 10 dakika kullanıldı, kalan 1 saat 50 dakika hafta sonunu atlayıp pazartesi sabahına sarktı. Takvim tanımlı olmasaydı aynı talebin son tarihi cumartesi sabahı 21:50 olacaktı, yani kimsenin çalışmadığı bir saat.

Bu fark küçük görünür ama ihlal istatistiğinin tamamını belirler. Hafta sonu ve gece saatlerini hesaba katan bir SLA, ekibin gerçekten geciktiği durumları gösterir; katmayan bir SLA ise her cuma akşamı yapay ihlal üretir ve birkaç ay içinde kimsenin bakmadığı bir rapora dönüşür.

Çözüm süresini kategoriye göre farklılaştırmak da mantıklıdır. Parola sıfırlama ile sunucu arızası aynı süreye bağlanamaz; birincisi dakikalar, ikincisi günler alabilir. Tek bir çözüm süresi tanımlanan kurulumlarda ekip, uzun süren işleri SLA’yı bozmamak için erkenden kapatıp yeniden açma eğilimine girer. Bu, sistemi kandırmak değil, ölçünün gerçeği yansıtmadığının işaretidir; süreyi düzeltmek gerekir.

Formda dikkat edilecek üç alan var. Tür (Type), kaydın yanıt mı çözüm süresi mi olduğunu belirler ve sonradan değiştirilebilir. Azami süre (Maximum time) sayı ve birim olarak ayrı ayrı seçilir; birim Saat yerine Dakika kalırsa 8 değeri sekiz saat değil sekiz dakika anlamına gelir. Soldaki SLA sekmesindeki sayaç ise o hizmet seviyesine kaç kayıt bağlı olduğunu gösterir.

İkisi de tanımlandığında hizmet seviyesinin altında yan yana dururlar ve her birinin kendi türü, süresi ve takvimi görünür:

Listedeki takvim sütunu, o sürenin hangi saatlerde işleyeceğini gösterir ve hizmet seviyesinden devralınır. İki kaydın takvimi de aynı görünmelidir; farklıysa biri elle değiştirilmiş demektir ve yanıt ile çözüm süreleri farklı zaman ölçülerine göre akmaya başlar.

SLA İhlali Durumunda Eskalasyon

Eskalasyon, süre aşıldığında sistemin kendiliğinden harekete geçmesidir ve GLPI’da SLA’ya bağlı seviyeler (SLA levels) ile kurulur. Her seviye bir zaman koşulu ve bir eylem taşır: süreye şu kadar kala bildirim gönder, süre aşıldığında önceliği yükselt, talebi başka bir gruba ata.

En yaygın ve en işe yarayan kurgu üç kademelidir. Sürenin dolmasına az kala teknisyene hatırlatma gider; bu, ihlallerin çoğunu daha oluşmadan önler. Süre aşıldığında ekip yöneticisine bildirim gider. İhlal belirgin biçimde büyüdüğünde talep otomatik olarak üst gruba devredilir.

Eskalasyonu kurarken akılda tutulması gereken şey, bunun bir ceza mekanizması olmadığıdır. Amaç, gecikmiş bir talebin kimsenin gündeminde olmadan beklemesini engellemektir. Acil serviste de hasta belirlenen sürede görülmediyse sorumlu hekim çağrılır; kimseyi cezalandırmak için değil, vakanın unutulmadığından emin olmak için.

Bildirimlerin kime gideceği en az zamanlaması kadar önemlidir. Her eskalasyonda tüm ekibe e-posta göndermek, birkaç hafta içinde herkesin filtreleyip klasöre attığı bir bildirim akışı üretir; o noktadan sonra gerçek bir kriz de aynı klasöre düşer. Hatırlatma yalnız atanan kişiye, ihlal bildirimi yalnız ekip yöneticisine gitsin. Bildirim ne kadar seyrekse o kadar okunur.

Eskalasyonun bir yan faydası, SLA sürelerinin gerçekçi olup olmadığını ortaya çıkarmasıdır. Belirli bir kategoride eskalasyon sürekli tetikleniyorsa iki ihtimal vardır: ya ekip o alanda yetersiz kalıyordur ya da süre yanlış konmuştur. İkisi de bilinmesi gereken şeydir ve ancak ölçüldüğünde görünür. Eskalasyon bu yüzden yalnız bir uyarı mekanizması değil, aynı zamanda kurgunun kendisini denetleyen bir geri bildirim döngüsüdür.

Helpdesk Raporlama ve İzleme

Yardım masasının ürettiği asıl değer, çözülen taleplerden çok biriken veridir. Üç aylık bir kayıt, kurumun BT yükünü hiçbir toplantının üretemeyeceği netlikte gösterir: talep hangi kategorilerde yoğunlaşıyor, hangi lokasyon daha çok destek istiyor, hangi cihazlar tekrar tekrar arızalanıyor.

GLPI’da raporlar Araçlar > Raporlar altında, anlık görünüm ise gösterge panellerinde bulunur. Yardım masası için gerçekten işe yarayan ölçüler dörttür: açık talep sayısı, ortalama yanıt süresi, ortalama çözüm süresi ve SLA ihlal oranı. Bunların dışındaki her ölçü, ihtiyacı doğduğunda eklenir.

Talep listesinin kendisi de bir izleme aracıdır. Sütunlar arasına Çözüm Süresi eklendiğinde her talebin son tarihi listede görünür hale gelir; böylece hangi işin ne zamana yetişmesi gerektiğini görmek için tek tek kayıt açmanız gerekmez.

Üstteki sayaçlar da aynı işi özet düzeyinde yapar: gelen, atanan, bekleyen, çözülen ve kapatılan talepler ayrı ayrı sayılır. Sabah işe başlarken bakılacak tek ekran budur; sayılardan biri beklenmedik şekilde şişmişse gün oradan planlanır.

Bu verinin en somut karşılığı bütçe konuşmalarındadır. “Ekip yetişemiyor” cümlesi bir görüştür ve tartışılır; “son üç ayda talep sayısı yüzde kırk arttı, ortalama çözüm süresi altı saatten on dört saate çıktı ve SLA ihlal oranı yüzde yirmiye ulaştı” cümlesi ise bir ölçümdür. İkincisi, yeni personel talebini kişisel bir yakınma olmaktan çıkarır.

Tekrar eden arızaların yakalanması da buradan gelir. Aynı cihazdan üçüncü kez talep açıldığında, tek tek bakıldığında üç ayrı iş görünür; envanterle eşleştirilmiş kayıtlar ise değiştirilmesi gereken bir donanımı işaret eder. Yardım masası bu noktada arıza kaydından çıkıp yenileme kararına girdi sağlayan bir araca dönüşür.

İlk üç ay rakamlara temkinli bakın. Yeni kurulan bir sistemde talep sayısı artıyor görünür, ama bu yükün arttığı anlamına gelmez; daha önce kayıt dışı kalan işin görünür hale geldiği anlamına gelir. Aynı şekilde ilk aylarda çözüm süreleri uzun çıkar, çünkü ekip kaydı geciktirerek tutar. Anlamlı karşılaştırma dördüncü aydan sonra başlar; o zamana kadar biriken veriyi kıyaslamak için değil, eğilimi görmek için kullanın.

Raporlarda en çok işe yarayan kırılım kategori değil, lokasyon ve kullanıcı kırılımıdır. Belirli bir şubeden gelen talep sayısı diğerlerinin iki katıysa oradaki altyapıda bir sorun vardır; belirli bir kullanıcı sürekli aynı talebi açıyorsa bu bir eğitim ihtiyacına işaret eder. Bu iki soru, arıza kaydı tutmanın ötesine geçip kurumun BT gerçeğini gösteren yerdir.

Dashboard Özelleştirme

Gösterge paneli, rolüne göre farklı kişiye farklı şey göstermelidir; herkese aynı ekranı vermek, kimsenin bakmadığı bir ekran üretir. GLPI’da paneller Gösterge Panelleri bölümünden düzenlenir ve widget’lar sürükleyerek yerleştirilir.

Teknisyenin panelinde kendi üzerindeki açık talepler, SLA süresi dolmak üzere olanlar ve bugün kapatılanlar bulunmalıdır; yani kendi işini yönetmesini sağlayan şeyler. Yöneticinin panelinde ise ekip geneli görünür: toplam açık talep, kategori dağılımı, ortalama süreler ve ihlal oranı.

Ayrımın sebebi basit. Teknisyene ekip geneli istatistiği göstermek, günlük işini yönetmesine yardım etmez; yöneticiye tek tek talepleri göstermek ise ağaçlara bakıp ormanı kaçırmasına yol açar. Acil serviste de hekim önündeki hastayı görür, başhekim ise bekleme sürelerini ve doluluk oranını.

İlk ay için panelde tutulacak şeyleri az tutun. Çok sayıda widget içeren bir panel, bakılan değil göz gezdirilen bir ekrana dönüşür. Dört göstergeyle başlayın: açık talep sayısı, bugün açılanlar, SLA süresi dolmak üzere olanlar ve kategori dağılımı. Bunlar hem günlük işi yönetmeye hem ilk eğilimleri görmeye yeter.

Panelin gerçekten işe yaradığını anlamanın basit bir testi var: ekip sabah işe başlarken oraya bakıyor mu? Bakmıyorsa panel yanlış kurulmuştur. Doğru kurulmuş bir panel, “bugün neye bakacağım” sorusunun cevabını verir; yanlış kurulmuş olan ise yalnız geçmişi özetler ve o özet zaten raporlardan alınabilir.

Yazan

İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştüren bir ağ ve sistem mühendisidir. Şirketlere özel teknoloji rehberleri burada.