RTO/RPO-ны қалай таңдау: DR тәжірибесі артық төлемсіз

Disaster Recovery арқылы не шешесіз және неге бұл ақша тұрады

Disaster Recovery (DR) тек файлдардың көшірмесін сақтау үшін қажет емес. Оның мақсаты — апаттан кейін бизнесті қайта жұмысқа қайтару: серверлік зал істен шыққанда, шифрлаушы деректерді бұзғанда, жарық өшкенде, сақтау құрылғысы істен шыққанда немесе жаңарту негізгі жүйені құлатқанда.

Бэкап сұраққа жауап береді: «Деректерді қалпына келтіре аламын ба?». DR басқаша сұрақ қояды: «Қызметті қанша жылдам іске қосамын және қанша деректі жоғалтуды қабылдаймын?». Көшірмелер болса да, қалпына келтіру бір күн алады — және бизнес әлі де тоқтап қалуы мүмкін.

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

Артық төлемнің басты себебі — барлық жүйелерге бірдей талап қою. Егер архивтер, тестілік стендтер мен ішкі порталдар қоса барлығына RTO 15 минут, RPO 5 минут қойсаңыз, артық серверлерге, каналдарға, лицензияларға және қолдауға ақша төлейсіз. Қызметтерді критикалықлігіне қарай бөліп, әрқайсысына өз қорғанысын беру әлдеқайда үнемді.

DR тек «стойкадағы серверлерге» қатысты емес, ол толық тізбекті қамтиды: қолданбалар, дерекқорлар мен файлдар, есептік жазбалар мен қолжетімділік, желі және қауіпсіздік, сонымен бірге маңызды командалардың жұмыс орындары (мысалы, кассалар немесе колл-орталық). Сатып алу порталында жиі RTO 8 сағат қабылданса, төлемдер немесе науқастарды тіркеу үшін минуттар қажет болады. RTO/RPO-ны артық төлемдерсіз қалай таңдау туралы әңгіме алғашында аппараттық таңдау емес, бизнеске әсерден басталады.

RTO мен RPO күрделі терминсіз: қалай түсінуге болады

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

RTO: қанша уақыт тоқтауға болады

RTO (Recovery Time Objective) — рұқсат етілген ең жоғарғы тоқтау уақыты. Егер бухгалтерия үшін RTO 8 сағат болса, онда бизнес апаттан кейін бухгалтерияның бір жұмыс күні ішінде істемегенін қабылдайды.

RTO тек серверлер мен виртуалды машиналар туралы емес. Бұл сондай-ақ процесс: ауыстыру туралы шешімді кім қабылдайды, қадамдарды кім орындайды, нұсқаулықтар қайда, қолжетімділіктер бар ма.

RPO: қанша деректі жоғалтуға болады

RPO (Recovery Point Objective) — уақыт бойынша рұқсат етілген дерек жоғалтуы. Егер RPO 15 минут болса, қалпына келтірілгеннен кейін ең көп дегенде 15 минутқа артқа оралуға болады. Егер RPO 24 сағат болса — тәуліктік деректерді жоғалту қабылданады (мысалы, оларды басқа көздерден қалпына келтіруге немесе қайта енгізуге болады).

Айырмашылықты нәтижелер арқылы сезінген жеңіл:

• RTO 15 минут, RPO 0–5 минут — әдетте дерлік үздіксіз резервтеу мен репликация, сонымен қатар жылдам процедуралар қажет.
• RTO 2 сағат, RPO 30 минут — жиі кесте бойынша репликация мен дайын ауыстыру жоспары жеткілікті.
• RTO 8 сағат, RPO 4 сағат — әдетте тұрақты бэкаптар мен анық қалпына келтіру жеткілікті.
• RTO 24–48 сағат, RPO 24 сағат — минималды шығындар, бірақ ұзақ тоқтауды және қолмен қадамдарды қабылдау керек.

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

Тоқтау мен дерек жоғалтудың салдарын қалай бағалау керек

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

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

Практикалық тәсіл — «1 сағат тоқтаудың құны» және «1 сағат дерек жоғалтудың құны» бағасын шығару. Сол кезде RTO/RPO-ны артық төлемсіз таңдау әлдеқайда оңай болады.

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

Шынайы бағалау үшін тексеріңіз:

• жүйені кім тұтынушысы (клиенттер, операторлар, бухгалтерия, дәрігерлер, касса);
• тоқтағанда не бұзылады (процестер, келісімдер, қауіпсіздік);
• қандай тәуелділіктер бар (желі, AD, дерекқорлар, интеграциялар);
• қандай сағаттарда тоқтау критикалық (жұмыс уақыттары, айдың соңы);
• қанша уақытқа қолмен жұмыс істеу қабылданады.

Контекст маңызды. Дүйсенбі 11:00-дегі бір сағат тоқтау мен түнгі уақытта бір сағат — әртүрлі шығын. Ал есеп жүйелерінде критикалық кезең көп жағдайда ай/квартал жабылуынан тұрады.

Жүйелердің критикалық деңгейлері: бизнес үшін түсінікті шкала

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

Төменде практикалық 0–4 градациясы. Оны приоритет матрицасының негізі ретінде қолдануға ыңғайлы.

• Деңгей 0–1 (маңызды емес): бірнеше күн бойы болмағаны жөн. Қалпына келтіру сұрау бойынша, тәулік бойы дайындық қажет емес. Мысал: ішкі жаңалықтар порталы, тест орта, кейбір архивтер.
• Деңгей 2 (ішкі маңызды): тоқтау жұмысты бұзады, бірақ бизнесті «құлатпайды». Жұмыс күні ішінде қалпына келтіруге болады. Мысал: бухгалтерия, кадр жүйесі, корпоративтік пошта (қосалқы байланыс арналары бар болса).
• Деңгей 3 (клиенттік және өндірістік): тоқтау клиенттерге байқалады немесе операцияларды бұзады. Уақыт сағаттармен есептеледі, дерек жоғалту аз болуы керек. Мысал: қойма мен жеткізілім үшін ERP, қызмет порталы, контакт-орталықтағы өтініш қабылдау.
• Деңгей 4 (миссияға маңызды): қысқа тоқтау да қабылданбайды, мақсаттар минуттармен өлшенеді, RPO минималды. Мысал: кассалар мен төлемдер, транзакция ядросы, қауіпсіздік жүйелері.

Жүйенің тоқтаған кездегі шығынды дереу ақшамен, айыппұлдармен немесе беделмен есептейтін болса — бұл көбіне деңгей 3–4. Егер тек ыңғайлылық пен жұмыс жылдамдығы зардап шегетін болса — әдетте деңгей 1–2.

Бір жүйенің деңгейі компанияға қарай өзгеруі мүмкін. Пошта бір команда үшін деңгей 2 болса, 24/7 қолдау қызметі үшін — деңгей 3 болуы мүмкін.

Қадаммен: RTO/RPO қалай таңдап, приоритет матрицасын қалай құру керек

RTO/RPO-ны артық төлемсіз таңдау үшін, апаттан кейін шын мәнінде не қалпына келтірілетінін анықтайтын тізімнен бастаңыз. Бұл құжат ИТ мен бизнестің ортақ құжаты болуы керек, «қорапқа қою» үшін емес.

Жұмыс істейтін бес қадам

Қысқа жұмыс тобы жинаңыз: ИТ, қауіпсіздік, қаржы және негізгі процестердің иелері.

• Жүйелер тізімін жасаңыз және әрқайсысына иесін тағайындаңыз (қайсысы тоқтауды және дерек жоғалтуды шешеді).
• Тәуелділіктер мен «минималды іске қосу» сипаттамасын жасаңыз: компанияның негізгі режимде жұмыс істеуі үшін не қажет (желі, AD, пошта, ERP, төлемдер, телефония).
• Қызметтердің әрқайсысына нөлден емес, критикалық деңгейлерге сай мақсатты RTO/RPO орнатыңыз.
• Шегіністер мен уақытша компромистерді бекітіңіз: қай жерде репликация орнына бэкап жеткілікті, қай жерде қолмен режим рұқсат етіледі, қай жерде айналып өту процесі керек.
• Приоритет матрицасын және қайта қарау ережелерін бекітіңіз: кім жаңартады, қаншалықты жиі, қандай өзгеріс қайта қарауды талап етеді.

Матрицаны қалай толтыру тиімді болады

Әр жүйе үшін әдетте 6–8 өріс жеткілікті: иесі, критикалық деңгейі, RTO, RPO, тәуелділіктер, қалпына келтіру тәсілі (бэкап/репликация/резерв), орналастыру орны және тестілеу тәртібі.

Мысалы, банкте төлем шлюзі үшін RTO 1 сағат және RPO 5 минут қажет болуы мүмкін (әдетте репликация және алдын ала дайындалып қойылған қуаттар керек). Ал ішкі оқу порталы үшін RTO 3 күн және RPO 24 сағат жеткілікті (көп жағдайда күнделікті көшірмелер жарайды). Инфрақұрылым тұрғысынан бұл әртүрлі ресурстар сыныптарын білдіреді: кейбір сервистер дайындалған қуатта сақталады, ал қалғаны қажет болғанда қалпына келтіріледі.

RTO/RPO әдемі көрінсе де, егер сіз қалпына келтіруді үнемі тексеруге дайын болмасаңыз, бұл мақсат емес — қауіп.

Приоритет матрицасында не болуы керек, сонда ол жұмыс істейді

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

Өрістерді қысқа ұстап, міндетті түрде келесі тармақтарды қосыңыз: жүйе атауы, иесі (шешім қабылдайтын адам), мақсатты RTO және RPO, қалпына келтіру приоритеті және тәуелділіктер.

Приоритетті мына критерийлермен байланыстыру жеңіл:

• ақша (табыстар, айыппұлдар, өндірістің тоқтауы);
• қауіпсіздік және тәуекел (жеке және медициналық деректер, қолжетімділік);
• міндеттемелер (реттеушілік, келісімдер, мемлекеттік қызметтер);
• клиенттер мен бедел (жаппай сұраулар, критикалық сервис).

Басқа жалпы платформаларды бөлек белгілеңіз, олар "барлығын тартады". Қайшылық: бизнес-қосымшаны бірінші орынға қойып, ал AD/DNS, желі, сақтау және виртуализацияны үшінші орынға қою. Нәтижесінде қолданбаны іске қосуға еш жерде болмайды.

Келісімдерді жаттығуларда оңай тексерілетін қарапайым фразалармен формулируйте:

• «Жүйеге қол жеткізуді инциденттен кейін 4 сағат ішінде қалпына келтіру»
• «Дерек жоғалтуы 15 минуттан аспауы керек»
• «Егер тәуелділік қолжетімсіз болса, RTO X-ке өседі»
• «Жүйе иесі приоритетті растап, жылына 2 рет тестке қатысады»

Әртүрлі бюджетке арналған типтік DR-архитектуралар

DR көбіне былайша шешіледі: сіз жылдам қалпына келтірілуге (RTO), минималды дерек жоғалтуға (RPO) немесе екеуіне де төлейсіз. Сондықтан архитектура әртүрлі жүйелер үшін мақсаттар анықталғаннан кейін таңдалады.

Жиі кездесетін нұсқалар — қарапайымынан жылдам жағына дейін:

• Сол алаңдағы бэкап — арзан және жылдам енгізіледі, бірақ өрт, су басу жағдайында немесе шифрлаушыдан сақтай алмайды, көбіне жеткіліксіз.
• Бэкап + бөлек сақтау немесе лента — көшірмелердің жойылу тәуекелін төмендетеді және ұзақ сақтау береді, бірақ RTO сағаттармен немесе күндермен есептеледі.
• Екінші алаңға репликация — қалпына келтіру жылдамырақ, бірақ қымбат: каналдар, екінші инфрақұрылым және қолдау шығындары.
• Warm standby — алаң дайындалған, бірақ кейбір қуаттар апат кезінде іске қосылады. Маңызды жүйелер үшін ақылға қонымды компромисс.
• Hot standby — бәрі параллель жұмыс істейді, ауыстыру дерлік сәтті. Бірақ егер бизнеске 1–2 сағат қалпына келу жеткілікті болса, минуттар үшін төлегенше артық шығын шығады.

Ауыстыру қалай жүзеге асырылатыны бөлек мәселе. Қолмен ауыстыру арзан, бірақ адамдарды, нұсқаулықты және уақытты талап етеді.

Автоматизация әдетте RTO минуттармен өлшенсе, түнгі ауысымда орындаушы жоқ болса, оператор қатесі тым қымбат немесе реттеушілік алдын ала болжамды қалпына келтіруді талап етсе ақталады.

Әртүрлі типтегі жүйелер үшін талаптар қалай өзгереді

Барлық жүйеге бірдей RTO/RPO қою жиі артық төлемге апарады. Жүктеме түріне және оның қалай қалпына келетіндігіне қараңыз. Процесс иесіне пайдалы сұрақ: егер сервис іске қосылса, бірақ деректер «кешегі күйде» болса, не болады?

Файлдар мен пошта: "қайда көшірме" ғана емес

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

Дерекқорлар мен ERP: консистенттілік және іске қосу тәртібі

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

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

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

24/7 қызметтер үшін мақсат қарапайым — қолмен қадамдарды жою, өйткені түнде және стресс кезінде адамдар қателеседі. Минималды тәжірибелер: критикалық компоненттерді автоматты іске қосу және қолжетімділікті тексеру, тәуелділіктерді алдын ала сипаттау (DNS, AD, сертификаттар, желі), ауыстыру туралы шешімді қабылдайтын бір жауапты, дежур жұмысы үшін қысқа нұсқаулықтар және жүйелі жаттығу тест ортасында.

DR іске аспауы немесе тым қымбат болуына әкелетін жиі қателіктер

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

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

Үшінші мәселе — барлық жүйеге бірдей мақсат қою.

Төртінші қате — тәуелділіктерді елемеу. «ERP қалпына келтіреміз» оңай естілсе де, оған AD, DNS, желілік саясаттар, сертификаттар, сақтау, лицензиялар, шифрлау кілттері және әкімші есептері керек екені анықталуы мүмкін.

Соңында, DR жиі тек қағазда болуы мүмкін, өйткені қалпына келтіруді тексермейді. Қалпына келтіруді жүйелі түрде тексермеген бэкап — сенім емес, үміт ғана.

Қысқа тексерулер жинағы, ол әдетте ақша мен нервтерді үнемдейді:

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

Жылдам тексерулер: компания DR-ға дайын ба

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

30 минуттық чек-лист

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

• Актуалды жүйелер тізімі, иелері және негізгі тәуелділіктер (ДҚ, AD, желі, интеграциялар) бар ма?
• Әр жүйе үшін критикалықлік пен мақсатты RTO/RPO бизнестің түсінігіне сай анықталған ба?
• Қалпына келтіру тәртібі және «минималды жұмыс жиынтығы» анықталған ба: алғашқы сағаттарда не іске қосылуы керек?
• Кибероқиғаға бөлек сценарий бар ма: шифрлаушы шабуылда не істейміз және көшірмелер қалай қорғалған (оқшаулау, өзгермейтіндік, бөлек тіркелгілер)?
• Тесттер жоспарланған ба және жауапты тағайындалған ба: кім DR-ды іске қосады, кім қалпына келтіруді растайды, кім басшылықпен байланысады?

Шынайылыққа жылдам тест

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

Егер жауаптар анық болмаса, приоритет матрицасынан және минималды сервистер жиынтығынан бастаңыз, сосын архитектура таңдау (бэкап, репликация, hot немесе cold резерв). Көп жағдайда бұл бәріне тез және қымбат DR құрудан арзанырақ.

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

Бір жұма күні 10:15-те бас офиске электр қуаты өшті. UPS 12 минутқа ғана жеткізді, сол кезде виртуализация мен желінің бір бөлігі құлады. Формалды түрде «ЦОД құлады», бірақ бизнес үшін нәтиже басқаша болды: кассалар мен онлайн төлемдер өтпеді, колл-орталық өтініштерді көрмеді, қойма тауар жібермеді.

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

Матрица компромистерді бекітеді. Төлемдер үшін RTO 1 сағат және RPO 15 минут таңдапты, ал аналитика үшін RTO 24 сағат және RPO 8 сағат. Апат кезінде ешкім «басынан есептерді көтерейік» деп уақыт жоғалтпады.

Содан кейін бюджет сұрақтары туды. «Тек бэкап» нұсқасы инфрақұрылым жағынан арзан еді, бірақ тоқтаудың құны бойынша қымбатқа түседі: базаларды көшірмеден қалпына келтіру 6–10 сағатты алады және көшірмелер арасындағы деректер жоғалуы мүмкін еді. Екінші нұсқада олар тек бір бөліктегі жүйелерге репликация жасады (төлемдер, тапсырыстар, каталог, AD), қалғанына бэкап қалдырылды. Бұл екінші контурға, каналдарға және қолдауға қосымша шығын әкелді, бірақ критикалық сервистер 30–60 минут ішінде RPO 15 минутқа дейін қалпына келді.

Тестілеуден кейін әр сервис үшін нақты RTO/RPO-ны тіркеу, не кедергі болғанын (адамдар, қолжетімділіктер, өткізу қабілеті, қадамның тәртібі) және не өзгерту керектігін жазу маңызды. Әдетте 1–2 беттік қысқа есеп пен runbook-ты жаңарту жеткілікті.

Келесі қадамдар жиі мынадай болады:

1. тәуелділіктер мен деректерге қысқа аудит;
2. матрица мен бюджетке сай мақсатты DR архитектурасын таңдау;
3. алаң мен жабдықты таңдау, 1–2 критикалық жүйе бойынша пилот;
4. жоспарлы тесттер мен дежурларды оқыту.

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