Dastur ishlab chiqishda prodakshn yonmoqda — bu nima, sabablari va harakat algoritmi

"Prodakshn yonmoqda" nimani anglatadi va qanday nosozliklar bor

"Prodakshn yonmoqda" (production is on fire, everything is down) iborasi prodakshn muhiti noto'g'ri ishlayotgan va bu foydalanuvchilarga ta'sir qilgan vaziyatni tavsiflaydi. Nosozlik dasturning to'liq mavjud emasligi (blank screen, 502 xatosi), qisman mavjud emasligi (to'lov moduli ishlamaydi, ammo boshqa funksiyalar mavjud) yoki unumdorlikning pasayishi (juda uzoq yuklash) sifatida namoyon bo'lishi mumkin. Insidentning severity ta'sirlangan foydalanuvchilar foizi va nosozlik davomiyligi bilan aniqlanadi.

Atlassian Statuspage (2025) ma'lumotlariga ko'ra, 2024-yilda mobil ilovalar uchun o'rtacha downtime har bir insident uchun 27 daqiqani tashkil etdi. Eng keng tarqalgan sabablar: deploydan keyin kod regressiyasi (34%), bulut provayderining ishdan chiqishi (22%), ma'lumotlar bazasi muammolari (18%), konfiguratsiya xatolari (15%) va DDoS hujumlari (11%). Asosiy xulosa: nosozliklarning aksariyati jamoaning o'zi kiritgan o'zgarishlar bilan bog'liq, tashqi omillar bilan emas.

Crash (dasturning mijoz tomonida qulashi) va backend outage (serverning mavjud emasligi) o'rtasida farq qilish muhimdir. Crash odatda mijoz kodining hotfixi bilan, backend outage esa infratuzilma o'zgarishlari yoki servisni redeploy qilish orqali tuzatiladi. Kuzatish metrikalari: mijoz uchun — crash-free rate, server uchun — error rate 5xx va p95 latency. APM (Application Performance Monitoring) — Sentry, New Relic, Datadog — nosozlik turini tez aniqlashga yordam beradi.

Insidentlarning severity darajalari: P0, P1, P2 va tasniflash mezonlari

Yagona severity tasnifi tezkor reaksiyaning asosidir. Usiz jamoa "bu qanchalik shoshilinch" muhokamasiga vaqt sarflaydi, harakat qilish o'rniga. Klassik shkala: P0 (critical) — dastur to'liq mavjud emas yoki foydalanuvchi ma'lumotlari sizmoqda, reaksiya vaqti — darhol; P1 (high) — kritik funksionallik 50%+ foydalanuvchilarda ishlamaydi, reaksiya vaqti — 15 daqiqa; P2 (medium) — kritik bo'lmagan funksionallik foydalanuvchilarning bir qismida mavjud emas, reaksiya vaqti — 1 soat.

P0 zudlik bilan eskalatsiyani talab qiladi: navbatchi muhandis har qanday joriy ishni to'xtatadi va insidentga o'tadi. Agar 10 daqiqadan so'ng muammo hal qilinmasa — tech lead qo'shiladi. Agar 30 daqiqadan so'ng — engineering manager'ga eskalatsiya. P0 insidentlari uchun har qanday jarayonlarni buzishga ruxsat beriladi: to'liq code reviewsiz hotfix, to'g'ridan-to'g'ri prodakshnga deploy, branch protection qoidalarini e'tiborsiz qoldirish. Emergency override oldindan jamoa darajasida kelishilgan bo'lishi kerak.

Severity jadvali

Severity ni pastga tushirishda xato qilmaslik juda muhim. P2 sifatida tasniflangan P0 + P1 kechikkan reaksiyaga va downtime oshishiga olib keladi. Qoida: shubhangiz bo'lsa — P0 qo'ying. Over-classification under-classification'dan yaxshiroq: ortiqcha uchrashuv yig'ish, bir soatlik tiklanish vaqtini yo'qotishdan yaxshiroq.

Dastlabki 10 daqiqa: nosozlikdagi harakat algoritmi

Timer starts: alert yoki foydalanuvchidan xabar kelgan paytdan boshlab. Dastlabki 10 daqiqa — eng muhimi. Algoritm: 1) confirm the issue — muammo haqiqiy ekanligiga ishonch hosil qiling (soxta alarm emas); 2) stop the bleeding — darhol impactni kamaytiring (rollback, feature toggle, endpointni bloklash); 3) communicate — umumiy #incident kanaliga status yozing: nima bo'ldi, severity, nima qilinmoqda. Dastlabki 10 daqiqa asosiy sabab tahliliga sarflanmaydi.

Qon ketishini to'xtatish bilan parallel ravishda bir muhandis diagnostikani boshlaydi, ikkinchisi — kommunikatsiyani. Kommunikatsiya kanallari: Slack #incident kanali (jamoa uchun), status sahifasi (foydalanuvchilar uchun), email/SMS eskalatsiyasi (rahbariyat uchun). Har 15 daqiqada — status yangilanishi: nima ma'lum, nima qilinmoqda, tiklanish ETA si. Status page (StatuPage, Statuspal) tashqi foydalanuvchilar uchun uptime va insidentlar tarixini ko'rsatadi.

Qon ketishini qanday to'xtatish: rollback, feature toggle va hotfix

Birinchi va eng muhim qoida: prodakshnda muammoni tuzatishga urinmang. Agar yangi reliz nosozlikka sabab bo'lgan bo'lsa — oldingi barqaror versiyaga rollback qiling. Agar nosozlik feature toggle bilan o'chirilgan ma'lum bir funksiyadan kelib chiqqan bo'lsa — shunchaki toggle ni o'chiring. Agar na rollback, na toggle mavjud bo'lmasa — minimal diff bilan hotfix. Rollback — eng xavfsiz variant, chunki biz allaqachon ishlagan holatga qaytamiz.

Feature toggle (aka feature flag) — deploy qilmasdan stop-the-bleeding uchun kuchli vosita. Agar to'lov moduli qulagan bo'lsa, lekin toggle orqali o'chirilgan bo'lsa — foydalanuvchilar shunchaki to'lov tugmasini ko'rmaydilar, xato ekranini olmaydilar. Toggle build yaratishni talab qilmaydi, do'kon review ni talab qilmaydi, soniyalar ichida ishlaydi. Har bir kritik funksiya server darajasida o'chirish imkoniyatiga ega feature toggle (remote config) ostida bo'lishi kerak. Feature flag — birinchi himoya chizig'i.

Agar rollback imkonsiz bo'lsa (masalan, qaytarib bo'lmaydigan BM migratsiyasi tufayli) va toggle nazarda tutilmagan bo'lsa — oxirgi vosita: minimal tuzatish bilan hotfix. Hotfix oxirgi release tegidan yaratiladi, faqat nosozlikni bartaraf etish uchun zarur satrlarni o'z ichiga oladi va fast-track deploy dan o'tadi ("Hotfix — shoshilinch tuzatishlar" maqolasiga qarang). Golden rule: barqarorlashtirishdan so'ng, har doim root cause analysis qiling, hatto sabab aniq ko'rinadigan bo'lsa ham.

Sabablarni diagnostika qilish: loglar, metrikalar va alarmlar

Qon ketishini to'xtatgandan so'ng (yoki parallel ravishda, muhandislar soni imkon bersa) diagnostika boshlanadi. Birinchi manba — loglar. Markazlashtirilgan loglash (ELK, Grafana Loki, Datadog Logs) timestamp, foydalanuvchi ID si yoki so'rov ID si bo'yicha xatoni topishga imkon beradi. Muhim: loglar tuzilgan (JSON) bo'lishi kerak, shunda grep tez ishlaydi. Structured logging — barcha servislar uchun majburiy talab.

Ikkinchi manba — metrikalar. Grafana, Datadog, New Relic xatolar qachon cho'qqiga chiqqanini, qaysi endpointlarda, qanday status kodlari bilan ko'rsatadi. Deploydan oldin va keyin metrikalarni solishtirish muammoni ma'lum bir servis yoki endpointgacha lokalizatsiya qilishga yordam beradi. RED metrics (Rate, Errors, Duration) — mikroservislarni monitoring qilish standarti.

Uchinchi manba — distributed tracing. Jaeger, Zipkin, Datadog APM so'rovning mikroservislar orqali yo'lini ko'rsatadi va kechikish yoki xato qayerda sodir bo'lganligini aniqlaydi. Tracing ayniqsa kaskadli nosozliklarda foydali, bir servisdagi xato barcha bog'liq servislarda xatolarga sabab bo'lganda. Trace ID mijozdan barcha backend servislariga uzatilishi kerak.

# kubectl va loglar yordamida tezkor diagnostika namunasi
# Xatosi bor podlarni ro'yxatga olish
kubectl get pods --field-selector=status.phase!=Running

# Qulagan podning loglarini tekshirish
kubectl logs --previous pod/auth-service-7f4b9c5d6-abc12

# Oxirgi 30 daqiqa davomida servisdagi xatolarni qidirish
kubectl logs deployment/api-gateway --since=30m
  | grep "5[0-9][0-9]" | head -50

Muhim: qon ketishini to'xtatmasdan sababni diagnostika qilishga urinmang. Foydalanuvchilarning 50% crash ko'rsa — avval rollback, keyin tahlil. Istisno: agar rollback to'g'ridan-to'g'ri hotfixdan ko'proq vaqt olsa (masalan, ma'lumotlar mos kelmasligi holatida). Bu holda hotfix darhol qo'llaniladi, post-mortem esa barqarorlashtirishdan so'ng o'tkaziladi. Diagnosis before fix — downtime ni oshiradigan xavfli naqsh.

Post-mortem: aybdor qidirmasdan insidentlarni qanday tahlil qilish

Post-mortem (shuningdek incident review deb ataladi) — insident hal qilinganidan 24-72 soat o'tgach o'tkaziladigan tuzilgan tahlil. Maqsad: nima uchun nosozlik sodir bo'lganini, nima uchun monitoring va testlar uni prodakshngacha tutmaganini va takrorlanishni oldini olish uchun jarayonlarda nimani o'zgartirishni tushunish. Blameless culture — asosiy prinsip: post-mortem jarayonlar, vositalar va kommunikatsiyani muhokama qiladi, aniq odamlarning xatolarini emas.

Post-mortem hujjatining tuzilishi: timeline (timestamp lar bilan voqealar xronologiyasi), impact (ta'sirlangan foydalanuvchilar, davomiylik, moliyaviy yo'qotishlar), root cause (texnik asosiy sabab), detection (qanday aniqlangan, nima uchun oldin tutilmagan), response (nima qilingan, nimani tezroq qilish mumkin edi), action items (mas'ul shaxslar va muddatlar bilan aniq vazifalar). Action items S.M.A.R.T. bo'lishi kerak: specific, measurable, assignable, realistic, time-bound.

Prodakshn nosozligidan keyin odatiy action items: jim bo'lgan metrikaga monitoring va alert qo'shish; o'tkazib yuborilgan holat uchun test qamrovini kengaytirish; shunga o'xshash vaziyat uchun bosqichma-bosqich algoritm bilan runbookga sahifa qo'shish; noto'g'ri ishlatilgan vosita bo'yicha jamoa trainingini o'tkazish. Har bir action item insidentni takrorlanish ehtimolini kamaytiradigan aniq o'zgarishdir.