Skip to main content

> p0_-_p3_kriz_seviyelendirme_(severity)_ve_sla_eskalasyon_matrisi

P0 - P3 Kriz Seviyelendirme (Severity) ve SLA Eskalasyon Matrisi

Mühendislik organizasyonları, müşteri etkisine ve sözleşmeli SLA cezalarına doğrudan bağlı net ve nicel bir P0/P1/P2/P3 kriz seviyelendirme matrisini nasıl kurar?

Senior (L5)

⚡ÖZET VE TEKNİK CEVAP

Öznel kriz seviyelendirmesi ('Bana göre bu SEV-1 gibi') ya tehlikeli bir duyarsızlığa ya da her şeye alarm çalarak nöbetçi mühendisleri tüketen kriz yorgunluğuna yol açar. Başarılı mühendislik ekipleri net matematiksel eşiklere dayalı P0-P3 matrisleri uygular:

1

SEV-0 / P0: Şirket çapında felaket (tüm ödemelerin veya girişlerin durması; 15 dk yanıt SLA'sı; 7/24 kriz masası; üst yönetici aranır),

2

SEV-1 / P1: Kritik işlev kaybı (>%5 işlem hatası, alternatifi olmayan ana servis kesintisi; 30 dk yanıt SLA'sı),

3

SEV-2 / P2: Geçici çözümü olan önemli hata veya yan servis aksaması (mesai saatlerinde müdahale; 4 saat SLA),

4

SEV-3 / P3: Kozmetik veya düşük etkili dahili hata (sonraki sprint'e planlanır). Seviyenin müşteri etkisine bağlanması kriz eskalasyonundaki stresi ve belirsizliği yok eder.

Mühendislik El Kitabı & Mekanizma

6 Boyutlu Mimari Analiz

⚙️1. Temel Çalışma Mekanizması

Mekanizma

Kriz seviyesi otomatik çağrı ve eskalasyon kurallarını tetikler:

1

P0: Kriz Koordinatörünü, baş SRE'yi ve Mühendislik Direktörünü telefonla uyandırır; otomatik Zoom kriz masası açar.

2

P1: İlgili servisin birincil ve ikincil mühendislerini nöbetçi telefonundan arar.

3

P2: Gece telefon çalmadan ilgili Slack kanalına yüksek öncelikli bildirim atar.

4

P3: Otomatik Jira bileti açar. Seviye değişimi kuralı: Herhangi bir mühendis şüphe anında seviyeyi ANINDA YÜKSELTEBİLİR; seviyeyi DÜŞÜRME yetkisi ise yalnızca telemetrinin en az 30 dakika stabil olduğunu doğrulayan Kriz Koordinatörüne aittir.

🎯2. Doğru Kullanım Senaryosu

Kapsam

Kurumsal SaaS platformları, fintech ödeme sistemleri, yüksek hacimli e-ticaret, bulut altyapı sağlayıcıları ve çok kiracılı B2B mimarileri.

⚠️3. Prodüksiyon Arıza Modları

Kritik Risk
  • ✓

    Bir ürün yöneticisinin önemli bir müşteri tweet attı diye gece saat 3'te bir buton hizalama hatasını 'SEV-1' ilan edip 10 mühendisi yatağından kaldırması

  • ✓

    finansal verileri bozan sessiz bir veritabanı gecikmesinin 'nasılsa sistem ayakta' denilerek SEV-3 sınıflandırılıp 12 saat fark edilmemesi

📡4. Teşhis ve Telemetri Sinyalleri

Metrikler
  • ✓

    Sürekli gece yersiz çalan alarmlar yüzünden mühendislerin PagerDuty bildirimlerini sessize alması

  • ✓

    büyük gelir kayıpları takip edilmezken önemsiz iç araç aksaklıkları için yöneticilerin postmortem talep etmesi

🛡️5. Önleme ve Mimari Bariyerler

Bariyerler
  • ✓

    Somut metriklerle tanımlanmış 1 sayfalık Kriz Seviye Matrisi yayınlayın (ör. Ödeme hata oranı > %1 = P1, Sepet sayfası çöktü = P0)

  • ✓

    her çeyrekte geçmiş olayları inceleyerek eşikleri yeniden kalibre edin

  • ✓

    keyfi ve yersiz eskalasyonları engelleyin

⚖️6. Mimari Ödünleşimler (Trade-offs)

Ödünleşim

Katı matematiksel kriz matrisleri belirsizliği yok eder; ancak eşiklerin anlık otomatik hesaplanabilmesi için sistemlerde gelişmiş telemetri ve metrik altyapısı gerektirir.

📋

Vaka İncelemesi (TinyCTO Saha Örneği)

GERÇEK DÜNYA TELEMETRİSİ

Bir fintech girişiminde her müşteri şikayeti SEV-1 yapıldığı için nöbetçi mühendisler tükenmişti. Şirket net bir matris getirdi: P0 = Tüm ödemelerin durması (yönetim + SRE aranır), P1 = >%2 işlem hatası veya API gecikmesi >2 sn (nöbetçi aranır), P2 = Yedeği olan tek bir banka entegrasyonu aksaması (mesaide Slack bildirimi), P3 = Yönetim paneli görsel hatası (Jira). İlk ayda gece çalan alarmlar %74 azaldı ve müşteri SLA başarısı hiç etkilenmedi.

İnteraktif Konsept Alıştırmaları

2 Alıştırma
Q1

SEV-0/P0 kriz ile SEV-1/P1 kriz arasındaki temel fark nedir?

SEV-0 tüm kullanıcıları veya ana geliri vuran topyekün çöküştür; SEV-1 ise geçici çözümü olmayan kritik bir alt sistem veya işlem kaybıdır.
Q2

Devam eden bir krizin seviyesini DÜŞÜRME (downgrade) yetkisi kime aittir?

Yalnızca Kriz Masası Koordinatörüne (IC); telemetrinin belirli bir süre stabil olduğunu doğruladıktan sonra.

P0 - P3 Kriz Seviyelendirme (Severity) ve SLA Eskalasyon Matrisi — Sıkça Sorulan Sorular

Müşteriyi etkilemeyen test/staging ortamı kesintileri asla P0 veya P1 olarak sınıflandırılmalı mıdır?

Hayır. Canlıdaki bir P0 krizine çıkılacak acil bir yamayı (hotfix) engellemediği sürece test ortamı aksaklıkları kesinlikle P2 veya P3'tür.

Bir krizi tamamen kapatmadan önce sistemlerin ne kadar süre stabil kalması beklenmelidir?

Genellikle en az 30 ila 60 dakika boyunca sıfır hata, temiz telemetri ve normal trafik hacmi gözlemlenmelidir.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

  • ▸

    Severity must be defined by quantitative, objective customer impact metrics.

  • ▸

    SEV-0/P0 = total catastrophic business halt; SEV-1/P1 = critical feature degradation without workaround.

  • ▸

    Anyone can upgrade severity instantly; only the Incident Commander can downgrade.

  • ▸

    Clear severity definitions prevent alert fatigue and protect on-call engineer health.

Yaygın Yanılgılar

  • ✗

    Yanılgı: A bug affecting an important enterprise customer is automatically SEV-0 (Gerçek: SEV-0 requires widespread, existential platform failure).

  • ✗

    Yanılgı: Downgrading severity can be done as soon as a fix is deployed (Gerçek: Telemetry must remain healthy for 30+ minutes first).

Karar Kılavuzu & Önceliklendirme

Enforce quantitative definitions in your on-call severity handbook. Automate P0/P1 paging logic directly within PagerDuty/Opsgenie.

Doğrulanmış Kaynaklar & Referanslar

Bu sayfadaki teknik terimler

SprintSLA