Hizmet bağımlılıkları, gerçek zamanlı sinyaller ve ekipler için net panolar kullanarak olay etkisini hesaplayan bir web uygulamasını nasıl tasarlayıp inşa edeceğinizi öğrenin.
Hesaplamaları veya panoları inşa etmeden önce, organizasyonunuzda “etki”nin gerçekte ne anlama geldiğine karar verin. Bu adımı atlarsanız, bilimsel görünen ama kimseye yardımcı olmayan bir puanla sonuçlanırsınız.
Etki, bir olayın iş için önemli bir şey üzerindeki ölçülebilir sonucudur. Yaygın boyutlar şunlardır:
2–4 ana boyut seçin ve bunları açıkça tanımlayın. Örneğin: “Etki = etkilenen ücretli müşteriler + risk altındaki SLA dakikaları,” değil “Etki = grafiklerde kötü görünen her şey.”
Farklı roller farklı kararlar alır:
“Etki” çıktıları, her kitlenin metrikleri çevirmeden en önemli sorusunu yanıtlayacak şekilde tasarlayın.
Hangi gecikmenin kabul edilebilir olduğuna karar verin. “Gerçek zamanlı” pahalıdır ve genellikle gerekli değildir; yakın-gerçek-zamanlı (ör. 1–5 dakika) karar verme için çoğu zaman yeterlidir.
Bunu bir ürün gereksinimi olarak yazın; çünkü alım, önbellekleme ve UI üzerinde etkisi olur.
MVP'niz doğrudan şu tür eylemleri desteklemelidir:
Bir metrik bir kararı değiştirmiyorsa, muhtemelen “etki” değildir—sadece telemetri.
Ekranları tasarlamadan veya veritabanı seçmeden önce, "etki analizi"nin gerçek bir olay sırasında cevaplaması gerekenleri yazın. Hedef ilk günde kusursuz hassasiyet değil—müdahale edenlerin güveneceği tutarlı, açıklanabilir sonuçlardır.
Etkiyi hesaplamak için almanız veya referans vermeniz gereken verilerle başlayın:
Çoğu ekip ilk günden mükemmel bağımlılık veya müşteri haritalamasına sahip değildir. Uygulamayı yine de kullanışlı kılmak için insanların manuel girmesine izin verilecekleri şeyleri belirleyin:
Bunları ad-hoc notlar yerine açık alanlar olarak tasarlayın ki sonradan sorgulanabilir olsunlar.
İlk sürümünüz güvenilir şekilde şunları üretmelidir:
Etki analizi bir karar aracıdır; bu yüzden kısıtlar önemlidir:
Bu gereksinimleri test edilebilir ifadeler olarak yazın. Doğrulayamıyorsanız, kesinti sırasında güvenemezsiniz.
Veri modeliniz, alım, hesaplama ve UI arasındaki sözleşmedir. Doğru kurarsanız, araç kaynaklarını değiştirebilir, puanlamayı iyileştirebilir ve yine de aynı soruları yanıtlayabilirsiniz: “Ne kırıldı?”, “Kim etkilendi?” ve “Ne kadar süre?”
En azından bunları birinci sınıf kayıtlar olarak modelleyin:
ID'leri kaynaklar arasında tutarlı ve sabit tutun. Zaten bir hizmet kataloğunuz varsa, onu doğruluk kaynağı olarak kullanın ve harici araç tanımlayıcılarını buna eşleyin.
Raporlama ve analiz için olaya birden fazla zaman damgası saklayın:
Ayrıca etki puanlama için hesaplanan zaman pencereleri (ör. 5 dakikalık kovalar) saklayın. Bu, tekrar oynatmayı ve karşılaştırmaları kolaylaştırır.
İki önemli grafiği modelleyin:
Basit bir desen customer_service_usage(customer_id, service_id, weight, last_seen_at) şeklinde olabilir; böylece müşterinin ne kadar dayandığını kullanarak etkiyi sıralayabilirsiniz.
Bağımlılıklar evrilir ve etki hesaplamaları o an olanı yansıtmalıdır. Kenarlara etkinlik tarihleri ekleyin:
dependency(valid_from, valid_to)Aynı şeyi müşteri abonelikleri ve kullanım anlık görüntüleri için de yapın. Tarihsel versiyonlarla geçmiş olayları doğru şekilde yeniden çalıştırabilir ve tutarlı SLA raporlaması üretebilirsiniz.
Etki analiziniz yalnızca besleyen girdiler kadar iyidir. Buradaki hedef basittir: zaten kullandığınız araçlardan sinyalleri çekin, sonra uygulamanızın üzerinde mantık yürütebileceği tutarlı bir olay akışına dönüştürün.
Olay sırasında “bir şey değişti” diyen güvenilir kaynaklarla başlayın:
Her şeyi bir anda almaya çalışmayın. Tespit, yükseltme ve teyit süreçlerini kapsayan kaynakları seçin.
Farklı araçlar farklı entegrasyon modelleri destekler:
Pratik bir yaklaşım: kritik sinyaller için webhooklar ve boşlukları doldurmak için toplu içe aktarma.
Gelen her öğeyi kaynak ne ad verirse versin tek bir “olay” şekline normalleştirin. En azından standart hale getirin:
Dağınık veri bekleyin. Çoğaltmayı engellemek için idempotency anahtarları (source + external_id) kullanın, sıralama dışı olayları occurred_at üzerinden sıralayarak tolere edin ve eksik alanlarda güvenli varsayılanlar uygulayın (aynı zamanda bunları incelenmek üzere işaretleyin).
UI'da küçük bir “eşleşmeyen hizmet” kuyruğu sessiz hataları engeller ve etki sonuçlarını güvenilir kılar.
Bağımlılık haritanız yanlışsa, sinyalleriniz ve puanlamanız mükemmel olsa bile blast radius yanlış olur. Amaç, hem bir olay sırasında hem de sonrasında güvenilebilecek bir bağımlılık grafiği oluşturmaktır.
Kenarları haritalamadan önce düğümleri tanımlayın. Bir olayda referans verebileceğiniz her sistem için bir hizmet kataloğu girdisi oluşturun: API'ler, arka plan işçileri, veri depoları, üçüncü taraf satıcılar ve diğer kritik paylaşılan bileşenler.
Her hizmet en azından şunları içermeli: sahip/ekip, seviye/kritiklik (ör. müşteri-facing vs dahili), SLA/SLO hedefleri ve runbook/on-call dokümanlarına bağlantılar (ör. /runbooks/payments-timeouts).
İki tamamlayıcı kaynağı kullanın:
Bunları ayrı kenar türleri olarak ele alın ki insanlar güveni anlayabilsin: “ekip tarafından beyan edildi” vs “son 7 günde gözlendi”.
Bağımlılıklar yönlü olmalıdır: Checkout → Payments ile Payments → Checkout aynı şey değildir. Yön, akıl yürütmeyi yönetir (“Payments bozulursa hangi upstream'ler başarısız olabilir?”).
Ayrıca sert vs yumuşak bağımlılıkları modelleyin:
Bu ayrım etkiyi abartmayı önler ve müdahale edenlerin önceliklendirmesine yardımcı olur.
Mimari haftalık değişir. Anlık görüntü saklamazsanız iki ay önceki bir olayı doğru şekilde analiz edemezsiniz.
Bağımlılık grafiği versiyonlarını zaman içinde (günlük, deploy başına veya değişiklikte) saklayın. Blast radius hesaplanırken olay zaman damgasını en yakın graf anlık görüntüsüne çözümleyin; böylece “kim etkilendi” o andaki gerçeği yansıtır—bugünkü mimariyi değil.
Sinyalleri (uyarılar, SLO tüketimi, sentetik kontroller, müşteri biletleri) aldıktan sonra uygulama, dağınık girdileri net bir ifadeye dönüştürmelidir: ne kırıldı, ne kadar kötü ve kim etkilendi?
Aşağıdaki desenlerden herhangi biriyle uygulanabilir bir MVP elde edebilirsiniz:
Hangi yaklaşımı seçerseniz seçin, ara değerleri (eşik atlaması, ağırlıklar, seviye) saklayın ki insanlar puanın neden ortaya çıktığını anlayabilsin.
Her şeyi tek bir sayıya erken sıkıştırmaktan kaçının. Önce birkaç boyutu ayrı ayrı takip edin, sonra genel bir şiddet türetin:
Bu, müdahale edenlerin durumu doğru iletişim kurmasını sağlar (örn. “erişilebilir ama yavaş” vs “yanlış sonuçlar”).
Etki sadece hizmet sağlığı değildir—onu hisseden kişilerdir.
Kullanım haritalaması (tenant → hizmet, müşteri planı → özellikler, kullanıcı trafiği → endpoint) kullanın ve etkilenen müşterileri olayla hizalı bir zaman penceresi içinde hesaplayın (başlangıç zamanı, azaltma zamanı ve varsa backfill dönemi).
Varsayımları açıkça belirtin: örneklenmiş loglar, tahmini trafik veya kısmi telemetri gibi.
Operatörlerin geçersiz kılmaya ihtiyacı olacak: yanlış pozitif uyarı, kısmi dağıtım, bilinen bir müşteri alt kümesi.
Şiddet, boyutlar ve etkilenen müşteriler üzerinde manuel düzenlemelere izin verin, ancak şu bilgiler zorunlu olsun:
Bu denetim izi panodaki güveni korur ve olay sonrası incelemeyi hızlandırır.
İyi bir etki panosu üç soruyu hızlıca yanıtlar: Ne etkilendi? Kim etkilendi? Ne kadar eminiz? Kullanıcılar beş farklı sekme açmak zorunda kalırsa, çıktıya güvenmezler veya harekete geçmezler.
Her zaman orada olacak ve gerçek olay iş akışlarına uyan küçük bir görünüm setiyle başlayın:
Açıklaması olmayan etki puanları keyfi görünür. Her puan girdilere ve kurallara geri izlenebilir olmalı:
Ana görünümü karmaşıklaştırmadan bunu yapacak basit bir “Etkiyi Açıklayın” çekmecesi yeterli olabilir.
Etkiyi hizmete, bölgeye, müşteri kademesine ve zaman aralığına göre dilimlemeyi kolaylaştırın. Kullanıcıların herhangi bir grafik noktasına veya satıra tıklayıp değişikliğe neden olan ham kanıtlara (tam monitörler, loglar veya olaylar) inebilmesini sağlayın.
Aktif bir olay sırasında insanlar taşınabilir güncellemelere ihtiyaç duyar. Şunları ekleyin:
Zaten bir status page'iniz varsa, iletişim ekiplerinin hızlı çapraz referans yapabilmesi için /status gibi göreli bir rota ile bağlantı verin.
Etki analizi ancak insanlara güven verirse kullanışlı olur—bu da kimlerin neyi görebileceğini kontrol etmeyi ve değişikliklerin açık kaydını tutmayı gerektirir.
Olayların gerçek hayatındaki akışa uyan küçük bir rol seti tanımlayın:
İzinleri iş unvanlarına değil eylemlere göre hizalayın. Örneğin, “müşteri etki raporunu dışa aktarabilir” gibi bir izin komutanlara ve sınırlı bir yönetici grubuna verilebilir.
Etki analizi genellikle müşteri kimliklerini, sözleşme kademelerini ve bazen iletişim detaylarını içerir. Varsayılan olarak en az ayrıcalık uygulayın:
İncelemeleri destekleyecek yeterli bağlamla ana eylemleri kaydedin:
Denetim günlüklerini eklemeli olarak saklayın, zaman damgası ve aktör kimliği ile. Olay başına aranabilir hale getirerek olay sonrası incelemelerde kullanışlı olmalarını sağlayın.
Şu anda neleri destekleyebileceğinizi belgeleyin—saklama süresi, erişim kontrolleri, şifreleme ve denetim kapsamı—ve yol haritasında nelerin olduğu. Uygulamada kısa bir “Güvenlik & Denetim” sayfası (örn. /security) beklentileri belirler ve kritik olaylar sırasında rastgele soruları azaltır.
Etki analizi yalnızca bir olay sırasında bir sonraki eylemi yönlendiriyorsa önemlidir. Uygulamanız olay kanalının “yol arkadaşı” gibi davranmalı: gelen sinyalleri net güncellemelere çevirir ve etki anlamlı şekilde değiştiğinde insanları dürter.
Yanıtlayanların zaten çalıştığı yere (çoğunlukla Slack, Microsoft Teams veya adanmış bir olay aracı) entegrasyonla başlayın. Amaç kanalı değiştirmek değil—bağlam odaklı güncellemeler göndermek ve ortak bir kayıt tutmaktır.
Pratik bir desen olay kanalını hem giriş hem çıkış olarak kullanmaktır:
Hızlı prototipleme yapıyorsanız, önce uçtan uca iş akışını kurmayı (olay görünümü → özetle → bildir) düşünün; puanlamayı mükemmelleştirmeye sonra odaklanın. Koder.ai gibi platformlar burada kullanışlı olabilir: React panosu, Go/PostgreSQL arka ucu ile sohbet odaklı yineleme imkanı sağlar ve ekip UX gerçeği yansıdığında kaynak kodunu dışa aktarabilirsiniz.
Bildirim spam'inden kaçınmak için yalnızca etki belirli eşikleri aştığında bildirim tetikleyin. Yaygın tetikleyiciler:
Bir eşik aşıldığında, neden (ne değişti), kimin harekete geçmesi gerektiği ve ne yapılacağı açıklayan bir mesaj gönderin.
Her bildirim “sonraki adım” bağlantıları içermeli ki müdahale edenler hızla ilerleyebilsin:
Bu bağlantıları göreli ve sabit tutun ki ortamlar arasında çalışsınlar.
Aynı veriden iki özet formatı oluşturun:
Zamanlanmış özetleri destekleyin (örn. her 15–30 dakika) ve harici gönderimden önce onay adımı olan “güncelleme oluştur” eylemlerini sağlayın.
Etki analizi ancak insanlar hem olay sırasında hem olay sonrasında ona güvendiklerinde kullanışlıdır. Doğrulama iki şeyi kanıtlamalı: (1) sistem tutarlı, açıklanabilir sonuçlar üretiyor ve (2) bu sonuçlar organizasyonun sonradan vardığı bulgularla uyuşuyor.
İki en hataya açık alanı kapsayan otomatik testlerle başlayın: puanlama mantığı ve veri alımı.
Test verilerini okunabilir tutun: biri bir kuralı değiştirdiğinde, neden puanın değiştiğini anlamalı.
Oynatma modu güven inşa etmenin hızlı yoludur. Tarihsel olayları uygulamadan geçirip sistemin “o anda” ne göstereceğini ile müdahale edenlerin sonradan vardığı sonuçları karşılaştırın.
Pratik ipuçları:
Gerçek olaylar nadiren temiz kesintilere benzer. Doğrulama paketiniz şu senaryoları içermelidir:
Her durumda sadece puanı değil, puanı getiren açıklamayı da doğrulayın: hangi sinyaller ve hangi bağımlılıklar/müşteriler sonucu tetikledi.
Doğruluğu operasyonel terimlerle tanımlayın ve izleyin.
Hesaplanan etkiyi olay sonrası inceleme sonuçlarıyla karşılaştırın: etkilenen hizmetler, süre, müşteri sayısı, SLA ihlali ve şiddet. Tutarsızlıkları bir doğrulama sorunu olarak kategorize edin (eksik veri, yanlış bağımlılık, hatalı eşik, gecikmiş sinyal).
Zamanla hedef mükemmellik değil—olaylarda daha az sürpriz ve daha hızlı uzlaşıdır.
Olay etki analizi için bir MVP göndermek çoğunlukla güvenilirlik ve geri bildirim döngüleriyle ilgilidir. İlk dağıtım tercihi değiştirme hızını optimize etmeli, teorik gelecekteki ölçeği değil.
Eğer güçlü bir platform ekibiniz ve net servis sınırlarınız yoksa modüler monolit ile başlayın. Tek dağıtılabilir birim migration, debug ve uçtan uca testleri basitleştirir.
Servisleri yalnızca gerçek bir acı noktası oluştuğunda ayırın:
Pratik orta yol: bir uygulama + arka plan worker'lar (kuyruklar) + gerekirse ayrı bir ingestion edge.
Hızlı ilerlemek ama büyük bir özel platforma erken bağlanmamak isterseniz, Koder.ai MVP hızlandırmada yardımcı olabilir: sohbet tabanlı “vibe-coding” ile React UI, Go API ve PostgreSQL veri modeli oluşturma, kural ve iş akışı yinelemeleri sırasında snapshot/rollback imkanı sunar.
Temel varlıklar (olaylar, hizmetler, müşteriler, sahiplik ve hesaplanmış etki anlık görüntüleri) için ilişkisel depolama (Postgres/MySQL) kullanın. Sorgulanması, denetlenmesi ve evrilmesi kolaydır.
Yüksek hacimli sinyaller (metrikler, log türetilmiş olaylar) için ham sinyal saklama ve rollup'lar SQL'de pahalı hale geldiğinde bir zaman serisi veya sütunlu mağaza ekleyin.
Bağımlılık sorguları darboğaz olduğunda veya model çok dinamik hale geldiğinde graf veritabanı düşünün. Birçok ekip, bitişik tablolar + önbellekleme ile uzun süre idare edebilir.
Etki analiz uygulamanız olay zincirinin bir parçası haline gelir; onu prod gibi instrument edin:
UI'da bir “sağlık + tazelik” görünümü sunun ki müdahale edenler sayılara güvensin veya sorgulasın.
MVP kapsamını sıkı tutun: birkaç aracı alım, net bir etki puanı ve “kim etkilendi, ne kadar” sorusunu yanıtlayan bir pano. Sonra yineleyin:
Modeli bir ürün gibi yönetin: sürümleyin, güvenli şekilde migrate edin ve değişiklikleri olay sonrası incelemeler için belgelendirin.
Etkı, bir olayın iş açısından önemli sonuçlarının ölçülebilir etkisidir.
Pratik bir tanım 2–4 ana boyut belirtir (ör. etkilenen ücretli müşteriler + risk altındaki SLA dakikaları) ve “grafiklerde kötü görünen her şey”i açıkça hariç tutar. Bu, çıktıyı yalnızca telemetriye değil karar almaya bağlar.
İlk 10 dakikada ekiplerin alacağı aksiyonlarla eşlenen boyutları seçin.
MVP için yaygın, uygun boyutlar:
Açıklığı korumak için 2–4 ile sınırlayın.
Her rolün ana sorusunu metric'leri çevirmeye gerek kalmadan yanıtlayacak çıktılar tasarlayın:
“Gerçek zamanlı” pahalıdır; birçok ekip için yakın-gerçek-zamanlı (1–5 dakika) yeterlidir.
Gecikme hedefini bir gereksinim olarak yazın çünkü bu şunları etkiler:
Ayrıca UI'da beklentiyi gösterin (ör. “veriler 2 dakika önceye kadar taze”).
Müdahale ekiplerinin vermesi gereken kararları listeleyin ve her çıktı bir kararı desteklesin:
Bir metrik bir kararı değiştirmiyorsa, onu telemetri olarak bırakın.
Genel olarak gerekli girdiler şunlardır:
Veri eksik veya sinyaller yanlış olduğunda uygulamanın hâlâ işe yaraması için açık, sorgulanabilir manuel alanlara izin verin:
Değişikliklerde kim/ne zaman/neden gerekli olsun ki güven zaman içinde bozulmasın.
Güvenilir bir MVP şunları üretmelidir:
Opsiyonel: güven aralıklarıyla birlikte maliyet tahminleri (SLA kredileri, gelir riski).
Tüm gelen öğeleri tek bir olay şemasına normalleştirerek hesaplamaların tutarlı kalmasını sağlayın.
En azından şunları standartlaştırın:
occurred_at, , Basit ve açıklanabilir bir yaklaşımla başlayın:
Ara değerleri (eşik atlamaları, ağırlıklar, seviye, güven) saklayın ki insanlar puanın değiştiğini görebilsin. Puanlamayı tek sayıya indirgemeden önce boyutları takip edin (erişilebilirlik/gecikme/hatlar/veri doğruluğu/güvenlik).
Eğer bir metrik hiçbirinin kullanmayacağı bir bilgi vermiyorsa, muhtemelen “etki” değildir.
Bu set “ne kırıldı”, “kim etkilendi” ve “ne kadar süre” sorularına cevap vermek için yeterlidir.
detected_atresolved_atservice_id (araç etiketlerinden/isimlerinden eşlenen)source + orijinal ham payload (denetim/aydınlatma için)Gürültüyle başa çıkmak için idempotency anahtarları (source + external_id) ve occurred_at tabanlı sıra toleransı kullanın.