Та томоохон худалдааны төвийн мэдээллийн технологийн дэд бүтцэд үйлчилгээ үзүүлж байна гээд төсөөлөөд үз дээ. Хотод бороо орж эхэлдэг. Борооны урсгал дээвэр дундуур урсаж, жижиглэн худалдааны байрыг шагайн хүртэл усаар дүүргэнэ. Таны серверийн өрөө подвалд байхгүй байгаа тул асуудлаас зайлсхийх боломжгүй гэж найдаж байна.
Тайлбарласан түүх нь уран зөгнөл биш, харин 2020 оны хэд хэдэн үйл явдлын хамтын тайлбар юм. Томоохон компаниудад энэ тохиолдолд гамшгаас хамгаалах төлөвлөгөө буюу гамшгаас сэргээх төлөвлөгөө (DRP) үргэлж бэлэн байдаг. Корпорацуудад энэ нь бизнесийн тасралтгүй байдлын мэргэжилтнүүдийн үүрэг юм. Гэхдээ дунд, жижиг компаниудад ийм асуудлыг шийдэх нь мэдээллийн технологийн үйлчилгээнд ордог. Та бизнесийн логикийг өөрөө ойлгож, юу бүтэлгүйтэж, хаана бүтэлгүйтэж болохыг ойлгож, хамгаалалт гаргаж, хэрэгжүүлэх хэрэгтэй.
Мэдээллийн технологийн мэргэжилтэн тухайн бизнестэй тохиролцож, хамгаалах хэрэгцээний талаар ярилцаж чадвал үнэхээр сайхан хэрэг. Гэхдээ нэг компани гамшгийн үед сэргээн босгох (DR) шийдлийг илүүдэхгүй гэж үзсэн учраас хэрхэн үр ашиггүй зарцуулсныг би нэг бус удаа харсан. Осол гарахад удаан хугацааны нөхөн сэргэлт нь алдагдалд заналхийлж, бизнес бэлэн биш байв. Та хүссэн хэмжээгээрээ: "Би чамд хэлсэн" гэж давтаж болно, гэхдээ мэдээллийн технологийн үйлчилгээ нь үйлчилгээгээ сэргээх шаардлагатай хэвээр байх болно.
Архитекторын байр сууринаас би энэ байдлаас хэрхэн зайлсхийх талаар танд хэлэх болно. Өгүүллийн эхний хэсэгт би бэлтгэл ажлыг харуулах болно: аюулгүй байдлын хэрэгслийг сонгохдоо үйлчлүүлэгчтэй гурван асуултыг хэрхэн хэлэлцэх вэ.
- Бид юу хамгаалж байна вэ?
- Бид юунаас хамгаалж байна вэ?
- Бид хэр зэрэг хамгаалдаг вэ?
Хоёрдахь хэсэгт бид өөрийгөө хэрхэн хамгаалах вэ гэсэн асуултанд хариулах сонголтуудын талаар ярих болно. Би янз бүрийн үйлчлүүлэгчид хамгаалалтаа хэрхэн бий болгодог тухай жишээ өгөх болно.
Бидний хамгаалдаг зүйл: бизнесийн чухал чиг үүргийг тодорхойлох
Бизнесийн үйлчлүүлэгчтэй яаралтай тусламжийн дараах үйл ажиллагааны төлөвлөгөөг хэлэлцэх замаар бэлтгэлээ эхлэх нь дээр. Энд байгаа гол бэрхшээл бол нийтлэг хэл олох явдал юм. Үйлчлүүлэгчид ихэвчлэн мэдээллийн технологийн шийдэл хэрхэн ажилладаг талаар огт хамаагүй. Энэ үйлчилгээ нь бизнесийн чиг үүргийг гүйцэтгэж, мөнгө авчирч чадах эсэх нь түүнд санаа тавьдаг. Жишээлбэл: хэрэв сайт ажиллаж байгаа боловч төлбөрийн систем нь доголдсон бол үйлчлүүлэгчдээс ямар ч орлого байхгүй, "хэт даврагчид" нь мэдээллийн технологийн мэргэжилтнүүд хэвээр байна.
Мэдээллийн технологийн мэргэжилтэн хэд хэдэн шалтгааны улмаас ийм хэлэлцээр хийхэд бэрхшээлтэй байж болно:
- Мэдээллийн технологийн үйлчилгээ нь мэдээллийн системийн бизнест гүйцэтгэх үүргийг бүрэн ойлгодоггүй. Жишээлбэл, бизнесийн үйл явц эсвэл ил тод бизнесийн загвар байхгүй бол.
- Бүх үйл явц нь мэдээллийн технологийн үйлчилгээнээс хамаардаггүй. Жишээлбэл, ажлын нэг хэсгийг гүйцэтгэгчид гүйцэтгэдэг бөгөөд мэдээллийн технологийн мэргэжилтнүүд тэдэнд шууд нөлөөлдөггүй.
Би харилцан яриаг дараах байдлаар зохион байгуулах болно.
- Бид аж ахуйн нэгжүүдэд осол аваар нь хүн бүрт тохиолддог, нөхөн сэргээхэд цаг хугацаа шаардагддаг гэдгийг тайлбарладаг. Хамгийн сайн зүйл бол нөхцөл байдал, энэ нь хэрхэн тохиолддог, ямар үр дагавар гарч болохыг харуулах явдал юм.
- Бүх зүйл мэдээллийн технологийн үйлчилгээнээс хамаардаггүй гэдгийг бид харуулж байна, гэхдээ та өөрийн хариуцаж буй чиглэлээр үйл ажиллагааны төлөвлөгөө гаргахад туслахад бэлэн байна.
- Бид бизнесийн үйлчлүүлэгчээс хариулахыг хүсч байна: хэрэв апокалипсис тохиолдвол аль процессыг хамгийн түрүүнд сэргээх ёстой вэ? Үүнд хэн, яаж оролцох вэ?
Бизнесээс энгийн хариулт шаардагдана, жишээлбэл: дуудлагын төв нь 24/7 програмыг үргэлжлүүлэн бүртгэх шаардлагатай.
- Бид системийн нэг эсвэл хоёр хэрэглэгчээс энэ үйл явцыг нарийвчлан тайлбарлахыг хүсч байна.
Хэрэв танай компанид шинжээч байгаа бол туслахын тулд шинжээчийг татан оролцуулах нь дээр.Эхлээд тайлбар нь иймэрхүү харагдаж болно: дуудлагын төв нь утсаар, шуудангаар, вэбсайтаас мессежээр хүсэлт хүлээн авдаг. Дараа нь тэр тэдгээрийг вэб интерфэйсээр дамжуулан 1С руу оруулдаг бөгөөд үйлдвэрлэл нь тэдгээрийг тэндээс ийм байдлаар авдаг.
- Дараа нь бид ямар техник хангамж, програм хангамжийн шийдлүүд үйл явцыг дэмждэг болохыг хардаг. Иж бүрэн хамгаалахын тулд бид гурван түвшинг харгалзан үздэг.
- сайт доторх програмууд болон системүүд (програм хангамжийн түвшин),
- систем ажиллаж байгаа сайт (дэд бүтцийн түвшин),
- сүлжээ (тэд үүнийг ихэвчлэн мартдаг).
- Бид бүтэлгүйтлийн боломжит цэгүүдийг олж мэдэв: үйлчилгээний гүйцэтгэлээс хамаардаг системийн зангилаанууд. Бид бусад компаниудын дэмждэг зангилаануудыг тусад нь тэмдэглэдэг: харилцаа холбооны операторууд, хостинг үйлчилгээ үзүүлэгчид, дата төвүүд гэх мэт. Үүний тусламжтайгаар та дараагийн алхамд бизнесийн үйлчлүүлэгч рүү буцаж очих боломжтой.
Бидний хамгаалдаг зүйл: эрсдэл
Дараа нь бид бизнесийн үйлчлүүлэгчээс эхлээд ямар эрсдэлээс өөрсдийгөө хамгаалдаг болохыг олж мэдээрэй. Бүх эрсдэлийг хоёр бүлэгт хувааж болно.
- үйлчилгээний сул зогсолтын улмаас цаг хугацаа алдах;
- физик нөлөөлөл, хүний хүчин зүйл гэх мэтийн улмаас өгөгдөл алдагдах.
Бизнесүүд өгөгдөл, цаг хугацаа алдахаас айдаг - энэ бүхэн мөнгө алдахад хүргэдэг. Тиймээс бид эрсдэлийн бүлэг тус бүрээс дахин асуулт асууж байна:
- Энэ үйл явцын хувьд бид өгөгдлийн алдагдал, цаг хугацааны алдагдалд хэр их мөнгө зарцуулдагийг тооцоолж чадах уу?
- Бид ямар өгөгдлийг алдаж болохгүй вэ?
- Бид хаана зогсолтыг зөвшөөрөхгүй байх вэ?
- Ямар үйл явдлууд бидэнд хамгийн их магадлалтай бөгөөд заналхийлж байна вэ?
Хэлэлцүүлгийн дараа бид бүтэлгүйтлийн цэгүүдийг хэрхэн эрэмбэлэхийг ойлгох болно.
Бид хэр их хамгаалдаг: RPO болон RTO
Гэмтлийн эгзэгтэй цэгүүд тодорхой болсон үед бид RTO болон RPO үзүүлэлтүүдийг тооцдог.
Үүнийг танд сануулъя RTO (сэргээх хугацаа) - энэ нь осол гарсан үеэс үйлчилгээ бүрэн сэргээгдэх хүртэлх зөвшөөрөгдөх хугацаа юм. Бизнесийн хэлээр бол энэ нь хүлээн зөвшөөрөгдөхүйц сул зогсолт юм. Хэрэв бид үйл явц хэр их мөнгө авчирсаныг мэдэж байгаа бол бид сул зогсолтын минут бүрээс алдагдлыг тооцож, хүлээн зөвшөөрөгдөх алдагдлыг тооцож болно.
RPO (сэргээх цэгийн зорилго) - хүчинтэй өгөгдөл сэргээх цэг. Энэ нь бидний өгөгдөл алдаж болох хугацааг тодорхойлдог. Бизнесийн үүднээс авч үзвэл мэдээлэл алдагдвал торгууль ногдуулдаг. Ийм алдагдлыг мөнгө болгон хувиргаж болно.
Сэргээх хугацааг эцсийн хэрэглэгчийн хувьд тооцоолох шаардлагатай: тэр хэр удаан системд нэвтэрч чадах вэ. Тиймээс эхлээд бид гинжин хэлхээний бүх холбоосыг сэргээх хугацааг нэмнэ. Энд ихэвчлэн алдаа гардаг: тэд үйлчилгээ үзүүлэгчийн RTO-г SLA-аас авч, үлдсэн нөхцлүүдийг мартдаг.
Тодорхой жишээг авч үзье. Хэрэглэгч 1С руу нэвтэрч, систем нь мэдээллийн сангийн алдаагаар нээгддэг. Тэр системийн администратортой холбоо барина. Өгөгдлийн сан нь үүлэн дотор байрладаг тул системийн администратор асуудлыг үйлчилгээ үзүүлэгчдээ мэдээлдэг. Бүх харилцаа холбоо 15 минут болно гэж бодъё. Клоуд дээр ийм хэмжээний мэдээллийн сан нэг цагийн дотор нөөцөөс сэргээгдэх тул үйлчилгээ үзүүлэгчийн RTO нь нэг цаг байна. Гэхдээ энэ нь эцсийн хугацаа биш бөгөөд хэрэглэгчийн хувьд асуудлыг илрүүлэхийн тулд 15 минут нэмсэн.
Дараа нь системийн администратор мэдээллийн бааз зөв эсэхийг шалгаж, 1С-д холбож, үйлчилгээг эхлүүлэх шаардлагатай. Үүнд дахиад нэг цаг шаардлагатай бөгөөд энэ нь администраторын RTO аль хэдийн 2 цаг 15 минут байна гэсэн үг юм. Хэрэглэгч дахин 15 минут шаардагдана: нэвтэрч, шаардлагатай гүйлгээ хийгдсэн эсэхийг шалгана уу. 2 цаг 30 минут бол энэ жишээн дээрх үйлчилгээг сэргээх нийт хугацаа юм.
Эдгээр тооцоолол нь эдийн засгийн нөхөн сэргээх хугацаа нь ямар гадаад хүчин зүйлээс хамаардаг болохыг бизнест харуулах болно. Жишээлбэл, оффис усанд автсан бол эхлээд гоожсон газрыг олж засварлах хэрэгтэй. Үүнд цаг хугацаа шаардагдах бөгөөд энэ нь IT-ээс хамаардаггүй.
Бид хэрхэн хамгаалдаг: янз бүрийн эрсдэлд зориулсан хэрэгслийг сонгох
Бүх зүйлийг ярилцсаны дараа үйлчлүүлэгч бизнесийн ослын зардлыг аль хэдийн ойлгосон. Одоо та багаж хэрэгслийг сонгож, төсвөө хэлэлцэж болно. Үйлчлүүлэгчийн тохиолдлуудын жишээг ашиглан би өөр өөр ажилд ямар хэрэгслийг санал болгож байгааг харуулах болно.
Эхний бүлгийн эрсдэлээс эхэлье: үйлчилгээний зогсолтоос үүдэлтэй алдагдал. Энэ асуудлыг шийдэх шийдэл нь сайн RTO өгөх ёстой.
- Аппликешныг үүлэн дээр байршуулах
Эхлэхийн тулд та зүгээр л үүл рүү шилжиж болно - үйлчилгээ үзүүлэгч өндөр хүртээмжтэй байдлын асуудлыг аль хэдийн бодож үзсэн. Виртуалчлалын хостуудыг кластерт нэгтгэж, эрчим хүч, сүлжээг нөөцөлж, өгөгдлийг алдаатай хадгалах системд хадгалдаг бөгөөд үйлчилгээ үзүүлэгч нь сул зогсолтыг санхүүгийн хувьд хариуцдаг.
Жишээлбэл, та үүлэн доторх мэдээллийн сан бүхий виртуал машиныг байршуулж болно. Аппликейшн нь өгөгдлийн сантай гаднаас нь тогтсон сувгаар эсвэл ижил үүлэн сүлжээгээр холбогдоно. Хэрэв кластер дахь серверүүдийн аль нэгэнд асуудал гарвал VM нь хөрш сервер дээр 2 минут хүрэхгүй хугацаанд дахин асах болно. Үүний дараа DBMS дотор нь ажиллаж эхлэх бөгөөд хэдхэн минутын дараа мэдээллийн сан бэлэн болно.
RTO: минутаар хэмжигддэг. Эдгээр нөхцлийг үйлчилгээ үзүүлэгчтэй байгуулсан гэрээнд зааж өгч болно.
зардал: Бид таны хэрэглээний үүлэн нөөцийн зардлыг тооцдог.
Энэ нь таныг юунаас хамгаалахгүй: үйлчилгээ үзүүлэгчийн сайт дээр гарсан их хэмжээний бүтэлгүйтлээс, жишээлбэл, хотын түвшинд гарсан ослын улмаас. - Аппликешныг бүлэглэх
Хэрэв та RTO-г сайжруулахыг хүсвэл өмнөх сонголтыг бэхжүүлж, кластер програмыг үүлэн дээр даруй байрлуулж болно.
Та кластерыг идэвхтэй-идэвхгүй эсвэл идэвхтэй-идэвхтэй горимд хэрэгжүүлж болно. Бид үйлдвэрлэгчийн шаардлагад үндэслэн хэд хэдэн VM-ийг үүсгэдэг. Илүү найдвартай байхын тулд бид тэдгээрийг өөр өөр сервер, хадгалах системд түгээдэг. Хэрэв өгөгдлийн сангийн аль нэг сервер ажиллахгүй бол нөөц зангилаа хэдхэн секундын дотор ачааллыг хүлээн авна.
RTO: секундээр хэмжсэн.
зардал: ердийн үүлнээс арай илүү үнэтэй тул кластер хийхэд нэмэлт нөөц шаардлагатай болно.
Энэ нь таныг юунаас хамгаалахгүй: Газар дээрх их хэмжээний эвдрэлээс хамгаалахгүй хэвээр байна. Гэхдээ орон нутгийн эвдрэл тийм ч удаан үргэлжлэхгүй.Практикаас: Жижиглэн худалдааны компани хэд хэдэн мэдээллийн систем, вэбсайттай байсан. Бүх мэдээллийн санг орон нутгийн хэмжээнд компанийн оффис дээр байрлуулсан. Оффис хэд хэдэн удаа дараалан цахилгаангүй болтол ямар ч DR-ийн талаар бодсонгүй. Үйлчлүүлэгчид вэбсайтын эвдрэлд сэтгэл хангалуун бус байсан.
Үйлчилгээний хүртээмжтэй холбоотой асуудал үүлэн рүү шилжсэний дараа шийдэгдсэн. Нэмж дурдахад бид зангилаа хоорондын урсгалыг тэнцвэржүүлснээр мэдээллийн сангийн ачааллыг оновчтой болгож чадсан. - Гамшигт тэсвэртэй үүл рүү шилжинэ
Хэрэв та үндсэн сайт дээрх байгалийн гамшиг ч таны ажилд саад учруулахгүй байх шаардлагатай бол гамшигт тэсвэртэй үүл сонгож болно. Энэ сонголтоор үйлчилгээ үзүүлэгч нь виртуалчлалын кластерыг 2 дата төвд тараана. Тогтмол синхрон хуулбар нь мэдээллийн төвүүдийн хооронд нэг нэгээр явагддаг. Мэдээллийн төвүүдийн хоорондох сувгууд нь нөөцлөгдсөн бөгөөд өөр өөр маршрутаар явдаг тул ийм кластер нь сүлжээний асуудлаас айдаггүй.
RTO: 0 байх хандлагатай.
зардал: Хамгийн үнэтэй үүлэн сонголт.
Энэ нь таныг юунаас хамгаалахгүй: Энэ нь хүний хүчин зүйлээс гадна мэдээллийн эвдрэлийн эсрэг тус болохгүй тул нэгэн зэрэг нөөцлөлт хийхийг зөвлөж байна.Практикаас: Манай нэг үйлчлүүлэгч гамшгаас хамгаалах цогц төлөвлөгөө боловсруулсан. Энэ бол түүний сонгосон стратеги юм:
- Гамшигт тэсвэртэй үүл нь програмыг дэд бүтцийн түвшинд бүтэлгүйтлээс хамгаалдаг.
- Хоёр түвшний нөөцлөлт нь хүний алдаанаас хамгаалах боломжийг олгодог. "Хүйтэн" ба "халуун" гэсэн хоёр төрлийн нөөцлөлт байдаг. "Хүйтэн" нөөц нь идэвхгүй байдалд байгаа бөгөөд байршуулахад цаг хугацаа шаардагдана. "Халуун" нөөцлөлтийг ашиглахад бэлэн болсон бөгөөд илүү хурдан сэргээгддэг. Энэ нь тусгай зориулалтын хадгалах системд хадгалагддаг. Гурав дахь хуулбарыг соронзон хальс дээр бичиж, өөр өрөөнд хадгална.
Долоо хоногт нэг удаа үйлчлүүлэгч хамгаалалтыг шалгаж, бүх нөөцлөлт, түүний дотор соронзон хальсны нөөцийн ажиллагааг шалгадаг. Жил бүр тус компани гамшигт тэсвэртэй үүлийг бүхэлд нь туршдаг.
- Өөр сайт руу хуулбарлах ажлыг зохион байгуулах
Үндсэн сайт дээрх дэлхийн асуудлуудаас хэрхэн зайлсхийх өөр нэг хувилбар: гео-захиалга өгөх. Өөрөөр хэлбэл, өөр хотын сайт дээр нөөц виртуал машин үүсгэх. DR-д зориулсан тусгай шийдлүүд үүнд тохиромжтой: манай компанид бид VMware vCloud Availability (vCAV) ашигладаг. Үүний тусламжтайгаар та хэд хэдэн үүлэн үйлчилгээ үзүүлэгч сайтуудын хооронд хамгаалалтыг тохируулах эсвэл өөрийн сайтаас үүлэнд сэргээх боломжтой. Би аль хэдийн vCAV-тай ажиллах схемийн талаар илүү дэлгэрэнгүй ярьсан .
RPO ба RTO: 5 минутаас.
зардал: эхний хувилбараас илүү үнэтэй, гэхдээ гамшигт тэсвэртэй үүлэн доторх техник хангамжийг хуулбарлахаас хямд. Үнэ нь vCAV лицензийн зардал, удирдлагын хураамж, үүлэн нөөцийн зардал, PAYG загварын дагуу нөөцийн нөөцөөс бүрдэнэ (унтраасан VM-ийн ажлын нөөцийн зардлын 10%).
Практикаас: Үйлчлүүлэгч өөр өөр мэдээллийн сан бүхий 6 виртуал машиныг Москва дахь манай үүлэн дотор хадгалдаг. Эхлээд хамгаалалтыг нөөцлөлтөөр хангасан: нөөц хуулбаруудын зарим нь Москва дахь үүлэн дотор хадгалагдаж, зарим нь манай Санкт-Петербургийн сайтад хадгалагдаж байсан. Цаг хугацаа өнгөрөхөд мэдээллийн баазын хэмжээ томорч, нөөцөөс сэргээхэд илүү их цаг зарцуулж эхлэв.
VMware vCloud Availability дээр суурилсан хуулбарыг нөөцлөлтөд нэмсэн. Виртуал машинуудын хуулбарыг Санкт-Петербург дахь нөөц сайт дээр хадгалдаг бөгөөд 5 минут тутамд шинэчлэгддэг. Хэрэв үндсэн сайтад алдаа гарвал ажилтнууд бие даан Санкт-Петербург дахь виртуал машины хуулбар руу шилжиж, түүнтэй үргэлжлүүлэн ажиллах болно.
Бүх шийдлүүд нь өндөр хүртээмжтэй байдаг боловч ransomware вирус эсвэл ажилчдын санамсаргүй алдаанаас үүдэн мэдээлэл алдагдахаас хамгаалдаггүй. Энэ тохиолдолд бидэнд шаардлагатай RPO-г хангах нөөцлөлт хэрэгтэй болно.
5. Нөөцлөлтийн талаар бүү мартаарай
Гамшгаас хамгаалах хамгийн гайхалтай шийдэлтэй байсан ч нөөцлөлт хийх хэрэгтэй гэдгийг хүн бүр мэддэг. Тиймээс би танд хэдэн зүйлийг товчхон сануулах болно.
Хатуухан хэлэхэд нөөц бол DR биш юм. Тэгээд ийм учраас:
- Удаан байна. Хэрэв өгөгдлийг терабайтаар хэмжсэн бол сэргээхэд нэг цагаас илүү хугацаа шаардагдана. Та сэргээх, сүлжээг хуваарилах, асаалттай байгаа эсэхийг шалгах, өгөгдөл эмх цэгцтэй байгаа эсэхийг шалгах хэрэгтэй. Тиймээс та өгөгдөл багатай тохиолдолд л сайн RTO өгч чадна.
- Өгөгдлийг анх удаа сэргээхгүй байж магадгүй тул та үйлдлийг давтах цаг гаргах хэрэгтэй. Жишээлбэл, өгөгдөл яг хэзээ алдагдсаныг мэдэхгүй байх тохиолдол байдаг. Алдагдал нь 15.00 цагт ажиглагдсан гэж бодъё, цаг тутамд хуулбар хийдэг. 15.00 цагаас эхлэн бид бүх сэргээх цэгүүдийг хардаг: 14:00, 13:00 гэх мэт. Хэрэв систем чухал бол бид нөхөн сэргээх цэгийн насыг багасгахыг хичээдэг. Гэхдээ шинэ нөөцлөлт нь шаардлагатай өгөгдлийг агуулаагүй бол бид дараагийн цэгийг авна - энэ бол нэмэлт цаг юм.
Энэ тохиолдолд нөөцлөх хуваарь нь шаардлагатай зүйлийг хангаж чадна RPO. Нөөцлөлтийн хувьд үндсэн сайттай холбоотой асуудал гарсан тохиолдолд гео-захиалга өгөх нь чухал юм. Зарим нөөц хуулбарыг тусад нь хадгалахыг зөвлөж байна.
Гамшгаас хамгаалах эцсийн төлөвлөгөө нь дор хаяж 2 хэрэгслийг агуулсан байх ёстой:
- Системийг эвдрэл, уналтаас хамгаалах 1-4 хувилбаруудын нэг.
- Өгөгдлийг алдагдахаас хамгаалахын тулд нөөцлөлт хийх.
Үндсэн интернет үйлчилгээ үзүүлэгч унтарсан тохиолдолд нөөц холбооны сувгийг анхаарч үзэх нь зүйтэй. Тэгээд - voila! -Хөдөлмөрийн хөлсний доод хэмжээгээр DR аль хэдийн бэлэн болсон.
Эх сурвалж: www.habr.com