Web Sitesindeki Hata Kayıtları Nasıl Önceliklendirilir? Etki, Sıklık ve Aciliyet Matrisi

Kısa cevap: Bir web sitesi hatasının önceliği yalnızca bildirimi yapan kişinin “acil” demesiyle belirlenmemelidir. Önce hatanın hangi işlevi etkilediği, kaç kullanıcı veya işlemi kapsadığı, ne sıklıkla tekrarlandığı, zaman açısından neden bekleyemeyeceği ve geçici bir çözüm bulunup bulunmadığı kaydedilmelidir. Aynı kök nedene ait yeni bildirimler tek ana kayıtta birleştirilmeli; etki büyüdükçe öncelik yeniden değerlendirilmelidir.

Kumsal Ajans olarak kritik talepleri sistemi, satışı veya temel işlevleri tamamen durduran sorunlar; yüksek talepleri önemli işlev kaybı doğuran sorunlar; normal talepleri ise sistemi durdurmayan hatalar olarak ayırıyoruz. Ancak bu sınıflandırma kayıt açıldığı anda sonsuza kadar sabit kalmaz. Başlangıçta tek kullanıcıyı etkiliyor gibi görünen bir sorun, yeni bilgiler geldikçe daha geniş bir iş etkisine sahip olabilir.

Bu rehberin sonunda hata kayıtlarını aynı alanlarla açabileceğiniz, benzer bildirimleri birleştirebileceğiniz ve öncelik değişikliğini gerekçelendirebileceğiniz bir hata triyaj kartı hazırlayabilirsiniz.

Önem Derecesi ile Öncelik Aynı Şey Değildir

Önem derecesi, hatanın sistem ve iş üzerindeki etkisini anlatır. Öncelik ise ekibin hangi kaydı önce ele alacağına ilişkin çalışma sırasıdır. Bu iki alan çoğu zaman birbiriyle ilişkili olsa da tamamen aynı değildir.

Örneğin yazım hatası düşük etkili olabilir; fakat ertesi sabah başlayacak resmî bir kampanyanın ana mesajındaysa zaman açısından hızlı ele alınabilir. Buna karşılık yalnız belirli koşullarda oluşan teknik bir hata yüksek etkiye sahip olabilir; ancak düzeltme için önce dış servis sağlayıcısından bilgi beklenmesi gerekebilir. Bu durumda önem derecesi düşmez, fakat işin ilerleme durumu “beklemede” olarak kaydedilir.

GitLab'ın issue triage rehberi, kayıt türü, önem derecesi ve öncelik ölçütlerinin önceden tanımlanıp belgelenmesini önerir. Buradaki amaç belirli bir yazılım aracını kopyalamak değil, aynı sorunun farklı ekip üyeleri tarafından benzer ölçütlerle değerlendirilmesini sağlamaktır.

Eksiksiz Bir Hata Kaydında Hangi Bilgiler Bulunmalıdır?

“Sayfa çalışmıyor” veya “form bozuk” ifadeleri incelemeye başlamak için çoğu zaman yeterli değildir. Kumsal Ajans yaklaşımında hata kaydına mümkün olduğunca şu bilgiler eklenir:

1. Ekran veya işlem: Hata hangi sayfada, formda, yönetim işlemi ya da entegrasyonda görülüyor?
2. Tekrar adımları: Sorunu yeniden oluşturmak için hangi işlemler hangi sırayla yapılıyor?
3. Beklenen sonuç: Normal koşulda ne olması gerekiyordu?
4. Gerçekleşen sonuç: Kullanıcı ne gördü veya hangi işlem tamamlanmadı?
5. Ortam ve sürüm: Canlı ya da test ortamı, cihaz, tarayıcı, uygulama veya ilgili sürüm nedir?
6. Destekleyici bilgi ve iş etkisi: Varsa ekran görüntüsü, hata kaydı veya log ile sorun nedeniyle duran ya da aksayan iş nedir?

Bu alanlar teknik ekibin yalnızca hatayı bulmasına yardımcı olmaz. Etkinin tek bir kullanıcıyla mı sınırlı olduğunu, bütün mobil ziyaretçileri mi kapsadığını veya bir dış servis bağlantısında mı oluştuğunu da görünür kılar.

Ekran görüntüsü tek başına yeterli olmayabilir. Görüntü sonucu gösterir; tekrar adımları ve ortam bilgisi ise sonuca nasıl ulaşıldığını açıklar. Log bulunması da otomatik olarak yüksek öncelik anlamına gelmez. Önceliği belirleyen, teknik bulgunun gerçek kullanıcı ve iş süreci üzerindeki etkisidir.

Etki Nasıl Belirlenir?

Etki değerlendirmesinde yalnız “kaç kişi bildirdi?” sorusuna bakmayın. Şu alanları birlikte inceleyin:

• Hangi kullanıcı grubu etkileniyor?
• Temel bir işlev tamamen mi duruyor, kısmen mi çalışıyor?
• Satış, başvuru, ödeme, üyelik veya içerik yönetimi aksıyor mu?
• Veri kaybı, yanlış veri, güvenlik veya gizlilik riski bulunuyor mu?
• Sorun tek sayfada mı, ortak bir bileşen nedeniyle birçok sayfada mı görülüyor?
• Kullanıcı işlemi başka bir yöntemle tamamlayabiliyor mu?

Atlassian'ın olay önem derecesi açıklaması, önem derecesini olayın iş üzerindeki etkisiyle ilişkilendirir ve seviyelerin kurumun kendi bağlamına göre tanımlanması gerektiğini belirtir. Bir iletişim formu, yalnızca destekleyici kanal olduğu bir sitede farklı; bütün satış taleplerinin tek giriş noktası olduğu bir yapıda farklı etki yaratabilir.

Güvenlik veya veri riski içeren kayıtlar ayrıca değerlendirilmelidir. OWASP Risk Rating Methodology, güvenlik risklerinde olasılık ile etkinin birlikte ele alınmasını ve iş etkisinin kuruma göre özelleştirilmesini açıklar. Bu yaklaşım, her web sitesi hatasını güvenlik puanına çevirmek anlamına gelmez. Güvenlik, veri bütünlüğü veya erişim riski bulunan bir kaydın sıradan görsel hatayla aynı ölçütlerde bırakılmaması gerektiğini gösterir.

Sıklık Nasıl Değerlendirilir?

Sıklık, yalnızca toplam bildirim sayısı değildir. Hatanın hangi koşullarda ve ne kadar düzenli oluştuğunu anlatır:

• Her denemede mi oluşuyor?
• Belirli cihaz, tarayıcı, kullanıcı rolü veya ürün grubunda mı tekrarlanıyor?
• Günün belirli saatinde ya da yoğun işlem sırasında mı görülüyor?
• Son güncellemeden sonra mı başladı?
• Aynı kök nedene bağlanan farklı belirtiler var mı?

On kişinin aynı ekran görüntüsünü göndermesi on ayrı hata olduğu anlamına gelmez. Buna karşılık tek bir bildirim, bütün ödeme işlemlerini durduran tekrarlanabilir bir hatayı gösterebilir. Bu nedenle bildirim sayısı, tekrar edilebilirlik ve etkilenen kapsam birlikte okunmalıdır.

Kumsal Ajans yaklaşımında aynı kök nedene ait bildirimler tek ana kayıt altında birleştirilir. Yeni bildirimler ayrı işler açmak yerine ana kayda ek bulgu, ortam ve etki bilgisi olarak eklenir. Böylece ekip aynı sorunu paralel kayıtlar üzerinden tekrar tekrar incelemez ve genişleyen etkiyi tek yerde görebilir.

Aciliyet Ne Zaman Yükselir?

Aciliyet, hatanın neden şimdi ele alınması gerektiğini açıklar. Yüksek etki her zaman aynı zaman baskısını oluşturmayabilir. Aciliyeti artırabilecek durumlar şunlardır:

• Satışın veya temel işlevin tamamen durmuş olması
• Yaklaşan yayın, kampanya, başvuru veya mevzuat tarihi
• Devam eden veri kaybı ya da yanlış kayıt oluşması
• Güvenlik veya yetkisiz erişim ihtimali
• Sorunun hızla daha fazla kullanıcıya yayılması
• İşe yarayan bir geçici çözüm bulunmaması

“Yönetici bildirdi” veya “müşteri çok acil dedi” tek başına aciliyet ölçütü değildir. Aciliyetin hangi iş sonucu veya zaman kısıtı nedeniyle yükseldiği kayıt üzerinde yazılmalıdır.

Etki × Sıklık × Aciliyet Matrisi

Aşağıdaki tablo evrensel bir puanlama standardı veya süre taahhüdü değildir. Hata kayıtlarını aynı sorularla değerlendirmek için kullanılabilecek pratik bir karar çerçevesidir.

Matris şu şekilde yorumlanabilir:

• Normal: Düşük veya sınırlı etki; sistem çalışmaya devam ediyor ve iş tamamlanabiliyor.
• Yüksek: Önemli bir işlev kaybı var, belirli kullanıcı grubu işlemi tamamlayamıyor veya sorun düzenli tekrarlanıyor.
• Kritik: Sistem, satış veya temel işlev tamamen durmuş; devam eden ciddi veri/güvenlik riski bulunuyor ya da işletmenin ana işlemi için kullanılabilir alternatif yok.

Bir hata üç alanda da yüksek olmak zorunda değildir. Tek bir kritik etki, örneğin bütün satış işlemlerinin durması, kaydı doğrudan kritik değerlendirmeye taşıyabilir. Tersine çok sık görülen küçük bir hizalama sorunu, yalnız sıklık nedeniyle kritik olmaz.

Öncelik Hangi Durumlarda Yeniden Değerlendirilmelidir?

Hata kaydı canlı bir çalışma kaydıdır. Şu gelişmelerden biri olduğunda sınıf yeniden gözden geçirilmelidir:

• Etkilenen kullanıcı, sayfa, ürün, işlem veya entegrasyon sayısı arttıysa
• Aynı kök nedene bağlı yeni belirtiler ortaya çıktıysa
• Sorun artık her denemede oluşuyorsa
• Geçici çözüm çalışmıyor veya sürdürülemiyorsa
• Satış, başvuru ya da temel işlev tamamen durduysa
• Veri kaybı, yanlış veri veya güvenlik riski anlaşıldıysa
• Başlangıçtaki ortam bilgisi yanlış ya da eksik çıktıysa
• Düzeltme başka bir kritik işlevde yan etki oluşturduysa

Öncelik değişikliği kayda kısa bir gerekçeyle eklenmelidir: “Yeni üç bildirim geldi” yerine “Sorunun yalnız tek tarayıcıyla sınırlı olmadığı ve bütün mobil kullanıcıların başvuru işlemini tamamlayamadığı doğrulandı” gibi etkiyi anlatan bir not daha kullanışlıdır.

Geçici Çözüm ve Dış Bağımlılık Önceliği Nasıl Etkiler?

Geçici çözüm, kullanıcının ana işlemi farklı bir yoldan sürdürebilmesini sağlayabilir. Bu, hizmet devamlılığı açısından değerlidir; fakat hatayı ortadan kaldırmaz ve kayıt otomatik olarak kapanmaz.

Örneğin bir dosya yükleme işlevi belirli formatta çalışmıyorsa güvenli ve uygulanabilir başka bir format geçici olarak kullanılabilir. Ancak bu çözüm bütün kullanıcılar için erişilebilir değilse veya veri kaybı riski taşıyorsa yeterli kabul edilmemelidir.

Sorun dış servis, hosting, e-posta, ödeme veya API sağlayıcısına bağlıysa kayıt “beklemede” durumuna alınabilir. Bekleme, önem derecesinin düşürüldüğü anlamına gelmez. Hangi sağlayıcıdan hangi bilgi beklendiği, bu sırada hangi işlevin etkilendiği ve geçici çözümün bulunup bulunmadığı kaydedilmelidir.

Bir kaydın hata desteği, düzenli bakım veya yeni geliştirme kapsamında olup olmadığı da öncelik kararından ayrı ele alınmalıdır. Bu kapsam ayrımını ücretsiz destek ve yıllık bakım rehberimizde inceleyebilirsiniz.

Kurgusal Karar Senaryosu: Normalden Kritiğe Yükselen Form Hatası

Aşağıdaki örnek gerçek bir müşteri vakası değildir; yöntemi göstermek için hazırlanmış kurgusal karar senaryosudur.

Bir kurumsal web sitesinde tek bir kullanıcı, mobil cihazdan teklif formunu gönderemediğini bildirir. İlk kayıtta sorun yalnız belirli cihazda görülmüş ve masaüstünde işlem tamamlanabildiği için normal öncelikte açılır.

İnceleme sırasında aynı kök nedene ait yeni bildirimler ana kayda eklenir. Sorunun tek cihazla sınırlı olmadığı, güncel iki mobil tarayıcıda tekrarlandığı ve mobil ziyaretçilerin tamamının formun son adımını geçemediği anlaşılır. Etki büyüdüğü için kayıt yüksek önceliğe çıkarılır.

Aynı gün başlayan kampanyanın bütün başvuruları bu form üzerinden aldığı ve alternatif başvuru kanalının görünür olmadığı tespit edilir. Satışa bağlı temel işlem fiilen durduğu ve kullanılabilir geçici çözüm bulunmadığı için kayıt kritik olarak yeniden sınıflandırılır.

Bu senaryoda önceliği yükselten şey yalnızca bildirim sayısı değildir. Etkilenen kullanıcı kapsamının genişlemesi, hatanın tekrarlanabilir hâle gelmesi, ana iş akışını durdurması ve zaman baskısıdır.

Düzeltme Sonrasında Kayıt Ne Zaman Kapatılır?

Kod değişikliğinin yapılması tek başına kapanış değildir. Düzeltme sonrasında en az şu kontroller uygulanmalıdır:

• Kayıttaki tekrar adımlarıyla hata yeniden denenir.
• Beklenen sonucun oluştuğu doğrulanır.
• Etkilenen cihaz, tarayıcı, kullanıcı rolü veya entegrasyon yeniden kontrol edilir.
• Değişikliğin yakın işlevlerde yeni sorun oluşturup oluşturmadığı incelenir.
• Geçici çözüm kullanıldıysa kaldırılması veya kalıcılaştırılması değerlendirilir.
• Sonuç ve yapılan kontrol müşteriye bildirilir.

Kapsamlı yazılım, form, üyelik, veri tabanı veya entegrasyon değişikliklerinin kontrollü bir ortamda doğrulanması gerekebilir. Bu ayrımı web sitesi değişikliklerinde test ortamı rehberimizde inceleyebilirsiniz.

Kumsal Ajans yaklaşımında kayıt, gerekli kontroller tamamlandıktan ve müşteri bilgilendirildikten sonra kapatılır. Kritik konularda ayrıca müşteri onayı alınabilir. Hata yeniden oluşursa eski kaydın bağlamı korunarak yeniden açılabilir veya aynı kök nedene bağlanan yeni bulgular ana kayda eklenebilir.

Kullanılabilir Hata Triyaj Kartı

Her hata için aşağıdaki alanları tek kayıtta tutabilirsiniz:

Bu kart her projede aynı yazılım alanlarını zorunlu kılmaz. Ama kararın yalnızca kişisel yorumla değil, görülebilir etki ve tekrar bilgileriyle verilmesini sağlar.

Sonuç

İyi bir hata önceliklendirme süreci, bütün bildirimleri acil kabul etmek veya yalnız en çok şikâyet edilen konuya yönelmek değildir. Önce kayıt kalitesini artırır; sonra etki, sıklık, aciliyet, geçici çözüm ve dış bağımlılıkları birlikte değerlendirir.

Aynı kök nedene ait bildirimleri tek ana kayıtta birleştirin. Yeni bilgiler kullanıcı veya işlem etkisini büyütüyorsa önceliği yeniden değerlendirin. Öncelik değişikliğini bildirim sayısıyla değil, değişen iş etkisiyle gerekçelendirin. Düzeltme sonrasında tekrar adımlarını yeniden çalıştırmadan ve müşteriyi bilgilendirmeden kaydı kapatmayın.