Kök neden analizi

1) RCA nedir ve neden gereklidir?

Kök Neden Analizi, tekrarlamayı önlemek için bir olayın kök nedenlerini tanımlamak için yapılandırılmış bir süreçtir. Merkezde - gerçekler, nedensel ilişkiler ve sistemik gelişmeler (süreçler, mimari, testler) ve suçlama arayışı değil.
Hedefler: Nüksetmeyi önlemek, MTTR/olay oranını azaltmak, SLO'yu iyileştirmek, düzenleyiciler ve ortaklarla güven oluşturmak.

2) İlkeler (Sadece Kültür)

Suçlama yok. İnsanları değil, riskli uygulamaları cezalandırıyoruz.
Gerçekçilik. Sadece doğrulanabilir veriler ve eserler.
E2E manzarası. Müşteriden arka uçtan sağlayıcılara.
Hipotezlerin test edilebilirliği. Herhangi bir ifade - bir test/deney ile.
CAPA kapatma. Sahipleri ve son teslim tarihleri ile düzeltici ve önleyici tedbirler.

3) Giriş eserleri ve hazırlık

UTC zaman çizelgesi: T0 algılama, T + eylemleri, T + kurtarma.
Gözlemlenebilirlik verileri: günlükler, metrikler (kohort dahil), yollar, sentetikler, durum sayfası.
Değişiklikler: sürümler, özellik bayrakları, yapılandırmalar, sağlayıcı olayları.
Ortam: sürümler, yapay karma, SBOM, altyapı etiketleri.
Olay tabanı: Etkinin tanımı (SLO/SLA, müşteriler, ciro), alınan kararlar, geçici çözüm.
Gözetim zinciri: Kanıtların kim tarafından ve ne zaman toplandığı/değiştirildiği (uyum için önemlidir).

4) RCA yöntemleri: ne zaman

1. 5 Neden - dar problemler için nedensel zinciri hızla çözün. Risk: Karmaşık bir sistemi bir çizgiye "yuvarlayın".
2. Balık kılçığı - Faktörleri İnsanlar/Süreç/Platform/Politika/Ortak/Ürün olarak kategorize edin. Başlangıçta faydalıdır.
3. Hata Ağacı Analizi (FTA) - Olaydan neden setlerine (AND/OR) kesinti. Altyapı ve ağaç arızaları için.
4. Nedensel Grafik/Olay Zinciri - olasılıklar ve katkı ağırlığı ile bağımlılık grafiği. Mikro hizmetler ve dış sağlayıcılar için iyidir.
5. FMEA (Arıza Modları ve Etkileri Analizi) - Önleme: arıza modları, ciddiyet (S), frekans (O), tespit edilebilirlik (D), RPN = S × O × D.
6. Değişim Analizi - karşılaştırma "olduğu gibi/olduğu gibi" (konfig diff, şema, sürümler).
7. İnsan Faktörleri İncelemesi - insanların kararlarının bağlamı (uyarı yorgunluğu, kötü oyun kitapları, aşırı yük).

Önerilen kombinasyon: Fishbone - Değişim Analizi - Nedensel Grafik/FTA - 5 Neden anahtar dalları tarafından.

5) Adım adım RCA süreci

1. Başlatın: Bir RCA sahibi atayın, bir rapor yayınlamak için son tarihi belirleyin (örneğin, 5 iş günü), bir ekip oluşturun (IC, TL, Scribe, sağlayıcı temsilcileri).
2. Gerçekleri toplayın: zaman çizelgesi, grafikler, sürümler, günlükler, eserler; Versiyonları ve miktar kontrolünü düzeltin.
3. Harita etkisi: Hangi SLI/SLO'lar etkilendi, hangi kohortlar (ülkeler, sağlayıcılar, VIP'ler).
4. Hipotezler oluşturun: birincil, alternatif; Şimdi hangilerinin doğrulanabilir olduğunu kontrol edin.
5. Test hipotezleri: sahne/simülasyon/kanarya üzerinde oynatma, iz analizi, hata enjeksiyonu.
6. Kök ve katkıda bulunan nedenleri belirleyin: teknolojik, süreç, organizasyonel.
7. Form CAPA: düzeltici (doğru) ve önleyici (önleme); Başarı ölçütleri ve zaman çizelgeleri.
8. Raporu uzlaştırın ve yayınlayın: iç bilgi tabanı + gerekirse, istemciler/düzenleyici için harici sürüm.
9. Etkiyi doğrulayın: 14/30 gün sonra kontrol noktaları; kapanış eylemleri.

6) "Kök neden'olarak sayılan şey

• Zayıf testler/özellik bayrakları, eksik sınırlar/uyarılar, belirsiz belgeler, yanlış varsayılanlar, kırılgan mimari.
• Genellikle bu faktörlerin bir kombinasyonudur (konfigürasyon × bir kapı eksikliği × yük × sağlayıcısı).

7) CAPA: düzeltici ve önleyici tedbirler

• Kod/yapılandırma düzeltme, desen geri alma, limit/zaman aşımı değiştirme, indeks ekleme, replika/sharding, trafik yeniden dağıtımı, sertifika güncellemesi.

• Testler (sözleşme, kaos vakaları), uyarılar (yanma oranı, sentetik sayısı), yayın politikası (kanarya/mavi-yeşil), yapılandırmalar için GitOps, eğitim/kontrol listeleri, sağlayıcı çoğaltma, DR egzersizleri.

Her eylem: sahip, son tarih, beklenen etki, doğrulama metriği (örneğin, değişim-başarısızlık oranında % X azalma, 90 gün tekrarlama yok).

8) Hipotezlerin ve etkilerin doğrulanması

Deneyler: hata enjeksiyonu/kaos, gölge trafik, A/B yapılandırmaları, gerçek profillerle yük.
Başarı metrikleri: SLO kurtarma, p95/p99 sabitleme, hata oranı artışı yok, MTTR azaltma, yanma oranı ve 30 gün boyunca sıfır yeniden açma eğilimi.
Kontrol noktaları: D + 7, D + 30, D + 90 - CAPA uygulamasının ve etkisinin gözden geçirilmesi.

9) RCA Rapor Şablonu (Dahili)

1. Kısa özet: Ne zaman oldu, kim etkiledi.
2. Etki: SLI/SLO, kullanıcılar, bölgeler, ciro/cezalar (varsa).
3. Zaman çizgisi (UTC): ana olaylar (uyarılar, kararlar, sürümler, düzeltmeler).
4. Gözlemler ve veriler: grafikler, günlükler, izler, yapılandırmalar (dağılımlar), sağlayıcı durumları.
5. Hipotezler ve testler: kabul edilen/reddedilen, deneylere referanslar.
6. Temel nedenler: teknolojik, süreç, organizasyonel.
7. Katkıda bulunan faktörler: "Neden fark etmedi/durmadı".
8. CAPA planı: sahipler/son tarihler/metrikler ile eylem tablosu.
9. Riskler ve kalan güvenlik açıkları: Izlenmesi/test edilmesi gereken başka şeyler.
10. Uygulamalar: eserler, bağlantılar, grafikler (liste).

10) Örnek (kısa, genelleştirilmiş)

Etkinlik: 19: 05-19: 26'da (SEV-1) %35 ödeme başarısı.
Etki: 21 dk ihlal e2e-SLO, 3 ülke etkilendi, geri dönüşler/tazminatlar.
Sebep 1 (bunlar): Kart doğrulayıcısının yeni sürümü gecikmeyi 1'e çıkardı. 2 s - Sağlayıcıya zaman aşımları.
Sebep 2 (yüzde): "A" sağlayıcısı için kanarya yoktu, serbest bırakma hemen %100 oldu.
Sebep 3 (org): İş SLI'sındaki uyarı eşiği belirli bir BIN aralığını (VIP kohort) kapsamadı.
CAPA: doğrulayıcının eski sürümünü döndürür; Kanarya 1/5/25 % girin; BIN kohortları tarafından iş SLI'ları ekleyin; "B" sağlayıcısı için %30 yük devretme konusunda anlaştık; Kaos davası "akıntıya karşı yavaş".

11) RCA süreç olgunluk metrikleri

CAPA zamanında tamamlanır (%30 gün içinde kapanır).
Yeniden açma oranı (olaylar 90 gün içinde yeniden açıldı).
Önce/sonra değişim-başarısızlık oranı.
Sistemik nedenlerin bulunduğu olayların oranı (sadece "insan hatası'değil).
RCA'dan yeni senaryoların test kapsamı.
Rapor yayınlanma süresi (yayın SLA).

12) Düzenlenmiş alanların özellikleri (fintech/iGaming, vb.)

Dışarıya raporlama: Hassas ayrıntılar olmadan, ancak tekrarları önlemek için bir planla raporun istemci/düzenleyici sürümleri.
Denetim günlüğü ve değişmezlik: eserlerin saklanması, imzalı raporlar, biletlere bağlantı, CMDB, yayın günlükleri.
Kullanıcı verileri: Örnek günlüklerde depersonalizasyon/maskeleme.
Bildirim süreleri: sözleşmelere ve yönetmeliklere bağlı (örn. İlk bildirim başına n saat).

13) Anti-desenler

"Vasya suçludur" - sistemik nedenler olmadan insan faktörü üzerinde bir durak.
Hipotez testlerinin eksikliği - sezgi ile sonuçlar.
Çok genel RCA ("hizmet aşırı yüklendi") - belirli bir değişiklik yok.
CAPA yok veya sahipler/son tarihler yok - raporun uğruna rapor verin.
Bilgiyi gizleme - güven kaybı, organizasyonu eğitememe.
SLO olmayan/iş SLI metrikleriyle aşırı yükleme.

14) Araçlar ve uygulamalar

Meta verilerle RCA deposu (wiki/bilgi tabanı): hizmet, SEV, nedenler, CAPA, durum.
Şablonlar ve botlar: Bir olaydan bir rapor karesi oluşturma (zaman çizelgesi, grafikler, sürümler).
Nedensellik grafiği: bir olay-nedensel haritanın oluşturulması (örneğin, günlüklere/izlere dayanarak).
Kaos kataloğu: sahnedeki geçmiş olayları yeniden üretmek için komut dosyaları.
"RCA'dan sonra" panolar: CAPA etkisini doğrulayan bireysel widget'lar.

15) Kontrol listesi "yayına hazır"

• Zaman çizelgeleri ve eserler tamamlandı ve doğrulandı.
• Testler/deneyler tarafından tanımlanan ve kanıtlanmış kök nedenler.
• Kök ve katkıda bulunan nedenler ayrılır.
• CAPA sahipler, son tarihler, ölçülebilir etki metrikleri içerir.
• 14/30 gün içinde bir doğrulama planı var.
• Dış paydaşlar için versiyon hazırlanmıştır (gerekirse).
• Rapor teknik/yüzde incelemesini geçti.

16) Alt satır

RCA formalite adına bir retrospektif değil, sistem için bir öğrenme mekanizmasıdır. Gerçekler toplandığında, nedensellik kanıtlanır ve CAPA'lar metriklere kilitlenir ve deneylerle test edilir, organizasyon her seferinde daha istikrarlı hale gelir: SLO'lar daha istikrarlıdır, nüks riski daha düşüktür ve kullanıcı ve düzenleyici güven daha yüksektir.