Sanajan éta caah, 1C kedah dianggo! Urang satuju jeung bisnis on DR

Bayangkeun: anjeun ngalayanan infrastruktur IT di pusat balanja ageung. Ieu mimiti hujan di kota. Aliran hujan norobos hateupna, cai ngeusi enggon eceran sajero-jero. Urang ngaharepkeun kamar server anjeun teu di basement, disebutkeun masalah teu bisa dihindari.  

Carita anu dijelaskeun sanés implengan, tapi pedaran koléktif ngeunaan sababaraha kajadian taun 2020. Di perusahaan ageung, rencana pamulihan bencana, atanapi rencana pamulihan bencana (DRP), sok aya di tangan pikeun kasus ieu. Dina korporasi, ieu mangrupikeun tanggung jawab spesialis kontinuitas bisnis. Tapi di perusahaan sedeng sareng alit, ngarengsekeun masalah sapertos kitu tumiba kana jasa IT. Anjeun kedah ngartos logika bisnis sorangan, ngartos naon anu tiasa gagal sareng dimana, kéngingkeun panyalindungan sareng ngalaksanakeunana. 

Éta saé upami spesialis IT tiasa negosiasi sareng bisnis sareng ngabahas kabutuhan panyalindungan. Tapi kuring geus katempo leuwih ti sakali kumaha hiji parusahaan skimped on solusi recovery musibah (DR) sabab dianggap kaleuleuwihan. Nalika kacilakaan lumangsung, recovery lila ngancam karugian, sarta bisnis teu siap. Anjeun tiasa ngulang saloba anjeun resep: "Kuring bébéja anjeun kitu," tapi jasa IT tetep kudu mulangkeun jasa.

Tina posisi arsitek, kuring bakal nyarioskeun ka anjeun kumaha carana nyingkahan kaayaan ieu. Dina bagian mimiti tulisan, kuring bakal nunjukkeun padamelan persiapan: kumaha ngabahas tilu patarosan sareng palanggan pikeun milih alat kaamanan: 

• Naon anu urang ngajaga?
• Urang ngajaga tina naon?
• Sabaraha urang ngajaga? 

Dina bagian kadua, urang bakal ngobrol ngeunaan pilihan pikeun ngajawab patarosan: kumaha carana membela diri. Kuring bakal masihan conto kasus kumaha konsumén béda ngawangun panyalindungan maranéhanana.

Anu kami lindungan: ngaidentipikasi fungsi bisnis kritis 

Éta langkung saé pikeun ngamimitian nyiapkeun ku ngabahas rencana aksi pasca-darurat sareng palanggan bisnis. Kasusah utama di dieu nyaéta pikeun milarian basa anu umum. Palanggan biasana henteu paduli kumaha jalanna solusi IT. Anjeunna paduli naha jasa tiasa ngalakukeun fungsi bisnis jeung mawa duit. Salaku conto: upami situsna berpungsi, tapi sistem pamayaran turun, teu aya panghasilan tina klien, sareng "ekstremis" masih spesialis IT. 

Profesional IT tiasa sesah dina rundingan sapertos kitu kusabab sababaraha alesan:

• Ladenan IT henteu ngartos sapinuhna peran sistem inpormasi dina bisnis. Salaku conto, upami teu aya pedaran ngeunaan prosés bisnis atanapi modél bisnis anu transparan. 
• Henteu sakabéh prosés gumantung kana jasa IT. Salaku conto, nalika bagian tina padamelan dilaksanakeun ku kontraktor, sareng spesialis IT henteu gaduh pangaruh langsung kana aranjeunna.

Abdi badé nyusun paguneman sapertos kieu: 

1. Urang ngajelaskeun ka usaha yén kacilakaan lumangsung ka dulur, sarta recovery butuh waktu. Hal anu pangsaéna nyaéta nunjukkeun kaayaan, kumaha ieu kajantenan sareng naon akibat anu mungkin.
2. Kami nunjukkeun yén henteu sadayana gumantung kana jasa IT, tapi anjeun siap ngabantosan rencana aksi di daérah tanggung jawab anjeun.
3. Kami naroskeun ka nasabah bisnis pikeun ngajawab: upami kiamat kajantenan, prosés mana anu kedah dibalikeun heula? Saha anu ilubiung dina éta sareng kumaha? 

   Jawaban anu saderhana diperyogikeun tina bisnis, contona: pusat sauran kedah terus ngadaptarkeun aplikasi 24/7.

4. Kami naroskeun ka hiji atanapi dua pangguna sistem pikeun ngajelaskeun prosés ieu sacara rinci. 
   Éta langkung saé ngalibetkeun analis pikeun ngabantosan upami perusahaan anjeun ngagaduhan.

   Pikeun mimitian, katerangan tiasa sapertos kieu: pusat sauran nampi pamundut ku telepon, ku mail sareng pesen tina situs wéb. Lajeng anjeunna ngasupkeun kana 1C via panganteur web, sarta produksi nyandak aranjeunna ti dinya ku cara kieu.

5. Teras we tingali naon solusi hardware sareng software anu ngadukung prosés éta. Pikeun panyalindungan komprehensif, urang tumut kana akun tilu tingkatan: 
   • aplikasi sareng sistem dina situs (tingkat software),   
   • situs sorangan dimana sistem ngajalankeun (tingkat infrastruktur), 
   • jaringan (aranjeunna sering poho ngeunaan eta).

6. Kami mendakan titik-titik anu mungkin gagal: titik sistem anu gumantung kana kinerja jasa. Urang misah catetan titik nu dirojong ku pausahaan séjén: operator telekomunikasi, panyadia hosting, puseur data, jeung saterusna. Kalayan ieu, anjeun tiasa uih deui ka palanggan bisnis pikeun léngkah salajengna.

Naon urang ngajaga tina: resiko

Salajengna, urang manggihan ti nasabah bisnis naon resiko urang ngajaga diri ti mimiti. Sadaya résiko tiasa dibagi kana dua kelompok: 

• leungitna waktu alatan downtime jasa;
• leungitna data alatan dampak fisik, faktor manusa, jsb.

Usaha sieun kaleungitan data sareng waktos - sadayana ieu nyababkeun kaleungitan artos. Kitu deui urang naroskeun patarosan pikeun unggal kelompok résiko: 

• Pikeun prosés ieu, urang bisa estimasi sabaraha leungitna data jeung waktu leungitna waragad duit? 
• Data naon anu urang moal leungit? 
• Dimana urang teu bisa ngidinan downtime? 
• Kajadian naon anu paling dipikaresep sareng paling ngancam urang?

Saatos diskusi, urang bakal ngartos kumaha prioritas titik gagal. 

Sabaraha urang ngajaga: RPO na RTO 

Nalika titik kritis gagalna jelas, urang ngitung indikator RTO sareng RPO. 

Hayu atuh ngingetan yén anjeun RTO (tujuan waktos pamulihan) - ieu teh waktos allowable ti momen kacilakaan nepi ka layanan pinuh disimpen. Dina basa bisnis, ieu téh downtime ditarima. Lamun urang nyaho sabaraha duit prosés dibawa, urang bisa ngitung karugian tina unggal menit downtime jeung ngitung leungitna ditarima. 

RPO (tujuan titik recovery) - titik recovery data valid. Ieu nangtukeun waktu salila urang bisa leungit data. Tina sudut pandang bisnis, leungitna data tiasa nyababkeun denda, contona. Karugian sapertos kitu ogé tiasa dirobih janten artos. 

Waktu pamulihan kedah diitung pikeun pangguna akhir: sabaraha lami anjeunna tiasa asup kana sistem. Janten mimitina urang tambahkeun waktos pamulihan sadaya tautan dina ranté éta. Kasalahan sering dilakukeun di dieu: aranjeunna nyandak RTO panyadia tina SLA, sareng hilap ngeunaan istilah sésana.

Hayu urang nempo conto husus. Pamaké asup kana 1C, sistem dibuka ku kasalahan database. Anjeunna ngahubungan administrator sistem. Pangkalan data aya dina méga, administrator sistem ngalaporkeun masalah ka panyadia ladénan. Anggap sadayana komunikasi butuh 15 menit. Dina méga, pangkalan data ukuran ieu bakal disimpen deui tina cadangan dina sajam, janten, RTO di sisi panyadia ladénan sajam. Tapi ieu sanés waktos anu terakhir; pikeun pangguna, 15 menit parantos ditambah kana éta pikeun ngadeteksi masalah. 
 
Salajengna, administrator sistem kedah pariksa yén pangkalan data leres, sambungkeun ka 1C sareng ngamimitian jasa. Ieu merlukeun jam sejen, nu hartina RTO di sisi administrator geus 2 jam 15 menit. Pamaké peryogi 15 menit deui: log in, pariksa yén transaksi anu diperyogikeun parantos muncul. 2 jam 30 menit nyaéta total waktos pamulihan jasa dina conto ieu.

itungan ieu bakal némbongkeun usaha dina naon faktor éksternal gumantung periode recovery. Salaku conto, upami kantor banjir, anjeun kedah milarian heula bocorna sareng ngalereskeunana. Bakal butuh waktu, nu teu gumantung kana IT.  

Kumaha urang ngajaga: milih alat pikeun resiko béda

Saatos ngabahas sagala titik, nasabah geus understands biaya kacilakaan pikeun bisnis. Ayeuna anjeun tiasa milih alat sareng ngabahas anggaran. Nganggo conto kasus klien, kuring bakal nunjukkeun anjeun alat naon anu kami tawarkeun pikeun tugas anu béda. 

Hayu urang mimitian ku grup résiko munggaran: karugian kusabab downtime jasa. Solusi pikeun masalah ieu kedah nyayogikeun RTO anu saé.

1. Host aplikasi dina awan 

   Pikeun mimitian, anjeun ngan saukur tiasa ngalih ka awan - panyadia parantos mikirkeun masalah kasadiaan anu luhur. Host virtualisasi dirakit kana klaster, kakuatan sareng jaringan ditangtayungan, data disimpen dina sistem panyimpen anu teu toleran, sareng panyadia ladénan tanggung jawab finansial pikeun downtime.

   Contona, anjeun tiasa ngadamel mesin virtual sareng pangkalan data dina méga. Aplikasi bakal nyambung ka database externally via channel ngadegkeun atawa tina awan sarua. Upami aya masalah sareng salah sahiji server dina kluster, VM bakal balikan deui dina server tatangga kirang ti 2 menit. Saatos éta, DBMS bakal ngamimitian di dinya, sareng dina sababaraha menit pangkalan data bakal sayogi.

   OTR: diukur dina menit. Sarat ieu tiasa dieusian dina perjanjian sareng panyadia.
   biaya: Urang ngitung biaya sumberdaya awan pikeun aplikasi Anjeun. 
   Naon eta moal ngajaga anjeun tina: ti gagalna masif di situs panyadia urang, contona, alatan kacilakaan di tingkat kota.

2. Kluster aplikasi  

   Upami anjeun hoyong ningkatkeun RTO, anjeun tiasa nguatkeun pilihan sateuacana sareng langsung nempatkeun aplikasi clustered dina awan.

   Anjeun tiasa nerapkeun klaster dina modeu aktip-pasip atanapi aktip-aktip. Urang nyieun sababaraha VM dumasar kana sarat vendor urang. Pikeun reliabilitas anu langkung ageung, kami ngadistribusikaeunana kana server sareng sistem panyimpen anu béda. Upami server sareng salah sahiji pangkalan data gagal, titik cadangan nyandak beban dina sababaraha detik.

   OTR: Diukur dina detik.
   biaya: rada leuwih mahal batan awan biasa, sumberdaya tambahan bakal diperlukeun pikeun clustering.
   Naon eta moal ngajaga anjeun tina: Masih moal ngajagi tina kagagalan dina situs. Tapi gangguan lokal moal salami lami.

   Tina prakna: Perusahaan ritel ngagaduhan sababaraha sistem inpormasi sareng situs wéb. Sadaya pangkalan data lokasina sacara lokal di kantor perusahaan. Teu aya DR anu dipikiran dugi ka kantor ditinggalkeun tanpa kakuatan sababaraha kali berturut-turut. Konsumén éta teu senang jeung ngadat ramatloka. 
    
   Masalah sareng kasadiaan jasa direngsekeun saatos pindah ka awan. Tambih Deui, urang junun ngaoptimalkeun beban dina database ku balancing lalulintas antara titik.

3. Pindah ka méga anu tahan bencana

   Lamun perlu mastikeun yén sanajan musibah alam dina situs utama teu ngaganggu karya anjeun, Anjeun bisa milih awan tahan bencana.Dina pilihan ieu panyadia nyebarkeun klaster virtualization sakuliah 2 puseur data. Réplikasi sinkron konstan lumangsung antara puseur data, hiji-ka-hiji. Saluran antara pusat data ditangtayungan sareng ngalangkungan rute anu béda, ku kituna klaster sapertos kitu henteu sieun masalah jaringan. 

   OTR: nuju 0.
   biaya: Pilihan awan paling mahal. 
   Naon eta moal ngajaga anjeun tina: Eta moal mantuan ngalawan korupsi data, kitu ogé ti faktor manusa, jadi eta disarankeun pikeun nyieun cadangan dina waktos anu sareng. 

   Tina prakna: Salah sahiji klien kami ngembangkeun rencana recovery musibah komprehensif. Ieu mangrupikeun strategi anu anjeunna pilih: 

   • A awan toleran bencana ngajaga aplikasi tina gagal dina tingkat infrastruktur. 
   • Cadangan dua tingkat nyadiakeun panyalindungan bisi kasalahan manusa. Aya dua jinis cadangan: "tiis" sareng "panas". Cadangan "tiis" aya dina kaayaan cacad sareng butuh waktos kanggo nyebarkeun. Cadangan "panas" parantos siap dianggo sareng disimpen deui langkung gancang. Éta disimpen dina sistem panyimpen khusus khusus. Salinan katilu dirékam dina kasét sareng disimpen di rohangan sanés. 

   Saminggu sakali, klien nguji panyalindungan sareng mariksa pungsionalitas sadaya cadangan, kalebet tina kaset. Unggal taun pausahaan nguji sakabéh awan tahan bencana. 

4. Atur réplikasi ka situs séjén 

   Pilihan séjén ngeunaan kumaha carana nyingkahan masalah global dina situs utama: nyadiakeun geo-reservations. Dina basa sejen, nyieun mesin virtual cadangan dina situs di kota sejen. Solusi khusus pikeun DR cocog pikeun ieu: di perusahaan kami kami nganggo VMware vCloud Availability (vCAV). Kalayan bantosanana, anjeun tiasa ngonpigurasikeun panyalindungan antara sababaraha situs panyadia awan atanapi malikkeun kana awan tina situs di tempat. Kuring parantos nyarios langkung rinci ngeunaan skéma pikeun damel sareng vCAV di dieu. 

   RPO jeung RTO: ti 5 menit. 

   biaya: leuwih mahal batan pilihan kahiji, tapi langkung mirah ti réplikasi hardware dina awan bencana-bukti. hargana diwangun ku biaya hiji lisénsi vCAV, waragad administrasi, biaya sumberdaya awan jeung sumberdaya cadangan nurutkeun model PAYG (10% tina biaya sumberdaya gawé pikeun switched kaluar VMs).

   Tina prakna: klien The diteundeun 6 mesin virtual kalawan database béda dina awan kami di Moscow. Mimitina, panyalindungan disadiakeun ku cadangan: sababaraha salinan cadangan disimpen dina awan di Moscow, sarta sababaraha disimpen dina situs St. Lila-lila, databés naék ukuranana, sareng malikkeun deui tina cadangan mimiti nyandak langkung waktos. 
    
   Réplikasi dumasar kana VMware vCloud Kasadiaan ditambahkeun kana cadangan. Réplika mesin virtual disimpen dina situs cadangan di St.. Petersburg sareng diropéa unggal 5 menit. Lamun gagalna lumangsung dina situs utama, karyawan bebas pindah ka replica tina mesin virtual di St Petersburg sarta nuluykeun gawé bareng eta. 

Sadaya solusi anu dianggap nyayogikeun kasadiaan anu luhur, tapi henteu ngajagaan tina leungitna data kusabab virus ransomware atanapi kasalahan karyawan anu teu kahaja. Dina hal ieu, urang peryogi cadangan anu bakal nyayogikeun RPO anu diperyogikeun.

5. Ulah poho ngeunaan cadangan

Sarerea terang yén anjeun kedah ngadamel cadangan, sanaos anjeun gaduh solusi tahan bencana anu paling keren. Janten kuring ngan ukur ngingetkeun sababaraha poin.

Tegesna, cadangan sanés DR. Sareng éta sababna: 

• Geus lila. Lamun data diukur dina terabytes, recovery bakal nyandak leuwih ti hiji jam. Anjeun kedah mulangkeun, ngadaptarkeun jaringan, pariksa yén éta hurung, tingali yén datana aya dina urutan. Janten anjeun tiasa nyayogikeun RTO anu saé upami aya sakedik data. 
• Data bisa jadi teu dibalikeun kahiji kalina, jeung anjeun kudu ngidinan waktu pikeun malikan deui tindakan. Contona, aya kali nalika urang teu nyaho persis lamun data ieu leungit. Hayu urang nyebutkeun leungitna ieu noticed di 15.00, sarta salinan dijieun unggal jam. Ti 15.00 urang tingali dina sagala titik recovery: 14:00, 13:00 jeung saterusna. Upami sistemna penting, urang nyobian ngaleutikan umur titik pamulihan. Tapi upami cadangan seger henteu ngandung data anu diperyogikeun, urang nyandak titik salajengna - ieu mangrupikeun waktos tambahan. 

Dina hal ieu, jadwal cadangan tiasa nyayogikeun anu diperyogikeun RPO. Pikeun cadangan, hal anu penting pikeun nyadiakeun geo-reservations bisi aya masalah sareng situs utama. Disarankeun pikeun nyimpen sababaraha salinan cadangan nyalira.

Rencana pamulihan bencana ahir kedah ngandung sahenteuna 2 alat:  

• Salah sahiji pilihan 1-4, anu bakal ngajaga sistem tina gagal sareng ragrag.
• Nyadangkeun pikeun ngajaga data tina leungitna. 

Éta ogé patut ngurus saluran komunikasi cadangan upami panyadia Internét utama turun. Jeung - voila! - DR di gajih minimum geus siap. 

sumber: www.habr.com