Bayangake: sampeyan nglayani infrastruktur IT ing pusat blanja gedhe. Wis wiwit udan ing kutha. Udan-udan mili ngliwati payon, banyu ngebaki papan eceran nganti jero tungkak. Kulo pengen sing kamar server ora ing ruang paling ngisor, yen masalah ora bisa nyingkiri.
Crita sing digambarake dudu fantasi, nanging deskripsi kolektif saka sawetara acara ing 2020. Ing perusahaan gedhe, rencana pemulihan bencana, utawa rencana pemulihan bencana (DRP), mesthi ana ing kasus iki. Ing perusahaan, iki minangka tanggung jawab spesialis kesinambungan bisnis. Nanging ing perusahaan menengah lan cilik, ngrampungake masalah kasebut ana ing layanan IT. Sampeyan kudu ngerti logika bisnis dhewe, ngerti apa sing bisa gagal lan ing ngendi, nggawe perlindungan lan ngetrapake.
Iku apik yen spesialis IT bisa rembugan karo bisnis lan ngrembug perlu kanggo pangayoman. Nanging aku wis ndeleng luwih saka sepisan carane perusahaan skimped ing Recovery bilai (DR) solusi amarga dianggep keluwih. Nalika ana kacilakan, pemulihan dawa ngancam kerugian, lan bisnis durung siap. Sampeyan bisa mbaleni kaya sing dikarepake: "Aku wis ujar," nanging layanan IT isih kudu mulihake layanan.
Saka posisi arsitek, aku bakal pitutur marang kowe carane supaya kahanan iki. Ing bagean pisanan artikel, aku bakal nuduhake karya persiapan: carane ngrembug telung pitakonan karo pelanggan kanggo milih alat keamanan:
- Apa sing kita lindungi?
- Apa sing kita nglindhungi?
- Carane akeh kita nglindhungi?
Ing bagean kapindho, kita bakal ngomong babagan pilihan kanggo njawab pitakonan: carane mbela diri. Aku bakal menehi conto kasus carane pelanggan beda mbangun perlindungan.
Apa sing kita lindungi: ngenali fungsi bisnis kritis
Luwih becik miwiti nyiapake kanthi ngrembug rencana aksi pasca darurat karo pelanggan bisnis. Kangelan utama ing kene yaiku nemokake basa sing umum. Pelanggan biasane ora peduli karo solusi IT. Dheweke peduli apa layanan kasebut bisa nindakake fungsi bisnis lan nggawa dhuwit. Contone: yen situs kasebut digunakake, nanging sistem pembayaran mudhun, ora ana penghasilan saka klien, lan "ekstremis" isih dadi spesialis IT.
Profesional IT bisa uga angel negosiasi amarga sawetara alasan:
- Layanan IT ora ngerti kanthi lengkap babagan peran sistem informasi ing bisnis. Contone, yen ora ana katrangan babagan proses bisnis utawa model bisnis sing transparan.
- Ora kabeh proses gumantung ing layanan IT. Contone, nalika bagean saka karya dileksanakake dening kontraktor, lan spesialis IT ora duwe pengaruh langsung marang wong-wong mau.
Aku bakal nggawe obrolan kaya iki:
- Kita nerangake marang bisnis manawa kacilakan kedadeyan kanggo kabeh wong, lan pemulihan butuh wektu. Sing paling apik yaiku nduduhake kahanan, kepiye kedadeyan lan akibat apa sing bisa ditindakake.
- Kita nuduhake manawa ora kabeh gumantung karo layanan IT, nanging sampeyan siyap mbantu rencana aksi ing wilayah tanggung jawab sampeyan.
- Kita takon pelanggan bisnis mangsuli: yen kiamat kedadeyan, proses apa sing kudu dipulihake dhisik? Sapa sing melu lan kepiye carane?
Jawaban prasaja dibutuhake saka bisnis, contone: pusat panggilan kudu terus ndhaptar aplikasi 24/7.
- Kita takon siji utawa loro pangguna sistem kanggo njlèntrèhaké proses iki kanthi rinci.
Luwih becik melu analis kanggo mbantu yen perusahaan sampeyan duwe.Kanggo miwiti, gambaran bisa katon kaya iki: pusat panggilan nampa panjalukan liwat telpon, mail lan liwat pesen saka website. Banjur dheweke mlebu menyang 1C liwat antarmuka web, lan produksi njupuk saka kono kanthi cara iki.
- Banjur kita ndeleng apa solusi hardware lan piranti lunak sing ndhukung proses kasebut. Kanggo pangayoman lengkap, kita njupuk telung tingkat:
- aplikasi lan sistem ing situs (tingkat piranti lunak),
- situs dhewe ing ngendi sistem mbukak (tingkat infrastruktur),
- jaringan (padha asring lali babagan).
- Kita nemokake titik kegagalan: simpul sistem sing gumantung karo kinerja layanan kasebut. Kita kapisah nyathet simpul sing didhukung dening perusahaan liyane: operator telekomunikasi, panyedhiya hosting, pusat data, lan liya-liyane. Kanthi iki, sampeyan bisa bali menyang pelanggan bisnis kanggo langkah sabanjure.
Apa kita nglindhungi saka: resiko
Sabanjure, kita ngerteni saka pelanggan bisnis apa risiko sing kita lindungi saka wiwitan. Kabeh risiko bisa dipérang dadi rong klompok:
- mundhut wektu amarga downtime layanan;
- mundhut data amarga pengaruh fisik, faktor manungsa, lsp.
Bisnis wedi kelangan data lan wektu - kabeh iki nyebabake kelangan dhuwit. Dadi maneh kita takon pitakon kanggo saben klompok risiko:
- Kanggo proses iki, kita bisa ngira pinten mundhut data lan wektu mundhut biaya ing dhuwit?
- Apa data sing ora bisa ilang?
- Where kita ora ngidini downtime?
- Acara apa sing paling mungkin lan paling ngancam kita?
Sawise dhiskusi, kita bakal ngerti carane menehi prioritas titik kegagalan.
Pinten kita nglindhungi: RPO lan RTO
Nalika titik kritis gagal cetha, kita ngetung indikator RTO lan RPO.
Ayo kula ngelingake sampeyan RTO (tujuan wektu pemulihan) - iki wektu allowable saka wayahe Laka nganti layanan wis dibalèkaké. Ing basa bisnis, iki minangka downtime sing bisa ditampa. Yen kita ngerti carane akeh dhuwit proses digawa ing, kita bisa ngetung losses saben menit downtime lan ngetung mundhut ditrima.
RPO (tujuan titik pemulihan) - titik Recovery data bener. Iku nemtokake wektu nalika kita bisa ilang data. Saka sudut pandang bisnis, mundhut data bisa nyebabake denda, contone. Kerugian kasebut uga bisa diowahi dadi dhuwit.
Wektu pemulihan kudu diwilang kanggo pangguna pungkasan: suwene dheweke bakal bisa mlebu menyang sistem. Dadi dhisik kita nambahake wektu pemulihan kabeh tautan ing rantai kasebut. Kesalahan asring ditindakake ing kene: dheweke njupuk RTO panyedhiya saka SLA, lan lali babagan syarat sing isih ana.
Ayo katon ing conto tartamtu. Pangguna mlebu menyang 1C, sistem mbukak kanthi kesalahan database. Dheweke ngontak administrator sistem. Database kasebut ana ing méga, administrator sistem nglaporake masalah kasebut menyang panyedhiya layanan. Ayo ngomong kabeh komunikasi njupuk 15 menit. Ing méga, database ukuran iki bakal dibalèkaké saka serep ing jam, mulane, RTO ing sisih panyedhiya layanan sak jam. Nanging iki dudu tenggat pungkasan; kanggo pangguna, 15 menit wis ditambahake kanggo ndeteksi masalah kasebut.
Sabanjure, administrator sistem kudu mriksa manawa database bener, sambungake menyang 1C lan miwiti layanan. Iki mbutuhake jam liyane, tegese RTO ing sisih administrator wis 2 jam 15 menit. Pangguna mbutuhake 15 menit liyane: mlebu, priksa manawa transaksi sing dibutuhake wis katon. 2 jam 30 menit minangka total wektu pemulihan layanan ing conto iki.
Petungan iki bakal nuduhake bisnis apa faktor njaba gumantung periode Recovery. Contone, yen kantor kebanjiran, sampeyan kudu nggoleki bocor lan ndandani. Bakal butuh wektu, sing ora gumantung ing IT.
Cara nglindhungi: milih alat kanggo macem-macem risiko
Sawise ngrembug kabeh poin, pelanggan wis ngerti biaya kacilakan kanggo bisnis kasebut. Saiki sampeyan bisa milih alat lan ngrembug babagan anggaran. Nggunakake conto kasus klien, aku bakal nuduhake sampeyan alat apa sing ditawakake kanggo macem-macem tugas.
Ayo dadi miwiti karo klompok pisanan saka risiko: mundhut amarga downtime layanan. Solusi kanggo masalah iki kudu nyedhiyakake RTO sing apik.
- Tuan rumah aplikasi ing méga
Kanggo miwiti, sampeyan mung bisa pindhah menyang awan - panyedhiya wis mikir babagan masalah kasedhiyan dhuwur. Host virtualisasi dirakit dadi kluster, daya lan jaringan dilindhungi undhang-undhang, data disimpen ing sistem panyimpenan fault-tolerant, lan panyedhiya layanan tanggung jawab finansial kanggo downtime.
Contone, sampeyan bisa dadi tuan rumah mesin virtual kanthi basis data ing méga. Aplikasi kasebut bakal nyambung menyang database eksternal liwat saluran sing diadegake utawa saka awan sing padha. Yen ana masalah karo salah siji saka server ing kluster, VM bakal miwiti maneh ing server tetanggan kurang saka 2 menit. Sawise iku, DBMS bakal diwiwiti, lan ing sawetara menit database bakal kasedhiya.
OTR: diukur ing menit. Istilah kasebut bisa ditemtokake ing persetujuan karo panyedhiya.
biaya: Kita ngetung biaya sumber daya awan kanggo aplikasi sampeyan.
Apa sing ora bakal nglindhungi sampeyan: saka kegagalan massive ing situs panyedhiya, contone, amarga kacilakan ing tingkat kutha. - Cluster aplikasi
Yen sampeyan pengin nambah RTO, sampeyan bisa ngiyatake pilihan sadurunge lan langsung nyelehake aplikasi clustered ing méga.
Sampeyan bisa ngleksanakake kluster ing mode aktif-pasif utawa aktif-aktif. Kita nggawe sawetara VM adhedhasar syarat vendor. Kanggo luwih linuwih, kita nyebarake ing macem-macem server lan sistem panyimpenan. Yen server karo salah siji saka database gagal, simpul serep njupuk liwat mbukak ing sawetara detik.
OTR: Diukur ing detik.
biaya: rada luwih larang tinimbang awan biasa, sumber daya tambahan bakal dibutuhake kanggo clustering.
Apa sing ora bakal nglindhungi sampeyan: Isih ora bakal nglindhungi saka massive ing situs gagal. Nanging gangguan lokal ora bakal suwe.Saka laku: Perusahaan ritel duwe sawetara sistem informasi lan situs web. Kabeh database dumunung sacara lokal ing kantor perusahaan. Ora ana DR sing dipikir nganti kantor ditinggal tanpa daya kaping pirang-pirang. Pelanggan ora seneng karo kacilakan situs web.
Masalah karo kasedhiyan layanan ditanggulangi sawise pindhah menyang awan. Kajaba iku, kita bisa ngoptimalake beban ing basis data kanthi ngimbangi lalu lintas ing antarane simpul. - Pindhah menyang awan sing tahan bencana
Yen sampeyan kudu mesthekake yen sanajan bencana alam ing situs utama ora ngganggu karya sampeyan, sampeyan bisa milih awan tahan bencana. Ing pilihan iki, panyedhiya nyebar kluster virtualisasi ing 2 pusat data. Replikasi sinkron sing terus-terusan dumadi ing antarane pusat data, siji-kanggo-siji. Saluran antarane pusat data dilindhungi undhang-undhang lan ngliwati rute sing beda-beda, saengga kluster kasebut ora wedi karo masalah jaringan.
OTR: cenderung 0.
biaya: Pilihan maya paling larang.
Apa sing ora bakal nglindhungi sampeyan: Ora bakal mbantu nglawan korupsi data, uga saka faktor manungsa, mula dianjurake kanggo nggawe serep bebarengan.Saka laku: Salah sawijining klien kita ngembangake rencana pemulihan bencana sing komprehensif. Iki strategi sing dipilih:
- Awan sing tahan bencana nglindhungi aplikasi saka kegagalan ing tingkat infrastruktur.
- Serep rong tingkat nyedhiyakake proteksi yen ana kesalahan manungsa. Ana rong jinis serep: "kadhemen" lan "panas". A serep "kadhemen" ing negara dipatèni lan njupuk wektu kanggo masang. Serep "panas" wis siyap digunakake lan dibalèkaké luwih cepet. Iki disimpen ing sistem panyimpenan khusus. Salinan katelu direkam ing tape lan disimpen ing kamar liyane.
Sawise seminggu, klien nyoba proteksi lan mriksa fungsi kabeh serep, kalebu saka tape. Saben taun perusahaan nguji kabeh awan tahan bencana.
- Ngatur replikasi menyang situs liyane
Pilihan liyane babagan carane supaya masalah global ing situs utama: nyedhiyani geo-reservasi. Ing tembung liyane, nggawe mesin virtual serep ing situs ing kutha liyane. Solusi khusus kanggo DR cocok kanggo iki: ing perusahaan kita nggunakake VMware vCloud Availability (vCAV). Kanthi bantuan, sampeyan bisa ngatur proteksi ing antarane sawetara situs panyedhiya maya utawa mulihake menyang awan saka situs on-premise. Aku wis ngomong kanthi luwih rinci babagan skema kanggo nggarap vCAV .
RPO lan RTO: saka 5 menit.
biaya: luwih larang saka pilihan pisanan, nanging luwih murah tinimbang replikasi hardware ing maya bilai-bukti. Rega kasebut kalebu biaya lisensi vCAV, biaya administrasi, biaya sumber daya awan lan sumber daya cadangan miturut model PAYG (10% saka biaya sumber daya kanggo VM sing dipateni).
Saka laku: Klien nyimpen 6 mesin virtual kanthi basis data beda ing awan kita ing Moskow. Ing wiwitan, proteksi diwenehake dening cadangan: sawetara salinan serep disimpen ing awan ing Moskow, lan sawetara disimpen ing situs St. Swara wektu, database ageng ing ukuran, lan mulihake saka serep wiwit njupuk wektu liyane.
Replikasi adhedhasar VMware vCloud Availability ditambahake menyang serep. Replika mesin virtual disimpen ing situs serep ing St.. Petersburg lan dianyari saben 5 menit. Yen ana kegagalan ing situs utama, karyawan kanthi mandiri ngalih menyang replika mesin virtual ing St. Petersburg lan terus nggarap.
Kabeh solusi sing dianggep nyedhiyakake kasedhiyan dhuwur, nanging ora nglindhungi mundhut data amarga virus ransomware utawa kesalahan karyawan sing ora disengaja. Ing kasus iki, kita butuh serep sing bakal nyedhiyakake RPO sing dibutuhake.
5. Aja lali babagan serep
Saben uwong ngerti yen sampeyan kudu nggawe serep, sanajan sampeyan duwe solusi tahan bencana sing paling apik. Dadi aku mung bakal ngelingake sampeyan sawetara poin.
Strictly ngandika, serep ora DR. Lan mulane:
- Iku dangu. Yen data diukur ing terabyte, pemulihan bakal njupuk luwih saka siji jam. Sampeyan kudu mulihake, nemtokake jaringan, priksa manawa diuripake, priksa manawa data kasebut ana ing urutan. Supaya sampeyan bisa nyedhiyani RTO apik mung yen ana sethitik data.
- Data bisa uga ora bisa dibalekake sepisanan, lan sampeyan kudu menehi wektu kanggo mbaleni tumindak kasebut. Contone, ana wektu nalika kita ora ngerti persis nalika data ilang. Ayo dadi ngomong mundhut wis ngeweruhi ing 15.00, lan salinan digawe saben jam. Saka 15.00 kita katon ing kabeh titik Recovery: 14:00, 13:00 lan ing. Yen sistem penting, kita nyoba kanggo nyilikake umur titik Recovery. Nanging yen serep seger ora ngemot data sing dibutuhake, kita njupuk titik sabanjure - iki wektu tambahan.
Ing kasus iki, jadwal serep bisa nyedhiyani sing dibutuhake RPO. Kanggo serep, penting kanggo nyedhiyakake geo-reservasi yen ana masalah karo situs utama. Disaranake kanggo nyimpen sawetara salinan serep kanthi kapisah.
Rencana pemulihan bencana pungkasan kudu ngemot paling ora 2 alat:
- Salah siji opsi 1-4, sing bakal nglindhungi sistem saka gagal lan tiba.
- Gawe serep kanggo nglindhungi data saka mundhut.
Sampeyan uga kudu ngurus saluran komunikasi serep yen panyedhiya Internet utama mudhun. Lan - voila! - DR ing upah minimum wis siyap.
Source: www.habr.com