# Deploydan keyin: log va monitoring

> Web ilovani deploy qilishdan keyingi muhim amallarni o'rganing: environment variable, loglar, monitoring, backup, rollback va chiqarish checklisti.

Manba: https://learncode.uz/web-dasturlash/deploy-operatsiyalar/
Sana: 2026-05-13

![Deploydan keyingi environment sozlamalari, log, monitoring, backup va rollback jarayonlari sxemasi](https://learncode.uz/images/web-dasturlash/deploy-operatsiyalar-hero.webp)

*Deploy yakun emas: ishlayotgan ilovani kuzatish, himoyalash va kerak bo'lsa tez qaytarish ham mahsulot sifatining qismidir.*

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.

> **Atama**
>
> **Deploy** — tayyor kodni foydalanuvchi ishlatadigan serverga chiqarish.
> **Release** — o'sha o'zgarishni foydalanuvchilarga ochish. Ular bir vaqtda ham,
> alohida ham bo'lishi mumkin: kod chiqarilgan, lekin funksiya hali yopiq turgan
> holat ham keng tarqalgan.

### 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:

```text
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.

> **Maxfiy qiymatni qaytarib bo'lmaydi**
>
> Token Git tarixiga tushib qolsa, uni faqat fayldan o'chirish yetmaydi — tarix
> saqlanib qoladi. Darhol provider tomonda bekor qilib, yangisini yarating;
> keyin tarixni tozalash zarurligini baholang. Tartib aynan shunday: avval
> bekor qiling, keyin tozalang.

### 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.

![Ishlash vaqti, xato foizi, javob tezligi va resurs sarfini ko'rsatadigan monitoring paneli](https://learncode.uz/images/web-dasturlash/monitoring-korsatkichlari.webp)

*To'rt asosiy ko'rsatkich muammoni foydalanuvchi shikoyat qilishidan
    oldin sezish imkonini beradi.*

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

```text
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](https://learncode.uz/web-dasturlash/web-testing) 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](https://learncode.uz/web-dasturlash/pwa-offline) — web
ilovaning tarmoq bo'lmaganda ham foydali bo'lishi mumkinligini ko'ramiz.