Инфрақұрылымның синтетикалық мониторингі: шуды азайтатын тексерістер

Мәселе: алерттер бар, бірақ не істен шыққаны түсініксіз

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

Инфрақұрылымның синтетикалық мониторингі осы олқылықты жабады. Ол кесте бойынша шынайы әрекеттерге ұқсас қысқа қадамдарды қайталайды және нәтижені тіркейді. Мысалы: DNS атауы резолв болды ма, VPN‑туннель көтерілді ме, RDP ашылады ма, сайт HTTP 200 қайтарады ма және қанша уақытта. Бұл метрикалар мен логтардың орнына емес, «сырттан» тәуелсіз тексеріс ретінде қызмет етеді, тіпті қосымша өзiн «барлығы жұмыс істейді» десе де.

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

Дұрыс бапталған синтетика тез жауап беруге көмектеседі және іздеуді тарылтады:

• Бұл желі ме әлде сервис пе?
• Мәселе DNS, маршрутизация, портқа қолжетімділік немесе қосымшада ма?
• Ақау локальды ма (бір сайт немесе провайдер) немесе жалпы ма?
• Қашан басталды және кешігу қалай өзгерді?

Қарапайым мысал: пайдаланушылар корпоративтік веб‑сервисті аша алмайды. Егер DNS резолв болмайтын болса — бір себеп. DNS дұрыс болса, бірақ HTTPS қосылмаса — басқа себеп. HTTPS бар, бірақ 500 қайтаратын болса — бұл қосымша немесе дерекқор мәселесіне ұқсайды. Мұндай талдау желі мамандары мен сервис иелері арасындағы бірнеше сағаттық хат алмасуды үнемдейді.

Не тексеруге болады кестеге сай: DNS, VPN, RDP, HTTP қарапайым тесттер

Жоспарлы тексерістердің мақсаты — пайдаланушы жолын имитациялау: атаудан сервиге дейін. Солай инфрақұрылымның синтетикалық мониторингі «порт ашық» деп қана емес, қай жерде ақау басталатынын көрсетеді — желідеме, қолжетімділікте ме, әлде қосымшада ма.

DNS‑ті бір сұраумен емес, қысқа тізбектермен тексерген дұрыс: қажетті атауды (A/AAAA, CNAME) резолвтеу, жауап уақыты және қате түрі. NXDOMAIN көбіне теру қатесі немесе қате жазба, ал SERVFAIL жиі DNS серверінің немесе рекурсия бөлімінің мәселесін көрсетеді. Қызмет сырттан ашық болса, ішкі зоналарды (мысалы, intranet.local) және сыртқы домендерді тексеру орынды.

VPN‑ті пайдаланушы сияқты тексеріңіз: шлюзтің қолжетімділігі, аутентификацияның сәттілігі және туннельдің орнатылу уақыты. Егер «шлюз пингіленеді», бірақ туннель ұзақ көтеріледі немесе мүлде көтерілмесе, бұл «жай желі» емес. Себептер: сертификат, есептік жазба, концентрациялық жабдықтың жүктелуі, қатынау саясаттары.

RDP үшін тек 3389 портын тексеру жеткіліксіз. Кіру экранына дейін жетіп, оған дейінгі уақытты өлшеу маңызды. Порт жауап беріп тұрса да, қызмет тоңып қалуы, лицензияның таусылуы, домен контроллері жетімсіз болуы немесе профиль ұзақ жүктелуі себебінен пайдаланушы кіре алмауы мүмкін.

HTTP/HTTPS тестін «браузер сияқты» жасаңыз: жауап коды, редиректтер, бірінші байтаға дейінгі уақыт, TLS дұрыстығы және сертификат мерзімі. 200, 302, 401 және 503 арасындағы айырмашылық қайда іздеу керектігін көрсетеді.

Практикалық базалық тесттер жинағы (әрқайсысында статус пен уақытты тіркеңіз):

• DNS: резолвинг + қате түрі (NXDOMAIN/SERVFAIL) + кешігу
• VPN: handshake/логин + туннель орнату уақыты
• RDP: TCP + кіріс экранының пайда болуы
• HTTP/HTTPS: код + TLS + редирект тізбегі + TTFB
• Сквозной қадам: барлық қадамдарды біртіндеп орындап, нақты URL‑ге жету

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

Қайдан және қаншалықты жиі іске қосу керек, нәтижелер адал болу үшін

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

Бастапқыда 2–4 іске қосу нүктесін таңдаңыз, олар трафиктің нақты бағыттарын көрсетсін: офис желісі (қызметкерлер сияқты), дата‑орталық (ішкі жүйелер сияқты), интернетке жақын сыртқы нүкте (пайдаланушылар сияқты), плюс ірі филиал немесе проблемалы аймақ.

Жиілік тоқтаудың бағасы мен «мигану» төзімділігіне байланысты. Маңызды нәрселер үшін (VPN кірісі, негізгі веб‑сервис) әдетте 1–5 минут жеткілікті. Қосалқы тексерістер үшін (резервтік арналар, емес негізгі зоналар) 15–60 минуттың ішінде өткізу орынды. Қарапайым ереже: тоқтаудың қымбаттағаны сайын тексеріс жиі болуы керек.

Техникалық жұмыстардың уақытын алдын ала белгілеңіз. Оған кезде алерттер өшіріледі немесе «хабарлама режиміне» өтеді, эскалация болмасын. Әйтпесе командаға жалған инциденттер жиналып, хабарламаларды елемей қалуы мүмкін.

Таймауттарды қатты орнатыңыз. Егер HTTP тексерісі 2 минут «асып» тұрса, жиі іске қосу мағынасыз және кезектер қатары үзіледі. Типтік бағыттар: DNS 2–3 секунд, VPN/RDP 10–20 секунд, HTTP 5–15 секунд. Одан кейін 1–2 қайталау және қысқа үзіліс қосыңыз, бір реттік желілік ақау індетке айналмайтындай.

Қадамдық: жоспарлы тексерістерді қарапайым қадамдардан қалай құрастыру

Алдымен «портты тексеру» емес, нақты пайдаланушы жолын сипаттаңыз. Мысалы: қызметкер VPN‑ке қосылды, RDP арқылы жұмыс серверіне кірді және ішкі порталға кірді. Мұндай сценарий айқын тартымдарды көрсетеді.

Сосын жолды бөлек тексерілетін кезеңдерге бөліңіз. Ыңғайлы логика: DNS — желі — TLS — HTTP — аутентификация. Әр кезең нақты нәтижені беруі тиіс: қолжетімділік, маршрутизация, сертификат немесе қосымшаның өзі.

Қадам бойынша тексерістерді жинау

Бастапқы каркас әдетте мынадай болады:

• Кіріс деректерін бекітіңіз: хост аты, IP (егер тұрақты болса), порт, URL, тесттік пайдаланушы.
• Жеке тексерістер жасаңыз: DNS‑резолв, TCP‑қолжетімділік (SYN), TLS‑қол алысу, HTTP‑жауап, логин немесе рөлді тексеру.
• Әр қадам үшін нәтижені және уақытты жазып отырыңыз (сәтсіздік, таймаут, қате код, қате).
• Минимум контекст қосыңыз: қай DNS сервер, қай IP қайтты, HTTP коды, қандай сертификат қайтарылды.
• Қадамдарды бір сценарийге жинаңыз, бірақ әр кезең бойынша детализация сақталады.

Әр қадамдағы уақыт және базалық сызық

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

Орнатқаннан кейін тексерістерді жұмыс уақытында да, түнде де іске қосып көріңіз. Егер түнде бәрі тұрақты, ал күндіз DNS немесе TCP уақыты өссе — бұл жиі желі немесе шеткі құрылғылардың жүктелуі. Егер DNS пен TCP жылдам, TLS өтеді, бірақ HTTP 500 қайтаратын болса — мәселе көбінесе сервисте.

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

Желілік ақауды сервис ақауынан қалай ажырату

Синтетикалық мониторингтің негізгі қағидасы: тізбекті қадамдар бойынша тексеріп, қай жерде сәтсіздік болғанын тіркеу. Осылайша «это сеть» немесе «это приложение» деген дау емес, нақты факт болады: қай қадам өтпеді.

Қарапайым тәртіпті сақтаңыз: алдымен атау, кейін жол, содан соң сервис. Егер атау резолв емес — HTTP немесе RDP‑ні тексерудің мәні жоқ. Атау резолв болса, бірақ адреске жетпесе — мәселе көбіне желі немесе маршрутизацияда. Жол бар болғанда ғана сервиске қатысты терең талдау жасаңыз.

Тиімді диагностикалық тізбек:

• DNS: домен атауы күтілетін IP береді және себебі жоқ «секіру» жасамайды
• Желі: IP немесе шлюзке дейін байланыстың болуы (жоғары кешігу немесе жоғалту жоқ)
• Порт: қажетті порт қолжетімді (443, 3389 және т.б.)
• Сценарий: сервис күтілгенді орындайды (логин, API жауап, бетті жүктеу)

Әр түрлі DNS‑терді салыстырыңыз: ішкі (қызметкерлер мен серверлер қалай көреді) және сыртқы (интернет қалай көреді). Егер сыртқы резолвтаса, ал ішкі резолвтемесе — мәселе ішкі инфрақұрылымға жатады. Керісінше болса — сыртқы DNS провайдері немесе жазбаның жариялануында проблема болуы мүмкін.

Тағы бір сенімді тәсіл — бір HTTP сұрауды әр түрлі нүктелерден параллель тексеру. Егер офистен ашылмаса, ал дата‑орталықтан ашылса — VPN, firewall немесе маршруттарды күдіктеніңіз. Егер еш жерде ашылмаса — веб‑сервис немесе оның тәуелділігі (дерекқор, балансировщик, сертификат) ықтимал себеп.

«Порт ашық» пен «сервис жұмыс істейді» дегенді араластыруға болмайды. RDP 3389‑ты тыңдап тұрса да, кіру саясаты, жүктеме, тоңу немесе домен контроллерінің жоқтығы себепті пайдаланушы кіре алмауы мүмкін. Сондықтан портты тексергеннен кейін сценарийді тексеріңіз: сессия орнату, кіріс экранына жету, тесттік аутентификация (немесе күтілетін жауапты алу).

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

Порогтар мен ережелер — алерттерді шудан сақтау үшін

Алерттегі шу көбінесе барлық оқиғалар бірдей маңызды деп есептегенде шығады. Синтетика үшін сигналдарды екі түрге бөлген дұрыс: жауап уақыты (latency) және қателіктер (fail). Олар әр түрлі түрде жүріп, әр түрлі порогтарды талап етеді.

HTTP 200 бере тұрып 8–10 секундқа «тұрып қалуы» пайдаланушыға жаман әсер етеді, бірақ әрдайым апат емес. Ал 3 рет қатарынан таймаут немесе 5xx сериясы нақты қолжетімсіздікті білдіруі ықтимал.

Жұмыс схемасы — екі деңгей: деградация үшін warning және қолжетімсіздік үшін critical.

Шуды көп бөлігін жоятын минималды ережелер

• Latency мен қателер үшін порогтарды бөлек қойыңыз.
• Warning пен critical үшін әртүрлі шарттар орнатыңыз (warning — баяулаған, critical — істемей жатыр).
• Растау қосыңыз: алерт N (2–3) рет сәтсіз тексерістен кейін ғана ашылсын, «сауығу» — 2 сәтті тексерістен кейін болсын.
• Қайталануларды басып тастаңыз: бір проблема үшін бір инцидент, жүздеген бірдей хабарлама емес.
• Жоспарлы жұмыстар кезінде критикалық ескертпелерді өшіріңіз немесе оларды ақпараттандыру режиміне ауыстырыңыз.

Практикада қалай көрінеді

Егер VPN тесті бір таймаут көрсетіп, келесі сәтте өтті — бұл тарихқа жазылады, бірақ түнгі дежурды оятуға себеп емес. Ал 3 тексерісте қатар туннель орнатылмаса және басқа нүктелерден де DNS пен HTTP нашарласа — бұл желілік проблема болуы мүмкін. Егер желі «жанды», бірақ тек бір хостқа RDP түссе — бұл сервис немесе нақты машина мәселесі.

Мақсат — мониторингті азайтқан жоқ, ал ескертулер нақты инциденттерге сәйкес келетіндей ету.

Хабарландырулар мен эскалация: маңыздыны жоғалтпай, адамдарды жүктемеуші болу

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

Ақау түріне қарай алушыларды бөлу:

• Желі (DNS, VPN, RDP, жоғалту, таймауттар) — желі бойынша дежурный немесе NOC
• Қауіпсіздік (сертификаттан қате, блоктаулар, күдік тудыратын жауаптар) — SOC немесе ИБ жауаптысы
• Қосымша/сервис (HTTP 5xx, логиннің өтпеуі, API қатесі) — сервис дежурныйы немесе иесі
• Платформа (балансировщик, прокси, SSO) — платформа командасы
• Провайдер/арна (бірнеше нүктеден расталған) — провайдерге жауапты адам

Хабарландыру арнасы да тәуекел деңгейіне сәйкес болуы тиіс. Чаттағы хабарламалар «бір нүкте құлап қалды» немесе «баяулаған, бірақ сервис тірі» үшін жарайды. Телефон қоңырауы қажет — бірнеше нүкте растаған істен шығу, критикалық сервиске әсер немесе SLA қаупі болғанда.

«Қайдан бастауды білмейтін» диалогтарды болдырмау үшін әр хабарда кем дегенде мыналар болсын:

• іске қосылған нүкте және желі (офис, дата‑орталық, сыртқы узел)
• сценарий қадамы (DNS, TCP, TLS, HTTP, логин) және қай жерде тоқтағаны
• қате коды немесе мәтіні (NXDOMAIN, timeout, 401, 502) және өлшеу уақыты
• бақылау терезесі (қанша тексеріс қатар) және бірінші ақау уақыты
• ағымдағы эскалация статусы (L1, L2) және жауапты контакт

Эскалация уақыт бойынша алдын ала жазылсын. Мысалы: 0–5 минут ішінде дежурный растайды, 5–15 минут ішінде екінші деңгей шақырылады, 30 минут ішінде сервис иесі хабарланады. Егер проблема расталмаса, оны флап ретінде тіркеп, порогтар мен нүктелерді қайта қараңыз, біржолата тексерісті «өшіріп» қоюдың орнына.

Сценарий мысалы: «корпоративтік веб‑сервис ашылмайды»

Таңертең пайдаланушылар: «портал VPN арқылы ашылмайды» деп жазады. Егер тек бір алертке ғана жауап беріп қалсаңыз — «сайт қолжетімсіз» — онда сағат өткізіп, қайсысы желі ме немесе сервис пе деген дауға кету оңай.

Жоспарлы тексерістер тізбектеліп жүреді: DNS, содан кейін VPN, адреске порт бойынша қолжетімділік, және соңында HTTP. Біздің мысалда сурет мынадай: портал аты резолв болады, VPN‑туннель орнайды, базалық желілік қолжетімділік бар, бірақ HTTP 502 қайтарады.

502 көбіне сіз веб‑нүктеге жеттіңіз, бірақ іште бір нәрсе бұзылғанын білдіреді: балансировщик, upstream, backend пулдары, лимиттер немесе аралық прокси. Маңызды қорытынды: желі жұмыс істейді, іздеуді сервис немесе балансировщиктан бастау керек. Осылай синтетика шуды азайтады — бәрі қызыл емес, нақты қай қабат құлағаны көрінеді.

Контрмысал: тексерістер бас офис пен филиалдан іске қосылады. Офистен DNS жауап береді, ал филиалдан DNS жауап бермейді немесе қате IP қайтарады. HTTP тест бастала алмайды, өйткені IP жоқ. Бұл филиалдық проблемаға ұқсайды: филиал DNS сервері, firewall ережелері, split‑DNS, кэш немесе VPN саясатына қатысты.

Тапсырымды қажетті командаға тез беруге жеңіл қысқа қорытынды жасаңыз: қай жерде және кімде ашылмайды, не тексерілді (DNS → VPN → порт/маршрут → HTTP), қай жерде және қай қадамда құлады (қате және код), қай нәрселер «жасыл» және неге бұл желі немесе сервиске ұқсайды.

Синтетиканы орнатуда жиі жіберілетін қателер

Ең көп жіберілетін қате — пингпен шектелу және сонымен тынышталу. Пинг түйіннің жауап бергенін көрсетеді, бірақ DNS, аутентификация, сертификаттар, веб‑бет немесе VPN жұмысы туралы ештеңе айтпайды. Нәтижесінде «жасыл» көрсеткіші бар, бірақ пайдаланушылар кіре алмайды.

Екінші типтік қате — тек бір нүктеден тексерістерді іске қосу, мысалы дата‑орталықтан. Сонда филиалдағы провайдер, маршрут немесе ішкі DNS мәселелерін байқамай қаласыз. Минимум — 2–3 іске қосу нүктесі: орталық желі, сыртқы интернет және бірнеше маңызды сайттар.

Жалған төмендеулер көбіне тым қатты таймауттардан шығады. Егер HTTP‑ге 1 секунд берсеңіз, ал сервистің әдеттегі уақыты шарықтаған кезде 2–3 секунд болса, сіз шындығында авария емес, бірақ көптеген ескертулер аласыз. Таймауттарды нақты өлшемдерге сай қойып, фактілерге қарай қайта қараңыз.

Тағы бір қате — желілік және прикладтық алерттерді бір шұңғырға салу. Бір хабарламада «DNS резолв болмайды», «VPN көтерілмеді» және «HTTP 500» сияқты аралас хабарламалар болмауы тиіс. Қарапайым классификация қажет: қай жерде істен шықты — резолвинг, канал, порт, логин немесе сервис.

Соңғысы — өлшеу тарихын сақтамау. Оның болмағанынан «қалай әдетте» екенін білмейсіз, және апталар бойы созылған деградация байқалмай өтеді.

Қателіктердің көп бөлігін болдырмайтын қысқа тексеру:

• DNS, TCP‑порт, логин (VPN/RDP) және HTTP үшін бөлек тесттер ұстаңыз.
• Тексерістерді ең азынан екі түрлі желіден іске қосыңыз.
• Таймауттарды нақты өлшемдерге сай орнатып, оларды қайта қараңыз.
• Оқиғаларды желі vs сервис түрлері бойынша бөлу.
• Тарихты сақтап, оны қалып ретінде пайдаланыңыз.

Өндіріске шығар алдында жылдам чек‑лист

Синтетикалық мониторингті барлық жерде қосып, дежурларды оятпас бұрын негізгі нәрселерді тексеріңіз. Бұл бір‑екі сағат уақыт алады, бірақ кейін күндер ұзақ талқылауды үнемдейді.

Алдымен «критикалық пайдаланушы жолдарын» бекітіңіз. «VPN жұмыс істейді» емес, нақты: «қызметкер VPN‑ке қосылып, RDP арқылы терминал серверіне кіріп, HTTPS арқылы ішкі порталға кіреді». Әр жолға сервис иесі мен желі иесі бекітілсін, алерт ауада қалмасын.

Әр жолды қадамдарға бөліп, күтілетін нәтижелерді жазыңыз: DNS X мс ішінде күтілетін жазбаны қайтарады, VPN Y секунд ішінде орнатылады, RDP кіріс экранына жеткізеді, HTTP 200 және логин беті шығады, редирект күтілген жерге апарады. Таймауттар мен жауап уақыт шектерін алдын ала қою маңызды, әйтпесе тексерістер «нервный» немесе «тыныш» болып қала береді.

Продқа шығар алдында чек‑лист:

• Критикалық жолдар тізімі келісілді, иелері тағайындалды (сервис, желі, қауіпсіздік).
• Әр қадам үшін күтілетін нәтижелер: кодтар, таймауттар, рұқсат етілген уақыт шектер.
• Тексерістер кем дегенде екі нүктеден іске қосылады (мысалы, офис пен сыртқы желі).
• Алертты растау: N сәтсіз тексерістен кейін ғана срабатывание және қайталануларды басу.
• Хабарлама оқылатын: қандай қадам құлады, қай нүктеден, қандай қате, қанша уақыт алды.

Соңғы тексеру ретінде бір тесттік инцидент жасаңыз. Мысалы, тесттік DNS жазбасын уақытша өзгертіп немесе тесттік портты жауып, алертің қалай және қаншалықты анық келетінін қараңыз. Егер хабарлама бастапқы шешім қабылдауға көмектеспесе, оны іске қосар алдында түзетіңіз.

Келесі қадамдар: шағын пилот пен ұқыпты кеңейту

Кішіден бастаңыз. Бизнестің тоқтап қалуына әкелетін 3–5 сервис таңдаңыз: корпоративтік портал, қашықтан жұмыс үшін VPN, негізгі RDP серверлері, DNS резолвингі, бір сыртқы HTTP endpoint. Бір типтік сценарийді таңдаңыз (мысалы, «үйден келген қызметкер VPN арқылы қосылып, веб‑сервис ашады») және дәл сол сценарийді тексеріңіз.

Қай көрсеткіштер SLA мен есептерге кіретінін алдын ала келісіңіз. Әдетте бұл «бәрі жасыл» емес, нақты метрикалар: сәтті тексерістер пайызы, 95‑перцентиль жауап уақыты, орташа қалпына келтіру уақыты. Даулыларды қалай шешетініңізді де алдын ала анықтаңыз, мысалы желі тірі, бірақ сервис тұрақты түрде баяу болғанда.

Пилот логтар жинаққа айналмас үшін дереу нәтижелерді сақтау орнатыңыз. Тарих болмаса, сіз тек ағымдағы ақауды ғана көресіз және апта бойы жиналған баяулау байқалмай қалады. Минимум сақтау керек: қадам статусы, ұзақтығы, іске қосу нүктесі, қате себебі.

Сосын жоспар бойынша кеңейтіңіз: филиалдар мен сыртқы провайдерлерде 1–2 қосымша нүкте қосыңыз, сценарийлерді кеңейтіңіз (логин, негізгі бет жүктелуі, API сұрауы), релиздерден кейін және желі өзгерістерінен кейін тексерістер енгізіңіз, порогтарды ай сайын нақты деректер бойынша қайта қараңыз.

Егер мониторингке сенімді база керек болса (бақылау жүйесі серверлері, диспетчерлер үшін жұмыс орындары, тех‑сопровождение), GSE.kz (gse.kz) инфрақұрылым, интеграция және тәулік тәулік қолдау бойынша көмектесе алады, солайша пилот тұрақты процеске айналады.