Қандай деректерді ИТ-тен сұрау керек, есептеу қайта тексерілетін болуы үшін

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

Қайта тексерілетін есеп фиксирленген кіріс деректерден және айқын жазылған шамалаулардан басталады. Сол кезде басқа маман сол деректерге сүйене отырып дәл сол сандарды алады. Бұл — қайталанғыштық: қай серверлер есепке алынғаны, қандай метрикалар қолданылғаны, Oracle ережесі бойынша және неге екені анық болады.

Көбіне бірнеше қарапайым артефакт жеткілікті: хосттар мен кластерлердің инвентарь шығару файлдары (CMDB немесе виртуализация жүйесінен), әр физикалық сервер бойынша CPU конфигурациясын растау, Oracle орналастыру схемасы (қай жерде іске қосуға рұқсат берілгені, соның ішінде миграциялар), өнімдер мен опциялардың тізімі (DBA-шығарылымдардан), сондай-ақ орталардың тізімі (prod, test, DR) және олардың қолданылу ережелері.

ИТ ішіндегі сұрауды рөлдер бойынша бөлген дұрыс. Инфрақұрылым жабдық пен хосттарды растайды, виртуализация командасы кластерлер мен миграция ережелерін сипаттайды, DBA нақты опциялар қолданылуын береді, ал қауіпсіздік пен архитектура шектеулерді белгілейді (мысалы, ВМ-ді кейбір хосттарға көшіруге тыйым).

Қарапайым мысал: «VMware-кластер, 10 хост» деп жазсаңыз, есепті 10 хосттың барлығына жасай береді. Ал егер ИТ Oracle ВМ-дері 4 хостқа бекітілгенін және бұл техникалық түрде enforced екенін растаса, сандар өзгеше болады және оларды қорғауға болады.

Алдымен шеңберді нақтылаңыз: не лицензиялануда және не үшін

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

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

Одан кейін периметрге кіретін нақты Oracle өнімдері мен редакцияларын тізіп шығыңыз. «Oracle Database» деп жалпы жазудың орнына дәлірек көрсетіңіз: Database Standard Edition 2 немесе Enterprise Edition. Опциялар мен management pack-тарды бөлек көрсетіңіз, егер олар қолданылса. Егер әлі сенімді болмасаңыз, сол пайдаланудың растауды қажет ететінін көрсетіңіз.

Әр позиция үшін есептеу қандай метрика бойынша жүргізілетінін анықтаңыз: Processor немесе Named User Plus. Толық есептеу үшін серверлер мен виртуализация деректері қажет болады, бірақ шеңбер деңгейінде не есептеп жатқаныңызды түсіну маңызды.

Негізгі нәрселер бойынша дау шықпасын десеңіз, ТЗ-да бес сұраққа жауап беріңіз:

есептің мақсаты (сатып алу, аудит, миграция, қолдауды ұзарту);
қай Oracle өнімдері мен редакциялары кіретіндігі;
қай орталар кіретіндігі (prod, test, dev, DR, оқу, пилоттар);
әр позиция үшін арнаулы метрика;
инвентарь «қырқ» күні және жоспарлау горизонты (мысалы, 3 жыл).

Егер сіз қазір prod пен test-ті легализациялап, бір жылдан кейін DR жоспарласаңыз, оны бірден жазған дұрыс. Әйтпесе есеп тек ағымдағы күйге негізделіп, бюджет кейінірек «шақырылады».

Физикалық сервер параметрлері: сокеттер, ядра, CPU моделі

Қайта тексеру көбіне «темір» деңгейінде үзіледі. Oracle орнатылымын нақты физикалық хосттармен бірмәнді байланыстыру маңызды. Мұнда әдеттегі мәселе—атаулардың әр түрлі жүйелерде бір-бірінен өзгеше болуы (hostname, инвентар нөмірі, мониторинг атауы) және кейін дәл сол объект екендігін дәлелдеу қиынға соғады.

ИТ-тен физикалық серверлер инвентаризациясын бөлек кесте түрінде сұраңыз, әр жол — бір хост. Міндетті минималды өрістер алдын ала бекітілгені дұрыс:

идентификаторлар: сервер моделі, сериялық нөмір немесе asset tag, орналасқан жері (ЦОД/площадка), рөлі (prod БД, тест, DR);
CPU: өндіруші мен нақты модель, сокеттер саны, сокет бойынша физикалық ядра саны;
CPU баптаулары: Hyper-Threading/SMT қосылған ба (әдістемелік ақпарат ретінде);
ресурстар шектеулері: hard partitioning бар ма, қандай технология, баптауды немен растайды (шығарылым/скриншот);
ОС және басқару: ОС типі мен нұсқасы, гипервизор орнатылған ба, қалай басқарылатыны.

«Шындық» қайдан алынатынын де атап өтіңіз. Мысалы: «Ядра саны өндіруші/инвентарь жүйесінен алынады, виртуалды машина қонағының ОС-ынан емес». Бұл қонақ ОС-та тек берілген vCPU көрінгенде дауды болдырмайды.

Екі бірдей сервер бір ЦОД-та болса, бірақ біреуі прод үшін, екіншісі тест үшін болса, кестеде әрқайсысының жеке asset tag және рөлі көрсетілген болуы керек. Солай оларды бір объект ретінде қосуды немесе керісінше біріктіріп жіберуді болдырмайсыз.

Виртуализация және кластерлер: Oracle нақты қай жерде жүруі мүмкін

Виртуал ортада негізгі сұрақ — «VM-нің қанша vCPU» емес, «келесі күні бұл VM қандай физикалық хостқа түсуі мүмкін». Егер бұл белгіленбесе, шекараны оңай бүкіл кластерге дейін кеңейтуге болады, және қайта тексерілетін есеп орнына дау туындайтын есеп пайда болады.

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

ТЗ-да «лицензиялау шекарасы» ұғымын енгізіп, оны кіріс деректерге байлаңыз:

кластерлер тізімі және әр кластердегі барлық хосттар (атауы, сокеттер, ядра, CPU моделі);
DRS/HA ережелері: автоматты көшіру қосылған ба, affinity/anti-affinity бар ма, қай хосттар failover деп есептеледі;
Oracle ВМ-дерін қай хосттарда іске қосуға рұқат беріледі (allowed hosts, белгіленген кластер);
Oracle ВМ параметрлері (vCPU, RAM) және пайдаланылса шектеулер;
растау үшін: vCenter/SCVMM/CMDB шығару файлдары және қажет болса саясаттардың скриншоттары.

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

Жоғары қолжетімділік және резерв: RAC, Data Guard, DR және тест орталар

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

RAC және деректер базасының кластері

Oracle RAC қолданылса, қарапайым фактілерді сұраңыз: нодтар саны, олар қандай хосттарда орналасқан, қандай нодтар үнемі белсенді, ал қайсысы тек резерв үшін. Кейбір нодтар көбіне бос тұрса да, оларда инстанс іске қосыла ма деген шартты түсіну маңызды.

Data Guard, DR және тест орталар

Data Guard үшін атауы емес, параметрлері маңызды: физикалық немесе логикалық standby, режимі (синхронды/асинхронды), standby қай жерде орналасқан (бөлек сервер, бөлек кластер, басқа площадка). DR үшін аппараттық құрам мен сценарийлерді бекітіңіз: сынақ ауыстырулары қаншалықты жиі жоспарланады, DR-да база қанша уақыт жұмыс істей алады, кім ауыстыру командаларын береді.

Есеп шамалауға ілінбеуі үшін әр орта (Prod, Standby, DR, Test/UAT) бойынша толтырыңыз:

шешім түрі (RAC, single instance, Data Guard, резервсіз);
инстанстың іске қосыла алатын хосттар/кластерлер тізімі;
рөлдер (active, passive, standby) және ауысу ережелері;
апаттық жағдайда жұмыс істеуге рұқсат етілген уақыт және DR тесттерінің жиілігі;
кім әкімшілік етеді және кімде инстанстарды көтеру құқығы бар.

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

Опциялар мен management packs: базада нақты не қолданылып жатқанын анықтау

Подготовка к госзакупке

Обсудим требования закупки и документацию для проектов с приоритетом локального содержания.

Связаться

Ең жиі даулардың себебі — серверлер емес, қосылған опциялар мен management pack-тар. Маңыздысы — «Oracle Database бар» деп қана қалмай, әр ортада қандай функциялар шын мәнінде қолданылатынын бекіту.

Алдымен әр база бойынша негізгі ақпарат жинаңыз: Oracle Database нұсқасы, редакциясы (SE2 немесе EE), қайда орналастырылған (хост немесе кластер). Бұл маңызды, себебі кей опциялар тек Enterprise Edition-да қолжетімді, ал management pack-тар бөлек лицензияланады.

Одан кейін әр база үшін қосылған немесе кем дегенде бір рет қолданылған опциялар мен пакеттерді тізіп шығыңыз. Көбіне Partitioning, Advanced Compression, Advanced Security, Database In-Memory, RAC, сондай-ақ Diagnostic Pack пен Tuning Pack туралы даулар туындайды.

«Ауызша» сеніп қалмаңыз. DBA-дан күні мен көзін көрсететін растамаларды сұраңыз, мысалы:

базалар бойынша нұсқалар мен редакциялар (Oracle жүйелік көріністерінен);
функция қолданылу есептері (мысалы, DBA_FEATURE_USAGE_STATISTICS);
пакеттер қолданылғанының белгілері (мысалы, Diagnostic Pack үшін AWR/ADDM есептері, Tuning Pack үшін SQL Tuning Advisor тапсырмалары);
параметрлер мен конфигурациялар (компрессия, партициялау, RAC-конфигурация).

ТЗ-да негізгі Oracle лицензиясын және әр опция/пакетті бөлек есептеу ережесін жазыңыз. Солай жеткізушінің есебін сіздің инвентаризацияңызбен салыстыру оңай болады.

Орталар арасында функциялар әртүрлі болуы мүмкін екенін де айқындаңыз. Мысалы, prod-та Partitioning пен Compression қосылған, ал test-та олар өшірілген болса, бұл деректерде көрсетілмесе, опциялар барлық ортаға есептеліп қалады және соманы даулау қиын болады.

Processor немесе Named User Plus: таңдау үшін қандай деректер керек

Метриканы ТЗ-да нақты көрсеткен дұрыс. Әйтпесе жеткізуші «қолайлы түрде» есеп шығарады, және оны тексеру қиын болады.

Named User Plus (NUP) шеңбері нақты шектелген пайдаланушылар саны бар кезде қолдануға ыңғайлы. Қайта тексерілетін есеп үшін «шамамен 200 адам» емес, есептеу қалай жасалғанының дереккөзі мен әдісін көрсетіңіз: кім деректер қорына тікелей қосылады немесе қолданба арқылы қосылады, сыртқы жүйелер сұраныс жіберіп отыра ма.

NUP үшін әдетте қажет деректер:

рөлдер мен қол жеткізу топтары (пайдаланушылар, әкімдер, әзірлеушілер, мердігерлер);
сервис-шоттар және техникалық пайдаланушылар (қалай және кім пайдаланады);
интеграциялар (сыртқы жүйелер, API, есептер, боттар, RPA);
қолданбада мүмкін болатын пайдаланушылар саны, егер база оның артығында болса;
қолжетімділік шектеулері (VPN, подсетьтер, SSO-топтар, қолданба лицензиясы сияқты шектік мәндер).

Processor көбіне пайдаланушылар көп болғанда, қолжетімділік қосымшалар арқылы жүзеге асырылғанда немесе интеграция көп болғанда таңдалады. Онда NUP дауқа айналады. Бұл жағдайда инфраструктура фактілері маңызды: Oracle нақты қай серверлерде жұмыс істей алады, соның ішінде кластерлер, миграциялар және failover. Мұндай деректер үшін ТЗ-да сокеттер, ядра, CPU моделі және Oracle іске қосуды рұқсат еткен хосттар/кластерлер тізімі қажет.

Практикалық ереже: егер ИТ пайдаланушылар санын және барлық «техникалық» қосылымдарды сенімді растай алмаса, екі нұсқада — NUP пен Processor бойынша — есеп беруді сұраңыз, айқын шамалаулар мен финал таңдау үшін қандай деректер қажет екенін көрсетіп.

Кіріс деректерді ТЗ-да қалай рәсімдеу: кестелер және шамалаулар

Контроль изменений в среде

Настроим правила изменений, чтобы перенос ВМ и рост кластера не ломали расчет.

Согласовать план

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

Әдетте екі кесте және нәтижелер форматына қысқа талап жеткілікті.

1) Шығу деректер кестесі (фактілер)

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

объект (хост/кластер/пул) және рөлі (prod/test/dev);
CPU (модель, сокеттер, физикалық ядра, Hyper-Threading белгісі);
виртуализация (платформа, vMotion/Live Migration бар ма);
Oracle (өнім/редакция, Processor немесе NUP метрикасы);
шектеулер (Oracle қай жерде іске қосуға болады: иә/жоқ, рұқсат етілген хосттардың тізімі).

2) Шамалау кестесі (не және неге қабылданған)

Мұнда расталмаған, бірақ қабылданған барлық нәрселерді және олардың негізін бекітіңіз. Мысалы: «кластердегі бар барлық хосттар есепке алынады, себебі миграция тыйым салынбаған» немесе «DR есепке алынбайды, себебі орта жылына 2 рет тест үшін қосылады». Егер шамалау құжатпен немесе баптаумен расталмаса, солай жазып қойыңыз.

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

ТЗ-да сонымен қатар нәтижелер форматын талап ету орынды: есеп жол-жолмен, формулалармен, коэффициенттермен, аралық сомалармен және әр қадамның түсіндірмесімен берілуі тиіс. Мысалы, «кластер 6 хосттан тұрады, Oracle тек 2 хостқа рұқсат етілген» деп жазылса, есепте неліктен 2 хост лицензияланатыны (егер көшіру тыйыммен расталса) немесе неге 6-сы лицензияланатыны көрсетілуі керек.

ТЗ-да жиі жіберілетін қателіктер, кейін есепті даулауға алып келетіндер

Даулар көбіне бағадан емес, бастапқы деректерден басталады. Егер ТЗ-да шекаралар мен шамалаулар айқын болмаса, есеп «ең жаман» сценариі бойынша жасалады, ал тапсырыс беруші кейінкері дәлелдей алмай қалады.

Типтік қателіктер:

ВМ-нің нақты орналасуын ғана сипаттап, қайда миграциялануы мүмкінін көрсетпейді («Oracle ESXi-03-де» деп қана жазады). vMotion/DRS бар кластерде егер шектеулер жазылмаса, есеп әдетте бүкіл пулға жасалады;
standby және DR-ды ұмыттады. Сервер көбінесе өшірулі болуы мүмкін, бірақ егер оны тесттерде немесе тексерістерде қосатын болса, пайдалану режимін сипаттау қажет;
опцияларды және packs-тарды бекітпеді. Көбіне «қолданылмайды» дейді, бірақ функция қосылған болса, ол бөлек лицензияланады;
prod пен test-ті бір кластерде араластырып, қатаң орын ауыстыру ережелерін көрсетпей, лицензиялау шекарасын бұрмалайды;
«қырқ» күнін және өзгерістерді бақылауды белгілеген жоқ: ТЗ келісім кезеңінде хост қосып, CPU өзгертсе немесе кластер кеңейсе, есеп ескі күйге сай қалады.

Жақсы тәсіл — қысқа сценарий мысалын қосу: «Oracle-ВМ кластер 6 хосттан тұратын ортада жұмыс істейді, миграция affinity ережесі бойынша тек 2 хостқа рұқсат етілген, қалғандары шеттетілген». Осылай жеткізуші дәл осы шарттар бойынша есеп көрсетуі тиіс.

ТЗ-ны жеткізушіге жібермес бұрын қысқа чеклист

Жібермес бұрын кіріс деректерді қайта тексеріңіз:

Oracle болуы мүмкін барлық площадкалар, кластерлер және хосттар толық тізімі бар (соның ішінде test, DR және миграция уақытша аумақтары);
әр хост үшін сокеттер, физикалық ядра және CPU моделі тіркелген;
виртуализация бойынша орналастыруға әсер ететін ережелер сипатталған: DRS/HA, миграциялар, affinity/anti-affinity, закрепление, тыйымдар;
Oracle өнімдері мен опциялары DBA немесе инвентаризациямен расталған, ауызша емес;
жеткізушіден нәтиже деректер кестесі және бөлек бөлімде барлық шамалаулар сұралады.

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

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

Уточнить рамки виртуализации

Разберем границы кластеров, миграции и DR, чтобы убрать спорные допущения.

Получить консультацию

Мысал ретінде: Oracle Database VMware-кластерде ВМ ретінде жұмыс істейді (кластер 4 хосттан), ал басқа площадкада standby бар DR. Мақсат — осылайша сипаттап, жеткізушінің есебін сол деректерге сүйеніп қайта есептеуге болады.

Сценарий (бір абзацпен)

Prod: бір ВМ Oracle DB-пен, ол VMware-кластер бойынша миграциялана алады. Test: сол кластерде бөлек ВМ, ресурстары аз. DR: Data Guard standby басқа площадкада, режимі бойынша (үнемі қосулы немесе тек апатта қосылады) сипатталған.

Жауап үшін ИТ-ке жазбаша сұраңыз:

кластердегі ESXi-хосттардың нақты тізімі және DRS/автомиграциялар қосылған ба;
Oracle-ВМ-ге қатысты нақты миграция шектеулері бар ма (және кім бекітеді);
ВМ-ге бөлінген ресурстар (vCPU, RAM, резервы/лимиттер);
DR қалай ұйымдастырылған: бөлек кластер ме, қай хосттар, standby режимі, ауыстырулар жиілігі;
қандай Oracle опциялары қандай орталарда қолданылатыны.

Содан кейін есепті жол-жолға бөліп жасаңыз: prod, test, DR және опциялар/management packs жеке жолдарымен, метрика көрсетіліп (Processor немесе NUP) және шекаралары туралы шамалаулар жазылған.

Жеткізушінің жауабын тексеру үш нәрсеге келеді: хосттар/кластерлер тізімі сәйкес пе, миграция туралы шамалаулар сәйкес пе, prod, test және standby бөлек есептелген бе. Егер жеткізуші кей хосттарды қалдырмаса, негізін көрсетсін (миграция ережесі, тыйым, архитектуралық шешім) және кім бекіткенін.

Келесі қадамдар: жұмысты қалай ұйымдастыру және мәліметтер жоғалтпау

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

Деректер иелерін анықтаңыз: кластер құрамын кім растайды, хост конфигурациясын кім, VM нақты орналасуын кім, Oracle опцияларын кім.

1–2 аптаға арналған жұмыс тәртібі:

CMDB, vCenter/аналогтардан және DBA есептерінен инвентаризация жинап, бір кестеге дата және жауапты көрсетіп біріктіріңіз;
«лицензиялау шекараларын» келісіңіз: Oracle қайда іске қосылуға рұқсат етілген, қай хосттар шеттелген, қай кластерлер миграцияға ашық;
өзгерістер ережелерін бекітіңіз: не бұзушылық саналады (мысалы, ВМ-ді басқа кластерге көшіру) және оны кім бекітеді;
жеткізушіден табличный есеп сұраңыз: әр сервер/кластер бойынша бөлек жол, метрикалар үшін бөлек бағандар және опциялар/pack-тар тізімі;
логиканың сәйкес екеніне көз жеткізу үшін 1–2 нодта ішкі тексеру жүргізіңіз.

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

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