Ticket Priority ve SLA
Ticket Priority & SLA
Bu derste neler öğreneceksin
- Destek taleplerinin öncelik seviyelerini tanımlamak
- Her öncelik seviyesine karşılık gelen SLA süreleri bilmek
- Escalation sürecini açıklamak
GitHub Enterprise desteğinde ticket önceliklendirmesi ve SLA (Service Level Agreement) yönetimi, bir enterprise administrator’ın bilmesi gereken temel konulardandır. GH-100 Domain 1 bu konuyu doğrudan ölçer.
Öncelik Seviyeleri
GitHub Support, talepleri dört öncelik seviyesinde sınıflandırır:
| Öncelik | Tanım | Örnek Senaryo |
|---|---|---|
| Urgent (Critical) | Tüm üretim sistemi çalışmaz, workaround yok | GHES tüm kullanıcılar için erişilemiyor |
| High | Önemli işlev bozulmuş, sınırlı workaround var | SSO çalışmıyor, kullanıcılar giriş yapamıyor |
| Normal | İşlev kısıtlı ama critical değil | Belirli bir webhook tetiklenmiyor |
| Low | Soru, öneri veya belgeleme isteği | API hakkında açıklama talebi |
SLA Yanıt Süreleri
SLA süreleri destek paketine ve öncelik seviyesine göre değişir:
Standart Paket:
Urgent → 8 saat (iş günü)
High → 24 saat (iş günü)
Normal → 48 saat (iş günü)
Premium Paket:
Urgent → 4 saat (7/24)
High → 8 saat (iş günü)
Normal → 24 saat (iş günü)
Premium+ Paket:
Urgent → 30 dakika (7/24)
High → 4 saat (7/24)
Normal → 8 saat (iş günü)
Not: Bu süreler yanıt süresidir, çözüm süresi değil. Karmaşık sorunlar daha uzun sürebilir.
Escalation Süreci
Bir ticket’ın önceliği yanlış ayarlandıysa veya yanıt beklentilerin karşılanmıyorsa escalation talep edebilirsin:
- Mevcut ticket’ta “Request escalation” veya “Upgrade priority” seçeneğini kullan
- Neden escalation gerektiğini iş etkisi (business impact) açısından açıkla
- Premium/Premium+ müşteriler Named Support Engineer’ı doğrudan ping edebilir
Support Bundle
GHES sorunlarında GitHub Support genellikle Support Bundle ister. Bunu oluşturmak için:
ghe-support-bundle -o /tmp/support-bundle.tar.gz
Bundle, sistem loglarını, metriklerini ve konfigürasyon özetini içerir. Hassas içerik (parola, token) otomatik olarak temizlenir (redact edilir).