Operasyonel Analiz

1) Operasyonel analitik nedir ve neden gereklidir?

Operational Analytics (Ops Analytics), gözlemlenebilirlik (metrikler/günlükler/yollar), ITSM (olaylar/sorunlar/değişiklikler), CI/CD (sürümler/yapılandırmalar), sağlayıcılar (PSP/KYC/CDN/Bulut), FinOps (maliyetler) ve iş SLS I (ödemelerin başarısı, Kayıt), karar vermek için tek pencerelere ve panolara dönüştü.

• Erken teşhis ve nedenlerin doğru ilişkilendirilmesi yoluyla MTTD/MTTR'yi azaltmak;
• SLO'ları ve hata bütçelerini kontrol altında tutmak;
• Bağlantı değişiklikleri - etki (yayınlar/yapılandırmalar - SLI/SLO/şikayetler/maliyetler)
• Ekiplere ve yönetime self servis analizler verin.

2) Kaynaklar ve kanonik veri katmanı

Telemetri: metrikler (SLI/kaynaklar), günlükler (örnekleme/PII sürümü), yollar (trace_id/span_id, serbest bırakma etiketleri).
ITSM/Olay modülleri: SEV, T0/Detected/Ack/Declared/Mitigated/Recovered zaman damgaları, RCA/CAPA.
CI/CD & Config: sürümler, taahhütler, kanarikler/mavi-yeşil, bayrak durumu, hedef yapılandırmaları.
Sağlayıcılar: Durumlar/SLA'lar, gecikmeler, hata kodları, rota ağırlıkları.
FinOps: etiketler/hesaplar/kiracılar tarafından maliyet, $/birim (1k operalar.) .
DataOps: pencere tazeliği, DQ hataları, soy.

Anahtar ilke, tanımlayıcılar aracılığıyla tek bir korelasyondur: 'hizmet', 'bölge', 'kiracı', 'release _ id', 'change _ id', 'incident _ id', 'sağlayıcı', 'trace _ id'.

3) Tek veri modeli (basitleştirilmiş çerçeve)

dim_service(service_id, owner, tier, slo_targets…)
dim_time(ts, date, hour, tz)
dim_region(region_id, country, cloud)
dim_provider(provider_id, type, sla)
fact_sli(ts, service_id, region_id, tenant, metric, value, target, window)
fact_incident(incident_id, service_id, sev, t0, t_detected, t_ack, t_declared, t_mitigated, t_recovered, root_cause, trigger_id, burn_minutes)
fact_change(change_id, type(code    config    infra), service_id, region_id, started_at, finished_at, canary_pct, outcome(ok    rollback), annotations)
fact_cost(ts, service_id, region_id, tenant, cost_total, cost_per_1k)
fact_provider(ts, provider_id, region_id, metric(latency    error    status), value)
fact_dq(ts, dataset, freshness_min, dq_errors)

4) SLI/SLO ve iş metrikleri

Бизнес -SLI: 'payment _ succcess _ ratio', 'signup _ completion', 'deposit _ latency'.
Тех -SLI: 'availability', 'http _ p95', 'error _ rate', 'queue _ depth'.
SLO katmanı: hedefler + yanma oranı (kısa/uzun pencere), ihlallerin otomatik ek açıklamaları.
Normalleştirme: 1k başarılı işlem/kullanıcı/trafik başına göstergeler.

5) Korelasyonlar ve nedenlerin ilişkilendirilmesi

SLI/SLO ↔ sürümleri/yapılandırmaları: grafikler üzerine ek açıklamalar; Neden ve sonuç raporları (değişim olaylarının oranı; MTTR değişim olayları).
İş SLI ↔ sağlayıcılar: Rotaların ağırlıkları ile gecikme/hatalar, her bir sağlayıcının SLO özlemesine katkısı.
Kapasite/kaynaklar ↔ gecikme süresi - havuzun aşırı ısınması - p95 büyümesi - dönüşüm etkisi.

6) Anormallikler ve tahmin

Anomali algılama: mevsimsellik + yüzdelik eşikler + değişim arama özellikleri (sürümden önce/sonra).
Tahmin: haftalık/mevsimsel yük modelleri, tükenme hatası bütçe tahmini, maliyet tahmini ($/birim).
Gardrails: Yalnızca çekirdek kaynakları (sentetik + RUM + iş SLI) olduğunda uyarır.

7) Vitrinler ve gösterge panoları (referans)

1. Executive 28d: SEV karışımı, medyan MTTR/MTTD, SLO uyumu, $/unit, en önemli nedenler.
2. SRE Ops: SLI/SLO + yazma oranı, Sayfa Fırtınası, İşlem Yapılabilir %, Hata Oranını Değiştir.
3. Değişiklik Etkisi: SLI/SLO/şikayetler, geri dönüşler ve etkileri ↔ yayınlar/yapılandırır.
4. Sağlayıcılar: PSP/KYC/CDN durum hatları, iş SLI üzerindeki etkileri, yanıt süreleri.
5. FinOps: 1k txn başına maliyet, günlükler/çıkış, maliyet anormallikleri, öneriler (örnekleme, depolama).
6. DataOps: pencere tazeliği, DQ hataları, boru hattı SLA'ları, dolgu başarısı.

8) Veri kalitesi ve yönetişim

Etkinlik sözleşmeleri: olaylar/sürümler/SLI'lar için açık şemalar (zorunlu alanlar, tek tip saat dilimleri).
DQ-dama: tamlık, anahtarların benzersizliği, zaman çizelgesi tutarlılığı (t0≤detected≤ack...).
Lineage: panodan kaynağa (izlenebilir).
PII/sırlar: politikaya göre düzenleme/maskeleme; Kanıt için WORM.
SLA tazeliği: Ops ≤ 5 dakika gecikme sergiliyor.

9) Operasyonel analitik olgunluk metrikleri

Kapsam: Vitrinlerdeki ve SLO panolarındaki kritik hizmetlerin %'si (hedef ≥ %95).
Tazelik: 5 dakika ≤ tazeliği ile widget payı (hedef ≥ %95).
İşlem yapılabilirlik: % kontrol panelinden aksiyona geçiş (playbook/SOP/ticket) ≥ %90.
Algılama Kapsamı: Olayların ≥ %85'i otomasyon tarafından tespit edilir.
Atıf Oranı: Doğrulanmış nedeni ve tetikleyicisi olan olayların yüzdesi %90 ≥.
Etki Payını Değiştir: Değişikliklerle ilgili olayların paylaşımı (eğilimi kontrol etme).
Veri Kalitesi: DQ hataları/hafta - QoQ ↓.

10) Süreç: veriden eyleme

1. Toplama - temizleme - vitrinin normalleştirilmesi - (ETL/ELT, ML için özellik katmanı).
2. Matris Algılama/Tahmin - Eskalasyon (IC/P1/P2/İletişim).
3. Eylem: oyun kitabı/SOP, serbest bırakma kapısı, özellik bayrağı, sağlayıcı anahtarı.
4. Kanıt ve AAR/RCA: zaman çizelgesi, grafikler, sürümlere/günlüklere/izlere bağlantılar.
5. CAPA ve ürün çözümleri: yanma dakikalarına ve $ etkisine göre önceliklendirme.

11) Sorgu örnekleri (fikir)

11. 1 Sürümlerin SLO üzerindeki etkisi (24 saat)

sql
SELECT r. change_id,
COUNT(i. incident_id) AS incidents,
SUM(i. burn_minutes) AS burn_total_min,
AVG(CASE WHEN i.root_cause='code' THEN 1 ELSE 0 END) AS code_ratio
FROM fact_change r
LEFT JOIN fact_incident i
ON i.trigger_id = r. change_id
WHERE r. started_at >= NOW() - INTERVAL '24 hours'
GROUP BY 1
ORDER BY burn_total_min DESC;

11. 2 Bölgeye göre sağlayıcılardan gelen sorunların paylaşımı

sql
SELECT region_id, provider_id,
SUM(CASE WHEN root_cause='provider' THEN 1 ELSE 0 END) AS prov_inc,
COUNT() AS all_inc,
100. 0SUM(CASE WHEN root_cause='provider' THEN 1 ELSE 0 END)/COUNT() AS pct
FROM fact_incident
WHERE t0 >= DATE_TRUNC('month', NOW())
GROUP BY 1,2
ORDER BY pct DESC;

11. 3 1k başarılı ödeme başına maliyet

sql
SELECT date(ts) d,
SUM(cost_total)/NULLIF(SUM(success_payments)/1000. 0,0) AS cost_per_1k
FROM fact_cost c
JOIN biz_payments b USING (ts, service_id, region_id, tenant)
GROUP BY d ORDER BY d DESC;

12) Eser desenleri

12. 1 Olay olay diyagramı (JSON, fragman)

json
{
"incident_id": "2025-11-01-042",
"service": "payments-api",
"region": "eu",
"sev": "SEV-1",
"t0": "2025-11-01T12:04:00Z",
"detected": "2025-11-01T12:07:00Z",
"ack": "2025-11-01T12:09:00Z",
"declared": "2025-11-01T12:11:00Z",
"mitigated": "2025-11-01T12:24:00Z",
"recovered": "2025-11-01T12:48:00Z",
"root_cause": "provider",
"trigger_id": "chg-7842",
"burn_minutes": 18
}

12. 2 Metrik katalog (YAML, fragman)

yaml metric: biz. payment_success_ratio owner: team-payments type: sli target: 99. 5 windows: ["5m","1h","6h","28d"]
tags: [tier0, region:eu]
pii: false

12. 3 Yönetici karnesi (bölümler)

1) SEV mix and MTTR/MTTD trends
2) SLO adherence and burn-out risks
3) Change Impact (CFR)
4) Providers: Degradation and switchover
5) FinOps: $/unit, log anomalies/egress
6) CAPAs: Status and Deadlines

13) Araçlar ve mimari desenler

Data Lake + DWH: Telemetri için "ham" katman, çözümler için vitrinler.
Akış işleme: Neredeyse gerçek zamanlı SLI/burn-rate, anomaliler için çevrimiçi özellikler.
Özellik Mağazası: Özelliklerin yeniden kullanımı (kanarya, mevsimsellik, sağlayıcı sinyalleri).
Anlamsal Katman/Metrik Deposu: Tekdüzen Metrik Tanımlar (SLO, MTTR...).
Erişim Denetimi: RBAC/ABAC, kiracılar/bölgeler için satır düzeyinde güvenlik.
Katalog/Lineage: arama, açıklamalar, bağımlılıklar, sahipler.

14) Kontrol listeleri

14. 1 Operasyonel analitiğin başlatılması

• Onaylı sözlükler SLI/SLO, SEV, nedenler, değişiklik türleri.
• Olay diyagramları ve tekdüze zaman dilimleri.
• Telemetri konektörleri, ITSM, CI/CD, sağlayıcılar, faturalandırma.
• Vitrinler: SLI/SLO, Olaylar, Değişiklikler, Sağlayıcılar, FinOps.
• Executive/SRE/Change/Providers panoları mevcuttur.
• Quorum uyarıları ve bastırma bakım pencerelerinde yapılandırılmıştır.

14. 2 Haftalık Ops İnceleme

• SEV trendleri, MTTR/MTTD, SLO özlüyor, dakikaları yakıyor.
• Değişim Etkisi ve CFR, geri dönüş durumu.
• Sağlayıcı olayları ve tepki süreleri.
• FinOps: $/unit, log anomalileri/çıkış.
• CAPA durumu, suçluluklar, öncelikler.

15) Anti-desenler

Harekete geçmeden "grafikler duvarı".
Komutlar için farklı metrik tanımları (anlamsal katman yok).
Sürüm/pencere ek açıklamalarının eksikliği - nedenlerin zayıf ilişkilendirilmesi.
P95/p99 yerine orta yönlendirme.
Hacim için normalleşme yoktur - büyük hizmetler'daha kötü görünür ".
Günlüklerde/vitrinlerde PII, retansiyon bozukluğu.
Veriler "durgunlaşır" (gerçek zamanlı widget'lar için> 5-10 dk).

16) Uygulama Yol Haritası (4-8 hafta)

1. Ned. 1: metrik sözlüğü, olay şemaları, kimlik korelasyonu ile ilgili anlaşmalar; SLI/SLO ve ITSM bağlantısı.
2. Ned. 2: Olaylar/Değişiklikler/Sağlayıcılar vitrinler, sürüm ek açıklamaları; Yönetici ve SRE panoları.
3. Ned. 3: FinOps tabakası ($/unit), SLI ile ligament; Nisap ile anomali tespiti.
4. Ned. 4: self servis (semantik katman/metrik mağaza), katalog ve soy.
5. Ned. 5-6: yük/maliyet tahmini, sağlayıcılara raporlar, CAPA vitrini.
6. Ned. 7-8: % ≥95 Tier-0/1 kapsamı, SLA tazeliği ≤5 dakika, düzenli Ops incelemeleri.

17) Alt satır

Operasyonel analitik bir karar makinesidir: metriklerin tekdüze tanımları, taze vitrinler, nedenlerin doğru ilişkilendirilmesi ve oyun kitaplarına ve SOP'lara doğrudan geçişler. Böyle bir sistemde, ekip hızlı bir şekilde sapmaları tespit eder ve açıklar, sürümlerin ve sağlayıcıların etkisini doğru bir şekilde değerlendirir, maliyetleri yönetir ve riski sistematik olarak azaltır - ve kullanıcılar istikrarlı bir hizmet alır.