Biarkan sekurang-kurangnya banjir, tetapi 1C harus berfungsi! Berunding dengan perniagaan tentang DR

Bayangkan: anda sedang menyediakan infrastruktur IT pusat beli-belah yang besar. Hujan mula turun di bandar. Aliran hujan meredah bumbung, air memenuhi premis runcit sedalam buku lali. Kami berharap bilik pelayan anda tidak berada di ruang bawah tanah, jika tidak masalah tidak dapat dielakkan.  

Kisah yang diterangkan bukanlah fantasi, tetapi penerangan kolektif tentang beberapa peristiwa pada tahun 2020. Dalam syarikat besar, pelan pemulihan bencana, atau pelan pemulihan bencana (DRP), sentiasa tersedia untuk kes ini. Dalam syarikat, ini adalah tanggungjawab pakar kesinambungan perniagaan. Tetapi dalam syarikat sederhana dan kecil, menyelesaikan masalah sedemikian terletak pada perkhidmatan IT. Anda perlu memahami logik perniagaan sendiri, memahami apa yang boleh gagal dan di mana, tampil dengan perlindungan dan melaksanakannya. 

Sangat bagus jika pakar IT boleh berunding dengan perniagaan dan membincangkan keperluan untuk perlindungan. Tetapi saya telah melihat lebih daripada sekali bagaimana syarikat berhemat dalam penyelesaian pemulihan bencana (DR) kerana menganggapnya berlebihan. Apabila kemalangan berlaku, pemulihan yang lama mengancam kerugian, dan perniagaan tidak bersedia. Anda boleh mengulangi seberapa banyak yang anda suka: "Saya memberitahu anda begitu," tetapi perkhidmatan IT masih perlu memulihkan perkhidmatan.

Dari kedudukan seorang arkitek, saya akan memberitahu anda bagaimana untuk mengelakkan situasi ini. Dalam bahagian pertama artikel, saya akan menunjukkan kerja persediaan: cara membincangkan tiga soalan dengan pelanggan untuk memilih alat keselamatan: 

• Apa yang kita lindungi?
• Apa yang kita lindungi?
• Sejauh mana kita melindungi? 

Di bahagian kedua, kita akan bercakap tentang pilihan untuk menjawab soalan: bagaimana untuk mempertahankan diri. Saya akan memberikan contoh kes bagaimana pelanggan yang berbeza membina perlindungan mereka.

Perkara yang kami lindungi: mengenal pasti fungsi perniagaan kritikal 

Adalah lebih baik untuk memulakan persediaan dengan membincangkan pelan tindakan selepas kecemasan dengan pelanggan perniagaan. Kesukaran utama di sini adalah untuk mencari bahasa yang sama. Pelanggan biasanya tidak peduli bagaimana penyelesaian IT berfungsi. Dia mengambil berat sama ada perkhidmatan itu boleh melaksanakan fungsi perniagaan dan membawa masuk wang. Sebagai contoh: jika tapak berfungsi, tetapi sistem pembayaran tidak berfungsi, tiada pendapatan daripada pelanggan, dan "pelampau" masih pakar IT. 

Seorang profesional IT mungkin mengalami kesukaran dalam rundingan sedemikian kerana beberapa sebab:

• Perkhidmatan IT tidak memahami sepenuhnya peranan sistem maklumat dalam perniagaan. Contohnya, jika tiada penerangan tersedia tentang proses perniagaan atau model perniagaan yang telus. 
• Bukan keseluruhan proses bergantung pada perkhidmatan IT. Sebagai contoh, apabila sebahagian daripada kerja dilakukan oleh kontraktor, dan pakar IT tidak mempunyai pengaruh langsung terhadap mereka.

Saya akan menyusun perbualan seperti ini: 

1. Kami menerangkan kepada perniagaan bahawa kemalangan berlaku kepada semua orang, dan pemulihan memerlukan masa. Perkara terbaik ialah menunjukkan situasi, bagaimana ini berlaku dan apakah akibat yang mungkin.
2. Kami menunjukkan bahawa tidak semuanya bergantung pada perkhidmatan IT, tetapi anda bersedia membantu dengan pelan tindakan dalam bidang tanggungjawab anda.
3. Kami meminta pelanggan perniagaan menjawab: jika kiamat berlaku, proses manakah yang perlu dipulihkan dahulu? Siapa yang menyertainya dan bagaimana? 

   Jawapan mudah diperlukan daripada perniagaan, sebagai contoh: pusat panggilan perlu meneruskan pendaftaran permohonan 24/7.

4. Kami meminta satu atau dua pengguna sistem untuk menerangkan proses ini secara terperinci. 
   Adalah lebih baik untuk melibatkan penganalisis untuk membantu jika syarikat anda mempunyainya.

   Sebagai permulaan, huraian mungkin kelihatan seperti ini: pusat panggilan menerima permintaan melalui telefon, melalui mel dan melalui mesej daripada tapak web. Kemudian dia memasukkannya ke dalam 1C melalui antara muka web, dan pengeluaran membawanya dari sana dengan cara ini.

5. Kemudian kita melihat penyelesaian perkakasan dan perisian yang menyokong proses tersebut. Untuk perlindungan menyeluruh, kami mengambil kira tiga peringkat: 
   • aplikasi dan sistem dalam tapak (peringkat perisian),   
   • tapak itu sendiri di mana sistem berjalan (peringkat infrastruktur), 
   • rangkaian (mereka sering melupakannya).

6. Kami mengetahui kemungkinan titik kegagalan: nod sistem yang bergantung kepada prestasi perkhidmatan. Kami secara berasingan mencatatkan nod yang disokong oleh syarikat lain: pengendali telekomunikasi, penyedia pengehosan, pusat data dan sebagainya. Dengan ini, anda boleh kembali kepada pelanggan perniagaan untuk langkah seterusnya.

Perkara yang kita lindungi daripada: risiko

Seterusnya, kami mengetahui daripada pelanggan perniagaan apakah risiko yang kami lindungi dari awal. Semua risiko boleh dibahagikan kepada dua kumpulan: 

• kehilangan masa akibat masa berhenti perkhidmatan;
• kehilangan data akibat kesan fizikal, faktor manusia, dsb.

Perniagaan takut kehilangan kedua-dua data dan masa - semua ini membawa kepada kehilangan wang. Jadi sekali lagi kami bertanya soalan untuk setiap kumpulan risiko: 

• Untuk proses ini, bolehkah kita menganggarkan berapa banyak kehilangan data dan kos kehilangan masa dalam wang? 
• Apakah data yang kita tidak boleh hilang? 
• Di manakah kita tidak boleh membenarkan masa rehat? 
• Apakah peristiwa yang paling mungkin dan paling mengancam kita?

Selepas perbincangan, kami akan memahami cara mengutamakan mata kegagalan. 

Sejauh mana kami melindungi: RPO dan RTO 

Apabila titik kritikal kegagalan jelas, kami mengira penunjuk RTO dan RPO. 

Biarkan saya mengingatkan anda bahawa RTO (objektif masa pemulihan) — ini ialah masa yang dibenarkan dari saat kemalangan sehingga perkhidmatan dipulihkan sepenuhnya. Dalam bahasa perniagaan, ini adalah masa henti yang boleh diterima. Jika kita tahu berapa banyak wang yang dibawa oleh proses itu, kita boleh mengira kerugian dari setiap minit masa henti dan mengira kerugian yang boleh diterima. 

RPO (objektif titik pemulihan) — titik pemulihan data yang sah. Ia menentukan masa di mana kita boleh kehilangan data. Dari sudut perniagaan, kehilangan data boleh mengakibatkan denda, contohnya. Kerugian sedemikian juga boleh ditukar kepada wang. 

Masa pemulihan perlu dikira untuk pengguna akhir: berapa lama dia boleh log masuk ke sistem. Jadi mula-mula kita tambahkan masa pemulihan semua pautan dalam rantaian. Ralat sering dilakukan di sini: mereka mengambil RTO penyedia daripada SLA, dan melupakan syarat yang tinggal.

Mari lihat contoh khusus. Pengguna log masuk ke 1C, sistem dibuka dengan ralat pangkalan data. Dia menghubungi pentadbir sistem. Pangkalan data terletak di awan, pentadbir sistem melaporkan masalah kepada pembekal perkhidmatan. Katakan semua komunikasi mengambil masa 15 minit. Dalam awan, pangkalan data bersaiz ini akan dipulihkan daripada sandaran dalam masa sejam, oleh itu, RTO pada bahagian penyedia perkhidmatan ialah sejam. Tetapi ini bukan tarikh akhir terakhir; bagi pengguna, 15 minit telah ditambahkan padanya untuk mengesan masalah. 
 
Seterusnya, pentadbir sistem perlu menyemak sama ada pangkalan data adalah betul, sambungkannya ke 1C dan mulakan perkhidmatan. Ini memerlukan satu jam lagi, yang bermaksud RTO di pihak pentadbir sudah pun 2 jam dan 15 minit. Pengguna memerlukan 15 minit lagi: log masuk, semak bahawa transaksi yang diperlukan telah muncul. 2 jam 30 minit ialah jumlah masa pemulihan perkhidmatan dalam contoh ini.

Pengiraan ini akan menunjukkan perniagaan tentang faktor luaran yang bergantung kepada tempoh pemulihan. Sebagai contoh, jika pejabat dinaiki air, anda perlu mencari kebocoran dan membetulkannya terlebih dahulu. Ia akan mengambil masa, yang tidak bergantung pada IT.  

Cara kami melindungi: memilih alat untuk risiko yang berbeza

Selepas membincangkan semua perkara, pelanggan sudah memahami kos kemalangan untuk perniagaan. Kini anda boleh memilih alat dan membincangkan belanjawan. Menggunakan contoh kes pelanggan, saya akan menunjukkan kepada anda alat yang kami tawarkan untuk tugasan yang berbeza. 

Mari kita mulakan dengan kumpulan risiko pertama: kerugian akibat masa berhenti perkhidmatan. Penyelesaian untuk masalah ini harus menyediakan RTO yang baik.

1. Hos aplikasi dalam awan 

   Sebagai permulaan, anda hanya boleh beralih ke awan - pembekal telah memikirkan isu ketersediaan tinggi. Hos virtualisasi dihimpunkan menjadi satu kluster, kuasa dan rangkaian dikhaskan, data disimpan pada sistem storan tahan kerosakan, dan pembekal perkhidmatan bertanggungjawab dari segi kewangan untuk masa henti.

   Sebagai contoh, anda boleh menjadi hos mesin maya dengan pangkalan data dalam awan. Aplikasi akan menyambung ke pangkalan data secara luaran melalui saluran yang ditetapkan atau dari awan yang sama. Jika masalah timbul dengan salah satu pelayan dalam kelompok, VM akan dimulakan semula pada pelayan jiran dalam masa kurang daripada 2 minit. Selepas itu, DBMS akan dimulakan di dalamnya, dan dalam beberapa minit pangkalan data akan tersedia.

   RTO: diukur dalam minit. Terma ini boleh dinyatakan dalam perjanjian dengan pembekal.
   Kos: Kami mengira kos sumber awan untuk aplikasi anda. 
   Perkara yang tidak akan melindungi anda daripadanya: daripada kegagalan besar-besaran di tapak penyedia, contohnya, disebabkan oleh kemalangan di peringkat bandar.

2. Kelompokkan aplikasi  

   Jika anda ingin menambah baik RTO, anda boleh mengukuhkan pilihan sebelumnya dan segera meletakkan aplikasi berkelompok dalam awan.

   Anda boleh melaksanakan kluster dalam mod aktif-pasif atau aktif-aktif. Kami mencipta beberapa VM berdasarkan keperluan vendor. Untuk kebolehpercayaan yang lebih besar, kami mengedarkannya ke seluruh pelayan dan sistem storan yang berbeza. Jika pelayan dengan salah satu pangkalan data gagal, nod sandaran mengambil alih beban dalam beberapa saat.

   RTO: Diukur dalam saat.
   Kos: lebih mahal sedikit daripada awan biasa, sumber tambahan akan diperlukan untuk pengelompokan.
   Perkara yang tidak akan melindungi anda daripadanya: Masih tidak akan melindungi daripada kegagalan besar di tapak. Tetapi gangguan tempatan tidak akan bertahan lama.

   Dari amalan: Syarikat runcit mempunyai beberapa sistem maklumat dan laman web. Semua pangkalan data terletak secara tempatan di pejabat syarikat. Tiada DR difikirkan sehingga pejabat itu dibiarkan tanpa kuasa beberapa kali berturut-turut. Pelanggan tidak berpuas hati dengan ranap tapak web. 
    
   Masalah dengan ketersediaan perkhidmatan telah diselesaikan selepas berpindah ke awan. Selain itu, kami berjaya mengoptimumkan beban pada pangkalan data dengan mengimbangi trafik antara nod.

3. Beralih ke awan kalis bencana

   Jika anda perlu memastikan bahawa walaupun bencana alam di tapak utama tidak mengganggu kerja anda, anda boleh memilih awan tahan bencana. Dalam pilihan ini, pembekal mengedarkan kluster virtualisasi merentasi 2 pusat data. Replikasi segerak berterusan berlaku antara pusat data, satu-satu. Saluran antara pusat data dikhaskan dan melalui laluan yang berbeza, jadi kluster sedemikian tidak takut dengan masalah rangkaian. 

   RTO: cenderung kepada 0.
   Kos: Pilihan awan yang paling mahal. 
   Perkara yang tidak akan melindungi anda daripadanya: Ia tidak akan membantu terhadap rasuah data, serta dari faktor manusia, jadi disyorkan untuk membuat sandaran pada masa yang sama. 

   Dari amalan: Salah seorang pelanggan kami membangunkan pelan pemulihan bencana yang komprehensif. Ini adalah strategi yang beliau pilih: 

   • Awan tahan bencana melindungi aplikasi daripada kegagalan di peringkat infrastruktur. 
   • Sandaran dua peringkat menyediakan perlindungan sekiranya berlaku kesilapan manusia. Terdapat dua jenis sandaran: "sejuk" dan "panas". Sandaran "sejuk" berada dalam keadaan dilumpuhkan dan mengambil masa untuk digunakan. Sandaran "panas" sudah sedia untuk digunakan dan dipulihkan dengan lebih cepat. Ia disimpan pada sistem storan khusus. Salinan ketiga dirakam pada pita dan disimpan di bilik lain. 

   Sekali seminggu, pelanggan menguji perlindungan dan menyemak kefungsian semua sandaran, termasuk yang daripada pita. Setiap tahun syarikat menguji keseluruhan awan tahan bencana. 

4. Susun replikasi ke tapak lain 

   Pilihan lain tentang cara untuk mengelakkan masalah global di tapak utama: sediakan tempahan geo. Dengan kata lain, cipta mesin maya sandaran di tapak di bandar lain. Penyelesaian khas untuk DR sesuai untuk ini: di syarikat kami, kami menggunakan VMware vCloud Availability (vCAV). Dengan bantuannya, anda boleh mengkonfigurasi perlindungan antara beberapa tapak pembekal awan atau memulihkan ke awan dari tapak di premis. Saya telah bercakap dengan lebih terperinci tentang skim untuk bekerja dengan vCAV di sini. 

   RPO dan RTO: dari 5 minit. 

   Kos: lebih mahal daripada pilihan pertama, tetapi lebih murah daripada replikasi perkakasan dalam awan kalis bencana. Harga terdiri daripada kos lesen vCAV, yuran pentadbiran, kos sumber awan dan sumber rizab mengikut model PAYG (10% daripada kos sumber kerja untuk VM yang dimatikan).

   Dari amalan: Pelanggan menyimpan 6 mesin maya dengan pangkalan data berbeza dalam awan kami di Moscow. Pada mulanya, perlindungan disediakan melalui sandaran: beberapa salinan sandaran disimpan di awan di Moscow, dan sebahagian lagi disimpan di tapak St. Petersburg kami. Dari masa ke masa, pangkalan data berkembang dalam saiz, dan memulihkan daripada sandaran mula mengambil lebih banyak masa. 
    
   Replikasi berdasarkan VMware vCloud Availability telah ditambahkan pada sandaran. Replika mesin maya disimpan di tapak sandaran di St. Petersburg dan dikemas kini setiap 5 minit. Jika kegagalan berlaku di tapak utama, pekerja secara bebas bertukar kepada replika mesin maya di St. Petersburg dan terus bekerja dengannya. 

Semua penyelesaian yang dipertimbangkan menyediakan ketersediaan yang tinggi, tetapi tidak melindungi daripada kehilangan data akibat virus ransomware atau ralat pekerja yang tidak disengajakan. Dalam kes ini, kami memerlukan sandaran yang akan menyediakan RPO yang diperlukan.

5. Jangan lupa tentang sandaran

Semua orang tahu bahawa anda perlu membuat sandaran, walaupun anda mempunyai penyelesaian kalis bencana yang paling hebat. Jadi saya hanya akan mengingatkan anda secara ringkas tentang beberapa perkara.

Tegasnya, sandaran bukanlah DR. Dan itulah sebabnya: 

• dah lama dah. Jika data diukur dalam terabait, pemulihan akan mengambil masa lebih daripada satu jam. Anda perlu memulihkan, menetapkan rangkaian, semak bahawa ia dihidupkan, lihat bahawa data adalah teratur. Jadi anda boleh menyediakan RTO yang baik hanya jika terdapat sedikit data. 
• Data mungkin tidak dapat dipulihkan pada kali pertama, dan anda perlu memberi masa untuk mengulangi tindakan itu. Contohnya, ada kalanya kita tidak tahu dengan tepat bila data hilang. Katakan kehilangan itu disedari pada pukul 15.00, dan salinan dibuat setiap jam. Dari jam 15.00 kami melihat semua titik pemulihan: 14:00, 13:00 dan seterusnya. Jika sistem itu penting, kami cuba meminimumkan umur titik pemulihan. Tetapi jika sandaran baru tidak mengandungi data yang diperlukan, kami mengambil titik seterusnya - ini adalah masa tambahan. 

Dalam kes ini, jadual sandaran boleh menyediakan yang diperlukan RPO. Untuk sandaran, adalah penting untuk menyediakan tempahan geo sekiranya terdapat masalah dengan tapak utama. Adalah disyorkan untuk menyimpan beberapa salinan sandaran secara berasingan.

Pelan pemulihan bencana akhir harus mengandungi sekurang-kurangnya 2 alat:  

• Salah satu daripada pilihan 1-4, yang akan melindungi sistem daripada kegagalan dan kejatuhan.
• Sandaran untuk melindungi data daripada kehilangan. 

Ia juga patut menjaga saluran komunikasi sandaran sekiranya pembekal Internet utama terputus. Dan - voila! — DR pada gaji minimum sudah sedia. 

Sumber: www.habr.com