Entegrasyon sağlık paneli: bozuk bağlantıları erken tespit edin

Bozuk entegrasyonların neden kullanıcıya yansıdığı sorunlar\n\n“Bozuk bağlantı” nadiren dramatiktir. Genellikle sessizce bir şeylerin eksik görünmesiyle ortaya çıkar: yeni bir sipariş nakliye aracınıza hiç ulaşmaz, bir müşteri kaydı CRM'de güncel kalmaz veya bir ödeme durumu "beklemede"den "ödendi"ye dönmez. Hiçbir şey çökmese de süreç sapmaya başlar.\n\nKullanıcılar genellikle ilk fark eden olurlar çünkü birçok hata sessizdir. Bir API çağrısı başarısız olabilir ve arka planda yeniden denenirken uygulama eski verileri göstermeye devam eder. Bir senkron bazılarında başarılı olur bazılarında başarısız olur; sorun ancak birisi belirli bir öğeyi arayana kadar gizlenir. Hatta “yavaş başarısızlıklar” bile gerçek hasar verir: entegrasyon çalışmaya devam eder ama saatler geride kalır, mesajlar gecikir ve destek bildirimleri birikir.\n\nSıkıntı en yakın iş yapan kişilerin omuzlarına düşer:\n\n- Araçları ve izinleri yöneten ve "sistem" yanlış olduğunda suçlanan yöneticiler\n- Sadece semptomları gören destek ekipleri\n- Güvenilir el değiştirmelere (siparişler, envanter, teslimat, faturalar) ihtiyaç duyan operasyon ekipleri\n\n- Birikme kriz olunca uyandırılan on-call sahipleri\n\nBir entegrasyon sağlık panelinin bir görevi vardır: kullanıcılar fark etmeden önce bozuk entegrasyonları tespit etmek ve düzeltmeleri kahramanlıktan çıkarıp tekrarlanabilir hale getirmek. Yöneticiler neyin neden başarısız olduğunu, en son ne zaman çalıştığını ve sonraki adımı (yeniden dene, yeniden bağla, token döndür, ya da yükselt) görmelidir.\n\n## Entegrasyon sağlık paneli nedir (ve ne değildir)\n\nBir entegrasyon sağlık paneli, bir ekibin hızlıca şu soruya cevap bulacağı ortak bir yerdir: "Bağlantılarımız şu an düzgün çalışıyor mu?" Üç araca ve loglarda define avına ihtiyaç duyuyorsanız, panonuz yoktur; dedektiflik yapıyorsunuzdur.\n\nAna ekran net bir liste gibi okumalı. Sorunu erken fark etmek için çoğu takımın sadece birkaç alana ihtiyacı vardır:\n\n- Durum (OK, Degraded, Failing, Paused, Unknown)\n- Son başarılı senkronizasyon zamanı\n- Hata oranı (son zaman penceresi içinde)\n- Birikim (senkronu bekleyen öğeler)\n- Sahip veya on-call iletişim bilgisi\n\n"Sağlıklı" hisse değil yazılı kurallara dayanmalıdır. Örneğin: "OK = son 30 dakika içinde en az bir başarılı senkron ve hata oranı %2'nin altında." Kurallar açık olduğunda destek ve yöneticiler tartışmayı bırakıp düzeltmeye başlar.\n\nFarklı roller farklı vurgulara ihtiyaç duyar. Destek genelde etkiyle (hangi müşteriler ya da işlemler etkilendi, ne söylenecek) ilgilenir. Yöneticiler sonraki adımlarla (yeniden dene, yeniden kimlik doğrulama, anahtarı döndür, izinleri kontrol et, rate limitleri doğrula) ilgilenir. İdeal olarak her iki görünüm de aynı gerçeği gösterir; rol tabanlı erişim kimin neyi değiştirebileceğini kontrol eder.\n\nNe değildir: bir log duvarı. Loglar ham malzemedir. Bir panel sonraki eyleme işaret etmelidir. Bir bağlantı token'ın süresi dolduğu için bozulduysa, panel bunu söylemeli ve düzeltmeye yol göstermelidir; sadece bir stack trace dökmemelidir.\n\n## Her entegrasyonda takip edilmesi gereken temel metrikler\n\nBir panel, triage'ı saniyeler içinde mümkün kılmıyorsa işe yaramaz: bu bağlantı şu an çalışıyor mu ve çalışmıyorsa kimin sorumluluğunda?\n\nHer entegrasyon için küçük bir alan setiyle başlayın:\n\n- Entegrasyon adı + sahip (örneğin, “Stripe payouts” + bir ekip)\n- Olay durumu (open, acknowledged, resolved ve kim onayladı)\n- Son başarılı çalışma zamanı ve son deneme zamanı\n- Başarı oranı ve hata oranı (yüksek hacim için son saat, gece işleri için son gün gibi uygun bir pencere)\n- Hacim (istekler, eventler, kayıtlar) — "yeşil ama hiçbir şey hareket etmiyor" durumlarını yakalamak için\n\nBiriken iş sinyallerini atlamayın. Birçok arıza yavaşlamalar şeklinde sessizce birikir. Kuyruk boyutu/birikim sayısı ve en eski bekleyen öğenin yaşıni takip edin. "500 bekleyen" bir zirveden sonra normal olabilir, ama "en eski bekleyen: 9 saat" ise kullanıcılar bekliyor demektir.\n\nYaygın bir tuzak şöyle görünür: CRM sync'inizde bugün %98 başarı oranı gösteriyor ama hacim 10.000 kayıttan 200'e düştü ve son başarılı çalışma 6 saat önce. Hata oranı "iyi" görünse bile bu kombinasyon gerçek bir sorundur.\n\n## Basit kurallarla "sağlıklı"yi nasıl tanımlarsınız\n\nPanel pratik bir soruyu yanıtlamalı: şu an birinin hemen müdahale etmesi gerekiyor mu?\n\nKüçük bir durum seti çoğu vakayı kapar:\n\n- OK: normal sınırlar içinde\n- Degraded: çalışıyor, ama olduğundan daha yavaş veya daha gürültülü\n- Failing: tekrarlayan hatalar ve olası kullanıcı etkisi\n- Paused: kasıtlı olarak durdurulmuş (bakım, planlı değişiklik)\n- Unknown: yakın zamanda sinyal yok (yeni entegrasyon, eksik kimlik bilgileri, ajan çevrimdışı)\n\nSon başarıdan geçen süre genelde en güçlü ilk kuraldır, ama eşikler entegrasyona uymalıdır. Bir ödeme webhook'u dakikalar içinde bozulabilirken, bir gece CRM sync'i saatlerce sorun olmayabilir.\n\nHer entegrasyon için iki zamanlayıcı tanımlayın: ne zaman Degraded olur ve ne zaman Failing olur. Örnek: "OK eğer son başarı 30 dakikadan önceyse, Degraded 2 saate kadar, Failing 2 saatten sonra." Kuralı entegrasyon adının yanında gösterin ki destek tahmin etmek zorunda kalmasın.\n\nHata oranları için toplamların yanı sıra sıçrama kuralları ekleyin. 1.000'de bir başarısız çağrı normal olabilir. Art arda on hata normal değildir. "5 ardışık başarısız" veya "15 dakika boyunca %20 üzeri hata oranı" gibi sürdürülen başarısızlık tetiklerini takip edin.\n\nBirikim büyümesi ve işleme gecikmesi de erken uyarı işaretleridir. Bir bağlantı "çalışır" görünebilir ama geride kalabilir. Yararlı Degraded kuralları: "10 dakika boyunca backlog büyüyor" veya "işleme gecikmesi 30 dakikayı aşıyor."\n\nPlanlı kesintiyi sürprizlerden ayırın. Yöneticiler bir entegrasyonu durdurduğunda durumu Paused yapın ve uyarıları susturun. Bu tek anahtar gereksiz gürültünün önüne geçer.\n\n## Gerekli veriyi logların altında boğulmadan toplamak\n\nKullanışlı bir entegrasyon sağlık paneli, "daha fazla log"tan çok hızlı sorgulanabilen küçük bir gerçek setine bağlıdır. Çoğu ekip için bu, her senkron denemesi için bir kayıt yakalamak ve güncel kalan birkaç özet alan demektir.\n\nHer çalışmayı bir zaman damgası ve net bir sonuçla bir deneme olarak değerlendirin. Uzun bir metin yerine kısa bir hata kategorisi saklayın. Auth, rate limit, validation, network ve server gibi kategoriler genelde paneli işe yarar kılmaya yeter.\n\nHemen fayda sağlayan veri:\n\n- Deneme zamanı, entegrasyon adı ve ortam (prod vs test)\n- Sonuç (success/fail) artı hata kategorisi ve kısa mesaj\n- Korrelasyon ID'si (destek birden fazla sistemde arayabilsin diye)\n- Süre ve sayılar (işlenen öğe sayısı, başarısız olanlar)\n- Enstantane sorgular için entegrasyonda saklanan last_success_at değeri\n\nBu last_success_at alanı önemlidir. "Bu en son ne zaman çalıştı?" sorusuna milyonlarca satır taramadan cevap verebilmelisiniz. Her başarılı çalışmada bunu güncelleyin. Hızlı triage için ayrıca last_attempt_at ve last_failure_at tutun.\n\nAşırı yükten kaçınmak için ham logları ayrı tutun (veya sadece hatada saklayın) ve panelin günlük hata toplamları, son N deneme ve entegrasyon başına en son durum gibi özetleri okumasına izin verin.\n\nGüvenli loglama yapın. Erişim tokenlarını, gizli bilgileri veya kişisel veri içeren tam yükleri saklamayın. Hareket etmek için yeterli bağlamı tutun (endpoint adı, dış sistem, hatalı alan, kayıt ID) ve hassas olanları maskeleyin veya hash'leyin.\n\n## Adım adım: ilk sağlık panelinizi nasıl inşa edersiniz\n\nİşe veriden değil iş tarafından başlayın. Amaç yöneticilere ve desteğe "Şu an bir şey kırık mı ve bir sonraki adım ne?" sorusunun net cevabını vermektir.\n\n### Hızla yayına alabileceğiniz ilk sürüm\n\nKısa bir envanterle başlayın. Ürününüzün bağımlı olduğu her entegrasyonu listeleyin, sonra her birini kritik (para veya temel iş akışını bloke eden) veya iyi-olsa-da-yaşanır (rahatsız edici ama katlanılabilir) olarak etiketleyin. Her entegrasyona bir sahip atayın, paylaşılan bir destek kuyruğu olsa bile.\n\nSırayla şunları yapın:\n\n1. 3–5 sinyal seçin. Örneğin: son başarılı senkron zamanı, hata oranı, ortalama çalışma süresi, backlog sayısı ve deneme sayısı.\n2. Başlangıç eşiklerini belirleyin. Açık şekilde açıklanabilecek kurallarla başlayın (örneğin: "kritik entegrasyonlar saatte en az bir kez başarılı olmalı"). Sonra ayarlayın.\n3. Her denemeyi loglayın, sadece hataları değil. Zaman damgası, durum, hata kodu/mesajı ve hedef sistemi saklayın. Entegrasyon başına bir özet (mevcut durum, son başarı zamanı, son hata) tutun.\n4. Filtrelerle dashboard görünümünü oluşturun. Duruma ve etkiye göre sıralanabilir olsun. Sistem, sahip ve ortam gibi filtreler ekleyin. Mümkünse "ne değişti" ipucu verin (son hata, son deploy zamanı, son kimlik bilgisi güncellemesi).\n5. Onaylama içeren uyarılar ekleyin. Doğru ekibi haberdar edin ve birinin olayı onaylamasına izin verin ki çift iş yapılmasın.\n\nCanlıya aldıktan sonra gerçek olayları haftalık gözden geçirip eşikleri ayarlayın; böylece erken yakalayıp sürekli gürültü yaratmazsınız.\n\n## Yöneticiler ve destek için uyarıları işe yarar kılın\n\nBir uyarı, neyin bozulduğunu ve ne yapılabileceğini söylemiyorsa fayda sağlamaz. Panel "ne oldu" ve "sonraki adım"ı aynı ekranda gösterin.\n\nUyarıları kısa bir olay notu gibi yazın: entegrasyon adı, son başarılı senkron zamanı, ne hatalı (auth, rate limit, validation, timeout) ve kaç öğe etkilendi. Tutarlılık gösterişten daha önemlidir.\n\nDetay görünümünde sonraki adımı belirgin yapın. Destek taleplerini azaltmanın en hızlı yolu, yaygın düzeltmelere karşı güvenli, geri alınabilir eylemler sunmaktır:\n\n- Bağlantıyı yeniden kimlik doğrulama (token süresi dolmuş veya iptal edilmiş)\n- Başarısız öğeleri yeniden deneme (sadece başarısız olanlar)\n- Senkronizasyonu durdurma (incelerken daha fazla zarar gelmesin diye)\n- Checkpoint'ten yeniden senkron (kısmi bir kesinti sonrası durumu yeniden kurmak için)\n- Kısa bir runbook açma (adımlar, sahipler, beklenen sonuç)\n\nRunbook'ları kısa tutun. Her hata kategorisi için en fazla 2–5 adım yazın, sade dille: "Kimlik bilgileri değişti mi kontrol et", "Son batch'i yeniden dene", "Birikimin azaldığını onayla."\n\nDenetim kaydı tekrar eden olayları engeller. Kim "Retry"ye tıkladı, kim entegrasyonu durdurdu, hangi parametreler kullanıldı ve sonuç ne oldu; hepsini loglayın. Bu geçmiş destek için ne olduğunu açıklamada yardımcı olur ve yöneticilerin aynı adımı tekrar etmesini önler.\n\nZaman kaybını önlemek için net yükseltme kuralları ekleyin. Destek genelde auth yenilemelerini ve ilk yeniden denemeyi yapabilir. Yeniden kimlik doğrulama sonrası hatalar devam edince, hatalar birçok tenant'ta patlayınca veya veriler yanlış değiştiriliyorsa mühendisliğe yükseltin.\n\n## Panoları işe yaramaz kılan yaygın hatalar\n\nBir panel, veri hareketi durduğunda her şeyi "çalışıyor" diye gösterdiğinde başarısız olur. Yeşil bir uptime ışığı, son başarılı senkron dünse ve müşteriler güncelleme kaçırıyorsa anlamsızdır.\n\nDiğer bir tuzak, her bağlayıcı için tek bir genel eşik kullanmaktır. Bir ödeme ağ geçidi, bir e-posta sağlayıcısı ve bir CRM farklı davranır. Hepsini aynı tutarsanız normal dalgalanmalar için gürültülü uyarılar alırsınız, önemli ama sessiz arızaları kaçırırsınız.\n\n### Dikkat edilecek hata kalıpları\n\n- Sadece erişilebilirliği takip edip çıktıları (kayıtlar senkronlandı mı, işler tamamlandı mı, onaylar alındı mı) görmezden gelmek\n- Tüm hataları aynı kovada toplamak yerine auth, rate limit, validation ve uzak kesintileri ayırmamak\n- Sahibiz olmayan uyarılar göndermek\n- Çok agresif yeniden deneme yapıp rate limit tetikleyen yeniden deneme fırtınaları yaratmak\n- Mühendislik-eğe sinyalleri (stack trace'ler, ham loglar) gösterip sade dilde anlam vermemek\n\nPratik bir çözüm kategorilendirme ve "muhtemel bir sonraki adım" eşleştirmesidir. Örneğin: "401 Unauthorized" süresi dolmuş kimlik bilgilerine işaret etmeli. "429 Too Many Requests" geri çekilme ve kota kontrolünü önermeli.\n\n### Mühendis olmayanlar için okunur hale getirin\n\nDestek her kırmızı durumu yorumlamak için bir mühendise ihtiyaç duyarsa panel göz ardı edilir. "Kimlik bilgileri süresi doldu", "Uzak servis kapalı" veya "Veri reddedildi" gibi kısa etiketler kullanın ve her birinin yanında tek eylem gösterin: yeniden bağla, yeniden denemeleri durdur veya son başarısız kaydı incele.\n\n## Hızlı kontroller: günlük 5 dakikalık entegrasyon sağlık rutini\n\nGünlük kontroller tutarlılık gerektirir. Bir sahip seçin (rotasyonlu olabilir) ve sabit bir zaman belirleyin. Para, sipariş veya destek akışını bloke edebilecek bağlantıları gözden geçirin.\n\n### 5 dakikalık tarama\n\nDünküyle ne değiştiğine bakın, mükemmellik değil:\n\n- Son başarılı senkron zamanı: her kritik entegrasyonun yakın zamanda bir başarısı olmalı. Herhangi bir eski durum önceliklidir, hata düşük görünse bile.\n- Hata oranı trendi: son saati son günle karşılaştırın. Son saatteki küçük bir sıçrama genelde sonra daha büyük olur.\n- Birikim büyümesi: kuyruk boyutunu ve en eski bekleyen öğenin yaşını kontrol edin.\n- Auth durumu: token süresi, iptal edilmiş izinler veya "invalid grant" hatalarına dikkat edin.\n- Son değişiklikler: ayar değişiklikleri, alan eşlemeleri, upstream API değişiklikleri veya son deploy not edin.\n\nSonra neyi şimdi, neyi sonra yapacağınıza karar verin. Bir sync eskiyse ve birikim büyüyorsa acil olarak ele alın.\n\n### Hızlı iyileştirme triage'i\n\nDestek ve yöneticilerin aynı şekilde tepki vermesi için bir oyun kitabı kullanın:\n\n- En küçük şeyi önce yeniden başlatın: yeniden kimlik doğrulama, bir başarısız öğeyi yeniden deneme ya da tek bir işi yeniden çalıştırma.\n- Etkileşim alanını sınırlayın: mümkünse sadece etkilenen akışı durdurun.\n- Bağlam yakalayın: en üst hata mesajını, ilk başarısız zaman damgasını ve bir örnek kaydı kaydedin.\n- Kurtarmayı doğrulayın: taze bir başarı bekleyin ve birikimin azaldığını doğrulayın.\n\nKısa bir notla bitirin: ne değişti, işe yaradı mı ve yarın neye bakılacak.\n\n## Örnek senaryo: müşteriler şikayet etmeden bozuk bir senkronu yakalamak\n\nYaygın bir arıza basittir: bir API token'ı gece boyunca süresi dolar ve "sessiz" bir entegrasyon veri hareketini durdurur. CRM yeni abonelikler oluşturuyor ve bir faturalama sistemi bu kayıtları müşteriden tahsil etmek için bekliyorsa, saat 02:10'da CRM'den faturalamaya giden sync token geçersiz olduğu için başarısız olmaya başlar.\n\nSaat 09:00'da henüz kimse şikayet etmemiş olabilir, ama entegrasyon sağlık paneli çoktan sorun gösterir. Son başarılı senkron zamanı 02:09'da takılıdır. Hata oranı neredeyse %100'dür ve hata kategorisi açıkça belirtilmiştir (örneğin, "Authentication/401"). Ayrıca etkiyi gösterir: son başarıdan bu yana 47 kayıt kuyruğa girmiş veya başarısız olmuştur.\n\nDestek tekrar edilebilir bir iş akışını takip edebilir:\n\n- Olayı onayla ve son başarının ne zaman olduğunu not et\n- Bağlantıyı yeniden kimlik doğrula (token'ı yenile veya değiştir)\n- Başarısız öğeleri yeniden dene (sadece başarısız olanları, tam resync değil)\n- Son başarı zamanının güncellenmesini ve hata oranının düşmesini izleyerek kurtarmayı doğrula\n- Faturalamadaki birkaç kaydı kontrol ederek doğru şekilde işlendiğinden emin ol\n\nDüzeltildikten sonra takip yapın. Uyarı kuralını sıkılaştırın (örneğin, iş saatlerinde 30 dakikadan fazla başarılı senkron yoksa uyar). Eğer sağlayıcı expiry timestamp veriyorsa token-bitiş uyarısı ekleyin.\n\nKullanıcı mesajı kısa ve spesifik olmalı: senkron ne zaman durdu, ne zaman geri geldi ve hangi veriler etkilendi. Örneğin: "02:10 ile 09:20 arasında oluşturulan yeni aboneliklerin faturalamada gecikmesi oldu; veri kaybı olmadı ve tüm bekleyen öğeler yeniden denendiktan sonra işlendi."\n\n## Sonraki adımlar: kademeli yayıp bakımını kolay tutun\n\nİyi bir entegrasyon sağlık paneli asla "bitmiş" sayılmaz. Bunu her kırılan şeye dayanarak küçük adımlarla geliştireceğiniz bir güvenlik sistemi gibi görün.\n\nDar başlayın. Arızalanması en çok zarar verecek 1–2 entegrasyonu seçin (ödeme, CRM sync, destek gelen kutusu) ve onları doğru hale getirin, sonra deseni tekrarlayın.\n\nÖncelikle bir sonucu iyileştirmeye odaklanın ve haftalık ölçün. Birçok ekip için en iyi ilk hedef tespit süresini kısaltmaktır; çünkü daha hızlı tespit her şeyi kolaylaştırır.\n\nPratik bir açılım planı:\n\n- 1–2 kritik entegrasyon ve sadece temel metriklerle (son başarı zamanı, hata oranı, kuyruk boyutu) başlatın\n- "10 dakika içinde arızayı tespit et" gibi bir hedef koyun\n- Entegrasyon başına sahip atayın (birincil ve yedek) ki uyarılar sürüklenmesin\n- İki hafta stabil sinyal gördükten sonra genişletin\n- Her hafta bir gürültülü uyarıyı kaldırarak uyarıları güvenilir hale getirin\n\nBakımı hafif tutmak için en yaygın hatalar için kısa runbook'lar yazın. En çok beş hata kategorinize odaklanın (auth expired, rate limit, hatalı payload, upstream outage, izin değişikliği). Her runbook: neye benzediğini, ilk kontrolü ve en güvenli düzeltmeyi yanıtlamalı.\n\nAğır kodlama olmadan böyle bir yönetici paneli inşa etmek isterseniz, AppMaster (appmaster.io) pratik bir seçenektir: sağlık metriklerini PostgreSQL'de modelleyebilir, web yönetici UI'si kurabilir ve görsel iş mantığı ile düzeltme akışlarını otomatikleştirebilirsiniz.\n\nAmaç sıkıcı güvenilirliktir. Panel genişletmesi ve güvenilirliği kolay olduğunda insanlar gerçekten kullanır.