Филиалдар үшін NetFlow/sFlow есептері: интернетті кім «жеді»?

Филиалдағы «интернетті кім жеген» деген не дегенім

Типтік жағдай: филиалда «бәрі баяу» деп шағымданады, бірақ канал толық құламайды. Мониторингіде линк 60%-те, кейін 90%-ке жетеді, кейде жоғалтулар бар, кейде жоқ. Пошта, ERP және видеоқоңыраулар үзіліп-жыбырлап істейді, ал қолданушылар «интернет жоқ» деп ойлайды.

Проблема мынада: ping пен интерфейс утилизациясы тек «симптом бар ма» деген сұраққа жауап береді. Ping кешігулер мен жоғалтуларды көрсетеді, ал интерфейс графигі — жалпы көлемді. Бірақ олар кім жүктеді, қандай қосымша оны жасады және мегабайттар қайда кетті дегенді түсіндірмейді.

«Интернетті кім жеген?» деп сұрағанда, әдетте тез арада төрт ось бойынша саралау керек: кім (құрылғы, қолданушы, подсеть), не (қосымша, порт, протокол), қашан (нақты терезе, шоқтар, қайталануы), қанша және қайда (көлем, жылдамдық, бағыт, сыртқы адрес немесе ішкі сервер). Осы мақсатта NetFlow/sFlow есептері қажет: олар тек «қанша» емес, «кім және немен» екенін көрсетеді.

Қарапайым мысал: филиалға 50 Мбит/с канал және әр күні сағат 10:00-де шағымдар басталады. Интерфейсте — жай ғана шың. Ал flow-дер бойынша бір ПК үлкен жүктемелерді бұлтты сақтауға жүктейтін болып шығады, сондықтан да дауыстық және корпоративтік жүйелер зардап шегеді.

Инциденттің алғашқы 30 минутында әдетте маңызды сұрақтар:

• Қазір және соңғы 15 минутта қайсысы Top-1 по трафикке?
• Қандай қосымшалар «бұрынғыдан» қатты өсті (мысалы, кеше осы уақытта)?
• Бұл бір «үлкен сөйлесуші» ме, әлде көптеген кішкене көздер ме?
• Трафик сыртқа бағытталған ба, әлде ішке (ЦОД-қа, интернетке, бұлтқа)?
• Қандай сервистер бизнеc үшін маңызды және олар қаншалықты деградацияға ұшырады?

Егер сіз оларға тез және ИТ-ке де, басшыға да бірдей түсінікті түрде жауап берсеңіз, онда сіз шынымен «интернетті кім жегенді» анықтап отырсыз, жай ғана графиктерді бақылап отырған жоқсыз.

NetFlow vs sFlow: нені аласыз

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

NetFlow «потоктармен» жұмыс істейді. Потокты байланыс туралы жазба ретінде елестетуге болады: қайнар көзі, тағайындалуы, порттар, протокол, көлем, уақыт. Мұндай жазбаларды есептерде жинақтау ыңғайлы: трафик бойынша топ, бағыттар, қосымшалар (егер анықталса), филиалдар.

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

Неліктен айырмашылық маңызды:

• Потоктарды уақыт бойынша агрегаттау және салыстыру оңай (алдынан/кейін, шоғыр уақыт, жұмыс сағаттары).
• Пакет таңдау жабдыққа жеңіл және тез, бірақ сирек оқиғаларды «жасыруы» мүмкін.
• Екі жағдайда да метадеректерді (кім, қайда, қанша) көресіз, бірақ мазмұнын көрмейсіз.

Деректерді экспорттауға жиі периметр мен филиалдың ядросындағы әртүрлі құрылғылар қабілетті. Практикада көздер көбінесе: маршрутизатор (WAN-ға шығуды көреді), firewall (саясаттарды және көбінесе қолданушыларды көреді), коммутатор (оның арқылы өтетін трафикті көреді, үлкен кеңселерде пайдалы).

Бөлек тақырып — L7 деңгейіндегі «қосымша атаулары» (мысалы, Teams, YouTube, бұлттық дискілер). Бір ғана flow-дер кейде жеткіліксіз: қазіргі трафик жиі шифрланады, ал порттар бұрынғыдай «шындықты» көрсетпейді. Есептерде түсінікті атаулар пайда болуы үшін классификация көзі керек:

• Firewall-дағы DPI немесе App-ID
• Маршрутизатордағы NBAR немесе ұқсас механизмдер
• прокси/secure web gateway журналдары
• DNS пен SNI-ға сәйкестендіру (әрқашан жұмыс істемейді)

Қарапайым мысал: филиалда «интернет баяу» дейді. Flow көрсете алады, каналдың 60%-ы ішкі бір IP-ке және бірнеше сыртқы хосттарға кетіп жатыр. Ал бұл — жаңартулар ма, видеосервис пе, әлде сақтауға көшіру ме — оны көбінесе FW немесе прокси арқылы L7-де көру арқылы анықтауға болады.

Қандай деректер жинау керек, есептер пайдалы болсын

NetFlow/sFlow есептері шынайы «интернетті кім жеген» деген сұраққа жауап беру үшін «бәрін түгел» жинаудан гөрі минималды, бірақ қажетті өрістер жиынтығын жинау маңызды. Әйтпесе әдемі графиктер болады, бірақ нақты қолданушыны, қосымшаны немесе бағытты атай алмайсыз.

Бастапқы тізбек: құрылғы-экспортер (маршрутизатор, L3-коммутатор, шекаралық firewall), коллектор (потоктар ағатын жер), сақтау (қанша күн сақтайсыз) және есептер панелі. Егер тарих кем дегенде 7-14 күн болмаса, бұл бір реттік шоқ па немесе жаңа норма ма екенін түсінбейсіз.

Міндетті өрістерді пилотқа дейін тексеріңіз. Олардың жоқтығында «кінәлі» жиі аноним болып қалады:

• src/dst IP (кім және қайда)
• src/dst порт пен протокол (трафик түрі)
• bytes/packets (неғұрлым нақты қанша)
• time (потоктың басталуы мен аяқталуы уақыты)
• interface және direction (кіру/шығу, қай линк)

Одан әрі дәлдік шешеді. sFlow әдетте sampling-пен келеді, NetFlow жиі дәлірек, бірақ жабдыққа ауыр тимек. Практикалық тәсіл — sampling 1:512 немесе 1:1024-пен бастау, қысқа, бірақ маңызды потоктар (мысалы, DNS) жоғалмай ма тексеру, содан кейін дәлдікті арттыру. Поток таймауттары да маңызды: тым қысқа болса суретті бөлшектейді, тым ұзақ болса шыңдарды жасырады.

Филиал бойынша бөлуді алдын ала ойлаңыз. Ең оңайы — трафикті филиалдың нақты WAN-интерфейсіне байлау. Егер желі күрделі болса, VRF тегтері, анық адрес жоспары және біртекті интерфейс атаулары көмектеседі, сонда есептер филиалдар араласпайды.

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

• каналдың орташа жүктемесі және шыңдары
• топ-5 қосымшалар бойынша трафик
• «бизнестен емес» трафиктің үлесі
• рұқсат етілген өсім (мысалы, базадан +20%)

Сосын филиал кенеттен «жұмыс жылдамдығы төмендесе», сіз базамен салыстырып, ауытқуды жылдам көресіз, «бұрын осылай болды» деп дауласпайсыз.

10 минут ішінде кінәлі табатын жылдам есептер

Филиалда «бәрі баяу» болғанда, болжам жасамау маңызды — тез тарылту керек: кім, қайда және қандай уақытта каналды жапты. Төмендегі NetFlow/sFlow есептері бір өту арқылы жиі жауап береді.

Алғаш тексерілетін 5 есеп

Белгілі бір уақыт терезесімен бастаңыз (мысалы, соңғы 30-60 минут) және қажет болса пайдаланушылар шағымданған уақытқа жылжытыңыз.

• Top talkers по объему и по скорости (Mbps): ең көп трафик жіберген құрылғыларды және ең жоғары жылдамдықты ұстап тұрғандарды көрсетеді. Көбіне бұл екі топ әртүрлі болады.
• Top applications (қосымшалар немесе порттар) с долей канала: бұл жұмыс жүктемесі ме (CRM, жаңартулар) әлде қажетсіз нәрсе ме (стриминг, торрент, бұлттық жүктеулер) — соны көрсетеді.
• Top conversations (клиент-сервер жұптары): кім қай сервермен сөйлескенін және қайда «ағып жатқанын» бірден көруге болады. Бір құрылғы бір сыртқы адресте үлкен көлем жүктей жатса пайдалы.
• Тренд утилизации по времени: минуттық канал жүктемесі графигі деградацияның қашан басталғанын көрсетеді. Бұл шыңды бэкаппен, жаңартумен немесе есептер жүктемесімен байланыстыруға көмектеседі.
• Inbound vs outbound: «жүктеді ме немесе қабылдады ма» сұрағына жауап береді. Егер outbound жоғары болса, бұл бұлтқа жүктеу, резервтік көшіру, видео жіберу немесе RDP сияқты нәрселер болуы мүмкін.

Күдікті хостты тапқаннан кейін картинаны нақтылаңыз: бұл бір реттік жағдай ма немесе күн сайын қайталанады.

«Жергілікті ме әлде жүйелік пе» тез тексеру

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

Мини-сценарий: трендте 10:15-те шың бар, inbound 3 есе өскен. Top applications-та HTTPS жетекші, ал Top conversations-да бір ПК бір сыртқы адрестен белсенді жүктеу жасап тұр. Одан әрі бұл жаңарту, архив жүктеу немесе видео екендігін анықтап, шара қолданасыз: түнге ауыстыру, жылдамдықты шектеу, өңдеу саясатын өзгерту.

Негізгі идея: бір есеп сирек жауап береді. Осы жинақтан 2-3 есеп әдетте бірдей түсінікті себепке әкеледі.

Операциялық дашборд шаблоны (ИТ үшін)

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

Жоғарғы тақырып: «қазір не қатты»

Жоғарғыда филиалдар бойынша каналдардың мәртебесін жасыл-сары-қызыл форматында ұстаңыз. Қасында әсер бойынша 3-5 жаңа инцидент көрсетіңіз: қай жерде жоғалтулар, кешігулер немесе утилизация шектен таяқ.

Шапкада әдетте жеткілікті:

• әр филиал бойынша кіріс/шығыс утилизация және соңғы сағаттағы тренд
• жоғалтулар мен кешігулер (өлімі бар болса) және «норма/жаман» белгісі
• тәуекел бойынша топ филиалдар: «канал толған», «жаңа бағыттаудың шоқтары», «real-time өсуі»
• жылдам фильтрлер: филиал, период, бағыт (интернетке/интернеттен/филиалдар арасындағы)

Негізгі блоктар: «кім және немен толтырып жатыр»

Сосын екі тез кесінді: топ құрылғылар және топ қосымшалар. Үш уақыт терезесін ұстаңыз: соңғы 15 минут, 1 сағат және 24 сағат, бұл бір реттік шоқты деректі жүктемеден ажыратуға көмектеседі.

Conversations (сөйлесулер) кестесін битрейт және көлем бойынша сұрыптауымен қосыңыз. Фильтрде минималды ғана ұстаңыз: филиал, қайнар/тағайындау, порт немесе қосымша, бағыт. Маңыздысы — тек «көлем бойынша топ» емес, сонымен бірге «қазіргі жылдамдық бойынша топ» көрсету, әйтпесе түнгі бэкап күндізгі айыпкер болып көрінеді.

Егер QoS-кластары болса, real-time трафиктің (дауыс, ВКС) үлесін және қазір не оны ығыстырып жатқанын бөлек көрсетіңіз. Бұл не кесуге болмайтынын және не шектеуге болатынын тез шешуге көмектеседі.

«Аномалиялар» блогын қысқа ұстаңыз, сонда ол шынымен жұмыс істейді:

• базалық сызыққа салыстырмалы кенеттен шоқтар (мысалы, +200% 10 минут ішінде)
• филиалда бұрын кездеспеген жаңа сыртқы тағайындаулар
• жаңа сервис/порттар немесе қосымшаның кенет өзгеруі
• ұзақ «ауыр» сөйлесулер (жоғары жылдамдық N минуттан артық)
• кестеге сәйкес келмеу (мысалы, бэкап жұмыс уақытында басталды)

Қысқа мысал: филиал қызылға өтті, 15 минуттық топта бір ПК және қосымша «бұлттық сақтау» көрінеді. Conversations-та бір сыртқы адресте ұдайы 80-90% канал бар. Әрекет: best-effort классты уақытша шектеу, синхрондауды түнге ауыстыру және жаңа агент немесе саясат пайда болғанын тексеру.

Басшылыққа арналған дашборд (управленческий)

Басшылыққа дашборд жұмыстың тоқтау қаупі қай жерде, қанша уақыт және қандай шешім тиімді деген үш сұраққа жауап беруі керек. Техникалық детальдар (порттар, ACL, кезектер) ИТ-командаға қалдырылсын, ал мұнда түсінікті метрикалар мен себептер көрсетілсін.

Блок 1. Филиалдар бойынша байланыс күйі (KPI)

Апта және ай бойынша барлық филиалдар үшін кесте немесе жылу картасын жасаңыз. Әр филиал үшін 2-3 индикатор жеткілікті: қолжетімділік, сапа (жоғалтулар/кешігулер бағасы) және инциденттер саны. Маңыздысы — бір реттік шыңдар емес, тұрақты проблемаларды көрсету: мысалы, филиал 7 күннің 4 күнінде қызыл аймақта болған.

Блок 2. Канал жүктемесі және «шекараға жақын уақыт"

Әр проблемалы филиал бойынша бір график: орташа жүктеме және 95-перцентиль, плюс канал алдын ала белгіленген шектен (мысалы, 85-90%) жоғары болған сағаттар саны. Бұл «кейде баяу» дегенді «аптасына 12 сағат шекарада жұмыс істейміз» дегенге айналдырады.

Блок 3. Трафик құрылымы категориялар бойынша (порттар бойынша емес)

Үлесті көрсетіңіз: бизнес-қосымшалар, инфрақұрылым (жаңартулар, бэкаптар) және «басқа» (бейне, әлеуметтік желілер, белгісіз). Бұл кескін NetFlow/sFlow есептеріндегі классификация негізінде жасалады, солайша басшылыққа полоса қайда кетіп жатқанын және не шектеуге болатынын айқын түсіндіруге болады.

Блок 4. Жұмыстың нашарлау себептері және салдары

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

Төменде «шешімдер блогын» қойып, қарапайым таңдауды ұсыныңыз:

• саясатты өзгерту (жаңартулар/бэкаптарды түнге ауыстыру, «басқа» категорияларын шектеу)
• каналды көбейту (егер бизнес-трафик тұрақты түрде шекті шектейді)
• қосымшаны оңтайландыру (бір сервис тұрақты шоқ жасаса)
• бақылауды орнату (келесі айға мақсаттар: шекараға жақын уақыт азайсын, инциденттер азайтылсын)

Мысал: филиал пиковые уақыттарда (9:00–12:00) тұрақты түрде 90%-дан асады, бірақ бизнес-қосымшалар тек 35% құрайды — қалғаны жаңартулар мен «басқа». Басшылыққа шешім қарапайым: алдымен жаңартуларды түнге ауыстыру және кейбір категорияларды шектеу, егер KPI жақсармайтын болса ғана каналды ұлғайту.

Қайнар көзді табудың қадамдық талдауы

Филиалда «бәрі баяу» болса, қолданушылар шағымданған нақты 10-20 минутқа түсу маңызды. Сонда NetFlow/sFlow есептері жылдам және дәл жауап береді.

Алдымен керек филиалды (немесе нақты WAN-каналды) және тар мерзімді кезеңді таңдаңыз. Ең дұрысы — сервис-десктен, чат хабарынан немесе қосымша логтардан алынған уақыт: мысалы, «сейсенбі 10:40–11:05». Содан кейін канал утилизациясының графигін ашып, деградация терезесін белгілеңіз: 90–100% өсу, шоқтар немесе тегіс «плато».

Одан соң тек осы терезе бойынша жұмыс істеңіз:

• таңдаған минуттар үшін Top talkers және Top applications-ты ашыңыз
• трафик көшбасшыларын қосылымдар саны бойынша салыстырыңыз: бір «қалың» поток пен мыңдаған кішкентай бір-бірінен басқа проблемалар туғызады
• пик резервтік көшіру, жаңартулар, синхрондау, бейнебақылау немесе видеоқоңырауларға сәйкес келмей ме тексеріңіз
• нәтижелерді интерфейс пен бағыт бойынша сүзгілеңіз, қай жерде тар жер екенін анықтаңыз: inbound немесе outbound

Күдікті көзді немесе қосымшаны тапқаннан кейін Top conversations-қа қарай тереңге түсу қажет. Ол жерде әдетте «кім кіммен, қай желіге, қандай портқа» айқын көрініп, бұл заңды жүктеме ме әлде жоқ па түсінікті болады. Мысал: бір бухгалтер ПК-сы 443 порт арқылы бұлтқа ондаған гигабайт жіберіп жатыр, ал қасында барлық жұмыс орындағы жаңарту серверінен ағылып жатқан поток бар.

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

Қорытынды қадам — қорытындыны тикетке тіркеу және әрекетті келісу. Көбінесе екі варианттың бірі таңдалады:

• приоритеттерді өзгерту (QoS) немесе тапсырманы түнге ауыстыру (резервтер, жаңартулар)
• нақты трафикті шектеу немесе блоктау, егер бизнеске қажет болмаса

NetFlow/sFlow есептеріндегі жиі қателіктер мен тұзақтар

Ең кең тараған мәселе — «деректер жоқ» емес, бірақ деректер осылай жиналғандықтан, олар бойынша тез жауап беру мүмкін емес: кім каналды жапты және неге — анықталмайды. Сонда NetFlow/sFlow есептері әдемі графиктерге айналып, әрекетке уақыт бермейді.

Бірінші тұзақ — sampling тым коғырлы және сақтау мерзімі тым қысқа. Қатты таңдау арқылы сіз тек «үлкен» потоктарды көресіз, ал кішкентай, бірақ тұрақты (жаңартулар, синхрондаулар, бұлт агенттері) жоғалып кетеді. Егер детальды деректер 1–2 күн ғана сақталса, «бүгін» мен «әдеттегі» салыстыру мүмкін болмайды, және қайталанатын ақаулар түсіндірілмей қалады.

Екінші тұзақ — филиал мен интерфейске байланбау. Егер есептер «құрылғы бойынша түгел» жиналып немесе бірнеше WAN-канал араласып кеткен болса, оңай дұрыс емес бөлімді немесе линкті айыптауға болады. Нәтижесінде провайдерлерге артық қоңыраулар басталады, ал шын мәселе резервтік каналда немесе ішкі интерфейсте болады.

Үшінші тұзақ — тек Mbps-қа қарау. Дауыстар мен ВКС үшін жоғалтулар, кешігу және jitter маңызды. Нақты кейс: канал тек 60% жүктелген, бірақ қолданушылар «роботталған» дыбыс туралы шағымданады. Себеп QoS кезектері немесе соңғы миляда пакет жоғалтулар болуы мүмкін; бір Mbps графигінен бұл көрінбейді.

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

Есептердің шатастырмауы үшін параметрлерді тексеріңіз:

• sampling пен агрегация периоды сіздің тапсырмаңызға сай ма (қысқа шыңдарды көруге мүмкіндік бар ма)
• сақтау мерзімі кемінде 2–4 аптаға жетеді ме
• филиал, канал және нақты интерфейс тегтері бар ма
• суретте тек жылдамдық қана емес, критикалық сервистер үшін жоғалтулар мен кешігулер де көрінеді
• қосымшаларға түсінікті категориялар берілген, тек IP:port емес

Қысқа чек-лист: мониторинг 5 минут ішінде жауап бере ала ма

Филиалда «интернет жоғалды» болса, ұзақ тергеуге уақыт жоқ. Жақсы мониторинг бірнеше кликте қай жерде тар орын, қашан басталған және кім/не жегенін көрсетуі керек.

Тексеріңіз, базалық диагнозды қолмен экспорт жасамай-ақ және күрделі сүзгілерсіз жасай аласыз ба:

• әр филиал үшін екі жылдам көрініс бар ма: «соңғы 15 минуттағы топ» (инцидент үшін) және «24 сағаттағы топ» (әдеттегі жүктемені түсіну үшін)
• бір қарапайым сүзгі қажетті каналды (интерфейс) және бағытты бөліп шығара ма: кіріс немесе шығыс трафик. Егер бұл үшін 5 шарт керек болса, маңызды уақытта уақыт жоғалады.
• «топ сөйлесулер» тізімі бар ма (кім кіммен) және дереу нақты уақытқа секіру мүмкіндігі бар ма, тек «сағаттық орташа» емес
• графикте нашарлау және қалпына келу сәттері минут бойынша көрінеді ме

Мониторингтің бизнестік тілде сөйлейтіндігін бағалаңыз:

• қосымшалар түсінікті категорияларда көрсетілген: пошта, ВКС, ERP/CRM, жаңартулар, бұлт сақтау
• басшылыққа арналған «1 беттік есеп» сақталған: не болды, қай филиал, қанша уақыт, қандай трафик себеп, қандай әрекеттер жасалды

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

Практикалық мысал: бір филиал, бір кінәлі, анық нәтиже

Таңертең, әдеттегі жұмыс күні. Филиал ERP-тің «тоқтап қалатынын» және видеоконференцияда дыбыс үзіліп-қосылатынын айтады. Пинг провайдерге салыстырмалы түрде қалыпты. Қажет — «жұмыс істемейді» емес, кім және немен каналды жаптығын анықтау.

NetFlow/sFlow есептерін ашып, терезені тарылтамыз: 10:05-те шығыс трафикте жылдам өсім басталып, 10:40-қа дейін қалыпқа келді. WAN жүктемесінің графигі outbound-тың толы екенін көрсетеді, сондықтан интерактивті қосымшалар (ERP, ВКС) бірінші болып зардап шегеді.

Әрі қарай тексеру минуттар ішінде өтеді: топ-дереккөздерде бір ПК шығыс трафиктің басым бөлігін беріп тұр. Проблемалы кезеңдегі Top conversations-қа қарасақ, бір сыртқы адресте көптеген ұзақ сессиялар, бір портпен және тегіс потокпен. Бұл ВКС немесе қарапайым вебке ұқсамайды — көбіне бұл үлкен жүктеу немесе синхрондау.

Тексерудің нәтижесін ИТ және бизнеске түсінікті фактілер түрінде бекітеміз:

• перегруз интервал: 10:05–10:40
• бағыт: шығыс трафик
• қайнар көз: бір филиал ПК
• сипаты: сыртқы адреске ұзақ сессиялар
• әсері: сол минуттарда ERP мен ВКС-те деградация

Шешім жергілікті: сол ПК-да күндіз архивтер жүктеліп жатқандықтан тапсырманы түнге ауыстыру, сол трафик класына шектеу қою және болашақта ұқсас оқиғалар үшін «бір хост N% шығыс каналды N минуттан ұзақ ұстаса» ескерту орнату. Бір аптадан кейін басқарушы есепте «жұмыс уақытындағы перегруз сағаттары» айтарлықтай төмендегені және ERP/ВКС шағымдарының тоқтағаны көрінеді.

Келесі қадамдар: енгізу және процесті бекіту

2–4 апта ішінде енгізу

Келісімдерден бастаңыз. Қай филиалдар мен каналдар маңызды екенін бекітпесеңіз, көптеген графиктер аласыз, бірақ аз жауап. Қысқа приоритеттер тізімін жасаңыз: негізгі филиалдар (табысы немесе қызметкерлер саны бойынша), негізгі каналдар (MPLS, VPN, интернет) және «өшірілмеуі тиіс» бизнес-қосымшалар (мысалы, 1С, CRM, видеобайланыс).

Сосын міндетті минимум есептерді анықтаңыз. Әдетте екі топ жеткілікті: ИТ үшін оперативтік (қазір не болып жатыр және кім шың жасады) және басшылық үшін управленческий (бизнеске не кедергі келтіруде, қайда өзгеріс керек немесе бюджет сұрау). Осы есептер логикасы барлық филиалдарда бірдей болу маңызды, әйтпесе салыстыру мүмкін емес.

Процесті күнделікті жұмысқа енгізу үшін қысқа жоспар жасаңыз:

• приоритеттерді бекіту: филиалдар, каналдар, қосымшалар, маңызды сағаттар (мысалы, 09:00–12:00)
• ИТ пен басшылыққа 5–7 міндетті метрика мен есепті бекіту және кімнің алатынын анықтау
• шектер мен ескертулер орнату: трафик шоқтары, жаңа тағайындаулар, «unknown» қосымшалардың аномалды өсуі
• әрекет регламентін дайындау: кім алерттерді қарайды, қандай әрекеттер рұқсат етілген (филиалға хабарласу, трафик класын шектеу, провайдерге тикет ашу)
• ырғақты енгізу: күнделікті тез шолу (5 минут) және апта сайын себептер мен өзгерістерді талқылау

Әдетке енгізу

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

Егер коллектор, сақтау және есеп инфрақұрылымы қажет болса, бұл жиі сенімді серверлер мен желіге қосылудың қалыпты интеграциясына тіреледі. Мұндай жұмыста GSE.kz (gse.kz) сияқты жүйелік интегратор көмектесе алады: мысалы, деректерді жинау және сақтау үшін серверлер қою (S200 Series тәрізді) және шешімді эксплуатацияға қолдау көрсету.