GPO арқылы BSOD дамптарын жинау: сақтау, ретеншн, метадеректер

Неліктен ПК паркіндегі BSOD дамптарын орталықтандыру керек

Көк экран әдетте қолайсыз сәтте болады: пайдаланушы ПК-ны қайта жүктейді, ИТ файлдарды ала алмай қалады, ал бірнеше күннен кейін мәселе басқа құрылғыда қайталанады. Дамптар жоғалып кетеді, ал тергеу чаттар бойынша іздеуге және кімде қандай қателік болғанын еске түсіруге айналады.

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

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

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

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

Қандай дамптарды жинау және қандай формат таңдау керек

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

Мини-дамп (minidump) әдетте қандай драйвер немесе модуль құлағанын түсінуге жеткілікті. Ол шағын және жаппай жинауға ыңғайлы. Kernel dump (ядро дампы) драйверлер мен ядро жадысы туралы көбірек контекст береді және minidump себептер тізбегін көрсетпегенде көмектеседі. Full dump (толық жады дампы) сирек қажет: өте үлкен, көшіру ұзақ және жиі сезімтал деректерді қамтиды.

Әдепкі бойынша minidump C:\\Windows\\Minidump\\*.dmp ішіне түседі, ал kernel/full дамп көбінесе C:\\Windows\\MEMORY.DMP ретінде болады. Сонымен бірге аздаған қосымша заттарды сақтау пайдалы: Windows нұсқасы мен билд, негізгі драйверлер туралы ақпарат (мысалы, видео, желі, storage), сондай-ақ құлау алдын ала жазылған Windows журналдарының (System және Application) оқиғалары. Көп жағдайда WHEA, disk және bugcheck оқиғалары жылдам нұсқа береді.

Типтің таңдау ережесі практикалық түрде мынадай:

• Көпшілік офис ПК-лары мен ноутбуктар үшін — minidump.
• Сыналатын және критикалық жұмыс орындары (кассалар, медициналық құралдар, операторлық АРМ) үшін — kernel dump.
• Сирек және тұрақсыз қателер үшін — уақытша full dump, бірақ шектеулі тобына ғана.

Егер филиалдарда өткізу қабілеті төмен болса, minidump-пен бастау және тек жаңа файлдарды жіберу оңайырақ. Көп офлайн болатын құрылғыларға арналғанда — желіге қайта қосылғанда көшіруді іске қосып, қайта жіберілмеуді қамтамасыз ету керек.

Мысал: филиалда ноутбук Wi-Fi драйверін жаңартқаннан кейін апта сайын BSOD болады. Minidump қате кодын және модульді көрсетеді. Егер ақпарат аз болса, сол ноутбук моделі үшін 1-2 аптаға kernel dump қосып, драйвер мен ядро күйін кеңірек көруге болады.

GPO арқылы дамптарды жасау: негізгі шаблон

Жұмыс тұрақты болуы үшін барлық ПК-лар бірдей және алдын ала белгілі орынға дамп жазуды қамтамасыз ету қажет. Windows-та бұл System failure параметрлері және HKLM\\SYSTEM\\CurrentControlSet\\Control\\CrashControl тіркесіндегі тіркеу кілттері арқылы басқарылады.

Домендік GPO-да әдетте төрт нәрсені бекіту жеткілікті: дамп түрі, жолы, қайта жазу тәртібі және жазу үшін минималды шарттар.

Көпшілік офис ПК-ға сәйкес келетін базалық шаблон:

• Түрі: Automatic memory dump (немесе Kernel memory dump, егер өлшемі алдын ала белгілі болуы маңызды болса).
• Дамп файлы: %SystemRoot%\\MEMORY.DMP.
• Минидамп папкасы: %SystemRoot%\\Minidump.
• Логтар: сәтсіздік туралы оқиғаны жүйелік журналға жазуды қосу.
• Қайта жазу: қайта жазуға рұқсат беру және бұрынғы дампты сақтау қажет пе деп бөлек шешім қабылдау.

Практикада бұл CrashDumpEnabled, DumpFile, MinidumpDir, LogEvent, AlwaysKeepMemoryDump сияқты параметрлерге сәйкес келеді (нақты мәндер таңдалған дамп түріне байланысты). GPO арқылы орнатқанда, клиентте нәтижені дәл CrashControl арқылы тексерген ыңғайлы.

Жалпы енгізбес бұрын тест тобында мына нәрселерді тексеріңіз:

1. Дамп жазу өшірілмеген бе (кейде оптимизаторлар өшіріп қояды).
2. Жүйелік дискіде жеткілікті орын бар ма және үшінші тарап тазалағыштар оны өшірмей ме.
3. System дискінде pagefile бар ма (оның жоқтығы дамптың жазылмауына әкелуі мүмкін).

Өнімділік тұрғысынан компромисс қарапайым: Complete dump көбіне артық, ал Automatic/Kernel бастапқы гипотезалар үшін жеткілікті деректер береді және сақтау көлемін төтенше түрде көбейтпейді.

Автоматтандырылған жинау скрипттері: GPO арқылы іске қосу схемасы

Автоматтандыру пайдаланушы ешнәрсе іздемей-ақ, қолдау командасы дереу артефакттарды алатындай ету үшін қажет.

Алдымен нені көшіру керектігін анықтаңыз. Көбінесе бұл C:\\Windows\\Minidump\\ қалтасы және қажет болса C:\\Windows\\MEMORY.DMP. Толық дамп үлкен болғандықтан, оны тек шынайы қажетті жерде ғана жинаған дұрыс.

Келесі қадам — қарапайым PowerShell скрипті жазу: ол жаңа файлдардың бар-жоғын тексеріп, оларды уақытша папкаға көшіреді, ZIP-ке сығымдайды, күнделік жазады (файлға немесе оқиға журналына) және түсінікті шығу кодын қайтарады. Архивке шағын мәтіндік файлмен метадеректер (хост, уақыт, OS нұсқасы) қосу пайдалы.

Оны іске қосудың ыңғайлы тәсілі — GPO арқылы таратылған Планировщик тапсырмасы. Триггер нұсқалары:

• Оқиға бойынша: қайта жүктелгеннен кейінгі немесе bugcheck-пен байланысты жүйелік журнал жазбасы бойынша.
• Жоспар бойынша: әр 30-60 минут сайын, жаңа дамптар болмаса тез шығып кететін режимде.
• Жүйеге кіруде: ноутбуктар үшін қосымша сақтық шарасы ретінде.

Бірдей файлды бірнеше рет жібермеу үшін өңдеу маркерін қолданыңыз. Бұл .sent файлы, файл хэші, ат пен уақыт бойынша салыстыру немесе қарапайым өзгертілген уақыты бойынша тексеру болуы мүмкін.

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

Сақтау құрылымы: папкалар, аттар, қолжетімділік құқықтары

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

Ыңғайлы схема — дамптарды "кім, қай жерде, қашан" принципі бойынша орналастыру. Мысалы: алдымен бөлімше немесе нысан, кейін ПК атауы, кейін дата, ішіне — дамп түрі (minidump немесе memory dump). Нәтижесінде жол өзі-ақ оқылады: бөлім -> нақты машина -> нақты күн -> құлау файлдары.

Файлдарды атауда бірден келісіп алған жөн. Ең қарапайым нұсқа: уақыт YYYYMMDD-HHMMSS форматында, содан кейін ComputerName, дамп түрі және қысқа идентификатор (мысалы, инцидент нөмірі немесе оқиға хэші). Солай екі қатар жиі болатын құлауды бір-бірін жоймайды және ПК мен дата бойынша іздеу секундтар алады.

Құқықтарды рөл бойынша бөлу пайдалы. Практикалық минимум:

• Жинаушылар (компьютерлік аккаунттар) — өз папкасына жазуға ғана рұқсат.
• Бірінші сынып (Service Desk) — оқу, жоюға емес.
• Тергеуші инженелер — оқу және аймақтар арасында жылжыту.
• Сақтау әкімшілері — толық қолжетімділік және квоталарды басқару.

Екі жоғарғы аймақты бөлу пайдалы: Quarantine және Investigated. Quarantine-қа бәрі автоматты түрде түседі. Investigated-ке тек алдын ала зерттелген, инцидентке байланған және шығару қорытындылары жазылған файлдар ауыстырылсын. Бұл маңызды дамптардың кездейсоқ жойылу қаупін азайтады және аудитті жеңілдетеді.

Шарға және өзгерістерге қолжетімділікті аудитке қосыңыз (оқу және жою), сонда кім файл ашқанын немесе тазалағанын көруге болады.

Ретеншн және тазалау: сақтау мерзімі мен көлем бақылау

Орталықтандырылған жинауды қосқанда сақтау көлемі бірден өседі. Ретеншнді алдын ала орнатқан дұрыс, әйтпесе ай ішінде файлдық сервер толып, ненің жойылатыны туралы дау шығады.

Практикалық тәсіл — әр дамп түріне әр түрлі сақтау мерзімі тағайындау. Минидамптар кіші және жиі жеткілікті ақпарат береді, сондықтан оларды ұзақ сақтау болады. Kernel және full dump көп орын алады, сондықтан оларды қысқа терезеде ғана сақтау немесе тек маңызды инциденттер үшін сақтау тиімді.

Ұсынылатын мерзімдер:

• Minidump: 60–180 күн.
• Kernel dump: 14–30 күн.
• Full dump: 3–14 күн.

Файлдық құрылымның өсуіне жол бермеу үшін квоталарды екі жерде енгізген жөн: ПК-де (егер дамп алдымен жергілікті түрде жиналса) және серверде (құрылғының папкасына немесе бөлімшеге лимит). 500–1000 ПК бар паркта әр машинаға қосылған артық 200–300 МБ тез жүздеген гигабайтқа айналуы мүмкін.

Автотазалау серверде жоспар бойынша іске қосылсын және анық ережелер бойынша орындалсын:

• Белгіленген мерзімнен ескі файлдарды жою.
• Папка көлемі лимиттен асса — ең ескі файлдарды жою.
• Тергеп жатқан статусындағы дамптарды алмау (атының ішінде белгі немесе бөлек маркер арқылы).
• Бүлінген және толық емес көшірмелерді жою.

Маңызды инциденттер үшін архивтеу пайдалы: маңызды деректерді сығып, арзан сақтау орнына ауыстыру. Әдетте тұрақты түрде сақтау тек сирек, жаппай немесе критикалық жағдайларға және метадеректердің минималды жинағына шектеледі, контекст жоғалмауы үшін.

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

Бір дамп жиі контекстсіз ұзақ іздеуге айналады: қашан құлаған, қай билдте Windows, қандай жаңартудан кейін және кімде қайталанып жүргені. Сондықтан әр дампқа жақын шағын метадеректер файлын сақтау орынды. Ең оңайы — әр инцидентке бір JSON (немесе CSV), сол папкада және дамп файлының негізгі атымен сәйкес келетін атаумен.

Метадеректерді дампты көшіретін сол скриптпен жинаған жөн: олар уақыт бойынша синхрондалады және жоғалмайды.

Міндетті сақталатындар

Минималды жинақ қысқа, бірақ пайдалы болуы тиіс:

• Құрылғы идентификаторлары: ПК атауы, домен, қажет болса серия нөмірі (есеп үшін). Пайдаланушыны тек компания ережелері рұқсат етсе сақтаңыз.
• Нұсқалар мен жабдық: Windows нұсқасы (build), құрылғы моделі, BIOS/UEFI туралы негізгі мәліметтер.
• Құлау оқиғасы: BugCheck code, құлау уақыты, uptime, оқиға ID (әдетте 1001), дамп жолы мен түрі.
• Ортаның күйі: жүйелік дисктегі бос орын, диск шифрланған ба (иә/жоқ).
• Қысқа контекст: құрушы уақыттағы 5–10 активті процестің тізімі (жүйенің толық снэпшотын алуға тырыспаңыз).

Төменде оқуға және талдауға ыңғайлы компактты JSON мысалы бар (код блогында). Бұл блогтағы JSON мазмұны өзгертусіз қалдырылды:

{
  "computer": "PC-0231",
  "domain": "CORP",
  "serial": "CZC1234567",
  "os_build": "10.0.19045.3930",
  "model": "Dell OptiPlex 7090",
  "bugcheck": "0x0000007E",
  "crash_time_utc": "2026-01-19T08:41:12Z",
  "uptime_sec": 184320,
  "event_id": 1001,
  "dump_path": "\\filesrv\\dumps\\PC-0231\\2026-01-19_084112\\MEMORY.DMP",
  "free_space_gb": 12.4,
  "disk_encryption": true,
  "top_processes": ["chrome.exe","winword.exe","teams.exe","svchost.exe"]
}

Егер метадеректерде бірнеше ПК-де бірдей bugcheck, бірдей build және құлау бір күні басталғаны көрінсе, бұл жиі драйвер немесе жаңарту мәселесіне нұсқайды. Ал бос орын 1–2 ГБ ғана болса, зерттеу алғашқы сәттен дамп жазудың сәтсіздігіне ауысады.

Жақсы ереже: тек себептерді тарылтуға көмектесетін деректерді сақтаңыз және жеке деректерді мүмкіндігінше сақтамаңыз.

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

Crash dump — бұл құлау сәтіндегі жадының снэпшоты. Онда құжаттардың фрагменттері, жазысулар, сессия токендері, файл атаулары, қосымша деректері және басқа пайдаланушыға қатысты іздер болуы мүмкін. Сондықтан орталықтандырылған жинауды алдын ала ИБ және процесс иелерімен келіскен жөн: бұл тек техникалық файл емес, мүмкін сезімтал зерттеу артефакті.

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

Тасымалдау және сақтау

Ең қауіпсіз нұсқа — көшіру үшін бөлек сервис есептік жазба және қарауды бөлек рөлдер. Тасымалдау кезінде қорғалған арна (мысалы, SMB шифрлауымен) пайдаланыңыз, дискінде том шифрлау болсын. Дамптарды пайдаланушылардың жалпы шарларынан бөлек сақтау дұрыс — мұрагерлік құқықтардың қатесіз берілу қаупін азайтады.

Минималды бақылау тізбесі:

• Дамптарға арналған бөлек папка/шар, құқықтар мұрагер емес.
• “Investigations Read” және жеке “Investigations Admin” топтары.
• Оқу/көшіргенді аудиттеу және берген журнал (кім, қашан, не үшін).
• Дамптарды пошта немесе мессенджер арқылы қолмен жіберуге тыйым.

Жеке деректер және сақтау мерзімдері

Комплаенс үшін сақтау мерзімдері мен жою рәсімдері айқын болуы тиіс. Дамптарды шектеулі уақытта сақтау (мысалы, 30–90 күн) және автоматты түрде жою орнату ұсынылады. Ішкі бақылау сұранысы немесе компания ережелері бойынша жою қажет болса — сол бойынша жою орындау және растайтын жазба қалдыру керек. Алдын ала кім жою сұрай алатынын, сұрауды қалай растауды және жою фактісін қайда жазуды бекітіңіз.

Енгізу кезінде жиі кездесетін қателіктер және оларды болдырмау жолдары

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

Бір тест ПК-те дамп жасау, көшіру және метадеректердің сақтауын бақылау — пайдалы бақылау нүктесі.

Дамптар жасалмайды

Типтік себептер және тез тексерулер:

• Қате дамп түрі таңдалған (мысалы, сіз MEMORY.DMP күткенде кішкентай дамп орнатылған) немесе дамп жасау өшірілген.
• C: дискіде орын жоқ, ОС файлды жаза алмайды.
• Pagefile өшірілген немесе таңдалған түрге тым кішкентай.
• Саясат қақтығысы: әртүрлі GPO-лар CrashControl параметрлерін әртүрлі қояды.
• Қатты қайта жүктеу (электр өшіп қалу, қуық батырмасы) жазу аяқталмай тұрып орын алады.

Скрипт қате көшіреді немесе шексіз көшіріп тұрады

Скрипттер көбінесе жолдар мен құқықтарды дұрыс өңдемейді. Минидамп Minidump-та, толық дамп басқа жерде — сондықтан серверде бос немесе ескі файлдар көрінуі мүмкін.

Тағы бір қақпан — файл құлауынан кейін әлі жазылып жатуы. Шешім: N минут өзгермеген файлдарды ғана көшіріп, жергілікті .sent маркерін немесе файл хэшін сақтаңыз.

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

Талдау жетіспеуі үшін минимумды бекітіңіз: құлау уақыты, BugCheck, OS және build, негізгі драйверлер (немесе ең соңғы жаңартылғандар), құрылғы аты және пайдаланушы (рұқсат болса), сонымен қатар соңғы жаңартулар уақыты.

Мысал: сақтау құралында дамп бар, бірақ уақыт пен BugCheck жоқ. Команда бір сағаттай оқиғаларды салыстырып өткізеді. Егер жанында 0x00000116 коды және GPU драйверінің нұсқасы көрсетілген метадеректер болса, гипотеза минуттарда пайда болуы мүмкін.

Енгізу және қабылдау үшін жылдам чек-лист

Барлық паркіге енгізбес бұрын 10–20 әртүрлі модель мен рөлдегі тест тобында дамп жинауды тексеріңіз. Қабылдау критерийі "скрипт іске қосылды" емес, "дамп пен деректер шынымен де құлауды талдауға көмектеседі" болуы тиіс.

Тест тобына арналған тексерулер

• BSOD-тан кейін қажетті типтегі дамп (әдетте minidump) пайда болады және ол орталықтандырылған сақтауға автоматты түрде түседі.
• Дампқа жанында метадеректер файлы жасалады және онда көрсетілген уақыт Windows оқиғалары жазбасымен сәйкес келеді.
• Қол жеткізу құқықтары дұрыс жұмыс істейді: сервис есептік жазба жазып, мамандар оқиды, жою шектелген және аудитке түседі.
• Ретеншн тест деректерінде дұрыс жұмыс істейді және ұстап тұруға белгіленген файлдарды жоймайды.
• Жүктеме қабылданарлық: көшіру жұмыс уақытында желіні тарылтып жібермейді, сақтау сервері диск және параллель қосылымдар бойынша шектелмеген.

"Прод"-қа дайындық критериялары

Енгізу қабылданған саналады, егер 1–2 тест инциденті бойынша сіз ПК атауы мен уақыт арқылы дампты оңай таба алсаңыз, метадеректер контекстті (OS, жаңартулар, құрылғы моделі) бірмәнді сипаттаса және қолжетімділік пен ретеншн болжамды жұмыс істесе. Сонан соң OU бойынша қамтуды біртіндеп кеңейтіңіз, сақтау көлемін және трафик шыңдарын бақылап отырыңыз.

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

Бухгалтерияда 20 бірдей модельді ПК тұр. Апта сайын 3–5 машина BSOD-қа ұшырайды, көбіне жұмыс күнінің соңында. Пайдаланушылар "қарапайым қайта жүктелді" дейді, ал инженер келгенде іздер болмай қалады.

Орталықтандырылған жинауды қосқаннан кейін жағдай өзгереді. Келесі таңертең сақтау орны жаңа дамптар мен олардың жанында метадеректер файлын алады: ПК атауы, құлау уақыты, BugCheck, Windows нұсқасы, соңғы орнатылған жаңарту нөмірі, BIOS нұсқасы, құрылғы моделі.

Метадеректер бойынша 5–10 минут ішінде оқиғаларды топтауға болады. Мысалы, 4 құлауда бірдей BugCheck және бір драйвер көрсетіледі. Барлық жерде бірдей накопительный жаңарту бір күн бұрын орнатылған. Бесінші машина басқа кодпен құлаған, оны бөлек қарастырған жөн.

Келесі кезең — жарты сағаттық жұмыс:

• Бір апта ішіндегі бірдей BugCheck бойынша инциденттерді сүзгіден өткізу.
• Сол топтан 3–5 дамп пен метадеректерді жүктеп алу.
• Драйвер нұсқаларын және жаңарту орнату күндерін салыстыру.
• Құлаушы және тұрақты ПК-лар арасында BIOS немесе компонент ревизиясының айырмашылығын тексеру.

Нәтижені қысқа және анық түрде баяндау пайдалы: ИТ және процесс иесі түсінетін тілде. Мысалы: "Бухгалтерия тобының ПК-ларындағы құлаулар BugCheck 0xXXXX байланысты. Барлық оқиғаларда драйвер X нұсқасы Y және жаңарту KBZZZZ орнатылған. Гипотеза: драйвер нұсқасы мен жаңарту арасындағы қақтығыс".

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

Келесі қадамдар: процесті қолдау және масштабтау

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

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

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

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

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