⚡ÖZET VE TEKNİK CEVAP
Canlı bir müşteri kesintisinde yazılım ve iletişim ekipleri kritik bir ikilemle karşılaşır:
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.
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:
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').
İç Hatalara Değil Kullanıcı Belirtilerine Odaklanın: Sağlayıcıları suçlamak yerine dışarıdan görünen etkiyi anlatın.
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ı
Mekanizma🎯2. Doğru Kullanım Senaryosu
Kapsam⚠️3. Prodüksiyon Arıza Modları
Kritik Risk📡4. Teşhis ve Telemetri Sinyalleri
Metrikler🛡️5. Önleme ve Mimari Bariyerler
Bariyerler⚖️6. Mimari Ödünleşimler (Trade-offs)
ÖdünleşimVaka İ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ırmaHarici durum sayfası (Status Page) güncellemeleri neden iç teknik kök nedenler yerine kullanıcı belirtilerine odaklanmalıdır?
Aktif bir büyük kesinti sırasında durum sayfasına güncelleme girilmesi gereken maksimum süre nedir?
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
