Stakeholder İletişimi

Bir GitHub Enterprise yöneticisinin teknik bilginin yanında iletişim becerileri de kritiktir. Bir outage ya da planlı bakım sırasında doğru bilgiyi doğru kişilere iletmek, Domain 1’in önemli bir bileşenidir.

GitHub Status Sayfası

GitHub’ın genel servis durumunu izlemek için githubstatus.com kullanılır. Bu sayfa:

• Tüm GitHub servisleri için anlık durum (operational, degraded, partial outage, major outage) gösterir
• Incident geçmişine erişim sağlar
• E-posta veya webhook ile abonelik imkânı sunar

GHES kurulumlarında ise enterprise yöneticisi kendi instance’ının sağlığını izlemek için /setup/monitor dashboard’unu ve GHES’in built-in Management Console’unu kullanır.

Outage Sırasında İletişim

Bir production outage’da yönetici şu sırayla hareket etmelidir:

1. Triage: Sorunun kapsamını belirle (tek kullanıcı mı, tüm org mı, tüm instance mı?)
2. İç bildirim: Geliştiricilere ve teknik ekiplere hızlı bir “biz farkındayız, araştırıyoruz” mesajı gönder
3. Support ticket aç: Urgent öncelikle GitHub’a bildir
4. Status güncellemesi: Belirli aralıklarla (15–30 dk) ekipleri güncelle; “hâlâ araştırıyoruz” bile bilgilendirici sayılır
5. Post-incident review: Çözüm sonrası kök neden analizi yap ve önleyici aksiyonları paylaş

Planlı Bakım İletişimi

GHES yükseltmeleri veya bakım pencereleri için:

• Bakımı en az 5 iş günü öncesinde duyur
• Etkilenen servisleri ve tahmini downtime süresini belirt
• Rollback planını hazırla ve paylaş

Sınav sorusu örüntüsü: “GHES instance’ını 3.8’den 3.10’a yükselteceksin. Hangi iletişim adımları gereklidir?” — Beklenen yanıt: Önceden duyuru, maintenance window belirleme, rollback planı dokümantasyonu.

Escalation Matrixi

Durum	İç iletişim	Dış iletişim
Kısa (<15 dk) outage	Slack/Teams’de duyuru	Gerekmeyebilir
Uzun (>1 saat) outage	Tüm stakeholder’lara e-posta	GitHub Support ticket
Veri kaybı riski	CTO/CISO bilgilendirme	Hukuki danışma gerekebilir
Güvenlik ihlali	Güvenlik ekibi + CISO	GitHub Security (security@github.com)