Transport IT tizimlarida yuklama va barqarorlik: nima birinchi buziladi va buni qanday oldini olish mumkin

Nega transport IT tizimlari aynan pik vaqtida buziladi

Transport IT tizimlari tasodifan ishdan chiqmaydi. Ular eng yuqori yuklama vaqtida buziladi — aynan biznes ularga eng ko'p bog'liq bo'lgan paytda. Ertalabki va kechki "tig'iz" soatlar, bayram oldidan chipta sotuvining cho'qqisi, ob-havo keskin o'zgargan kunlardagi buyurtmalar to'lqini — bularning barchasi yuk grafigida o'tkir cho'qqilarni hosil qiladi. Aynan shu paytda kunlik test paytida ko'rinmagan arxitektura xatolari yuzaga chiqadi.

Sabab oddiy: kam yuklamada deyarli har qanday tizim ishlaydi. Bitta dispetcher, o'nlab haydovchi, sekundiga bir necha so'rov — bunday sharoitda noto'g'ri qurilgan arxitektura ham "yetib boradi". Muammo yuklama o'n yoki yuz barobar oshganda boshlanadi: navbatlar to'lib ketadi, ulanishlar tugaydi, kechikishlar tarqaladi va bitta sekin komponent butun zanjirni to'xtatadi. Shuning uchun barqarorlikni baholashning to'g'ri savoli "ishlayaptimi?" emas, balki "pik 3 baravar oshganda nima birinchi buziladi?".

Birinchi bo'lib nima buziladi: zaif nuqtalar ketma-ketligi

Yuklama oshganda komponentlar tasodifiy emas, balki taxmin qilinadigan tartibda yiqiladi. Bu tartibni bilish loyihalashning yarmi hisoblanadi. Amaliyotda transport tizimlarida quyidagi zanjir takrorlanadi:

• Ma'lumotlar bazasiga ulanishlar puli (connection pool). Ko'pincha birinchi bo'lib aynan u tugaydi. Har bir so'rov ulanishni band qiladi, sekin so'rovlar ularni ushlab turadi, yangi so'rovlar navbatda qotadi. Foydalanuvchi buni "ilova osilib qoldi" deb ko'radi.
• Sinxron tashqi chaqiruvlar. To'lov shlyuzi, SMS-gateway, xarita yoki geokodlash xizmati sekinlashsa, sizning tizimingiz ham xuddi shuncha sekinlashadi — chunki javobni kutib turibsiz.
• Real-time qatlam (WebSocket/MQTT). Haydovchi va mashinalarning joylashuvini uzatuvchi doimiy ulanishlar. Heartbeat (ping/pong) yo'q bo'lsa, "o'lik" ulanishlar timeout tugaguncha osilib turadi va ulanishlar limitini yeb qo'yadi.
• Navbatlar va fon ishlovchilar (workers). Bildirishnomalar, hisob-kitoblar, hisobotlar. Ular yetishmasa, navbat o'sib ketadi va ma'lumotlar real vaqtdan orqada qola boshlaydi.
• Disk va xotira. Loglarning portlashi, keshning shishishi, OOM (xotira tugashi) tufayli jarayonning o'lishi — pik paytda eng yomon vaqtda yuz beradi.

Yashirin arxitektura xatolari qayerda yashiringan

Eng xavfli muammolar — sezilmaydiganlari. Ular kichik yuklamada o'zini ko'rsatmaydi, lekin pikda butun tizimni qulatadi. Mana eng tez-tez uchraydiganlari.

N+1 so'rovlar. Ro'yxatni olish uchun bitta so'rov, keyin har bir element uchun yana bittadan so'rov. 20 ta buyurtmada bu sezilmaydi, 2000 ta buyurtmada esa ma'lumotlar bazasi ko'milib ketadi. Bu kodni ko'rib chiqishda eng ko'p uchraydigan, lekin oson tuzatiladigan kamchilik.

Sinxron arxitektura. Foydalanuvchi tugmani bosadi, tizim esa to'lov, SMS, push va hisobotni ketma-ket, javobni kutib bajaradi. To'g'ri yondashuv — kritik bo'lmagan ishlarni navbatga (queue) o'tkazish: foydalanuvchiga darhol javob berish, qolganini fonda bajarish.

Indekslarning yo'qligi. Geolokatsiya, sana oralig'i va status bo'yicha filtrlar — transport tizimlarining asosi. To'g'ri indekslar bo'lmasa, har bir filtr to'liq jadvalni skanerlashga aylanadi.

Idempotentlikning yo'qligi. Tarmoq uzilganda mijoz so'rovni qayta yuboradi. Agar tizim takror so'rovni ajrata olmasa — ikkita buyurtma, ikki marta to'lov, dublikat yozuvlar paydo bo'ladi. Pik paytida tarmoq uzilishlari ham ko'payadi, demak bu muammo aynan o'sha paytda kuchayadi.

Bitta nuqtali ishonchsizlik (single point of failure). Barcha trafik o'tadigan bitta proxy, bitta baza, bitta region. U yiqilsa — hamma narsa yiqiladi. Pik yuklama esa aynan eng zaif bo'g'inni sinaydi.

Barqarorlikni qanday loyihalashtirish kerak

Barqarorlik — bu keyin "qo'shib qo'yiladigan" xususiyat emas, balki arxitektura qarori. U loyihaning boshida shakllanadi. Asosiy tamoyillar:

• Gorizontal masshtablanish. Tizim bitta kuchli serverni emas, balki bir nechta oddiy nusxani qo'shish orqali o'sishi kerak. Buning uchun ilova "stateless" bo'lishi — holatni xotirada emas, balki umumiy bazada yoki keshda saqlashi zarur.
• Backpressure va rate limiting. Tizim qabul qila olmaydigan yukni xushmuomalalik bilan rad eta olishi kerak. To'liq qulashdan ko'ra, ortiqcha so'rovlarni cheklash yoki navbatga qo'yish yaxshiroq.
• Circuit breaker. Tashqi xizmat yiqilganda, unga so'rov yuborishni vaqtincha to'xtatish kerak — aks holda kutishlar butun tizimni bloklaydi.
• Timeout va retry siyosati. Har bir tashqi chaqiruvda timeout bo'lishi shart. Retry esa "exponential backoff" bilan bo'lishi kerak, aks holda qayta urinishlar to'lqini xizmatni yanada ko'mib qo'yadi.
• Keshlash. Tez-tez so'raladigan va kam o'zgaradigan ma'lumotlar (marshrutlar, tariflar, ma'lumotnomalar) keshda bo'lishi, har safar bazaga bormasligi kerak.
• Graceful degradation. Ikkilamchi funksiya (masalan, hisobot yoki tahlil) ishlamay qolsa ham, asosiy funksiya (buyurtma, joylashuvni kuzatish) ishlashda davom etishi kerak.

Monitoring: muammoni mijozdan oldin ko'rish

Eng ko'p uchraydigan stsenariy — biznes nosozlik haqida mijozlarning shikoyatidan biladi. Bu juda kech. Yaxshi qurilgan tizimda monitoring muammoni foydalanuvchidan oldin aniqlaydi. Buning uchun shunchaki "server tirikmi?" emas, balki ma'noli metrikalarni kuzatish kerak:

• So'rovlarning kechikishi (latency) — o'rtacha emas, balki p95 va p99 protsentillar bo'yicha; aynan ular pikni ko'rsatadi.
• Xatolar foizi (error rate) va ularning kelib chiqish nuqtasi.
• Ma'lumotlar bazasiga ulanishlar puli to'ldirilganligi va sekin so'rovlar jurnali.
• Navbatlar uzunligi va fon ishlovchilarning orqada qolishi (lag).
• Biznes-metrikalar: masalan, oxirgi N daqiqada qabul qilingan buyurtmalar soni nolga tushib qoldimi.

Muhim nuance: umumiy "tizim ishlayapti" ko'rsatkichi alohida oqimning to'liq o'lik holatini maskalashi mumkin. Shuning uchun har bir kritik oqim uchun alohida proba kerak. Bundan tashqari, ogohlantirishlar (alert) avtomatik bo'lishi — kechasi yoki dam olish kunida ham xabar bermasa, monitoringning foydasi yo'q.