Çok Katmanlı Ölçüm ve Arıza Teşhisi Labı

İlk laboratuvar dersinde karar sorusu, yazılı yetki, izole ortam ve koşu günlüğünü kurdun. Şimdi kurgusal Ekin Lojistik'in sabah sevkiyat planlama ekranındaki gecikmeyi çok katmanlı ölçümle ayıracaksın. Senaryo tamamen eğitim örneğidir; Arven Holding'e veya gerçek müşteriye ait değildir. Laboratuvar izole ve sentetik veriyle yürütülür; üretime trafik gönderme yetkisi yoktur. Müşteri 'ekran bazen yavaş' demiştir. Bu sözden depolama, ağ veya uygulama kök nedeni çıkarılamaz. İlk karar sorusu, darboğaz hipotezlerinden hangisinin eldeki ölçümle desteklendiği ve sonraki doğrulamanın ne olduğudur. Microsoft Azure Well-Architected performans ilkeleri iş açısından kritik akış, gerçekçi hedef, temsilî baseline ve değişen yükün ölçülmesini önerir. Azure tasarım ilkeleri burada vendor bağımsız yöntem olarak kullanılır. Ders için yaklaşık 28 dakika anlatı, 33 dakika ölçüm tasarımı ve 15 dakika kontrol planla. Çıktın katmanlar arası zaman çizelgesi, kontrollü deney matrisi ve sınırlı karar notudur.

Uçtan uca akışı dört noktada işaretle: kullanıcı eylemi ve tarayıcı yanıtı, uygulama/API işleme, veri sorgusu, altyapı I/O ve ağ yolu. Aynı işlem ID'si veya iz korelasyonu yoksa farklı saatlerdeki grafikler tek olaymış gibi birleştirilemez. Saatlerin senkronu ve zaman dilimi kaydı ilk koşuldur. İş sonucu için medyan, p95 gecikmesi, hata oranı ve işlem hacmini birlikte düşün; yalnız ortalama değer az sayıda kötü kullanıcı deneyimini saklayabilir. Kurgusal baseline örneğinde on işlemin sekizi 2 saniye, ikisi 18 saniye sürebilir; ortalama 5,2 saniye yalnız dağılımı gizler. Bu sayı müşteri gerçeği veya kabul eşiği değildir. Başlangıç koşusundaki veri seti, eşzamanlı kullanıcı, warm/cold cache, batch işleri ve uygulama sürümü yazılır. Farklı saatlerdeki iki ölçümü karşılaştırmadan önce iş yükü farkını not et. Baseline doğrulanmamışsa alternatif iyileştirme yüzdesi yayımlama. Müşterinin gerçek kabul eşiği de öğrenilmeden teknik iyileşmeyi iş başarısı sayma.

OpenTelemetry'nin gözlemlenebilirlik açıklaması trace'i isteğin bileşenler arasındaki yolu, metric'i zaman aralığında sayısal özet, log'u zaman damgalı olay kaydı olarak ayırır. Üç sinyal birbirinin yerine geçmez. Tek bir kullanıcı isteğinin trace'i API'de 800 ms, veri çağrısında 500 ms gösterebilir; aynı dakikadaki storage grafiğinde 2 ms hizmet süresi görülmesi bu gözlemi otomatik çürütmez. Veri çağrısı içinde connection pool beklemesi, lock veya istemci kuyruk süresi olabilir. İki metrik farklı kapsam ve örneklem kullanır. Ekin labında trace ID, run ID, ortam sürümü ve veri seti etiketiyle eşleştirme yap. Trace üretilemeyen bileşen için yüksek güvenli çıkarım yapmak yerine o boşluğu belirle ve uygulama ekibinden ek gözlem iste. Loglar işlemle ilişkiliyse hata ve retry örüntüsü ayırt edilebilir; ilişkisiz log yığını kök neden değildir. Kişisel veri veya token içeren log alanları lab kanıtına alınmaz. Telemetri aracının kendisi de overhead yaratabilir; örnekleme oranı ve saat kayması kaydedilir.

Katman matrisi gözlem, olası neden ve ayırt edici test sütunları taşısın. Uygulamada thread pool doluluğu, connection pool beklemesi ve sorgu planı; compute tarafında CPU ready, bellek baskısı ve NUMA etkisi; storage tarafında host queue ile array hizmet süresi; ağda retransmit, RTT ve hata sayaçları ayrı ölçülür. Hiçbir göstergenin adı tek başına suçlu katmanı seçmez. Örneğin yüksek CPU kullanımı yoğun faydalı işlem olabilir; yüksek IOPS de iyi iş çıkaran sağlıklı sistemin belirtisi olabilir. Korelasyon göster: kullanıcı p95 sıçradığı aynı koşuda API span'ı ve sorgu beklemesi de artıyor mu? Bir sistemde üst katman beklerken alt katman boş görünüyorsa kuyruk veya kilit noktası araştırılır. Seçilen metrik iş akışını yansıtmıyorsa yeni enstrümantasyon gerekir. Aynı anda üç ayarı değiştirme; hangi ayarın etkili olduğunu ayıramazsın. Bu ders ürün komut listesi değil, ölçüm anlamını ayırt etme çalışmasıdır.

Üç hipotezi ayrı koşularla sınayacaksın: H1 sorgu planı kaynak tüketiyor; H2 host veya storage kuyruk gecikmesi yaratıyor; H3 ağ yeniden iletimi API yanıtını uzatıyor. Her hipotez için beklenen gözlem ve onu yanlışlayacak gözlem yaz. H1 için aynı sentetik veri setinde sorgu planı değişiminin veri çağrısı süresi ve uçtan uca p95'e etkisi; H2 için kontrollü I/O yükünde host queue, array latency ve kullanıcı süresi; H3 için izinli izole ağ koşusunda retransmit ve RTT bağı değerlendirilebilir. Üretim ağına kasıtlı hata enjekte edilmez. Kontrol koşusunda yazılım sürümü, cache ve eşzamanlı iş değişmiyorsa sonuç kıyaslanabilir; değişiyorsa koşuyu geçersiz işaretle. Test sırasını rastgele veya dengeli planlamak cache ısınması gibi sıra etkisini azaltabilir. Microsoft performans ilkeleri hipotez ve baseline ile ölçümün tekrar edilmesini, sistemin bütününe bakılmasını önerir. Burada amaç gerçek Ekin sistemine komut uygulamak değil; kendi izole labında ayırt edici deney kurmaktır.

Kurgusal koşu örneği düşün: sorgu planı düzeltildiğinde veri çağrısı p95'i 900 ms'den 300 ms'ye iner ama kullanıcı ekranı p95'i 8 saniyeden 7,8 saniyeye düşer. Bu H1'in veri katmanındaki etkisini destekler, toplam sorunun tek nedeni olduğunu göstermez. Eşzamanlı başka API span'ı uzunsa ikinci hipotez gerekir. Ağ retransmit'i artmadan kullanıcı gecikmesi yükseliyorsa H3 bu koşulda zayıflar; bütün ağ sorunlarını ebediyen dışlamaz. Storage array latency artarken host queue sabit olabilir veya tam tersi; ölçümün hangi katmanı kapsadığı yazılmalı. Karar tablosunda 'desteklendi', 'zayıfladı', 'kararsız' statülerini kullan. Ham verinin sınırlı temsilini ve varyansını gizleme. Başarı ölçüsünü testten sonra ayarlamak seçici yorumdur. Test sürecinde yetki kapsamı değişirse koşu durur ve yeni onay gerekir. Elde edilen metrik, müşteri iş hedefi doğrulanmadığı sürece teknik bulgudur, sözleşmesel performans taahhüdü değildir.

Labın sonunda bir kök neden hikâyesi uydurma baskısı olabilir. Bulguları gözlem, yorum, karşı kanıt ve açık soru olarak dört satırda sun. Bir hipotez destekleniyorsa kanıtın veri, yük, ortam ve süre sınırını ekle. İki hipotez aynı anda mümkünse karar 'daha fazla ölçüm' olabilir. Müşterinin operasyon ekibi ölçüm penceresini değiştirirse eski koşular yeni dönemi temsil etmeyebilir. Teknik öneri ADR/HLD ve BoM satırlarına etki yapabilir, ancak satış fiyatı veya lisans hakkı ayrıca onaylanır. Ekin labında depolama değişikliği önerisi yalnız benchmark'a değil uçtan uca iş metriği ve katmanlar arası kanıta dayanmalı. Sorgu düzeltmesi güçlü aday olsa bile bakım penceresi, rollback, veri bütünlüğü ve uygulama sahibi kararı açık kalır. 'Üç koşuda iyileşme' ifadesi üretim SLA'sı değildir. Yönetici özetinde önce iş etkisi ve karar seçeneği, sonra grafik göster; teknik eki isteyen okuyucuya ham koşu günlüğü ve hesap yöntemini ver. Grafik ekseninin birimi, zaman aralığı ve örnek sayısı görünür olmalı.

Karar seçenekleri: ölçümle desteklenen sınırlı iyileştirmeyi pilotla; başka hipotezi test et; ortam temsilini iyileştir; veya kanıt ve yetki açığı nedeniyle dur. Her seçeneğin owner, takvim, kabul ölçüsü ve başarısızlık durumunda geri dönüşü olsun. Müşteri gerçek sabah işlem hacmini henüz paylaşmadıysa bu eksiklik sonraki POC planının giriş koşuludur. Lab sunumundan sonra izole ortam kapatılır, geçici erişimler kaldırılır ve sentetik verinin saklama kaydı güncellenir. Karar paketi kullanıcı deneyimi, uygulama trace'i, veri katmanı ve altyapı ölçülerinin aynı run ID'sine bağlı olduğunda başka bir ekip tarafından denetlenebilir. Bir sonraki laboratuvar dersi kontrollü dayanıklılık, kurtarma ve güvenlik değişikliklerine geçer; orada arıza enjekte etme veya failover için daha sıkı işletim yetkisi gerekecektir. Bugünkü dersin ölçüm yöntemi o çalışmanın ön koşuludur: normal durum baseline'ı olmadan hata sonrası kötüleşmeyi veya iyileşmeyi adil kıyaslayamazsın. Sorumlu pre-sales uzmanı belirsizlikten utanmaz; hangi sorunun henüz yanıtlanmadığını ve yanıt için güvenli en küçük deneyi açıklar.