Tenant — multi-tenant tizimda umumiy platformadan foydalanadigan, ma’lum userlar, data, konfiguratsiya va billing chegarasiga ega mustaqil mijoz yoki tashkilot. Tenant fizik server bilan aynan bir narsa emas; bir infratuzilmada ko‘p tenant izolyatsiyalangan ishlashi mumkin.
Izolyatsiya modellari
Shared database va shared schema tejamkor, ammo barcha queryda tenant filter talab qiladi. Bu xususiyat xavfsizlik, izchillik va ekspluatatsiya talabiga birga ta’sir qiladi. Separate schema kuchliroq mantiqiy chegara beradi, migration sonini oshiradi. Amaliy holat log, metric va nazoratli test orqali tasdiqlanadi. Dedicated database yuqori izolyatsiya va yuqori narx beradi. Aniq semantika foydalanilayotgan protocol yoki platforma hujjatida tekshiriladi.
Identity va ruxsat
Authenticated user qaysi tenant nomidan ishlayotgani server tomonidan aniqlanadi. Amaliy holat log, metric va nazoratli test orqali tasdiqlanadi. Client yuborgan tenant ID yolg‘iz access control uchun ishonchli emas. Aniq semantika foydalanilayotgan protocol yoki platforma hujjatida tekshiriladi. Row-level security accidental cross-tenant accessni cheklaydi. Bu xususiyat xavfsizlik, izchillik va ekspluatatsiya talabiga birga ta’sir qiladi.
Noisy neighbor
Bir tenantning CPU yoki request bursti boshqalarga ta’sir qilishi mumkin. Aniq semantika foydalanilayotgan protocol yoki platforma hujjatida tekshiriladi. Quota, rate limit va workload isolation adolatni saqlaydi. Bu xususiyat xavfsizlik, izchillik va ekspluatatsiya talabiga birga ta’sir qiladi. Metric va billing usage tenant bo‘yicha ajratiladi. Amaliy holat log, metric va nazoratli test orqali tasdiqlanadi.
Hayot sikli
Provisioning default role, key va configuration yaratadi. Bu xususiyat xavfsizlik, izchillik va ekspluatatsiya talabiga birga ta’sir qiladi. Deletion primary data, cache, backup va log retentionni qamraydi. Amaliy holat log, metric va nazoratli test orqali tasdiqlanadi. Katta tenantni dedicated shardga ko‘chirish uchun stable identity zarur. Aniq semantika foydalanilayotgan protocol yoki platforma hujjatida tekshiriladi.
Boshqaruv mezonlari
Tenant uchun owner, scope va hayot sikli aniq belgilanadi. Konfiguratsiya faqat muvaffaqiyatli odatiy oqimda emas, ruxsat xatosi, duplicate amal, uzilish va capacity chegarasida ham tekshiriladi. O‘zgarish canary yoki kichik guruhdan boshlanib, kerak bo‘lsa oldingi barqaror holatga qaytariladi.
Audit qaysi identity, qaysi vaqt va qanday sabab bilan holatni o‘zgartirganini saqlaydi. Dashboard umumiy son bilan cheklanmay, status va failure sabablarini ajratadi. Shu yondashuv Tenant bilan bog‘liq yashirin data yoki access xatosini erta aniqlashga yordam beradi.
Chekka holatlar va nazorat
Production muhitida izolyatsiya modellari bilan identity va ruxsat bir xil qatlam deb qaralmaydi. Birinchi qism noto‘g‘ri bo‘lsa, keyingi qismning muvaffaqiyatli ko‘rinishi umumiy natijani kafolatlamaydi. Shu sabab input, oraliq holat va yakuniy natija alohida qayd etiladi. Limitga yaqin qiymatlar, bo‘sh to‘plam, duplicate amal, kechikkan javob va qisman nosozlik maxsus testlar bilan qamrab olinadi.
Tenant uchun noisy neighbor hamda hayot sikli production metrikalarida mustaqil ko‘rinishi kerak. Multi-tenancy, Tenant isolation va Row-level security bilan bog‘lanishlar configuration yoki schema o‘zgarganda qayta tekshiriladi. Normal trafficdagi muvaffaqiyat failure paytidagi recoveryni isbotlamaydi; runbook, alert chegarasi va rollback amalda sinab ko‘riladi. Natijalar owner va o‘zgarish versiyasi bilan saqlansa, keyingi incidentda sababni taxmindan emas, dalildan aniqlash mumkin.
Bog‘liq tushunchalar
Multi-tenancy, Tenant isolation, Row-level security, Quota, Noisy neighbor, Shard key, Provisioning, Data deletion