BT olaylarını kayıttan kapanışa yönetmek: süreç, öncelik ve eskalasyon
BT olay yönetimi süreci nasıl işler: kayıt, önceliklendirme matrisi, eskalasyon, büyük olay müdahalesi, ölçüm ve sık yapılan hatalar örneklerle.
Olay yönetimi nedir, neyi çözer?
BT olay yönetimi (incident management), bir BT hizmetinde plansız kesinti ya da kalite düşüşü yaşandığında hizmetin olabildiğince hızlı normale döndürülmesini hedefleyen süreçtir. Önemli nokta, hedefin kök nedeni bulmak değil, hizmeti geri getirmek olmasıdır. Sunucunun neden çöktüğünü araştırmak problem yönetiminin işidir; olay yönetimi önce çözüm ya da geçici çözümle kullanıcıyı çalışır duruma getirir.
Olay ile hizmet talebini karıştırmamak gerekir. Çalışan yeni bir yazılım yüklenmesini istiyorsa bu bir hizmet talebidir; yüklü uygulama açılmıyorsa olaydır. Olay, bozulan bir şeyin onarılmasıyla ilgilidir. Yine olay, sorun (problem) ve değişiklik kavramlarından ayrıdır: tekrarlayan olayların ortak nedeni problem kaydına, kalıcı çözüm için yapılan düzeltme değişiklik sürecine akar. Bu sınırların net olması, kayıtların doğru sınıflanmasını ve doğru ekibe gitmesini sağlar.
Olay yaşam döngüsü: kayıttan kapanışa
Çoğu kurumda olay şu aşamalardan geçer. Tespit: olay kullanıcı bildirimiyle ya da izleme aracının otomatik uyarısıyla ortaya çıkar. Kayıt: olay bir kayıt sistemine, yeterli bilgiyle girilir (kim etkileniyor, ne zaman başladı, hangi hizmet, hangi hata mesajı). Sınıflandırma: olay kategori ve etkilenen hizmetle etiketlenir. Önceliklendirme: etki ve aciliyet birlikte değerlendirilerek öncelik verilir. Yönlendirme: olay ilk seviye destekten uzman ekibe aktarılır. Araştırma ve tanı: sebep daraltılır, çözüm ya da geçici çözüm uygulanır. Çözüm ve kapanış: kullanıcı onayı alınır, kayıt kapatılır, bilgi tabanına not düşülür.
Bu yaşam döngüsünün kalitesi kayıt kalitesine bağlıdır. "Çalışmıyor" gibi tek satırlık bir kayıt, ekibi aylarca yanlış yönlendirebilir. Kayıt formunda zorunlu alanlar, bilinen olaylar için hazır şablonlar ve kullanıcıya yönelik net sorular kayıt kalitesini artırır. İlk temasta çözülen olay oranını yükseltmek de kayıt ve bilgi tabanının birlikte çalışmasına bağlıdır.
Önceliklendirme matrisi nasıl kurulur?
Önceliklendirme olay yönetiminin en çok tartışılan noktasıdır, çünkü herkes kendi sorununu acil sayar. Çözüm, öznel değerlendirmeyi etki ve aciliyet matrisine bağlamaktır. Etki, olayın ne kadar kullanıcıyı ya da iş sürecini etkilediğidir (tek kullanıcı, bir departman, tüm kuruluş, müşteriye dönük hizmet). Aciliyet, işin ne kadar beklemeye dayanabileceğidir (iş durdu mu, çözüm gecikirse zarar büyüyor mu).
Matristeki her kesişim bir öncelik düzeyi verir ve her düzeyin yanıt ile çözüm hedefi tanımlanır. Matrisi kurarken dikkat edilecekler: etki sınıflarını iş dilinde tanımlayın ("tüm şubede satış yapılamıyor" gibi), hedef süreleri hizmet seviyesi sözleşmeleriyle uyumlu tutun, kritik hizmet listesi çıkarıp o hizmetlerdeki kesintilere otomatik yüksek öncelik verin ve matrisin zaman içinde ne kadar doğru çalıştığını kalibrasyon toplantılarıyla gözden geçirin. Sıkça yapılan hata, kayıtların büyük bölümünün en yüksek öncelikle açılmasıdır; bu durumda öncelik anlamını yitirir.
Büyük olaylarda müdahale ve iletişim
Her olay sıradan bir destek kaydı değildir. Birçok kullanıcıyı ya da kritik hizmeti etkileyen büyük olaylarda ayrı bir müdahale yapısı kurulur. Olay komutanı müdahaleyi koordine eder, teknik ekipler çözüme odaklanır, bir iletişim sorumlusu da paydaşlara düzenli bilgi verir. Rollerin ayrılması önemlidir: çözümle uğraşan mühendis aynı anda yönetime bilgi vermeye çalışırsa ikisi de aksar.
İletişim protokolü önceden hazırlanmalıdır: kime, hangi kanaldan, hangi sıklıkla bilgi verilecek? Kullanıcıya durum sayfası ya da kısa duyuru, yönetime etki ve tahmini çözüm süresi, teknik ekibe ayrı bir müdahale kanalı. Bilinmeyen konuda kesin süre vaat etmek yerine "bir sonraki güncelleme şu saatte" demek güveni korur. Nöbet (on-call) düzeni de bu yapının parçasıdır: mesai dışında kimin, hangi uyarıda, nasıl devreye gireceği ve yorgunluğu önleyecek rotasyon baştan tasarlanır. Kalitesiz uyarılar nöbetçiyi sürekli yanlış alarmla uyandırır; bu yüzden hangi uyarının insan müdahalesi gerektirdiğini ayıklamak gerekir.
Örnek senaryo: kurumsal e-posta kesintisi
Örneğin bir sabah birçok çalışan e-posta gönderemediğini bildirir. Destek masası ilk bildirimlerde benzer şikayetleri ayırt eder ve bunları tek bir olay altında birleştirir. Etki kapsamı geniş olduğundan olay yüksek öncelikle işaretlenir ve yönlendirme ilgili mesajlaşma ekibine yapılır. Bu sırada iletişim sorumlusu çalışanlara kısa bir duyuru yayınlar.
Ekip son değişiklikleri inceler ve bir önceki akşamki yapılandırma güncellemesini şüpheli bulur. Hızlı çözüm olarak güncellemeyi geri alırlar; hizmet normale döner. Olay burada kapanır, ancak tekrar etmemesi için kök neden araştırması problem kaydıyla ve değişiklik süreci iyileştirmesiyle devam eder. Kapanış sonrasında kısa bir olay sonrası değerlendirme yapılır: ne zaman fark edildi, ne kadar sürede müdahale edildi, hangi bilgi eksikti, iletişim yeterli miydi? Suçlama yapmayan bu değerlendirme, süreç iyileştirmenin asıl kaynağıdır.
Ölçüm, otomasyon ve sık yapılan hatalar
Süreç yönetilebilmek için ölçülmelidir. Sık kullanılan göstergeler: olayın tespitinden çözümüne kadar geçen ortalama süre, hedef süre içinde çözülen olay oranı, ilk temasta çözülen olay oranı, yeniden açılan olay oranı ve tekrar eden olayların payı. Tek bir göstergeye bakmak yanıltır; çözüm süresi kısalırken yeniden açılan olay artıyorsa sorun hızlı ama kalitesiz kapatılıyor demektir.
Otomasyon alanları: izleme aracından olay kaydının otomatik açılması, kayıt sırasında kategori önerisi, bilinen olaylar için self servis çözüm adımlarının kullanıcıya sunulması ve eskalasyon kurallarının zamana bağlı çalıştırılması. Otomasyon süreç oturduktan sonra eklenmelidir; bozuk bir süreci otomatikleştirmek bozukluğu hızlandırır.
Sık hatalar: olay ile talebi aynı kuyrukta yönetmek, kayıt kalitesini önemsememek, önceliklendirmeyi öznel bırakmak, çözülmeyen olayı sahipsiz bırakmak, bilgi tabanını güncellememek ve kapanıştan sonra öğrenme adımını atlamaktır.
Nasıl öğrenilir, Mindset bağlamı
Bu beceriyi geliştirmek için önce temel kavramları (olay, talep, problem, değişiklik) ayırmayı, sonra kendi kurumunuzdaki örnek bir olayı yaşam döngüsü adımlarıyla haritalamayı deneyin. Ardından önceliklendirme matrisi ve eskalasyon kurallarını yazılı hale getirin. İleri aşamada büyük olay yönetimi, nöbet tasarımı ve otomasyon gelir.
Mindset kataloğunda bu konuya yönelik ilgili programlar vardır. Olay Yönetimi (Incident Management) Süreç Tasarımı ve Otomasyonu; kayıt, sınıflandırma ve kayıt kalitesi, önceliklendirme matrisi ve kalibrasyon, yönlendirme, eskalasyon ve bilgi yönetimi, otomasyon ve self servis, ölçüm ve sürekli iyileştirme modüllerini içerir. Olay Yönetimi ve On-Call Süreç Tasarımı ise olay yönetimi çerçevesi, nöbet rotasyonu, uyarı kalitesi ve eskalasyon, olay komutanlığı, iletişim protokolleri ve ölçüm ile öğrenme üzerine kuruludur.
İlgili Mindset programı
Olay Yönetimi (Incident Management) Süreç Tasarımı ve Otomasyonu
Sık sorulan sorular
Olay yönetimi ile problem yönetimi arasındaki fark nedir?
Olay yönetimi hizmeti hızla normale döndürmeye odaklanır; geçici çözüm kabul edilebilir. Problem yönetimi ise olayların altındaki kök nedeni bulup kalıcı çözüm üretir. Biri yangını söndürür, diğeri yangının neden çıktığını araştırıp tekrarını önler.
Olay ile hizmet talebi nasıl ayrılır?
Olay, çalışması gereken bir şeyin bozulmasıdır: uygulama açılmıyor, ağ yavaş. Hizmet talebi ise standart bir şeyin istenmesidir: yeni yazılım yükleme, erişim izni. Farklı süreçler ve hedef süreler gerektirdiğinden aynı kuyrukta yönetilmeleri önceliği bulanıklaştırır.
Önceliği kim belirler?
Öncelik etki ve aciliyet matrisinden türer, kişisel kanaatten değil. Kayıt açan kişi etkiyi bildirir, destek masası matrise göre önceliği atar. Anlaşmazlık olursa kalibrasyon toplantısında matris gözden geçirilir. Kritik hizmetler için otomatik yüksek öncelik tanımlamak da yaygındır.
Olay yönetimi için hangi araçlar kullanılır?
Bir hizmet yönetimi aracı (kayıt, iş akışı, bilgi tabanı), izleme ve uyarı araçları ile iletişim kanalları gerekir. Araç seçimi sürecin yerine geçmez; önce kayıt kalitesi, öncelik ve eskalasyon kuralları tanımlanmalı, araç bunları uygulayan altyapı olarak yapılandırılmalıdır.
Olay sonrası değerlendirme neden suçlamasız yapılır?
Amaç kişiyi bulmak değil, sistemin ve sürecin zayıf noktalarını görmektir. Suçlama korkusu olan ekip hataları gizler ve öğrenme fırsatı kaybolur. Suçlamasız değerlendirme zaman çizelgesini, eksik bilgiyi ve iyileştirme aksiyonlarını açıkça konuşmayı mümkün kılar.
İlgili rehberler
İlgili eğitimler
Kategori: BT Yönetişimi ve Stratejisi, DevOps ve Bulut Teknolojileri