Sayt yoki servis uchun ommaviy status sahifasini qanday yaratish
Amaliyot4 daqInnovialabs tahririyati
Qisqacha
Status sahifasi — alohida joylashtirilgan sahifa bo‘lib, unda servisning har bir qismi holati va insidentlar bo‘yicha yangiliklar ko‘rinadi; nosozlik paytida foydalanuvchilar qo‘llab-quvvatlashga emas, shu sahifaga qaraydi.
Status sahifasi nima beradi
Status sahifasi — odatda status.sizningdomen.uz manzilidagi ommaviy sahifa. Unda mahsulotning har bir qismi hozir ishlayaptimi va jamoa muammolar bilan nima qilayotgani ko‘rinadi.
Nosozlik paytida qo‘llab-quvvatlashga keladigan murojaatlarning ko‘pi bitta savol: «Bu hammada buzilganmi? Qachon tuzatiladi?» Status sahifasi bu savolga bir marta va hamma uchun javob beradi. Natijada:
- Muhandislar muammoni tuzatayotganda bir xil tiket va qo‘ng‘iroqlar kamayadi.
- Ishonch oshadi: foydalanuvchilar siz nosozlikni ular yozishidan oldin payqaganingizni ko‘radi.
- Sotuv va qo‘llab-quvvatlash bo‘limi tayanishi mumkin bo‘lgan insidentlar tarixi paydo bo‘ladi.
Sahifada nimani ko‘rsatish kerak
Sahifa texnik bilimi yo‘q mijozga ham tushunarli bo‘lsin. Ichki serverlarni emas, foydalanuvchi taniydigan komponentlarni ko‘rsating.
| Yaxshi komponent nomlari | Yomon komponent nomlari |
|---|---|
| Sayt, Mobil ilova, To‘lovlar, Kirish, API, Bildirishnomalar | web-01, redis-cluster, k8s-node-pool |
Har bir komponent uchun bir nechta holat yetarli: Ishlayapti, Sekin ishlayapti, Qisman nosozlik, Jiddiy nosozlik, Rejali ishlar.
Qo‘shish foydali bo‘lgan narsalar:
- Har bir komponent bo‘yicha so‘nggi 30–90 kunlik ishlash tarixi.
- Sayt yoki API uchun javob vaqti grafigi — agar u barqaror va tushunarli bo‘lsa.
- Oldindan e’lon qilingan rejali ishlar.
- Obuna: email, RSS, webhook yoki Telegram-kanal, shunda yangiliklar sahifani yangilamasdan keladi.
Kuzatayotgan hamma narsani e’lon qilmang. Kontekstsiz ichki metrikalar javobdan ko‘ra ko‘proq savol tug‘diradi.
Uni asosiy infratuzilmadan alohida joylang
Mahsulot ishlamay qolganda status sahifasi ishlashi shart. Agar u o‘sha serverda, o‘sha bulut akkauntida yoki o‘sha balansirovkachi ortida bo‘lsa, hamma narsa bilan birga to‘xtaydi.
Tekshiruv ro‘yxati:
- Boshqa hosting: SaaS status servisi, boshqa provayderdagi statik sayt yoki hech bo‘lmaganda boshqa region va akkaunt.
- Mustaqil DNS: asosiy DNS-provayderda nosozlik bo‘lsa ham
status.ochilishi kerak. Alohida zona yoki provayder haqida o‘ylab ko‘ring. - Avtorizatsiya, ma’lumotlar bazasi yoki API’ingizga hech qanday bog‘liqlik bo‘lmasin.
- Statik yoki keshlangan sahifa yetarli — u shunchaki ochilishi kerak.
Hosted yoki self-hosted
| Hosted (SaaS) | Self-hosted | |
|---|---|---|
| Ishga tushirish | Bir necha daqiqa, serversiz | O‘zingiz o‘rnatasiz va qo‘llab-quvvatlaysiz |
| Mustaqillik | Allaqachon infratuzilmangizdan tashqarida | Faqat alohida joylasangiz |
| Imkoniyatlar | Obunalar, shablonlar, integratsiyalar tayyor | Vositaga bog‘liq |
| Narx | Oylik obuna, obunachilar va funksiyalar soni bilan oshadi | Hosting va jamoa vaqti |
| Nazorat | Vendor bilan cheklangan | Ma’lumot va dizayn ustidan to‘liq nazorat |
Hosted servislar orasida Atlassian Statuspage, Instatus, Better Stack bor. Mashhur open-source variantlar — Uptime Kuma, Gatus, Upptime va Cachet. Kichik jamoa uchun odatda hosted servis yoki GitHub Pages va GitHub Actions’da ishlaydigan Upptime eng oson yo‘l.
Uni ishlash monitoringiga ulang
Faqat qo‘lda yangilanadigan sahifa ko‘pincha haqiqatdan orqada qoladi. Monitoringni ulang:
- Har bir komponent uchun bir nechta joydan tashqi tekshiruvlar (HTTP, TCP, ping, kalit so‘z qidiruvi) sozlang.
- Holatni faqat bir nechta joydan tasdiq kelganda yoki ketma-ket bir nechta tekshiruv muvaffaqiyatsiz bo‘lganda o‘zgartiring — shunda yolg‘on signallar kamayadi.
- Monitoring komponent holatini avtomatik o‘zgartirsin yoki inson tasdiqlaydigan insident qoralamasini yaratsin.
- Bir vaqtning o‘zida navbatchi jamoaga alert yuboring, shunda sahifa ham, odamlar ham birga harakat qiladi.
Avtomatik holat o‘zgarishi aniq nosozliklar uchun yaxshi. Insident matnini esa inson yozgani ma’qul.
Insident xabarlarini qanday yozish kerak
Oldindan ma’lum ketma-ketlikdan foydalaning: Tekshirilmoqda → Sabab topildi → Kuzatilmoqda → Hal qilindi.
Har bir xabar uchun qoidalar:
- Ichki sababni emas, foydalanuvchi nimani ko‘rayotganini yozing: «Ma’lumotlar bazasi replikasi kechikishi» emas, «To‘lovlarning bir qismi xato bilan tugayapti».
- Ko‘lamni ko‘rsating: qaysi komponent, qaysi region yoki foydalanuvchilar guruhi.
- Keyingi xabar vaqtini ayting: «Keyingi yangilik 30 daqiqadan keyin» — va hech narsa o‘zgarmagan bo‘lsa ham va’dani bajaring.
- Ishonchingiz komil bo‘lmasa, tuzatish muddatini va’da qilmang.
- Hal qilingandan keyin qisqa xulosa qo‘shing: nima bo‘ldi, qancha davom etdi, nimani o‘zgartirasiz.
Misol:
Tekshirilmoqda: foydalanuvchilarning bir qismi mobil ilovaga kira olmayapti. Sayt odatdagidek ishlayapti. Sababni qidiryapmiz, keyingi yangilik 30 daqiqa ichida.
Ko‘p uchraydigan xatolar
- Status sahifasi mahsulot bilan bir serverda.
- Foydalanuvchilar allaqachon shikoyat qilayotganda «Barcha tizimlar ishlayapti» yozuvi.
- Xabarlar orasida soatlab sukut.
- Mijoz tushunmaydigan texnik jargon.
- Chiroyli ko‘rinish uchun eski insidentlarni o‘chirish.