500–2000 құрылғыға арналған open source CMDB: «өлі тіркеусіз»

Неліктен CMDB жиі 3 айдан кейін «тоқтап қалады»

«Өлі тіркеу» — CMDB бар деген формалды база, бірақ оған сенім жоқ. Деректер сенімді көрінеді, бірақ шындыққа сай келмейді: құрылғылар ауыстырылған, иелері өзгерген, сервистер басқа жерге көшірілген, ал жазбалар бұрынғы күйінде қалады. Нәтижесінде база есеп үшін ғана сақталады, жұмыс үшін емес.

500–2000 құрылғы көлемінде бұл мәселе тез күшейеді. Excel-мен 150–300 элементті, өзгерістер сирек және бір адам жүргізсе ұстап тұру мүмкін. Бұдан әрі тұрақты қозғалыс басталады: жаңа орындар, жөндеулер, филиалдарға техника беру, ОС қайта орнату, желідегі өзгерістер. Кесте соңғы нұсқасы мен кім жолды жаңартуы керек екенін білмейтін түзету кезегіне айналады.

CMDB «минималды» күйінде алдымен бірнеше практикалық міндетті шешуі керек, олар дереу пайда береді:

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

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

Бастапқы бағдар: 500–2000 құрылғыға арналған open source CMDB — инфрақұрылым энциклопедиясы емес, жұмыс картасы. Ол қолдау және әкімшілерге күнделікті көмек көрсетуі тиіс. Егер бұл болмаса, 3 айдан кейін оны жаңартуды тоқтатады да, қайта «шеттік үшін» тіркеуге айналады.

Мақсаттар мен шекаралар: «минималды» CMDB не екенін қалай санау керек

CMDB «минималды» идеалды әлем үшін емес, практикалық сұрақтарға жылдам жауап беру үшін керек: бұл не, қайда, кім жауапты, не басқарып тұр және оны өшірсе не бұзылады. 500–2000 құрылғы масштабы үшін бұл аса маңызды: қамту кең болған сайын қолмен қолдау қымбатқа түседі.

Шекараны бастапта анықтаңыз. Күнделікті өзекті ұстай алатынды таңдаңыз, қалғанын кейінге қалдырыңыз. Әдетте «әліппен жүргізілетіндер» — серверлер, виртуалды машиналар, желе жабдығы, маңызды бөлімшелердегі жұмыс станциялары, негізгі сервистер (пошта, 1С, клиникалық жүйе, СКУД). «Қазірге дейін жүргізілмейтіндер» — тұтыну материалдары, әрбір монитор, шағын периферия, бір рет қолданылатын тест стендтері.

Нәтижені қалай өлшеу

Метрикалар қарапайым және көрінетін болуы тиіс, «есептік цирк» қажет емес:

• Өзектілік: X күннен жаңа емес CI-лердің үлесі (мысалы, 14 күн).
• Толықтық: міндетті өрістері толтырылған CI-лердің үлесі (иесі, орналасуы, сериялық нөмір немесе басқа бірегей ID).
• Жауап беру жылдамдығы: инцидентте иені және тәуелділіктерді табуға кеткен уақыт.
• Қайшылықтар: апта ішінде табылған дереккөздер арасындағы қанша қайшылық және олардың қаншасы жабылған.

Міндетті процестер, база өміршең болуы үшін

Үш келісім қажет: кім CI жасайды, негізгі өрістерді кім өзгерте алады және дереккөздер келіспесе не есептеледі. Қысқа өзгеріс циклі де маңызды: сатып алу немесе эксплуатацияға енгізу жазба жасайды, орын ауыстыру орналасуды жаңартады, списание CI-ді жабады.

Терминдерді алдын ала бекіту де пайдалы.

CI — қызмет жұмысына әсер ететін нәрсе.

Актив — балансқа тіркелген нәрсе (әрдайым CI емес).

Қызмет — қолданушы үшін маңызды нәрсе (мысалы, «медициналық жүйеге қолжетімділік»).

Практикалық мысал: 1200 құрылғысы бар ауруханада регистратурадағы барлық ПК актив болуы мүмкін, бірақ CI тек критикалық процесс қатысатын, иесі мен қолдауы бар құрылғылар болады.

Ашық кодты платформа таңдау: фанатизмсіз неге қарау керек

500–2000 құрылғыға арналған open source CMDB әдетте «қате» платформа салдарынан емес, деректер тәртібінің болмауынан сәтсіз болады. Жазбаларды растау үшін адам жоқ, дереккөздер анықталмаған, интеграциялар «көзіктен» жасалған.

Практикалық тәсілмен таңдаңыз: жылдам «тірі» базаны беретін, идеалды схеманы емес.

Қандай шешімдер бар

CMDB белгісімен жиі үш тип жүйе таңдалады:

Классикалық CMDB — нысандар мен байланыстарға (жабдық, ПО, сервистер) бағытталған.

IPAM және DCIM — желі, адрестер, стойкалар және порттарды есептеуде күшті.

ITSM — өтініштер мен өзгерістер туралы, ал CMDB жиі «қоса беріледі».

Практикада: егер басты проблема — желі мен физикалық инфрақұрылым, NetBox-пен бастау ыңғайлы. Егер процесстер мен бекітулермен «кітабың» керек болса — iTop немесе CMDBuild. Егер CMDB-ның дереу service desk-пен бірге өмір сүруін қаласаңыз, GLPI ыңғайлы.

Қалай фанатизмсіз таңдау жасау

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

• Қатынау құқықтары мен рөлдер: кім түзете алады, кім тек қарайды, кім бекітеді.
• API және интеграциялар: AD, виртуализация, сканерлер, MDM-тен фактіні үнемі алу мүмкін бе.
• Импорт және жаппай правкалар: CSV, шаблондар, өріс сәйкестігі.
• Өзгерістер аудиті: кім, қашан, не өзгертті және даулы жағдайларды тексеруге бола ма.
• Өмірлік цикл: статустар («пайдалануда/қоймада/пайдаланудан алынған») және қарапайым валидация.

NetBox желі мен жабдықты нақты есептеу қажет болғанда жеңіске жетеді. iTop — сервистер арасындағы байланыстар мен өзгерістерді бақылауда жақсы. GLPI — service desk-пен бастауға ыңғайлы. CMDBuild — реттелетін модель мен формалар қажет болғанда жарайды.

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

Нысандар және байланыстар: өмір сүретін қарапайым деректер моделі

500–2000 құрылғыға арналған open source CMDB үшін күнде ұстап тұруға болатын модельден бастаған дұрыс. Нысандар тым көп болса, карточкаларды толтыру тоқтайды, база болжамдар архивіне айналады.

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

• Құрылғы (ПК, сервер, принтер, желілік)
• Қолданушы (қызметкер немесе рөл, мыс., «диспетчерлік смена»)
• Орын (ғимарат, қабат, кабинет немесе стойка)
• ПО (негізгі пакеттер мен нұсқалар)
• Қызмет (мысалы, «Пошта», «1С», «Видеобақылау»)

Кілт — карточкаларда бірдей минимум өрістер болуы.

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

Қолданушы үшін: табельдік нөмір немесе логин, бөлімше, статусы (жұмыс істейді/жоқ).

Орын үшін: код және бөлменің жауаптысы.

ПО үшін: атау, нұсқа, критикалықтылығы.

Қызмет үшін: сервис иесі және негізгі компоненттер тізімі.

Байланыстар тек шешім қабылдауға көмектесетіндей болсын: құрылғы — қолданушы (кім пайдаланады), құрылғы — желі (сегмент немесе IP), сервис — компоненттер (қандай серверлер, базалар, қосымшалар оны қамтамасыз етеді).

Мысал: 30 сервер және 900 жұмыс орны болғанда «Бухгалтерия» сервисі істен шықса, қандай серверлер мен қандай ПО оған қатысып тұрғанын және кім иесі екенін жылдам көресіз.

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

Бастапта тым терең модельдеуге болмайды. Көбінесе кейінге қалдыруға болады:

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

Дереккөздер: фактілер қайдан алынады, пікірлер емес

CMDB «минималды» болса да, карточкада тек анық дереккөздері бар өрістер болу керек. Егер өрісті үнемі растау мүмкін болмаса, ол тез дау болады.

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

Каталог және құрылғылар басқармасы: AD және MDM

AD-дан компьютер аты, OU/топтар, соңғы белсенділік, иесі (егер тіркелсе) және доменге байланысы алынуы тиіс. Жаңарту — күнделікті. «Соңғы кіру/белсенділік» өрісін жиірек жаңарту маңызды болса, жиі жаңарта беріңіз.

MDM (ноутбуктер мен телефондар үшін) сенімді мәліметтер береді: сериялық, модель, ОС нұсқасы, сәйкестік статусы, шифрлау. Бұл атрибуттарды күнделікті жаңартып отыру қауіпсіздік пен қолдауға пайдалы.

Агенттік жинау: қашан қажет

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

Бірақ бәрін топтастырмаңыз. Міндетті минимум: ОС және нұсқасы, сериялық, CPU/RAM/дискілер, негізгі қосымшалар (офис, браузер, VPN), және агенттің соңғы есебі күні. Егер агент есебі 14 күннен артық жүрмесе — құрылғыға сенуге болмайды.

Желілік деректер: SNMP, DHCP, IPAM және қатысу фактілері

Желі құрылғының инфрақұрылымда нақты болғанын көрсетеді. DHCP және ARP кестелері MAC-адрестің пайда болғанын, SNMP — басқарылатын құрылғыларды (коммутаторлар, принтерлер, ИБП) және олардың негізгі параметрлерін растайды.

Не факт ретінде санау керектігін келісіңіз. Практикалық нұсқа: соңғы N күн ішінде кем дегенде бір сенімді сигнал (агент, MDM, DHCP/ARP, SNMP) болса, объект «тірі» деп есептеледі. Осылайша CMDB «мәңгілік» жазбаларды сақтамайды.

Виртуализация және бұлт: маңыздысы

Виртуализация үшін маңызды: гипервизор/кластер, хост, VM аты, CPU/RAM/дискілер, желі, тэгтер/жоба және сервис иесі. Ең құндысы — «VM -> хост -> стойка/площадка» байланысы және соңғы растау күні.

Сатып алу және қойма: қайталанбау арқылы байланыс

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

Қайталанбаудан болдырмау үшін ереже жасаңыз: жаңа актив алдымен сатып алу/қойма есебінен «ввод күтілуде» пайда болады, ал «тірі құрылғы» тек IT-дереккөзінен (агент/MDM/желі) расталғаннан кейін ғана белсенді болып есептеледі. Осылай CMDB пікір емес, деректер базасы болып қалады.

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

CMDB платформа емес, ережелер арқылы өмір сүреді: кім деректерді жаңартайды, қаншалықты жиі және дереккөздер келіспесе не істеу керек. 500–2000 құрылғы көлемінде бұл әсіресе маңызды: қолмен түзетулер базаңызды тез пікірлер жиынтығына айналдырады.

Өрістерді бөліп, әр біріне шындық дереккөзін тағайындаңыз. Сериялық нөмір мен модель инвентаризациядан (агент, желі сканы, сатып алу), ал иесі мен бөлімше — HR немесе сервис-десктен келуі тиіс. Келістірмесеңіз, өрістер «кім қалай көрсе солай» жазыла бастайды.

Қарапайым 1–2 беттік регламентпен ережелерді бекітіңіз:

• Әр өріс үшін шындық дереккөзі: мыс., сериялық — инвентаризация, орналасу — орын ауыстыру есебі, списание статусы — өтініш.
• Жауапкершілік матрицасы: кім өзгерістер енгізеді, кім растайды, кім тек қарайды. Рөлдер бойынша (ИТ-операциясы, сервис-деск, ИБ, қойма), нақты адамдар емес.
• Жиілік: жабдық — оқиға бойынша (жеткізу, орын ауыстыру, жөндеу) және тоқсан сайын тексеру; ПО — жиірек (аптасына немесе жаңартудан кейін); иелік пен жауаптылық — кадрлық оқиғалар бойынша және айына бір бақылау.
• Қолмен өрістерге ережелер: қандай өрістерді қолмен өзгертуге болады, ал қайсысы тек жүйе-дерекқөзінен ауысады.
• Даулы объектілер статустары: «карантин», «расталмаған», «списание» және мерзімі.

Қайшылықтар болады. Мысалы, бір дереккөз «құрылғы офисде» десе, басқа «қашықтықтағы желіде» болуы мүмкін.

Қайшылықтарды қалай шешуге болады

1. Дереккөздердің басымдылығы: әр өріс үшін кім «жеңетінін» алдын ала анықтаңыз.

2. Жаңа мәліметтің жаңалығы ережесі: егер екі дереккөз жарамды болса, жаңасы жеңеді.

3. Адам арқылы тексеру: критикалық өрістерге (иесі, орналасу, статус) әсер етсе, растайтын тапсырма ашылады.

4. Карантин: объектіні N күн ішінде растай алмасаңыз, оны «анықталмаған» деп белгілеп, дәлдік маңызды есептерден шығарыңыз.

Пайдалы қағида: өзгерістер немесе «оқиға» (өтініш, жеткізу, жөндеу) арқылы орындалуы керек, немесе шындық дереккөзінен автоматты түрде. Барлығы басқа жолға кетсе, база тез «өлі тіркеуге» айналады.

4–8 аптада енгізудің кезеңдері: ауыртпалықсыз MVP

500–2000 құрылғыға арналған open source CMDB «өлі тіркеуге» айналмасын десеңіз, MVP-ден бастаңыз: минималды нысандар, минималды дереккөздер, бірақ айқын ережелер. Мақсат — фактілер ағынын қалыптастырып, деректер автоматты түрде немесе анық процеспен жаңартылуын қамтамасыз ету.

4–8 аптаға жоспар

Қысқа итерациялармен жүріп, әр қадам нәтиже беруі маңызды:

• 1-апта: құрылғылар мен орындардың минималды каталогын жинап, біркелкі атау форматын келісіңіз (офистер, қабаттар, сервер бөлмелері, стойкалар).
• 2–3 апта: 1–2 дереккөзді қосып, өрістерді (серия, модель, ОС, IP, иесі, соңғы белсенділік) автоматты толтыруды баптаңыз.
• 4-апта: статустар мен қарапайым өзгеріс процесін қосыңыз: «жасады — өзгертті — списание», күрделі бекітулерсіз.
• 5–6 апта: расхождeniе бойынша тексеру және есептер қосыңыз, база «ағып кеткен» жерлерді көріп отыру үшін.
• 7–8 апта: модельді тек тұрақтанғаннан кейін ғана кеңейтіңіз, расхождениелер азайған және өңдеу анық болған кезде.

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

Процестерді шамадан тыс күрделендірмес үшін

Рөлдерді осылай бөліңіз, «бәрі жауапты — ешкім жауапты емес» деген жағдай болмас үшін:

• CMDB иесі: ережелерді және дауларды бекіту.
• Площадка бойынша жауаптылар: орналасуларды және орын ауыстыруларды растау.
• Эксплуатация: статустарды және списание жүргізу.
• Қауіпсіздік: критикалық активтерге мінез-құлық талаптарын қою.

Мысалы, ноутбук бөлмеден бөлмеге көшсе, бір операциямен орналасу мен датаны өзгерту жеткілікті. Апталық тексерулер AD/желіден көрінетін, бірақ базаға енбеген құрылғыларды көрсетіп, оларды талдап жоюы тиіс. Егер осы есептер аптасына бір рет қаралып, ауытқулар жабылса, CMDB тұлғаның энтузиазмына емес, тұрақты рәсімге сүйенеді.

Сапа тексерулері: база шашырамау үшін

CMDB «шашырай бастағанда», әдетте әр дереккөз бір құрылғыны әртүрлі сипаттайды. 500–2000 құрылғы үшін жазбаларды қалай сәйкестендіретініңізді және не шындық екенін алдын ала келісіңіз.

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

• сериялық нөмір (физикалық жабдық үшін ең жақсы)
• UUID/Asset Tag (егер толығымен толтырылса)
• hostname (қосымша, себебі өзгере береді)
• MAC-адрес (док-станциялар, Wi‑Fi/ETH айырмашылықтары мен платалар ауысуы салдарынан сақ болу қажет)

Дедупликация ереже болсын, бір рет жасалатын тазалау емес. Егер импорт «күшті» кілт бойынша сәйкестік тапса, ол бар жазбаны жаңартасын, жаңа жазба жасамауы тиіс. «Әлсіз» кілт бойынша сәйкестік табылса, жазба тексеруге жіберіледі.

Нормализация справочниктерді таза ұстайды. Бір ноутбук бірнеше атымен көрінсе («HP 840 G8», «EliteBook 840», «840G8»), парк бойынша сүзгілеу және ауыстыруды жоспарлау қиын болады. Модельдер, орындар және бөлімшелер үшін біртекті анықтамалықтар жасап, оларды шектеулі топ қана өзгерте алсын.

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

Сапаны ұстап тұру үшін көбіне үш апта сайынғы есеп жеткілікті:

• «Аптада жаңа және өзгергендер» (не пайда болды немесе кенет өзгерді)
• «Сәйкестендіру қайшылығы» (әлсіз кілтпен сәйкестік және дубль күдігі)
• «Ескірген деректер» (N күн жаңартылмаған құрылғылар және бос критикалық өрістер)

Егер осы үш есеп тұрақты қаралып, қарапайым әрекет процесі болса, база тірі қалады.

Ашық кодты CMDB-да жиі кездесетін қателіктер

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

CMDB-ны жиі бұзатын нәрселер

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

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

Үшінші — негізгі жаңартуларды қолмен жасайды деп сену. Қолмен түзетулер керек, бірақ тек ерекше жағдайларда. Егер CMDB өзгерістерінің 70% қолмен жасалса, база міндетті түрде артта қалады.

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

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

Практикалық мини‑тексеру

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

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

Жылдам чек-лист: CMDB тірі ме, әлде реестрге айналып барады ма

CMDB тірі болғанда онда жай карточкалар ғана емес, анық ережелер бар: факт қайдан келеді, кім жауапты және қаншалықты жиі жаңартылады. 500–2000 құрылғыға арналған open source CMDB үшін төмендегі қысқа өз-өзіне тест тез қай жерде база «қаттыса» екенін көрсетеді.

Бес сұрақ:

• Әр маңызды өрістің «шындық дереккөзі» және иесі бар ма.
• Барлық құрылғыларда бірегей идентификатор және түсінікті статус бар ма (өнімде, қоймада, жөндеуде, списанған).
• Екі минимум дереккөзі қосылған және жаңарту кестесі бар ма.
• Расхождениелер бойынша тұрақты есеп бар және оңай түзету процесі анықталған ба.
• Жаңа құрылғы қосу және списание қолмен көп «сауын» талап етпейді: бір әрекет тізбекті іске қосады (өтініш, қабылдау, статус тағайындау, CMDB-де пайда болу).

Егер осы сұрақтардың екеуіне болса да «жоқ» десеңіз, CMDB «өлі тіркеу» режиміне бет алды. Ең ауыр жерден бастаңыз: 5–7 негізгі өріс үшін шындық дереккөзі мен иелерін анықтаңыз — бұл барлық басқа әрекеттерден жылдам нәтиже береді.

Мысал сценарий: 1200 құрылғыда өзектілікті қалай ұстап тұру

Шарттар: 1200 офис ПК, 80 сервер, 5–7 филиал. AD бар, серверлердің бір бөлігі виртуалда, желі басқарылатын коммутаторлармен. Техника есебі кестелерде және «бас миында». Минималды CMDB мақсаты — «бұл құрылғы қандай, қайда тұр, кім жауапты және бұл қалай расталған» сұрақтарына тез жауап беру.

Бірден бәрін енгізбей, үш нысаннан бастаңыз: Құрылғы, Орын, Жауапты. Құрылғы үшін 8–10 өріс жеткілікті: тип, атау/hostname, сериялық (бар болса), ОС, иесі (бөлімше), орналасу, критикалықтылығы, факт дереккөзі. Осылай 500–2000 құрылғы үшін open source CMDB алғашқы аптада-ақ пайда әкеле бастайды.

AD және желіні сүзгілермен қосыңыз, әйтпесе база шуға толады. AD-дан тек белсенді компьютерлер мен серверлер (мыс., соңғы 30 күнде байқалған) және қажетті атрибуттар алыңыз. Желіден «байланыс нүктелерін» (MAC, IP, порт, коммутатор) бақылау ретінде, датамен сақтаңыз — бұл «мәңгілік шындық» емес.

Апталық rutina қысқа және міндетті болуы керек:

• Автосбор кестесі бойынша (AD, сканер, гипервизор) деректер жинау және CMDB-ге жүктеу.
• Расхождениелер бойынша есеп: «AD-де бар, CMDB-де жоқ», «орын өзгерген», «құрылғы 30+ күн көрінбейді».
• Топ-20 расхождениені жауаптылармен талқылап шешу (орын ауыстыру, списание, ауыстыру).
• Ережелерді жаңарту: әр өріс үшін шындық дереккөзі не.

2–3 ай ішінде тәртіп дұрыс болса әдетте көрінеді:

• Құрылғылардың 85–95% тұрақты орналасуы мен иесі расталады.
• Жаңа құрылғылар CMDB-ге 1–3 күнде енеді, «кейінірек қашан» емес.
• Списания мен ауыстырулар жазбаларды жоғалтпай өтеді (не және неге өзгергені көрінеді).
• «Кімнің бұл ПК/сервер екенін табу» уақыты қысқарады және тексерулерге дайындық оңай.

Құпия — деректер көлемінде емес, әдетте: әр аптада расхождениелерді жабу, айлар бойы жинау емес.

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

CMDB күнделікті маңызды 5–10 сұраққа жауап беруі керек: мысалы, «қай ноутбуктар шифрланбаған», «қолдауы жоқ серверлер қайда», «қай жүйеде критикалық сервис жүріп тұр», «қызмет иесі кім және қайда орналасқан». Мұндай сұрақтар болмаса, база жылдам архивке айналады.

Ұйымыңызға сәйкес минималды нысандар мен факті дереккөздерін жинаңыз. 500–2000 құрылғыға әдетте жеткілікті: инвентарлы объектілер (құрылғылар, ПО/агенттер, желі) және 2–3 бизнес-нысан (бөлімше, иесі, критикалықтылық).

Өзгерістер ережелері мен минималды рөлдерді бекітіңіз. Әйтпесе сіз деректер емес, пікірлер аласыз:

• Деректер иесі: шындықты кім анықтайды (құрылғылар бойынша — эксплуатация командасы, қолданушылар бойынша — HR/AD, орналасулар бойынша — ғимарат әкімшілігі).
• Жүктеу жауаптысы: импорт кестесін және қателерді кім бақылайды.
• Қайшылық ережесі: қай дереккөз басым және егер екеуі де келіспесе не істеу керек.
• Жаңалық ережесі: қанша күннен кейін жазба ескірген болып есептеледі және әрі қарай не болады.

Пилотты «бірақ бір бөлімшені толық жүзеге асыру» принципімен құрыңыз: бір бөлімше немесе бір аймақ таңдап, циклды толығымен орындаңыз — жинау, нормализация, салыстыру, жаңарту. Мысалы, 250 құрылғысы бар филиал: 2 апта ішінде сериялық нөмірлер мен иелер бойынша 90% қамтуды алыңыз, содан кейін екінші дереккөзді (MDM немесе желі сканы) қосып, қайшылықтарды қалай шешетініңізді тексеріңіз.

Егер пилот кезеңінде көптеген дереккөздер болса, филиалдық желі, аудит талаптары немесе CMDB-ны өтініштер мен мониторингке енгізу қажет болса, интегратор қажет болуы мүмкін.

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