İnsidentlərin idarə edilməsi və əməliyyat dövrü

1. ChatGPT Apps dünyasında insident nədir

Klassik vebdə insident adətən “server yatıb”, “500 xətaları kəskin artdı”, “latency iki dəfə böyüdü” kimi hallardır. ITIL üzrə formal tərif: insident — servisin planlaşdırılmamış dayandırılması və ya servis keyfiyyətinin pisləşməsi.

ChatGPT Apps və GiftGenius dünyasında mənzərə daha mürəkkəbdir. Bizdə aşağıdakıları edə bilən modellər qatı əlavə olunur:

• lazım olan tool-u çağırmamaq, baxmayaraq ki, hər şey əlçatan olub;
• tool-u yanlış parametrlərlə çağırmaq;
• sizin MCP-ni görməzlikdən gələrək nəticəni “hallusinasiyalı” şəkildə uydurmaq.

Buna görə insident yalnız HTTP 500 deyil, həm də bütün backend metrikaları “yaşıl” olsa da, istifadəçilər kütləvi şəkildə “bot zəifdir və hədiyyələri göstərmir” deyə şikayət etdikləri vəziyyətdir — çünki model suggest_gifts çağırmağı dayandırıb və ya arqumentləri qarışdırır. Bu, keyfiyyət insidentidir (Quality incident).

İnsidentlər barədə kateqoriya üzrə düşünmək rahatdır:

İnsident — bu, faktiki metrika əvvəlcədən razılaşdırılmış SLO hüdudlarından çıxdığı andır. Məsələn:

• razılaşmışıq: hədiyyə seçiminin p95-i < 4 saniyə. Oldu 9 saniyə;
• həftəlik checkout-ların 99%-nin uğurlu olmasını istəyirik, amma oldu 94%;
• alış ssenarilərində modelin demək olar həmişə create_checkout_session çağıracağını gözləyirik, amma loglarda “ötürmələrin” kəskin artdığını görürük.

Vacibdir: insident — bu “kimsə çatda şikayət etdi” deyil. Şikayət — trigger-dir, “bəli, bu insidentdir” qərarını isə SLO/SLI və dashboard-lara əsaslanaraq veririk.

2. SLO/SLI insidentlərə necə çevrilir

Observability modulunda artıq əsas metrikaları təyin etmisiniz: latency, availability, error-rate, checkout uğuru. İndi onları “qapıdakı mühafizəçilər” kimi istifadə edirik.

Ən sadə ssenari: bizdə checkout_success_rate üzrə SLO var. Hadisələri strukturlaşdırılmış şəkildə loglayırıq:

// MCP serverində checkout üçün log-hadisə nümunəsi
logger.info({
  event: 'checkout_result',
  request_id,
  user_id,
  checkout_session_id,
  status: 'success', // və ya 'failed'
  error_code: null,
});

Bu logların üzərindən metrika qurulur: son N dəqiqə/saat üçün bütün checkout_result arasında status = "success" payı. Bu pay həddən aşağı düşəndə (məsələn, 10 dəqiqə üçün 95%), monitorinq on-call kanala alert göndərir. Bu da insidentin deteksiyasıdır: SLI, SLO-nu aşdı.

Eyni qaydada alert-lər aşağıdakılara görə də işə düşə bilər:

• suggest_gifts, search_products alətlərinin error_rate artımına;
• p95/p99 latency artımına;
• workflow_completed sayının anomallıqla enməsinə (insanlar ssenarini sona çatdırmır);
• trafik artmadan LLM xərclərinin anormal yüksəlməsinə (iqtisadi insident).

Bunların hamısı yalnız ona görə mümkündür ki, biz strukturlu loglayırıq, “checkout yenə nəsə qaydasında deyil” kimi qeydlər yazmırıq. Metrikalar və alert-lər qurulduqda, nəsə səhv getdiyini görməyi öyrənirik. Növbəti sual: deteksiyadan sonra nə baş verir, kim və necə reaksiya verir?

3. İnsidentin həyat dövrü: deteksiyadan post-mortem-ə

Daimi “yanğın” rejimində yaşamamaq üçün insidentin standart pipeline-ını təsvir etmək rahatdır. Bir çox SRE komandası bunu belə bir zəncir kimi formallaşdırır:

flowchart TD
    D["Detection (aşkarlanma)"] --> T["Triage (qiymətləndirmə)"]
    T --> M["Mitigation (təsirin tez azaldılması)"]
    M --> R["Resolution (yekun düzəliş)"]
    R --> P["Post-mortem (analiz və təkmilləşdirmə)"]

GiftGenius nümunəsində mərhələləri izah edək.

Detection — hər şeyin pis olduğunu necə anlamaq

Problemin təyini avtomatik və əl ilə ola bilər.

Avtomatik — SLO/SLI üzrə monitorinqdən gələn alert-lərdir:

• PagerDuty / Opsgenie / e-poçt / Slack-bot qışqırır: SEV-1: checkout_success_rate < 60% son 10 dəqiqədə;
• latency üzrə alert: p95(suggest_gifts) > 10 sek;
• xərc üzrə anomaliya: “LLM xərcləri eyni workflow_completed sayında 2 dəfə artdı”.

Əl ilə deteksiya — dəstəyə (və ya sizə birbaşa Telegram-da) “ödəniş keçmir”, “vidcet sonsuz fırlanır” kimi müraciət seli gələndə. Bəzən məhz bu, monitorinq yetişməmişdən problemi işıqlandırır.

Praktik nəticə: hələ ideal monitorinqiniz olmasa belə, istifadəçilərin hər kütləvi şikayətinə metrikalar prizmasından baxmağa vərdiş edin: “bunun arxasında hansı metrika dayanır və onu necə ölçmək olar?”.

Triage — təsnifat və prioritetləndirmə

Deteksiyadan sonra iki sualın cavabı lazımdır: nə qədər pisdir və kim düzəldəcək.

Sadə ciddilik şkalası saxlamaq rahatdır:

• SEV-1: kritik — istifadəçilər ala bilmir, App əsas ssenari üzrə işləmir (məsələn, canlı trafildə checkout=0).
• SEV-2: ciddi, lakin deqradasiya ilə — istifadəçilərin bir hissəsi ssenarini bitirə bilmir, latency çox artıb, amma sıfıra düşməyib.
• SEV-3: kiçik bug-lar — əlavə tool-lardan biri bəzən düşür, yalnız edge-case pozulur.

GiftGenius üçün commerce-insidentlər demək olar həmişə SEV-1-dir: əgər pul hərəkət etmir, sizdə təkcə texniki problem deyil, gəlirə və etimada birbaşa zərər var.

Elə bu addımda on-call təyin olunur (və ya komanda bir nəfərdirsə siz özünüz) və qərar verilir: “Bəli, bu rəsmi SEV‑1 insidentidir, runbook N üzrə işləyirik” (runbook — qabaqcadan addım-addım yazılmış təlimatdır; strukturunu ayrıca bölmədə nəzərdən keçirəcəyik).

Mitigation — “qanaxmanı” dayandırmaq

Mitigation — kök səbəbi axtarmaq yox, istifadəçilərin əzabını azaltmaq üçün sürətli tədbirlərdir. Nümunələr:

• son MCP/Agents/ACP relizini geri qaytarmaq (rollback);
• problemli feature-flag-ı söndürmək;
• GiftGenius-u “yalnız-baxış” rejiminə keçirmək: tövsiyələri göstəririk, amma alışı rəsmiləşdirmirik;
• yükün müvəqqəti azaldılması (rate limiting) və ya ağır alətlərin söndürülməsi.

Bizim MCP-də “deqradasiya rejimi” üçün tipik kod nümunəsi:

// Psevdo-kod: sürətlə dəyişdirilə bilən qlobal bayraq
let checkoutDisabled = false;

export function setCheckoutDisabled(value: boolean) {
  checkoutDisabled = value;
}

export async function createCheckoutSession(args: CheckoutArgs) {
  if (checkoutDisabled) {
    // Modelə ödənişin müvəqqəti əlçatmaz olduğunu bildiririk
    return {
      error: 'checkout_temporarily_disabled',
      message: 'Ödəniş müvəqqəti əlçatmazdır, istifadəçiyə izah göstər.',
    };
  }

  // adi sessiya yaratma məntiqi
}

Feature-flag sistemində setCheckoutDisabled(true) çağırışını mitigation-ın bir hissəsi kimi edə bilərsiniz: istifadəçilər ən azı 500-lər və ilişən ödənişlər görməyəcək, dürüst mesaj görəcəklər.

Resolution — yekun düzəliş

“Qanaxma dayandırıldıqdan” sonra kök səbəbi tapmaq və düzəltmək üçün vaxtınız olur:

• MCP/ACP kodunda bug;
• üçüncü tərəf provayderində problem (Stripe, ödəniş şlüzü);
• OpenAI API limitləri (429, yüklənmə);
• pozulmuş prompt və ya dəyişmiş model, hansı ki, artıq tool çağırmır.

Resolution adətən bunları əhatə edir:

• fix (patch/rollback/konfiq);
• staging-ə, sonra production-a deploy;
• bütün SLI/SLO-nun yoxlanması;
• flag-ların normal vəziyyətə qaytarılması.

Post-mortem — səhvlərdən öyrənirik

İnsidentdən sonra, xüsusən SEV‑1/SEV‑2 üçün post-mortem keçirilir: burada suallara dürüst cavab verdiyiniz sənəd:

• nə baş verdi (faktlar və zaman xətti ilə);
• bu necə fərq edildi;
• necə reaksiya verildi;
• nə yaxşı işlədı, nə işləmədi;
• təkrarlanmaması üçün hansı dəyişiklikləri edəcəksiniz.

Post-mortem günahkar axtarışı deyil, sistem və prosesin yaxşılaşdırılmasıdır. Onun əsasında runbook-lar, alert-lər, bəzən hətta arxitektura yenilənir.

4. Rollar və məsuliyyət: “tək döyüşçü” olsanız belə

Yuxarıda təsvir edilən insident pipeline-ının real həyatda işləməsi üçün, yanğın zamanı kimlərin hansı qərarlara cavabdeh olacağı barədə qabaqcadan razılaşmaq vacibdir. Komandanızı bir liftə sığdırmaq mümkün olsa belə, insidentlər zamanı rolları formallaşdırmaq məntiqlidir. Bu, xaosu azaldır.

Adətən aşağıdakılar ayrılır:

• On-call mühəndis — alert ilk öncə ona gəlir və stabilləşdirmə üzrə texniki qərarlar verir (rollback, feature-flags, müvəqqəti “stub”lar).
• Incident commander — prosesi aparan şəxs: zaman xəttini yazır, tapşırıqların prioriteti barədə qərarlar verir, komandanın ora-bura qaçmamasına nəzarət edir. Mikrokomandada bu, elə həmin on-call-dur, sadəcə başqa “rol”da.
• Kommunikasiya — istifadəçilər və biznes tərəfdaşları ilə əlaqəyə cavabdehdir: Slack mesajları, status səhifəsi, App interfeysində (vidcet/çat), ChatGPT mağazasında.
• Scribe — vacib addım və faktları qeyd edir, sonra bu konspekt əsasında post-mortem yazılır.

Bir nəfərlik komandada bütün dörd rol — sizsiniz, sadəcə şüurlu şəkildə rejim dəyişmək faydalıdır: “indi mühəndisəm və düzəldirəm”, “indi kommunikasiyadayam”, “indi zaman xəttini yazıram”.

5. Runbook: yaddaş yox, qayda

Runbook — konkret insident növündə nə etmək lazım olduğunu addım-addım təsvir edən sənəddir: hansı qrafiklərə baxmalı, hansı düymələri basmalı, nədən imtina etmək olar. O, improvizasiya payını və stress səviyyəsini ciddi azaldır.

Runbook-un strukturu

Adətən runbook aşağıdakılardan ibarət olur:

1. İnsidentin qısa təsviri və onun necə detekt edildiyi. Nümunə: “ACP checkout xətaları > 5% 5 dəqiqədə” və ya “>20% sorğu üçün Error talking to app”.
2. Scope — problemi kimlər yaşayır: bütün trafik, yalnız region, yalnız konkret tool.
3. Haraya baxmalı: dashboard linkləri (checkout üzrə SLO, MCP error-rate, tool_name = create_checkout_session üzrə loglar), MCP Inspector və s.
4. Tez mitigation addımları: “Stripe statusunu yoxlamaq”, “son ACP relizini geri qaytarmaq”, “alış olmadan tövsiyə rejimini aktivləşdirmək”.
5. Yekun araşdırma və fix addımları.
6. Nəticədə nəyi yeniləmək lazımdır: alert-lər, kod, sənədləşmə.

GiftGenius üçün mini-runbook nümunəsi (checkout düşür)

Ona kod-a daha yaxın olsun deyə strukturlaşdırılmış məlumat şəklində baxaq:

type Severity = 'SEV-1' | 'SEV-2' | 'SEV-3';

interface RunbookStep {
  title: string;
  description: string;
}

interface Runbook {
  id: string;
  title: string;
  severity: Severity;
  detection: string;
  steps: RunbookStep[];
}

export const checkoutFailureRunbook: Runbook = {
  id: 'rb-checkout-failure',
  title: 'GiftGenius-də checkout xətalarının artması',
  severity: 'SEV-1',
  detection: 'Alert: checkout_success_rate < 60% son 10 dəqiqədə',
  steps: [
    {
      title: 'Xarici statusları yoxla',
      description: 'Stripe və ACP backend status səhifəsini aç, qlobal outage olmadığından əmin ol.',
    },
    {
      title: 'Son relizləri yoxla',
      description: 'Son 30 dəqiqədə MCP/ACP deploy olub-olmadığını yoxla. Zəruridirsə, rollback et.',
    },
  ],
};

Real runbook-da daha çox addım əlavə edəcəksiniz: read-only feature-flag-ını aktivləşdirmək, vidcetdə banner göstərmək, post-mortem üçün loglar toplamaq.

Commerce-insidentdə vidcet üçün mətn nümunəsi

Runbook-da istifadəçi üçün mətni əvvəlcədən düşünmək faydalıdır. Məsələn, GiftGenius vidceti belə göstərə bilər:

“Hazırda ödənişlə bağlı müvəqqəti texniki problemlərimiz var. Bəyəndiyiniz hədiyyə ideyalarını yenə də saxlaya bilərsiniz, alışı bir az sonra tamamlayacağıq.”

Bu mətni sonra UI vəziyyətinə tikmək olar:

// Vidcet vəziyyəti üçün psevdo-kod
const [checkoutAvailable, setCheckoutAvailable] = useState(true);

if (!checkoutAvailable) {
  return (
    <Alert>
      Ödəniş müvəqqəti əlçatmazdır. Siz yenə də hədiyyə ideyalarına baxa və onları saxlaya bilərsiniz.
    </Alert>
  );
}

6. GiftGenius-da praktika: insidentlər ətrafında kod

Mövzu sırf təşkilati qalmasın deyə, insident menecmentinə birbaşa kömək edən bir neçə kod parçasına baxaq.

MCP/Backend üçün health-check endpoint

Ən sadə, lakin vacib alət — health-check-dir. Next.js 16-da onu route handler vasitəsilə etmək olar:

// app/api/health/route.ts
import { NextRequest, NextResponse } from 'next/server';

export function GET(_req: NextRequest) {
  // Bura DB, növbələr və s. yoxlamaları əlavə etmək olar
  return NextResponse.json({
    status: 'ok',
    mcp: 'healthy',
    timestamp: new Date().toISOString(),
  });
}

Monitorinq sistemi periodik olaraq /api/health soruşacaq. 200 OK əvəzinə timeout və ya 5xx gələrsə, bu, aydın Availability insidenti siqnalıdır (MCP işləmir).

Metrikalar üzrə insidentin klassifikasiyası

Analitik servis və ya admin backend skript tərəfində ciddiliyi müəyyən edən sadə məntiq saxlamaq olar:

type Severity = 'SEV-1' | 'SEV-2' | 'SEV-3';

interface IncidentContext {
  checkoutSuccessRate: number; // 0..1
  giftSearchErrorRate: number; // 0..1
  p95GiftSearchMs: number;
}

export function classifyIncident(ctx: IncidentContext): Severity | null {
  if (ctx.checkoutSuccessRate < 0.6) return 'SEV-1'; // pul hərəkət etmir
  if (ctx.giftSearchErrorRate > 0.3 || ctx.p95GiftSearchMs > 8000) return 'SEV-2';
  return null; // hələ insident deyil
}

Belə parça cron ilə işə salına və ya monitorinqdən trigger oluna bilər: SEV‑1 qaytarıldıqda sisteminizdə insident avtomatik yaradılır və on-call xəbərdarlığı gedir.

İnsidentin əsas hadisələrinin loglanması

İnsidentlər — yalnız metrikalar deyil, həm də hadisələrdir: insident nə vaxt yaradıldı, dəyişdi, bağlandı. Bunu ayrıca loglarda saxlamaq rahatdır.

function logIncidentEvent(event: {
  incidentId: string;
  type: 'created' | 'mitigated' | 'resolved';
  severity: Severity;
  requestId?: string;
  message: string;
}) {
  logger.warn({
    level: 'WARN',
    service: 'incident-manager',
    ...event,
    timestamp: new Date().toISOString(),
  });
}

Məsələn, GiftGenius üçün “read-only” rejim aktiv ediləndə:

setCheckoutDisabled(true);
logIncidentEvent({
  incidentId: 'inc-2025-11-21-001',
  type: 'mitigated',
  severity: 'SEV-1',
  message: 'Checkout disabled, app switched to recommendations-only mode',
});

Sonra bu hadisələri asanlıqla tapıb metrika zaman sıraları ilə tutuşdurmaq olur.

7. Əməliyyat təqvimi: “ura, hər şeyi düzəltdik”dən sonrakı həyat

İnsident menecment — yalnız yanğınsöndürmə deyil, həm də müntəzəm profilaktikadır. SRE praktikasında əməliyyat dövrü tez-tez əməliyyat təqvimi kimi təsvir edilir — SLO, xərclər və təhlükəsizliyin müntəzəm icmalları ilə.

Şərti olaraq aktivlikləri periodiklik üzrə bölmək olar.

Həftəlik

Həftədə bir dəfə (və ya iki həftədən bir) məntiqlidir:

• əsas SLO-lara baxmaq: latency, error-rate, checkout uğuru, kateqoriyalar üzrə insident payı;
• həftə ərzində öz-özünə “sönmüş” alert-lər olub-olmadığına baxmaq və hədləri sərtləşdirib-yumşaltmağı dəyərləndirmək;
• ən azı bir insidenti qısa təhlil etmək (SEV‑3 olsa belə) — bu, post-mortem “əzələsini” məşq etdirir.

Aylıq

Ayda bir dəfə yaxşı olar ki:

• xərclərə baxış keçirəsiniz (LLM, ACP/Stripe komissiyaları, infrastruktur) və onları gəlirlə tutuşdurasınız — modul 19-un 1–2 mövzusu ilə əlaqə;
• produkt metrikalara baxasınız: activation, retention, workflow_completed → checkout_success konversiyası — marketinq və böyümə modulu ilə əlaqə;
• təhlükəsizlik jurnallarını anomaliyalar üçün gözdən keçirəsiniz: qəribə login nümunələri, avtorizasiya xətaları, qeyri-adi sorğu sıçrayışları (təhlükəsizlik mövzusuna körpü).

Rüblük

Rübdə bir dəfə siz:

• sirləri rotasiya edirsiniz: OpenAI API açarları, Stripe, OAuth müştəriləri və s.;
• SLO-ların köhnəlib-köhnəlmədiyini yoxlayırsınız: bəlkə App böyüyüb və indi p95 2 saniyə əvəzinə 1 deyil — norma budur, yaxud əksinə, hədəfləri sərtləşdirə bilərsiniz;
• runbook-ları yenidən gözdən keçirirsiniz: yeni insident tipləri, yenilənmiş asılılıqlar (SDK, MCP-spec və s.).

Təqvimi sadəcə Wiki səhifəsi və ya GiftGenius repozitoriyasında README kimi aparmaq olar: əsas odur ki, “canlı” olsun və yenilənsin.

8. İnsidentlər, pul və məhsul: niyə commerce yanğını ən “isti”dir

Modul 19 ümumilikdə App-in iqtisadiyyatı və “əməliyyat həyatı” haqqındadır və burada insidentlər pulla sıx bağlıdır. Commerce insidentləri — checkout keçməyəndə, pullar bloklananda və ya iki dəfə silinəndə — adətən, məsələn, hədiyyə axtarışında təsadüfi timeout-dan daha yüksək prioritetdə olur.

Səbəblər sadədir:

• hazırkı anda birbaşa gəlir itkisi;
• etimad itkisi riski (pulu silinib mal verilməyən istifadəçi yəqin ki, geri qayıtmayacaq);
• potensial hüquqi və reputasiya nəticələri.

Buna görə GiftGenius insident kataloqunuzda commerce insidentlər açıq şəkildə SEV‑1 kimi qeyd olunmalı və reaksiya vaxtı üzrə sərt SLO-lar olmalıdır (məsələn, “on-call 15 dəqiqə ərzində reaksiya, 1 saat ərzində mitigation”).

İqtisadi anomaliyalar (məsələn, LLM xərci gəlir artmadan kəskin artıb) — bu da insidentdir, amma adətən SEV‑2 səviyyəsində: UX-i dərhal sındırmır, lakin vaxtında görməsəniz bütün marjanı “yeyə” bilər.

Produkt tərəfdən hər böyük insident — düşünmək üçün fürsətdir:

• workflow çoxmu mürəkkəbdir (bəlkə daha sadə — daha etibarlıdır);
• fallback ssenarisi əlavə etməyə dəyərmi: məsələn, MCP cavab vermirsə, model ən azı xarici məlumatlar olmadan məsləhətlər versin;
• problemləri gizlətmək əvəzinə, onları dürüst bildirəcək UX dəyişikliklərinə ehtiyac varmı.

9. Mini tapşırıqlar (özünüz üçün)

Mühazirə praktikum olmasa da, öz GiftGenius-unuzda həqiqətən aşağıdakı addımları etmək çox tövsiyə olunur:

1. Tək bir sənəddə ən azı iki runbook təsvir edin:
   • “Ödənişdə (checkout) kütləvi xətalar”;
   • “MCP cavab vermir / ChatGPT Error talking to app göstərir”.
2. Bir aylıq əməliyyat təqvimi tərtib edin:
   • həftəlik hansı SLO-lara baxacaqsınız;
   • ay sonunda hansı xərc icmalını edəcəksiniz;
   • hansı təhlükəsizlik yoxlamalarını daxil edəcəksiniz (heç olmasa əsasları).

Bu, bir neçə saatınızı alacaq, amma tətbiqinizə baxışınızı ciddi dəyişəcək: o, sadəcə kod olmaqdan çıxacaq və canlı servisə çevriləcək.

ChatGPT Apps-da insident menecmentində tipik səhvlər

Səhv №1: “İnsident yalnız hər şey düşəndədir”
Bir çoxu vərdişcə yalnız MCP və ya bazanın tam düşməsini insident sayır. AI‑Apps-da tez-tez daha ağrılısı “yumşaq” keyfiyyət insidentləridir: model lazım olan tool-u çağırmağı dayandırıb, checkout-flow dolaşıqlaşıb, istifadəçilər sona çatmır, baxmayaraq ki, HTTP metrikaları yaşıl görünür. Belə vəziyyətləri insident saymır və təhlil etmirsinizsə, App-in keyfiyyəti səssiz-səmirsiz deqradasiyaya uğrayacaq.

Səhv №2: Dəqiq SLO-ların və “normal iş” sərhədlərinin olmaması
Formal SLO-suz istənilən insident mübahisəsi “məncə hər şey yavaşdır” vs “məndə lokalda sürətlidir” mübahisəsinə çevrilir. Məhz buna görə SLO-lar insident menecmentinin bazası sayılır: problemi obyektivləşdirirlər.

Səhv №3: Runbook-lar əvəzinə improvizasiya
Yayılan mənzərə: alert, hər kəs panikada prod-a atılır, kimsə relizi geri qaytarır, kimsə konfiqləri düzəldir, bir saatdan sonra “deyəsən, düzəldi”, amma heç kim nəyin kömək etdiyini xatırlamır. Runbook-suz hər insident kiçik xaosdur və komanda öyrənmir. Checkout insidenti üzrə tək bir sadə runbook belə stress səviyyəsini ciddi azaldır.

Səhv №4: İstifadəçilərlə kommunikasiya ignor edilir
Bəzən mühəndislər sistemi səssizcə düzəldirlər, istifadəçilər isə bu vaxt yalnız “spinner” və “nəsə səhv oldu” xətasını görürlər. Commerce ssenarilərində bu xüsusilə toksikdir: insanlar pulları üçün narahat olur. Vidcet, App təsviri və lazım gəldikdə xarici kanallar üçün mesaj şablonlarını qabaqcadan hazırlamaq vacibdir ki, problemi və gözlənilən düzəliş vaxtını dürüst bildirmək mümkün olsun.

Səhv №5: Öz hissənizi araşdırmadan “günah OpenAI-dır” demək
Hər şeyi “OpenAI zəif işləyir”ə yazmaq asandır, amma təcrübə göstərir ki, upstream problemlərində belə öz tərəfinizdə çox şey etmək olar: timeout və xətaları düzgün işləmək, MCP-siz rejimə keçmək, təkrarlanan cəhdlərin sayını azaltmaq ki, vəziyyəti ağırlaşdırmayasınız. “Shared responsibility” konsepsiyası, zəncirin sizin hissəsinə cavabdeh olduğunuzu nəzərdə tutur, hətta provayderlərdən biri stabil olmasa belə.

Səhv №6: Post-mortem və əməliyyat dövrünün olmaması
İnsident “yaxşı, yəqin ki, hər şey qaydasındadır, davam edək” cümləsi ilə bitir və heç bir sənəd, alert və kod dəyişmirsə — sistem eyni səhvləri təkrarlamağa məhkumdur. Post-mortemlər, SLO, xərclər və təhlükəsizliyin müntəzəm icmalları — bu, bürokratiya deyil, gələcək siz və komandanızla razılaşma yoludur ki, bir ildən sonra GiftGenius daha etibarlı, yoxsa daha kövrək olmasın.