Staff/Principal (L6+)
⚡ÖZET VE TEKNİK CEVAP
Canlı bir müşteri kesintisinde yazılım ve iletişim ekipleri kritik bir ikilemle karşılaşır:
1
Sessizlik ve İnkar: Sosyal medyada binlerce öfkeli müşteri hata ekranı paylaşırken Durum Sayfasında (Status Page) 'Tüm Sistemler Çalışıyor' yazmak kurumsal güveni yerle bir eder.
2
Aşırı Detay ve Hukuki İtiraf Tuzağı: 'Mühendisimiz yanlışlıkla müşteri veritabanı yedeklerini sildi' gibi kontrolsüz itiraflar yazmak şirketi anında devasa tazminat davalarına ve KVKK/GDPR cezalarına maruz bırakır. Kurumsal kriz iletişimi dengeyi Disiplinli Olgusal Şeffaflık ile kurar:
1
Erken Yayınlayın (10-15 dk içinde): Kök nedeni tahmin etmeden sorunu kabul edin ('Ödeme işlemlerini etkileyen hata oranlarını inceliyoruz').
2
İç Hatalara Değil Kullanıcı Belirtilerine Odaklanın: Sağlayıcıları suçlamak yerine dışarıdan görünen etkiyi anlatın.
3
Tarafsız ve Hukuka Uygun Dil: Yalnızca doğrulanmış somut olguları yazın, spekülasyondan kaçının ve bir sonraki güncelleme saatini taahhüt edin.
Mühendislik El Kitabı & Mekanizma
6 Boyutlu Mimari Analiz⚙️1. Temel Çalışma Mekanizması
MekanizmaStatus page iletişim süreci 4 standart aşamayı izler:
1
İnceleniyor: 'Giriş servislerini etkileyen gecikme şikayetlerini inceliyoruz. Sonraki duyuru 20 dakika içinde yapılacaktır.'
2
Tespit Edildi: 'Ağ yönlendirme katmanındaki arıza tespit edildi ve çözüm paketi canlıya alınıyor. Kullanıcılar geçici zaman aşımı yaşayabilir.'
3
İzleniyor: 'Çözüm uygulandı ve sistem metrikleri izleniyor. Servisler normale dönmektedir.'
4
Çözüldü: 'Arıza tamamen giderildi. Tüm sistemler kararlı çalışmaktadır. Detaylı teknik rapor 5 iş günü içinde paylaşılacaktır.'
🎯2. Doğru Kullanım Senaryosu
KapsamHerkese açık durum sayfaları (Statuspage.io), B2B kurumsal müşteri SLA bildirimleri, müşteri durum webhook'ları ve halkla ilişkiler kriz yönetimi.
⚠️3. Prodüksiyon Arıza Modları
Kritik Risk- ✓Olguları teyit etmeden alelacele bulut sağlayıcısını suçlamak ('AWS yüzünden çöktük')
- ✓kullanıcıların %30'u hala hata alırken durum sayfasını erkenden 'Çözüldü'ye çekip müşterileri çıldırtmak
📡4. Teşhis ve Telemetri Sinyalleri
Metrikler- ✓2 saatlik küresel kesinti sırasında durum sayfasının yeşil 'Tüm Sistemler Çalışıyor' göstermesi
- ✓hukuk müşavirinin kontrolsüz itiraflar içeren durum metinlerini reddetmesi
- ✓sayfada bilgi olmadığı için destek ekibine binlerce bilet yağması
🛡️5. Önleme ve Mimari Bariyerler
Bariyerler- ✓Hukuk müşavirliği ile önceden onaylanmış standart durum bildirim şablonları hazırlayın
- ✓Datadog/PagerDuty webhook'ları ile durum sayfası güncellemelerini yarı-otomatikleştirin
- ✓20 dakikalık duyuru ritmini zorunlu kılın
⚖️6. Mimari Ödünleşimler (Trade-offs)
ÖdünleşimDisiplinli kriz iletişimi kurumsal müşteri güvenini korur ve şirketi davalardan korur; ancak iç mimari sırları ifşa etmemek için dikkatli ve profesyonel bir dil gerektirir.
📋
GERÇEK DÜNYA TELEMETRİSİVaka İncelemesi (TinyCTO Saha Örneği)
Bir B2B SaaS faturalandırma motorunda veritabanı kilitlenmesi yaşandı ve 500 fatura takıldı. Panikleyen kıdemsiz bir mühendis durum sayfasına: 'Veritabanımız çöktü ve hatalı SQL yüzünden veri kaybettik' yazdı. 12 büyük kurumsal müşteri milyon dolarlık sözleşmelerini feshetmek için avukatlarını aradı. Kriz ekibi metni derhal yayından kaldırdı ve hukuken incelenmiş şeffaf bir metin paylaştı: 'Kısıtlı sayıda hesabı etkileyen işlem gecikmesini çözüyoruz. Tüm muhasebe kayıtları güvenli yedeklerimizde korunmaktadır; otomatik mutabakat süreci yürütülmektedir'. Kriz kontrol altına alındı, veriler eşitlendi ve sıfır müşteri kaybıyla süreç atlatıldı.
İnteraktif Konsept Alıştırmaları
2 AlıştırmaQ1
Harici durum sayfası (Status Page) güncellemeleri neden iç teknik kök nedenler yerine kullanıcı belirtilerine odaklanmalıdır?
Çünkü müşterilerin hangi iş akışlarının etkilendiğini ve sistemin ne zaman düzeleceğini bilmeye ihtiyacı vardır; erken aşamadaki teknik tahminler ise genellikle yanıltıcıdır ve gereksiz hukuki ve güvenlik riskleri doğurur.
Q2
Aktif bir büyük kesinti sırasında durum sayfasına güncelleme girilmesi gereken maksimum süre nedir?
Hiçbir yeni teknik gelişme olmasa bile, çalışmaların devam ettiğini belirten ve bir sonraki duyuru saatini veren güncellemeler en geç her 15 ila 30 dakikada bir girilmelidir.
Kamuya Açık Kriz İletişimi: Status Page Şeffaflığı ve Hukuki Sorumluluk Dili Dengesi — Sıkça Sorulan Sorular
Bilinen bir kesinti sırasında durum sayfasında 'Tüm Sistemler Çalışıyor' göstermek neden şirket için yıkıcıdır?
Hata alan kullanıcılara gerçeği inkar ediyormuş hissi verir; onları destek hatlarına yığar ve sosyal medyada şirketi rezil etmelerine yol açarak kurumsal güveni tamamen yok eder.
Bir kriz çözüldükten sonra kamuya açık detaylı postmortem raporu ne zaman yayınlanmalıdır?
İç suçlamasız analiz tamamlandıktan, kök neden tam doğrulandıktan ve kalıcı düzeltici aksiyonlar belirlendikten sonra genellikle 3 ila 5 iş günü içinde.
🤖 AEO & Yapay Zeka Çıkarım Özeti
Temel Gerçekler & İlkeler
- ▸Müşteri güvenini korumak için kesintileri 10-15 dakika içinde kamuoyuna duyurun.
- ▸İç spekülatif teknik suçlamalar yerine dışarıdan görünen kullanıcı etkisini anlatın.
- ▸Sonraki duyuru saatini taahhüt ederek her 15-30 dakikada bir düzenli güncelleme geçin.
- ▸Standart kriz iletişim şablonlarını şirket hukuk müşavirliği ile önceden onaylayın.
Yaygın Yanılgılar
- ✗Yanılgı: Kök nedeni kesin olarak bulana kadar durum sayfasına hiçbir şey yazmamalıyız (Gerçek: Sessizlik panik yaratır; araştırma sürerken belirtiyi anında duyurun).
- ✗Yanılgı: Şeffaflık tüm iç yazışmaları ve mühendis isimlerini paylaşmak demektir (Gerçek: Şeffaflık etkiyi ve çözümü dürüstçe anlatmaktır; personeli hedef göstermek değildir).
Karar Kılavuzu & Önceliklendirme
Müşteri güvenini korurken hukuki riskleri önlemek için kullanıcı belirtilerine odaklanan ve 20 dakikalık güncelleme ritmine sahip önceden onaylanmış kriz iletişim şablonları kullanın.
Doğrulanmış Kaynaklar & Referanslar
- [OFFICIAL_DOCUMENTATION]Atlassian Incident Communication Handbook: Status Page Best Practices— Atlassian / Statuspage Documentation