# VC-099 · Hata ve harcama artıyor ama sorumlu kişiye uyarı ulaşmıyor

Hatalar günlükte ve harcama panelde görünse de kimseye haber gitmiyor. Kullanıcı şikâyeti veya fatura gelene kadar sorun sürüyor, yalnız veri toplamak erken müdahale sağlamıyor.

- Önem: ORTA. Etkisi orta. Trafik artınca ya da istek tekrarlanınca tetiklenir.
- Önem notu: Hata veya maliyet artışı sırasında fark edilme gecikmesi temel alınır. Kesintinin iş etkisi ve ücretli çağrı hızı önemi değiştirir. Uyarı harcamayı otomatik durduran bir tavan değildir.
- Eksen ve kategori: Sağlamlık, 15 Gözlem, yedek ve kurtarma
- Yığın: Her yığın
- Yapay zekâ kodunda: ölçülmedi. Dayanak: uzman görüşü.
- Ne zaman bakılır: İlk yayından önce, Her ay
- CWE: yok. Uyarı ve müdahale süreci eksikliği günlük kaydı eksikliğiyle aynı değildir. Doğrudan CWE eşlemesi kullanılmaz, izleme ve bütçe belgelerine dayanılır.
- Checklist ifadesi: Hata ya da harcama eşiği aşınca sorumlu kişiye uyarı ulaşıyor.
- Son inceleme: 4 Ekim 2026, Komünite editörlüğü
- Adres: https://vibecheck.komunite.com.tr/madde/hata-ve-harcama-uyarilari-kurulmamis

## 60 saniyelik kontrol

Yalnız kendi uygulamanda ya da yazılı izin aldığın sistemde dene. Bu bir sızma testi değildir.

1. Kullanıcıyı etkileyen hata için tanımlı eşik ve sorumluyu bul.
2. Harcama uyarısının hangi veri gecikmesiyle çalıştığını incele.
3. Son zararsız deneme bildiriminin teslim kaydını kontrol et.
4. Veri gelmemesi halinde sistemin sağlıklı sayılıp sayılmadığını doğrula.

## Ne oluyor

Uygulama hata kaydı tutuyor, sağlayıcı da harcama grafiği gösteriyor. Bu iki özellik izleme tamamlanmış gibi görünebilir. Fakat kimse paneli açmadığında sorundan haber gelmiyorsa müdahale yolu hâlâ eksiktir. Kullanıcı işlemleri başarısız olmaya devam ederken ekip bunu şikâyetten öğrenebilir. Ücretli çağrılar da bütçe fark edilene kadar sürebilir.

Veri toplamak, bir koşulu değerlendirmek ve sorumluya haber vermek ayrı adımlardır. Hangi hata bir kişiyi uyandırmalı, hangisi ertesi gün incelenmeli? Bildirimde hangi uygulama ve hangi dönemden söz ediliyor? Mesaj ulaşmazsa bu durum nasıl anlaşılacak? Bu sorular yanıtlanmadığında çok sayıda günlük satırı tek başına operasyonel görünürlük sağlamaz.

Harcama için ek bir ayrım gerekir. Bütçe bildirimi, kullanımı otomatik durduran bir sınır olmayabilir. Sağlayıcı maliyet verisini gecikmeli işliyorsa eşik aşıldığında ücret oluşmaya devam edebilir. Uyarı kanalını kurmak değerlidir, fakat bunu harcamayı kesin sınırlayan bir mekanizma diye sunmak yanlış beklenti yaratır. Uyarı ve uygulama içi kullanım bütçesi birlikte, ayrı sorumluluklarla tasarlanmalıdır.

## Gerçek olay

Bu madde belirli bir AI uygulamasının fatura veya kesinti vakasına bağlanmıyor. Google SRE kitabı, izleme verisiyle eylem gerektiren uyarıyı ayırıyor. Çok sık ve belirsiz bildirimlerin gerçek sorunun fark edilmesini zorlaştırabileceğini de anlatıyor. Amaç her olağandışı satır için bildirim göndermek yerine anlaşılır ve müdahale edilebilir koşullar seçmektir. [İzleme ve uyarı](https://sre.google/sre-book/monitoring-distributed-systems/)

AWS Budgets belgesi, kullanımın faturaya yansıması ile bildirimin alınması arasında gecikme olabileceğini açıkça belirtiyor. Eşik aşıldıktan sonra ek maliyet oluşması bu modelde mümkündür. [Bütçe bildirimi sınırları](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html) Bu satıcı davranışını bütün hizmetlere aynı süreyle genellemiyoruz. Kendi sağlayıcının veri yenileme ve otomatik işlem seçeneklerini ayrıca incelemelisin. Burada evrensel bir hata oranı veya para eşiği önermiyoruz.

## Yapay zekâ bunu neden üretiyor

**Model kayıt tutmayı gözlemle eşitleyebilir.** Ajan hata yakalayıp `console.error` eklediğinde sorunun görünür olduğunu düşünebilir. Geliştirme sırasında terminal açık olduğu için hata gerçekten göz önündedir. Canlıda aynı satıra kimin bakacağı ise ayrı bir konudur. Bildirim alıcısı ve müdahale sorumlusu istemde belirtilmediyse çözüm günlük toplama aşamasında kalabilir. Kabul ölçütü bu yolu tamamlamalıdır.

**Panel görünür bir tamamlanma işaretidir.** Grafik eklemek, çalışan bir arayüz üretir ve kolayca gösterilir. Eşik değerlendirmesi, teslim hatası veya sorumlunun değişmesi gibi durumlar daha az görünürdür. Ajan ekranın açılmasını başarı sayarsa bu işletim ayrıntıları atlanabilir. Gönderim yolu üzerinde zararsız bir deneme yapmak, yalnız tasarımın varlığından daha somut kanıt sağlar.

**Örnek eşik ürün kararı gibi kalabilir.** Model açıklama için seçilmiş bir oranı veya tutarı uygulamaya doğrudan koyabilir. Düşük hacimde bu eşik sürekli yanlış alarm üretirken yüksek hacimde geç tepki verebilir. Ölçüm penceresi ve asgari örnek sayısı belirtilmeden tek sayı anlamlı değildir. İş yükünün normal davranışıyla karşılaştırma yapılmalıdır. Eşik değişikliği de kayda alınabilir olmalıdır.

**Sessizlik sağlıklı durum sanılabilir.** Veri kaynağı durduğunda hiçbir eşik aşımı görünmeyebilir. Model yalnız gelen ölçümleri değerlendiren kod yazdıysa ölçüm gelmemesini hiç fark etmez. Son ölçüm zamanı ve izleme sisteminin kendi sağlığı ayrıca izlenmelidir. Bu açıklamalar olası üretim mekanizmalarıdır. AI araçlarının bu eksiği hangi sıklıkla oluşturduğunu gösteren bir araştırma sonucu olarak sunulmaz.

## Etki

Fark edilme gecikmesi, arızanın kullanıcı üzerindeki süresini uzatabilir. Harcama artışı da ekip müdahale edene kadar devam edebilir. Bildirim fazla gürültülüyse insanlar kanalı susturabilir ve yararlı sinyal aynı akışta kaybolabilir.

Bu yüzden yalnız uyarı sayısını artırmak çözüm değildir. Her uyarının sahibi, beklenen tepkisi ve uygun aciliyeti olmalıdır. Bir deneme projesi için basit bir kanal yeterli olabilir. Ödeme alan veya ücretli model çağıran bir hizmette farklı belirtiler ve ayrı maliyet sınırları gerekebilir. Madde mevcut günlüklerin yetersiz olduğunu otomatik varsaymaz.

## Nasıl anlarsın

Kullanıcıyı etkileyen bir hata belirtisi seç ve ölçümden alıcıya kadar yolu izle. Eşik hangi pencereye uygulanıyor, veri nereden geliyor ve son başarılı teslim denemesi ne zaman yapılmış? Gerçek kullanıcı işlemini bozmadan sentetik sinyal kullan. Bildirim adresini veya günlük içeriğini paylaşırken sırları dışarı taşıma.

Yerel örnek hata ve harcama koşullarını ayrı olaylara dönüştürür. Test sağlıklı durumda sessizliği, ilk eşik aşımını, aynı olayın tekrarını, düzelme sonrası yeni olayı ve gönderim hatasından sonra yeniden denemeyi doğrular. Gerçek e-posta veya mesaj göndermez. Teslim alıcısı yalnız test işleviyle temsil edilir.

## Nasıl düzeltirsin

1. **Belirtiyi seç.** Başarısız işlem, gecikme veya harcama artışını iş etkisiyle bağla. Her teknik günlük satırı insan müdahalesi gerektirmez.
2. **Pencereyi tanımla.** Oran, örnek alt sınırı ve tutarın hangi döneme ait olduğunu belirle. Kod örneğindeki değerler yalnız sentetik deney içindir.
3. **Teslim yolunu dene.** Sorumlu ve yedek sorumlu belli olsun. Bildirim hatasını başarılı teslim gibi kaydetme.
4. **Tekrarı yönet.** Aynı olay için gereksiz tekrarları azalt. Durum düzeldikten sonra oluşan yeni olayı bastırma.
5. **Eksik veriyi izle.** Telemetri kesintisini ayrı koşul olarak ele al. Bütçe bildirimini gerektiğinde uygulama içi kota ve harcama tavanıyla tamamla.

## Bir daha olmasın

Uyarı sahibini ve zararsız teslim denemesini yayın kontrolüne ekle. Sağlayıcı veya iletişim kanalı değiştiğinde denemeyi yenile.

## Sınır

Örnekte durum bellekte tutulur ve çağrılar sırayla yapılır. Yeniden başlatma veya birden çok izleyici için kalıcı olay durumu gerekir. Kod ölçüm toplamayı, zamanlayıcıyı veya telemetri yokluğu denetimini kurmaz. Bütçe uyarısı otomatik harcama engeli değildir. Güvenlik olaylarının ayrıntılı denetim izi ve hataların uygulama içinde doğru ele alınması komşu konulardır.

## Düzeltme kodları

### Node.js: Hata ve harcama bildirim koşulu

Önce:

```js
// gozlem/uyari.js, açıklama amaçlı. Değerler önceden toplanmış aynı pencereye ait.
export function createMonitor(send) {
  return async function observe({ requests, errors, spendCents }) {
    if (![requests, errors, spendCents].every(Number.isSafeInteger) ||
        requests < 0 || errors < 0 || spendCents < 0 || errors > requests) {
      throw new Error('Geçersiz ölçüm');
    }
    // Panel güncellenir, sorumlu kişiye bildirim yolu hiç çağrılmaz.
    return { requests, errors, spendCents };
  };
}
// Günlük toplamı veya bütçe dönemini bu örnek oluşturmaz.
// send yalnız testte taklit edilir, gerçek ileti gönderilmez.
// Dashboard verisi kendi başına uyarı değildir.
// Telemetri yokluğunu izlemek ayrıca gerekir.
```

Sonra:

```js
// gozlem/uyari.js, açıklama amaçlı. Eşikler yalnız sentetik örnek içindir.
export function createMonitor(send) {
  const notified = new Set();
  return async function observe({ requests, errors, spendCents }) {
    if (![requests, errors, spendCents].every(Number.isSafeInteger) ||
        requests < 0 || errors < 0 || spendCents < 0 || errors > requests) {
      throw new Error('Geçersiz ölçüm');
    }
    const active = new Set();
    if (requests >= 20 && errors >= 5 && errors / requests >= 0.2) active.add('ERRORS');
    if (spendCents >= 10000) active.add('SPEND');
    for (const key of notified) if (!active.has(key)) notified.delete(key);
    for (const key of active) {
      if (notified.has(key)) continue;
      await send({ key });
      notified.add(key);
    }
  };
}
// observe çağrıları sırayla yapılır. Yeniden başlatmada bu küme sıfırlanır.
// Üretimde kalıcı olay durumu, teslim kanıtı ve telemetri yokluğu denetimi gerekir.
```

Düzeltmeyi kanıtlayan test:

```js
// gozlem/uyari.test.mjs, açıklama amaçlı. Dış bildirim yerine yerel alıcı.
import test from 'node:test';
import assert from 'node:assert/strict';
const { createMonitor } = await import(process.env.ORNEK_DOSYA);
test('eşik, tekrar, düzelme ve teslim hatası ayrı değerlendirilir', async () => {
  const delivered = [];
  const observe = createMonitor(async event => { delivered.push(event.key); });
  const normal = { requests: 100, errors: 0, spendCents: 10 };
  const high = { requests: 20, errors: 5, spendCents: 10000 };
  await observe(normal);
  assert.deepEqual(delivered, []);
  await observe(high);
  await observe(high);
  assert.deepEqual(delivered, ['ERRORS', 'SPEND']);
  await observe(normal);
  await observe(high);
  assert.equal(delivered.length, 4);
  let tries = 0;
  const retry = createMonitor(async () => { if (++tries === 1) throw new Error('DELIVERY'); });
  await assert.rejects(retry({ ...normal, spendCents: 10000 }), /DELIVERY/);
  await retry({ ...normal, spendCents: 10000 });
  assert.equal(tries, 2);
  await assert.rejects(observe({ ...normal, errors: NaN }));
});
```

## Ajan kuralı (AGENTS.md)

```md
## Hata ve harcama uyarısı yok (vibecheck VC-099)
- Eylem gerektiren hata ve harcamalar için sorumlu belirle.
- Eşik ve ölçüm penceresini iş yüküne göre seç.
- Tekrarlanan bildirimi sınırlarken yeni olayı kaçırma.
- Bildirim yolunu zararsız sinyalle dene.
- Bütçe uyarısını harcama tavanı sayma.
- Telemetri kesilmesini ayrıca izle.
```

## Kaynaklar

1. [Monitoring Distributed Systems](https://sre.google/sre-book/monitoring-distributed-systems/), Google
2. [Managing your costs with AWS Budgets](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html), AWS

---

vibecheck · Komünite editörlüğü. Metin CC BY 4.0, prompt ve kural parçaları MIT-0. Kaynak: https://vibecheck.komunite.com.tr/madde/hata-ve-harcama-uyarilari-kurulmamis