Kök Neden Analizi (RCA) Standardı ve Nedensellik Yöntemleri

RCA sürecini tetikleyen her üretim olayı, ciddiyetine göre sınıflandırılmalı ve resmi bir yönetişim kaydına işlenmelidir.

Ciddiyet Eşikleri

• SEV-0 (Katastrofik): Birincil iş kabiliyetinin tamamen durması, aktif veri bozulması, güvenlik kimlik bilgisi sızıntısı veya 50.000 USD'yi aşan SLA ceza riski. 48 saat içinde RCA yayını ve VP düzeyinde onay gerektirir.
• SEV-1 (Kritik): Kritik servis yollarında kısmi müşteri etkisi veya yedeklilik kaybı. 5 iş günü içinde RCA tamamlanmasını gerektirir.
• SEV-2 (Majör): Dahili araçların aksaması, kritik olmayan telemetri kaybı veya yüksek riskli ucuz atlatma. 10 iş günü içinde RCA tamamlanmasını gerektirir.

Zorunlu Rol ve Sorumluluklar

1. Incident Commander: Zaman çizelgesi doğrulamasını koordine eder ve suçlamasız inceleme toplantısını yönetir.
2. Lead Investigating SRE: Birincil yazar, telemetri adli analizcisi ve nedensellik diyagramı modelleyicisidir.
3. Owning Service Architect: Mimari sınırlandırmayı ve teknik uygulanabilirliği doğrular.
4. Engineering Director: Yönetici onayı sağlar ve CAPA maddeleri için kalıcı kaynak tahsis eder.

Tetikleyicileri kök nedenlerle karıştırmak, yazılım postmortemlerindeki en yaygın hata modudur. Yetkili sözlük taksonomisi için RCA Teknik Sözlük Tanımı maddesini inceleyin. Bu standart dört belirgin katman tanımlar:

1. Tetikleyici Mekanizma (Kıvılcım): Arıza zincirini başlatan tekil olay (örn. otomatik release deploy'u, ani müşteri trafik dalgası, tedarikçi API timeout'u).
2. Yakın Neden (Mekanizma): Servis kesintisini doğrudan üreten anlık teknik durum (örn. Redis thread havuzunun tükenmesi, TCP SYN kuyruğu doygunluğu, kilitlenen veritabanı işlemleri).
3. Kök Neden (Sistemik Hata): Yakın nedenin var olmasına ve üretim öncesinde yakalanamamasına izin veren mimari, doğrulama veya otomasyon açığı.
4. Katkıda Bulunan Faktörler (Ortam): Kesinti süresini uzatan veya müdahale verimliliğini düşüren gizli çevresel, kültürel veya gözlemlenebilirlik eksiklikleri (örn. eksik metrikler, rollback rehberinin olmaması, dağınık alarmlar).

RCA raporları tek bir anlatı tekniğine dayanamaz. Aşağıdaki dört resmi metodoloji, Olay Sonrası İnceleme ve Kök Neden Analizi Paketi (TPL-OPS-002) içinde şablonlanmış olup, INC-001 (Prod Aslında Altı Meeting Önce Düşmüştü), INC-002 (Cache Guy Hızlı Cevap Getirdi) ve INC-100 (Sistem Roadmap'in Unuttuğunu Hatırlar) dahil gerçek üretim kesintileriyle test edilmiştir:

A. 5 Whys (Dallanma Kuralları ile)

Neden-sonuç ilişkilerini inceleyen ardışık sorgulama tekniği.

• Kural 1: Her 'Neden' adımı somut log/metrik zaman damgasıyla desteklenmelidir.
• Kural 2: İnsan hatası (örn. 'mühendis bayrağı unuttu') uç nokta olarak kesinlikle yasaktır. Uç nokta mimari veya süreç kontrol hatasına ulaşmalıdır.
• Kural 3: Bir yanıt birden çok bağımsız önkoşula sahipse, paralel neden dallarına ayrılmalıdır.

B. Ishikawa Diyagramı (Balık Kılçığı 6-M Sistemi)

Katkıda bulunan koşulları altı sistemik alanda gruplandırır:

1. Yöntemler (Methods): Deploy süreçleri, test kapısı tanımları, onay sıklığı.
2. Makineler / Altyapı: Bulut sunucuları, bellek sanallaştırması, ağ topolojisi.
3. Malzemeler / Bağımlılıklar: Üçüncü taraf SaaS API'leri, açık kaynak paketler, base container imajları.
4. Ölçüm / Gözlemlenebilirlik: Metrik kapsamı, log saklama, trace örnekleme, alarm eşikleri.
5. Ortam (Milieu): İşletim yükü, eşzamanlılık patlamaları, ağ bölünmeleri.
6. İnsan Gücü (Manpower): Nöbetçi yorgunluğu, rehber belirsizlikleri, ekip içi iletişim devirleri.

C. Hata Ağacı Analizi (FTA)

İstenmeyen sistem durumlarını AND/OR mantıksal kapılarıyla temel bileşen arızalarına kadar izleyen tümdengelimli Boole analizi.

D. Değişim Analizi (Kepner-Tregoe)

Karşılaştırmalı analitik yöntem:

• Ne oluyor karşısında Ne bekleniyordu.
• Ne zaman gerçekleşti karşısında En son ne zaman başarıyla çalıştı.
• Nerede gözlemlendi karşısında Nerede görülmüyor.

Bir RCA raporu, yalnızca onu destekleyen deneysel telemetri kadar geçerlidir. Spekülatif postmortemler reddedilir. TPL-OPS-002 paketindeki adli kanıt kontrol listeleri, INC-065 (Hypercare Kanalı Kalıcı Hale Geldi) ve INC-138 (Instant Product Kalıcı Hypercare İstedi) gibi vakalarda görülen kanıt kayıplarını önlemek için telemetrinin anında dondurulmasını şart koşar.

Kanıt Koruma Protokolleri

1. Snapshot Alma: $T_{-2h}$ ila $T_{+2h}$ arasındaki üretim metrik panoları (Grafana, Datadog), değiştirilemez görüntüler veya serileştirilmiş JSON durumu olarak kalıcı olarak arşivlenmelidir.
2. Log Dondurma: Ham uygulama ve ingress logları, SHA-256 bütünlük doğrulamasıyla salt-eklenebilir WORM uyumlu soğuk depolama bucket'ına taşınmalıdır.
3. Trace Sabitleme: Yüksek gecikmeli tail anomalilerini gösteren örnek dağıtık trace'ler etiketlenmeli ve standart TTL silme işleminden muaf tutulmalıdır.
4. Gizlilik ve Temizleme: Müşteri PII verileri, gizli anahtarlar ve JWT token'ları, RCA dokümanına dahil edilmeden önce geri döndürülemez hash'lerle maskelenmelidir.

Postmortemler sıklıkla eylem maddelerinin unutulan backlog'larda çürümesi nedeniyle başarısız olur. TPL-OPS-002 paketindeki 3 Katmanlı SMART CAPA (Düzeltici ve Önleyici Faaliyet) takip tablosu ve yönetici sunum şablonu, bu standardı hayata geçirerek INC-001 (Prod Aslında Altı Meeting Önce Düşmüştü) ve INC-100 (Sistem Roadmap'in Unuttuğunu Hatırlar) vakalarında incelenen tekrarlayan arızaları ortadan kaldırır:

SMART İyileştirme Kriterleri

Her düzeltici ve önleyici eylem maddesi, iyileştirme backlog'una alınmadan önce beş SMART mühendislik kriterini karşılamak zorundadır:

1. Spesifik (Specific): Tam olarak tek bir mimari sınır, konfigürasyon veya operasyonel mekanizma değiştirilir. Belirsiz biletler (örn. 'önbellek dayanıklılığını artır') Olay Komutanı tarafından doğrudan reddedilir.
2. Ölçülebilir (Measurable): Somut telemetri iddiaları tanımlanır (örn. 'Simüle edilmiş Redis primary düğüm arızasında 5.000 QPS altında p99 gecikme < 120ms').
3. Ulaşılabilir (Achievable): Tanımsız platform yeniden yazımlarına ihtiyaç duymadan mevcut ekip mimari kapasitesi dahilinde uygulanabilir olmalıdır.
4. İlgili (Relevant): RCA neden-sonuç grafiğinde tespit edilen bir nedensel faktörü veya gizil arıza koşulunu doğrudan ele almalıdır.
5. Zamana Bağlı (Time-bound): Yetkili mühendislik kaydında takip edilen kesin SLA vadelerine (Katman 1 için 48 saat, Katman 2 için 30 gün, Katman 3 için 90 gün) bağlı olmalıdır.

İyileştirme Yönetişimi ve Çürüme Önleme Kuralı

Eylem maddesi çürümesi, tavizsiz yönetişim kapılarıyla engellenir:

• Tek Sorumlu Birey (DRI / Remediation Owner): Her Katman 1, 2 ve 3 maddesi, belirsiz bir ekip unvanına değil, ismi belirli tek bir mühendise atanmalıdır.
• Backlog Öncelik Güvencesi: Katman 2 ve Katman 3 biletleri P1 mühendislik maddesi olarak kaydedilir ve sprint kapasite sınırlarını doğrudan aşar.
• Haftalık Operasyon Konseyi Denetimi: Çözülmemiş biletler, resmi doğrulama tamamlanana kadar Mühendislik Operasyon Konseyi tarafından haftalık incelenir.
• Zorunlu Etkililik Doğrulaması (VoE): Bir bilet kod deploy edildiğinde hemen kapatılamaz. Üretim telemetrisi ve otomatik kaos testlerinin arızanın tekrarlanmadığını kanıtladığı 30 ila 90 günlük zorunlu bir doğrulama vadesi şarttır.
• Resmi Kapatma Yetkisi: Kapatma onayı yalnızca Olay Komutanı ve VP of Engineering ile sınırlıdır; mühendisler bağımsız kanıt sunmadan kendi CAPA biletlerini kapatamazlar.

Bir RCA raporu, 20 kalite kriterinin tamamı doğrulanmadan onaylanamaz:

1. Olay tanımlaması ve benzersiz takip referansı atandı.
2. Tüm anlatı bölümlerinde suçlamasız (blameless) dil kullanımı doğrulandı.
3. Zaman çizelgesi, doğrulanmış UTC zaman damgalarıyla dakika/saniye çözünürlüğünde belgelendi.
4. Tespit mekanizması belirlendi (otomatik SLO alarmı mı müşteri bildirimi mi).
5. Tetikleyici olay, yakın nedenden açıkça ayrıştırıldı.
6. Yakın teknik neden, deneysel metrikler veya stack trace'lerle desteklendi.
7. 5 Whys analizi, insan hatasını suçlamadan mimari veya süreç kök nedenlerine ulaştı.
8. Ishikawa kılçık diyagramı, gizli koşulları 6 alanda kategorize etti.
9. Çok faktörlü arızalar için Hata Ağacı veya Değişim Analizi uygulandı.
10. Doğrudan finansal kayıp ve müşteri SLA ihlal etkisi hesaplandı.
11. Veri bütünlüğü doğrulaması yapıldı (sıfır sessiz kayıp veya yakalanmamış bozulma).
12. Güvenlik ve yasal uyumluluk sınırlarının korunduğu teyit edildi.
13. Sınırlandırma adımları kronolojik sırayla belgelendi.
14. Rollback güvenliği ve gözlemlenebilirlik açıkları resmi olarak değerlendirildi.
15. Katman 1 acil düzeltici faaliyetlerin 48 saat içinde yayına alındığı doğrulandı.
16. Katman 2 mimari güçlendirme biletleri 30 günlük SLA ile isimli mühendislere atandı.
17. Katman 3 sistemik önleme girişimleri kardeş servisler için 90 günlük SLA ile kapsamlandırıldı.
18. Ham telemetri snapshot'ları değiştirilemez depolamada arşivlendi.
19. Mühendislik paydaşlarıyla suçlamasız postmortem toplantısı gerçekleştirildi.
20. Yönetici mühendislik liderliği onayı alındı ve kayda geçirildi.