Жұмыс орындарындағы Java инвентаризациясы: нұсқалар, тазалау, сатып алу

Неліктен жұмыс орындарындағы Java/JRE проблема тудырады

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

Негізгі мәселе Java‑да емес, нұсқалардың әртүрлілігінде. Бір ұйымда әртүрлі JRE нұсқалары болғанда осалдықтар, істен шығулар және күтпеген тәуелділіктер пайда болады. Бірдей қосымша бір пайдаланушыда іске қосылып, екіншісінде құлап қалуы мүмкін, себебі «сол» нұсқа everywhere орнатылмаған.

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

«Ұмытылған» орнатулар жиі күтпеген жерлерде болады: ескі шолғыш плагиндері, өшіп қалған толстые клиенттер, қол қою құралдары, МФУ және принтер утилиталары, кейде инженерлік ПО‑мен бірге. Миграциялар мен жұмыс орындарын ауыстырғаннан кейін мұндай «қоқындар» оңай өткізіліп кетеді.

Тағы бір жағдай — пайдаланушылардың өздері бағдарламаларды орната алатын құқықтары. Сонда параллель JRE, «портативті» жинақтар және жүйе жаңартушысына көрінбейтін бірнеше Java қалталары пайда болады.

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

СИ жобаларында жиі кездесетін сценарий: доменде басқарылатын орнатуы бар ПК‑лар бар, бір бөлігі оқшауланған контурда орналасқан, және everywhere әртүрлі Java. Мысалы, GSE.kz командасы аралас инфрақұрылымдарда бұл жағдаймен тұрақты түрде бетпе‑бет келеді — жалпы көрініс болмаса паркты қауіпсіз «тазалау» және қолдау мен сатып алуға бюджет дұрыс жоспарлау қиын.

Инвентаризацияға дайындық

Алдымен қамтуды анықтаңыз. Java тек «барлық ПК‑лар бірден» тексеру емес: қай жерде Java шынымен маңызды екенін түсіну маңызды. Бөлімдер мен құрылғы түрлерінің тізімін жасаңыз (офис компьютерлері, тонкие клиенттер, ноутбуктар, киоскалар), сондай‑ақ «ерекше» жұмыс орындарын: бухгалтерия, кассалар, медициналық жабдық АРМ‑дары, оқу сыныптары, филиал терминалдары.

Келесі этап — Java нақты қажет болатын қосымшалар тізімін жинау. Пайдаланушылардың сөзіне ғана сенбеңіз: жүйе иелерінен сұраңыз (1С, ЭДО, банк клиенттері, ведомстволық порталар, ішкі утилиталар). Әр қосымша бойынша үш нәрсені анықтаңыз: Java қазір керек пе, қандай нұсқа талап етіледі және ауыстыруға бола ма (мысалы, веб‑нұсқаға көшу немесе басқа модуль қолдану).

«Орнату» ұғымын келісіңіз. Есепте әдетте үш түрлі жағдай араласады: бөлек орнатылған JRE, орнатылған JDK және қосымшаның ішіндегі рантайм (Java қалтасы exe‑дің жанына орналасады). Оларды ажыратпасаңыз, көрсеткіштер асыра бағаланады және «тазалау» қате мақсаттарға бағытталуы мүмкін.

Процеске иелер мен келісім ережелерін тағайындаңыз. Минимум құрам: ИТ (деректер жинау және жою), ИБ (саясаттар мен тәуекелдер), сатып алу (лицензиялар және келісімшарттар), бизнес‑бөлімдер (маңыздылығын растайды). Бұл әсіресе жұмыс орындарының бір бөлігі оқшауланған контурларда болса маңызды — кез келген өзгерістер бөлек рәсім арқылы өтеді.

Белгіленетін өрістердің жиынтығын дереу орнатыңыз. Содан кейін деректер аудит пен сатып алу үшін қолдануға жарайды: өнім (JRE/JDK/embedded), шығарушы, нұсқа мен жаңарту (мысалы, 8uXXX), разрядтық және ОС, орнату жолы (embedded белгісімен), орнату күні немесе соңғы өзгеріс күні.

Қарапайым мысал: қаржы бөлімінде «есептілік үшін Java қажет» делінсе, тексеріп көргенде Java тек бір қол қою модулі үшін қажет екені анықталады, ал қалған ПК‑ларда бірден екі нұсқа «сәйкессіздік үшін» тұр. Дайындық қажеттіні артықтан тез ажыратуға көмектеседі және жұмысты тоқтатпайды.

Қадамдар: Java мен JRE нұсқаларын қалай анықтау

Тексеру «менде Java жоқ» деген даудан шықпау үшін алдын ала іздеу тәсілін анықтаңыз: бар инвентаризация жүйесі арқылы (бар болса), желі бойынша скрипттермен және бақылау үшін бірнеше ПК‑да қолмен тексерумен.

Машиналық іздеуден бастаңыз, бірақ бірнеше «жол белгілерін» бір уақытта тексеріңіз. Java жаңартулардан, банк клиенттерінен, ЭЦП‑дан, ескі бухгалтерлік модульдерден немесе әзірлеуші құралдарынан кейін қалуы мүмкін.

Java‑ны нақты қай жерден іздеу керек

Бір ғана көзге сенбей, бірнеше белгіге қараған дұрыс. Оларға орнатылған бағдарламалар тізімі, орнату қалталары (өкінішке орай стандартты емес каталогтарды қоса), JAVA_HOME және PATH айнымалылары, Windows реестріндегі (Uninstall, JavaSoft, MSI жазбалары) жазбалар, сондай‑ақ қызметтер, жоспарлағыш тапсырмалар және автозагрузка кіреді.

32‑бит және 64‑бит орнатуларды бөлек тіркеңіз. Бір ПК‑да екеуі де болуы мүмкін, және әр қосымша әртүрлі разрядтықты талап етуі ықтимал. Сондай‑ақ Java‑ның пайда болу каналын белгілеңіз: корпоративті таратудағы MSI, қолмен орнатылған EXE, қосымша ішіндегі тасымалданатын рантайм (embedded), жүйеде жазбалары жоқ «портативті» қалталар.

Содан кейін Java шынымен пайдаланылып жатқанын анықтау маңызды. Іске қосу белгілерін іздеңіз: java.exe/javaw.exe процестері, қосымша логтары, соңғы оқиғалар, конфигурациялар, онда java жолы нақты көрсетілген болуы мүмкін. Егер кассалық ПО немесе қол қою модулі аптасына бір рет Java іске қосса, бұл да «қолдану» деп есептеледі.

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

Офлайн‑желі және оқшауланған контурлар: деректерді қалай жинау

Оқшауланған сегменттерде инвентаризация шындықпен шектеледі: домен жоқ, орталық жүйелерге байланыс жоқ, кіру тек кестеге сәйкес мүмкін болады. Алдымен сегменттердің картасын жасаңыз: қай жерде AD және кәдімгі құралдар бар, ал қай жерде компьютерлер автономды (лабораториялар, медициналық жабдық, өндірістік АРМ‑дар, қорғалатын контурлар).

Офлайн үшін жұмыс істейтін нұсқа — тасымалданатын деректер жинау пакеті. Бұл Java/JRE тексеру скрипті мен есеп шаблонын қамтитын қалта немесе архив. Скрипт жергілікті іске қосылады, нәтиже файлға (CSV немесе JSON) сақталады және флешкаға немесе алдын ала дайындалған қалтаға салынады.

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

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

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

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

Қайсысын қалдыру керек, қайсысын жою керек екенін қалай түсіну

Негізгі қателік — кез келген Java‑ны «артық» деп есептеу. Нақты жағдайда орнатулардың бір бөлігі белгілі бір бизнес‑қосымшаға тәуелді, ал бір бөлігі бір рет қолданылғаннан кейін «на всякий» пайда болады.

Жай бөлу ыңғайлы: үш жағдай бар:

1. Қосымша ішіндегі Java (embedded runtime, jre/runtime қалтасы бағдарламаның каталогында). Мұндай ортамен әдетте араласуға болмайды: жаңарту үйлесімділікті бұзуы мүмкін, ал жою жұмысты тоқтатады.

2. Windows‑та жүйелік Java, оны бір немесе бірнеше қосымша қолданады.

3. Пайдаланушының өзі орнатқан нұсқа, ол ешнәрсеге байланыссыз және көбіне қажет емес.

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

Сосын «рұқсат етілген» нұсқаларды және ескі нұсқаларды шығару мерзімдерін белгілеңіз. Мысалы: кең таралған жұмыс орындары үшін бір актуалды LTS тармағы, ал ескі нұсқалар — тек ерекшелікте, ажырату күнімен бірге. Осылайша паркты сақтау және бір қосымша осал JRE тартқанда тәуекелді төмендету оңай.

Ерекшеліктерді дереу белгілеу дұрыс: жаңартуға жол бермейтін ескі жүйелер, зертханалық стендтер, фиксированный ПО жинағы бар терминалдар мен киоскалар, арнайы кесте бойынша жаңартылатын оқшауланған контурлар.

Қысқаша мысал: бухгалтерияда белгілі JRE‑мен ғана жұмыс жасайтын клиент бар, ал бірнеше қызметкерде екінші Java «қол қою үшін» ескі нұсқа бойынша орнатылған. Матрицада қайсысы міндетті, қайсысы ешбір іске қосылуға байланыспағаны көрінеді. Сонда міндеттісін ерекшелік ретінде қалдырып, қалған артықтарды жоюға болады немесе қосымшаның встроенный рантаймын қолдана отырып стандартты нұсқамен ауыстырады.

Қауіпсіз жою және ауыстыру: жұмыс орындарын «тазалау» жоспары

Пилоттан бастаңыз: әртүрлі бөлімдер мен рөлдердегі 10–20 ПК және бірнеше «проблемалық» орын, мұнда ескі қосымшалар жиі іске қосылады. Пилот нақты қай жерде Java қажет екенін және қай жерде ол жай ғана «жататынын» көрсетеді.

Оралу жоспарын алдын ала дайындаңыз. Минимум: қажетті нұсқалардың орнатушыларын сақтау (x86 және x64), Java‑ға тәуелді қосымшалар тізімін жазып қою және қай қолдау қызметкері ПК‑ға Java‑ны тез қайтарып қоя алатынын анықтау. Офлайн сегменттер үшін локал репозиторий мен қысқа нұсқаулық пайдалы.

Java‑ны «көзге қарай» емес, анықталған сценарий бойынша жойыңыз. Әдетте ереже: нақты сценарий үшін бекітілген нұсқаны қалдырамыз, дубликаттарды алып тастаған жөн (егер екі разрядтық бірдей қолданылмаса), ескі жаңартуларды жоямыз, ал embedded‑пен жұмыс тек олардың пайдаланылмайтыны расталған жағдайда жүргізіледі.

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

Ауыстыру сәтті өтуі үшін әр сценарийге «дұрыс» Java нұсқасын келісіп, офлайн‑пакетті дайындаңыз. Қолдаушыларға «не орнатамыз және не үшін» деген қысқа нұсқаулық және қосымша Java сұрағанда пайдаланушыға берілетін жауап шаблоны көмектеседі. Эксплуатацияны интегратор жүргізетін ұйымдарда (мысалы, GSE.kz) осындай пакеттер өзгертулер процедурасында стандарт ретінде бекітіледі.

Пайдаланушылардың орнатуларын бақылау және «өзбетінше әрекеттерді» болдырмау

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

Алдымен қарапайым ережені бекітіңіз: кім Java орнатуға және жаңартуға құқылы. Көбінесе пайдаланушы әкімші құқықтарымен ПО орнатпауы керек, жаңартуларды ИТ пакет арқылы жүргізеді. Егер кейбір рөлдерге кеңейтілген құқық керек болса, оларды рәсімдеп, бақылау қосыңыз: бөлек топтар, бөлек ПК, бекітілген нұсқалар.

Келесі қадам — орнатудың рұқсат етілген көздерін анықтау. Көбінесе 1–2 нұсқа жеткілікті: ішкі ПО дүкені, пакетпен тарату немесе ИТ сақтайтын бекітілген орнатушылар жинағы. Офлайн контурлар үшін бұл қолтаңбаланған тасымалдағыш немесе «алтын» образ болуы мүмкін.

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

Сондай‑ақ сұраныстар есебі қажет: не үшін Java керек, қай қосымша үшін, қандай мерзімге және қай ПК‑ға. Тәжірибе көрсеткендей, «қайта қарау датасын» (мысалы, 90 күн) қою пайдалы. Егер бизнес‑қажет расталмаса, келесі циклда Java жойылады.

Жиі бақылау сирек аудиттерден гөрі тиімді. Апта сайын немесе ай сайын өзгерістерді (жаңа орнатулар, нұсқа қайтарулар, екінші рантаймның пайда болуы, JDK белгілері) тексеріп отыруды жоспарлаңыз. Әдеттегі сигнал — бір ПК‑да әртүрлі қалталардан бірнеше java.exe пайда болуы немесе нұсқа сәйкес келмей өзгеруі.