Burn-in тесті — серверді продакшнге енгізер алдында CPU/RAM/желіге арналған утилиталар, жарамдылық критерийлері және кепілдік үшін нәтижелерді тіркеу тәртібі.
bash\nN=$(nproc)\nstress-ng --cpu $N --cpu-method matrixprod --timeout 2h --metrics-brief\n\n\nМәселе ретінде есептелетіні — тек жоғары температура емес, тұрақты емес мінез-құлық:\n\n- тұрақты троттлинг, жиіліктерді айтарлықтай төмендететін жағдайлар;\n- жүйелік журналдардағы MCE/WHEA қателері, тіпті утилита формалды түрде құламаса да;\n- тест процесстерінің құлауы, ілініп қалулар, қайта жүктелулер, kernel panic;\n- утилитаның көрсететін есептеу қателері.\n\nКепілдік жағдайында утилитаның шығуын, BIOS/микрокод нұсқаларын және жүйелік журналдардан үзінділерді бір архивке сақтаңыз — дата мен сервердің сериялық нөмірімен. Бұл көбіне дәлел ретінде жетіспейтін нәрсе.\n\n## RAM және ECC тесті: жадының тұрақсыздығын қалай табу\n\nЖадты бөлек тексеру маңызды, тіпті CPU мен дискілер қалыпты жұмыс істесе де. Бір ұяшықтың бұзылуы, «жүзе беретін» модуль немесе контроллер ақауы әдеттегі жүктемеде көрінбеуі мүмкін, ал аптадан кейін продакшнде кездейсоқ сервис құлдырауы мен база қателері ретінде көрінуі ықтимал.\n\nOS-тан тыс тексеруді Memtest86 (немесе баламасы) арқылы бастау сенімді: ол модульдердің және таймингтердің айқын мәселелерін жақсы шығарады.\n\nЖүйеде жадқа ұзақ жүктеме қосу пайдалы. Көбіне stress-ng-тың vm режимі (ұзын жады блоктарын бөліп, белсенді жазып/оқиды) қолданылады; қажет болғанда y-cruncher да өткір шекаралық тұрақсыздықты көрсетеді, әсіресе жоғары температурада.\n\nECC үшін corrected және uncorrected қателерді айыру маңызды. Бір рет түзетілген қате бірнеше сағатта кездейсоқ болуы мүмкін, бірақ қайталанатын оқиғалар, жүктеме кезінде есептегіштердің өсуі немесе бір DIMM-те қателер — әдетте аппараттық ақау. Linux-та dmesg және EDAC/MCE жазбаларына (corrected/uncorrected ECC) қараңыз. Windows-та ұқсас оқиғалар жүйелік журналға түседі.\n\nПамять бойынша әдеттегі FAIL шарттары:\n\n- кез келген uncorrected ECC қатесі, kernel panic, BSOD немесе күтпеген қайта жүктелу;\n- бір слот/каналда қайталанатын corrected ECC қателері;\n- Memtest86 қателері, егер олар қайталанса онда бір қате ретінде қабылданады;\n- y-cruncher құлауы немесе есептеу қателері (mismatch) бірдей параметрлерде;\n- ұзақ жадқа жазу кезінде қосымшалардың құлауы және бұзылған архивтер/хэштер.\n\nЖаңа серверді қабылдағанда (мысалы, виртуализация үшін) 4–12 сағат жүктеме өткізіп, ECC есептегіштерінің өспеуін қадағалаңыз. Егер олар өссе — уақыт, температура және модуль нөмірін тіркеңіз, сонда кепілдікпен ауыстыру дәлелденуі оңай болады.\n\n## Желі тесті: өткізу қабілеті, жоғалтулар және тұрақтылық\n\nЖелі көбіне «қалыпты» көрінеді, бірақ нақты жүктеме басталғанда (резервтік көшіру, VM миграциясы, репликация) ұшып кетеді. Желіні burn-in арқылы тексеріп, порттың, кабельдің, SFP мен баптаудың плавающий қателерін алдын ала табу керек.\n\nАлдымен линктің базалық күйін тексеріңіз. Интерфейс тек «жанып тұр» ғана емес, жасырын қателер де (кейін TCP қайта жіберімдері мен жылдамдық құлдырауына әкеп соғатын) болмауы тиіс.\n\nТексеру керек заттар:\n\n- жылдамдық пен дуплекс (мысалы, 10G/Full), автосәйкестендірудің дұрыстығы;\n- интерфейстегі қателер есептегіштері: CRC, drops, overruns, frame errors;\n- NIC драйвері мен микропрограммасы (жүйелік журналдарда ескерту жоқ болуы тиіс);\n- flow control pause кадрларының күтпеген өсуі.\n\nСодан кейін iperf3 арқылы каналды жүктеңіз. Екі бағытта және әртүрлі ағын санымен іске қосыңыз: бір «жуан» сессия мен бірнеше параллельді сессия әр түрлі суретті береді. Тұрақтылық үшін қысқа емес, 10–30 минуттық ұзақ прогондар пайдалы.\n\nbash\n# На принимающей стороне\niperf3 -s\n\n# На тестируемом сервере: 4 потока, 15 минут\niperf3 -c <IP_партнера> -P 4 -t 900\n\n# Обратное направление (сервер передает в ответ)\niperf3 -c <IP_партнера> -P 4 -t 900 -R\n\n\nДауысты қызметтерге немесе VDI сияқты латентті сезімтал сервистерге потерь мен джиттерді тексеру қосыңыз. Қарапайым әдіс — ұзақ ping және iperf3 жүктемесі алдында/соңындағы салыстыру.\n\nОтчет пен кепілдікке қосу үшін тіркеу керек: конфигурация (жылдамдық/MTU) суреті, iperf3-тің толық шығысы, интерфейстің қателер есептері тест алдында және кейін, сондай-ақ TCP метрикалары (қайта жіберімдер, уақыт бойынша жылдамдық құлдыраулары). Егер жаңа серверде 10G линк тұрақты CRC көрсетсе де, бір портыңызда ретрансляция өссе — кабель, SFP немесе NIC ауыстыруға дәлел болады.\n\n## Дискілер мен сақтау (тапсырмаға байланысты): I/O стресс және тексерулер\n\nЕгер сервер дерекқорларды, виртуалдық машиналарды немесе файл қызметін ұстайтын болса, тек CPU прогоны жеткіліксіз. Көптеген тосынсыйлар дискілер мен контроллерден келеді: жүктеме кезінде кешігулер өсіп, таймауттар пайда болады, кейде жай ғана журналдарда көрінбейтін қателер шығады.\n\nЖылдам I/O стресс үшін fio жеткілікті. Идея — ұзақ уақыттық аралас жүктеме (оқу/жазу), нақты сценариге ұқсас. Дерекқор үшін шағын блоктар мен кездейсоқ қол жеткізу, файл архиві үшін ірі блоктар мен қатарлы жазу. Тесті нақты сақтау деңгейінде іске қосыңыз: жеке диск, RAID, LVM немесе SAN LUN.\n\nПараллельде жүйені бақылаңыз: iostat құрылғылар бойынша жүктеме мен кешігуді көрсетеді, vmstat жады мен свопқа тап болу-болмауды көрсетеді. Дискілердің SMART және температурасы тесттің алдында және соңында тексерілсін — қызу көбінесе «жай баяулауды» маскилайды.\n\nТестті тоқтату қажет ететін сигналдар:\n\n- fio-да оқу/жазу қателері, dmesg немесе syslog-та I/O error;\n- кешігулердің күрт өсуі және жылдамдықтың түсіп кетуі профил сақталуымен бір уақытта;\n- дискілер немесе контроллер таймауттары, reset/abort командалары туралы хабарлар;\n- SMART көрсеткіштерінің (reallocated, pending, uncorrectable) өсуі, тіпті тест «формалды түрде» өткен болса да;\n- дискілер немесе контроллер жылуы нормадан жоғары.\n\nКритикалық жүктемелер үшін (мысалы, стойкадағы VM кластері) нәтижелерді сол конфигурацияның эталонымен салыстыру пайдалы. Эталонды профиль қабылдауға арналған базалық өлшем ретінде сақтау ыңғайлы.\n\n## 4–12 сағаттық burn-in қадамдық сценарийі (мысал)\n\nТөмендегі мысал көптеген жаңа серверлерге продакшнге енгізер алдында тиімді келеді. Оны стандартты прогон ретінде қайталап, бірдей модельдер арасында салыстыруға ыңғайлы.\n\nЖаңа немесе жөнделген сервер үшін burn-in-ды алдын ала болжанатын шарттарда өткізу ұсынылады: қалыпты желдету, штат вентиляторлар, жабық қақпақ, тұрақты қуат.\n\n### Үлгі тәртібі (4–12 сағат)\n\n1) Сервер паспорты мен лог жинауды орнатыңыз: модель, сериялық нөмір, CPU/RAM/дискілер/ NIC конфигурациясы, BIOS/firmware нұсқалары, тест уақыты мен орны. Дұрыс уақыттық меткалармен dmesg/journal/syslog пен BMC/IPMI оқиғаларын сақтау керек.\n\n2) 30–60 минут бақылау, жүктеме жоқ: температура мен вентилятор айналымдарының тұрақтылығын тексеріңіз, журналдарда қателер жоқ болуы тиіс, ECC коррекция есептегіші өспеу керек, күтпеген қайта жүктелулер болмауы тиіс.\n\n3) Жүктеме кезеңдері: алдымен CPU стресс, кейін RAM стресс, соңында CPU+RAM бірге. Маңыздысы — тек жүктеме емес, деградация белгілерін анықтау: троттлинг, температура секірулері, MCE, тесттердің құлауы, ілініп қалулар.\n\n4) Желі бойынша iperf3 прогондары: екі бағытта, бірнеше ағынмен, әр конфигурацияға минимум 10–15 минут. Егер сақтау немесе дерекқорлар болса — қажетті дискілерде қысқа I/O стресс (fio) қосыңыз.\n\n5) Қорытынды PASS/FAIL және артефактілерді жинау: журналдар, утилиталардың нәтижелері, сенсор скриншоттары және метрикалар кестесі. Бұл талдау мен кепілдікке жүгінуде үлкен көмек береді.\n\n## "Жарамды/жарамсыз" критериялары: болжамсыз шешімді қалай болдырмау\n\nНегізгі ереже — burn-in нәтижелерін басқа серверлермен емес, өндірушінің сипаттамаларымен салыстырыңыз: CPU, жад, плата және салқындату спецификациялары. Температура шектері, рұқсат етілген жиіліктер, turbo ережелері және троттлинг шектер ұқсас конфигурацияларда да әртүрлі болуы мүмкін.\n\n«Жарамды/жарамсыз» шешімін төрт ось бойынша бағалау ыңғайлы: тұрақтылық, журналдағы қателер, жылулық мінез-құлық және өнімділіктің болжаушылығы. Егер қайсыбір ось қайталанып сәтсіз болса — оны продакшнге дейін шешу керек.\n\nПрактикалық чек: \n\n- FAIL: журналдарда қайталанатын аппараттық қателер (ECC/MC, PCIe AER, MCE), тіпті сервер әлі құламаса да. Бір рет болған ескерту әлі онша емес, алайда қайталануы — қызыл сигнал.\n- FAIL: ілініп қалулар, күтпеген қайта жүктелулер, kernel panic, желі интерфейстерінің жоғалуы немесе контроллер ақаулары.\n- FAIL: қалыпты шарттарда тұрақты троттлинг (тазартылған фильтрлер, қалыпты сервер бөлмесі температурасы, ұсынылған вентилятор профилі бар кезде).\n- PASS: тесттер бірнеше сағат бойы айтарлықтай қателер мен құлауларсыз өтті, көрсеткіштер тұрақты.\n- PASS: өнімділік болжамды, ешқандай күтпеген жиілік «пилалары» жоқ.\n\nМысал: S200 деңгейіндегі rack-серверді 8 сағатқа прогондадыңыз. Егер әр 20–30 минут сайын MCE тіркеліп немесе ECC есептегіші өсе берсе — оны продакшнге жарамсыз деп санай беріңіз, тіпті қолданбалар әлі байқамаса да. Ал егер температура мен жиіліктер спецификация шегінде болып, журналдар таза болса — «жарамды» шешім сенімді болады.\n\n## Burn-in кезінде жиі кездесетін қателіктер және тұзақтар\n\nЕң жиі қате — burn-in-ды «қорапшада» жүргізу: стресс іске қосылды да, бәрі өзіне қалдырылды. Температуралар, жиіліктер, ECC және жүйелік журналдарсыз сіз уақыт жоғалтасыз және кепілдікке қажетті дәлелдер болмайды.\n\nЕкінші тұзағы — бірден бәрін жаңарту. BIOS, RAID драйвері мен NIC микропрограммасын бір уақытта жаңартсаңыз да, сервер құлаған жағдайда қай өзгеріс кінәлі екенін анықтау қиын болады. Өзгерістерді бір-бірден енгізіп, нұсқаларды тіркеңіз.\n\n### Қайсысы ең жиі тестті бұзады\n\n- Бақылаусыз стресс: графиктер жоқ, логтар жоқ, уақыттық меткалар жоқ.\n- Жоспары жоқ «коктейль» жүктемелері: CPU, RAM, желі және дискілер бірден, және кінәлісі белгісіз.\n- Шарттарды елемеу: жабық стойка, бітелген фильтрлер, сервер бөлмесінің жоғары температурасы.\n- Қуат нашарлығы немесе PDU проблемасы: қысқа үзілістер «кездейсоқ» ребуттар сияқты көрінеді.\n- Өте қысқа прогон: 10–20 минут жадтың сирек қателерін және ұзақ мерзімді қызуды көрсетпейді.\n\nҚарапайым мысал: сервер 15 минут өтті, бірақ 2 сағаттан кейін троттлинг басталды немесе шартты ECC қателері пайда болды. Егер syslog/journal және сенсорлар жазылмаса, «қайталана ма/қайталанбай ма» даулығы ұзаққа созылады.\n\n### Қалай қателіктерден құтылуға болады\n\nТест басталардан бұрын бір типтік сценарий таңдап, салқындату мен қуатты тексеріп, қандай логтар мен скриншоттарды сақтайтыныңызды анықтаңыз.\n\n## Кепілдікке қажетті нәтижелерді қалай тіркеу керек\n\nПродакшнге енгізілгеннен кейін сирек болатын ақау шықса, дау көбінесе «не істелді» емес, «дәлел бар ма» дегеннен басталады. Сондықтан burn-in-ды «әрекет аяқталды» деп қана қоймай, дәлелдері бар пакетті қалдыру маңызды.\n\nӘр серверге бір үлгі есеп жасаған ыңғайлы. Бірінші бөлімге дата, орнату орны, сериялық нөмір мен нақты конфигурация (CPU, RAM көлемі, диск модельдері, NIC) мен BIOS/firmware нұсқаларын жазыңыз. Тесті бастамас бұрын өзгертілген параметрлерді (қуат профилі, XMP, RAID, MTU) бөлек көрсетіңіз.\n\nСосын «қауыс деректерді» жинаңыз, оларды екіұдай түсіндіру қиын болатындай:\n\n- ОС журналдары: dmesg және тест уақытына сәйкес жүйелік журнал (уақыттық меткалармен);\n- BMC журналы: SEL экспорт (мысалы, ipmitool арқылы) және сенсор көрсеткіштері (температура, қуат, вентиляторлар);\n- дискілер: SMART экспорттары тестке дейін және кейін, сонымен қатар I/O утилиталарының нәтижелері;\n- стресс-утилиталардың нәтижелері: есептер, аяқталу кодтары, қателер көрсеткіштері (ECC, segfault, құлаулар).\n\nФотодалелдер де пайдалы: консоль экранына түсірілген скриншот пен уақыты, сериялық нөмірі бар шильдик фотосы, стойка мен қосылымдардың жалпы көрінісі. Бұл тесттің нақты аппаратта өткенін растауға көмектеседі.\n\nБарлығын өзгермейтін архивте сақтаңыз, файлдардың контрольдық соммасын және жауапты тұлғаның қолымен бекіту қосыңыз. Практикалық тұрғыдан бұл күндер сабақ үнемдейді: толық пакет қоса берілсе, сервистік команда оқиғаның хронологиясын жылдам көреді.\n\n## Продакшнге беру алдындағы қысқа чек-лист\n\nСерверді нақты жүктемеге бермес бұрын қысқа тексеруден өту пайдалы — кейін «қай кезде басталды» туралы дау болмас үшін. Бұл тізім burn-in-ды толықтырып, типтік тәуекелдерді жабады.\n\n### 15 минутта 5 тексеріс\n\n- Идентификаторлар мен конфигурацияны тіркеңіз: сериялық нөмір, модель, CPU, RAM көлемі, диск/RAID құрамы, желі карталары. BIOS/BMC/контроллерлердің firmware нұсқаларын жазып алу.\n- Жүктеме астындағы термопрофильді тексеріңіз: CPU, чипсет, дискілер температуралары мен вентилятор айналымдары. Егер айқын троттлинг немесе вентилятор айналымдарының «пилалары» көрінсе — тоқтатыңыз және шешіңіз.\n- Жүйелік журналдарды қарап шығыңыз: Machine Check, ECC, PCIe, контроллер қателері, қызу жазбалары. Тестілеу кезінде қайталанатын қателер болмауы тиіс.\n- Дискілерді бағалаңыз: SMART-та алаңдататын атрибуттар жоқ, переназначение/күтудегі секторлар саны өспеген, оқу/жазу қателері жоқ.\n- Желі күйін тексеріңіз: жылдамдық және тұрақтылық (мысалы, iperf3 арқылы), ұзақ прогонда жоғалтулар немесе кенеттен құлдыраулар болмауы.\n\nЕрекше — кепілдікке арналған «дәлел пакетін» сақтаңыз: сервер аты мен датасы бар папка, командалар шығысымен файлдар, журналдар (zip), BIOS/BMC скриншоттары, және жауапты тұлғаның қорытындысы «жарамды/жарамсыз».\n\n## Практикалық мысал: жаңа серверді сюрпризсіз енгізу\n\nRack-сервер виртуализацияға қойылды. Дискілер бөлек СХД-да болғандықтан негізгі тәуекел — жад пен желіде. Қолданушыларға кедергі келтірмеу үшін тест серверді тест VLAN-ға қосып, продакшндегі сол баптаулармен (порт жылдамдығы, MTU, bonding) түнде burn-in жүргізді.\n\nСценарий: 30–60 минуттік базалық CPU жүктемесі температура мен қуат ақауларын анықтау үшін, кейін RAM пен желіге басымдық. Жад үшін stress-ng (vm және malloc режимдері) іске қосылып, параллельде ECC журналдары dmesg пен жүйелік журналда бақыланды. Негізгі мақсат — белгілі бір DIMM-те қайталанатын коррекция болмауын тексеру.\n\nЖелі үшін бірнеше iperf3 прогоны алға-артқа түрлі ұзақтықпен жүргізілді: қысқасы пике үшін, ұзақсы тұрақтылық үшін. Потерь, retransmit немесе жылдамдық секірулері байқалмады.\n\nИтог мынадай пакетпен рәсімделді:\n\n- бір PDF/Doc: конфигурация, BIOS/firmware нұсқалары, тест уақыт аралығы, қысқаша қорытынды және PASS/FAIL критерийлері;\n- журналдар архиві: командалар шығыстары, жүйелік журналдар, сенсор скриншоттары;\n- сериялық нөмір шильдигінің фото;\n- архивтың контрольдық соммасы.\n\nЕгер тест FAIL берсе, бірден бәрін алмастырмайды. Алдымен прогонды қайталап, кездейсоқ ақауды жоққа шығарады, содан кейін компонентті оқшаулайды: модульдерді орнына ауыстыру, кабель/портты ауыстыру, firmware жаңарту. Қайталану мен бақылау нәтижелері сақталса — сервиске толық пакетпен жібереді.\n\n## Келесі қадамдар: burn-in-ды сіздің ИТ-практикаңызға енгізу\n\nBurn-in бір реттік бастама болмауы үшін оны жаңа сервер қабылдау және кез келген тәуекелді өзгерістерден кейін міндетті қадам ретінде бекітіңіз: CPU/RAM ауыстыру, firmware, RAID баптаулары, стойканы көшіру.\n\nЖай ереже: тест есебі жоқ сервер «продакшнге дайын» статусын алмайды. Бұл ИТ, сатып алу және мердігерлер арасындағы дау-жанжалдарды азайтады, себебі шешім өлшенетін деректерге сүйенеді.\n\n### Ұдайы ұстап тұруға оңай процесс\n\nПроцедура иесін анықтаңыз (мысалы, эксплуатация инженері) және қысқа регламент жасаңыз: не тестіленеді, қанша сағат, қандай утилиталар және қандай метрикалар критикалық саналады. Артефакт форматында да келісіңіз: журналдар, скриншоттар, BIOS/BMC нұсқалары, сериялық нөмірлер, және PASS/FAIL қорытындысы.\n\nӘр жолы қолмен жасамау үшін нәтижелер жинауды автоматтандырыңыз: бір скрипт тесттерді іске қосып, журналдарды (dmesg, BMC/SEL, SMART, утилиталар есептері), температура мен жиіліктерді жинап, бір архив пен қысқаша есеп құрайтын болсын. Мұндай пакет ішкі бақылау мен кепілдікке жүгінуде ыңғайлы.\n\n### Сатып алудан бұрын критерийлерді бекітіңіз\n\nЖеткізу келісіміне дейін SUP-лигімен PASS/FAIL критерийлерін және қайсысы «дефект» саналатынын бекітіңіз: ECC, Machine Check, желінің деградациясы, қызу, троттлинг, жүктеме астындағы тұрақсыздық. Бұл күту мен жауапкершілікті айқын етеді.\n\nЕгер сіз жеткізуді «ашық кілтпен» жоспарласаңыз, GSE.kz (gse.kz)-пен қабылдау процесі, burn-in және есеп пакеті қалай көрінетіні туралы алдын ала келісу пайдалы болады.