Kapasite ve Performans İzleme: Metrikleri Okumak ve Geleceği Planlamak

Kazanimlar:

• Ortalama yerine percentile (p95/p99) ve baseline kullanarak metrikleri yapay zeka desteğiyle doğru yorumlayabilme
• Mevsimselliği trendden ayırıp kapasite projeksiyonunu tek sayı değil iyimser-kötümser aralık olarak üretebilme
• Kaynak yatırımı ve alarm eşiği kararlarının kaynak temin süresi ve iş bağlamıyla birlikte insana ait olduğunu kavrayabilme

Kapasite ve Performans İzleme: Metrikleri YZ ile Okumak ve Geleceği Planlamak

Bir sistemin sağlığını gözünüzle göremezsiniz; onu metrikler üzerinden anlarsınız. Metrik, bir sistemin ölçülebilir bir özelliğinin zamana bağlı sayısal değeridir: CPU kullanımı, bellek doluluğu, disk boş alanı, ağ gecikmesi, saniyedeki istek sayısı. Performans izleme, bu metrikleri sürekli toplayıp "sistem şu an iyi mi" sorusunu yanıtlar. Kapasite planlama ise bir adım öteye geçer: "bu gidişle ne zaman yetersiz kalırım, ne zaman yeni kaynak almalıyım" sorusunu yanıtlar. İşte YZ, metrik yığınlarını yorumlamakta, anormallikleri işaretlemekte, trendi okuyup gelecek projeksiyonu üretmekte çok yetenekli bir asistandır. Ama tek bir uyarı her şeyin üstündedir: YZ geçmiş veriden örüntü çıkarır; kaynak yatırımı, ölçeklendirme ve alarm eşiği kararlarını bağlamıyla veren sizsiniz.

Bu ünitede baseline (normal davranış çizgisi), anomali (normalden sapma), percentile (yüzdelik dilim) gibi izleme kavramlarını; YZ ile metrik yorumlamayı; trend ve büyüme tahminini; ve doğru alarm eşiği kurmayı öğreneceksiniz.

Ortalama yalan söyler: neden percentile?

İzlemede en yaygın hata, her şeyi ortalamayla ölçmektir. Diyelim yanıt süreniz ortalama 200 ms. Kulağa iyi geliyor. Ama kullanıcıların %5'i 8 saniye bekliyor olabilir; ortalama bunu gizler. Bu yüzden profesyoneller percentile kullanır: p95 = "isteklerin %95'i bu sürenin altında" demektir. p95 yanıt süresi 8 saniyeyse, her yirmi kullanıcıdan biri berbat bir deneyim yaşıyor demektir — ortalama bunu asla göstermez. YZ'ye metrik verirken hangi istatistiği istediğinizi netleştirin: "bana ortalamayı değil p50, p95 ve p99'u yorumla." Bu tek alışkanlık, gizli sorunları ortaya çıkarır.

İpucu: Kullanıcı deneyimini ilgilendiren her metrikte (yanıt süresi, gecikme) percentile bakın; ortalama yerine p95/p99 sizi asıl acı çeken azınlığa götürür. Kaynak metriklerinde (CPU, bellek) ise hem zirve (peak) hem sürekli (sustained) değere bakın.

Baseline olmadan anomali olmaz

Bir metriğin "anormal" olduğunu söyleyebilmek için önce "normal"i bilmeniz gerekir. Baseline, sistemin sağlıklı günlerdeki tipik davranış aralığıdır: "bu servis hafta içi öğlen CPU'su tipik olarak %40–60". Baseline olmadan bir %70 değeri korkutucu mu normal mi bilemezsiniz. YZ'ye geçmiş sağlıklı veriyi verip "bu metriğin normal aralığını ve günlük/haftalık örüntüsünü çıkar" diyerek baseline kurdurabilirsiniz. Sonra yeni veriyi bu baseline'a göre yorumlatırsınız: "bu değer normalin neresinde?" Anomali, baseline'dan anlamlı ve sürekli sapmadır — tek bir ani sıçrama çoğu zaman gürültüdür.

Adım adım: kapasite projeksiyonu

1. Temiz ve yeterli geçmiş topla. Trend için en az birkaç haftalık, tercihen aylık veri gerekir. Az veriyle yapılan projeksiyon tahmin değil tahmindir.
2. Mevsimselliği ayır. Trafik hafta sonu düşer, ay sonu artar, kampanyada patlar. YZ'ye bu döngüleri söyleyin ki büyümeyi mevsimsel dalgalanmayla karıştırmasın.
3. Trendi çıkart. "Bu disk son 8 haftada haftada ortalama kaç GB büyüdü?" YZ büyüme hızını hesaplar.
4. Projeksiyon iste, aralıkla. "Bu hızla disk ne zaman %90 dolar?" — ama tek bir tarih değil, iyimser/kötümser aralık isteyin. Gelecek belirsizdir; tek sayı sahte kesinliktir.
5. Karar eşiğini insanla belirle. Projeksiyon "6 hafta sonra dolar" diyorsa, kaynak temini süresini (satın alma, onay) düşünüp bugün mü aksiyon alacağınıza siz karar verirsiniz.
6. Alarmı doğru kur. Çok hassas alarm gürültü ve alarm yorgunluğu üretir; çok gevşek alarm olayı kaçırır. YZ'den eşik önerisi alın ama son eşiği kendi risk toleransınızla belirleyin.

Üç mini vaka

Vaka 1 — Ortalama gizledi, p99 gösterdi. Bir ekip API'lerinin "ortalama 180 ms, gayet iyi" olduğunu düşünüyordu. Metrikleri YZ'ye verip percentile yorumu isteyince p99'un 6.400 ms olduğu ortaya çıktı — her yüz istekten biri 6 saniyeden yavaştı. Kök neden bir yavaş veritabanı sorgusuydu. Ortalama sağlıklı görünürken, azınlık berbat deneyim yaşıyordu.

Vaka 2 — Projeksiyon 3 hafta önceden uyardı. Bir yönetici, log diskinin doluluk verisini YZ'ye verdi. YZ haftalık ~7 GB büyüme trendi çıkardı ve mevcut hızla 19 gün içinde %90'a ulaşılacağını, iyimser-kötümser aralıkla 16–23 gün olarak projekte etti. Yeni disk temini 10 gün sürdüğü için ekip hemen sipariş verdi ve kesintiyi gerçekleşmeden önledi.

Vaka 3 — Sahte anomaliden dönüş. Bir izleme alarmı her Pazar gece CPU %95'e çıkıyor diye ötüyordu. Mühendis paniklemeden önce baseline'ı YZ'ye çıkarttırdı: bu sıçrama her hafta aynı saatte olan planlı bir yedekleme işiydi, yani normalin parçasıydı. Anomali değildi; baseline eksikti. Alarm eşiği o zaman dilimi için düzeltildi ve gereksiz gece uyandırmaları bitti.

Dört kopyalanabilir şablon

1) Metrik yorumlama (percentile):

Aşağıda [servis] yanıt süresi metrikleri var (maskeli).Bana ortalama değil p50, p95 ve p99'u yorumla. p99 ile p50arasındaki fark ne anlama gelir, hangi kullanıcı deneyimisorununa işaret eder? Uydurma değer ekleme, sadece verdiğimveriyi yorumla. Veri: [metrikler]

2) Baseline çıkarma:

Aşağıda son 4 haftanın sağlıklı [metrik] verisi var.Bu metriğin (1) normal aralığını (2) günlük ve haftalıkörüntüsünü (ör. gece düşük, öğlen zirve) çıkar. Sonratek bir yeni değer vereceğim; onu bu baseline'a göre"normal / dikkat / anormal" diye sınıflandır.Veri: [geçmiş metrik]

3) Kapasite projeksiyonu (aralıkla):

Aşağıda [kaynak] doluluğunun son 8 haftalık verisi var.(1) Haftalık ortalama büyüme hızını hesapla,(2) mevsimsel etkileri belirt,(3) mevcut hızla %90 eşiğine ulaşma zamanını İYİMSER veKÖTÜMSER aralıkla tahmin et. Tek tarih verme, aralık verve varsayımlarını yaz. Veri: [zaman serisi]

4) Alarm eşiği önerisi:

[Metrik] için baseline'ım şu: [aralık]. Amacım gerçeksorunları kaçırmadan yanlış alarmı en aza indirmek.Bana (1) uyarı ve (2) kritik eşiği için öneri ver,her birini gerekçelendir ve alarm yorgunluğu riskinideğerlendir. Son eşiği ben belirleyeceğim.

Zayıf prompt / Güçlü prompt

Zayıf prompt:

Sunucum yavaş mı?

Bağlam, metrik ve baseline yok. YZ ne "yavaş"ın tanımını bilir ne de kıyaslayacağı bir normal değeri. Cevap boş bir tahmindir.

Güçlü prompt:

Rolün: kapasite planlama uzmanı. Aşağıda bir API'nin son14 günlük p95 yanıt süresi ve istek/saniye verisi var(maskeli). Baseline'ım p95 için 250-400 ms. Bana (1) son14 günde baseline dışına çıkan günleri işaretle, (2) yanıtsüresi ile istek yükü arasında görünür bir ilişki var mısöyle (hipotez olarak), (3) bu trend sürerse 30 gün sonrap95 nereye gider, aralıkla tahmin et. Veri: [zaman serisi]

Metrik türü

Yanlış ölçüm

Doğru ölçüm

Yanıt süresi

Sadece ortalama

p50, p95, p99

CPU/bellek

Anlık değer

Zirve + sürekli + baseline

Disk büyümesi

Bugünkü doluluk

Haftalık trend + projeksiyon

Anomali

Tek sıçrama

Baseline'dan sürekli sapma

Alarm

Keyfi tek eşik

Gerekçeli uyarı + kritik eşik

Sık yapılan hatalar

• Her şeyi ortalamayla ölçmek. Ortalama, azınlığın yaşadığı kötü deneyimi gizler; percentile'a bakın.
• Baseline'sız anomali aramak. Normali bilmeden bir değerin anormal olduğunu söyleyemezsiniz; sahte alarm üretirsiniz.
• Mevsimselliği trend sanmak. Kampanya zirvesini kalıcı büyüme sayıp gereksiz kaynak almak paraya mal olur.
• Tek sayılı projeksiyona güvenmek. "Tam 19 gün" sahte kesinliktir; iyimser-kötümser aralık kullanın.
• Kaynak temin süresini unutmak. Projeksiyon eşiği ile satın alma süresini birlikte düşünmeyen ekip kesintiye yakalanır.

Dikkat: YZ'nin trend projeksiyonu geçmişin geleceğe aynen süreceğini varsayar. Yeni bir ürün lansmanı, bir müşteri göçü veya bir mimari değişiklik bu varsayımı bozar. Projeksiyonu bağlamınızla düzeltmek sizin işinizdir.

Özetle

Performans izleme "şu an iyi mi", kapasite planlama "ne zaman yetmez" sorusunu yanıtlar. YZ metrikleri yorumlamakta, baseline çıkarmakta, anomali işaretlemekte ve trend projekte etmekte güçlü bir ortaktır. Ama ortalama yalan söyler — percentile kullanın; baseline olmadan anomali olmaz — normali önce kurun; mevsimselliği trendden ayırın; ve projeksiyonu tek sayı değil aralık olarak alın. Kaynak yatırımı ve alarm eşiği kararları, kaynak temin süresi ve iş bağlamıyla birlikte insana aittir.

Uygulama görevi

Kendi sistemlerinizden bir kaynağın (disk, bellek, yanıt süresi) son birkaç haftalık verisini alın ve hassas alanları maskeleyin. Yukarıdaki "Baseline çıkarma" şablonuyla normal aralığı ve örüntüyü çıkartın. Sonra "Kapasite projeksiyonu" şablonuyla bir eşiğe ne zaman ulaşacağınızı iyimser-kötümser aralıkla tahmin ettirin. Bir de yanıt süresi metriğinizi "percentile" şablonuyla yorumlatıp ortalamanın gizlediği bir şey var mı bakın. Bulgularınızı ve alacağınız aksiyonu 5 maddede yazın.

Kontrol listesi

• [ ] Yanıt süresi metriklerinde ortalama yerine p95/p99'a baktım mı?
• [ ] Anomali aramadan önce sağlıklı veriden bir baseline kurdum mu?
• [ ] Mevsimsel dalgalanmayı kalıcı trendden ayırdım mı?
• [ ] Projeksiyonu tek tarih değil iyimser-kötümser aralık olarak aldım mı?
• [ ] Kaynak temin süresini projeksiyon eşiğiyle birlikte değerlendirdim mi?
• [ ] Alarm eşiğini YZ önerisiyle değil kendi risk toleransımla mı belirledim?