Сақтық көшірмеден қалпына келтіруді іс жүзінде тексеру

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

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

Сәтті көшірме сәтті қалпына келтіруді білдірмейді

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

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

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

NIST SP 800-53 құжатының CP-9 бақылауы да тасымалдағыш сенімділігі мен ақпарат тұтастығын тексеруді жүйе функцияларының бір бөлігін қалпына келтіруден бөледі. Мұндай бөлу аудиторларға ғана керек емес. Ешкім қалпына келтірілген дананы іске қоспаса да, жасыл белгілердің скриншотымен тапсырманы жабуға жол бермейді.

Тексеру нысаны қалпына келтіру нысанына сай болуы керек

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

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

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

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

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

Автоматика каталогты ғана емес, деректерді де оқуы керек

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

Үлкен репозиторийлерді күн сайын толық оқу бүкіл техникалық қызмет көрсету уақытын алуы мүмкін. Оны бір-бірімен қабыспайтын бөліктерге бөліп, белгіленген цикл ішінде бүкіл көлемді оқыңыз. Мысалы, restic ішінде restic check метадеректерді тексереді, read-data режимі барлық пакетті оқиды, ал read-data-subset жұмысты апталық циклге бөлуге мүмкіндік береді. Нақты тексеру мынадай болады:

# Проверка выбранной базовой копии PostgreSQL
pg_verifybackup /srv/backups/orders/base
status=$?
printf 'backup_integrity_status=%s\n' "$status"
exit "$status"

Сәтті толық өту no errors were found хабарламасымен және 0 қайтару кодымен аяқталады. Мониторингке дәл осы қайтару кодын, соңғы сәтті оқылған қалпына келтіру нүктесінің жасын, тексерілген көлем үлесін және репозиторий идентификаторын беру керек. Журналдан error сөзін іздеу сенімсіз: хабарлама пішімі өзгеруі мүмкін, ал ескерту назардан тыс қалады.

PostgreSQL жүйесінде plain пішіміндегі базалық көшірме pg_verifybackup /path/to/backup пәрменімен тексеріледі. Утилита файлдардың бар екенін және олардың бақылау сомаларын backup_manifest бойынша салыстырады, содан кейін қажетті WAL ауқымын тексереді. WAL тексеруі нұсқаға тәуелді болғандықтан, сервер нұсқасына сәйкес келетін pg_verifybackup нұсқасын іске қосыңыз. Одан кейін де қалпына келтірілген дерекқорды іске қосу қажет.

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

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

Оқшауланған орта өндірістік жүйені тексеруден қорғайды

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

Оқшаулау виртуалды машинаға басқа атау беруді ғана емес, өндірістік ішкі желілерге бағыты жоқ бөлек сегментті білдіреді. Шығыс қосылымдарға тәуелділік имитаторлары, пакет репозиторийі және нәтиже жинау жүйесі үшін рұқсат тізімі бойынша ғана жол беріңіз. Сынақ ортасындағы DNS тестілік мекенжайларды қайтаруы керек. Электрондық поштаны, SMS, төлем шлюздерін және сыртқы API қызметтерін сұрауларды тексеру үшін сақтайтын, бірақ сыртқа ештеңе жібермейтін имитаторлармен ауыстырыңыз.

Microsoft компаниясының Azure Site Recovery сынақтық ауысу нұсқаулығы қалпына келтіру алаңының өндірістік желісінен оқшауланған желіні таңдап, сонымен бірге өндірістік ішкі желілер құрылымын қайталауды ұсынады. Бұл кеңес бір бұлтпен шектелмейді: желі логикасы ұқсас болуы керек, ал нақты өндіріспен байланыс болмауы тиіс. Тым қарапайым сынақ ортасы тәуелділіктерді жасырады, ал толық қосылған орта оқу-жаттығу кезінде оқиға туғызады.

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

Сынақ ортасының сыйымдылығын алдын ала тексеріңіз. Жедел жад жетіспесе, жүйе баяу іске қосылып, команда оны көшірменің бұзылуы деп қате түсінуі мүмкін. Диск жетіспесе, ашу процесі соңына таяғанда үзіледі. Өнімділікті тексеру үшін ресурстар мақсатты апаттық платформаға шамалас болуы керек. Функционалдық тексеруге шағын орта жарайды, бірақ бұл шектеуді жазып, өлшенген уақытты расталған RTO ретінде көрсетуге болмайды.

Сынақтық қалпына келтіру бос ортадан басталуы керек

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

Іс жүзіндегі іске қосу бес кезеңнен тұрады:

1. Кезекші оператор сценарий нөмірін, сервис атауын, мақсатты нүктені және рұқсат етілген уақытты алады, бірақ снимок идентификаторы жазылған дайын пәрменді алмайды.
2. Автоматика таза есептеу ресурстарын, оқшауланған желіні, бос дискілерді және сыртқы сервистердің имитаторларын жасайды.
3. Оператор каталогтан қажетті нүктені табады, кілтті апаттық тәртіппен алады және қолданыстағы нұсқаулық бойынша деректерді қалпына келтіреді.
4. Команда тәуелділіктерді дұрыс ретпен іске қосып, тек алдын ала рұқсат етілген мекенжай өзгерістерін енгізеді және қолданбалы тестілерді орындайды.
5. Сервис иесі нәтижені қабылдайды немесе қабылдамайды, содан кейін сынақ ортасы жойылып, уақытша құпиялардың күші тоқтатылады.

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

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

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

Сервистің жұмысын қолданбалы тексерулер растайды

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

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

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

SELECT max(committed_at) AS newest_commit FROM orders;
SELECT status, count(*) FROM orders GROUP BY status ORDER BY status;
SELECT count(*) AS broken_refs
FROM order_items i LEFT JOIN orders o ON o.id = i.order_id
WHERE o.id IS NULL;

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

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

Шифрлау мен сығу қателердің бөлек түрлерін туғызады. Архив бүтін болуы мүмкін, бірақ кілті жоғалады. Кілт бар болғанымен, апаттық команданың оны алуға құқығы болмауы мүмкін. Қалпына келтіру бағдарламасы ескі пішімді қолдамауы ықтимал. Сондықтан тексеруде кілтке қол жеткізудің нақты тәртібі және апаттық жиынтықтағы бағдарлама нұсқасы қолданылады. Әкімші жатқа білетін құпиясөз рәсім болып саналмайды.

Тексеру жиілігі тәуекел мен өзгеріс жылдамдығына байланысты

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

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

Кейбір оқиғалардан кейін күнтізбені күтпей тексеру қажет:

• сақтық көшірме өнімінің, пішімінің, шифрлаудың немесе сақтау саясатының ауысуы;
• қолданбаның, дерекқордың, гипервизордың немесе желі схемасының ірі жаңартылуы;
• репозиторийдің көшуі, кілттердің ауысуы немесе апаттық рөлдердің өзгеруі;
• тапсырманың сәтсіздігі, тасымалдағыштың бұзылуы немесе нақты оқиға кезінде қалпына келтіру;
• RPO, RTO, сервис құрамының немесе сыртқы тәуелділіктің өзгеруі.

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

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

Хаттама сынақты дәлелге айналдырады

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

Ең аз жазбаны JSON түрінде сақтап, өзгерістер журналына автоматты түрде жіберуге болады:

{
  "test_id": "restore-2026-04-orders-01",
  "service": "orders",
  "recovery_point_utc": "2026-04-14T01:30:00Z",
  "started_utc": "2026-04-14T03:00:00Z",
  "service_ready_utc": "2026-04-14T04:42:00Z",
  "rpo_minutes": 30,
  "rto_minutes": 240,
  "integrity_check": "passed",
  "application_checks": {"passed": 8, "failed": 0},
  "runbook_version": "git:7c91e2a",
  "operator": "oncall-a",
  "owner_decision": "accepted"
}

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

Кемінде төрт мәртебе қажет: passed, failed, passed with limitation және not run. Соңғысын көшірме бар болғаны үшін сәтті мәртебеге айналдыруға болмайды. Шектеуді де нақты жазыңыз: «функциялар өндірістік қуаттың жартысында тексерілді, RTO расталмады» деген жазба сары белгішеден пайдалырақ.

Әр ауытқуға жауапты адам, мерзім және қайта тексеру шарты тағайындалады. Нұсқаулық қатесін нұсқаулықты өзгертіп, сәтсіз қадамды қайта іске қосу арқылы түзетіңіз. Сыйымдылық жетіспесе, платформаны түзеп, толық қалпына келтіру керек. Команда ескертуді «келесі жолы ескереміз» деген мәтінмен жапса, хаттама сылтаулар мұрағатына айналады.

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

Ақаулардың көбі көшірменің айналасында болады

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

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

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

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

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

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

Оқу-жаттығу себеп түзетілгенде ғана аяқталады

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

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

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

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