Cisco IOS‑XE және NX‑OS жаңарту алдындағы чеклист: үйлесімділік

Неліктен апгрейд алдындағы чеклист қажет және ол не істейді

Cisco IOS‑XE немесе NX‑OS жаңартуы жиі қарапайым көрінеді: образты көшіріп, перезагрузка жасап, тексеріп қоясыз. Шындығында ақаулар көбінесе дәл сол жаңарту айналасында қалған ұсақ‑түйектерден шығады, олар алдын ала тексерілмеген.

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

Алдын ала чеклист үш міндетті шешеді: болжамдылық, жылдам қалпына келтіру және сәттілік критерийлерінің анық болуы. Ол алдын ала тексеруге көмектеседі: аппараттық құралдар мен ресурстар (жад, образдар үшін орын, модульдердің жағдайы), релиздің шектеулері, нақты конфигурация мен пайдаланылатын функциялар, лицензиялар мен тәуелділіктер (VRF, EVPN, FEX, ISSU, шифрлау, TACACS/RADIUS және т.б.), сондай‑ақ откатқа дайындығы.

Шығар нәтижесінде нақты артефакттар болуы тиіс:

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

Жүйелік интеграция жобаларында (мысалы, желі аурухана немесе банк қызметін қамтамасыз етсе) мұндай чеклист сағаттар бойғы тоқтауды үнемдейді: шешімдер алдын ала қабылданады, апат сәтінде емес.

Инвентаризация: әрбір құрылғыдан не білу керек

Жұмыс терезесін ашпас бұрын инвентарь жинаңыз. Бұл IOS‑XE және NX‑OS жаңартуы үшін база: нақты деректерсіз образды, лицензияны немесе тіпті перезагрузка тәртібін дұрыс таңдамау оңай.

Әр құрылғыға қысқа карточка жасаңыз — тек жаңартуға және тоқтауға әсер ететін нәрселер:

• модель, сериялық нөмір, рөлі (ядро, қол жеткізу, шекара), орналасқан жері және қызметтің критикалылығы
• ағымдағы ПО нұсқасы, ROMMON/BIOS нұсқасы (қолданылса), uptime және соңғы перезагрузка күні
• жұмыс режимі: standalone, stack/StackWise, vPC/VSS, FEX, dual‑sup, ISSU (қолдансаңыз)
• образдардың орналасқан жері және bootflash/sup‑bootflash‑тағы бос орын мөлшері
• жауапты тұлға және егер желі ішінара құлсын кім арқылы кіру (OOB, консоль, консоль сервер)

Сосын конфигурацияны сақтап, есте қалдыру қиын бөліктерді тіркеңіз: интерфейстер тізімі мен тағайындалуы, VRF, маршрутизация (OSPF/BGP/EIGRP), QoS, ACL, NAT, DHCP, NTP, SNMP, TACACS/RADIUS.

Арнайы ескеріңіз: EEM‑апплеттер, кастом скрипттер, автопровижнинг, мониторингке интеграциялар, талаптар бойынша сәйкестік. Мұндай детальдар көбіне жаңартудан кейін бірінші бұзылады.

Мысал: егер сізде vPC‑да жұп Nexus болса, критикалық VLAN мен port‑channel, қайсысы primary, peer‑gateway қай жерде қосылғанын жазыңыз. Бұл әрекеттер тәртібін шатастырмауға және перезагрузкадан кейін мінез‑құлықтың өзгергенін тез түсінуге көмектеседі.

Нұсқалық үйлесімділік матрицасы: құжаттамадан не іздеу керек

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

Міндетті талаптар және релиз «қосарланған бөлігі»

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

• минималды bootrom/ROMMON нұсқалары, NX‑OS үшін EPLD талаптары
• ұсынылатын нұсқалар (тек «қолдаулы» емес, «ұсынылады» деп көрсетілгендері)
• жадқа, образдарға және сақтау типтеріне қойылатын шектеулер
• нақты модельдер мен модульдерге тән ерекшеліктер (линейные карты, супервизорлар)

Төмен деңгей талаптарымен сәйкестігін тексеріңіз. Әйтпесе жартылай жүктелу немесе перезагрузкадан кейін мәселелер шығуы мүмкін.

Мінез‑құлықта не өзгереді және қалай жаңарту керек

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

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

• ROMMON/EPLD жаңартуды талап етеді, ал терезе оған жетпейді
• қолданыста депрекацияланған командалар бар
• мақсатты релиз сіздің модуль/трансивер/функцияны қолдамайды
• нұсқалар арасында «секіру» тыйым салынған, аралық қадам қажет
• сіздің сценариге қатысты белгілі критикалық баг бар (EVPN, HSRP, QoS және т.б.)

Лицензиялар: жаңартудан кейін функцияларды қалай жоғалтпау

IOS‑XE немесе NX‑OS жаңартуы тек багтар мен функцияларды ғана өзгертіп қоймайды, сонымен қатар құрылғының сол функцияларға құқықты қалай растайтынын өзгертеді. Сондықтан лицензияларды образпен бірдей қаттылықпен тексеріңіз. Әйтпесе перезагрузкадан кейін мүмкіндіктердің күтпеген «төмендеп қалуы» болады.

Біріншіден, ағымдағы күйді тіркеңіз: қандай пакеттер мен функциялар белсенді және конфигурацияда нақты қандай қолданылып жатыр. IOS‑XE үшін әдетте Smart Licensing пен деңгейлер (Network Essentials/Advantage) қаралады, NX‑OS‑та орнатылған функциялар мен олардың статусы қаралады. Нақты критикалықтерді белгілеп алыңыз: AAA және шифрлау, маршрутизация, сегментация, VXLAN/EVPN, телеметрия.

Окно алдындағы қысқа тексеріс:

• лицензияларға қатысты командалар шығуларын алып, конфиг бэкаппен бірге сақтаңыз
• сериялық нөмірмен байланыстығын, Smart Account/Virtual Account және жазылым мерзімін тексеріңіз
• мақсатты релизде сіздің платформаңыз үшін лицензиялау моделі өзгермейтінін анықтаңыз
• grace period бар-жоғын және оның аяқталуында не өшетініне назар аударыңыз

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

Железо мен ресурстар: модульдер, жад, образдар үшін орын

Жаңартудан бұрын ПО нұсқасынан бөлек «темірді» тексеру пайдалы: қандай модульдер орнатылған, flash/bootflash‑та бос орын бар ма, RAM жеткілікті ме, қуат пен салқындату жүйесінде жасырын проблемалар жоқ па. Перезагрузкадан кейін дәл осы нәрселер бірінші көрініс береді.

Модульдердің инвентаризациясынан бастаңыз және олардың мақсатты релизбен үйлесімдігін тексеріңіз. IOS‑XE‑та бұл шассидағы әртүрлі линейные карталар мен супервизорларға қатысты аса маңызды, NX‑OS‑та — бөлек модульдері бар коммутаторларда. Егер модуль қолдау таппаса, құрылғы кейбір порттар немесе функцияларсыз жүктелуі мүмкін.

Ресурстар мен тұрақтылық қоры туралы тексеріңіз:

• жаңа образ пен ескі образтың сақтық көшірмесі үшін flash/bootflash‑та бос орын
• таңдалған образ үшін RAM жеткілікті ме (‘‘впритык’’ болмауы керек)
• CPU жүктемесі мен жалпы тұрақтылықты алдын ала тексеріңіз
• PSU және вентиляторлар күйі
• boot‑айнымалылардың дұрыстығы және жүктеу тәртібі

Командалар платформаға байланысты, бірақ әдетте мына минимум жеткілікті:

show inventory
show version
dir flash:
show platform resources
show environment

Стектер, кластерлер және жұптар (мысалы, vPC) үшін құрылғылар мен модульдердің ревизияларының қақтыспайтынын және «темір + мақсатты релиз» үйлесімді екенін бөлек тексеріңіз. Практикалық мысал: стекте бір коммутатордың жад ревизиясы басқаша болса, ол ұзақ жүктелуі немесе образды қабылдамауы мүмкін, және стек толық көтерілмейді.

Функция үйлесімділігі: нақты конфигурацияны мақсатты релизбен салыстыру

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

Қолданылып жатқан функциялар тізімін жинау

Функцияларды бастаншадан емес, командалардың шығуларынан және конфигтен шығарып алған дұрыс. NX‑OS үшін feature тізімі көмектеседі, IOS‑XE үшін running‑config арқылы іздеу (маршрутизация, қауіпсіздік, QoS). Сол уақытта жұмыс режимін де тіркеңіз: L2/L3, VRF, протоколдар, Stack/vPC, active/standby.

Әдетте келесі командалар жеткілікті:

• show running-config (және интерфейстер, routing, security блоктары бөлек)
• show feature немесе эквивалент
• show ip route, show bgp/ospf neighbor
• show vpc, show switch/stack, show redundancy
• show policy-map interface, show access-lists

Мақсатты релизбен салыстыру және «үнсіз» өзгерістерді табу

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

Арнайы түрде тексеріп шығыңыз — үйлесімсіздіктен жиі бұзылатын сценарийлер:

• HA: SSO/NSF, Stateful switchover, ISSU (егер қолдансаңыз)
• vPC/Stack және FHRP (HSRP/VRRP) шеттерінде
• BGP/OSPF және саясаттар (route‑map, prefix‑list)
• QoS (кластары, кезектер, trust boundary)
• ACL, NetFlow/телеметрия

Мысал: vPC жұбы HSRP шлюзін қамтамасыз етеді және uplink‑те QoS бар. Жаңартудан кейін QoS қолдану тәртібі немесе протокол таймерлері өзгеруі мүмкін. Бұл сізге «құрылғы құлап қалды» емес, кешігу мен трафиктің бір линкке асып кетуі сияқты көрініс беруі мүмкін. Мұндай жағдайларды алдын ала must‑test ретінде белгілеңіз.

«До» снимктер: бэкаптар, чекпойнттар және авария жағдайындағы қолжетімділік

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

Конфигурацияны сақтап, flash/bootflash‑та қандай образдар мен файлдар тұрғанын тіркеңіз.

show running-config
show startup-config
dir flash:
dir bootflash:
show version

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

• көршілер: CDP/LLDP, маршрутизация протоколдары
• маршрут кестелері және ARP/ND
• порттардың және Port‑Channel күйі
• қуат, модульдер, интерфейс қателері

Жаңа образ жүктемес бұрын контрольді сомаларды (MD5/SHA) және қосымша образ үшін орын бар-жоғын тексеріңіз.

Және соңғысы — желі жоғалған жағдайда қолжетімділік. Консолдің (жергілікті немесе консоль сервер арқылы) жұмысын және Out‑of‑Band (mgmt VRF, бөлек порт) бар-жоғын, кіру деректерінің алдын ала тексерілгенін растаңыз.

Пилот және тест: үлкен тәуекелсіз қалай тексеру керек

Пилот — чеклисттің шынайы жұмыс жасағанын тексеретін тәсіл. Алдымен желінің шағын бөлігін, өндірістікке ұқсас, бірақ бизнес‑қауіпі төмен жерден жаңартыңыз.

Алдын ала сәттілік критерийлерін бекітіңіз. «Құрылғы жүктелді» жеткіліксіз. Қандай нәрселер жаңарудан кейін дәл осылай болуы тиіс екенін алдын ала жазыңыз:

• көршілер және маршрутизация: BGP/OSPF/EIGRP up күйінде, кестелер «бос» емес
• коммутация: VLAN, trunk, STP күтпеген қайта есептеулер мен блоктауларсыз
• қолжетімділік: AAA/TACACS/RADIUS, SSH, SNMP, NTP, syslog бұрынғыдай жұмыс істеуі
• өнімділік және қателер: CPU/жад қалыпты, drop, CRC, flap саны өспеуі
• критикалық функциялар: VXLAN, vPC, HSRP, QoS, NetFlow (немесе сіз үшін маңызды басқа функциялар)

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

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

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

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

Откатты апгрейдке дейін ойластыру қажет, өйткені ақау кезінде сабырмен шешім қабылдауға уақыт жоқ. Бастапқыда «қайтару» не екенін анықтаңыз: алдыңғы образтан жүктеу, install режиміндегі пакеттерді кері қайтару (add/remove/activate/commit), rescue‑қа өту немесе boot‑переменные‑ды ескі файлға қайтару.

Жақсы откат жоспары — командалар, күтілетін нәтиже және шешім нүктелері бар қысқа пошаговая инструкция. Мысалы: «құрылғы жүктелді, бірақ критикалық протоколдар көтерілмесе, X жасаймыз; егер N минут ішінде көмектеспесе, Y орындап, ескі образқа қайтарамыз». Кім откат шешімін қабылдайтынын және сервис қалпына келгенін қалай растайтынын алдын ала келістіріңіз.

Откат триггерлері

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

• құрылғы жұмыс режиміне жүктелмейді немесе ROMMON/loader‑ға түседі
• management‑қол жетімділіктер (SSH/console арқылы OOB) келісілген уақыттан артық қалпына келмесе
• тексеру жиынтығы (маршрутизация, HSRP/VRRP, BGP/OSPF, vPC/Port‑Channel, L2/L3 шлюздер) өтпесе
• жүктелгеннен кейін қайталанатын crash, жоғары CPU немесе модуль қателері байқалса
• сервис үшін маңызды лицензияланған функция жоғалып кетсе

Окноға дейін ескі образтың құрылғыда бар‑жоғын (flash/bootflash), бүтіндігін (checksum) және сақтық көшірме ретінде белгіленгенін тексеріңіз. Конфигурацияның қайтарылғандағы үйлесімділігін де бағалаңыз: жаңартудан кейін пайда болған жаңа командалар ескі релизде жұмыс істемеуі мүмкін. Практикалық тәсіл — «до» конфигтің бэкапын сақтау және ескі релизке оралғаннан кейін оны қайтару қадамын дайындап қою.

Мысал: NX‑OS vPC жұбында vPC peer‑link 10 минуттан артық үзілсе, алдымен екінші коммутаторды откаттап, vPC қалпына келтіріп, содан кейін ғана бірінші туралы шешім қабылдаңыз.

Жұмыс жоспары: терезеден бастап сервис растауына дейінгі қадамдар

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

Терезе таймлайны

Әр қадамның уақытын бағалап, буфер қойыңыз:

• T‑30 мин: терезенің соңғы растауы, рұқсаттар мен консоль қолжетімділігін тексеру, образдар мен хештердің барын тексеру
• T0: старт, өзгерістерге тыйым салу, негізгі көрсеткіштерді (CPU, жад, uptime, порт қателері) тіркеу
• T+X: таңдалған процедура бойынша апгрейд, жүктелуді және желіге оралуын қадағалау
• T+Y: келісілген тізім бойынша сервис тексерістері (маршрутизация, VLAN/VRF, критикалық жүйелерге қолжетімділік)
• T+Z: түзетуге немесе откатқа арналған буфер

Рөлдер, коммуникация және төтенше жағдай

Рөлдер нақты адамдарға бекітілуі тиіс, бөлімдерге емес. Бір адам өзгеріс жасап, сол өзгерісті қабылдамауы керек.

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

Форс‑мажорға дайындалғанда: кім байланыс көпірін көтереді, қай жерде резервтік қолжетімділік (OOB/консоль), қосымша құрылғы/модуль бар‑жоғын және «қайтарымсыз нүкте» қай жерде екенін алдын ала шешіп қойыңыз.

Жиі кездесетін қателер: жаңартуды не жиі бұзады

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

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

Үшінші топ қателер HA, стек және vPC‑ға байланысты. Бір коммутатор жаңарса да, жұп «шамадан тыс» күйге келіп, үйлесімсіздік салдарынан бұзылуы мүмкін. Мұндай жүйелерде екі жақтың да таңдалған релизді және орнату тәсілінің бірдей екенін алдын ала тексеру маңызды.

Тағы бір жиі қате: «образты көшіру» дегеніміз оны «оны жүктеу» дегенмен бірдей емес. IOS‑XE және NX‑OS үшін командалар реті, активацияны растау және перезагрузка маңызды.

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

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

Старт алдында:

• қажетті образ және дұрыс checksum (құрылғыда немесе көшіру серверінде сақталған файл бойынша тексерілген)
• свежий бэкап running‑config және негізгі show (нұсқа, модульдер, лицензиялар, көршілер)
• расталған OOB немесе консоль қолжетімділігі және жұмыс істейтін есептер (тек TACACS емес, AAA өшкенде қолданатын локал жоспар)
• storage/bootflash‑та бос орын және boot жолының нақты анықталуы
• откат жоспары: қай образ қайда және кім «откат» деп бұйырады

Жаңартудан кейін дереу барлығын тексеруге тырыспаңыз. Алдымен негізгі жұмыс қабілеттілігін және төтептілігін растаңыз:

• порттар мен агрегаттар: up/down, қателер, жылдамдық/дуплекс, port‑channel күйі
• маршрутизация және көршілер: OSPF/BGP/ISIS, HSRP/VRRP, маршрут кестесі және ARP/ND
• HA: stack/vPC/VSS/SSO күйі, рөлдер, синхрондау, split‑brain жоқтығы
• сервис: бірнеше қарапайым тест (VLAN арасында ping, шлюзке қолжетімділік, негізгі қосымшаларға қолжетімділік)
• логтар: критикалық хабарлар, crashinfo/core, лицензиялау оқиғалары

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

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

Типтік кеңсе: екі ядролық коммутатор жұбы vPC және HSRP шлюзі ретінде жұмыс істейді, шетте провайдерге BGP жүгіртетін маршрутизатор орналасқан және кіріс трафик үшін бөлек ACL бар. Терезе мақсаты — IOS‑XE/NX‑OS нұсқаларын көтеру, байланыс жоғалтпай.

Аптасына команда нақты конфигурация мен show‑шығуларды жинап, оларды мақсатты релизбен салыстырды. Критикалық тексерістер қарапайым, бірақ нақты болды: vPC күйі (роль, peer‑link, consistency), HSRP активтілігі, BGP көршілер саны және маршруттар, ACL бойынша drop счетчиктері және мониторинг негізгі метрикаларды (интерфейстер, CPU, логтар) көретіндігі.

Ретті «қызметі азнан көпке» деп таңдады. Алдымен HSRP‑да белсенді шлюз емес коммутатор жаңартылып, vPC‑ның айырмашылығы жоқ па тексерілді. Содан кейін екіншісі жаңартылды. Шеттегі маршрутизатор соңында қалдырылды, себебі бірден бірнеше ықтимал себептерді араластырудан аулақ болу керек.

Соңында қысқа есеп жасалды:

• не жаңартылған: модельдер, ескі және жаңа нұсқалар, образдардың checksum‑тары
• не тексерілді: vPC/HSRP, BGP, ACL, мониторинг, OOB/консоль арқылы қолжетімділік
• өзгерістер: логтардағы ескертулер, конфиг айырмашылықтары, лицензия статусы
• қорытынды: тоқтау уақыты (бар болса), жоспардан ауытқулар, откат қажет болмады

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

Жаңартудан кейінгі кезеңде барлық фактілерді бір пакетке жинап, не істегеніңіз бен не талап еткенін тіркеңіз. Бұл келесі релизді қайталанатын процедураға айналдырады.

Пакетті былай дайындаңыз, сонда кез келген кезекші оны жарты жылнан кейін ашып, контексті тез түсінеді:

• алдын‑ала және кейінгі нұсқалар, қолданылған командалар мен олардың шығулары
• образдардың нақты аттары, орналасқан жерлері және хештер
• финалдық чеклист және кім орындағаны туралы белгі
• пилоттың қысқаша есебі және табылған нюанстар
• откат жоспары және триггерлер: қай белгілер бойынша қайтамыз

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

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