Saya pikir tidak ada yang akan berpendapat bahwa memiliki cadangan yang dapat diandalkan dan infrastruktur cadangan selalu baik. Jumlah bencana alam dan ulah manusia di dunia terus bertambah setiap tahun, dan kerusakan yang diakibatkannya diukur dalam ratusan miliar dolar. Meskipun kesempatan untuk menderita dari insiden besar tidak begitu besar, tetapi kami menghadapi masalah lokal dalam semangat pemadaman listrik, banjir atau kebakaran di ruang server cukup sering.
Apa pun bisa terjadi - kadang-kadang karyawan yang tersinggung membalas dendam pada bisnis, kadang-kadang otoritas penegak hukum merebut peralatan, kadang-kadang alamat IP asing secara tidak sengaja jatuh di bawah blok Roskomnadzor, dan begitu sebuah truk melaju ke ruang server lokal pelanggan kami, langsung menembus dinding dari jalan.
Apakah semua perusahaan memerlukan cadangan panas untuk dengan cepat beralih ke situs kedua? Bahkan tidak. Pencadangan waktu-nyata relevan jika proses bisnis penting untuk layanan pelanggan berkelanjutan sangat tergantung pada perangkat lunak yang berjalan di server pusat. Dalam hal ini, kehilangan gambar juga menakutkan, dan biaya waktu henti cukup mudah untuk dihitung, itulah sebabnya uang untuk RDC biasanya ditemukan. Terlebih lagi, sistem IT semacam itu pada awalnya dirancang dalam versi yang tahan bencana.
Jika tidak tersedianya sistem TI hanya menyebabkan terbuangnya waktu kerja karyawan dan secara hipotetis dapat menyebabkan denda untuk laporan yang terlambat diajukan atau pembeli misteri yang dilayani dengan buruk, maka bisnis dengan enggan menyetujui biaya cadangan panas.
Kesulitannya adalah jika Anda datang ke integrator sistem dengan tugas cadangan, maka sesuai dengan pengalaman Anda, kemungkinan besar Anda akan ditawari pendekatan teruji dengan analisis risiko bisnis, pengembangan DRP, dan solusi berbasis perangkat keras dengan fungsi sinkronisasi perangkat keras. Selain biayanya yang tinggi, solusi semacam itu memiliki satu kelemahan lagi - mereka sulit diimplementasikan tanpa modernisasi yang signifikan dari situs utama, yang, sebagai suatu peraturan, tidak seorang pun ingin menyentuh sekali lagi.
Namun demikian, untuk sistem bisnis yang benar-benar kritis, ini adalah risiko dan biaya yang dapat dibenarkan, karena tidak mungkin sebaliknya, tetapi bagaimana jika sistem tidak cukup kritis untuk proyek "dewasa" dan cantik?
Anda dapat, tentu saja, mencapai kesepakatan dan tidak melakukan apa-apa, dan jika sesuatu terjadi, angkat bahu dan dapatkan topi dari bisnis. Anda dapat mengontrak integrator untuk menghitung pusat data cadangan, membuat pilot, mengevaluasi anggaran, memberikan solusi untuk bisnis, mendapatkan "belum ada uang" sebagai respons, dan menunda proyek hingga waktu yang lebih baik. Ini, tentu saja, tidak akan menyelamatkan perusahaan dari downtime, tetapi sulit bagi departemen TI untuk membuat klaim dalam hal force majeure, karena "well, kami menawarkan Anda", dan pengetahuan baru tentang pasar solusi DR tidak akan berlebihan. Opsi semacam itu juga memiliki hak untuk hidup, tetapi bisnis tersebut mungkin tidak dapat bertahan dengan hilangnya data, dan kemudian Anda harus mencari pekerjaan baru.
Anda tidak dapat berinvestasi di pusat data cadangan lengkap, tetapi membuat hidup Anda lebih mudah untuk masa depan dengan menyiapkan cadangan data sekunder (atau bahkan primer) ke cloud. Saat ini layanan BaaS (cadangan sebagai layanan) ditawarkan oleh banyak penyedia layanan, dan berdasarkan berbagai perangkat lunak. Jika Anda menggunakan beberapa solusi cadangan yang populer di dalam, Anda pasti dapat menemukan layanan serupa dengan integrasi asli yang nyaman dengan perangkat lunak Anda saat ini. Atau, sebagai opsi, Anda dapat menyewa penyimpanan S3-murah yang murah dari penyedia dan menyimpan cadangan di sana - solusi dari banyak vendor saat ini mendukung protokol S3. Keuntungan dari pendekatan ini jelas - untuk uang yang masuk akal Anda mendapatkan asuransi terhadap risiko dibiarkan tanpa akses fisik ke data dan kemampuan untuk pulih di cloud yang sama jika diperlukan.
Seberapa cepat Anda dapat mengangkat sistem dari cadangan tergantung pada upaya yang dihabiskan untuk pengujian sebelumnya, ketersediaan sumber daya prabayar untuk pemulihan dan prosedur DR yang ditulis bersama dengan penyedia layanan. Namun, bahkan jika Anda hanya memiliki cadangan kosong, Anda masih menjalankan sistem bisnis Anda di cloud, meskipun tidak terlalu cepat, dan dukungan pemasok BaaS akan membantu Anda dalam hal ini.
Tetapi bagaimana jika kerusakan dari downtime sistem TI jelas bagi semua orang, tetapi tidak begitu besar untuk dibelanjakan pada proyek DR penuh dengan analisis risiko bisnis dan peralatan dan situs kedua?
Di sini, penyedia layanan kembali datang untuk menyelamatkan, menawarkan infrastruktur cloud yang sudah didistribusikan di beberapa situs geografis. Anda hanya perlu memindahkan server Anda ke cloud, dan penyedia layanan akan mengurus sisanya.
Jika Anda tidak ingin beralih ke cloud sepenuhnya karena suatu alasan (misalnya, jika Anda baru-baru ini menghabiskan perangkat keras dan server Anda sendiri), maka opsi dengan sinkronisasi perangkat lunak di cloud dari beberapa server yang sangat bernilai sangat cocok. Anda dapat menyewa sumber daya komputasi dan penyedia layanan cloud, perangkat lunak sinkronisasi yang tersedia dari penyedia cloud dan memberikan solusi DR terperinci untuk dukungan. Ini adalah pilihan yang cukup nyaman, dan Anda tidak perlu membayar untuk pemeriksaan sistem TI Anda, persiapan proyek teknis dan tahap lain dari proyek penuh - Anda dapat membatasi diri untuk pengaturan standar yang murah.
Menggunakan layanan cloud menghilangkan kebutuhan untuk memprediksi jumlah lisensi yang diperlukan untuk perangkat lunak DR dan setiap tahun membayar perpanjangan dukungan vendor untuk mempertahankan akses ke pembaruan. Jika terjadi kesulitan, Anda dapat dengan cepat mendapatkan dukungan teknis dari dukungan penyedia dalam bahasa Rusia (bukan psikologis dalam bahasa Inggris, seperti yang sering terjadi pada vendor). Bagaimanapun, hoster mengetahui layanannya, karena dikonfigurasi dan dipelihara olehnya, dan produsen perangkat lunak harus memahami log dan korespondensi dengan susah payah, apa yang dikonfigurasi dan apa yang ada di dalam Anda.
Secara umum, menyewa layanan dari cloud dibandingkan dengan membeli peralatan untuk suatu proyek memiliki nilai tambah yang signifikan, bahkan jika kita tidak membandingkan biaya kepemilikan. Ini adalah biaya rendah jika terjadi kesalahan. Jika tidak lepas landas dengan cara apa pun, maka kami hanya menolak layanan dari hoster dan itu saja, tetapi Anda tidak bisa menolak besi Anda lagi.
Kisah-kisah seperti itu sebenarnya akrab bagi banyak pemimpin TI. Beberapa tahun yang lalu kami melakukan survei cloud-ready di sebuah perusahaan teknik, dan salah satu prasyarat untuk pindah ke cloud adalah lambatnya sistem bisnis. Semua data aplikasi ada di penyimpanan entry-level, dan kinerjanya cukup basi. Namun, selama audit, kami menemukan pada klien layanan kelas menengah yang sangat baik dari vendor terkenal yang bertindak sebagai penukar file. Menanggapi pertanyaan bodoh kami, "mengapa?" pelanggan bercerita tentang kehilangan data karena bug langka dan keengganan untuk mengambil risiko lagi, meskipun vendor telah memperbaiki bug sejak lama.
Sebenarnya, dalam praktik ActiveCloud, ada banyak situasi ketika besi yang dibeli tidak dapat digunakan untuk tujuan aslinya, atau dimasukkan ke dalam pertempuran dengan penundaan selama beberapa bulan. Apakah ada baiknya mengambil risiko ini sendiri, ketika Anda dapat mentransfernya ke penyedia, pertanyaannya menarik.
ActiveCloud menawarkan kepada pelanggannya
layanan cadangan ke penyimpanan cloud berdasarkan perangkat lunak Veeam dan
layanan cadangan panas ke cloud berdasarkan perangkat lunak Carbonite (ex-Double-Take). Layanan memungkinkan Anda untuk mencadangkan secara berkala atau secara real time menyinkronkan server besi dan virtual dengan cloud di semua hypervisor populer. Layanan ditawarkan sesuai dengan model rental dan mencakup semua yang Anda butuhkan: sumber daya cloud, perangkat lunak yang diperlukan, dukungan 24x7 dan pengaturan awal yang cepat.
Jika Anda memiliki tugas dan keinginan yang sama untuk membahasnya, tulis ke
dmitriy.yashin@activecloud.ru .