To'fon bo'lsa ham, 1C ishlashi kerak! Biz DR bo'yicha biznes bilan rozi bo'lamiz

Tasavvur qiling: siz yirik savdo markazining IT infratuzilmasiga xizmat ko'rsatyapsiz. Shaharda yomg'ir yog'a boshlaydi. Yomg'ir oqimlari tomni kesib o'tadi, suv chakana savdo binolarini to'piqgacha to'ldiradi. Umid qilamizki, sizning server xonangiz podvalda emas, aks holda muammolardan qochib bo'lmaydi.  

Ta'riflangan voqea xayoliy emas, balki 2020 yildagi bir nechta voqealarning umumiy tavsifidir. Yirik kompaniyalarda bu holatda falokatni tiklash rejasi (DRP) har doim tayyor. Korporatsiyalarda bu biznesning uzluksizligi bo'yicha mutaxassislarning mas'uliyati. Ammo o'rta va kichik kompaniyalarda bunday muammolarni hal qilish IT xizmatlariga to'g'ri keladi. Siz biznes mantig'ini o'zingiz tushunishingiz kerak, nima muvaffaqiyatsiz bo'lishi mumkinligini va qaerda ekanligini tushunishingiz, himoya qilishni o'ylab topishingiz va uni amalga oshirishingiz kerak. 

IT-mutaxassis biznes bilan muzokara olib borishi va himoya zarurligini muhokama qilishi juda yaxshi. Ammo men kompaniyaning tabiiy ofatdan qutqarish (DR) yechimidan qanday foydalanmaganini bir necha bor ko'rganman, chunki u buni ortiqcha deb hisoblagan. Baxtsiz hodisa yuz berganda, uzoq tiklanish yo'qotishlar bilan tahdid qildi va biznes tayyor emas edi. Siz xohlagancha takrorlashingiz mumkin: "Men sizga aytdim", lekin IT xizmati hali ham xizmatlarni tiklashi kerak.

To'fon bo'lsa ham, 1C ishlashi kerak! Biz DR bo'yicha biznes bilan rozi bo'lamiz

Me'morning pozitsiyasidan men sizga bu vaziyatdan qanday qochish kerakligini aytaman. Maqolaning birinchi qismida men tayyorgarlik ishlarini ko'rsataman: xavfsizlik vositalarini tanlash uchun mijoz bilan uchta savolni qanday muhokama qilish kerak: 

  • Biz nimani himoya qilamiz?
  • Biz nimadan himoya qilamiz?
  • Biz qanchalik himoya qilamiz? 

Ikkinchi qismda biz savolga javob berish variantlari haqida gapiramiz: o'zingizni qanday himoya qilish kerak. Men turli xil mijozlar o'z himoyasini qanday yaratishiga misollar keltiraman.

Biz nimani himoya qilamiz: muhim biznes funktsiyalarini aniqlash 

Tayyorgarlikni biznes-mijoz bilan favqulodda vaziyatdan keyingi harakatlar rejasini muhokama qilishdan boshlash yaxshidir. Bu erda asosiy qiyinchilik umumiy til topishdir. Mijoz odatda IT yechimi qanday ishlashiga ahamiyat bermaydi. U xizmat biznes funktsiyalarini bajarishi va pul olib kelishi mumkinligi haqida qayg'uradi. Misol uchun: agar sayt ishlayotgan bo'lsa, lekin to'lov tizimi ishlamasa, mijozlardan daromad yo'q va "ekstremistlar" hali ham IT mutaxassislari. 

IT mutaxassisi bir necha sabablarga ko'ra bunday muzokaralarda qiyinchiliklarga duch kelishi mumkin:

  • IT-xizmati axborot tizimining biznesdagi rolini to'liq tushunmaydi. Misol uchun, agar biznes jarayonlarining tavsifi yoki shaffof biznes modeli mavjud bo'lmasa. 
  • Butun jarayon IT xizmatiga bog'liq emas. Masalan, ishning bir qismi pudratchilar tomonidan bajarilganda va IT-mutaxassislari ularga bevosita ta'sir ko'rsatmasa.

Men suhbatni shunday tuzgan bo'lardim: 

  1. Biz korxonalarga baxtsiz hodisalar hamma bilan sodir bo'lishini tushuntiramiz va tiklanish vaqt talab etadi. Eng yaxshisi, vaziyatlarni, bu qanday sodir bo'lishini va qanday oqibatlarga olib kelishi mumkinligini ko'rsatishdir.
  2. Biz hamma narsa IT xizmatiga bog'liq emasligini ko'rsatamiz, lekin siz o'zingizning mas'uliyat sohangiz bo'yicha harakatlar rejasida yordam berishga tayyormiz.
  3. Biz biznes mijozidan javob berishini so'raymiz: agar apokalipsis sodir bo'lsa, birinchi navbatda qaysi jarayonni tiklash kerak? Unda kim va qanday ishtirok etadi? 

    Biznesdan oddiy javob talab qilinadi, masalan: call-markaz 24/7 kun davomida arizalarni ro'yxatdan o'tkazishni davom ettirishi kerak.

  4. Tizimning bir yoki ikkita foydalanuvchisidan ushbu jarayonni batafsil tasvirlab berishlarini so'raymiz. 
    Sizning kompaniyangiz bo'lsa, yordam berish uchun tahlilchini jalb qilish yaxshiroqdir.

    Boshlash uchun tavsif quyidagicha ko'rinishi mumkin: qo'ng'iroq markazi telefon orqali, pochta orqali va veb-saytdan xabarlar orqali so'rovlarni qabul qiladi. Keyin u veb-interfeys orqali ularni 1C ga kiritadi va ishlab chiqarish ularni shu tarzda u erdan oladi.

  5. Keyin qanday apparat va dasturiy echimlar jarayonni qo'llab-quvvatlayotganini ko'rib chiqamiz. Har tomonlama himoya qilish uchun biz uchta darajani hisobga olamiz: 
    • sayt ichidagi ilovalar va tizimlar (dasturiy ta'minot darajasi),   
    • tizimlar ishlaydigan saytning o'zi (infratuzilma darajasi), 
    • tarmoq (ular ko'pincha bu haqda unutishadi).

  6. Biz nosozlikning mumkin bo'lgan nuqtalarini aniqlaymiz: xizmatning ishlashi bog'liq bo'lgan tizim tugunlari. Biz boshqa kompaniyalar tomonidan qo'llab-quvvatlanadigan tugunlarni alohida qayd etamiz: aloqa operatorlari, hosting provayderlari, ma'lumotlar markazlari va boshqalar. Bu bilan siz keyingi qadam uchun biznes mijozga qaytishingiz mumkin.

Biz nimadan himoya qilamiz: xavflar

Keyinchalik, biz biznes mijozdan birinchi navbatda o'zimizni qanday xavflardan himoya qilishimizni bilib olamiz. Barcha xavflarni ikki guruhga bo'lish mumkin: 

  • xizmat ko'rsatishning to'xtab qolishi sababli vaqtni yo'qotish;
  • jismoniy ta'sirlar, inson omillari va boshqalar tufayli ma'lumotlarning yo'qolishi.

Korxonalar ma'lumotlar va vaqtni yo'qotishdan qo'rqishadi - bularning barchasi pul yo'qotilishiga olib keladi. Shunday qilib, biz har bir xavf guruhi uchun yana savollar beramiz: 

  • Ushbu jarayon uchun ma'lumotlar yo'qotilishi va vaqt yo'qotilishi qancha pulga tushishini taxmin qila olamizmi? 
  • Qanday ma'lumotlarni yo'qota olmaymiz? 
  • Qayerda to'xtab qolishga yo'l qo'ymasligimiz mumkin? 
  • Qaysi voqealar biz uchun eng ko'p va eng xavfli?

Muhokama qilgandan so'ng, biz muvaffaqiyatsizlik nuqtalariga qanday ustuvorlik berishni tushunamiz. 

Biz qanchalik himoya qilamiz: RPO va RTO 

Muvaffaqiyatsizlikning muhim nuqtalari aniq bo'lsa, biz RTO va RPO ko'rsatkichlarini hisoblaymiz. 

Men sizga buni eslatib qo'yaman RTO (tiklash vaqti maqsadi) — bu voqea sodir bo'lgan paytdan boshlab xizmat to'liq tiklanguncha ruxsat etilgan vaqt. Ishbilarmonlik tilida bu maqbul ishlamay qolish vaqtidir. Agar jarayon qancha pul olib kelganini bilsak, biz har bir ishlamay qolgan daqiqadan yo'qotishlarni hisoblab, maqbul yo'qotishni hisoblashimiz mumkin. 

RPO (tiklash nuqtasi maqsadi) — yaroqli maʼlumotlarni tiklash nuqtasi. Bu ma'lumotlarni yo'qotishimiz mumkin bo'lgan vaqtni belgilaydi. Biznes nuqtai nazaridan, ma'lumotlarning yo'qolishi, masalan, jarimaga olib kelishi mumkin. Bunday yo'qotishlarni pulga aylantirish ham mumkin. 

To'fon bo'lsa ham, 1C ishlashi kerak! Biz DR bo'yicha biznes bilan rozi bo'lamiz

Qayta tiklash vaqtini oxirgi foydalanuvchi uchun hisoblash kerak: u tizimga qancha vaqt kira oladi. Shunday qilib, avval biz zanjirdagi barcha bo'g'inlarning tiklanish vaqtini qo'shamiz. Bu erda ko'pincha xatoga yo'l qo'yiladi: ular provayderning RTO-ni SLA-dan olishadi va qolgan shartlarni unutishadi.

Keling, aniq bir misolni ko'rib chiqaylik. Foydalanuvchi 1C ga kiradi, tizim ma'lumotlar bazasi xatosi bilan ochiladi. U tizim administratoriga murojaat qiladi. Ma'lumotlar bazasi bulutda joylashgan, tizim ma'muri muammo haqida xizmat ko'rsatuvchi provayderga xabar beradi. Aytaylik, barcha aloqalar 15 daqiqa davom etadi. Bulutda ushbu o'lchamdagi ma'lumotlar bazasi bir soat ichida zaxiradan tiklanadi, shuning uchun xizmat ko'rsatuvchi provayder tomonida RTO bir soatni tashkil qiladi. Ammo bu oxirgi muddat emas; foydalanuvchi uchun muammoni aniqlash uchun unga 15 daqiqa qo'shilgan. 
 
Keyinchalik, tizim ma'muri ma'lumotlar bazasi to'g'riligini tekshirishi, uni 1C ga ulashi va xizmatlarni ishga tushirishi kerak. Buning uchun yana bir soat kerak bo'ladi, ya'ni administrator tomonida RTO allaqachon 2 soat 15 daqiqa. Foydalanuvchiga yana 15 daqiqa kerak bo'ladi: tizimga kiring, kerakli tranzaktsiyalar paydo bo'lganligini tekshiring. 2 soat 30 daqiqa - bu misolda xizmatni tiklashning umumiy vaqti.

Ushbu hisob-kitoblar biznesni tiklanish davri qanday tashqi omillarga bog'liqligini ko'rsatadi. Misol uchun, agar ofis suv bosgan bo'lsa, avval siz qochqinni topib, uni tuzatishingiz kerak. Bu ITga bog'liq bo'lmagan vaqtni oladi.  

Biz qanday himoya qilamiz: turli xavflar uchun vositalarni tanlash

Barcha fikrlarni muhokama qilgandan so'ng, mijoz biznes uchun baxtsiz hodisaning narxini allaqachon tushunadi. Endi siz vositalarni tanlashingiz va byudjetni muhokama qilishingiz mumkin. Mijozlarning misollaridan foydalanib, men sizga turli vazifalar uchun qanday vositalarni taklif qilishimizni ko'rsataman. 

Xatarlarning birinchi guruhidan boshlaylik: xizmat ko'rsatishning to'xtab qolishi sababli yo'qotishlar. Ushbu muammoni hal qilish yaxshi RTOni ta'minlashi kerak.

  1. Ilovani bulutda joylashtiring 

    Boshlash uchun siz shunchaki bulutga o'tishingiz mumkin - provayder allaqachon yuqori darajadagi mavjudlik masalalarini o'ylab ko'rgan. Virtualizatsiya xostlari klasterga yig'iladi, quvvat va tarmoq zaxiralanadi, ma'lumotlar nosozliklarga chidamli saqlash tizimlarida saqlanadi va xizmat ko'rsatuvchi provayder to'xtab qolish uchun moliyaviy javobgarlikni o'z zimmasiga oladi.

    Masalan, bulutda ma'lumotlar bazasiga ega virtual mashinani joylashtirishingiz mumkin. Ilova ma'lumotlar bazasiga tashqaridan o'rnatilgan kanal orqali yoki bir xil bulutdan ulanadi. Agar klasterdagi serverlardan birida muammolar yuzaga kelsa, VM qo'shni serverda 2 daqiqadan kamroq vaqt ichida qayta ishga tushadi. Shundan so'ng, unda DBMS ishga tushadi va bir necha daqiqadan so'ng ma'lumotlar bazasi mavjud bo'ladi.

    OTR: daqiqalarda o'lchanadi. Ushbu shartlar provayder bilan tuzilgan shartnomada belgilanishi mumkin.
    qiymati: Biz ilovangiz uchun bulutli resurslar narxini hisoblaymiz. 
    Bu sizni nimadan himoya qilmaydi: provayder saytidagi katta nosozliklardan, masalan, shahar darajasidagi baxtsiz hodisalar tufayli.

  2. Ilovani klasterlash  

    Agar siz RTO-ni yaxshilamoqchi bo'lsangiz, oldingi variantni kuchaytirishingiz va darhol bulutga klasterli dasturni joylashtirishingiz mumkin.

    Klasterni faol-passiv yoki faol-faol rejimda amalga oshirishingiz mumkin. Biz sotuvchining talablari asosida bir nechta VM larni yaratamiz. Kattaroq ishonchlilik uchun biz ularni turli serverlar va saqlash tizimlariga tarqatamiz. Agar ma'lumotlar bazalaridan biri bo'lgan server ishlamay qolsa, zaxira tugun bir necha soniya ichida yukni oladi.

    OTR: soniyalarda o'lchanadi.
    qiymati: oddiy bulutdan biroz qimmatroq, klasterlash uchun qo'shimcha resurslar talab qilinadi.
    Bu sizni nimadan himoya qilmaydi: Hali ham saytdagi katta nosozliklardan himoya qilmaydi. Ammo mahalliy buzilishlar uzoq davom etmaydi.

    Amaliyotdan: Chakana savdo kompaniyasida bir nechta axborot tizimlari va veb-saytlari mavjud edi. Barcha ma'lumotlar bazalari kompaniya ofisida mahalliy darajada joylashgan edi. Ofis bir necha marta ketma-ket quvvatsiz qolmaguncha, hech qanday DR haqida o'ylamagan. Mijozlar veb-saytning ishdan chiqishidan norozi edi. 
     
    Xizmat mavjudligi bilan bog'liq muammo bulutga o'tgandan keyin hal qilindi. Bundan tashqari, biz tugunlar orasidagi trafikni muvozanatlash orqali ma'lumotlar bazalariga yukni optimallashtirishga muvaffaq bo'ldik.

  3. Falokatdan himoyalangan bulutga o'ting

    Agar asosiy saytdagi tabiiy ofat ham ish to‘xtatilmasligiga ishonch hosil qilishingiz kerak bo‘lsa, ofatga chidamli bulutni tanlashingiz mumkin.Ushbu variantda provayder virtualizatsiya klasterini 2 ta ma’lumot markazlari bo‘ylab tarqatadi. Doimiy sinxron replikatsiya ma'lumotlar markazlari o'rtasida, birma-bir sodir bo'ladi. Ma'lumot markazlari orasidagi kanallar ajratilgan va turli yo'nalishlar bo'ylab harakatlanadi, shuning uchun bunday klaster tarmoq muammolaridan qo'rqmaydi. 

    OTR: 0 ga intiladi.
    qiymati: Eng qimmat bulutli variant. 
    Bu sizni nimadan himoya qilmaydi: Bu ma'lumotlarning buzilishiga, shuningdek, inson omiliga qarshi yordam bermaydi, shuning uchun bir vaqtning o'zida zaxira nusxalarini yaratish tavsiya etiladi. 

    Amaliyotdan: Mijozlarimizdan biri ofatni tiklashning keng qamrovli rejasini ishlab chiqdi. Bu u tanlagan strategiya: 

    • Tabiiy ofatlarga chidamli bulut dasturni infratuzilma darajasidagi nosozliklardan himoya qiladi. 
    • Ikki darajali zaxira inson xatosidan himoya qiladi. Ikki turdagi zaxira mavjud: "sovuq" va "issiq". "Sovuq" zaxira o'chirilgan holatda va uni joylashtirish uchun vaqt talab etiladi. "Issiq" zaxira allaqachon foydalanishga tayyor va tezroq tiklanadi. U maxsus ajratilgan saqlash tizimida saqlanadi. Uchinchi nusxa lentaga yozib olinadi va boshqa xonada saqlanadi. 

    Haftada bir marta mijoz himoyani sinovdan o'tkazadi va barcha zaxiralarning, shu jumladan lentadagilarning funksionalligini tekshiradi. Har yili kompaniya butun ofatga chidamli bulutni sinovdan o'tkazadi. 

  4. Boshqa saytga replikatsiya qilishni tashkil qiling 

    Asosiy saytdagi global muammolardan qanday qochishning yana bir varianti: geo-rezervatsiyani ta'minlash. Boshqacha qilib aytganda, boshqa shahardagi saytda zaxira virtual mashinalarni yarating. Buning uchun DR uchun maxsus echimlar mos keladi: kompaniyamizda biz VMware vCloud Availability (vCAV) dan foydalanamiz. Uning yordami bilan siz bir nechta bulutli provayder saytlari o'rtasida himoyani sozlashingiz yoki mahalliy saytdan bulutga tiklashingiz mumkin. Men allaqachon vCAV bilan ishlash sxemasi haqida batafsilroq gaplashdim shu yerda

    RPO va RTO: 5 daqiqadan boshlab. 

    qiymati: birinchi variantdan qimmatroq, lekin ofatdan himoyalangan bulutda apparat replikatsiyasidan arzonroq. Narx vCAV litsenziyasi narxidan, ma'muriy to'lovlardan, bulutli resurslar narxidan va PAYG modeli bo'yicha zahira resurslaridan iborat (o'chirilgan VMlar uchun ishchi resurslar narxining 10%).

    Amaliyotdan: Mijoz Moskvadagi bulutimizda turli ma'lumotlar bazalariga ega 6 ta virtual mashinani saqladi. Dastlab, himoya zaxira bilan ta'minlandi: zaxira nusxalarining bir qismi Moskvadagi bulutda, ba'zilari esa bizning Sankt-Peterburg saytimizda saqlangan. Vaqt o'tishi bilan ma'lumotlar bazalari hajmi kattalashdi va zaxiradan tiklash ko'proq vaqt talab qila boshladi. 
     
    Zaxira nusxalariga VMware vCloud Availability asosidagi replikatsiya qo'shildi. Virtual mashinalarning nusxalari Sankt-Peterburgdagi zaxira saytida saqlanadi va har 5 daqiqada yangilanadi. Agar asosiy saytda nosozlik yuzaga kelsa, xodimlar mustaqil ravishda Sankt-Peterburgdagi virtual mashinaning nusxasiga o'tadi va u bilan ishlashni davom ettiradi. 

Ko'rib chiqilayotgan barcha echimlar yuqori darajadagi mavjudlikni ta'minlaydi, ammo to'lov dasturi virusi yoki tasodifiy xodim xatosi tufayli ma'lumotlarni yo'qotishdan himoya qilmaydi. Bunday holda, bizga kerakli RPO ni ta'minlaydigan zaxira nusxalari kerak bo'ladi.

5. Zaxira haqida unutmang

Har bir inson, hatto eng zo'r ofatga chidamli yechimga ega bo'lsangiz ham, zaxira nusxalarini yaratishingiz kerakligini biladi. Shuning uchun men sizga bir nechta fikrlarni qisqacha eslatib o'taman.

To'g'ri aytganda, zaxira DR emas. Va shuning uchun: 

  • Bu uzoq vaqt. Agar ma'lumotlar terabaytlarda o'lchansa, tiklash bir soatdan ko'proq vaqtni oladi. Qayta tiklashingiz, tarmoqni belgilashingiz, yoqilganligini tekshirishingiz, ma'lumotlarning tartibda ekanligini tekshirishingiz kerak. Shunday qilib, siz ozgina ma'lumot bo'lsa, yaxshi RTO ni taqdim etishingiz mumkin. 
  • Ma'lumotlar birinchi marta tiklanmasligi mumkin va siz harakatni takrorlash uchun vaqt berishingiz kerak. Misol uchun, ma'lumotlar qachon yo'qolganini aniq bilmaydigan holatlar mavjud. Aytaylik, yo'qotish soat 15.00 da sezildi va har soatda nusxa ko'chiriladi. 15.00 dan boshlab biz barcha tiklash nuqtalarini ko'rib chiqamiz: 14:00, 13:00 va hokazo. Agar tizim muhim bo'lsa, biz tiklanish nuqtasining yoshini minimallashtirishga harakat qilamiz. Ammo agar yangi zaxirada kerakli ma'lumotlar bo'lmasa, biz keyingi nuqtani olamiz - bu qo'shimcha vaqt. 

Bunday holda, zaxira jadvali kerakli narsani ta'minlashi mumkin RPO. Zaxira nusxalari uchun asosiy sayt bilan bog'liq muammolar yuzaga kelganda geo-rezervatsiyani ta'minlash muhimdir. Ba'zi zaxira nusxalarini alohida saqlash tavsiya etiladi.

Favqulodda vaziyatni tiklashning yakuniy rejasi kamida 2 vositani o'z ichiga olishi kerak:  

  • Tizimlarni nosozliklar va tushishlardan himoya qiladigan 1-4 variantlardan biri.
  • Ma'lumotlarni yo'qotishdan himoya qilish uchun zaxiralash. 

Asosiy Internet-provayder ishlamay qolsa, zaxira aloqa kanali haqida ham g'amxo'rlik qilish kerak. Va - voila! — Eng kam ish haqi bo'yicha DR allaqachon tayyor. 

Manba: www.habr.com

a Izoh qo'shish