Cisco Catalyst 9300 лицензиялары: қалай артық төлемсіз таңдау жасауға болады

Catalyst 9300 таңдау кезінде қандай мәселе туындайды

Catalyst 9300‑ды жиі артық төлеп алатын себебі — қымбат опцияларды жақсы көргеннен емес, керісінше жетіспейтін функциялардан қорқу. Коммутаторды 5–7 жылға алады, ал талаптар 6–12 ай сайын өзгеруі мүмкін: 802.1X қосылады, дауыс пен видео өседі, жаңа кеңселер пайда болады, қауіпсіздік бөлімі көбірек бақылау сұрайды, басшылық желінің жай-күйін көргісі келеді. Осындай жағдайда лицензиялар мен функциялар «миналық алаңға» ұқсайды, сондықтан көбісі «аздаған қор» алып қоятын болады, кейін қайта жасамайын деп.

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

Шектеулер дереу байқалмайды. Типтік сценарий: бастапқыда желі «қалай болды» солай жұмыс істейді, ал жарты жылдан кейін жаңа тапсырмалар пайда болып, үш нәрсе жетіспейтіні айқындалады:

• порттардағы қауіпсіздік (қонақтық қолжетімділік, құрылғыларды есепке алу, NAC/802.1X‑ке дайындық)
• көрінушілік (телеметрия, түсінікті есептер, пайдаланушы проблемаларын диагностикалау)
• басқарылғыштық (біртұтас конфигурациялар, өзгерістерді бақылау, жылдам типтік енгізулер)

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

Міндет — бүгінгі қажеттілікті жабатын минималды жиынтықты таңдау (тұрақтылық, QoS, базалық қауіпсіздік), бірақ ертең NAC енгізгенде, телеметрияны арттырғанда немесе орталықтандырылған басқаруға өткенде шектеуге ұшыратпайтын болу.

Алдымен талаптар: лицензия таңдамас бұрын не шешу керек

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

Алдымен ортаның түрін бекітіңіз. Бірдей модельдегі коммутатор кеңседегі қабатта, оқу корпусында және ауруханада әр түрлі трафик пен қолжетімділік талаптарын қанағаттандырады. Аралас желіде әдетте Wi‑Fi, телефония, жұмыс орындары және IoT (камералар, сізаттар, датчиктер) қатар болады — бұл базалық талапты анықтайды.

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

Порттың «физикасын» тексеріңіз: қолжеткізу жылдамдықтары (1G, 10G, мультигига), аплинктер, стек жоспары, сондай‑ақ PoE және PoE‑буџеті. Мұнда қате лицензиядан гөрі ауыр салдарға әкеледі: жарты жылдан кейін Wi‑Fi 6/6E нүктелері немесе жаңа камералар қосылса, қуат та, порттар да жетіспеуі мүмкін.

Лицензиялық деңгейді таңдаудан бұрын бірнеше сұрақты жауып алыңыз:

• Аkses деңгейінде L3 (маршрутизация мен ACL) қажет пе немесе тек L2‑ден ядырға жеткізу жеткілікті ме?
• 802.1X пен сегментацияға дайындық керек пе?
• Қазір қандай аплинктер қажет және 12 ай ішінде порттар өсімі қалай болады?
• Қандай сервистер кешігулерге сезімтал (дауыс, видео, VDI)?

Мысал: екі ғимаратты кампус бүгін 1G және телефониямен жұмыс істейді, ал бір жыл ішінде 80 камера мен Wi‑Fi 6 қосылады. Егер бұл алдын ала белгілі болса, PoE, аплинктер және қолжетімділік саясаты талаптары бірден құрылады — шешім «сақтықпен» емес, ойластырылған болады. СИ мен интегратор жобаларында (мысалы, GSE.kz) мұндай сұрау шын мәнінде бюджеттен үнемдейді.

Лицензиялау моделі қысқаша: қайсысы не үшін жауапты

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

Бірінші қабат — аппараттық құрал. Ол бір рет сатып алынып, физикалық түрде сіздің иелігіңізде қалады.

Екінші қабат — базалық желілік мүмкіндіктер. Оларды Network Essentials пен Network Advantage сияқты сетевой деңгей лицензиялары анықтайды: VLAN, маршрутизация, ACL және басқа желілік функциялар. Әдетте бұл функциялар басқаруға жазылымға тәуелді емес және сақталады.

Үшінші қабат — Cisco DNA жазылымы (мысалы, Cisco DNA Essentials немесе жоғарырақ). Бұл коммутатор трафикті өшіре ме‑жеңгілейтіні туралы емес, оны қалай басқаруға болатыны: орталықтандырылған саясаттар, автоматтандыру, кеңейтілген телеметрия, аналитика, есептер және интеграциялар туралы.

Маңызды жайт — мерзімдер: жазылым аяқталса және оны ұзартпасаңыз, коммутатор әдетте сатып алынған желілік деңгейінде жұмысын жалғастырады. Бірақ Cisco DNA‑ға байланған функциялар құндылығын жоғалтады немесе қол жетімсіз болады. Smart Licensing бойынша заңдық сәйкестік мәселесін де ескеріңіз.

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

• Маршрутизация қажет пе және қандай протоколдар жоспарланып отыр;
• Келесі жылы орталықтандырылған басқару мен автоматтандыру болады ма;
• Кеңейтілген телеметрия мониторинг пен талдауға керек пе;
• NAC және 802.1X енгізу жоспарлары қаншалықты шұғыл;
• Жазылым мерзімі: 1, 3 немесе 5 жыл.

Сатып алу құжаттарына дұрыс жазу: «коммутатор тұрақты желілік функционалы деңгейі X және басқару жазылымы деңгейі Y мерзімі N жыл, ұзарту құқығымен». Бұл интегратор мен сатып алушы арасында түсініспеушілікті азайтады.

9300‑дегі QoS: қандай функциялар шынымен қажет

Кампустық желіде QoS «қашан да» қажетті емес, нақты трафик сыныптары үшін қажет. Әдетте үш топ жеткілікті: дауыс (IP‑телефония), видео (конференциялар) және бірнеше критикалық сервистер (VDI, ERP/1С, терминалдар). Қалғанына best effort қалдыру дұрыс, әйтпесе саясаттар тез өсіп, "бәрі маңызды" дау туындайды.

Практикада QoS екі сұраққа негізделуі керек: қай жерде сіз маркировкаларға сенесіз (DSCP/CoS), және қай жерде нақты кезектерді басқарасыз.

Қай жерде приоритет қою керек

Политика тек дұрыс нүктелер таңдалғанда жұмыс істейді:

• қолжеткізуда: пайдаланушылар мен телефондардан трафикті классификациялау және маркировка жасау, одан әрі желіде дұрыс меткалармен жүруі үшін;
• қолжеткізу аплинктерінде: кезектерді басқару және шоқтар кезінде микропотерядан қорғау;
• WAN шекарасында: реальды канал жылдамдығына бейімделген шейпинг және приоритеттер, себебі дәл осында кезек жиі толып қалады.

Есіңізде болсын: лицензия QoS‑тың орнын толтыра алмайды — дизайнның тәртібі маңызды. Көп проблема QoS бір жерде қосылып, қай жерде және кім метка қоятынын келіспегендіктен туындайды.

Трафикті классификациялау: нақты қандай іс‑әрекеттер

Кампустарда кішігірім сыныптардан бастап, нақты ережелерді орнату жақсы:

• Дауыс: тек IP‑телефоннан (немесе дауыс VLAN‑нан) сеніңіз, әйтпесе пайдаланушылар өздеріне приоритет қоя бастайды.
• Видео: бөлек сынып, бірақ дауысқа әсер етпеуі үшін шектеу қойыңыз.
• Wi‑Fi басқару және инфрақұрылымдық сервистер: аздаған, бірақ тұрақты приоритет беріңіз.
• Бизнес‑қолданбалар: келісілген порттар/адрестер бойынша, «барлық корпоративті» деген тұжырымды қолданбаңыз.

Tip: сенім нүктесін дұрыс таңдамасаңыз, мәселе болады. Мысалы, access портында DSCP‑ке сеніп қойған болсаңыз, оған ПК қосылып, EF меткасын жіберсе, «жалған дауыс» приоритетті толтырып, нақты дауысты зардап шегеді.

Телефония және Wi‑Fi командасымен үш нәрсені алдын ала келісіңіз: олар қандай DSCP қояды, қай жерде trust рұқсат етіледі және қай ағындар деградация жағдайында сақталуы тиіс (дауыс әрқашан бірінші, видео әдетте екінші).

NAC‑қа дайындық: кейінге қалса да не заложу керек

NAC‑дайындығы — желінің әртүрлі құрылғыларды саясатпен жіберуді білетін деңгейі: кім жұмыс желісіне кіре алады, кім бөлек сегментте болуы тиіс және кімді мүлде қабылдамау керек. Тіпті NAC (мысалы, Cisco ISE немесе басқа) кейін енгізілсе де, коммутаторлар қолжетімділік бақылаудың базалық механизмдерін қолдауы керек, әйтпесе дизайнды қайта жазуға тура келеді.

Кампуста бірнеше типтік құрылғылар болады: корпоративтік ПК, принтер, IP‑телефон, камера, қонақ. ПК үшін әдетте 802.1X арқылы рөл тағайындау керек. 802.1X‑ті қолдамайтын құрылғылар (принтер, кейде телефон, камера) үшін уақытша MAB (MAC‑авторизация) пайдалы. Қонақтарға ішкі ресурстардан оқшауланған бөлек сегмент қажет.

Catalyst 9300‑де алдын ала не заложу керек:

• access порттарда 802.1X пен MAB, бір порт түрлі құрылғылар үшін жарамды болсын;
• қонақтар мен «танылмаған» құрылғылар үшін бөлек VLAN/сегменттер;
• құрылғылар бойынша бастапқы сегментация, кейін рөл бойынша саясатты қосу оңай болсын;
• идентификация жоспары: есеп жазбалары қайда сақталады және "өздер" мен "бөтендер" қалай айырылады.

BYOD, ескі құрылғылар және қатаң аймақтарды бөлу жобаны күрделендіреді. BYOD болса, ережелер жылдам өзгеруі керек; ескі құрылғылар 802.1X‑ты қолдамаса, оларды MAB арқылы немесе оқшауланған сегментке шығаруды алдын ала шешіңіз.

Егер NAC кейін енгізілетін болса, желіні қазір тұрғызғанда қанша құрылғы түрі күтілетінін, қонақ қолжетімділігінің қажет екенін, қандай зоналар қатты бөлінуі тиіс (мысалы, жұмыс орындары мен камералар) және қай порттар телефон + ПК сияқты комбинацияларды қолдайтынын анықтаңыз. Бұл интеграторға функцияларды таңдау мен өсу кезінде шектеуге ұшырамау үшін көмектеседі.

Телеметрия мен мониторинг: пайдалы болатындай не қосу керек

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

Тез пайда беретін минимум: дұрыс логтар, SNMP, Syslog, оповещениелер және қарапайым инвентаризация. Бұл көбіне күнделікті инциденттерді жабады: «порт түсті», «CRC қателері», «широковещательный шторм шықты», «құрылғы қайта жүктелді». Деректерді жинап қана қоймай, шекті мәндер мен түсінікті оповещениелер орнату маңызды, әйтпесе оқиғалар шудың арасында жоғалады.

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

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

"Бәрін жинап, пайдаланбайтын жағдайға" жол бермеу үшін 5–7 метриканы таңдаңыз және әрбір срабатывание бойынша не істелетінін алдын ала жазыңыз:

• аплинктердің жүктемесі және top talkers;
• порттағы қателер (CRC, drops) және discards өсуі;
• шторм‑контроль және broadcast/multicast шоқтары;
• линк күйінің өзгерістері және жиі flap‑оқиғалар;
• кешігулер мен джиттер критикалық сегменттер үшін (егер өлшенсе);
• MAC кестесі және аномалиялар (жаңа MAC‑тердің шоқтары петля белгісі болуы мүмкін);
• температура және қуат (PoE‑буџет, қызып кету деградация себебі).

Таңдауда жиі ұмытып кететін функциялар және кейін өкініш

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

Стек және резервтеу: пайдалы, бірақ кейде күрделілікке қосымша шығын

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

VLAN, ACL және саясаттар масштабы: эксплуатация datasheet максимумынан маңызды

Көпшілік қате — қолжеткізуді "қалай шықса солай" жобалап, кейін жүздеген ACL және исключениямен өмір сүреді. 9300 бұлны ұстайды, бірақ іздеу уақыты мен қолдау күрделілігі өседі. Алдын ала ережелер мен стандарттар жасаңыз: қанша VLAN қажет, локальді исключенияның шегі, SVI, ACL және QoS класстарының атаулары.

Аплинктерді де жиі ұмытады. Бүгін 2x10G жетеді, ал ертең Wi‑Fi 6/6E мен сервер трафигі өскенде магистраль тар шегініс болуы мүмкін. 12–24 айға жылдамдық және оптика түрі бойынша жоспар жасаңыз, сонда модульдерді ауыстыру немесе кроссты қайта жасау қажеттілігі азаяды.

PoE‑буџет — классика: «впритык» есептеп қойып, кейін қосылған камералар мен AP‑лар шығып кеткенде қуат өшеді.

Соңғы тексеріс алдында мына сұрақтарды бір рет өтініз:

• Резервтеу бизнес тарабынан талап етіле ме немесе «қор үшін" жасалсын ба?
• 12–24 айға арналған аплинк жоспары бар ма (жылдамдық, оптика, порт резерві)?
• PoE есептелген бе және өсуге запас бар ма?
• Конфигурация стандарттары келісілген бе (шаблондар, атаулау, кім өзгертеді және қалай)?
• VLAN/ACL‑тағы қолмен жасалған исключения шектелген бе, желі қолдау мүмкіндігін сақтай ма?

Мысал: кампусқа жаңа Wi‑Fi нүктелері мен бақылау камералары қосылды, бірақ PoE запассыз есептелген және аплинк 10G қалдырылған. Нәтижесінде лицензия бойынша коммутатор көп функциялы болса да, қолданушылар кесір көреді. Бұл түзетуді жасау бастапқы қуат пен магистраль қарастырғаннан қымбатқа түседі.

Сіздің желіге арналған лицензиялар мен функцияларды таңдау қадамдары

Licenses таңдау прайс‑листен емес, желінің бүгінгі қолданылуы мен бір жыл ішіндегі жоспарыннан бастау керек.

Нәтиже беретін қадамдар

1. Желінің 3–5 негізгі сценарийін сипаттаңыз: дауыс, корпоративті Wi‑Fi, қонақтық қолжетімділік, камералар, 2–3 критикалық қолданба.

2. Талаптарды қабаттарға бөліңіз: «қалай қауіпсіздік», «L2/L3‑те не керек», «қолжеткізуда 802.1X, сегментация», «QoS және телеметрия қандай» — әр сценарий бойынша қажеттілікті белгілеңіз.

3. «Жүргізу үшін минимум» және «өсуге опциялар» тізімін және мерзімдерін құрыңыз. Минимум — жұмысқа қабылдау үшін міндетті нәрсе; опциялар — 6–12 айдан кейін қажет болатын элементтер. Бұл қай жерде базалық жиынтық жеткілікті, қай жерде бірден сақтықпен алу керек екенін көрсетеді.

4. Компанияңызда бар жүйелермен сәйкестікті тексеріңіз. Екі жиі кездесетін стоп‑фактор: таңдалған NAC жүйесі 802.1X пен құрылғы профилирлеу үшін нақты функция талап етеді, және ағымдағы мониторинг белгілі форматтағы телеметрияны күтуі мүмкін. Версиялар мен протоколдарды алдын ала салыстырып алу қажет.

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

Егер интегратор тартсаңыз, ол бұл логиканы «сценарий → функция → лицензия/опция → мерзім» таблицасында көрсетуі тиіс. Солайша өсу басталғанда шешім түсінікті болып қалады.

Мысал сценарий: орташа кампус және бір жыл ішіндегі өсу

Кампус: 3 корпус, шамамен 800 қызметкер/студент/мердігер, жұмыс орындарында IP‑телефония, аудиторияларда Wi‑Fi, тұрақты видеоқоңыраулар. Қолжеткізу деңгейіндегі коммутаторлар — Catalyst 9300, аплинктер ядырға, қуат пен аплинктер бойынша резерв бар.

Бастапқыда проблема көбіне лицензияда емес, қызмет сапасында болады. Дауыс пен видео сапасы нашар болса, пайдаланушылар күте қоймайды.

Жобаға бастапқыда міндетті түрде енгізетін минимум:

• дауыс пен видеоға арналған QoS: маркировка, кезектер, қажет порттарда DSCP‑қа сенім, «шулы» сегменттерден қорғаныс;
• базалық мониторинг: интерфейс есептегіштері, қателер, жүктеме, қуат және стек оқиғалары;
• резервтеу: қолжеткізу деңгейінде стек немесе резервті линктер және аплинк схемасы;
• мұқият сегментация: дауыс, корпоративтік құрылғылар және қонақтар үшін бөлек VLAN/VRF.

6–12 ай ішінде қонақ қолжетімділігі мен кезеңдік құрылғы бақылауды енгізу талаптары көбейеді. Бұл үшін алдын ала NAC‑дайындық қажет: порттарға 802.1X, принтер мен телефон үшін MAB, танылмаған құрылғыларға саясат және порт шаблондары («жұмыс орны», «телефон+ПК», «переговорная»).

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

Жиі кездесетін қателер және оларды қалай болдырмау

Ең қымбат қате — максимумды сатып алып, оны пайдалана алмай қалу. Лицензиялар мен функциялар тек дұрыс эксплуатациямен бірге мәнге ие болады: кім алерттерді қарайды, кім саясаттарды өзгертеді, кім дауыс пен Wi‑Fi сапасына жауап береді.

Көбіне кездесетін қателер

1. Кеңейтілген функцияларды өсімге алып алады, бірақ басқару платформасы мен регламенттер жоқ. Телеметрия бар, бірақ есептерды ешкім қарамайды.

2. PoE пен аплинктер жоспарланбаған. Бір жылдан кейін Wi‑Fi нүктелері мен камералар қосылады, коммутатор PoE шегіне жетіп қалған болады және аплинк тар шұңқырға айналады.

3. NAC‑ты кейінге қалдырады, бірақ желіні NAC‑қа дайындамайды. Порттар бірдей күйде, сегментация жоқ, карантин рөлдері ойластырылмаған. 802.1X қосқанда бүкіл бөліктерді қайта жазуға тура келеді.

4. QoS қосады, бірақ телефония, Wi‑Fi және ядро арасында маркировка келіспейді. Нәтижесінде дауыс «текетірес» етеді, дегенмен приоритет орнатылған.

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

Артық сатып алусыз қалай сақтану

Функцияларды нақты тапсырмалар мен жауаптылармен байланыстырыңыз:

• 12–18 айға өсімді бекітіңіз: қанша PoE‑құрылғы қосылады және қай жерде 2.5G/10G қажет;
• NAC‑дайындықты залождаңыз: порт шаблондары, рөлдер, қонақ VLAN және оқшаулау, бір корпусқа пилот;
• QoS‑ты end‑to‑end келісіңіз: кім меткаларды қояды (телефондар, Wi‑Fi контроллер), қай жерде сенім бар, қай жерде қайта маркировка қажет;
• мониторинг бойынша 3–5 пайдалы есепті анықтаңыз (мысалы, ең жүктелген аплинктер, порттардағы қателер, дауыс бойынша SLA) және кім қарайтынын көрсетіңіз;
• қысқа пилот өткізіңіз: бір коммутатор, бір қабат — қателер сонда арзанға шығады.

Мысалы: QoS IP‑телефония үшін қосылғанда, Wi‑Fi контроллері дауыс меткасын басқа қояды екен. Бір кездесу жеткілікті: телефония және желі командалары DSCP кестесін келіседі — мәселе лицензиясыз шешіледі.

Қысқа чек‑лист және келесі қадамдар

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

Сатып алудан бұрын чек‑лист

Бір бетке қысқаша жауаптар:

• трафик сценарийлері: офис қолданбалары, дауыс/видео, Wi‑Fi, видеобақылау, баспа, терминалдар;
• қуат және порттар: қанша PoE/PoE+ құрылғы, қуатта запас бар ма;
• аплинктер және өнімділік: 1/10/25G, коммутатор үшін неше магистраль, қай жерде тар шыңдар болуы мүмкін;
• резервтеу: екі аплинк жоғарыға, екі коммутатор шкафта, стек және әр түйіннің рөлі;
• 12 айға өсім жоспары: Wi‑Fi нүктелер қосу, 802.1X‑ке көшу, жаңа сегменттер, видеоконференциялар өсуі.

Қауіпсіздік бойынша NAC‑ты кейін енгізсеңіз де дайындық залождаңыз: қай жерде 802.1X, қай жерде принтер/телефон үшін MAB, қонақтық қолжетімділік қалай жұмыс істейді (бөлек VLAN/SSID, қолдану мерзімі, базалық ережелер). Алдын ала бұл анықталған сайын конфигурацияны қайта жазу ықтималдығы азаяды.

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

Пилотта не тексеріп, әрі қарай не істеу керек

Пилотта тек пинг емес, нақты тәуекелдерді тексеріңіз:

• жүктеме кезінде дауыс/видео (кезектер, приоритет, кешігулер);
• қонақтық қолжетімділік пен базалық саясаттар (кім қайға кіре алады);
• сенімділік (аплинк үзілу, стек түйінінің қайта жүктелуі);
• жаңарту және кері қайтару (тоқтаулар уақыты, үйлесімділік, процедура).

Содан кейін талаптарды жинап, QoS, NAC және мониторинг бойынша «қазір керек / кейін керек» матрицасын құрыңыз және соған сәйкес лицензияларды жазыңыз.

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