Желі таңертең баяуласа, себебін қалай табуға болады?

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

Диагностика қолданушы көрген кідірісті нақты ресурс және нақты трафик ағынымен бір уақыт шкаласында байланыстыруы керек. Ақауға дейінгі, ақау кезіндегі және одан кейінгі деректер қажет: қолданба кідірісі, интерфейс жүктемесі, пакет жоғалуы мен тасталуы, сервердің CPU, жады және дискілерінің күйі, сондай-ақ тапсырма журналдары. Бір таңғы түсірілім тек сәйкестікті көрсетеді. Екінші күні қайталануы және бақыланатын өзгеріс себептік байланысты дәлелдейді.

Таңғы ақауды алғашқы қоңырауға дейін ұстаңыз

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

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

Әр тексеруде басталу уақыты, аяқталу уақыты, нәтиже және межелі мекенжай болуы керек. Веб-қолданба 18 секундта ашылса, жолды DNS, TCP қосылымын орнату, TLS және алғашқы байтты күту кезеңдеріне бөліңіз. Баяу DNS жылдам TCP қосылымынан кейін алғашқы байттың ұзақ күтілуінен басқа жерді көрсетеді. Қолданушы бір үзілісті көреді, ал инженер оның қай кезеңде болғанын көруі тиіс.

Төрт қабатты бір уақытта жинаңыз:

• клиент: жүйеге кіру уақыты, DNS, TCP және қолданба әрекеті;
• желі: байттар, пакеттер, кезектер, тасталған пакеттер, қателер және қайта жіберулер;
• сервер: CPU, жады, диск кідірісі, желі интерфейсі және сұраулар кезегі;
• кесте: сақтық көшірмелер, жаңартулар, сканерлеу, синхрондау және пакеттік тапсырмалар.

Барлық порттағы бүкіл трафикті тұрақты жазудан бастамаңыз. Ол қажетсіз дерек үйіндісін жасайды және сізге керек емес мазмұнды ұстап қалу қаупін туғызады. Есептегіштер мен синтетикалық тексерулер уақыт аралығы мен желі бөлігін тарылтады. Трассаға қойылатын сұрақ белгілі болғанда ғана нақты екі торап арасында қысқа пакеттік жазба қосыңыз.

Бір уақыт шкаласы жалған болжамдардың жартысын жояды

Барлық дереккөзді бір уақыт шкаласына келтіріңіз, әйтпесе бір-біріне жақын оқиғалар бір мезгілде болғандай көрінеді. Клиенттерде, серверлерде, гипервизорларда, желілік жабдықта және сақтық көшірме жүйесінде сағаттың синхрондалуын тексеріңіз. Уақыт белдеуін жазып қойыңыз және нақты түрлендірусіз жергілікті уақытты UTC уақытымен араластырмаңыз.

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

Тек шыңдарды емес, шекараларды да белгілеңіз. Сақтық көшірме 08:00-де басталып, арна 08:03-те толса, қайта жіберулер 08:04-те өсіп, қолданба 08:05-те баяуласа, болжам қисынды. Қолданба 07:55-те-ақ баяу болса, көшірме алғашқы себеп бола алмайды, бірақ кейін жағдайды нашарлатуы мүмкін.

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

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

Жаппай кіру бірнеше түрлі жүктеме туғызады

Таңғы жүйеге кіру тек домен контроллеріне салмақ салмайды. Жұмыс станциясы мекенжай алады, DNS пен домен контроллерін табады, тіркелгі деректерін тексереді, саясаттарды қолданады, сценарийлерді іске қосады, желілік дискілерді тіркейді, профильді оқиды және автожүктеу бағдарламаларын бастайды. Бір мезгілде кірген жүз адам әр шағын әрекетті DNS, LDAP, Kerberos, SMB және профиль қоймасына бағытталған сұраулар толқынына айналдырады.

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

Windows ортасында бақылау станциясындағы Microsoft-Windows-GroupPolicy/Operational журналынан бастаңыз. Microsoft компаниясының Group Policy ақауларын анықтау нұсқаулығы бір саясатты қолдану оқиғаларын ActivityID арқылы байланыстырып, өңдеуді дайындық, негізгі және аяқтау кезеңдеріне бөлуді ұсынады. Бұл бір қызыл оқиғаны іздегеннен дұрысырақ: ұзаққа созылған сәтті кезең де кідіріс тудыруы мүмкін.

Қай кіру сценарийлері файл көшіретінін, қандай GPO пакет орнататынын, қандай дискілер тіркелетінін және көшпелі профильдер қайда орналасқанын тексеріңіз. Әр кірген сайын WAN арқылы үлкен каталогты салыстыратын бір сценарий анық қатесіз-ақ тұрақты толқын жасай алады. Оны салқын және жылы кэшпен бөлек өлшеңіз.

Домен контроллерлерінде аутентификация сұрауларын CPU, диск және желі интерфейсінің белсенділігімен салыстырыңыз. Windows Server 2025 жүйесінде Microsoft DC Locator және LDAP клиенті үшін жеке есептегіштер қосты. Олардың ішінде домен контроллерін сәтті және сәтсіз іздеу кідірісі, жаңа сұраулар, pending responses және average response time бар. Бұрынғы нұсқаларда жоқ көрсеткіштерді ойлап таппай, Netlogon, Directory Service, DNS журналдары мен жүйенің қалыпты есептегіштеріне сүйеніңіз.

Жаппай кірудің белгілері өзара үйлеседі: кіру саны күрт өседі, DNS пен домен контроллерлеріне сұраулар сол толқынмен келеді, профиль файлдарының сервері көптеген ұсақ файлды оқиды, ал алғашқы қолданушы сессиясы аяқталған соң мәселе басылады. Кэштің арқасында сол компьютерге екінші кіру жылдам өтсе, бұл қосымша белгі, бірақ желінің кінәсін дәлелдемейді.

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

Жаңартулар мен көшірмелер трафик бағытымен көрінеді

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

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

Бес белгіні салыстырыңыз:

• ақаулы уақыттағы ең ірі жіберушілер мен алушылардың мекенжайлары;
• тар интерфейстегі кіріс және шығыс трафик қатынасы;
• тапсырманың жоспарланған емес, нақты басталу уақыты мен көлемі;
• бастапқы және репозиторий дискілерінің кезегі мен кідірісі;
• жылдамдық шектеуі, параллель ағындар саны және қайталау әрекеттері.

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

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

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

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

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

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

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

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

Арнаның шамадан тыс жүктелуі кезек пен жоғалудан көрінеді

Жоғары пайдалану пайызының өзі шамадан тыс жүктелуді дәлелдемейді, ал төмен орташа мән оны жоққа шығармайды. Тар орынды сол аралықта өсетін кезек, жаңа тастаулар және кідірістің артуы растайды. Қысқа серпіліс кезінде интерфейс кешегідей орташа байт өткізуі мүмкін, бірақ интерактивті қолданба пакеттері үлкен тасымалдың артында күтеді.

Күмәнді бөліктің екі жағынан да есептегіш жинаңыз: клиенттің access-порты, коммутатор uplink-і, WAN интерфейсі, виртуалды коммутатор және сервер интерфейсі. RFC 2863 стандарты IF-MIB үшін ifHCInOctets, ifHCOutOctets, ifInErrors, ifOutErrors, ifInDiscards және ifOutDiscards есептегіштерін анықтайды. Олар түрлі өндірушіге жарайды, бірақ дельталарды салыстырып, құрылғының қайта іске қосылуын немесе есептегіштің нөлденуін ескеріңіз.

Қателер мен тастаулардың мағынасы бөлек. CRC және басқа input errors көбіне физикалық деңгейге, кабельге, оптикаға, трансиверге немесе параметрлерді келісуге апарады. Физикалық қатесіз discards әдетте толған кезекті, QoS саясатын немесе буфер жетіспеуін көрсетеді. Cisco компаниясының show interfaces құжаттамасы өсіп жатқан Total output drops мәнін шығыс кезектерінің толуымен тікелей байланыстырады, бірақ есептегіштің нақты мағынасы платформаға тәуелді.

Windows серверінде таңға дейін кіріктірілген есептегіштерді жинауды қосыңыз. Бұл команда айналмалы журнал жасап, желі, TCP, процессор, жады және дискілерді әр 15 секунд сайын өлшейді:

logman create counter MorningTrace -o C:\PerfLogs\MorningTrace.blg -f bincirc -max 1024 -si 00:00:15 -c "\Network Interface(*)\*" "\TCPv4\Segments Retransmitted/sec" "\Processor Information(*)\% Processor Time" "\Memory\*" "\PhysicalDisk(*)\*"
logman start MorningTrace

Ақаулы уақыт өткен соң жинауды тоқтатыңыз:

logman stop MorningTrace

Microsoft қысқа Task Manager қаралымы мәселені ұстамаса, ұзақ бақылауға Data Collector Sets қолдануды ұсынады. Желілік есептегіштер нұсқаулығында Bytes Sent/sec, Bytes Received/sec, Output Queue Length, қателер, тастаулар және TCP Segments Retransmitted/sec бар. Басқа мақаладан алынған шек сіздің базалық деңгейіңізді алмастырмайды: бірдей таңдарды және нақты интерфейстің өткізу қабілетін салыстырыңыз.

Linux жүйесінде sysstat тарихты алдын ала жинап тұрса, алғашқы ұқсас көріністі sar береді:

sar -n DEV,EDEV,TCP,ETCP -s 07:30:00 -e 10:00:00

DEV шығысынан rxkB/s және txkB/s, EDEV бөлімінен rxerr/s, txerr/s, rxdrop/s және txdrop/s, ETCP бөлімінен retrseg/s іздеңіз. Өріс атаулары нұсқаға қарай өзгеруі мүмкін, сондықтан деректермен бірге тақырып жолын да сақтаңыз.

Бақылау жұптары баяу серверді желіден ажыратады

Желі мен серверді ping командасымен емес, жолдың бір бөлігін ортақ пайдаланатын әрекеттерді салыстыру арқылы ажыратыңыз. Серверге тұрақты ping осы жағдайда шағын ICMP пакеттерінің өткенін ғана растайды. Қолданба DNS, TLS, веб-сервер кезегін, дерекқор құлпын немесе дискіні күтуі мүмкін, ал желілік құрылғы ICMP мен жұмыс трафигін әртүрлі өңдеуі ықтимал.

Бақылау жұптарын құрыңыз. Бір қолданбаға ақаулы сегменттегі клиенттен және серверге жақын клиенттен кіріңіз. Содан кейін ақаулы клиенттен сол жолдағы басқа қалыпты серверге кіріңіз. Қарапайым матрица шығады:

• Барлық сегменттен бір серверге ғана баяу: серверді немесе оған ең жақын қосылымды тексеріңіз.
• Бір сегменттен барлық серверге баяу: access, uplink, Wi-Fi немесе сегмент бағытын тексеріңіз.
• Атаумен баяу, IP арқылы жылдам: DNS пен атауды шешу ретін тексеріңіз.
• TCP тез қосылады, алғашқы байт кеш келеді: қолданбаны, дерекқорды, дискіні немесе сервер кезегін тексеріңіз.
• Бірнеше межелі жерге кідіріс пен жоғалу қатар өседі: ортақ желі бөлігін іздеңіз.

Мақсатты серверде сол секундта CPU, бос жады, paging, диск latency, сұраулар кезегінің ұзындығы және белсенді қосылымдарды өлшеңіз. Сервердің желі интерфейсіндегі жоғары жүктеме желіні бірден кінәлі етпейді: сервер сақтық көшірме ағынын өзі жасауы немесе диск салдарынан сұрауларға ұзақ жауап беруі мүмкін.

Бақыланатын екі торап арасындағы өткізу қабілетін тексеруге iperf3 жарайды. ESnet құжаттамасында клиент пен сервер JSON шығара алатыны, ал параллель ағындар -P параметрімен берілетіні жазылған. Бір қысқа ағыннан бастап, бағыттарды бөлек тексеріңіз:

iperf3 -c 10.20.0.15 -t 15 -J
iperf3 -c 10.20.0.15 -t 15 -R -J

Жүктеліп тұрған жұмыс арнасында көп параллель ағын қоспаңыз: сынақ қосымша трафик жасап, ақауды күшейте алады. Уақытты келісіңіз, сынақты шектеңіз немесе оқшауланған VLAN пайдаланыңыз. iperf3 екі торап арасындағы қолжетімді өткізу қабілетін көрсетеді, бірақ нақты дерекқор немесе файл әрекетінің кідірісін қайталамайды.

Қысқа пакеттік жазба күтудің қайда басталғанын көруге көмектеседі: SYN қайталана ма, TCP retransmission бар ма, деректі кім ұзақ растады, DNS қанша уақыт алды. Сағаты синхрондалған бір сессияның екі жағын да жазыңыз. Клиент жағындағы жалғыз жазба жолдағы жоғалуды сервер кідірісінен әрдайым ажырата алмайды.

Wi-Fi мен сымды желіге бөлек дәлел керек

Wi-Fi қолданушылары шағымданса, дәл сол әрекетті сол ішкі желіде немесе мүмкіндігінше ұқсас бағытта кабельмен қайталаңыз. Таңертең радиоортаның жағдайы өзгереді: клиенттер бірге оянады, кіру нүктелеріне көбірек құрылғы қосылады, эфир уақыты үшін бәсеке өседі, құрылғылар нүктелер арасында ауысуы мүмкін. Сымды uplink жүктемесі бұл кезде қалыпты болып қала береді.

Wi-Fi үшін әр радиодағы клиент санын, эфир уақытының пайдаланылуын, кадрларды қайта жіберуді, сигнал деңгейін, сигнал мен шу қатынасын, таңдалған арнаны және роуминг оқиғаларын қараңыз. Кіру нүктесінің Ethernet-портындағы жүктеме клиенттердің радиоэфир үшін қанша уақыт таласқанын көрсетпейді. Сигналы нашар екі клиент төмен жылдамдықта эфир уақытының шамадан тыс бөлігін алуы мүмкін.

Ноутбуктегі «Wi-Fi жолақтарына» қарап қорытынды жасамаңыз. Ол сигналды шамамен көрсетеді, бірақ бәсекені, кедергіні, қайта жіберулерді немесе кіру нүктесінен кейінгі кідірісті көрсетпейді. Контроллерден немесе кіру нүктесінен дерек және сол уақыттағы сымды бақылау сынағы қажет.

Кабель жылдам, ал радио баяу болса, қуатты арттырмай тұрып клиенттердің кіру нүктелері мен диапазондарға таралуын тексеріңіз. Тым жоғары қуат клиентті алыстағы нүктеде ұстап, арналарды қайта пайдалануды нашарлатуы мүмкін. Кабель де, радио да баяу болса, ортақ uplink, WAN немесе серверге оралыңыз.

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

Екі таң себептік байланысты көрсетеді

Дерек жинауды алдын ала дайындасаңыз, кезеңдік диагностика екі ұқсас таңға сыяды. Бірінші таң ақау орнын анықтауға, екіншісі бір бақыланатын өзгерісті тексеруге керек. Көшірме кестесін, QoS пен Wi-Fi баптауын бірден өзгертпеңіз: нәтиже жақсарса да, нақты не көмектескенін білмейсіз.

1. Алдыңғы күні нақты қолданушы әрекеті мен бақылау тораптарын таңдаңыз. Уақытты синхрондап, күмәнді интерфейстер мен серверлерде айналмалы жинауды қосыңыз, тапсырма кестелерін экспорттаңыз.
2. Бірінші таң симптомның басталуы мен аяқталуын белгілеңіз. Кезегі, кідірісі немесе тастауы қатар өскен алғашқы ресурсты тауып, ең ірі ағындарды атаңыз.
3. Күдікті себептің тәуелділіктерін тексеріңіз. Кіру үшін олар DNS, домен контроллері, GPO және профиль қоймасы; көшірме үшін бастапқы торап, желі және репозиторий; қолданба үшін веб-торап, дерекқор және диск.
4. Бір қайтарылатын өзгерісті таңдаңыз: тапсырманы жылжытыңыз, оның жолағын шектеңіз, параллельдікті азайтыңыз немесе клиенттердің сынақ тобын басқа ресурсқа бағыттаңыз.
5. Екінші таң сол өлшеулерді қайталаңыз. Күдікті фактор өзгеріп, сәйкес кезек жоғалып, қолданушы әрекеті жылдамдаса, болжам расталады.

Ойлау барысындағы қалыпты қатені қарастырайық. 08:10-да қолданушылар файл жүйесіне шағымданады, ал WAN 95 пайызды көрсетеді. Топ бірден кеңірек арна сатып алады. Ауыстырғаннан кейін шағым қалады: сақтық көшірме WAN-ды шынымен толтырған, бірақ файлдар жергілікті қоймада орналасқан, сол жерде көшірме оқу процесі диск кідірісін өсірген. Сервер жанындағы клиентпен жасалған бақылау жұбы WAN-сыз да файлдың баяу ашылатынын көрсетіп, арнаны ауыстырудан сақтар еді.

Басқа жағдай керісінше көрінеді. Сервер CPU-ы төмен, диск қалыпты, бірақ бірнеше алаңның клиенттері бір уақытта баяулайды. Орталық шығыс интерфейсінде ifOutDiscards өседі, ал таңғы жаңарту таратылымын шектеу тастауды да, кідірісті де жояды. Бұл жолы желі тар орын болды, ал кестені өзгерту механизмді растады.

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

Түзету графикті емес, кезекті жоюы керек

Түзетуді табылған механизм бойынша таңдаңыз. Жаппай кіруді кіру әрекеттерін қысқарту және уақытқа бөлу, қажет мазмұнды жергілікті орналастыру, DNS пен профильдерді түзету, кейде нақты қызметтің қуатын арттыру арқылы емдейді. Фондық тасымалға кесте, жолақ және параллельдік шектеуі көмектеседі. Жүктелген uplink ағындарды қайта бөлуді, дұрыс QoS немесе порттардың екі жағын тексергеннен кейін сыйымдылықты арттыруды қажет етеді.

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

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

Жөндеуден кейін жеңіл тұрақты бақылау қалдырыңыз: синтетикалық әрекеттің ұзақтығы, маңызды интерфейстер жүктемесі, errors және discards дельталары, TCP retransmits, сервер дискісінің кідірісі және ауыр тапсырмалардың нақты уақыт аралығы. Шекті өзіңіздің базалық деңгейіңіз бен ұзақтығыңыз бойынша қойыңыз, сонда рұқсат етілген бір секундтық шың кезекшіні оятпайды, ал он минуттық нашарлау бір сағаттық орташа мәнде жоғалмайды.

Күрделі инфрақұрылым үшін GSE.kz серверлік және желілік бөлікті бір жүйе ретінде жобалап, оны Қазақстан бойынша тәулік бойы қолдай алады. Бірақ интегратор да уақыт шкаласы мен өлшеуден бастайды: оларсыз жабдық сатып алу бәс тігу болып қала береді.

Зерттеуді тексерілетін тұжырыммен жабыңыз: «08:02-ден 08:27-ге дейін X тапсырмасы Y интерфейсі арқылы дерек жіберді, онда шығыс тастаулары өсті, ал келісілген жылдамдыққа шектегеннен кейін Z әрекетінің кідірісі базалық деңгейге қайтты». Осындай сөйлем жаза алмасаңыз, себеп әлі табылған жоқ.