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 triage 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
- Alert fatigue 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.
Pratikte
Bu prensibi bugün uygulayabilirsin. Bir alarm kurarken şunu 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. Hata izleme kurduysan (Sentry vb.), muhtemelen 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
- Çok fazla bildirim yüzünden ekiplerin alarmlara duyarsızlaşması; kritik uyarıların kaçırılmasına yol açar.
- triage
- Gelen olayları aciliyet ve etkiye göre sınıflandırıp önceliklendirme.
- escalation
- Çözülemeyen bir olayın daha üst yetki ya da uzmanlığa aktarılması.
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ı agent’lar. 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ı.
Öne çıkanlar
- Sistem tasarımı iş sürecinin şeklini takip ediyor: süreç günlere yayılıyorsa, agent da oturumlar arası durumu taşımak zorunda.
- Metrikler girdi değil sonuç odaklı: çözüm oranı, dönüş süresi, geri kazanılan adaylar.
Pratikte
Buradaki asıl mimari ders uzun süreli state 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 context window’a sığmaz, özetlemen gerekir. Bir öğrenme ya da asistan ürününde kullanıcının geçmişini modele verirken aynı problemi yaşarsı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 · 2 terim
- conversion funnel
- 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
- Bir kullanıcı etkileşiminin, sonraki etkileşimlerde de gereken bilgisi.
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ı.
Öne çıkanlar
- 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ı.
Pratikte
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. Bir doküman aramada modele yalnızca soruyu değil kullanıcının rolünü ve içinde bulunduğu süreci de verirsen cevap niteliksel olarak değişir. Bu ücretsiz değil: 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 (ablation).
Sözlük · 1 terim
- context
- Modele görevle birlikte verilen çevresel bilgi; çıktı kalitesini model seçiminden çok etkileyebilir.