SMBIOS және BMC арқылы CMDB-ді автоматты толтыру: есепке алу қателерін азайту

Неліктен CMDB қажет және қолмен есепке алуда уақыт қайда кетеді

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

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

Көбінесе қолмен енгізілетін немесе түзетілетіндер — модель мен сериялық нөмір, CPU/RAM құрамасы мен диск түрі, прошивка нұсқалары мен контроллерлер, орналасу (майданша, стойка, слот), иесі және сервиспен байланыстар, сондай-ақ критикалықтік деңгейі.

Дәлсіз деректер диагностика уақытын тікелей ұзартады. Өнімділік төмендеген кезде команда алдымен «дұрыс» серверді табуға тырысады: жапсырмаларды салыстырады, ЦОД-тен фото сұрайды, сатып алу бөліміне не жеткізілгенін анықтайды. Сағаттар негізгі ақпаратты растауға кетеді.

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

Сондықтан SMBIOS пен BMC-тен CMDB-ді автоматты толтыру — бұл «косметика» емес, тоқтауларды қысқарту және есепке алудағы типтік адами қателерді жою тәсілі.

SMBIOS пен BMC‑ті қарапайым тілмен: не жинауға болады

SMBIOS (System Management BIOS) — жүйелік микробағдарламадан ОС алатын құрылғылық деректер жиынтығы. Қарапайым айтқанда, бұл құрылғының ОС арқылы көрінетін «жеке куәлігі». SMBIOS-тен әдетте өндіруші, модель, сериялық нөмір, аналық плата туралы мәліметтер, CPU сокеттері мен жад ұялары туралы ақпарат алынады.

BMC (Baseboard Management Controller) — ОС-тан тыс жұмыс істейтін бөлек серверді басқару контроллері. Ол сервер өшіп тұрса да немесе ОС жүктелмесе де қолжетімді. BMC «темірден» тікелей деректер береді: FRU (модульдердің инвентарлық өрістері), температура және қуат сенсорлары, желдеткіш жылдамдығы, питание блоктары мен диск сөрелерінің жағдайы, сондай-ақ оқиғалар журналы (мысалы, қызып кету, желдеткіш ақауы, қуат қатесі).

CMDB автоматтандыруын баптамас бұрын әр өріске қай дереккөз басым болатынын келісіңіз. Практикада жиі төмендегідей жұмыс істейді:

• құрылғы моделі мен платформа типі — SMBIOS (егер дұрыстап толтырылса)
• шасси сериялық нөмірі — BMC/FRU (серверлер үшін жиі сенімді)
• аналық платаның сериялық нөмірі мен ревизиясы — SMBIOS
• модульдердің құрамы (PSU, желдеткіштер, backplane) — BMC
• ағымдағы күйі мен инцидент себептері (сенсорлар, SEL-журнал) — BMC

Дереккөздер кейде әртүрлі ақпарат береді. Аналық платаны алмағанда SMBIOS жаңа board serial көрсетсе, ал шасси сериялық нөмірі BMC-те бұрынғы күйінде қалуы мүмкін. Керісінше де болады: SMBIOS-та сериялық бос немесе «To be filled by O.E.M.» деген жазумен тұрса, FRU дұрыс толтырылған болуы мүмкін. Мұндай жағдайларды алдын-ала ескеріп, басымдықтарды бекітіңіз, екі мәнді де қайнармен бірге сақтаңыз және сәйкессіздіктерді есеп пен диагностика үшін бөлек сигнал ретінде пайдаланыңыз.

CMDB-ге бірінші кезекте қай өрістерді автотолтыру керек

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

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

Екінші деңгей — конфигурация, себебі оны инциденттер мен сыйымдылық жоспарлау кезінде жиі тексереді. Әдетте жеткілікті: CPU түрі мен саны, жад көлемі, сақтағыштар тізімі (кем дегенде түрі мен көлемі), желілік адаптерлер (MAC-мекенжайлар мен порт типі/жылдамдығы).

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

Үшінші қабат — қолдау үшін қажет атрибуттар: BIOS пен BMC нұсқалары, прошивка нұсқалары және қызмет көрсету ескертпелері. Түнде сервер құлдырағанда кезекші CMDB-ден модель мен BMC нұсқасын көріп, қандай қашықтан қолжетімділік профиль қажет екенін және белгілі прошивка мәселелерін бірден анықтай алады.

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

Дайындық: деректер ережелері мен сәйкестендіру кілттері

Автоматтандыру серверлерді опрос жасаудан емес, деректер тәртібінен басталады. Әйтпесе SMBIOS пен BMC-тен автожинақтау бұрынғы қателерді тез көбейтеді.

Бастапқыда актив объектісі және оның байланыстары қайда сақталатынын шешіңіз: CMDB, жабдық есеп жүйесі, ITSM немесе бірнеше дерекқордың қосындысы. Әр темірге бір басты объект болуы және басқа жүйелер деректерді синхрондау арқылы алуы маңызды — қолмен көшіру жоқ болуы керек.

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

Практикалық ереже жиі қолданылатын түрі:

• шасси сериялық нөмірі мен сервер моделі — BMC (өрістер дұрыс толтырылған жағдайда)
• UUID, BIOS пен плата туралы деректер — SMBIOS
• CPU, RAM (көлемі), дискілер — екі қайнар көзден; басымдық онда болады, қайда бос орын аз
• желі және порттар — кірістірілген интерфейстер үшін көбіне BMC

Сонымен қатар нормативтік сөздіктерді бір түрге келтіріңіз: модельдер, құрылғы типтері, майданшалар, стойкалар, орта атаулары. Бір жерде «S200», басқада «S-200» немесе «Rack server» болса, сәйкестіктер аз болады да, қолмен өңдеу шексізге созылады.

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

Көбінесе пайдаланылады: сериялық нөмір (chassis serial), UUID, asset tag (инвентарлық нөмір) және фиксирленген интерфейстің MAC-адресі (тек резерв ретінде).

Мысалы: майданшада аналық платаны ауыстырғанда UUID өзгерді. Егер сәйкестендіру тек UUID бойынша болса, CMDB-де «жаңа» сервер пайда болады. Егер шасси сериялық нөмірі мен asset tag бар болса, актив тарихы мен байланыстар сақталады.

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

CMDB-ге автоматты толтыру процесі: қадамдар

SMBIOS пен BMC-тен CMDB-ге автотолтыру сенімді жұмыс істеуі үшін қайталанатын процесс маңызды: нормализациядан бастап жаңарту ережелері мен өзгерістерді бақылауға дейін.

Жинақтаудан CMDB-ге жазуға дейінгі процесс

Тесттік топтан (10–20 құрылғы, әртүрлі модельдер) бастаңыз. Осылай нақты қандай өрістер келетіні және қайсысы «қалықтайтыны» жылдам көрінеді.

• Хосттардан SMBIOS-ты шығарып, мәндерді нормализациялаңыз: өндірушілер атауларын біркелкілеу, сериялық нөмір форматын бір қалыпқа келтіру, модельді артық бос орынсыз жазу, жад пен дискілер үшін бірлік бірліктерін бірдей ету.
• BMC-тен бөлек деректерді жинаңыз: FRU, шасси моделі, сериялық нөмірлер, контроллер идентификаторлары және параметрлері.
• Екі қайнар көз жазбаларын сәйкестендіріп, дубликаттарды жойыңыз. Әдетте сериялық нөмірден бастап, резерв кілттерін (asset tag, UUID, өрістер комбинациясы) қосады, егер бір мән бос немесе қате болса.
• «Кім басты» ережелеріне сүйеніп CMDB-ні жаңартыңыз. Мысалы, шасси сериялық нөмірі мен модельді BMC-тен, ОС-ке байланысты мәліметтерді хосттан алыңыз. Қандай өрістер автоматты түрде қайта жазылатынын және қайсысы тек бекіту арқылы өзгеруі мүмкін екенін айқындап қойыңыз.
• Жоспарлау мен өзгерістерді бақылауды қосыңыз: күнделікті маңызды өрістерді (статус, желі) жаңарту, апта сайын конфигурацияны қарап шығу және сериялық нөмір, UUID немесе өндіруші күтпеген түрде өзгерсе, ескерту жүйесін қосу.

Қысқаша мысал

Аналық платаны ауыстырғаннан кейін SMBIOS жаңа сериялық нөмір немесе UUID көрсетті, ал BMC синхрондалғанға дейін ескі FRU мәні қалды. Мұндай сәйкессіздікті «тексеруді талап етеді» деп белгілеген жөн, бірден CMDB-ге жазудан бұрын.

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

Деректердегі типтік проблемалар және оларды шешу жолдары

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

Түрлі модель атаулары және «жүзбелі» атаулар

Бір платформа «S200», «S200 Series», «S200-2U» немесе жеткізу атауымен келуі мүмкін. Бұл нормализация арқылы шешіледі: канондық модельді енгізіп, парсинг ережелерін жасаңыз (серия бөлек, модификация бөлек). Шикі SMBIOS/BMC мәтінін тексеру үшін қосымша өрісте сақтау жақсы.

Сериялық нөмірлер бос, қайталанады немесе дұрыс емес

Кейбір компоненттерде (жад, дискілер, кейде аналық плата) сериялық нөмір бос немесе бірдей болуы мүмкін. Сондықтан CI бірегейлігін бір өріске сүйеніп құрастыру дұрыс емес.

Пайдалы тәжірибе:

• сервер үшін басымдық: BMC Serial → SMBIOS System Serial → Asset Tag
• бірнеше идентификатор мен олардың қайнар көзін сақтау
• «бір сериялық — екі түрлі хост» сияқты дубльдерді ережелер арқылы анықтау
• күмәнді жазбаларды «тексеруді талап етеді» деп белгілеу, бірден жазуды жоюдан гөрі

BMC қолжетімсіз болғанда

Көбіне себептер: басқару желісіне маршрут жоқ, ACL-дар, интерфейс өшірілген, құпиясөз өзгертіліп, жүйеге енгізілмеген. Бұл қолмен шешуге айналмас үшін BMC қолжетімділігін бақылау контурын енгізіңіз: BMC жауап беріп жатыр ма, жоқ па және не үшін — желі ме, аутентификация ма әлде интерфейс өшірілген бе. Осылай деректер мәселесін инфрақұрылым проблемасынан оңай ажыратады.

ОС қайта орнату байланысын бұзады

Hostname немесе агентке сүйенсеңіз, ОС қайта орнатқанда кейбір белгілер өзгереді. Қатты-жабдықтың тұрақты идентификаторлары қажет: SMBIOS-тен алынған UUID, жүйе сериялық нөмірі және ең дұрысы — 2–3 өрістен тұратын буын. Сол кезде ОС өзгерсе де сервер бір CI ретінде сақталады.

CMDB шынайы орналасумен сәйкес келмейді

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

Қауіпсіздік және қолжетімділіктер: деректерді қауіпсіз жинау

Автожалданған CMDB пайдалы ғана емес, сонымен қатар деректер жинау жаңа тәуекелдерді тудырмауы керек. Негізгі қағида: қажетті минимум жинаңыз, минимум құқық беріңіз және әрекеттерді журналға жазып отырыңыз.

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

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

Практикалық шаралар:

• жинау үшін бөлек (read-only) есептік жазбалар, ортақ құпиясөз қолданбау
• BMC желісін сегменттеу және тек арнайы түйіндерден қолжетімді ету
• құпиясөздерді тұрақты түрде ауыстыру және қажет емес протоколдарды өшіру
• CMDB-де тек қажет өрістерді сақтау, конфигурацияның толық дампын сақтамау
• жинауды логтау: кім іске қосқан, қашан, қай түйіннен және қандай өрістер өзгергені

Барлығын «барлығын жинайық» деп жасамаңыз. Есеп үшін әдетте жеткілікті: өндіруші, модель, сериялық нөмір, UUID, BIOS/BMC нұсқалары және негізгі сипаттамалар. Қалғанын нақты кейс үшін ғана қосыңыз — әйтпесе деректер көлемі мен шабуыл беті өседі.

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

• осы өрістер бойынша автоприемді тоқтату
• SMBIOS пен BMC деректерін салыстыру, қажет болса жапсырма/акт бойынша тексеру
• оқиғаны тіркеп, соңғы расталған мәнге қалпына келтіру

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

Автотолтыруды енгізудегі типтік қателер

SMBIOS пен BMC-тен автожинақтау тез пайда әкеледі, бірақ ережесіз бастағанда тез хаос та туғызады.

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

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

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

Төртінші қате — барлық темірге бір CMDB схемасын қолдану. Сервер, жұмыс станциясы және моноблок өрістері ұқсас болса да, өмірлік цикл мен міндетті атрибуттары әртүрлі. Оларды біртипті етіп араластыратын болсақ, орынсыз міндетті өрістер мен қате есептер пайда болады.

Бесінші қате — жаппай импортта дубльдерді елемеу. Бұл жиі жартылай сәйкес кілттермен немесе кейбір деректер уақытша бос болған кезде болады.

Қорғауға жеткілікті минималды шаралар:

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

Мысалы: филиалда хосттарды қайта атағаннан кейін инвентаризация «DC-01» мен «DC-02» үшін екі жаңа жазба ашып, ескі жазбаларды қалдырып кеткен. Сервис-деск қате құрылғыға өтініш жазды, диагностика ұзарды. Сериялық нөмір бойынша сәйкестендіруге көшу және дубльдерді тексеру бір синхрондау циклінде тәртіп орнатты.

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

Өндірістік іске қосар алдында қысқаша чек‑лист

Парктің бәріне автотолтыруды қосар алдында ережелерді бекітіңіз. Әйтпесе автоматтандыру қателіктерді тез көбейтеді.

Мінімум — бұларсыз бастамаған жөн

• Әр актив үшін бірегей сәйкестендіру кілті бар: сериялық нөмір, UUID немесе басқа тұрақты идентификатор. Егер кілт кейде бос немесе өзгере берсе, резервті нұсқаны анықтаңыз (мысалы, сериялық + asset tag) және осындай жағдайларды тәуекел ретінде белгілеңіз.
• Әр өріске басты дереккөз белгіленген: қайсысын SMBIOS-тен, қайсысын BMC-тен аламыз. Ереже бірдей және қайталанатындай болуы тиіс.
• Жаңарту кестесі мен техникалық терезе орнатылған: деректерді қаншалықты жиі жаңартатыныңызды (күнде бір рет, апта сайын) және қашан опрос жасау серверге жүктеме туғызбайтынын шешіңіз.
• Сапа тексерісі бапталған: толтырылу және сәйкестік мақсаттары. Мысалы: сериялық нөмір толтырылу деңгейі ≥ 98%, модельдер бойынша дереккөздер арасында сәйкестік ≥ 95% типтік серверлер үшін.
• Сәйкессіздіктер туралы есептер және түзету процесі бар: кім конфликттер тізімін алады, қанша күнде жібереді, ерекшелік жағдайларда не істейді (плата ауыстыру, DMI өрістерінің қате толтырылуы, ескі прошивка, айырбасталған активтер).

Егер серверлер мен жұмыс станциялары Қазақстанда өндірілсе және GSE.kz арқылы қызмет көрсетілсе, прошивкаларды жаңарту және DMI өрістерінің дұрыстығы үшін кім жауапты екенін алдын ала келісу сәйкессіздіктер санын іске қоспай-ақ азайтады.

Практикалық мысал: бұл қалай диагностика уақытын қысқартады

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

SMBIOS пен BMC арқылы автотолтырылған CMDB-де картина бірден көрініп тұрады. Инженер карточканы ашып, модель мен сериялық нөмір, CPU және RAM құрамы, BIOS пен BMC нұсқалары, диск пен желі туралы негізгі ақпаратты бірден көреді. Дата-центрге фото сұраудың немесе хостқа әкімшілік кіріп деректер жинаудың қажеті жоқ.

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

Командалар арасындағы коммуникация да өзгереді. Бірінші деңгей тикетке CMDB-дегі нақты өрістерді тіркейді, инженерлер қосымша сұрақтар аз қояды, сатып алу модель мен сериялық нөмір арқылы кепілдік пен бөлшекті жылдам тексереді. Бұл әсіресе GSE.kz және басқа өндірушілер араласқан аралас паркінде байқалады: CMDB-дегі біртекті деректер диагностика жылдамдығын бірдей деңгейге көтереді.

Келесі қадамдар: пилот, кеңейту және GSE.kz көмегі

20–50 құрылғыдан тұратын пилоттан бастаңыз. Парктің «орташа» бөлігін алыңыз: бірнеше BMC бар серверлер, бірнеше жұмыс станциясы және 5–10 ПК. Осылай қай жерде деректер сәйкес келетінін және қай жерде нормализация ережелері керек екенін жылдам анықтауға болады.

Пилот табыстылығы үшін критерийлерді алдын ала бекітіңіз: кемінде 95% құрылғы модельі мен сериялық нөмірі қолмен енгізусіз алынуы; CMDB-дегі дубльдер ≤ 1–2%; CPU/RAM/сақтағыштар бойынша сәйкессіздіктер есепке түседі; нақты не және неге тартылмағанын көрсететін ерекшеліктер тізімі бар.

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

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

Интеграторды қосу қисынды болады, егер қай дереккөзді «бағынышты» санау туралы даулар пайда болса, бірнеше CMDB/жүйелер болса немесе деректер моделі мен келісім процесін жобалау қажет болса. Мұндай жұмыстарда GSE.kz өндіруші және жүйелік интегратор ретінде пайдалы болуы мүмкін: жинақтау, нормализация және сапаны бақылауды орнатуға көмектесіп, кейінгі тұрақты эксплуатация мен қолдауға өткізу.