Yüngül yük testləri və feed məlumatlarının keyfiyyəti

1. Ümumiyyətlə niyə ChatGPT App üçün yük testləri lazımdır?

Klassik vebdə yük testləşdirmə tez-tez «milyonlarla RPS, nəhəng klaster, SRE üçün pizza» kimi təsəvvür olunur. ChatGPT App və MCP serverləri üçün reallıq daha sadə və, xoşbəxtlikdən, daha ucuzdur. Prinsipcə artıq SLO ilə tanışsınız, amma gəlin baxaq, SLO/observability və feed keyfiyyəti yük altında necə qarşılıqlı təsir göstərir.

Əsas xüsusiyyət: ChatGPT cavab generasiyasını davam etdirmək üçün tool call-ın bitməsini gözləyir. İstifadəçi gözəl token axınını görür, amma model aləti çağırmağa qərar verən kimi, axının sehrli hissəsi bitir — backend cavab verənə qədər. Əgər MCP və ya ACP serveriniz bəzən hədəflənən 2–4 saniyə əvəzinə 8–10 saniyəyə cavab verirsə, UX «sehrli köməkçi»dən «daha bir yavaş sayt»a çevrilir.

Üstəlik sərt timeout büdcəsi var: alət çağırışları üçün OpenAI yuxarı həddi onlarla saniyə səviyyəsində saxlayır (dəqiq rəqəmlər rejimdən asılıdır, amma 30–60 saniyə çərçivəsində düşünmək lazımdır, UX baxımından isə ümumiyyətlə 5–10 saniyəyə qədər). Əgər pik yük zamanı tool calls birdən 25–30 saniyəyə sığmağa başlayırsa, formal olaraq hələ limit daxilindəsiniz, amma istifadəçi baxımından artıq «sınımısınız».

İkinci məqam: bizə abstrakt RPS yox, məhz paralellik vacibdir. Store-dan gələn App üçün 50–100 eyni vaxtda aktiv istifadəçi tam realistdir; yoxlamaq istədiyimiz də budur, «sintetik GET /health 50k RPS-ə dözürmü?» sualı yox.

Və nəhayət, ChatGPT App — bu bir stack-dir:

flowchart LR
  User --> ChatGPT
  ChatGPT -->|tools/call| MCP["MCP serveri GiftGenius"]
  MCP --> DB["Hədiyyə feed-i bazası"]
  MCP --> ACP["Checkout / ACP backend"]
  ACP --> PSP["Ödəniş sistemi / Stripe"]

Əgər bu stack-i kiçik, amma realistik yük altında necə davrandığını yoxlamasaq, istənilən promo göndərişi və ya Store seçiminə düşmək onu tez bir zamanda «LLM məhsullarını necə ETMƏMƏK lazımdır» slaydına çevirə bilər.

Bu mühazirədə «yüngül yük testləri» dedikdə qısa qaçışlar (adətən 1–10 dəqiqə) nəzərdə tutulur ki, bunlar yoxlayır:

• sistem gözlənilən pik onlayna dözürmü;
• p95/p99 gecikmə SLO-dan yuxarı sürüşmürmü;
• xətalar, timeout-lar və xarici API-lərdən gələn rate limit-lər səpələnmirmi.

Və paralel olaraq keyfiyyətin ikinci tərəfinə — product feed (bundan sonra sadəcə «feed») məlumatlarına baxacağıq; onsuz heç bir GiftGenius nə «Gift», nə də «Genius» olacaq.

Bu mühazirədə əvvəl MCP/ACP üçün yüngül yük testlərini (dəqiq nəyə və necə yük vermək, hansı metriklərə baxmaq) müzakirə edəcəyik, sonra bunu observability ilə bağlayacağıq (gecikmə, xətalar, resurslar, webhook-lar və loglar), ikinci hissədə isə feed keyfiyyəti və onun yük altında gözlənilmədən necə «atəş açdığını» danışacağıq.

2. Nəyi yükləmək lazımdır: ChatGPT yox, öz API-ləriniz

Qarışmasın deyə bir fikri dərhal bərkidək: yük testini birbaşa öz backend-imizdə — MCP serverində, ACP endpoint-lərində, webhook-larda aparırıq, ChatGPT UI üzərindən yox.

Səbəblər bir neçəsidir.

• Birincisi, qənaət. Real tool calls-ları ChatGPT-dən keçirsəniz, həm tokenlərə görə pul ödəyəcəksiniz, həm də ChatGPT limitlərinə ilişəcəksiniz, halbuki test etdiyiniz sizin koddur.
• İkincisi, proqnozlanma. Birbaşa /mcp və ya /api/checkout çağırışlarında siz ssenarini idarə edirsiniz, modelin həmin aləti indi çağırıb-çağırmayacağı qərarından asılı qalmırsınız.
• Üçüncüsü, şəffaflıq. Yük altında açıq görmək istəyirsiniz: 5 dəqiqəyə MCP-yə 2000 sorğu budur, gecikmə paylanması budur, CPU qrafiki budur. Yükü ChatGPT-dən keçirsəniz, əlavə səs-küy və məhdudiyyətlər mənzərəni yalnız çətinləşdirəcək.

GiftGenius üçün yük testi üçün tipik endpoint dəsti:

• JSON‑RPC tools-u reallaşdıran MCP server endpoint-i (/mcp və ya oxşarı);
• checkout yaratmaq və tamamlamaq üçün bir-iki ACP endpoint-i (ödəniş sisteminin sandbox rejimində);
• mümkündür — ödəniş sistemindən gələn webhook-ları işləyən endpoint ki, pik hadisələrdə necə davrandığını görəsiniz.

Hesab edək ki, bizdə Next.js 16 backend var, burada /api/mcp vasitəsilə əlçatan MCP serveri və /api/checkout/create endpoint-i olan ACP serveri yaşayır.

3. GiftGenius üçün mini smoke‑load ssenarisi

Tutaq ki, product menecerlərimiz parlaq gələcəyə inanır və deyirlər: «Realistik pik — eyni vaxtda 50 istifadəçi, hər biri daxil olur, hədiyyə seçir və bəzən ödənişə qədər gedir».

Yüngül yük testi üçün, məsələn, 30–50 «virtual istifadəçi»ni (VU) modelləşdirmək kifayətdir, hər biri ardıcıllıqla aşağıdakıları edir:

1. giftgenius.search_gifts alət çağırışı (profil və büdcəyə görə hədiyyə axtarışı).
2. Nəticədən bir-iki məhsul üçün giftgenius.get_gift_details çağırışı.
3. (Bəzən) bir məhsul üçün create_checkout_session ACP endpoint çağırışı.

Bunların hamısı ChatGPT-siz, birbaşa HTTP ilə MCP/ACP-yə.

MCP-yə JSON‑RPC çağırışı

MCP-yə sorğu gövdəsi nümunəsi (sadələşdirilmiş):

const body = {
  jsonrpc: "2.0",
  id: "test-" + Math.random(),
  method: "tools/call",
  params: {
    toolName: "giftgenius.search_gifts",
    arguments: {
      occasion: "birthday",
      budget: 50,
      interests: ["sport", "books"],
    },
  },
};

Real layihədə struktur bir az fərqli ola bilər, amma prinsip eynidir: bir JSON‑RPC metod, içində alət və arqumentlər.

4. TypeScript-də sadə yük skripti yazırıq

İlk addım kimi ssenarimizin ən sadə hissəsini — MCP-yə giftgenius.search_gifts çağırışını həyata keçirək. Əvvəlcə /api/mcp-yə belə sorğular göndərən və gecikməni ölçən minimal Node.js/TypeScript skripti yazacağıq, sonra checkout və daha mürəkkəb yolları əlavə edəcəyik.

Baza HTTP müştərisi

Tutaq ki, bizdə .env var və orada MCP_URL=http://localhost:3000/api/mcp.

// scripts/loadTest.ts
import "dotenv/config";

const MCP_URL = process.env.MCP_URL!;

async function callSearchGifts() {
  const body = {
    jsonrpc: "2.0",
    id: `search-${Date.now()}-${Math.random()}`,
    method: "tools/call",
    params: {
      toolName: "giftgenius.search_gifts",
      arguments: { occasion: "birthday", budget: 50 },
    },
  };

  const started = Date.now();
  const res = await fetch(MCP_URL, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(body),
  });
  const latencyMs = Date.now() - started;
  if (!res.ok) throw new Error(`HTTP ${res.status}`);
  return latencyMs;
}

Burada həmçinin sadə JSON cavab parsinqi də əlavə etmək olar, amma latency/error rate məqsədləri üçün bu kifayətdir.

Bir neçə sorğunun paralel icrası

Eyni vaxtda sorğuların sayını idarə etmək lazımdır. Sadəlik üçün sabit sayda «virtual istifadəçi» götürək və hər birindən ard-arda N sorğu göndərməsini xahiş edək.

async function runVirtualUser(iterations: number) {
  const latencies: number[] = [];
  for (let i = 0; i < iterations; i++) {
    try {
      const ms = await callSearchGifts();
      latencies.push(ms);
    } catch (e) {
      console.error("Error in VU:", e);
      latencies.push(-1); // səhv kimi işarələyək
    }
  }
  return latencies;
}

İndi, məsələn, 20 belə virtual istifadəçini işə sala bilərik:

async function main() {
  const users = 20;
  const iterations = 10;

  const tasks = Array.from({ length: users }, () =>
    runVirtualUser(iterations),
  );

  const results = await Promise.all(tasks);
  const all = results.flat();
  // ...metriklərin hesablanması
}

main().catch((e) => console.error(e));

Bu artıq təxminən 200 MCP çağırışı təmin edəcək, hansılardan bir qismi paralel icra olunacaq, yəni kifayət qədər yüksək paralelliklə.

p95 və error rate hesablanması

Perseptil və səhvlərin hesablanması üçün kiçik util əlavə edək. Xatırladaq: p95 — bu o dəyərdir ki, sorğuların 95%-i ondan aşağıda yerləşir.

function percentile(values: number[], p: number) {
  const sorted = values.filter(v => v >= 0).sort((a, b) => a - b);
  if (!sorted.length) return 0;
  const idx = Math.floor((p / 100) * (sorted.length - 1));
  return sorted[idx];
}

function errorRate(values: number[]) {
  const total = values.length;
  const errors = values.filter(v => v < 0).length;
  return (errors / total) * 100;
}

Və main-də çıxış əlavə edək:

const p95 = percentile(all, 95);
const p99 = percentile(all, 99);
const errRate = errorRate(all);

console.log(`Total: ${all.length}`);
console.log(`p95: ${p95} ms, p99: ${p99} ms`);
console.log(`Error rate: ${errRate.toFixed(2)}%`);

İndi sizdə lokalda və ya staging-də release-dən əvvəl işə sala biləcəyiniz minimal smoke‑load skripti var. Bu zaman ChatGPT-yə dəymirsiniz, tokenləri yandırmırsınız və bütün diqqət MCP-nizdədir.

ACP və checkout ilə nə etmək lazımdır

Oxşar şəkildə callCreateCheckoutSession adlı daha bir helper əlavə edə bilərsiniz, bu da ACP endpoint-inə vuracaq. Burada real sifarişləri «şişirtməmək» üçün test/sandbox ödəniş rejimindən istifadə etmək vacibdir. Tipik çağırış adi JSON ilə POST olacaq:

async function callCreateCheckoutSession(productId: string) {
  const started = Date.now();
  const res = await fetch("http://localhost:3000/api/checkout/create", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ productId, test: true }),
  });
  const latencyMs = Date.now() - started;
  if (!res.ok) throw new Error(`HTTP ${res.status}`);
  return latencyMs;
}

Sonra runVirtualUser-də belə bir pattern qura bilərsiniz: 3 dəfə axtarış → 1 dəfə checkout, beləliklə «axtarışların alışdan çox olduğu» hunini modelləşdirən.

5. Daha ciddi alətlər: k6 (amma sadə yanaşma ilə)

Node skripti «minimal giriş» kimi yaxşıdır, amma bəzən k6 kimi ixtisaslaşmış alətdən istifadə rahatdır, burada ssenarilər JavaScript-də yazılır, runtime isə Go-dadır (yəni sürətlidir).

MCP üçün kiçik k6 skripti nümunəsi:

// loadtest-mcp.js
import http from "k6/http";
import { check, sleep } from "k6";

export const options = {
  stages: [
    { duration: "30s", target: 30 },
    { duration: "2m", target: 30 },
  ],
};

export default function () {
  const payload = JSON.stringify({
    jsonrpc: "2.0",
    id: `search-${Math.random()}`,
    method: "tools/call",
    params: {
      toolName: "giftgenius.search_gifts",
      arguments: { occasion: "birthday", budget: 50 },
    },
  });

  const res = http.post(__ENV.MCP_URL, payload, {
    headers: { "Content-Type": "application/json" },
  });

  check(res, { "status is 200": (r) => r.status === 200 });
  sleep(1);
}

İşə salma komandası:

MCP_URL=http://localhost:3000/api/mcp k6 run loadtest-mcp.js

k6 özü p95/p99 və error rate-i hesablayacaq, gözəl hesabatlar çəkəcək — sonra onları Grafana və digər sistemlərə ixrac edə bilərsiniz.

Vacibdir ki, hətta bu cür alətlərlə də məqsədimiz dəyişməz qalır: milyon RPS-i dözmək yox, gözlənilən pikdən 5–10× artıqda sistemin dağılmadığına və p95-in SLO daxilində qaldığına əmin olmaq.

6. Yük qaçışı zamanı (və sonra) nəyə baxmalı

Metrikləri və SLO-ları artıq müzakirə etmişdik, indi sadəcə onları yük kontekstinə «endirməklə» danışaq.

Birincisi, gecikmə (latency). search_gifts tipli MCP alətləri üçün əvvəlcədən «p95 < 2–3 saniyə» kimi hədəf qoymuşdunuz. Smoke‑load zamanı baxırsınız: p95/p99 2–3 dəfə artmırmı. Üstəlik, baseline ilə müqayisə önəmlidir: kod dəyişikliyindən əvvəl p95 400 ms idisə, sonra 1500 ms oldu — formal olaraq hələ SLO daxilində olsanız belə, düşünməyə əsas var.

İkincisi, error rate. Yük altında gözlənilməz şeylər tez-tez üzə çıxır: DB bağlantı hovuzunun tükənməsi, xarici API-dən qəfil 429-lar, ödəniş sisteminə müraciətdə timeout-lar. Normal yükdə error rate sıfıra yaxın olmalıdır; smoke‑load-da ayrı-ayrı nasazlıqlar ola bilər, amma qətiyyən 5–10% yox.

Üçüncüsü, resurs metrikləri: CPU, yaddaş, bəzən — açıq fayl deskriptorlarının və qoşulmaların sayı. Bunlar infrastrukturanızdan asılıdır, amma əsas fikir sadədir: 30 VU-da CPU 100% və GC vaxtın yarısını yeməsini görmək istəmirsiniz.

Dördüncüsü, webhook-lar. Əgər commerce ssenariniz varsa, sifarişin son nöqtəsi tez-tez ödəniş sistemindən gələn webhook-un uğurla işlənməsindən asılı olur. Vacibdir ki, ACP-də sorğunun sürətinə deyil, həm də «webhook gəldi → biz onu uğurla işlədik» gecikməsinə baxasınız.

Və nəhayət, loglar. trace_id/checkout_session_id ilə strukturlu loglar yük qaçışından sonra ən yavaş və ya yıxılmış bir-iki sorğunu götürməyə və zəncir üzrə keçməyə imkan verir: MCP → xarici API → ACP → webhook. Bu, xüsusən də yük altında qəribə p99 quyruqları görürsünüzsə faydalıdır.

7. Feed məlumatlarının keyfiyyəti: strukturdən mənaya

Yük altında gecikmə, xətalar və resursların davranışına baxdıq. Amma bunların hamısında SLO hədəflərinə sığsanız belə, istifadəçi təcrübəsi yenə də pis feed məlumatlarına görə «sökülə» bilər.

İkinci böyük mövzuya keçiririk: məlumatlar. GiftGenius kimi commerce App-də product feed (məhsul feed-i) «diskdə nəsə» deyil, LLM və agentlər üçün birbaşa yanacaqdır. Feed zibildirsə, model sizin yerinizə qiyməti və mövcudluğu «uydurmayacaq».

Feed keyfiyyəti haqqında üç qat kimi düşünmək rahatdır.

Struktur səviyyə

Bu, məlumatların bazis düzgünlüyüdür:

• JSON düzgün parse olunur.
• Bütün məcburi sahələr mövcuddur: id, name, price, currency, imageUrl, availability və s.
• Dəyərlərin tipləri gözləntilərə uyğundur: qiymət — rəqəm, availability — enum, categories — sətir massividir.
• id dublikatları yoxdur.

Bunun bir hissəsini artıq kontrakt testləri ilə, feed üçün JSON Schema/Zod sxemini təsvir edərkən örtmüşdünüz. İndi həmin sxemləri real həcmli məlumatlara tətbiq etmək lazımdır.

GiftGenius feed elementinə aid sadə Zod sxem nümunəsi:

import { z } from "zod";

export const giftItemSchema = z.object({
  id: z.string().min(1),
  name: z.string().min(3),
  description: z.string().optional(),
  price: z.number().positive(),
  currency: z.enum(["USD", "EUR", "GBP"]),
  imageUrl: z.string().url(),
  inStock: z.boolean(),
  tags: z.array(z.string()).default([]),
});

Bütün feed-in sxemi isə sadəcə z.array(giftItemSchema)-dır.

Biznes səviyyəsi (semantika)

Struktur baxımdan məhsul düzgün ola bilər, amma biznes baxımından — absurd:

• Bahalı məhsul üçün qiymət 0 və ya 0.01.
• Bazarla uyğun gəlməyən valyuta (yalnız EUR-da satılan məhsullar üçün USD).
• inStock = true, amma son yeniləmə tarixi yarım il əvvəl.
• Unifikasiyasız 1000 variantlı kateqoriyalar.

Bu səviyyə üçün əlavə yoxlamalar və «sağlam məntiq» qaydaları əlavə etmək faydalıdır. Məsələn:

const businessRules = (item: GiftItem) => {
  const problems: string[] = [];

  if (item.price > 10000) {
    problems.push("şübhəli dərəcədə yüksək qiymət");
  }
  if (!item.inStock && item.tags.includes("bestseller")) {
    problems.push("bestseller, amma stokda deyil");
  }
  return problems;
};

Bu yoxlamaları nightly job kimi və ya yeni feed yaradılarkən işə sala bilərsiniz.

LLM səviyyəsi

Model — çox ağıllıdır, amma onun da «qüsurları» var:

• HTML, artıq teqlər və texniki mətndən ibarət doldurulmuş təsvirlər.
• Dillərin qarışması (feed-in yarısı ingilis, yarısı başqa dildə) və locale göstərilməməsi.
• «SEO» tərzində həddindən artıq uzun adlar: «Ən yaxşı super hədiyyəni indi ucuz al».

Bu səviyyədə məlumatları dost formata gətirmək vacibdir:

• HTML teqlərini çıxarmaq və ya plaintext-ə çevirmək.
• Təsvirlərin dilini normallaşdırmaq (və ya ən azı locale-u açıq göstərmək).
• Həddən artıq uzun adları və təkrarlanan informasiyanı kəsmək.

Bu tapşırıqların bir hissəsini avtomatlaşdırmaq (məsələn, pre‑processing skriptləri ilə), bir hissəsini isə feed-i dolduran komanda ilə razılaşdırmaq olar.

8. Praktika: GiftGenius üçün feed validatoru

Layihəmizə validateFeed.ts adlı sadə skript əlavə edək; bu, feed-i JSON-dan oxuyacaq, Zod ilə validasiya edəcək və keyfiyyətin baza metriklərini hesablayacaq.

// scripts/validateFeed.ts
import { readFile } from "fs/promises";
import { giftItemSchema } from "../src/schema/giftItem";

async function main() {
  const raw = await readFile("data/gift-feed.json", "utf-8");
  const data = JSON.parse(raw);

  const items = giftItemSchema.array().parse(data);
  console.log(`Məhsulların ümumi sayı: ${items.length}`);

  const missingImages = items.filter(i => !i.imageUrl).length;
  console.log(`Şəkilsiz: ${missingImages}`);
}

main().catch((e) => {
  console.error("Feed validation failed:", e);
  process.exit(1);
});

Burada biz MCP serveri ilə eyni kontraktdan istifadə edirik, yəni kontrakt testləri və feed yoxlaması eyni sxemdən istifadə edir — bu, uyğunsuzluq ehtimalını xeyli azaldır.

Daha sonra biznes qaydaları yoxlamalarını və belə metrikləri əlavə etmək olar:

• təsvirsiz məhsulların payı;
• şübhəli dərəcədə aşağı/yüksək qiymətli məhsulların payı;
• id dublikatlarının və ya təkrarlanan name + price cütlərinin sayı.

Bu rəqəmləri artıq metrik sisteminə (Prometheus, Datadog və s.) göndərmək və məlumat keyfiyyəti üçün ayrıca SLO-lar saxlamaq olar — necə ki, kod üçün SLO təyin edirsiniz.

9. Yük və feed bir-biri ilə necə bağlıdır

Bəzən elə gəlir ki, «performans» və «məlumat keyfiyyəti» çox da əlaqəli mövzular deyil. Praktikada onlar olduqca sıx bağlıdır.

Nümunə əlaqələr:

• Yük altında sorğuların bir hissəsi əvvəl demək olar ki, rast gəlinməyən «nadir» məntiq budaqlarına düşməyə başlayır. Məsələn, xüsusi endirim tipləri və ya qeyri-standart shipping olan məhsullar. Feed bu yerlərdə çirkli idisə, həm xətalar ala, həm də performansın ciddi pisləşməsini (yığınla validasiya, istisnalar, fallback məntiqi) görə bilərsiniz.
• Feed çox səs-küylüdürsə (HTML-li nəhəng təsvirlər, mənasız teqlər), MCP serveri daha çox məlumatı çəkməli və seriyallaşdırmalıdır, bu isə birbaşa tool-call emal vaxtına və cavab ölçüsünə təsir edir.
• Commerce hissəsində pis feed out of stock olan məhsul seçən istifadəçilərə görə çox sayda «boş» checkout cəhdlərinə gətirə bilər. Bu həm UX-ə, həm də ACP metriklərinə (uğursuz intent-lərin artması) zərbə vurur.

Buna matris kimi baxmaq rahatdır:

Yük qaçışı burada fənər rolunu oynayır: o, adi vaxtlarda nadir toxunulan feed hissələrini işıqlandırmağa kömək edir, amma aktiv trafikdə «atəş açmağa» başlayır.

10. Bunu GiftGenius-un release prosesinə necə daxil edirik

Proses baxımından, yuxarıda təsvir edilənlər «ilk prod-dan əvvəl bir dəfə» olmamalıdır. 16-cı modul («Production, şəbəkə və miqyaslandırma») və 17-ci modulda («Müşahidəolunurluq və keyfiyyət») bu yanaşma məhz müntəzəm release checklist-inin bir hissəsi kimi tikilib: release-dən əvvəl sadəcə unit/contract/E2E yox, qısa smoke‑load və üstəlik feed yoxlaması da işə salınır.

Məntiqli minimal pipeline, yeni versiyanı yayımlamazdan əvvəl:

1. Unit + contract + inteqrasiya testləri «yaşıldır».
2. Staging-də MCP/ACP-yə qarşı qısa smoke‑load, əgər kritik kod (axtarış məntiqi, DB ilə iş, checkout) dəyişibsə.
3. Feed validatoru xətasız işləyir, feed-in baza metrikləri (qırıq qeydlərin sayı, şəkilsiz pay və s.) qəbul edilən hədlərdədir.
4. Dashboard-lar və alert-lər yeni endpoint-lər və SLO nəzərə alınaraq yenilənib.
5. Uğursuzluq halı üçün rollback planı var: ya feature flag ilə funksiyanı söndürmək, ya da build-i geri qaytarmaq.

Beləcə, GiftGenius «DevDay üçün demo» olmaqdan çıxır və Store-da və trafik sıçrayışlarına hazır olan bir servislə əvəz olunur.

11. Yük testləri və feed yoxlamasında tipik səhvlər

Səhv №1: yük testi ChatGPT üzərindən, öz backend-iniz üzərindən yox.
Bəzən «hər şeyi real kimi test etmək» istəyirlər və məhz ChatGPT UI üzərindən gedən skriptlər işə salırlar. Nəticədə OpenAI limitlərinə dirənirlər, tokenləri yandırırlar və çox səs-küylü nəticələr alırlar. Halbuki MCP/ACP problemlərini /mcp və /api/checkout-a birbaşa atəş açaraq yüz dəfə ucuz tutmaq olardı.

Səhv №2: yalnız orta cavab vaxtına fokus.
«Bizdə orta gecikmə 500 ms-dir, hər şey əladır» — amma p95 bu zaman 5 saniyədir, bunu nədənsə unudurlar. SLO mövzusunda müzakirə etdiyimiz kimi, real UX-i məhz paylanmanın quyruğu (p95/p99) müəyyən edir. Yük altında orta tez-tez «normal» qalır, quyruq isə iki-üç dəfə artır.

Səhv №3: praktiki smoke‑load əvəzinə «enterprise yükü» qurmağa cəhd.
On minlərlə istifadəçini imitasiya edən mürəkkəb stendi aylarla hazırlamaq, GiftGenius səviyyəli ChatGPT App üçün demək olar ki, həmişə artıqdır. Daha faydalısı 50–100 VU üçün sadə, amma müntəzəm işlədilən smoke‑load və anlaşılan metriklərə sahib olmaqdır.

Səhv №4: qeyri-realistik yük ssenarisi.
Skript eyni sorğunu təkrar-təkrar göndərir, istifadəçi, dil, məhsul tipi variasiyası yoxdur və eyni zamanda ACP və webhook-lara dəymir. Nəticədə siz yalnız bir isti happy‑path-ı test edirsiniz, sistemin real «küncləri» isə kölgədə qalır. Daha yaxşısı, heç olmasa sadələşdirilmiş, amma inandırıcı flow modelləşdirməkdir: müxtəlif büdcələr, maraqlar, istifadəçilərin bir hissəsi checkout-a çatır, bir hissəsi — yox.

Səhv №5: feed-i yalnız «gözlə» və ya prod-da yoxlamaq.
Feed toplanıb, prod-a yüklənib, modeldən qəribə tövsiyələr gəlib və baş qaşımağa başlamısınız. Halbuki Zod/JSON Schema ilə sadə skript bir dəqiqəyə göstərərdi ki, məhsulların 10%-i şəkilsizdir, 5%-də qiymət 0-dır, 3%-də isə valyuta XXX-dır. Feed-in avtomatik validasiyasının olmaması commerce tətbiqlərində ən çox rast gəlinən xəcalət mənbələrindən biridir.

Səhv №6: pis feed ilə LLM-in «öz‑özünə hər şeyi başa düşəcəyinə» ümid.
Bəli, model çox şey bacarır, amma düzgün qiyməti və ya stokda olmanı uydurmayacaq. Eyni məhsul feed-də müxtəlif qiymətlərlə və ya «stokda var»/«stokda yox» kimi ziddiyyətlərlə təqdim olunursa, agent həm hallusinasiyalara, həm də istifadəçi üçün uyğunsuz təcrübəyə səbəb ola bilər. Məlumatın təmizliyinə görə məsuliyyət sizdədir, modeldə yox.

Səhv №7: feed metrikləri ilə ümumi SLO-lar arasında əlaqənin olmaması.
Mükəmməl sürətli MCP və ACP-yə sahib ola bilərsiniz, amma feed-də məhsulların 30%-i «qırıq»dırsa, istifadəçi təcrübəsi yenə də dəhşətli olacaq. Komandalar tez-tez yalnız texniki SLO-ları (gecikmə, error rate) izləyir və məlumat keyfiyyəti üzrə SLO-ları (minimum etibarlı SKU faizi, maksimum dublikat və s.) görməzdən gəlirlər. Nəticədə «rəqəmlərə görə hər şey yaxşıdır», hissiyyata görə isə — yox.

Səhv №8: hazırlıq olmadan birbaşa prod-da yük testlərinin işə salınması.
Bəzən kimsə cümə axşamı axşam «tez bir k6 boğazını prod MCP-də yoxlayaq» qərarına gəlir və heç kəsi xəbərdar etmir. Yaxşı halda real metrikləri pozar və on‑call mühəndisi trafik sıçrayışı ilə təəccübləndirərsiniz, pis halda — xarici API və ya ödəniş sisteminin rate limit-lərinə ilişərsiniz. Həmişə ilk ssenariləri staging-də işə salın, əgər prod testi lazımdırsa — bunu şüurlu şəkildə, pəncərə və bildirişlərlə edin.