Deploydan keyin: log va monitoring

Sayt hostingga chiqdi — lekin ish shu bilan tugamaydi. Boshlovchilar deployni finish chizig’i deb o’ylashadi. Amalda esa u start chizig’i: shu paytdan boshlab kod haqiqiy foydalanuvchilar, haqiqiy ma’lumot va haqiqiy tarmoq sharoitida ishlaydi.

Bu darsda deploydan keyingi to’rt masalani ko’ramiz: sozlamalarni xavfsiz saqlash, nima bo’layotganini ko’rish, muammoni sezish va xato chiqqanda tez qaytish.

Muhitlar va sozlamalar

Muhitlar orasidagi farq

Jiddiy loyihada odatda uch muhit bo’ladi:

Muhit	Kim ishlatadi	Ma’lumot
Development	Dasturchining kompyuteri	Sinov ma’lumoti
Staging	Jamoa, testerlar	Productionga o’xshash nusxa
Production	Haqiqiy foydalanuvchilar	Haqiqiy ma’lumot

Staging muhitining maqsadi — o’zgarishni haqiqiy foydalanuvchiga yetkazishdan oldin productionga yaqin sharoitda sinash. Kichik loyihada staging bo’lmasligi mumkin, lekin unda “mening kompyuterimda ishlagandi” muammosi tez-tez uchraydi.

Environment variable — sozlama koddan tashqarida

Baza manzili, API kaliti va boshqa maxfiy qiymatlar hech qachon kodda yozilmaydi. Buning ikki sababi bor: birinchidan, kod Git tarixiga tushadi va u yerdan o’chirish qiyin; ikkinchidan, har muhitda qiymat boshqacha bo’ladi.

Yechim — bu qiymatlarni muhitning o’zidan olish:

DATABASE_URL=postgres://...
API_KEY=...
NODE_ENV=production

Loyihada .env fayli .gitignore ga qo’shiladi, uning o’rniga .env.example saqlanadi — u yerda faqat nomlar bo’ladi, qiymatlarsiz. Shunda yangi dasturchi qaysi sozlamalar kerakligini biladi, lekin maxfiy qiymatlarni ko’rmaydi.

Productionda esa bu qiymatlar hosting panelidagi secret sozlamalarida turadi.

Log — o’tmishni ko’rish

Log — ilova nima qilganini yozib boradigan yozuv. Foydalanuvchi “sayt ishlamadi” desa, log sizga aynan nima bo’lganini aytadi.

Yaxshi log yozuvida to’rt narsa bo’ladi:

Element	Nima uchun
Vaqt	Muammo qachon boshlanganini topish
Daraja (info, warn, error)	Muhimini ajratish
Kontekst (route, so’rov ID)	Qaysi amal bilan bog’liq
Xabar	Nima sodir bo’ldi

So’rov identifikatori ayniqsa foydali: bitta so’rovga tegishli barcha yozuvlarni bir joyga to’plash imkonini beradi.

Va eng muhim qoida: logga maxfiy ma’lumot yozmang. Parol, token, session qiymati va shaxsiy ma’lumot logda qolsa, u endi log tizimini ko’ra oladigan har kimga ochiq.

Monitoring — hozirni ko’rish

Log o’tmishni ko’rsatadi, monitoring esa hozirgi holatni. Ular bir-birini almashtirmaydi.

Kichik loyiha uchun to’rt ko’rsatkich yetarli:

• Uptime — sayt umuman ochilyaptimi (tashqi xizmat har bir necha daqiqada tekshiradi).
• Xato foizi — so’rovlarning necha foizi 5xx qaytaryapti.
• Javob tezligi — o’rtacha emas, p95 qarang: foydalanuvchilarning eng sekin 5 foizi qanday tajriba olmoqda.
• Resurs sarfi — xotira va disk to’lib qolmayaptimi.

O’rtacha qiymatga ishonmaslik muhim. Yuzta so’rovning to’qsonta tez, o’ntasi juda sekin bo’lsa, o’rtacha yaxshi ko’rinadi — lekin har o’ninchi foydalanuvchi noqulaylik sezadi.

Backup va rollback

Bu ikkisi bir-biriga o’xshash tuyuladi, lekin turli muammoni hal qiladi:

• Backup — ma’lumot yo’qolsa tiklash uchun.
• Rollback — kod buzilsa avvalgi versiyaga qaytish uchun.

Backupning eng muhim qoidasi shundaki, sinalmagan zaxira — zaxira emas. Faylni saqlab qo’yish yetarli emas; uni haqiqatan tiklash mumkinligini kamida bir marta amalda tekshirish kerak.

Rollback esa tez bo’lishi kerak. Ko’p hosting platformalarida bu bir tugma: avvalgi build qaytariladi. Lekin bitta muhim ogohlantirish bor — agar yangi versiya ma’lumotlar bazasi tuzilmasini o’zgartirgan bo’lsa, faqat kodni qaytarish yetarli emas. Shuning uchun baza o’zgarishlari orqaga mos qilib rejalashtiriladi: avval yangi ustun qo’shiladi, eskisi esa bir muddat saqlanadi.

Xatolar foydalanuvchiga qanday ko’rinadi

Texnik tomon tayyor bo’lsa ham, xato paytida foydalanuvchi nima ko’rishi alohida qaror talab qiladi. Bu yerda ikki auditoriya bor va ularga ikki xil ma’lumot kerak.

Dasturchiga batafsil kontekst kerak: qaysi funksiya, qaysi qator, qanday qiymat bilan. Foydalanuvchiga esa qisqa, tushunarli va xavfsiz xabar kerak. Database connection refused yoki to’liq stack trace ko’rsatish ikki xato: u foydalanuvchiga yordam bermaydi va tizim ichki tuzilishini oshkor qiladi.

Yaxshi xato sahifasi uch narsani beradi: nima bo’lgani, foydalanuvchi endi nima qilishi mumkinligi va murojaat uchun so’rov identifikatori. Oxirgisi ayniqsa qimmatli — foydalanuvchi shu raqamni aytsa, siz logdan aynan o’sha holatni topasiz.

Shuningdek, 404 va 500 sahifalarini oldindan tayyorlang. Ular sayt dizaynida bo’lsin va bosh sahifaga qaytish havolasi bo’lsin; hostingning odatiy oq sahifasi foydalanuvchida sayt butunlay ishlamayotgandek taassurot qoldiradi.

Release jarayoni

Sog’lom release oqimi

branch → pull request → check/test → review → deploy → smoke test → monitoring

Smoke test — deploydan keyin eng muhim yo’llarni tez tekshirish: bosh sahifa ochilishi, login, asosiy forma, API va xato holati. Bu to’liq E2E test o’rnini bosmaydi, ammo eng og’ir nosozlikni bir necha daqiqada ushlaydi.

Chiqarish vaqtini ham o’ylang. Juma kuni kechqurun deploy qilish keng tarqalgan xato: muammo chiqsa, uni tuzatadigan odam bo’lmasligi mumkin.

Kichik qadamlar xavfni kamaytiradi

Deployning eng xavfli turi — uzoq vaqt yig’ilgan katta o’zgarishni bir yo’la chiqarish. Muammo chiqsa, uni yuzlab o’zgarish ichidan izlash kerak bo’ladi.

Teskari yondashuv ancha xavfsiz: kichik, tez-tez deploy. Har chiqarish oz narsani o’zgartiradi, shuning uchun xato sababi darhol ma’lum bo’ladi va rollback ham oson kechadi. Bu odat ko’p tajribali jamoalarda asosiy qoidaga aylangan.

Katta funksiyani xavfsiz chiqarish uchun feature flag ishlatiladi: kod serverga chiqadi, lekin sozlama orqali yopiq turadi. Keyin uni avval o’zingiz, so’ng kichik guruh, oxirida hamma uchun ochasiz. Muammo sezilsa, yangi deploy kutmasdan sozlamani o’chirib qo’yish kifoya.

Chiqarish checklisti

1. Environment variable: maxfiy qiymatlar kodda yoki Gitda emas, hostingning secret sozlamasida.
2. Build va test: pull requestda test, type check va production build o’tadi.
3. Log: vaqt, route va xavfsiz kontekst yoziladi; maxfiy ma’lumot yo’q.
4. Monitoring: uptime, xato foizi va sekin so’rovlar kuzatiladi.
5. Backup: zaxira qachon olinadi, qayerda saqlanadi va tiklash sinalganmi.
6. Rollback: avvalgi versiyaga qaytish qadami oldindan sinovdan o’tgan.
7. Smoke test: deploydan keyin asosiy yo’llar qo’lda tekshiriladi.

Xato bo’lganda ayblov emas, sabab

Jiddiy nosozlikdan keyin jamoalar qisqa tahlil yozadi: nima bo’ldi, qachon sezildi, qanday tuzatildi va bunday holat qaytmasligi uchun nima o’zgaradi.

Bu hujjatning asosiy qoidasi — kimni ayblash emas, tizimdagi bo’shliqni topish. Agar bitta noto’g’ri buyruq butun bazani o’chira olgan bo’lsa, muammo buyruqni yozgan odamda emas, bunga imkon bergan jarayonda. Yechim ham shunga mos bo’ladi: ruxsatlarni cheklash, tasdiqlash qadami qo’shish yoki zaxirani avtomatlashtirish.

Yolg’iz ishlayotgan bo’lsangiz ham shu odatni saqlang. Bir necha oydan keyin o’sha qaydlar bir xil xatoni takrorlashdan saqlaydi.

Amaliy mashq

O’zingizning kichik loyihangiz uchun bir sahifalik “operatsion qayd” yozing. Unda to’rt savolga javob bo’lsin: sayt ishlamay qolsa buni qanday bilaman, oxirgi ishlaydigan versiyaga qanday qaytaman, ma’lumot zaxirasi qayerda va uni oxirgi marta qachon tiklab ko’rganman?

Bu qayd bir varaqdan oshmasin, lekin muammo chiqqan paytda uni izlab yurmaydigan joyda tursin.

Qisqacha xulosa

• Deploy — yakun emas, ishlayotgan tizimni kuzatish boshlanadigan nuqta.
• Maxfiy qiymatlar koddan tashqarida, hosting secret sozlamasida turadi.
• Log o’tmishni, monitoring hozirni ko’rsatadi — ikkalasi ham kerak.
• Tezlikni o’rtacha emas, p95 bilan o’lchang.
• Backup ma’lumot uchun, rollback kod uchun; ikkalasi ham sinalgan bo’lsin.
• Deploydan keyin smoke test — eng arzon va eng foydali odat.

Keyingi darsda PWA va offline ishlash — web ilovaning tarmoq bo’lmaganda ham foydali bo’lishi mumkinligini ko’ramiz.