Cisco Catalyst-ты үзіліссіз жаңарту: ISSU, стек және артқа қайтару

"Үзіліссіз" практикада нені білдіреді

"Үзіліссіз" әрдайым "бірде-бір үзіліссіз" деген сөз емес. Көбінесе бұл пайдаланушылар үшін байқалатын қызметтің тоқтауынсыз өтуін және жаңарту ықпалын алдын ала келісілген шегіне сыйғызуды білдіреді.

Cisco Catalyst жаңарту кезінде формальды түрде үзіліс болып саналатын, бірақ шын мәнінде сезілмейтін қысқа оқиғалар жиі рұқсат етіледі: кейбір порттардың секундтық қайта қосылуы, LACP қайта келісімі, маршрутизация кестелерінің жаңаруы, STP root-тың қайта сайлануы, ауысу кезінде бірер жоғалған пакет.

Жұмыс соңында дау-дамайсыз болу үшін бизнеcпен табыс критерийлерін алдын ала келісіп, оларды өлшенетін етіп жазып алыңыз:

• Wi‑Fi немесе сымды қосылымдағы клиент үшін 1-ден артық емес қысқа қайта қосылу
• критикалық қосымшалар үшін X секундтан артық деградация болмауы
• жұмыс орындарында қолмен әрекеттерге жол бермеу
• жұмыстардан кейін негізгі сервистерді тексеру

ISSU қолданған кезде де "микро-пауаздар" болуы мүмкін. Олар буферсіз және үздіксіз трафик бар сервистерде айқын байқалады: IP-телефония, колл-орталықтар, төлем терминалдары, бейнебақылау, VDI, VPN-сессиялар.

Мысалы: кеңседегі қолданушы порттың 2 секундтық қайта келісімін байқамауы мүмкін, ал колл-орталық операторы сөйлемнің үзілетінін естиді. Сондықтан "үзіліссіз" — бұл күтулер, метрикалар және жаңартуды қай сервистер шыдайтынын анықтау туралы.

Сіздің Catalyst ISSU және үзіліссіз жаңартуға жарай ма

Бесшовты жаңарту тек нақты артықшылықтар болғанда мүмкін. Қолданушы деңгейінде бұл көбінесе бір құрылғыдағы қысқа үзіліс маңызды емес екенін білдіреді (пайдаланушылар Wi‑Fi арқылы қалады немесе резервтік uplink-ке ауысады). Дистрибуцияда және ядро деңгейінде жұп құрылғы немесе резервті supervisor шасси болмаса, көбіне "минималды тоқтау" шығады, бірақ нөл болмайды.

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

Содан кейін платформа мен конфигурацияда бесшовты ауысуды қамтамасыз ететін механизмдердің бар-жоғын тексеріңіз: SSO (stateful switchover) және NSF (non-stop forwarding). Олар қолдамаса немесе қосылмаған болса, ISSU оңайша кәдімгі қайта жүктеуге айналуы мүмкін.

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

• нақты модель және режим: жеке коммутатор, стек, шасси, StackWise Virtual
• резервтеу бар ма (LACP/ECMP жұп, HSRP/VRRP, екі uplink әртүрлі құрылғыларға)
• сіздің IOS XE тармағыңызда сіздің схемада ISSU қолдау бары (функциялар, лицензиялар, стек түрі)
• ағымдағы және мақсатты нұсқалар анықталған ба, тікелей апгрейд бар ма
• "қуат бірлігі" не болады: бір коммутатор, бүкіл стек немесе supervisor

Шешім қабылдауға деректер қажет: командалармен жай-күйді алыңыз және шығуды файлға сақтаңыз (ол откат үшін де керек болады):

show version
show redundancy
show platform
show switch (для стека)

Мысалы: егер сізде бір кішігірім кеңседе бір Catalyst болса және барлық жұмыс орындары оған тәуелді болса, ISSU көмектеспейді — кез келген жаңарту тәуекел. Ал егер дистрибуцияда FHRP бар және uplink-тері дублирленген жұп коммутатор болса, ISSU және SSO/NSF жаңартуды сессия жоғалтпай өту мүмкіндігін береді, бірақ тек модель, нұсқа және қолдау функциялары сәйкес келгенде ғана.

Образдар, үйлесімділік және құрылғыдағы орынға дайындық

Бастамас бұрын командалардан гөрі мына нәрселерді тексеріңіз: таңдаған IOS XE нұсқасы сіздің жабдыққа және ағымдағы жүктеу режиміне сәйкес келе ме.

Мақсатты IOS XE нұсқасын коммутатор моделімен, Supervisor типімен (бар болса), жад көлемімен және лицензияларымен салыстырыңыз. Кейбір функциялар (шифрлау, Network Advantage, DNA) нақты лицензияны талап етуі немесе белгілі релиздерге өтуге шектеу қоюы мүмкін.

ROMMON талаптарын бөлек тексеріңіз. Кейбір модельдер мен тармақтарда ROMMON жаңартуы міндетті және ол кейде қайта жүктеуді қажет етеді. Егер өндіруші аралық релизді ұсынса (алдымен X-ке, одан кейін Y-ге өту), оны жоспарға енгізген дұрыс.

Образды жүктер алдында құрылғының қай режимде жұмыс істейтінін анықтаңыз:

• Install mode (packages.conf және пакет жиынтығы) әдетте ISSU және болжамды апгрейдтер үшін қолайлы.
• Bundle mode (.bin арқылы тікелей жүктеу) қарапайым, бірақ бесшовты жаңартуға шектеу қоюы мүмкін.

Flash-та жаңа образға ғана емес, резервтік көшірмеге де жеткілікті орын бар екеніне көз жеткізіңіз. Минимум: ескі .bin (немесе пакеттер) үшін орын, ағымдағы packages.conf және уақытша файлдарға қойылатын орын запас.

Образды көшіргеннен кейін контрольдік сомманы тексеріңіз. Типтік командалар мысалы:

show version
show boot
dir bootflash:
verify /md5 bootflash:<image>.bin

Егер құрылғыда аз бос орын қалса, файлдарды ретсіз жоймаңыз. Алдымен құрылғының қазір немен жүктелетінін және откат үшін нақты қандай файлдар қажет екенін бекітіңіз. Catalyst-те install mode кезінде қате пакет жою құрылғының қажетті релизде жүктелмеуіне әкелуі мүмкін.

Окноға дейінгі тексерулер (pre-checks)

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

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

Құрылғының аппараттық және денсаулық көрсеткіштері

Қуат пен салқындатуды тексеріңіз: екі БП бар ма (бар болса), вентиляторлардың күйі, температура, қуат журналдары. Порттардағы қателерді де алдын ала қараңыз: аплинктегі CRC немесе input errors өсімі протоколдарды қайта іске қосқанда "үзіліссіз" режимді қысқа үзілістерге айналдырады.

Жүктемені бағалаңыз: CPU және жад, flash-та бос орын, crashinfo. Егер crashinfo бар болса, оның себебін анықтау жақсы, бір уақытта екі оқиғаға кірісуден гөрі.

Резервтеу және критикалық кестелер

Резервтеу шын мәнінде жұмыс істейтінін тексеріңіз, тек "дөңгелекте" емес. Аплинктердің біреу ғана емес екеніне, EtherChannel дұрыс жиналғанына және HSRP/VRRP күтілген рөлдерде (active/standby) екеніне көз жеткізіңіз.

Окно алдында жиі қажет кестелерді тіркеңіз: ARP, MAC, маршруттар (немесе дефолтты маршрут), STP күйі (root/port roles). Жаңартудан кейін бір сегментке қатынау мәселесі болса, MAC/ARP/STP салыстыруы трафиктің басқа аплинкке ауысқанын немесе root bridge-тің өзгергенін тез көрсетеді.

Pre-checks соңында сізде фактілер жинағы болуы керек: құрылғы тұрақты, резервтеу жұмыс істейді және салыстыруға алатын эталон бар.

Окно басталардан бұрын қысқа чек-лист

Окно басталардан бұрын апаттық сценарийде де құрылғыны басқара алатыныңызды тексеріңіз. Бұл 3-5 минут алады, бірақ көбінесе ұзақ қалпына келтіріп алу уақытынан үнемдейді.

Басқаруға қол жеткізуді тексеріңіз: консоль бар ма (орында немесе консоль-сервер арқылы) және резервтік жол бар ма. Жақсы минимум - жеке OOB-канал немесе management интерфейсіне екінші тәуелсіз маршрут. Логиндер мен құқықтар барын, құрылғы уақыты синхрондалғанын тексеріңіз.

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

Шешім қабылдау нүктелерін алдын ала келісіңіз: кім "go/no-go" шешімін қабылдайды және қандай сигналдарға қарай. Әдетте 2-3 тоқтату триггері жеткілікті: басқару жоғалту, көршіліктің тұрмауы, қайта жүктеуден кейін журналдарда критикалық қате.

• Қол жеткізу: консоль + резервті басқару арнасы (OOB/екінші жол), логиндер мен құқықтар тексерілген.
• Образ: орналасуы мен контрольдық сомма тексерілген, жылдам жеткізу жоспары бар (негізгі және сақтық).
• Шешімдер: "go/no-go" жауаптысы тағайындалған, тоқтату және откат критерийлері бекітілген.
• Мониторинг: жұмыстардан кейін күшейтілген бақылау келісілген (әдетте 15-30 минут) және не қарайтынымыз анықталған.
• Байланыстар: қосымша иесі, дежур инженер және провайдер/оператор байланыста.

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

Қадамдық жоспар: жеке Catalyst, IOS XE және ISSU

Жеке коммутаторда негізгі шарт қарапайым: платформа және конфигурация ISSU-ны қолдауы керек, және құрылғы install mode-да болуы тиіс (IOS XE пакеттер жиынтығынан жүктеледі, бір монолиттік image емес).

Жаңарту қадамдары (install mode және ISSU)

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

Келесі ретпен жұмыс істеңіз:

• Жаңа образды құрылғыға көшіріп, контрольдық сомманы тексеріңіз (вендордан алынған болса).
• install add орындап, аяқталуын күтіңіз, кейін пакеттердің дұрыстығын verify арқылы тексеріңіз.
• install activate арқылы (немесе платформаға және нұсқаға байланысты ISSU командасын қолданып) жаңа жиынтыққа ауысуды бастаңыз.
• Активтеу кезінде SSO және NSF-тің қалыпты жұмысына, күтпеген ажыратулардың болмауына бақылау жасаңыз.
• Жаңа нұсқа табысты жұмыс істей бастағанда install commit орындап, жаңартуды тұрақтандырыңыз.

Ауысу кезінде бақылау керек нәрселер

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

Тез расталатын критерийлер: порттар күтілген күйде, журналдарда қайталанатын қателер жоқ, негізгі VLAN және uplink жұмыс істеп тұр, CPU мен жад үздіксіз жоғарыға шықпаған, ал негізгі тексерістер (gateway-ге ping, критикалық сервистерге қолжетімділік) нашарламай өтіп жатыр.

Қадамдық жоспар: Catalyst стекін жаңарту

Стек әдетте rolling upgrade арқылы жаңартылады: мүшелердің бір бөлігі қайта жүктеліп, желі резервтеу есебінен жұмысын жалғастырады. Егер резервтеу uplink деңгейінде дұрыс жасалса, бұл "үзіліссіз" тәрізді өтеді.

Алдымен стектің ағымдағы күйін бекітіңіз: кім active, кім standby, мүшелердің нөмірлері және приоритеттері. Рөлдер күтпеген жағдайда ауысса, қосымша перезагрузка туындауы мүмкін.

Окно алдындағы тексерулер

• барлық мүшелер стекта көрініп тұр, "жартылай өлі" мүшелер жоқ
• StackWise кабельдері мен байланыстардың күйі (қателер, флаппинг) қалыпты
• барлық мүшелерде жүктеу режимі мен IOS XE нұсқасы сәйкес
• образ барлық мүшелер үшін қолжетімді және орын жеткілікті
• конфигурация сақталған, рөлдер мен приоритеттер жазылған

Rolling upgrade кезінде жеке порттар қысқа уақытқа жыпылықтауы мүмкін және резервсіз access құрылғылары қайта қосылуы ықтимал екенін тағы бір рет келісіңіз.

Жаңарту тәртібі (типтік)

1. Барлық members-ке бірдей образ пен бір режимді сәйкестендіріңіз.
2. Стекте орнатуды/активацияны бастаңыз және мүшелердің бірден емес, кезекпен қайта жүктелуіне бақылау жасаңыз.
3. Келесі мүшені қайта жүктеуге көшу алдында standby-нің active қызметті алу үшін дайын екеніне (SSO) көз жеткізіңіз.
4. Барлық мүшелер толығымен стектің құрамына оралғаннан кейін ғана нәтижені бекітіңіз.

Мысалы, 4 мүшелі стек пен 1 және 2 мүшелерде критикалық uplink бар болса, алдымен 2 мүшенің standby күйінің дайын екеніне көз жеткізіп, содан кейін 1 мүшені перезагрузкаға жіберіңіз.

Жұмыс аяқталғаннан кейін версиялар теңелгенін, стектің қатесіз құрылғанын және рөлдер сақталғанын тексеріңіз.

Откат жоспары: қашан және қалай кері қайту керек

Откат қажет емес дегеннен гөрі, мәселе туындаған жағдайда қызметті тез қайтаруға мүмкіндік беру үшін маңызды. "Қайтарылмайтын нүкте" — commit. Commit жасалмайынша кері қайту әдетте оңай және жылдам.

Қай нүктеден кейін тез қайту мүмкін емес

ISSU немесе install процесінде құрылғы "ескі" және "жаңа" пакеттерді қатар ұстай алады. Commit жасалмағанша сіз жаңа нұсқаны сынақтан өткізіп жатасыз. Commit-тен кейін жүйе жаңа нұсқаны негізгі деп санайды, ал откат көбіне толық қайта жүктеу мен бұрынғы образды қолмен жүктеуді талап етеді.

Алдын ала "Plan B" дайындаңыз: бұрынғы образ flash-та қолжетімді болуы және жүктеу конфигурациясы анық болуы тиіс.

Оралу нұсқалары және айырмашылықтары

• Rollback (install/ISSU арқылы) — егер әлі commit жасалмаса және бұл әдіс қолдаулы болса ең жылдам жол.
• Install remove — белсенді емес пакеттерді тазалайды, бірақ ескі нұсқаға қайтармайды.
• Қолмен жүктеу — нақты қандай image немесе packages.conf-тан жүктеу керектігін көрсетіп қайта жүктеу; ең ауыр, бірақ кейде қажет жол.

Откат шешімін симптомдарға негіздеп жасаған дұрыс, сезімге емес:

• STP петлялары, массовый topology change, control plane-да CPU-ның күрт өсуі
• көршіліктің құлауы (HSRP/OSPF/BGP), порттарда flapping
• интерфейстердегі қателердің күрт өсуі, критикалық PoE порттарының жұмысының тоқтауы
• пайдаланушы шағымдары, метрикалармен расталған (латенттілік, үзілістер, қосымшалардың деградациясы)
• жағдай қарапайым әрекеттермен тұрақтанбайды (конфигурацияны кері қайтару, проблемалық фича-флагты өшіру)

Коммуникация да жоспардың бөлігі: кім откат бастайды, кімге хабарланады және журналға не жазылады:

• откат басталған уақыт және себеп (1-2 сөйлем)
• откат командасы/әдісі, нақты не істелгені
• көршілік пен негізгі сервистердің күйі до және кейін
• кім хабарланған (NOC, сервис иесі, қауіпсіздік)
• нәтиже: қайтарылды немесе жаңарту жалғастырылды

Мысалы: жаңа нұсқаға өткеннен кейін STP өзгерістері басталып, бірнеше стек мүшелерінде uplink-тер құлап жатқан кезде commit жасамай тоқтаңыз, симптомдарды тіркеңіз және rollback орындап, мәселені окнодан тыс талдаңыз.

Окно соңындағы тексерулер (post-checks)

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

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

Содан соң негізгі тәуекел нүктелерін қараңыз:

• Интерфейстер: критикалық порттар up, жылдамдық/duplex дұрыс, қателер мен дроптар өсімсіз.
• PoE: AP/телефондар қуат алады, power-deny жоқ.
• L2/L3: STP тұрақты, LACP порт-каналдар қалыпты, маршрутизация (OSPF/BGP) full/established күйінде.
• Пайдаланушы перспективасы: корпоративтік жүйелерге кіру, телефония, Wi‑Fi, файл ресурстарына қолжетімділік бірнеше сегменттен тексеріледі.
• Жүйелік денсаулық: CPU/жад қалыпты, температура қалыпты, журналдарда жаңа alarm/critical жоқ.

Жылдам растау үшін типтік командалар жиынтығын орындаңыз (модель/нұсқаға сәйкес атаулар өзгешелеуі мүмкін):

show version
show logging | last 50
show interfaces status
show interfaces counters errors
show power inline
show spanning-tree summary
show etherchannel summary
show ip ospf neighbor
show ip bgp summary

Соңында конфигурацияны сақтап, жаңа эталондық "снимогын" (версиялар, стек рөлдері, негізгі счетчиктер және көршіліктер) тіркеңіз және өзгеріс журналына тіркеңіз. Бұл кейінгі талдауды тездетеді, егер біреу "жаңартудан кейін нашарлады" десе.

Жиі болатын қателер мен тұзақтар

Көбінесе окно платформалық шектеулерді тексерместен іске кірісуден сәтсіз болады. Бесшовты сценарийлерде ISSU бәрін өзіңіз жасайды деп ойлауға болмайды: кішкене детальдер жоспарды бұзады.

Үйлесімділік: ROMMON және жүктеу режимі

ISSU немесе қайта жүктеу ROMMON мен жүктеу режимін тексермегенде дұрыс өтпеуі мүмкін. Типтік оқиға: жаңа IOS XE жүктелгеннен кейін reloadтан кейін құрылғы ROMMON-ға түсіп қалады, себебі boot-параметрі ескі немесе ROMMON үйлеспейді, ал қашықтан қол жеткізу жоқ.

Окно алдынан негізгі заттарды тексеріңіз:

• ROMMON нұсқасы мақсатты релизге және модельге сай
• жүктеу режимі (install/bundle) жоспармен сәйкес
• flash-та пакеттер мен журналдар үшін орын жеткілікті
• файл нақты сіздің платформа мен лицензияға арналған

Сөздегі "резервтеу"

ISSU көмектеспейді, егер шын мәнінде резервтеу болмаса. Бір ғана аплинк, бір ғана БП, бір басқару жолы — бәрі бір кабельге тәуелділік демек. Көбінесе актив супервизор ауысқанда MAC немесе порт рөлдері өзгере салып, аплинк секундтық жарқ етіп, екінші аплинк өшірулі немесе дұрыс конфигурацияланбағаны анықталады.

Стек: әртүрлі приоритеттер мен "өлген" standby

Стек "бір құрылғы" секілді көрінеді, бірақ бірнеше коммутатордан тұрады. Әр түрлі приоритеттер, әр түрлі нұсқалар, standby-ның дайын еместігі master-дің күтпеген таңдалуына және қосымша қайта жүктеулерге әкеледі. Кейде бір мүшенің оқиға алдындағы көрінбейтіндігі тек жаңарту кезінде байқалады.

Commit-ті тым ерте орындау және апаттық қолжетімділіктің болмауы

Commit-ті жобағаннан кейін бірден орындап қою жиі кездесетін қате — бақылауға уақыт қалмайды. Желінің жүктеме астында қалай жұмыс істейтінін бақылап, аплинктер мен көршіліктерді тексеріп, журналдарды қарап, содан кейін ғана commit жасаған дұрыс.

Егер басқару желісі арқылы қолжетімділік жоғалса, консоль және анық жоспар болмаса, откат ұзаққа созылады, тіпті техникалық түрде мүмкін болғанымен.

Мысал сценарий: қызметті тоқтатпай жаңарту

Орташа ұйым мысалын алыңыз: серверлік бөлмеде 2 коммутатары бар стек (ядро/агрегация), ал басқа ғимаратта 2 қатынау коммутаторы жұмыс істейді, оларға жұмыс орындары мен телефония қосылған. Талап — пайдаланушылар үшін байқалатын үзіліссіз, тек секундтық ауысулар рұқсат етіледі.

Окнодағы күннен бір күн бұрын команда "сухой прогон" жасап, фонында қауіпсіз орындалатын тексерістерді түнде орындайды: модельдер мен нұсқаларды салыстыру, қуат пен резерв сызықтарын тексеру, flash орын мен контрольдық сомманы тексеру, CPU/порт қателері/HSRP/VRRP немесе стек статусын жинау, коммуникация жоспарын дайындау. Түнде образдарды құрылғыларға көшіріп, конфигурацияларды сақтайды, осылайша окнода файл беру уақытын үнемдейді.

Окно 60-90 минут ішінде рөлдер бойынша өтеді: бір инженер консольмен және командалармен жұмыс істейді, екіншісі мониторинг пен критикалық сервистерді (телефония, ERP, серверлік қолжетімділік) бақылайды, үшіншісі орындықтағы дежурмен байланыста. Негізгі бақылау — "ПО жүктелді ме" емес, "трафик өміршең бе": gateway-ге ping, тест сервистерге қолжетімділік, uplink-тердегі қателер мен дроптардың өсуі.

Откат шешімі фактілерге негізделеді. Мысалы, стек мүшесінің перезагрузкасынан кейін SSO қалпына келмесе, магистраль порттарда қателер көбейсе немесе критикалық VLAN келісілген шектен (3-5 минут) ұзақ үзіліп қалса, алдын ала келісілген қадамдар бойынша бұрынғы образға оралады.

Окно соңында артефактілер сақталады: версиялар мен стек/рөлдер күйінің до және кейінгі шығуы, оқиғалар журналы уақыт белгілерімен, критикалық интерфейстердегі счетчиктердің «до» және «кейін» суреттері, 3-5 эталон сервистің қолжетімділігін растайтын нәтижелер, соңғы конфигурация файлы және орындалған өзгерістер тізімі.

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

Бесшовты жаңарту — бір ретті сәттілік емес, қайталанатын процесс. "Жаңарту стандарты" көмектеседі: біркелкі версиялар, құрылғылардың түсінікті рөлдері және әр жолы бірдей тексерістер.

Жақсы тәжірибе — сіздің Catalyst модельдеріңізге арналған "алтын" IOS XE нұсқасын таңдап, оған жоспарлы түрде (мысалы, тоқсан сайын немесе әр жартыжылдықта) өту. Осылай бірнеше релизге бірден секіріп, үйлесімсіздіктерге тап болу қаупі азаяды.

Жұмыс стандартына әдетте кіреді: pre-check/post-check шаблондары (командалар, күтілетін мәндер, кім растайды), образдар мен бэкаптарды сақтау ережесі, окноны тоқтату критерийлері, жаңарту күнтізбесі және минималды откат жоспары, оны тест ортада кемінде бір рет тексерген болу.

Бақылауды қамтамасыз ету қажет. Егер симптомдарды алдын ала көрмесеңіз, сәтті өткен окно кейін шағымдарға ұшырауы мүмкін. Бастапқы мониторинг жеткілікті: жүйе және стек оқиғалары (қайта жүктеулер, split-brain, master-дің өзгеруі), порт қателері (CRC, input/output errors, flaps), канал сапасы (жоғалту, кешігу, jitter), қуат пен орта (PSU, PoE бюджеттілігі, температура).

Сондай-ақ аппараттық шектеулерді тексеріңіз: бір ғана қуат көзі, асып кеткен PoE, резервсіз uplink, порттар лимитіне жеткен жағдайлар. Көп жағдайда бесшовды тексерістің үзілуіне дәл солар себеп болады, образ емес.

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