15 Kas 2025·8 dk
Uygulama Sağlığını ve İş KPI'larını İzleyen Bir Web Uygulaması Oluşturun
Uptime, gecikme ve hataları gelir, dönüşümler ve churn ile birleştiren bir web uygulaması nasıl kurulur—panolar, uyarılar ve veri tasarımı dahil.
Uptime, gecikme ve hataları gelir, dönüşümler ve churn ile birleştiren bir web uygulaması nasıl kurulur—panolar, uyarılar ve veri tasarımı dahil.
Birleştirilmiş “Uygulama Sağlığı + İş KPI'ları” görünümü, ekiplerin sistemin çalışıp çalışmadığını ve ürünün işin önem verdiği sonuçları verip vermediğini aynı yerde görmesini sağlar. Olaylar için gözlemlenebilirlik aracından performans için analitik aracına gidip gelmek yerine, noktaları tek bir iş akışında bağlarsınız.
Teknik metrikler yazılımınızın ve altyapınızın davranışını tanımlar. Cevap verir: Uygulama yanıt veriyor mu? Hata alınıyor mu? Yavaş mı? Yaygın örnekler: gecikme, hata oranı, throughput, CPU/ram kullanımı, kuyruk derinliği, bağımlılık erişilebilirliği.
İş metrikleri (KPI'lar) kullanıcı ve gelir sonuçlarını tanımlar. Cevap verir: Kullanıcılar başarılı mı? Para kazanıyor muyuz? Örnekler: kayıtlar, aktivasyon oranı, dönüşüm, ödeme tamamlama, ortalama sipariş değeri, churn, iadeler, destek talep hacmi.
Amaç kategorilerden birini değiştirmek değil—amaç onları bağlamak: böylece 500 hata sıçraması sadece “grafikte kırmızı” olmaz, aynı zamanda “checkout dönüşümü %12 düştü” ile açıkça ilişkilendirilir.
Sağlık sinyalleri ve KPI'lar aynı arayüzde ve zaman penceresinde paylaşıldığında ekipler genelde şunları görür:
Bu rehber yapı ve kararlar üzerine odaklanır: metrikleri nasıl tanımlayacağınız, kimlikleri nasıl bağlayacağınız, veriyi nasıl depolayıp sorgulayacağınız ve panolar ile uyarıları nasıl sunacağınız. Bilinçli olarak belirli bir satıcıya bağlı değildir; böylece yaklaşımı hazır araçlarla, kendi çözümünüzü inşa ederek veya her ikisini birleştirerek uygulayabilirsiniz.
Her şeyi izlemeye çalışırsanız, kimsenin güvenmediği bir pano elde edersiniz. Basınç altındayken uygulamanın ne yapmasına yardımcı olması gerektiğini belirleyin: bir olay sırasında hızlı ve doğru kararlar almak ve hafta hafta ilerlemeyi izlemek.
Bir şey ters gittiğinde panolarınız hızla şu soruları cevaplamalı:
Bir grafik bu sorulardan birine yardımcı olmuyorsa, kaldırılmaya adaydır.
Çekirdek seti küçük ve ekipler arasında tutarlı tutun. Başlangıç için iyi bir liste:
Bunlar yaygın hata modlarına iyi eşlenir ve daha sonra uyarı için kolayca kullanılabilir.
Müşteri hunisini ve gelir gerçekliğini temsil eden metrikleri seçin:
Her metrik için bir sahip, bir tanım/doğru kaynak ve bir gözden geçirme sıklığı (haftalık veya aylık) tanımlayın. Hiç kimsenin sahibi olmadığı bir metrik sessizce yanıltıcı hale gelir ve olay kararlarınızı etkiler.
Sağlık grafikleri bir araçta, iş KPI panosu başka bir araçta ise olay sırasında “ne oldu” konusunda tartışmak kolaydır. İzlemeyi, performansın sonuçları açıkça etkilediği birkaç müşteri yolculuğu etrafında sabitleyin.
Geliri veya retention'ı doğrudan sürükleyen akışları seçin: onboarding, arama, checkout/ödeme, hesap girişi, içerik yayını gibi. Her yolculuk için ana adımları ve “başarı”nın ne anlama geldiğini tanımlayın.
Örnek (checkout):
Her adımı en güçlü etkileyen teknik sinyalleri eşleyin. İşte uygulama sağlık izlemenin iş ile alakalı hale geldiği yer.
Checkout için öncü gösterge “ödeme API'si p95 gecikmesi” olabilir; geciken gösterge ise “checkout dönüşüm oranı”dır. Her ikisini aynı zaman çizelgesinde görmek nedenselliği netleştirir.
Bir metrik sözlüğü kafa karışıklığını ve “aynı KPI farklı matematik” tartışmalarını önler. Her metrik için belgeleyin:
Sayfa görüntülemeleri, ham kayıtlar veya “toplam oturumlar” gibi metrikler bağlam olmadan gürültülü olabilir. Kararlara dayalı metrikleri tercih edin (tamamlama oranı, hata bütçesi tüketimi, ziyaret başına gelir). Ayrıca KPI'ları çoğaltmayın: bir resmi tanım, üç çelişen panodan daha iyidir.
UI kodunu yazmadan önce gerçekte ne inşa edeceğinize karar verin. Bir “sağlık + KPI'lar” uygulaması genelde beş çekirdek bileşene sahiptir: collector'lar (metrikler/loglar/trace'ler ve ürün olayları), ingestion (kuyruklar/ETL/streaming), depolama (zaman serisi + warehouse), bir veri API'si (tutarlı sorgular ve izinler için) ve bir UI (panolar + drill-down). Uyarı UI'nin bir parçası olabilir veya mevcut on-call sistemine devredilebilir.
Hızlı bir UI ve iş akışı prototipi yapmak istiyorsanız, Koder.ai gibi vibe-coding platformları chat tabanlı bir spesifikasyondan React tabanlı bir pano kabuğu ile Go + PostgreSQL backend'i ayağa kaldırmanıza yardımcı olabilir; ardından drill-down gezinmesi ve filtreler üzerinde iterasyon yapabilirsiniz.
Ortamlara baştan plan yapın: prod verisi staging/dev ile karışmamalıdır. Ayrı proje kimlikleri, API anahtarları ve depolama bucket/tablo kullanın. “Prod vs staging karşılaştırması” yapmak istiyorsanız, bunu API'de kontrollü bir görünümle yapın—ham pipeline'ları paylaşmayın.
Tek pencere her şeyi yeniden uygulamak demek değildir. Şunları yapabilirsiniz:
Embed seçerseniz, net bir gezinme standardı tanımlayın (ör. “KPI kartından trace görünümüne”) ki kullanıcılar araçlar arasında savruluyormuş gibi hissetmesin.
Panolarınızın güvenilirliği arkasındaki verinin güvenilirliğine bağlıdır. Pipeline'ları inşa etmeden önce zaten “ne olduğunu bilen” sistemlerin bir listesini yapın ve her birinin ne sıklıkta yenilenmesi gerektiğine karar verin.
Güvenilirlik ve performansı açıklayan kaynaklarla başlayın:
Pratik kural: sağlık sinyallerini varsayılan olarak neredeyse gerçek zamanlı kabul edin; çünkü bunlar uyarıları ve olay müdahalesini tetikler.
İş KPI'ları genelde farklı ekiplerin sahip olduğu araçlarda yaşar:
Her KPI'nin saniye saniye güncellenmesine gerek yok. Günlük gelir batch olabilir; checkout dönüşümü daha taze veri isteyebilir.
Her KPI için basit bir gecikme beklentisi yazın: “Her 1 dakikada güncellenir”, “Saatlik”, veya “Ertesi iş günü”. Bunu UI'da direkt gösterin (örneğin: “Veri 10:35 UTC itibarıyla”). Bu yanlış alarmları önler ve “yanlış” sayılar yüzünden tartışmaları azaltır.
Hataları gelire bağlamak istiyorsanız tutarlı ID'lere ihtiyacınız var:
Her bir kimlik için bir “doğru kaynak” tanımlayın ve her sistemin bunu taşıdığından emin olun (analytics event'leri, loglar, faturalama kayıtları). Sistemler farklı anahtar kullanıyorsa, erken bir eşleme tablosu ekleyin—geriye dönük dikişleme pahalı ve hataya açıktır.
Her şeyi tek bir veritabanında saklamaya çalışırsanız genelde yavaş panolar veya pahalı sorgularla karşılaşırsınız. Daha temiz bir yaklaşım, uygulama sağlık telemetrisi ile iş KPI'larını farklı veri şekilleri ve okuma kalıpları olarak ele almaktır.
Gecikme, hata oranı, CPU, kuyruk derinliği gibi sağlık metrikleri yüksek hacimlidir ve zaman aralığıyla sorgulanır: “son 15 dakika”, “dündekiyle karşılaştır”. Bir zaman serisi veritabanı hızlı rollup'lar ve aralık taramaları için optimize edilmiştir.
Etiketleri/sınırları sınırlı ve tutarlı tutun (service, env, region, endpoint group). Çok fazla benzersiz etiket kardinaliteyi patlatır ve maliyeti artırır.
İş KPI'ları (kaydolmalar, ücretli dönüşümler, churn, gelir, siparişler) genelde join'ler, backfill'ler ve “as-of” raporlama gerektirir. Warehouse/lake bunun için daha uygundur:
Web uygulamanız tarayıcıdan doğrudan her iki depoya erişmemeli. Bir backend API oluşturun: her depo için sorgulama, izinleri uygulama ve tutarlı bir şema döndürme işi API'de olsun. Tipik desen: sağlık panelleri zaman serisi deposuna, KPI panelleri warehouse'a çarlar; drill-down uç noktaları her ikisinden de çekip zaman penceresine göre birleştirebilir.
Açık katmanlar belirleyin:
Yaygın pano görünümlerini (saatlik/günlük) önceden agregate edin ki kullanıcıların çoğu “her şeyi tarayan” pahalı sorguları tetiklemesin.
Bir pano, “Tamam mıyız?” ve “Değilsek, nereden bakmalıyım?” sorularını hızlıca cevapladığında başarılıdır. Her şeyi ölçmekten ziyade kararları kolaylaştıracak şekilde tasarlayın.
Çoğu ekip, bir mega-panodan ziyade amaçlı birkaç görünümle daha iyi iş yapar:
Her sayfanın üstünde tek bir zaman seçici koyun ve tutarlı hale getirin. Gerçekten kullanılan global filtreleri ekleyin—bölge, plan, platform ve belki müşteri segmenti. Amaç “US + iOS + Pro plan”ı “EU + Web + Free” ile yeniden grafik kurmadan karşılaştırabilmek.
Her sayfada teknik ve iş sinyallerini aynı zaman ekseninde bindiren en az bir korelasyon paneli koyun. Örnekler:
Bu, teknik olmayan paydaşların etkiyi görmesini sağlar ve mühendislerin müşteri sonuçlarını koruyan düzeltmeleri önceliklendirmesine yardımcı olur.
Kalabalıktan kaçının: daha az grafik, daha büyük yazı tipleri, net etiketler. Her ana grafik eşikler (iyi / uyarı / kötü) göstermeli ve mevcut durum hover olmadan okunabilmeli. Bir metrik anasayfaya hazır değilse genelde iyi/kötü aralığı konusunda anlaşma yoktur.
İzleme, doğru eylemi tetkiklediğinde kullanışlıdır. Service Level Objectives (SLO) kullanıcı deneyiminin “yeterli” olduğunu işletmeye uygun şekilde tanımlamanıza yardımcı olur—ve uyarılar müşteriler fark etmeden önce tepki vermenizi sağlar.
Kullanıcıların gerçekten hissettiği SLI'ları seçin: login, arama, ödeme gibi kilit yolculuklarda hata, gecikme ve erişilebilirlik—içsel metrikler değil.
Mümkünse, önce kullanıcı etkisi semptomlarına uyarı verin, sonra muhtemel nedenleri:
Neden uyarıları yine değerli, ama semptom tabanlı uyarılar gürültüyü azaltır ve ekibi müşteri deneyimine odaklar.
Sağlık izleme ile iş KPI'larını bağlamak için küçük bir iş-etkisi uyarı seti ekleyin, örneğin:
Her uyarıyı beklenen bir eyleme bağlayın: araştır, rollback, sağlayıcı değiştir, destek bilgilendir.
Önceden şiddet seviyeleri ve yönlendirme kuralları tanımlayın:
Her uyarı yanıtlamalı: ne etkileniyor, ne kadar kötü ve bir sonraki adım ne olmalı?
Uygulama sağlık izleme ile iş KPI panosunu karıştırmak riskleri artırır: tek bir ekran hata oranlarını gelir veya müşteri isimleriyle yan yana gösterebilir. İzinler ve gizliliği sonra eklemek ya ürünü aşırı kısıtlar ya da veriyi fazla açığa çıkarır.
Rolleri organizasyon şemasından çok kararlar etrafında tanımlayın. Örnek roller:
Varsayılan olarak en az ayrıcalık verin: kullanıcılar ihtiyaç duyunca daha geniş erişim talep etsin.
PII'yi ayrı bir veri sınıfı olarak sıkı ele alın:
Gözlemlenebilirlik sinyallerini müşteri kayıtlarına bağlamanız gerekiyorsa, bunu sabit, PII içermeyen kimliklerle yapın (tenant_id, account_id) ve eşlemeyi daha sıkı erişimli bir yerde tutun.
Ekipler bir KPI formülü sessizce değiştiğinde güvenini kaybeder. Şunları takip edin:
Bunu bir denetim kaydı olarak sunun ve ana widget'lara iliştirin.
Birden çok ekip veya müşteri uygulamayı kullanacaksa, tenant-aware token'lar, tenant-aware sorgular ve varsayılan olarak sıkı izolasyon gibi çok kiracılı tasarımı baştan düşünün. Analytics entegrasyonu ve olay müdahalesi canlıyken sonradan düzeltmek zordur.
“Uygulama sağlık + KPI” ürününü test etmek, sadece grafiklerin yüklenip yüklenmediğiyle ilgili değildir. İnsanların sayılara güvenip bunlara göre karar alabilmesiyle ilgilidir. Dışa açmadan önce doğruluğu ve hızını gerçekçi koşullarda doğrulayın.
İzleme uygulamanızı birinci sınıf ürün gibi ele alın ve hedefler belirleyin:
Bu testleri “gerçekçi kötü günler” ile de çalıştırın—yüksek kardinaliteli metrikler, büyük zaman aralıkları ve zirve trafik pencereleri.
Bir pano görsel olarak iyi görünürken pipeline sessizce başarısız olabilir. Otomatik kontroller ekleyin ve bunları internal bir görünümde sunun:
Bu kontroller staging'de yüksek sesle başarısız olmalı ki üretimde sorunları keşfetmeyesiniz.
Sıfır, ani sıçramalar, iadeler, çoğaltılmış event'ler ve saat dilimi sınırları gibi köşe durumlarını içeren sentetik veri setleri oluşturun. Ardından (kimlikler anonimleştirilmiş) gerçek prod trafik kalıplarını staging'e replay ederek panoları ve uyarıları doğrulayın.
Her çekirdek KPI için tekrarlanabilir doğruluk rutini tanımlayın:
Bir sayıyı teknik olmayan bir paydaşa bir dakikadan kısa sürede açıklayamıyorsanız, yayınlanmaya hazır değildir.
Birleştirilmiş “sağlık + KPI” uygulaması ancak insanlar güvenip kullanırsa ve güncel tutarsa işe yarar. Yayını bir ürün lansmanı gibi ele alın: küçük başlayın, değeri kanıtlayın ve alışkanlıklar oluşturun.
Herkesin önem verdiği tek bir müşteri yolculuğu seçin (ör. checkout) ve buna en çok katkı veren bir backend servisi seçin. O ince dilim için yayınlayın:
Bu “bir yolculuk + bir servis” yaklaşımı uygulamanın amacını netleştirir ve erken dönemde hangi metriklerin önemli olduğu tartışmalarını yönetilebilir tutar.
Ürün, destek ve mühendislik ile 30–45 dakikalık haftalık bir gözden geçirme planlayın. Pratik tutun:
Kullanılmayan panoları basitleştirmek için bir sinyal olarak değerlendirin. Gürültülü uyarıları hata olarak görün.
Sahipliği atayın (paylaşılsa bile) ve aylık hafif bir kontrol listesi çalıştırın:
İlk dilim stabil hale gelince aynı desenle bir sonraki yolculuğa veya servise genişleyin.
Uygulama fikirleri ve örnekleri görmek isterseniz browse /blog. İnşa mı al mı değerlendirmesi yapıyorsanız, seçenekleri ve kapsamı karşılaştırın browse /pricing.
İlk çalışan versiyonu (pano UI + API katmanı + auth) hızlandırmak isterseniz, Koder.ai özellikle React frontend ile Go + PostgreSQL backend isteyen takımlar için pragmatik bir başlangıç olabilir; ayrıca hazır olduğunuzda kaynak kodunu dışa aktarma seçeneği sunar.
Tek bir iş akışı (genellikle bir pano + drill-down deneyimi) içinde teknik sağlık sinyallerini (gecikme, hatalar, doygunluk) ve iş sonuçlarını (dönüşüm, gelir, churn) aynı zaman ekseninde görmektir.
Amaç korelasyondur: sadece “bir şey bozuldu” demek yerine “checkout hataları arttı ve dönüşüm düştü” gibi durumu görüp düzeltmeleri etkiye göre önceliklendirebilirsiniz.
Bir gecikme sıçramasının önemli olup olmadığını tahmin etmek yerine, onu satın alma/dönüşüm gibi KPI'larla doğrulayarak hemen müşteri etkisini görebilir ve sayfayı, rollback'i veya izlemeyi seçebilirsiniz.
Olay sorularıyla başlayın:
Ardından 5–10 sağlık metriği (erişilebilirlik, gecikme, hata oranı, doygunluk, trafik) ve 5–10 KPI (kaydolmalar, aktivasyon, dönüşüm, gelir, retention) seçin. Anasayfayı minimal tutun.
Gelir veya retention'ı doğrudan etkileyen 3–5 kritik yolculuk seçin (checkout/ödeme, giriş, onboarding, arama, yayınlama).
Her yolculuk için:
Bu, panoları sonuçlara odaklar, altyapı ayrıntılarına değil.
Bir metric sözlüğü “aynı KPI farklı hesap” tartışmalarını önler. Her metrik için belgeleyin:
Sahibi olmayan metrikler, bakımsız ve yanıltıcı hale gelir.
Sistemler tutarlı kimlikleri paylaşamıyorsa hataları sonuçlara bağlayamazsınız.
Standartlaştırın ve her yerde taşıyın:
user_idaccount_id / org_idorder_id / invoice_idAraçlar farklı anahtar kullanıyorsa, erken bir eşleme tablosu oluşturun; geriye dönük birleştirme pahalı ve hataya açık olur.
Pratik bir ayrım:
Araya bir veri API koyun: UI doğrudan depolara bağlanmasın; yetkilendirme, birleştirme ve tutarlı bucket/unit dönüşleri API'de yapılsın.
Kural:
“Tek pencere” her şeyi yeniden yazmak anlamına gelmez.
Önce kullanıcı etkisinin belirtilerine (symptoms) uyarı verin, sonra nedenlere.
İyi semptom uyarıları:
Ayrıca iş-etkisi olan küçük bir uyarı seti ekleyin (dönüşüm düşüşü, ödeme hataları, sipariş/dk düşüşü) ve her uyarıya beklenen bir eylem atayın (araştır, rollback, sağlayıcı değiştir, destek bildir).
Gelir/KPI'ları operasyonel veriyle karıştırmak gizlilik ve güven sorunlarını doğurur.
Uygulayın:
Join yaparken mümkünse PII içermeyen sabit gibi kimlikler kullanın.
account_id