Елестетіп көріңізші: сіз ірі сауда орталығының IT-инфрақұрылымына қызмет көрсетесіз. Қалада жаңбыр жауа бастайды. Жаңбыр ағындары шатырды жарып өтіп, су сауда үйлерін табанына дейін толтырады. Сіздің серверлік бөлмеңіз жертөледе емес деп үміттенеміз, әйтпесе проблемаларды болдырмау мүмкін емес.
Сипатталған оқиға қиял емес, 2020 жылғы бірнеше оқиғалардың жиынтық сипаттамасы. Ірі компанияларда апатты қалпына келтіру жоспары немесе апатты қалпына келтіру жоспары (DRP) бұл жағдайда әрқашан қол жетімді. Корпорацияларда бұл бизнестің үздіксіздігі мамандарының міндеті. Бірақ орта және шағын компанияларда мұндай мәселелерді шешу IT қызметтеріне түседі. Сіз бизнес логикасын өзіңіз түсінуіңіз керек, ненің сәтсіздікке ұшырауы мүмкін екенін түсінуіңіз керек, қорғауды ойлап тауып, оны жүзеге асыруыңыз керек.
Егер IT маманы бизнеспен келіссөздер жүргізіп, қорғау қажеттілігін талқылай алса, бұл өте жақсы. Бірақ мен компанияның апатты қалпына келтіру (DR) шешімін қалай пайдаланбағанын бірнеше рет көрдім, себебі ол оны артық деп санады. Апат болған кезде, ұзақ қалпына келтіру шығындарға қауіп төндірді, ал бизнес дайын болмады. Қалағаныңызша қайталай аласыз: «Мен айттым», бірақ АТ қызметі әлі де қызметтерді қалпына келтіруі керек.
Сәулетшінің позициясынан мен сізге бұл жағдайдан қалай аулақ болу керектігін айтамын. Мақаланың бірінші бөлігінде мен дайындық жұмыстарын көрсетемін: қауіпсіздік құралдарын таңдау үшін тұтынушымен үш сұрақты қалай талқылау керек:
- Біз нені қорғаймыз?
- Біз неден қорғаймыз?
- Біз қаншалықты қорғаймыз?
Екінші бөлімде біз сұраққа жауап беру нұсқалары туралы сөйлесеміз: өзіңізді қалай қорғауға болады. Мен әртүрлі тұтынушылардың өз қорғанысын қалай жасайтыны туралы мысалдар келтіремін.
Біз нені қорғаймыз: маңызды бизнес функцияларын анықтау
Төтенше жағдайдан кейінгі іс-қимыл жоспарын іскери тапсырыс берушімен талқылаудан дайындықты бастаған дұрыс. Мұндағы басты қиындық – ортақ тіл табу. Тұтынушы әдетте АТ шешімі қалай жұмыс істейтініне мән бермейді. Ол қызметтің іскерлік функцияларды орындап, ақша әкеле алатындығына алаңдайды. Мысалы: егер сайт жұмыс істеп тұрса, бірақ төлем жүйесі істен шыққан болса, клиенттерден кіріс жоқ, ал «экстремистер» әлі де IT мамандары.
АТ маманы мұндай келіссөздерде бірнеше себептерге байланысты қиындықтарға тап болуы мүмкін:
- АТ қызметі ақпараттық жүйенің бизнестегі рөлін толық түсінбейді. Мысалы, бизнес-процестердің қол жетімді сипаттамасы немесе ашық бизнес үлгісі болмаса.
- Бүкіл процесс АТ қызметіне байланысты емес. Мысалы, жұмыстың бір бөлігін мердігерлер орындаған кезде, ал IT мамандары оларға тікелей әсер етпейді.
Мен әңгімені былай құрастырар едім:
- Кәсіпорындарға жазатайым оқиғалардың барлығында болатынын және қалпына келтіру уақытты қажет ететінін түсіндіреміз. Ең жақсысы - жағдайларды, бұл қалай болатынын және қандай салдары болуы мүмкін екенін көрсету.
- Біз бәрі IT қызметіне байланысты емес екенін көрсетеміз, бірақ сіз өзіңіздің жауапкершілік аймағыңыздағы әрекет жоспарына көмектесуге дайынсыз.
- Біз іскери тұтынушыдан жауап беруін сұраймыз: егер апокалипсис орын алса, ең алдымен қай процесті қалпына келтіру керек? Оған кім және қалай қатысады?
Бизнестен қарапайым жауап қажет, мысалы: байланыс орталығы өтініштерді тіркеуді тәулік бойы жалғастыруы керек.
- Жүйенің бір немесе екі пайдаланушысынан осы процесті егжей-тегжейлі сипаттауды сұраймыз.
Егер сіздің компанияңыз болса, көмектесу үшін талдаушыны тартқан дұрыс.Бастау үшін сипаттама келесідей болуы мүмкін: байланыс орталығы телефон арқылы, пошта арқылы және веб-сайттан хабарламалар арқылы сұрауларды қабылдайды. Содан кейін ол веб-интерфейс арқылы оларды 1С-ге енгізеді, ал өндіріс оларды сол жерден осылайша алады.
- Содан кейін қандай аппараттық және бағдарламалық шешімдер процесті қолдайтынын қарастырамыз. Кешенді қорғау үшін біз үш деңгейді ескереміз:
- сайт ішіндегі қолданбалар мен жүйелер (бағдарламалық қамтамасыз ету деңгейі),
- жүйелер жұмыс істейтін сайттың өзі (инфрақұрылым деңгейі),
- желі (олар бұл туралы жиі ұмытады).
- Біз ақаулықтың ықтимал нүктелерін анықтаймыз: қызметтің өнімділігі тәуелді жүйелік түйіндер. Біз басқа компаниялар қолдайтын түйіндерді бөлек атап өтеміз: байланыс операторлары, хостинг провайдерлері, деректер орталықтары және т.б. Осы арқылы келесі қадам үшін іскери тұтынушыға оралуға болады.
Біз неден қорғаймыз: тәуекелдер
Әрі қарай, біз бизнес тұтынушыдан алдымен өзімізді қандай қауіптерден қорғайтынымызды білеміз. Барлық тәуекелдерді екі топқа бөлуге болады:
- қызмет көрсетудің тоқтап қалуынан уақыт жоғалту;
- физикалық әсерлерден, адам факторларынан және т.б. деректердің жоғалуы.
Кәсіпорындар деректерді де, уақытты да жоғалтудан қорқады - мұның бәрі ақша жоғалтуға әкеледі. Сондықтан біз тағы да әрбір тәуекел тобына сұрақтар қоямыз:
- Бұл процесс үшін деректердің жоғалуы мен уақыт жоғалтуының ақшаға қанша тұратынын есептей аламыз ба?
- Біз қандай деректерді жоғалта алмаймыз?
- Қай жерде тоқтап қалуға жол бермеуге болады?
- Қандай оқиғалар бізге ең ықтимал және қауіп төндіреді?
Талқылаудан кейін біз сәтсіздікке қалай басымдық беру керектігін түсінеміз.
Біз қаншалықты қорғаймыз: RPO және RTO
Сәтсіздіктің сыни нүктелері анық болғанда, біз RTO және RPO көрсеткіштерін есептейміз.
Мен сізге еске аламын RTO (қалпына келтіру уақыты мақсаты) — бұл апат болған сәттен бастап қызмет толық қалпына келтірілгенге дейінгі рұқсат етілген уақыт. Іскерлік тілмен айтқанда, бұл қолайлы үзіліс. Егер біз процестің қанша ақша әкелгенін білсек, біз бос уақыттың әрбір минутынан шығындарды есептей аламыз және қолайлы шығынды есептей аламыз.
RPO (қалпына келтіру нүктесінің мақсаты) — жарамды деректерді қалпына келтіру нүктесі. Ол деректерді жоғалтуға болатын уақытты анықтайды. Бизнес тұрғысынан деректердің жоғалуы, мысалы, айыппұлдарға әкелуі мүмкін. Мұндай шығындарды ақшаға да айналдыруға болады.
Қалпына келтіру уақытын соңғы пайдаланушы үшін есептеу керек: ол жүйеге қанша уақыт кіре алады. Сондықтан алдымен тізбектегі барлық буындардың қалпына келтіру уақытын қосамыз. Бұл жерде жиі қате жіберіледі: олар SLA-дан провайдердің RTO-сын алып, қалған шарттарды ұмытып кетеді.
Нақты мысалды қарастырайық. Пайдаланушы 1С жүйесіне кіреді, жүйе дерекқор қателігімен ашылады. Ол жүйелік әкімшіге хабарласады. Деректер базасы бұлтта орналасқан, жүйе әкімшісі мәселе туралы қызмет провайдеріне хабарлайды. Барлық байланыс 15 минутты алады делік. Бұлтта мұндай өлшемдегі дерекқор сақтық көшірмеден бір сағат ішінде қалпына келтіріледі, сондықтан қызмет провайдері жағындағы RTO бір сағатты құрайды. Бірақ бұл соңғы мерзім емес; пайдаланушы үшін мәселені анықтау үшін оған 15 минут қосылды.
Әрі қарай, жүйелік әкімші дерекқордың дұрыс екенін тексеріп, оны 1С-ге қосып, қызметтерді бастауы керек. Бұл тағы бір сағатты қажет етеді, яғни әкімші жағындағы RTO қазірдің өзінде 2 сағат 15 минутты құрайды. Пайдаланушыға тағы 15 минут қажет: жүйеге кіріңіз, қажетті транзакциялар пайда болғанын тексеріңіз. 2 сағат 30 минут - осы мысалдағы қызметті қалпына келтірудің жалпы уақыты.
Бұл есептеулер бизнесті қалпына келтіру кезеңі қандай сыртқы факторларға байланысты екенін көрсетеді. Мысалы, кеңсені су басқан болса, алдымен ағып кетуді тауып, оны жою керек. Бұл АТ-қа тәуелді емес уақытты қажет етеді.
Біз қалай қорғаймыз: әртүрлі тәуекелдерге арналған құралдарды таңдау
Барлық тармақтарды талқылағаннан кейін тапсырыс беруші бизнес үшін апаттың құнын түсінеді. Енді сіз құралдарды таңдап, бюджетті талқылай аласыз. Клиент істерінің мысалдарын пайдалана отырып, мен әртүрлі тапсырмалар үшін қандай құралдар ұсынатынымызды көрсетемін.
Тәуекелдердің бірінші тобынан бастайық: қызмет көрсетудің тоқтап қалуынан болатын шығындар. Бұл мәселенің шешімдері жақсы RTO қамтамасыз етуі керек.
- Қолданбаны бұлтта орналастырыңыз
Бастау үшін сіз жай ғана бұлтқа ауыса аласыз - провайдер жоғары қолжетімділік мәселелерін ойластырған. Виртуализация хосттары кластерге жиналады, қуат пен желі сақталады, деректер ақауларға төзімді сақтау жүйелерінде сақталады және қызмет провайдері тоқтап қалуға қаржылық жауапты болады.
Мысалы, бұлтта дерекқоры бар виртуалды машинаны орналастыруға болады. Қолданба дерекқорға орнатылған арна арқылы немесе бір бұлт арқылы сырттан қосылады. Кластердегі серверлердің бірімен ақаулықтар туындаса, VM көрші серверде 2 минуттан аз уақыт ішінде қайта іске қосылады. Осыдан кейін онда ДҚБЖ іске қосылады және бірнеше минуттан кейін деректер базасы қолжетімді болады.
RTO: минутпен өлшенеді. Бұл шарттар провайдермен келісімде көрсетілуі мүмкін.
құны: Қолданбаңыз үшін бұлттық ресурстардың құнын есептейміз.
Ол сізді неден қорғамайды: провайдер сайтындағы жаппай сәтсіздіктерден, мысалы, қала деңгейіндегі жазатайым оқиғаларға байланысты. - Қолданбаны кластерлеу
RTO-ны жақсартқыңыз келсе, алдыңғы опцияны күшейтіп, кластерленген қолданбаны дереу бұлтқа орналастыруға болады.
Сіз кластерді белсенді-пассивті немесе белсенді-белсенді режимде жүзеге асыра аласыз. Біз жеткізушінің талаптарына негізделген бірнеше VM жасаймыз. Үлкен сенімділік үшін біз оларды әртүрлі серверлер мен сақтау жүйелеріне таратамыз. Егер дерекқорлардың біреуі бар сервер сәтсіз болса, сақтық көшірме түйіні бірнеше секунд ішінде жүктемені қабылдайды.
RTO: секундтармен өлшенеді.
құны: кәдімгі бұлтқа қарағанда сәл қымбатырақ, кластерлеу үшін қосымша ресурстар қажет болады.
Ол сізді неден қорғамайды: Сайттағы үлкен ақаулардан әлі де қорғамайды. Бірақ жергілікті бұзылулар ұзаққа созылмайды.Практикадан: Бөлшек сауда компаниясында бірнеше ақпараттық жүйелер мен веб-сайттар болды. Барлық деректер базалары компанияның кеңсесінде жергілікті жерде орналасқан. Кеңсе бірнеше рет қатарынан электр қуатынсыз қалмайынша, ДР туралы ойланбады. Клиенттер веб-сайттың бұзылуына наразы болды.
Қызметтің қолжетімділігіне қатысты мәселе бұлтқа көшкеннен кейін шешілді. Сонымен қатар, біз түйіндер арасындағы трафикті теңестіру арқылы дерекқорларға жүктемені оңтайландыра алдық. - Апатқа төзімді бұлтқа көшіңіз
Егер негізгі сайттағы табиғи апаттың да жұмысыңызға кедергі жасамауын қамтамасыз ету қажет болса, апатқа төзімді бұлтты таңдауға болады.Бұл опцияда провайдер виртуалдандыру кластерін 2 деректер орталығына таратады. Тұрақты синхронды репликация деректер орталықтары арасында бір-бірден орын алады. Деректер орталықтары арасындағы арналар сақталған және әртүрлі маршруттар бойынша жүреді, сондықтан мұндай кластер желі ақауларынан қорықпайды.
RTO: 0-ге бейім.
құны: Ең қымбат бұлт опциясы.
Ол сізді неден қорғамайды: Бұл деректердің бұзылуына, сондай-ақ адам факторына қарсы көмектеспейді, сондықтан сақтық көшірмелерді бір уақытта жасау ұсынылады.Практикадан: Біздің клиенттеріміздің бірі апатты қалпына келтірудің кешенді жоспарын әзірледі. Бұл оның таңдаған стратегиясы:
- Апатқа төзімді бұлт қолданбаны инфрақұрылым деңгейіндегі сәтсіздіктерден қорғайды.
- Екі деңгейлі сақтық көшірме адам қатесі болған жағдайда қорғауды қамтамасыз етеді. Сақтық көшірмелердің екі түрі бар: «суық» және «ыстық». «Суық» сақтық көшірме өшірілген күйде және оны орналастыру үшін уақыт қажет. «Ыстық» сақтық көшірме пайдалануға дайын және тезірек қалпына келтіріледі. Ол арнайы сақтау жүйесінде сақталады. Үшінші данасы таспаға жазылып, басқа бөлмеде сақталады.
Аптасына бір рет клиент қорғауды тексереді және барлық сақтық көшірмелердің, соның ішінде таспадағылардың функционалдығын тексереді. Жыл сайын компания апатқа төзімді бұлтты сынақтан өткізеді.
- Басқа сайтқа көшіруді ұйымдастырыңыз
Негізгі сайттағы жаһандық проблемаларды болдырмаудың тағы бір нұсқасы: гео-брондауды қамтамасыз ету. Басқаша айтқанда, басқа қаладағы сайтта сақтық көшірме виртуалды машиналарын жасаңыз. Бұл үшін DR үшін арнайы шешімдер қолайлы: біздің компанияда VMware vCloud Availability (vCAV) қолданамыз. Оның көмегімен сіз бірнеше бұлттық провайдер тораптары арасында қорғауды теңшей аласыз немесе жергілікті сайттан бұлтқа қалпына келтіре аласыз. Мен vCAV-мен жұмыс істеу схемасы туралы толығырақ айттым .
RPO және RTO: 5 минуттан бастап.
құны: бірінші нұсқаға қарағанда қымбатырақ, бірақ апатқа қарсы бұлттағы аппараттық репликациядан арзанырақ. Баға vCAV лицензиясының құнынан, әкімшілік алымдардан, бұлттық ресурстардың құнынан және PAYG үлгісіне сәйкес резервтік ресурстардан тұрады (өшірілген VM үшін жұмыс ресурстары құнының 10%).
Практикадан: Клиент Мәскеудегі біздің бұлтта әртүрлі дерекқорлары бар 6 виртуалды машинаны сақтады. Бастапқыда қорғаныс резервтік көшірме арқылы қамтамасыз етілді: сақтық көшірмелердің бір бөлігі Мәскеудегі бұлтта сақталды, ал кейбіреулері біздің Санкт-Петербург сайтында сақталды. Уақыт өте келе дерекқорлар көлемі өсті және сақтық көшірмеден қалпына келтіру көп уақытты талап ете бастады.
VMware vCloud Availability негізіндегі репликация сақтық көшірмелерге қосылды. Виртуалды машиналардың көшірмелері Санкт-Петербургтегі резервтік сайтта сақталады және әрбір 5 минут сайын жаңартылады. Егер негізгі сайтта ақаулық орын алса, қызметкерлер Санкт-Петербургтегі виртуалды машинаның көшірмесіне дербес ауысады және онымен жұмысты жалғастырады.
Қарастырылған барлық шешімдер жоғары қолжетімділікті қамтамасыз етеді, бірақ төлемдік бағдарлама вирусы немесе қызметкердің кездейсоқ қателігі салдарынан деректердің жоғалуынан қорғамайды. Бұл жағдайда бізге қажетті RPO қамтамасыз ететін сақтық көшірмелер қажет болады.
5. Сақтық көшірме жасауды ұмытпаңыз
Сізде апатқа қарсы ең жақсы шешім болса да, сақтық көшірме жасау керек екенін бәрі біледі. Сондықтан мен сізге бірнеше тармақты қысқаша еске саламын.
Қатаң айтқанда, сақтық көшірме DR емес. Және сол себепті:
- Ол ұзақ. Деректер терабайтпен өлшенсе, қалпына келтіру бір сағаттан астам уақытты алады. Қалпына келтіру, желіні тағайындау, оның қосылғанын тексеру, деректердің реттелгенін көру керек. Сондықтан сіз аз деректер болған жағдайда ғана жақсы RTO бере аласыз.
- Деректер бірінші рет қалпына келтірілмеуі мүмкін және әрекетті қайталауға уақыт беру керек. Мысалы, деректердің қашан жоғалғанын нақты білмейтін кездер болады. Шығын сағат 15.00-де байқалды делік, көшірмелер сағат сайын жасалады. 15.00-ден бастап біз барлық қалпына келтіру нүктелерін қараймыз: 14:00, 13:00 және т.б. Жүйе маңызды болса, біз қалпына келтіру нүктесінің жасын барынша азайтуға тырысамыз. Бірақ егер жаңа сақтық көшірмеде қажетті деректер болмаса, біз келесі тармақты аламыз - бұл қосымша уақыт.
Бұл жағдайда сақтық көшірме жасау кестесі қажеттіні қамтамасыз ете алады РҚБ. Сақтық көшірмелер үшін негізгі сайтта ақаулар туындаған жағдайда гео-брондауды қамтамасыз ету маңызды. Кейбір сақтық көшірмелерді бөлек сақтау ұсынылады.
Апатты қалпына келтірудің соңғы жоспары кемінде 2 құралды қамтуы керек:
- Жүйені сәтсіздіктерден және құлаудан қорғайтын 1-4 нұсқалардың бірі.
- Деректерді жоғалудан қорғау үшін сақтық көшірме жасау.
Сондай-ақ, негізгі Интернет-провайдер істен шыққан жағдайда байланыс арнасының сақтық көшірмесін жасау керек. Және - уа! — Ең төменгі жалақы бойынша ДР қазірдің өзінде дайын.
Ақпарат көзі: www.habr.com