Editörden

Bugünün kapağı, mühendislikte az konuşulan ama herkesin yaşadığı bir problemi ele alıyor: alarm yorgunluğu. Her bildirimi acil sayarsan boğulursun, saymazsan önemli olanı kaçırırsın. Çözüm şaşırtıcı derecede basit ve her sisteme uygulanabilir.

Günün Kapağı
AWS Architecture Blog 16 Temmuz 202612 dk okuma orta

Alarm yorgunluğunu çözmek: önce filtrele, sonra önceliklendir

Prioritize your AWS Health alerts using AWS User Notifications · Naga Bhargav

AWS Health her servis, her hesap ve her bölge için olay üretiyor: devam eden sorunlar, planlı değişiklikler, hesap bildirimleri ve kullanımdan kaldırma uyarıları — hepsi tek bir ayrışmamış akışta. Bir operasyon ekibi için bu tanıdık bir problem yaratıyor.

Yazının problem tanımı çok net: ya her bildirimi acil sayarsın ve istenmeyen bir triyaj gürültüsüyle boğulursun, ya da onları görmezden gelmeye başlarsın ve önemli olanı kaçırma riskini alırsın. Her iki yol da daha yavaş tepki süresine ve istenmeyen eskalasyonlara çıkıyor.

Sorunun kökeni önem derecelerinin farklı olması değil, hepsinin aynı kanaldan gelmesi. Bir operasyonel arıza, bir planlı bakım penceresi ve gelen kutusunda kaybolmuş bir kullanımdan kaldırma uyarısı çok farklı sonuçlar doğurur — ama aynı görünürler.

Çözümün tasarım ilkesi bir cümlede özetlenmiş: önce filtrele, sonra önceliğe göre ayır. İlk katman gürültüyü eliyor — olay kuralları yalnızca kurumun bağımlı olduğu servisler için eşleşiyor, geri kalan her şey gelen kutusuna ulaşmadan susturuluyor. İkinci katman kalanları aciliyete göre ayrı yapılandırmalara bölüyor.

Öne çıkanlar

  • Alarm yorgunluğu bir kişilik zaafı değil, bir tasarım kusurudur — çözümü de tasarımdadır.
  • İki katmanın sırası önemli: filtrelemeden önceliklendirmeye geçersen, gürültüyü de sınıflandırmakla uğraşırsın.
  • "Sessize alma" bilinçli bir karar olarak tasarlanmış; kazara görmezden gelmekle aynı şey değil.
  • Farklı öncelikler farklı teslim kanallarına gidiyor — acil olan e-postaya değil çağrıya düşmeli.

Neden önemli?

Bir alarm sisteminin başarısı, ürettiği alarm sayısıyla değil, alarma verilen tepki oranıyla ölçülür. Kimsenin bakmadığı bir gösterge paneli ya da herkesin sustuğu bir kanal, hiç olmamasından daha kötüdür: koruma yanılsaması yaratır. Bu yazının verdiği iki katmanlı desen, her izleme sisteminde uygulanabilir.

Sende karşılığı

Bu prensibi kendi projelerinde bugün uygulayabilirsin. Bir alarm kurarken şu soruyu sor: bu tetiklendiğinde gece 3'te kalkar mıyım? Cevap hayırsa bu bir alarm değil, bir metriktir — panele koy, bildirime bağlama. KlioAI'da hata izleme kurduysan (Sentry vb.), muhtemelen zaten gürültüden bunalmışsındır; çözüm daha az hata yakalamak değil, hataları sınıflandırmak: kullanıcıyı engelleyenler ayrı kanala, geri kalanı haftalık özete. Aynı disiplin CI/CD için de geçerli — sürekli kırmızı yanan bir test paketi, hiç test olmamasıyla aynı bilgiyi taşır.

Sözlük

alert fatigue alarm yorgunluğu
Çok fazla bildirim yüzünden ekiplerin alarmlara duyarsızlaşması; kritik uyarıların kaçırılmasına yol açar.
triage triyaj
Gelen olayları aciliyet ve etkiye göre sınıflandırıp önceliklendirme.
escalation eskalasyon
Çözülemeyen bir olayın daha üst yetki ya da uzmanlığa aktarılması.
Orijinali oku

Kısa Kısa

OpenAI Research 16 Temmuz 20264 dk okuma başlangıç

Tek oturumda bitmeyen süreçler: Cars24'ün sesli ajan mimarisi

How Cars24 scales conversations and builds faster with OpenAI

Cars24, Hindistan merkezli büyük bir çevrimiçi araç alım-satım platformu. Problem tanımı ilginç: geleneksel e-ticaretin aksine Hindistan'da araç alıp satmak nadiren tek bir oturumda oluyor. Sürecin büyük kısmı uygulamanın dışında geçiyor — telefon görüşmeleri, belge kontrolleri, günler hatta haftalar süren takipler.

Ölçek büyüdükçe temel zorluk şu hâle gelmiş: operasyon ekiplerini sürekli büyütmeden, milyonlarca etkileşimde tutarlı ve kaliteli deneyim nasıl verilir?

Çözüm: alım, satım, finansman, takip ve destek için sesli ve yazılı ajanlar. Paylaşılan sonuçlar somut — ayda 1 milyondan fazla konuşma dakikası, destek çözüm oranlarında %50 artış, kilit süreçlerde %80 daha kısa dönüş süresi ve daha önce kaybedilen satıcı adaylarının %12'sinin geri kazanılması.

  • Sistem tasarımı iş sürecinin şeklini takip ediyor: süreç günlere yayılıyorsa, ajan da oturumlar arası durumu taşımak zorunda.
  • Metrikler girdi değil sonuç odaklı: çözüm oranı, dönüş süresi, geri kazanılan adaylar.

Sende karşılığı

Buradaki asıl mimari ders uzun süreli durum yönetimi. Bir kullanıcı bugün konuşup üç gün sonra geri döndüğünde, sistem önceki bağlamı nasıl hatırlıyor? Bu, konuşma geçmişini bir veritabanında tutmak kadar basit değil — geçmiş büyüdükçe bağlam penceresine sığmaz, özetlemen gerekir. KlioAI'da kullanıcının öğrenme geçmişini modele verirken aynı problemi yaşayacaksın. Pratik çözüm: ham geçmişi değil, damıtılmış bir profil tut — "kullanıcı geniş zamanda zorlanıyor, telaffuzda iyi" gibi. Hem ucuz hem de modele daha kullanışlı.

Sözlük

conversion funnel dönüşüm hunisi
Kullanıcının ilgiden satın almaya kadar geçtiği aşamalar; her aşamada bir kısmı ayrılır.
session state oturum durumu
Bir kullanıcı etkileşiminin, sonraki etkileşimlerde de gereken bilgisi.
Orijinali oku
OpenAI Research 16 Temmuz 20263 dk okuma başlangıç

Asıl fark yetenek değil bağlam: bir tasarımcının Codex deneyimi

How Codex became a collaborator for OpenAI’s creative team

OpenAI'ın kendi kullanım örneklerinden biri: Creative Specialist Chad Nelson, kod yazmayan biri olarak Codex'i bir yaratıcı problem çözücü gibi kullanıyor. Eskizler, storyboard'lar ve tasarım stil kılavuzları gibi "Codex'in anlayacağını varsaymayacağın" şeyleri getirdiğini söylüyor.

Yazının en isabetli cümlesi ise araç eleştirisi: "Kariyerim boyunca kullandığım araçların hangi projede olduğum, hangi marka için çalıştığım, hangi ürünü sunmaya çalıştığım hakkında hiçbir fikri yok." Codex ve ChatGPT'de bağlam var — hangi müşteri, hangi ürün, hangi duygu.

Yani anlatılan fark bir yetenek farkı değil, bağlam farkı.

  • Bir aracın değeri sadece ne yapabildiğiyle değil, ne kadar bağlam taşıyabildiğiyle ölçülüyor.
  • "Sadece geliştiriciler için" varsayımı, aracın gerçek kullanım alanını daraltan bir önyargı.

Sende karşılığı

Bu gözlemi kendi araçlarına uygula. Bir LLM özelliğinin kalitesini belirleyen şey genelde model değil, modele verdiğin bağlamdır. Mobit'teki doküman aramada modele sadece soruyu değil — kullanıcının rolünü, hangi firmayla çalıştığını, hangi ihale sürecinde olduğunu da verirsen cevap niteliksel olarak değişir. Bu ücretsiz değil elbette: her ek bağlam token demek. O yüzden doğru soru şu — hangi bağlam cevabı gerçekten değiştiriyor? Bunu test etmenin yolu, bağlamı tek tek çıkarıp çıktının bozulup bozulmadığına bakmak.

Sözlük

context bağlam
Modele görevle birlikte verilen çevresel bilgi; çıktı kalitesini model seçiminden çok etkileyebilir.
Orijinali oku