Үлкен ұйымға арналған DNS, DHCP және IPAM архитектурасы

Қандай мәселе шешіледі және нені алдын ала анықтау керек

Үлкен ұйымда DNS, DHCP және адрестер жоспары бір жерде емес, тізбектей бұзылуы мүмкін. Пайдаланушылар бұл жағдайды «сайт ашылмайды», «1С жұмыс істемейді», «принтер жоғалды», «телефония үнсіз» сияқты көрінеді, ал себебі қарапайым болуы мүмкін: атау резолвталмайды, адрес дұрыс жерде берілмеген немесе бір IP-ді екі құрылғы алған.

Типтік инциденттер қайталанып тұрады: DHCP-пулдар таусылады, құрылғы ауысқан соң DNS-те қалдық жазбалар қалады, тура және кері зоналар шатасады, сервистер басқа подсетьке көшіп, ережелер мен тәуелділіктер жаңартылмайды. Особенно ауыр күй — критикалық жүйелер (AD, пошта, VoIP, медицина жүйелері, төлем терминалдары) A/AAAA және PTR-ге тәуелді болғанда: бір қате оңай жайлауға әкелуі мүмкін.

IP-қақтығыстар тіпті тәртіппен пайдаланғанда да пайда болады. Себеп көбіне «ұғынбаушылықта» емес, нақты өмірде: статикалы құрылғылар, роутерде немесе AP-де жасырын DHCP, алаңдар арасында қиысып жатқан диапазондар, ескі резервтер, қайта пайдаланылған VLAN-дар, жедел миграциялар және «уақытша» схемалардың тұрақты бола кетуі. Сондықтан DNS, DHCP және IPAM-ды ойластырылған түрде байланыстыру — өзгерістерді басқару үшін қажет.

Сіз шынымен жақсартқаныңызды түсіну үшін алдын ала өлшенетін мақсаттар қойыңыз: ақаудан қалпына келу уақыты, қолмен жасалатын операциялардың үлесі (серверде «қолмен» жасалатын түзетулер саны), IP қақтығыстары саны және ескірген DNS-жазбалар пайызы.

Жоспар құрудан бұрын минимум енгізулерді жинаңыз: алаңдар мен сегменттер (подсеттер, VLAN, қай жерде DHCP-relay бар), критикалық сервистер тізімі және атаулар мен адрестерге қойылатын талаптар, құрылғы түрлері және адресация тәсілдері (DHCP, резервтер, статика), ағымдағы DNS-зоналар және басқару моделі (орталықтан немесе филиал бойынша), нақты пайдаланудағы адрестер және «көгілдір аймақтар» (есепке алынбаған диапазондар).

Мысал: филиал қонақ Wi‑Fi қосты, ал точка доступа өз DHCP-ін қосып жіберді. Кейбір ноутбуктар «бүтін емес» подсетьтен адрес алып, DNS жаңартылмайды, ішкі ресурсқа қатынау жоғалады. Егер подсеть шекаралары, жауапкершілік және адрес беру ережелері алдын ала бекітілсе, мұндай жағдайлар өзгерістер кезеңінде ұсталады, емес — шағымдар толқынынан кейін.

Үлкен желіде DNS, DHCP және IPAM ролдерін қалай бөлу керек

Үлкен желіде DNS, DHCP және IPAM жиі әртүрлі командаларда «тұрады», бірақ біртұтас жүйе ретінде жұмыс істеуі тиіс. DNS атаулар мен сервистердің қайда бағыттайтынын жауапты болса, DHCP құрылғыларға адрес береді. IPAM адрестер кеңістігін — подсеттерді, пулдарды, резервтерді және кімге тиесілі екенін тіркеуді жүргізеді. Рөлдер араласып кетсе, «көгілдір» адрестер, қақтығыстар және күтпеген тоқтап қалулар пайда болады.

Негізгі принцип қарапайым: IPAM — адрестер бойынша жалғыз сенімді ақпарат көзі болуы керек. DHCP мен DNS есеп жүйесіне айналмауы тиіс, тіпті техникалық жағынан олар деректерді сақтай алса да. Кез келген подсеть, пул, резерв, статикалық адрестеу және VLAN тағайындау алдымен IPAM-да тіркеліп, содан соң ғана DHCP және DNS-ке қолданылады.

Бұл қағиданы тек сөзде қалдырмау үшін жауапкершілік шектерін алдын ала айқындаңыз. Практикада жиі мынадай бөлініс жұмыс істейді:

• Желілік инженерлер: адрес жоспары, подсеттер, VLAN/VRF, маршрутизация, сегментация ережелері.
• DNS/DHCP платформасының әкімшілері: пулдар, резервтер, беру саясаттары, опциялар параметрлері.
• Қауіпсіздік командасы: DNS-ті жаңарту ережелері, динамикалық жазбаларға шектеулер, өзгерістер аудиті.
• Филиалдардағы жергілікті ИТ: жаңа диапазондар мен резервтерге өтініштер, бірақ серверлерде қолмен түзетулер жасамау.

Қай өзгерістер өтініш арқылы жасалатынын нақты келісіңіз, әйтпесе есеп пен шындық тез сәйкессіз болады. Әдетте өтініш арқылы өтетіндер: жаңа подсеть құру, пулдарды кеңейту, статикалық адрестер беру, критикалық құрылғыларға резервтер бөлу, сервистерді алаңдар арасында көшіру.

Мысал: филиалда 30 терминал қосылады. Егер жергілікті админ DHCP-пулды жай ғана «қосу» жасаса, IPAM бұл туралы білмейді. Кейін орталық команда сол диапазонды Wi‑Fi үшін бөліп алса, қақтығыс пайда болады. Нормальды схемада өзгеріс IPAM-ға жазып, келісуден өтіп, одан кейін ғана DHCP және қажет болса DNS-де қолданылады.

DNS зоналарын жобалау: құрылым, делегирование, TTL

Жақсы схема зоналарды анық бөлуден басталады. Сыртқы DNS-зона интернеттен көрінуі тиіс нәрселер үшін ғана қажет: қоғамдық сайттар, пошта, тексеріс жазбалары. Ішкі зона корпоративтік желіге қатысты барлық нәрсені сақтайды: хосттар, сервистер, принтерлер, камералар, домен контроллерлері, ішкі баланстар.

Егер бір домен сыртта да, ішінде де әртүрлі жауап беруі қажет болса, split-horizon әдісін қолданады: бір атаумен екі зона — әртүрлі мазмұнмен. Бұл ыңғайлы, бірақ шатасуы оңай. Қандай жазбалар тек ішкі зонада тұратынын, кім оларды өзгерте алатынын және сыртқы DNS ішкі атауларды алмайтындай қалай қамтамасыз ететініңізді алдын ала анықтаңыз.

Зоналардың құрылымы және қарапайым атау ережесі

Қажетсіз жерге зоналарды бөлмеуге тырысыңыз. Көбіне ұйым үшін бір ішкі зона жеткілікті, ал алаңдарға немесе ірі бөлімшелерге подзондар делегирлеу жасалады.

Алдын ала қарапайым атау ережесін бекіту пайдалы:

• Атау = тип + рөл + алаң (мысалы, srv-files-alm, pc-acc-ast).
• Сервистер үшін түсінікті алиастар (CNAME) қолданыңыз, құжаттарда IP‑ді көрсетпеңіз.
• Тест (lab) және басқару (mgmt) үшін бөлек неймспейс.
• Бір атауда «адам» және «құрылғы» элементтерін араластырмаңыз.
• Алаңдардың қысқартуларын бекітіп, кейін өзгертуге жол бермеңіз.

Делегирование және TTL: қате жасайтын жерлер

Делегирование жауапкершілікті бөліседі: орталық команда корневая зонаны жүргізсе, алаңдар өз подзоналарын басқара алады. Делегирование түсінікті NS‑жазбалармен және бірдей жаңарту схемасымен бірге жүргізілуі тиіс.

TTL клиенттердің қанша уақыт жауапты «ескеретінін» анықтайды. Әдеттегі логика: критикалық жазбалар тұрақты қойылып, TTL көбейтіледі; ауысып тұратын жазбаларға (балансировщиктер, көшірілу) TTL төменірек қояды. Миграция алдында TTL алдын ала төмендетіп, тұрақтанғаннан кейін қайта қалыбына келтіру керек. Барлығына төмен TTL қою ұсынылмайды — жүктеме өседі және ақауларды талдау қиындайды.

Мысал: ішкі порталды басқа алаңға көшіру кезінде алдымен portal жазбасының TTL-ын төмендетіп, ауыстырып, қолжетімділікті тексеріп, кейін TTL-ды қалпына келтіресіз. Осылайша пайдаланушылардың бір бөлігі сағаттар бойы ескі адреске «отырып қалмайды».

DNS-жазбалар және өмірлік цикл: статика, динамика, кері зоналар

DNS-жазба нақты иесін және адрестеудің тәсілін көрсетуі тиіс. Солайша ұзақ уақыт сақталған ескі сервер жазбалары пайда болмайды және бір IP екі жерде тіркеліп қалмайды.

Статикалық жазбалар предсказуемтік қажет жерлерге қажет: критикалық сервистер, балансировщиктер, шлюздер, инфрақұрылымдық түйіндер және кез келген жүйелер фиксирленген IP-мен. Динамикалық жаңартулар клиенттік құрылғылар мен уақытша VM‑ларға жарайды, бірақ тек егер жаңартулардың көзі (әдетте DHCP) бақылауда болса және жазбаның «мерзімі өтуін» бақылау ережелері болса.

Дупликаттарды болдырмау үшін A, PTR және CNAME үшін қарапайым ережелер ұстаңыз: бір түйін — бір каноникалық атау A/AAAA арқылы; барлық альтернатив аттар — CNAME; PTR әрдайым сол каноникалық атауға сілтеме жасау керек. IP басқа хостқа өткен кезде алдымен ескі PTR мен A-ны тазалап, содан кейін ғана жаңа жазбаларды қосыңыз.

Кері зоналарды (PTR) подсеть шекаралары бойынша жобалап, оны сол подсетьтің адрес жоспарын басқаратынға делегирлеңіз. Мысалы, офис /24 және серверлік /24 — әртүрлі зоналар және әртүрлі жауаптылар.

IPAM/CMDB-де жазба үшін минималды «паспорты» пайдалы: иесі (команда немесе сервис), түрі (статикалық немесе динамикалық), өмір сүру мерзімі және себебі (жоба, алаң), авариялық контакт, жою ережесі (ауыстыру кезінде қашан өшіру).

Қызметтік құрылғылар (принтерлер, камералар, терминалдар) үшін бір тәсілді таңдаңыз: немесе DHCP‑резервтер + динамикалық DNS, немесе статикалық IP + статикалық DNS. Аралас тәсілдер көбіне дубликаттар мен «кім дұрыс» деген дауларға әкеледі.

DHCP: пулдар, резервтер және адрес беру саясаттары

Үлкен желіде DHCP жиі серверден емес, ережелер хаосынан бұзылады. Дұрыс схема әр подсетьтің анық бөліктерге бөлінуінен басталады: автоматты беру үшін адресер, статикалық құрылғылар үшін орын және исключения диапазондары (желілік жабдық немесе уақытша тесттер үшін). Негізгі ереже: бір диапазон — бір мағына, және бұл есепте көрсетілген.

Пулдарды бүкіл /24 етіп қоюдың орнына резерв қалдырыңыз және статикалық тағайындаулар үшін бөлек орын бөліңіз, сонда кейін критикалық сервистердің адрестері ауыстырылмайды. Исключения‑ларды әкімшінің есте сақтауымен емес, заң ретінде тіркеңіз.

Резервациялар құрылғыға болжамды IP керек болғанда пайдалы, бірақ оларды «барлығына» қоюдан абай болыңыз: база өсіп, MAC өзгергенде шектен тыс жазбалар пайда болады және қақтығыстар көбеюі мүмкін.

Адрестерді құрылғы түрлері мен қосылу орны бойынша бөлу пайдалы. Практикада VLAN және Option 82 (құралды желіде) көмектеседі, Wi‑Fi үшін SSID бойынша байлау, MAC/OUI қосымша белгі ретінде (бірақ жалғыз кепіл емес), сондай‑ақ қонақтар мен IoT үшін жеке подсеттер.

Біртұтас DHCP-параметр стандарттары «қызық» инциденттерді азайтады. Минимум бекітілетіндер: DNS servers және DNS suffix (аттар бірдей резолв болу үшін), NTP (телефония мен журналдау үшін маңызды), маршруттар (ішкі күрделі маршрутизация болса), прокси/автоконфигурация (егер қолданылса).

Мысал: бір қабаттағы ПК негізгі пулдан алса, IP-телефондар — дауыс VLAN‑дан, IoT — қысқа арендасы бар жеке подсетьтен, қонақ Wi‑Fi өз диапазоннан ішкі DNS зоналарға қатынаусыз. Мұндай жағдайда қақтығыстар ережелер деңгейінде ұсталады, сервис құлауынан кейін емес.

IPAM: есеп моделі, адрес жоспары және резерв ережелері

IPAM адрестерді «кімнің басында» емес, бір жерде тіркеу үшін қажет. DHCP адрес береді, DNS атаулар жариялайды, ал IPAM кімге және не үшін бәрі берілгенін тіркейді.

Алдымен қандай адрес кеңістігін есепке алатыныңызды келісіңіз. Әдетте бұл тек RFC1918 емес, сондай‑ақ қоғамдық диапазондар, DMZ, VPN туннельдердегі адрестер, қонақ Wi‑Fi үшін диапазондар және миграциялар мен тесттер үшін уақытша желілер. Егер маршруттау немесе брандмауэрде бір нәрсе бар болса, ол IPAMда да болуы тиіс.

Адрес жоспарын қарапайым иерархиямен құру ыңғайлы: алаң -> қауіпсіздік аймағы немесе желі түрі -> сегмент. Осылай жауапкершілікті делегирлеу және қателерді іздеу оңай болады. Мысалы: «Астана, офис, пайдаланушылар», «Алматы, ЦОД, серверлер», «Филиалдар, POS‑терминалдар».

Есеп ұзақ жылдар бойы жұмыс істеуі үшін анық ережелер қажет. Актив сегментте сыйымдылық резервін ұстаңыз (көптеген жағдайда 20–30%), әр подсетьті маркирлеңіз (мақсат, иесі, контакт, критичность, соңғы тексеру күні), біртұтас статустар қолданыңыз (жоспарда, бөлінді, пайдалануында, ажыратылуда), және «жымысқы» өзгерістерге тыйым салыңыз: жаңа подсеттер мен үлкен резервтер тек өтініш арқылы және IPAMға жазу арқылы ғана жүзеге асады.

Бірігу немесе мердігерлермен жұмыс кезінде қиысатын диапазондар жиі пайда болады. Практикалық шешім — оларға бөлек VRF немесе NAT аймақтарын бөлу және корпоративтік стандартқа көшіруді жоспарлау. IPAM‑да осындай желілерді оқшауланған деп белгілеп, миграцияның крайний күнін көрсету керек, әйтпесе бір күні қақтығыс апатқа айналады.

Процестер және құқықтар: адрестер есебі құлауын болдырмау үшін

IP‑қақтығыстар көбінесе «жаман DHCP» емес, біріктірілмеген өзгерістерден пайда болады: біреу жаңа VLAN ашты, басқа DNS жазба қосты, ал IPAM жаңартылмады. Сондықтан схема ғана емес, қарапайым ережелер керек: кім адрес кеңістігін өзгерте алады, бұл желімен қалай келісілетіндігі және нәтиже қайда тіркелетіні.

Жауапкершілікті бір бетке RACI форматында жинау ыңғайлы. Көбінесе келесі рөлдер жұмыс істейді:

• Желілік инженер: VLAN, маршрутизация үшін жауапты және подсеть параметрлерін бекітеді.
• DNS/DHCP әкімшісі: DNS пен беру саясаттарын енгізеді, дұрыстығына жауапты.
• Сервис иесі: өтініш жасайды және талаптарды растайды (атау, қолжетімділік, жұмыс уақыты).
• IPAM әкімшісі: есепті жүргізеді, адрестер мен белгілердің бірегейлігін бақылап отырады.
• IT жетекшісі/Change manager: жоғары тәуекелді өзгерістер мен жұмыс уақытыны бекітеді.

Келісім бірізді болуы тиіс: желіні өзгерту (жаңа VLAN немесе көшіру) DHCP‑опцияларды, тура және кері DNS зоналарын және IPAM‑дағы подсеть жазбасын жаңартпайынша аяқталмаған саналады. Жұмыс мәдениеті: бір Change — бір тапсырмалар жинағы, бір нәтиже иесі.

Адамдар процесті нақты пайдалануы үшін қысқа өтініш шаблондары қажет: жаңа подсеть, жаңа сервис, сервис көшіру, эксплуатациядан шығару. Әр шаблонға атау және метка (site, vlan, environment, owner) ережелерін алдын ала бекітіңіз және оларды күрделендірмеңіз.

IPAM үшін минималды өрістер, болмағанда есеп тез бұзылады: подсеть/VRF, VLAN ID, алаң; статус және өзгерген күні; иесі мен тағайындауы; байланысты DNS-атау және PTR (серверлер үшін); беру көзінің түрі (DHCP-пул, резерв, статик).

Қалдықты тоқтатпай енгізудің қадамдық жоспары

Жаңа схеманы енгізгенде бизнес тоқтамайтын жобаны қысқа итерациялармен жүргізу қауіпсіз. Әр қадамда не тексерілетінін және қалай оралуға болатынын айқындаңыз. Осылай ескі қателерді жаңа модельге жұқтырмайсыз және критикалық сервисті тоқтатуға тәуекел азаяды.

Бастапқыда факттерді жинаңыз: барлық DNS-зоналар, подсеттер, DHCP-пулдар, резервтер және белгілі IP‑қақтығыстар тізімі. Жергілікті статикалық адрес беру және қай жүйелер кері зоналарға тәуелді екенін бөліп көрсетіңіз.

Содан кейін жоспар бойынша жүріңіз:

1. Инвентаризацияны біріктірілген реестрге жинаңыз: зоналар, подсеттер, диапазондар, резервтер, сегмент иелері, өзгерістерге кіру нүктелері.
2. Мақсатты схеманы келісіңіз: зоналардың құрылымы мен делегированиеі, адрес жоспары өсуге резервпен, DHCP саясаттары (офистер, серверлер, қонақтар, IoT) және динамикалық адрестеу ережелері.
3. Бір сегментте пилот жасаңыз: бір алаң немесе VLAN (мысалы, офис Wi‑Fi немесе бөлек қабат), динамикалық жазбалар, резервтер мен кері зоналарды тексеру үшін.
4. Толқындармен көшіріңіз: жұмыс тәртібі, сәттілік критерийлері және айқын оралу жоспарын (сол сегментке ескі DHCP‑ны қайтару және зона үшін бұрынғы NS‑ті қалпына келтіру) алдын ала анықтаңыз.
5. Нәтижені бекітіңіз: әкімшілер мен сервис‑деск үшін қысқа оқыту және содан кейін өзгерістерді регламентке енгізу.

Пилоттан кейін масштабтауға дайындық белгісі: сізде жаңа сегменттер үшін қайталанатын шаблон бар және IPAM‑да айқын «шындық көзі» орналасқан.

Сенімділік және қолдау: HA, бэкапы, мониторинг

Үлкен желіде DNS пен DHCP ақаулары «бәрі бұзылды» сияқты көрінеді, ал себебі бір сервердің тоқтауы немесе пулдың толып қалуы болуы мүмкін. Сондықтан отказоустойчивтікті бастапқыда қосыңыз. DNS үшін әдетте маңызды зонаға минимум екі түйін қажет (әр түрлі стойкаларда немесе алаңдарда). DHCP үшін — екі сервер failover режимінде, сонда бір түйін құлса да адрес беру жалғасады.

Бэкапы «былай болсын» емес, қалпына келтіру тексерісімен болуы тиіс. DNS зоналарын және конфигурацияларын, DHCP конфигурацияларын (саясаттар мен резервтер кіретін), IPAM базасын және өзгерістер журналын сақтаңыз. DHCP үшін lease‑жүйесінің күйін архивтеу пайдалы — инциденттен кейін кім қай кезде адрес алғанын тез анықтауға мүмкіндік береді.

Мониторингті пайдаланушылар мен әкімшілер байқайтын симптомдарға негіздеңіз: негізгі зоналар бойынша NXDOMAIN және SERVFAIL санының өсуі, DHCP‑де NACK және DECLINE көбеюі, lease мерзімінің жиі аяқталуы және қайталанатын сұраныстардың шарықтауы, пулдардың толуы және unknown clients санының күрт өсуі, DNS жауап кешігулері және динамикалық жазбалардың жаңарту қателері.

Өзгерістерді бұзбау үшін тест конфигурациясы мен оралу жоспары керек. Жаңа DHCP саясатын Wi‑Fi үшін енгізбес бұрын бір алаңда тексеріп, содан кейін жоспарланған терезеде басқа алаңдарға енгізіп, ескі ережені тез қайтару мүмкіндігін сақтаңыз.

IP-қақтығыстарға әкелетін типтік қателіктер

IP‑қақтығыстар көбінесе DNS, DHCP және адрестер есебінің бұзылуынан туындайды. Тіпті жақсы жобаланған схема да ережелер бекітілмесе және адамдар процесті айналып өтсе, ақауға ұшырайды.

Жиі кездесетін себептер:

• DNS‑ке қолмен түзетулер автоматты жаңартулармен параллель жасалады. Мысалы, админ принтер үшін қолмен A жазбасын қосады, ал DHCP динамикалық жаңарту кейін сол атауды басқа адреспен байлайды. Нәтижесінде кейбір пайдаланушылар ескі IP‑ге барады, басқа бөлігі — жаңаға.
• Қақтығысты «шешу» үшін артықша DHCP‑резервтер жасау. Егер әр адрес «на всякий» резерв бола бастаса, пул пул болудан қалады, бос диапазондар күтпеген жерден таусылады, әрі біреу статиканы «бос» адрестерден қосады — бірақ ол адрес әлдеқашан алынған болуы мүмкін.
• VLAN мен подсеттерді өзгерту IPAM‑мен синхрондалмай жасалады. Желінің орналасуы өзгерді, есеп жаңартылмады: ескі адрестер бос емес болып есептеледі, жаңалары резервтелмеген, кері зоналар шындықпен сәйкес келмейді.
• Әртүрлі сегменттерде бірдей хост атаулары және бақылаусыз DNS‑суффикстер. Аралас ортада (ПК, IP‑телефондар, камералар) бұл «қай хостқа қосылғаныңды табу» мәселесіне тез айналады.
• Подсеттер мен жазбаларға иелердің тағайындалмауы. Егер ешкім DHCP арендасы мен DNS жазбаларын тазартуға жауап бермесе, қоқыс айлар бойы жиналады.

Қақтығыс жақындап қалғанының белгілері: DHCP-пул ішінде көп статикалық адрестер; резервтер өтінішсіз және мерзімсіз жасалады; бірдей атаулар бірнеше рет кездеседі; IPAM желілік өзгерістерден кейін жаңартылмаған; подсеть немесе зона үшін жауапты адам жоқ.

Іске қосар алдында және өзгерістерден кейінгі қысқа чек-лист

Жаңа схеманы енгізерден бұрын және кез келген түзетуден кейін қысқа тексеруден өту пайдалы. Бұл тесттер толық тексеруді алмастырмайды, бірақ типтік қателіктер мен «күтпеген» ақауларды тез анықтайды.

Бірінші кезекте адрестер кеңістігі бойынша бір ғана «шындық көзі» барын тексеріңіз. Бұл IPAM жүйесі немесе қатал жүргізілетін реестр болуы мүмкін, бірақ маңыздысы: подсеттер, беру диапазондары және резервтер әр түрлі командалардың әр түрлі кестелерінде өмір сүруі тиіс емес.

Подсеттер бойынша тексеру (әр VLAN/сегмент үшін бөлек): иесі мен контакті белгіленген; подсеть мақсаты мен құрылғы түрлері анықталған; DHCP‑диапазон, исключения (статика) және резервтер IPAM‑мен сәйкес келеді; алаңдар, филиалдар, VPN және уақытша желілер арасында диапазондар қиыспайды; қандай адрестерді өзгертуге болмайтыны (шлюзтер, балансировщиктер, критикалық сервистер) анық.

Содан кейін DNS жаңартулар ережелерін тексеріңіз. Динамикалық жазбалар үшін A/AAAA‑ны кім және қалай жаңартайтынын және кері PTR‑ды қалай бақылайтынын алдын ала шешіңіз, сонда «қоқыс» жазбалар жиналып, диагностика бұзылмайды.

Және сенімділікті тексеріңіз: DNS/DHCP/IPAM конфигурацияларының тұрақты бэкаптары бар ма және қалпына келтіру тексерілген бе. Қалпына келтіру ешқашан тексерілмеген болса, онда бэкаптың өзі жоқ деп есептеңіз.